Аудит AI-проекта: решение о запуске по доказательствам
Удачная демонстрация на двух документах ничего не говорит о готовности AI-проекта. Для решения о запуске нужен пакет доказательств: какой процесс меняется, на каких данных, с какой версией модели, сколько стоит принятый результат и что происходит при ошибке. Аудит не выносит технологический вердикт заранее. Он показывает, где пилот уже повторяем, где допустимо ограниченное применение, а где безопаснее остановиться.
1. Зафиксируйте границу процесса
Опишите маршрут от входа до решения без слова «оптимизировать». Укажите владельца, исходный формат, действие модели, конечный результат и человека, который его принимает. Цель «сократить подготовку внутреннего отчёта с 90 до 40 минут при сохранении проверки чисел» измерима; цель «внедрить ИИ в отдел» — нет.
Заранее запишите цену трёх ошибок: пропуска, ложного срабатывания и опасного действия. Для чернового резюме они различаются, а для платежа или юридического письма любая из них может требовать обязательного ручного согласования. Если граница ответственности не определена до теста, проект нельзя масштабировать.
2. Соберите пакет исходных данных
Составьте опись источников: файл, владелец, дата обновления, формат, права и известные дефекты. Отдельно отметьте дубли, устаревшие версии и фрагменты, где правило разделено между страницами. Сохраните журнал очистки, чтобы через месяц было понятно, почему конкретная строка исчезла из выборки.
Создайте закрытую контрольную выборку, которую не используют при настройке промпта. Включите обычные случаи, неполные формы, опечатки, конфликтующие инструкции и редкие исключения. Персональные данные обезличьте до передачи; порядок локальной очистки описан в материале о маскировании.
3. Проверьте фактический маршрут модели
Запишите идентификатор модели и версии, режим доступа, лимит контекста, параметры генерации и резервный вариант. Уточните, где выполняется обработка — локально, в облаке или через промежуточный сервис. Название кнопки не гарантирует конкретную модель: сверяйте фактический идентификатор в журнале.
Разделите процесс на этапы. Извлечение фактов, формирование вывода, вызов инструмента и проверка человеком должны иметь отдельные записи. Один длинный запрос скрывает место появления ошибки и мешает оценить пользу каждого шага.
4. Проведите воспроизводимый тест
Подготовьте минимум 30 задач: 18 обычных, шесть пограничных и шесть с ожидаемым отказом. Для каждой заранее задайте обязательные поля, допустимый формат и источник, с которым сверяется результат. Запускайте задания в одинаковом окружении и сохраняйте необработанный ответ до редакторских правок.
Повторите десять задач через день, не меняя вход. Затем измените только версию инструкции и снова сохраните отчёт. Так вы увидите, что именно влияет на результат: данные, модель, промпт или случайность. Методика проверки ответов и ручного подтверждения разобрана в отдельном гайде.
5. Ведите реестр рисков
Для каждого риска укажите вероятность, последствия, обнаруживающий тест, владельца и компенсирующую меру. Не пишите «модель может ошибиться» без конкретики. Запись «при смешанном формате дат перепутан день и месяц; проверка — контрольный лист; мера — расчёт блокируется до подтверждения» пригодна для решения.
| Риск | Как обнаружить | Временная мера |
|---|---|---|
| Выдуманный факт | сверка с исходником | обязательная цитата и ревью |
| Пропуск строки | сравнение количества записей | контрольная сумма скриптом |
| Инъекция в документе | вредная инструкция в тестовом файле | считать текст данными |
| Лишний вызов API | журнал аргументов | белый список и подтверждение |
| Утечка секрета | поиск токенов в логах | локальная очистка и ротация |
Для агента дополнительно проверьте восстановление после тайм-аута и откат. Успешный текст после неверного изменения записи не является успешным запуском.
6. Проверьте безопасность доступа
Разделите права чтения, записи и выполнения. Токены выдавайте с минимальным охватом, опасные команды отключите по умолчанию, а подтверждение человека вынесите в отдельный шаг интерфейса. Попробуйте намеренно добавить во вход просьбу игнорировать правила проекта. Система должна распознать её как данные и остановиться, а не исполнить.
Проверьте историю запросов, резервные копии и срок удаления временных файлов. Если поставщик не объясняет хранение, используйте синтетические данные до уточнения политики. Локальный валидатор JSON-LD и другие технические тесты не заменяют аудит доступа и поведения модели.
7. Посчитайте экономику принятого результата
Суммируйте запросы, повторные прогоны, распознавание файлов, хранение и время сотрудника на проверку. Сравните не стоимость черновика, а цену документа, который можно принять без риска. Зафиксируйте бюджет пилота, минимально допустимую точность и предел ручных исправлений.
Если метрики не достигнуты, определите причину: сузить задачу, изменить данные, выбрать другую модель или отказаться от автоматизации. Не компенсируйте плохой результат увеличением числа запросов без нового измерения.
8. Примите решение go/no-go
Разделите итог на три статуса:
- Продолжать пилот. Контрольная выборка пройдена, риски имеют меры, владелец назначен.
- Ограничить. Полезен только черновой этап, чтение или один отдел; опасные действия остаются ручными.
- Остановить. Есть неустранимые утечки, повторяющиеся фактические ошибки или экономика хуже ручного процесса.
К каждому статусу приложите тестовые записи, метрики, реестр рисков и дату следующего пересмотра. Решение без доказательств превращается в мнение презентации.
Как оформить аудиторский пакет, который можно перепроверить
Соберите материалы в четыре слоя, а не в один длинный отчёт. В первом лежит описание процесса и критерий успеха. Во втором — обезличенная выборка и эталонные ответы. В третьем — журнал запусков с моделью, промптом, временем и исправлениями. В четвёртом — решение комиссии с указанием открытых рисков. Такое разделение позволяет заменить модель или инструкцию, не переписывая всё исследование с нуля.
Перед встречей с владельцем процесса проведите «слепое чтение». Дайте коллеге только вход, полученный результат и эталон, но не говорите, какой режим был включён. Попросите отметить расхождения и место, где он перестал бы доверять ответу. Затем сопоставьте замечания с логом: иногда проблема заметна человеку, но не попадает в формальную метрику, например неуместный тон или неудобный формат для следующего шага.
Зафиксируйте срок действия вывода. Аудит, проведённый на одной версии модели и одном типе данных, не становится бессрочным разрешением. Запишите триггеры повторной проверки: смена провайдера, обновление системного промпта, новый формат файла, рост доли отказов или изменение требований к хранению. При каждом триггере достаточно прогнать сокращённую контрольную выборку и сравнить худшие случаи с предыдущим пакетом. Так решение остаётся живым контролем, а не красивым документом, который никто не открывает после запуска.
Итоговый чек-лист
Проверьте цель и цену ошибки, опись данных, закрытую выборку, идентификатор модели, разделённые этапы, повторный прогон, реестр рисков, права и бюджет. После исправлений соберите пакет заново и подпишите его ответственным человеком. Аудит не доказывает безошибочность ИИ; он показывает, где технология уже управляемо помогает и какие границы нельзя пересекать.