Безопасность данных при внедрении ИИ: Архитектура, 152-ФЗ и почему «облако» не панацея

Как реально утекают данные: маркетинг против инженерии

В 2023–2024 годах компании массово подключали публичные API, не читая пользовательские соглашения. К 2026 году рынок повзрослел, но утечки не исчезли. Они изменили форму.

Если вендор говорит «мы не используем ваши данные», уточните, где именно проходит граница. Данные утекают не через «хакерские атаки», а через архитектурные допущения:

• Логирование промптов «для улучшения качества». Многие облачные сервисы сохраняют входящие запросы на 30–90 дней. Если в промпт попал договор, он стал частью логов. Логи часто реплицируются в аналитические хранилища и кэши. Удалить их оттуда по запросу сложно или невозможно.
• Скрытые условия обучения. Галочка «опт-аут» в настройках не означает, что данные не использовались до того, как вы её сняли. Агрегированные паттерны и синтетические данные на основе ваших документов могут попасть в обучающие выборки.
• Side-channel утечки. Метаданные, токены авторизации, структура запросов и время ответов позволяют восстановить контекст без прямого доступа к тексту.
• Prompt-injection и эксфильтрация. Если ИИ имеет доступ к внутренним документам и внешнему интернету, злоумышленник может через инъекцию промпта вытащить фрагменты вашей базы в чат-ответ.

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

On-Premise: архитектура локального контура

Ещё три года назад локальный запуск LLM требовал дата-центров и десятков миллионов рублей. Сегодня это стандарт для B2B. Open-weight модели (14B–32B параметров) работают на одном сервере с GPU или на оптимизированном CPU. Задержка инференса составляет 0.5–3 секунды, что приемлемо для корпоративных задач.

Как устроен изолированный контур:

1. Изоляция сети. Модель разворачивается внутри вашего периметра (bare-metal, VM или изолированный Kubernetes-неймспейс). Внешние API-вызовы запрещены на уровне фаервола и egress-правил.
2. Локальный RAG. Документы индексируются в локальную векторную базу (Qdrant, Milvus, Weaviate). ИИ не «запоминает» данные. Он ищет релевантные фрагменты в вашей базе и цитирует источники.
3. Аудит и контроль. Каждый запрос, ответ, метаданные и действия администраторов пишутся в вашу SIEM. Вы контролируете ротацию ключей, удаление данных и доступы.
4. Обновления без внешних зависимостей. Новые версии моделей и эмбеддингов загружаются оффлайн, проверяются по хеш-суммам и разворачиваются в изолированном контуре. Никаких «облачных патчей» или телеметрии.

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

Гибридные модели: когда внешние API допустимы

Локально нужно не всегда. Если задача не требует работы с персональными или чувствительными данными, внешние API могут быть эффективнее. Ключевое условие — строгая анонимизация на границе периметра.

Правило: Если данные нельзя обезличить без потери смысла задачи — только локальное развёртывание. Никаких «доверенных партнёров», сертификатов ISO или устных гарантий. Технические ограничения сильнее бумажных.

Для гибридных сценариев также внедряется защита от prompt-injection: выходные данные ИИ проверяются на предмет попыток запросить внутренние документы, а доступ к внешним инструментам ограничивается строгими ACL.

152-ФЗ и комплаенс: как встроить в пайплайн

В 2025–2026 годах Роскомнадзор ужесточил требования к автоматизированной обработке. Простого согласия недостаточно. Архитектура должна обеспечивать четыре принципа:

1. Целевое ограничение. Данные используются только для заявленной цели. ИИ не может «исследовать» данные в поисках новых инсайтов. Запрос с неизвестной целью отклоняется шлюзом.
2. Локализация и изоляция. Данные физически хранятся и обрабатываются в РФ. Внешние вызовы запрещены. Трансграничная передача не требуется и не допускается.
3. RBAC и аудит. Бухгалтер видит финансы, технолог — техкарты, ИИ — только разрешённые сегменты. Доступ логируется, права пересматриваются ежеквартально.
4. Удаление и отзыв. При отзыве согласия или завершении договора данные удаляются не только из исходных хранилищ, но и из векторных индексов, кэшей и сессионных логов.

Compliance не «накручивается сверху». Он вшивается в пайплайн обработки: от момента загрузки документа до генерации ответа и очистки сессии.

Кейс: частная клиника (0 утечек, -96% времени анализа)

Задача: Ускорить анализ медкарт и выписок, не нарушая врачебную тайну и 152-ФЗ.

Архитектура:

• Локальный сервер в дата-центре клиники (1× GPU, 96 ГБ RAM).
• Модель: open-weight 14B Instruct (локально, без телеметрии).
• Векторная база: локальный индекс, хранение только обезличенных симптомов и протоколов.
• CRM и медкарты: в защищённом контуре, доступ по ролям.

ИИ не ставит диагнозы. Он структурирует анамнез, выделяет противоречия в назначениях и предлагает врачу проверенные ссылки на протоколы. Врач принимает решение. ИИ экономит время и снижает когнитивную нагрузку.

Чек-лист аудита вендора и «красные флаги»

Прежде чем подписывать договор на пилот или внедрение, задайте эти вопросы. Если ответы уклончивы — не рискуйте.

1. Где физически обрабатываются данные? (Если «в облаке партнёра» — уточняйте, где, кто имеет доступ, как изолируются запросы.)
2. Логируются ли промпты и ответы? На какой срок? Кто имеет доступ?
3. Используются ли данные для дообучения моделей? (Требуйте письменного исключения из пользовательского соглашения.)
4. Как реализуется право на удаление? (Технический пайплайн удаления должен быть описан в договоре.)
5. Есть ли возможность полного оффлайн-развёртывания? (Если нет — это риск для compliance.)
6. Как обеспечивается RBAC и аудит? (Должна быть интеграция с вашей SIEM/Active Directory.)
7. Что происходит при инциденте? (Сроки уведомления, план восстановления, ответственность по договору.)

Красные флаги вендора:

Частые вопросы