Ви впроваджуєте Co-Pilot і чекаєте на хвилю продуктивності, але замість прориву отримуєте сплеск подій, пов'язаних із втратою даних, на 300%. Ми припускали, що ще розкриє наш геній, але насправді він здебільшого виявляє наші борги з доступом. Група «Всі у вашому середовищі SharePoint зараз є найбільшою дірою в безпеці вашої організації» – це відкриті двері, які ніхто не зачинив, бо дані були заховані в підвалі. Тепер ці дані стали доступними для обговорення. Ваша поточна стратегія маркування конфіденційності не є захистом. Це кладовище даних, яке приховує інформацію від тих, кому вона справді потрібна і зовсім не заважає щі надавати доступ до конфіденційних речей не тим людям. Це криза ізольованого спільного щі. Сьогодні ми переходимо від стримування до контексту, і ми врятуємо ваші інвестиції в щі, виправивши структурну брехню, що лежить в основі вашої моделі керування даними. Парадокс успадкування Фундаментальна вада більшості впровадженші – це неправильне розуміння того, як працює машина. І хоча ви можете думати, що Coopilot приймає рішення про те, хто що бачить, насправді це не так.

Coopilot – це дзеркало, що успадковує вашу організаційну ентропію, тому він не створює нових доступів. Він просто використовує ті права доступу, які ви самі роздали багато років тому. Подумайте про це як про ефект прожектора. До появи ще надмірний доступ був прихованим, як безлад у файловій шафі, куди ніхто не зазирав, але ще робить це видимим на швидкості машини. Якщо молодший аналітик запитає резюме стратегічних змін, а ваша папка з M.E.A. налаштована як внутрішня, ще підсумує злиття, про яке ви ще не оголосили. Це не порушення, це особливість вашої власної архітектури. Реальність така, що ручне маркування в середньому підприємстві рідко перевищує 10%, бо ми десятиліттями просили користувачів позначати файли, а вони цього просто не робили. Ми покладалися на підхід «Налаштував і забув» щодо тегів чутливості, припускаючи, що якщо файл позначено як публічний, він таким і залишиться назавжди.

Але дані динамічні, а це означає, що документ, який був публічним учора, сьогодні може містити відповідь із конфіденційними даними. Покладаючись на статичні мітки, ми створюємо невидимі бар'єри для міжвідомчої співпраці, і мітка «Суворо конфіденційно» на проектному плані може завадити маркетинговій команді побачити дату запуску, необхідну для роботи. Це створює бар'єри, і саме через них ваш щі виглядає не як помічник, а як суворий бібліотекар із обмеженнями. Ми побудували систему, виходячи з припущення, що можемо класифікувати світ один раз і на цьому закінчити, але в умовах співпраці ця модель не працює. Якщо мітки відсутні, щі бачать забагато, а якщо вони є, то часто бувають надто жорсткими, що заважає щі поєднувати дані між відділами. Зараз ми бачимо величезний розрив між очікуваннями керівництва від щі та можливостями архітектури даних, а ви не можете мати високоефективного щі-агента, якщо ваші дані замкнені в ієрархіях папок стилю 90-х.

Парадокс успадкування означає, що рівень безпеки вашого щі дорівнює рівню помилки вашого найгіршого адміністратора SharePoint з 2014 року. Ми повинні визнати, що поточний підхід до класифікації зазнає невдачі, бо він статичний, ручний і розглядає дані як об'єкт, який треба замкнути, а не як актив для використання. Більшість організацій зараз перебувають у пілотному чистилищі, бо через шість тижнів зрозуміли, що їхні права доступу – це безлад. Вони намагаються виправити це додаванням нових міток, але нові мітки у зламаній системі лише створюють більше ізольованих сховищ і не вирішують основну проблему видимості. Зсув, який нам потрібен – це не кращі теги, а краща модель. Ми зосереджувалися на «що», тобто на самому файлі, але нам час зосередитися на «хто», «де» і «чому». Проблема не лише в тому, що мітки відсутні, а в тому, що наявні статичні і не враховують реалії того, як сьогодні виконується робота.

