Интеграция ИИ с корпоративными системами

От API к MCP: смена парадигмы

Традиционные API-интеграции - модель обращается к CRM, ERP через заранее описанные интерфейсы. При масштабировании это создаёт три проблемы:

1. Стоимость интеграции растёт линейно. Каждая новая модель или агент требует отдельной настройки доступа.

2. Время вывода решений увеличивается. Добавление сценария требует участия 3 - 4 команд.

3. Отсутствует единая логика управления контекстом. Модель получает данные фрагментарно, без сквозной семантической структуры.

По оценкам интеграторов, до 40% бюджета ИИ-пилотов уходит на настройку и сопровождение интерфейсов доступа к данным. MCP (Model Context Protocol) меняет эту картину.

MCP - это открытый протокол от Anthropic (ноябрь 2024), ставший за 18 месяцев стандартом де-факто для интеграции ИИ-агентов. Вместо множества разрозненных API формируется единый контекстный слой - «шина данных для ИИ». Источники данных публикуют свои возможности через MCP-серверы, агенты динамически формируют запросы. Подключение к контекстному слою происходит один раз - после этого количество агентов практически не влияет на сложность инфраструктуры.

Архитектура: три слоя интеграции

1. Системы-источники → MCP-серверы. Каждая система публикует инструменты через MCP-сервер:

• 1С:Предприятие - HTTP-сервис с 51 инструментом (JSON-RPC 2.0). Агент вызывает get_balance, get_document_list, create_object.
• CRM (Битрикс24) - MCP-сервер на Python/FastMCP, оборачивающий REST API.
• SCADA - OPC UA-клиент внутри MCP-сервера. Агент читает теги через read_tag('Temperature_Reactor_1').

2. API Gateway - единая точка входа. Kong, Traefik или Bifrost как LLM-шлюз:

• Failover-цепочки: Claude → GPT → локальная модель.
• Rate limiting: по пользователю, команде, бюджету токенов.
• Семантическое кэширование: одинаковые по смыслу запросы не идут в модель повторно - экономия 20 - 40%.
• PII-фильтрация: на выходе блокируются ИНН, паспортные данные, номера счетов.
• Audit trail: каждый вызов журналируется с метаданными.

3. Аутентификация и авторизация. Keycloak как OAuth 2.1/OIDC-провайдер:

• SSO: единый вход через корпоративный LDAP.
• RBAC с per-tool scoping: токен агента содержит scope 1c.read_nomenclature, но не 1c.create_payment.
• OAuth Token Exchange для Kubernetes-сред.
• Proof-of-Possession (DPoP): привязка токена к сессии, предотвращает replay-атаки.

MCP-безопасность: OWASP и Red Hat

OWASP GenAI Security Project в 2026 году выпустил Practical Guide for Secure MCP Server Development. Red Hat опубликовал детальный разбор OAuth 2.1 + PKCE для MCP. Ключевые практики, которые мы применяем:

• CIMD (Client ID Metadata Documents) вместо Dynamic Client Registration - статический JSON-файл для проверки клиента.
• Resource Indicators (RFC 8707): токен скоуплен на конкретный MCP-сервер, не может быть переиспользован.
• Confused deputy prevention: валидация state-параметров и redirect URI.
• Per-tool authorization: каждый инструмент MCP-сервера требует отдельного scope.
• mTLS для внутренних service-to-service MCP-соединений.

Пример: агент проверяет остатки и создаёт заказ

1. Пользователь в Telegram: «Проверь остатки гаек М12 и закажи 500 штук у ООО 'Метизы'».

2. LLM определяет intent: чтение справочника + создание документа.

3. MCP-клиент вызывает find_by_name(справочник='Номенклатура', имя='Гайка М12').

4. Получив номенклатурную позицию, вызывает get_balance(account_code='10.01', item='Гайка М12').

5. Видит остаток 200 шт. - меньше запрошенных 500.

6. Формирует ответ: «Гаек М12 на складе 200 шт. Создать заказ поставщику на недостающие 300?»

7. После подтверждения пользователя - create_object(тип='ЗаказПоставщику', контрагент='Метизы', ...).

Весь процесс - в закрытом контуре. RBAC гарантирует, что агент не сможет провести платёж без human-in-the-loop.