Deployment Mode · 2 of 5
בינה מלאכותית ללא שמירת נתונים (Zero Data Retention)
אותם מודלי Frontier. חוזה שונה. ZDR endpoints מאפשרים להשתמש ב־Claude, GPT ו־Gemini על מידע לקוחות, workloads רגולטוריים ומידע עסקי רגיש - מבלי שהשאילתות יישמרו, יירשמו לצורכי training או ישמשו לשיפור השירות של הספק. איכות המודלים נשארת זהה. חשיפת המידע נעלמת.
עבור workloads שבהם Public Cloud פתוח מדי ו־Self-Hosted איטי מדי להטמעה - ZDR הוא הפתרון. BrainPack מנתבת workloads ל־ZDR באופן אוטומטי כאשר סיווג המידע דורש זאת.
ZDR הוא התשובה לשאלה שרוב הספקים לא ישאלו אתכם.
קראו את תנאי ה־API הסטנדרטיים של OpenAI. קראו את תנאי ה־API הסטנדרטיים של Anthropic. קראו את תנאי ה־API הסטנדרטיים של Azure OpenAI. הם לא זהים למה שמופיע בעמודי השיווק. בתוך השפה המשפטית מסתתרים סעיפים על ניטור תוכן, זיהוי שימוש לרעה, רישום פרומפטים, ובהתאם להגדרות ורמת המוצר גם שימוש אפשרי בנתונים שלכם לצורכי בטיחות, הערכה או שיפור השירות. שום דבר מזה לא זדוני. הכול אמיתי. וכמעט שום דבר מזה לא מתאים לנתונים שה־CFO שלכם שולח למערכות AI כשאף אחד לא בודק את כותרות ה־API.
גישה חוזית שונה על אותם מודלים בדיוק. אותו Claude, אותו GPT, אותו Gemini, אותה מהירות, אותה איכות תנאים שונים. הספק מתחייב בכתב שהנתונים אינם נשמרים בצד שלו מעבר לרגע העיבוד, אינם נרשמים לצורכי אימון, אינם נבדקים לצורך שיפור השירות, ובמקרים רבים אף אינם משמשים לניטור שימוש לרעה. רמת הציות גבוהה יותר באופן משמעותי. המחיר מעט גבוה יותר. היתרון הוא היכולת לשלוח נתונים רגישים למודלים מתקדמים ללא בעיית ה־audit trail שקיימת בענן הציבורי.
ZDR הוא מצב הטמעה שמסבירים אותו לא נכון יותר מכולם ב-2026. ספקים מזכירים אותו אבל לעתים נדירות מסבירים מתי הוא התשובה הנכונה, מתי הוא לא מספיק, ואיך הוא מסנכרן עם המצבים האחרים. העמוד הזה מכסה את כל זה.
מה המשמעות האמיתית של ZDR.
זו הגדרה חוזית, לא ארכיטקטורה טכנית.
Zero Data Retention פירושו ניתוב inference דרך endpoints שבהם ספק ה־AI התחייב חוזית שלא לשמור את ה־inputs או ה־outputs שלכם. השאילתה והתשובה מעובדות בזיכרון בלבד - ונמחקות לאחר סיום קריאת ה־inference. המידע לא נכנס ל־training corpora, לא משמש ל־fine-tuning של מודלים קיימים או עתידיים, ולא נאסף או נדגם לצורכי שיפור השירות.
Zero Data Retention פירושו ניתוב inference דרך endpoints שבהם ספק ה־AI התחייב חוזית שלא לשמור את ה־inputs או ה־outputs שלכם. השאילתה והתשובה מעובדות בזיכרון בלבד - ונמחקות לאחר סיום קריאת ה־inference. המידע לא נכנס ל־training corpora, לא משמש ל־fine-tuning של מודלים קיימים או עתידיים, ולא נאסף או נדגם לצורכי שיפור השירות.
ZDR הוא לא feature של מוצר - הוא שכבת שירות חוזית. העובדה שספק ה־AI לא שומר את המידע לא מבטלת את הצורך ב־logging; היא פשוט מעבירה את האחריות על ה־audit log לסביבה שלכם. מה נשלח, מי שלח ומה חזר — עדיין חייבים להיות מתועדים somewhere תחת ZDR. ההבדל הוא שה־somewhere הזה כבר לא נמצא אצל ספק ה־AI. החלטת ההטמעה היא החלטת חוזה ו־audit - לא רק שאלה של "האם הספק שומר את המידע".
BrainPack מתייחסת ל־ZDR כאל שכבת execution אחת מתוך חמש. שכבות ה־Connect, Orchestrate ו־Governance אינן משתנות. מה שמשתנה הוא המסגרת החוזית שמנהלת את קריאת ה־inference - והעובדה שכל ה־audit trail של ה־inputs, ה־outputs והחלטות הניתוב נשמר כולו בצד שלכם.
איך זה עובד בפועל - שכבת ה־Governanceאיפה ZDR הוא הבחירה הנכונה.
5 סוגי workloads שבהם הוא מספק את היתרון הגדול ביותר.
חמש קטגוריות של workloads שבהן ZDR הוא הבחירה הנכונה - כאשר איכות מודלי ה־Frontier חשובה, אבל רגישות המידע גבוהה מדי עבור תנאי השמירה הסטנדרטיים של Public Cloud.
Confidential Internal Data עם מודלי Frontier
מסמכי אסטרטגיה פנימיים, ניתוחי M&A, חומרי דירקטוריון ודוחות כספיים שטרם פורסמו. המידע אולי לא מחייב Self-Hosting מבחינה רגולטורית — אבל הוא מספיק רגיש כדי שלא תרצו שהוא יישמר אצל ספק AI או ייכנס לתהליכי training ושיפור שירות. ZDR מאפשר לשמור על איכות מודלי ה־Frontier - בלי שכבת השמירה וה־retention של Public Cloud רגיל.
מידע לקוחות תחת הסכמי סודיות והגבלות חוזיות
חוזים מול לקוחות Enterprise כוללים לעיתים סעיפים שאוסרים שימוש במידע שלהם לצורכי training של מודלים חיצוניים או שמירה אצל subprocessors. ZDR endpoints מאפשרים לעמוד בדרישות האלה - תוך המשך עבודה מול אותם ספקי AI שהצוות שלכם כבר עובד איתם כיום.
Customer-Facing Apps ב־Production עם מידע אישי (PII)
סוכני תמיכה, assistants לניהול חשבונות וכל מערכת שנוגעת ברשומות לקוח, פרטי קשר או היסטוריית עסקאות. תנאי Public Cloud סטנדרטיים יוצרים מורכבות סביב חשיפה, audit ו־compliance. ZDR מסיר לחלוטין את שאלת ה־retention מהשכבה החוזית.
תעשיות רגולטוריות על גבי מודלי Cloud
שירותים פיננסיים, מערכות Healthcare ועומסים משפטיים שדורשים את איכות מודלי ה־Frontier - אך פועלים תחת רגולציות כמו SEC, HIPAA, GLBA או חיסיון עו״ד־לקוח, שבהן שמירת מידע אצל ספק AI יוצרת סיכון Compliance. במקרים רבים, ZDR הוא הגשר בין "אפשר להשתמש במודל הזה" לבין "אי אפשר להשתמש בו בכלל".
כאשר ה־Audit Trail חייב להישמר בצד הארגון
ביקורות פנימיות, legal hold ובדיקות רגולטוריות. לוגים שנשמרים אצל ספק AI הם שכבת סיכון שקשה לשלוט בה לחלוטין — מה נשמר, איפה זה נשמר ולכמה זמן. ב־ZDR הספק לא שומר דבר, וכל ה־audit trail של ה־inputs, ה־outputs והחלטות הניתוב נשמר אצלכם - תחת מערכות ה־logging ומדיניות השמירה שכבר קיימות בארגון.
מתי לא נכון להשתמש ב־ZDR - ואיזה מודל הטמעה מתאים במקום.
יש workloads שבהם גם ZDR לא מספיק - או לחלופין מיותר לחלוטין. במקרים האלה BrainPack בוחרת במודל הטמעה אחר בהתאם לדרישות המידע, הרגולציה והעלות.
Data שחייב להישאר בתוך הרשת הארגונית
חוזי ביטחון עם סיווגי מידע מבוקרים, workloads מודיעיניים וכל מערכת תחת דרישות Air-Gap. גם ב־ZDR, קריאת ה־inference עדיין עוברת דרך האינטרנט הציבורי אל ספק AI חיצוני. אם סיווג המידע אוסר עצם היציאה של המידע מהרשת הארגונית - ה־workload חייב לרוץ ב־On-Premise או Air-Gapped. שום תנאי חוזי של retention לא פותר בעיית network egress.
מקרים שבהם ריבונות מידע מנצחת את איכות ה־AI
נתוני ליבה בנקאיים במדינות עם דרישות Data Residency מחמירות, workloads ממשלתיים תחת FedRAMP High או רגולציות מקבילות, ומידע רפואי במדינות שאוסרות עיבוד מידע מחוץ לגבולות המדינה. במקרים כאלה, מיקום הדאטה־סנטר של הספק חשוב יותר מהתנאים החוזיים. הפתרון הנכון הוא Self-Hosted באזור שלכם או סביבת On-Premise.
Core IP שלא מורשה לעזוב את סביבת הארגון
קוד מקור של מוצרים מסחריים, אלגוריתמים קנייניים, סודות מסחריים ותיעוד תהליכי ייצור. גם ב־Zero Data Retention, ה־inference עדיין רץ על תשתית מחשוב של ספק AI חיצוני. עבור ארגונים שבהם היתרון התחרותי הוא ה־IP עצמו, הבחירה הנכונה היא Self-Hosted Open Source על גבי GPU ייעודי - בלי ספק AI חיצוני במסלול המידע, אף פעם.
משימות יומיומיות שלא מצדיקות שכבת ZDR
ניסוח אימיילים, סיכום מסמכים ציבוריים, brainstorming וניתוח מידע שכבר פומבי. ל־ZDR יש עלות גבוהה יותר ומבחר מודלים מצומצם יותר לעומת Public Cloud רגיל. שימוש ב־ZDR עבור workloads שלא באמת צריכים אותו מבזבז תקציב וקיבולת שצריכים להיות שמורים למידע שבאמת דורש את ההגנה החוזית הזו.
כאשר היכולות החדשות עדיין זמינות רק ב־Public Cloud רגיל
מודלי Frontier חדשים מגיעים קודם ל־Public Cloud הסטנדרטי. ZDR endpoints, Self-Hosted ו־On-Premise מפגרים לעיתים בשבועות או חודשים מבחינת יכולות reasoning, multimodal ו־coding חדשות. אם workload מסוים באמת דורש גישה מיידית למודל חדש — וסיווג המידע מאפשר זאת - Public Cloud רגיל הוא סביבת ההרצה הנכונה, לא ZDR.
לאיזה מודל הטמעה לנתב
General Productivity Work שלא דורש ZDR - ועובד כחלק מארכיטקטורת Multi-Mode מלאה.
ZDR הוא מצב הגשר. ענן ציבורי מהיר אבל ברירת מחדל. מתארח מבוקר אבל המודלים בפיגור. ZDR יושב באמצע - איכות מודל-חזית עם הגנת נתונים חוזית. התזמור חשוב יותר מכל מצב יחיד.
פריסת BrainPack אמיתית נראית כך:
חמש שאילתות. אותו ממשק משתמש. אותה ספריית סוכנים. חמש החלטות ניתוב שונות שהתקבלו אוטומטית על ידי שכבת הממשל על בסיס סיווג נתונים. המשתמש לא בוחר את המצב. המצב בוחר את עצמו על בסיס מה הנתונים. ZDR הוא אחד מהחמישה - ולהרבה ארגונים, זה המצב שרוב העבודות צריכות לנחות עליו ברגע שהן גדלות מעבר לענן ציבורי.
המשתמש לא צריך לבחור איפה ה־AI ירוץ.
שכבת ה־Governance מחליטה לבד.
ZDR בתוך שכבת BrainPack.
ניתוב ל-ZDR endpoint הוא טכנית פשוט. לעשות את זה טוב בסקייל ארגוני דורש כמה דברים מעל קריאת ה-API.
חוזים ארגוניים פעילים
BrainPack מתחזקת הסכמים ארגוניים זכאי-ZDR עם Anthropic, OpenAI (דרך Azure או ישיר), Google Vertex, AWS Bedrock ו-Mistral. החוזים נסגרים ביד מרכזית ומיושמים פר עבודה. אתם לא רוכשים ZDR בנפרד - זה חלק משכבת ההפעלה.
ניתוב אוטומטי לפי סיווג נתונים
שכבת הממשל מסווגת שאילתות על בסיס תוכן, תפקיד משתמש ומדיניות. שאילתות שתואמות לקטגוריות נדרשות-ZDR מנותבות ל-ZDR endpoints - אוטומטית, ללא הזדמנות שמפתח ינתב אותן בטעות ל-endpoints של תנאי ברירת מחדל. הסיווג קורה לפני שהנתונים עוזבים את הסביבה שלכם.
ZDR רב-אזורי
מסגרות רגולטוריות שונות דורשות אזורים פיזיים שונים לעיבוד נתונים. BrainPack מנתבת שאילתות ZDR לאזור הנכון פר עבודה - נתוני EU ל-EU-resident ZDR endpoints, נתוני בריאות בארה"ב ל-endpoints US-resident, וכן הלאה.
גיבוי ספק עם אותה עמדה.
אם לספק ה-ZDR הראשי יש תקלה, המתזמר מנתב לספק זכאי-ZDR גיבוי - לעולם לא נופל חזרה ל-endpoint של ענן ציבורי בתנאי ברירת מחדל. העמדה החוזית נשמרת דרך תקלות.
יומן אודיט בצד שלכם.
אפילו שהספק לא שומר את השאילתות, שכבת הממשל של BrainPack שומרת יומני אודיט מלאים בסביבה שלכם. מה נשלח, מי שלח, מה חזר, מתי. היעדר שמירה מצד הספק לא אומר היעדר אחריות; זה אומר שהאחריות חיה בתשתית הלוגים שלכם.
שקיפות עלויות.
ZDR בדרך כלל יקר יותר פר טוקן מהסקה בתנאי ברירת מחדל. BrainPack עוקבת אחרי הפרש העלות, מייחסת אותו לעבודות שמשתמשות ב-ZDR, ומייצרת דוחות Chargeback שמראים למה העלות היא מה שהיא. עלות ZDR לעתים נדירות היא שיחת תקציב; חשיפת נתונים כן.
עלויות וביצועים. ומה הארגון מקבל בפועל.
ל־ZDR יש עלות חוזית גבוהה יותר ומבחר מודלים מצומצם יותר לעומת Public Cloud רגיל. בתמורה, שאלת ה־retention נעלמת לחלוטין מקריאת ה־inference.
זמן הטמעה מהיר, עם שכבת חוזה Enterprise או gateway עבור ZDR.
לכל קריאה. מעט גבוה יותר מ־Public Cloud רגיל gateways כמו Azure OpenAI ו־Bedrock מוסיפים שכבת ניתוב נוספת. ועדיין, זמני התגובה נשארים לחלוטין בתוך טווחי Production תקינים.
מעל תעריפי Public Cloud רגילים עבור אותו מודל. העלות הנוספת היא עבור השכבה החוזית — לא עבור כוח המחשוב עצמו. מודל החיוב לפי טוקנים נשאר זהה.
מפגר אחרי Public Cloud רגיל בכל הנוגע להשקות של מודלים חדשים. שכבות Enterprise ו־ZDR נפתחות רק אחרי ה־public tier. אם יש workloads שדורשים גישה ביום ההשקה - צריך לתכנן זאת בהתאם.
העלות האמיתית של ZDR היא לא הפרמיה החוזית - אלא ניתוב workloads ל־ZDR שלא באמת צריכים להיות שם. Public Cloud רגיל מטפל בעבודות פרודוקטיביות כלליות בעלות נמוכה יותר ועל גבי מודלים חדשים יותר. שכבת ה־Governance מונעת over-routing בדיוק כפי שהיא מונעת under-routing.
ZDR הוא רק שכבת הרצה אחת מתוך מערכת Multi-Mode מלאה.
ZDR הוא המצב שרוב העבודות הארגוניות המפוקחות מסיימות לרוץ עליו, לצד ענן ציבורי לעבודה לא רגישה ומתארח לניתוח מוגן-IP.
ZDR מטפל בנתוני HR ספציפיים-לעובדים - סינון גיוס, סיכומי סקירת ביצועים, ניתוח תגמול. ענן ציבורי מטפל בש"ת מדיניות ותוכן Onboarding. ממשק HR מאוחד אחד; שני נתיבי ניתוב.
ZDR מטפל באינטראקציות שירות לקוחות וניתוח לקוחות אינדיבידואלי. ענן ציבורי מטפל באנליטיקת מרצ'נדייז על נתונים מאוחדים, לא-אישיים. אותה ספריית סוכנים, שתי עמדות Compliance.
ZDR מטפל בקייסי תמיכת לקוחות אינדיבידואליים; ענן ציבורי מטפל באנליטיקת שרשרת אספקה; מתארח מטפל בניתוח חוזי ספקים. שלושת המצבים פועלים בו-זמנית, נשלטים מרכזית.
ZDR הוא איפה שמודלי חזית הופכים תואמים.
רוב עבודות ה-AI הארגוניות מסיימות מנותבות דרך ZDR endpoints ברגע שהן עוברות את סקירת ה-Compliance הראשונה. דברו עם ארכיטקט על אילו עבודות בסביבה שלכם צריכות להיות בענן ציבורי, ZDR, מתארח, On-Premise או מנותק אינטרנט - ואיך מדיניות התזמור צריכה להיות מוגדרת.