AI Compliance · אבטחה ובקרות

הנדסת אוטומציית AI מאובטחת

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

נכתב על ידי Vladimir Zhemerov

מנהל מוצר בכיר ומומחה AIO/GEOפורסם 2026-06-20

קטגוריה

AI compliance · אבטחה

זמן קריאה

17 דקות קריאה

פורסם

2026-06-20

עבור

CTOs, CISOs, COOs, מנהלי נתונים ובעלי אוטומציה

תשובה ישירה

אוטומציית AI מאובטחת דורשת ממשל, זרימות נתונים מבוקרות, הרשאות מוגבלות-היקף, אישור פעולה דטרמיניסטי, הערכה מול תרחישי כשל, וראיות תפעוליות לאורך כל ה-workflow — לא רק איכות מודל. אותן בקרות חלות על מערכות RAG, סוכני AI ואוטומציות ארגוניות: בעלים אחראי, אחזור מודע-ACL המכבד את זכאות הפונה, זהויות שירות ייעודיות בהיקף least-privilege, שערי אישור לפעולות בעלות השפעה גבוהה, בדיקות ניתנות-לחזרה מול prompt injection ו-agency עודף, וחבילת ראיות המורכבת תוך כדי בניית המערכת. מתוכננת בהתייחס ל-NIST AI RMF, NIST CSF 2.0, ISO/IEC 42001/27001/27701 והנחיות OWASP GenAI — התאמה שמתעדת איך נשקלו הבקרות, ונבדלת מהסמכה. כשהיא נבנית כך, אוטומציית AI יכולה לפעול על נתונים ארגוניים ולעמוד בסקירת אבטחה, ממשל וציות.

7שלבי אספקה

ממשל ← מיפוי ← מידול איומים ← בקרות ← הערכה ← ראיות ← ניטור

שרשרת אחת ניתנת-למעקב ממטרה עסקית ועד ראיה תפעולית.

5שכבות תפעוליות

קלט · החלטה · ידע · פעולה · פיקוח

הסיכון מצטבר בגבולות שביניהן.

8ראיות ליבה

דוסייה, מפת זרימת נתונים, מודל איומים, מרשם סיכונים, מודל גישה, הערכה, ניטור, פלייבוק תקריות

מורכבות תוך כדי בניית המערכת — לא אחרי תקרית.

4מסגרות ייחוס

NIST AI RMF · NIST CSF 2.0 · ISO/IEC 42001 / 27001 / 27701

OWASP GenAI Top 10 · MITRE ATLAS.

מודל בקרה למערכות שיכולות לאחזר ולפעול

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

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

01
קלט
בקשות משתמש, מסמכים, הודעות, דפי אינטרנט, טפסים ו-payloads של API.
02
החלטה
Prompts, לוגיקת תזמור, קריאות מודל, ניתוב והערכת מדיניות.
03
ידע
מסמכי מקור, מסדי נתונים, vector stores, מטא-דאטה ומסנני אחזור.
04
פעולה
עדכוני CRM, אימיילים, כרטיסים, תשלומים, טריגרים של workflow ובקשות API.
05
פיקוח
אימות, לוגים, הערכה, אישור, ניטור ותגובה לתקריות.

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

איור 01 — גבולות אמון באוטומציית AI

היכן נאכפים זהות, סינון, היקף ואישור

קלט בלתי-מהימן → פעולה מבוקרת

משתמש / תוכן חיצוני

Prompts, קבצים, דפי אינטרנט, אימיילים

זהות

מתזמר AI

Prompts, ניתוב, קריאות מודל

מסנן ACL

RAG / מאגר ידע

מסמכים, וקטורים, מטא-דאטה

token מוגבל-היקף

כלי CRM / אימייל / API

פעולות על מערכות תפעוליות

שער אישור

אישור אנושי

שער לפעולות בעלות השפעה גבוהה

סכמת פעולה

לוגים וניטור

ראיות ניתנות-לייחוס וניתנות-לשחזור

