WEBVTT

00:00:00.000 --> 00:00:07.660
מוכנים למד מינוס עשרה ימים של Microsoft 365, Copilot, בינה מלאכותית, Azure והאנשים שמעצבים את עתיד העבודה.

00:00:07.840 --> 00:00:12.380
בינואר הקרוב, M365Con חוזרת, ואנחנו הולכים בגדול.

00:00:12.580 --> 00:00:18.660
הצטרפו אלינו למפגשים חיים, הדגמות מהעולם האמיתי וידע מעשי ממש ומומחי תעשייה מכל העולם.

00:00:18.900 --> 00:00:21.680
בלי מצגות גנריות, בלי מילים ריקות מתוכן.

00:00:21.920 --> 00:00:29.280
אנחנו מתמודדים עם האתגרים האמיתיים, Copilot Studio, סוכני AI, פבריק, אבטחה, ממשל ואוטומציה.

00:00:29.280 --> 00:00:35.040
בין אם אתם אנשי איט, מפתחים או מובילים עסקיים, יש מפגשים שתוכננו במיוחד עבורכם.

00:00:35.380 --> 00:00:40.420
במהלך עשרה ימים מלאים, תוכלו לחקור טכנולוגיות רבות ולהתחבר לקהילה גלובלית.

00:00:40.640 --> 00:00:44.840
צפו בשידור חי וקחו איתכם תובנות מעשיות בחזרה לארגון שלכם.

00:00:45.060 --> 00:00:49.340
ינואר 2027, עשרה ימים, קהילת מייקרוסופט אחת.

00:00:49.520 --> 00:00:50.860
ההרשמה פתוחה כעת.

00:00:52.940 --> 00:00:54.720
הבטיחו את מקומכם עוד היום.

00:00:56.120 --> 00:00:59.300
הכתובת היא M365Con.net

00:00:59.300 --> 00:01:05.020
הרשמו עכשיו ב-M365Con.net ונתראה בשידור חי בינואר.

00:01:05.160 --> 00:01:09.040
מה יקרה אם סוכני ה-AI שלכם יתחילו לקבל החלטות מבלי שתבחינו בכך?

00:01:09.160 --> 00:01:12.000
במפגש היום, נבחן מדוע ממשל, Governance, כבר אינו אופציונלי,

00:01:12.180 --> 00:01:16.160
ואיך מרכז הניהול של מייקרוסופט 365 יכול להעניק לכם את לוח הבקרה החסר הזה.

00:01:16.300 --> 00:01:19.840
תראו את הכלים המדויקים שיעזרו לכם למנוע מהסוכנים שלכם לפעול ללא פיקוח,

00:01:19.840 --> 00:01:22.140
תוך העצמת הצוותים שלכם לבנות את מה שהם צריכים.

00:01:22.140 --> 00:01:25.860
אם תהיתם איך לממש את היתרונות של כל פעילות מבלי לאבד שליטה,

00:01:26.080 --> 00:01:27.220
הגעתם למקום הנכון.

00:01:27.380 --> 00:01:30.060
מדוע סוכני AI מפחידים כל כך הרבה ארגונים?

00:01:30.280 --> 00:01:34.340
מה גורם לחברה להסס כשהיתרונות של סוכני AI נראים כל כך ברורים על הנייר?

00:01:34.520 --> 00:01:37.980
צמצום עבודה ידנית, קבלת החלטות מהירה יותר, שימוש טוב יותר בנתונים.

00:01:38.160 --> 00:01:40.920
על פני השטח זה נשמע כמו ניצחון שקל לאשר.

00:01:40.920 --> 00:01:46.040
אולם, כשהשיחה עוברת מהמצגת לפריסה בשטח, רואים את צוותי ההנהלה מתחילים לסגת.

00:01:46.040 --> 00:01:49.040
ההססנות לא נובעת מחוסר אמונה בטכנולוגיה.

00:01:49.200 --> 00:01:54.060
היא נובעת מפחד ממה שעלול לקרות ברגע שמעות או אפילו אלפי אוטומציות קטנות

00:01:54.060 --> 00:01:56.340
יתחילו לפעול ברקע ללא פיקוח ברור.

00:01:56.940 --> 00:02:00.500
המתח בין הבטחה עצומה לבין אי-וודאות גדולה באותה מידה

00:02:00.500 --> 00:02:04.440
השאיר ארגונים רבים תקועים בשלב הפיילוט זמן רב יותר ממה שציפו.

00:02:04.440 --> 00:02:08.860
המציאות היא שסוכני AI מעוררים עצבנות כי הם לא פועלים כמו כלים אחרים.

00:02:08.860 --> 00:02:12.220
ניתן לשלוט מתי עובדים מתקינים אפליקציית פרודוקטיביות חדשה

00:02:12.220 --> 00:02:13.820
או לחסום תוכנות עם ניהול קצה,

00:02:14.080 --> 00:02:16.260
אך סוכנים לא נכנסים בקלות לאותן קטגוריות.

00:02:16.380 --> 00:02:19.740
הם מתוכננים לפעול לעיתים במהירות, לעיתים על פני מערכות מרובות.

00:02:19.920 --> 00:02:22.960
מרגע שהופעלו, הם יכולים להרגיש כאילו הם פועלים בעצמם.

00:02:23.120 --> 00:02:27.320
ועבור מובילי איט שהוכשרו לחשוב במונחים של שליטה, סטנדרטיזציה וממשל,

00:02:27.320 --> 00:02:30.920
הרעיון של תהליכי רקע בלתי נראים המעצבים תזרימי מידע אמיתיים

00:02:30.920 --> 00:02:33.000
עלול להרגיש כמו איבוד אחיזה בארגון כולו.

00:02:33.120 --> 00:02:35.580
ישנן דוגמאות רבות המראות איך זה עובד בפועל.

00:02:35.720 --> 00:02:38.580
צוות מחקר משיק בוט כדי למשוך ולארגן מערכי נתונים.

00:02:38.840 --> 00:02:41.600
מישהו אחר רואה שזה עובד ומעתיק את זה עם התאמות קלות.

