WEBVTT

00:00:00.000 --> 00:00:07.060
Ви впроваджуєте Co-Pilot і чекаєте на хвилю продуктивності, але замість прориву отримуєте сплеск подій, пов'язаних із втратою даних, на 300%.

00:00:07.060 --> 00:00:12.320
Ми припускали, що ще розкриє наш геній, але насправді він здебільшого виявляє наші борги з доступом.

00:00:12.460 --> 00:00:21.140
Група «Всі у вашому середовищі SharePoint зараз є найбільшою дірою в безпеці вашої організації» – це відкриті двері, які ніхто не зачинив, бо дані були заховані в підвалі.

00:00:21.260 --> 00:00:23.460
Тепер ці дані стали доступними для обговорення.

00:00:23.460 --> 00:00:34.320
Ваша поточна стратегія маркування конфіденційності не є захистом. Це кладовище даних, яке приховує інформацію від тих, кому вона справді потрібна і зовсім не заважає щі надавати доступ до конфіденційних речей не тим людям.

00:00:34.540 --> 00:00:44.140
Це криза ізольованого спільного щі. Сьогодні ми переходимо від стримування до контексту, і ми врятуємо ваші інвестиції в щі, виправивши структурну брехню, що лежить в основі вашої моделі керування даними.

00:00:44.280 --> 00:00:45.640
Парадокс успадкування

00:00:45.640 --> 00:00:54.460
Фундаментальна вада більшості впровадженші – це неправильне розуміння того, як працює машина. І хоча ви можете думати, що Coopilot приймає рішення про те, хто що бачить, насправді це не так.

00:00:54.620 --> 00:01:02.480
Coopilot – це дзеркало, що успадковує вашу організаційну ентропію, тому він не створює нових доступів. Він просто використовує ті права доступу, які ви самі роздали багато років тому.

00:01:02.660 --> 00:01:04.760
Подумайте про це як про ефект прожектора.

00:01:04.760 --> 00:01:12.760
До появи ще надмірний доступ був прихованим, як безлад у файловій шафі, куди ніхто не зазирав, але ще робить це видимим на швидкості машини.

00:01:12.980 --> 00:01:21.140
Якщо молодший аналітик запитає резюме стратегічних змін, а ваша папка з M.E.A. налаштована як внутрішня, ще підсумує злиття, про яке ви ще не оголосили.

00:01:21.300 --> 00:01:24.540
Це не порушення, це особливість вашої власної архітектури.

00:01:24.700 --> 00:01:33.740
Реальність така, що ручне маркування в середньому підприємстві рідко перевищує 10%, бо ми десятиліттями просили користувачів позначати файли, а вони цього просто не робили.

00:01:33.740 --> 00:01:41.240
Ми покладалися на підхід «Налаштував і забув» щодо тегів чутливості, припускаючи, що якщо файл позначено як публічний, він таким і залишиться назавжди.

00:01:41.400 --> 00:01:47.640
Але дані динамічні, а це означає, що документ, який був публічним учора, сьогодні може містити відповідь із конфіденційними даними.

00:01:47.940 --> 00:01:59.220
Покладаючись на статичні мітки, ми створюємо невидимі бар'єри для міжвідомчої співпраці, і мітка «Суворо конфіденційно» на проектному плані може завадити маркетинговій команді побачити дату запуску, необхідну для роботи.

00:01:59.220 --> 00:02:05.360
Це створює бар'єри, і саме через них ваш щі виглядає не як помічник, а як суворий бібліотекар із обмеженнями.

00:02:05.500 --> 00:02:12.060
Ми побудували систему, виходячи з припущення, що можемо класифікувати світ один раз і на цьому закінчити, але в умовах співпраці ця модель не працює.

00:02:12.220 --> 00:02:19.320
Якщо мітки відсутні, щі бачать забагато, а якщо вони є, то часто бувають надто жорсткими, що заважає щі поєднувати дані між відділами.

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

00:02:31.300 --> 00:02:38.240
Парадокс успадкування означає, що рівень безпеки вашого щі дорівнює рівню помилки вашого найгіршого адміністратора SharePoint з 2014 року.

00:02:38.240 --> 00:02:48.080
Ми повинні визнати, що поточний підхід до класифікації зазнає невдачі, бо він статичний, ручний і розглядає дані як об'єкт, який треба замкнути, а не як актив для використання.

00:02:48.260 --> 00:02:54.400
Більшість організацій зараз перебувають у пілотному чистилищі, бо через шість тижнів зрозуміли, що їхні права доступу – це безлад.

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

