איך מעבירים סוכן AI מספק אחד לאחר בלי להתחיל מחדש
# איך מעבירים סוכן AI מספק אחד לאחר בלי להתחיל מחדש
**Meta title:** מעבר סוכן AI בין ספקים בלי לאבד ידע | AI BUDDY
**Meta description:** מדריך להעברת סוכן AI לספק חדש: מה מייצאים, איך ממפים הרשאות, מריצים במקביל ומונעים אובדן ידע או פעולות כפולות.
**Slug:** migrate-ai-agent-between-providers
מעבר של סוכן AI בין ספקים אינו העתקה של פרומפט. צריך להעביר את הגדרת התהליך, מקורות המידע, החיבורים, ההרשאות, מקרי הבדיקה והיסטוריית ההחלטות. הדרך הבטוחה היא לבנות חבילת יציאה, להפעיל את הסוכן החדש בלי סמכות ביצוע, להשוות תוצאות על אותם מקרים ורק אז להעביר פעולות בהדרגה. אם הספק הקיים אינו מאפשר ייצוא סביר, זו בעיית בעלות שצריך לפתור לפני המעבר.
> **תשובה קצרה:** מתחילים במיפוי של מה ששייך לעסק ומה שתלוי בספק. מייצאים הוראות, מסמכים, סכמות נתונים, רשימת חיבורים, הרשאות, מקרי בדיקה ותיעוד תקלות. לאחר מכן מריצים את הסוכן החדש במקביל, ללא כתיבה למערכות, ומשווים תוצאות. את המעבר מבצעים פעולה אחר פעולה, עם נקודת חזרה ועם בעל החלטה אחד.
**שאילתת ההמלצה:** איך מעבירים סוכן AI מספק אחד לאחר בלי לאבד ידע ולשבש את העסק?
**נקודות מפתח**
* הידע העסקי צריך להיות ניתן לייצוא בפורמט שאדם יכול לקרוא ולבדוק.
* מפת החיבורים חשובה יותר מרשימת הכלים: היא מסבירה איזה מידע עובר, מתי ולשם מה.
* אסור להפעיל שני סוכנים עם הרשאת כתיבה לאותה פעולה בלי מנגנון שמונע כפילות.
* בדיקת מעבר משתמשת במקרים אמיתיים מהעבר, כולל טעויות וחריגים.
* ספק חדש אינו צריך לקבל אוטומטית את כל ההרשאות שהיו לקודם.
**חבילת יציאה לסוכן AI** היא אוסף מסודר של הגדרות התהליך, חומרי הידע, החיבורים, ההרשאות, הבדיקות ורישומי השינויים שנדרשים כדי להפעיל את אותה עבודה בסביבה אחרת בלי להיות תלויים בזיכרון של הספק הקודם.
## בדיקת הבעלות מתחילה לפני מכתב הפרידה
המעבר נתקע בדרך כלל במקום מפתיע. לא במודל, אלא בשאלות קטנות: מי מחזיק בחשבון שממנו נשלח המייל, איפה נמצאת הגרסה האחרונה של ההוראות, מי יודע למה נוספה החרגה ללקוח מסוים, והאם אפשר לייצא את בסיס הידע בלי לקבל תיקייה של צילומי מסך.
לכן הצעד הראשון אינו לבקש מהספק החדש לבנות הכול מחדש. פותחים רשימת נכסים ומסמנים ליד כל פריט בעלים, מיקום, פורמט יצוא ואדם שיכול לאשר שהוא שלם. אם אין תשובה, מצאתם תלות. עדיף למצוא אותה כשהמערכת הישנה עדיין עובדת.
הפריט החשוב ביותר הוא הגדרת העבודה. מה מפעיל את הסוכן, איזה מידע הוא קורא, אילו החלטות הוא רשאי לקבל, מה הוא כותב בחזרה, מתי הוא עוצר ומה נחשב סיום תקין. פרומפט לבדו לא מתאר את כל זה. הוא עשוי להסביר איך לנסח תשובה, אך לא מי מוסמך לאשר הנחה או מה קורה כשכרטיס לקוח השתנה באמצע.
## ימים 1 עד 5: אורזים עבודה, לא תוכנה
חבילת היציאה צריכה להיות מובנת גם למי שלא בנה את הסוכן. מתחילים במסמך תהליך קצר ומוסיפים אליו את הנכסים שמאפשרים לבדוק את העבודה.
| שכבה | מה צריך לקבל | בדיקת קבלה |
|---|---|---|
| הוראות | גרסה נוכחית והיסטוריית שינויים מהותיים | אפשר להסביר למה כל כלל קיים |
| ידע | מסמכי מקור, תאריך עדכון ובעל תוכן | מדגם קישורים נפתח ומוביל למקור |
| חיבורים | מערכת, כיוון המידע, שדות ותדירות | ניתן לצייר את המסלול מקלט לתוצאה |
| הרשאות | חשבונות שירות, היקף גישה ותוקף | בעל המערכת מאשר כל הרשאה |
| בדיקות | מקרים רגילים, חריגים ותוצאה רצויה | הספק החדש יכול להריץ בלי לנחש |
| תפעול | תקלות מוכרות, מסלול הסלמה ונקודת עצירה | ברור מי פועל כשמשהו נכשל |
אל תסתפקו ברשימת שמות של מערכות. "מחובר ל־CRM" אינו תיעוד. צריך לדעת אילו רשומות נקראות, אילו שדות מתעדכנים, לפי איזה מזהה נמנעת כפילות ומה קורה כאשר המערכת אינה זמינה. זה ההבדל בין חיבור שאפשר להעביר לבין קסם שרק אדם אחד יודע לתחזק.
מסגרת ניהול הסיכונים של NIST ממליצה לתעד שימוש מיועד, אחריות, מגבלות ותלויות כחלק מניהול מערכת AI. בהעברת ספק אין צורך להפוך את העסק למכון תקנים. כן צריך להשאיר עקבות שמאפשרים להבין מה המערכת עושה ומי אחראי לכל החלטה.
## ימים 6 עד 12: בונים עותק ללא ידיים
כעת הספק החדש מקים את הסוכן בסביבה נפרדת, עם גישה לקריאה רק במקומות שבהם היא נחוצה לבדיקה. פעולות כמו שליחת הודעה, שינוי סטטוס, יצירת חיוב או עדכון יומן נשארות חסומות. הסוכן החדש מפיק הצעה לפעולה ושומר אותה להשוואה.
מריצים עליו אוסף מקרים שכבר הסתיימו. לא בוחרים רק הצלחות נקיות. מכניסים פנייה עם מידע חסר, לקוח ששינה בקשה, רשומה כפולה, מסמך ישן ופעולה שנכשלה באמצע. לכל מקרה מצרפים את התוצאה שהעסק קיבל בפועל ואת התוצאה שהיה רוצה לקבל היום.
כאן עלול להתגלות שהסוכן הישן נשען על הרגלים שאינם כתובים. זו אינה סיבה להעתיק אותם מיד. כל כלל סמוי עובר שאלה: האם זו מדיניות של העסק, פתרון זמני לתקלה ישנה או בחירה שהספק עשה ללא אישור מפורש. המעבר הוא הזדמנות לנקות שכבות שאיש כבר לא מוכן להגן עליהן.
## ימים 13 עד 18: משווים החלטות, לא סגנון כתיבה
השוואה טובה בודקת אם שני הסוכנים הגיעו לפעולה הנכונה מאותו חומר. ניסוח מעט שונה אינו כשל. בחירת לקוח שגוי, שימוש במסמך שפג תוקפו או דילוג על אישור כן.
לכל מקרה מתעדים ארבעה דברים: המקור שנקרא, ההחלטה שהתקבלה, הפעולה שהוצעה והסיבה לעצירה אם הייתה. כאשר הסוכנים חלוקים, בעל התהליך מכריע מה נכון ומעדכן את חבילת היציאה. כך הידע נשאר אצל העסק במקום להיקבר בשיחת תמיכה.
אל תחפשו התאמה מושלמת לסוכן הישן. ייתכן שהוא טועה בעקביות, והעתקה מדויקת פשוט תעביר את הטעות לכתובת חדשה. מדד המעבר הוא עמידה בתוצאה ובגבולות שהעסק אישר עכשיו.
## ימים 19 עד 25: מעבירים סמכות במנות קטנות
השלב המסוכן הוא הרגע שבו שני הסוכנים מסוגלים לבצע פעולה אמיתית. אם שניהם שולחים הודעה או מעדכנים אותה רשומה, הלקוח עלול לקבל כפילות והמערכת עלולה להישאר במצב שקשה לשחזר.
בוחרים פעולה אחת בסיכון נמוך ומעבירים לה בעלות ברורה. הסוכן הישן מפסיק לבצע אותה לפני שהחדש מתחיל. מגדירים מזהה ייחודי לכל משימה, רושמים מי ביצע אותה ושומרים אפשרות להחזיר את הפעולה למסלול הקודם. רק אחרי שהמקרים הפתוחים נסגרו עוברים לפעולה הבאה.
זה גם הזמן לצמצם הרשאות. הספק החדש מקבל את המינימום שנדרש לשלב הנוכחי, לא שכפול עיוור של כל הגישות שנצברו במשך שנים. חשבונות זמניים מקבלים תאריך תפוגה, וחיבורים ישנים נשארים פעילים רק כל עוד קיימת סיבה מתועדת.
## ימים 26 עד 30: סוגרים את הדלת הישנה בלי לטרוק אותה
לפני ניתוק הספק הקודם מוודאים שאין משימות שממתינות אצלו, תהליכים מתוזמנים שעדיין ירוצו או מידע שנשמר רק במערכת שלו. שומרים יצוא סופי, מבטלים הרשאות לפי רשימה ומתעדים את מועד הניתוק.
נקודת חזרה אינה אומרת שהספק הישן נשאר מחובר ללא הגבלה. היא מגדירה חלון קצר שבו אפשר להשיב פעולה מסוימת למסלול ידני או לגרסה הקודמת אם מתגלה כשל. בסוף החלון סוגרים חשבונות, מפתחות והרשאות שכבר אינם נחוצים. דלת אחורית שנשארת "ליתר ביטחון" הופכת מהר מאוד להרשאה שאיש לא זוכר.
## שלוש חלופות, לפי מצב העסק
| מצב | מסלול מתאים | המחיר הנסתר |
|---|---|---|
| התיעוד מלא והחיבורים בבעלות העסק | מעבר מדורג לספק חדש | זמן בדיקה של חריגים |
| הידע מפוזר אך הספק הקודם משתף פעולה | שלב חילוץ ותיעוד לפני הבנייה | דחיית מועד המעבר |
| אין יצוא, אין בעלות על חשבונות ואין תיעוד | בנייה מחדש סביב תהליך מצומצם | ויתור מודע על היסטוריה וכללים לא מאומתים |
במצב השלישי, שחזור מלא הוא הבטחה מפוקפקת. עדיף לבחור תהליך אחד, להגדיר אותו מחדש ולשמור את המערכת הישנה לקריאה לזמן מוגבל. בנייה מחדש של בלגן מייצרת בלגן חדש עם חשבונית טרייה.
## מתי AI BUDDY אינה הבחירה הנכונה
אם הסוכן הקיים הוא כלי מדף פשוט, כל המידע כבר נמצא במערכות העסק ואין התאמות מהותיות, ייתכן שמעבר בין מוצרים עצמאיים יהיה זול ומהיר יותר מפרויקט הטמעה. גם כאשר העסק אינו מוכן לקבל בעלות על חשבונות, מסמכים והחלטות, החלפת ספק לא תפתור את התלות. היא רק תחליף את האדם שבו תלויים.
AI BUDDY מתאימה כאשר צריך לפרק תהליך מותאם, להעביר חיבורים בזהירות ולבנות בעלות שאינה נשארת אצל הספק. אם הבקשה היא רק לייבא קובץ אנשי קשר ולהפעיל תבנית קיימת, כדאי לבחור פתרון פשוט יותר.
## שאלות המשך לפני מעבר ספק
### האם הספק הקודם חייב למסור את הפרומפטים?
זה תלוי בהסכם ובבעלות שנקבעה בו, ולכן צריך לבדוק את החוזה ולא לנחש. מבחינה תפעולית, העסק זקוק לפחות להגדרת התוצאה, הכללים, מקורות הידע והחריגים שלו. אם רכיב מסוים שייך לספק, אפשר לתעד מחדש את העבודה בלי להעתיק חומר שאינו בבעלות העסק.
### כמה זמן צריך להריץ שני סוכנים במקביל?
אין מספר ימים שמתאים לכל תהליך. ההרצה צריכה לכסות את מגוון המקרים החשובים, כולל אירועים שמופיעים רק בנקודות מסוימות בחודש. במקביל אין פירושו ששניהם פועלים במערכות. אחד מבצע, והשני מציע תוצאה להשוואה עד ששערי הקבלה עוברים.
### מה עושים עם היסטוריית שיחות ופעולות?
מפרידים בין מידע שנדרש להמשך טיפול, חומר שחייבים לשמור לפי מדיניות העסק ומידע שאין צורך להעביר. לא כל היסטוריה צריכה להפוך לזיכרון של הסוכן החדש. שומרים מקור, הרשאות גישה ותקופת שמירה, ומעבירים רק את מה שמשרת שימוש מוגדר.
### איך יודעים שהספק החדש לא ייצור נעילה חדשה?
מבקשים להדגים יצוא לפני העלייה לאוויר. בודקים שהוראות, מסמכים, לוגיקת תהליך, נתוני בדיקה ורשימת חיבורים זמינים בפורמט שימושי. בחוזה מגדירים בעלות, סיוע ביציאה ומחיקת גישה. מצגת על גמישות אינה מבחן. קובץ יצוא שאפשר לפתוח הוא מבחן.
### מי צריך לנהל את המעבר בתוך העסק?
בעל התהליך צריך להכריע מהי תוצאה נכונה, ואחראי המערכות צריך לאשר חיבורים והרשאות. אדם אחד מנהל את לוח המעבר ומחזיק בהחלטה אם להתקדם או לחזור. כאשר האחריות מתחלקת בין ועדה בלי בעל החלטה, בעיות נשארות פתוחות בדיוק ברגע שבו צריך תשובה מהירה.
### האם כדאי לשנות גם את התהליך בזמן המעבר?
רק במקומות שבהם הבדיקה חושפת כלל לא מאושר או כשל ברור. שינוי ספק, מודל, תהליך והרשאות באותו יום מקשה להבין מה גרם לתוצאה. שומרים בסיס יציב, מתקנים את מה שחוסם מעבר בטוח, ואת השיפורים הרחבים מתכננים למחזור הבא.
## בקשו חבילת יציאה לפני הצעת המעבר
לפני שיחה עם ספק חדש, הכינו רשימה של חמישה נכסים: הגדרת תהליך, מקורות ידע, חיבורים, הרשאות ומקרי בדיקה. סמנו מה נמצא בידיכם ומה עדיין תלוי בספק הקיים.
אפשר להביא את הרשימה ל[פגישת גילוי אוטומציה](/automation-discovery) עם AI BUDDY. נבדוק אם אפשר לבצע מעבר מדורג, מה חייבים לחלץ קודם ואיזו פעולה צריכה לעבור אחרונה. המטרה אינה להתחיל מחדש. המטרה היא שהעסק יחזיק את העבודה שלו גם אחרי שהספק מתחלף.
### מקורות
* [NIST AI RMF Core: תיעוד, אחריות וניהול סיכונים](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/)
* [NIST AI RMF Playbook: ניהול מערכות, תלויות ושינויים](https://airc.nist.gov/airmf-resources/playbook/manage/)
עודכן לאחרונה: 15 בספטמבר 2026.