00:02:41.760 --> 00:02:44.800
בתוך שבועות, החברה כבר לא מריצה סוכן אחד מנוהל היטב.

00:02:44.920 --> 00:02:46.980
היא מריצה עשרים שיבוטים עם הבדלים קטנים,

00:02:47.180 --> 00:02:49.080
ללא בקרת גרסאות וללא בעלים ברור.

00:02:49.080 --> 00:02:54.740
כעת, אנליסט בברלין מקבל החלטות על בסיס מערך נתונים שונה במקצת מזה של מנהל בניו יורק

00:02:54.740 --> 00:02:58.400
ומחלקת הכספים מגרדת בראשה כי שתי הגרסאות מזינות את הדוחות שלה.

00:02:58.580 --> 00:03:02.180
תחפילו זאת בעשרות מחלקות שכל אחת מנסה להעיץ את עצמה

00:03:02.180 --> 00:03:06.920
ופתאום שיפור הפרודוקטיביות הופך לשאלה על איזה מספר מישהו באמת יכול לסמוך.

00:03:07.360 --> 00:03:11.740
ראינו גם מקרים שבהם האוטומציה חצתה גבולות שאסור היה לגעת בהם.

00:03:11.740 --> 00:03:18.140
בחברה אחת היה תסריט פנימי שהעביר בשקט מידע לקוחות בין מערכות כדי לייעל את תהליך הקליטה

00:03:18.140 --> 00:03:21.520
אך איש לא בדק אם העברות הנתונים עמדו בתקני הציוט.

00:03:21.780 --> 00:03:28.160
שהגיעו המבקרים, הארגון לא הצליח להציג רישום של מי כתב אותו, מדוע הוא פעל או באילו כללים הוא פעל.

00:03:28.380 --> 00:03:32.520
זה לא היה כישלון של יכולות הבינה המלאכותית, זה היה כישלון של פיקוח.

00:03:32.720 --> 00:03:37.960
טכנולוגיה שנועדה לחסוך זמן יצרה את כאב הראש התפעולי הגדול ביותר שהחברה חוותה מזה שנים.

00:03:37.960 --> 00:03:40.580
לא קשה לראות מדוע מנהיגים מגיבים בזהירות.

00:03:40.700 --> 00:03:46.100
הצגת סוכנים ללא גבולות היא כמו לתת לכל עובד רחפן ולתת לו להטיס אותו לאן שירצה.

00:03:46.280 --> 00:03:50.560
הראשונים אולי ימריעו בצורה חלקה, אבל בקרוב אחד יתנגש בבניין,

00:03:50.840 --> 00:03:55.220
אחר ייעלם בלי שאף אחד ידע לאן, ושלישי יחסו מסוק חירום מנחיתה.

00:03:55.340 --> 00:04:00.500
ללא מגדל פיקוח, אותה טכנולוגיה שהייתה אמורה להוסיף יעילות הופכת למפגע ציבורי.

00:04:00.620 --> 00:04:03.160
אותו עיקרון חל גם בעבודה מבוססת ידע.

00:04:03.160 --> 00:04:05.620
האוטומציה עצמה היא לא מקור הפחד.

00:04:05.820 --> 00:04:07.360
היעדר השליטה הוא המקור.

00:04:07.580 --> 00:04:10.640
סקרים מגבים את מה שכבר אפשר לנחש מהסיפורים האלה.

00:04:10.800 --> 00:04:16.520
מנהלים מצביעים בעקביות על ציות, הבטחה ודליפת מידע כדאגות המרכזיות שלהם לגבי בינה מלאכותית ארגונית.

00:04:16.660 --> 00:04:19.820
זה לעיתים רחוקות נוגע לשאלה האם הטכנולוגיה מספקת תוצאות.

00:04:19.820 --> 00:04:25.820
החשש הוא שפיסת מידע שגויה תדלוף, או שבו תנקות בפעולה שאף אחד לא יכול לעקוב אחריה בדיעבד.

00:04:25.940 --> 00:04:28.080
הסיכונים הם לא רק טעויות טיפוליות.

00:04:33.160 --> 00:04:37.960
לבנות מחדש את האמון כאשר לקוחות מאמינים שהאוטומציה שלך חשפה מידע שלא הייתה אמורה לחשוף.

00:04:38.100 --> 00:04:40.660
לכן חשוב להגדיר את הבעיה האמיתית בצורה נכונה.

00:04:40.840 --> 00:04:43.260
חברות לא מפחדות מסוכני קופה אילות עצמם.

00:04:43.420 --> 00:04:45.140
הן מפחדות מלאבד אותה מהעין.

00:04:45.320 --> 00:04:51.380
הן מפחדות לשכוח מבנה איזה סוכן, מתי הוא נבדק לאחרונה, או מדוע הוא מושך מידע ממערכות רגישו.

00:04:51.380 --> 00:04:57.040
הבעיה אינה התוכנה, אלא האדרם של מעקות בטיחות ששומרים עליה אמינה, צפויה ותואמת לכללי הארגון.

00:04:57.200 --> 00:05:01.900
ברגע שרואים זאת כך, הדרך קדימה הופכת לברורה יותר, וכאן רוב האנשים מופתעים.

00:05:02.060 --> 00:05:07.200
לוח הבקרה שארגונים רבים מרגישים שחסר להם, נמצא למעשה כבר בתוך מייקרוסופט 365.

00:05:07.760 --> 00:05:09.060
זה אינו תוסף נפרד.

00:05:09.240 --> 00:05:10.820
זה אינו פיצ'ר פרימיום חבוי.

00:05:10.980 --> 00:05:12.740
זה מוטמע ישירות במרכז הניהול.

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

00:05:21.100 --> 00:05:24.780
במילים אחרות, מעקות הבטיחות שאתם צריכים נמצאים כבר ממש מולכם.

00:05:24.920 --> 00:05:27.520
השאלה היחידה היא אם פתחתם את הלוח הנכון.

00:05:27.720 --> 00:05:29.980
לוח הבקרה שלא ידעתם שקיים אצלכם.

