Какие бизнес-процессы стоит автоматизировать с помощью ИИ — и с чего начать

Коротко: автоматизация с ИИ начинается не с выбора нейросети, а с одного конкретного процесса. Хороший кандидат повторяется каждый день, съедает часы сотрудников, получает на вход понятные данные — письма, документы, заявки — и выдаёт результат, который человек проверит за минуту. Важные решения при этом остаются за людьми. А если задача полностью описывается правилом «случилось X — сделай Y», нейросеть ей не нужна: хватит простой автоматизации.

Менеджер третий час переносит данные из писем в CRM. Юрист читает сотый типовой договор, чтобы найти пять рискованных пунктов. Оператор к вечеру обработал сорок заявок — и устал в основном от копипаста.

Знакомо? Почти в каждой компании есть такая работа: повторяющаяся, понятная, бесконечная. Именно с неё стоит начинать внедрение ИИ. Но компании часто делают наоборот: сначала выбирают модель или платформу, тестируют ChatGPT и Claude, показывают руководству красивую демонстрацию — а ежедневная работа сотрудников не меняется. Инструмент купили, задачу не нашли.

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

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

Мини-аудит: подходит ли процесс для автоматизации

Хороший кандидат обычно виден сразу. Он:

• повторяется каждый день или каждую неделю;
• состоит из похожих, однотипных действий;
• отнимает у сотрудников заметное время;
• получает на вход письма, формы, PDF, таблицы или карточки CRM;
• заканчивается результатом, который можно проверить: заполненная карточка, таблица, сводка;
• связан с чтением текста: разобрать письмо, вытащить данные, сравнить, найти;
• позволяет отдавать спорные случаи человеку;
• создаёт затраты, ошибки или задержки, которые можно посчитать до и после пилота.

Признак	Хороший кандидат	Риск или ограничение
Повторяемость	Ежедневно или еженедельно	Несколько раз в год
Объём	Десятки или сотни похожих операций	Единичные случаи
Вход	Письмо, PDF, форма, CRM, таблица	Каждый раз принципиально разные данные
Результат	Его можно проверить по критериям	Субъективный результат без критерия
Измеримость	Известны часы, объём, ошибки или сроки обработки	Сначала нужно замерить текущие затраты
Цена ошибки	Результат проверяется до действия	Нужна обязательная проверка до действия
Необходимость ИИ	Нужно понимать текст, извлекать, сравнивать, классифицировать	Задача полностью решается однозначными правилами

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

Быстрая проверка: возьмите одну рутинную работу и запишите: сколько раз в день она выполняется, сколько минут занимает один проход, что приходит на вход, какой результат считается правильным и кто разбирает исключения. Нет ответов — сначала соберите их. Это займёт день, а сэкономит месяцы.

Примеры процессов и результаты внедрений собраны в разделе «Кейсы внедрения ИИ и автоматизации».

ИИ или обычная автоматизация: три уровня решения

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

1. Обычная автоматизация

Работает там, где правила однозначны: пришла заявка из формы — создать карточку в CRM, назначить ответственного по региону, поставить срок, отправить уведомление в Telegram.

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

2. ИИ для работы с текстом и документами

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

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

3. ИИ-агент или система из нескольких шагов

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

Агент оправдан, когда путь заранее неизвестен: система сама выбирает, какой источник опросить, каких данных не хватает, какой инструмент использовать следующим. Границы при этом жёсткие: список доступных действий, условия остановки и шаги, которые требуют подтверждения человека, задаются заранее. Такой управляемый маршрут от входа до проверенного результата я называю рабочим контуром. Подробнее о разнице между моделью, ассистентом и агентом — в материале «AI-агенты: что это, как работают и зачем нужны».

Правило выбора короткое:

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

Как понять, что процесс действительно стоит автоматизировать

Процесс повторяется

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

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

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

На него регулярно уходят часы сотрудников

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

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

Есть понятный вход

Система должна получать данные из реального источника: почта, форма на сайте, PDF, Excel, карточка CRM, сообщения в мессенджере. Следующий вопрос — насколько эти данные стабильны.

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

