כל חיבור של כלי בינה מלאכותית לשירות חיצוני, מחשבון בנק ועד תיקיית לקוח, עובר דרך מסך הרשאה שקובע מה הכלי יכול לראות ולעשות. שלושה עקרונות לחיבור תקין, מי נושא באחריות כשההרשאה רחבה מהנדרש, ורשימת בדיקה לפני אישור ספק או שירות MCP.
MCP, ראשי תיבות של Model Context Protocol, הוא תקן טכני שמאפשר לכלי בינה מלאכותית להתחבר לשירותים חיצוניים ולהחליף איתם מידע: תיבת דואר, יומן, מערכת קבצים, חשבון בנק או מערכת פנימית של הארגון. השאלה המשפטית שהתקן הזה פותח אינה טכנית: מה מותר לחבר, מי אישר את ההרשאה, ומי נושא באחריות כשההרשאה שניתנה רחבה מהצורך בפועל.
השאלה הזאת חשובה לכל מי שמחבר נתון רגיש, אישי או עסקי, לכלי AI: יחיד שמחבר את חשבון הבנק שלו, עורך דין שמחבר תיקיית לקוח, וארגון שמחבר מערכת פנים ללקוחותיו.
כשמחברים כלי AI לשירות חיצוני, מסך ההרשאה קובע מה הכלי יכול לראות ולעשות: קריאה בלבד, או גם כתיבה ופעולה. הרשאה רחבה מהנדרש אינה רק סיכון טכני, היא גם שאלה של אחריות: מי יישא בנזק אם הכלי ביצע פעולה שלא הייתה דרושה למשימה, מכוח הרשאה שניתנה לו בלי צורך אמיתי.
כל חיבור של כלי AI לשירות חיצוני, הרשאת בנקאות פתוחה או שירות MCP בכלל זה, צריך לעמוד בשלושה עקרונות.
העיקרון הראשון: הרשאת קריאה בלבד כברירת מחדל. גישה לכתיבה, לביצוע פעולה או לשינוי במערכת המקור ניתנת רק כשהמשימה דורשת זאת בפועל, ולא כהרחבה למקרה שתידרש בעתיד.
העיקרון השני: האימות מתבצע במקור, לא בתוך שיחה עם הכלי. בקשה להזין סיסמה, קוד אימות או מפתח גישה בתוך חלון צ'אט היא סימן אזהרה, לא שלב רגיל בתהליך.
העיקרון השלישי: ההרשאה הדירה בכל עת, ובאחריות הצד שמחבר לבדוק זאת לפני האישור, לא אחריו.
כשמשהו משתבש, שלושה גורמים עלולים לחלוק באחריות: הארגון או היחיד שאישר הרשאה רחבה מהנדרש, הספק שבנה את החיבור כך שהוא מבקש יותר ממה שהמשימה דורשת, וכלי ה-AI עצמו, אם הוא ניצל הרשאה קיימת לפעולה שלא התבקשה. בפועל, הגורם שמאשר את מסך ההרשאה נושא בנטל הראשון: לבדוק מה כתוב במסך עצמו, לא רק את תיאור השירות בעמוד השיווק שלו.
לפני שמאשרים חיבור של כלי AI לשירות חיצוני, שווה לעבור על רשימה קצרה: האם ההרשאה המוצגת בפועל במסך האישור תואמת את מה שהמשימה דורשת, האם ניתן לבטל את ההרשאה בלי תלות בספק המתווך, האם מפתחות גישה, במקרה של חיבור מתקדם מול API, נשמרים רק במחשב המשתמש, והאם הספק עצמו מורשה או מפוקח כשהחיבור נוגע לתחום מוסדר כמו פיננסים, בריאות או מידע ציבורי.
הדוגמה הנפוצה ביותר בפניות שמגיעות למשרד היא חיבור חשבון בנק או כרטיס אשראי לכלי AI, לקבלת ניתוח או דשבורד. כאן שלושת העקרונות שלמעלה מקבלים צורה מוחשית: החיבור צריך לאפשר צפייה בנתונים בלבד, האימות צריך להתבצע באתר הבנק או באפליקציה שלו ולא בתוך הצ'אט, וצריכה להיות דרך פשוטה לבטל את ההרשאה. לפני שמאשרים, כדאי לבדוק מי הגורם שמקבל את הנתונים בפועל, ואם הוא פועל ברישיון או בפיקוח בתחום הפיננסי.
שירות שמבקש את סיסמת הבנק בתוך שיחה עם הכלי, או הרשאה לבצע פעולות בחשבון כשהמשימה היא ניתוח בלבד, חורג מהעקרונות האלה, גם אם הוא מציג את עצמו כשירות בנקאות פתוחה.
חיבור חשבון אישי הוא עניין של היחיד. חיבור נתוני לקוחות, ספקים או עובדים לכלי AI חיצוני הוא עניין אחר: הוא עשוי להיתפס כהעברת מידע לעיבוד על ידי צד שלישי, ולדרוש בסיס חוקי ברור במסגרת דיני הגנת הפרטיות, מעבר להסכמת בעל החשבון עצמו. ארגון ששוקל חיבור כזה, ראוי שיבדוק זאת לפני ההחלטה, לא אחריה.
מאמר זה מידע כללי ואינו ייעוץ משפטי. הנושא קרוב לזה שנכתב במאמר סודיות וחיסיון כשעורך דין מזין מידע לקוח למודל שפה, העוסק בהרשאה מהצד ההפוך: מה מותר להזין, לא מה מותר לחבר. המונחים עצמם מוגדרים במילון מונחי Legal AI.
ד״ר עו״ד אברהם ללום מלווה משרדים וארגונים בבדיקת חיבורי AI לנתונים רגישים לפני שהם עולים לאוויר, במסגרת הייעוץ בתחום הבינה המלאכותית.
נושא: בינה מלאכותית וממשל סיכונים
השירות בתחום: ייעוץ וחוות דעת שנייה בנושא AI
ייעוץ וחוות דעת נדל״ן · ייעוץ וחוות דעת AI · ייעוץ משפטי · גישור ויישוב סכסוכים · מאמרים · שאלות ותשובות · מבדק מוכנות · לתיאום פגישת ייעוץ
כל שינוי בקוד נבדק בשער פיתוח מאובטח לפי עקרונות OWASP Top 10, ISO/IEC 27001:2022 (A.8.28) ו-NIST SSDF. בדיקה אחרונה: 2.11.2026. פירוט הבקרות