Тіньовий AI був легкою проблемою: справжня загроза ховається в затвердженому програмному забезпеченні

Два роки тому тіньовий AI означав, що співробітники вставляють дані клієнтів у ChatGPT. Виправлення, в широкому сенсі, було керованим: виявити інструменти, санкціонувати хороші, заблокувати погані, навчити людей. Більшість організацій знаходяться десь посередині виконання цього сценарію, де 61% вже зустрілися з тіньовим AI у своїх середовищах, і сценарій у більшості випадків працює.

Однак цей опис більше не описує проблему. Тіньовий AI перейшов за межі поведінкової проблеми до архітектурної проблеми. Традиційна система управління не може впоратися з сучасним ландшафтом, включаючи вбудовані агенти постачальників і агенти, підключені працівниками, що діють всередині затверджених систем з успадкованими повноваженнями, роблячи ідентифікацію єдиною справжньою точкою контролю.

Дві тіньові, яких ви не спостерігаєте

Цікаве питання у 2026 році не полягає в тому, який інструмент AI відкрив співробітник. Це який агент ваш затверджений постачальник тихо відправив всередину останнього квартального оновлення продукту і які повноваження він успадкував від людини, яка його встановила.

Тіньовий AI раніше був питанням поведінки. Ви могли його побачити, назвати і створити політику проти нього. Версія, яка зараз поширюється, є структурною. Вона приходить через програмне забезпечення, яке ви вже затвердили, діє під повноваженнями, які ви вже видали, у потоках, які ви вже перевірили. Тінь вже не є поведінкою, а архітектурою. Співробітники все ще у картині, але вони перейшли від використання AI до його розгортання: підключення агентів до систем, до яких вони вже мають доступ, і роблять це через інтерфейси, призначені для того, щоб зробити це простим. Політика, написана для першої поведінки, не досягає другої.

Це пояснює, чому “заборонити його” ніколи не було справжнім дебатом. CISO, які вийшли вперед тіньового AI, санкціонуючи корпоративні інструменти і спрямовуючи працівників до керованих альтернатив, виграли цю раунд і виявили, що наступний вже триває, і що в нього дві вектори, а не один. Перший – це те, що затверджені постачальники відправляють у продукти, які вже знаходяться у виробництві: вбудовані моделі, агентні режими, нові інтеграції, які прибули у примітці про оновлення, яку ніхто не читав. Другий – це те, що працівники самі підключають: LLM, підключений до CRM через безкодову автоматизацію, Custom GPT, якому видали ключ API до складу даних, MCP-з’єднання від настільного помічника до системи виробництва. Обидва призводять до одного результату, який включає агентів, що діють під затвердженими повноваженнями, проти затверджених систем, у потоках, які ніколи не проходили жодного огляду, призначеного для їх виявлення. Процurement може побачити перший вектор і повністю пропустити другий.

Це варто бути чесним щодо того, наскільки нерівномірно була виграна перша раунда. Дев’ять із десяти організацій планують збільшення бюджету IT, пов’язаного з AI, протягом наступних 6-24 місяців. Видатки прямують до інтелектуальних можливостей. Керування відстає на дюйми. Ця дисбаланс є проблемою, а не побічним ефектом.

Периметр завжди був людським

Ментальна модель, яка працювала для першої хвилі, не працює для цієї. Тіньовий AI як поведінка працівників припускав людину в циклі, що приймає рішення, яке команда безпеки могла впливати. Тіньовий AI як архітектура постачальників видаляє вибір. Модель, яка написала електронний лист, агент, який запланував зустріч, помічник, який підсумував документ і направив його далі. Жоден з них не потребував від працівника нічого, крім того, щоб продовжувати використовувати програмне забезпечення, яке їм було призначено використовувати.

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

Єдине місце, куди можна подивитися

Ідентифікація є правильною точкою контролю, але формулювання має змінитися. Традиційна формулювання каже “ідентифікація – це новий периметр”, тому що користувачі є всюди, пристрої є всюди, а SaaS є всюди. Це було правдою десять років тому, зараз це базові вимоги. Версія, яка має значення у 2026 році, інша: ідентифікація – це єдине місце, де можна побачити, що AI насправді робить, тому що до того часу, як воно робить це, межа інструменту вже була перетнута. Агент діє під повноваженнями когось. Чий, з яким обсягом, проти яких даних, на чиєй авторизації – це питання, які дають корисний слід аудиту. Керування на рівні інструменту не може відповісти на ці питання, тому що інструмент більше не є одиницею аналізу.

Практично 90% лідерів IT вже визнають, що уніфікація має прямий вплив на їхню здатність реалізовувати і масштабувати AI безпечно. Більш складне питання полягає в тому, що уніфікація насправді означає на рівні керування. Це не може означати лише менше панелей. Це означає єдину тканину ідентифікації, де кожен актор, незалежно від того, чи це людина, сервісний аккаунт, агент, вбудована модель, провіщується, обмежується, контролюється і видаляється через одну і ту ж саму механіку. Все, що менше цього, дає вам вигляд консолідованого керування, тоді як насправді це просто фрагментоване виконання.

Ваш огляд постачальника має термін дії

На жаль, огляд постачальника дійсний лише певний час. Це має незручні наслідки для того, як структуруються програми безпеки. Більшість комітетів з управління AI організовані навколо огляду інструментів, з постачальниками, які приходять і проходять оцінку, санкціонування або відхилення, щоб бути доданими до реєстру. Цей процес припускає, що поведінка інструменту на момент санкціонування є поведінкою інструменту у виробництві. Для програмного забезпечення з вбудованим AI це припущення порушено ще до того, як чорнила висохнуть. Постачальник відправить нову модель, новий агентний режим, нову інтеграцію, і огляд керування, який був затверджений шість місяців тому, зараз описує продукт, який більше не існує.

За межами інструменту, на ідентифікацію

Програми, які витримають, будуть тими, які перемістять керування з інструменту на ідентифікацію. Кожна дія проти ваших даних, будь-яким актором, можна простежити до ідентифікатора з відомим власником, обмеженим набором повноважень і визначеним терміном дії. Чи це людина, чи не людина, працівник чи агент, санкціонований інструмент чи вбудований режим, питання одне і те ж: хто це, що їм дозволено робити, і як ми знаємо, коли це повинно припинитися бути правдою? Програми, які можуть відповісти на ці питання, не потребують виграти гонку санкціонування інструментів. Програми, які не можуть, будуть грати в догонялки проти постачальників і працівників, які відправляють швидше, ніж будь-який процес огляду може рухатися.

Тіньовий AI як категорія не зникає. Особливо з новою епохою агентської робочої сили, 72% організацій вже мають агенти AI у виробництві. Замість цього, це стає меншою частиною більшої проблеми. Організації, які витрачають наступний бюджетний цикл на відкриття інструментів і політику санкціонування, є тими, хто розв’язує проблему 2024 року на графіку 2026 року. Ті, хто витрачає його на інструментарій рівня ідентифікації для людей, агентів, складної межі між ними, розв’язують проблему, яку вони насправді матимуть.

Перша хвиля тіньового AI навчила команди безпеки, що вони не можуть обігнати цікавість працівників. Друга хвиля навчитиме їх, що вони не можуть обігнати швидкість постачальників або винахідливість працівників. Обидва уроки вказують на один і той же висновок. Одиниця керування ніколи не буде інструментом. Це завжди буде ідентифікація, що діє через нього.