Нельзя так просто взять и внедрить LLM в прод: как управлять ИИ-системами в компании

Сегодня ИИ-агенты, которые что-то делают автономно, уже никого не удивляют.

В демках всё выглядит шикарно, но в проде большинство таких агентов не работает. Рынок уже насытился этими демками, но как же превратить их в готовое решение для продакшена? Давайте разберемся.

Не путаем LLM и систему на базе LLM

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

Поэтому выигрывает не компания с самой умной моделью, а компания с самой управляемой ИИ-системой. Такие системы нужно проектировать, измерять, контролировать и постепенно масштабировать.

Когда компании начинают внедрять ИИ, они часто думают, что достаточно выбрать модель, подключить интерфейс, дать доступ к данным — и волшебным образом компания станет AI-First (нет).

В продакшене модель — это интеллектуальное ядро. Но конечный результат создаёт система вокруг неё: управление контекстом, интеграции с различными сервисами, сложная оркестрация, механизмы передачи задачи человеку, а также экономические эффекты.

Поэтому внедрить LLM ещё не означает внедрить ИИ-систему, приносящую пользу бизнесу.

Почему между демками и продом такая пропасть

В демо, как правило, всё стерильно: понятный запрос, хороший контекст и нет конфликтующих правил.

В проде всё наоборот: шумные данные, хаотичные формулировки, устаревшие документы, а ошибка ^[1] может стоить денег, репутации или привести к серьёзному инциденту.

В этот момент выясняется, что в проде сбоит не столько модель, сколько вся система вокруг неё: не тот документ попал в контекст или не сработал инструмент. Так из каких элементов на самом деле состоит готовая к продакшену ИИ-система в компании?

Где на самом деле создается ценность

Для бизнеса ценность появляется только тогда, когда ИИ улучшает бизнес-метрики: быстрее закрывает кейсы в поддержке, сокращает цикл разработки и повышает качество решений.

Если система выдала результат, который сотрудник ещё должен проверять десятки минут и переписывать вручную, то ценности от такой системы может не быть вовсе. Иногда ИИ в таком процессе только добавляет ещё один уровень работы.

Поэтому нужно понять, какую метрику мы улучшаем. У ИИ есть смысл в основном в трёх случаях: если он делает работу быстрее, дешевле или качественнее.

Начинать нужно не с модели, а со сценария использования

Большинство провальных ИИ-проектов стартует одинаково. Сначала команда обсуждает, как она будет файнтюнить очередную модель и навешивать на неё RAG. А потом придумывает, куда всё это пристроить.

Это неправильная логика ^[2]. Правильный путь начинается с процесса. Какую задачу человек или команда реально решают? Где именно в процессе теряются время, деньги, качество или скорость? Где нужен ИИ, а где хватит обычной автоматизации? И как должна измениться роль человека после внедрения?

Сначала мы формализуем процесс в виде AS-IS-диаграммы. Затем выявляем точки автоматизации, потом проектируем TO-BE-процесс с новой ролью человека и ИИ-агентами. И только потом выбираем технологии под конкретную задачу.

Не каждой задаче нужна LLM. Если всё определяется жёсткими правилами, то это детерминированная логика. Если задача связана с прогнозом на больших массивах данных, то применяем классический ML. А если мы работаем с языком и смыслами, то вот здесь подключаем LLM. Зрелая архитектура почти всегда гибридна: жёсткие правила, вызов ML-моделей для отдельных задач и LLM для интерпретации смыслов.

Четыре роли ИИ в продукте

Одна из причин провала многих ИИ-проектов — попытка спроектировать все сценарии использования одинаково. Но у ИИ как минимум четыре разные роли.

1. Функция. Это локальная автоматизация: суммаризация статьи, классификация документа или автозаполнение текста. Это самый простой и часто самый окупаемый уровень.

2. Ассистент. Система отвечает на запрос и помогает найти релевантную информацию. Она не действует сама по себе, а работает по инициативе человека.

3. Копилот. ИИ подсказывает шаги, готовит черновики, предлагает решения и помогает человеку двигаться по процессу быстрее.

4. Ограниченный агент. Система сама запускает цепочку действий в заданных границах: вызывает инструменты и передаёт результат дальше по процессу.

Это четыре разных класса продукта. У них разные требования к UX, контролю, риску, метрикам и архитектуре.

Но чем выше автономность, тем больше ответственности.

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

Главная проблема — контекст

Компании часто думают, что модель является главным ограничением, но на практике даже небольшие модели могут приносить ощутимую пользу. Дело в неправильном использовании контекста.

Даже мощная LLM будет ошибаться, если ей дали плохой контекст. И хуже всего то, что ошибаться она будет убедительно.

