WEBVTT

00:00:00.220 --> 00:00:07.540
Готові до 10-х днів Microsoft 365, Co-Pilot, She, Azure та зустрічей з тими, хто формує майбутні роботи.

00:00:07.700 --> 00:00:12.300
Цього січня M365Con повертається, і ми стаємо ще масштабнішими.

00:00:12.460 --> 00:00:18.780
Приєднуйтесь до нас на живих сесіях, демонстраціях реальних кейсів та отримуйте практичні знання від MVP та експертів з усього світу.

00:00:18.960 --> 00:00:21.780
Жодних загальних слайдів чи нескінченних модних слів.

00:00:22.040 --> 00:00:29.140
Ми розбираємо реальні виклики Co-Pilot Studio, She-агенти, Fabric, безпека, управління та автоматизація.

00:00:29.140 --> 00:00:35.020
Незалежно від того, чи ви і те фахівець, розробник чи керівник бізнесу, у нас є сесії саме для вас.

00:00:35.160 --> 00:00:40.660
Протягом 10 повних днів ви зможете вивчити різні технології та налагодити зв'язки з глобальною спільнотою.

00:00:40.880 --> 00:00:44.740
Дивіться наживо та впроваджуйте практичні ідеї у своїй організації.

00:00:44.740 --> 00:00:50.980
Січень 2027, 10 днів, одна спільнота Microsoft. Реєстрація вже відкрита.

00:00:52.880 --> 00:00:54.840
Забронюйте своє місце сьогодні.

00:00:54.840 --> 00:01:04.880
Приєднуйтесь на M365-con.net і побачимось у прямому ефірі в січні.

00:01:05.040 --> 00:01:09.120
Що станеться, якщо ваші ще агенти почнуть приймати рішення, навіть не повідомляючи вас?

00:01:09.120 --> 00:01:16.140
На сьогоднішній сесії ми розглянемо, чому управління вже не є необов'язковим, і як центр адміністрування Microsoft 365 надасть вам необхідну панель контролю.

00:01:16.260 --> 00:01:22.200
Ви побачите інструменти, які допоможуть запобігти виходу агентів з-під контролю, одночасно дозволяючи командам створювати те, що їм потрібно.

00:01:22.320 --> 00:01:27.200
Якщо ви думали, як отримати переваги Coopilot, не втрачаючи нагляду, ви в правильному місці.

00:01:27.380 --> 00:01:30.080
Чому ще агенти лякають так багато організацій?

00:01:30.240 --> 00:01:34.420
Що змушує компанії вагатися, коли переваги ще агентів здаються такими очевидними на папері?

00:01:39.120 --> 00:01:46.060
Проте, коли розмова переходить від презентації до реального розгортання, ви бачите, як керівні команди починають відступати.

00:01:46.220 --> 00:01:48.900
Вагання виникають не через брак віри в технологію.

00:01:49.080 --> 00:01:56.580
Вони виникають через страх перед тим, що може статися, коли сотні чи навіть тисячі дрібних автоматизацій почнуть працювати у фоні безналежного нагляду.

00:01:56.740 --> 00:02:04.340
Напруга між величезними обіцянками та такою ж величезною невизначеністю змусила багато організацій застрягти в пілотному режимі набагато довше, ніж вони очікували.

00:02:04.340 --> 00:02:09.160
Реальність у тому, що ще агенти змушують людей нервувати, бо вони працюють не так, як інші інструменти.

00:02:09.320 --> 00:02:16.000
Ви можете контролювати встановлення нових програм або блокувати ПЗ через керування кінцевими точками, але агенти не вписуються в ці рамки.

00:02:16.200 --> 00:02:19.880
Вони створені діяти іноді швидко, іноді охоплюючи кілька систем одночасно.

00:02:20.000 --> 00:02:22.900
Після запуску може здатися, що вони рухаються самі собою.

00:02:22.900 --> 00:02:32.820
А для ІТ-лідерів, навчених мислити категоріями контролю, стандартизації та управління, ідея невидимих фонових процесів, що формують реальні потоки даних, може відчуватися як втрата контролю над організацією.

00:02:32.980 --> 00:02:35.480
Є безліч прикладів, які показують, як це відбувається.

00:02:35.700 --> 00:02:38.780
Дослідницька команда запускає бота для збору та впорядкування наборів даних.

00:02:38.900 --> 00:02:41.640
Хтось інший бачить, як він працює і копіює його з невеликими змінами.

00:02:41.820 --> 00:02:44.800
За кілька тижнів компанія керує вже не одним, добре контрольованим агентом.

00:02:44.800 --> 00:02:49.060
Вона керує 20 маклонами з невеликими відмінностями, без контролю версій і без чіткого власника.

00:02:49.200 --> 00:02:54.860
Тепер аналітик у Берліні приймає рішення на основі набору даних, який дещо відрізняється від того, що використовує менеджер у Нью-Йорку,

00:02:54.940 --> 00:02:58.320
а фінансовий відділ у розгубленості, бо обидві версії потрапляють у їхні звіти.

00:02:58.460 --> 00:03:02.180
Помножте це на десятки відділів, кожен з яких намагається пришвидшити свою роботу,

00:03:02.260 --> 00:03:06.880
і раптом підвищення продуктивності перетворюється на питання про те, яким цифрам взагалі можна довіряти.

00:03:06.880 --> 00:03:11.880
Ми також бачили випадки, коли автоматизація переходила межі, яких не слід було торкатися.

00:03:12.040 --> 00:03:17.780
Одна компанія мала внутрішній скрипт, що тихо переносив інформацію про клієнтів між системами для спрощення адаптації,

