Агент прочитал письмо клиента, вытащил из него персональные данные, сложил в векторное хранилище и записал в память «клиент склонен к скидкам». Спустя полгода приходит запрос на удаление по статье 17. В вашей карте данных — CRM и почта, их вы чистите. Память агента, эмбеддинги и логи вызовов в карте нет, и стереть оттуда запись никто не умеет. Ровно это ранние обзоры регуляторов называют главным риском агентного ИИ: не агенты как класс, а непрозрачные многоагентные потоки данных, которые никто не задокументировал.
Почему агент ломает привычную карту данных
Классическая карта данных — системы-источники и системы-приёмники. Агент добавляет третий тип: производные хранилища, о которых знает один инженер. Персональные данные копятся минимум в четырёх местах: контекст запроса, долговременная память, векторное хранилище и логи с полными текстами вызовов. Каждое из них — обработка по GDPR со всеми обязанностями, но каждое живёт своей жизнью: у памяти свой TTL, у эмбеддингов своя база, у логов свой ретеншн. Пока у этих мест нет владельца и описания, любая обязанность GDPR исполняется «где-то приблизительно».
Основание и минимизация: на входе, а не на бумаге
Статья 6 требует правового основания для каждой категории персональных данных, которые агент обрабатывает. На практике это значит: до того как агент получил данные, должно быть понятно, на каком основании и зачем. Отсюда рабочее правило агентного контура — минимизация исполняется в момент сборки контекста. Что агент не получил, то он не может утечь, запомнить или воспроизвести. Минимизация «на бумаге» — политика без фильтра — не работает: агент по определению тянет больше контекста, чем нужно для ответа, если его никто не ограничил на входе.
Оценка воздействия (DPIA) для агента
Статья 35 требует оценку воздействия там, где обработка носит систематический характер, включает профилирование или значимые решения. Агент, который классифицирует тикеты, сегментирует клиентов или решает, кому отказать в доступе, попадает под это почти всегда. DPIA для агента — не формальность: она фиксирует, какие данные агент видит, какие решения принимает, кто их проверяет и что происходит при ошибке. Если описать это некому — это и есть первый сигнал, что агент в проде лишний.
Право на удаление, которое доходит до памяти
Право на удаление по статье 17 у агентного контура упирается в производные хранилища. Работоспособная схема: стирание — операция над всеми местами, где данные могли осесть (контекст, память, эмбеддинги, логи), а не только над источником. Для этого нужны метки происхождения у каждой записи памяти («пришло из письма X клиента Y») и запускаемый каскад удаления. Если память изолирована по тенантам и у записей есть TTL, запрос на удаление — одна операция; если память — общая свалка, это forensic-экспедиция с неопределённым результатом.
Автоматизированные решения: статья 22
Статья 22(1) даёт право не быть объектом решения, основанного исключительно на автоматизированной обработке и производящего правовые или схожие значимые эффекты. Агент, который единолично закрывает заявку с компенсацией или меняет уровень доступа, — потенциальный кандидат. Практический вывод: для решений с такими эффектами нужен человек в цикле, а для остальных — трасса решения: что агент видел, на что опирался, кто это одобрил. Та же трасса закрывает и DPIA, и разбор инцидентов.
Обработчики и DPA
Агент почти всегда ходит через третьи стороны: провайдера модели, MCP-серверы, SaaS-инструменты. Статья 28 требует договора обработки с каждым из них. Проверьте по своему списку: у провайдера модели DPA есть почти наверняка, у самописного внутреннего MCP-сервера — нет, и именно через него могут ходить персональные данные. Список обработчиков агента должен существовать явно, а не восстанавливаться по логам после запроса регулятора.
Где Codenik
Codenik закрывает агентную часть этих обязанностей на уровне архитектуры: минимизация применяется до сборки контекста, каждая запись памяти несёт метку происхождения и тенанта, стирание — каскадная операция по контексту, памяти и логам, а каждый вызов фиксируется в трассе решения с указанием инструмента и одобрения. Вместо «мы договорились не скармливать агенту персональные данные» — фильтр на входе и операция удаления, которая доходит до конца.
Короткий вывод
GDPR для агентов — не новый закон, а те же обязанности, применённые к новым местам: основание на входе, минимизация при сборке контекста, DPIA на решения, стирание до памяти и эмбеддингов, человек в цикле для значимых решений и DPA с каждым обработчиком. Проверьте свой агентный контур по этим шести пунктам — там, где пункт не исполняется архитектурой, он не исполняется вообще.