00:05:30.140 --> 00:05:35.680
מה אם תה הטייס לניהול סוכני ה-AI שלכם כבר היה מולכם, ורוב מנהלי המערכת פשוט לא שמו לב?

00:05:35.840 --> 00:05:36.840
זה נשמע לא סביר.

00:05:36.840 --> 00:05:43.020
אך האמת היא שמרכז הניהול של Microsoft 365 מחזיק בשקט בהגה שארגונים רבים חיפשו.

00:05:43.140 --> 00:05:50.000
האירוניה היא שצוותי איט רבים פותחים את הפורטל מדי יום, אך ממשיכים לחלוף על פני החלקים החשובים ביותר לממשל סוכנים.

00:05:50.200 --> 00:05:54.600
כשחושבים על זה, זה אחד מאותם מצבים שבהם ההיכרות המוקדמת כמעט עובדת נגדיכם.

00:05:54.780 --> 00:06:00.880
אתם מניחים שאתם יודעים מה יש בפנים, ולכן אתם לא מצפים למצוא מנופי שניטה חדשים חבויים מאחורי לשוניות שאתם בדרך כלל מתעלמים מהם.

00:06:00.880 --> 00:06:09.280
במשך שנים, מרכז הניהול טופל כלוח שירות בלבד. אתם פותחים אותו כדי לחלק רישיונות, להגדיר תיבות דואר באקסצ'יינג', אולי לכוונן מדיניות צוות כזו או אחרת.

00:06:09.460 --> 00:06:16.380
זהו מרחב עבודה שנועד למפות תכונות למשתמשים ולוודא שאנשים שפתחו קריאות שירות יקבלו בסופו של דבר גישה לשירותים שביקשו.

00:06:16.500 --> 00:06:19.500
מה שלעיתים קרובות מתפספס הוא כמה השיר הוא הפך להיות.

00:06:19.500 --> 00:06:27.340
מאחורי אותו, ממשק קיים סט הולך וגדל של תכונות שנועדו לעזור למנהלים לנהל לא רק למי יש גישה, אלא איך אנשים יוצרים, משתמשים ומשתפים אוטומציה.

00:06:27.480 --> 00:06:33.320
אם דאגתם שסוכני הקופילות שלכם יצאו משליטה, מעקות הבטיחות עבורם נמצאים לרוב במרחק של כמה קליקים בלבד.

00:06:33.460 --> 00:06:34.600
חוסר ההלים הברור.

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

00:06:46.460 --> 00:06:52.540
ובכל זאת, אותם ארגונים משמיעים את החששות הללו בזמן שהם בקושי מביטים בלוח המכוונים המרכזי שנועד למנוע בדיוק את זה.

00:06:52.720 --> 00:06:53.760
זהו ניתוק מוזר.

00:06:53.920 --> 00:06:58.680
אנחנו חוששים מעובדן שליטה, אך לא משתמשים מספיק בלוח הבקרה שקיים כדי לטעם את הטיסה.

00:06:58.680 --> 00:07:03.220
זה כמו להתלונן על תנועה בלתי צפויה בזמן שמתעלמים מרמזורים בפינת הרחוב.

00:07:03.360 --> 00:07:06.200
תארו לעצמכם תרחיש טיפוסי בתוך חברה גדולה.

00:07:06.320 --> 00:07:11.880
במחלקת השיווק בונים סוכנים לאיסוף משוב מלקוחות בזמן שבאופרציה מעצבים בות לאיעול מעקב הזמנות.

00:07:12.000 --> 00:07:13.920
אף אחד מהדברים האלה אינו שדו איט.

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

00:07:21.180 --> 00:07:26.600
כשמחלקת העית נתקלת בהם במקרה, בלתי אפשרי לדעת למי הם שייכים או לאילו מקורות נתונים הם ניגשים.

00:07:26.780 --> 00:07:29.520
פתאום, שיחות על ציוט הופכות לעבודת בילוש.

00:07:29.700 --> 00:07:32.160
מי באמת בנה את זה? מתי זה הודכן לאחרונה?

00:07:32.320 --> 00:07:33.960
אילו הרשאות זה ירש בשקט?

00:07:34.120 --> 00:07:38.760
ללא פיקוח ברור, גם אוטומציות קטנות עלולות להפוך לפרצות ציות שאף אחד לא תכנן.

00:07:38.920 --> 00:07:43.400
מרכז הניהול מטפל בזה ישירות על ידי ריכוז כל הפעילות הסמויה הזו למקום אחד.

00:07:43.400 --> 00:07:49.680
במקום לנחש, תוכלו לראות אילו סוכנים קיימים, על אילו מחברים הם מסתמכים ומי מורשה לשנות או לפרסם אותם.

00:07:49.820 --> 00:07:56.840
מדיינויות קובעות אילו קבוצות רשאיות ליצור אוטומציה מלכתחילה, כך שתוכלו להפריד בין ניסויים לבין פריסה רשמית.

00:07:57.000 --> 00:08:04.720
זה קריטי, כי בניית אב טיפוס פנימי בצוות אחד שונה מאוד מהקמת משהו שמשפיע על כל פלטפורמת ה-CRM או ה-HR שלכם.

00:08:04.900 --> 00:08:07.320
המרכז מאפשר לכם לשמור על ההפרדה הזו.

00:08:07.320 --> 00:08:09.700
הרשאות מוסיפות שכבת הבטחה נוספת.

00:08:09.860 --> 00:08:16.020
קל לדמיין את הסיכון אם כל עובד נלהב היה יכול לא רק לבנות סוכנים, אלא גם להפעיל אותם עבור כל הארגון.

00:08:16.300 --> 00:08:22.540
מודל טוב יותר הוא לאפשר השתתפות רחבה בגיבוש רעיונות תוך הגבלת סמכות הפריסה לתפקידים יהודיים.

00:08:22.980 --> 00:08:28.340
בפועל, זה עשוי להיראות כמו אנליסטים פיננסיים שיוצרים סוכני טיוטה לצורכי דיווח,

