Інтеграція AI з ERP та корпоративними системами

Контролер фінансів витрачає дві години на день на ручне введення даних з рахунків-фактур до ERP. Відділ продажів чекає 24 години на відповідь від відділу логістики, бо запит щодо наявності вимагає пошуку в трьох системах. Служба підтримки вирішує ті самі проблеми з налаштуваннями, бо знання зберігаються в голові старшого спеціаліста, а не в системі. Це не проблеми відсутності технологій. Це проблеми неузгодженої інтеграції між системами, які у вас вже є. AI не замінює ERP чи CRM — підключається до них і заповнює прогалини, які досі вимагали ручної роботи на кожному кроці.

Перше побоювання, з яким ми стикаємося в розмовах з клієнтами: «Чи доведеться нам перебудовувати ERP?». Ні. Модель AI працює як проміжний шар — зчитує дані з системи через API, обробляє їх і записує результат назад. SAP, Microsoft Dynamics, Comarch ERP, Optima, Symfonia — кожна з цих систем має API або принаймні експорт даних, що дозволяє побудувати інтеграцію без зміни базової конфігурації.

Практична різниця між підходами:

Для переважної більшості компаній точкою входу є перший рядок. Пілот не вимагає зміни контракту з постачальником ERP чи найму програмістів, які знають внутрішню будову системи.

Хороший кандидат для інтеграції AI має три характеристики: велика кількість повторень, структуровані вхідні дані та вимірюваний час ручної обробки. П’ять процесів, які найчастіше зустрічаються в проектах:

Бухгалтерське проведення та обробка рахунків-фактур. OCR витягує поля з PDF-документа (ІПН, сума, дата, позиції), модель зіставляє їх із рахунками бухгалтерського плану та зберігає в ERP як пропозицію проведення для затвердження. Помилкові рахунки-фактури потрапляють до черги винятків із описом розбіжностей.

Класифікація та маршрутизація замовлень. Нове замовлення з e-commerce або EDI надходить до агента, який перевіряє наявність, верифікує умови оплати клієнта та призначає замовлення на відповідний маршрут виконання. Винятки (відсутність товару, перевищення кредиту) ескалуються автоматично з повним контекстом.

Тріаж сервісних запитів. Тікет із служби підтримки описує проблему; модель категоризує її, призначає пріоритет і пропонує відповідь на основі бази вирішених випадків (RAG за історією тікетів). Консультант затверджує або коригує — не починає з нуля.

Звітність та наратив даних. Дані з ERP (продажі, стан складу, дебіторська заборгованість) надходять до моделі, яка пише наратив відхилень від плану. Замість таблиці цифр керівник отримує речення: «Маржа в категорії X знизилася на 4 в.п. порівняно з минулим місяцем, головним чином через зростання вартості доставки».

Доповнення даних master data. Новий контрагент, внесений до системи, має неповну картку — відсутні код КВЕД, організаційно-правова форма, контактні дані. Модель верифікує дані з доступних джерел, пропозицію доповнення подає на затвердження оператору.

Кожна інтеграція AI з операційною системою повинна мати чотири шари. Відсутність будь-якого з них зазвичай виявляється через кілька тижнів експлуатації як інцидент безпеки або помилка, яку важко пояснити.

Шар вилучення даних. Вихідна система (ERP, CRM) експортує дані через API або циклічний експорт. На цьому етапі застосовується маскування або псевдонімізація PII. Персональні дані клієнтів, номери ідентифікаційних кодів, фінансові дані фізичних осіб — вирізаються або псевдонімізуються перед передачею далі. Модель у хмарі ніколи не бачить даних, що ідентифікують фізичних осіб. Детальніше про цей патерн у статті про анонімізацію PII перед AI.

Шар виклику моделі. Промпт будується з шаблону та замаскованих даних. Виклик проходить через router LLM, який підбирає модель під завдання та вартість, логує кожен виклик і контролює добові бюджети. Структурований вихід із примусовою схемою JSON усуває половину помилок парсингу — замість тексту модель повертає об’єкт із визначеними полями.

Шар валідації та guardrails. Відповідь моделі валідується перед записом: перевіряється відповідність схеми, діапазони значень (чи сума рахунку-фактури в межах розумного), а guardrails блокують операції за межами визначеного обсягу. Замість тихого запису аномалії система спрямовує її до черги винятків із поясненням.

Шар дій та human-gate. Зворотні дії (пропозиція проведення, класифікація замовлення) записуються як чернетки для затвердження. Незворотні дії (відправка замовлення постачальнику, зміна статусу рахунку-фактури на «оплачено») чекають на підтвердження людиною. Це не питання довіри до моделі — це принцип, що незворотна дія з помилкою коштує в рази дорожче, ніж секунда затвердження людиною. Схему human-gate детальніше описано в статті про роль людини в петлі.

ERP та CRM містять дані, витік яких є дорогим з правової та репутаційної точки зору. Кілька принципів, які ми впроваджуємо в кожному проекті:

Чутливі дані (персональні дані клієнтів, фінансові дані фізичних осіб, кадрові дані) ніколи не потрапляють до моделі в хмарі в ідентифікуючій формі. Якщо вимоги RODO або політика безпеки компанії цього вимагають, весь стек — ембедінги та модель — працює локально на інфраструктурі клієнта (self-hosting). Латентність зростає, але дані не залишають мережі.

