פיתוח מערכת AI ל-GovTech ולעיר חכמה

למה פיתוח AI ל-GovTech נתקע בפיילוטים

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

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

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

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

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

מה משתנה בעבודת המשרד לאחר הטמעת AI

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

את המסגרת המתודולוגית אנחנו שואבים מ-עקרונות ה-AI האחראי של OECD: החלטת המודל מוסברת, והעובד רואה על מה מבוססת הבחירה בניתוב.

צמצום הניתוח הידני של פניות

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

מרשם אחיד של פניות והחלטות

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

פורמטים של עבודה: פיילוט, מעגל מלא, תמיכה

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

פיילוט על תהליך אחד

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

מעגל מלא מקצה לקצה

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

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

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

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

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

בדיקה על נתונים היסטוריים

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

הדרכה ומסירה לתפעול

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

ערכת אספקה: תרשימים, מדיניות גישה, תקנונים

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

מדיניות גישה והפרדת תפקידים

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

תקנונים והוראות למפעילים

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

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

מקרה בוחן: עיבוד פניות בשירות עירוני

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

איך עבדו לפני

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

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

מה השתנה לאחר ההשקה

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

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

מעגל סגור או ענן: כיצד לבחור אחסון

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

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

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

ספקות המזמין: איכות, נתונים, אחריות

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

מה אם המערכת תטעה?

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

מי אחראי לתוצאה?

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

הנתונים סגורים — כיצד לנהל את העבודה ומה לאחר החתימה?

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

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

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

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

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