00:08:28.340 --> 00:08:32.960
בעוד שרק צוות ה-Eat Governance מחליט אם הטיוטות האלו מגיעות לסביבת ייצור.

00:08:32.960 --> 00:08:38.600
על ידי הגדרת הכללים הללו בתוך מרכז הניהול, אתם מחליטים מראש מי קובע את חוקי המרחב האווירי.

00:08:38.720 --> 00:08:40.300
דיווח סוגר את המעגל.

00:08:40.440 --> 00:08:44.940
במקום לחכות שמשהו יתקלקל כדי לגלות שקיים בות, תוכלו לעקוב אחר מגמות שימוש,

00:08:45.180 --> 00:08:49.800
לראות אילו מחלקות מתנסות הרבה ולבצע ביקורות בלי לרדוף אחרי גיליונות אלקטרוניים אקראיים.

00:08:49.980 --> 00:08:54.100
התצוגה מבוססת, הנתונים הזו לא רק מחסה צייות, היא מעצבת אסטרטגיה.

00:08:54.100 --> 00:09:02.500
אם אתם מבחינים שצוותי תמיכה מקימים שוב ושוב סוכנים דומים, אולי יגיע הזמן להשקיע בפתרון סטנדרטי במקום לתת לעשרות כאלה לפעול ללא השגחה.

00:09:02.700 --> 00:09:07.660
השילוב של נירות ושליטה הופך אוטומציה מכאב ראש להזדמנות שבאמת ניתן לנהל.

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

00:09:13.920 --> 00:09:20.560
כל תוכנית טיסה מתועדת, כל המראה מאושרת לפי מדיניות, והתנגשויות פשוט לא קורות כמישהו רואה את כל השמיים.

00:09:20.780 --> 00:09:28.600
ברגע שמבינים שלוח מכוונים מרכזי אחד מחזיק בשקט בכוח הזה, מפסיקים להתייחס לסוכנים כאיום סמוי ומתחילים להפעיל אותם כמו אופרציות מובנות.

00:09:28.600 --> 00:09:31.500
ואם המסגרת הזו במקומה, השיחה משתנה.

00:09:31.780 --> 00:09:37.720
כי בעוד למנהלים יש פיקוח, העובדים עדיין צריכים מרחב לבנות ולהתנסות בלי לפרוץ את הגבולות האלה.

00:09:37.820 --> 00:09:40.440
וכאן בדיוק נכנס לתמונה Copilot Studio.

00:09:43.920 --> 00:09:48.900
את מאפשרים לעובדים ליצור פתרונות מבוססי בינה מלאכותית בלי לדרדר את הארגון לקאוס.

00:09:49.140 --> 00:09:51.920
זה האתגר המרכזי כשזה מגיע לקופילות סטודיו.

00:09:51.920 --> 00:10:00.260
מצד אחד, הכלי הזה נועד לשחרר יצירתיות במחלקות ולתת לאנשים שמכירים את נקודות הכאב היומיומיות שלהם הזדמנות לאוטומציה ישירה.

00:10:00.520 --> 00:10:09.380
מצד שני, חלוקת כלי בנייה ללא פיקוח עלולה להוביל בקלות לגל של תהליכי עבודה לא מבוקרים שיותירו את העית בניסיון להבין מה בעצם רץ.

00:10:09.380 --> 00:10:16.060
זה איזון שנראה מסובך במבט ראשון. האם להעצים משתמשים ולהסתכן בוולגן או לנעול הכל ולחנוק את ההתקדמות?

00:10:16.060 --> 00:10:25.460
Copilot Studio מציב את עצמו כדרך האמצע. חישבו על זה כעל סדנה שבה עובדים יכולים לנסות פתרונות, לבחון אינטראקציות ואפילו לפרסם סוכנים כדי לשפר את אופן העבודה שלהם.

00:10:25.620 --> 00:10:29.440
ההבדל בין זה לבין אוטומציות הייט עשה זאת בעצמך של העבר הוא פשוט.

00:10:29.440 --> 00:10:40.880
מנגנוני הגנה כבר מובנים בתוך הפלטפורמה. במקום לבקש מהאיט לנקות אחרי מעשה, Studio הוא משתמש באותם עקרונות ממשל שאתם מנהלים ב-Admin Center ושורג אותם ישירות לסביבת העיצוב.

00:10:41.080 --> 00:10:46.160
זה מה שהופך את זה למעשי ולא למסוכן. ובכל זאת, המתח עבור מנהלים הוא אמיתי מאוד.

00:10:46.320 --> 00:10:53.760
אם ראיתם פעם מה קורה כשצוות נלהב שם יד על כלי סקריפטים, תדעו כמה מהר בדיקה פשוטה יכולה להפוך לתלות קריטית למשימה.

00:10:53.760 --> 00:11:06.780
הבעיה היא לא כוונות רעות. רוב המשתמשים רק רוצים לפתור את סברי הבקבוק שלהם. אבל כשהפתרונות המקומיים האלה מתחילים ליצור אינטראקציה עם נתוני לקוחות, רשומות פיננסיות או קבצי משאבי אנוש, אתם עוברים מהר מניסויים מועילים לטריטוריה של תעימות.

00:11:06.840 --> 00:11:12.960
וברגע שאתם בצד הזה של הגדר, אחריות ופיקוח הם כבר לא אופציונליים. תארו לעצמכם את התרחיש הזה.

00:11:12.960 --> 00:11:25.580
אנליסט פיננסי בונה סוכן שמושך אוטומטית יתרות לקוחות ומפיק דוח שבועי. זה חוסך שעות של עבודה ידנית והופך לפופולרי במהירות. כמה קולגות לוקחים אותו לעצמם ובקרוב הוא מתפשט בכל המחלקה.

00:11:25.700 --> 00:11:34.680
אבל הנה הקץ. מי הבטיח שהסוכן לא חושף שדות רגישים? מי אישר שמקורות הנתונים תואמים את כללי התעימות לטיפול במידע פיננסי?