Робота динамічна, тому наша безпека також має бути динамічною. Якщо ми це не виправимо, ЩІ продовжуватиме галюцинувати, бо дивиться на неправильні дані, або, що гірше, розкриватиме правду про дані, які мали бути приховані. Щоб виправити цикл переробки, ми повинні розглянути фундаментальну модель надання доступу. Висока ціна переробки. Ми говоримо про підвищення продуктивності завдяки ЩІ, ніби це валовий показник, і, бачачи заощаджені 9 годин на місяць, вважаємо, що справу зроблено. Але реальність значно складніша, бо зараз близько 40% часу, який ваші працівники заощаджують завдяки ЩІ, одразу втрачається на виправлення помилок ЩІ. Це приховане тертя ізольованих систем. Коли Coopilot не має доступу до якісних даних, фіналізованого контракту, фактичного бюджету чи перевіреного плану проєкту, він не зупиняється. Він вгадує. Він звертається до прихованих даних, які може бачити, як от старий чернетка зі спільної папки чи припущення в чаті, і будує відповідь на їхній основі.

Результатом є цикл переробки, який непомітно виснажує ваш ROI. Ми насправді можемо кількісно оцінити цей цифровий бор. Для ваших найкращих фахівців, досвідчених користувачів, які найактивніше використовують ці інструменти, ця переробка означає близько півтора тижня втраченого часу на рік. Задумайтеся про це. Ви платите за преміум-ліцензію, щоб заощадити час, але через те, що ваші дані розпорошені, найкращі працівники витрачають майже два повні робочі тижні лише на виправлення машинних помилок. По суті, вони працюють як високооплачувані коректори для системи, що мала бути їхнім другим пілотом. Це стається тому, що жорстка класифікація створює вакуум. Якщо ще закритий від системи обліку за старілою міткою конфіденційності, він заповнить цей вакуум будь-якою доступною інформацією. У таких відділах, як фінанси чи HR, це призводить до впевнено неправильних результатів. Фінансовий менеджер може попросити звіт про щоквартельні витрати.

Якщо доступ до актуального експорту з ERP заблоковано, а недбалий робочий чернитковий файл лежить у відкритому каналі Teams, ще підсумує саме цей чернитку. Тоді менеджер витрачає 20 хвилин на пошук невідповідностей. Це тертя між загальною ефективністю та чистою цінністю. Якщо ви витрачаєте 2 хвилини на створення звіту, але 20 хвилин на перевірку цифр, бо ще не бачив джерела істини, ви нічого не виграли. Ви просто перенесли зусилля зі створення на виправлення. Ця переробка не просто незручність, це симптом структурного збою. Ми роками будували сховище даних для захисту інформації, але в епоху генеративного щі ці сховища працюють як пов'язки на очах. Коли щі з пов'язкою на очах, він починає галюцинувати. Він намагається догодити користувачеві, з'єднуючи факти, які не варто було з'єднувати. Ми бачимо організації, де рівень переробки настільки високий, що співробітники починають втрачати довіру до інструменту.

Вони припиняють звертатися до щі за складним аналізом і повертаються до використання його лише для написання базових листів. Як тільки це стається, ваша стратегія впровадження щі зазнала краху. Ви платите за двигун, але користуєтеся лише фарами. Щоб виправити цей цикл переробки, ми маємо перестати дивитися на щі і почати дивитися на внутрішні процеси. Хороші дані існують, блискучі інсайти є, але вони заблоковані стіною застарілих дозволів і статичних міток, створених для світу, де пошук здійснювали люди. Нам потрібно перейти до моделі, де ще може бачити те, що йому потрібно, саме тоді, коли це потрібно, не порушуючи безпеку. Ми маємо переглянути базову модель надання доступу, адже доки ще працює з обмеженим контекстом, ви будете працювати понаднормово, виправляючи результати. Це витрати, які жодна організація не може ігнорувати. Відстримування до контексту, нам потрібно припинити сприймати безпеку як стіну.