אירוע ביקורת

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

המסגרות שמאחורי מודל האספקה

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

NIST AI Risk Management Frameworkממבנה סיכוני AI סביב Govern, Map, Measure ו-Manage לאורך מחזור החיים.
NIST Cybersecurity Framework 2.0ממסגר תוצאות אבטחה דרך Govern, Identify, Protect, Detect, Respond ו-Recover.
ISO/IEC 42001:2023דרישות למערכת ניהול בינה מלאכותית — מדיניות, יעדים, הערכה ושיפור.
ISO/IEC 27001:2022בסיס מערכת-ניהול לניהול סיכוני אבטחת מידע.
ISO/IEC 27701:2025מוסיף שכבת ניהול-פרטיות לארגונים שמעבדים נתונים אישיים.
OWASP Top 10 for LLM Applicationsאיומים ברמת היישום: prompt injection, חשיפת מידע רגיש, טיפול לקוי בפלט, agency עודף וצריכה בלתי-מוגבלת.
MITRE ATLASמאגר ידע חי של טקטיקות וטכניקות יריב נגד מערכות מבוססות-AI.

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

איור 02 — מחזור חיי הבטחת-האיכות של Profitec AI

שבעה שלבים, כל אחד מעוגן במסגרת ייחוס

Govern עובר דרך כל שלב

01GovernNIST AI RMF
02MapISO 27001
03Threat modelMITRE ATLAS
04Build controlsOWASP GenAI
05EvaluateNIST GenAI Profile
06EvidenceISO 42001
07MonitorNIST CSF 2.0

תגי המסגרות הם תוויות טקסט, לא סימני הסמכה — הם מציינים איזה מקור מזין כל שלב.

מודל האספקה — שבעה שלבים

שלב 1

ביסוס בעלות, מטרה וגבולות סיכון

כל אספקה מתחילה בדוסייה של מערכת AI — מה המערכת אמורה לעשות, מי הבעלים שלה, איזה תהליך עסקי היא תומכת, אילו משתמשים מושפעים ואילו פעולות היא רשאית לבצע.

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

הסדנה הראשונה מפיקה:

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

ממופה אל Govern (NIST AI RMF), Govern (NIST CSF 2.0) ודרישות המדיניות והאחריותיות של ISO/IEC 42001.

תוצר

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

שלב 2

מיפוי נתונים, זהויות, אינטגרציות ומסלולי פעולה

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

עבור כל רכיב, אנו מתעדים:

קטגוריות נתונים, סיווג ורגישות;
נתונים אישיים, מידע עסקי חסוי ורשומות מוסדרות;
מקור הנתונים, מטרה חוקית, שמירה ומסלול מחיקה;
שיטת אימות, זהות שירות והרשאות מערכת-מקור;
ספק המודל, סביבת האירוח והגדרות אזוריות;
tenancy של vector-store, צינור embedding ומטא-דאטה של מסמכים;
APIs, webhooks, פלטפורמות אוטומציה ופעולות במורד הזרם;
יעדי logging, גישה ללוגים ושמירת טלמטריה.

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

שאלת התכנון

מהו מינימום הנתונים ומינימום ההרשאות הנדרשים כדי שהמערכת הזו תבצע את המשימה המוגדרת שלה?

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

ממופה אל Map (NIST AI RMF), Identify (NIST CSF 2.0), ניהול נכסים וסיכונים לפי ISO/IEC 27001, וניהול מידע פרטיות לפי ISO/IEC 27701.

תוצר

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

שלב 3

בניית מודל איומים ייחודי ל-AI

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