00:11:34.680 --> 00:11:44.260
ואם רגולטור דופק בדלת, מי הוכיח שזה נבנה והותמה לפי מדיניות ולא כפרויקט צדדי? ללא המבנה הנכון, הבוט הפשוט הזה הופך לחוות.

00:11:44.380 --> 00:11:53.600
כאן בדיוק Copilot Studio מחזק את התמונה. הפלטפורמה לא מניחה שכל בונה הוא מפתח מקצועי. כל התכנון שלו כולל הגנות למשתמשים שאינם טכניים.

00:11:53.600 --> 00:11:59.900
מנהלי מערכת מגדירים אילו פעולות זמינות, באילו מחברים ניתן להשתמש, ולמי יש הרשאה להעביר תוצרים לסביבת ייצור.

00:12:00.080 --> 00:12:05.320
עובדים עשויים להרגיש שיש להם חופש יצירתי מלא, אך מה שקורה בפועל הוא התנסות מוגבלת ומבוקרת.

00:12:05.440 --> 00:12:10.480
ההבדל הזה הוא שמאפשר לחברות להרחיב את אימוץ הסוכנים מבלי להתעכל בבעיית אית צללים נוספת.

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

00:12:18.280 --> 00:12:21.720
אולי רק מחברים מאושרים כמו SharePoint או Dynamics יהיו זמינים.

00:12:21.860 --> 00:12:25.420
בעוד שכל דבר הנוגע לשירותי צד שלישי רגישים יישאר מחוץ לתחום.

00:12:25.420 --> 00:12:28.780
מעבר לכך, אתם מחליטים אילו פעולות מערכת יישארו מוגבלות.

00:12:28.780 --> 00:12:34.520
למשל, שאילת במסד נתונים עשויה להיות תקינה, אך עדכון ישיר של שדות מפתח נחסם כדי למנוע נזק מקרי.

00:12:34.660 --> 00:12:39.680
בקיצור, משתמשים יכולים לנסות רעיונות, אך הם לא ישנו רשומות ייצור ללא אישור מפורש.

00:12:39.840 --> 00:12:43.500
אנלוגיה פשוטה עוזרת כאן. זה כמו ארגז חול במגרש משחקים.

00:12:43.500 --> 00:12:48.000
ילדים יכולים לבנות כמה טירות שהם רוצים בתוך הארגז, אך יש גבול ברור סביבו.

00:12:48.100 --> 00:12:52.720
הגדר מבדע שהמשחק נשאר בטוח, תוך שהיא משאירה מספיק מקום ליצירתיות.

00:12:52.720 --> 00:12:55.340
סטודיו מביא את אותו קונספט לבניית סוכנים.

00:12:55.540 --> 00:12:58.280
העובדים מקבלים את תחושת החופש שהם צריכים כדי לחדש,

00:12:58.500 --> 00:13:02.640
בזמן שהמנהלים יודעים שהגדר הבלתי נראית עוצרת כל דבר מלהפוך לסיכון אמיתי.

00:13:02.820 --> 00:13:06.500
לכן, כאשר מגדירים את Copilot Studio עם הרשאות ומדיניות מתאימות,

00:13:06.500 --> 00:13:10.520
הוא מפסיק להוות בעיית הבטחה והופך למה שנועד להיות, מעבדת חדשנות בטוחה.

00:13:10.620 --> 00:13:15.720
מחלקות יכולות לחקור סוכנים המותאמים לעבודתן, להתנסות בגישות חדשות ולשתף רעיונות מוקדמים,

00:13:15.720 --> 00:13:19.100
וכל זאת ללא הפרת תאימות או יצירת תהליכי עבודה לא מאושרים.

00:13:19.260 --> 00:13:21.360
החדשנות נמשכת, אך הקאוס לא.

00:13:21.540 --> 00:13:26.100
וגם אם חומות מגן אלו, עדיין יש אמצעי הגנה אחד שלא ניתן להתעלם ממנו, נירות.

00:13:26.280 --> 00:13:30.400
כי לא משנה כמה חזקים מעקות הבטיחות, עדיין צריך להשגיח על מה שקורה בזמן אמת.

00:13:30.400 --> 00:13:32.700
כאן נכנסים לתמונה הניטור והמעקב.

00:13:32.880 --> 00:13:35.960
מגדל השמירה, ניטור ומעקב אחר פעילות הסוכן.

00:13:36.120 --> 00:13:39.880
מה יקרה אם הסוכן שלכם קיבל בשקט מאות החלטות שמעולם לא ראיתם?

00:13:40.040 --> 00:13:41.120
זה לא תרחיש דמיוני.

00:13:41.320 --> 00:13:46.480
זה בדיוק מה שיכול לקרות כאשר ארגון מגדיר בקרות, אך שוכח את החצי השני של המשוואה.

00:13:46.600 --> 00:13:48.580
הרשאות ומדיניות הן כמו גדרות.

00:13:48.720 --> 00:13:52.480
הן אומרות לעובדים היכן מותר להם לבנות ובאילו כלים הם יכולים להשתמש.

00:13:52.480 --> 00:13:56.800
אך ללא נירות, אין לכם דרך לדעת אם מי שהוא שוטט לפינה לא מבוקרת,

00:13:56.920 --> 00:13:59.580
או אם סוכן פועל בשקט מחוץ לטווח שנועד לו.

00:14:00.060 --> 00:14:04.100
ניטור הוא החלק שמעביר את כל סיפור המשילות הזה מניחושים לבהירות.

00:14:04.100 --> 00:14:07.400
חישבו על האופן שבו אנחנו מתמודדים בדרך כלל עם בעיות אי.

00:14:07.560 --> 00:14:11.960
מה שהוא משתבש, משתמש פותח קריאה, ואז אנחנו רצים בניסיון להבין מה השתנה.

00:14:12.160 --> 00:14:13.260
זו גישה ריאקטיבית.

00:14:13.260 --> 00:14:17.620
זה עובד במינונים קטנים, אבל הופך לבלגן יקר כשמגדילים את זה למאות אוטומציות.

00:14:17.800 --> 00:14:22.520
עם סוכני AI, הסיכון גדול יותר כי הבעיה עלולה להיות בלתי נראית עד שיהיה מאוחר מדי.