Десятиліттями галузь покладалася на модель захищеного периметра. Ви були або всередині мережі, або ззовні, але цей світ уже минув. Сьогодні периметр є проникним. Люди працюють з дому, використовують некеровані пристрої та співпрацюють із зовнішніми підрядниками. У цьому середовищі стара модель стримування, коли ви замикаєте дані в папку і вважаєте їх безпечними, бо папка приватна є небезпечною ілюзією. Це небезпечно, бо припускає, що загроза лише ззовні, але справжня загроза в епоху Coopilot – це внутрішнє розширення прав доступу, що накопичувалося роками. Ми повинні перейти від стратегії стримування до стратегії контексту. Стара модель була створена для структури. Вона припускала, що конфіденційність файлу – це фіксований атрибут. Ви позначили документ як конфіденційний, і на цьому історія закінчилася. Але в середовищі спільної роботи зіщить цей тех занадто грубий. Він дає недостатньо інформації.

Він не враховує, хто запитує, який пристрій використовує або де знаходиться. Ось чому ми спостерігаємо масовий перехід до контролю доступу – DAC. Це не просто технічне оновлення, це філософський СУ. Він переносить процес прийняття рішень з моменту створення файлу на мілісекунду запиту даних. Це різниця між статичним замком і розумним датчиком. До 2026 року галузь вимагає переходу до контролю доступу на основі атрибутів – ABAC. Це основа сучасної структури ідентифікації. Замість покладання на одну статичну мітку, ABAC оцінює десяток різних сигналів ризику в реальному часі. Він дивиться на роль користувача, звісно, але також на стан його ноутбука. Він враховує його фізичне місцезнаходження. Він навіть аналізує його поведінку. Якщо користувач, який зазвичай відкриває лише маркетингові файли, раптом просить Coopilot узагальнити всю базу даних зарплат з кав'ярні в іншій країні, система не повинна дивитися лише на мітку чутливості.

Вона має проаналізувати контекст і відповісти «ні». Так ми переходимо від питання, чи має файл мітку. Док чи повинен цей користувач бачити ці дані зараз? Це тонкий сув із величезними наслідками. Це дозволяє нам бути лояльнішими, коли ризик низький, і більше обмежувальними, коли ризик високий. Це руйнує інформаційні бар'єри, оскільки забезпечує доступ саме вчасно. Якщо маркетинговій команді потрібно побачити суворо конфіденційну дату запуску, система може надати їм тимчасовий доступ лише для читання на основі контексту їхнього проєкту, не порушуючи безпеку файлу назавжди. Це єдиний спосіб забезпечити міжвідомчу інтелектуальну взаємодію, яку обіцяє ЩІ, не перетворюючи вашу орендар на територію без контрольного доступу до даних. Рентабельність інвестицій ROI у такі динамічні системи вже стає очевидною. Організації, які відмовляються від статичних міток на користь контекстнозалежних моделей, отримують зниження страхових внесків від кіберризиків на від 15 до 30%.

Чому? Тому що страховики знають, що статичні мітки легко обійти або проігнорувати. Динамічні системи, навпаки, набагато важче скомпрометувати. Вони забезпечують рівень безперервної перевірки, з яким статичні моделі просто не можуть зрівнятися. Вони зменшують радіус ураження скомпрометованого облікового запису, оскільки зловмисник не може просто успадкувати багаторічні недбалоналаштовані права доступу. Кожен запит – це нова оцінка. Кожна взаємодія – це нова можливість підтвердити довіру. Це не просто теоретичний сув для ІТ-архітекторів. Це вимога виживання для наступної хвилі агентного щі. Оскільки ми переходимо до агентів, що можуть діяти від нашого імені, призначати зустрічі, переказувати гроші чи оновлювати записи, ми не можемо покладатися на модель безпеки, налаштував і забув. Нам потрібна система, яка розуміє намір, що стоїть за дією. Нам потрібна безпека, яка є такою ж розумною, як і щі, який вона захищає.

