Agentic AI: что из западных подходов переносится в российский B2B

Почему западный playbook не переносится напрямую

Когда Anthropic публикует документацию по Claude Managed Agents, а Gartner прогнозирует, что к 2028 году 33% корпоративных приложений будут включать агентный ИИ, российский ЛПР оказывается в неудобной позиции: материалов много, применимость — под вопросом.

Проблема не в том, что западные подходы плохи. Проблема в том, что они разработаны для экосистемы, которой в РФ нет: AWS Bedrock, Azure AI Foundry, Salesforce Agentforce, облачный Claude API. Всё это либо недоступно, либо создаёт compliance-риски по 152-ФЗ при работе с реальными бизнес-данными.

При этом концептуальный уровень — паттерны, архитектурные решения, метрики — вполне применим. Нужен фильтр переносимости.

Фильтр переносимости: 5 паттернов × 3 вердикта

Ниже — таблица, которой нет ни в одном из существующих материалов по теме. Для каждого западного паттерна: суть, статус в РФ и что делать.

Ключевой вывод: концептуальный слой (что делать) переносится хорошо. Инфраструктурный слой (на чём делать) требует полной замены.

MCP: USB-C для корпоративных систем

Один из наиболее недооценённых паттернов в российском контексте — Model Context Protocol. Часто его воспринимают как «западную технологию для западных стеков». Это ошибка.

MCP — открытый протокол под управлением Linux Foundation. Его суть: агент не должен знать, как именно устроена каждая система, с которой работает. Вместо этого каждая система предоставляет MCP-сервер — стандартизированный интерфейс. Агент обращается к нему по единому протоколу.

Аналогия: до USB-C каждый производитель ноутбуков делал свой разъём. После — один кабель работает везде. MCP делает то же самое для корпоративных систем.

Для 1С это означает: вместо того чтобы писать кастомную интеграцию агента с каждым объектом конфигурации, вы один раз разворачиваете MCP-сервер поверх 1С REST API — и агент получает унифицированный доступ к номенклатуре, контрагентам, документам, остаткам. Всё это работает on-prem, без передачи данных наружу.

Реализации MCP-серверов для 1С уже существуют и используются в российских проектах. Это не экспериментальная технология — это практический мост между западным агентным стеком и отечественной ERP-реальностью.

Data-readiness: чеклист перед запуском агента

Deloitte фиксирует: 48% компаний, пытающихся внедрить агентный ИИ, упираются в searchability данных, 47% — в reusability. В российском B2B с типичной историей 1С эти цифры, скорее всего, выше.

Пройдите чеклист до того, как принимать решение об агенте:

• Единая номенклатура. Одни и те же товары/услуги называются одинаково во всех документах? Или «Болт М8» и «болт м8х20» — это разные позиции в разных базах?
• Актуальность справочников. Когда последний раз чистились справочники контрагентов, номенклатуры, сотрудников? Есть ли задвоения?
• Структурированность ключевых полей. Адреса, ИНН, суммы — в стандартных полях или частично в комментариях и «свободных» реквизитах?
• Доступность данных через API. Есть ли REST API или другой программный интерфейс к 1С? Или данные доступны только через выгрузки в Excel?
• Полнота истории. Данные за последние 2–3 года в одной базе или разбросаны по нескольким конфигурациям после переходов?
• Права доступа задокументированы. Понятно ли, какие данные агент может читать, а какие — нет? Есть ли ролевая модель?
• Baseline метрики. Известно ли, сколько времени сейчас занимает ручной процесс, который агент должен автоматизировать? Без baseline невозможно измерить ROI.

Если три и более пунктов дают ответ «нет» — начинайте с аудита данных. Агент, запущенный поверх грязных данных, будет галлюцинировать и давать противоречивые ответы. Это не проблема модели — это проблема фундамента.

Мини-кейс: агент поверх 1С — что сработало, где застряли

Обобщённый кейс из практики российского производственного B2B (металлообработка, ~500 сотрудников).

Задача: сократить время на подготовку коммерческих предложений. Менеджеры тратили 40–60 минут на каждое КП: поиск актуальных остатков, цен, сроков, формирование документа.

Что сделали: агент с read-only доступом к 1С через REST API + MCP-сервер. LLM — open-source модель on-prem (Qwen2.5 72B на собственном GPU-сервере). Агент отвечает на NL-запросы менеджера, формирует черновик КП, менеджер проверяет и отправляет.

Что сработало: время на черновик КП — с 40 минут до 7 минут. Агент корректно извлекает остатки и цены. Human-in-the-loop встроен органично: менеджер всё равно проверяет перед отправкой клиенту.

Где застряли:

• Первые два месяца агент путал номенклатуру из-за задвоений в справочнике. Пришлось остановить пилот и провести дедупликацию — это заняло три недели.
• Evaluation-фреймворк не был выстроен заранее. Ошибки обнаруживались случайно, а не системно. После выстраивания evals на 200 реальных запросах hallucination rate снизился с 18% до 4%.
• Попытка дать агенту write-доступ (автоматически создавать черновик документа в 1С) была отложена — слишком высокий риск ошибочных записей без дополнительного слоя валидации.

Итог: агент в production по read-only сценарию. Write-доступ — следующий этап после 6 месяцев стабильной работы и выстраивания audit trail.

