נקודת מבט על AI ו-ML: אבטחה

Last reviewed 2025-11-26 UTC

במסמך הזה, שמופיע בWell-Architected Framework: AI and ML perspective, יש סקירה כללית של עקרונות והמלצות שיעזרו לכם לוודא שהפריסות של ה-AI וה-ML עומדות בדרישות האבטחה והתאימות של הארגון. ההמלצות במסמך הזה תואמות לsecurity pillar של Google Cloud Well-Architected Framework.

פריסה מאובטחת של עומסי עבודה של AI ו-ML היא דרישה קריטית, במיוחד בסביבות ארגוניות. כדי לעמוד בדרישה הזו, אתם צריכים לאמץ גישה הוליסטית לאבטחה שמתחילה מהשלב הראשוני של גיבוש הרעיון לפתרונות ה-AI וה-ML שלכם, ונמשכת לשלבי הפיתוח, הפריסה והתפעול השוטף. Google Cloud מציעה כלים ושירותים חזקים שנועדו לעזור לכם לאבטח את עומסי העבודה של ה-AI וה-ML.

ההמלצות במסמך הזה ממופות לעקרונות הליבה הבאים:

למידע נוסף על אבטחת AI, אפשר גם לעיין במקורות המידע הבאים:

  • Google Cloud‫Secure AI Framework‏ (SAIF) הוא מדריך מקיף ליצירת מערכות AI מאובטחות ואחראיות. הוא מפרט עקרונות מרכזיים ושיטות מומלצות לטיפול בשיקולי אבטחה ותאימות לאורך מחזור החיים של ה-AI.
  • ב-Compliance resource center, מרכז המשאבים המשפטיים, מפורט על הגישה של Google Cloudלנושא האמון ב-AI.

הגדרת יעדים ודרישות ברורים

אבטחה יעילה של AI ולמידת מכונה היא רכיב מרכזי באסטרטגיה העסקית הכוללת שלכם. קל יותר לשלב את אמצעי האבטחה והתאימות הנדרשים בשלב מוקדם בתהליך התכנון והפיתוח, במקום להוסיף אמצעי בקרה אחרי הפיתוח.

כבר בתחילת תהליך התכנון והפיתוח, חשוב לקבל החלטות שמתאימות לסביבת הסיכון הספציפית ולסדרי העדיפויות העסקיים הספציפיים שלכם. לדוגמה, אמצעי אבטחה מגבילים מדי עשויים להגן על הנתונים, אבל גם לפגוע בחדשנות ולהאט את מחזורי הפיתוח. עם זאת, היעדר אבטחה עלול להוביל לפרצות אבטחה, לפגיעה במוניטין ולהפסדים כספיים, שפוגעים ביעדים העסקיים.

כדי להגדיר יעדים ודרישות ברורים, כדאי לפעול לפי ההמלצות הבאות.

התאמת האבטחה של AI ו-ML ליעדים העסקיים

כדי להתאים את מאמצי האבטחה שלכם בתחום ה-AI וה-ML ליעדים העסקיים, מומלץ להשתמש בגישה אסטרטגית שמשלבת אבטחה בכל שלב במחזור החיים של ה-AI. כדי לפעול בשיטה הזו:

  1. הגדרת יעדים עסקיים ברורים ודרישות אבטחה:

    • מזהים יעדים עסקיים מרכזיים: מגדירים יעדים עסקיים ברורים שהיוזמות שלכם בתחום ה-AI וה-ML נועדו להשיג. לדוגמה, המטרות שלכם יכולות להיות שיפור חוויית הלקוח, אופטימיזציה של הפעולות או פיתוח מוצרים חדשים.
    • תרגום יעדים לדרישות אבטחה: כשמבהירים את היעדים העסקיים, מגדירים דרישות אבטחה ספציפיות לתמיכה ביעדים האלה. לדוגמה, יכול להיות שהיעד שלכם הוא להשתמש ב-AI כדי להתאים אישית המלצות ללקוחות. כדי לעמוד ביעד הזה, יכול להיות שדרישות האבטחה שלכם הן להגן על פרטיות נתוני הלקוחות ולמנוע גישה לא מורשית לאלגוריתמים של המלצות.

  2. איזון בין אבטחה לצרכים עסקיים:

    • עורכים הערכות סיכונים: מזהים איומי אבטחה פוטנציאליים ונקודות חולשה במערכות ה-AI.
    • קביעת סדר עדיפויות לאמצעי אבטחה: סדר העדיפויות של אמצעי האבטחה האלה צריך להתבסס על ההשפעה הפוטנציאלית שלהם על היעדים העסקיים.
    • ניתוח העלויות והיתרונות: חשוב לוודא שאתם משקיעים בפתרונות היעילים ביותר. כדאי לשקול את העלויות והיתרונות של אמצעי אבטחה שונים.
    • להקדים בדיקות אבטחה: הטמעת שיטות מומלצות לאבטחה בשלב מוקדם של תהליך התכנון, והתאמת אמצעי הבטיחות בהתאם לשינויים בצרכים העסקיים ולאיומים חדשים.

זיהוי סיכונים ווקטורים פוטנציאליים של התקפות

כדאי לשקול וקטורים פוטנציאליים של מתקפות שיכולים להשפיע על מערכות ה-AI, כמו הרעלת נתונים, היפוך מודל או מתקפות יריבות. צריך לעקוב באופן רציף אחרי השטח הפגיע שמשתנה ככל שמערכת ה-AI מתפתחת, ולבדוק אותו, וגם לעקוב אחרי איומים ונקודות חולשה חדשים. חשוב לזכור ששינויים במערכות ה-AI יכולים גם להוביל לשינויים בשטח הפנים להתקפה שלהן.

כדי לצמצם סיכונים משפטיים וסיכונים שקשורים למוניטין, צריך גם לעמוד בדרישות התאימות שקשורות לפרטיות נתונים, להטיה אלגוריתמית ולתקנות רלוונטיות אחרות.

כדי לצפות מראש איומים ונקודות חולשה פוטנציאליים ולבחור עיצוב שממזער את הסיכונים, מומלץ לאמץ גישה של אבטחה משלב התכנון.

‫Google Cloud מספקת חבילה מקיפה של כלים ושירותים שיעזרו לכם ליישם גישה של אבטחה מובנית:

  • ניהול מצב האבטחה בענן: שימוש ב-Security Command Center כדי לזהות נקודות חולשה פוטנציאליות ובעיות בהגדרות בתשתית ה-AI.
  • ניקוד החשיפה להתקפות ונתיבי התקפה: שיפור ושימוש בניקוד החשיפה להתקפות ובנתיבי התקפה שנוצרים ב-Security Command Center.
  • ‫Google Threat Intelligence: קבלת מידע על איומים חדשים וטכניקות תקיפה חדשות שצצות במטרה לפגוע במערכות AI.
  • רישום ביומן ומעקב: עוקבים אחרי הביצועים והאבטחה של מערכות ה-AI, ומזהים אנומליות או פעילויות חשודות. מבצעים ביקורות אבטחה באופן קבוע כדי לזהות נקודות חולשה פוטנציאליות בתשתית ובמודלים של ה-AI ולטפל בהן.
  • ניהול נקודות חולשה: כדאי להטמיע תהליך לניהול נקודות חולשה כדי לעקוב אחרי נקודות חולשה באבטחה במערכות ה-AI ולתקן אותן.

מידע נוסף זמין במאמרים Secure by Design at Google וImplement security by design.

שמירה על אבטחת הנתונים ומניעת אובדן או טיפול לא תקין

נתונים הם נכס חשוב ורגיש שצריך לשמור עליו מאובטח. אבטחת מידע עוזרת לכם לשמור על אמון המשתמשים, לתמוך ביעדים העסקיים שלכם ולעמוד בדרישות התאימות.

כדי לשמור על אבטחת הנתונים, כדאי לפעול לפי ההמלצות הבאות.

הקפדה על עקרונות הגבלת איסוף המידע

כדי לשמור על פרטיות נתונים, חשוב להקפיד על העיקרון של הגבלה על איסוף המידע. כדי למזער את הנתונים, אל תאספו, תשמרו או תשתמשו בנתונים שלא נחוצים באופן מוחלט ליעדים העסקיים שלכם. במידת האפשר, השתמשו בנתונים סינתטיים או בנתונים אנונימיים לחלוטין.

איסוף נתונים יכול לעזור לכם להפיק תובנות עסקיות ולבצע ניתוחים, אבל חשוב להפעיל שיקול דעת בתהליך איסוף הנתונים. אם אתם אוספים פרטים אישיים מזהים (PII) על הלקוחות שלכם, חושפים מידע רגיש או יוצרים הטיה או מחלוקת, יכול להיות שתבנו מודלים מוטים של ML.

אתם יכולים להשתמש בתכונות של Google Cloud כדי לשפר את הגבלה על איסוף המידע ואת פרטיות נתונים במגוון תרחישי שימוש:

  • כדי להסיר את הפרטים המזהים מהנתונים וגם לשמור על השימושיות שלהם, אפשר להשתמש בשיטות טרנספורמציה כמו פסאודונימיזציה, הסרת פרטים מזהים והכללה כמו חלוקה לקטגוריות. כדי להטמיע את השיטות האלה, אפשר להשתמש ב-Sensitive Data Protection.
  • כדי להעשיר את הנתונים ולצמצם את ההטיות הפוטנציאליות, אפשר להשתמש במשימת תיוג נתונים ב-Vertex AI. תהליך תיוג הנתונים מוסיף תגים אינפורמטיביים ומשמעותיים לנתונים גולמיים, וכך הופך אותם לנתוני אימון מובנים למודלים של למידת מכונה. הוספת תוויות לנתונים מאפשרת להוסיף פרטים ספציפיים לנתונים ולהפחית את העמימות.
  • כדי להגן על משאבים מפני גישה ממושכת או מניפולציה, כדאי להשתמש בתכונות של Cloud Storage כדי לשלוט במחזור החיים של הנתונים.

