*מאת צוות הפורנזיקה הטכנולוגית וארכיטקטורת ה-AI של ContextHint*
תמצית מנהלים (Executive Summary)
בניהול סכסוכים משפטיים המעורבים ב-AI יוצר (Generative AI), סוכנים אוטונומיים (Autonomous Agents) או מודלי שפה ארגוניים (LLMs), בקשות גילוי מסמכים (eDiscovery) מסורתיות נכשלות. דרישת "קוד מקור" (Source Code) או "תכתובות אימייל בין מפתחים" אינה מספקת כמעט שום ראייה או תובנה לגבי הסיבה לכך שמערכת הסתברותית ייצרה פלט מסוים, הפרה חוזה או הדליפה מידע מוגן.
יישום המבוסס על LLM אינו הרצת קוד סטטי דטרמיניסטי. זוהי מערכת דינמית, מרובת שכבות ולא-דטרמיניסטית המורכבת בהקשר בזמן ריצה (Runtime Context), אינדקסים וקטוריים, אורקסטרציית פרומפטים ותצורות פרמטרים.
מדריך זה מספק מסגרת גילוי בת 6 שכבות (6-Layer LLM Discovery Framework) עבור שותפי ליטיגציה, עורכי דין לקניין רוחני (IP) ויועצים משפטיים ראשיים (General Counsels). המדריך מפרט את ה-Data Artifacts המדויקים שעלייך לדרוש בבקשות גילוי מסמכים – או להגן עליהם במסגרת היערכות להגנה – כדי להוכיח או להפריך טענות בדבר רשלנות אלגוריתמית, חבות מוצר והפרת חובת זהירות.
מטריצת גילוי מנהלים (Executive Discovery Matrix)
| שכבה | רכיב המערכת | Data Artifacts קריטיים לדרישה | יעד משפטי מרכזי |
|---|---|---|---|
| שכבה 1 | ארכיטקטורת Prompt | היסטוריית גרסאות של System Prompt, תבניות בהקשר דינמי, Metaprompts | הוכחת כוונת גבולות המערכת, הנחיות הגנה מפורשות, או רשלנות מבנית. |
| שכבה 2 | צינור RAG ו-Vector DB | Snapshots וקטוריים, מדדי מרחק דמיון (Similarity Distance), Chunks שנשלפו ב-Top-K | קביעה האם ה"הזיה" נגרמה כתוצאה מכשל בשליפת המידע הפנימי. |
| שכבה 3 | היפר-פרמטרים בזמן ריצה | לוגים של Temperature, Top-P, נקודות ביקורת מדויקות של המודל (gpt-4o-2024-08-06) | הוכחה שהמערכת הוגדרה לאקראיות גבוהה בסביבה קריטית. |
| שכבה 4 | ריצה מרובת סוכנים | גרף ביצועים / לוגי DAG, Payloads בין סוכנים, טלמטריית קריאות לכלים (Tool-Calling) | מיפוי הנתיב הפורנזי של כשלים שרשרתיים בסוכנים אוטונומיים. |
| שכבה 5 | מעקות בטיחות (Guardrails) | לוגים של קריאות ל-Moderation API, טלמטריית NeMo/Llama Guard, טריגרים של Fallback | הערכת הציות לתקן חובת הזהירות (Standard of Care) ופרוטוקולי בטיחות. |
| שכבה 6 | טלמטריית Payloads מלאה | JSON Payloads גולמיים של בקשות/תגובות API, צריכת טוקנים, חותמות זמן של המערכת | שחזור מצב ריצת המערכת המדויק בזמן האירוע. |
מסגרת גילוי המסמכים ב-6 שכבות (The 6-Layer LLM Discovery Framework)
שכבה 1: ארכיטקטורת Prompt וניהול גרסאות
השאלה המשפטית המרכזית: *אילו הנחיות מפורשות, מגבלות והקשרים הוטלו על המודל במאיות השנייה המדויקות של הביצוע?*
בליטיגציית תוכנה מסורתית, בקשות גילוי מסמכים דורשות קוד מקור בר-ביצוע. אך במערכות LLM, ה-System Prompt משמש כ"היגיון העסקי" (Business Logic) וכגבול התפעולי של התוכנה.
Artifacts שחובה לדרוש:
- היסטוריית שינויים ב-System Prompt: לוגים מלאים ממערכת ניהול הגרסאות (Git) המציגים עדכונים, שינויים וביטולי גרסאות של ה-System Prompt סביב תאריך האירוע.
- תבניות הקשר דינמיות (Dynamic Context Templates): התבניות המבניות המשמשות להזרקת נתוני משתמש, משתנים והקשר חיצוני לתוך מחרוזת הפרומפט לפני שהיא מגיעה למודל.
- Metaprompts ועקיפות מערכת: הנחיות מוסתרות המעטפות את בקשת המשתמש, כולל פרומפטים לאכיפת מדיניות ארגונית.
שכבה 2: צינור RAG ומצב האינדקס הווקטורי
השאלה המשפטית המרכזית: *האם המודל יצר הזיה (Hallucination) מאי-שם, או שמא הוגש לו הקשר שגוי, חסר או פגום על ידי מערכת השליפה הפנימית?*
שליפה מועשרת ביצירה (RAG) היא הארכיטקטורה העיקרית בשימוש באפליקציות ארגוניות מודרניות. אם עוזר AI מספק ייעוץ רפואי שגוי או תנאים פיננסיים מוטעים, האחריות בדרך כלל עוברת מספק המודל הבסיסי (כמו OpenAI) אל צינור ה-RAG שמימשה החברה.
Artifacts שחובה לדרוש:
- Snapshots של בסיס הנתונים הווקטורי: יצוא נקודת-זמן של ה-Vector Database (Pinecone, Qdrant, Milvus, Chroma) כדי לנתח את הרכב האינדקס נכון למועד הסכסוך.
- מדדי מרחק ודמיון של Top-K: ציונים מוקלטים (כגון Cosine Similarity, Euclidean Distance) המראים עד כמה הקטעים שנשלפו (Chunks) היו קרובים לשאילתת הפרומפט.
- מפרטי אסטרטגיית הניתוח והחיתוך (Chunking & Parsing): תיעוד וקוד המגדירים את גודל ה-Chunks, אחוזי החפיפה (Overlap) ומבנה תגיות ה-Metadata.
שכבה 3: היפר-פרמטרים בזמן ריצה ותצורת המודל
השאלה המשפטית המרכזית: *האם האלגוריתם הוגדר באופן מכוון או רשלני כדי למקסם "יצירתיות" על חשבון דיוק בתחום תפעולי בעל סיכון גבוה?*
LLMs הם ביסודם מנועים הסתברותיים. מערכת המוגדרת עם ערך temperature (טמפרטורה) גבוה תבחר באופן מכוון בטוקנים בעלי הסתברות נמוכה יותר, מה שיוביל לתפוקות יצירתיות – ופוטנציאלית לא מדויקות.
Artifacts שחובה לדרוש:
- היפר-פרמטרים של הסקת מסקנות (Inference): ערכים ספצificיים שהוגדרו עבור
temperature,top_p,presence_penaltyו-frequency_penalty. - מזהי נקודת ביקורת מדויקים של המודל (Model Checkpoints): מחרוזות הפריסה המדויקות בשימוש בקריאת ה-API (למשל
gpt-4o-2024-08-06ולא סתם "GPT-4"). - הגדרות הפרמטר Seed: לוגים של ה-Seed ששימשו בסביבות בדיקה דטרמיניסטיות, במידה וקיימים.
שכבה 4: נתיבי הרצה מרובי סוכנים ו-Directed Acyclic Graphs (DAGs)
השאלה המשפטית המרכזית: *במערכת מרובת סוכנים, איזה סוכן יזם את הפעולה המזיקה, ואיפה נכשלו בדיקות הגבולות?*
ארכיטקטורות ארגוניות מודרניות מסתמכות יותר ויותר על סביבות עבודה של סוכנים אוטונומיים (כמו LangChain, AutoGen או CrewAI). כשרשת סוכנים מבצעת העברה בנקאית לא מורשית או משחררת נתונים קנייניים, ביסוס קשר סיבתי דורש מיפוי של גרף הביצוע.
Artifacts שחובה לדרוש:
- טלמטריית גרף ביצועים / DAG: לוגים מבניים הממפים תלויות בין סוכנים, סדר הפעלה וצומתי החלטה.
- Payloads של תקשורת בין-סוכנים: תנועת ההודעות הפנימית המלאה שהועברה בין סוכנים אוטונומיים לפני האירוע.
- טלמטריית קריאה לכלים/פונקציות (Tool/Function Calling): חתימות קריאות API, פרמטרים ו-Payloads של תגובות שהונפקו על ידי סוכנים למאגרי נתונים חיצוניים או לממשקי תוכנה.
שכבה 5: מעקות בטיחות (Safety Guardrails) וטלמטריית ניטור
השאלה המשפטית המרכזית: *האם המפתח הטמיע מעקות בטיחות המקובלים בתעשייה (חובת זהירות), והאם מנגנונים אלו הופעלו, נכשלו או נעקפו באופן מכוון?*
הוכחת רשלנות דורשת השוואה מול פרקטיקות מקובלות בתעשייה. הצגה כי מפתח השמיט מעקות בטיחות בסיסיים או התעלם מדגלי ניטור (Moderation) מהווה ראיית מפתח בהוכחת הפרת חובת הזהירות.
Artifacts שחובה לדרוש:
- לוגים של ניטור קלט/פלט (Moderation Logs): לוגים גולמיים מסווגי בטיחות (כגון OpenAI Moderation API, NeMo Guardrails, Llama Guard) המראים האם פרומפטים או תגובות סומנו כבעלי סיכון.
- לוגים של הגנת Prompt Injection: לוגים של ביקורת המעקבים אחר ניסיונות Jailbreak שנזכרו או חתימות Indirect Prompt Injection.
- קוד חריגות Fallback: קטעי קוד ולוגים המאמתים את נהלי ה-Fallback כאשר מעקות הבטיחות הופעלו.
שכבה 6: טלמטריית API Payload גולמית (האמת העובדתית)
השאלה המשפטית המרכזית: *איזה החלפת נתונים מדויקת התרחשה בין האפליקציה הארגונית לבין מנוע ההסקה (Inference Engine)?*
ה-JSON Payload הגולמי הוא מקור האמת היחיד בליטיגציית LLM. הוא קושר יחד את ה-System Prompt, תצורת ההיפר-פרמטרים בזמן ריצה, קלט המשתמש וההקשר שנשלף לכדי רשומה אחת בודדת.
Artifacts שחובה לדרוש:
- JSON Payloads גולמיים של בקשות ותגובות: לוגים ללא שינוי של ה-API Catch לוקחים את המצב המלא של חלון השיחה ברגע הביצוע המדויק.
דוגמת JSON Payload פורנזית:
{
"timestamp": "2026-10-12T14:22:01.402Z",
"request_id": "req_01j8m49z2x3p9a7v6b1c8d",
"model": "gpt-4o-2024-08-06",
"hyperparameters": {
"temperature": 0.85,
"top_p": 1.0,
"max_tokens": 1024
},
"system_prompt_version": "v3.4.1-enterprise",
"messages": [
{
"role": "system",
"content": "אתה עוזר יועץ פיננסי. ספק תשובות מדויקות בהתבסס אך ורק על ההקשר שנשלף."
},
{
"role": "user",
"content": "מהו הקנס על משיכה מוקדמת בחשבון מסוג B?"
},
{
"role": "assistant",
"content": "הקשר שנשלף: [Chunk_ID: 9842, Similarity: 0.61] 'בחור חשבון מסוג B אין עמלת משיכה מוקדמת.'"
}
],
"response": {
"choices": [
{
"message": {
"role": "assistant",
"content": "אין קנס על משיכה מוקדמת בחשבון מסוג B."
},
"finish_reason": "stop"
}
]
},
"guardrail_telemetry": {
"input_flagged": false,
"output_flagged": false,
"confidence_score": 0.61
}
}תובנה פורנזית: *שים לב כיצד ה-Payload חושף ציון דמיון וקטורי נמוך (
0.61) המשולב עם Temperature גבוהה ולא מתאימה (0.85) עבור מתן ייעוץ פיננסי. הדבר מדגים כיצד נתונים משכבה 2, שכבה 3 ושכבה 6 מצטלבים כדי להוכיח רשלנות תפעולית.*
תבניות בקשת גילוי מסמכים מעשיות (Court-Ready Templates)
כדי לסייע לצוותים המשפטיים בניסוח בקשות ממוקדות, להלן נוסחים מוכנים להגשה בבית משפט עבור סכסוכי AI יוצר:
בקשה לגילוי מסמכים: RAG והקשר המערכת
*"כל תבניות ה-System Prompt, סכמות הזרקת ההקשר הדינמיות, Snapshots של בסיסי נתונים וקטוריים, אלגוריתמי ה-Chunking, תצורות סף הדמיון, ו-JSON Payloads גולמיים של בקשות ותגובות API המשוייכים לרכיב מערכת ה-AI [שם רכיב/Feature] במהלך התקופה שבין [תאריך] ל-[תאריך]."*
בקשה לגילוי מסמכים: היפר-פרמטרים ומצב המודל
*"כל לוגי התצורה, פרמטרי הפריסה, הגדרות זמן הריצה (כולל אך לא רק הגדרות Temperature, Top-P ו-Frequency Penalty), ומזהי נקודות הביקורת של המודל (Model Checkpoints) שהיו בשימוש בסביבת הייצור עבור [שם האפליקציה] בתאריך האירוע [תאריך מדויק]."*
סיכום וצעדים מעשיים לצוותים משפטיים
ניהול ליטיגציה בתחום ה-AI היוצר דורש מעבר מטענות כלליות על "טכנולוגיה בלתי צפויה" לבחינת הבחירות ההנדסיות שנעשו מאחורי המערכת.
- אל תסכימו לקבל היצף קוד מקור גנרי. דרשו את ה-Artifacts המפורטים ב-6 השכבות לעיל.
- שמרו על מצבי ריצה מוקדם ככל הניתן. אינדקסים וקטוריים והיסטוריית פרומפטים משתנים במהירות. מכתבי התראה על שיבוש ראיות (Spoliation Letters) חייבים לציין במפורש Snapshots של Vector DB ולוגים של API Payloads.
- שלבו מומחי פורנזיקת AI בשלב מוקדם. ניתוח מטריצות דמיון, DAGs של ביצועים ו-JSONs של Payloads דורש מומחיות טכנית עמוקה.
זקוקים לסיוע מומחה בליטיגציית AI או פורנזיקה?
ב-ContextHint, אנו מסייעים לצוותים משפטיים, שותפי ליטיגציה ויועצים משפטיים של חברות לנווט בסכסוכי AI מורכבים, לבצע ביקורת (Audit) לארכיטקטורת LLM ולהכין חוות דעת מומחה עמידות לבית המשפט.