Заказчик приходит с фразой «хотим внедрить ИИ в свои процессы». Куда именно его ставить, он не знает. Сработает ли на его документах, тоже не знает. И совсем не представляет, сколько разработчики берут за такую работу: спрашивает цену, получает цифру и не может сравнить её ни с чем, потому что непонятно, что именно куплено.
Ниже — порядок, который снимает эту слепоту. Пять шагов: выбрать узкую зону и собрать прототип, определиться с контуром безопасности, заложить отказоустойчивость, расширить решение на соседние процессы и заранее понять, сколько времени съест сама аналитика. На каждом шаге сказано, на что смотреть и какая развилка чего стоит. И отдельно — про второй слой этой работы: документированную версию ваших процессов, которая остаётся у вас, даже если до ИИ дело не дойдёт.
Всё, что написано ниже, мы собрали на одном проекте. Осенью 2025 года к нам пришёл сертификационный центр: компания выпускает декларации и сертификаты соответствия по техническим регламентам, и весь выпуск держится на людях. Заявка приходит письмом, менеджер вручную заносит данные заявителя, технический отдел определяет применимый регламент, собирает пакет документов по шаблонам и сверяет поля глазами. Заказчик хотел поставить сюда ИИ, но не знал ни куда именно, ни сработает ли это на его документах, ни сколько стоит такая работа.
За 2 месяца мы разобрали процесс по реальным сделкам, собрали прототип распознавания входящих документов, прогнали его на живых пакетах и письменно ответили на техническую проверку заказчика: персональные данные, выбор моделей, архитектура, права на результат, метрики приёмки. Выжимка из этой работы — то, что ниже. Она переносится на любую страну и любой регламент: меняются названия систем и законов, логика шагов остаётся.
Шаг 1. Узкая зона и прототип
ИИ нестабилен. Модель придумывает данные, которых во входящем документе не было, отказывается выполнять задачу, от прогона к прогону выдаёт разный результат на одном и том же файле. Поэтому начинают не с бюджета. Берут один небольшой процесс, собирают прототип и замеряют два параметра.
- Устойчивость. Насколько одинаково модель отрабатывает одно и то же.
- Достижимость. Попадает ли результат в тот порог качества, при котором процесс вообще имеет смысл автоматизировать.
Для одного процесса порог — почти безошибочное заполнение полей. Для другого хватит черновика, который человек потом проверяет глазами.
На что смотреть
- Порог качества назначает цена ошибки на выходе, а не подрядчик. Если документ уходит во внешнюю систему и ошибку увидит регулятор, партнёр или клиент, порог высокий и ручная сверка остаётся. Если ошибку ловит следующий сотрудник в цепочке, порог ниже, а экономика складывается быстрее.
- Прототип собирают на живых данных. Демо-набор всегда чистый, а реальные входящие приходят сканами, фотографиями и таблицами с чужой разметкой.
- Результаты прогона оформляют документом. Иначе через месяц спор о качестве не на чем строить.
Пока эти два параметра не замерены, любая оценка бюджета — фантазия. На ИИ заранее не скажешь, что сработает.
И правило, которое странно слышать от подрядчика: параметры недостижимы, дальше не идём. Это нормальный завершённый результат. Вы узнали, что здесь ИИ не нужен, и заплатили за это малую долю бюджета вместо всего бюджета.
В сертификационном центре готовая декларация уходит в государственный реестр, и цену ошибки назначает надзор, а не внутренний регламент. Поэтому мы искали не место, где ИИ красиво показать, а место, где он не ошибётся. Прототип собрали на реальных пакетах документов и на них же смотрели устойчивость. Числа мы не сохранили, воспроизводимой выгрузки не осталось, и это наш недочёт: такой замер стоит отдавать заказчику вместе с прототипом.
Шаг 2. Контур: внешний или закрытый
Развилка про безопасность, которая определяет всю экономику проекта.
- Внешний контур. Модели по API провайдера: выбор шире, качество выше, деньги лояльнее. Данные уходят за периметр компании.
- Закрытый контур. Национальные модели или локально развёрнутые: данные не покидают периметр, качество пока ниже, инфраструктура дороже. Локальной модели нужны видеокарты, место и человек, который за ними следит.
Через 5 лет разговор будет о других порядках, но считать приходится по тому, что есть сейчас.
На что смотреть
- Сначала закон и политика безопасности, потом модель. Персональные данные, коммерческая тайна, отраслевые требования к хранению решаются до выбора модели, а не после.
- Стандартизированность области решает, хватит ли слабой модели. Там, где процесс регламентирован и формулировки повторяются из документа в документ, разрыв между сильной и слабой моделью сокращается, и более слабую модель в закрытом контуре взять можно. Область живая, формулировки произвольные, и разрыв вылезет сразу.
- Контур выбирают вторым шагом, а не пятым. Он меняет и стоимость, и достижимые параметры качества: выбрали модель раньше, и прототип переделывается с нуля.
В сертификационном центре мы сразу заложили закрытый контур на национальных моделях: данные заявителей попадают под требования о персональных данных, а зависимость от зарубежного провайдера в этой отрасли считается риском сама по себе. Отрасль регламентирована достаточно, чтобы подход от смены модели не поменялся. Отдельно разобрали, как готовые декларации попадают в государственный реестр: через оператора-посредника и личный кабинет ведомства, что нужно для подключения к межведомственному обмену данными и нужна ли аттестация программы, которая пишет в реестр напрямую. На аттестации мы упёрлись: однозначного ответа не нашли, а дальше копать не стали, потому что проект встал на стороне заказчика. Ответ зависит от сценария подачи — через личный кабинет с ручным подтверждением требования одни, при прямой интеграции другие. Если вы идёте в государственные системы, этот вопрос закрывают до архитектуры.
Шаг 3. Отказоустойчивость
Про качество распознавания думают все. Ляжет обычно от другого.
Упал провайдер модели, отвалилась сеть, вышел из строя локальный сервер: процесс встал. И заменить его некем, потому что люди, которые делали эту работу руками, уже перестали.
Решения два, оба рабочие:
- Оставить людей в контуре как запасной путь. Дешевле, но навык надо поддерживать, иначе он уходит.
- Построить контур отказа. Два-три провайдера или сервера с переключением: дороже, зато работает без людей.
Это база, а не роскошь.
На что смотреть
- Допустимый простой определяют заранее. Час, день, неделя: от ответа зависит, какой из двух вариантов брать.
- Запасной путь проверяют в бою. Переключение, которое никто ни разу не пробовал, в день аварии не работает.
Шаг 4. Расширение на соседние процессы
Прототип отработал, параметры устраивают, решение стоит в работе. Дальше его переносят на соседние блоки и процессы: планомерно, а не сразу везде.
Каждый перенос документируют и тестируют заново. То, что работало на одном процессе, на другом ведёт себя иначе: другие данные, другие формулировки, другие крайние случаи.
На что смотреть
- Следующим берут самый похожий процесс, а не самый большой. Похожий переносится дёшево и отвечает на главный вопрос: решение переносимо вообще или оно жило только на первом куске.
- Порядок важнее скорости. Большой процесс выглядит заманчиво, но там, где перенос ломается, вы теряете и время, и доверие команды к затее.
Шаг 5. Чего ждать по трудозатратам
Тяжёлая часть не модель. Тяжело снять карту движения информации: что откуда берётся, кто и в какой момент принимает решение, где данные меняют форму, какие поля переписываются вручную по третьему разу.
Мы недооценили эту фазу в проекте для сертификационного центра. Рассчитывали снять цепочку быстро, а разбираться пришлось дольше и подробнее.
Причина простая: регламентный процесс живёт в головах сотрудников и в переписке, а не на бумаге. Чтобы его снять, нужны реальные сделки от первого письма клиента до готового пакета документов, записи работы отделов и доступ наблюдателя в систему, где всё это происходит. Созвон этого не заменяет: на созвоне вам расскажут, как процесс задуман, а не как он идёт.
Здесь же прячется второй слой, ради которого иногда стоит затевать всю историю. Структурировать чужой хаос — наша основная работа, и по ходу разбора мы вынимаем процесс из голов сотрудников и записываем таким, какой он есть. Дальше обе версии кладут рядом: идеальную, как процесс задуман в компании, и реальную, как он идёт каждый день. Разрыв виден сразу: где решение ждёт трёх согласований, где одни и те же данные переписывают по третьему разу, где всё держится на одном человеке в отпуске. Эти места чинятся сразу и без всякого ИИ, и такая правка нередко приносит больше, чем сама автоматизация.
На что смотреть
- Аналитику и прототип закладывают отдельным этапом, со своим сроком и своей ценой, до разговора о разработке.
- Вы платите за знание, а не за обещание. Карта процесса остаётся полезной даже при смене подрядчика.
- Документ просят вместе с прототипом. Снятая карта процессов работает сама по себе: по ней видно, где процесс проседает, и правки можно вносить не дожидаясь никакой автоматизации.
Что вы получаете на выходе
Документ и прототип — только носители. Забираете вы четыре вещи:
- Нужен ли вам здесь ИИ. Ответ бывает только «да» или «нет», и «нет» стоит того, чтобы за него сказать спасибо. Вокруг всемогущего искусственного интеллекта много шума, и под этот шум легко купить решение, которое вашему процессу не нужно. Узнать это на прототипе дешевле, чем на середине разработки.
- Сколько это стоит. С понятной раскладкой по инфраструктуре, разработке и содержанию.
- Как это будет расти. Какие соседние процессы переносятся на то же решение, какие придётся делать заново и во что упрётся расширение: в людей, в лицензии или в железо.
- Документированную версию своих процессов. Снятую с реальных сделок и из голов сотрудников, а не переписанную из регламента. Идеальный процесс компании и её реальный процесс наконец лежат рядом, и разрыв между ними виден без нас.
У вас есть регламентный процесс, который держится на людях и шаблонах, и есть мысль поставить туда ИИ. Покажите его нам. Разберём процесс, соберём прототип на ваших документах и скажем, где модель снимет рутину, а где подведёт. У разбора фиксированная цена и срок: вы знаете сумму до начала работ и получаете результат, который остаётся у вас.