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

Self-hosted отвечает на важный вопрос: где запущен инстанс и где хранится его основное содержимое. Но для оценки приватности этого мало. Текст может уйти выбранной модели, поля операции — интеграции, технические сведения — лицензионному или сервису наблюдаемости, а копия данных — в резервное хранилище. Пока эти стрелки не нарисованы, утверждение «всё у нас» остаётся непроверяемым.

Официальная страница тарифов AiHummer формулирует границу честно: в self-hosted-режиме содержимое инстанса хранится на инфраструктуре пользователя; данные, необходимые внешним моделям, интеграциям и лицензионному сервису, передаются в зависимости от конфигурации. Соответствие 152‑ФЗ требует отдельной организационной и юридической проверки.

Инвентаризация входов

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

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

Поток к модели

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

Для каждого провайдера запишите endpoint, регион, договор, retention, возможность обучения на данных, шифрование и порядок удаления. Отметьте fallback: если локальная модель недоступна, система не должна незаметно отправить чувствительный запрос наружу, если политика этого не разрешает.

Поток к инструментам

Агент может вызвать CRM, почту, календарь или HTTP API. Инструмент получает параметры действия, а результат возвращается в ход. Сокращайте payload до необходимых полей. Scoped-учётные данные и минимальные права уменьшают ущерб ошибки.

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

Знания, память и области

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

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

Технические сервисы и телеметрия

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

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

Резервные копии

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

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

Контроли, которые решают разные задачи

Vault защищает учётные данные. RBAC и scoped-ключи ограничивают действия пользователей и автоматизации. RLS разделяет строки рабочих пространств при корректной конфигурации. IP-allowlist ограничивает источник административного доступа. Air-gapped-режим блокирует управляемый моделью публичный egress, но отключает инструменты, которым нужен интернет. Аудит помогает расследовать события.

Ни один контроль не заменяет остальные. Кроме того, часть возможностей зависит от тарифа и настройки. Перед заявлением о защите подтвердите, что контроль включён, протестирован и покрывает конкретный поток.

Упражнение на 30 минут

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

Затем для каждой стрелки ответьте:

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

Неразмеченная стрелка становится задачей, а не маркетинговым допущением.

Честные формулировки

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

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

Повторяйте privacy-review

Карта потоков устаревает при каждом новом инструменте, модели или канале. Включите её обновление в change-management: автор изменения перечисляет новые категории данных, получателей, секреты, retention и способ отключения. Без заполненной строки изменение не получает production-доступ. Это соединяет архитектурную схему с реальной конфигурацией.

Раз в квартал сравнивайте документ с фактами: списком endpoint, настройками egress, активными OAuth-подключениями, журналами и политиками резервного копирования. Отзывайте неиспользуемые доступы и проверяйте удаление тестовой записи по всей цепочке. Инцидент или смена условий провайдера запускают внеплановый обзор. Цель не в том, чтобы однажды поставить отметку, а в том, чтобы обнаруживать расхождение между заявленным потоком и фактическим до того, как оно станет проблемой. Результаты обзора храните рядом с конфигурацией и датой проверки. Формулировка для пользователей должна соответствовать фактическому маршруту сегодня, а не плану внедрения или возможностям, которые ещё не включены.

Источники и границы

См. тарифы и FAQ о данных, сетевые контроли и air-gapped, guardrails и RBAC. Актуальность возможностей и их тарифные условия нужно перепроверять перед внедрением.

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