Как подготовить ИИ-систему к независимой проверке: практический маршрут

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

Ниже — маршрут для рабочего пилота. Он подходит чат-боту, поиску по документам и агенту с инструментами. Для решений в медицине, финансах и других регулируемых областях этого недостаточно: там добавляются юридические и отраслевые требования.

1. Зафиксируйте границу системы

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

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

2. Разделите заявления на тесты

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

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

3. Дайте проверяющему реальный доступ

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

Отдельно запишите, какие области закрыты и почему. Ограничение не стыдно; опасно скрыть его, а потом распространить вывод на всю систему.

4. Подготовьте эталон

Для десяти–тридцати примеров нужен принятый человеком результат. Эталон не обязан быть идеальным, но должен иметь владельца и объяснение. Если эксперты расходятся, это фиксируют как неоднозначность задачи, а не заставляют модель угадать «правильный» вариант.

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

5. Сделайте журнал пригодным для расследования

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

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

6. Закрепите право остановки

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

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

7. Проведите слепую приёмку

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

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

8. Опубликуйте ограничения вместе с выводом

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

После обновления модели повторите контрольный набор и пограничные случаи. Исходный отчёт не переписывают задним числом — выпускают новую версию с объяснением изменений.

Короткий FAQ

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

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

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