00:03:17.920 --> 00:03:21.500
але ніхто не перевіряв, чи відповідає передача даних стандартам відповідності.

00:03:21.660 --> 00:03:28.500
Коли прийшли аудитори, організація не змогла надати запис про те, хто його написав, навіщо він працював і яких правил дотримувався.

00:03:28.660 --> 00:03:32.260
Це не було помилкою, можливо, стейші. Це було провалом нагляду.

00:03:32.260 --> 00:03:37.860
Технологія, покликана завщаджувати час, спричинила найбільший головний біль щодо відповідності вимогам, з яким компанія стикалася роками.

00:03:37.980 --> 00:03:40.600
Неважко зрозуміти, чому керівники реагують з обережністю.

00:03:40.800 --> 00:03:46.340
Впровадження агентів без обмежень схоже на те, щоб дати кожному співробітнику дрон і дозволити йому літати де завгодно.

00:03:46.520 --> 00:03:54.920
Перші кілька можуть злетіти плавно, але незабаром один врізається в будівлю, інший зникне і ніхто не знатиме, куди, а третій завадить посадці рятувального вертольота.

00:03:54.920 --> 00:04:00.400
Без диспетчерської вежі та сама технологія, що мала підвищити ефективність, стає небезпекою для оточення.

00:04:00.540 --> 00:04:02.980
Той самий принцип діє і в інтелектуальній роботі.

00:04:03.420 --> 00:04:05.700
Автоматизація сама по собі не є джерелом страху.

00:04:05.840 --> 00:04:07.500
Джерелом є відсутність контролю.

00:04:07.660 --> 00:04:10.900
Опитування підтверджують те, що ви вже можете припустити з цих історій.

00:04:11.040 --> 00:04:16.720
Керівники постійно вказують на відповідність вимогам, безпеку та витік даних, як на свої головні побоювання щодо корпоративного щі.

00:04:16.840 --> 00:04:19.500
Рідко йдеться про те, чи дає технологія результати.

00:04:19.500 --> 00:04:25.720
Побоювання полягає в тому, що витече не та інформація або що бот вчинить дії, які ніхто не зможе відстежити постфактум.

00:04:25.860 --> 00:04:28.120
Ставки – це не лише операційні помилки.

00:04:28.360 --> 00:04:32.640
Вони безпосередньо впливають на репутацію, регуляторні ризики та довіру клієнтів.

00:04:32.780 --> 00:04:38.000
Потрібні роки, щоб відновити довіру, коли клієнти вірять, що ваша автоматизація розкрила дані, які не мала розкривати.

00:04:38.160 --> 00:04:40.520
Ось чому важливо правильно назвати справжню проблему.

00:04:40.680 --> 00:04:43.000
Компанії не бояться самих агентів Co-Pilot.

00:04:43.000 --> 00:04:45.260
Вони бояться втратити їх із поля зору.

00:04:45.260 --> 00:04:51.280
Вони бояться забути, хто створив якого агента, коли його востаннє перевіряли, або чому він отримує інформацію з конфіденційних систем.

00:04:51.460 --> 00:04:57.060
Проблема не в програмному забезпеченні, а у відсутності запобіжників, які роблять його надійним, передбачуваним та відповідним правилам організації.

00:04:57.200 --> 00:05:00.040
Коли ви дивитеся на це так, шлях уперед стає зрозумілішим.

00:05:00.160 --> 00:05:02.060
І саме тут більшість людей дивується.

00:05:02.240 --> 00:05:07.260
Панель керування, якої, на думку багатьох організацій, не вистачає, насправді вже є в Microsoft 365.

00:05:07.260 --> 00:05:12.820
Це не окремий додаток. Це неприхована преміум-функція. Вона вбудована в центр адміністрування.

00:05:13.000 --> 00:05:21.260
І хоча багато організацій використовують цей портал лише для призначення ліцензій або базових політик Teams, він непомітно став вежею контролю польотів для агентів Co-Pilot.

00:05:21.460 --> 00:05:24.480
Іншими словами, потрібні вам запобіжники вже перед вами.

00:05:24.640 --> 00:05:27.200
Питання лише в тому, чи відкрили ви потрібну панель.

00:05:27.340 --> 00:05:30.220
Панель керування, про існування якої ви навіть не здогадувалися.

00:05:30.220 --> 00:05:35.620
Що, якби кабіна для керування вашими щі агентами вже була перед вами, а більшість адміністраторів цього просто не помітили.

00:05:35.760 --> 00:05:43.060
Це звучить мало ймовірно, але правда в тому, що центр адміністрування Microsoft 365 спокійно тримає штурвал, який шукали багато організацій.

00:05:43.220 --> 00:05:50.340
Іронія полягає в тому, що багато ІТ-команд відкривають портал щодня, але проходять повз ті частини, які найважливіші для управління агентами.

00:05:50.520 --> 00:05:54.360
Якщо замислитися, це одна з тих ситуацій, коли звичка грає проти вас.

00:05:54.360 --> 00:06:00.760
Ви припускаєте, що знаєте, що всередині, тому не очікуєте знайти нові важелі контролю, приховані за вкладками, які ви зазвичай ігноруєте.

00:06:00.940 --> 00:06:03.800
Роками центр адміністрування сприймався як допоміжна панель.

00:06:03.960 --> 00:06:09.280
Ви відкриваєте його, щоб роздати ліцензії, налаштувати поштові скриньки Exchange, можливо, підкоригувати політику для команди другої.