00:03:02.460 --> 00:03:11.740
Зсув, який нам потрібен – це не кращі теги, а краща модель. Ми зосереджувалися на «що», тобто на самому файлі, але нам час зосередитися на «хто», «де» і «чому».

00:03:11.740 --> 00:03:18.520
Проблема не лише в тому, що мітки відсутні, а в тому, що наявні статичні і не враховують реалії того, як сьогодні виконується робота.

00:03:18.520 --> 00:03:29.680
Робота динамічна, тому наша безпека також має бути динамічною. Якщо ми це не виправимо, ЩІ продовжуватиме галюцинувати, бо дивиться на неправильні дані, або, що гірше, розкриватиме правду про дані, які мали бути приховані.

00:03:29.820 --> 00:03:34.240
Щоб виправити цикл переробки, ми повинні розглянути фундаментальну модель надання доступу.

00:03:34.380 --> 00:03:35.740
Висока ціна переробки.

00:03:35.900 --> 00:03:43.100
Ми говоримо про підвищення продуктивності завдяки ЩІ, ніби це валовий показник, і, бачачи заощаджені 9 годин на місяць, вважаємо, що справу зроблено.

00:03:43.100 --> 00:03:50.700
Але реальність значно складніша, бо зараз близько 40% часу, який ваші працівники заощаджують завдяки ЩІ, одразу втрачається на виправлення помилок ЩІ.

00:03:50.820 --> 00:03:52.780
Це приховане тертя ізольованих систем.

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

00:04:00.020 --> 00:04:07.520
Він вгадує. Він звертається до прихованих даних, які може бачити, як от старий чернетка зі спільної папки чи припущення в чаті, і будує відповідь на їхній основі.

00:04:07.520 --> 00:04:13.560
Результатом є цикл переробки, який непомітно виснажує ваш ROI. Ми насправді можемо кількісно оцінити цей цифровий бор.

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

00:04:21.720 --> 00:04:30.680
Задумайтеся про це. Ви платите за преміум-ліцензію, щоб заощадити час, але через те, що ваші дані розпорошені, найкращі працівники витрачають майже два повні робочі тижні лише на виправлення машинних помилок.

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

00:04:38.680 --> 00:04:45.840
Якщо ще закритий від системи обліку за старілою міткою конфіденційності, він заповнить цей вакуум будь-якою доступною інформацією.

00:04:46.000 --> 00:04:50.580
У таких відділах, як фінанси чи HR, це призводить до впевнено неправильних результатів.

00:04:50.740 --> 00:04:53.900
Фінансовий менеджер може попросити звіт про щоквартельні витрати.

00:04:53.900 --> 00:05:01.460
Якщо доступ до актуального експорту з ERP заблоковано, а недбалий робочий чернитковий файл лежить у відкритому каналі Teams, ще підсумує саме цей чернитку.

00:05:01.600 --> 00:05:08.020
Тоді менеджер витрачає 20 хвилин на пошук невідповідностей. Це тертя між загальною ефективністю та чистою цінністю.

00:05:08.200 --> 00:05:15.760
Якщо ви витрачаєте 2 хвилини на створення звіту, але 20 хвилин на перевірку цифр, бо ще не бачив джерела істини, ви нічого не виграли.

00:05:15.940 --> 00:05:18.700
Ви просто перенесли зусилля зі створення на виправлення.

00:05:18.700 --> 00:05:22.360
Ця переробка не просто незручність, це симптом структурного збою.

00:05:22.500 --> 00:05:28.680
Ми роками будували сховище даних для захисту інформації, але в епоху генеративного щі ці сховища працюють як пов'язки на очах.

00:05:28.820 --> 00:05:31.300
Коли щі з пов'язкою на очах, він починає галюцинувати.

00:05:31.500 --> 00:05:34.780
Він намагається догодити користувачеві, з'єднуючи факти, які не варто було з'єднувати.

00:05:34.940 --> 00:05:39.780
Ми бачимо організації, де рівень переробки настільки високий, що співробітники починають втрачати довіру до інструменту.

00:05:39.780 --> 00:05:44.520
Вони припиняють звертатися до щі за складним аналізом і повертаються до використання його лише для написання базових листів.

00:05:44.640 --> 00:05:47.640
Як тільки це стається, ваша стратегія впровадження щі зазнала краху.

00:05:47.760 --> 00:05:50.260
Ви платите за двигун, але користуєтеся лише фарами.

