Границы доверия к ИИ: где агенту верить, а где ставить проверку
С ИИ часто спорят слишком общо: можно ему доверять или нельзя. Такой вопрос почти бесполезен. Один и тот же агент может идеально переименовать файлы, нормально собрать черновик письма, ошибиться в фактах и быть опасным рядом с платежами, публикацией или юридическим выводом.
Поэтому доверие к ИИ должно быть не эмоцией, а картой. В ней видно, какие действия можно принимать сразу, какие требуют проверки, какие должны проходить ручное утверждение, а какие вообще нельзя отдавать модели.
OpenAI в материале Why language models hallucinate объясняет важную вещь: модели обучены продолжать текст и могут выдавать уверенные неточности. Для практика вывод простой: если задача требует факта, источника или ответственности, агенту нужна проверка.
Что здесь меняется
Плохая система говорит: "модель умная, пусть делает". Хорошая система говорит: "вот уровни доверия".
Главное:Не решайте один раз, можно ли доверять ИИ. Разложите работу агента по уровням: принять сразу, проверить источником, отправить на ревью, запретить без человека.
Карта доверия
| Уровень | Что можно делать | Пример | Проверка |
|---|---|---|---|
| Зеленый | принимать без ручной проверки | форматирование, сортировка, черновая разметка | автоматический тест или простой diff |
| Желтый | проверять выборочно | резюме письма, черновик поста, список идей | чтение источника человеком |
| Оранжевый | проверять обязательно | фактология, выводы по документу, рекомендации | ссылка, цитата, второй источник |
| Красный | не отдавать без человека | платеж, публикация, юридическое решение, удаление данных | ручное утверждение |
Эта карта должна быть привязана к реальным задачам. Для Codex зеленым может быть переименование локальных файлов по понятному правилу. Желтым - черновик документации. Оранжевым - изменение бизнес-логики. Красным - деплой, удаление данных, отправка письма клиенту или публикация на сайт.
NIST AI RMF Generative AI Profile полезен как напоминание: генеративные системы требуют управления рисками, мониторинга и оценки, а не только хорошего промпта. В агентном контуре это превращается в практическую дисциплину: у каждого действия есть уровень риска.
Почему модель-судья не решает все
Иногда кажется, что проверку можно просто отдать другой модели. Частично можно: модель может найти явные противоречия, проверить формат, заметить пропущенные поля. Но это не абсолютная независимость.
Исследования про LLM-as-a-judge, например работа о self-preference bias, показывают, что у модельных оценщиков бывают свои смещения. Значит, модель-судья - это полезный фильтр, но не последний арбитр для важных решений.
Как применить это в Codex
Для каждой регулярной задачи Codex заведите короткую строку:
- Что агент делает.
- Какие файлы или данные он трогает.
- Какой уровень доверия у действия.
- Как проверяется результат.
- Где агент обязан остановиться.
Например:
| Задача Codex | Уровень | Правило |
|---|---|---|
| собрать список источников | желтый | человек открывает ключевые ссылки |
| исправить тест | оранжевый | тест должен пройти, diff читается |
| обновить публичную статью | красный | ревью текста и live-аудит обязательны |
| создать черновик README | желтый | читается перед публикацией |
OWASP Top 10 for LLM Applications отдельно выделяет риски вроде prompt injection, excessive agency и overreliance. Это ровно про границы доверия: чем больше агент может сделать сам, тем строже должен быть контур проверки.
Какой навык собирается: не спорить с ИИ на уровне веры, а проектировать уровни доверия для каждого действия.