За последние два года автоматизация с языковыми моделями перестала быть экспериментом отдела разработки и превратилась в строку бюджета, за которую кто-то отвечает деньгами. И основная часть провалов, которые я вижу в компаниях, связана не с качеством моделей, а с неверно выбранным объектом автоматизации. Процесс берут потому, что он заметный, трудоёмкий или модный, а не потому, что он пригоден к передаче машине. Ниже разберём природу этой ошибки и дадим систему оценки, по которой можно отсеивать процессы до того, как в них вложены месяцы работы.
Где ИИ ошибается и почему это системная особенность
Языковая модель не принимает решений в том смысле, в каком их принимает сотрудник. Она продолжает последовательность, опираясь на статистические закономерности в данных, и выдаёт наиболее вероятный вариант ответа. Правдоподобие и правильность в этой логике совпадают часто, но не всегда, и момент расхождения внешне ничем не отличается от нормальной работы. Сотрудник, который не понимает задачу, обычно подаёт сигнал. Модель уверенно выдаёт результат одинаковым тоном и в том случае, когда она права, и в том случае, когда ошиблась на сто процентов.
Отсюда вырастает несколько ограничений, которые невозможно убрать настройкой запроса или дообучением. Их стоит держать в голове как физические свойства инструмента.
- Модель не чувствует цену ошибки. Опечатка в описании товара и ошибка в сумме акта для неё одинаковы по значимости, потому что она оценивает текст, а не последствия.
- Модель не видит контекста, который не попал в запрос. Сотрудник знает, что этот клиент на грани расторжения договора, а бухгалтерия закрывает квартал. Модель об этом не знает, если ей не передали.
- Модель не несёт ответственности. Ответственность всегда остаётся на человеке или юридическом лице, и чем дальше отодвинут человек, тем сильнее размывается понимание, кто отвечает за результат.
- Поведение модели меняется при обновлении версии. Процесс, отлаженный на одной версии, после обновления может начать работать иначе при тех же запросах.
- Качество падает тихо. Нет аварии, нет остановки конвейера, есть постепенное сползание результата, которое обнаруживается через недели.
Последний пункт самый неприятный с управленческой точки зрения. Классическая автоматизация ломается громко. Скрипт падает, интеграция отдаёт ошибку, отчёт не формируется. Автоматизация на основе ИИ деградирует без шума, продолжая выдавать гладкий текст и уверенные ответы. Поэтому процесс, в котором нет дешёвого способа проверить результат, превращается в источник скрытых потерь.
Главный риск не в том, что модель ошибётся. Главный риск в том, что вы узнаете об ошибке позже, чем она станет дорогой.
Почему проблема почти всегда в процессе, а не в модели
Когда внедрение не даёт результата, первая реакция руководителя предсказуема. Ищут более сильную модель, переписывают инструкции, нанимают подрядчика по настройке. Иногда это помогает. Но в большинстве разборов, которые я проводил, корень лежал на уровень глубже.
Автоматизация формализует процесс. Она требует однозначного описания входа, шагов и критериев приёмки. Если в компании процесс держится на опыте двух сотрудников, которые по интонации письма понимают, что клиенту нужно позвонить, а не ответить, то формализовать нечего. Модель получит на вход неполные данные и отдаст результат, который формально корректен и практически бесполезен. Внедрение в такой ситуации работает как диагностика. Оно подсвечивает, что процесса в управленческом смысле не существует, есть лишь набор привычек.
Второй распространённый корень связан с выбором мотивации. Если проект начинался с идеи сократить расходы на людей, критерии успеха сместятся в сторону объёма, а не качества. Команда будет отчитываться числом обработанных обращений и сэкономленными часами, потому что эти показатели легко считать. Качество решения вопроса клиента в такой отчётности не появится, пока не начнётся отток.
Критерии, по которым процесс оценивают до автоматизации
Дальше идёт рабочая часть. Я предлагаю прогонять каждый процесс через шесть критериев. Это не теория, а сито, которое отсекает заведомо провальные идеи за полчаса обсуждения с владельцем процесса. Отвечать нужно честно, иначе упражнение бессмысленно.
- Какова цена одной ошибки в деньгах, репутации и юридических последствиях.
- Можно ли откатить результат и сколько это стоит.
- Есть ли дешёвый способ проверить, что результат верный.
- Существует ли письменный регламент и стабильные входные данные.
- Требует ли решение персональной ответственности конкретного человека.
- Как часто меняются правила внутри процесса.
Цена ошибки и обратимость
Эти два критерия работают в паре и дают самый быстрый отсев. Ошибка в черновике рассылки стоит пятнадцать минут работы редактора. Ошибка в отправленной рассылке на сто тысяч адресов стоит репутации и части базы. Процесс один, разница только в наличии шага проверки перед необратимым действием.
Полезно считать не среднюю ошибку, а худшую из вероятных. Средние показатели успокаивают и скрывают распределение. Модель, которая правильно обрабатывает девяносто пять процентов обращений, выглядит отлично в презентации. Но если в оставшиеся пять процентов попадают именно сложные случаи с крупными клиентами, экономическая картина меняется на противоположную. Дешёвые задачи автоматизируются, дорогие ломаются.
Простой ориентир для расчёта выглядит так. Умножьте вероятность ошибки на её стоимость и сравните с экономией от автоматизации за тот же период. Если разница не кратная, а в пределах нескольких десятков процентов, браться не стоит, потому что любая неучтённая переменная съест выгоду.
Проверяемость результата
Автоматизация имеет смысл, когда проверка результата дешевле его создания. В этом вся экономика. Если для контроля ответа модели нужен эксперт того же уровня, который написал бы ответ сам за сравнимое время, выгоды нет. Вы лишь переложили работу с создания на вычитку, а вычитывать чужой уверенный текст тяжелее психологически, чем писать свой.
Проверяемость удобно разложить по уровням.
- Результат проверяется формально по правилу или справочнику. Сюда попадает классификация обращений, извлечение данных из документов, сверка реквизитов.
- Результат проверяется быстрым взглядом специалиста. Черновики текстов, сводки по звонкам, предварительные подборки резюме.
- Результат проверяется только через время и внешние последствия. Прогноз спроса, выбор стратегии, оценка потенциала сотрудника.
Первые два уровня пригодны к автоматизации при соблюдении остальных критериев. Третий уровень передавать модели нельзя, пока не найден способ приблизить проверку. Иначе вы получаете решения, качество которых выяснится через квартал, когда исправлять уже нечего.
Регламент и стабильность данных
Здесь работает старое правило, которое ИИ не отменил. Автоматизируя хаос, вы получаете быстрый хаос. Модель усиливает процесс, а не исправляет его, и делает это с масштабом, который человеку недоступен. Если в базе знаний поддержки лежат три версии инструкции по возврату товара и сотрудники интуитивно пользуются свежей, модель будет пользоваться всеми тремя.
Перед внедрением имеет смысл проверить несколько простых вещей. Описан ли процесс так, чтобы новый сотрудник выполнил его без наставника. Единообразны ли входные документы или каждый контрагент присылает свой формат. Есть ли список исключений и понятно ли, что делать при их появлении. Если на эти вопросы нет ответа, работа начинается не с внедрения, а с описания процесса, и это нормальный первый этап, который экономит бюджет.
Внедрение ИИ стоит воспринимать как стресс-тест управленческой зрелости. Процесс, который нельзя передать толковому стажёру с инструкцией, нельзя передать и модели.
Персональная ответственность и частота изменений
Есть класс решений, где важен не только результат, но и наличие субъекта, который за него отвечает. Отказ в выплате, увольнение, согласование сделки, медицинская рекомендация. В таких процессах подпись человека несёт самостоятельную ценность, потому что она создаёт точку обращения при споре и обеспечивает возможность пересмотра. Автоматизация здесь допустима только на подготовительных шагах, а финальное решение остаётся за человеком, который его подписывает и способен объяснить логику.
Частота изменений добавляет последний фильтр. Процессы, правила которых переписываются каждые две недели, съедают ресурс на поддержку быстрее, чем приносят экономию. Каждое изменение требует обновления инструкций, перепроверки на примерах, корректировки контроля. Если правила внутри процесса меняются чаще, чем раз в месяц, сначала стоит стабилизировать сам процесс, а автоматизацию отложить до появления устойчивой версии.
Шесть критериев дают не приговор, а карту. Процессы редко бывают целиком пригодными или целиком непригодными, чаще непригодна конкретная часть, и её нужно уметь выделить. Поэтому следующий шаг состоит в разборе конкретных зон, где автоматизация стабильно даёт отрицательный результат, и в понимании того, какая именно часть каждого такого процесса остаётся за человеком.
Зоны риска: процессы, которые остаются человеку
Критерии дают рамку, но на практике удобнее иметь перед глазами перечень участков, где отрицательный результат повторяется из компании в компанию. Я собрал семь таких зон. В каждой автоматизация возможна на периферии и опасна в ядре, поэтому важно понимать, где именно проходит граница.
Юридические и финансовые решения
Модель хорошо работает с юридическим текстом и плохо с юридическими последствиями. Она соберёт черновик договора, найдёт в документе пункты об ответственности, сравнит две редакции и подготовит перечень расхождений. Это полезная работа, которая экономит юристу несколько часов. Но решение о подписании, об уступке по неустойке, о подаче иска или об отказе в выплате опирается на обстоятельства, которых в тексте нет. Отношения с контрагентом, позиция судов в конкретном регионе, планы компании на следующий год, готовность собственника к риску.
Дополнительная сложность в том, что модель воспроизводит нормы с той точностью, с которой они встречались в данных. Законодательство меняется, формулировки уточняются, и ответ будет выглядеть одинаково уверенно до и после изменений. В финансовой части картина похожая. Подготовка платёжного реестра поддаётся автоматизации, а решение о платеже при недостатке средств на счёте требует понимания приоритетов, которые нигде не записаны.
- Допустимо передать модели сравнение редакций документов, извлечение данных и первичную проверку комплектности.
- Допустимо готовить черновики типовых писем и претензий с обязательной правкой юриста.
- Нельзя передавать расчёт налоговой базы без сверки, трактовку спорных норм и любые действия, порождающие обязательства компании.
- Нельзя передавать решения об одобрении кредита, скидки или рассрочки без явного правила и человека, подтверждающего исключения.
Найм, оценка и увольнение сотрудников
Автоматический отбор кандидатов выглядит идеальным сценарием. Поток резюме большой, критерии кажутся формальными, экономия времени очевидна. Проблема вскрывается через полгода, когда выясняется, что воронка стала однородной. Модель ориентируется на признаки успешных сотрудников из прошлого и воспроизводит их, отсекая нестандартные траектории. Человек с перерывом в стаже, с переходом из смежной отрасли, с незаконченным образованием и сильной практикой получает отказ по формальному признаку.
Второй слой проблемы связан с объяснимостью. Кандидат имеет право понимать причину отказа, а компания должна быть способна её назвать. Если решение принято алгоритмом, внутри которого нет явного правила, объяснение отсутствует. Это создаёт и репутационный, и правовой риск, особенно в части требований к обработке персональных данных.
Автоматизированный отбор не делает воронку объективнее. Он делает её прошлые перекосы быстрыми, массовыми и невидимыми.
Оценка эффективности и решения об увольнении стоят в той же категории, только с большей ценой ошибки. Сводка по выполненным задачам и формальным показателям полезна руководителю как материал для разговора. Вывод о соответствии сотрудника должности на основании этой сводки непригоден, потому что вклад человека в работу команды измеряется далеко не только тем, что попало в систему учёта.
Работа с персональными и конфиденциальными данными
Здесь ограничение носит правовой характер и обсуждению почти не подлежит. Передача персональных данных во внешний сервис без законных оснований и согласия субъекта создаёт прямое нарушение, а размер штрафов за утечки в последние годы вырос многократно. Отдельно действуют требования к размещению баз данных на территории России, что сужает выбор инструментов для процессов с реальными данными клиентов.
Практический вывод простой. Чем чувствительнее данные, тем ближе к собственной инфраструктуре должна быть модель. Возможных конфигураций немного, и выбор между ними делается до начала проекта, а не после.
| Тип данных | Допустимый контур | Что обязательно |
|---|---|---|
| Обезличенные тексты, публичная информация | Любой внешний сервис | Проверка условий использования данных поставщиком |
| Внутренние документы без персональных данных | Внешний сервис с договором или собственный контур | Соглашение о конфиденциальности, запрет на обучение на ваших данных |
| Персональные данные клиентов и сотрудников | Российская инфраструктура или локальная модель | Правовое основание, согласие, учёт в политике обработки |
| Специальные категории, медицинские и финансовые сведения | Только закрытый контур компании | Обезличивание на входе, журналирование, ограничение доступа |
Отдельная типовая ошибка связана не с архитектурой, а с поведением людей. Сотрудник вставляет в чат фрагмент договора или выгрузку с номерами телефонов, чтобы быстрее подготовить сводку. Формально процесс не автоматизирован, фактически данные уже покинули компанию. Поэтому политика использования модели нужна раньше, чем первое внедрение.
Конфликты, жалобы и кризисные коммуникации
Техническая поддержка по типовым вопросам автоматизируется успешно, и это одна из самых окупаемых зон. Но внутри входящего потока есть обращения другого типа. Клиент пишет не за информацией, а за признанием проблемы. Он потерял деньги, сорвал сроки перед своим заказчиком, получил бракованный товар во второй раз. Корректный по форме ответ с перечнем условий возврата в такой ситуации усиливает конфликт, потому что воспринимается как отказ слушать.
Модель не распознаёт этот переход надёжно. Эмоциональная окраска текста определяется неплохо, а вот значимость клиента, история предыдущих обращений и допустимый объём компенсации лежат за пределами запроса. Поэтому разумная схема строится на раннем выявлении и быстрой передаче человеку.
- Признаки для немедленной передачи оператору стоит задать явно. Повторное обращение по той же проблеме, упоминание суда, контролирующих органов или публикации в соцсетях, прямая просьба позвать человека.
- Передача должна происходить с сохранением всей переписки, чтобы клиенту не приходилось повторять историю.
- Публичные ответы на отзывы и комментарии в кризисной ситуации готовятся человеком. Автоматическая рассылка однотипных ответов под негативными отзывами читается мгновенно и усиливает недовольство.
- Официальные заявления при аварии, утечке или отзыве продукции не автоматизируются ни на каком этапе, кроме сбора фактов.
Медицинские решения и всё, что связано с безопасностью
В этой зоне граница задана не управленческим решением, а законом и природой риска. Постановка диагноза, назначение терапии, корректировка дозировки остаются за врачом, несущим ответственность. То же относится к допуску к работе, оценке состояния оборудования, расчёту несущих конструкций, настройке параметров безопасности на производстве. Ошибка здесь измеряется не деньгами.
Это не значит, что инструменты бесполезны. Они работают как подсказка и как второй взгляд. Автоматическое заполнение медицинской документации, предварительная сортировка обращений по срочности, выделение отклонений в потоке данных с датчиков, напоминание о пропущенном шаге регламента. Во всех этих сценариях модель расширяет внимание специалиста и не замещает его решение.
Финальный контроль качества и экспертная оценка
Соблазн понятен. Проверка результата кажется формальной операцией, а объём её большой. На практике передача финального контроля модели убирает из процесса единственное место, где ловились нетипичные ошибки. Модель хорошо проверяет соответствие формальным требованиям и плохо замечает то, что требований не нарушает, но является ошибкой по сути.
Пример из практики. Описание товара формально корректно, характеристики на месте, стилистика выдержана, но указана совместимость с моделью устройства, которая этот товар не поддерживает. Проверка на соответствие шаблону проходит успешно, ошибка уходит в каталог и возвращается валом возвратов. Человек с предметным знанием спотыкается на такой строке сразу.
Контроль можно усилить автоматизацией, но нельзя целиком заменить ею. Если за качеством не следит человек, качество измеряется только жалобами.
Стратегия, приоритизация и распределение ресурсов
Модель даёт сильный результат как собеседник при проработке решения. Она перечислит варианты, подскажет упущенные факторы, соберёт возражения к вашему плану, поможет структурировать аргументы. Это реальная ценность, и ею стоит пользоваться. Но выбор направления развития, распределение бюджета между подразделениями, отказ от продукта опираются на готовность компании к риску, на отношения с партнёрами, на неформальные договорённости и на понимание того, что люди в реальности способны сделать в срок. Эти переменные не оцифрованы и не будут оцифрованы.
Есть и вторая причина не передавать стратегию. Решение, которое руководитель не продумал сам, он не сможет защитить перед командой и не удержит при первом сопротивлении. Ценность стратегической работы частично состоит в самом процессе обдумывания, и автоматизация этот процесс обнуляет.
Что можно передать ИИ частично
Деление на автоматизируемое и неавтоматизируемое слишком грубое для практики. Почти любой процесс разбирается на шаги, и обычно часть шагов передаётся модели без риска, а один или два остаются за человеком. Задача проектирования состоит в том, чтобы найти правильную линию разреза, а не в выборе между полной автоматизацией и полным отказом.
Черновик с обязательной проверкой человеком
Это базовая и самая надёжная схема. Модель создаёт заготовку, человек доводит её до состояния, в котором готов поставить своё имя. Выигрыш возникает за счёт устранения самой дорогой части работы, то есть старта с пустого листа.
Схема работает при двух условиях. Проверяющий должен быть компетентен в предмете, иначе он не заметит ошибку. И у него должно быть время на проверку, заложенное в норматив. Если руководитель сократил сроки под предлогом появления ИИ, проверка превращается в формальность, и схема перестаёт выполнять свою функцию.
- Черновики писем, коммерческих предложений, описаний товаров и карточек услуг.
- Сводки по длинным обсуждениям, записям звонков и встречам с выделением договорённостей.
- Первые редакции внутренних инструкций и регламентов на основе интервью с сотрудниками.
- Варианты заголовков, структур и планов материалов для последующего отбора.
- Ответы на типовые обращения, которые оператор дочитывает и корректирует перед отправкой.
Полезная деталь в организации такой работы. Стоит заранее договориться, что правка черновика считается нормой, а не признаком плохой настройки. Иначе появляется искажение, при котором сотрудники отправляют результат без изменений, чтобы не выглядеть медленными.
Подготовительные этапы: сбор, сортировка, разметка
Самая недооценённая зона применения. Подготовительная работа занимает значительную долю времени специалистов, редко требует суждения и хорошо проверяется выборочно. Именно здесь автоматизация даёт тихий, стабильный эффект без управленческих рисков.
- Распределение входящих обращений по категориям и уровням срочности с передачей на нужную линию.
- Извлечение данных из счетов, накладных и однотипных форм с последующей сверкой по контрольным полям.
- Поиск нужных фрагментов в большом объёме документов и подготовка выжимки со ссылками на источник.
- Первичная разметка отзывов и обращений по темам для анализа причин недовольства.
- Приведение данных к единому формату, нормализация наименований, выявление дублей в справочниках.
- Подготовка повестки и материалов к встрече на основе предыдущих обсуждений.
Проверка на этом уровне строится на выборке. Берём случайные пять процентов результата, сверяем вручную, фиксируем долю ошибок и наблюдаем за её динамикой. Если доля растёт, это сигнал о смене данных на входе или об изменении поведения модели после обновления. Такой контроль занимает немного времени и решает главную проблему тихой деградации.
Границы ответственности: кто подписывает результат
Любая частичная автоматизация требует ответа на вопрос о подписи. Не в бюрократическом смысле, а в управленческом. Должен быть человек, который отвечает за выход процесса, знает, какая часть сделана моделью, и имеет право остановить работу.
Распределение удобно закрепить письменно до запуска, потому что после запуска договариваться сложнее.
| Роль | За что отвечает | Полномочия |
|---|---|---|
| Владелец процесса | Результат на выходе, соответствие регламенту | Остановить автоматизацию, изменить правила передачи человеку |
| Исполнитель на проверке | Качество конкретного результата, который он подтвердил | Отклонить работу модели, вернуть задачу в ручной режим |
| Технический ответственный | Работоспособность, версии, журналы обращений | Откатить изменения настроек, переключить на предыдущую версию |
| Ответственный за данные | Законность обработки, состав передаваемых сведений | Запретить передачу определённых данных во внешний контур |
Отдельно стоит зафиксировать правило информирования клиента. Если человек общается с автоматическим помощником, он должен это понимать, и у него должна быть возможность перейти к сотруднику. Попытка выдать модель за оператора разрушает доверие сильнее, чем любая техническая ошибка, и восстанавливается это доверие долго.
Ошибки при внедрении ИИ
Разбирая неудачные проекты, я почти всегда нахожу одну из четырёх ошибок. Они не связаны с выбором модели или подрядчика и повторяются в компаниях любого размера. Их объединяет общая черта. Каждая из них совершается на этапе подготовки, а обнаруживается через несколько месяцев, когда исправление стоит дороже первоначальной разработки.
Автоматизация непрописанного процесса
Самый частый сценарий. Процесс выбирают по ощущению трудоёмкости, а не по готовности к передаче. Внешне всё логично. Отдел тратит на согласование заявок двадцать часов в неделю, значит, здесь и экономия. Но при попытке описать шаги выясняется, что единого порядка нет. Один менеджер согласовывает по сумме, другой по типу клиента, третий звонит руководителю при любом сомнении.
Модель в такой ситуации получает три несовместимых правила и начинает выдавать результаты, которые каждый из трёх менеджеров считает неверными. Команда внедрения делает вывод о слабости инструмента, хотя причина в отсутствии процесса. Признаки, по которым эту ситуацию видно до начала работ, довольно заметны.
- На вопрос о порядке действий разные сотрудники дают разные ответы, и каждый уверен в своём.
- Регламент существует, но реальная работа идёт иначе, и об этом знают все, кроме руководителя.
- Нет перечня исключений, вместо него формулировка про решение по ситуации.
- Входные документы приходят в произвольных форматах, и приведение их к порядку считается частью работы специалиста.
- Критерий приёмки результата не сформулирован, качество определяется отсутствием жалоб.
Правильная последовательность выглядит иначе. Сначала описание процесса в текущем виде, затем устранение расхождений и фиксация правил, затем автоматизация стабильной версии. Первые два этапа дают эффект сами по себе, даже если до внедрения дело не дойдёт.
Нет точки контроля и ответственного
Вторая ошибка возникает из желания получить полностью автономный процесс. Логика понятна. Если результат нужно проверять, экономия сокращается, а ценность внедрения на презентации выглядит скромнее. Поэтому контроль убирают или делают его формальным, оставляя проверку на усмотрение сотрудников.
Через несколько недель процесс работает без надзора. Никто не знает текущую долю ошибок, никто не отвечает за выход, а при появлении проблемы начинается поиск виноватого между отделом, подрядчиком и техническим специалистом. Отсутствие ответственного превращает любой сбой в затяжное обсуждение вместо быстрого исправления.
Автоматизация без ответственного человека не экономит ресурс, а переносит его из текущей работы в разбор последствий.
Минимальная рабочая конструкция контроля состоит из четырёх элементов. Названный владелец процесса. Выборочная проверка с фиксированной периодичностью. Числовой порог, при превышении которого процесс возвращается в ручной режим. И срок пересмотра настроек, привязанный к календарю, а не к появлению проблем.
Экономия на людях вместо роста качества
Третья ошибка лежит в постановке цели. Когда проект начинается с задачи сократить штат, все последующие решения смещаются в одну сторону. Нормативы времени урезаются, проверка сокращается, порог передачи сложных случаев человеку поднимается, потому что каждая передача выглядит как провал автоматизации.
Результат предсказуем. Простые задачи обрабатываются быстрее, сложные начинают проваливаться, а сотрудники, которые раньше ловили нетипичные случаи, либо уволены, либо загружены объёмом проверки без времени на вдумчивую работу. Экономия в отчёте есть, потери в оттоке клиентов и в исправлении ошибок в отчёт не попадают, потому что считаются в другом центре затрат.
Более устойчивая постановка цели звучит так. Освободить время специалистов от механической части, чтобы они занялись тем, что раньше делалось в последний момент и некачественно. При таком подходе измеряются не сокращённые часы, а изменение показателей процесса.
- Доля обращений, решённых с первого контакта, вместо числа обработанных обращений.
- Время от поступления документа до готового решения, а не скорость отдельного шага.
- Количество возвратов и переделок после выхода результата.
- Доля случаев, где потребовалось вмешательство человека, в динамике по месяцам.
Отказ от логов и аудита решений
Четвёртая ошибка техническая по форме и управленческая по последствиям. Процесс запускают без журналирования. Не сохраняются запросы, не фиксируется версия модели, не записывается, какой результат был отдан и кто его подтвердил. Пока всё работает, отсутствие логов не ощущается как проблема.
Проблема появляется в момент разбора. Клиент утверждает, что получил неверную информацию о сроках возврата. Проверить нечего. Непонятно, что именно было отвечено, на основании какой инструкции, какая версия модели работала в тот день и менялись ли настройки на этой неделе. Восстановить картину невозможно, а значит, невозможно и исправить причину. Остаётся общая фраза про доработку.
Минимальный набор того, что стоит сохранять, невелик и редко требует сложной разработки.
| Что фиксируем | Зачем это нужно |
|---|---|
| Входной запрос и переданный контекст | Понять, располагала ли модель нужными данными |
| Выданный результат и время | Восстановить ход событий при споре |
| Версия модели и текущая редакция инструкции | Связать изменение качества с обновлением |
| Факт проверки и имя подтвердившего | Определить, где именно пропущена ошибка |
| Случаи передачи человеку и причина | Увидеть границы применимости в реальных данных |
При работе с персональными данными журналы сами становятся объектом защиты, поэтому доступ к ним ограничивается, а сроки хранения определяются заранее. Это не повод отказываться от логов, это повод спроектировать их аккуратно.
Чек-лист проверки процесса перед автоматизацией
Этот перечень удобно проходить на встрече с владельцем процесса до обсуждения инструментов. Отрицательный ответ не запрещает проект, но указывает, что именно нужно сделать раньше внедрения. Три и более отрицательных ответа означают, что автоматизацию стоит отложить.
- Процесс описан письменно, и новый сотрудник выполнит его по инструкции без наставника.
- Перечень исключений составлен, и для каждого понятен порядок действий.
- Входные данные приходят в предсказуемом виде, а источники их формирования известны.
- Критерий правильного результата сформулирован так, что два человека оценят одинаково.
- Проверка результата дешевле его создания и выполняется за минуты.
- Цена худшей из вероятных ошибок посчитана и сопоставлена с ожидаемой экономией.
- Действие обратимо, либо перед необратимым шагом стоит подтверждение человека.
- Определён владелец процесса с правом остановить автоматизацию.
- Состав передаваемых данных проверен на соответствие требованиям к обработке персональных сведений.
- Выбран контур обработки, и он соответствует чувствительности данных.
- Правила передачи сложного случая человеку описаны явными признаками.
- Настроено журналирование запросов, результатов и версий.
- Заданы показатели качества и порог, при котором процесс возвращается в ручной режим.
- Сотрудники знают о внедрении, понимают свою роль и имеют время на проверку в нормативе.
- Есть рабочая ручная процедура, по которой процесс пойдёт при отключении автоматизации.
Последний пункт выпадает чаще всего, а на практике он важнее большинства остальных. Компании, которые сохранили работоспособный ручной вариант, переживают сбои поставщика или неудачное обновление за один рабочий день. Те, кто демонтировал старый порядок сразу после запуска, останавливают процесс целиком.
Как откатить автоматизацию, если ИИ уже внедрён
Ситуация, когда процесс уже работает и результат не устраивает, встречается чаще, чем аккуратный выбор на старте. Здесь важно не поддаться двум крайностям. Резкое отключение парализует работу, потому что люди отвыкли и часть знаний ушла вместе с уволенными сотрудниками. Продолжение по инерции накапливает ошибки. Разумный путь состоит из пяти шагов и занимает от двух недель до полутора месяцев.
Шаг первый: измерить фактическое качество
До любых решений нужны числа. Берём случайную выборку результатов за последний месяц, не меньше ста случаев, и проверяем их вручную силами компетентного специалиста. Фиксируем не только долю ошибок, но и их характер. Отдельно считаем ошибки на простых случаях и на сложных, потому что это разные диагнозы. Высокая доля ошибок на сложных случаях при хорошей работе на простых означает, что нужно менять правила передачи человеку, а не отключать инструмент.
Шаг второй: найти границу, где процесс ломается
Почти всегда обнаруживается конкретный участок. Определённый тип обращений, документы одного контрагента, вопросы, требующие знания условий, которых нет в базе. Задача этого шага состоит в том, чтобы описать проблемную зону признаками, по которым её можно отделить автоматически. Если признаки найдены, откат получается частичным и сохраняет полезную часть работы.
Шаг третий: вернуть человека в разрыв
На выявленный участок ставится обязательная проверка или полный ручной режим. Здесь понадобится честный разговор с командой о сроках, потому что нагрузка вырастет. Нормативы времени нужно вернуть к реальным значениям, иначе проверка снова станет формальной. Если ручная компетенция утрачена, восстанавливать её придётся через обучение, и этот срок стоит включить в план.
Откат автоматизации не является признанием провала. Это нормальная управленческая операция, которая возвращает процессу работоспособность.
Шаг четвёртый: исправить причину, а не симптом
Когда поток стабилизирован, появляется время на разбор. В большинстве случаев причина лежит в одном из трёх мест. Неполный контекст, который передаётся модели. Отсутствие правила для класса ситуаций, который не был предусмотрен. Или изменение входных данных, произошедшее после запуска и никем не замеченное. Исправление этих причин возвращает часть процесса в автоматический режим уже осознанно, с проверкой на отложенной выборке.
Шаг пятый: закрепить порядок наблюдения
Чтобы история не повторилась, нужен постоянный режим контроля. Он складывается из нескольких простых договорённостей.
- Выборочная проверка с заданной периодичностью и назначенным исполнителем.
- Фиксация доли вмешательств человека как основного индикатора состояния процесса.
- Обязательная перепроверка на контрольных примерах после каждого обновления модели или инструкции.
- Квартальный пересмотр границы между автоматической и ручной частью, поскольку процессы меняются.
- Канал, по которому сотрудники сообщают о странных результатах без риска получить замечание за замедление работы.
Если собрать всё сказанное в одну мысль, она окажется довольно простой. Решение о том, что автоматизировать не следует, не означает отказ от технологии. Оно означает, что вы знаете устройство своего процесса достаточно хорошо, чтобы разложить его на части и передать машине только то, что она действительно выполняет лучше. Компании, которые научились проводить эту линию аккуратно, получают от ИИ больше, чем те, кто пытался отдать ему всё целиком. Разница не в инструментах, а в качестве предварительной работы, и эта работа остаётся человеческой по своей природе.
Сильная автоматизация начинается не с вопроса о том, что можно передать модели, а с честного ответа на вопрос, где именно в вашем процессе думает человек.