Це підводить нас до технічної дорожньої карти. Оскільки філософія змінюється, інструменти для її впровадження нарешті з'являються в екосистемі Перв'ю. У дорожній карті Перв'ю 2026 року сув у бік контекстно-залежного інтелекту нарешті відображається в архітектурі екосистеми Майкрософт. Ми виходимо з ери, коли Перв'ю був лише інструментом для звітності про відповідність вимогам, і до 2026 року він перетворився на діагностичний двигун реального часу. Однією з найважливіших змін є перехід до постійно активної діагностики для кінцевих точок DLP. Раніше усунення помилок політики означало тиждень листування між ІТ-відділом і користувачем, поки вони намагалися відтворити збій, що стався один раз. Тепер ці діагностичні трасування зберігаються локально на пристрої в безпечному стиснутому форматі протягом 90 днів. Це дозволяє системі аналізувати, чому конкретний файл був заблокований або чому мітка не застосувалася, не надсилаючи при цьому конфіденційний вміст у хмару.

Це локальна видимість у поєднанні з глобальним виконанням правил. Ця діагностична потужність підсилюється інструментами пояснення на базі ЩІ. Ми досягли такого рівня складності, що адміністратори вже не можуть вручну відстежувати різницю між десятками різних політик DLP. Коли політика змінюється, система тепер генерує стислий виклад природною мовою, щоб пояснити, що саме було змінено і на які групи користувачів це впливає. Вона також показує потенційний вплив на спільні робочі процеси, що знижує ризик відхилення від політики. Це стається, коли правила безпеки стають настільки заплутаними, що починають блокувати правомірну роботу. Ці інструменти дозволяють команді безпеки сприяти розвитку, а не бути сторожами, надаючи чіткість правил з розумілою для бізнесу мовою. Важливою частиною цієї дорожньої карти є роль обмеженого пошуку SharePoint або RSS. Це аварійне гальмо для вашого впровадження ЩІ.

Це дозволяє вам прямо виключити сайти з високим рівнем ризику, як от документи правління, дані про заробітну плату чи юридичні стратегії з використання як бази для Coopilot. Ще до того, як ви скористаєтеся міткою конфіденційності, ви можете використати RSS, щоб ЩІ просто не бачив найнебезпечніші ділянки вашого тенента. Це фундаментальний рівень захисту, який визнає, що не всі дані рівноцінні. Це дає вам простір для виправлення боргів із дозволами без необхідності зупиняти весь експеримент із ЩІ. Ми також спостерігаємо значне розширення можливостей автоматичного маркування. Мета на 2026 рік – забезпечити безпеку за замовчуванням. Ваші бібліотеки SharePoint вбільше не є пасивними сховищами, оскільки вони стають активними учасниками вашої безпеки. Коли файл завантажується в певну бібліотеку, мітка за замовчуванням для цієї бібліотеки автоматично застосовується до нього у стані спокою. Якщо файл містить типи конфіденційної інформації, система тепер може замінити вручну встановлені мітки з нижчим пріоритетом.

Це закриває прогалину в охопленні, яка роками була проблемою для ручних систем. Це гарантує, що навіть якщо користувач забуде позначити документ, платформа його підстрахує. Це перехід від добровільної системи до обов'язкової автоматизованої інфраструктури. Для керування цим у масштабі ми все частіше покладаємося на граф АРІ для аналітики використання. Тепер ми можемо зазирнути глибше, щоб побачити, які саме відділи ізольовані. Якщо команда R&D має 90% показник переробки через те, що вони не бачать інженерних специфікацій, дані це покажуть. Ми можемо виявити вузькі місця, де жорстка класифікація знижує продуктивність і коригувати політики в режимі реального часу. Саме так ми переходимо від реактивної безпеки до проактивної стратегії управління. Ми використовуємо дані, щоб бачити, де система дає збій, а не чекаємо на скарги користувачів чи виникнення витоку. Але навіть з найкращими інструментами стратегія зазнає невдачі без підтримки керівництва.

