המהפך האדריכלי הנדרש לניהול סוכנים של AI

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

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

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

למה ניהול מתפרק בעידן של איחוד

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

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

בעובדה, הפירוק הזה מופיע במציאות היומיומית.

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

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

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

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

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

ממדיניות לפלטפורמה

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

• מישור בקרה מאוחד

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

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

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

• אריג נתונים המבוסס על תקנים פתוחים

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

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

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

• ניתוב ויזואלי ויחוס בזמן אמת

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

ניתוב כאן אינו רק “נחמד להיות,” אלא היסוד לבקרה בזמן ריצה ותגובה לאירוע.

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

טיפול בסוכנים כ”עמיתים דיגיטליים”

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

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

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

זה לא “בעיה של כתיבת פרומפט” שהינו מורגלים לנווט; במקום זאת, זו בעיה של זהות ואכיפה בזמן ריצה.

מה משתנה ב-2026: סוכנים עוברים מניסויים לייצור

2026 הוא השנה בה הניסויים מסתיימים, וסוכנים תופסים את המושב המייצר.

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

בלי עיצוב ניהול אדריכלי, שתי המהירויות האלה יסתוכלנה.

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

המטרה אינה לבחור מהירות. היא לבנות אדריכלות שתומכת בשתיהן.

רשימת בדיקה מעשית לניהול סוכנים בזמן ריצה

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

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

המהפך הניהולי צריך להיות אדריכלי, או שאינו קיים

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

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

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

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