Compliance EU AI Act + NIST RMF: checklist de 18 itens para times brasileiros que vendem pra fora

Você tem 70 dias.

Em 2 de agosto de 2026, a maior parte do EU AI Act entra em vigor. A Comissão Europeia passa a ter poder de aplicar multas. E não, isso não é problema só de gringo: se você tem um SaaS hospedado em São Paulo e cliente pagante em Lisboa, Madri ou Berlim, o regulamento atinge você. Extraterritorialidade está no artigo 2º — o que importa é onde o output do sistema de IA é usado, não onde ele roda.

A boa notícia: muito do que o EU AI Act exige sobre IA de alto risco já está coberto pelo NIST AI Risk Management Framework. Quem implementou o RMF tem 70% do caminho andado. Quem não implementou nada precisa de um plano de ataque.

Esse post é o plano de ataque. 18 itens em ordem de prioridade, mapeados pra Govern/Map/Measure/Manage do NIST, com templates Markdown prontos que você cola no repositório hoje.

TL;DR

• O que é: checklist técnico de 18 itens para times brasileiros que vendem IA pra clientes na UE, conciliando EU AI Act + NIST AI RMF + GDPR.
• Stack: agnóstica. Funciona em Laravel, Python, Node — o que importa é a arquitetura de processo e logging.
• Custo/Acesso: zero em ferramenta. O custo é tempo de engenharia (estimativa: 4–8 semanas para um time de 3 devs, partindo do zero).
• Repositório/Link útil: texto consolidado do EU AI Act e NIST AI 600-1 (perfil GenAI).

O contexto — por que isso virou urgência

A linha do tempo do EU AI Act tem três marcos que importam pra quem vende SaaS de IA:

As multas não são piada. Até €35 milhões ou 7% do faturamento global, o que for maior. É mais punitivo que GDPR, que para em 4%.

E o ponto cego do brasileiro: se você usa OpenAI/Anthropic na ponta e expõe a API pra um cliente europeu, você é deployer de IA de alto risco sempre que o caso de uso cair em saúde, RH, crédito, educação, serviços essenciais ou infraestrutura crítica (Anexo III). A obrigação não desce só pra OpenAI. Desce pra você.

Do lado brasileiro, o PL 2338/2023 já foi aprovado no Senado e está na Câmara. A ANPD será o regulador residual. A estrutura é parecida com a europeia, mas com tetos menores (2% de faturamento Brasil). Quem se prepara pra UE já fica pronto pra Brasil.

Por que enfiar NIST RMF no meio? Porque o EU AI Act exige o que fazer, sem dizer como. NIST RMF é o como. As quatro funções — Govern, Map, Measure, Manage — formam o esqueleto operacional. O perfil generativo (NIST AI 600-1) já está alinhado com o que a Comissão Europeia espera ver em auditoria.

Pré-requisitos antes de começar

• [ ] Um inventário inicial dos sistemas de IA em produção (mesmo que rascunho em planilha).
• [ ] Acesso ao repositório Git de cada sistema — todo controle vai parar no PR.
• [ ] Pessoa designada como AI Risk Owner (não precisa ser exclusiva, mas precisa existir).
• [ ] Cliente UE já mapeado: contrato, DPA assinado, finalidade de processamento documentada.

Se faltar inventário, comece pelo item 1 do checklist. Sem ele, nada faz sentido.

O checklist — 18 itens em ordem de prioridade

A ordem importa. Cada item depende dos anteriores. Tentar fazer eval registrado (item 5) sem ter data lineage (item 3) é construir auditoria em cima de areia.

1. Classificação de risco do sistema — NIST: Map | EU: Art. 6

Antes de qualquer controle técnico, classifique cada sistema de IA do seu inventário em uma das quatro categorias do EU AI Act: proibido, alto risco (Anexo III), risco limitado (chatbot, geração de conteúdo) ou risco mínimo.

# system-classification.md
- ID: sys-credit-scoring-v2
- Caso de uso: scoring de crédito para PMEs
- Anexo III aplicável: sim (item 5 — acesso a serviços essenciais)
- Classificação: ALTO RISCO
- Justificativa: decisões automatizadas com impacto material em pessoa física
- Aprovador: jane.doe@empresa.com
- Data: 2026-05-15

Sem essa classificação, você não sabe quais dos 17 itens seguintes precisa cumprir. Risco limitado precisa basicamente do item 10 (right to explanation light). Alto risco precisa de tudo.