Ви можете мати найсучасніше налаштування перв'ю у світі, але якщо ваше керівництво досі сприймає дані як щось, що треба накопичувати, ви ніколи не розкриєте повний потенціал ЩІ. Це підводить нас до нового виду ризику, що виникає знизу вгору. Це виклик, який походить не від хакерів чи зовнішніх загроз, а від ваших власних співробітників, які намагаються бути продуктивними. Ми повинні поговорити про Дилиму, громадянина-розробника. Дилима, громадянина-розробника. Зараз ми спостерігаємо найбільший вибух нерегулюваної творчості в історії корпоративних обчислень. Зараз в екосистемі Microsoft існує понад 1 мільйон низькокодових активів. Ми надали співробітникам можливість створювати власні додатки, власні потоки, а тепер і власні ЩІ-агенти. Але ці розширені можливості мають і зворотний бік. Ми перейшли від тіньових ІТ до тіньового ЩІ, де нетехнічні користувачі створюють складні агенти на основі некерованих і хаотичних даних.

Це ризик розростання кількості агентів. Це трапляється, коли координатор маркетингу створює власний GPT у Co-Pilot Studio для роботи з запитами постачальників, але ненавмисно прив'язує цього агента до сайту SharePoint, що містить усі контракти, підписані компанією з 2012 року. Дилема полягає в тому, що ми не можемо просто це вимкнути. Якщо ви позбавите людей здатності вирішувати власні проблеми, ви вб'єте самогнучкість, яку має забезпечити ЩІ. Натомість ми маємо перейти до багаторівневої моделі управління. Не всі агенти однакові. Низькокодовий інструмент, який допомагає окремій особі підсумовувати власні листи за допомогою стандартних конекторів Teams, є активом з низьким рівнем ризику, який має оминати процес суворої перевірки. Але якщо агент звертається до системи записів, як-от Dataverse або чутлива SQL-база, йому потрібен контролер доступу. Ми повинні припинити розглядати розробку користувачами як єдину категорію і почати сприймати її як спектр ризиків.

Галузь переходить від старого поняття громадянської розробки до того, що ми тепер називаємо персональним будівництвом за підтримки ЩІ. Різниця тонка, але вирішальна. У старому світі користувач був розробником, а в новому світі користувач – це оркестратор. Вони спрямовують ЩІ на створення рішення для себе. Це робить запобіжники в Co-Pilot Studio уважливішими за сам код. Нам потрібно впровадити рівні модерації контенту, які не дозволять цим агентам галюцинувати або виточувати дані через атаки ін'єкціями промптів, про які користувач навіть не здогадувався. Ви б не дозволили літньому стажеру писати ваші правила Брандмауера, тому ми не повинні дозволяти їм створювати агентів, які мають доступ на читання до всієї корпоративної віки. Рішення є структурним. Нам потрібно автоматизувати дотримання політик запобігання втраті даних у межах низькокодового середовища. Якщо користувач спробує підключити я і агента до зовнішнього некерованого облікового запису Dropbox, система повинна миттєво це заблокувати.

Якщо вони спробують створити бота, який звертається до бібліотеки з грифом «Суворо конфіденційно розгортання», має автоматично ініціювати ручну перевірку командою IT-операцій. Це створює шлях для інновацій, безпечний за задумом. Це дозволяє розробникам будувати, гарантуючи, що найчутливіші активи організації залишаються за контекстно-залежними стінами, про які ми говорили. Ми переходимо в епоху, де кожен співробітник – потенційний архітектор інтелекту компанії. Це величезна конкурентна перевага, якщо нею правильно керувати, але катастрофічна відповідальність, якщо пустити все на самоплив. Мета – не зупинити поширення, а керувати потоком. Ми повинні надати розробникам-ентузіастам заздалегідь затверджені шаблони та безпечні зони, де вони можуть експериментувати, не ризикуючи найціннішими активами. Це гарантує, що створені ними агенти є продовженням нашої стратегії управління, а не винятком із неї.