Есть понятный результат

«Сделать работу лучше» — не постановка задачи. Результат — это заполненная карточка, таблица рисков, разложенная по категориям заявка, сводка или черновик письма. Для результата должны быть критерии: что считается полным и правильным.

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

Эффект можно измерить

До пилота запишите время, объём, число ошибок, задержки и стоимость одной операции. После пилота измерьте то же самое. Сравнивать разные наборы цифр нельзя — вывод получится ненадёжным.

Человек может проверить критические решения

Проверка сотрудником — нормальная часть автоматизации, а не её недоделанность. Система берёт на себя чтение, перенос данных и первичную разбивку, человек разбирает исключения и принимает решения.

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

ИИ решает проблему, а не добавляется ради моды

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

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

Какие бизнес-процессы можно автоматизировать с помощью ИИ

Чаще всего автоматизация начинается с документов, заявок, договоров, отчётности, CRM, внутренних знаний, закупок, поддержки, финансов или подбора сотрудников. Ниже — типовые направления. Каждое из них проверяется по матрице выше и на данных своей компании.

1. Документы

Как это выглядит сейчас. Сотрудник открывает PDF и вложения, читает, ищет глазами реквизиты и требования, перебивает данные в таблицу, готовит сводку.

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

Что остаётся человеку. Спорные места, плохие сканы, нестандартные условия и решения, за которые компания отвечает.

Что измерить. Число документов, время на типовой пакет, долю файлов с ручной доработкой, пропуски, срок обработки.

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

2. Входящие заявки

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

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

Что остаётся человеку. Неоднозначные обращения, противоречивые данные, жалобы, нестандартные запросы, контроль ошибочных назначений.

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

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

3. Договоры

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

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

Что остаётся человеку. Юридическая оценка, проверка цитат, переговорная позиция, решение о подписании. Уверенность модели не может заменять юридическое заключение.

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

Когда ИИ не нужен. Если договор полностью типовой и проверяется точным сравнением версий или обязательных полей.

4. Отчётность

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

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

Что остаётся человеку. Подтверждение цифр, причин отклонений и выводов для руководства.

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

Когда ИИ не нужен. Если задача — посчитать формулы и построить диаграммы по готовым данным.

5. CRM

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

Что отдать системе. Извлечь факты из письма или расшифровки звонка, подготовить резюме и черновик карточки. Смену статуса, сроки и уведомления выполняют обычные правила CRM.

Что остаётся человеку. Подтверждение важных фактов, коммерческая оценка, следующий шаг, спорные данные.

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

Когда ИИ не нужен. Если данные уже структурированы, а сотрудник просто нажимает одну и ту же последовательность кнопок.

6. Корпоративные знания и поиск по внутренним документам (RAG)

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

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

Что остаётся человеку. Проверка ответа в чувствительных вопросах, актуальность инструкций, решение при конфликте двух источников.

Что измерить. Время поиска, число повторяющихся вопросов, долю ответов с найденным источником, случаи «ответа нет», устаревшие документы.

Когда ИИ не нужен. Если документов немного, навигация понятна и обычный поиск находит ответ за секунды.

7. Закупки

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

Что отдать системе. Обычная автоматизация находит лоты по точным фильтрам, скачивает файлы и создаёт карточки. Модель читает техзадание и готовит сводку: требования, сроки, риски — с цитатами и пометкой, каких данных нет.

Что остаётся человеку. Проверка сумм и требований, оценка «потянем ли», решение об участии.

Что измерить. Часы на первичный отсев, число просмотренных ТЗ, долю карточек, которые всё равно пришлось читать, ошибки в критических полях.

Когда ИИ не нужен. Если площадка отдаёт все критерии в структурированных полях и решения принимаются фильтрами.

8. Поддержка клиентов

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

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

Что остаётся человеку. Жалобы, деньги, обещания, конфликты и обращения, под которые нет надёжного источника ответа.

Что измерить. Время первого ответа, время решения, доля переадресаций, повторные обращения, доля черновиков, принятых без правки.

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

