Локальный контур не заканчивается на модели

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

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

Официальный материал OpenTelemetry от мая 2026 года хорошо показывает границу. Стандартные GenAI-конвенции позволяют записывать модель, длительность, число входных и выходных токенов и причину завершения. Полное содержимое prompts, ответов, системных инструкций, вызовов инструментов и результатов также поддерживается, но включается отдельно. По умолчанию содержимое и аргументы инструментов не фиксируются именно потому, что могут содержать чувствительные данные.

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

Что действительно нужно записывать

Для эксплуатации не обязательно видеть каждое слово разговора. Полезно разделить телеметрию на три класса.

**Операционные метаданные** обычно нужны постоянно:

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

**Связующие идентификаторы** нужны для расследования, но их стоит псевдонимизировать:

  • случайный trace ID вместо ФИО, email или номера договора;
  • стабильный внутренний идентификатор подразделения вместо названия клиента;
  • хеш шаблона запроса или обнаруженного правила вместо полного текста;
  • ссылка на защищённую бизнес-запись вместо копии этой записи в логе.

**Содержимое** — prompts, ответы, RAG-контекст, системные инструкции, аргументы и результаты инструментов — относится к высокорисковому классу. Его следует записывать только для конкретной цели, ограниченной выборки и заранее установленного срока. «На всякий случай» — не цель.

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

Архитектура: фильтр должен стоять до коллектора

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

1. **Шлюз модели** присваивает запросу случайный trace ID и знает контекст операции: поиск по базе, подготовка письма, извлечение реквизитов или вызов инструмента.
2. **Политика телеметрии** решает, какие поля разрешены для этого сценария. По умолчанию проходит только метаинформация.
3. **Фильтр и маскирование** удаляют секреты, персональные идентификаторы, токены доступа и содержимое документов до отправки в коллектор. Маскирование после записи оставляет опасное окно и не очищает уже созданные копии.
4. **Локальный коллектор** принимает стандартизованные события и маршрутизирует разные классы данных в разные хранилища. Для этого не требуется облачный сервис: OpenTelemetry совместим с локальными backend-системами.
5. **Хранилище метрик** держит агрегаты и низкорисковые технические поля дольше. Содержимое отладочных выборок изолируется, шифруется и удаляется быстрее.
6. **Аудит доступа** отдельно фиксирует, кто открыл чувствительную трассу, экспортировал её или изменил срок хранения.

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

Почему маскировки по регулярным выражениям недостаточно

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

Поэтому защита строится слоями:

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

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

Что логировать для расследования инцидента

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

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

Если содержимое всё же необходимо, используйте режим «break glass»: заявка на доступ, ограниченная роль, причина, короткий срок, уведомление и полный аудит просмотра. Отладочная выборка не должна автоматически попадать в обычные резервные копии на годы.

NIST Privacy Framework предлагает смотреть на приватность как на управляемый риск предприятия. Для локального ИИ это означает назначить владельца данных, описать цель обработки, определить минимально достаточные поля, срок и процедуру удаления до включения расширенной телеметрии.

Экономика лишних логов

Безопасность здесь совпадает с экономикой. Полные prompts и ответы имеют высокую кардинальность, плохо агрегируются и раздувают индексы. Их приходится хранить, резервировать, передавать и просматривать.

Пример ниже — модельный расчёт, а не показатель конкретной компании. Допустим, локальный ассистент обрабатывает 20 000 запросов в день, а средний полный пакет «запрос + контекст + ответ + инструменты» занимает 20 КБ. Это около 400 МБ сырых данных в день и 12 ГБ за 30 дней. С учётом индекса, реплики и резервной копии реальный объём может составить 24–60 ГБ.

Если вместо содержимого постоянно хранить около 1 КБ метаданных на запрос, получится 20 МБ в день, или примерно 600 МБ за месяц до накладных расходов. Полные трассы можно оставить для 0,1–1% обезличенной диагностической выборки на 3–7 дней. Точные числа надо измерить на своём стеке, но порядок разницы виден ещё до покупки хранилища.

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

Пилот на пять рабочих дней

**День 1. Инвентаризация.** Возьмите один сервис локального ИИ. Выгрузите схему событий без значений и отметьте, где могут появляться prompts, ответы, системные инструкции, RAG-фрагменты, аргументы инструментов и идентификаторы пользователей.

**День 2. Минимальный профиль.** Оставьте модель, длительность, токены, статус, trace ID и версию политики. Отключите захват содержимого по умолчанию. Проверьте, что по этим данным можно найти медленный вызов, тайм-аут и повтор.

**День 3. Фильтр.** Добавьте белый список полей и маскирование до коллектора. Прогоните тестовый набор с телефонами, email, токенами, реквизитами, договорными условиями и вложенными результатами инструментов.

**День 4. Доступ и срок.** Разделите метрики, аудит действий и диагностическое содержимое. Назначьте владельцев, роли, срок удаления и процедуру временного доступа. Проверьте резервные копии и экспорт.

**День 5. Учение.** Смоделируйте ошибочный ответ и подозрительный вызов инструмента. Команда должна восстановить цепочку по безопасным метаданным. Если без полного текста расследование невозможно, добавьте одно строго ограниченное поле или выборку, а не включайте запись всего потока.

Что взять руководителю

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

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