00:05:50.420 --> 00:05:54.800
Щоб виправити цей цикл переробки, ми маємо перестати дивитися на щі і почати дивитися на внутрішні процеси.

00:05:54.940 --> 00:06:00.680
Хороші дані існують, блискучі інсайти є, але вони заблоковані стіною застарілих дозволів і статичних міток,

00:06:00.800 --> 00:06:03.100
створених для світу, де пошук здійснювали люди.

00:06:03.100 --> 00:06:09.820
Нам потрібно перейти до моделі, де ще може бачити те, що йому потрібно, саме тоді, коли це потрібно, не порушуючи безпеку.

00:06:09.980 --> 00:06:15.120
Ми маємо переглянути базову модель надання доступу, адже доки ще працює з обмеженим контекстом,

00:06:15.240 --> 00:06:18.320
ви будете працювати понаднормово, виправляючи результати.

00:06:18.480 --> 00:06:21.520
Це витрати, які жодна організація не може ігнорувати.

00:06:21.860 --> 00:06:25.600
Відстримування до контексту, нам потрібно припинити сприймати безпеку як стіну.

00:06:26.000 --> 00:06:29.040
Десятиліттями галузь покладалася на модель захищеного периметра.

00:06:29.040 --> 00:06:32.400
Ви були або всередині мережі, або ззовні, але цей світ уже минув.

00:06:32.540 --> 00:06:34.180
Сьогодні периметр є проникним.

00:06:34.380 --> 00:06:38.880
Люди працюють з дому, використовують некеровані пристрої та співпрацюють із зовнішніми підрядниками.

00:06:39.020 --> 00:06:44.100
У цьому середовищі стара модель стримування, коли ви замикаєте дані в папку і вважаєте їх безпечними,

00:06:44.200 --> 00:06:46.600
бо папка приватна є небезпечною ілюзією.

00:06:46.740 --> 00:06:51.460
Це небезпечно, бо припускає, що загроза лише ззовні, але справжня загроза в епоху Coopilot –

00:06:51.460 --> 00:06:54.400
це внутрішнє розширення прав доступу, що накопичувалося роками.

00:06:54.580 --> 00:06:57.720
Ми повинні перейти від стратегії стримування до стратегії контексту.

00:06:57.880 --> 00:06:59.640
Стара модель була створена для структури.

00:06:59.820 --> 00:07:02.740
Вона припускала, що конфіденційність файлу – це фіксований атрибут.

00:07:02.900 --> 00:07:05.960
Ви позначили документ як конфіденційний, і на цьому історія закінчилася.

00:07:06.120 --> 00:07:08.840
Але в середовищі спільної роботи зіщить цей тех занадто грубий.

00:07:08.980 --> 00:07:10.540
Він дає недостатньо інформації.

00:07:10.540 --> 00:07:14.360
Він не враховує, хто запитує, який пристрій використовує або де знаходиться.

00:07:14.360 --> 00:07:18.180
Ось чому ми спостерігаємо масовий перехід до контролю доступу – DAC.

00:07:18.480 --> 00:07:21.500
Це не просто технічне оновлення, це філософський СУ.

00:07:21.660 --> 00:07:26.660
Він переносить процес прийняття рішень з моменту створення файлу на мілісекунду запиту даних.

00:07:26.760 --> 00:07:29.660
Це різниця між статичним замком і розумним датчиком.

00:07:29.660 --> 00:07:35.080
До 2026 року галузь вимагає переходу до контролю доступу на основі атрибутів – ABAC.

00:07:35.300 --> 00:07:37.780
Це основа сучасної структури ідентифікації.

00:07:37.980 --> 00:07:39.640
Замість покладання на одну статичну мітку,

00:07:39.740 --> 00:07:42.720
ABAC оцінює десяток різних сигналів ризику в реальному часі.

00:07:42.720 --> 00:07:46.020
Він дивиться на роль користувача, звісно, але також на стан його ноутбука.

00:07:46.180 --> 00:07:48.180
Він враховує його фізичне місцезнаходження.

00:07:48.360 --> 00:07:50.080
Він навіть аналізує його поведінку.

00:07:50.260 --> 00:07:53.160
Якщо користувач, який зазвичай відкриває лише маркетингові файли,

00:07:53.280 --> 00:07:56.900
раптом просить Coopilot узагальнити всю базу даних зарплат з кав'ярні в іншій країні,

00:07:56.900 --> 00:07:59.320
система не повинна дивитися лише на мітку чутливості.