למידע על שיטות מומלצות להטמעת הצפנת נתונים, ראו הצפנה של נתונים במנוחה ובתנועה במסגרת Well-Architected Framework.

מעקב אחרי איסוף נתונים, אחסון וטרנספורמציה

נתוני האימון של אפליקציית ה-AI שלכם הם הסיכון הגדול ביותר להטיה ולדליפת נתונים. כדי לשמור על תאימות ולנהל נתונים בצוותים שונים, צריך להקים שכבת משילות מידע שתאפשר לעקוב אחרי זרימות נתונים, טרנספורמציות וגישה. שמירה של יומנים לגבי פעולות של גישה לנתונים ומניפולציה שלהם. היומנים עוזרים לכם לבדוק את הגישה לנתונים, לזהות ניסיונות גישה לא מורשים ולמנוע גישה לא רצויה.

אתם יכולים להשתמש בתכונות הבאות כדי ליישם אסטרטגיות של משילות מידע (data governance): Google Cloud

  • כדי ליצור פלטפורמה לניהול נתונים בכל הארגון או במחלקה מסוימת, אפשר להשתמש בקטלוג הידע. פלטפורמה ל<משילות מידע (data governance)> יכולה לעזור לכם לגלות, לנהל, לעקוב ולשלוט בנתונים ובפריטי AI באופן מרכזי בכל פלטפורמות הנתונים שלכם. פלטפורמת ניהול הנתונים מספקת גם גישה למשתמשים מהימנים. אתם יכולים לבצע את המשימות הבאות באמצעות Knowledge Catalog:
    • ניהול של שרשרת מקורות הנתונים. ב-BigQuery אפשר גם לקבל שושלת ברמת העמודה.
    • ניהול של בדיקות איכות נתונים ופרופילי נתונים.
    • ניהול של גילוי נתונים, חיפוש נתונים ועיבוד נתונים במאגרי נתונים שונים.
    • ניהול מטא-נתונים של תכונות וארטיפקטים של מודלים.
    • יצירת מילון המונחים הארגוני כדי לנהל מטא-נתונים וליצור אוצר מילים סטנדרטי.
    • העשרת המטא-נתונים בהקשר באמצעות היבטים וסוגי היבטים.
    • איחוד של משילות מידע (data governance) בטבלאות בפורמט פתוח כמו Iceberg ו-Delta, וגם ב-BigLake.
    • כדאי ליצור רשת נתונים כדי להעביר את הבעלות על הנתונים לבעלי נתונים מצוותים או מדומיינים שונים. השיטה הזו תואמת לעקרונות של אבטחת נתונים, והיא יכולה לעזור לשפר את הנגישות לנתונים ואת היעילות התפעולית.
    • בדיקה ושליחה של תוצאות של מידע אישי רגיש מ-BigQuery אל Knowledge Catalog.
  • כדי לבנות lakehouse מאוחד ופתוח עם ניהול נאות, צריך לשלב את אגמי הנתונים ומחסני הנתונים עם שירותי חנות מטא-נתונים מנוהלת כמו Dataproc Metastore ו-Lakehouse runtime catalog. ב-lakehouse פתוח נעשה שימוש בפורמטים פתוחים של טבלאות שתואמים למנועי עיבוד נתונים שונים.
  • כדי לתזמן את המעקב אחרי תכונות וקבוצות של תכונות, משתמשים ב-Vertex AI Feature Store.
  • כדי לסרוק את מערכי הנתונים של Vertex AI ברמת הארגון, התיקייה או הפרויקט, משתמשים בגילוי נתונים רגישים ב-Vertex AI. אפשר גם לנתח את פרופילי הנתונים שמאוחסנים ב-BigQuery.
  • כדי לתעד יומנים בזמן אמת ולאסוף מדדים שקשורים לצינורות עיבוד נתונים, משתמשים ב-Cloud Logging וב-Cloud Monitoring. כדי לאסוף נתוני ביקורת של קריאות ל-API, משתמשים ב-Cloud Audit Logs. לא מומלץ לרשום פרטים אישיים מזהים (PII) או נתונים סודיים ביומנים של ניסויים או בשרתי יומנים שונים.

הטמעה של בקרת גישה מבוססת-תפקידים לפי העיקרון של הרשאות מינימליות

כדאי להטמיע בקרת גישה מבוססת-תפקידים (RBAC) כדי להקצות רמות גישה שונות על סמך תפקידי המשתמשים. המשתמשים צריכים לקבל רק את ההרשאות המינימליות שנדרשות להם כדי לבצע את הפעולות שקשורות לתפקיד שלהם. מומלץ להקצות הרשאות על סמך העיקרון של הרשאות מינימליות, כך שהמשתמשים יקבלו רק את הגישה שהם צריכים, כמו גישה לקריאה בלבד או גישה לכתיבה.

שימוש ב-RBAC עם הרשאות מינימליות חשוב לאבטחה כשבארגון שלכם משתמשים בנתונים רגישים שנמצאים במאגרי נתונים, במאגרי תכונות או בהיפרפרמטרים לאימון מודלים. השימוש בשיטה הזו עוזר למנוע גניבת נתונים, לשמור על שלמות המודל ולהגביל את השטח שבו עלולות להתרחש תאונות או מתקפות.

כדי לעזור לכם להטמיע את אסטרטגיות הגישה האלה, אתם יכולים להשתמש בתכונות הבאות שלGoogle Cloud :

  • כדי להטמיע רמת גישה מפורטת, אפשר להשתמש באפשרויות הבאות:

    • ממפים את תפקידי ה-IAM של מוצרים שונים למשתמש, לקבוצה או לחשבון שירות כדי לאפשר גישה מפורטת. ממפים את התפקידים האלה לפי הצרכים של הפרויקט, דפוסי הגישה או התגים.
    • הגדרת מדיניות IAM עם תנאים כדי לנהל גישה גרנולרית לנתונים, למודל ולהגדרות המודל, כמו קוד, הגדרות משאבים והיפרפרמטרים.

    • אפשר לבדוק גישה פרטנית ברמת האפליקציה, שעוזרת לאבטח מידע אישי רגיש שאתם בודקים ומשתפים מחוץ לצוות.

  • כדי להגביל את הגישה למשאבים מסוימים, אפשר להשתמש במדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB). אפשר גם להשתמש בPrivileged Access Manager כדי לשלוט בהעלאת רמת הרשאה זמנית 'בדיוק בזמן' עבור גורמים נבחרים. בהמשך תוכלו לראות את יומני הביקורת של הפעילות הזו ב-Privileged Access Manager.

  • כדי להגביל את הגישה למשאבים על סמך כתובת ה-IP ומאפייני המכשיר של משתמש הקצה, אפשר להרחיב את מדיניות הגישה של שרת proxy לאימות זהויות (IAP).

  • כדי ליצור דפוסי גישה לקבוצות משתמשים שונות, אתם יכולים להשתמש בבקרת גישה ב-Vertex AI עם IAM כדי לשלב בין התפקידים המוגדרים מראש או התפקידים המותאמים אישית.

  • כדי להגן על מכונות Vertex AI Workbench באמצעות אמצעי בקרה של בקרת גישה מבוססת-הקשר, צריך להשתמש ב-Access Context Manager וב-Chrome Enterprise Premium. בגישה הזו, הגישה מוערכת בכל פעם שמשתמש מאמת את עצמו במכונה.

הטמעה של אמצעי אבטחה להעברת נתונים

הטמעת אמצעים כמו הצפנה והגבלות על העברת נתונים, וגם אמצעים אחרים כמו הקמת גבולות מאובטחים. האמצעים האלה עוזרים למנוע דליפת נתונים ואובדן נתונים, שעלולים לגרום להפסדים כספיים, לפגיעה במוניטין, לחשיפה לתביעות משפטיות ולשיבוש בפעילות העסקית.

כדי למנוע זליגת נתונים ואובדן נתונים ב- Google Cloud, אפשר להשתמש בשילוב של כלים ושירותים לאבטחה.

כדי להטמיע הצפנה, כדאי:

  • כדי לקבל שליטה רבה יותר על מפתחות ההצפנה, אפשר להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud KMS. כשמשתמשים ב-CMEK, השירותים הבאים שמשולב בהם CMEK מצפינים את הנתונים באחסון בשבילכם:
  • כדי להגן על הנתונים ב-Cloud Storage, מומלץ להשתמש בהצפנה בצד השרת כדי לאחסן את מפתחות ה-CMEK. אם אתם מנהלים את מפתחות ה-CMEK בשרתים שלכם, הצפנה בצד השרת יכולה לעזור להגן על מפתחות ה-CMEK והנתונים שמשויכים אליהם, גם אם מערכת האחסון של מפתחות ה-CMEK נפגעה.
  • כדי להצפין נתונים במעבר, צריך להשתמש ב-HTTPS בכל קריאות ה-API לשירותי AI ו-ML. כדי לאכוף שימוש ב-HTTPS באפליקציות ובממשקי ה-API, צריך להשתמש במאזני עומסים של HTTPS.

