Разобрать задачу
Назад к блогу

Почему enterprise AI ломается между demo и production

2026-05-23·3 min read
Enterprise AILLMАгентыProductionAI Readiness

Большинство enterprise AI-проектов не ломается на этапе demo. Demo обычно работает. Команда выбирает чистый пример, prompt под него подкручен, модель отвечает убедительно, и в комнате видно потенциальную пользу.

Проблема начинается позже, когда система должна выжить в production-условиях.

Demo скрывает operating model

Demo доказывает, что модель может дать полезный ответ в контролируемой ситуации. Но оно не доказывает, что компания сможет эксплуатировать систему.

Production требует ответов на менее эффектные вопросы:

  1. Кто владеет workflow после запуска?
  2. Какие данные модель может видеть и под чьими правами?
  3. Что происходит, если retrieval вернул устаревший, конфликтующий или чувствительный контекст?
  4. Какие tool calls требуют human approval?
  5. Как команда воспроизведет плохой ответ или рискованное действие?
  6. Какая стоимость одной задачи при реалистичной нагрузке?
  7. Кто обновляет prompts, evals, документы и escalation rules?

Если на эти вопросы нет ответов, проект превращается в demo с операционным долгом.

Настоящая единица - workflow

Enterprise AI нужно начинать с workflow, а не с модели.

Полезный workflow имеет давление: он медленный, дорогой, рискованный или стратегически важный. У него также есть наблюдаемые inputs, outputs, decisions, users, permissions, exceptions и success metrics.

Когда команды начинают с модели, они спрашивают:

Куда бы нам применить эту модель?

Когда команды начинают с workflow, они спрашивают:

Какую часть этого процесса можно улучшить без неприемлемого риска?

Второй вопрос намного полезнее.

Контекст - это не просто длинный prompt

Многие production-сбои - это сбои контекста.

Модель получает слишком много контекста, устаревший контекст, контекст не той роли, данные, которые нужно было отфильтровать до retrieval, или tool output, который ошибочно воспринимается как trusted instruction.

Для production-систем контекст требует архитектуры:

  • retrieval с учетом permissions;
  • разделение task context, business context, user context, tool context и memory;
  • логи фактического context package, который ушел в модель;
  • evals для качества retrieval, а не только финального ответа;
  • правила того, что вообще не должно попадать в prompt.

Поэтому context engineering важнее декоративного prompt engineering.

Evals - мост к production

Если evals нет, каждое изменение становится догадкой.

Серьезному pilot нужен небольшой, но реальный evaluation set:

  • примеры из настоящего бизнес-процесса;
  • expected outcomes и unacceptable outcomes;
  • adversarial cases;
  • retrieval checks;
  • tool-call checks;
  • refusal и escalation checks;
  • cost и latency measurements.

Одной accuracy недостаточно. Систему нужно проверять на security, стоимость, observability и операционное поведение.

Tool-using agents меняют модель риска

Чатбот может ошибиться. Tool-using agent может ошибиться и действовать.

Это меняет security model. Нужно проверять:

  • какие tools существуют;
  • что каждый tool может сделать;
  • под чьей identity действует агент;
  • какие действия имеют side effects;
  • какие tool outputs являются untrusted;
  • какие действия требуют confirmation;
  • как логируются важные model calls и tool calls.

Prompt injection - только часть проблемы. Главный вопрос в том, остается ли система безопасной, когда hostile или ambiguous context попадает в loop.

Production checklist

До продвижения AI pilot дальше я хочу видеть доказательства в шести областях:

  1. Business pressure: workflow достаточно важен, чтобы оправдать систему.
  2. Data readiness: нужные знания существуют, доступны и могут быть permissioned.
  3. Architecture: context, tools, memory и handoff описаны явно.
  4. Evals: команда может измерять regressions и risky behavior.
  5. Security: data leakage, tool misuse, prompt injection и approvals проверены.
  6. Ownership: кто-то владеет prompts, evals, monitoring, costs и updates после запуска.

Если этого нет, часто безопаснее не строить сразу. Сначала аудит, сужение workflow и определение минимального полезного production slice.

Это менее эффектно, чем очередное demo. Зато так AI-системы становятся полезными.

Есть похожая AI-задача?

Отправьте короткий бриф, и я предложу минимальный платный следующий шаг: консультацию, аудит, security review или разработку.