Почему разовую задачу теперь можно автоматизировать — если её дёшево проверить

1. Проект, в котором нечего делать

Меня подключили к проекту внедрения ИИ в одной крупной организации, когда проект уже шёл. Платформа была развёрнута, первое частное техническое задание написано и согласовано, оставалось делать. Я открыл ЧТЗ и не сразу понял, что читаю: объектом автоматизации в нём значился «паспорт аналитической задачи». Это документ, в котором описано, какие данные откуда взять, как их свести и в каком виде выдать наверх. Таких паспортов в организации было много, и на первый взгляд это выглядело как готовый реестр рутины — бери и автоматизируй. Потом я начал читать паспорта подряд.

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

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

Второй признак: результат работы ИИ нечем проверить. Формально критерии качества в паспортах были — например, «не менее 80% подобранной информации должно быть релевантным», — и с этими критериями мы намучились больше всего. Часть брака была явными галлюцинациями модели, на которые проектная команда повлиять не могла никак, только ждать следующую версию от разработчика модели. Но в большинстве случаев спор шёл не с моделью, а между людьми: один эксперт считал материал релевантным, другой — нет, а модели и вовсе было неоткуда знать, что упоминание однофамильца или того же термина в соседнем ведомственном значении — это не то. Критерии существовали, но были субъективными, и адресованы они были по большей части не команде проекта, а разработчику модели. Промптами, пайплайнами и перекрёстной проверкой одной модели другой мы двигали качество на проценты, а спор о том, что такое «релевантно», не закрывался ничем.

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

2. Закон, который все знают

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

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

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

Формула классической автоматизации: повторяемость × стабильность окупают дорогую разработку.

3. Что изменил ИИ

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

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

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

Внешние данные с этим согласуются. По исследованию MIT (2025), 95% пилотов генеративного ИИ не дают измеримой отдачи на вложения. Gartner в Hype Cycle for Agentic AI 2026 сообщает, что агентов развернули 17% организаций, а больше 60% планируют это в ближайшие два года. Обе цифры описывают один и тот же разрыв: развернуть стало дёшево, а проверить — нет.

Формула ИИ‑автоматизации: дешёвая разработка окупается там, где дёшева проверка.

4. Кейс: миграция, которую нельзя было автоматизировать

Сначала контекст. Одна организация внедряла новую учётную систему, и в неё нужно было перенести историю из старой. Старая система была написана когда‑то под задачи технической инвентаризации, и последние десять лет её никто не поддерживал: Visual Basic, Windows Server 2003, SQL Server 2000 и набор проприетарных библиотек для работы с векторными поэтажными планами, которые в DWG открываются, но рендерятся криво — с потерянными надписями и уехавшими контурами. Документации не было, разработчиков не было, зато были данные, накопленные за двадцать с лишним лет, и от них зависела вся история объектов. Внутри — одиннадцать баз данных: 1 451 таблица, 594 представления, 2 565 хранимых процедур, 21 616 колонок. Отдельно — архив почти из трёх тысяч поэтажных планов в том самом проприетарном формате.

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

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

Проверка была устроена так. На каждом шаге результат сравнивался не с чьим‑то мнением, а с независимым источником, и расхождения отдавались модели на поиск причин. Выгрузка сверялась по числу строк с источником: 1 631 797 строк по 50 наборам данных, расхождений ноль. Сопоставление объектов недвижимости проверялось не глазами, а по государственному реестру: все 10 089 объектов с кадастровыми номерами были прогнаны через ЕГРН, найдено 10 068, площади совпали у 99,7%. Загрузка планов проверялась по двум счётчикам — дубли по бизнес‑ключу и планы без растрового рендера; оба должны быть нулём, и оба были нулём на 1 894 загруженных планах. Каждое изменение в целевой базе шло в два прогона, пробный и боевой, с журналом «поле — было — стало»; за 22 прогона ни одной перезаписи непустого значения. Ни одна из этих проверок не требовала знать, как задача была сделана. Все они требовали только сравнить два отчёта.

Здесь и появляется условие, без которого ничего не работает. Сравнить отчёты может скрипт. Понять, почему они расходятся, может только человек, который знает и бизнес‑смысл этих данных, и устройство обеих систем. Когда 600 контуров помещений из 13 766 не сопоставились автоматически, решать, что это — ошибка эвристики, особенность нумерации в конкретном доме или реально отсутствующий объект, приходилось аналитику. Human‑in‑the‑loop здесь не формальность из презентации; это та самая дорогая часть, которая осталась дорогой.

