חילוץ נתונים מחוזים באמצעות בינה מלאכותית: מערכת לעורכי דין

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

חילוץ נתונים מחוזים: היכן נשברת הבדיקה הידנית

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

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

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

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

מה נותנת המערכת: לוחות זמנים, שלמות, שגיאות שנמנעו

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

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

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

אפשרויות בנייה: שירות ענן, מתחם סגור, היברידי

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

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

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

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

כיצד הסכימה משתנה עם הזמן

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

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

כיצד מתבצעת ההטמעה: מביקורת המערך ועד המסירה

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

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

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

מה עורך הדין מקבל לידיו: מרשם חוזים וכללי פירוק

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

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

מקרה בוחן: כיצד צומצם הפירוק הידני של מערך הסכמים

כיצד היה

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

מה שינו ומה נהיה

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

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

בדיקת המסמך הצטמצמה ל-2–3 דקות: עורך הדין מאשר את מה שחולץ ולא מחפש אותו. שיעור השדות שהתקבלו ללא תיקונים — 92%, סעיפים מקושרים שהוחמצו — פחות מ-1% לעומת 6–8% בפירוק ידני. המערך פורק בשלושה שבועות במקום ארבעה חודשים, וחתך לפי תנאי סיום נבנה בדקות במקום ביום.

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

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

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

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

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

חוזים מגיעים כסריקות באיכות גרועה — מה יקרה איתם?

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

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

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

האם המערכת מתחשבת בתיקוני עורכי הדין בממשק?

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

כיצד נבדקת האיכות לפני ההרצה ומי רואה את המסמכים?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

מה כדאי לשלוח בהתחלה ולהבהיר יחד:

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

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