00:06:09.400 --> 00:06:16.200
Це робочий майданчик для прив'язки функцій до користувачів та гарантії того, що люди, які подають тікети, зрештою отримають доступ до запитаних послуг.

00:06:16.200 --> 00:06:19.700
Те, що часто залишається поза увагою, це те, наскільки багатшим він став.

00:06:19.840 --> 00:06:27.460
За цим самим інтерфейсом живе дедалі більший набір функцій, розроблених, щоб допомогти адміністраторам керувати не лише тим, хто має доступ, а й тим, як люди створюють, використовують і поширюють автоматизацію.

00:06:27.600 --> 00:06:33.180
Якщо вас турбує, що агенти Coopilot виходять з-під контролю, запобіжники для них рідко знаходяться далі, ніж за кілька кліків.

00:06:33.180 --> 00:06:46.320
Невідповідність очевидна. Цілі дискусії на ІТ-форумах обертаються навколо страху перед хаосом щі, появою неконтрольованих ботів у відділах, автоматизацією доступу до конфіденційних даних або дублюванням робочих процесів із незначними, але згубними відмінностями.

00:06:46.480 --> 00:06:52.460
Проте ті самі організації висловлюють ці побоювання, ледь поглядаючи на центральну панель, створену саме для того, щоб цьому запобігти.

00:06:52.460 --> 00:06:58.700
Це дивний дисонанс. Ми боїмося втратити контроль, але недовикористовуємо саму панель керування, яка існує для координації польоту.

00:06:58.860 --> 00:07:03.380
Це як скаржитися на непередбачуваний рух транспорту, ігноруючи світлофори на перехресті.

00:07:03.520 --> 00:07:11.880
Уявіть типовий сценарій у великій компанії. Маркетинговий відділ створює агентів для збору відгуків клієнтів, а операційний розробляє бота для спрощення відстеження замовлень.

00:07:11.880 --> 00:07:17.240
Це не навмисне використання тіньових IT-технологій. Це просто ентузіасти-співробітники, які намагаються полегшити собі роботу.

00:07:17.380 --> 00:07:21.120
Але після запуску ці агенти розпорошуються по різних ізольованих системах без єдиного обліку.

00:07:21.280 --> 00:07:26.280
Коли IT-відділ нарешті їх виявляє, неможливо зрозуміти, хто ними володіє або до яких джерел даних вони звертаються.

00:07:26.420 --> 00:07:29.480
Раптово обговорення питань комплеєнсу перетворюється на детективне розслідування.

00:07:29.480 --> 00:07:34.160
Хто насправді це створив? Коли це оновлювали? Які дозволи воно успадкувало безвідомо?

00:07:34.300 --> 00:07:39.000
Без належного нагляду навіть невеликі автоматизації можуть призвести до проблем із відповідністю нормам, яких ніхто не очікував.

00:07:39.120 --> 00:07:43.320
Центр адміністрування вирішує це питання, збираючи всю приховану активність в одному місці.

00:07:43.520 --> 00:07:49.680
Замість припущень ви можете побачити, які агенти існують, на які конектори вони покладаються і хто має права на їх зміну чи публікацію.

00:07:49.680 --> 00:07:56.760
Політики визначають, які групи можуть створювати автоматизацію, що дозволяє відокремити експерименти від офіційного розгортання.

00:07:56.940 --> 00:08:04.820
Це важливо, адже створення внутрішнього прототипу в межах однієї команди – це не те саме, що налаштування рішення для всієї CRM чи HR-платформи.

00:08:04.960 --> 00:08:09.600
Центр дозволяє тримати ці речі окремо. Дозволи додають ще один рівень безпеки.

00:08:09.800 --> 00:08:16.100
Легко уявити ризики, якби кожен енергійний співробітник міг не лише створювати агентів, а й публікувати їх для всього орендаря.

00:08:16.100 --> 00:08:22.820
Краща модель – дозволити ширшу участь у створенні ідей, обмежуючи при цьому повноваження на розгортання лише визначеними ролями.

00:08:23.360 --> 00:08:32.560
На практиці фінансові аналітики можуть створювати чернетки агентів для звітів, але лише команда IT-керівництва вирішує, чи потраплять вони в робоче середовище.

00:08:32.880 --> 00:08:38.640
Налаштовуючи ці правила в центрі адміністрування, ви заздалегідь вирішуєте, хто встановлює правила повітряного простору.

00:08:38.820 --> 00:08:40.440
Звітність замикає цей цикл.

00:08:40.440 --> 00:08:49.780
Замість того, щоб чекати збою для виявлення бота, ви можете відстежувати тенденції використання, бачити найбільш активні відділи та проводити аудити без пошуку випадкових таблиць.

00:08:49.880 --> 00:08:54.040
Цей огляд на основі даних не лише забезпечує відповідність вимогам, а й формує стратегію.

00:08:54.160 --> 00:09:02.380
Якщо ви помічаєте, що служби підтримки постійно запускають схожих агентів, можливо, варто інвестувати в стандартизоване рішення, а не дозволяти десяткам аналогів працювати без нагляду.

00:09:02.380 --> 00:09:07.660
Поєднання видимості та контролю перетворює автоматизацію з головного болю на можливість, якою можна керувати.

00:09:07.840 --> 00:09:14.020
Тож замість того, щоб уявляти агентів, які хаотично літають у всіх напрямках, сприймайте центр адміністрування як диспетчерську вежу.

00:09:14.160 --> 00:09:20.600
Кожен план польоту зафіксовано, кожен виліт узгоджено з політикою і зіткнення просто неможливі, оскільки хтось бачить усе небо.