2. Inventário versionado de modelos, prompts e tools — NIST: GV-1.6

Um arquivo inventory.yaml na raiz do repositório, atualizado por PR, com cada modelo, prompt, tool, RAG source e owner. É o documento mais consultado em auditoria. Sem ele, você não consegue responder "que versão estava rodando em 12 de março às 14h?".

# inventory.yaml
agents:
  - id: agent-onboarding-v3
    classification: high-risk
    model: claude-opus-4-7
    prompt_version: v18
    tools: [crm-lookup, kyc-check, document-ocr]
    rag_sources: [policy-docs-2026q2]
    owner: lucas@empresa.com
    approved_at: 2026-04-20T10:00:00-03:00
    approval_signature: 7d4f...

3. Data lineage e DPIA — NIST: MP-4 | EU: Art. 10 + GDPR Art. 35

Para cada dataset de treino, fine-tuning ou few-shot, registre origem, base legal de processamento (GDPR Art. 6), categoria de dados, retenção e transformações aplicadas. Para qualquer sistema de alto risco que processe dado pessoal, DPIA é obrigatória e a do AI Act se sobrepõe à do GDPR — você pode reaproveitar uma DPIA bem-feita para cumprir o FRIA (item 13).

4. Human-in-the-loop documentado — NIST: MP-3.5 | EU: Art. 14

Não basta dizer "tem humano revisando". Você precisa documentar onde o humano entra, com qual autoridade (pode vetar, pode editar, pode só observar?) e que treinamento ele recebeu. Se o humano só clica "aprovar" sem ler, isso não é supervisão. É carimbo.

5. Eval registrado e versionado — NIST: MS-2.5

Toda mudança de modelo, prompt ou tool passa por um conjunto de evals com gate de qualidade. O eval mora no repositório, tem ID, dataset versionado, métrica clara e threshold.

