Коротко: AI не отримує доступу до вашої ERP. Він отримує доступ до названого переліку операцій, що виконуються під названим обліковим записом, із усіма дозволами, які Business Central застосував би до людини з таким самим записом. Усе інше в цій статті — деталі цього речення.
Чотири межі
Захист будується шарами, і кожен тримає незалежно від інших. Це важливо: якщо безпека тримається на одному механізмі, вона тримається погано.
| Межа | Що обмежує | Хто забезпечує |
|---|---|---|
| Перелік операцій | Що AI взагалі може спробувати | Ваша інтеграція |
| Набір дозволів | До чого має доступ обліковий запис | Business Central |
| Процеси погодження | Що виконується без людини | Business Central |
| Договір із провайдером | Що відбувається з даними назовні | Юридичний документ |
Зверніть увагу, чого в таблиці немає: інструкції для моделі. Промпт визначає поведінку в нормальних умовах і не є контролем. Агента, якого вмовили спробувати заборонене, зупиняє платформа, а спроба лишається в журналі.
Обліковий запис: головне рішення
Ухвалюється на початку й визначає все далі, тому переробляти його потім дорого.
Сервісний обліковий запис. Інтеграція працює під одним технічним записом. Просто реалізувати, але всі користувачі бачать однаковий зріз. Якщо керівник напряму й фінансовий директор мають бачити різне — не підходить.
Делегований доступ. Інтеграція діє від імені того, хто питає. Кожен бачить рівно те, що йому дозволено, а журнал показує реальну людину. Складніше, але для більшості компаній правильно.
У будь-якому варіанті під інтеграцію створюють окремий набір дозволів, а не копіюють роль бухгалтера «щоб точно вистачило». Надлишкові права ніхто потім не звужує — це не гіпотеза, а закономірність. Ширший контекст — у матеріалі про права користувачів.
Перелік операцій
Друга межа й та, що відрізняє добре спроєктовану інтеграцію від небезпечної. AI не отримує можливості «виконати будь-який запит». Він отримує конкретні операції з перевіреними параметрами: «показати прострочені рахунки понад суму X за період Y».
Спокуса зробити один універсальний гнучкий інструмент велика — розробнику з ним зручніше. Наслідок у тому, що межа безпеки переїжджає з вашого коду в судження моделі. Операції роблять вузькими, а перелік періодично переглядають, як будь-який набір прав: кожен доданий за рік зручний інструмент розширює поверхню.
Те саме стосується запису: не «оновити запис», а «оновити дату наступного контакту в картці клієнта». Детальніше про це — на сторінці про MCP і шар інтеграції.
Що відбувається з даними назовні
Єдина межа, яка не є технічною. Модель обробляється в постачальника, тож питання просте: що йому дозволено робити з тим, що ви надіслали.
- Корпоративні тарифи великих провайдерів договірно виключають дані клієнта з навчання. Це пункт договору, а не властивість технології, тому його читають, а не припускають.
- Розгортання у власному хмарному середовищі знімає питання остаточно: дані не залишають ваш тенант. Дорожче, але для частини компаній це єдиний прийнятний варіант.
- Обсяг переданого залежить від проєктування. Погана інтеграція надсилає цілі таблиці замість потрібних рядків. Це лікується не вибором провайдера, а операціями, які повертають рівно потрібне.
- Персональні дані. Якщо у відповідях можуть з'являтися персональні дані, місце обробки має відповідати вашим зобов'язанням, а частину полів варто виключити з передачі взагалі.
Аудит
Дії AI журналюються так само, як дії будь-якого користувача. Практична порада одна, але важлива: окремий обліковий запис на кожного агента, а не спільний сервісний. Інакше журнал змін не відповість, який саме агент що зробив, і під час перевірки доведеться зіставляти вручну.
Це коштує нічого на етапі проєктування й дорого — після.
Перелік для перевірки
Що варто запитати в підрядника до початку робіт:
- Під яким обліковим записом працює інтеграція й хто його створює?
- Який набір дозволів йому призначено і чому саме такий?
- Який повний перелік операцій, доступних моделі? Покажіть його.
- Що станеться, якщо попросити виконати щось поза цим переліком?
- Який провайдер моделі, де вона розгорнута, який договір це регулює?
- Які поля не передаються назовні взагалі?
- Як у журналі відрізнити дії агента від дій людини?
- Що робить рішення, коли даних немає — відповідає чи відмовляється?
Останнє питання не про безпеку в класичному сенсі, але у фінансовому контексті впевнена неправда шкідливіша за відмову. Рішення має відповідати «даних немає», і це перевіряють окремим тестуванням, а не сподіваються.
Часті запитання
Чи може AI побачити дані, до яких у користувача немає доступу?
За правильного налаштування ні. Виклики йдуть під обліковим записом Business Central із набором дозволів, і платформа застосовує їх так само, як до людини. Ризик виникає тоді, коли інтеграцію запускають під сервісним записом із широкими правами, а різні люди мають бачити різне.
Чи потраплять наші дані в навчання моделі?
Це визначає договір із постачальником, а не технологія. Корпоративні тарифи великих провайдерів договірно виключають дані клієнта з навчання; споживчі умови — не завжди. Умови фіксують письмово до підключення до продуктиву.
Чи можна залишити дані всередині компанії?
Так, якщо розгорнути модель у власному хмарному середовищі. Дані тоді не залишають ваш тенант. Це дорожче за використання публічного API, і для частини компаній єдиний прийнятний варіант.
Чи захищає промпт від небажаних дій?
Ні. Формулювання інструкції визначає поведінку в нормальних умовах і контролем не є. Захист — це перелік доступних операцій і набір дозволів Business Central. Якщо безпека тримається на промпті, вона не тримається.
Як зрозуміти, що зробив агент?
З журналу змін, за умови що в агента власний обліковий запис. Якщо кілька агентів працюють під спільним сервісним записом, розібратися постфактум складно. Це вирішують на етапі проєктування.
Чи потрібен окремий аудит перед запуском?
Корисно, і найпростіша його форма — спроба зробити те, від чого рішення має відмовитися. Це перевірка на пів дня, яка дає більше, ніж будь-який опис архітектури.