Процесс проверки AI: эксперты для рисков, инженеры для правил

Почему это часто идёт не так

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

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

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

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

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

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

Найдите результаты, где есть реальный риск

Большинство ошибок AI начинается не в модели. Они начинаются тогда, когда команда считает все результаты одинаково безобидными. Короткое внутреннее резюме — это одно. Письмо клиенту, где обещан возврат денег или изменены условия договора, — совсем другое.

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

Чтобы их отсортировать, задайте четыре вопроса:

1. Кто это читает?
2. Может ли человек сразу что-то сделать на основании этого?
3. Влияет ли это на деньги, безопасность, юридические условия или соблюдение требований?
4. Во что обойдётся один неправильный ответ?

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

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

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

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

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

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

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

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

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

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

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

Пусть инженеры отвечают за ограничения

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

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

Что должны зафиксировать инженеры

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

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

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

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

Несколько правил закрывают большую часть задачи:

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

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

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

Постройте процесс проверки шаг за шагом

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

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

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

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

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

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

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

Простой пример из финансовой команды

Финансовая команда начинает с узкой задачи: AI готовит черновики ответов по спорам о счетах. Клиент может сказать, что в счёте неверная сумма, платёж уже прошёл или штраф за просрочку применять не нужно. Модель пишет первый черновик, но ничего не отправляет сама.

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

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

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

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

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

Теперь черновики улучшаются так, что это можно измерить. Возможно, раньше бухгалтер тратил на спор по счёту шесть минут, а теперь тратит две. И что ещё важнее — одни и те же ошибки перестают возвращаться.

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

Ошибки, которые команды совершают в начале

На старте команды часто делают одно неверное предположение: будто у всех AI-результатов одинаковый риск. Это не так. Черновик поста в соцсетях и письмо с советом по платежу не должны проходить через один и тот же маршрут проверки.

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

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

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

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

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

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

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

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

Разделение между бизнес-проверкой и управлением системой — это практическое решение. Oleg Sotnikov часто работает именно так в AI-first операциях: профильные эксперты проверяют бизнес-риск, а инженеры управляют инструментами, границами и путями отказа.

Короткий чек-лист перед запуском

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

1. Вы описали результаты, которые могут причинить вред? Начните со всего, что может менять деньги, юридические условия, обещания клиентам, формулировки по комплаенсу или медицинские и безопасностные рекомендации.
2. У каждого рискованного результата есть один именованный владелец? Групповой ящик почты — не решение. За каждый тип ответа должен отвечать один человек, даже если его могут подменять другие.
3. Система останавливается и просит человека в нужный момент? Не полагайтесь на память людей. Продукт должен блокировать отправку, публикацию или утверждение, пока проверяющий не подтвердит результат.
4. Вы сохраняете правки и их причину? Если проверяющий меняет цифру, убирает утверждение или переписывает предложение, это нужно сохранять.
5. Вы можете быстро откатиться? Если качество результата падает после обновления модели или изменения промпта, команда должна уметь за минуты отключить автоматизацию, перейти на ручную проверку или восстановить последнюю безопасную конфигурацию.

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

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

Такая дисциплина скучна. Но именно она предотвращает большую часть ненужного ущерба.

Что делать дальше

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

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

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

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

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

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

Если вы настраиваете это в небольшой или средней компании, Oleg Sotnikov на oleg.is работает как fractional CTO и советник по практическому внедрению AI, инженерным ограничениям и лёгким процессам проверки. Такая внешняя помощь особенно полезна, когда команде нужны понятные правила и процесс, который действительно можно поддерживать.