Validando e Lançando LMs Customizados em Setores Regulados

Notas do Ciclo de Release — Parte IV

Uma diretora jurídica entra na revisão de engenharia. Ela tem uma única pergunta: “Se a solicitação de direito ao esquecimento do Artigo 17 do EU AI Act chegar amanhã pedindo para removermos todo fato que nosso modelo aprendeu sobre um paciente específico, podemos provar que o fizemos?”

A resposta honesta que a maioria das equipes precisa dar é: “Podemos fazer fine-tune do modelo para esquecer. Podemos mostrar o treinamento. Mas não podemos provar que a informação está estruturalmente removida, porque ela pode ressurgir sob o prompt adversarial certo.”

Isso não é uma resposta de compliance. É uma não-resposta com um encolher de ombros procedimental.

Este post é sobre como se parece uma resposta de compliance de verdade para LLMs customizados — em quatro frameworks regulatórios (EU AI Act, GDPR Artigo 17, HIPAA, NIST AI RMF), mapeados para o pipeline de quatro estágios (Register → Gate → Roll → Observe) que entregamos para releases de clientes. A tensão central que atravessa o pedido de cada regulador é open-weights vs API fechada: as coisas que você pode provar sobre um fine-tune do Gemma 4 não são as coisas que você pode provar sobre um release servido atrás de uma API opaca de fornecedor. O formato de recibo que usamos diz isso explicitamente, linha por linha. Essa honestidade é o que torna o recibo útil para um auditor.

Os quatro reguladores e o que cada um realmente quer

Discussões de compliance tendem a colapsar em “documentamos as coisas”. Esse enquadramento falha com um auditor. O que auditores querem é evidência que possam verificar sem ter de confiar na sua infraestrutura. Os quatro frameworks abaixo usam vocabulários diferentes para o mesmo pedido subjacente.

Os números das penalidades não são o que torna esses frameworks interessantes. Os números das penalidades são o que os torna estruturalmente determinantes. A parte interessante é o primitivo de verificação — como cada framework realmente quer que o artefato pareça. Três dos quatro pedem prova de grau criptográfico em vocabulários diferentes. O quarto (NIST AI RMF) é voluntário, mas de fato exigido na aquisição corporativa. Eles convergem na mesma forma: um artefato que um auditor consegue verificar sem confiar nos seus logs.

A divisão: open-weights vs API fechada

Antes do mapeamento por estágio, a ressalva mais importante de todo este post:

Para backings de modelo open-weights — Gemma, Qwen, Llama, Mistral, GPT-OSS, qualquer coisa em que os pesos sejam endereçáveis e editáveis — toda decisão de release do Divinci emite um recibo vindex que inclui uma atestação de pesos: prova criptográfica de que os pesos ativos no momento da decisão são exatamente os pesos que o manifest registrou. É isso que torna possível a apagabilidade verificável do Artigo 17 do GDPR. Você aplica um patch DELETE que remove uma relação-entidade específica do espaço de pesos, o recibo embute o hash antes-e-depois, e um auditor consegue verificar que a deleção aconteceu re-rodando a verificação contra o vindex público.

Para backings de modelo de API fechada — OpenAI, Anthropic, Google via APIs opacas — o mesmo recibo cobre a cadeia de decisão (qual manifest, qual resultado do gate, qual leitura do monitor, qual usuário acionou qual ação) mas não pode reivindicar proveniência dos pesos, porque o provedor não expõe os pesos. O recibo registra isso explicitamente em um campo weight_attestation: null com uma note explicando por quê. Isso não é uma postura de compliance degradada — é o limite do que é verificável, escrito honestamente. Um auditor que lê o recibo entende exatamente qual classe de prova está e não está sendo feita.

Essa divisão atravessa o pedido de cada regulador abaixo. Sempre que um framework demanda algo no nível dos pesos, o caminho open-weights pode satisfazer e o caminho de API fechada não. Dizemos isso no recibo, em vez de insinuar uma prova que não conseguimos entregar.

Como cada framework mapeia nos quatro estágios do pipeline

