Anchor 3.0: новые модели для проверки коммуникаций ИИ-агентов
23 сентября ZeroDrift объявила о доступности семейства Anchor 3.0 — небольших моделей, предназначенных для контроля коммуникаций ИИ-агентов до отправки. Смысл такого слоя понятнее, если не называть его «умной модерацией». Агент может верно решить задачу, но отправить письмо не тому получателю, раскрыть лишнюю деталь, пообещать невозможное или использовать неутверждённый тон. Эти ошибки не исчезают от более длинного системного промпта.
Что проверяет отдельный слой
У каждого сообщения должна быть явная цель: ответить на запрос, передать статус, предложить черновик или попросить подтверждение. Контрольный слой получает эту цель, набор правил и контекст получателя. Он проверяет, не противоречит ли исходящая фраза ограничению: например, не выдаёт ли агент личные данные, не обещает ли срок без основания и не отправляет ли действие без согласования.
Важно не путать проверку с догадкой о намерении. Правила должны быть короткими и наблюдаемыми: разрешённые домены, обязательные поля, запрет на конкретный тип данных, лимит суммы, необходимость подтверждения. Если правило невозможно объяснить человеку, его будет трудно проверить и исправить после ложного срабатывания.
Как провести первый пилот
Не подключайте проверку сразу к реальной рассылке. Возьмите архив уже утверждённых сообщений и несколько неудачных примеров, очистите персональные данные и пропустите их через стенд. Для каждого решения фиксируйте: правило, вход, результат, причину блокировки и решение редактора. Цель пилота — не добиться нуля блокировок, а увидеть, понимает ли команда, почему сообщение прошло или было остановлено.
Затем задайте маршрут для пограничных случаев. Если система не уверена, она не должна переписывать письмо молча. Пусть помечает фрагмент, показывает сработавшее правило и передаёт черновик человеку. Такая пауза может казаться медленной, но она дешевле ошибочной коммуникации с клиентом или партнёром.
Ограничения
Контрольная модель сама тоже ошибается. Она может пропустить обходное выражение, неверно понять бизнес-термин или слишком строго заблокировать безобидный ответ. Поэтому критичные правила остаются на сервере: ограничения доступа, список получателей, лимит отправки и требование подтверждения. Модель дополняет эти барьеры объяснением и классификацией, но не заменяет их.
Полезный стартовый набор — запрет личных данных, запрет необоснованных обещаний, проверка получателя и маркировка черновика. Когда метрики ложных пропусков и ложных блокировок понятны, можно добавлять более тонкие правила. Для настройки процесса пригодится гайд о контроле агентной задачи и материал о защите от prompt injection.
Вывод
Anchor 3.0 интересна как повод отделить генерацию ответа от права его отправить. Надёжный агентный процесс состоит из явных правил, сервера-посредника, журнала и человека на спорных случаях. Модель проверки делает этот маршрут удобнее, но не превращает автономную переписку в безопасную по умолчанию.
FAQ
Можно ли заменить правила одной контрольной моделью? Нет. Права доступа и лимиты должны исполняться программно.
Что делать при неуверенности модели? Не отправлять сообщение автоматически и передать его на проверку человеку.
Как измерить пользу? Считать критичные пропуски, ложные блокировки, время редактора и число предотвращённых нарушений.