למידע נוסף על שיטות מומלצות להצפנת נתונים, ראו הצפנת נתונים באחסון ובתנועה בעמודת האבטחה של Well-Architected Framework.

כדי להטמיע את ההיקפים, כדאי לשקול את הדברים הבאים:

  • כדי ליצור גבולות גזרה לשירות מסביב למשאבי ה-AI וה-ML ולמנוע זליגת נתונים מהענן הווירטואלי הפרטי (VPC), צריך להשתמש ב-VPC Service Controls כדי להגדיר גבולות גזרה לשירות. לכלול את משאבי ה-AI וה-ML ואת המידע האישי הרגיש בהיקף. כדי לשלוט בזרימת הנתונים, צריך להגדיר כללי תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) לגבולות הגזרה.
  • כדי להגביל את תעבורת הנתונים הנכנסת והיוצאת למשאבי ה-AI וה-ML, מגדירים כללים של חומת אש. הטמעת מדיניות שדוחה כברירת מחדל את כל התנועה, ומאפשרת באופן מפורש רק את התנועה שעומדת בקריטריונים שלכם. דוגמה למדיניות אפשר לראות במאמר דוגמה: דחיית כל החיבורים החיצוניים למעט חיבורים ליציאות ספציפיות.

כדי להטמיע הגבלות על העברת נתונים, כדאי לשקול את האפשרויות הבאות:

  • כדי לשתף נתונים ולהרחיב את השימוש בהם מעבר לגבולות הפרטיות בסביבה מאובטחת, אפשר להשתמש בשיתוף ב-BigQuery ובחדרי נתונים ב-BigQuery, שמספקים מסגרת אבטחה ופרטיות חזקה.
  • כדי לשתף נתונים ישירות ליעדים מובנים מלוחות בקרה של בינה עסקית, אפשר להשתמש ב-Looker Action Hub, שמספק סביבת ענן מאובטחת.

הגנה מפני הרעלת נתונים

הרעלת נתונים היא סוג של מתקפת סייבר שבה התוקפים מחדירים נתונים זדוניים למערכי נתונים של אימון כדי לתמרן את התנהגות המודל או לפגוע בביצועים שלו. מתקפת הסייבר הזו יכולה להיות איום רציני על מערכות אימון של ML. כדי להגן על התוקף והאיכות של הנתונים, חשוב לשמור על שיטות עבודה שמגנות על הנתונים. הגישה הזו חיונית לשמירה על עקביות, אמינות ויושרה של המודל.

כדי לעקוב אחרי התנהגות לא עקבית, שינויים או גישה לא צפויה לנתונים, מומלץ להגדיר מעקב והתראות מקיפים לצינורות עיבוד נתונים ולצינורות למידת מכונה.

Google Cloud יכולות לעזור לכם להטמיע אמצעי הגנה נוספים מפני הרעלת נתונים:

  • כדי לוודא תקינות נתונים, כדאי:

    • לפני שמשתמשים בנתונים לאימון, חשוב להטמיע בדיקות חזקות לאימות הנתונים. בודקים את פורמטי הנתונים, הטווחים וההתפלגויות. אתם יכולים להשתמש ביכולות האוטומטיות של איכות הנתונים ב-Knowledge Catalog.
    • כדי ליהנות מיכולות מקיפות של מניעת אובדן נתונים, אפשר להשתמש ב-Sensitive Data Protection עם Model Armor. מידע נוסף זמין במאמר מושגי מפתח ב-Model Armor. בעזרת Sensitive Data Protection עם Model Armor אפשר לגלות, לסווג ולהגן על מידע רגיש כמו קניין רוחני. היכולות האלה יכולות לעזור לכם למנוע חשיפה לא מורשית של מידע רגיש באינטראקציות עם מודלים של שפה גדולה (LLM).
    • כדי לזהות אנומליות בנתוני האימון שעשויות להצביע על הרעלת נתונים, אפשר להשתמש בזיהוי אנומליות ב-BigQuery עם שיטות סטטיסטיות או מודלים של ML.

  • כדי להתכונן לאימון חזק, צריך לבצע את הפעולות הבאות:

    • כדי לצמצם את ההשפעה של נקודות נתונים שהורעלו, כדאי להשתמש בשיטות של שילוב מודלים. מומלץ לאמן כמה מודלים על קבוצות משנה שונות של הנתונים באמצעות כוונון של היפרפרמטרים.
    • שימוש בטכניקות להגדלת נתונים כדי לאזן את ההתפלגות של הנתונים בין מערכי הנתונים. הגישה הזו יכולה לצמצם את ההשפעה של הרעלת נתונים, ומאפשרת לכם להוסיף דוגמאות מתנגדות.

  • כדי לשלב בדיקה אנושית של נתוני אימון או של פלט המודל, צריך לבצע את הפעולות הבאות:

    • ניתוח מדדי הערכת המודל כדי לזהות הטיות פוטנציאליות, אנומליות או התנהגות לא צפויה שעשויות להצביע על הרעלת נתונים. פרטים נוספים זמינים במאמר הערכת מודלים ב-Vertex AI.
    • להשתמש במומחיות בתחום כדי להעריך את המודל או האפליקציה ולזהות דפוסים או נקודות נתונים חשודים שאולי שיטות אוטומטיות לא יזהו. פרטים נוספים זמינים במאמר סקירה כללית על שירות הערכת AI גנרטיבי.

במאמר הטמעת אבטחה כבר בשלב התכנון במסגרת Well-Architected Framework מוסברות שיטות מומלצות ליצירת פלטפורמות נתונים שמתמקדות באבטחת תשתית ואבטחת מידע.

שמירה על צינורות ה-AI מאובטחים ועמידים בפני שינויים לא מורשים

קוד ה-AI ולמידת המכונה שלכם וצינורות הנתונים שמוגדרים בקוד הם נכסים קריטיים. אפשר לשנות קוד לא מאובטח, וזה עלול להוביל לדליפות נתונים, לאי עמידה בדרישות ולשיבוש של פעילויות עסקיות קריטיות. שמירה על האבטחה של קוד ה-AI וה-ML עוזרת להבטיח את השלמות והערך של המודלים ושל התוצאות שלהם.

כדי לאבטח קוד וצינורות של AI, כדאי לפעול לפי ההמלצות הבאות.

שימוש בשיטות מאובטחות לכתיבת קוד

כדי למנוע נקודות חולשה, מומלץ להשתמש בשיטות קידוד מאובטחות כשמפתחים מודלים. מומלץ להטמיע אימות של קלט ופלט ספציפיים ל-AI, לנהל את כל התלות בתוכנה ולהטמיע באופן עקבי עקרונות של קידוד מאובטח בפיתוח. הטמעת אבטחה בכל שלב במחזור החיים של ה-AI, החל מעיבוד מקדים של הנתונים ועד לקוד האפליקציה הסופי.

כדי להטמיע אימות קפדני, כדאי לשקול את האפשרויות הבאות:

  • כדי למנוע מניפולציה של המודל או ניצול לרעה של המערכת, צריך לאמת ולנקות את הקלט והפלט בקוד.

    • אתם יכולים להשתמש ב-Model Armor או במודלים גדולים של שפה (LLM) שעברו כוונון עדין כדי לסנן באופן אוטומטי הנחיות ותשובות ולזהות סיכונים נפוצים.
    • כדי לאמת את הנתונים, אפשר להטמיע סקריפטים של Python ב-Vertex AI Pipelines או ב-BigQuery. הסקריפטים האלה יאמתו את סוגי הנתונים, הפורמטים והטווחים שלהם במהלך הטמעת הנתונים והעיבוד המקדים שלהם.
    • שימוש בסוכני LLM של עוזר תכנות, כמו CodeMender, כדי לשפר את אבטחת הקוד. חשוב להשאיר אדם בתהליך כדי לאמת את השינויים המוצעים.

  • כדי לנהל ולאבטח את נקודות הקצה של ממשקי ה-API של מודלים של AI, אפשר להשתמש ב-Apigee, שכולל תכונות שניתנות להגדרה כמו אימות בקשות, בקרה על התנועה ואימות.

  • כדי לצמצם את הסיכון לאורך מחזור החיים של ה-AI, אתם יכולים להשתמש ב-ניהול סיכונים במערכות AI כדי:

    • איתור מלאי של AI בסביבה שלכם.
    • הערכת מלאי שטחי הפרסום כדי לזהות נקודות חולשה פוטנציאליות.
    • מאבטחים נכסי AI באמצעות אמצעי בקרה, כללי מדיניות ואמצעי הגנה.
    • ניהול מערכות AI עם יכולות זיהוי, חקירה ותגובה.

כדי לאבטח את התלות של הקוד והארטיפקטים בצינור ה-CI/CD, כדאי לשקול את האפשרויות הבאות:

  • כדי לטפל בסיכונים שעלולים להיווצר בפרויקט בגלל תלות בספריות קוד פתוח, אפשר להשתמש ב-Artifact Analysis עם Artifact Registry כדי לזהות נקודות פגיעות מוכרות. שימוש בגרסאות המאושרות של ספריות ותחזוקה שלהן. אחסון חבילות ML בהתאמה אישית ויחסי תלות שנבדקו במאגר פרטי של Artifact Registry.
  • כדי להטמיע סריקת תלות בצינורות עיבוד הנתונים של MLOps ב-Cloud Build, צריך להשתמש באישור בינארי. אוכפים מדיניות שמאפשרת פריסות רק אם תמונות המאגר של הקוד עוברות את בדיקות האבטחה.
  • כדי לקבל מידע על האבטחה בשרשרת אספקת התוכנה, אפשר להשתמש בלוחות בקרה במסוף Google Cloud . בלוחות האלה מפורטים מקורות, גרסאות build, ארטיפקטים, פריסות וזמני ריצה. המידע הזה כולל פגיעויות בארטיפקטים של build, ב-אישור המקור של Build וברשימות תלות של Software Bill of Materials (SBOM).
  • כדי להעריך את רמת הבשלות של אבטחת שרשרת האספקה של התוכנה, אפשר להשתמש במסגרת Supply chain Levels for Software Artifacts‏ (SLSA).