01
שחקן
תוקף חיצוני, מקורב זדוני, ספק שנפרץ, משתמש רגיל או התנהגות מערכת בלתי-מכוונת.
02
נקודת כניסה
Prompt, אימייל, קובץ שהועלה, דף אינטרנט, payload של API, מסמך מקור או אינטגרציה.
03
תנאי מקדים
הרשאה, שגיאת תצורה, מסנן חסר, plugin פגיע או מסלול נתונים בלתי-מבוקר.
04
נכס בסיכון
תוכן מקור, אישורי גישה, רשומות לקוח, שלמות החלטה, זמינות או ראיות ביקורת.
05
תוצאה
חשיפה, פעולה לא-מורשית, מניפולציה, שיבוש שירות, הפסד כספי או חשיפה רגולטורית.
06
בקרה וזיהוי
מניעה, טלמטריה, התראה ונוהל תגובה.

המודל צריך לכסות prompt injection ישיר ועקיף — שבו LLM מעבד תוכן חיצוני, כגון אתר או קובץ, והתוכן הזה משנה את התנהגות המודל. ב-workflow ארגוני זה יכול להגיע דרך אימייל של ספק, PDF בכונן משותף, כרטיס תמיכה או דף אינטרנט שאוחזר.

הוא צריך גם לבחון agency עודף, ששלוש סיבותיו החוזרות הן פונקציונליות עודפת, הרשאות עודפות ואוטונומיה עודפת. סוכן שקיבל זהות גנרית בעלת הרשאות גבוהות או יכולת “הרצת פקודה” פתוחה נושא רדיוס-נזק רחב יותר ממה שמטרתו העסקית דורשת. MITRE ATLAS מספק אוצר-מילים מובנה לטקטיקות יריב, תומך בעיצוב תרחישי red-team ומחבר איומי AI לתפעול אבטחה מוכר.

ממופה אל Measure (NIST AI RMF), איומי היישום של OWASP LLM Top 10 וטכניקות היריב של MITRE ATLAS.

תוצר

מודל איומי AI ו-backlog בקרות — כל תרחיש נושא דירוג סבירוּת והשפעה, בעלים אחראי, בקרת יעד, עדיפות יישום ושיטת אימות. תרחישים בסיכון גבוה נשארים גלויים אחרי ההשקה במרשם הסיכונים ובתוכנית הניטור.

שלב 4

יישום בקרות בגבולות האמון

הבקרות המשמעותיות ביותר יושבות מחוץ למודל. הן קובעות אילו נתונים מגיעים למודל, אילו הרשאות הוא מקבל ואילו פעולות יכולות לעבור למערכות תפעוליות.

01
אחזור עם הקשר הגישה של הפונה
מערכות RAG מחילות את הזהות, התפקיד, הארגון וזכאות המסמך של המשתמש לפני שתוכן מגיע למודל. סינון מטא-דאטה נאכף במסלול האחזור, עם תוצאת דחייה נבדקת עבור תוכן בלתי-מורשה. מסד נתונים וקטורי מאיץ חיפוש סמנטי; הוא אינו מחליף את מודל הגישה של מערכת המקור.
02
זהויות ייעודיות והרשאות מינימליות הכרחיות
כל סוכן ואינטגרציה משתמשים בזהות שירות נפרדת עם היקפים מוגבלי-מטרה. פונקציות קריאה, כתיבה, מחיקה, ייצוא וניהול מופרדות בכל מקום שהתהליך מאפשר. tokens פגי-תוקף, אחסון סודות מאובטח, סקירות הרשאות ומלאי אינטגרציות מונעים מ-workflow לרשת גישה רחבה וקבועה.
03
בקרות פעולה דטרמיניסטיות
Prompt יכול להנחות התנהגות; ההרשאה נאכפת באמצעות קוד יישום, מנועי מדיניות, שערי API וחוזי כלים. לשכבת הפעולה יש סכמה מוגדרת, פרמטרים מאומתים ומסלולי דחייה מפורשים.
04
טיפול בקלט, פלט ואינטגרציה
תוכן חיצוני — אימיילים, מסמכים, דפי אינטרנט ותגובות צד-שלישי — מטופל כקלט בלתי-מהימן. נתונים שמועברים במורד הזרם דורשים אימות פלט, קידוד הקשרי וסכמות כלים מחמירות. פלט מודל בצורה חופשית לעולם אינו מועבר ישירות להרצת קוד, הרצת שאילתות או בקשות API בעלות השפעה גבוהה.
05
נצפוּת ויכולת-ביקורת
כל אירוע משמעותי ניתן לייחוס למשתמש, זהות שירות, תצורת מודל וגרסת workflow. ראיות הופכות שימושיות כשהן מחברות את הבקשה, המקורות שאוחזרו, הכלי שנבחר, החלטת המדיניות, הפעולה הסופית והתוצאה.

