Архітектурний зсув, необхідний для управління агентами штучного інтелекту

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

Ризик не є теоретичним. Незначні прогалини в видимості, контролі доступу та аудитабельності можуть швидко накопичуватися, перетворюючись на помилки виконання, які важко виявити і ще важче скасувати.

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

Чому управління ламає у період конвергенції

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

Є організації, які запускають свої платформи в паралельних системах, оскільки вони мають кілька процесів для одночасного управління. Це включає окремі системи ідентифікації, реєстратори, каталоги та затверджені процеси. Результатом є те, що деякі називають “платформою Франкенштейна”, де інтеграційна витрата збільшується з кожним новим інструментом або хмарним середовищем. Насправді, ця фрагментація проявляється в повсякденній реальності.

Згідно з недавнім опитуванням, 47% респондентів вказують на складні вимоги доступу та процеси, а 44% – на обмежену видимість того, де розташовані дані, як бар’єри для ефективного використання даних.

Це саме те місце, де агенти викривають шви між системами.

Щоб відповісти на бізнес-питання, агент може мати besoin витягнути дані з локальної системи ERP, хмарної системи CRM, операційної телеметрії в іншій хмарі та документів у колаборативній суїті. Якщо організація застосовує політику по-різному в кожному місці, агент або зазнає невдачі, або, що гірше, успішно діє способами, які ви не можете пояснити чи контролювати.

Це момент, коли корпоративні лідери повинні звернути увагу. Агенти змушують встановити вищий рівень, який вимагає узгодженості між середовищами та відповідальності у режимі виконання.

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

Від політики до платформи

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

• Єдина контрольна площина

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

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

Практичний тест простий: якщо користувач не може отримати доступ до стовпця, перевірте, чи не може агент, який діє від його імені, отримати доступ до нього також. Це повинно вказувати на те, чи виконуються написані політики по всій площі.

• Тканина даних, заснована на відкритих стандартах

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

Відкриті формати таблиць, такі як Apache Iceberg, підтримують це, дозволяючи кільком двигунам спільно використовувати керований дані без копіювання їх у новий сегмент. Це важливо, оскільки дублікування даних – це місце, де управління зазвичай виходить з ладу. Як тільки команди починають копіювати “тільки те, що потрібно агенту”, ви створили нове, менш кероване середовище.

Якщо агенти можуть діяти по різних наборах даних без введення нових прогалин у повноваженнях, управління працює так, як передбачено.

• Реальне спостереження та лінійність

Агенти керуються лише тоді, коли ви можете побачити, що вони роблять у режимі виконання.

Спостереження тут не є просто “бажаним”, а є основою для контролю у режимі виконання та реагування на інциденти.

Конкретно, потрібно мати повний доказ дій агентів. Агенти повинні能够 довести дії, такі як які дані були доступні та які інструменти були викликані, а звідти лінійність може зв’язати виходи з входами. Це дозволяє командам проводити аудит цих рішень та розслідувати невдачі, якщо це потрібно, тим самим доводячи загальну відповідність.

Відноситися до агентів як до “цифрових колег”

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

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

Розгляньте агент підтримки. Він може потребувати доступу до попередніх випадків підтримки для вирішення проблеми, але він не може розголошувати приватні дані іншого клієнта під час цього. Інакше кажучи, агент може використовувати обмежені знання для обґрунтування, але все ж таки повинен забезпечувати дотримання меж розголошення. Це не є проблемою “написання промпта”, яку ми історично знали, як навігувати; натомість це проблема ідентифікації та забезпечення виконання у режимі виконання.

Що змінюється у 2026 році: агенти переходять з експериментів до виробництва

2026 рік – це рік, коли експерименти закінчуються, а агенти займають місце виробництва.

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

Без встановленої архітектури управління ці дві швидкості будуть конфліктувати.

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

Мета полягає не в тому, щоб вибрати швидкість. Це полягає в тому, щоб побудувати архітектуру, яка підтримує обидві швидкості.

Практичний чек-лист для управління агентами у режимі виконання

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

Якщо ви не можете відповісти на ці питання, behandуйте розгортання агентів як виробничу аварію, яка чекає на свій час.

Зсув управління повинен бути архітектурним, інакше воно не існує

Агенти стануть стандартною частиною корпоративних операцій. Питання полягає в тому, чи вони стануть надійною частиною корпоративних операцій.

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

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

Це саме те, як ви отримуєте агентів, які рухаються швидко без порушення підприємства.