Когда не нужен ИИ

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

• Нет объёма - задача редкая, ручной труд дешевле и быстрее
• Нет данных - хаос в документах и процессах модель только усилит
• Нужна гарантия - деньги, юрфакты, безопасность, жизнь и здоровье
• Правила жёсткие - if/else, валидации и скрипты надёжнее LLM
• Правило - сначала процесс и метрика, потом модель

ИИ - инструмент, а не обязательный слой

Модель хорошо справляется с черновиками, классификацией, поиском по смыслу и подсказками оператору. Она плохо заменяет ясное ТЗ, чистые данные и ответственность человека за решение.

Типичная ошибка 2026 года: купить «ИИ в продукт», не ответив на три вопроса - какой объём, какой критерий успеха, кто отвечает за ошибку. Без ответов ИИ становится дорогим украшением архитектуры.

Когда ИИ точно не нужен

1. Задача редкая и дешёвая вручную

Если действие делается раз в неделю и занимает 10-15 минут, автоматизация через LLM часто дороже внедрения и поддержки. Считайте: стоимость интеграции + токены + контроль качества против часов сотрудника в год.

2. Процесс ещё не описан

Нет регламента, нет единого источника правды, ответы в чатах противоречат FAQ. ИИ не «наведёт порядок» - он масштабирует путаницу. Сначала карта процесса, потом автоматизация.

3. Нужен детерминированный результат

Проверка ИНН, расчёт налога, статус оплаты, права доступа, соответствие схеме API - зона правил и тестов. LLM вероятностна: один и тот же вход может дать разный выход. Для гарантий берите код, валидаторы и сценарий, а не промпт.

4. Цена ошибки слишком высока

Юридические обещания клиенту, медицинские выводы, финансовые транзакции без подтверждения, безопасность инфраструктуры. Здесь допустим ассистент рядом с человеком, но не автопилот без эскалации.

5. Данных мало или они грязные

RAG по трём устаревшим PDF и разрозненным Notion-страницам даёт уверенные, но неверные ответы. Сначала чистка базы знаний, версии документов и владельцы контента.

6. Уже есть простое решение

Поиск по каталогу, фильтры, шаблоны писем, макросы поддержки, SQL-отчёт, n8n без LLM. Если классический инструмент закрывает 80% кейсов - не усложняйте стек ради демо.

7. Нет владельца метрик

Без базовой линии (время ответа, доля ошибок, стоимость обращения) нельзя понять, помог ли ИИ. «Стало умнее» - не KPI. Нужны цифры до и после.

Что делать вместо ИИ

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

Как понять за один день, нужен ли ИИ

1. Выпишите 20 реальных задач за последний месяц.
2. Отметьте, сколько из них повторяются и тратят >30 минут в неделю суммарно.
3. Проверьте: есть ли чистые данные и понятный критерий «правильно / неправильно».
4. Оцените риск ошибки: можно ли откатить или нужен человек.
5. Если объём мал, данные грязные или риск высок - отложите модель.

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

Когда ИИ уже стоит подключать

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

• Объём стабилен - десятки однотипных задач в неделю, а не разовые случаи
• Данные собраны в одном месте и не противоречат друг другу
• Ошибка не критична или её проверяет человек перед отправкой
• Есть тот, кто считает метрику «было / стало», и понятен критерий успеха
• Команда готова ограничить сценарий узкой задачей, а не «ИИ на весь процесс»

Тогда пилот на одном сценарии с контролем качества - оправданный следующий шаг.

Итог

ИИ не нужен, когда нет объёма, нет данных, нужна жёсткая гарантия или задачу уже закрывает простое правило. Сначала процесс, данные и метрика - потом модель в узком сценарии с контролем качества. Иначе вы платите за токены и поддержку, а выигрыш остаётся в презентации.

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

Часто задаваемые вопросы

Значит ли «не нужен ИИ», что ИИ бесполезен?

Нет. ИИ полезен на объёме: черновики, FAQ, классификация, RAG по чистой базе, copilot оператора. Речь о том, чтобы не ставить модель туда, где правила, редкость задачи или цена ошибки делают её лишней.

Можно ли начать с ИИ, а процессы навести потом?

Обычно нет. Модель усиливает текущее состояние. Если процессы хаотичны, автоматизация ускорит хаос. Сначала минимальный порядок и источник правды, затем узкий пилот.

Чем заменить ИИ в поддержке на старте?

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

Когда ИИ оправдан даже при высоком риске?

Как помощник человеку, не как финальный автоответ. Черновик, подсветка риска, поиск по регламентам - да. Автоотправка клиенту без проверки - нет, пока нет жёсткого контроля и аудита.

Как объяснить заказчику, что ИИ пока рано?

Через цифры: объём задач, стоимость внедрения, риск ошибки и что даст простой сценарий без LLM. Предложите этапность: порядок → правила → пилот ИИ на одном сценарии с метрикой. Так решение выглядит зрелым, а не «против прогресса».

Термины в статье

LLM — Large Language Model — большая языковая модель

промпт — prompt — текст-инструкция или запрос к модели

RAG — Retrieval-Augmented Generation — генерация с дополненным поиском

n8n — open-source workflow automation platform — платформа с открытым кодом (open-source) для автоматизации сценариев (workflow)

KPI — Key Performance Indicator — ключевой показатель эффективности

BI — Business Intelligence — бизнес-аналитика