Коротко: MCP створила Anthropic, тому Claude працює з ним без прошарків. На практиці це впливає на швидкість першого запуску, але не на складність самої інтеграції з Business Central: перелік операцій, дозволи й тестування відмов однакові для будь-якої моделі.
Що означає «рідна» підтримка
Model Context Protocol розробила Anthropic і відкрила як стандарт. Наслідок для практики простий: у клієнтських застосунках Claude підключення MCP-сервера — це налаштування, а не розробка обгортки.
Що це дає реально: швидший пілот. Ви піднімаєте MCP-сервер з кількома операціями, підключаєте його в клієнті й за день бачите, чи взагалі корисно те, що ви задумали.
Чого це не дає: жодного спрощення в тій частині, де зосереджена вартість. Спроєктувати вузькі операції під модель даних Business Central, узгодити визначення розрахунків, налаштувати дозволи й перевірити відмови треба однаково, яку б модель ви не взяли.
Це варто сказати прямо, бо «рідна підтримка» в матеріалах часто подається так, ніби вона скорочує проєкт. Вона скорочує його першу годину.
Три варіанти розгортання
| Варіант | Де обробляються дані | Кому підходить |
|---|---|---|
| Клієнтський застосунок Claude | В Anthropic, за умовами тарифу | Пілоти, внутрішні асистенти |
| API у власному рішенні | В Anthropic, за договором | Продуктив, свій інтерфейс |
| Через хмарного провайдера | У середовищі провайдера | Жорсткі вимоги до регіону |
Третій варіант вартий уваги для компаній, яким важливо, де фізично обробляються дані: моделі Claude доступні через великих хмарних провайдерів, і тоді обробка відбувається в їхній інфраструктурі за вашим договором із провайдером. Конкретний перелік регіонів і доступність варто перевіряти в документації — ця ділянка змінюється швидше, ніж оновлюються статті.
Для більшості компаній із фінансовими даними робочий вибір — другий або третій варіант. Перший добре підходить, щоб перевірити ідею на демоданих.
Обробка даних
Логіка тут така сама, як із будь-яким зовнішнім провайдером, і зводиться до трьох питань.
Що каже договір про навчання. Корпоративні умови великих провайдерів договірно виключають дані клієнта з навчання моделей. Це пункт документа, який читають, а не властивість технології.
Де відбувається обробка. Якщо у вас є вимоги до регіону, це вирішується вибором варіанта розгортання, а не налаштуванням.
Скільки даних іде назовні. Найважливіше й найменш обговорюване: обсяг визначається проєктуванням операцій. Інструмент, що повертає три потрібні рядки, безпечніший за той, який віддає таблицю й лишає моделі фільтрувати. Це рішення архітектора й воно впливає на приватність більше за вибір провайдера.
Довгий контекст: де це справді допомагає
Одна практична відмінність, яку варто врахувати при виборі моделі для роботи з ERP: обсяг матеріалу, який модель тримає в межах одного завдання.
Для більшості запитань це неважливо — «покажи прострочені рахунки» повертає перелік із двадцяти рядків, і будь-яка модель із ним упорається. Різниця з'являється в задачах, де треба зіставити багато записів одночасно: розібрати сотню позицій вхідного замовлення проти номенклатури, порівняти умови в кількох десятках договорів, знайти закономірність у довгій історії операцій по клієнту.
Тут менш містка модель змушує розбивати роботу на частини, а розбиття означає, що агент не бачить картину цілком і може пропустити зв'язок між першою й останньою частиною. Практичний наслідок: сценарії на кшталт «знайди дублікати серед усіх контрагентів» або «зістав це замовлення з нашим прайсом повністю» працюють стабільніше там, де контекст більший.
Це не аргумент, який має вирішувати вибір сам по собі — умови обробки даних і регіон розгортання важливіші. Але якщо ваші сценарії саме такі, його варто врахувати.
Що не залежить від вибору моделі
Приблизно вся складність проєкту. Корисно перелічити явно, бо саме тут проходить межа очікувань:
- Перелік операцій проєктується під вашу модель даних Business Central, а не під модель AI.
- Дозволи й обліковий запис — це налаштування Business Central і Entra ID.
- Визначення розрахунків узгоджується з вашими фінансистами.
- Тестування відмов перевіряє поведінку системи, а не моделі.
- Журналювання й аудит — див. безпеку AI в Business Central.
Практичний висновок: якщо ви обираєте між моделями, це рішення оборотне за умови правильної архітектури — модель має бути замінною частиною. Значно менш оборотні рішення про модель автентифікації й гранулярність операцій.
Коли Claude має сенс, а коли ні
Має сенс, якщо ви будуєте на MCP і хочете найкоротший шлях до працюючого пілота; якщо потрібна робота з довгим контекстом — розбір великих переліків документів, зіставлення багатьох записів; якщо вам підходять доступні варіанти розгортання за регіоном.
Не має сенсу, якщо ви вже глибоко в екосистемі Microsoft і вам простіше лишитися всередині тенанта — тоді дивіться в бік Copilot Studio. І не має сенсу, якщо запитання повторюються незмінно: тоді вам потрібен звіт, а не модель.
Порядок дій
- Визначити варіант розгортання — це розмова про політику даних, а не про техніку.
- Перевірити договірні умови провайдера щодо обробки й навчання.
- Зареєструвати застосунок в Entra ID, створити окремий набір дозволів під інтеграцію.
- Підняти MCP-сервер із вузьким переліком операцій.
- Підключити клієнта, перевірити на пісочниці з реалістичними обсягами.
- Протестувати відмови: неіснуюча операція, брак дозволів, порожній результат, часткова невдача.
- Вихід у продуктив із записаним переліком дозволеного.
Кроки 1–2 займають більше календарного часу, ніж 3–5, бо вимагають рішень, а не роботи.
Що зробите самі, а що замовляти
| Частина | Самотужки |
|---|---|
| Пілот на демоданих у клієнтському застосунку | Так, за день-два з розробником |
| Вибір варіанта розгортання | Тільки ви |
| Реєстрація застосунку в Entra ID | Так, стандартна процедура |
| Окремий набір дозволів | Так, якщо розумієте свою модель прав |
| Операції під модель даних Business Central | Потрібне знання BC, не лише API |
| Узгодження визначень розрахунків | Тільки ви, з фінансистами |
| Тестування відмов | Складно без переліку чужих помилок |
Пілот варто зробити самим: за день-два стане зрозуміло, чи корисно це вашим людям, і ви прийдете до підрядника з фактами, а не з наміром.
Орієнтир вартості продуктивного рішення: AI Discovery від $750 з письмовим висновком, який лишається вам; асистент від $3 000, агент від $6 000. Використання моделі й хостинг — окремі поточні витрати провайдера.
Часті запитання
Чи справді MCP працює з Claude краще?
Протокол розробила Anthropic, тож підтримка первинна й підключення сервера — це налаштування. Практичний виграш — швидший пілот. На складність самої інтеграції з Business Central це не впливає: операції, дозволи й тестування однакові для будь-якої моделі.
Чи можна обробляти дані в конкретному регіоні?
Так, якщо обрати розгортання через хмарного провайдера, який пропонує потрібний регіон. Конкретну доступність варто перевіряти в документації — ця ділянка змінюється швидше, ніж оновлюються статті.
Чи потраплять дані в навчання моделі?
Корпоративні умови великих провайдерів договірно виключають дані клієнта з навчання. Це пункт договору, тому його читають, а не припускають, і фіксують у документі з архітектури до підключення продуктиву.
Чи можна змінити модель після запуску?
Так, якщо архітектура правильна: модель має бути замінною частиною, а логіка процесу жити в оркестраторі й шарі операцій. Якщо заміна вимагає переписування, значить логіка розповзлася по промптах.
Claude чи ChatGPT для Business Central?
З погляду інтеграції різниця невелика: обидва працюють із зовнішніми інструментами. Обирають за умовами обробки даних, доступними регіонами й ціною. Якщо ви глибоко в екосистемі Microsoft, варто розглянути й Copilot Studio.
Скільки часу до пілота?
День-два, якщо є розробник і ви обмежитеся демоданими та кількома операціями. Продуктивне рішення — два-чотири тижні після discovery.