O pipeline tem quatro estágios. O pedido de cada regulador mapeia para um ou mais deles. A matriz abaixo é o mapa real.

As duas células ◐ são as entradas GDPR Artigo 17 / somente-open-weights — esses são os pedidos que o caminho de API fechada não consegue satisfazer plenamente. Tudo o mais se aplica aos dois backings.

O restante do post percorre a contribuição de cada estágio.

Estágio ① — Register

O estágio Register produz um manifest JSON imutável, endereçado por SHA-256. Para releases regulados, o manifest carrega tudo o que o Anexo IV^[1] pede em um único artefato:

• O artefato do modelo (repo HF + commit SHA, ou uma referência a um patch vindex)
• O template de prompt (cada variável, cada system message — versionado)
• As regras de roteamento (qual classe de tráfego cai em qual release)
• A versão do dataset usada para computar os thresholds do gate (resumo dos dados de treino por hash)
• O SHA do release anterior (para que a cadeia de auditoria seja ininterrupta)
• O escopo de divulgação — para deployments HIPAA, quais categorias de PHI o modelo está autorizado a receber

O manifest é a documentação. Um auditor não lê prosa; ele lê o hash do manifest e verifica o bundle. Nenhum resumo em prosa escrito-seis-meses-depois é necessário.

Bônus open-weights. Quando o artefato do modelo referencia um modelo open-weights, o manifest também embute o vindex_sha256 — a impressão digital criptográfica do vindex publicado do modelo. Essa impressão digital é o que permite a um terceiro verificar os pesos ativos sem nunca ter de confiar na nossa infraestrutura de deployment.

Ressalva de API fechada. Quando o artefato do modelo referencia um modelo de API fechada, o campo vindex_sha256 do manifest é null, e o weight_attestation_class do manifest é decision_chain_only. O auditor que lê isso sabe exatamente o que está sendo reivindicado e o que não está.

Estágio ② — Gate

O estágio Gate é onde as “medidas de supervisão humana”^[1] do EU AI Act se operacionalizam. Um regulador que lê o EU AI Act e conclui “precisamos de um workflow de aprovação humana” perdeu o ponto — o pedido mais difícil é contra o que o humano está aprovando. O estágio Gate responde a essa pergunta com um ρ de Spearman por slice contra um avaliador ancorado em humano^[3]. Cada slice que importa na sua postura regulatória (oncologia pediátrica, licenciamento de IP, francês belga) recebe seu próprio threshold. O caminho de override exige uma justificativa escrita que entra na trilha de auditoria.

Para deployments cobertos por HIPAA, é também aqui que vive a regra de divulgação “mínima-necessária”. A suíte de QA pontuada do gate inclui testes negativos para superexposição de PHI — respostas que incluem identificadores pessoais quando nenhum foi solicitado. Um release que regride no slice de superexposição falha no gate, independentemente de como os outros slices se saem.

Para NIST AI RMF, o estágio Gate cobre a função “measure” — a evidência numérica por slice de que o sistema está performando dentro das tolerâncias configuradas.

Estágio ③ — Roll

O monitoramento pós-mercado do EU AI Act^[1] exige que o operador demonstre observação contínua — não apenas pré-lançamento — de como o sistema de IA performa em condições reais. Um canário 5% → 25% → 100% com checkpoints de quality-monitor é a forma mais natural de satisfazer isso. O dwell em cada checkpoint, mais as leituras do monitor durante o dwell, é o que um auditor quer ver.

Para HIPAA, o estágio de canário é também onde o logging de auditoria por requisição é exercitado de ponta a ponta. Cada checkpoint produz uma amostra de recibos assinados de request-response; se algum deles tiver um tratamento de PHI mal configurado, ele aparece a 5% de tráfego, e não a 100%.

Estágio ④ — Observe

Este é o estágio que sustenta a história de compliance. O estágio Observe roda replay contínuo de traces pelo release ativo, pontuado pelo mesmo juiz ancorado em humano do Gate, com um monitor de qualidade que aciona rollback automático caso seja violado.