00:14:22.640 --> 00:14:26.020
תהליך עבודה סורר יכול לרוץ שבועות לפני שמישהו יבחין בכך.

00:14:26.020 --> 00:14:30.720
לא כי הוא נכשל ברעש, אלא כי הוא קיבל בשקט החלטות שנראות תקינות על פני השטח.

00:14:30.840 --> 00:14:35.720
עד שמישהו שואל למה הנתונים לא מסתדרים, אתה חוקר את העבר במקום למנוע את העתיד.

00:14:35.720 --> 00:14:38.040
ניתור משנה את הדינמיקה הזו לחלוטין.

00:14:38.200 --> 00:14:43.260
במקום לעבוד על עיוור, מקבלים נראות בזמן אמת לאילו סוכנים קיימים, מי בנה אותם ואיך הם בשימוש.

00:14:43.400 --> 00:14:47.440
מייקרוסופט 365 מטמיעה את הנראות הזו בתוך העקוס סיסטם שלה.

00:14:47.440 --> 00:14:55.620
ניתוח שימוש עוזר לראות אילו מחלקות מאמצות סוכנים מהר, מי הם הבנאים, הכבדים ואיפה עלולה להופיע פעילות לא צפויה.

00:14:56.500 --> 00:14:58.480
יומני ביקורת עוקבים אחר הפרטים.

00:14:58.480 --> 00:15:02.720
מתי סוכן עבר שינוי, באילו מחברים הוא נגע ומי יפעיל את הפעולות שלו.

00:15:02.880 --> 00:15:05.580
סוג כזה של עקבות לא רק משמח את צוותי התאימות.

00:15:05.700 --> 00:15:09.200
זה מה שמאפשר לך באמת להבין את הסביבה החיה במקום לנחש לגביה.

00:15:09.360 --> 00:15:12.920
הערך של התובנה הזו מתברר כשמדמיינים תרחיש רגיל מאוד.

00:15:12.920 --> 00:15:16.560
צוות שיווק בונה סוכן כדי לנתח סקרי משוב של לקוחות.

00:15:16.720 --> 00:15:21.080
זה מתחיל בקטן, קמפיין אחד, כמה אלפי רשומות, והתוצאות נראות מועילות.

00:15:21.080 --> 00:15:26.360
עם הזמן, מי שהוא משכפל אותו לפרויקט אחר, ואז צוות נוסף לוקח את התבנית ועורכת עמו.

00:15:26.500 --> 00:15:32.200
ללא ניתור, יש לך כעת כמה גרסאות של סוכן שרצות במקביל, כשכל אחת ניגשת לנתונים בצורה מעט שונה.

00:15:32.400 --> 00:15:37.700
כשלא רואים זאת, ההבדלים האלו מחלחלים בסוף לדוחות ומבלבלים את מקבלי ההחלטות בדרגים הגבוהים.

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

00:15:48.420 --> 00:15:52.920
לפעמים נירות היא ההבדל בין תיקון קטן לבין תקרית ברמה כותרת עיתון.

00:15:53.120 --> 00:15:57.840
קחו למשל מקרה של סוכן שמושך נתונים פיננסיים רגישים כדי להאיץ נחזיות פנימיות.

00:15:57.840 --> 00:16:04.920
אם הוא חשף בטעות יותר מדי פרטים או הפך את הנתונים לנגישים מחוץ למחלקת הכספים, סיכון התאימות היה מזנק במהירות.

00:16:05.020 --> 00:16:08.260
אבל עם ניתור, הגישה החריגה מופיעה בבירור ביומנים.

00:16:08.480 --> 00:16:12.940
ניתן להשביט אותו או להתאים הרשאות לפני שרגולטורים או לקוחות בכלל יצטרכו לשאול שאלות.

00:16:13.100 --> 00:16:15.880
זה לא עניין של להניח את הכוונות הגרועות ביותר מהבונים.

00:16:16.100 --> 00:16:20.120
זה עניין של להכיר בכך שגם הצוותים הזהירים ביותר עושים טעויות בזמן ניסויים.

00:16:20.120 --> 00:16:23.940
נירות היא מה שהופך את הטעויות הללו להפיכות במקום לקטסטרופליות.

00:16:24.160 --> 00:16:26.940
דיווח גם מחליק את מערכת היחסים עם המבקרים.

00:16:27.120 --> 00:16:30.700
כל מי שעבר ביקורת מכיר את המרדף המטיש אחר איסוף תיעוד.

00:16:31.020 --> 00:16:34.900
מי אישר מה, מתי התרחש כל שינוי, והאם הבקרות אכן נאכפו.

00:16:35.060 --> 00:16:37.880
מעקב ידני הוא מועד לטעויות ומעורר לחץ.

00:16:38.000 --> 00:16:42.680
כשמערכת הדיווח שלך כבר שומרת את הרישומים האלה, אתה מפסיק לרדוף אחרי הזנב של עצמך.

00:16:42.680 --> 00:16:46.960
ניתן להפיק את היסטוריית הפעילות של הסוכן בפורמט שתואמת דרישות הרגולציה.

00:16:47.140 --> 00:16:51.500
זה מפחית גם את המשאבים האנושיים הנדרשים וגם את הסיכון שמה שהוא קריטי התפספס.

00:16:51.620 --> 00:16:57.880
מנקודת מבט תפעולית, זה גם חוסך אינספור שעות שהיו מתבזבזות על בניית דוחות ביקורת חד פעמיים בדיעבד.

00:16:58.040 --> 00:17:02.180
מה שהופך את הניטור לעוצמתי כל כך הוא האופן שבו הוא משנה את כל תפיסת האחריות.

00:17:02.180 --> 00:17:06.460
במקום לחכות לתלונות כסימן לבעיה, אתה מפתח מפה חיה של מה שקורה בשטח.

00:17:06.620 --> 00:17:09.520
מגמות הופכות לברורות, והפתעות הופכות לפחות סבירות.