00:07:59.440 --> 00:08:01.840
Вона має проаналізувати контекст і відповісти «ні».

00:08:01.840 --> 00:08:04.060
Так ми переходимо від питання, чи має файл мітку.

00:08:04.060 --> 00:08:06.460
Док чи повинен цей користувач бачити ці дані зараз?

00:08:06.580 --> 00:08:08.660
Це тонкий сув із величезними наслідками.

00:08:08.860 --> 00:08:11.080
Це дозволяє нам бути лояльнішими, коли ризик низький,

00:08:11.160 --> 00:08:12.980
і більше обмежувальними, коли ризик високий.

00:08:13.120 --> 00:08:16.740
Це руйнує інформаційні бар'єри, оскільки забезпечує доступ саме вчасно.

00:08:16.740 --> 00:08:21.120
Якщо маркетинговій команді потрібно побачити суворо конфіденційну дату запуску,

00:08:21.220 --> 00:08:26.220
система може надати їм тимчасовий доступ лише для читання на основі контексту їхнього проєкту,

00:08:26.340 --> 00:08:28.320
не порушуючи безпеку файлу назавжди.

00:08:28.320 --> 00:08:31.760
Це єдиний спосіб забезпечити міжвідомчу інтелектуальну взаємодію,

00:08:31.920 --> 00:08:36.320
яку обіцяє ЩІ, не перетворюючи вашу орендар на територію без контрольного доступу до даних.

00:08:36.460 --> 00:08:40.080
Рентабельність інвестицій ROI у такі динамічні системи вже стає очевидною.

00:08:40.220 --> 00:08:43.580
Організації, які відмовляються від статичних міток на користь контекстнозалежних моделей,

00:08:43.700 --> 00:08:46.940
отримують зниження страхових внесків від кіберризиків на від 15 до 30%.

00:08:46.940 --> 00:08:47.380
Чому?

00:08:47.600 --> 00:08:50.940
Тому що страховики знають, що статичні мітки легко обійти або проігнорувати.

00:08:50.940 --> 00:08:53.880
Динамічні системи, навпаки, набагато важче скомпрометувати.

00:08:53.880 --> 00:08:57.960
Вони забезпечують рівень безперервної перевірки, з яким статичні моделі просто не можуть зрівнятися.

00:08:58.100 --> 00:09:00.540
Вони зменшують радіус ураження скомпрометованого облікового запису,

00:09:00.600 --> 00:09:03.720
оскільки зловмисник не може просто успадкувати багаторічні недбалоналаштовані права доступу.

00:09:03.840 --> 00:09:05.400
Кожен запит – це нова оцінка.

00:09:05.580 --> 00:09:08.420
Кожна взаємодія – це нова можливість підтвердити довіру.

00:09:08.580 --> 00:09:11.320
Це не просто теоретичний сув для ІТ-архітекторів.

00:09:11.320 --> 00:09:14.300
Це вимога виживання для наступної хвилі агентного щі.

00:09:14.460 --> 00:09:17.220
Оскільки ми переходимо до агентів, що можуть діяти від нашого імені,

00:09:17.300 --> 00:09:19.980
призначати зустрічі, переказувати гроші чи оновлювати записи,

00:09:20.040 --> 00:09:22.580
ми не можемо покладатися на модель безпеки, налаштував і забув.

00:09:22.740 --> 00:09:25.440
Нам потрібна система, яка розуміє намір, що стоїть за дією.

00:09:25.580 --> 00:09:28.740
Нам потрібна безпека, яка є такою ж розумною, як і щі, який вона захищає.

00:09:28.880 --> 00:09:31.040
Це підводить нас до технічної дорожньої карти.

00:09:31.040 --> 00:09:34.200
Оскільки філософія змінюється, інструменти для її впровадження

00:09:34.200 --> 00:09:36.020
нарешті з'являються в екосистемі Перв'ю.

00:09:36.200 --> 00:09:41.200
У дорожній карті Перв'ю 2026 року сув у бік контекстно-залежного інтелекту

00:09:41.200 --> 00:09:44.240
нарешті відображається в архітектурі екосистеми Майкрософт.

00:09:44.320 --> 00:09:47.140
Ми виходимо з ери, коли Перв'ю був лише інструментом для звітності

00:09:47.140 --> 00:09:50.280
про відповідність вимогам, і до 2026 року він перетворився

00:09:50.280 --> 00:09:52.080
на діагностичний двигун реального часу.

00:09:52.200 --> 00:09:55.040
Однією з найважливіших змін є перехід до постійно активної діагностики

