Валидация и релиз кастомных языковых моделей в регулируемых областях

Заметки из цикла релиза — Часть IV

Главный юрисконсульт заходит на инженерный ревью. У неё один вопрос: «Если завтра поступит запрос по EU AI Act Статья 17 о праве на удаление с требованием убрать каждый факт, который наша модель узнала о конкретном пациенте, сможем ли мы доказать, что мы это сделали?»

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

Это не ответ комплаенса. Это не-ответ с процедурным пожатием плеч.

Этот пост — о том, как выглядит настоящий ответ комплаенса для кастомных LLM — по четырём регуляторным фреймворкам (EU AI Act, GDPR Статья 17, HIPAA, NIST AI RMF), сопоставленным с четырёхстадийным пайплайном (Register → Gate → Roll → Observe), который мы выпускаем для клиентских релизов. Сквозное напряжение во всех запросах регуляторов — это open-weights против closed-API: то, что вы можете доказать о дообучении Gemma 4, — это не то же самое, что вы можете доказать о релизе, обслуживаемом за непрозрачным API вендора. Формат квитанции, который мы используем, говорит об этом явно, построчно. Именно эта честность делает квитанцию полезной для аудитора.

Четыре регулятора и что каждый из них на самом деле хочет

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

Цифры штрафов — это не то, что делает эти фреймворки интересными. Цифры штрафов — это то, что делает их несущими. Интересная часть — это примитив верификации: то, как именно каждый фреймворк хочет, чтобы выглядел артефакт. Три из четырёх требуют криптографического уровня доказательства в разных формулировках. Четвёртый (NIST AI RMF) добровольный, но де-факто обязательный в корпоративных закупках. Все они сходятся к одной и той же форме: артефакту, который аудитор может верифицировать, не доверяя вашим логам.

Разделение: open-weights против closed-API

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

Для бэкендов с открытыми весами (open-weights) — Gemma, Qwen, Llama, Mistral, GPT-OSS, всё, где веса адресуемы и редактируемы — каждое решение о релизе Divinci эмитирует квитанцию vindex, включающую weight-attestation: криптографическое доказательство того, что активные веса на момент решения точно совпадают с весами, зарегистрированными в манифесте. Именно это делает возможным верифицируемое удаление по GDPR Статья 17. Вы применяете DELETE-патч, который удаляет конкретную сущность-отношение из пространства весов, квитанция встраивает хеш до и после, и аудитор может верифицировать, что удаление произошло, повторно прогнав верификацию по публичному vindex.

Для бэкендов с закрытыми API (closed-API) — OpenAI, Anthropic, Google через непрозрачные API — та же квитанция покрывает цепочку решений (какой манифест, какой результат гейта, какие показания монитора, какой пользователь инициировал какое действие), но не может претендовать на provenance весов, потому что провайдер не раскрывает веса. Квитанция явно отмечает это в поле weight_attestation: null с note, объясняющим причину. Это не ухудшенная позиция комплаенса — это предел того, что верифицируемо, честно записанный. Аудитор, читающий квитанцию, понимает ровно, какой класс доказательства предъявляется и какой нет.

Это разделение проходит через каждый запрос регулятора ниже. Всякий раз, когда фреймворк требует чего-то на уровне весов, open-weights-путь может это удовлетворить, а closed-API-путь — нет. Мы пишем об этом в квитанции, а не подразумеваем доказательство, которое не можем предоставить.

Как каждый фреймворк сопоставляется с четырьмя стадиями пайплайна

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

Две ячейки ◐ — это записи GDPR Статья 17 / только open-weights — это те запросы, которые closed-API-путь не может полностью удовлетворить. Всё остальное применимо к обоим бэкендам.

Остальная часть поста проходит по вкладу каждой стадии.

Стадия ① — Register

Стадия Register производит неизменяемый JSON-манифест, адресуемый по SHA-256. Для регулируемых релизов манифест несёт всё, что просит Приложение IV^[1], в одном артефакте:

• Артефакт модели (HF-репозиторий + SHA коммита или ссылка на vindex-патч)
• Шаблон промпта (каждая переменная, каждое системное сообщение — под версионным контролем)
• Правила маршрутизации (какой класс трафика попадает на какой релиз)
• Версия датасета, использованная для расчёта порогов гейта (сводка обучающих данных по хешу)
• SHA предыдущего релиза (чтобы цепочка аудита была неразрывной)
• Объём раскрытия — для HIPAA-развертываний, какие категории PHI модели разрешено получать

