← Visi straipsniai
Tinklaraštis

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

Команда AiHummer6 min. skaitymo
Русский
Straipsnio „Приватность ИИ-системы: вместо лозунга нарисуйте потоки данных“ viršelis

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. Актуальность возможностей и их тарифные условия нужно перепроверять перед внедрением.

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

Naujų straipsnių prenumerata

Gaukite naujus AiHummer straipsnius el. paštu.

Komentarai

Įkeliami komentarai…

Nemokamas startas

Išbandykite AiHummer

Paleiskite DI darbuotojus debesyje arba savo įrangoje — Community planas nemokamas.