נקודת מבט על 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.
  • כדי להעשיר את הנתונים ולצמצם את ההטיות הפוטנציאליות, אפשר להשתמש במשימת תיוג נתונים ב-Agent Platform. תהליך תיוג הנתונים מוסיף תגים אינפורמטיביים ומשמעותיים לנתונים גולמיים, וכך הופך אותם לנתוני אימון מובנים למודלים של למידת מכונה. הוספת תוויות לנתונים מאפשרת להוסיף פרטים ספציפיים לנתונים ולהפחית את העמימות.
  • כדי להגן על משאבים מפני גישה ממושכת או מניפולציה, כדאי להשתמש בתכונות של 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 מאוחד ופתוח עם ניהול נאות, כדאי לשלב את אגמי הנתונים ומחסני הנתונים עם שירותי metastore מנוהלים כמו Dataproc Metastore ו-Lakehouse runtime catalog. ב-lakehouse פתוח נעשה שימוש בפורמטים פתוחים של טבלאות שתואמים למנועי עיבוד נתונים שונים.
  • כדי לתזמן את המעקב אחרי תכונות וקבוצות של תכונות, משתמשים ב-Agent Platform Feature Store.
  • כדי לסרוק את מערכי הנתונים של פלטפורמת הסוכנים ברמת הארגון, התיקייה או הפרויקט, משתמשים בגילוי נתונים רגישים בפלטפורמת הסוכנים. אפשר גם לנתח את פרופילי הנתונים שמאוחסנים ב-BigQuery.
  • כדי לתעד יומנים בזמן אמת ולאסוף מדדים שקשורים לצינורות נתונים, אפשר להשתמש ב-Cloud Logging וב-Cloud Monitoring. כדי לאסוף נתוני ביקורת של קריאות ל-API, משתמשים ביומני הביקורת של Cloud. אל תתעדו פרטים אישיים מזהים (PII) או נתונים סודיים בניסויים או בשרתי יומנים שונים.

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

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

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

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

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

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

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

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

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

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

  • כדי להגן על מופעים של Gemini Enterprise Agent Platform 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 עם הגנה מוגברת על המודל כדי ליהנות מיכולות מקיפות של מניעת אובדן נתונים. מידע נוסף זמין במאמר בנושא מושגי מפתח בהגנה מוגברת על המודל. ‫Sensitive Data Protection עם Model Armor מאפשר לכם לגלות, לסווג ולהגן על מידע רגיש כמו קניין רוחני. היכולות האלה יכולות לעזור לכם למנוע חשיפה לא מורשית של מידע אישי רגיש באינטראקציות עם מודלים מסוג LLM.
    • כדי לזהות אנומליות בנתוני האימון שעשויות להצביע על הרעלת נתונים, אפשר להשתמש בזיהוי אנומליות ב-BigQuery עם שיטות סטטיסטיות או מודלים של ML.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • איתור מלאי של 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 ורכיבי הפייפליין, ולהסתיר מידע אישי רגיש.
  • כדי להטמיע את העיקרון של הרשאות מינימליות, צריך לוודא שלחשבונות השירות שבהם אתם משתמשים למשימות מותאמות אישית, לצינורות ולמודלים שפרסתם ב-Agent Platform יש רק את הרשאות ה-IAM המינימליות הנדרשות. מידע נוסף זמין במאמר הטמעה של בקרת גישה מבוססת-תפקידים לפי עקרונות של הרשאות מינימליות.
  • כדי לאבטח ולהגן על צינורות העיבוד ועל ארטיפקטים של בנייה, חשוב להבין את הגדרות האבטחה (VPC ו-VPC Service Controls) בסביבה שבה הקוד פועל.

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

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

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

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

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

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

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

  • כדי לנהל שלבים של MLOps בשירותים ובמשאבים של Google Cloud , אפשר להשתמש ב-Agent Platform 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. רישום מטא-נתונים לגבי מקורות נתונים, טרנספורמציות, פרמטרים של מודלים ותוצאות של ניסויים.
  • כדי לעקוב אחרי השיוך של ארטיפקטים של צינורות עיבוד נתונים מ-Agent Platform Pipelines, ולחפש משאבים של מודלים ושל מערכי נתונים, אפשר להשתמש ב-Knowledge Catalog. מעקב אחרי ארטיפקטים ספציפיים בצינור עיבוד נתונים כשרוצים לבצע ניפוי באגים, פתרון בעיות או ניתוח שורש הבעיה. כדי לעקוב אחרי כל פייפליין ה-MLOps, כולל שושלת הנתונים של ארטיפקטים של פייפליין, משתמשים ב-Vertex ML Metadata. בעזרת Vertex ML Metadata אפשר גם לנתח את המשאבים וההפעלות. במרשם המודלים, המערכת מחילה ומנהלת את הגרסאות של כל מודל שאתם מאחסנים.
  • כדי לעקוב אחרי קריאות ל-API ופעולות אדמיניסטרטיביות, צריך להפעיל יומני ביקורת של Agent Platform. ניתוח יומני ביקורת באמצעות Observability Analytics מאפשר להבין מי ניגש לנתונים ולמודלים או שינה אותם, ומתי. אפשר גם להעביר יומני ניתוב ליעדים של צד שלישי.

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

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

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

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

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

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

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

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

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

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

  • כשפורסים מודלים, כדאי להשתמש במאגר המודלים. אם אתם פורסים מודלים בקונטיינרים, כדאי להשתמש ב-GKE Sandbox וב-Container-Optimized OS כדי לשפר את האבטחה ולבודד עומסי עבודה. הגבלת הגישה למודלים מ-Model Garden בהתאם לתפקידים ולאחריות של המשתמשים.
  • כדי לאבטח את ממשקי ה-API של המודלים, אפשר להשתמש ב-Apigee או ב-API Gateway. כדי למנוע ניצול לרעה, כדאי להטמיע מפתחות API, אימות, הרשאה והגבלת קצב יצירת הבקשות. כדי לשלוט בגישה לממשקי API של מודלים, משתמשים במפתחות API ובמנגנוני אימות.
  • כדי לאבטח את הגישה למודלים במהלך חיזוי, אפשר להשתמש בהיסק ב-Gemini Enterprise Agent Platform. כדי למנוע זליגת נתונים, צריך להשתמש בהיקפים של VPC Service Controls כדי להגן על נקודות קצה פרטיות ולשלוט בגישה למודלים הבסיסיים. אתם משתמשים בנקודות קצה פרטיות כדי לאפשר גישה למודלים ברשת VPC. ה-IAM לא מוחל ישירות על נקודת הקצה הפרטית, אבל שירות היעד משתמש ב-IAM כדי לנהל את הגישה למודלים. לחיזוי אונליין, מומלץ להשתמש ב-Private Service Connect.
  • כדי לעקוב אחרי קריאות ל-API שקשורות לפריסת מודלים, צריך להפעיל את יומני הביקורת של Cloud עבור Agent Platform. קריאות רלוונטיות ל-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 Metadata ומעקב אחרי הפעלות וארטיפקטים.
    • חתימה על ארטיפקטים: חותמים על הארטיפקטים כדי לאמת את האותנטיות והשלמות שלהם.
    • ניהול נקודות חולשה: סורקים את הארטיפקטים ואת התלות שלהם כדי לאתר נקודות חולשה באופן קבוע. להשתמש בכלים כמו Artifact Analysis.
    • אבטחת פריסה: חשוב להטמיע שיטות פריסה שיעזרו לכם לאבטח את המערכות, כמו השיטות שמתוארות במסמך הזה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • בכל המודלים שלכם, כדאי לבדוק אם יש נתונים פגומים או שינויים זדוניים בנתונים. כדי לתזמן את הבדיקות האלה, אפשר להשתמש ב-Gemini Enterprise Agent Platform Managed Training או ב-Agent Platform Pipelines.
    • במודלים שבהם האבטחה היא קריטית, מומלץ לבצע סימולציות של מתקפות יריבות כדי להבין את נקודות החולשה הפוטנציאליות.
    • למודלים שפריסתם מתבצעת בקונטיינרים, אפשר להשתמש ב-Artifact Analysis ב-Artifact Registry כדי לסרוק את קובצי הבסיס לאיתור נקודות חולשה.

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

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

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

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

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

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

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

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

  • אתם יכולים להשתמש ב-Model Monitoring ב-Agent Platform כדי לעקוב אחרי התפשטות לא צפויה של תחזיות או אחרי עליות חדות בתחזיות של מודלים עם רמת מהימנות נמוכה. חשוב לעקוב באופן פעיל אחרי התוצאות של מודל ה-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 שלכם, כדאי לפעול לפי ההמלצות הבאות:

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

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

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

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

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

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

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

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

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

      • ביצוע חזרה לגרסה קודמת של מודל באמצעות ניהול גרסאות ב-מרשם המודלים.
      • צינור להכשרה מחדש במקרה חירום ב-Gemini Enterprise Agent Platform Managed Training.
      • בידוד של מקור נתונים שנפרץ ב-BigQuery או ב-Cloud Storage.

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

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

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

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

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

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

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

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

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

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

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

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

מחברים:

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

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