Манифест — это и есть документация. Аудитор не читает прозу; он читает хеш манифеста и верифицирует бандл. Никакого резюме в прозе, написанного шесть месяцев спустя, не требуется.

Бонус для open-weights. Когда артефакт модели ссылается на модель с открытыми весами, манифест также встраивает vindex_sha256 — криптографический отпечаток опубликованного vindex модели. Этот отпечаток позволяет третьей стороне верифицировать активные веса, не доверяя нашей инфраструктуре развертывания.

Оговорка для closed-API. Когда артефакт модели ссылается на closed-API-модель, поле vindex_sha256 манифеста равно null, а weight_attestation_class манифеста — decision_chain_only. Аудитор, читающий это, точно знает, что заявлено, а что нет.

Стадия ② — Gate

Стадия Gate — это место, где «меры человеческого надзора»^[1] EU AI Act операционализируются. Регулятор, который читает EU AI Act и заключает «нам нужен воркфлоу человеческого одобрения», упустил суть — более сложный запрос против чего именно человек одобряет. Стадия Gate отвечает на этот вопрос посрезовым Spearman ρ против оценщика, привязанного к человеку^[3]. Каждый срез, имеющий значение для вашей регуляторной позиции (детская онкология, лицензирование IP, бельгийский французский), получает свой собственный порог. Путь override требует письменного обоснования, которое попадает в аудиторский след.

Для HIPAA-развертываний это также место, где живёт правило раскрытия «minimum-necessary». Scored-QA-набор гейта включает негативные тесты на чрезмерное раскрытие PHI — ответы, содержащие персональные идентификаторы, когда о них не спрашивали. Релиз, который регрессирует на срезе чрезмерного раскрытия, проваливает гейт, независимо от того, как ведут себя его другие срезы.

Для NIST AI RMF стадия Gate покрывает функцию «measure» — посрезовое численное доказательство того, что система работает в пределах настроенных допусков.

Стадия ③ — Roll

Постмаркет-мониторинг EU AI Act^[1] требует от оператора демонстрировать постоянное — а не только предзапусковое — наблюдение за тем, как ИИ-система работает в реальных условиях. Канареечный раскат 5% → 25% → 100% с контрольными точками мониторинга качества — самый естественный способ удовлетворить это требование. Выдержка в каждой контрольной точке плюс показания монитора во время выдержки — это то, что аудитор хочет видеть.

Для HIPAA канареечная стадия — это также место, где end-to-end отрабатывается журналирование аудита на каждый запрос. Каждая контрольная точка производит выборку подписанных квитанций запрос-ответ; если в какой-то из них есть неправильно сконфигурированная обработка PHI, это всплывает на 5% трафика, а не на 100%.

Стадия ④ — Observe

Это стадия, которая зарабатывает историю комплаенса. Стадия Observe прогоняет непрерывное воспроизведение трасс через активный релиз, оцениваемое тем же привязанным к человеку судьёй из Gate, с монитором качества, который запускает автоматический откат при пробое.

Каждое решение о релизе — register, gate-pass, gate-fail, gate-override, checkpoint-promote, checkpoint-hold, auto-rollback, manual-rollback, и любое применение DELETE-патча по GDPR Статья 17 — эмитирует квитанцию vindex. Хеш-цепочка к предыдущей квитанции для этого клиента и предыдущей квитанции для этого релиза.

Вот как выглядит настоящая квитанция для DELETE-патча по GDPR Статья 17 — адаптирована напрямую из формата, задокументированного на странице комплаенса:

{
  "name": "gdpr-art17-patient-12348-removal",
  "version": 1,
  "base_model": "google/gemma-4-E2B-it",
  "manifest_sha256": "9abaeaf6c91f8b...",
  "previous_manifest_sha256": "8f72b1de4a93c5...",
  "created_at": "2026-05-29T03:17:42Z",
  "user_id": "compliance-officer-7c4e1a",
  "operation": {
    "op": "delete",
    "entity": "patient-record-12348",
    "relation": "diagnosis-association",
    "target": "weight-feature-11179-layer-27",
    "weight": -1.0
  },
  "verification": {
    "before_feature_11179_score": 17.34,
    "before_feature_11179_rank": 1,
    "after_feature_11179_score": null,
    "after_feature_11179_rank": "ABSENT_FROM_TOP_25",
    "perplexity_delta_wikitext103": "+0.02%",
    "vindex_sha256_before": "abc12...",
    "vindex_sha256_after":  "def34..."
  },
  "weight_attestation_class": "full",
  "chain_signature": "sha256(manifest || prev_manifest || user_id || created_at || prev_chain_signature)"
}