כדי להטמיע באופן עקבי עקרונות של כתיבת קוד מאובטח בכל שלב של הפיתוח, כדאי לשקול את האפשרויות הבאות:

  • כדי למנוע חשיפה של מידע אישי רגיש מאינטראקציות עם מודלים, אפשר להשתמש ברישום ביומן עם Sensitive Data Protection. כשמשתמשים במוצרים האלה יחד, אפשר לשלוט בנתונים שנרשמים ביומן של אפליקציות ה-AI ורכיבי הפייפליין, ולהסתיר מידע אישי רגיש.
  • כדי ליישם את העיקרון של הרשאות מינימליות, צריך לוודא שלחשבונות השירות שבהם אתם משתמשים למשימות, לצינורות ולמודלים שפרסתם ב-Vertex AI יש רק את הרשאות ה-IAM המינימליות הנדרשות. מידע נוסף זמין במאמר בנושא יישום אמצעי בקרה לגישה מבוססת-תפקידים עם עקרונות של הרשאות מינימליות.
  • כדי לאבטח ולהגן על צינורות העיבוד ועל ארטיפקטים של בנייה, חשוב להבין את הגדרות האבטחה (VPC ו-VPC Service Controls) בסביבה שבה הקוד פועל.

הגנה על צינורות ועל ארטיפקטים של מודלים מפני גישה לא מורשית

הארטיפקטים והצינורות של המודל הם קניין רוחני, ונתוני האימון שלהם מכילים גם מידע קנייני. כדי להגן על משקלי המודל, הקבצים והגדרות הפריסה מפני שיבוש ופגיעות, צריך לאחסן את הארטיפקטים האלה ולגשת אליהם באמצעות אבטחה משופרת. מטמיעים רמות גישה שונות לכל ארטיפקט על סמך תפקידי המשתמשים והצרכים שלהם.

כדי לאבטח את הארטיפקטים של המודל, כדאי לשקול את האפשרויות הבאות:

  • כדי להגן על ארטיפקטים של מודלים ועל קבצים רגישים אחרים, מצפינים אותם באמצעות Cloud KMS. ההצפנה הזו עוזרת להגן על נתונים באחסון ובתנועה, גם אם האחסון הבסיסי נפגע.
  • כדי לאבטח את הגישה לקבצים, מאחסנים אותם ב-Cloud Storage ומגדירים אמצעי בקרה לגישה.
  • כדי לעקוב אחרי הגדרות שגויות או לא מספיקות, ואחרי סטיות מהתקנים שהגדרתם, אתם יכולים להשתמש ב-Security Command Center כדי להגדיר תצורות אבטחה.
  • כדי להפעיל בקרת גישה מפורטת והצפנה במנוחה, מאחסנים את הארטיפקטים של המודל במרשם המודלים של Vertex AI. כדי להוסיף שכבת אבטחה, אפשר ליצור חתימה דיגיטלית לחבילות ולמאגרי תגים שנוצרים במהלך תהליכי הבנייה שאושרו.
  • כדי ליהנות מהאבטחה ברמה שמתאימה לארגונים של Google Cloud, צריך להשתמש במודלים שזמינים ב-Model Garden. ‫Model Garden מספק מודלים קנייניים של Google וגם מודלים של צד שלישי משותפים נבחרים.

  • כדי לאכוף ניהול מרכזי של כל מחזורי החיים של המשתמשים והקבוצות, וכדי לאכוף את העיקרון של הרשאות מינימליות, צריך להשתמש ב-IAM.

    • יוצרים חשבונות שירות ייעודיים עם הרשאות מינימליות לצינורות MLOps ומשתמשים בהם. לדוגמה, לחשבון השירות של צינור עיבוד נתונים לאימון יש הרשאות לקרוא נתונים רק מקטגוריה ספציפית של Cloud Storage ולכתוב ארטיפקטים של מודלים ב-Model Registry.
    • משתמשים בתנאים של IAM כדי לאכוף בקרת גישה מותנית על סמך מאפיינים. לדוגמה, תנאי מאפשר לחשבון שירות להפעיל צינור עיבוד נתונים של Vertex AI רק אם הבקשה מגיעה מטריגר לפיתוח גרסת Build מהימן של Cloud Build.

כדי לאבטח את צינורות הפריסה, כדאי לשקול את האפשרויות הבאות:

  • כדי לנהל שלבים של MLOps ב Google Cloud שירותים ובמשאבים, אפשר להשתמש ב-Vertex AI Pipelines, שיכול להשתלב עם שירותים אחרים ולספק בקרת גישה ברמה נמוכה. כשמבצעים מחדש את הצינורות, חשוב לבצע בדיקות של Vertex Explainable AI ושל AI אחראי לפני פריסת ארטיפקטים של המודל. הבדיקות האלה יכולות לעזור לכם לזהות או למנוע את בעיות האבטחה הבאות:

    • שינויים לא מורשים, שיכולים להצביע על שיבוש המודל.
    • פרצת אבטחה XSS‏ (cross-site scripting), שיכולה להצביע על קובצי אימג' של קונטיינר או תלויות שנפרצו.
    • נקודות קצה לא מאובטחות, שיכולות להצביע על תשתית להצגת מודעות שלא הוגדרה כראוי.

  • כדי לאבטח את האינטראקציות עם המודל במהלך ההסקה, משתמשים בנקודות קצה פרטיות שמבוססות על Private Service Connect עם מאגרי תמונות מוכנים מראש או מאגרי תמונות בהתאמה אישית. יוצרים חתימות של מודלים עם סכימת קלט ופלט מוגדרות מראש.

  • כדי ליצור אוטומציה של מעקב אחרי שינויים בקוד, משתמשים ב-Git לניהול קוד המקור ומשלבים ניהול גרסאות עם פייפליין חזק של CI/CD.

מידע נוסף זמין במאמר בנושא אבטחת צינור ה-AI.

אכיפת שושלת ומעקב

כדי לעזור לכם לעמוד בדרישות התאימות לתקנות, כדאי לאכוף את השושלת והמעקב של נכסי ה-AI וה-ML שלכם. ‫Data lineage and tracking (היסטוריית נתונים ומעקב) מספקת רשומות מפורטות של שינויים בנתונים, במודלים ובקוד. מקור המודל מספק שקיפות ואחריותיות לאורך מחזור החיים של ה-AI וה-ML.

כדי לאכוף ביעילות את השושלת והמעקב ב- Google Cloud, כדאי להשתמש בכלים ובשירותים הבאים:

  • כדי לעקוב אחרי השושלת של מודלים, מערכי נתונים וארטיפקטים שמוצפנים אוטומטית במצב מנוחה, משתמשים ב-Vertex ML Metadata. כדאי לרשום ביומן את המטא-נתונים לגבי מקורות נתונים, טרנספורמציות, פרמטרים של מודלים ותוצאות של ניסויים.
  • כדי לעקוב אחרי ההיסטוריה של ארטיפקטים של פייפליין מ-Vertex AI Pipelines, ולחפש משאבים של מודלים ושל קבוצות נתונים, אפשר להשתמש ב-Knowledge Catalog. כדאי לעקוב אחרי ארטיפקטים ספציפיים של פייפליין כשרוצים לבצע ניפוי באגים, פתרון בעיות או ניתוח של הגורם הבסיסי. כדי לעקוב אחרי כל פייפליין MLOps, כולל ההיסטוריה של ארטיפקטים של פייפליין, אפשר להשתמש ב-Vertex ML Metadata. בעזרת Vertex ML Metadata אפשר גם לנתח את המשאבים וההפעלות. מרשם המודלים מחיל ומנהל את הגרסאות של כל מודל שמאוחסן.
  • כדי לעקוב אחרי קריאות ל-API ופעולות אדמיניסטרטיביות, צריך להפעיל יומני ביקורת של Vertex AI. אפשר לנתח את יומני הביקורת באמצעות Observability Analytics כדי להבין מי ניגש לנתונים ולמודלים או שינה אותם, ומתי. אפשר גם להעביר את היומנים ליעדים של צד שלישי.

פריסה במערכות מאובטחות באמצעות כלים וארטיפקטים מאובטחים

חשוב לוודא שהקוד והמודלים שלכם פועלים בסביבה מאובטחת. בסביבה הזו צריכה להיות מערכת חזקה של בקרת גישה, והיא צריכה לספק הבטחות אבטחה לגבי הכלים והארטיפקטים שאתם פורסים.

כדי לפרוס את הקוד במערכות מאובטחות, כדאי לפעול לפי ההמלצות הבאות.

אימון ופריסה של מודלים בסביבה מאובטחת

כדי לשמור על התקינות, הסודיות והזמינות של מערכות ה-AI וה-ML, צריך להטמיע אמצעי בקרת גישה מחמירים שימנעו שיבוש לא מורשה של משאבים. ההגנה הזו עוזרת לכם:

  • לצמצם את הסיכון לשיבוש המודל, שעלול להניב תוצאות לא צפויות או סותרות.
  • להגן על נתוני האימון מפני הפרות פרטיות.
  • לשמור על זמינות השירות.
  • שמירה על עמידה בדרישות רגולטוריות.
  • בניית אמון המשתמשים.