Для інтеграції з системами високого ризику (кадрові дані, медичні дані, фінансовий скоринг) потрібна DPIA перед запуском у продакшен. AI Act накладає додаткові вимоги на системи, що оцінюють фізичних осіб — класифікатори ICP, які працюють з персональними даними, потрапляють до категорії високого ризику з обов’язком документування та пояснюваності рішень. Детальніше в статті AI Act та RODO 2026 — обов’язки компаній.

Кожен виклик моделі логується з ідентифікатором операції, міткою часу та результатом — без персональних даних. Цей лог — не зайва бюрократія: це аудиторський слід, необхідний при перевірці та основа для вимірювання якості.

Пілот інтеграції AI з ERP — це проект із фіксованим обсягом, який завершується вимірюваним результатом, а не відкритою ліцензією на AI. Типовий шлях:

Перший крок — аудит процесу: скільки часу займає сьогодні, які дані на вході та виході, де винятки та як вони обробляються. Без цього виміру неможливо підтвердити, що AI дає віддачу. Оцініть готовність свого процесу за допомогою інструменту оцінки готовності.

Другий крок — технічна інтеграція: підключення до API вихідної системи або налаштування експорту, побудова конвеєра даних із маскуванням PII, налаштування роутера та guardrails, впровадження в режимі shadow (модель працює паралельно з людиною, результати порівнюються, але не записуються автоматично).

Третій крок — калібрування: протягом 2–4 тижнів збираються результати режиму shadow, вимірюється точність (скільки пропозицій моделі оператори затверджують без змін), визначаються категорії винятків і коригуються guardrails. Лише після досягнення встановленого порогу точності (зазвичай 85–95%, залежно від процесу) переходимо до автоматичного запису пропозицій та вибіркового контролю людиною.

Часовий та вартісний діапазон залежать від обсягу та складності API вихідної системи. Розрахуйте варіанти для свого процесу в калькуляторі ROI.

Відсутність режиму shadow перед продакшеном. Запуск автоматичного запису в ERP без фази shadow означає, що перші помилки моделі потрапляють прямо до системи. Кілька тижнів shadow mode та збір даних про винятки дешевше, ніж дві години ручного прибирання аномалій у базі.

Ігнорування валідації схеми на виході. Модель повертає коректний JSON у 98% випадків. Ці 2% потрапляють до системи як null, порожній рядок або значення з минулого — тихо. Примусова схема JSON-Schema та валідація перед записом перетворюють ці 2% на виняток, видимий в дашборді, а не на приховану помилку в даних.

Інтеграція без моніторингу якості. Точність моделі знижується з часом: дані в ERP змінюються, типи документів еволюціонують, з’являються нові винятки. Без вимірювання точності (скільки пропозицій оператори затверджують без змін, скільки потрапляє до винятків) ви не знаєте, коли модель потребує рекалібрування.

Один виклик моделі на кожен запис. При обробці сотень рахунків-фактур на день вартість токенів може здивувати. Оптимізація вартості токенів через prompt caching, batching та маршрутизацію на дешевшу модель для простих завдань може знизити операційні витрати на 40–70%.

Опишіть процес, який хочете автоматизувати, та вихідні дані — модель покаже, як спроектувати конвеєр інтеграції, маскування PII та схему guardrails. Це відправна точка, а не готовий проект (playground: PII маскуються, нульова ретенція):

У переважній більшості випадків — так. Інтеграція базується на API системи (REST, SOAP, EDI) або експорті даних (CSV, XML). Вам не потрібен доступ до вихідного коду чи зміна конфігурації постачальника. Більшість польських ERP-систем (Comarch, Symfonia, Sage, Microsoft Dynamics) мають документоване API або принаймні можливість експорту, якої достатньо для пілоту.

Основний ризик — помилковий автоматичний запис, який важко скасувати. Тому застосовуємо принцип: модель пропонує, людина затверджує для незворотних дій. Протягом перших кількох тижнів модель працює в режимі shadow — результати порівнюються з ручними рішеннями, але не записуються автоматично. Лише після вимірювання точності (зазвичай понад 90% пропозицій затверджуються без змін) переходимо до автоматичного запису з вибірковим контролем.

Залежить від типу даних. Неперсональні дані (коди продуктів, суми загалом, категорії замовлень) не підпадають під обмеження RODO. Персональні дані (ІПН фізичної особи, контактні дані приватних клієнтів, кадрові дані) вимагають або маскування перед відправкою, або локальної моделі. На етапі аудиту класифікуємо дані процесу та підбираємо відповідну архітектуру — хмарну з маскуванням або повністю локальну.

Пілот одного процесу (наприклад, бухгалтерське проведення рахунків-фактур) зазвичай триває від 3 до 8 тижнів від підписання обсягу до вимірюваного результату. Найбільша змінна — доступність API вихідної системи та якість вхідних даних. Якщо рахунки-фактури надходять як скани низької якості без текстового шару, OCR потребує калібрування, що подовжує проект. Детальний графік та вартість залежать від обсягу — зв’яжіться з нами, щоб почати з конкретних цифр.

Ні, у буквальному сенсі. AI усуває повторювані механічні дії (ручне введення полів, пошук даних у кількох системах, написання звітів за даними), а не рішення, що потребують бізнес-контексту. Працівники, які сьогодні вводять рахунки-фактури, можуть займатися верифікацією винятків, аналізом відхилень та покращенням якості даних — це дає більшу цінність і менш монотонно. Найчастіший ефект пілоту — не скорочення штату, а перерозподіл часу на роботи з вищою доданою вартістю.