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