00:09:20.600 --> 00:09:28.520
Коли ви усвідомлюєте, що центральна панель керування має таку владу, ви перестаєте бачити в агентах приховану загрозу і починаєте керувати ними як структурованими процесами.

00:09:28.700 --> 00:09:31.400
Із цією структурою розмова змінює свій напрямок.

00:09:31.560 --> 00:09:37.700
Бо поки адміністратори мають свій контроль, співробітникам все одно потрібен простір для створення та експериментів, не порушуючи встановлених меж.

00:09:37.820 --> 00:09:40.340
І саме тут на допомогу приходить Co-Pilot Studio.

00:09:40.760 --> 00:09:43.580
Інновації без хаосу – Co-Pilot Studio в дії.

00:09:43.580 --> 00:09:48.920
Як дозволити співробітникам створювати власні рішення на базі ЩІ, не занурюючи організацію в хаос?

00:09:49.080 --> 00:09:51.820
Це головний виклик, коли мова йде про Co-Pilot Studio.

00:09:52.160 --> 00:09:56.000
З одного боку, цей інструмент створений для розкриття творчого потенціалу в різних відділах,

00:09:56.100 --> 00:10:00.260
даючи людям, які знають свої щоденні проблеми, можливість автоматизувати їх безпосередньо.

00:10:00.400 --> 00:10:06.000
З іншого боку, надання інструментів розробки без нагляду може легко призвести до хвилі неконтрольованих робочих процесів,

00:10:06.120 --> 00:10:09.240
через що IT-відділ буде змушений розбиратися, що саме працює.

00:10:09.240 --> 00:10:11.820
Це баланс, який на перший погляд здається складним.

00:10:11.980 --> 00:10:15.900
Чи давати користувачам свободу і ризикувати безладом, чи заблокувати все і придушити прогрес.

00:10:16.040 --> 00:10:18.900
Co-Pilot Studio позиціонує себе як золота середина.

00:10:19.100 --> 00:10:22.140
Сприймайте це як майстерню, де співробітники можуть випробовувати рішення,

00:10:22.240 --> 00:10:25.780
тестувати взаємодії та навіть публікувати агентів для покращення своєї роботи.

00:10:25.900 --> 00:10:29.180
Різниця між цим і саморобною автоматизацією минулого проста.

00:10:29.400 --> 00:10:31.740
Механізми захисту вже вбудовані в платформу.

00:10:31.740 --> 00:10:34.580
Замість того, щоб просити IT виправляти все після факту,

00:10:34.580 --> 00:10:38.440
Studio У використовує ті ж принципи управління, що й у центрі адміністрування,

00:10:38.600 --> 00:10:41.000
інтегруючи їх безпосередньо в середовище розробки.

00:10:41.160 --> 00:10:43.320
Ось що робить це практичним, а не ризикованим.

00:10:43.460 --> 00:10:46.000
Тим не менш, напруга для адміністраторів цілком реальна.

00:10:46.140 --> 00:10:50.200
Якщо ви бачили, що стається, коли ентузіасти отримують доступ до інструментів для написання скриптів,

00:10:50.320 --> 00:10:53.840
ви знаєте, як швидкозвичайне тестування може перетворитися на критично важливу залежність.

00:10:53.980 --> 00:10:55.340
Проблема не в злих намірах.

00:10:55.340 --> 00:10:58.540
Більшість користувачів просто хочуть усунути власні перешкоди в роботі.

00:10:58.640 --> 00:11:01.820
Але коли такі локально створені рішення починають взаємодіяти з даними клієнтів,

00:11:01.900 --> 00:11:03.820
фінансовими записами або кадровими документами,

00:11:03.920 --> 00:11:06.680
ви швидко переходите від корисних експериментів до питань комплеєнсу.

00:11:06.780 --> 00:11:11.060
А коли ви опиняєтеся на цьому боці, відповідальність і нагляд перестають бути необов'язковими.

00:11:11.220 --> 00:11:12.660
Уявіть собі такий сценарій.

00:11:12.820 --> 00:11:18.080
Фінансовий аналітик створює агента, який автоматично підтягує баланси клієнтів і генерує щотижневий звіт.

00:11:18.080 --> 00:11:21.360
Це економить години ручної роботи і швидко стає популярним.

00:11:21.520 --> 00:11:25.320
Кілька колег забирають його собі, і незабаром він поширюється по всьому відділу.

00:11:25.460 --> 00:11:26.800
Але ось у чому підвох.

00:11:26.900 --> 00:11:29.820
Хто гарантував, що агент не розкриває конфіденційні поля?

00:11:30.000 --> 00:11:34.880
Хто підтвердив, що джерела даних відповідають правилам дотримання вимог для роботи з фінансовою інформацією?

00:11:35.020 --> 00:11:40.640
І якщо прийде регулятор, хто доведе, що це було створено та розгорнуто згідно з політикою, а не як сторонній проєкт?

00:11:40.640 --> 00:11:44.220
Без належної структури такий простий бот стає ризиком для компанії.

00:11:44.420 --> 00:11:47.140
Саме тут Co-Pilot Studio покращує ситуацію.

00:11:47.280 --> 00:11:50.480
Платформа не передбачає, що кожен розробник є професійним програмістом.

00:11:50.640 --> 00:11:53.960
Увесь дизайн системи передбачає захист для користувачів без технічних навичок.

00:11:54.120 --> 00:11:57.680
Адміністратори визначають, які дії доступні, які конектори можна використовувати,

00:11:57.780 --> 00:12:00.080
та хто має дозвіл на розгортання в робочому середовищі.

00:12:00.220 --> 00:12:05.060
Працівники можуть відчувати повну творчу свободу, але насправді це ретельно обмежений експеримент.

