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

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

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

Начинать нужно с проблемы, а не с технологии

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

Рабочая постановка звучит конкретнее: «Юристы тратят в среднем 25 минут на первичную проверку договора поставки. Мы хотим автоматически находить отклонения от типовой формы и готовить список пунктов для проверки специалистом». Здесь уже видны:

  • определённый тип документа;
  • конкретная операция;
  • пользователь результата;
  • текущие затраты времени;
  • роль ИИ;
  • роль человека;
  • возможная метрика.

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

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

Критерий №1. В процессе должна существовать измеримая боль

Фотография: небольшой ЭЛТ-монитор в бежевом корпусе на тёмном деревянном столе, на синем экране — пиксельный значок песочных часов
Ощущение «здесь долго» — не аргумент. Аргументом становятся посчитанные объём операций, время обработки, очередь и доля исправлений.

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

Для оценки текущего процесса полезно собрать несколько показателей:

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

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

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

Критерий №2. В задаче должно быть место именно для ИИ

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

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

ИИ оправдан там, где процесс связан с интерпретацией:

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

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

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

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

Критерий №3. Для проверки должны быть доступны реальные данные

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

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

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

Хороший набор содержит не только аккуратные примеры. В него стоит включить:

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

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

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

Критерий №4. Задача должна иметь узкие границы

Фотография: плата расширения с разъёмом и двухразрядным семисегментным индикатором на тёмном деревянном столе
Узкая задача с одной понятной функцией проверяется, встраивается и останавливается проще, чем универсальное решение «для всей работы с документами».

Формулировка «автоматизировать работу с договорами» охватывает слишком много действий. Сюда могут входить подготовка документа, проверка условий, согласование, переписка, хранение, подписание и контроль исполнения.

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

Узкая граница помогает определить:

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

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

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

Критерий №5. Цена ошибки должна быть управляемой

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

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

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

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

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

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

Критерий №6. Должен существовать человек, способный проверить результат

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

Фраза human-in-the-loop — схема, при которой значимое решение остаётся за человеком, — звучит успокаивающе, но сама по себе ничего не гарантирует. Нужно определить конкретного сотрудника, его полномочия и способ проверки.

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

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

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

Критерий №7. Результат можно встроить в существующую работу

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

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

Нужно определить:

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

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

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

Хороший первый процесс выглядит немного скучно

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

Хороший первый кандидат обладает несколькими признаками:

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

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

Какие процессы не стоит выбирать первыми

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

Плохими кандидатами также будут процессы, где:

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

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

Как сравнить несколько кандидатов

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

  1. Бизнес-эффект.
  2. Пригодность задачи для ИИ.
  3. Доступность данных.
  4. Техническая реализуемость.
  5. Управляемость риска.
  6. Готовность пользователей и владельца процесса.

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

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

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

Пример выбора первого процесса

Представим, что страховая компания рассматривает три идеи:

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

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

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

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

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

Как мы выбираем первый сценарий в Daturum

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

Затем выбираем узкий участок и берём небольшую выборку обезличенных примеров. Подход Hyperfast Presale позволяет быстро собрать прототип и увидеть, что модель действительно умеет делать на данных клиента. Дальнейший путь от подтверждённой гипотезы до промышленного контура разложен по фазам в методологии AI Factory.

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

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

Первый проект должен дать право на следующий шаг

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

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

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

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

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

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

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

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

Какие данные нужны, чтобы проверить сценарий?

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

Как сравнить несколько кандидатов на первый ИИ-проект?

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

Почему не стоит начинать с самого масштабного процесса?

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

Источники

Опубликовано 29 июля 2026 года. Источники проверены 29 июля 2026 года.

Об авторе

Роман Ткачёв — сооснователь Daturum. Более 25 лет в корпоративной автоматизации. Участвовал более чем в 80 крупных проектах в банках, страховых компаниях, телекомах, на транспорте, в госсекторе, промышленности и ритейле; реализовал более 50 коммерческих BPM-внедрений.

До Daturum — директор BPM-департамента и Центра инноваций «Т1 Консалтинг».

Полная биография