אבטחת מידע ב-AI ל-ERP: 7 שאלות שכל ארגון צריך לשאול

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

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

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

איפה הבעיה מתחילה

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

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

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

לאן זרמת השיחה

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

האזור הגיאוגרפי משנה. אם הספק במזרח ארה”ב, הנתונים יוצאים מישראל. בעלי עסק שלא מתעניינים בזה כשמדובר בפנייה ראשונה של לקוח, יתעניינו בזה מאוד כשעורך הדין מבקש לראות את הסכם עיבוד הנתונים. שווה לשאול גם על אפשרויות לאזור אירופה. למשל, ספק שמשתמש ב-Anthropic דרך AWS Bedrock ב-Frankfurt משאיר את הנתונים באירופה, מה שמכוסה תחת ה-GDPR וה-AWS Customer Agreement שכנראה כבר חתום אצלכם.

עוד שאלה: האם הנתונים שלכם משמשים לאימון המודל. ה-API המסחרי של Anthropic, OpenAI ו-Google לא משתמש בנתונים לאימון בברירת מחדל. זה כתוב מפורש בתנאי השימוש. השירותים הציבוריים, כמו ChatGPT.com ו-Claude.ai, כן משמשים לאימון אלא אם משלמים לתוכניות עסקיות. אז אם הספק שלכם משתמש בממשק הציבורי מאחורי הקלעים במקום ב-API, הנתונים שלכם בקלות הופכים לחלק ממסד הידע של הספק. שווה לוודא ולקבל בכתב.

ואחרון, retention. גם אם המידע לא משמש לאימון, השיחות נשמרות זמנית לזיהוי שימוש לרעה. ברירת המחדל בתעשייה היא בערך 30 ימים. ספקים גדולים מציעים מסלול שנקרא Zero Data Retention שבו השיחות לא נשמרות בכלל ונמחקות מיד. זה תוסף תשלום לארגון, אבל הוא קיים. לחברות בענפים מוסדרים פיננסים, בריאות, ממשלה זה כמעט חובה. לעסק רגיל בישראל, nice-to-have.

מה ה-AI יכול לראות אצלכם

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

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

נושא נפרד הוא SQL. אם ה-AI יכול להריץ SQL חופשי, צריך לוודא שיש מנגנון שחוסם גישה לטבלאות רגישות. זה רלוונטי במיוחד ל-SAP B1, שיש לו תכונה אדריכלית מוכרת: ה-SQLQueries endpoint לא בודק form-level permissions על הטבלאות שמתחת. עובד שאין לו גישה לטופס “חשבוניות” יכול עדיין להריץ SELECT * FROM OINV אם יש לו את ההרשאה הכללית להריץ שאילתות. כל ספק AI הוגן צריך להכיר את הסיפור הזה ולחסום SQL לעובדים רגילים בברירת מחדל. אצלנו ב-AigentOne זה תוקן ב-3 שכבות (end user, אנליסט, אדמין) שכל אחת מקבלת רמה אחרת של גישה. הצורה האמיתית של זה צריכה להיות שיחה עם הספק, לא תיק PDF.

מה ה-AI יכול לעשות

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

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

אודיט ולוגים

זאת השאלה שלקוחות הכי שוכחים לשאול בשלב הבחירה, וזאת השאלה שמטרידה אותם הכי הרבה אחרי 6 חודשים.

אם משהו השתבש, צריך להוכיח מה קרה. אם עובד פוטר וטוען שלא הוא הוציא את הקובץ, צריך הוכחה. הסטנדרט המינימלי כולל לוג של כל שאילתה לסוכן עם user, timestamp, IP, וה-skill שהופעל. לוג נפרד של כל פעולת כתיבה ב-SAP עם ה-payload המלא של מה שנשלח, שמור לפחות 90 ימים. והתראות real-time במקרה של דפוס חשוד DROP TABLE, ניסיונות זיהוי כושלים, רצפים מהירים של פעולות חריגות.

ספק שלא יכול להציג לכם דוגמת לוג בדמו, מציג שקופית של איך זה אמור להיראות, או אומר “זה תכונה בדרך” — דגל אדום ענקי. תבקשו לוג אמיתי, לא vendor brochure.

מי בתוך הספק

זאת השאלה הכי קשה לשאול ולכן הכי שווה לשאול. הספק שלכם הוא חברה עם עובדים. למישהו שם יש גישה למסד הנתונים. ל-DBA, למפתחים, ל-SRE. הם לא יסתכלו בלי סיבה, אבל היכולת קיימת, וזה לא תיאוריה — זה איך כל SaaS עובד.

יש כמה דברים שמקטינים את הסיכון. הצפנה במנוחה (encryption at rest) של credentials רגישים זה מינימום. מסד נתונים מבודד לכל לקוח (per-customer schema) זה רמה מתקדמת יותר שמקטינה גישה צד-בצד. BYOK (Bring Your Own Key) זה כשאתם מספקים לספק את ה-API key של Anthropic או של AWS — הנתונים זורמים דרך החשבון שלכם, לא של הספק, אז גם אם הספק רוצה להציץ אין לו גישה. ובקצה הקיצוני, מצב Zero-Trust שבו גם הספק לא יכול להתחבר ל-SAP שלכם — כל משתמש מתחבר עם הסיסמה שלו עצמו. מודל שמיושם אצל לקוחות שמנהלים מידע ביטחוני.

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

תקנים שצריך להכיר

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

SOC 2 ו-ISO 27001 הם סטנדרטים בינלאומיים לאבטחת מידע. ספק שלא מוסמך לא בהכרח פסול, אבל הוא צריך לתת תשובות מספקות לכל שאר השאלות. GDPR ו-חוק הגנת הפרטיות הישראלי (כולל תיקון 13 שנכנס לתוקף ב-2025) הם החובות הרגולטוריות. כל ספק שעובד עם נתוני אזרחים אירופיים או ישראלים חייב לעמוד בהם, ולתת לכם DPA (Data Processing Agreement) חתום. ZDR ו-BYOK שכבר הזכרתי — תוספים שיכולים לסגור פערים ספציפיים.

הצ’קליסט לפני שחותמים

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

1. לאיזה ספק LLM נשלחת השיחה (Anthropic / OpenAI / Bedrock / אחר)
2. באיזה אזור גיאוגרפי המודל רץ
3. האם נתונים משמשים לאימון (חייב להיות “לא”)
4. מה מדיניות retention
5. איזה הצפנה יש על credentials במנוחה
6. איך SAP permissions אכופות
7. האם SQL חופשי חסום בברירת מחדל לעובדים רגילים
8. האם פעולות כתיבה ב-SAP דורשות אישור משתמש (חייב להיות “כן”)
9. איזה לוגים זמינים, ולכמה זמן נשמרים
10. איזה תקני אבטחה הספק עומד בהם
11. DPA, קיים? עומד לחתימה?

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

איך אנחנו ב-Nesh ניגשים לזה

ב-AigentOne שלנו אנחנו מיישמים את כל מה שהזכרתי למעלה: הצפנה במנוחה של כל ה-credentials, Confirmation Gating על כל פעולה ב-SAP, מודל הרשאות 3 שכבות ל-SQL, אופציות ל-Zero Data Retention עם Anthropic, ניתוב דרך AWS Bedrock לאזור אירופה, BYOK, ומצב Zero-Trust שמונע גם מאיתנו להתחבר ל-SAP שלכם.

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

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