כדי לאמן את מודלי ה-ML בסביבה עם אבטחה משופרת, אפשר להשתמש בשירותים מנוהלים ב- Google Cloud כמו Cloud Run‏, GKE ו-Managed Service for Apache Spark. אפשר גם להשתמש באימון ללא שרתים ב-Vertex AI.

בקטע הזה אנחנו מציעים המלצות שיעזרו לכם לאבטח עוד יותר את סביבת האימון והפריסה.

כדי לאבטח את הסביבה ואת הגבולות, מומלץ:

כדי לאבטח את הפריסה, כדאי לשקול את האפשרויות הבאות:

  • כשפורסים מודלים, כדאי להשתמש במאגר המודלים. אם אתם פורסים מודלים בקונטיינרים, כדאי להשתמש ב-GKE Sandbox וב-Container-Optimized OS כדי לשפר את האבטחה ולבודד עומסי עבודה. הגבלת הגישה למודלים מ-Model Garden בהתאם לתפקידים ולאחריות של המשתמשים.
  • כדי לאבטח את ממשקי ה-API של המודלים, מומלץ להשתמש ב-Apigee או ב-API Gateway. כדי למנוע שימוש לרעה, כדאי להטמיע מפתחות API, אימות, הרשאה והגבלת קצב יצירת הבקשות. כדי לשלוט בגישה לממשקי ה-API של המודלים, אפשר להשתמש במפתחות API ובמנגנוני אימות.
  • כדי לאבטח את הגישה למודלים במהלך חיזוי, משתמשים ב-Vertex AI Inference. כדי למנוע זליגת נתונים, צריך להשתמש בהיקפים של VPC Service Controls כדי להגן על נקודות קצה פרטיות ולשלוט בגישה למודלים הבסיסיים. אתם משתמשים בנקודות קצה פרטיות כדי לאפשר גישה למודלים ברשת VPC. ה-IAM לא מוחל ישירות על נקודת הקצה הפרטית, אבל שירות היעד משתמש ב-IAM כדי לנהל את הגישה למודלים. לחיזוי אונליין, מומלץ להשתמש ב-Private Service Connect.
  • כדי לעקוב אחרי קריאות ל-API שקשורות לפריסת מודלים, צריך להפעיל את יומני הביקורת של Cloud ל-Vertex AI. קריאות רלוונטיות ל-API כוללות פעילויות כמו יצירת נקודת קצה, פריסת מודל ועדכוני הגדרות.
  • כדי להרחיב את התשתית למיקומי קצה, כדאי לשקול פתרונות של Google Distributed Cloud. כדי לקבל פתרון מנותק לחלוטין, אפשר להשתמש ב-Distributed Cloud air-gapped, שלא דורש קישוריות ל- Google Cloud. Google Cloud
  • כדי לעזור בתהליך הפריסה ולעמוד בדרישות הרגולטוריות והאבטחה, מומלץ להשתמש ב-Assured Workloads.

הנחיות SLSA לגבי תוצרי AI

פועלים לפי ההנחיות הרגילות של Supply-chain Levels for Software Artifacts‏ (SLSA) לגבי ארטיפקטים ספציפיים ל-AI, כמו מודלים וחבילות תוכנה.

‫SLSA היא מסגרת אבטחה שנועדה לעזור לכם לשפר את השלמות של ארטיפקטים של תוכנה ולמנוע שינויים לא מורשים. כשפועלים בהתאם להנחיות של SLSA, אפשר לשפר את האבטחה של צינור עיבוד הנתונים של AI ולמידת מכונה, ושל הארטיפקטים שנוצרים בצינור עיבוד הנתונים. היתרונות של עמידה בדרישות של SLSA:

  • הגברת האמון בארטיפקטים של ה-AI וה-ML: SLSA עוזרת לוודא שלא מתבצעת חבלה במודלים ובחבילות התוכנה. המשתמשים יכולים גם לעקוב אחרי מודלים וחבילות תוכנה עד למקור שלהם, מה שמגביר את הביטחון שלהם בשלמות ובאמינות של הארטיפקטים.
  • צמצום הסיכון למתקפות על שרשרת האספקה: SLSA עוזרת לצמצם את הסיכון למתקפות שמנצלות נקודות חולשה בשרשרת אספקת התוכנה, כמו מתקפות שמזריקות קוד זדוני או שפוגעות בתהליכי בנייה.
  • שיפור רמת האבטחה: SLSA עוזרת לשפר את רמת האבטחה הכוללת של מערכות ה-AI וה-ML. הטמעה כזו יכולה לעזור להפחית את הסיכון למתקפות ולהגן על הנכסים החשובים שלכם.

כדי להטמיע את SLSA בארטיפקטים של AI ו-ML ב- Google Cloud, מבצעים את הפעולות הבאות:

  1. הסבר על רמות SLSA: כדאי להכיר את רמות SLSA השונות ואת הדרישות שלהן. ככל שהרמה גבוהה יותר, כך גם רמת השלמות שהם מספקים.
  2. הערכת הרמה הנוכחית: בוחנים את השיטות הנוכחיות בהשוואה למסגרת SLSA כדי לקבוע את הרמה הנוכחית ולזהות תחומים לשיפור.
  3. הגדרת רמת היעד: קובעים את רמת ה-SLSA המתאימה לטירגוט על סמך רמת הסיכון שאתם מוכנים לקחת, דרישות האבטחה והחשיבות של מערכות ה-AI וה-ML שלכם.

  4. הטמעת דרישות SLSA: כדי לעמוד ברמת ה-SLSA הרצויה, צריך להטמיע את אמצעי הבקרה והשיטות הנדרשים, שיכולים לכלול את הפעולות הבאות:

    • בקרת מקור: משתמשים במערכת לניהול גרסאות כמו Git כדי לעקוב אחרי שינויים בקוד ובהגדרות.
    • תהליך ה-build: מומלץ להשתמש בשירות שיעזור לכם לאבטח את גרסאות ה-build, כמו Cloud Build, ולוודא שתהליך ה-build מבוסס על סקריפט או אוטומטי.
    • יצירת שושלת: יצירת מטא-נתונים של שושלת שמתעדים פרטים על אופן בניית הארטיפקטים, כולל תהליך build, קוד המקור והתלות. פרטים נוספים זמינים במאמרים בנושא מעקב אחר מטא-נתונים של Vertex ML ומעקב אחר הרצות וארטיפקטים.
    • חתימה על ארטיפקטים: חותמים על הארטיפקטים כדי לאמת את האותנטיות והשלמות שלהם.
    • ניהול נקודות חולשה: סורקים את הארטיפקטים והתלויות כדי לאתר נקודות חולשה באופן קבוע. אפשר להשתמש בכלים כמו Artifact Analysis.
    • אבטחת פריסה: הטמעת שיטות פריסה שיעזרו לאבטח את המערכות שלכם, כמו השיטות שמתוארות במסמך הזה.

  5. שיפור מתמיד: עוקבים אחרי ההטמעה של SLSA ומשפרים אותה כדי להתמודד עם איומים ונקודות חולשה חדשים, ושואפים להגיע לרמות גבוהות יותר של SLSA.

שימוש בקובצי אימג' מאומתים של קונטיינרים מוכנים מראש

כדי למנוע נקודת כשל יחידה בשלבי ה-MLOps, צריך לבודד את המשימות שדורשות ניהול תלות שונה במאגרי נתונים שונים. לדוגמה, אפשר להשתמש במאגרי תמונות נפרדים למשימות של הנדסת תכונות, אימון או כוונון עדין והסקת מסקנות. הגישה הזו גם מאפשרת למהנדסי ML לשלוט בסביבה שלהם ולהתאים אותה אישית.

כדי לשמור על עקביות ב-MLOps בכל הארגון, מומלץ להשתמש בקונטיינרים מוכנים מראש. כדאי לשמור על מאגר מרכזי של תמונות בסיס מאומתות ומהימנות של פלטפורמות, ולפעול לפי השיטות המומלצות הבאות:

  • להקים בארגון צוות פלטפורמה מרכזי שיוצר ומנהל קונטיינרים בסיסיים סטנדרטיים.
  • להרחיב את קובצי האימג' של קונטיינרים שנוצרו מראש ומוצעים ב-Vertex AI במיוחד ל-AI ול-ML. לנהל את קובצי האימג' של קונטיינרים במאגר מרכזי בארגון.

‫Vertex AI מספקת מגוון של קונטיינרים מוכנים מראש לאימון ולהסקת מסקנות, והיא מאפשרת גם להשתמש בקונטיינרים בהתאמה אישית. במודלים קטנים יותר, אפשר להפחית את זמן האחזור של הסקת מסקנות אם טוענים מודלים בקונטיינרים.