Ви не можете керувати мільйоном агентів із підвалу. Вам потрібна підтримка керівництва. Час перенести розмову із серверної до зали засідань ради директорів. Стратегія отримання – схвалення керівництва. Технічна битва за контекстно-залежну безпеку виграється в коді, але стратегічна – досі програється в залі засідань. Роками управління ідентифікацією та доступом вважалося лише технічною проблемою. Це було справою команд у підвалах, поки бізнес зосереджувався на зростанній. У 2026 році таке мислення – це тягар. Ми маємо змінити всю розмову, бо ідентифікація – це більше не просто логін. Це основна площина контролю для цифрової довіри. Якщо ваше керівництво цього не розуміє, впровадження штучного інтелекту залишиться серією дорогих, розрізнених експериментів. Ми повинні припинити подавати безпеку як центр витрат. Натомість ми маємо представити її як інструмент прискорення прийняття рішень. Більшість керівників сприймають безпеку як низку відмов.

Ні, ви не можете використовувати цей інструмент. Ні, ви не можете надати доступ до цього файлу. Але сучасна інфраструктура ідентифікації діє навпаки. Вона дає так, що дозволяє бізнесу рухатися швидше. Маючи безперервну контекстно-залежну перевірку, ви можете підключити нового партнера за години, а не тижні. Ви можете надати консультанту доступ рівно до того, що потрібно для триденного проєкту, а потім спостерігати, як доступ автоматично зникає, щойно він закінчить роботу. Це не про обмеження, це про гнучкість. Це про створення середовища, де потрібні люди можуть діяти на основі потрібної інформації без тертя ручних узгоджень. Ми бачимо ціну ігнорування цього на ринку МІА. Виникає величезний розрив у зрілості між організаціями, які опанували керування ідентифікацією і тими, що досі покладаються на застарілі моделі. Коли зріла компанія купує конкурента, вона інтегрує новий персонал у свою щі екосистему за лічені дні, тоді як для компаній із низькою культурою ідентифікації це розтягується на місяці, виснажуючи цінність і гальмуючи синергію, заради якої було здійснено злиття.

Незадовільне керування ідентифікацією – це прямий удар по вартості компанії після злиття. Це тягар на балансі, який більшість CEO ще навіть не оцінили кількісно. Саме тому запит на збільшення бюджету на від 5 до 20% для інфраструктури ідентифікації – це не просто витрати на безпеку. Це інвестиція в інфраструктуру зростання. Це цифровий аналог будівництва швидкісної залізниці між вашими ізольованими сховищами даних. Ви переходите від захищеного периметра, який усі намагаються оминути, до моделі безперервної верифікації, що реально підтримує робочі процеси. Ви пояснюєте топ-менеджменту, якщо вони хочуть п'ятикратного зростання продуктивності, обіцяного щі, вони мають оплатити фундамент, який зробить це безпечним. Потрібно змінити фокус із захисту даних на керування потоками інтелекту. Перехід до контекстно-залежної моделі – це єдиний спосіб побудувати стійке підприємство в епоху агентного щі.

Це дозволяє організації масштабувати свій інтелект, не масштабуючи ризики. Коли топ-менеджмент розглядає доступ як стратегічний актив, змінюється вся культура компанії. Безпека стає спільною відповідальністю, а дані – ліквідним ресурсом, а не таємницею, яку ховають. Час перестати дивитися на вартість інструментів і почати рахувати вартість тертя, адже в епоху щі перемагає найшвидший, а ви не можете бути швидкими, якщо ваші дані замкнені в брехні. Ваш мандат на 2026 рік чіткий. Ви повинні перевірити свій борг прав доступу перш ніж масштабувати ліцензії на щі. Технології готові, але ваша архітектура, скоріше за все, ні. Завдання на наступний квартал – впровадити обов'язкове автомаркування та провести 90-денне очищення сайту, щоб закрити найочевидніші прогалини. Припиніть накопичення. Запустіть потік. Якщо хочете поділитися прогресом у руйнуванні ізоляції даних або обговорити перехід до контекстнозалежних прав доступу, зв'яжіться з Мірко Пітерсом у LinkedIn.

Побудуймо модель інтелекту, яка працює насправді. Підписуйтесь на детальніші огляди майбутнього роботи. Залишайтеся в безпеці. Залишайтеся продуктивними. Дякую за перегляд!