עבור פעולות בעלות השפעה גבוהה ה-workflow דורש אחת או יותר מ:

אישור משתמש
אישור מבוסס-תפקיד
אימות דטרמיניסטי שני
תקרת עסקה
תור סקירה
הרשאה מוגבלת-בזמן
מצב dry-run או טיוטה

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

ממופה אל Protect (NIST CSF 2.0), בקרות אבטחת המידע של ISO/IEC 27001 והנחיות OWASP ליישומי agentic. עקרון zero-trust: אימות והרשאה מטופלים כפונקציות נפרדות לפני שגישה למשאב מתבססת — מה שחל ישירות על סוכני AI וקריאות הכלים שלהם.

תוצר

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

איור 03 — מ-prompt ועד פעולה מבוקרת

פלט המודל מגיע למערכות תפעוליות רק דרך שערים דטרמיניסטיים

source

פלט מודל

פעולה ישירה בעלת השפעה גבוהה — חסומה

gate

אימות מדיניות

פעולה מותרת לפונה הזה?

gate

אימות סכמת כלי

פרמטרים מוקלדים, גבולות נבדקים

gate

שער אישור

אישור / הסלמה לפי השפעה

out

מערכת במורד הזרם

CRM, תשלום, הודעה, כרטיס

out

לוג ביקורת

בקשה, החלטה, פעולה, תוצאה

המודל מציע; שכבות דטרמיניסטיות מחליטות. אף פלט בצורה חופשית אינו מגיע ישירות למערכת בעלת השפעה גבוהה.

שלב 5

הערכת המערכת מול תרחישי כשל

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

תחום בדיקהמה הבדיקה מאמתת

Prompt injectionהמערכת עומדת בניסיונות להפנות מחדש הוראות דרך קלטים ישירים ותוכן שאוחזר.
הרשאת אחזורמשתמשים מקבלים רק תוכן המותר לפי זכאותם במערכת-המקור.
בטיחות כליםהמודל אינו יכול להפעיל כלים בלתי-מאושרים, להעביר פרמטרים בלתי-תקפים או לחרוג מהסמכות שהואצלה.
אישור פעולהפעולות בעלות השפעה גבוהה עוצרות, מסלימות או נכשלות באופן בטוח לפי מטריצת האישורים.
שלמות פלטפלטים מובנים תואמים לסכמה ומערכות במורד הזרם דוחות נתונים לא-בטוחים או פגומים.
רגרסיית שינוישינויי מודל, prompt, מחבר ומדיניות משמרים את בקרות האבטחה והעסק הקודמות.
זמינות ועלותמגבלות קצב, timeouts, מדיניות retry ומגבלות תקציב מונעות צריכה בלתי-מבוקרת.
איכות ראיותלוגים ו-traces מאפשרים לסוקר מורשה לשחזר פעולות משמעותיות.

הבדיקות ניתנות לחזרה. קורפוס prompt-injection, חבילת בדיקות הרשאות וסימולציית פעולה רצים בכל פעם שרכיב בעל השפעה גבוהה משתנה — ומסגור מחזור החיים של GenAI מעודד לשקול דרישות משפטיות ורגולטוריות, סובלנות סיכון ומגבלות משאבים.

ממופה אל Measure ו-Manage (NIST AI RMF), ה-NIST Generative AI Profile והערכת הביצועים של ISO/IEC 42001.