כדי לשפר את האבטחה של ניהול מאגרי התגים, כדאי לפעול לפי ההמלצות הבאות:

  • משתמשים ב-Artifact Registry כדי ליצור, לאחסן ולנהל מאגרים של קובצי אימג' בקונטיינרים בפורמטים שונים. Artifact Registry מטפל בבקרת גישה באמצעות IAM, ויש לו תכונות משולבות של יכולת צפייה והערכת נקודות חולשה. ב-Artifact Registry אפשר להפעיל תכונות אבטחה של קונטיינרים, לסרוק קובצי אימג' של קונטיינרים ולחקור נקודות חולשה.
  • מריצים שלבים של אינטגרציה רציפה ויוצרים קובצי אימג' של קונטיינרים באמצעות Cloud Build. בשלב הזה אפשר לזהות בעיות בתלות. אם רוצים לפרוס רק את קובצי האימג' שנוצרו על ידי Cloud Build, אפשר להשתמש ב-Binary Authorization. כדי למנוע מתקפות על שרשרת האספקה, כדאי לפרוס את קובצי האימג' שנוצרו על ידי Cloud Build ב-Artifact Registry. מומלץ לשלב כלי בדיקה אוטומטיים כמו SonarQube,‏ PyLint או OWASP ZAP.
  • שימוש בפלטפורמת קונטיינרים כמו GKE או Cloud Run, שעברו אופטימיזציה ל-GPU או ל-TPU עבור עומסי עבודה של AI ו-ML. כדאי לשקול את אפשרויות הסריקה של נקודות חולשה לקונטיינרים באשכולות GKE.

כדאי להשתמש ב-Confidential Computing עבור יחידות GPU

כדי להגן על נתונים בשימוש, אפשר להשתמש ב-Confidential Computing. אמצעי אבטחה רגילים מגנים על נתונים באחסון ובמעבר, אבל Confidential Computing מצפין נתונים במהלך העיבוד. כשמשתמשים ב-Confidential Computing עבור GPU, עוזרים להגן על נתוני אימון רגישים ועל פרמטרים של מודלים מפני גישה לא מורשית. אתם יכולים גם למנוע גישה לא מורשית ממשתמשי ענן עם הרשאות מיוחדות או מתוקפים פוטנציאליים שעשויים לקבל גישה לתשתית הבסיסית.

כדי לקבוע אם צריך להשתמש ב-Confidential Computing עבור מעבדי GPU, צריך להביא בחשבון את רמת הרגישות של הנתונים, את הדרישות הרגולטוריות ואת הסיכונים הפוטנציאליים.

אם הגדרתם Confidential Computing, כדאי לשקול את האפשרויות הבאות:

  • לעומסי עבודה כלליים של AI ו-ML, משתמשים במופעים של מכונות וירטואליות חסויות עם מעבדי GPU מסוג NVIDIA T4. המכונות הווירטואליות האלה מציעות הצפנה מבוססת-חומרה של נתונים בשימוש.
  • לעומסי עבודה בקונטיינרים, משתמשים ב-Confidential GKE Nodes. הצמתים האלה מספקים סביבה מאובטחת ומבודדת לפודים.
  • כדי לוודא שעומס העבודה פועל במתחם מאובטח ומקורי, צריך לאמת את דוחות האימות ש-Confidential VM מספקת.
  • כדי לעקוב אחרי הביצועים, ניצול המשאבים ואירועי האבטחה, צריך לעקוב אחרי משאבי Confidential Computing ו-Confidential GKE Nodes באמצעות Monitoring ו-Logging.

אימות והגנה על קלט

צריך להתייחס לכל הקלט במערכות ה-AI כאל קלט לא מהימן, בלי קשר לשאלה אם הקלט מגיע ממשתמשי קצה או ממערכות אוטומטיות אחרות. כדי לשמור על האבטחה של מערכות ה-AI ולוודא שהן פועלות כמצופה, צריך לזהות ולנטרל מוקדם ככל האפשר וקטורים פוטנציאליים של מתקפות.

כדי לאמת את הקלט שלכם ולהגן עליו, כדאי לפעול לפי ההמלצות הבאות.

יישום שיטות שעוזרות לאבטח מערכות AI גנרטיבי

מתייחסים להנחיות כאל רכיב קריטי באפליקציה, שחשוב לאבטחה כמו קוד. מיישמים אסטרטגיית הגנה לעומק שמשלבת תכנון פרואקטיבי, סינון אוטומטי וניהול מחזור חיים מבוקר.

כדי לאבטח את ההנחיות שלכם ל-AI גנרטיבי, אתם צריכים לתכנן אותן מתוך מחשבה על אבטחה, לבדוק אותן לפני השימוש ולנהל אותן לאורך מחזור החיים שלהן.

כדי לשפר את האבטחה של תכנון ההנחיות וההנדסה שלהן, כדאי להשתמש בשיטות הבאות:

  • מבנה הנחיות לשם הבהרה: צריך לעצב ולבדוק את כל ההנחיות באמצעות יכולות ניהול ההנחיות של Vertex AI Studio. ההנחיות צריכות להיות בעלות מבנה ברור וחד-משמעי. צריך להגדיר תפקיד, לכלול דוגמאות של כמה צילומים ולתת הוראות ספציפיות ומוגבלות. השיטות האלה מפחיתות את הסיכון שהמודל יפרש לא נכון את הקלט של המשתמש באופן שיוצר פרצה אבטחתית.

  • בדיקת הקלט כדי לוודא שהוא חזק ומבוסס: מומלץ לבדוק את כל המערכות באופן יזום כדי לוודא שהן לא יקרסו ולא יפיקו פלט לא מאובטח אם יזינו להן קלט לא צפוי, לא תקין או זדוני. שימוש בבדיקות של צוות אדום כדי לדמות מתקפות מהעולם האמיתי. כשלב סטנדרטי ב-Vertex AI Pipelines, כדאי להפוך את בדיקות החוסן לאוטומטיות. אפשר להשתמש בטכניקות הבדיקה הבאות:

    • בדיקות fuzz.
    • בדיקה ישירות מול פרטים אישיים מזהים (PII), קלט רגיש והחדרת SQL.
    • סריקת קלט רב-אופני שיכול להכיל תוכנות זדוניות או להפר את מדיניות ההנחיות.

  • הטמעת הגנה בשכבות: שימוש בכמה אמצעי הגנה, ולא הסתמכות על אמצעי הגנה יחיד. לדוגמה, באפליקציה שמבוססת על יצירה משופרת באחזור (RAG), אפשר להשתמש ב-LLM נפרד כדי לסווג את כוונת המשתמש הנכנסת ולבדוק אם יש דפוסים זדוניים. לאחר מכן, ה-LLM הזה יכול להעביר את הבקשה ל-LLM הראשי והחזק יותר, שמפיק את התשובה הסופית.

  • ניקוי ואימות של קלט: לפני שמשלבים קלט חיצוני או קלט שסופק על ידי משתמש בהנחיה, צריך לסנן ולאמת את כל הקלט בקוד אפליקציה. האימות הזה חשוב כדי למנוע החדרת הנחיות עקיפה.

כדי לסנן באופן אוטומטי הנחיות ותשובות, כדאי להשתמש בשיטות הבאות:

  • שימוש בשירותי אבטחה מקיפים: מומלץ להטמיע שירות אבטחה ייעודי שלא תלוי במודל, כמו Model Armor, כשכבת הגנה מחייבת עבור מודלים גדולים של שפה (LLM). שירות Model Armor בודק הנחיות ותשובות כדי לזהות איומים כמו החדרת הנחיות, ניסיונות לפריצת חומת האבטחה ותוכן מזיק. כדי לוודא שהמודלים לא חושפים נתוני אימון רגישים או קניין רוחני בתשובות שלהם, מומלץ להשתמש בשילוב של Sensitive Data Protection עם Model Armor. לפרטים נוספים, אפשר לעיין במאמר בנושא מסנני Model Armor.
  • מעקב אחר אינטראקציות ותיעוד שלהן: חשוב לשמור יומנים מפורטים של כל ההנחיות והתשובות של נקודות הקצה של המודל. כדאי להשתמש בתיעוד כדי לבדוק את האינטראקציות האלה, לזהות דפוסי שימוש לרעה ולגלות וקטורים של התקפות שעשויים להופיע נגד המודלים שפרסתם.

כדי לאבטח את ניהול מחזור החיים של ההנחיות, מומלץ להשתמש בשיטות הבאות:

  • הטמעת ניהול גרסאות להנחיות: צריך להתייחס לכל ההנחיות שלכם בסביבת הייצור כמו לקוד אפליקציה. כדאי להשתמש במערכת לניהול גרסאות כמו Git כדי ליצור היסטוריה מלאה של השינויים, לאכוף תקנים לשיתוף פעולה ולאפשר חזרה לגרסאות קודמות. השיטה הבסיסית הזו של MLOps יכולה לעזור לכם לשמור על יציבות של מערכות AI ועל האבטחה שלהן.
  • ניהול ריכוזי של הנחיות: כדאי להשתמש במאגר מרכזי לאחסון, לניהול ולפריסה של כל ההנחיות עם הגרסאות שלהן. כך אפשר לשמור על עקביות בין הסביבות, ולבצע עדכונים בזמן הריצה בלי לפרוס מחדש את האפליקציה.
  • עורכים ביקורות קבועות ובדיקות של צוותים אדומים: בודקים באופן רציף את אמצעי ההגנה של המערכת מפני נקודות חולשה ידועות, כמו אלה שמפורטות בOWASP Top 10 for LLM Applications. כמהנדסי AI, אתם צריכים להיות פרואקטיביים ולבצע בדיקות צוות אדום באפליקציה שלכם כדי לגלות נקודות חולשה ולתקן אותן לפני שתוקף יוכל לנצל אותן.

מניעת שאילתות זדוניות למערכות ה-AI

בנוסף לאימות ולהרשאה, שנדונו קודם במסמך הזה, אפשר לנקוט באמצעים נוספים כדי לאבטח את מערכות ה-AI מפני קלט זדוני. צריך להכין את מערכות ה-AI לתרחישים של אחרי האימות, שבהם תוקפים עוקפים את פרוטוקולי האימות וההרשאה, ואז מנסים לתקוף את המערכת באופן פנימי.