00:09:55.040 --> 00:09:56.880
для кінцевих точок DLP.

00:09:57.080 --> 00:09:59.900
Раніше усунення помилок політики означало тиждень листування

00:09:59.900 --> 00:10:03.120
між ІТ-відділом і користувачем, поки вони намагалися відтворити збій,

00:10:03.260 --> 00:10:04.220
що стався один раз.

00:10:04.340 --> 00:10:07.480
Тепер ці діагностичні трасування зберігаються локально на пристрої

00:10:07.480 --> 00:10:10.300
в безпечному стиснутому форматі протягом 90 днів.

00:10:10.460 --> 00:10:13.640
Це дозволяє системі аналізувати, чому конкретний файл був заблокований

00:10:13.640 --> 00:10:16.220
або чому мітка не застосувалася, не надсилаючи при цьому

00:10:16.220 --> 00:10:17.580
конфіденційний вміст у хмару.

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

00:10:20.880 --> 00:10:24.640
Ця діагностична потужність підсилюється інструментами пояснення на базі ЩІ.

00:10:24.780 --> 00:10:27.640
Ми досягли такого рівня складності, що адміністратори вже не можуть

00:10:27.640 --> 00:10:30.520
вручну відстежувати різницю між десятками різних політик DLP.

00:10:30.740 --> 00:10:33.580
Коли політика змінюється, система тепер генерує стислий виклад

00:10:33.580 --> 00:10:36.200
природною мовою, щоб пояснити, що саме було змінено

00:10:36.200 --> 00:10:38.080
і на які групи користувачів це впливає.

00:10:38.080 --> 00:10:41.180
Вона також показує потенційний вплив на спільні робочі процеси,

00:10:41.180 --> 00:10:43.140
що знижує ризик відхилення від політики.

00:10:43.280 --> 00:10:45.840
Це стається, коли правила безпеки стають настільки заплутаними,

00:10:45.980 --> 00:10:47.660
що починають блокувати правомірну роботу.

00:10:47.800 --> 00:10:50.900
Ці інструменти дозволяють команді безпеки сприяти розвитку,

00:10:51.020 --> 00:10:55.020
а не бути сторожами, надаючи чіткість правил з розумілою для бізнесу мовою.

00:10:55.200 --> 00:10:59.760
Важливою частиною цієї дорожньої карти є роль обмеженого пошуку SharePoint або RSS.

00:10:59.760 --> 00:11:02.380
Це аварійне гальмо для вашого впровадження ЩІ.

00:11:02.520 --> 00:11:05.060
Це дозволяє вам прямо виключити сайти з високим рівнем ризику,

00:11:05.060 --> 00:11:08.320
як от документи правління, дані про заробітну плату чи юридичні стратегії

00:11:08.320 --> 00:11:09.940
з використання як бази для Coopilot.

00:11:10.160 --> 00:11:12.860
Ще до того, як ви скористаєтеся міткою конфіденційності,

00:11:12.940 --> 00:11:17.360
ви можете використати RSS, щоб ЩІ просто не бачив найнебезпечніші ділянки вашого тенента.

00:11:17.540 --> 00:11:21.780
Це фундаментальний рівень захисту, який визнає, що не всі дані рівноцінні.

00:11:21.780 --> 00:11:25.380
Це дає вам простір для виправлення боргів із дозволами без необхідності

00:11:25.380 --> 00:11:27.100
зупиняти весь експеримент із ЩІ.

00:11:27.100 --> 00:11:30.780
Ми також спостерігаємо значне розширення можливостей автоматичного маркування.

00:11:30.940 --> 00:11:34.320
Мета на 2026 рік – забезпечити безпеку за замовчуванням.

00:11:34.440 --> 00:11:37.000
Ваші бібліотеки SharePoint вбільше не є пасивними сховищами,

00:11:37.080 --> 00:11:39.560
оскільки вони стають активними учасниками вашої безпеки.

00:11:39.680 --> 00:11:41.440
Коли файл завантажується в певну бібліотеку,

00:11:41.540 --> 00:11:45.460
мітка за замовчуванням для цієї бібліотеки автоматично застосовується до нього у стані спокою.

00:11:45.460 --> 00:11:47.820
Якщо файл містить типи конфіденційної інформації,

00:11:47.820 --> 00:11:51.000
система тепер може замінити вручну встановлені мітки з нижчим пріоритетом.

00:11:51.160 --> 00:11:54.520
Це закриває прогалину в охопленні, яка роками була проблемою для ручних систем.

