FTC взялась за автономных агентов: что вы должны уметь про них доказать

Американская FTC начала широкое расследование рисков, связанных с технологиями OpenAI и Anthropic. По сообщениям, регулятора интересуют в том числе случаи, когда автономные ИИ-системы выходили за рамки первоначально поставленной задачи. Речь пока не о запрете технологий. Выясняют другое: достаточно ли существующего законодательства, чтобы спрашивать с компаний за действия автономных систем.

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

Рамка будет спорной, требование к инженерии уже понятно

Юридическая дискуссия займёт годы. Кто отвечает за действие агента: разработчик модели, интегратор, компания-оператор, сотрудник, который поставил задачу. Национальные режимы разойдутся, определения будут переписывать. Всё это шумно и далеко.

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

• Что именно сделал агент. Запись «обратился к системе» здесь ничего не стоит. Нужна конкретная последовательность вызовов: параметры, результаты, время.
• По чьему распоряжению он это сделал. Какая задача, от какого человека или процесса, в рамках какого разрешения.
• В каких границах он действовал. Что ему вообще было доступно в этот момент и где проходила стена, которую он не мог перейти.

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

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

Журнал действий: что именно сделал агент

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

Что в него должно попадать:

• исходная задача и её источник: пользователь, расписание, внешнее событие;
• каждый вызов инструмента: имя, аргументы, к какой системе ушёл, что вернулось;
• решения ветвления: почему агент выбрал этот путь, какие данные были у него на входе;
• версия модели, версия промпта, версия конфигурации прав;
• всё, что агент изменил во внешнем мире, с идентификаторами затронутых записей.

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

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

Права и области видимости: что агенту вообще доступно

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

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

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

Первая: агент работает быстрее человека и успевает использовать избыточное право до того, как кто-то заметит. Вторая: у агента нет интуиции про то, что «вот в эту папку лучше не лезть». Он использует всё, что ему дали, если это помогает решить задачу.

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

Изоляция выполнения: где проходит стена

Журнал фиксирует, права ограничивают, но ни то ни другое не останавливает агента в момент, когда он делает что-то разрушительное. Эту роль берёт на себя изоляция.

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

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

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

Подтверждение человеком на необратимых операциях

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

Критерий простой: можно ли откатить результат за разумное время своими силами. Создать черновик письма обратимо. Отправить письмо клиенту нет. Подготовить платёжное поручение обратимо. Провести платёж нет. Собрать выгрузку обратимо. Передать её наружу нет.

Трудность в том, что подтверждение должно быть осмысленным. Если агент сто раз в день просит нажать «ок», человек нажимает «ок» не глядя, и на сто первый раз подтверждает то, чего не читал. Такой контур существует только на бумаге и в суде работать не будет. Про баланс между полной автономией и ручным управлением у меня есть отдельная заметка о том, почему человек в контуре нужен тем чаще, чем выше риск решения.

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

Российский контекст

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

Для российской компании вопрос стоит даже острее. Если агент работает с персональными данными, ответственность по 152-ФЗ лежит на операторе уже сейчас, и наличие в контуре автономной системы её никуда не переносит. Модель не является субъектом, вендор отвечает перед вами по договору, а перед регулятором и субъектом данных отвечаете вы. Я разбирал это подробно в заметке про ИИ-контур и 152-ФЗ, и появление агентов меняет здесь только масштаб: агент принимает решения о данных быстрее и в большем количестве мест, чем ассистент в чате.

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

С чего начать, пока рамка не оформилась

1. Составьте список агентов, которые уже работают. Включая тех, которых завёл один энтузиаст в отделе. Пока списка нет, разговор про ответственность беспредметный.
2. Для каждого ответьте на три вопроса из начала статьи. Что он сделал вчера, по чьему распоряжению, в каких границах. Там, где ответа нет, у вас пробел в доказуемости.
3. Заведите журнал действий отдельно от логов приложения. Неизменяемый, с идентификаторами затронутых объектов, читаемый посторонним.
4. Выдайте каждому агенту собственную идентичность. Общая сервисная учётка на всех лишает вас возможности разобраться, кто что сделал.
5. Сузьте права до задачи и поставьте срок жизни доступу. Начните с тех агентов, которые дотягиваются до клиентских и финансовых данных.
6. Проведите все обращения во внешний мир через один слой. Это даёт журнал и политику в одном месте.
7. Разметьте операции на обратимые и необратимые и поставьте подтверждение на вторые. Держите количество подтверждений низким, иначе они обесценятся.
8. Зафиксируйте, кто внутри компании отвечает за поведение агента. Это организационное решение, и его придётся принять раньше, чем появится норма.

Честные оговорки

• Содержание расследования мне неизвестно. Публично известно немного, и выводы в этой заметке мои собственные. Я разбираю инженерное следствие из самой постановки вопроса, а не предсказываю исход.
• Это не юридическая консультация. Я описываю, что надо построить в системе, чтобы ответить на вопрос «что сделал агент». Как это ляжет на конкретные нормы и договоры, решают юристы, и привлекать их стоит одновременно с инженерной работой.
• Все четыре элемента стоят денег и замедляют запуск. Это честная цена. Аргумент в пользу того, чтобы заплатить её сразу, простой: пристроить журнал действий и границы прав к работающему агентному контуру дороже, чем заложить их в проект. И в момент, когда они понадобятся, времени на дострой уже не будет.
• Полная доказуемость недостижима. Модель остаётся вероятностной, и объяснить, почему она выбрала именно этот путь, вы не сможете до конца. Доказуемыми становятся действия и границы, а не ход рассуждения, и регулятору в большинстве сценариев нужно именно первое.

Если коротко

• FTC выясняет, хватает ли действующего закона, чтобы спрашивать с компаний за действия автономных систем. Юридическая рамка будет спорной и небыстрой.
• Инженерное требование уже сформулировано: надо уметь доказать, что сделал агент, по чьему распоряжению и в каких границах.
• Четыре элемента перестают быть архитектурным улучшением: журнал действий, права и области видимости, изоляция выполнения, подтверждение человеком на необратимых операциях.
• Встроить их в проект дешевле, чем пристраивать к работающему контуру, и в момент нужды времени на дострой не останется.
• Для российского оператора персональных данных ответственность по 152-ФЗ лежит на нём уже сейчас, и автономность системы её не переносит.

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