9. Финансы и внутренние операции

Как это выглядит сейчас. Бухгалтер сверяет документы и реестры, раскладывает операции по категориям, ищет расхождения, собирает пакет на проверку.

Что отдать системе. Точное сопоставление сумм и номеров делают правила. Модель помогает там, где текст: разобрать назначение платежа, вытащить данные из документов, собрать список расхождений.

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

Что измерить. Число операций, время сверки, количество расхождений, стоимость исправления, долю случаев на ручной проверке.

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

10. HR и подбор

Как это выглядит сейчас. Рекрутер переносит данные из резюме, группирует отклики, готовит вопросы, делает сводку после интервью, обновляет карточки кандидатов.

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

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

Что измерить. Время на отклик, полноту карточек, скорость обратной связи, число правок, долю кандидатов на повторном просмотре.

Когда ИИ не нужен. Если поток небольшой или форма отклика уже собирает всё нужное в готовых полях.

Как посчитать эффект до разработки

Честную окупаемость вложений (ROI) до пилота пообещать нельзя — можно только прикинуть, во сколько процесс обходится сейчас, какая экономия возможна и что пилот должен будет подтвердить.

Стоимость текущего процесса

Базовая формула:

сколько раз в месяц × сколько минут занимает один проход × полная стоимость часа сотрудника

Сверху, если применимо, добавьте:

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

Полная стоимость часа — это не только зарплата, делённая на рабочее время. В расчёте можно учесть налоги, рабочее место и другие прямые расходы. Главное — использовать одну и ту же методику до и после пилота, иначе сравнение будет некорректным.

Потенциальный эффект

Предполагаемую экономию за месяц считают так:

текущие месячные затраты − оставшаяся ручная работа − оплата сервисов − поддержка

Отдельно идут разовые расходы: разработка, подключение систем, подготовка данных, тестирование, запуск. Срок окупаемости — разовые расходы, делённые на месячную экономию. Если в расчёте «забыть» часть затрат, автоматизация на бумаге всегда будет выглядеть выгоднее, чем в жизни.

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

До пилота это гипотеза. После пилота — цифра.

Для самостоятельной прикидки можно взять промпт расчёта ROI автоматизации и промпт аудита рутинной задачи. Их вывод тоже проверяется на данных вашей компании.

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

Реальные кейсы: что изменилось и что осталось человеку

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

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

Процесс	Было	Стало	Что осталось человеку
Документы	Около 3 дней	Около 2 часов	Проверка спорных мест и принятие решения
Заявки	Около 4 часов в день	Около 8 минут контроля	Исключения и спорные заявки
Анализ договора	Около 6 часов	Около 20 минут	Проверка и юридическое решение
Госзакупки	Около 30 часов в неделю	Около 1–2 часов в неделю	Проверка карточки и решение об участии

Документы: около трёх дней превратились примерно в два часа

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

Система на Claude API, Make.com, Notion и Telegram готовила предварительный разбор и таблицу рисков. Юрист проверял спорные места и принимал решение. Время на типовой пакет сократилось примерно до двух часов — с разбором и проверкой. Решение осталось за специалистом.

Заявки: четыре часа ручной работы сократились до восьми минут контроля

В строительной компании оператор обрабатывал около 47 заявок в день. На каждую уходило пять–семь минут: прочитать, определить тип, назначить исполнителя, создать задачу в CRM. Итого примерно четыре часа ежедневно.

Система определяла тему по тексту, извлекала поля и назначала исполнителя по правилам. После внедрения на контроль уходило около восьми минут в день, спорные заявки оставались человеку. Важная деталь: модель разбирала неоднозначный текст, а однозначное назначение делала обычная таблица правил через API CRM.

Анализ договора: карта рисков примерно за 20 минут

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

Подготовка карты и её проверка заняли около 20 минут. Решение — участвовать, отказаться, торговаться — осталось за юристом. Сложные сделки всё равно требовали глубокого чтения: система экономила время на черновой структуре, а не принимала юридические решения.

