Как контролировать качество AI-работы

Почему «AI отлично справляется» — плохой критерий качества

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

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

Сначала определите, что считается приемлемым результатом: совпадают ли факты с проверенным источником, соблюдены ли сроки, указаны ли неопределённости, есть ли зафиксированная ответственность за отправку.

Разделите задачи по последствиям ошибки

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

Качественное поручение состоит из шести полей

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

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

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

Источники и разрешения: AI не должен видеть всё подряд

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

Если сервис читает Google Drive, таблицы, CRM или корпоративные документы, раздельно проверяйте чтение, изменение, создание, отправку и удаление. Read-only подключения уменьшают класс рисков, но не гарантируют конфиденциальность: из прочитанного можно случайно сформировать небезопасный ответ.

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

Три уровня проверки результата

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

Уровень 2 — фактическая сверка. Проверяются цены, даты, названия документов, цитаты и соответствие версии источника. AI может убедительно выдумать факт, поэтому ссылка должна реально вести на документ, подтверждающий утверждение.

Уровень 3 — бизнес-решение. Ответственный человек оценивает контекст, тон, риски, договорные условия и последствия. Даже идеальная арифметика не означает, что предложение допустимо отправлять клиенту.

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

Пятнадцать тестов вместо одной красивой демонстрации

Перед внедрением подготовьте небольшую тестовую выборку:

1. Пять обычных типовых задач с вымышленными данными.
2. Три задачи с неполными условиями, где нужна оговорка или вопрос.
3. Три задачи с противоречивыми документами разной даты.
4. Две задачи со структурой и вычислениями, которые легко сверить вручную.
5. Две задачи на соблюдение границ: система должна отказаться от недопустимого действия или запросить подтверждение.

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

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

Точность, полезность и критические ошибки — разные показатели

Средняя оценка 4,8/5 не оправдывает один опасный платёж или раскрытие чужих данных. Для критических ошибок установите отдельный стоп-порог, а не прячьте их среди удачных черновиков.

Учебный кейс: руководитель Олег и команда из четырёх человек

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

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

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

Учебная экономика: считаем готовую работу, а не токены

Допустим, один сотрудник без AI тратит 14 минут на готовый проверенный ответ. В месяц команда делает 200 таких ответов: 200 × 14 = 2800 минут, или 46 часов 40 минут.

В гипотетическом AI-процессе черновик и ввод данных занимают 4 минуты, проверка — ещё 5 минут: 200 × 9 = 1800 минут, или 30 часов. Экономия — 1000 минут, то есть 16 часов 40 минут.

Если условно оценить час работы в $18, потенциальная стоимость высвобождённого времени — $300. При гипотетических затратах на AI и инструменты $80 условный баланс составляет $220 до дополнительных ошибок, налогов и простоев. Не называйте его подтверждённой прибылью.

Теперь добавим в среднем три минуты повторной проверки на каждый ответ. Тогда 200 × 12 = 2400 минут; экономия сократится до 400 минут, или 6 часов 40 минут. По прежней ставке это около $120, после $80 расходов — $40. Малое увеличение ручной проверки резко меняет экономику.

Умная маршрутизация — не магия и не повод раскрывать данные

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

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

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

Документы и таблицы: чем полезен режим только чтения

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

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

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

Инцидент: что делать при неправильном AI-ответе

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

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

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

Семидневный план руководителя

1. День 1. Выберите одну повторяющуюся низкорисковую задачу и измерьте действующий процесс.
2. День 2. Опишите шестипольное поручение и запреты; назначьте ответственного человека.
3. День 3. Соберите пятнадцать синтетических тестов и критерии их приёмки.
4. День 4. Ограничьте источники и права; убедитесь, что AI не может совершать запрещённые действия.
5. День 5. Проведите тесты, отдельно отметив фактические и критические ошибки.
6. День 6. Посчитайте время на ввод, правки, проверку, инструменты и поддержку.
7. День 7. Разрешите только ограниченный пилот при приемлемом риске, добавьте журнал ошибок и право остановки.

Семь дней — удобная структура первого испытания. Для финансовых, медицинских, правовых и иных критичных операций её недостаточно.

Двенадцать контрольных вопросов

1. Какая конкретная задача передаётся AI?
2. Кто отвечает за результат перед клиентом?
3. Какие источники считаются достоверными и актуальными?
4. Какие данные запрещено передавать провайдерам?
5. Есть ли разделение чтения и изменения?
6. Какие действия требуют подтверждения человека?
7. Проверяются ли числа, сроки и ссылки независимо?
8. Есть ли отдельное правило для критической ошибки?
9. Зафиксированы ли модель, настройки и версия инструкций?
10. Считается ли полное время до готовой работы?
11. Существует ли возможность остановить процесс и восстановиться?
12. Проверяется ли качество после изменения провайдера или источника?

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

Вопросы и ответы

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

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

Что делать, если AI не знает ответа? Это нормальная граница. Помощник должен запрашивать уточнение или отмечать неопределённость, не выдумывая факты.

Почему не выбрать одну «самую мощную» модель? Разные задачи требуют разной глубины анализа, инструментов и контроля. Выбор следует проверять по качеству и стоимости, а не только названию.

Достаточно ли пятнадцати тестов? Нет. Это первый фильтр ошибок; после запуска нужны расширенные проверки и наблюдение.

Можно ли подключать рабочие документы? Лишь при понятных правах доступа, обработке данных и договорных условиях. Read-only доступ полезен, но не отменяет требований безопасности.

Официальные источники

- NIST AI Risk Management Framework - NIST AI RMF Playbook - EDPB — основы защиты персональных данных - OWASP — LLM Top 10 - AGENTUM — бизнес-инструменты AI