Коротко: підключити AI до Business Central можна чотирма способами, і вибір визначається не технікою, а тим, наскільки відкритим має бути перелік запитань. Спільне в усіх — інтеграція працює під обліковим записом Business Central, і саме він, а не модель, є межею того, що AI може побачити й зробити.
Чотири способи, коротко
| Спосіб | Коли доречний | Що потрібно |
|---|---|---|
| Вбудований Copilot | Сценарії, які вже є в продукті | Увімкнути й налаштувати |
| Power Automate з AI Builder | Фіксований процес із кроком, де потрібна модель | Ліцензії, конектор |
| Власна інтеграція через API | Вузький набір відомих запитань | Розробка, реєстрація застосунку |
| Шар MCP | Агенти й перелік можливостей, що зростатиме | Розробка, сервер, хостинг |
Перші два не потребують розробки й з них варто починати перевірку. Третій і четвертий — це вже проєкт; різницю між ними ми розбираємо окремо на сторінці про MCP і шар інтеграції.
Окремо варто сказати про те, чого в цьому переліку немає. Вивантаження даних у зовнішнє сховище, щоб «AI мав до чого звертатися», — поширена ідея й майже завжди помилкова для ERP: ви отримуєте другу копію правди, яка застаріває, і всі питання про актуальність цифр повертаються.
Що таке API Business Central насправді
Під «API Business Central» ховаються три різні речі, і плутанина між ними коштує часу на старті.
- Стандартний REST API — набір готових ендпоїнтів для основних сутностей: клієнти, постачальники, номенклатура, замовлення, рахунки. Покриває більшість типових запитів і не потребує розробки на боці Business Central.
- OData через вебсервіси — публікація довільної сторінки або запиту як сервісу. Гнучкіше, але кожен ендпоїнт треба свідомо опублікувати, і продуктивність залежить від того, що саме опубліковано.
- Власні API-сторінки на AL — коли потрібні поля з ваших розширень або специфічна форма даних. Це доробка, хоч і невелика.
Практичне правило: почніть зі стандартного API, і лише те, чого в ньому бракує, публікуйте окремо. Зворотний порядок породжує десятки ендпоїнтів, які потім ніхто не супроводжує.
Автентифікація: під ким працює інтеграція
Це головне архітектурне рішення, і ухвалити його треба на початку, бо воно визначає все далі.
Сервісний обліковий запис
Інтеграція працює під одним технічним записом із фіксованим набором дозволів. Просто в реалізації. Наслідок: усі користувачі бачать однаковий зріз даних. Якщо керівник відділу продажів і фінансовий директор мають бачити різне, цей варіант не підходить.
Делегований доступ
Інтеграція діє від імені того, хто питає. Кожен бачить рівно те, що йому дозволено в Business Central, а журнал показує реальну людину. Складніше в реалізації, але для більшості компаній це правильний вибір — і переробити його потім дорого.
Обидва варіанти будуються на Entra ID. Реєстрація застосунку, права доступу до Business Central і згода адміністратора — стандартна процедура, але вона потребує людини з правами в тенанті, і це варто узгодити до старту робіт, а не в останній день.
Дозволи
Обліковий запис інтеграції — це звичайний обліковий запис Business Central. Йому призначають набір дозволів, і платформа відхиляє все поза ним так само, як відхилила б людині. Три речі, які варто зробити свідомо:
- Окремий набір дозволів під інтеграцію, а не копія ролі бухгалтера «щоб точно вистачило». Надлишкові права ніхто потім не звужує.
- Область компанії. Якщо в базі кілька юридичних осіб, вкажіть, до яких інтеграція має доступ.
- Окремий запис на кожного агента, якщо їх буде кілька, — інакше журнал змін не відповість, хто саме що зробив.
Ширший контекст — у матеріалі про права користувачів у Business Central.
Ліміти й підводні камені
- Обмеження кількості запитів. Хмарний Business Central обмежує інтенсивність звернень. Асистент, який на одне запитання робить сорок дрібних викликів, впирається в це швидко. Лікується проєктуванням операцій: один запит, що повертає потрібне, замість двадцяти, що повертають по шматку.
- Пісочниця не дорівнює продуктиву. Обсяги даних відрізняються, і запит, який на пісочниці виконується миттєво, у продуктиві може впертися в час очікування. Тестувати треба на реалістичних обсягах.
- Оновлення двічі на рік. Інтеграції на стандартному API переживають релізи так само, як AL-розширення: їх треба перевіряти після кожного великого оновлення. Те, що читає недокументовані внутрішні структури, не переживає — тому й варто лишатися на опублікованих ендпоїнтах.
- Середовища. Ключі, URL і дозволи в пісочниці та продуктиві різні. Це очевидно, доки хтось не задеплоїть конфігурацію пісочниці в продуктив.
Порядок дій
- Перевірити, чи закриває запитання вбудований Copilot. Це найдешевша відповідь.
- Визначити конкретні запитання й хто їх ставитиме.
- Перевірити, чи є потрібні дані у стандартному API, і що доведеться публікувати окремо.
- Обрати модель автентифікації: сервісний запис чи делегований доступ.
- Створити окремий набір дозволів під інтеграцію.
- Зібрати прототип на пісочниці й дати його тим, хто ставитиме запитання.
- Перевірити відповіді проти тих самих запитань, порахованих вручну.
- Перевірити, що система відмовляє там, де має відмовляти.
- Вихід у продуктив із записаним переліком того, що рішенню дозволено.
Кроки 7 і 8 пропускають найчастіше, і саме вони визначають, чи користуватимуться рішенням через пів року.
Що ви зробите самі, а що доведеться замовляти
Чесний поділ, щоб ви могли оцінити обсяг до того, як почнете.
| Частина | Реально зробити самотужки |
|---|---|
| Увімкнути й перевірити Copilot | Так, це налаштування |
| Сценарій у Power Automate з AI Builder | Так, якщо є людина, яка вже працює з потоками |
| Реєстрація застосунку в Entra ID | Так, це стандартна процедура на пів години |
| Окремий набір дозволів | Так, якщо ви розумієте свою модель прав |
| Вузький асистент на прямих викликах API | Так, якщо в команді є розробник інтеграцій |
| Визначення розрахунків і термінів | Тільки ви — підрядник цього не вирішить |
| Шар MCP з переліком операцій | Рідко: потрібен і розробник, і знання моделі даних BC |
| Тестування відмов і граничних випадків | Складно без досвіду: невідомо, що саме перевіряти |
Верхні чотири рядки варто спробувати до розмови з будь-яким підрядником: вони безкоштовні й дадуть фактичну картину того, чого не вистачає. Нижні три — саме те, за що платять.
Орієнтир вартості: AI Discovery від $750 (оцінка сценаріїв, даних, дозволів і архітектури — документ лишається вам незалежно від продовження), асистент від $3 000, агент від $6 000. Використання моделі й хостинг — окремі поточні витрати провайдера.
Часті запитання
Чи потрібно вивантажувати дані в окреме сховище?
Майже ніколи. Асистент звертається до Business Central у момент запитання, тож дані завжди актуальні. Окрема копія створює другу версію правди, яка застаріває, і повертає всі питання про те, якій цифрі вірити.
Хто має видати доступ у Entra ID?
Людина з правами адміністратора у вашому тенанті: потрібні реєстрація застосунку, права доступу до Business Central і згода адміністратора. Це стандартна процедура, але її варто узгодити до старту робіт, бо без неї розробка впирається в глухий кут.
Скільки викликів API це створює?
Залежить від проєктування. Погано спроєктований асистент робить десятки дрібних викликів на одне запитання й швидко впирається в обмеження інтенсивності. Правильний підхід — операції, що повертають потрібне одним запитом.
Що буде після оновлення Business Central?
Інтеграції на стандартному API переживають релізи, але їх треба перевіряти після кожного великого оновлення — так само, як AL-розширення. Це закладають у супровід, а не сподіваються, що обійдеться.
Чи можна підключитися без розробки взагалі?
Так, двома способами: увімкнути Copilot або зібрати сценарій у Power Automate з AI Builder. Обидва обмежені тим, що передбачив продукт, але обидва варто перевірити першими — вони дешевші за будь-яку розробку.