Контекст в компании — это не просто база знаний. Это задача пользователя, состояние процесса, применимые правила и ограничения, история действий, доступные инструменты и корпоративная память ^[3]: кейсы, исключения, шаблоны и накопленные решения.

Поэтому инженерия контекста сегодня — это уже отдельное направление работы.

Автономность нельзя повышать быстрее, чем контроль

Это один из главных законов агентной архитектуры.

Пока ИИ работает как функция, ассистент или копилот, риск ограничен. Он помогает, но человек всё ещё принимает финальное решение.

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

Поэтому автономность должна расти только вместе с контролем.

Чем больше у агента возможностей, тем выше и степень его свободы. Но мы не должны делать вольных агентов: наши агенты должны помогать бизнесу, поэтому нам нужно больше ограничений.

Если автономность растёт быстрее, чем контроль, то в какой-то момент вы обязательно столкнётесь с инцидентом.

Так у нас агент отрефакторил код, который рефакторить было не нужно, после чего бизнес-логика уже не работала должным образом. Инцидент выявили и починили, а агент получил по рукам более строгую политику доступов в репозитории.

Без evals нет управления качеством

LLM-системы опасны тем, что могут потихоньку деградировать.

Снаружи всё может выглядеть нормально: система отвечает, интерфейс живой, пользователи получают ответы. Но внутри качество уже просело.

Поменяли промпт — поломали соседний сценарий. Обновили API — агент стал хуже работать с инструментами. Пересобрали индекс в векторной базе — теперь мы извлекаем из RAG нерелевантную информацию. Но всё это можно не заметить, если нет системы оценки — evals.

Evals — это инструмент управления качеством.

Нужны два подхода. Первый — офлайн: golden datasets, эталонные и краевые сценарии использования. Второй — онлайн: реальные запросы, выборочные ревью, ошибки вызова инструментов и деградация системы уже в проде.

DataOps — подготовка контекста

Когда говорят про LLM в проде, внимание ^[4] часто уходит на модель, а данные воспринимаются как что-то вторичное. Но на практике без хорошего DataOps ничего хорошего не бывает.

Система использует конкретный контекст, который нужно откуда-то брать, обновлять, очищать и держать в рабочем состоянии. Понятно, что весь цикл DataOps мы разбирать не будем: он гораздо шире и включает также governance, разметку, архитектуру хранилищ данных и многое другое. Но если говорить о базе для LLM-систем, то здесь есть несколько обязательных уровней.

Источники данных

CRM, почта, внутренние документы, базы знаний — всё это нужно синхронизировать. Без доступа к контексту ни о какой ИИ-системе вообще говорить не приходится.

Очистка и нормализация

Реальные корпоративные данные часто славятся наличием дублей, мусора и разрозненных форматов. Если просто «скормить» всё это в векторную базу, то вы не получите умную систему.

Эмбеддинги и индексы

Это уже вопрос того, как данные превращаются в механизм поиска и подачи контекста. Индексы нужно обновлять, а качество поиска — постоянно проверять.

Актуальность и доступность контекста

Недостаточно один раз загрузить данные: контекст нужно поддерживать в актуальном состоянии. Если система работает на вчерашней информации, то сегодня она будет принимать неверные решения.

Качество данных

Здесь работает очень простой принцип: garbage in — garbage out. Если на входе у системы плохие данные, то на выходе не будет качественного результата.

Безопасность и контроль доступов

Контекст должен быть не только полным и актуальным, но и правильно ограниченным. ИИ-система не должна получать доступ ко всему подряд, а доступ к данным должен быть ограничен согласно ролевой модели.

MLOps — жизненный цикл модели

Если DataOps отвечает за данные и контекст, то MLOps — это уже про сам жизненный цикл модели. Опять же, в данной статье не целиком, а в контексте LLM.

Есть обучение ^[5] модели или дообучение на новых данных, адаптация модели под домен или конкретную задачу. Есть управление версиями: какие веса используются, какая конфигурация сейчас в проде, что именно поменялось между релизами. Есть деплой и, конечно, мониторинг: как модель ведёт себя после релиза и не просело ли качество на ключевых сценариях из-за дрейфа данных.

В классическом ML MLOps является центром всей системы. Но сегодня даже идеальная модель не гарантирует, что вся ИИ-система работает хорошо. Тем не менее MLOps остаётся критичным там, где у вас есть собственные дообученные модели под ваши задачи.

В LLM-системах модель тоже должна существовать с версионностью, тестами, понятным циклом обновления и контролем изменений.

AIOps — управление всей ИИ-системой в проде

А вот AIOps — это уже следующий уровень зрелости. Это управление всей ИИ-системой в проде.

