שילוב מסקנות AI/ML בתהליכי עבודה של ייצור

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

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

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

כיצד Triggerfish פותרת את זה

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

AI כשלב בתהליך עבודה, לא מערכת נפרדת

ב-DSL של תהליך העבודה, שלב מסקנות LLM מוגדר עם call: triggerfish:llm. תיאור המשימה אומר לתת-הסוכן מה לעשות בשפה טבעית. לתת-הסוכן יש גישה לכל כלי רשום ב-Triggerfish. הוא יכול לחפש ברשת, לשאול מסדי נתונים דרך כלי MCP, לקרוא מסמכים, לגלוש באתרים, ולהשתמש בזיכרון בין-מפגשי. כאשר השלב מושלם, פלטו מוזן ישירות לשלב הבא בתהליך העבודה.

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

אבטחה שלא דורשת הנדסה מותאמת

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

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

תהליך עבודה AI שקורא רשומות לקוח (CONFIDENTIAL) ומייצר סיכום לא יכול לשלוח את הסיכום הזה לערוץ Slack ציבורי. זה אינו מאכף על ידי הוראת prompt שהמודל עשוי להתעלם ממנה. זה מאכף על ידי קוד דטרמיניסטי ב-hook של PRE_OUTPUT שהמודל לא יכול לראות, לא יכול לשנות, ולא יכול לעקוף. ה-hooks של המדיניות רצים מתחת לשכבת ה-LLM. ה-LLM מבקש פעולה, ושכבת המדיניות מחליטה אם לאפשר אותה. פסק זמן שווה לדחייה. אין נתיב מהמודל לעולם החיצון שלא עובר דרך אכיפה.

מסלולי ביקורת שכבר קיימים

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

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

גמישות מודל ללא ארכיטקטורה מחדש

Triggerfish תומכת בספקי LLM מרובים דרך ממשק LlmProvider: Anthropic, OpenAI, Google, מודלים מקומיים דרך Ollama, ו-OpenRouter לכל מודל מנותב. בחירת הספק ניתנת לתצורה לכל סוכן עם failover אוטומטי. כאשר מודל טוב יותר הופך לזמין או ספק משנה תמחור, המעבר מתרחש ברמת התצורה מבלי לגעת בהגדרות תהליכי העבודה.

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

Cron, Webhookים, וביצוע מונע-אירועים

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

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

טיפול בשגיאות ואדם בלולאה

תהליכי עבודה AI ייצוריים צריכים לטפל בכשל בחן. ה-DSL של תהליכי העבודה תומך ב-raise לתנאי שגיאה מפורשים ובסמנטיקת try/catch דרך טיפול בשגיאות בהגדרות משימות. כאשר תת-סוכן LLM מייצר פלט בעל ביטחון נמוך או נתקל במצב שהוא אינו יכול לטפל בו, תהליך העבודה יכול לנתב לתור אישורים אנושי, לשלוח התראה דרך שירות ההתראות, או לנקוט פעולת fallback.

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

איך זה נראה בפועל

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

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

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

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