כדי ליישם אסטרטגיה מקיפה שתעזור להגן על המערכת מפני מתקפות אחרי אימות, צריך לעמוד בדרישות הבאות:

  • שכבות מאובטחות של רשתות ואפליקציות: הקמת הגנה רב-שכבתית לכל נכסי ה-AI.

    • כדי ליצור מתחם אבטחה היקפית שמונע זליגת נתונים של מודלים מ-Model Registry או של נתונים רגישים מ-BigQuery, משתמשים ב-VPC Service Controls. מומלץ להשתמש תמיד במצב הרצה יבשה כדי לאמת את ההשפעה של היקף לפני שמפעילים אותו.
    • כדי להגן על כלים מבוססי-אינטרנט כמו מחברות, צריך להשתמש ב-IAP.
    • כדי לאבטח את כל נקודות הקצה של ההסקה, אפשר להשתמש ב-Apigee לאבטחה ולניהול ברמת הארגון. אפשר גם להשתמש ב-API Gateway לאימות פשוט.

  • שימו לב לאנומליות במבנה השאילתות: לדוגמה, תוקף שבודק מערכת כדי למצוא נקודות חולשה עשוי לשלוח אלפי שאילתות עוקבות שונות במקצת. כדאי לסמן דפוסי שאילתות חריגים שלא משקפים התנהגות רגילה של משתמשים.

  • מעקב אחרי נפח הבקשות: עלייה פתאומית בנפח השאילתות מצביעה בבירור על מתקפת מניעת שירות (DoS) או על ניסיון לגנוב את המודל באמצעות הנדסה הפוכה. כדי לשלוט בנפח הבקשות ממשתמש או מכתובת IP יחידה, אפשר להגביל את קצב הבקשות ולבצע ויסות.

  • מעקב והגדרת התראות לגבי אנומליות גיאוגרפיות וזמניות: צריך להגדיר ערכי בסיס לדפוסי גישה רגילים. יצירת התראות על פעילות פתאומית ממיקומים גיאוגרפיים חריגים או בשעות לא שגרתיות. לדוגמה, עלייה חדה במספר הכניסות ממדינה חדשה בשעה 3:00 לפנות בוקר.

מעקב, הערכה והכנה למענה לפלט

מערכות AI מספקות ערך כי הן מייצרות פלט שמשפר, מבצע אופטימיזציה או מבצע אוטומציה של תהליכי קבלת החלטות אנושיים. כדי לשמור על השלמות והמהימנות של מערכות ויישומים מבוססי-AI, חשוב לוודא שהפלט מאובטח ושהוא נמצא בתוך הפרמטרים הצפויים. בנוסף, צריך להכין תוכנית למענה על אירועים.

כדי לשמור על התוצאות, כדאי לפעול לפי ההמלצות הבאות.

הערכת ביצועי המודל באמצעות מדדים ואמצעי אבטחה

כדי לוודא שהמודלים של ה-AI עומדים במדדי הביצועים, בדרישות האבטחה ובתקני ההוגנות והתאימות, חשוב לבצע הערכה יסודית של המודלים. מומלץ לבצע הערכות לפני הפריסה, ולאחר מכן להמשיך להעריך את המודלים בסביבת הייצור באופן קבוע. כדי למזער את הסיכונים ולבנות מערכות AI מהימנות, חשוב להטמיע אסטרטגיית הערכה מקיפה שמשלבת מדדי ביצועים עם הערכות אבטחה ספציפיות של ה-AI.

כדי להעריך את החוסן של המודל ואת מצב האבטחה, כדאי לפעול לפי ההמלצות הבאות:

  • מטמיעים חתימה ואימות של מודלים בצינור MLOps.

    • למודלים מבוססי-קונטיינר, משתמשים ב-Binary Authorization כדי לאמת חתימות.
    • כדי לאמת מודלים שנפרסים ישירות לנקודות קצה ב-Vertex AI, צריך להשתמש בבדיקות מותאמות אישית בסקריפטים של הפריסה.
    • לכל דגם, אפשר להשתמש ב-Cloud Build כדי לחתום על הדגם.

  • הערכת העמידות של המודל בפני קלט לא צפוי או קלט שמנסה להטעות את המודל.

    • לכל המודלים, כדאי לבדוק אם יש נתונים פגומים נפוצים ושינויים בנתונים שעלולים להיות זדוניים. כדי לתזמן את הבדיקות האלה, אפשר להשתמש ב-Vertex AI training או ב-Vertex AI Pipelines.
    • במודלים שבהם האבטחה היא קריטית, מומלץ לבצע סימולציות של מתקפות יריבות כדי להבין את נקודות החולשה הפוטנציאליות.
    • לגבי מודלים שפריסתם מתבצעת בקונטיינרים, אפשר להשתמש ב-Artifact Analysis ב-Artifact Registry כדי לסרוק את קובצי הבסיס לאיתור נקודות חולשה.

  • שימוש ב-Vertex AI Model Monitoring כדי לזהות סחף ו-skew במודלים פרוסים. לאחר מכן, משתמשים בתובנות האלה כדי לבצע הערכה מחדש או כדי לאמן מחדש את המודל.

  • שימוש בהערכות מודלים מ-Vertex AI כרכיב של פייפליין באמצעות Vertex AI Pipelines. אפשר להריץ את רכיב הערכת המודל לבד או עם רכיבים אחרים של צינור העיבוד. משווים בין גרסאות המודל לבין המדדים וערכות הנתונים שהגדרתם. רישום התוצאות של ההערכה ב-Vertex ML Metadata לצורך מעקב אחר שושלת היוחסין.

  • להשתמש בשירות ההערכה של AI גנרטיבי או לבנות עליו כדי להעריך את המודלים שבחרתם או כדי להטמיע תהליכי עבודה מותאמים אישית של הערכה אנושית.

כדי להעריך את ההוגנות, ההטיה, ההסבר והדיוק העובדתי, כדאי לפעול לפי ההמלצות הבאות:

  • הגדירו מדדי הוגנות שמתאימים לתרחישי השימוש שלכם, ואז תבצעו הערכה של המודלים כדי לזהות הטיה פוטנציאלית בפלחי נתונים שונים.
  • להבין אילו תכונות מניעות את התחזיות של המודל כדי לוודא שהתכונות והתחזיות שמתקבלות תואמות לידע בתחום ולהנחיות אתיות.
  • אפשר להשתמש ב-Vertex Explainable AI כדי לקבל שיוכי תכונות למודלים.
  • משתמשים בשירות ההערכה של AI גנרטיבי כדי לחשב מדדים. במהלך שלב אימות המקור בבדיקה, מדד ההצמדה של השירות בודק את העובדות מול טקסט המקור שסופק.
  • כדי לאפשר שכבה שנייה של אימות המקור ברמת המשתמש, צריך להפעיל הארקה של הפלט של המודל.
  • כדאי לעיין בעקרונות ה-AI שלנו ולהתאים אותם לאפליקציות ה-AI שלכם.

מעקב אחרי פלט של מודלים של AI ולמידת מכונה בסביבת ייצור

לעקוב באופן רציף אחרי מודלים של AI ולמידת מכונה (ML) והתשתית שתומכת בהם בסביבת הייצור. חשוב לזהות ולאבחן במהירות ירידות באיכות או בביצועים של פלט המודל, נקודות חולשה באבטחה שמתגלות וסטיות מדרישות התאימות. המעקב הזה עוזר לשמור על הבטיחות, האמינות והמהימנות של המערכת.

כדי לעקוב אחרי הפלט של מערכות AI ולזהות אנומליות, איומים וירידה באיכות, כדאי לפעול לפי ההמלצות הבאות:

  • כדאי להשתמש ב'מעקב אחרי מודלים' כדי לעקוב אחרי התפוקות של המודל ולזהות שינויים בלתי צפויים בהתפלגויות החיזוי או עליות חדות בחיזויים של המודל עם רמת מהימנות נמוכה. מומלץ לעקוב באופן פעיל אחרי התפוקות של מודל ה-AI הגנרטיבי כדי לזהות תוכן שנוצר שהוא לא בטוח, מוטה, לא רלוונטי או זדוני. אפשר גם להשתמש ב'הגנה מוגברת על המודל' כדי לסנן את כל התפוקות של המודל.
  • לזהות דפוסי שגיאות ספציפיים, לתעד אינדיקטורים של איכות או לזהות פלט מזיק או לא תואם ברמת האפליקציה. כדי למצוא את הבעיות האלה, אפשר להשתמש במעקב בהתאמה אישית בלוחות בקרה של Monitoring ובמדדים מבוססי-יומנים מ-Logging.

כדי לעקוב אחרי התפוקות לאיתור אותות ספציפיים שקשורים לאבטחה ושינויים לא מורשים, כדאי לפעול בהתאם להמלצות הבאות:

  • זיהוי ניסיונות גישה לא מורשים למודלים של AI, למערכי נתונים ב-Cloud Storage או ב-BigQuery, או לרכיבים של צינור MLOps. חשוב במיוחד לזהות שינויים לא צפויים או לא מורשים בהרשאות IAM למשאבי AI. כדי לעקוב אחרי הפעילויות האלה ולבדוק אם יש בהן דפוסים חשודים, אפשר להשתמש ביומני הביקורת של פעילות אדמין וביומני הביקורת של גישה לנתונים ביומני הביקורת של Cloud. שילוב הממצאים מ-Security Command Center, שיכולים לסמן טעויות בהגדרות האבטחה ואיומים פוטנציאליים שרלוונטיים לנכסי ה-AI.
  • מעקב אחרי פלט של כמויות גדולות של בקשות או בקשות ממקורות חשודים, שעשויות להצביע על ניסיונות לבצע הנדסה הפוכה של מודלים או לזליגת נתונים. אפשר גם להשתמש ב-Sensitive Data Protection כדי לעקוב אחרי זליגה של מידע אישי רגיש פוטנציאלי.
  • שילוב יומנים בפעולות האבטחה. אתם יכולים להשתמש ב-Google Security Operations כדי לזהות איומי סייבר ממערכות ה-AI, לתאם את הפעולות הנדרשות ולתת להם מענה.

