אותה קפסולה — זהות, חוקים והוכחה — חתומה לפי התחום שלכם. פותחים, ורואים את כל הארסנל הרגולטורי, לא כותרת אחת. גם מה שכן, וגם מה שעדיין לא, בגילוי מלא.
למה עכשיו
סוכני AI ניגשים למידעמודלים קוראים את המידע הארגוני, לא רק אנשים.
IAMשולט במשתמשים, לא במודלים.
DLPמזהה מידע, אך לא מונע גישה אמיתית.
הצפנהנופלת ברגע שהספק מחזיק את המפתח.
הרגולטור מתחיל לשאול שאלה חדשה: מי באמת יכול לראות את המידע?
A new control layer · not a competitor
שכבת בקרה חדשה · אין דאטה · אין מפתח · יש הוכחה
לא DLP ולא עוד הצפנה — שכבה חדשה שיושבת מעל הכל: הספק לא רואה את המידע, לא מחזיק מפתח, והכל מוכח קריפטוגרפית. השילוב של שלוש הצלעות הוא מה שאף כלי קיים לא עושה. פריטים המסומנים ב-▲ נשענים עליו.
The AI era · three moves
עידן ה-AI, בשלושה מהלכים
לא עוד רשימת בקרות — מודל אחד: להחליט מה נחשף, לשלוט איך AI מחשב עליו, ולכבול הוכחה לכל נגיעה.
Aמזעור גישה
סריקה מקומית ממפה את השדות הרגישים, ואז רק הפרוסה הנחוצה מפוענחת — need-to-know. תואם GDPR Art 5(1)(c) ו-EDPB 28/2024.
Cחישוב מבוקר
כשצריך AI, הוא רואה רק את הפרוסה הבעייתית בתוך sandbox בשליטתך — לעולם לא הנכס כולו, לעולם לא המפתח.
Bהוכחה כבולה
כל גישה — אדם או סוכן AI — כובלת קבלה עמידה-לזיוף. עוזרת לשמור ולהוכיח את לוגי-התפעול שה-AI Act דורש (Art 12, Art 26(6)).
חובות הסיכון-הגבוה של ה-AI Act נדחו ל-2027–2028 (Digital Omnibus). מכינים אתכם למה שמגיע — ראו את שכבת הגישה ב-Capsule Access API.
One capsule · two modes of ownership
קפסולה אחת · שני מצבי בעלות
אותה קפסולה, אותם קודים — ההבדל היחיד הוא איפה יושב המפתח.
🛠️ נשלטת
מקוון · שליטה
המפתח בשרת — ביטול · סיבוב · שיחה · הוכחות. מופעל בתוכנית.
🔐 עצמאית
אופליין · לנצח
המפתח בקוד — נפתחת אופליין, לנצח, שורדת גם אם NoData ייעלם. חינם.
🌉 הגשר חתום: כל קפסולה עצמאית נחתמת ב-ECDSA, והקובץ מאמת את עצמו לפני שהוא נפתח — זיוף או שינוי נדחים על הסף, כך שלא ניתן להזריק תוכן זדוני לכספת.
הלקוח לא מיישם עשרות בקרות. הוא יורש אותן מהקפסולה.
🩺🔒
קפסולת בריאות
HIPAAHITECH42 CFR Part 2GDPR Health
חתומה ומוכנה. בפנים — 11 דרישות שנמסרות (3 על השכבה החדשה ▲), כולל ה-Safe-Harbor לדיווח פריצה. לחצו לפתוח.
🩺
קפסולת בריאות
HIPAA · HITECH · 42 CFR Part 2 · GDPR Health
כיסוי עמוק
11 נמסרות · 3 חלקיות · 1 לא
11דרישות נמסרות
3חלקיות
1לא כלול · גילוי מלא
✓נמסר במלואו · 11
✓
§164.402 / .404
דיווח פריצה — Safe Harbor▲ שילוש
הצפנה ריבונית → פריצה לא מחייבת דיווח: המפתח לעולם לא אצלנו.
✓
§164.312(a)(2)(iv)
הצפנת ePHI
המפתח מחוץ למשוואה — אין תרחיש שבו הספק חושף PHI.
✓
§164.312(b)
בקרות ביקורת▲ שילוש
יומן חתום ובר-אימות ל-OCR גם בלעדינו.
✓
GDPR Art. 34(3)(a)
פטור מהודעה בזכות הצפנה
פריצה למידע בריאות בלי גל הודעות אישיות.
✓
42 CFR §2.16
רשומות התמכרות (SUD)
חשיפה פלילית → חסום מתמטית, כל נגיעה מוכחת.
✓
GDPR Art. 32(1)(a)
אבטחת עיבוד
ארכיטקטורת no-key בעומק שרגולטור אוהב לראות.
✓
§164.312(c)(1)
שלמות הרשומה
כל שינוי מזוהה קריפטוגרפית — מחזיק גם בבית משפט.
✓
§164.312(a)(1)
בקרת גישה
ביטול גם אחרי שיתוף: סבב-מפתח מנתק גישה לאובייקט העטוף.
✓
§164.502(b)
מינימום הכרחי▲ שילוש
ל-AI אין מפתח לשדות המזהים — מתמטיקה, לא סינון.
✓
§164.308(b) / .502(e)
הסכם עוסק (BAA)
ה-BAA הכי בטוח: לספק אין מפתח ואין ערך מאוחסן.
✓
§164.528
דו״ח חשיפות
מי ראה מה ומתי — מוכן-לאימות בלחיצה.
◐חלקי · 3
◐
§164.312(d)
אימות אדם/ישות
דו-ערוצי (קישור+קוד) — אך אין SSO/SCIM ארגוני.
◐
GDPR Art. 9
נתוני בריאות מיוחדים
אמצעי-הגנה מחמירים — לא הבסיס החוקי (הסכמה).
◐
42 CFR §2.31
הסכמה לחשיפה
מוכיחים גישה תחת מדיניות מאושרת — לא מנהלים טפסים.
✕לא כלול · בגילוי מלא · 1
✕
§164.514(b)(2)
de-identification (Safe Harbor)
חוסמים AI מ-PHI מתמטית — אך לא מסירים 18 מזהים מהרשומה.