00:12:05.060 --> 00:12:10.280
Саме ця різниця дозволяє компаніям масштабувати впровадження агентів, не стикаючись із проблемами тіньових ІТ.

00:12:10.440 --> 00:12:12.380
Контрольні точки є цілком конкретними.

00:12:12.540 --> 00:12:15.460
Ви можете дозволити всім у відділі маркетингу створювати чернетки агентів,

00:12:15.540 --> 00:12:18.140
але публікувати їх поза пісочницею можуть лише окремі особи.

00:12:18.280 --> 00:12:21.860
Можливо, доступні лише схвалені конектори, як от SharePoint або Dynamics.

00:12:22.020 --> 00:12:25.220
Тоді як будь-який доступ до чутливих сторонніх сервісів заборонено.

00:12:25.380 --> 00:12:28.760
Крім того, ви самі вирішуєте, які системні дії залишаються обмеженими.

00:12:28.760 --> 00:12:34.520
Наприклад, робити запити до бази даних можна, але пряме оновлення ключових полів заблоковано, щоб запобігти випадковим пошкодженням.

00:12:34.600 --> 00:12:39.660
Коротше кажучи, користувачі можуть тестувати ідеї, але не змінять робочі записи без явного схвалення.

00:12:39.860 --> 00:12:41.340
Допоможе проста аналогія.

00:12:41.520 --> 00:12:43.640
Це як пісочниця на дитячому майданчику.

00:12:43.820 --> 00:12:48.020
Діти можуть будувати скільки завгодно замків усередині, але навколо є чітка межа.

00:12:48.160 --> 00:12:52.340
Огорожа гарантує безпеку гри, залишаючи багато простору для творчості.

00:12:52.500 --> 00:12:55.720
Studio переносить цю саму концепцію у створення агентів.

00:12:55.720 --> 00:13:02.520
Працівники відчувають свободу, необхідну для інновацій, тоді як адміністратори знають, що невидима огорожа запобігає реальним ризикам.

00:13:02.660 --> 00:13:10.540
Отже, коли ви налаштовуєте Coopilot Studio з належними правами та політиками, це перестає бути головним болем для безпеки і стає тим, чим мало бути, безпечною лабораторією інновацій.

00:13:10.680 --> 00:13:19.140
Відділи можуть вивчати агентів, адаптованих до їхньої роботи, експериментувати з новими підходами та ділитися ідеями, не порушуючи комплеєнс і не створюючи несанкціонованих процесів.

00:13:19.140 --> 00:13:26.020
Інновації тривають, а хаос – ні. Навіть із цими захисними стінами є ще один засіб безпеки, який не можна ігнорувати – видимість.

00:13:26.160 --> 00:13:30.200
Бо незалежно від надійності бар'єрів, ви все одно маєте стежити за тим, що відбувається в режимі реального часу.

00:13:30.380 --> 00:13:32.820
Саме тут на допомогу приходять моніторинг і відстеження.

00:13:33.180 --> 00:13:36.140
Спостережна вежа – моніторинг і відстеження активності агентів.

00:13:36.260 --> 00:13:39.580
А що, як ваш агент тихо прийняв сотні рішень, про які ви навіть не знали?

00:13:39.720 --> 00:13:41.320
Це зовсім невигаданий сценарій.

00:13:41.320 --> 00:13:46.500
Це саме те, що може статися, коли організація встановлює контроль, але забуває про іншу половину рівняння.

00:13:46.680 --> 00:13:48.500
Дозволи та політики – це як паркани.

00:13:48.680 --> 00:13:52.540
Вони вказують працівникам, де їм дозволено будувати і які інструменти можна використовувати.

00:13:52.720 --> 00:13:56.880
Але без видимості ви не зможете дізнатися, чи хтось зайшов на неконтрольовану ділянку,

00:13:57.000 --> 00:13:59.800
або чи агент тихо діє поза межами своїх повноважень.

00:14:00.140 --> 00:14:04.300
Моніторинг – це те, що перетворює всю історію керування з припущень на ясність.

00:14:04.300 --> 00:14:07.260
Подумайте про те, як ми зазвичай вирішуємо і те проблеми.

00:14:07.420 --> 00:14:11.900
Щось ламається, користувач надсилає запит, а ми поспіхом намагаємося з'ясувати, що змінилося.

00:14:12.060 --> 00:14:13.300
Це реактивний підхід.

00:14:13.440 --> 00:14:17.840
Він працює в малих масштабах, але перетворюється на дорогий безлад, коли масштабується до сотень автоматизацій.

00:14:18.000 --> 00:14:22.380
Зі штучним інтелектом ризик більший, бо проблему можна не помітити, поки не стане занадто пізно.

00:14:22.600 --> 00:14:25.980
Некерований робочий процес може працювати тижнями, перш ніж хтось це помітить.

00:14:25.980 --> 00:14:30.560
Не тому, що він видав помилку, а тому, що тихо приймав рішення, які зовні здавалися слушними.

00:14:30.700 --> 00:14:35.940
Коли хтось врешті запитує, чому дані не збігаються, ви вже розслідуєте минуле, замість того, щоб запобігати майбутнім проблемам.

00:14:36.180 --> 00:14:37.980
Моніторинг повністю змінює цей ритм.

00:14:38.160 --> 00:14:43.360
Замість роботи на осліп ви отримуєте огляд у реальному часі, які агенти існують, хто їх створив і як вони використовуються.

00:14:43.520 --> 00:14:47.260
Microsoft 365 вбудовує таку видимість у власну екосистему.

