LLM Engineering

🛡 Комплаенс, безопасность и AI governance

Properties3
descriptionЧто можно и нельзя делать с данными в AI-проектах — персональные данные (152-ФЗ), on-prem vs cloud, утечки через модель, промпт-инъекции как атака, red team, и как выстроить AI-governance в компании.
tagsai, compliance, security, governance, privacy, 152-fz, risks
aliasesкомплаенс, безопасность, ai-governance, 152-fz, персональные-данные, red-team, on-prem

время чтения ~4 мин.

🛡 Комплаенс, безопасность и AI governance

Технологически систему можно построить за недели. Юридически и репутационно один неверный шаг с данными — и проект закрыт, а компания — в заголовках. Эта статья — про то, где проходят красные линии: какие данные куда можно отправлять, как устроены риски именно AI, и как управлять всем этим на уровне компании (AI governance).

Дисклеймер

Статья носит образовательный характер и не заменяет юридическую консультацию. Конкретные требования зависят от юрисдикции, типа данных и отрасли. По спорным вопросам привлекайте юристов и DPO.

Главное правило: данные решают архитектуру

Ещё до выбора модели (05-vybor-modeli) ответьте на один вопрос: можно ли эти данные вообще отправлять внешнему поставщику LLM?

flowchart TD
    D{"Что в данных?"}
    D -->|"Публичные /<br/>несензитивные"| Cloud["☁ Облачный API<br/>(дешево, просто)"]
    D -->|"Коммерческая тайна,<br/>контракты"| Case1{"Согласовано<br/>политикой?"}
    Case1 -- да --> Cloud
    Case1 -- нет --> Local["🔒 On-prem /<br/>открытая модель"]
    D -->|"Персональные данные"| PD["⚖ Требуется<br/>согласие / 152-ФЗ"]
    D -->|"Гостайна, санкционные<br/>сектора, КИИ"| Strict["🔒 Только<br/>собственный контур"]

Этот фильтр — первый, не последний

Именно отсюда растёт решение «открытая модель в своей инфраструктуре». Если данные нельзя выпускать — выбор закрытых облачных моделей отпадает автоматически, какой бы умной они ни были (04-landshaft-modeley).

Персональные данные (152-ФЗ)

В России обработка персональных данных регулируется 152-ФЗ. Ключевое для AI-проектов:

  • Нужен законный повод и (как правило) согласие субъекта на обработку, особенно если данные уходят за пределы контролируемого контура.
  • Цели обработки должны быть определены; нельзя собирать «на всякий случай».
  • Хранение и трансграничная передача — отдельные требования; отправка ПД в иностранные сервисы часто требует дополнительных оснований.
  • Назначение DPO (лица, ответственного за обработку ПД) и ведение реестра обработки.

Практический ход

Прежде чем подавать в LLM базу с ПД, проведите её через DPO/юр-функцию и зафиксируйте: что именно обрабатывается, на каком основании, где хранится, кому передаётся. Это снимает 90% будущих проблем.

On-prem vs cloud — архитектурное решение

Облако (API закрытой модели)Собственный контур (on-prem)
ДанныеПокидают периметрОстаются внутри
Юридическая простотаСложнее (договор, ПД, трансграничность)Проще с точки зрения данных
ЗатратыOpEx за токеныCapEx на инфраструктуру
Гибкость моделиЛучшие флагманыОткрытые модели, нужны компетенции
КогдаНечувствительные/публичные данныеЧувствительные, КИИ, гостайна, репутационные риски

Типичный enterprise-паттерн

Сегментация по чувствительности: публичные и малочувствительные задачи — в облаке через рублёвый агрегатор; контракты, ПД, коммерческая тайна — на открытой модели внутри контура. Это даёт экономию и контроль одновременно (04-landshaft-modeley, 05-vybor-modeli).

Риски, специфичные для AI

Эти угрозы появляются именно благодаря природе LLM — их нет в классическом ПО:

  • Утечка данных через промпт: вы отправили в облачную модель коммерческую тайну — она может попасть в логи поставщика или, в худшем случае, «всплыть» в чужом ответе.
  • Промпт-инъекция (07-prompt-engineering): вредоносный текст в документе заставляет модель нарушить правила — особенно опасен у агентов с инструментами (11-tools-mcp).
  • Утечка системного промпта: «вытащить» у модели её скрытые инструкции — поэтому в системный промпт нельзя класть секреты.
  • Галлюцинация в регуляторно-значимом ответе (08-gallyutsinatsii-i-nadezhnost).
  • Диффамация / вредный контент: модель генерирует клевету, дискриминационные ответы, нарушает чужие права.

Секреты — не в промпт

Никогда не вкладывайте в промпт пароли, токены, ключи API, персональные данные «для контекста». Всё, что попало в промпт, считается потенциально скомпрометированным. Секреты модель должна получать через инструменты с контролем доступа, а не текстом.

Red team и тестирование безопасности

Red teaming — целенаправленные попытки сломать систему: заставить нарушить правила, выдать скрытое, выполнить опасное действие. Перед запуском в production критичных сценариев red team обязателен. Проверяют:

  • Можно ли через пользовательский ввод заставить модель нарушить правила.
  • Можно ли «договориться» с агентом на опасное действие (11-tools-mcp).
  • Что модель делает на граничных и враждебных входах (08-gallyutsinatsii-i-nadezhnost).

AI governance — управление на уровне компании

AI governance — это набор политик, ролей и процессов, которые делают работу с AI контролируемой и подотчётной. Без него разрозненные «тениевые» AI-инициативы рано или поздно приводят к инциденту.

flowchart TD
    Pol["📋 Политики<br/>(что можно/нельзя с AI)"] & Own["👤 Ответственные<br/>(владельцы рисков)"] & Rev["🔍 Ревью кейсов<br/>(до запуска)"] & Audit["📝 Аудит-след<br/>(логи решений)"] & Train["🎓 Обучение<br/>(команда и юзеры)"]
    Pol & Own & Rev & Audit & Train --> Gov["🛡 AI Governance"]

Минимальный каркас:

  • Политика использования AI: какие данные в какие инструменты можно подавать; что запрещено.
  • Ревью новых кейсов: до запуска — оценка рисков, данных, комплаенса.
  • Ответственность: для каждого AI-сервиса есть владелец и кто отвечает за ошибку.
  • Аудит-след: логирование запросов и решений (особенно автоматических) для расследования инцидентов (14-ocenka-kachestva).
  • Обучение: сотрудники знают, что можно и нельзя, как пользоваться безопасно (13-vnedrenie-i-avtomatizatsiya).

Зрелость комплаенса

Цель — не «запретить всё», а разрешить безопасное. Чёткие политики и зелёный коридор для санкционированных кейсов уменьшают «теневые» (неконтролируемые) использования, которые и есть главный реальный риск.

📌 Что запомнить

  • Данные решают архитектуру: сначала — что можно куда отправлять, потом — модель.
  • 152-ФЗ требует основания, целей и контроля для ПД; тяжёлые случаи — через DPO/юр-функцию.
  • On-prem для чувствительных данных, облако для публичных; часто — сегментация.
  • AI-специфичные риски: утечка через промпт, промпт-инъекция, утечка системного промпта.
  • Секреты не кладут в промпт.
  • Red team обязателен для критичных сценариев.
  • AI governance: политики + ответственные + ревью + аудит + обучение. Цель — разрешить безопасное, а не запретить всё.

Дальше: ⚖ AI в юридической сфере (LegalTech) → — специфика права как домена и реальные сценарии AI в юр-функции.

Вид графа

Обратные ссылки

Недавние заметки