00:11:54.720 --> 00:11:58.880
Це гарантує, що навіть якщо користувач забуде позначити документ, платформа його підстрахує.

00:11:59.060 --> 00:12:03.000
Це перехід від добровільної системи до обов'язкової автоматизованої інфраструктури.

00:12:03.000 --> 00:12:07.940
Для керування цим у масштабі ми все частіше покладаємося на граф АРІ для аналітики використання.

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

00:12:11.900 --> 00:12:18.020
Якщо команда R&D має 90% показник переробки через те, що вони не бачать інженерних специфікацій, дані це покажуть.

00:12:18.140 --> 00:12:23.640
Ми можемо виявити вузькі місця, де жорстка класифікація знижує продуктивність і коригувати політики в режимі реального часу.

00:12:23.820 --> 00:12:27.740
Саме так ми переходимо від реактивної безпеки до проактивної стратегії управління.

00:12:27.740 --> 00:12:33.240
Ми використовуємо дані, щоб бачити, де система дає збій, а не чекаємо на скарги користувачів чи виникнення витоку.

00:12:33.360 --> 00:12:37.340
Але навіть з найкращими інструментами стратегія зазнає невдачі без підтримки керівництва.

00:12:37.340 --> 00:12:44.860
Ви можете мати найсучасніше налаштування перв'ю у світі, але якщо ваше керівництво досі сприймає дані як щось, що треба накопичувати, ви ніколи не розкриєте повний потенціал ЩІ.

00:12:45.000 --> 00:12:48.000
Це підводить нас до нового виду ризику, що виникає знизу вгору.

00:12:48.140 --> 00:12:53.360
Це виклик, який походить не від хакерів чи зовнішніх загроз, а від ваших власних співробітників, які намагаються бути продуктивними.

00:12:53.500 --> 00:12:56.180
Ми повинні поговорити про Дилиму, громадянина-розробника.

00:12:56.400 --> 00:12:58.180
Дилима, громадянина-розробника.

00:12:58.180 --> 00:13:03.460
Зараз ми спостерігаємо найбільший вибух нерегулюваної творчості в історії корпоративних обчислень.

00:13:03.600 --> 00:13:07.860
Зараз в екосистемі Microsoft існує понад 1 мільйон низькокодових активів.

00:13:08.020 --> 00:13:13.260
Ми надали співробітникам можливість створювати власні додатки, власні потоки, а тепер і власні ЩІ-агенти.

00:13:13.460 --> 00:13:15.900
Але ці розширені можливості мають і зворотний бік.

00:13:16.040 --> 00:13:22.060
Ми перейшли від тіньових ІТ до тіньового ЩІ, де нетехнічні користувачі створюють складні агенти на основі некерованих і хаотичних даних.

00:13:22.060 --> 00:13:24.180
Це ризик розростання кількості агентів.

00:13:24.300 --> 00:13:29.060
Це трапляється, коли координатор маркетингу створює власний GPT у Co-Pilot Studio для роботи з запитами постачальників,

00:13:29.760 --> 00:13:35.060
але ненавмисно прив'язує цього агента до сайту SharePoint, що містить усі контракти, підписані компанією з 2012 року.

00:13:35.800 --> 00:13:38.520
Дилема полягає в тому, що ми не можемо просто це вимкнути.

00:13:38.680 --> 00:13:43.720
Якщо ви позбавите людей здатності вирішувати власні проблеми, ви вб'єте самогнучкість, яку має забезпечити ЩІ.

00:13:43.860 --> 00:13:46.720
Натомість ми маємо перейти до багаторівневої моделі управління.

00:13:46.720 --> 00:13:53.080
Не всі агенти однакові. Низькокодовий інструмент, який допомагає окремій особі підсумовувати власні листи за допомогою стандартних конекторів Teams,

00:13:53.220 --> 00:13:56.300
є активом з низьким рівнем ризику, який має оминати процес суворої перевірки.

00:13:56.420 --> 00:14:02.380
Але якщо агент звертається до системи записів, як-от Dataverse або чутлива SQL-база, йому потрібен контролер доступу.

00:14:02.520 --> 00:14:07.960
Ми повинні припинити розглядати розробку користувачами як єдину категорію і почати сприймати її як спектр ризиків.

00:14:07.960 --> 00:14:14.080
Галузь переходить від старого поняття громадянської розробки до того, що ми тепер називаємо персональним будівництвом за підтримки ЩІ.

