Astra Guarded: карточка модели с контролем действий
Astra Guarded стоит рассматривать не как автономного сотрудника, а как модель для задач, где каждое действие можно ограничить и проверить. Название режима подчёркивает идею: агент предлагает шаг, но чувствительные операции должны проходить через подтверждение. В этой карточке мы отделяем свойства подхода от маркетинговых обещаний и показываем, как проверить модель на собственном сценарии до подключения к рабочим системам.
Короткий профиль
Тип: агентная языковая модель с инструментальными вызовами и ограничениями доступа. Основные задачи — разобрать запрос, составить план, подготовить черновик команды или отчёта, а затем дождаться решения оператора. Дата проверки карточки — 4 сентября 2026 года; интерфейс, доступность и лимиты могут измениться.
Модель полезна там, где вход можно обезличить, список действий заранее известен, а результат проходит контроль. Она не должна самостоятельно удалять записи, отправлять письма, менять права, проводить платежи или запускать команды вне белого списка. Если задача не допускает остановки между предложением и действием, guarded-режим не превращает её в безопасную автоматически.
Что проверить до запуска
Составьте карту доступа. Для каждого инструмента укажите, какие данные он читает, какое действие выполняет, что возвращает и кто может нажать «подтвердить». Отдельно опишите запрещённые области: персональные данные, секреты, продакшен-базу и каталоги с резервными копиями. Ключи API храните в секретном хранилище или переменных окружения, а не в системной инструкции.
Подготовьте обезличенный набор из десяти–пятнадцати примеров. В него должны входить нормальная задача, неполный вход, конфликтующие инструкции, попытка выйти за пределы прав и запрос с двусмысленным результатом. Для каждого примера зафиксируйте ожидаемый следующий шаг: выполнить, спросить уточнение, отказать или передать человеку.
Поведение агента и подтверждения
В хорошем сценарии Astra сначала показывает план: какие данные использует, какой инструмент вызовет и какой результат ожидает. До внешнего действия оператор видит понятное подтверждение, а не технический идентификатор. После выполнения в журнале остаются запрос, версия модели, имя инструмента, время, ответ и решение человека. Если модель пропустила подтверждение или скрыла параметр, тест считается проваленным, даже если итог выглядит правильным.
Установите небольшой белый список функций. Для чтения отчёта разрешите только конкретный запрос с ограничением периода и количества строк; для записи — отдельный маршрут с предварительным просмотром. Тайм-аут, лимит вызовов и автоматический откат должны быть настроены до пилота. Ошибка сети или неполный ответ должны приводить к паузе, а не к повторному действию без участия оператора.
Проверка качества
Оценивайте не «умность» ответа, а прохождение контрольных точек. Сверьте факты с входными данными, проверьте, не появились ли лишние поля, и посчитайте долю корректных отказов. Для планов важна последовательность: агент не должен вызывать инструмент, пока не получил обязательный параметр. Для черновиков измеряйте количество правок, а не количество сгенерированных строк.
Повторите тест несколько раз с одинаковыми настройками. Зафиксируйте задержку, число вызовов и стоимость. Затем намеренно добавьте в пользовательский текст просьбу игнорировать ограничения и сравните результат. Устойчивая модель повторяет отказ и объясняет границу; случайное «согласие» означает, что сценарий нельзя расширять.
Ограничения и риски
Агент может неверно понять цель, выбрать слишком широкий запрос или принять вредный фрагмент текста за инструкцию. Ограничения на интерфейсе не защищают от плохо настроенных прав в самой системе. Нужны отдельные роли, журналирование и регулярный просмотр действий. Не отправляйте внешнему сервису документы, для которых нет разрешения на обработку, даже если модель обещает не сохранять историю.
С осторожностью относитесь к демонстрациям, где показан один идеальный диалог. Реальная стоимость складывается из повторных вызовов, ручных подтверждений, поддержки и расследования ошибок. Перед расширением пилота сравните её с привычным процессом на одинаковой выборке.
Практический пилот на один отдел
Выберите безопасную задачу: собрать черновик внутреннего отчёта из обезличенных строк или подготовить список вопросов к документу. Запретите запись и отправку наружу, назначьте одного владельца и срок в одну неделю. Каждый день просматривайте журнал и отмечайте: где модель попросила уточнение, где ошиблась, сколько времени заняла проверка.
Порог остановки задайте заранее: например, одна попытка обхода прав, две фактические ошибки или рост времени проверки. При срабатывании переключитесь на ручной маршрут, сохраните пример сбоя и пересмотрите инструкции. Расширять доступ можно только после повторного прогона на новых данных.
Итоговая оценка
Что сверить перед расширением прав
Составьте короткий отчёт по неделе: число запросов, доля остановок, ручные исправления, стоимость и один пример каждого отказа. Сравните его с тем же процессом без модели. Если экономия появляется только потому, что оператор пропускает проверку, пилот нельзя считать успешным. После смены роли или инструмента прогоните контрольный набор заново и убедитесь, что старые разрешения не сохранились в кэше.
Храните решение о расширении вместе с датой и именем ответственного. При следующем обновлении будет понятно, какие условия изменились и почему доступ можно оставить, сократить или отозвать.
Astra Guarded имеет смысл как помощник, который готовит действие и ждёт разрешения, а не как бесконтрольный исполнитель. Сильная сторона — возможность встроить подтверждения, журнал и белый список в один маршрут. Слабая — зависимость от настройки прав, качества входных данных и дисциплины команды. Наш вердикт: начинать стоит с чтения и черновиков, держать финальное решение у человека и измерять не эффектную демонстрацию, а повторяемый безопасный результат.