00:17:09.660 --> 00:17:14.500
אתה לא רק הוכף חוקים באמצעות הרשאות, אתה בודק אם החוקים האלה עומדים במבחן המציאות.

00:17:14.740 --> 00:17:21.360
זה אותו ההבדל בין צפייה בעיר דרך מצלמות תנועה חיות לבין להסתמך רק על תמרורים בצמתים כדי לשמור על סדר.

00:17:21.560 --> 00:17:26.540
גישה אחת מעניקה לך ביטחון, השנייה משאירה אותך בהמתנה מתוכה לבסורות על התאונה הבאה.

00:17:26.540 --> 00:17:32.260
לכן, כשמשלבים בקרות מדיניות עם ניטור, מודל הממשל מפסיק להיות פסיבי והופך ליוזם באמת.

00:17:32.460 --> 00:17:38.400
ניחושים מוחלפים בפיקוח, ופיקוח הוא מה שמונע הצטברות שקטה של סיכונים שצפים רק חודשים לאחר מכן.

00:17:38.580 --> 00:17:46.360
מבט המגדלור, לא רק מגן מפני תרחישי קיצון, הוא יוצר ביטחון לצוותים להמשיך להתנסות בידיעה שמישהו משגיח על האופק.

00:17:46.360 --> 00:17:48.700
וזה מוביל באופן טבעי לשאלה הבאה.

00:17:48.700 --> 00:17:56.220
אם נראות היא כל כך עוצמתית, למה כל כך הרבה ארגונים עדיין נופלים בטעויות ממשל קלאסיות שמבטלות את אותן הגנות?

00:17:57.820 --> 00:17:59.880
הימענות מטעויות ממשל קלאסיות

00:17:59.880 --> 00:18:07.020
כישלונות הממשל הגדולים ביותר בשימוש בסוכני קופיילות לא נובעים מחוסר בכלים, אלא משימוש לא נכון בכלים הקיימים.

00:18:07.020 --> 00:18:14.220
רוב הטעויות שראיתי בארגונים אינן בגלל שמנהלי מערכת לא הכירו את מרכז הניהול או שלא ידעו שקופילות סטודיו קיים.

00:18:14.220 --> 00:18:20.900
הבעיה האמיתית היא שתכונות הופעלו בלי לחשוב על סוג התשתית הדרושה כדי להפעיל אותן כראוי בהיקף נרחב.

00:18:21.080 --> 00:18:27.420
זה כמו לתת לכל מחלקה סט מפתחות משלה למשרד משותף, אבל בלי להסכים לעולם מי נועלת הדלתות בלילה.

00:18:27.580 --> 00:18:31.420
דפוס נפוץ הוא שמנהלי מערכת מניחים שהפעלה שקולה לממשל.

00:18:31.420 --> 00:18:36.580
תכונה חדשה מופיעה במרכז הניהול, המתג מופעל וכולם מרגישים שהעבודה הוא שלמה.

00:18:36.720 --> 00:18:39.160
אבל טכנולוגיה לא קובעת את הגבולות בעצמה.

00:18:39.160 --> 00:18:44.920
אם ההרשאות אינן ברורות, אם הניטור קבוי או אם האחריות מפוצלת בין צוותים שונים ללא תאום,

00:18:45.160 --> 00:18:47.420
הקאוס מחלחל פנימה בשקט ובהתמדה.

00:18:47.580 --> 00:18:50.720
החלק המפחיד ביותר הוא שזה בדרך כלל לא מתפוצץ מיד.

00:18:50.720 --> 00:18:56.380
זה נבנה לאט, ואז ביקורת אחת, תקרית אחת או שאלה רגולטורית אחת חושפות פתאום

00:18:56.380 --> 00:19:00.620
שמה שנראה כמו שליטה היה למעשה סדרה של פערים שמחכים להתגלות.

00:19:01.000 --> 00:19:02.980
המוקש הראשון קשור להרשאות.

00:19:02.980 --> 00:19:08.880
אם איש לא הגדיר למי מותר לבנות, לפרסם או לשתף סוכנים, המשתמשים לעיתים קרובות ממלאים את החלל בעצמם.

00:19:09.080 --> 00:19:12.820
זה עלול להוביל לכפילות של סוכנים, לפרסום סוכנים לסביבת ייצור לפני בדיקות,

00:19:12.980 --> 00:19:15.720
או לתהליכי עבודה שגורמים לגישה לנתונים שאסור להם לראות.

00:19:15.720 --> 00:19:21.800
ללא גבולות ברורים, אתם מסיימים עם כתלוג צללים של אוטומציות שמחלקת העית מגלה רק כשמשהו משתבש.

00:19:21.800 --> 00:19:27.140
הפעלת תכונות מבלי להגביל את הגישה עליהן אינה קידום חדשנות, אלא חלוקת שקים פתוחים.

00:19:27.300 --> 00:19:29.200
המוקש השני הוא ויתור על ניטור.

00:19:29.400 --> 00:19:33.280
לא פעם דיברתי עם מנהלי מערכות שהניחו שהגדרת הרשאות מספיקה,

00:19:33.500 --> 00:19:36.160
כשבפועל לא היה להם מושג אם הכללים האלה בכלל עובדים.

00:19:36.160 --> 00:19:38.280
זה מותיר אותם עברים למה שקורה באמת.

00:19:38.420 --> 00:19:41.360
אם לא הפעלתם יומני ביקורת, לא תוכלו להוכיח מי הסמה.

00:19:41.540 --> 00:19:45.580
אם אינכם מסתכלים על מדדי שימוש, לא תוכלו לראות אילו סוכנים הופכים לפופולריים,

00:19:45.580 --> 00:19:47.320
או אם דפוסי הפעילות נראים חריגים.

00:19:47.460 --> 00:19:49.880
טיסה ללא הנתונים האלה מרגישה בסדר לזמן מה,

00:19:50.100 --> 00:19:54.700
עד שגורם רגולטורי חיצוני או צוות הציוט שלכם שואלים שאלות שאינכם יכולים לענות עליהן.

00:19:54.820 --> 00:19:56.840
מדיניות לא עקבית היא המוקש השלישי.

