Карта движения данных для LLM-сервиса в российской компании

Что считать картой движения данных

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

1. какие категории данных передаются;
2. откуда и куда они идут;
3. с какой целью выполняется передача;
4. где обрабатываются и хранятся данные;
5. кто получает технический или административный доступ;
6. как долго сохраняются исходные и производные данные;
7. какими доказательствами подтверждены ответы.

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

Почему одной схемы архитектуры недостаточно

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

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

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

Шаг 1. Задайте границу обследования

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

Создайте паспорт обследования:

Сценарий: ответ на внутренний вопрос сотрудника
Среда: production
Версия приложения: __________________
Дата проверки: ______________________
Владелец процесса: __________________
Технический владелец: _______________
Входы: текст, вложение, идентификатор сотрудника
Выходы: ответ модели, ссылка на документ
За границей проверки: _______________

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

Шаг 2. Проведите инвентаризацию компонентов

Начните с репозитория и развёртывания. Ищите не только название модели, но и библиотеки телеметрии, адреса вебхуков, очереди, объектные хранилища и резервное копирование.

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

rg -n --hidden \
  --glob '!*.key' \
  --glob '!*.pem' \
  --glob '!.env*' \
  --glob '!node_modules/**' \
  --glob '!vendor/**' \
  '(https?://|base_url|endpoint|webhook|telemetry|tracing|logging|sentry|vector|queue|backup)' .

rg -n --hidden \
  --glob '!.env*' \
  --glob '!node_modules/**' \
  --glob '!vendor/**' \
  '(retention|ttl|expire|redact|mask|delete|purge)' .

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

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

Шаг 3. Разделите данные по категориям

Не ставьте одну метку «конфиденциально» на весь поток. Она не показывает, почему передача допустима и какая защита нужна. Практичная начальная классификация выглядит так:

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

Шаг 4. Запишите каждый переход отдельной строкой

Не описывайте цепочку словами «данные передаются провайдеру». Разбейте её на наблюдаемые переходы. Минимальный реестр можно вести в контролируемой таблице:

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

Шаг 5. Отдельно разберите модель, логи и интеграции

Поставщик модели

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

Логи и наблюдаемость

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

Интеграции и инструменты

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

Шаг 6. Введите конфигурацию минимизации

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

llm:
  send_conversation_history: false
  send_user_identifier: false
  allow_training_use: false        # подтвердить договором и настройкой
  request_retention: "verify"

telemetry:
  capture_prompt: false
  capture_completion: false
  capture_tool_arguments: false
  capture_authorization_headers: false
  allowed_attributes:
    - request_id
    - model_alias
    - latency_ms
    - status_code

integrations:
  pass_full_context: false
  require_field_allowlist: true

storage:
  raw_prompt_ttl: "verify"
  trace_ttl: "verify"
  backup_ttl: "verify"

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

Шаг 7. Проверьте карту контрольной трассировкой

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

FLOW_MARKER=ALJ_FLOW_20260729_A
USER_LABEL=SYNTHETIC_USER_001
DOCUMENT_LABEL=SYNTHETIC_DOCUMENT_001

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

rg -n --fixed-strings 'ALJ_FLOW_20260729_A' /var/log/your-service
journalctl --since '30 minutes ago' --no-pager \
  | rg --fixed-strings 'ALJ_FLOW_20260729_A'

Путь /var/log/your-service условный. Не используйте широкие каталоги без необходимости и не сохраняйте полный вывод в неконтролируемом месте. Для внешних систем применяйте штатный поиск в интерфейсе с учётной записью только на чтение.

Проверка должна установить:

1. в каких системах появилась каждая метка;
2. какие поля были добавлены по пути;
3. где обнаружено полное содержимое вместо метаданных;
4. какие системы не удалось проверить самостоятельно;
5. совпадает ли наблюдение с документацией и договорными условиями.

Как проверить результат

Карта готова к согласованию, если для каждого производственного потока выполнены следующие условия:

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

Полезный артефакт проверки — не снимок красивой диаграммы, а реестр потоков с идентификаторами, ссылками на доказательства и журналом изменений. Диаграмму можно строить поверх этого реестра.

Вопросы для юристов

1. Какие сведения в каждом сценарии относятся к персональным данным и есть ли специальные категории или биометрические данные?
2. Кто выступает оператором, а кто обрабатывает данные по поручению?
3. Определены ли цель, состав данных, категории субъектов и правовое основание обработки?
4. Соответствует ли фактический поток уведомлениям, согласиям, локальным актам и пользовательским документам?
5. Какие требования к локализации применимы к первичной записи и дальнейшей обработке?
6. Возникает ли трансграничная передача либо удалённый доступ из другой страны и какие действия требуются до её начала?
7. Достаточно ли договоров с поставщиком модели, провайдером логов и субподрядчиками?
8. Допустимо ли использование переданных данных для улучшения сервиса, обучения или оценки качества поставщиком?
9. Какие сроки хранения и процедуры удаления нужны для основных данных, логов, индексов и резервных копий?
10. Как выполнять запросы субъектов данных и подтверждать удаление у всех получателей?
11. Какие ограничения следуют из режима коммерческой тайны и договоров с клиентами или партнёрами?
12. Нужно ли обновить оценку рисков, уведомления, согласия или внутренние регламенты до запуска?

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

Вопросы для службы безопасности

1. Какие данные запрещено отправлять модели при любых настройках?
2. Где выполняется фильтрация секретов и чувствительных полей — до модели и до телеметрии?
3. Можно ли технически ограничить исходящие соединения утверждёнными адресами?
4. Как разделены production, тестовая среда и аккаунты разных подразделений?
5. Какие роли имеют доступ к промптам, ответам, трассировкам и экспортам?
6. Включены ли многофакторная аутентификация, аудит действий и регулярный пересмотр прав?
7. Шифруются ли данные при передаче и хранении, и кто управляет ключами?
8. Как обнаруживается отправка токена, пароля или закрытого документа?
9. Как отзываются ключи и блокируется интеграция при инциденте?
10. Можно ли независимо подтвердить удаление и отсутствие данных в резервных копиях?
11. Какие изменения конфигурации должны проходить повторное согласование?
12. Кто и как проверяет поставщика и его субподрядчиков?

Типовые ошибки

• Рисовать только основной запрос. Ответ, ошибки, результаты инструментов и резервные копии остаются за пределами карты.
• Верить названию региона. Регион вычислений не обязательно определяет место логов, поддержки и резервирования.
• Считать отсутствие собственного логирования отсутствием логов. Записи могут создавать шлюз, платформа, SDK и поставщик модели.
• Проверять только текст пользователя. Системный промпт и RAG-контекст могут содержать более чувствительные сведения.
• Указывать «не хранится» без доказательства. Временный буфер, журнал защиты или резервная копия тоже являются хранением.
• Собирать карту из реальных секретов. Для трассировки нужны синтетические метки, а не рабочие токены и персональные данные.
• Подменять факт планом. Желаемое ограничение должно быть помечено как задача, пока оно не включено и не проверено.
• Не обновлять карту. Новый SDK наблюдаемости или интеграция способны добавить получателя без изменения пользовательского интерфейса.

Ограничения метода

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

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

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

Итоговый минимальный комплект

После работы у команды должны остаться четыре связанных артефакта:

1. реестр потоков с идентификатором каждой передачи;
2. диаграмма компонентов и границ ответственности;
3. папка доказательств с контролируемым доступом и датами проверки;
4. список нерешённых юридических и технических вопросов с владельцами.

Другие практические материалы собраны в разделе руководств Agent Lab Journal, а определения терминов — в глоссарии.