Антипаттерны: как российские компании копируют западный подход неправильно

1. Выбирают платформу до выбора модели. В западном контексте модель — это деталь: можно переключиться с Claude на GPT-4 в один клик. В РФ выбор модели определяет всю архитектуру: on-prem open-source требует GPU-инфраструктуры, GigaChat Enterprise — отдельного договора и развёртывания, YandexGPT — облачного контура с соглашением об обработке данных. Начинайте с модели, потом выбирайте фреймворк.

2. Копируют западный SaaS-стек без compliance-проверки. Claude Managed Agents, Azure AI Foundry, Agentforce — всё это облачные сервисы с обработкой данных вне РФ. Пилот на тестовых данных проходит отлично. Потом юристы смотрят на реальные данные и говорят «нет». Агент застревает на пилоте навсегда. Compliance-проверку нужно делать до начала пилота, а не после.

3. Оценивают агента по демо, а не по evals. «Wow-демо» на подготовленных данных — не показатель. Evaluation-фреймворк на реальных бизнес-документах (минимум 100–200 примеров) должен быть выстроен до перехода в production. Без него невозможно знать, когда агент ошибается систематически.

4. Игнорируют human-in-the-loop для необратимых действий. Отсутствие checkpoint перед финансовыми транзакциями, удалением данных или отправкой документов контрагентам — прямой путь к production-инциденту. Это не паранойя: в марте 2026 года был зафиксирован кейс с Claude Code, где агент выполнил необратимые действия без подтверждения. Human-in-the-loop — это не тормоз автоматизации, это страховка, которая позволяет агенту вообще работать в production.

Почему 86–89% пилотов не доходят до production — и что добавляет РФ

Глобальная статистика (Deloitte, FifthRow): только 11–14% агентных пилотов переходят в production. Причины универсальные: качество данных, отсутствие evals, compliance-барьеры, неготовность процессов.

В российском B2B к этому добавляются специфические барьеры:

• Отсутствие managed-платформ. На Западе можно взять готовый Agentforce или Claude Managed Agents и сфокусироваться на бизнес-логике. В РФ нужно собирать стек самостоятельно: LLM + оркестратор + инструменты + мониторинг. Это требует компетенций, которых часто нет внутри.
• Разрозненность данных в 1С. Типичная история: несколько конфигураций, переходы между версиями, ручные правки в базе. Data-readiness score ниже, чем у западных компаний с SAP/Oracle.
• Отсутствие культуры evals. Западные команды привыкли к CI/CD для ML-моделей. В российском B2B evaluation-фреймворк для агентов — редкость.
• Неопределённость с audit trail. 152-ФЗ требует логирования операций с ПДн. Для агентных систем это означает: каждое действие агента должно быть задокументировано. Compliance audit trail coverage — метрика, которую нужно закладывать в архитектуру с первого дня.

Целевой бенчмарк для РФ-проектов: если вы выстроили data-readiness, evals и human-in-the-loop до начала пилота — шансы перейти в production существенно выше глобального медиана в 14%.

Метрики, которые стоит отслеживать с первого дня

Без измерений невозможно ни обосновать бюджет перед CFO, ни понять, когда агент готов к production:

• Hallucination rate на domain-specific evals: % ответов с фактическими ошибками на тестовом наборе из реальных бизнес-документов. Целевой уровень для production — менее 5%.
• Human escalation rate: % задач, где агент запрашивает подтверждение человека. Слишком высокий (>40%) — агент не уверен в данных. Слишком низкий (<5% для критических операций) — нет guardrails.
• Время ответа агента vs. ручной процесс — baseline для ROI-расчёта. Без baseline нет обоснования.
• Compliance audit trail coverage: % действий агента, покрытых логированием. Для операций с ПДн — должно быть 100%.
• Стоимость inference на задачу (токены × тариф on-prem или API) vs. стоимость ручного выполнения. Для обоснования бюджета перед финансовым директором.

Что делать прямо сейчас

Практическая последовательность для ЛПР, который хочет начать — не дожидаясь идеальной инфраструктуры:

1. Пройдите data-readiness чеклист по данным в 1С/ERP. Это займёт день и покажет реальную точку старта.
2. Определите один узкий сценарий с измеримым baseline: сколько времени сейчас занимает процесс вручную.
3. Выберите LLM-модель исходя из требований 152-ФЗ и наличия GPU-инфраструктуры — до выбора платформы.
4. Выстройте evaluation-фреймворк на реальных данных до запуска пилота, а не после.
5. Начните с read-only доступа к данным. Write-доступ — только после 3–6 месяцев стабильной работы и выстроенного audit trail.
6. Назначьте human checkpoint — конкретного человека с конкретной ролью, который подтверждает действия агента в критических сценариях.

Агентный ИИ — не вопрос «внедрять или нет». Это вопрос «какую часть западного playbook можно взять в работу уже сейчас». Ответ: концептуальный слой — весь. Инфраструктурный — с заменой на on-prem и локальные модели. Данные — сначала.

Смежные материалы блога brezatech: если вас интересует технический угол запуска LLM в production без ML-отдела — см. статью про production LLM checklist. Вопросы регуляторики 152-ФЗ применительно к генеративному ИИ разобраны в отдельном материале. О том, когда данных достаточно для BI и AI — в статье про data readiness.