00:14:47.260 --> 00:14:55.900
Аналітика використання показує, які відділи швидко впроваджують агентів, хто є активним розробником і де може з'явитися підозвіла активність.

00:14:56.380 --> 00:14:58.500
Журнали аудиту відстежують деталі.

00:14:58.640 --> 00:15:02.560
Коли агент був змінений, які конектори він використовував і хто запускав його дії.

00:15:02.760 --> 00:15:05.420
Такий паперовий слід задовольняє не лише вимоги комплеєнсу.

00:15:05.420 --> 00:15:09.200
Це те, що дозволяє реально розуміти живе середовище, замість того, щоб будувати припущення.

00:15:09.340 --> 00:15:12.880
Цінність цього розуміння стає очевидною, якщо уявити звичайний сценарій.

00:15:12.880 --> 00:15:16.680
Маркетингова команда створює агента для аналізу опитувань відгуків клієнтів.

00:15:16.860 --> 00:15:21.340
Починається все з малого – одна кампанія, кілька тисяч записів і результати виглядають корисними.

00:15:21.540 --> 00:15:26.360
З часом хтось дублює його для іншого проєкту, потім інша команда бере шаблон і вносить зміни.

00:15:26.560 --> 00:15:32.240
Без моніторингу у вас одночасно працює кілька версій агента, кожна з яких звертається до даних трохи інакше.

00:15:32.240 --> 00:15:37.520
Якщо цього не бачите, такі розбіжності зрештою потрапляють у звіти і дезорієнтують керівництво.

00:15:37.520 --> 00:15:43.200
З увімкненим моніторингом ви вчасно помітите сплеск використання, побачите зростання кількості копій

00:15:43.200 --> 00:15:48.100
і зможете стандартизувати одну офіційну версію, перш ніж інші стануть вводити в оману.

00:15:48.640 --> 00:15:52.860
Іноді видимість – це різниця між дрібним виправленням і гучним інцидентом.

00:15:53.080 --> 00:15:57.900
Візьмемо випадок з агентом, що збирає чутливі фінансові дані для прискорення внутрішніх прогнозів.

00:15:57.900 --> 00:16:03.100
Якщо він випадково відкриє забагато деталей або зробить дані доступними за межами фінансового відділу,

00:16:03.200 --> 00:16:05.000
ризики комплеєнсу швидко зростуть.

00:16:05.120 --> 00:16:08.220
Але з моніторингом незвичний доступ чітко видно в логах.

00:16:08.360 --> 00:16:12.960
Ви можете вимкнути його або налаштувати дозволи, поки регулятори чи клієнти ще не поставили запитань.

00:16:13.160 --> 00:16:15.780
Справа не в тому, щоб підозрювати розробників у найгіршому.

00:16:16.000 --> 00:16:20.360
Справа в розумінні того, що навіть найобережніші команди припускаються помилок під час експериментів.

00:16:20.360 --> 00:16:23.740
Саме видимість робить ці помилки виправними, а не катастрофічними.

00:16:23.920 --> 00:16:26.960
Звітність також значно спрощує взаємодію з аудиторами.

00:16:27.120 --> 00:16:31.040
Кожен, хто проходив аудит, знає цей болісний поспіх зі збору документації,

00:16:31.220 --> 00:16:34.980
хто що затвердив, коли відбулися зміни чи дійсно дотримувалися контролів.

00:16:35.120 --> 00:16:38.140
Ручне відстеження схильне до помилок і викликає стрес.

00:16:38.300 --> 00:16:42.220
Коли ваша система звітності вже веде ці записи, ви більше не метушитеся.

00:16:42.400 --> 00:16:47.040
Ви можете створити історію активності агента у форматі, що відповідає нормативним вимогам.

00:16:47.040 --> 00:16:51.360
Це зменшує як людські зусилля, так і ризик того, що щось критичне буде пропущено.

00:16:51.520 --> 00:16:54.540
З операційної точки зору це також економить незліченні години,

00:16:54.680 --> 00:16:58.080
які інакше пішли б на створення разових аудиторських слідів постфактум.

00:16:58.260 --> 00:17:02.000
Сила моніторингу полягає в тому, як він переосмислює всю відповідальність.

00:17:02.160 --> 00:17:06.480
Замість того, щоб чекати на скарги як на сигнал, ви створюєте живу карту того, що відбувається.

00:17:06.640 --> 00:17:09.420
Тренди стають зрозумілими, сюрпризи менш ймовірними.

00:17:09.420 --> 00:17:14.380
Ви не просто впроваджуєте правила за допомогою дозволів, ви бачите, чи діють ці правила на практиці.

00:17:14.540 --> 00:17:17.740
Це те саме, що спостерігати за містом через камери дорожнього руху,

00:17:17.820 --> 00:17:21.620
замість того, щоб просто вірити, що знаків на перехрестях достатньо для порядку.

00:17:21.780 --> 00:17:26.260
Один підхід дає впевненість, інший змушує нервово чекати на новини про чергову аварію.

00:17:26.400 --> 00:17:28.840
Отже, коли ви поєднуєте політику контролю з моніторингом,

00:17:28.980 --> 00:17:32.440
ваша модель управління перестає бути пасивною і стає по-справжньому проактивною.

00:17:32.440 --> 00:17:36.680
З догадки замінюються наглядом, а нагляд – це те, що запобігає тихому накопиченню ризиків,

00:17:36.760 --> 00:17:38.280
які спливають лише через місяці.

00:17:38.460 --> 00:17:41.680
Вигляд з вежі спостереження не лише захищає від найгірших сценаріїв,

