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

Last reviewed 2025-11-26 UTC

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

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

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

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

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

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

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

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

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

התאמת האבטחה של 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 שלכם הם הסיכון הגדול ביותר להטיה ולדליפת נתונים. כדי לשמור על תאימות ולנהל נתונים בצוותים שונים, צריך להגדיר שכבת משילות מידע כדי לעקוב אחרי זרימות נתונים, טרנספורמציות וגישה. שמירה של יומנים לגבי פעילויות של גישה לנתונים ומניפולציה שלהם. היומנים עוזרים לכם לבדוק את הגישה לנתונים, לזהות ניסיונות גישה לא מורשים ולמנוע גישה לא רצויה.

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

  • כדי להקים פלטפורמה לניהול נתונים ברמת הארגון או המחלקה, אפשר להשתמש ב-Dataplex Universal Catalog. פלטפורמת משילות מידע יכולה לעזור לכם לגלות, לנהל, לעקוב ולשלוט בנתונים ובארטיפקטים של AI באופן מרכזי בכל פלטפורמות הנתונים שלכם. פלטפורמת ניהול הנתונים מספקת גם גישה למשתמשים מהימנים. אפשר לבצע את המשימות הבאות באמצעות Dataplex Universal Catalog:
    • ניהול של שרשרת מקורות הנתונים. ב-BigQuery אפשר גם לראות את ההיסטוריה של עמודות.
    • ניהול של בדיקות איכות נתונים ופרופילי נתונים.
    • ניהול של גילוי נתונים, חיפוש נתונים ועיבוד נתונים במאגרי נתונים שונים.
    • ניהול מטא-נתונים של תכונות וארטיפקטים של מודלים.
    • יוצרים מילון המונחים הארגוני כדי לנהל את המטא-נתונים ולקבוע אוצר מילים סטנדרטי.
    • העשרת המטא-נתונים בהקשר באמצעות היבטים וסוגי היבטים.
    • איחוד של משילות מידע (data governance) בטבלאות BigLake ובטבלאות בפורמט פתוח כמו Iceberg ו-Delta.
    • ליצור רשת נתונים כדי לבזר את הבעלות על הנתונים בין בעלי נתונים מצוותים או מדומיינים שונים. השיטה הזו תואמת לעקרונות של אבטחת מידע, ויכולה לעזור לשפר את הנגישות לנתונים ואת היעילות התפעולית.
    • בדיקה ושליחה של תוצאות של מידע אישי רגיש מ-BigQuery אל Dataplex Universal Catalog.
  • כדי לבנות lakehouse מאוחד ופתוח עם ניהול נאות, כדאי לשלב בין אגמי הנתונים ומחסני הנתונים לבין שירותי metastore מנוהלים כמו Dataproc Metastore ו-BigLake metastore. ב-lakehouse פתוח נעשה שימוש בפורמטים פתוחים של טבלאות שתואמים למנועי עיבוד נתונים שונים.
  • כדי לתזמן את המעקב אחרי תכונות וקבוצות של תכונות, משתמשים ב-Vertex AI Feature Store.
  • כדי לסרוק את מערכי הנתונים של Vertex AI ברמת הארגון, התיקייה או הפרויקט, משתמשים במיון מידע אישי רגיש ב-Vertex AI. אפשר גם לנתח את פרופילי הנתונים שמאוחסנים ב-BigQuery.
  • כדי לתעד יומנים בזמן אמת ולאסוף מדדים שקשורים לצינורות נתונים, אפשר להשתמש ב-Cloud Logging וב-Cloud Monitoring. כדי לאסוף נתוני ביקורת של קריאות ל-API, משתמשים ביומני ביקורת של Cloud. אל תרשמו פרטים אישיים מזהים (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 sharing ובחדרי נתונים ב-BigQuery, שמספקים מסגרת אבטחה ופרטיות חזקה.
  • כדי לשתף נתונים ישירות ליעדים מובנים מלוחות בקרה של בינה עסקית, אפשר להשתמש ב-Looker Action Hub, שמספק סביבת ענן מאובטחת.

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

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

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

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

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

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

  • כדי להתכונן לאימון חזק:

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

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

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

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

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

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

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

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

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

כדי ליישם אימות קפדני, כדאי:

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

    • אתם יכולים להשתמש בהגנה מוגברת על המודל או במודלים גדולים של שפה (LLM) שעברו כוונון עדין כדי לסנן באופן אוטומטי הנחיות ותשובות ולזהות סיכונים נפוצים.
    • מטמיעים אימות נתונים בסקריפטים של הטמעת נתונים ועיבוד מקדים של נתונים, כדי לוודא שסוגי הנתונים, הפורמטים והטווחים תקינים. ב-Vertex AI Pipelines או ב-BigQuery, אפשר להשתמש ב-Python כדי להטמיע את אימות הנתונים הזה.
    • שימוש בסוכני 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 וברשימות תלות של Software Bill of Materials (SBOM).
  • כדי להעריך את רמת הבשלות של אבטחת שרשרת האספקה של התוכנה, אפשר להשתמש במסגרת Supply chain Levels for Software Artifacts‏ (SLSA).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לאמן את מודלי ה-ML בסביבה עם אבטחה משופרת, אפשר להשתמש בשירותים מנוהלים ב-Google Cloud, כמו Cloud Run, ‏ GKE ו-Dataproc. Google Cloud אפשר גם להשתמש באימון ללא שרתים ב-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. Google Cloud כדי להשתמש בפתרון מנותק לחלוטין, אפשר להשתמש ב-Distributed Cloud air-gapped, שלא דורש קישוריות ל- Google Cloud.
  • כדי לעזור בתהליך הפריסה ולעמוד בדרישות הרגולטוריות והאבטחתיות, מומלץ להשתמש ב-Assured Workloads.

הנחיות SLSA לגבי ארטיפקטים של AI

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

‫SLSA הוא מסגרת אבטחה שנועדה לעזור לכם לשפר את השלמות של ארטיפקטים של תוכנה ולמנוע שיבוש שלהם. כשפועלים לפי ההנחיות של SLSA, אפשר לשפר את האבטחה של צינור עיבוד הנתונים של ה-AI וה-ML, ושל הארטיפקטים שנוצרים בצינור עיבוד הנתונים. הקפדה על 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, כדאי להפוך את בדיקות החוסן לאוטומטיות. אפשר להשתמש בטכניקות הבדיקה הבאות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כשמזהים בעיות פוטנציאליות בביצועים, באבטחה או בתאימות, חשוב מאוד להגיב בצורה יעילה. כדי להבטיח שההתראות יגיעו בזמן לצוותים המתאימים, צריך להטמיע מנגנוני התראה חזקים. להגדיר ולהפעיל נהלי תגובה מקיפים לאירועים שמתבססים על 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 ולמידת המכונה, ה-MLOps, האבטחה ומדעי הנתונים. להבין את מחזור החיים המלא של האירוע. אפשר להשתמש בתובנות האלה כדי לשפר את העיצוב של מערכת ה-AI, לעדכן את אמצעי הבקרה לאבטחה, לשפר את הגדרות המעקב ולשפר את תוכנית התגובה לאירועי AI ואת מדריכי ההפעלה.

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

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

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

מחברים:

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

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