Где проходят данные¶

Что вы узнаете¶

После этой страницы вы сможете по конкретному запросу ответить на пять вопросов:

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

Главный принцип¶

У одного разговора может быть несколько независимых границ данных.

локальная модель
+ корпоративный документ
+ интернет-поиск

означает, что модель работает локально, но поиск всё равно требует сетевого взаимодействия с внешними ресурсами.

Карта основных потоков¶

Сценарий	Где лежат рабочие данные	Внешняя граница
Чат с локальной моделью	сервер Студии	не требуется
Чат с Yandex AI	сервер + Yandex AI Studio	да
Локальная модель + интернет-поиск	сервер + внешние сайты	да, поиск
Локальная модель + RAG	сервер + локальный индекс	не требуется
Yandex AI + RAG	сервер + индекс + Yandex AI	найденные фрагменты могут передаваться
Инфраструктура Яндекс Облака	сервер + API Яндекс Облака	да
FinOps	сервер + Billing API	да
Общая ссылка	сервер + получатель	да, доступ получателя
Временный разговор	сервер в пределах срока хранения	зависит от модели и сервисов

1. Обычный чат с локальной моделью¶

браузер пользователя
        ↓ HTTPS
ИИ Студия
        ↓
локальная среда модели
        ↓
ИИ Студия
        ↓ HTTPS
браузер пользователя

В обработке могут участвовать:

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

Если внешние функции выключены, перечисленные данные могут оставаться в локальном серверном контуре.

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

2. Чат с Yandex AI¶

браузер
   ↓
ИИ Студия
   ↓
серверный шлюз НайсСофт
   ↓
Yandex AI Studio
   ↓
шлюз
   ↓
ИИ Студия

На сервере остаются авторизованный ключ, закрытая часть ключа и механизм получения IAM-токена.

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

закрытая часть авторизованного ключа;
IAM-токен служебной учётной записи.

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

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

3. Файл «целиком»¶

файл
  ↓
локальное извлечение текста
  ↓
контекст разговора
  ↓
активная модель

Ключевой вопрос безопасности находится на последнем шаге.

Если активна локальная модель, извлечённый текст может обрабатываться локально.

Если активна Yandex AI, часть текста, попавшая в контекст, передаётся облачной модели.

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

4. Поиск по документам¶

документ
  ↓
извлечение текста
  ↓
разбиение на фрагменты
  ↓
векторное представление
  ↓
локальная векторная база
  ↓
запрос пользователя
  ↓
поиск релевантных фрагментов
  ↓
активная модель

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

Неверно:

«Файл хранится локально, значит Yandex AI никогда не увидит сведения из него».

Правильно:

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

5. Интернет-поиск¶

запрос
  ↓
ИИ Студия
  ↓
локальный поисковый агрегатор
  ↓
внешние поисковые источники
  ↓
защитный получатель страниц
  ↓
извлечённый текст
  ↓
активная модель

Интернет-поиск является внешним сетевым взаимодействием независимо от модели.

Не отправляйте в поиск секрет¶

Плохо:

Найди причину ошибки для токена eyJ...

Правильнее:

Найди причины HTTP 401 при обмене авторизованного ключа на IAM-токен.
Секретные значения не используй.

Защитный получатель страниц должен блокировать loopback, частные сети, link-local и служебные адреса облачной среды.

6. Инфраструктура Яндекс Облака¶

запрос пользователя
   ↓
ИИ Студия
   ↓
шлюз Яндекс Облака
   ↓
IAM
   ↓
разрешённый API
   ↓
ответ API
   ↓
активная модель

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

Если полученные сведения анализирует Yandex AI, информация об инфраструктуре становится частью облачного модельного контекста. Если анализ выполняет локальная модель, она может оставаться локально.

7. FinOps и Billing¶

Расходы могут раскрывать масштаб инфраструктуры, названия проектов, изменения нагрузки и структуру сервисов. Поэтому доступ к Billing должен быть отдельным.

Billing API
    ↓
серверный финансовый слой
    ↓
агрегаты / детализация по запросу
    ↓
активная модель

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

Подробнее: FinOps.

8. Память¶

сообщение
  ↓
решение о запоминании
  ↓
структурированная запись памяти
  ↓
будущий разговор

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

9. Общие ссылки¶

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

Ссылка имеет собственный жизненный цикл:

создание → использование → ревизия → отзыв

Управляйте самой ссылкой, а не рассчитывайте только на редактирование исходного разговора.

10. Плановые задания¶

Перед созданием расписания проверьте:

какая модель будет использоваться;
какие сервисы доступны помощнику;
какие данные входят в запрос;
куда сохраняется результат;
может ли операция требовать подтверждения;
создаёт ли она облачные расходы.

Плановое выполнение не должно обходить серверные запреты.

11. Журналы¶

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

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

12. Резервная копия¶

рабочие данные
+ конфигурация
+ файлы
+ базы данных
+ возможно секреты
        ↓
резервная копия

Защита резервной копии должна быть не слабее защиты рабочего сервера.

Пять вопросов перед чувствительным запросом¶

1. Какие данные я использую?¶

общедоступные;
внутренние;
коммерчески чувствительные;
персональные;
секреты аутентификации.

2. Какая модель активна?¶

локальная;
Yandex AI;
внешняя модель организации.

3. Какие дополнительные функции включены?¶

интернет-поиск;
поиск по файлам;
сервис Яндекс Облака;
корпоративный сервис;
память.

4. Кто увидит результат?¶

только автор;
получившие доступ к помощнику;
получатели общей ссылки;
администраторы в пределах своих полномочий.

5. Сколько времени данные должны существовать?¶

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

Карточка потока данных¶

Название процесса:
Владелец:
Категория данных:
Источник:
Где хранится:
Активная модель:
Внешние сервисы:
Кому доступно:
Срок хранения:
Резервное копирование:
Правовое основание, если есть персональные данные:
Меры защиты:
Дата последней проверки:

Контрольная проверка установки¶

Создайте тестового USER.
Проверьте локальный разговор.
Проверьте Yandex AI на нейтральных данных.
Проверьте поиск без секретов.
Проверьте RAG на тестовом документе.
Проверьте отказ веб-получателя для внутреннего адреса.
Убедитесь, что USER не открывает административную панель.
Создайте общую ссылку на тестовый чат.
Отзовите её и подтвердите потерю доступа.
Проверьте резервное копирование и восстановление на отдельном стенде.

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