AI-система, которая не умеет читать и писать в ваши учётные системы, — это демо. Польза появляется в тот момент, когда она начинает участвовать в системах, где реально идёт работа. В этот же момент появляется и риск.
Определите, какая система главная. Это не технический вопрос.
До любой интеграции нужно ответить на один вопрос по каждой сущности: какая система побеждает?
Если CRM и ERP расходятся в адресе клиента — какой верный? Если агент извлёк из документа значение, противоречащее ERP, что происходит?
Это решение бизнеса. Инженеры не могут его принять и не должны угадывать. Проекты регулярно встают именно здесь, и такая остановка полезна: она означает, что организация жила с неразрешённой неоднозначностью, которую люди закрывали вручную.
Зафиксируйте ответ письменно по каждой сущности. Он становится правилом разрешения конфликтов и отличает систему, которая сходится, от системы, которая колеблется.
Чтение и запись несимметричны
Чтение относительно прощает. Устаревшие данные дадут неоптимальный ответ. Неприятно, но редко разрушительно.
Запись — там, где последствия. Пути записи без исключений нужны:
Идемпотентность. Сетевые вызовы падают и повторяются. Если повтор создаёт вторую запись, вы произвели задвоенный счёт. У каждой записи должен быть ключ, делающий повтор безвредным.
Валидация до границы. Проверяйте данные схемой на своей стороне, до вызова чужого API. Ошибки валидации вендора часто бесполезны, иногда неполны, а иногда приходят уже после частичной записи.
Карантин, а не отбрасывание. Записи, не прошедшие проверку, должны попадать туда, где человек может их разобрать. Никогда не удаляйте молча: удалённая запись обнаружится при сверке через месяцы, когда восстановить произошедшее уже никто не сможет.
Журнал операций. Что записано, когда, чем инициировано и — для записей, инициированных AI, — с каким обоснованием. Именно это делает систему защитимой, когда спросят, почему изменилась запись.
Права нужно проверять, а не предполагать
Самый серьёзный сценарий отказа в AI-интеграции — агент, случайно ставший обходным путём вокруг контроля доступа.
Если ассистент по базе знаний индексирует документы под служебной учётной записью, которая видит всё, а потом отвечает на вопросы любому сотруднику, — вы построили инструмент обхода прав с дружелюбным интерфейсом. Спрашивающий получает содержимое, к которому не был допущен, и ни один журнал доступа не покажет нарушения, потому что формально его не было.
Поиск должен фильтроваться правами спрашивающего пользователя в момент запроса — не на этапе индексации и не широкой служебной учётной записью. Это дороже. Приемлемого обходного пути нет.
Тот же принцип касается записи: агент должен действовать с правами под конкретное действие, а не под административной учёткой, которая может всё, потому что так было проще настроить.
Адаптеры вместо прямых вызовов
Оберните каждую внешнюю систему в адаптер с интерфейсом, который определяете вы. Все особенности вендора — пагинация, ограничения частоты, непоследовательные имена полей, эндпоинт, возвращающий 200 с ошибкой в теле, — живут внутри этого адаптера и больше нигде.
Это не архитектурная чистоплотность, а практический ответ на то, что чужие API меняются без предупреждения, а лимиты обнаруживаются в продакшене. Когда вендор что-то ломает, вы правите один файл, а не проверяете все места вызова.
Это же делает систему тестируемой. Написать надёжные тесты против живой ERP нельзя; против интерфейса адаптера — можно.
Когда API нет
У многих полезных систем нет пригодного интерфейса. Варианты, примерно в порядке предпочтения:
- Поддерживаемый интерфейс интеграции, который вы не нашли, — искать стоит упорнее, чем кажется разумным.
- Интеграция на уровне базы данных, по возможности только на чтение и по согласованию с вендором.
- Файловый обмен по расписанию. Немодно, абсолютно надёжно и часто достаточно.
- Задокументированный адаптер, сделанный вместе с владельцем системы.
Чего мы по возможности избегаем — автоматизации через интерфейс, когда чужую систему «кликают» как пользователь. Это хрупко, ломается на ближайшем релизе вендора и обычно нарушает его условия. Это крайняя мера, и планировать её нужно как временный мост с известным сроком, а не как архитектуру.
Лимиты частоты — это проектное ограничение
У чужих API есть лимиты, и обнаруживаются они обычно при первой же реальной перезаливке данных.
Проектируйте с их учётом сразу: ставьте записи в очередь вместо синхронной отправки, группируйте там, где API это поддерживает, и делайте так, чтобы при троттлинге система деградировала мягко — медленнее, а не сломанно. Перезаливка, которой нужна ночь, — это нормально. Перезаливка, которая долбит API, пока вендор не отключит ваш ключ, — это инцидент.
Неэффектный вывод
Основная сложность AI-интеграции — не в AI. Это та же дисциплина распределённых систем, что и всегда: идемпотентность, валидация, права, наблюдаемость, мягкая деградация.
Модель — интересная часть. Интеграция — та часть, от которой зависит, будет ли всё это работать через год.