הערכת ספק וסיכוני צד שלישי

רווחים:

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

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

למה סיכון צד שלישי?

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

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

צירי הערכה

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

• אישורי תאימות: SOC 2 Type II (ביקורת עצמאית של בקרות האבטחה של ארגון), ISO/IEC 27001 (תקן ניהול אבטחת מידע) ויותר ויותר ISO/IEC 42001 (תקן מערכת ניהול בינה מלאכותית).
• שמירת נתונים: כמה זמן נשמרת ההנחיה/התשובה? האם מוצע ZDR (שימור נתונים אפס)?
• שימוש באימון: האם הנתונים שלך משמשים לאימון המודל? (בדרך כלל "לא" ברמות הארגוניות.)
• מגורי נתונים: באיזו מדינה/אזור הנתונים מעובדים ומאוחסנים?
• מעבדי משנה: באילו חברות אחרות משתמש הספק (ענן, ניטור)? הם גם חלק מהגבול שלך.
• תכונות אבטחה: הצפנה (במעבר/במצב מנוחה), בקרת גישה, יומן ביקורת, זמן התראה על אירועים.
• חוזה ויציאה: האם יש DPA? האם מובטח שהנתונים שלך יימחקו אם השירות יסתיים? מה הסיכון של נעילה?

צעד אחר צעד: סקירת ספקים

1. שלח סקר אבטחה. הפוך את הצירים למעלה לרשימת שאלות.
2. בקשו ראיות. אמת תביעות עם תיעוד (דוח SOC 2, אישור ISO, טיוטת DPA).
3. מפה את זרימת הנתונים. אילו נתונים הולכים לאן ולאיזה תהליך?
4. לנהל משא ומתן על ה-DPA. אין להתחיל בייצור מבלי לחתום על הסכם עיבוד נתונים (הטקסט המשפטי המפרט כיצד הספק יעבד את הנתונים).
5. סקור מעבדי משנה. קחו בחשבון את כל השרשרת.
6. הגדר לוח זמנים להערכה מחדש. יש לבחון מחדש את סיכון הספק לפחות פעם בשנה.

ארבע תבניות הניתנות להעתקה

ליבת סקר אבטחת הספק:

דברים שכדאי לשאול את הספק: 1. אילו אישורי ציות יש לך? (SOC 2 Type II, ISO 27001/42001) האם אתה יכול לשתף את הדוח?2. כמה נתוני בקשה/תשובה נשמרים? האם יש אפשרות ZDR?3. האם נעשה שימוש בנתונים שלנו באימון מודלים? האם זה כתוב בחוזה?4. באיזה אזור הנתונים מעובדים/מאוחסנים? האם נוכל לבחור אזור?5. מי הם מעבדי המשנה שלך? איך מודיעים כשזה משתנה?6. מהי תקופת ההודעה שלך במקרה של הפרה?7. כיצד ומתי הנתונים שלנו נמחקים עם סיום החוזה?

כלל בדיקת אימות ראיות:

עבור כל טענה, "האם יש ראיות?" בדוק:- תביעת הסמכה -> האם ראיתי את הדוח/מספר האישור הנוכחי?- ZDR/תביעה לאחסון -> האם זה כתוב בסעיף החוזה?- אי שימוש בהדרכה -> האם יש סעיף פתוח ב-DPA? סמן כל טענה ללא ראיות כ"לא מאומת"; אל תקבל מילים מילוליות.

הנחיה למיפוי זרימת נתונים:

חלץ את זרימת הנתונים לאינטגרציה הבאה: {{ תרחיש }}ציין בכל שלב: אילו נתונים (האם הוא מכיל PII), לאן הוא הולך (איזו חברה/אזור), לאיזו מטרה, כמה מאוחסן. סמן כל שלב ומעבדי משנה שחוצים את גבול הארגון.

כרטיס ניקוד סיכון ספק:

ציון כל ציר עם ציון של 0-2 (0=אין, 1=חלקי, 2=מלא):תעודה, ZDR/שמירה, אין להשתמש בהדרכה, תושבות נתונים, שקיפות מעבד משנה, הודעת הפרה, יציאה/מחיקה. אם סך < 10 או כל ציר הוא 0: "סיכון גבוה, הוכנס לייצור".

הנחיה חלשה / הנחיה חזקה

גישה גרועה

גישה חזקה

בהנחה ש"חברה גדולה, בטוחה"

אמת אישור ו-DPA עם מסמך

בהסתמך על הבטחות מילוליות

קישור כל הבטחה לסעיף החוזה

פשוט בדוק את הספק

שקול גם את שרשרת המשנה

לבחור פעם אחת ולשכוח

לוח שנה להערכה מחדש

שלושה מיני מארזים

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

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

מקרה 3 - כרטיס ניקוד ביטל את ההצעה הזולה. שלוש הצעות נבדקו. הספק הזול ביותר קיבל 0 (ללא SOC 2) על ציר ההסמכה. כלל כרטיס הניקוד "אם ציר כלשהו הוא 0, הכנס אותו לייצור" בוטל; נבחר ספק יקר יותר ב-22% אך עם דירוג מלא וההחלטה תועדה לביקורת.

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

טעויות נפוצות

• בהתחשב בגודל/מותג של הספק כהבטחת אבטחה.
• הסתמכות על מפה לאוזן מבלי לאמת טענות עם תיעוד.
• נכנסים לייצור מבלי לחתום על DPA.
• התעלמות משרשרת מעבד המשנה (מגורי הנתונים מנוקבים שם).
• חושב ש-ZDR והערבות "לא בשימוש בחינוך" זהים.
• אישור הספק פעם אחת ולא הערכה מחדש מדי שנה.

לסיכום

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

משימת יישום

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

רשימת בדיקה

• [ ] תיעדתי את אישורי התאימות של הספק (SOC 2 / ISO 27001).
• [ ] סעיפי אחסון נתונים, ZDR ו"אי שימוש בחינוך" כתובים בחוזה.
• [ ] זה עומד בדרישת מגורי הנתונים שלי (KVKK/GDPR).
• [ ] מיפיתי והערכתי את שרשרת המשנה.
• [ ] לא נכנסתי להפקה ללא DPA חתום.
• [ ] הקמתי עבור הספק לוח שנה להערכה מחדש.