בדיקת נאותות לספק AI (AI Vendor Due Diligence)

למה בדיקת-נאותות-רגילה לא מספיקה ל-AI

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

נתוני-האימון ומקור-המודל

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

הטיה והזיות

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

אבטחה וגישה

מסגרת-בדיקה אחת מציעה 30 שאלות בחמש קטגוריות, שנשלחות לספק בכתב: הבנת-המודל (האם הארכיטקטורה קניינית או מבוססת-מודל-פתוח, מה שמשפיע ישירות על יכולת-הביקורת-וההחלפה בעתיד), אבטחה (תעודת SOC 2 Type II, חשיפה להזרקת-פרומפטים ולהתקפות-חילוץ-נתונים ייחודיות ל-AI), ובקרות-גישה-ל-API (ניהול-מפתחות, הרשאות-לפי-תפקיד, הגבלת-כתובות-IP, הגבלת-קצב ותיעוד-ביקורת). קבלת תשובות בכתב, ולא רק בשיחה, הופכת אותן לבסיס-להשוואה בין ספקים מתחרים.

מה קורה אחרי החתימה

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

למה זה שייך לתבנית-RFP ולא להצהרת-ספק

ההמלצה המקצועית היא לשלב את שאלות-הבדיקה בתוך תבנית-בקשת-הצעות (Request for Proposal, RFP) הרשמית, ולא להסתפק בהצהרה עצמאית שהספק מספק מרצונו — כי כך הבדיקה הופכת לחלק-רשמי-מהחוזה עם השלכות משפטיות, ולא רק לשאלון-לא-מחייב שאפשר להתעלם ממנו בדיעבד אם משהו משתבש.