00:19:56.980 --> 00:19:59.300
חלק אחד בארגון עשוי לעבוד בצורה מוקפדת,

00:19:59.300 --> 00:20:01.300
בעוד אחר משאיר את הפרסום פתוח לכולם.

00:20:01.480 --> 00:20:06.500
חוסר העקביות מבטיח תערובת מבולגנת של סוכנים מבוקרים ולא מבוקרים שחיים באותו דייר, תנן.

00:20:06.500 --> 00:20:11.280
מבחוץ זה יכול להיראות כאילו פתרתם את נושא האסטרטגיה כי קיימות מדיניות כלשהן.

00:20:11.360 --> 00:20:15.460
אבל צוותי ציוט וסקירות הבטחה לא רוצים רק הוכחה לכך שמדיניות קיימת,

00:20:15.720 --> 00:20:18.000
הם רוצים הוכחה לכך שהיא עקבית בכל הארגון.

00:20:18.000 --> 00:20:22.640
השונות הזו הופכת לקשה עוד יותר להגנה כאשר אזורים שונים כפופים לרגולציות שונות,

00:20:22.840 --> 00:20:24.440
והמדיניות שלכם לא תואמת אותן.

00:20:24.540 --> 00:20:27.560
ואז יש את המקרה הקלאסי של בעלות מופרדת, סילואים.

00:20:27.560 --> 00:20:31.340
אולי העית קובע כלל אחד, צוות ההבטחה מניח שיש שכבת כיסוי אחרת,

00:20:31.540 --> 00:20:34.200
והיחידות העסקיות מניחות שהן יכולות לפרסם כרצונן.

00:20:34.360 --> 00:20:38.020
כל קבוצה חושבת שמישהו אחר משגיח על הקצוות, אבל בפועל אף אחד לא.

00:20:38.020 --> 00:20:43.060
חוסר הבהירות הזה מייצר הפתעות מיותרות כמו הרשאות כפולות או סוכנים שחומקים מתחת לרדאר,

00:20:43.140 --> 00:20:45.220
כי לא היה ברור לאיזה צוות יש סמכות סופית.

00:20:45.360 --> 00:20:47.780
חברה אחת שדיברתי איתה חוותה בדיוק את זה.

00:20:47.920 --> 00:20:50.580
הם אפשרו לכל עובד לפרסם סוכנים באופן חופשי.

00:20:50.740 --> 00:20:52.380
בהתחלה זה נראה כמו העצמה.

00:20:52.580 --> 00:20:57.140
אולם יכלו להתנסות ולהפיץ שיפורים, אבל איש לא חיבר בין זכויות פרסום ליומני ביקורת.

00:20:57.140 --> 00:21:02.460
חודשים לאחר מכן, רגולטור ביקש הוכחה למי התמיע אוטומציות ספציפיות, ולא היה להם כלום.

00:21:02.620 --> 00:21:07.100
לא היה שום תיעוד, לא היה בעלים רשמי, ולא הייתה שום יכולת להתגונן בביקורת.

00:21:07.180 --> 00:21:11.540
מה שהחל כי מאמץ להנגשת האוטומציה הפך בסופו של דבר לפער משמעותי בתאימות.

00:21:11.540 --> 00:21:16.040
דוגמאות אלו מדגישות כיצד טעויות קטנות עלולות להפוך במהירות לסיכונים רחבי היקף.

00:21:16.040 --> 00:21:21.040
הרשאה שהוגדרה באופן שגוי או סוכן שלא נבדק עשויים להיראות שוליים בפיילוט קטן,

00:21:21.260 --> 00:21:25.460
אך בקנה מידה ארגוני, אותה טעות מוכפלת למאות סוכנים שרצים בפינות נסתרות.

00:21:25.680 --> 00:21:29.080
בעיות לא גדלות באופן לינארי, הן גדלות באופן אקספוננציאלי,

00:21:29.080 --> 00:21:33.840
כיוון שכל סוכן בלתי מבוקר מותיר שאלות פתוחות בנושאי שלמות נתונים, אמינות והבטחה.

00:21:33.940 --> 00:21:37.420
החדשות הטובות הן שהמלכודות מוכרות היטב, וכך גם הדרכים לעקוף אותן.

00:21:37.580 --> 00:21:40.540
התחילו בהגדרת קווי הגנה בסיסיים במרכז הניהול, אדמין סנטר.

00:21:40.680 --> 00:21:43.560
קיבו תפקידים ברורים למי מורשה לבנות לעומת מי מורשה לפרסם.

00:21:43.560 --> 00:21:48.180
הבחו את הניטור לחובה, לא לאופציה, כדי שתקבלו התראה לפני שנושא כלשהו יהפוך לבעיה רציני.

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

00:21:53.740 --> 00:21:57.580
והחשוב מכל, תעמו ציפיות עם צוותי ההבטחה והטעימות שלכם מהיום הראשון.

00:21:57.760 --> 00:22:01.060
השארתה מחוץ לתהליך עד לשלב מאוחר יותר כמעט תמיד מובילה לתוצאות הפוכות.

00:22:01.060 --> 00:22:03.940
ארגונים רבים כבר גיבשו תוכניות עבודה שמוכיחות את עצמן.

00:22:03.940 --> 00:22:13.140
רשימות תיוג לבחינת מדיניות בכל רבעון נהלים שקושרים תיעוד ביקורת ישירות להרשאות פרסום ומסגרות שבהן צוותי חדשנות מתנסים קודם לפני שהתבוחן פריסה רשמית.

00:22:13.360 --> 00:22:17.120
למידה מהניסיון שלהם אומרת שאתם לא צריכים לחזור על הטעויות שלהם.

00:22:17.120 --> 00:22:23.240
בכל פעם שחברה אחרת דיווחה על קשל, זה לרוב קרה כי קווי הגנה היו קיימים על הנייר אך לא יוסמו בצורה הנכונה.

00:22:23.400 --> 00:22:26.440
על ידי הפנמת הלקחים שלהם מוקדם, אתם חוסכים את העלויות.