ביקורת ארכיטקטורה — מערכות AI / LLM

למי זה מתאים

• מייסדים ו-CTOים שמתכננים לשלב פיצ\'ר AI במוצר ייצור — לפני שמשלמים בהפסד אמון לקוחות על תוצר שגוי.
• יועצים משפטיים פנימיים שצריכים להעריך חשיפה משפטית של מערכת AI קיימת — לפני שמשקיעים, לקוחות, או רגולטור יבחנו אותה.
• עורכי דין בתיק AI — סכסוך משפטי שהליבה שלו היא תוצר של LLM (החלטה מוטעית, ייעוץ שגוי, פגיעה בזכויות יוצרים, פליטת נתונים).

מה הביקורת כוללת

1. מבנה השכבות. איך הקריאות ל-LLM מתבצעות, איפה ה-orchestration יושב, איך הקלט מסונן, איך הפלט נבדק לפני שמוצג למשתמש. מערכות שעובדות כצינור פתוח ישירות אל מודל — בעיתיות.
2. הסיכון: Prompt injection וגרירת נתונים. אם המודל ניגש לכלים פנימיים (RAG, function-calling, agent loops), כל כניסת משתמש היא וקטור תקיפה פוטנציאלי. הביקורת בודקת איזה גבולות הוצבו, אילו לא, ומה האפקט אם הם נפרצים.
3. הסיכון: Hallucination ואחריות משפטית. כשהמודל ממציא — מי אחראי? הביקורת בודקת אם יש שכבת validation, אם יש disclosure למשתמש שמודיע שהפלט הוא AI, ואם יש לוג שמאפשר לשחזר מה המודל אמר ומתי.
4. חשיפת IP בנתוני אימון. Fine-tuning על נתוני לקוחות, או על דאטהסט ציבורי שהיה ב-AI training cutoff — שני סיכונים משפטיים שונים. הביקורת ממפה את שניהם.
5. Vendor lock-in וניוד. מה קורה אם OpenAI מעלה מחיר פי 3, או אם Anthropic משנה את מודל ה-API breaking? מערכת שלא ניתנת להחלפת ספק בתוך 14 יום — תיק עסקי בעייתי.
6. Eval harness. איך אתם יודעים שהמודל לא רגרס אחרי כל שינוי ב-prompt? מערכת ייצור AI ללא eval harness היא מערכת שמשנים אותה בעצימת עיניים.

פורמט המעורבות

ביקורת חד־פעמית של שבועיים. שבוע ראשון: עיון בקוד, בארכיטקטורה, ובמסמכי ה-prompt; ראיון של מהנדס הראשי. שבוע שני: כתיבת מסמך מסקנות (12-20 עמודים) עם המלצות ממוספרות לפי דחיפות. כולל סבב תיקון אחד והשתתפות באחת ישיבת מנהלים להצגת הממצאים.

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

מתי זה לא מתאים

• כאשר המוצר עדיין בשלב פרוטוטייפ ולא ייצור — אז ביקורת היא בזבוז זמן, החזרה להחלטות תכנון פתוחות עדיפה.
• כאשר נדרשת בדיקת המודל עצמו (האם GPT-5 מדויק יותר מ-Claude Opus 4.7 על משימה X). זה תפקיד של תיק eval / bench mark, לא ביקורת ארכיטקטורה.
• כאשר השאלה היא רגולטורית טהורה (AI Act באירופה, AI HHS באמריקה). שם נדרש עורך דין שמתמחה ברגולציה, לא מומחה תוכנה.

תמחור

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

שאלות נפוצות

מתי כדאי לעשות ביקורת ארכיטקטורה ל-AI / LLM?

לפני שילוב פיצ\'ר AI במוצר ייצור, לפני סבב גיוס שבו משקיעים יבדקו את הגישה, לפני החלפת ספק LLM, וכאשר עולה אירוע (hallucination, prompt injection, חריגת עלות) שצריך לחקור.

מה כלול בביקורת?

בחינת הארכיטקטורה, זיהוי וקטורי תקיפה (prompt injection, data exfiltration), הערכת אחריות משפטית במקרה של hallucination, ניתוח חשיפת IP בנתוני אימון, מסמך מסקנות עם המלצות מסודרות.

האם נדרשת חוות דעת AI לבית משפט?

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

האם הביקורת כוללת בדיקת הספק (OpenAI / Anthropic / Google)?

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