Этот артефакт верифицируем. Аудитору не нужно доверять нашим логам. Он берёт vindex_sha256_after, подтягивает соответствующий опубликованный vindex с huggingface.co/Divinci-AI и верифицирует, что фича 11179 в слое 27 структурно отсутствует в top-25. Он берёт chain_signature и верифицирует её против предыдущей квитанции. Вся цепочка якорится внешне по расписанию, которое клиент настраивает.

Та же операция против closed-API-модели. Поля квитанции выше меняются тремя способами: operation.target становится provider_api_endpoint, verification становится другой схемой, покрывающей только доказательства цепочки решений, а weight_attestation_class становится decision_chain_only. Провайдер closed-API-модели не раскрыл веса, поэтому квитанция говорит об этом. Аудитор, желающий доказательства на уровне весов, теперь знает, что ему нужно эскалировать к провайдеру, а не к нам.

Это дифференциация, которой никто другой в 2026 году не выпускает. Лагерь eval-CI (Braintrust, Humanloop, Patronus) не сидит на трафике и не эмитирует квитанции решений. Лагерь serving-canary (SageMaker Deployment Guardrails^[2], KServe, Vertex, BentoCloud, Seldon) эмитирует логи инфраструктурных метрик, но не криптографически связанные квитанции комплаенса. Лагерь observability (Arize, Phoenix, Confident, Deepchecks) наблюдает выход, но не обеспечивает контроль.

Что аудитор на самом деле верифицирует?

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

Чего аудитору не нужно делать: доверять нашему Datadog. Доверять нашему CloudWatch. Доверять скриншоту. Доверять экспорту. Вся суть формата квитанции в том, что аудитор может верифицировать её независимо.

Чего это не решает

Три честных ограничения:

Регрессии closed-API в зоне GDPR Статья 17 нерешаемы на уровне платформы. Если вы обслуживаете медицинского ассистента за closed-API-моделью и пациент инициирует Статью 17, платформа может удостоверить, что запись пациента была удалена из вашего хранилища поиска, вашего шаблона промпта и ваших правил маршрутизации, — но не может удостоверить, что лежащие в основе веса модели забыли данные пациента. Вам нужен либо open-weights-бэкенд, либо обязательство вендора по удалению на уровне весов. Мы пишем об этом в квитанции.

Документация необходима, но недостаточна. Квитанция, доказывающая, что модель встретила порог, не доказывает, что порог был правильным. Если ваш scored-QA-набор не покрывает срез, который реально важен для пациента в вашем сервисе, никакое количество связывания квитанций это не исправит. Регуляторы всё больше это понимают; «мы прошли наш eval» больше не является достаточным ответом комплаенса, если eval был не тем eval.

Формат vindex — это single-vendor. Мы используем его, потому что это самый конкретный криптографический примитив, доступный сегодня для доказательства на уровне весов. Если индустрия остановится на другом формате — model-cards с хешами, схемы артефактов, опубликованные NIST, — формат квитанции должен эволюционировать к этому. Суть (хеш-цепочка, внешняя верифицируемость, осведомлённость о weight-attestation) — это то, что несущее, а не конкретное название схемы. Мы ожидаем, что это изменится по мере созревания регуляторного и стандартного ландшафта.

FAQ

Что такое верифицируемое удаление по GDPR Статья 17 для ИИ-систем?

Верифицируемое удаление означает, что третья сторона может верифицировать, что данные были удалены, не доверяя вашим логам. Дообучение модели, чтобы она «забыла» конкретную информацию, не соответствует этому стандарту — информация может всплыть при состязательном промптинге, и нет криптографического примитива, который аудитор мог бы проверить. DELETE-патч на уровне весов с опубликованным хешем vindex до и после соответствует стандарту, потому что аудитор может повторно прогнать верификацию против публичного артефакта.

Почему closed-API-модели не могут удовлетворить GDPR Статья 17 тем же способом?

Потому что провайдер не раскрывает веса. Без доступа к весам никакая третья сторона — включая клиента, использующего API, — не может выпустить или верифицировать удаление на уровне весов. Часть квитанции с цепочкой решений (какой шаблон промпта использовался, из какого хранилища поиска пришли данные, какие правила маршрутизации были активны) по-прежнему верифицируема, но заявление на уровне весов — нет. Это предел того, что верифицируемо, когда веса приватны, а не предел фреймворка комплаенса.

