73,000 מונים "חכמים" כבו בן לילה — וזה חשף כל מה שלא תקין בדרך שבה אנחנו בונים AI לתשתיות

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

"הספק אומר שזו תקלה ידועה," הוא אמר לי. "הם עובדים על טלאי."

שאלתי כמה זמן המונים שולחים נתונים שגויים. הוא השתהה. "אנחנו חושבים שכתשעה ימים."

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

הלילה שבו 73,000 מונים השתתקו

בפלאנו, טקסס, העירייה הוציאה $10.2 מיליון על 87,000 מוני מים חכמים מחברת Aclara Technologies, בציפייה שיחזיקו מעמד עשרים שנה. עד 2023, הסוללות התחילו לגווע מוקדם. הפתרון של הספק? עדכון קושחה מרחוק שהופץ בנובמבר 2024 כדי לייעל את צריכת החשמל.

אותו עדכון הפך 73,000 מונים ללבנים דוממות.

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

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

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

ופלאנו אינה לבד. טורונטו איבדה 470,000 משדרים לבלייה מוקדמת — $5.6 מיליון בעלויות תיקון ראשוניות. חברת Memphis Light, Gas and Water התמודדה עם שיעור כשל מערכתי של 8% בכל צי המונים החכמים שלה, והקצתה $9 מיליון לתיקונים. בבריטניה, למעלה מ-900,000 מונים חכמים תוקנו או הוחלפו מאז שהרגולטורים החלו לשים לב.

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

מדוע מונים חכמים מתים צעירים?

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

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

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

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

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

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

מה קורה כשהרגולטורים מתחילים לספור?

הרגולטור האנרגטי של בריטניה, Ofgem, החליט שראה מספיק. החל מפברואר 2026, הוא אוכף תקני ביצוע מובטחים (Guaranteed Standards of Performance) המחייבים תשלומים אוטומטיים של £40 ללקוחות כאשר תקני השירות של מונים חכמים אינם מתקיימים. מחכים יותר משישה שבועות לתור התקנה? תשלום אוטומטי. ההתקנה נכשלת מפני שהספק הגיע ללא הציוד הנכון? תשלום אוטומטי. דווח על תקלת מונה ואין תוכנית פתרון תוך חמישה ימי עבודה? תשלום אוטומטי.

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

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

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

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

"פשוט תשתמשו ב-GPT" — העצה שמדירה שינה מעיניי

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

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

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

לאן הולכים הנתונים?

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

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

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

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

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

מה קורה כשה-API משתנה?

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

תשתית קריטית לא יכולה להיות תלויה בהמשכיות העסקית של דף תמחור API של סטארט-אפ מעמק הסיליקון.

איך Deep AI נראה באמת

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

ב-Veriprajna, אנחנו לא מוכרים מחדש מפתחות API. אנחנו לא בונים מעטפות. אנחנו פורסים את מחסנית ההיסק המלאה של AI — מנועים כמו vLLM, Text Generation Inference, ו-BentoML — ישירות על התשתית של הלקוח עצמו. אשכולות ה-Kubernetes שלהם. ה-GPU על ברזל חשוף (bare-metal) שלהם. הענן הפרטי הווירטואלי שלהם.

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

בניית מוח סמנטי

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

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

המייל האחרון של הדיוק

אנחנו לוקחים מודלי יסוד פתוחים כמו Llama 3 ומכווננים אותם באופן עדין על הקורפוס הספציפי של חברת השירותים באמצעות טכניקות כמו LoRA (Low-Rank Adaptation). התוצאה היא מודל בהתאמה אישית שמבין את המינוח של הלקוח, את המערכות הישנות שלו, את המוזרויות התפעוליות שלו. בבדיקות שלנו, כוונון עדין ספציפי-לתחום זה מגדיל את הדיוק במשימות מתמחות בעד 15% בהשוואה למודל הבסיס.

אותם 15% אולי נשמעים תוספתיים. הם לא. באימות קושחה, ההבדל בין דיוק של 85% ל-100% הוא ההבדל בין תפיסת עדכון מסוכן לבין מתן אפשרות לו להפוך 73,000 מונים ללבנים דוממות.

איך תופסים באג בקושחה לפני שהוא מגיע לשטח?

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

בנינו צינור לכך. הוא מתחיל בזיהוי בינארי — באמצעות כלים כמו EMBA ו-Firmwalker כדי לחלץ ולנתח את מערכות הקבצים של הקושחה, גם כאשר קוד המקור אינו זמין. לאחר מכן אנחנו מפרקים את הבינארי (decompile) באמצעות Ghidra, וה-LLM הפרטי שלנו מנתח את הקוד המפורק לאיתור פגמי לוגיקה, נהלים לא מאובטחים, ופגיעויות פוטנציאליות.

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

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

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

מתגובתי לחיזוי: מה משתנה כש-AI צופה ברשת

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

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

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

זה סוג התפיסה שמצדיק את כל ההשקעה. והמספרים תומכים בכך: הוכח שתחזוקה מנבאת מבוססת-AI מפחיתה כשלי תשתית ב-73%, חותכת עלויות תחזוקה ב-18-25%, ומאריכה את אורך חיי הנכסים בעד 40%.

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

מה לגבי ה-ROI?

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

אבל שקלו כמה עולה החלופה. פלאנו: $765,000 עבור קוראי מונים ידניים, בתוספת ההשקעה המקורית של $10.2 מיליון שכעת פגומה משמעותית. ממפיס: קרן תיקונים של $9 מיליון. טורונטו: $5.6 מיליון וסופרים. חברות השירותים בבריטניה: העלות המצטברת של 900,000 החלפות מונים בתוספת הקנסות הרגולטוריים שעומדים להתחיל לפגוע.

תעשיות מדווחות על עלות נפילה ממוצעת של $125,000 לשעה. הפחתה של 30-50% בזמן ההשבתה לא רק מחזירה את עלות ה-AI — היא משנה את הפרופיל הפיננסי של חברת השירותים. כשמוסיפים דחיית הוצאות הון מהארכת חיי הנכס ב-40%, הפחתה של 28% בעיכובי שרשרת אספקת הרכיבים, והפחתה של 40% בתקריות בטיחות, חישוב ה-ROI אינו קרוב.

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

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

הרשת שאליה אנו בונים

כשמספר מכשירי ה-IoT צפוי לעבור את 30 מיליארד עד 2026, בעיית המורכבות לא הולכת להיעלם. היא מאיצה. החזית הבאה — ומה שהצוות שלי בונה לקראתו באופן פעיל — היא זרימות עבודה של AI סוכני (agentic AI): מערכות שלא רק מסמנות אנומליות אלא נוקטות פעולה. מבודדות אוטומטית מכשיר IoT שנפגע. מכווננות פרמטרי שנאי בזמן אמת על בסיס דפוסי עומס חזויים. מבצעות שחזור קושחה לאחור (rollback) ברגע שעדכון מראה סימנים של גרימת בעיות.

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

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

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

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