Почему нужен отдельный термин? Потому что нам нужно контролировать не только модель, но и качество через evals, стоимость работы системы, задержки, инструменты, оркестрацию, контекст, RAG, безопасность, поведение ^[6] агентов, фолбэки и всё, что происходит вокруг инференса, включая работу с пользователями.

Иными словами, AIOps — это управление поведением ^[7] системы, а не только её вычислительным ядром.

Например, модель может быть стабильной, но retrieval деградировал — и качество уже падает. Или стоимость выросла не потому, что модель стала дороже, а потому, что контекст стал длиннее и оркестратор начал делать лишние вызовы. Да и вообще пользователи жалуются, что чатбот бесполезный. Всё это уже далеко не только про MLOps.

Поэтому в AIOps важны несколько вещей: качество, стоимость, задержки, надёжность инструментов, качество контекста, безопасность и наблюдаемость.

В зрелой компании ИИ в проде — это операционная среда, где нужно видеть и контролировать весь процесс решения задачи: от входа и контекста до действия, результата, стоимости и риска.

Релиз LLM-системы — это управляемый эксперимент

Выкатывать LLM в прод как обычную продуктовую фичу — плохая идея.

Даже хорошо протестированная система в реальной среде сталкивается с тем, чего не было в тестах: странными формулировками, новыми типами кейсов, неожиданными цепочками действий и человеческим фактором.

Поэтому запуск такой системы должен происходить поэтапно. Сначала — скрытая проверка на реальных данных без влияния на пользователя. Затем — внутреннее использование командой на себе. Далее можно симулировать поведение реального пользователя. Потом — запуск на небольшой части реальных пользователей. После этого — постепенное расширение охвата. И только в самом конце — полноценное внедрение для всех.

Но ещё важнее другое: у релиза должны быть заранее определённые критерии отката. Если упала какая-то метрика, участились сбои вызова инструментов или просело качество, то релиз должен тормозиться автоматически.

Как измерять работу ИИ правильно

Бизнесу нужно измерять завершённую работу.

Но и этого мало. ИИ-метрики должны подниматься выше — на уровень бизнеса: скорость вывода продуктов на рынок, маржа или стоимость операций.

Экономика ИИ: считать нужно не токены, а юнит

Наивно полагать, что экономика ИИ равна счёту за API.

Настоящая стоимость включает не только токены, но и работу всей системы: подготовку и хранение данных, RAG, оркестрацию запросов, вызов инструментов и эскалации на человека.

Поэтому актуальный вопрос — сколько стоит полезно выполненная задача. У зрелой компании экономика ИИ считается на уровне единицы работы или выпущенной продукции.

UX в ИИ — это дизайн доверия

В обычных продуктах под UX обычно понимают удобство использования. В ИИ-системах UX — это ещё и управление доверием.

Проблема в том, что модель умеет звучать уверенно даже тогда, когда ошибается. Человек, естественно, склонен принимать уверенный тон за компетентность. Отсюда две крайности: слепое доверие или полное отторжение.

Хороший ИИ-UX калибрует доверие.

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

Показывать нужно не «мышление модели», а основание решения: фактчекинг, что именно решено, на основе каких документов было принято это решение и какие ограничения действовали.

Эскалация тоже должна быть частью UX, а не признаком плохой работы системы. Хорошая система умеет вовремя остановиться и передать человеку уже собранный и структурированный кейс.

Например, при KYC (Know Your Customer, процедуре проверки клиентов) клиентам с меньшим риском открывают счета в банке автоматически, а высокорисковых отправляют на подтверждение человеком с уже собранным досье из всего интернета.

Governance должен быть исполняемым

Многие компании совершают одну и ту же ошибку: пишут политики и регламенты, считая, что на этом governance внедрён.

Но это не так. Governance, который нельзя исполнить технически, бесполезен: он работает на уровне пожеланий, но никогда не работает в реальности.

Если агенту нельзя переводить деньги, это должно быть невозможно на уровне доступов. Если нельзя отправлять персональные данные в модель, это должно отсекаться на уровне guardrails. И если нужно расследовать инциденты, то каждый шаг должен быть зафиксирован.

Настоящий governance — это политика, которая исполняется кодом.

И чем больше умеет агент, тем важнее этот принцип. Каждый новый навык агента — это не только рост пользы, но и рост возможных рисков.

Безопасность начинается с ограничения ущерба

Как только система получает доступ к документам, внешним сервисам, API и данным, возникает вполне прикладной операционный риск. Появляются инъекции промптов через документы и внешние источники, утечки контекста или ошибки инструментов.

Поэтому базовый принцип безопасности для агентных систем: нужно давать агентам минимально необходимый набор доступов. Только нужные данные и только нужные инструменты на определённое время. Всё остальное закрыто по умолчанию.

