Пилот в ChatGPT и LLM в продакшене отличаются контуром: источник данных, оценка качества (evals), ограничения ответа, логирование и правовой режим ПДн. ML-отдел не обязателен — обязательны владелец процесса, интегратор и чеклист приёмки до включения для сотрудников или клиентов. Пилот ≠ продакшен Команде часто кажется: «мы уже используем ИИ» — потому что отдел пробовал ChatGPT, Copilot или телеграм-бота на базе GPT. Пилот отвечает на вопрос: *решает ли модель задачу на наших примерах?* Продакшен отвечает: *будет ли это стабильно, безопасно и измеримо через 3–12 месяцев?* Критерий | Пилот | Продакшен Данные | Выборка, ручная подгрузка | Автообновление, версии, доступы Качество | «Нравится эксперту» | Evals, метрики, регрессии Риск | Ошибка видна сразу | Масштаб × последствия ПДн | Часто игнорируют | 152-ФЗ, договоры, маскирование Стоимость | Не считают | Бюджет токенов + поддержка Без этого различия проекты застревают между «впечатлило на демо» и «боимся включить для клиентов». Чеклист до запуска 1. Владелец процесса и граница сценария • Назначен бизнес-владелец (не только IT): кто принимает качество. • Сценарий описан в одном абзаце: вход → действие LLM → выход в систему. • Явно перечислено, что LLM не делает (скидки, юридические обещания, медицина). 2. Источник правды • Ответы с цифрами и фактами идут из БД, API, индекса — не из «памяти» модели. • Версия данных в логе каждого ответа (дата прайса, id документа). • Для RAG — пайплайн переиндексации при обновлении источников (см. материал про RAG). 3. Evals (регрессионные тесты) • Golden set: 50–100 реальных запросов + эталонный ответ или критерий «допустимо/нет». • Метрики минимум: доля верных, доля отказов, доля эскалаций. • Прогон evals перед каждым изменением промпта, модели или индекса. OpenAI и Anthropic в документации сходятся: без автоматизируемых evals качество деградирует незаметно. 4. Guardrails • Системный промпт + post-filter: запрещённые темы, PII, утечка инструкций. • Лимиты длины, таймауты, fallback «передать человеку». • Для клиентских каналов — disclaimer и кнопка связи с оператором. 5. Интеграция и observability • Логи: prompt hash, model id, latency, tokens, user/session (без лишних ПДн). • Алерт на рост ошибок, latency, стоимости. • Связь с CRM/ERP/тикетами — заявка не теряется в чате. 6. Право и 152-ФЗ (РФ) • Классификация: есть ли ПДн в запросах и логах. • Договор с провайдером API / хостингом, политика на сайте. • Минимизация: не отправлять в модель лишние поля «на всякий случай». • При необходимости — on-prem или российский провайдер (оценка после пилота на API). 7. Эксплуатация и бюджет • Ответственный за промпты и базу знаний (0,2–0,5 FTE на средний проект). • Резерв 20–40% бюджета на итерации после запуска. • Календарь ревью: раз в месяц — evals + инциденты + стоимость. Типовые ошибки • «В prod на следующий день после демо» — нет evals и мониторинга. • Один mega-prompt на все отделы — некontrolируемые ответы. • Fine-tune первым шагом — дорого поддерживать; чаще хватает RAG + tools. • Нет эскалации — пользователь застревает с галлюцинацией. • Игнор стоимости токенов — при росте трафика бюджет «взрывается». Минимальная архитектура (без ML-отдела) Цепочка, которую собирают без ML-отдела: • Канал — виджет, Telegram, intranet. • Orchestrator — правила маршрутизации и эскалации. • LLM API + tools — search, CRM, lookup по данным. • Guardrails + logging — фильтры, логи, алерты. • Evals pipeline — регрессионные тесты промптов при каждом изменении. ML-инженер не обязателен на старте. Нужны: backend/интегратор, владелец процесса, человек, который ведёт golden set. Когда отложить prod • Нет владельца процесса и критериев «хорошего ответа». • Данные хаотичны — аудит качества данных не делали. • Юридический контур не согласован, а в чат пишут клиенты с ПДн. • Ожидание «LLM заменит отдел» без метрик — лучше сузить сценарий. Связанные материалы • RAG и источник правды — данные под LLM. • Когда чат-бот не справится — граница сценария vs процесс. Ключевые факты • Gartner и отраслевые обзоры 2025–2026: основной риск enterprise LLM — не «слабая модель», а отсутствие evals, guardrails и версионирования промптов • 152-ФЗ: при обработке ПДн через облачный API нужны договор поручения, политика и минимизация данных в промпте — не «анонимизация на словах» • Golden set из 50–100 типовых запросов с эталоном — минимальный барьер перед prod; без него качество меряют субъективно • Стоимость в prod = токены + интеграции + мониторинг + итерации промптов; закладывают 20–40% бюджета на поддержку после запуска