Я разрабатываю информационные системы уже 20 лет. И каждый раз, когда слышу «а давайте встроим сюда ИИ навсегда», у меня дёргается глаз.
Потому что по умолчанию все думают одинаково. Нашли процесс, посадили туда LLM, оставили жить. Чат-бот в поддержке, агент в CRM, ассистент в аналитике. Модель становится постоянной деталью механизма – как база данных или очередь.
Это не архитектура. Это привычка.
И вот недавно я наткнулся на точку зрения, которая эту привычку ломает. Общался с innovation director большой британской enterprise-компании. Они уже провели несколько раундов AI-оптимизации, причём не в стиле «сократим людей», а как реальное улучшение работы. И вывод у них получился неожиданный: держать LLM постоянной частью бизнес-процессов – слишком рискованно.
Чему мы вообще делегируем
Сперва договоримся, что такое LLM в этой картине. Не разум. Не сознание.
Я смотрю на неё как на софтверный компонент, которому можно делегировать часть мышления: интерпретацию контекста, работу с неоднозначностью, построение следующего шага. И только. Мы не отдаём ей принятие решений. Мы отдаём ей работу с размытостью там, где обычный код спотыкается.
Значит, и вопрос не в том, «как впихнуть LLM в продукт». Вопрос в том, оставить её там навсегда или использовать как временный инструмент.
Разведчик, а не жилец
Риска тут два. Первый понятный – vendor dependency, привязка к чужим ценам, лимитам и политикам. Второй тоньше: встраивая LLM в процесс навсегда, вы делегируете часть бизнес-мышления внешнему стохастическому компоненту. То есть тому, что по своей природе выдаёт вероятностный результат, а не гарантированный.
Поэтому LLM здесь – не финальная архитектура. Это разведчик.
Работает он в три захода:
- Людям дают агентов или LLM-помощников. Они работают в реальных задачах, а система собирает данные: что люди реально делают, что повторяют, где принимают решения, какие правила живут только в головах и в workflow никогда не были описаны.
- Логи анализируются, из них вытаскиваются устойчивые паттерны.
- Часть процессов автоматизируется уже не через LLM, а через обычный код: workflow-логика, правила в CRM, интеграции, дашборды, approval flows, внутренние тулзы.
Идея не в том, чтобы навсегда усадить нейронку в каждый процесс. Наоборот. Использовать её как временный исследовательский слой, понять реальное операционное поведение компании, а потом всё, что можно формализовать, вернуть в обычный детерминированный код.
Модель отработала разведку – и ушла. На её месте остаётся скучный предсказуемый код. Он не галлюцинирует, не жрёт токены и не зависит от чужого API.
Почему это бьёт в старую боль
Классическая автоматизация двадцать лет спотыкается об одно и то же. Об discovery.
Прежде чем что-то автоматизировать, надо точно понять, как это работает. А люди не могут объяснить собственную работу. Половина правил живёт в головах, в негласных договорённостях, в «ну тут я обычно смотрю и решаю».
Раньше это лечили аналитиками. Посади человека рядом, понаблюдай, опиши процесс. Но посадить аналитика к каждому сотруднику в компании на десятки тысяч человек – нереально. А раздать LLM-помощников и собрать логи реального поведения – вполне.
Именно в этом ценность. Не в том, что ИИ умнее человека. А в том, что он масштабируется туда, куда живой аналитик физически не дотянется.
И сразу уточню, пока не поняли неправильно. Это не про то, чтобы переложить работу на нейронку. Люди работают сами. Ты собрал логи, проанализировал, предложил, что автоматизировать. На основании реальных данных, а не впечатлений.
«А кто ответит перед советом директоров?»
В чате мне сразу прилетело здравое возражение. Мол, доверять нейронке нельзя там, где цена ошибки высокая. В юридические вещи, в расшифровку аудио для протоколов – лучше не пускать.
«Галлюцинации могут стоить больших денег. Не могу же сказать совету директоров, ну сорян пацики тут нейронка проебалась».
Возражение справедливое. Но оно не против разведчика, оно за него.
Именно потому, что LLM не остаётся на критичном процессе навсегда. Она помогает понять, что там автоматизировать обычным кодом, и уходит. А перед советом директоров отвечает детерминированная система с предсказуемым поведением. Разведка снимает риск ровно потому, что не претендует на роль постоянного исполнителя.
Это не серебряная пуля
Тут легко увлечься и объявить scout-подход универсальным решением. Не надо.
Как заметил коллега в чате, в разных бизнес-процессах разное соотношение детерминированной и вариативной составляющей. Где-то процесс на 90% из чётких правил – его и стоит формализовать в код после разведки. А где-то вариативность и есть суть работы, и там LLM по делу останется в рантайме.
Я и сам про это говорил: такие техники почти не обсуждают. Куда чаще мусолят заезженные способы работы с ЛЛМ. А это интересная мысль, с которой стоит поиграться и подумать, где она применима. Не догма, а лишний вопрос, который полезно себе задать.
Что делать на практике
Перед каждым процессом задайте себе три вопроса.
- Это runtime или scout? LLM должна остаться в процессе навсегда – или её задача лишь понять, что тут автоматизировать кодом?
- Сколько здесь детерминированного, а сколько вариативного? Больше чётких правил – уходим в обычный код после разведки. Больше неоднозначности – LLM оправданна в рантайме.
- Кто отвечает за результат? Если ошибка стоит дорого, критичную часть держим на предсказуемом коде, а модель используем как помощника, а не как финальное звено.
Звучит парадоксально, но самый зрелый способ внедрить ИИ – иногда внедрить его временно.
Дайте модели разведать территорию, собрать карту реальных процессов. А потом постройте на этой карте надёжные, скучные, детерминированные дороги.
И прежде чем сажать ЛЛМ в прод навсегда, спросите себя: вам нужен исполнитель или разведчик? Обсудить можно в нашем чате.