ИИ-агенты и персональные данные в России: карта рисков перед запуском

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

Article

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

В законе № 152-ФЗ нет отдельного режима «для нейросетей». К ИИ-сценарию применяются общие требования: определить цель и правовое основание, не собирать данные сверх необходимого, закрепить сроки хранения, принять организационные и технические меры, а при привлечении другого лица оформить отношения по обработке.

Пять зон риска

Контекст запроса. Пользователь может написать только «проверь задолженность», но агент сам добавит к запросу ФИО, телефон и содержание документов из 1С. Оценивать нужно полный текст перед отправкой модели, а не одну фразу в интерфейсе.

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

Модель и её юрисдикция. Российский и иностранный поставщик модели — разные маршруты. Нельзя считать, что единый интерфейс, совместимый с OpenAI API, делает их одинаковыми с точки зрения передачи данных.

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

Журналы. Полный запрос в журнале упрощает диагностику, но создаёт второе хранилище ПДн. Безопаснее фиксировать идентификатор запроса, модель, результат проверки и категории срабатываний без исходных значений.

Как построить первый пилот

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

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

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

Статьи по теме