פיצול הביצוע: למה סוכני AI צריכים Control Plane

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

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

כדי להוציא סוכנים מהמעבדה אל השטח, אנחנו צריכים להפריד בין ה-Data Plane (איפה שהעבודה קורה) לבין ה-Control Plane (איפה שהחוקים נקבעים).

נקודות מפתח

• מלכודת הדמו: סוכנים נכשלים בייצור כי אין הפרדה בין יכולת החשיבה לבין הסמכות לבצע פעולות.
• ארכיטקטורת שלושת המישורים: הפרדה הכרחית בין מישור הבנייה (Build), התזמור (Orchestration) והבקרה (Control).
• זהות מאומתת: סוכן AI חייב לפעול תחת ⁨זהות משתמש ספציפית ומאומתת⁩, לא תחת חשבון שירות גנרי.
• ממשילות מחוץ ללופ: הבקרה חייבת לשבת מחוץ למסגרת העבודה של הסוכן כדי למנוע מצב שבו הסוכן "עוקף" את החוקים של עצמו.

למה סוכני AI נתקעים בשלב הניסוי

כשבניתי את המערכות הראשונות ב-Aniccai, ראיתי את זה קורה שוב ושוב. צוותים בונים סוכן מדהים ב-LangChain או ב-OpenAI SDK. הוא יודע לענות על שאלות, הוא יודע לקרוא מסמכים. אבל אז מבקשים ממנו לעדכן הזדמנות ב-Salesforce או להנפיק החזר כספי.

כאן מתחילה הבעיה. הסוכן מקבל גישה ל-API עם ⁨הרשאות רחבות מדי⁩. אם הוא הוזה (Hallucination), הוא עלול למחוק דאטה או לשלוח מיילים לא נכונים ללקוחות.

הפתרון המקובל כיום הוא לנסות "לאלף" את הסוכן דרך ה-Prompt. זה לא עובד. ⁨אי אפשר לנהל סיכונים עסקיים⁩ באמצעות בקשות מנומסות ממודל שפה. אנחנו צריכים שכבת בקרה דטרמיניסטית שחוסמת פעולות לא מורשות עוד לפני שהן יוצאות לדרך.

ארכיטקטורת שלושת המישורים של פורסטר

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

1. מישור הבנייה (Build Plane): כאן הסוכן נוצר. זה המקום של ה-LLM, הזיכרון והכלים. כאן הוא לומד "איך" לחשוב.
2. מישור התזמור (Orchestration Plane): כאן הסוכן משתלב בתהליכי עבודה. זה המקום שבו מחליטים מתי הסוכן נכנס לפעולה ואיך הוא מתקשר עם בני אדם.
3. מישור הבקרה (Control Plane): זו השכבה העצמאית שבודקת: האם לסוכן הזה מותר לעשות את הפעולה הזו עכשיו? האם יש לו תקציב? האם המשתמש שהוא מייצג בכלל קיים במערכת?

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

ההבדל בין חשיבה הסתברותית לביצוע דטרמיניסטי

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

ה-Control Plane הופך את הפעולה של הסוכן לדטרמיניסטית. במקום שהסוכן ינסה להבין איך להשתמש ב-API מורכב של SAP, הוא קורא ל-"Enterprise Skill" – פעולה מוגדרת מראש בתוך מישור הבקרה.

זהות משתמש מאומתת: המפתח לאמון

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

מערכות מודרניות משתמשות בטכנולוגיה כמו Verified User Authentication (VUA). זה אומר שהסוכן לא פועל כיישות עצמאית, אלא כזרוע ביצועית של עובד ספציפי. אם לעובד אין הרשאה למחוק לקוח, גם לסוכן שלו לא תהיה. זה פותר את בעיית ה-Compliance ומוודא שכל פעולה משאירה עקבות ברורים במערכות הארגוניות.

מקורות

• Enterprise Agent Architecture: The Three Planes (Mercor)
• What Is an Agent Control Plane? Enterprise Guide 2026 (web)
• Control and Execution Plane for Enterprise AI (2026) (Workato)

שאלות נפוצות

מה ההבדל בין Control Plane ל-Orchestration?

תזמור (Orchestration) עוסק ב-"איך" התהליך רץ – הסדר של הפעולות. בקרה (Control) עוסקת ב-"האם" מותר לפעולה לקרות ובאיזו סמכות.

האם אפשר לבנות Control Plane לבד?

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

למה אי אפשר פשוט להגיד לסוכן ב-Prompt מה אסור לו לעשות?

כי Prompt Injection היא בעיה לא פתורה. משתמש מתוחכם יכול לשכנע את הסוכן להתעלם מההוראות המקוריות שלו. רק חסימה ברמת הרשת או ה-API היא בטוחה באמת.

דברים שחשוב לזכור

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

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