AI-агент рвётся к данным: как пройти согласование с DPO

Вы подключаете к рабочим системам не чат-бота, который отвечает на вопросы, а агента — программу, которая сама решает, к какой базе обратиться, какое письмо прочитать и какую запись в CRM изменить. С точки зрения безопасности и приватности это принципиально другой зверь. Классическая интеграция ходит по заранее описанному маршруту. Агент маршрут выбирает сам, и заранее вы не знаете, какие именно персональные данные он затронет в конкретном запуске. Поэтому согласование с DPO — не бюрократическая формальность, а точка, где проект либо получает рамки, либо тихо копит риски.

Ниже — как выстроить разговор с DPO так, чтобы он закончился разрешением, а не бесконечным раундом правок. И что подготовить до того, как вы вообще к нему придёте.

Почему агент — отдельный случай для DPO

Обычный сервис обрабатывает данные по фиксированному сценарию: получил заявку — записал в таблицу — отправил уведомление. DPO может описать этот путь одной строкой в реестре обработки. Агент так не работает.

• Недетерминированный доступ. На один и тот же запрос агент в разных запусках может обратиться к разным источникам. Гарантии «он читает только вот эту таблицу» у вас нет — есть только права доступа, которые вы ему выдали.
• Передача данных наружу. Если рассуждение выполняет облачная модель, содержимое запросов и, возможно, фрагменты данных уходят провайдеру модели. Это трансграничная передача или как минимум привлечение обработчика.
• Логи и промежуточные шаги. Агент оставляет след: промпты, ответы инструментов, цепочки рассуждений. В них оседают те же персональные данные, что и в основных базах, но уже в системе, которую никто не вносил в реестр.
• Автоматизированные решения. Если агент не просто читает, а что-то меняет или отказывает — это уже действие с правовыми последствиями для человека, к которому относятся данные.

DPO смотрит именно на эти четыре вещи. Если вы придёте с ответами на них, разговор будет коротким.

Агенту нельзя выдать «доступ к CRM». Ему выдают доступ к конкретному набору полей конкретных клиентов ради конкретной задачи — и всё, что шире, DPO обязан оспорить.

Что подготовить до встречи

DPO не будет за вас реконструировать, как устроен агент. Чем точнее вы опишете потоки данных, тем быстрее получите ответ. Минимальный пакет:

1. Карта источников. К каким системам агент подключается через инструменты, какие поля читает, какие пишет. Не «база клиентов», а перечень: ФИО, телефон, история заказов, тег сегмента.
2. Цель обработки. Зачем агенту эти данные и почему нельзя обойтись меньшим объёмом. Принцип минимизации DPO проверит первым.
3. Куда уходят данные. Какая модель выполняет рассуждение, где физически размещена, что именно попадает в её контекст. Если модель развёрнута в вашем контуре — это сильный аргумент.
4. Права и роль агента. От чьего имени он действует, какие права ему выданы, может ли он выполнять действия без подтверждения человека.
5. Что пишется в логи. Где хранятся промпты и ответы инструментов, сколько живут, кто имеет к ним доступ, обезличиваются ли они.

Минимизация: главный вопрос DPO

Разработчики по привычке дают агенту широкий доступ «на всякий случай» — так проще, чем перечислять поля. Для DPO это красный флаг. Ответ на вопрос «а зачем ему видеть паспортные данные, если задача — предложить релевантный товар» должен быть готов заранее. Если ответа нет, доступ к полю нужно закрыть до встречи, а не после неё.

Три архитектуры и их приватность

Способ, которым агент получает данные, определяет объём рисков. Вот как это выглядит с точки зрения DPO.

Компромисс, который DPO чаще всего принимает: агент работает с обезличенными данными через RAG, а обратная подстановка реальных ФИО и контактов происходит уже на стороне вашего сервиса, после того как модель вернула результат. Модель видит «клиент №4821», а не Иванова Ивана Ивановича. Так объём ПДн, покидающих контур, стремится к нулю.

Как договориться о рамках

Согласование — это не «да или нет», а набор условий, при которых DPO подписывает. Обычно они сводятся к следующему:

• Whitelist инструментов и полей. Агент может обращаться только к явно разрешённым источникам, всё остальное — недоступно на уровне прав, а не на уровне промпта.
• Человек в контуре для действий. Любое изменение или отправка данных наружу требует подтверждения оператора, пока агент не отработает достаточный срок в наблюдаемом режиме.
• Срок хранения логов. Промпты и ответы инструментов чистятся по расписанию, а не хранятся бессрочно «для отладки».
• Договор с провайдером модели. Если рассуждение выполняет внешний сервис, нужно соглашение об обработке, гарантия неиспользования данных для обучения и понимание, где физически размещены серверы.
• Пересмотр при изменении. Добавили агенту новый инструмент или расширили доступ — согласование повторяется, а не наследуется автоматически.

Кому этот подход нужен, а кому нет

Пригодится, если:

• агент работает с данными клиентов, сотрудников или пациентов — то есть с персональными данными в любом объёме;
• рассуждение выполняет внешняя облачная модель, а не локальная;
• агент имеет право что-то менять или отправлять, а не только читать;
• в компании есть DPO или ответственный за обработку ПДн, и его подпись реально требуется для запуска в прод.

Можно упростить, если:

• агент работает исключительно с обезличенными или синтетическими данными и физически не имеет доступа к ПДн;
• модель развёрнута локально, данные не покидают периметр, а логи не содержат идентификаторов;
• это внутренний прототип на тестовых данных без выхода в прод — но тогда важно не подсунуть ему боевую базу «просто попробовать».

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