00:14:14.220 --> 00:14:16.000
Різниця тонка, але вирішальна.

00:14:16.160 --> 00:14:20.580
У старому світі користувач був розробником, а в новому світі користувач – це оркестратор.

00:14:20.720 --> 00:14:23.280
Вони спрямовують ЩІ на створення рішення для себе.

00:14:23.480 --> 00:14:27.060
Це робить запобіжники в Co-Pilot Studio уважливішими за сам код.

00:14:27.060 --> 00:14:35.400
Нам потрібно впровадити рівні модерації контенту, які не дозволять цим агентам галюцинувати або виточувати дані через атаки ін'єкціями промптів, про які користувач навіть не здогадувався.

00:14:35.540 --> 00:14:42.180
Ви б не дозволили літньому стажеру писати ваші правила Брандмауера, тому ми не повинні дозволяти їм створювати агентів, які мають доступ на читання до всієї корпоративної віки.

00:14:42.340 --> 00:14:43.560
Рішення є структурним.

00:14:43.720 --> 00:14:48.300
Нам потрібно автоматизувати дотримання політик запобігання втраті даних у межах низькокодового середовища.

00:14:48.300 --> 00:14:54.560
Якщо користувач спробує підключити я і агента до зовнішнього некерованого облікового запису Dropbox, система повинна миттєво це заблокувати.

00:14:54.740 --> 00:15:02.940
Якщо вони спробують створити бота, який звертається до бібліотеки з грифом «Суворо конфіденційно розгортання», має автоматично ініціювати ручну перевірку командою IT-операцій.

00:15:03.040 --> 00:15:05.700
Це створює шлях для інновацій, безпечний за задумом.

00:15:05.860 --> 00:15:12.520
Це дозволяє розробникам будувати, гарантуючи, що найчутливіші активи організації залишаються за контекстно-залежними стінами, про які ми говорили.

00:15:12.520 --> 00:15:16.920
Ми переходимо в епоху, де кожен співробітник – потенційний архітектор інтелекту компанії.

00:15:17.080 --> 00:15:22.640
Це величезна конкурентна перевага, якщо нею правильно керувати, але катастрофічна відповідальність, якщо пустити все на самоплив.

00:15:22.800 --> 00:15:25.440
Мета – не зупинити поширення, а керувати потоком.

00:15:25.600 --> 00:15:32.420
Ми повинні надати розробникам-ентузіастам заздалегідь затверджені шаблони та безпечні зони, де вони можуть експериментувати, не ризикуючи найціннішими активами.

00:15:32.560 --> 00:15:37.600
Це гарантує, що створені ними агенти є продовженням нашої стратегії управління, а не винятком із неї.

00:15:42.520 --> 00:15:46.540
Ви не можете керувати мільйоном агентів із підвалу. Вам потрібна підтримка керівництва.

00:15:46.700 --> 00:15:49.900
Час перенести розмову із серверної до зали засідань ради директорів.

00:15:50.080 --> 00:15:52.260
Стратегія отримання – схвалення керівництва.

00:15:52.420 --> 00:15:57.760
Технічна битва за контекстно-залежну безпеку виграється в коді, але стратегічна – досі програється в залі засідань.

00:15:57.920 --> 00:16:01.820
Роками управління ідентифікацією та доступом вважалося лише технічною проблемою.

00:16:01.820 --> 00:16:05.820
Це було справою команд у підвалах, поки бізнес зосереджувався на зростанній.

00:16:05.820 --> 00:16:13.200
У 2026 році таке мислення – це тягар. Ми маємо змінити всю розмову, бо ідентифікація – це більше не просто логін.

00:16:13.360 --> 00:16:15.980
Це основна площина контролю для цифрової довіри.

00:16:16.140 --> 00:16:21.480
Якщо ваше керівництво цього не розуміє, впровадження штучного інтелекту залишиться серією дорогих, розрізнених експериментів.

00:16:21.600 --> 00:16:24.120
Ми повинні припинити подавати безпеку як центр витрат.

00:16:24.120 --> 00:16:27.360
Натомість ми маємо представити її як інструмент прискорення прийняття рішень.

00:16:27.500 --> 00:16:29.760
Більшість керівників сприймають безпеку як низку відмов.

00:16:29.960 --> 00:16:31.600
Ні, ви не можете використовувати цей інструмент.

00:16:31.860 --> 00:16:33.500
Ні, ви не можете надати доступ до цього файлу.

00:16:33.620 --> 00:16:35.920
Але сучасна інфраструктура ідентифікації діє навпаки.