תוצר

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

שלב 6

הרכבת ראיות תוך כדי בניית המערכת

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

איור 04 — חבילת ראיות ל-AI ארגוני

שמונה תוצרים מורכבים תוך כדי בניית המערכת

01
דוסייה של מערכת AI
מטרה, בעלות, פעולות מותרות, מחלקת סיכון
02
מפת זרימת נתונים
היכן נתונים נכנסים, נעים, נשמרים, מי יכול לפעול
03
מודל איומים
תרחישים, סבירות, השפעה, מסלול בקרה
04
מרשם סיכונים
סיכונים פתוחים, בעלים, טיפול, סיכון שיורי
05
מודל גישה
זהויות, היקפים, זכאות, מטריצת אישורים
06
דוח הערכה
כיסוי, ממצאים, תיקון, קבלה
07
תוכנית ניטור
אותות, קריטריוני התראה, קצב סקירה
08
פלייבוק תקריות
להשעות, לבודד, לבטל, לשמר, להתאושש

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

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

ממופה אל נוהלי מערכת-הניהול של ISO/IEC 42001, ניהול אבטחת המידע של ISO/IEC 27001 ואחריותיות הפרטיות של ISO/IEC 27701.

תוצר

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

שלב 7

ניטור, תגובה והתאוששות

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

אותות ניטור שימושיים כוללים:

נפח קריאות-כלים חריג או בדיקות מדיניות שנכשלו
ניסיונות לגשת לתוכן מוגבל
בקשות אישור שנדחו
שינויי הרשאות בלתי-צפויים
אנומליות בקליטת מסמכי מקור
שינויים בדפוסי אחזור
עלייה בשיעורי שגיאה, timeout או retry
חסימות פלט בלתי-בטוח חוזרות
שינויי גרסת מודל, prompt ו-workflow
תלונות לקוחות או הסלמות משתמש מהותיות

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

ממופה אל Detect, Respond ו-Recover (NIST CSF 2.0) והשיפור המתמשך של ISO/IEC 42001.

תוצר

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

סיכונים נסתרים ששורדים לעיתים קרובות הדגמה מוצלחת

workflow יכול לעבור הדגמת מוצר ועדיין לשאת את הסיכונים שלהלן. כל אחד מהם יושב בגבול אמון שההדגמה מעולם לא בחנה.

לוח סיכונים

#סיכוןחשיפהבקרה

01Prompt injectionחשיפה · תוכן מהימן הופך לערוץ הוראות — אימייל, מסמך או דף שאוחזר מפנה מחדש את המודל.בקרה · הפרדת הוראה–נתונים, בקרות קלט, הגבלות כלים, בדיקות יריב.
02Agency עודףחשיפה · חשבון שירות רחב הופך לסמכות האמיתית של הסוכן על כל החלטת מודל.בקרה · זהויות ייעודיות, הרשאות API מוגבלות-היקף, allowlists של כלים, שערי אישור.
03דליפת אחזורחשיפה · מאגר ידע מערבב מודלי הרשאות ומשתמש רואה חומר בלתי-מורשה.בקרה · אחזור מודע-ACL הנאכף בזמן השאילתה, עם בדיקות וטלמטריה משלו.
04פלט להרצהחשיפה · תגובת מודל נצרכת ישירות על ידי מריץ workflow, שכבת SQL או כלי הודעות.בקרה · סכמות מוקלדות, אימות, חוקים עסקיים, מסלולי אישור עצמאיים.
05תצורת ספקחשיפה · ספק, endpoint, מדיניות שימוש-בנתונים, residency, שמירה ותת-מעבדים מסיטים את משטח הסיכון.בקרה · סקירת ספק ניתנת-לחזרה ותהליך ניטור-שינויים.
06פער ראיותחשיפה · המערכת עובדת עבור המשתמש אך פעולה אינה ניתנת לשחזור בדיעבד.בקרה · תיעוד גרסאות, traces של מקורות, לוגי החלטת-מדיניות ופעולה.
07שינוי מבטל את ההבטחהחשיפה · מודל חדש, סכמת כלי, אוסף מקורות או הרשאה משנים התנהגות.בקרה · בדיקות רגרסיה ומסלול אישור פרופורציונלי להשפעת השינוי.

