חוק ה-AI הוא שעון, לא תאריך יחיד

דרך מעשית לראות את הרעיון

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

צלילה טכנית: עקבו אחרי המערכת, לא אחרי הסיסמה

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

מעבדת קוד: מעטפת נצפית

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

from datetime import date

SYSTEMS = [
  {"name": "support bot", "owner": "CX", "deadline": date(2026, 8, 2)},
  {"name": "hiring ranker", "owner": "People", "deadline": date(2027, 8, 2)},
]

def next_actions(today):
    return sorted(
        ({**s, "days": (s["deadline"] - today).days} for s in SYSTEMS),
        key=lambda s: s["days"]
    )

מבחן בעולם האמיתי

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

הניתוח של ג׳ק

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

מה הדוגמה אינה מוכיחה

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

שאלות שכדאי לשאול בבדיקה

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