00:17:41.740 --> 00:17:44.280
він створює впевненість для команд продовжувати експерименти,

00:17:44.420 --> 00:17:46.180
знаючи, що хтось стежить за горизонтом.

00:17:46.300 --> 00:17:48.700
І це природно підводить нас до наступного питання.

00:17:48.900 --> 00:17:53.020
Якщо видимість настільки потужна, чому так багато організацій все ще припускаються

00:17:53.020 --> 00:17:56.580
класичних помилок управління, які нівелюють ці ж захисні механізми?

00:17:56.580 --> 00:18:04.240
Найбільші провали в управлінні агентами Co-Pilot виникають не через відсутність інструментів,

00:18:04.300 --> 00:18:07.060
а через наявність інструментів та їх неправильне використання.

00:18:07.260 --> 00:18:10.200
Більшість помилок, які я бачив в організаціях, пов'язані не з тим,

00:18:10.340 --> 00:18:14.060
що адміністратори не знали про центр адміністрування чи існування Co-Pilot Studio.

00:18:14.420 --> 00:18:17.860
Справжня проблема в тому, що функції вмикалися без роздумів про те,

00:18:17.860 --> 00:18:20.860
яка структура потрібна для їх належної роботи в масштабі.

00:18:20.980 --> 00:18:24.300
Це як дати кожному відділу власний набір ключів від спільного офісу,

00:18:24.300 --> 00:18:27.240
але ніколи не домовитися про те, хто замикає двері на ніч.

00:18:27.380 --> 00:18:31.480
Поширеною є модель, коли адміністратори вважають, що активація дорівнює управлінню.

00:18:31.640 --> 00:18:33.760
Нова функція з'являється в центрі адміністрування,

00:18:33.880 --> 00:18:36.600
перемикач вмикається і всі відчувають, що роботу виконано.

00:18:36.740 --> 00:18:39.260
Але технологія не встановлює межі самостійно.

00:18:39.420 --> 00:18:42.120
Якщо дозволи не чіткі, якщо моніторинг не увімкнено,

00:18:42.120 --> 00:18:45.120
або якщо відповідальність розділена між різними командами без координації,

00:18:45.820 --> 00:18:47.560
хаос проникає тихо і поступово.

00:18:47.560 --> 00:18:50.520
Найстрашніше те, що зазвичай це не вибухає одразу.

00:18:50.740 --> 00:18:55.180
Це накопичується поступово, а потім одна перевірка, інцидент чи запитання від регулятора

00:18:55.180 --> 00:18:57.840
раптом викривають, що те, що здавалося контролем,

00:18:57.980 --> 00:19:00.800
насправді було низкою прогалин, які чекали на виявлення.

00:19:00.940 --> 00:19:02.900
Перша пастка стосується дозволів.

00:19:02.900 --> 00:19:06.680
Якщо ніхто не визначив, кому дозволено створювати, публікувати або ділитися агентами,

00:19:06.780 --> 00:19:09.000
користувачі часто заповнюють цю прогалину самостійно.

00:19:09.000 --> 00:19:12.300
Це може призвести до дублювання агентів, публікації агентів у робочому середовищі

00:19:12.300 --> 00:19:15.600
без тестування або робочих процесів, що мають доступ до даних, яких не повинні мати.

00:19:15.780 --> 00:19:18.580
Без чітких меж ви отримуєте тіньовий каталог автоматизацій,

00:19:18.660 --> 00:19:21.720
про який IT-відділ дізнається лише тоді, коли щось ламається.

00:19:21.900 --> 00:19:25.480
Вмикати функції, не обмежуючи доступ до них, це не сприяння інноваціям,

00:19:25.580 --> 00:19:26.980
це видача незаповнених чеків.

00:19:27.140 --> 00:19:29.320
Друга пастка – це ігнорування моніторингу.

00:19:29.320 --> 00:19:33.080
Я не раз спілкувався з адміністраторами, які вважали, що налаштування дозволів достатньо,

00:19:33.160 --> 00:19:36.120
хоча насправді вони не мали жодного уявлення, чи працюють ці правила взагалі.

00:19:36.220 --> 00:19:38.260
Це робить їх сліпими до того, що відбувається.

00:19:38.420 --> 00:19:41.580
Якщо у вас не увімкнені журнали аудиту, ви не зможете довести, хто і що зробив.

00:19:41.700 --> 00:19:44.200
Якщо ви не стежите за показниками використання, ви не побачите,

00:19:44.360 --> 00:19:47.440
які агенти стають популярними або чи виглядають паттерни активності незвичними.

00:19:47.560 --> 00:19:49.640
Працювати без цих даних деякий час здається нормальним,

00:19:49.640 --> 00:19:52.160
поки зовнішній регулятор або навіть власна команда з комплеєнсу

00:19:52.160 --> 00:19:54.340
не поставить запитання, на які ви не зможете відповісти.

00:19:54.500 --> 00:19:56.980
Не узгоджені політики – це третя міна сповільненої дії.

00:19:57.140 --> 00:19:59.420
Один підрозділ організації може дотримуватися суворих правил,

00:19:59.480 --> 00:20:01.540
тоді як інший залишає публікацію повністю відкритою.

00:20:01.660 --> 00:20:05.220
Ця невідповідність гарантує хаотичну суміш контрольованих і неконтрольованих агентів,

00:20:05.340 --> 00:20:06.580
що існують в одному орендарі.

00:20:06.580 --> 00:20:09.580
Ззовні може здатися, що ви вирішили стратегічні питання,

00:20:09.740 --> 00:20:11.080
адже політики десь існують.

