אחד הדברים המבלבלים בעולם ה־AI הוא כמה קל להראות משהו שעובד. דמו טוב יכול לענות יפה, לסכם מסמך, לקרוא מידע, או להפעיל Agent שמבצע פעולה. אבל בארגון אמיתי, השאלה החשובה היא לא רק האם ה־AI הצליח פעם אחת. השאלה היא האם אפשר להבין למה הוא עשה את מה שהוא עשה, מי נתן לו סמכות, מאיפה הגיע המידע, ומה קורה כשהמידע מתיישן או מתנגש עם מידע אחר.
מדמו יפה למערכת שאפשר לסמוך עליה
זו הנקודה שבה דמו מפסיק להספיק. כשמערכת AI משפיעה על החלטות עסקיות, תוכן, מכירות, תמיכה או תפעול, צריך Proof. לא במובן של שקף שמבטיח שהכול בטוח, אלא הוכחה שאפשר לבדוק: מקור, זמן, סמכות כתיבה, Lifecycle, שינוי, מחיקה, ומדיניות שמסבירה מי רשאי לעדכן מה.
הרבה שיחות על זיכרון של Agents מתמקדות בדיוק של Retrieval. האם המערכת שלפה את העובדה הנכונה? האם היא מצאה את המסמך הנכון? זה חשוב, אבל זו לא כל הבעיה. במערכות Production, בעיה קשה לא פחות היא Governance. אם שתי עובדות סותרות אחת את השנייה, מי מנצחת? אם עובדה נכתבה על ידי Agent זמני, האם היא שווה לעובדה שאושרה ידנית? אם מידע הגיע מפגישה ישנה, האם הוא עדיין תקף?
הקוד הפתוח שלנו לקהילה
Notary הוא פיתוח קוד פתוח שלנו סביב governance של memory במערכות multi-agent. הוא יצא מתוך העבודה הפנימית שלנו על תהליכי AI agents בפרודקשן, אבל הריפו הציבורי חושף רק spec ו־benchmark runner, לא את המימוש הפנימי. המטרה היא לתת לקהילה דרך לבדוק provenance, lifecycle, stability ו־governance בלי לחשוף תשתיות פרטיות.
אותה בעיית governance יכולה להופיע אצל צוות שעובד עם Claude Code, Codex, OpenClaw, Hermes, סוכן AI אחר או שכבת orchestration פנימית. Notary אמור להישאר runtime-neutral: העניין הוא לא שם הכלי, אלא האם אפשר לסמוך על הזיכרון שמאחורי התהליך.
כאן נכנסת החשיבה שמאחורי Notary: לא עוד “זיכרון חכם”, אלא דרך למדוד ולמסגר אמינות תפעולית של זיכרון. זה מתחבר ישירות לAI Engine Optimization, אבל ברמה פנימית יותר: לא רק איך מנועי AI מבינים את האתר שלכם, אלא איך המערכות שלכם מבינות את עצמן.
הקונטקסט מהקפסולה וההשקה
ההבדל בין זיכרון לבין זיכרון עם Provenance הוא ההבדל בין “המערכת אמרה” לבין “המערכת יודעת להסביר”. אם Agent טוען שלקוח מסוים ביקש שינוי, צריך לדעת איפה זה נאמר, מתי, מי אישר, והאם ההקשר עדיין נכון. אם מערכת תוכן משתמשת בעובדות על מוצר, צריך לדעת אם העובדות נבדקו או נוצרו באופן זמני. אם Agent מקבל החלטות, צריך לדעת אם הוא פועל על מידע יציב או על רעש.
זה לא רלוונטי רק למחקר AI. זה רלוונטי לכל עסק שמתחיל לחבר AI לתהליכים אמיתיים. אתר שמייצר תוכן אוטומטי, מערכת שמסכמת פניות, Agent שמעדכן CRM, או כלי שממליץ על צעדים מסחריים – כולם צריכים שכבת הוכחה. אחרת, ככל שהמערכת הופכת שימושית יותר, כך קשה יותר לסמוך עליה.
באוטומציות עסקיות רגילות, אנחנו כבר מבינים שצריך Logs, הרשאות, סטטוסים ובקרות. ב־AI זה אפילו חשוב יותר, כי התוצאה יכולה להיראות משכנעת גם כשהבסיס שלה חלש. בלי Provenance, קשה לדעת אם התשובה טובה או פשוט כתובה בביטחון.
המסר של Notary הוא פשוט: אל תמדדו רק מה ה־AI זוכר. מדדו איך הזיכרון מנוהל. האם לכל Fact יש מקור? האם יש Lifecycle? האם יש סמכות כתיבה? האם יש דרך לזהות עובדות זמניות? האם יש הגנה מפני החלפת Facts יציבים בלי אישור? אלה מדדים משעממים לכאורה, אבל הם בדיוק מה שמבדיל בין ניסוי יפה לבין מערכת שאפשר להכניס לעבודה.
זה גם משנה את הדרך שבה בונים אתרים ומערכות עם AI. לא מספיק לבנות פיצ’ר שמייצר טקסט או מנתח מידע. צריך לבנות סביבו תהליך: מה נכנס לזיכרון, מה נשאר זמני, מה מקודם למקור אמת, מי מאשר, ומה נמחק. בלי זה, המערכת צוברת שכבות של מידע לא ברור, ובשלב מסוים אף אחד לא יודע למה היא מתנהגת כמו שהיא מתנהגת.
אותו עיקרון נכון גם באתר עצמו. כשבונים אתר B2B לחברת SaaS או הייטק, טענות, הוכחות, מקרי שימוש ודאטה צריכים להיות מסודרים מספיק כדי שגם אדם וגם מערכת AI יבינו מה מקור האמת.
איך Digitizer חושבת על AI אמין
ב־Digitizer אנחנו מתייחסים ל־AI כתשתית, לא כטריק. אם AI נכנס לאתר, למוצר או לתהליך עסקי, הוא צריך להיות מחובר למדידה, תיעוד ובקרות. לפעמים זה אומר להתחיל קטן. לפעמים זה אומר לבנות סביב ה־Agent מערכת Governance לפני שמרחיבים שימוש. אבל בכל מקרה, Proof צריך להיות חלק מהמוצר, לא משהו שמוסיפים אחרי שמשהו נשבר.
אם אתם בונים דמו AI, אפשר להתחיל מהר. אם אתם בונים מוצר AI, תכניסו הוכחה לתוך התהליך מהיום הראשון.