Toda decisão de release — register, gate-pass, gate-fail, gate-override, checkpoint-promote, checkpoint-hold, auto-rollback, manual-rollback, e qualquer aplicação de patch DELETE do Artigo 17 do GDPR — emite um recibo vindex. Hash-chained ao recibo anterior deste cliente e ao recibo anterior deste release.

Eis como se parece um recibo real para um patch DELETE do Artigo 17 do GDPR — adaptado diretamente do formato documentado na página de compliance:

{
  "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)"
}

Esse artefato é verificável. Um auditor não precisa confiar nos nossos logs. Ele pega o vindex_sha256_after, puxa o vindex publicado correspondente em huggingface.co/Divinci-AI, e verifica que a feature 11179 na camada 27 está estruturalmente ausente do top-25. Pega o chain_signature e verifica contra o recibo anterior. A cadeia inteira é ancorada externamente em uma cadência configurada pelo cliente.

Mesma operação contra um modelo de API fechada. Os campos do recibo acima mudam de três formas: operation.target se torna provider_api_endpoint, verification se torna um schema diferente cobrindo apenas evidências da cadeia de decisão, e weight_attestation_class se torna decision_chain_only. O provedor do modelo de API fechada não expôs pesos, então o recibo o diz. Um auditor que quer prova no nível dos pesos agora sabe que precisa escalar para o provedor, não para nós.

Essa é a diferenciação que ninguém mais em 2026 entrega. O acampamento de eval-CI (Braintrust, Humanloop, Patronus) não fica em cima do tráfego e não emite recibos de decisão. O acampamento de serving-canary (SageMaker Deployment Guardrails^[2], KServe, Vertex, BentoCloud, Seldon) emite logs de métricas de infra, mas não recibos de compliance hash-chained. O acampamento de observabilidade (Arize, Phoenix, Confident, Deepchecks) observa a saída, mas não enforça.

O que um auditor realmente verifica?

Um exercício útil: percorrer as perguntas que um auditor real fará, e qual artefato responde a cada uma.

O que o auditor não precisa fazer: confiar no nosso Datadog. Confiar no nosso CloudWatch. Confiar em um screenshot. Confiar em um export. O ponto inteiro do formato do recibo é que o auditor consegue verificá-lo independentemente.

O que isto não resolve

Três limitações honestas:

Regressões em API fechada no território do Artigo 17 do GDPR não são solucionáveis na camada da plataforma. Se você está servindo um assistente de saúde atrás de um modelo de API fechada e um paciente invoca o Artigo 17, a plataforma pode atestar que o registro do paciente foi removido do seu retrieval store, do seu template de prompt e das suas regras de roteamento — mas não pode atestar que os pesos do modelo subjacente esqueceram os dados do paciente. Você precisa de um backing open-weights ou de um compromisso do fornecedor com apagamento no nível dos pesos. Nós dizemos isso no recibo.

Documentação é necessária, mas não suficiente. Um recibo que prova que um modelo atingiu um threshold não prova que o threshold era o threshold correto. Se sua suíte de QA pontuada não cobre o slice que realmente importa para um paciente no seu serviço, nenhuma quantidade de receipt-chaining conserta isso. Reguladores cada vez mais entendem isso; “passamos no nosso eval” não é mais uma resposta de compliance suficiente se o eval era o eval errado.

O formato vindex é single-vendor. Nós o usamos porque é o primitivo criptográfico mais concreto disponível hoje para prova no nível dos pesos. Se a indústria convergir num formato diferente — model-cards-com-hashes, schemas de artefato publicados pelo NIST — o formato do recibo deve evoluir para isso. A substância (hash-chained, verificável externamente, ciente de weight-attestation) é o que sustenta a estrutura, não o nome específico do schema. Esperamos que isso mude conforme o cenário regulatório e de padrões amadurece.

FAQ

O que é apagabilidade verificável sob o Artigo 17 do GDPR para sistemas de IA?

Apagabilidade verificável significa que um terceiro consegue verificar que os dados foram removidos sem ter de confiar nos seus logs. Fazer fine-tune de um modelo para “esquecer” informações específicas não atende a esse padrão — a informação pode ressurgir sob prompts adversariais, e não há primitivo criptográfico que um auditor possa checar. Um patch DELETE no nível dos pesos com um hash vindex publicado antes/depois atende ao padrão, porque o auditor consegue re-rodar a verificação contra o artefato público.