Что требует EU AI Act Приложение IV простым языком?

Приложение IV просит техническую документацию, охватывающую логику системы, сводку обучающих данных, предполагаемое использование, меры человеческого надзора и постмаркет-мониторинг. Ловушка, в которую попадает большинство команд, — это трактовать их как пять отдельных документов. Манифест релиза на Стадии 1 несёт первые три запроса как единый хеш; стадия Gate покрывает четвёртый; стадии Roll + Observe покрывают пятый. Один пайплайн; четыре запроса удовлетворены как побочный продукт обычных операций.

Насколько быстрым должен быть откат для HIPAA-развертываний?

HIPAA не определяет время отката, но руководство HHS по реагированию на нарушения трактует время-до-локализации как несущее. Откат порядка секунд (in-flight-дренирование на манифест-управляемом переключении — наше число около 12 секунд) структурно быстрее типичного blue-green по инфраструктурным метрикам, который зависит от распространения тревоги. Сравните с публичными постмортемами: инцидент Cloudflare в июне 2022^[4] занял 44 минуты на откат, потому что инженеры наступали друг другу на откаты.

Как NIST AI RMF сопоставляется с пайплайном релиза?

Четыре основные функции NIST AI RMF — Govern, Map, Measure, Manage — охватывают весь жизненный цикл релиза, а не одну стадию. Govern — это задокументированная политика релиза плюс воркфлоу обоснования gate-override (стадии Register + Gate). Map — это посрезовый scored-QA-набор (Gate). Measure — это посрезовые пороги Spearman и непрерывный монитор качества (Gate + Observe). Manage — это путь отката и цепочка квитанций (Observe). Все четыре покрываются, когда пайплайн эмитирует свой полный набор квитанций.

References

1. EU AI Act. artificialintelligenceact.eu. Приложение IV определяет требования к технической документации для ИИ-систем высокого риска: логика системы, сводка обучающих данных, меры человеческого надзора, постмаркет-мониторинг. Штрафы до 7% глобального оборота за нарушения.
2. AWS SageMaker Deployment Guardrails. Use canary traffic shifting + Auto-Rollback Configuration. По умолчанию TerminationWaitInSeconds 600, максимум MaximumExecutionTimeoutInSeconds 1800. Цитируется как индустриальный стандарт канареечного раската по инфраструктурным метрикам, с которым контрастирует монитор качества Стадии 4.
3. Калиброванное согласие LLM-as-judge. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% общего согласия GPT-4-против-человека, с покатегорийной дисперсией от кодинга (86%) до письма (36–44%). Якорь для покалевой калибровки Spearman, которая управляет стадией Gate.
4. Сбой Cloudflare в июне 2022. Cloudflare outage on June 21, 2022. 44 минуты от «мы знаем, что откатывать» до завершения отката, потому что инженеры наступали друг другу на откаты. Якорь для утверждения «манифест-управляемый откат не может иметь такой режим отказа».
5. NIST AI Risk Management Framework. NIST AI RMF. Voluntary framework — Govern, Map, Measure, Manage — that has become the de facto enterprise procurement baseline for AI governance. Voluntary but enforced in practice through customer due-diligence questionnaires.
6. HIPAA Privacy Rule. HHS Office for Civil Rights. Minimum-necessary disclosure, access audit, and breach response timing requirements applicable to any AI system that touches PHI. Civil monetary penalties up to $1.9M per violation-type per year per CMP inflation adjustment, 2025.
7. GDPR Article 17 (Right to Erasure). gdpr-info.eu/art-17-gdpr. The data subject's right to obtain erasure of personal data, and the controller's obligation to demonstrate compliance under Article 5(2) accountability. Penalties up to €20M or 4% of annual global turnover.
8. Internal — vindex receipt format. The receipt JSON in this post is adapted from the format documented on the compliance page and demonstrated in the "Deleting Paris from a Language Model" post. The hash chain is SHA-256 over manifest || prev_manifest || user_id || created_at || prev_chain_signature. Externally anchorable on a customer-configured schedule.

Следующий в этой серии: Автоматизированные пайплайны CI/CD для LLM с мгновенным откатом. Этот пост показал, что хочет аудитор. Следующий покажет операционный паттерн, который заставляет квитанцию приходить на стол аудитора за секунды, а не за недели — автоматизация под четырёхстадийным пайплайном, с акцентом на то, что меняется, когда откат срабатывает сам по себе.