אין כרטיסי אזהרה אדומים — אלה גבולות הנדסיים, לכל אחד בקרה מוגדרת, לא אזעקות.

הקשר פרטיות ורגולציה

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

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

איך נראית אספקת אוטומציית AI בשלה

לפרויקט אוטומציית AI בשל יש שרשרת ניתנת-למעקב מדרישה עסקית ועד בקרה מיושמת:

מטרה עסקית → היקף מערכת → מפת נתונים והרשאות → תרחיש איום → בקרת ארכיטקטורה → מקרה בדיקה → ראיה תפעולית → ניטור וסקירה.

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

איך Profitec AI ניגשת לזה

שכבת הוכחה הנדסית מתחת להצעת ה-AI Compliance

מודל אספקה זה הוא השכבה ההנדסית מתחת להצעה המסחרית. שירות ה-AI Compliance ממפה מקרי שימוש, חשיפת נתונים, משטחי פעולה ופערי בקרה; עמוד האבטחה והבקרות מתעד גישה ברמת least-privilege, שערי אישור, לוגי ביקורת, סודות ו-kill switches. מאמר זה הוא ההוכחה ברמת הארכיטקטורה שמתחת לשניהם.

מערכות מתוכננות בהתייחס ל-NIST AI RMF, ISO/IEC 42001, ISO/IEC 27001 והנחיות OWASP GenAI — התאמה שמתעדת איך נשקלו בקרות ממשל, אבטחה וסיכון, ונבדלת מהסמכה רשמית או מקביעת ציות משפטית.

AI Compliance וממשל אבטחה ובקרות

אוטומציית AI מאובטחת — שאלות נפוצות

האם RAG מסיר את סיכון ה-prompt injection?

לא. RAG יכול לשפר את הגישה למידע רלוונטי, אבל OWASP קובע ש-RAG ו-fine-tuning אינם ממתנים במלואם פגיעויות prompt injection. תוכן שאוחזר דורש את אותו טיפול בגבול-אמון כמו כל קלט חיצוני אחר — הפרדת הוראה–נתונים, בקרות קלט, הגבלות כלים ובדיקות יריב.

האם כל סוכן AI צריך אישור אנושי?

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

האם system prompt יכול לאכוף בקרת גישה?

לא. בקרת גישה שייכת לשכבות דטרמיניסטיות — ספקי זהות, קוד יישום, מנועי מדיניות, שערי API והרשאות מערכת-מקור. system prompt יכול לבטא כללי התנהגות; הוא אינו יכול להחליף גבול הרשאה.

האם התאמה ל-NIST, ISO או OWASP אומרת שהמערכת מוסמכת או תואמת משפטית?

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

מתי ארגון צריך לסקור שוב את ארכיטקטורת ה-AI?

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

להתחיל כאן

להתחיל ב-AI Compliance Quick Scan

Profitec AI ממפה מקרי שימוש של AI, חשיפת נתונים, משטחי פעולה ופערי בקרה מיידיים לפני פרודקשן. התוצאה היא תוכנית מתועדפת לממשל, בקרות אבטחה, הערכה וראיות — אותה שרשרת שתוארה לעיל, מיושמת על workflows של AI Compliance שלכם.

לחקור AI Compliance וממשל לבקש סקירת workflow לצפות באבטחה ובקרות

תקנים וחומר מקור

תקנים חיצוניים נפתחים בלשונית חדשה. מובאים לצורך מעקב ואימות — התאמה למקורות אלה מתעדת איך נשקלו הבקרות ואינה מהווה כשלעצמה הסמכה או קביעת ציות משפטית.

קריאה קשורה

על המאמר הזה

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