אוטומציה של ביקורת ציות: מערכת RAG עם ניטור שינויים

פיתוח AI לצורכי ציות: היכן נשברת ביקורת ידנית

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

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

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

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

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

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

תוצאות האוטומציה: מהירות תגובה ושלמות הבדיקות

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

• חלון התגובה לשינוי בדרישה — משבועות לשעות: המערכת עוקבת אחר מקורות חיצוניים כגון ConsultantPlus ותקנות פנימיות, מסמנת מסמכים שנפגעו ומעבירה אותם לבדיקה מחדש.
• שלמות הבדיקות מפסיקה להיות תלויה ביתרת הזמן: לבדיקה הראשונית נכנס מכלול המסמכים, ולא מדגם שהספיקו לסרוק בעין. סעיפים שנפלו מוצגים בדוח נפרד.
• יכולת שחזור החלטות: אותו קלט מניב אותה תוצאה עם הפניה לסעיף דרישה מסוים. הוויכוח «למה כך» מוסר באמצעות ציטוט מהמקור הראשוני, ולא מזיכרון הבודק.
• צמצום העבודה הידנית: השוואת נוסחים וניתוח בלוקים מאותו סוג נלקחים על ידי האוטומציה; למומחה נשארים מקרי גבול ופרשנויות שנויות במחלוקת, שבהם נדרשת מומחיות.
• סוג כשלים שהוסר: בדיקה לפי נוסח מיושן, עדכון תקנה שהוחמץ, החלטה בלי בסיס — כשלים אלה מפסיקים להיות אפשריים ברמת התהליך, ולא בזכות ערנות העובד.

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

מצבי הפעולה של מערכת הבדיקה: השוואת גישות

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

מדוע במעגל העבודה נשארת לרוב הגישה ההיברידית

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

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

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

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

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

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

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

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

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

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

מה מועבר לידיים: קונפיגורציות, תקנונים, תיעוד

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

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

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

מקרה בוחן: בדיקת חוזים ותקנות פנימיות

איך נראתה העבודה לפני

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

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

מה שינו

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

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

מה קרה למדדים

אותה מנה של 400 חוזים עוברת בדיקה ביומיים במקום שלושה שבועות. שיעור הפערים בין הבודקים ירד מ-18% ל-4%: סעיפים שנויים במחלוקת מסומנים באופן זהה, והניתוח מתבצע רק על תנאים שבאמת אינם חד-משמעיים.

כיסוי — 100% מהסעיפים במקום מדגם ידני, ועם זאת עורך הדין משקיע זמן ב-10–15 מקומות שנויים במחלוקת, ולא בקריאת המסמך כולו.

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

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

הכול נשבר על שונות השפה: «אנו חייבים לשמור ולעבד נתונים» ו«המידע מעובד בהסכמת נושא הנתונים» — אותה דרישה, אבל אף כלל לא יתפוס אותה, בעוד שלילות והומונימיה יוצרים הפעלות כוזבות.

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

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

ספקות טכניים שאנו מסירים לפני ההתחלה

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

מה מבטיח שהמערכת אינה ממציאה תקנות?

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

הרגולציה משתנה — מה עם האינדקס?

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

כמה נתונים דרושים להערכה?

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

מה עם האחריות לאחר המסירה?

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

נדון במשימה: מה דרוש להערכה ולתוכנית עבודה

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

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

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