00:16:36.140 --> 00:16:38.780
Вона дає так, що дозволяє бізнесу рухатися швидше.

00:16:38.980 --> 00:16:44.400
Маючи безперервну контекстно-залежну перевірку, ви можете підключити нового партнера за години, а не тижні.

00:16:44.400 --> 00:16:48.280
Ви можете надати консультанту доступ рівно до того, що потрібно для триденного проєкту,

00:16:48.280 --> 00:16:52.000
а потім спостерігати, як доступ автоматично зникає, щойно він закінчить роботу.

00:16:52.140 --> 00:16:54.140
Це не про обмеження, це про гнучкість.

00:16:54.280 --> 00:16:59.880
Це про створення середовища, де потрібні люди можуть діяти на основі потрібної інформації без тертя ручних узгоджень.

00:17:00.040 --> 00:17:02.720
Ми бачимо ціну ігнорування цього на ринку МІА.

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

00:17:10.280 --> 00:17:15.640
Коли зріла компанія купує конкурента, вона інтегрує новий персонал у свою щі екосистему за лічені дні,

00:17:15.780 --> 00:17:19.860
тоді як для компаній із низькою культурою ідентифікації це розтягується на місяці,

00:17:20.000 --> 00:17:24.080
виснажуючи цінність і гальмуючи синергію, заради якої було здійснено злиття.

00:17:24.260 --> 00:17:28.240
Незадовільне керування ідентифікацією – це прямий удар по вартості компанії після злиття.

00:17:28.380 --> 00:17:32.100
Це тягар на балансі, який більшість CEO ще навіть не оцінили кількісно.

00:17:32.100 --> 00:17:37.760
Саме тому запит на збільшення бюджету на від 5 до 20% для інфраструктури ідентифікації – це не просто витрати на безпеку.

00:17:37.880 --> 00:17:39.840
Це інвестиція в інфраструктуру зростання.

00:17:40.000 --> 00:17:44.000
Це цифровий аналог будівництва швидкісної залізниці між вашими ізольованими сховищами даних.

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

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

00:17:58.940 --> 00:18:03.080
Потрібно змінити фокус із захисту даних на керування потоками інтелекту.

00:18:03.200 --> 00:18:08.740
Перехід до контекстно-залежної моделі – це єдиний спосіб побудувати стійке підприємство в епоху агентного щі.

00:18:08.860 --> 00:18:12.800
Це дозволяє організації масштабувати свій інтелект, не масштабуючи ризики.

00:18:12.960 --> 00:18:17.700
Коли топ-менеджмент розглядає доступ як стратегічний актив, змінюється вся культура компанії.

00:18:17.700 --> 00:18:22.860
Безпека стає спільною відповідальністю, а дані – ліквідним ресурсом, а не таємницею, яку ховають.

00:18:23.000 --> 00:18:32.340
Час перестати дивитися на вартість інструментів і почати рахувати вартість тертя, адже в епоху щі перемагає найшвидший, а ви не можете бути швидкими, якщо ваші дані замкнені в брехні.

00:18:32.500 --> 00:18:34.960
Ваш мандат на 2026 рік чіткий.

00:18:35.140 --> 00:18:38.660
Ви повинні перевірити свій борг прав доступу перш ніж масштабувати ліцензії на щі.

00:18:38.780 --> 00:18:41.740
Технології готові, але ваша архітектура, скоріше за все, ні.

00:18:41.740 --> 00:18:48.720
Завдання на наступний квартал – впровадити обов'язкове автомаркування та провести 90-денне очищення сайту, щоб закрити найочевидніші прогалини.

00:18:48.840 --> 00:18:50.100
Припиніть накопичення.

00:18:50.320 --> 00:18:51.240
Запустіть потік.

00:18:51.420 --> 00:18:58.280
Якщо хочете поділитися прогресом у руйнуванні ізоляції даних або обговорити перехід до контекстнозалежних прав доступу, зв'яжіться з Мірко Пітерсом у LinkedIn.

00:18:58.540 --> 00:19:00.840
Побудуймо модель інтелекту, яка працює насправді.

00:19:00.960 --> 00:19:03.080
Підписуйтесь на детальніші огляди майбутнього роботи.

00:19:03.220 --> 00:19:04.200
Залишайтеся в безпеці.

00:19:04.380 --> 00:19:05.460
Залишайтеся продуктивними.

00:19:05.460 --> 00:19:35.440
Дякую за перегляд!