Госзакупки: меньше пустого чтения, а не «волшебные лоты»

В моём кейсе по закупкам первичный отсев съедал около 30 часов в неделю. Автоматизация находила новые лоты по фильтрам, скачивала PDF, извлекала текст, модель готовила карточку с требованиями, сроками и рисками. После запуска на проверку карточек и решения об участии уходило около одного–двух часов в неделю.

Система не увеличила долю подходящих закупок и не сделала рынок лучше. Она убрала большую часть ручного чтения. Угадывать критические поля было запрещено: если начальная цена контракта (НМЦК) не нашлась в явном виде или скан был плохим, материал уходил на ручную проверку.

Общая логика этих проектов — в кейсе «ИИ-агенты для бизнеса: как я превращаю рутину в рабочий контур».

Как начать внедрение: от процесса к пилоту

Шаг 1. Выберите один процесс

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

Шаг 2. Зафиксируйте исходные показатели

Замерьте время, объём, ошибки, задержки и число действий сотрудника. Сохраните несколько реальных примеров: обычные, сложные и ошибочные. Это будет тестовый набор.

Шаг 3. Определите границы

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

Шаг 4. Соберите пилот

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

Шаг 5. Сравните с исходными показателями

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

Шаг 6. Только после этого масштабируйте

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

Формула запуска:

процесс → исходные показатели → пилот → контроль → измерение → масштабирование

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

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

Соберите исторический тестовый набор

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

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

Заранее определите правильный ответ

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

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

Разделяйте критические и некритические ошибки

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

Список помогает решить, где достаточно поправить текст, а где система обязана остановиться и позвать человека. Средняя «точность» без понимания цены ошибки может прятать неприемлемый риск.

Измеряйте полный цикл, а не скорость ответа модели

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

После каждого прогона фиксируйте:

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

Назначьте владельца процесса

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

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

Зафиксируйте условие остановки

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

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

Когда я бы не стал внедрять ИИ

Процесс происходит редко

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

Обычная автоматизация решает задачу

Точные правила, фильтры, формулы и сопоставление номеров надёжнее выполнять без языковой модели. Добавлять её ради слова «ИИ» — платить больше за менее предсказуемый результат.

Нет нормальных исходных данных

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

Никто не знает стоимость текущего процесса

Без исходных цифр невозможно понять, стало лучше или нет. Сначала проведите несколько замеров — сложная финансовая модель не нужна.

Цена ошибки критическая

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

Сам процесс постоянно меняется

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

Автоматизация дороже ручной работы

Иногда ручной процесс достаточно дешёвый, быстрый и редкий. Оставить его как есть — нормальный вывод аудита.

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

Частые вопросы

Какие процессы лучше всего автоматизировать с помощью ИИ?

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

С чего начать внедрение ИИ в компании?

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

Чем ИИ-автоматизация отличается от обычной автоматизации?

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

Когда нужен ИИ-агент?

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

Можно ли полностью убрать человека из процесса?

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

Как понять, окупится ли автоматизация?

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

Сколько времени занимает пилот?

Единого срока нет: зависит от данных, интеграций, объёма тестового набора и рисков. Корректнее сначала определить границы и критерии приёмки, потом оценивать срок конкретного пилота.

Нужно ли компании обучать собственную модель?

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

Можно ли использовать ИИ с CRM и внутренними документами?

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

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

Разберём процесс до того, как что-либо разрабатывать

Для первого разбора достаточно описать три вещи:

1. Что сотрудники сейчас делают вручную.
2. Какие данные приходят на вход.
3. Какой результат должен получиться.

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

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

Описать процесс и получить предварительный разбор →

Ссылки

Ссылки

• ИИ-агенты для бизнеса: как я превращаю рутину в рабочий контур
• Разбор проекта: юридические документы — 3 дня → 2 часа
• Разбор проекта: заявки строительной компании — 4 часа → 8 минут
• Разбор проекта: анализ договоров — 6 часов → 20 минут
• Как я перестал читать закупки — и оставил себе только одно решение
• AI-агенты: что это, как работают и зачем нужны