AI-агенти в компаніях: де межа між автоматизацією і ризиком
Співробітники дедалі частіше підключають AI-агентів до робочих систем, не усвідомлюючи, які дані й дії стають доступними. Це створює нові загрози для бізнесу, від утрати клієнтських даних до видалення production-баз.
AI-агенти перестали бути інструментом лише для розробників. Маркетинг автоматизує outreach, sales оновлює CRM, finance працює з документами, а працівники підключають пошту, Drive і Slack. Для бізнесу це відкриває можливості, але водночас створює приховані ризики: коли співробітник дає агенту доступ до кількох систем, зовнішній лист може вплинути на зміни в CRM, а внутрішній документ — потрапити назовні.
Більшість тих, хто збирає агентів, не до кінця розуміють, який рівень доступу вони надають. Логіка часто проста: якщо система доступна мені, її можна підключити й агенту. Наслідки вже фіксуються. У липні 2025 року AI-агент Replit видалив production database під час code freeze, а у квітні 2026 року Cursor agent одним API-викликом знищив production database і backups у PocketOS. Проблема в тому, що окремі доступи (Gmail, CRM, Drive) можуть бути безпечними, але разом вони створюють можливості, які ніхто не погоджував.
Ключове питання — не забороняти агентів, а розділити права людини й права конкретного workflow. Людині доступ потрібен для її ролі, агенту — тільки для його задачі. Наприклад, sales manager може бачити клієнтські дані й експортувати звіти, але агент, який лише класифікує відповіді, має отримати значно вужчі права. Так само розробнику з production access не обов’язково давати його агенту для аналізу логів.
Проблема виходить за межі engineering. У травні 2026 року Community Bank (дочірній банк CB Financial Services) повідомив SEC про інцидент із неавторизованим AI-застосунком, через який оброблялися непублічні дані клієнтів: імена, дати народження та Social Security numbers. Компанія визнала інцидент суттєвим і почала повідомляти регуляторів. Це показує: політика «ми дозволили користуватися AI-сервісом» не вирішує проблему, важливо, які дані конкретний агент бачить і що може з ними зробити.
Покладатися лише на промпти також небезпечно. Якщо агенту написати «не проводь refund більше ніж $500», але технічно він може провести $2000, реальний ліміт — $2000. Краще, щоб система просто не дозволяла провести суму понад $500 без погодження. Межі доступу мають бути поза моделлю, а не в інструкціях.
Найгірший варіант — заборонити співробітникам будувати агентів. Люди, які працюють із процесом щодня, краще бачать, що автоматизувати. Але правила доступу мають бути спільними для компанії. Співробітник вирішує, що агент читає партнерські листи й готує follow-up, компанія визначає, які дані CRM він бачить і що може змінити. Це практичніше, ніж дві крайнощі: тотальний контроль чи повна свобода.
Кожному агенту варто відповісти на три питання: що він може прочитати, що може змінити і що інформація з однієї системи може змусити його зробити в іншій. Свобода автоматизувати роботу й право самостійно визначати доступ до систем компанії мають залишатися різними речами.