Безопасность должна строиться так, чтобы даже при ошибке ущерб оставался ограниченным и контролируемым.

Что компании реально могут сделать с ИИ уже сегодня

Большинство компаний не будут выигрывать за счёт собственной большой модели: у них нет ресурсов её обучить. Для них основной интеллектуальный актив находится в контексте, оркестрации, логике работы процессов, интеграциях, evals, governance и прикладной экономике.

Именно здесь создается долгосрочное преимущество.

Не в самом доступе к модели, а в способности встроить её в компанию так, чтобы она работала лучше, дешевле, надёжнее и масштабируемее, чем у других.

ИИ-трансформация — это смена операционной модели

Главная ошибка компаний — добавить ИИ в старый процесс: прикрутить новый интеллект ^[8] поверх старой логики с неготовыми к изменениям людьми и отсутствием зрелой инфраструктуры.

Настоящая ИИ-трансформация начинается с вопросов: если часть когнитивной и операционной работы теперь может выполнять ИИ-система, как должен измениться сам процесс, сама роль человека и структура ответственности в компании? Как масштабировать компанию без роста штата и оставить людям только «человеческую» работу, а всё остальное доверить ИИ?

В AI-First-парадигме человек перестаёт быть исполнителем. Его роль смещается выше: теперь человек — оператор системы или менеджер ИИ-агентов.

Меняется не только скорость, но и сама суть работы. Люди не любят неопределённость и боятся, что ИИ их заменит. Но на самом деле меняется процесс их работы, поэтому нужно заранее начинать переобучение сотрудников после проектирования TO-BE-процесса.

Сначала меняется оргструктура компании под новые роли. Затем руководители каждой функции проводят командные встречи по внедрению ИИ, где каждый сотрудник демонстрирует прогресс: что было сделано, что сработало, что не получилось и какие выводы сделаны. Лучшие практики, рабочие кейсы и готовые агенты затем выносятся на уровень всей компании в формате демо-сессий и внутренних вебинаров.

Параллельно запускается отдельная серия обучающих вебинаров, посвящённых тому, как создавать агентов: от постановки задачи и проектирования роли агента до тестирования, внедрения и оценки эффекта. Все наработанные практики фиксируются в корпоративной обучающей платформе и становятся частью стандарта онбординга, чтобы каждый новый сотрудник с первого дня понимал новые процессы работы в компании.

В моей практике экономические эффекты — это оптимизация миллионов долларов для компаний с полным редизайном процессов. Но, к примеру, есть и кейс, когда мы помогли сотрудникам колцентра лучше выявлять ошибки и больше продавать ^[9] — тут ИИ помогает, бизнес-эффекты имеются, но всё же это улучшение процесса, а не полный его редизайн. Пока в колцентре люди продают людям.

Нужно строить масштабируемую ИИ-платформу

Попытка внедрить ИИ везде и сразу, как правило, заканчивается одинаково: локальные эксперименты, отдельные демки и пилоты, разный стек, отсутствие переиспользуемых паттернов и общего контекста, недостаточный контроль над мультиагентными системами и отсутствие общей экономики.

Правильный путь такой:

Сначала — пилоты

Один-два-три сценария, где есть острая боль ^[10], процесс зрелый и понятный, а эффект можно быстро измерить.

Потом — платформа

Единый контекстный слой, безопасные интеграции, evals, governance, мониторинг, контроль качества и стоимости.

И только потом — масштабирование

Расширение по продуктам и командам.

Сначала ценность. Потом платформа. Потом масштаб.

Почему ИИ-проекты проваливаются

95% ИИ-проектов терпят провал ^[11] не из-за технологий, а по очень приземлённым причинам.

Их делали ради демки, а не под прод. У них не было владельца результата. У них не было evals. Контекст оказался плохим. Интеграция в процесс была слабой или экономика не сошлась. Автономность обогнала контроль, а governance остался в PDF. Да и вообще никто не решил, как именно измерять успех.

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

Выводы

LLM-система в компании — это не просто модель.

Это фреймворк из сценариев использования, контекста, архитектуры, интеграций, evals, мониторинга, governance, экономики и управления изменениями.

Если хотя бы один из них — слабое звено, то, согласно теории ограничений, устойчивость всей системы определяется самым слабым её элементом.

LLM сама по себе не меняет бизнес. Бизнес меняет только такая ИИ-система, которая встроена в процессы, ограничена правилами, измеряется метриками и управляется как часть бизнес-модели.

Поэтому сегодня компании должны в меньшей степени думать о том, какую модель им выбрать, а сфокусироваться на создании ИИ-системы, которой можно доверить реальную работу.

Если вам интересна тема ИИ, подписывайтесь на мой Telegram-канал ^{[12]  [13]}— там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.