# evals/eval-credit-decision-v4.md
- ID: eval-cred-v4
- Suite: 320 casos rotulados por 2 humanos (cohen's kappa = 0.81)
- Métrica primária: F1 sobre decisão correta
- Threshold: F1 >= 0.87 (regressão bloqueia merge)
- Dataset hash: sha256:9a3f...
- Última execução: 2026-05-24T18:32:00-03:00 (F1=0.892)

6. Prompt versionado com diff, autor e aprovação — NIST: GV-1.4

Todo prompt que vai para produção é um artefato Git. Tem hash, autor, revisor, mensagem de commit explicando por quê mudou. Mudança de prompt sem revisão é exatamente o tipo de coisa que aparece em incident report com "ninguém sabia que tinha mudado".

7. Model card — NIST: MS-2.9 | EU: Anexo IV §2

Para cada modelo (próprio ou fine-tuned), um model card no formato Hugging Face: capacidades, limitações conhecidas, viés medido, dados de treino, métricas em benchmark, uso recomendado e proibido. Para GPAI (você consumindo Claude/GPT), o provedor é obrigado a publicar o dele — guarde o link no inventário.

8. Audit trail por requisição — NIST: MS-2.4 + MG-4.3 | EU: Art. 12

Cada inferência em produção gera um log com: ID da requisição, timestamp, modelo, versão do prompt, input hash (não o input cru se tiver PII), output, latência, custo, tools chamadas e decisão final. Retenção mínima de 6 meses; para alto risco, 10 anos.

{
  "request_id": "req_01HZX9...",
  "timestamp": "2026-05-24T17:22:14-03:00",
  "system": "agent-onboarding-v3",
  "model": "claude-opus-4-7",
  "prompt_version": "v18",
  "input_hash": "sha256:...",
  "output_redacted": "Aprovado com observação X",
  "tools_called": ["kyc-check"],
  "latency_ms": 1840,
  "human_review": { "reviewer": "ana@empresa.com", "decision": "approved" }
}

9. AIDR — detecção e resposta a ataques no nível do prompt — NIST: MS-2.7

Prompt injection, jailbreak e exfiltração via tool poisoning são vetores reais. Em 2026, ferramentas tipo CrowdStrike Falcon AIDR já tratam isso como SOC trata EDR. Se você não usa solução comercial, no mínimo: classificador de injection na entrada, output filter (PII, instrução de sistema vazando) na saída, e alerta pra quando ambos disparam ao mesmo tempo.

10. Right to explanation — NIST: MS-2.8 | EU: Art. 86

Qualquer pessoa atingida por uma decisão de IA de alto risco tem direito a uma explicação clara: papel da IA, principais parâmetros que influenciaram o output, nível de supervisão humana. Você precisa de um endpoint (interno que seja) que, dado um request_id, devolva essa explicação em linguagem natural — não basta cuspir o JSON do log.

11. Right to erasure (e o paradoxo do audit trail) — GDPR Art. 17 vs EU AI Act Art. 12

Aqui mora a contradição mais delicada: o GDPR exige que você apague dado pessoal quando solicitado. O EU AI Act exige que você mantenha audit trail por anos. Saída prática: separe os logs em dois fluxos — um técnico (hashes, versões, métricas, sem PII) que fica retido pra auditoria, e outro de conteúdo (input/output cru) que vive em base separada com política de retenção compatível com pedido de erasure. Documente essa arquitetura na DPIA.

12. Política de retenção e mascaramento de PII — NIST: MS-2.10

Toda PII que passa pelo modelo é mascarada antes do log e antes de qualquer envio pra LLM externo. Token de pagamento, CPF, e-mail, telefone — tudo redacted via classificador na borda. Sem isso, o item 11 não funciona.

13. FRIA — Fundamental Rights Impact Assessment — EU: Art. 27

Obrigatório para deployers de IA de alto risco em setores públicos ou que afetem direitos fundamentais (crédito, seguro, RH). Estrutura: descrição do sistema, período de uso, categorias de pessoas afetadas, riscos específicos, medidas de mitigação, mecanismo de revisão. Se você já tem DPIA decente, o FRIA é um delta pequeno.

14. Post-market monitoring — NIST: MG-4.1 | EU: Art. 72 + Anexo IV §9

Plano formal de monitoramento contínuo: o que você mede em produção, com que frequência, quem revisa, qual o threshold de degradação que dispara revisão e quem aprova a decisão de re-treinar ou rollback. Não é dashboard. É processo com dono e cadência.

15. Incident reporting — EU: Art. 73

Incidente grave em sistema de alto risco vira notificação à autoridade de mercado em 15 dias (72h se for morte ou dano sério). Template de incident report deve estar pronto antes do incidente — em pleno fogo não é hora de pensar em formato.

16. Cláusula contratual com fornecedores GPAI — NIST: GV-6 | EU: Art. 25

Você está acoplado à OpenAI, Anthropic, Google, AWS Bedrock. O contrato precisa cobrir: SLA de model card atualizado, notificação de mudança de versão, base legal de processamento se houver dado pessoal, retenção de prompts, política de uso de outputs para treino. Se o contrato não fala disso, renegocie — em auditoria, "a OpenAI não me avisou" não é defesa.

17. Conformity assessment e registro na base europeia — EU: Art. 43 + 49

Para sistemas de alto risco, antes de colocar no mercado UE você precisa: avaliação de conformidade (interna na maioria dos casos do Anexo III), declaração UE de conformidade, marca CE quando aplicável, registro na base de dados pública da UE. Sem isso, o sistema não pode operar — e a multa por operar sem registro é proporcional ao tempo de operação irregular.

18. Programa contínuo de governance — NIST: GV-1.5 + GV-4

Cadência trimestral de revisão do inventário, anual de revisão do FRIA, contínua de monitoramento de mudanças regulatórias. Sem programa, todo o resto vira foto — bonita no dia do lançamento, desatualizada três meses depois.

Templates Markdown prontos pra colar no repositório

Model card mínimo

# Model Card — <nome-do-modelo>

## Descrição
- Versão:
- Tipo: (base / fine-tuned / RAG-augmented)
- Modelo subjacente:
- Data de treino/cutoff:

## Uso pretendido
- Casos de uso aprovados:
- Casos de uso proibidos:
- Usuários esperados:

## Métricas
- Suite de avaliação:
- F1 / precisão / recall:
- Latência p95:
- Custo médio por inferência:

## Limitações conhecidas
- Domínios onde falha:
- Vieses medidos:
- Idiomas suportados:

## Considerações éticas
- Dados de treino — origem e base legal:
- Avaliação de viés realizada em:
- Plano de mitigação de viés:

## Manutenção
- Owner:
- Última revisão:
- Próxima revisão:

Entry de prompt registry

# prompts/<agent-id>/v<N>.md
---
agent_id: agent-onboarding-v3
version: 18
author: lucas@empresa.com
approved_by: ana@empresa.com
approved_at: 2026-05-20T14:32:00-03:00
diff_from: v17
eval_run: eval-cred-v4 (F1=0.892)
---

<corpo do prompt>

Incident report (Art. 73)

# Incident Report — <id>

## Sumário
- ID: inc-2026-05-24-001
- Sistema: <agent-id>
- Severidade: (sério / não sério)
- Detectado em:
- Notificação à autoridade em: (max 15 dias / 72h se grave)

## Descrição
- O que aconteceu:
- Quantas pessoas afetadas:
- Impacto material:

## Causa raiz
- Modelo / prompt / tool / dado:

## Ações imediatas
- Rollback / disable / hotfix:
- Comunicação a afetados:

## Plano de remediação
- Mudanças no sistema:
- Atualização de model card / FRIA:
- Eval adicionada pra prevenir regressão:

Limitações e pontos de atenção

A maior pegadinha é tratar isso como projeto de papelada. Não é. O EU AI Act foi escrito pra ser auditado em código, log e processo — não em PDF. Auditor europeu sério pede pra ver o repositório, o pipeline de CI, o dashboard de eval. Se a "evidência" é um Confluence que ninguém atualiza desde janeiro, você falha.

Segundo ponto: o regulamento ainda vai ganhar guidelines específicas por setor (saúde, educação, RH) ao longo de 2026 e 2027. O que você implementa agora é a base — espere ajustes incrementais. Quem tem inventário, audit trail e governance estabelecidos absorve ajuste sem dor. Quem improvisa, refaz do zero.

Terceiro ponto delicado: o item 11 (right to erasure vs audit trail) ainda é zona cinza juridicamente. A solução de logs em duas camadas é o que a maior parte dos escritórios europeus está recomendando hoje, mas não tem jurisprudência consolidada. Documente a sua escolha de arquitetura na DPIA com justificativa — se a interpretação mudar, você tem trilha de decisão.

FAQ rápido

Sou um SaaS brasileiro com dois clientes na Europa. Preciso mesmo de tudo isso? Depende da classificação do sistema. Se o caso de uso cai no Anexo III, sim — não tem dois clientes que justifiquem operar fora da lei. Se é risco limitado (chatbot, geração de conteúdo), você precisa basicamente dos itens 1, 7, 8, 10 e 15.

Eu uso só Claude/GPT via API. A responsabilidade não é deles? Parte sim. O provedor de GPAI tem suas próprias obrigações (transparência, copyright, risco sistêmico). Mas quem decide como aplicar o modelo em decisão de crédito, RH ou saúde é você — e essa parte é sua. O artigo 25 do AI Act trata isso explicitamente.

Quanto tempo leva pra implementar tudo? Time de 3 devs, partindo do zero, com 1 sistema de alto risco e 2 de risco limitado: 4 a 8 semanas pra ter os 18 itens funcionando. A parte cara não é técnica — é alinhar dono de risco, contrato com fornecedor e processo com legal/compliance.

Posso pular o NIST RMF e implementar só o EU AI Act? Pode, mas vai sofrer. O regulamento europeu diz o que exigir; o NIST RMF dá vocabulário e estrutura pra como fazer. Time que adota só EU AI Act tende a virar fábrica de PDF. Time que adota NIST como sistema operacional cumpre EU AI Act como subproduto.

Conclusão

O EU AI Act não vai pegar você de surpresa em 2 de agosto de 2026 porque você não sabia. Vai pegar porque achou que dava pra empurrar mais um trimestre. Os 18 itens acima cabem num sprint planning honesto — começa pelo inventário, classifica risco, monta o audit trail, fecha o ciclo com governance. O resto é detalhe.

A parte boa: depois de implantar, isso vira diferencial comercial. Cliente europeu sério hoje exige declaração de conformidade preliminar como pré-requisito de procurement. Quem chega com a casa arrumada vende mais caro e mais rápido. Esse tipo de conversa — engenharia de IA séria, em português, com gente fazendo em produção — é exatamente o que rola na Beer and Code, a melhor comunidade de AI engineering em português, com grupo no WhatsApp aberto pra quem está construindo IA em produção.

70 dias. Pode parecer pouco, mas dá. Começa hoje.