И теперь о том, что вскрыла сверка. Расхождения между старой системой и внешним реестром оказались не только ошибками переноса. По 338 объектам класс «жилое/нежилое» в старой системе не совпадал с ЕГРН. У 14 объектов кадастровые номера были переставлены внутри здания, у 10 — относились к другому адресу. 171 объект, живой в старой системе, в реестре числился снятым с учёта. У 1 641 помещения в старой системе не было этажа, хотя в реестре он есть. Эталон, с которым мы собирались сверяться, сам оказался битым — и это выяснилось только потому, что проверка была дешёвой и её можно было сделать сплошной, а не выборочной. Ни одно из этих расхождений не исправлялось автоматически: они зафиксированы в протоколе и переданы заказчику на решение. ИИ дёшево находит расхождение; кто прав, по‑прежнему решает человек.

Формула кейса: разовая задача автоматизируется, если результат можно сверить с независимым источником дешевле, чем получить.

5. Следствие: ИИ автоматизирует ИТ‑службу, а не организацию

Обратите внимание, кто получил выгоду в этом кейсе. Не «ведомство» и не «бизнес‑процесс» — искать в них рутину даже не понадобилось. Выгоду получила ИТ‑служба, которая раньше отдала бы эту работу наружу. Для неё проверка своя: отчёт из старой системы и отчёт из новой лежат у неё же. Разработка стала дешёвой. И тогда короче сделать самим, чем проходить цикл обоснования бюджета, выбора поставщика, контрактования и приёмки. Сама закупка в крупной структуре занимает в среднем полгода; в теории можно уложиться в три месяца, но работа, не попавшая в бюджет текущего года, ждёт следующего, так что честнее считать закупочный цикл годовым. Четыре месяца работы подрядчика по контракту — это на самом деле год с лишним от момента, когда задача возникла, и большая часть этого времени уходит не на работу, а на её оформление.

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

Здесь полезен обратный пример. В августе 2026 Reuters сообщил о свёрнутом плане Meta сократить инженерные команды на 60% за счёт ИИ: объём кода вырос на 220%, доля полезных изменений — на 36%, а число инцидентов — на 40% (разбор у The Pragmatic Engineer). Это та же формула, прочитанная наоборот. Разработка подешевела в разы, проверка осталась прежней, и разрыв между ними ушёл в инциденты. Дешёвая разработка без дешёвой проверки не ускоряет работу — она ускоряет производство ошибок.

Формула следствия: эффект ИИ лежит там, где проверка уже своя, а разработка раньше покупалась.

6. Не ERP, а офисный пакет

Из этого следует и другой вывод, к которому я шёл дольше, чем хотелось бы. Я всю жизнь внедрял ERP, и схема въелась: анализ, техническое задание, разработка, внедрение, опытная эксплуатация, правка всего и вся на лету и на коленке, сдача в промышленную эксплуатацию. Проект с паспортами шёл ровно по этой схеме, и схема была не по размеру задаче: ТЗ на то, что выполняется раз в год и на следующий год выглядит иначе, устаревает раньше, чем его согласуют. ИИ по способу распространения больше похож не на ERP, а на офисный пакет в конце 1990-х: развернули, научили, провели тренинги, создали линию поддержки, которая по запросу делает пользователю шаблон с формулами и макросами под конкретную задачу. Паспорт аналитической задачи — это и есть такой шаблон, только вместо формул в нём промпт и пайплайн. Разница с офисным пакетом в одном: у линии поддержки должен быть фильтр на входе, потому что шаблон в Excel ошибается там, где ошибся пользователь, а модель — там, где никто не заметил. Поэтому запрос сортируется сначала по тому, чем его результат проверить, и только потом по классической экономике — объёму в год, снимаемой трудоёмкости в деньгах и прогнозу, сколько лет задача проживёт в нынешнем виде.

Формула раздела: для пользователей ИИ внедряется не проектом, а линией поддержки с фильтром на входе.

7. Где формула не работает

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

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

8. Что делать

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

  • Сколько раз в год — измеримый объём одинаковой по содержанию работы.

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

Дальше правило порядка. Автоматизировать сначала правую колонку, а не левую. Задача с пустой левой и заполненной правой — разовая, но проверяемая — это кандидат номер один: старый закон её отсекал, новый разрешает, и таких задач в ИТ‑службе обычно больше, чем кажется. Задача с заполненной левой и пустой правой — повторяемая, но непроверяемая — это ловушка: она выглядит как классическая автоматизация и в классической экономике ею была, но модель на ней будет тихо ошибаться в объёме. Всё, где пусто в обеих колонках, — не проект. Это может быть исследование, и его честно так и называть, с исследовательским бюджетом и исследовательскими критериями успеха, а не внедренческими.

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

9. Финал

Закон автоматизации не изменился. Изменилось то, что в нём было дорогим. Сорок лет дорогой была разработка, и мы окупали её повторяемостью. Теперь дорогой осталась проверка, и окупать её нужно проверяемостью. Повторяемость → проверяемость — вот вся замена. Всё остальное, включая слово «ИИ», — подробности.