Por que modelos de API fechada não conseguem satisfazer o Artigo 17 do GDPR do mesmo jeito?

Porque o provedor não expõe os pesos. Sem acesso aos pesos, nenhum terceiro — incluindo o cliente que usa a API — consegue emitir ou verificar um apagamento no nível dos pesos. A parte da cadeia de decisão do recibo (qual template de prompt foi usado, de qual retrieval store os dados vieram, quais regras de roteamento estavam ativas) ainda é verificável, mas a reivindicação no nível dos pesos não é. Isto é um limite do que é verificável quando os pesos são privados, não um limite do framework de compliance.

O que o Anexo IV do EU AI Act exige, em português claro?

O Anexo IV pede documentação técnica cobrindo a lógica do sistema, o resumo dos dados de treino, o uso pretendido, as medidas de supervisão humana e o monitoramento pós-mercado. A armadilha em que a maioria das equipes cai é tratar isso como cinco documentos separados. O manifest de release no Estágio 1 carrega os três primeiros pedidos como um único hash; o estágio Gate cobre o quarto; os estágios Roll + Observe cobrem o quinto. Um pipeline; quatro pedidos satisfeitos como subproduto das operações normais.

Quão rápido o rollback deveria ser para deployments cobertos por HIPAA?

O HIPAA não especifica um tempo de rollback, mas a orientação do HHS sobre resposta a violações trata o tempo-para-contenção como estruturalmente determinante. Um rollback na ordem de segundos (drain em voo num flip orientado a manifest — o nosso número é em torno de 12 segundos) é estruturalmente mais rápido do que um blue-green típico baseado em métrica de infra que depende de propagação de alarme. Compare com postmortems públicos: o incidente da Cloudflare em junho de 2022^[4] levou 44 minutos para ser revertido porque engenheiros passaram por cima dos reverts uns dos outros.

Como o NIST AI RMF mapeia para um pipeline de release?

As quatro funções centrais do NIST AI RMF — Govern, Map, Measure, Manage — abrangem todo o ciclo de vida do release, não um único estágio. Govern é a política de release documentada mais o workflow de justificativa de gate-override (estágios Register + Gate). Map é a suíte de QA pontuada por slice (Gate). Measure são os thresholds de Spearman por slice e o monitor contínuo de qualidade (Gate + Observe). Manage é o caminho de rollback e a cadeia de recibos (Observe). Todas as quatro são cobertas quando o pipeline emite seu conjunto completo de recibos.

References

1. EU AI Act. artificialintelligenceact.eu. Annex IV defines the technical documentation requirements for high-risk AI systems: system logic, training data summary, human oversight measures, post-market monitoring. Penalties up to 7% of global turnover for non-compliance.
2. AWS SageMaker Deployment Guardrails. Use canary traffic shifting + Auto-Rollback Configuration. Default TerminationWaitInSeconds 600, max MaximumExecutionTimeoutInSeconds 1800. Cited as the industry-standard infra-metric canary that the Stage 4 quality monitor is contrasted against.
3. Calibrated LLM-as-judge agreement. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% overall GPT-4-vs-human agreement, with per-category variance from coding (86%) down to writing (36–44%). Anchor for the per-slice Spearman calibration that drives the Gate stage.
4. Cloudflare June 2022 outage. Cloudflare outage on June 21, 2022. 44 minutes from "we know what to revert" to revert complete because engineers walked over each other's reverts. Anchor for the "manifest-driven rollback can't have that failure mode" claim.
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.

Próximo nesta série: Pipelines Automatizados de CI/CD para LLMs com Rollback Instantâneo. Este post mostrou o que um auditor quer. O próximo mostra o padrão operacional que faz o recibo chegar à mesa do auditor em segundos em vez de semanas — a automação por baixo do pipeline de quatro estágios, com foco no que muda quando o rollback dispara sozinho.