כדי לעקוב אחרי התקינות והביצועים של התשתית שמשרתת את מודלי ה-AI שלכם, כדאי לפעול לפי ההמלצות הבאות:

  • זיהוי בעיות תפעוליות שיכולות להשפיע על אספקת השירות או על ביצועי המודל.
  • עוקבים אחרי נקודות הקצה (endpoints) של Vertex AI כדי לבדוק את זמן האחזור, שיעורי השגיאות ודפוסי התנועה.
  • לעקוב אחרי צינורות עיבוד נתונים של MLOps כדי לראות את סטטוס ההפעלה ושגיאות.
  • אפשר להשתמש בכלי 'מעקב' שמספק מדדים מוכנים מראש. אפשר גם ליצור לוחות בקרה בהתאמה אישית כדי לזהות בעיות כמו הפסקות בשירות של נקודות קצה או כשלים בצינור עיבוד הנתונים.

הטמעה של נוהלי התראה ותגובה לתקריות

כשמזהים בעיות פוטנציאליות בביצועים, באבטחה או בתאימות, חשוב מאוד להגיב בצורה יעילה. כדי להבטיח שהצוותים המתאימים יקבלו התראות בזמן, צריך להטמיע מנגנוני התראה חזקים. צריך להגדיר נהלים מקיפים לתגובה לאירועים שמודעים ל-AI, ולהפעיל אותם כדי לנהל את הבעיות האלה, לבלום אותן ולתקן אותן ביעילות.

כדי ליצור מנגנוני התראה חזקים לבעיות ב-AI שזיהיתם, כדאי לפעול לפי ההמלצות הבאות:

  • הגדרת התראות פרקטיות כדי להודיע לצוותים הרלוונטיים, על סמך פעילויות המעקב של הפלטפורמה. לדוגמה, אפשר להגדיר התראות שיופעלו כשכלי המעקב אחרי מודלים מזהה סחף משמעותי, הטיה או אנומליות בתחזיות. לחלופין, אפשר להגדיר התראות שיופעלו כש-הגנה מוגברת על המודל או כללי מעקב מותאמים אישית יסמנו קלט זדוני או פלט לא בטוח.
  • הגדירו ערוצי התראות ברורים, שיכולים לכלול Slack, אימייל או SMS באמצעות שילובים של Pub/Sub. התאמה אישית של ערוצי ההתראות לפי רמת החומרה של ההתראות והצוותים האחראים.

פיתוח תוכנית לתגובה לתקריות שמתחשבת ב-AI והפעלתה. תוכנית תגובה לאירועים מובנית היא חיונית כדי לצמצם את ההשפעות הפוטנציאליות ולהבטיח התאוששות. אפשר להתאים אישית את התוכנית הזו כדי לטפל בסיכונים ספציפיים ל-AI, כמו שיבוש מודלים, תחזיות שגויות בגלל סחף, החדרת הנחיות או פלט לא בטוח ממודלים גנרטיביים. כדי ליצור תוכנית יעילה, צריך לכלול את השלבים העיקריים הבאים:

  • הכנה: זיהוי נכסים ונקודות חולשה שלהם, פיתוח תוכניות פעולה ווידוא שלצוותים יש הרשאות מתאימות. השלב הזה כולל את המשימות הבאות:

    • זיהוי נכסי AI קריטיים, כמו מודלים, מערכי נתונים ומשאבים ספציפיים של Vertex AI, כמו נקודות קצה או מופעים של Vertex AI Feature Store.
    • לזהות את מצבי הכשל הפוטנציאליים או את וקטורי התקיפה של הנכסים.

    • פיתוח תוכניות פעולה ספציפיות ל-AI לאירועים שתואמים למודל האיומים של הארגון. לדוגמה, פלייבוקים יכולים לכלול את הפעולות הבאות:

      • ביצוע חזרה לגרסה קודמת של מודל באמצעות ניהול גרסאות ב-מרשם המודלים.
      • צינור עיבוד נתונים לאימון מחדש במקרה חירום ב-Vertex AI Training.
      • בידוד של מקור נתונים שנפרץ ב-BigQuery או ב-Cloud Storage.

    • תוכלו להשתמש ב-IAM כדי לוודא שלצוותי התגובה יש גישה עם הרשאות מינימליות לכלים שנדרשים במהלך אירוע.

  • זיהוי ותעדוף: שימוש בהתראות שהוגדרו כדי לזהות תקריות פוטנציאליות ולאמת אותן. קובעים קריטריונים וערכי סף ברורים לגבי האופן שבו הארגון חוקר או מכריז על תקרית שקשורה ל-AI. כדי לבצע חקירה מפורטת ולאסוף ראיות, אפשר להשתמש ב-Logging ליומני אפליקציות וליומני שירותים, וביומני הביקורת של Cloud לפעילויות אדמין ולדפוסי גישה לנתונים. צוותי אבטחה יכולים להשתמש ב-Google SecOps כדי לבצע ניתוחים מעמיקים יותר של נתוני טלמטריה באבטחה.

  • הכלה: בידוד של מערכות או רכיבי AI שהושפעו כדי למנוע השפעה נוספת או זליגת נתונים. השלב הזה עשוי לכלול את המשימות הבאות:

    • משביתים נקודת קצה בעייתית ב-Vertex AI.
    • ביטול הרשאות ספציפיות ב-IAM.
    • עדכון של כללים לחומת האש או של כללי מדיניות ב-Cloud Armor.
    • השהיית צינור עיבוד נתונים ב-Vertex AI שמתנהג בצורה לא תקינה.

  • מיגור: זיהוי והסרה של שורש הבעיה שגרמה לתקרית. השלב הזה עשוי לכלול את המשימות הבאות:

    • תיקון הקוד הפגיע בקונטיינר של מודל בהתאמה אישית.
    • הסרת דלתות אחוריות זדוניות שזוהו ממודל.
    • לפני שמפעילים מחדש אימון מאובטח ב-Vertex AI, צריך לנקות את הנתונים המורעלים.
    • מעדכנים את כל ההגדרות הלא מאובטחות.
    • שיפור הלוגיקה של אימות הקלט כדי לחסום טכניקות ספציפיות של הזרקת הנחיות.

  • שחזור ופריסה מחדש מאובטחת: שחזור של מערכות ה-AI המושפעות למצב תפעולי טוב ומאובטח. השלב הזה עשוי לכלול את המשימות הבאות:

    • פריסת גרסת מודל שאומתה בעבר ונחשבת מהימנה מתוך מרשם המודלים.
    • חשוב למצוא את כל תיקוני האבטחה לנקודות חולשה שעשויות להיות בקוד או במערכת שלכם, ולהחיל אותם.
    • מאפסים את הרשאות ה-IAM לעקרון של הרשאות מינימליות.

  • פעילות אחרי האירוע והפקת לקחים: אחרי שמטפלים באירועי ה-AI המשמעותיים, מבצעים בדיקה יסודית של האירוע. הבדיקה הזו כוללת את כל הצוותים הרלוונטיים, כמו צוותי ה-AI וה-ML, ה-MLOps, האבטחה ומדעי הנתונים. להבין את מחזור החיים המלא של האירוע. אפשר להשתמש בתובנות האלה כדי לשפר את התכנון של מערכת ה-AI, לעדכן את אמצעי הבקרה לאבטחה, לשפר את הגדרות המעקב ולשדרג את תוכנית התגובה לאירועי AI ואת מדריכי ההפעלה.

כדי להשיג מאמץ מתואם, כדאי לשלב את התגובה לאירוע שקשור ל-AI עם מסגרות ארגוניות רחבות יותר, כמו ניהול תקריות שקשורות ל-IT ואירועי אבטחה. כדי להתאים את תגובת האירוע הספציפית ל-AI למסגרות הארגוניות שלכם, כדאי לשקול את הדברים הבאים:

  • העברת טיפול לרמה גבוהה יותר: הגדרת נתיבים ברורים להעברת טיפול באירועי AI משמעותיים ל-SOC מרכזי, ל-IT, למחלקת המשפטים או ליחידות עסקיות רלוונטיות.
  • תקשורת: חשוב להשתמש בערוצים ארגוניים קיימים לכל הדוחות והעדכונים על אירועים פנימיים וחיצוניים.
  • כלים ותהליכים: כדי להבטיח מעקב ועקביות, מומלץ להשתמש במערכות קיימות לניהול אירועים וכרטיסים של ארגונים לצורך ניהול אירועים שקשורים ל-AI.
  • שיתוף פעולה: הגדרה מראש של פרוטוקולים לשיתוף פעולה בין צוותי AI ו-ML,‏ MLOps, מדעי הנתונים, אבטחה, משפטים ותאימות, כדי להגיב ביעילות לאירועי AI.

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים:

הקודם
מצוינות תפעולית
הבא
אמינות