00:20:11.180 --> 00:20:14.520
Але командам з комплеєнсу та аудиторам безпеки потрібні докази не лише того,

00:20:14.680 --> 00:20:18.200
що політики існують, а й того, що вони однакові для всієї організації.

00:20:18.360 --> 00:20:22.360
Таку розбіжність ще важче виправдати, коли різні регіони підпадають під різні правила,

00:20:22.460 --> 00:20:24.480
а ваші власні політики не узгоджені з ними.

00:20:24.720 --> 00:20:27.260
Далі йде класичний випадок розрізненого володіння.

00:20:27.420 --> 00:20:31.140
Можливо, IT встановлює одне правило – команда безпеки передбачає інший рівень захисту,

00:20:36.580 --> 00:20:38.040
але на практиці ніхто цього не робить.

00:20:38.160 --> 00:20:40.720
Ця відсутність ясності призводить до сюрпризів, яких можна було уникнути,

00:20:40.840 --> 00:20:42.800
як от дублювання дозволів або агенти, щоб проскочили,

00:20:42.900 --> 00:20:44.900
бо не було зрозуміло, яка команда має остаточне право.

00:20:45.000 --> 00:20:47.740
Одна компанія, з якою я спілкувався, зіткнулася саме з цим.

00:20:47.920 --> 00:20:50.560
Вони дозволили кожному співробітнику вільно публікувати агентів.

00:20:50.720 --> 00:20:52.680
Спочатку це здавалося розширенням можливостей.

00:20:52.800 --> 00:20:54.780
Кожен міг експериментувати та впроваджувати покращення,

00:20:54.780 --> 00:20:57.220
але ніхто не пов'язав права на публікацію з журналами аудиту.

00:20:57.340 --> 00:20:59.300
Через місяці регулятор попросив докази того,

00:20:59.480 --> 00:21:02.280
хто розгорнув конкретні автоматизації, і у них не було нічого.

00:21:02.480 --> 00:21:04.740
Не було жодної історії дій відповідальної особи

00:21:04.740 --> 00:21:07.040
і жодної можливості захистити себе під час аудиту.

00:21:07.200 --> 00:21:09.520
Те, що починалося як спроба демократизувати автоматизацію,

00:21:09.600 --> 00:21:11.780
врешті-решт стало серйозною прогалиною у дотриманні вимог.

00:21:11.900 --> 00:21:13.860
Ці приклади підкреслюють, як дрібні помилки

00:21:13.860 --> 00:21:15.860
можуть швидко перетворитися на масштабні ризики.

00:21:15.860 --> 00:21:18.460
Неправильно налаштований дозвіл або неперевірений агент

00:21:18.460 --> 00:21:20.600
можуть здаватися дрібницею в пілотному проєкті,

00:21:20.680 --> 00:21:22.720
але в корпоративному масштабі цей самий недогляд

00:21:22.720 --> 00:21:25.620
множиться на сотні агентів, що працюють у невідомих куточках.

00:21:25.760 --> 00:21:27.400
Проблеми не зростають лінійно.

00:21:27.600 --> 00:21:30.440
Вони зростають експоненціально, оскільки кожен неконтрольований агент

00:21:30.440 --> 00:21:33.800
залишає відкритими питання щодо цілісності даних, надійності та безпеки.

00:21:33.960 --> 00:21:36.240
Хороша новина полягає в тому, що ці пастки добре відомі,

00:21:36.240 --> 00:21:37.400
які способи їх уникнення.

00:21:37.400 --> 00:21:40.420
Почніть із визначення базових принципів захисту в Центрі адміністрування.

00:21:40.560 --> 00:21:42.460
Чітко розподіліть ролі між тими, хто може створювати,

00:21:42.560 --> 00:21:43.620
і тими, хто може публікувати.

00:21:43.780 --> 00:21:45.560
Зробіть моніторинг обов'язковим, а не опціональним,

00:21:45.640 --> 00:21:48.340
щоб отримувати сповіщення до того, як ситуація стане серйозною проблемою.

00:21:48.520 --> 00:21:50.980
Дотримуйтесь послідовної політики навіть між регіонами,

00:21:51.100 --> 00:21:53.400
щоб впевнено відстоювати свою систему управління.

00:21:53.560 --> 00:21:56.100
І найголовніше, узгоджуйте дії зі своїми командами з безпеки

00:21:56.100 --> 00:21:57.640
та відповідності вимогам з першого дня.

00:21:57.640 --> 00:22:01.020
Виключення їх із процесу до останнього моменту майже завжди має зворотний ефект.

00:22:01.120 --> 00:22:03.820
Багато організацій уже створили дієві методики роботи.

00:22:03.940 --> 00:22:06.220
Контрольні списки для перегляду політик щокварталу – правила,

00:22:06.360 --> 00:22:09.440
що пов'язують аудит логів безпосередньо з правами публікації та структури,

00:22:09.520 --> 00:22:11.240
де інноваційні команди експериментують до того,

00:22:11.360 --> 00:22:13.200
як IT-відділ проводить офіційне впровадження.

00:22:13.360 --> 00:22:17.000
Використання цього досвіду означає, що вам не доведеться повторювати їхні помилки.

00:22:17.000 --> 00:22:19.160
Щоразу, коли інша компанія повідомляла про збій,

00:22:19.160 --> 00:22:21.980
це зазвичай ставилося тому, що запобіжники існували лише на папері,

00:22:22.040 --> 00:22:23.540
але не застосовувалися належним чином.

00:22:23.740 --> 00:22:26.460
Засвоївши їхні уроки завчасно, ви уникнете витрат.