Безопасность данных при автоматизации: доступы, хранение и права агента

Что значит безопасность данных при автоматизации

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

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

Какие данные проходят через ИИ-агента

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

• Персональные данные: имена, телефоны, адреса, переписка — то, что регулирует 152-ФЗ.
• Коммерческая тайна: цены, условия сделок, коммерческие предложения, списки клиентов и поставщиков.
• Служебная информация: регламенты, внутренние поручения, статусы задач и промежуточные материалы.
• Технические данные: логи, идентификаторы, метаданные сообщений — по отдельности безобидные, но в связке позволяющие восстановить полную картину переписки.

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

Что требует 152-ФЗ при автоматизации

Закон о персональных данных не запрещает использование ИИ. Оператором персональных данных остаётся компания: она определяет цели обработки, отвечает за их законность и за соблюдение прав субъекта. Автоматизация здесь — это способ обработки, а не способ обойти требования закона, и относиться к ней нужно так же, как к любой другой обработке.

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

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

Доступы: минимальные права вместо «админ для всех»

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

Отдельный пункт — права агента. Если агент может прочитать почту, это не значит, что он должен уметь удалять письма, менять реквизиты или рассылать коммерческие предложения. Полномочия выдаются под конкретный сценарий, а не «раз уж подключились к почте, дадим всё сразу».

Где хранятся данные: контур, облако, внешние модели

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

Универсального «правильного» варианта нет: всё определяется тем, какие данные проходят через агента. Если это внутренние регламенты и статусы задач, требования мягче. Если персональные данные клиентов и коммерческая тайна — выбор размещения становится первым вопросом проекта, а не последним пунктом в чек-листе. Если используется внешний провайдер, полезно читать не общую политику, а раздел про корпоративные данные: вендоры отдельно описывают, кому принадлежат входные и выходные данные и используются ли они для обучения моделей. Например, OpenAI в разделе Enterprise privacy заявляет о владении и контроле над бизнес-данными пользователей — именно такое заявление стоит найти и зафиксировать в решениях проекта, а не полагаться на пересказ.

Права агента: что он делает сам, а что согласует

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

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

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

Промпт-инъекции и утечки через контекст

У ИИ-агентов есть риски, которых не было у обычных интеграций. Главный — промпт-инъекция: во входных данных, будь то письмо, документ или сообщение, может оказаться текст, который попытается отменить инструкции агента или заставить его сделать лишнее. Агент читает эти данные как часть задачи, поэтому защита строится не на «умных» моделях, а на ограничениях прав и объёма контекста. Перечень типовых рисков LLM-приложений собран в проекте OWASP Top 10 for LLM Applications: среди них промпт-инъекции, раскрытие чувствительной информации и избыточные полномочия агента. Все три лечатся не одной настройкой, а сочетанием минимизации контекста, узких прав и ограниченного набора разрешённых действий.

• Не смешивать инструкции и данные: то, что пришло извне, — это содержимое, а не команда для агента.
• Не давать лишних прав: утечка опасна ровно настолько, насколько широк доступ агента к системам.
• Проверять входные документы: не каждое вложение стоит целиком передавать модели в контекст.
• Ограничивать исходящие действия: агент без права отправки не сможет вынести данные наружу.
• Логировать обращения к данным: если видно, что и когда читалось, инцидент разбирается быстрее.

Журнал действий и разбор инцидентов

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

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

Чек-лист перед запуском

1. Список данных, которые проходят через агента, с пометкой «персональные / коммерческая тайна».
2. Цели обработки под каждую задачу и основания для данных клиентов.
3. Реестр доступов: кто и к чему имеет право, включая учётные записи агента.
4. Узкие права под каждый сценарий вместо единой учётной записи на всё.
5. Решение о размещении данных: свой контур, российское облако или внешний сервис.
6. Проверенные условия вендора: что происходит с данными и используются ли они для обучения.
7. Список действий, которые агент выполняет только с согласованием, и явных запретов.
8. Журнал действий с понятным сроком и правилами хранения.
9. Порядок разбора инцидента: кто замечает, кто реагирует, где фиксируется вывод.
10. Периодическая ревизия прав: при смене роли, увольнении и окончании проекта.

Список выглядит длинным, но большая часть пунктов — это решения, а не работы. Их можно принять на одной встрече до старта проекта, и дальше они не требуют постоянного внимания: правила просто соблюдаются, а права пересматриваются по событию.

Частые ошибки

• Выдавать агенту широкие права «чтобы не мешало» и не пересматривать их.
• Считать, что безопасность — задача подрядчика, а не владельца процесса и данных.
• Отправлять во внешнюю модель весь документ, когда для ответа нужен один фрагмент.
• Заводить журнал «для галочки», из которого нельзя понять, что произошло.
• Откладывать вопросы хранения и доступов до момента, когда агент уже работает с реальными данными.

Безопасность не мешает автоматизации, если решения приняты до запуска. Большинство проблем возникает не потому, что что-то технически невозможно, а потому, что вопрос не задали вовремя — и потом отвечать на него приходится уже в режиме разбора инцидента.

Как внедрять безопасно: порядок шагов

1. Шаг 1. Перечислить данные, которые проходят через агента, и выделить персональные.
2. Шаг 2. Выбрать вариант размещения и проверить условия вендора по данным.
3. Шаг 3. Выдать минимальные права сотрудникам и отдельные — агенту.
4. Шаг 4. Определить уровни автономии: что автоматически, что только через согласование.
5. Шаг 5. Включить журнал действий и порядок разбора инцидентов.
6. Шаг 6. Провести ревизию прав и обновить документы по обработке данных.

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