Не всё нужно превращать в AI: где LLM действительно полезна, а где обычные правила надёжнее

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

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

Допустим:

Здесь нет задачи «понять смысл».
Здесь уже есть правило.
И для меня это важное различие.

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

В одном из моих проектов была как раз такая логика.

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

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

Совсем другая ситуация, когда на входе нет жёсткой формы.

Например, клиент пишет:

«Добрый день, мне нужно понять, можете ли вы сделать это до конца недели, объект находится в области, желательно сегодня связаться».

Здесь нельзя заранее написать одно простое правило на все возможные формулировки. Вот здесь AI уже реально помогает.

Он может:

То есть я использую AI там, где есть язык, смысл, вариативность и неструктурированные данные. Но дальше для меня начинается очень важная часть.
Я не воспринимаю ответ модели как истину только потому, что он звучит уверенно. AI может прекрасно оформить ответ, вернуть правильный JSON, разложить данные по полям — и всё равно ошибиться в самом содержании.

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

Вот это, наверное, лучше всего описывает, как я сама сейчас проектирую такие системы.

Допустим, приходит заявка в свободной форме.

AI может понять из текста:

Но что делать с этой заявкой дальше, я уже не обязана отдавать модели.

Если у бизнеса есть правило:

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

Получается примерно так:

AI понимает неструктурированный вход → обычная логика применяет обязательные правила → система выполняет нужное действие.

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

Я много работаю с AI и при этом всё равно перепроверяю важные вещи. Если мне нужен критичный факт — я не просто принимаю первый ответ. Я прошу найти источники, сравнить варианты, посмотреть похожие решения. Если принимаю серьёзное решение — мне важно понимать, на чём оно основано.

В бизнес-системах для меня действует тот же принцип.

Если цена ошибки высокая, решение необратимое или связано с деньгами, доступами, обязательствами перед клиентом — я бы не оставляла всё на автоматике.

Здесь нужен human-in-the-loop.
Но human-in-the-loop для меня — это не когда человек после AI вручную переделывает всю работу.

Наоборот.

Система уже должна:

А человек подключается только там, где действительно нужно принять решение.

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

— Сейчас я обычно задаю несколько очень простых вопросов.
— Можно ли это правило заранее точно записать?
— Если да — скорее всего, AI здесь вообще не нужен.
— Нужно ли понять смысл текста, извлечь информацию, классифицировать или обработать разные формулировки?
Вот здесь AI уже может дать реальную пользу.
— Что будет, если модель ошибётся?
— Если последствие — неправильная цена, доступ не того человека, неверное обязательство перед клиентом или необратимое действие, я не хочу, чтобы финальное решение жило только внутри LLM.

И ещё один вопрос, который мне очень нравится:
— кто здесь в итоге отвечает за решение?

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

Я сама очень много работаю с AI, и он действительно сильно ускорил мою работу. Он помогает мне быстрее искать информацию, сравнивать варианты, структурировать, анализировать, считать, смотреть на задачу шире.
Но чем больше я им пользуюсь, тем меньше воспринимаю его как инструмент, который «сам всё сделает».
— Ты всё равно задаёшь направление.
— Ты определяешь контекст.
— Ты решаешь, где ему можно доверить часть работы, а где нужен жёсткий контроль.

И в бизнес-системах всё ровно так же.

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

Для меня хорошая система — это не та, где больше AI.
Хорошая система — это та, где каждый слой делает свою работу:

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

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

«Какую модель сюда подключить?»

А с другого:

«Какую часть этого решения вообще стоит отдавать модели?»

И вот этот вопрос для меня намного важнее любой конкретной технологии.