Соответствие требованиям РФ: 152-ФЗ, DPA¶

Эта страница отвечает на типовые вопросы юридических и ИБ-служб российских заказчиков:

где физически обрабатываются промпты и метаданные;
применяется ли 152-ФЗ о персональных данных и не нарушается ли трансграничная передача;
какие документы (DPA) сопровождают развёртывание;
каков статус в реестре отечественного ПО.

Ключевой принцип: выбор сценария за заказчиком¶

Glarus AI — модельно-агностичная платформа (см. "Поддерживаемые LLM-провайдеры"). Именно заказчик решает, какую LLM использовать, и именно выбор провайдера модели определяет юрисдикцию данных и применимость 152-ФЗ.

Три сценария и их последствия по 152-ФЗ:

Сценарий	Юрисдикция данных	Трансграничная передача ПД	Режим работы по 152-ФЗ
A. Локальная LLM (Ollama / совместимый сервер в контуре заказчика)	периметр заказчика	нет	соответствие 152-ФЗ обеспечивается так же, как и для любой on-premise-системы заказчика
B. Российский облачный провайдер (MWS GPT)	РФ (дата-центр провайдера)	нет	152-ФЗ выполняется; провайдер сам является оператором ПД и имеет УЗ-1. Заказчик подписывает DPA с провайдером LLM
C. Иностранный облачный провайдер через прокси (Claude / OpenAI / Gemini)	США / ЕС	да	требуется согласие субъекта ПД в явной форме (ст. 12 152-ФЗ), а также DPA от зарубежного провайдера и уведомление Роскомнадзора

Glarus Digital как поставщик платформы не навязывает сценарий. Для клиентов, работающих с массовыми ПД (госсектор, финансы, медицина, страхование), рекомендуются сценарии A или B. Сценарий C допустим только для данных без ПД (обезличенная агрегация, технические показатели).

Что уходит в LLM при запросе¶

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

Промпт пользователя — текст вопроса. Может содержать ПД, если пользователь их туда включил.
Метаданные схемы — имена таблиц, колонок, типы данных, описания моделей. Обычно ПД не являются, но имена колонок вида passport_number, client_fio раскрывают структуру хранимых ПД.
Фрагменты данных (результаты промежуточных SQL-запросов агента) — могут содержать ПД, если агент вытащил их из таблицы.

В Glarus AI действуют следующие средства контроля:

Права пользователя применяются Glarus BI при режиме MCP per-request: каждый вызов выполняется с сессией конкретного пользователя. Ограничения строк и столбцов зависят от настроенных прав и выбранного инструмента.
Режим «только метаданные» настраивается администратором в MCP-сервере: glarusbi.mcp.dataMode=metadata. Результаты запросов не содержат строки данных; остаются статус, признак наличия строк, имена и типы колонок. Запросы при этом действительно выполняются. Режим не удаляет данные из текста, который пользователь сам отправил модели, и не является настройкой хранения переписки. Для строгого запрета анализа значений администратор ограничивает доступные инструменты выполнения запросов.

Архитектурная схема обработки данных¶

Вся оркестрация, логирование и доступ к источникам данных происходят внутри периметра заказчика. За его пределы уходят только HTTP-запросы к выбранной модели — и только в сценариях B и C. В сценарии A наружу не уходит ничего.

Основные элементы:

Периметр заказчика (on-prem / private cloud): браузер аналитика → Glarus BI (с правами текущего пользователя) → Glarus AI Orchestrator + MCP-клиент → источники данных (ClickHouse, Postgres, …) и MCP-серверы (1С, внутренние API, документация) и MongoDB (журнал сессий и tool calls).
Исходящие вызовы только к выбранной LLM:
сценарий A — LLM развёрнут внутри периметра (Ollama / совместимый сервер), исходящий трафик отсутствует;
сценарий B — HTTPS-запрос к MWS GPT (РФ, УЗ-1);
сценарий C — HTTPS-запрос через российский прокси к иностранному провайдеру (предупреждение: трансграничная передача ПД).

Что логируется и где хранится¶

Glarus AI ведёт подробный журнал сессий в MongoDB, развёрнутой в контуре заказчика:

текст промпта пользователя;
цепочка вызовов MCP-инструментов (какие SQL выполнены, какие таблицы/колонки запрошены);
ответ модели;
временные метки, идентификатор пользователя.

Сроки хранения и удаление переписки определяются настройками развёртывания и процедурами администратора. Фиксированный срок 90 дней и отдельный переключатель полного отключения записи ответов не предусмотрены как гарантированное поведение. Временные диалоги используют срок действия записей и TTL-индексы MongoDB. Режим MCP dataMode=metadata ограничивает ответы инструментов, а не отключает сохранение промптов и ответов чата.

Независимо от настроек ретеншна, MongoDB Glarus AI развёрнут в контуре заказчика, никакие данные в Glarus Digital (вендора) не отправляются.

DPA провайдера LLM¶

Для сценария B пример DPA и аттестата — у MWS GPT: инфраструктура развёрнута в аттестованном сегменте 152-ФЗ, УЗ-1 — см. mws.ru/services/iaas-152-fz/.

Для других российских провайдеров DPA и условия обработки данных запрашиваются у выбранного провайдера в составе условий предоставления услуги.

Для сценария C DPA запрашивается у провайдера-оригинала (Anthropic / OpenAI / Google) — это отдельный документ от DPA с поставщиком прокси и от DPA с Glarus Digital.

Реестр отечественного ПО¶

Glarus AI — штатный компонент Glarus BI и покрывается единой реестровой записью Glarus BI в реестре российских программ для ЭВМ. Дополнительная реестровая запись на AI-модуль не требуется.

Внешний LLM-провайдер — отдельный элемент архитектуры; если требуется «российский LLM по реестру», подходит MWS GPT — входит в реестр Минцифры.

Реестровый номер Glarus BI — см. главную страницу glarus-bi.ru.

Чек-лист для внедрения с ПД¶

Определите, содержат ли ваши аналитические данные ПД (фамилии, паспорта, телефоны, e-mail, адреса).
Если да — выберите сценарий A (локальная LLM) или B (российский провайдер).
Подпишите DPA с провайдером LLM.
Проверьте права пользователя, перечень доступных MCP-инструментов, выбранный режим данных и фактическое содержимое запросов, ответов и журналов на тестовых данных.