O EU AI Act não é implementado anexando um parecer ao ticket de release. Os requisitos viram inventário, classificação, linhagem, evidência técnica versionada, logs automáticos, autoridade humana, quality gates, conformidade, monitoramento pós-mercado e resposta a incidentes.
Identifique se o produto é um sistema de IA, mercados e pessoas afetadas, finalidade prevista, misuse previsível e papel de cada ator. Provider, deployer, importer, distributor, representante, fabricante e provider de GPAI têm deveres distintos. Uma empresa pode ser deployer em um fluxo e tornar-se provider após modificação substancial ou rebranding.
Em 22 de junho de 2026: o Regulamento entrou em vigor em 1º de agosto de 2024; proibições, definições e AI literacy aplicam-se desde 2 de fevereiro de 2025; governança e GPAI desde 2 de agosto de 2025; e muitas outras disposições estão previstas para 2 de agosto de 2026. O acordo político do AI Omnibus, anunciado em 7 de maio de 2026, indica 2 de dezembro de 2027 para sistemas do Annex III e 2 de agosto de 2028 para sistemas incorporados a produtos. Separe o texto oficial vigente das alterações acordadas ainda sujeitas à adoção formal.
O registry não pode ficar desconectado da produção. Endpoint, modelo, prompt, policy, dataset, workflow humano e deployment precisam resolver para o mesmo sistema. O control plane verifica evidências, bloqueia releases incompatíveis, publica configuração aprovada e recebe outcomes de runtime.
| Requisito | Capacidade de arquitetura | Evidência de release | Sinal em runtime | Bloqueio |
|---|---|---|---|---|
| Risco, Art. 9 | Registro de hazards ligado a finalidade, misuse, grupos, controles, testes e risco residual. | Versão aprovada e métricas predefinidas. | Novo hazard, reclamação, contexto ou falha. | Risco não aceito ou avaliação expirada. |
| Dados, Art. 10 | Registry com origem, propósito, preparação, labels, geografia, população, qualidade, vieses, gaps, acesso e retenção. | Manifests imutáveis e checks assinados. | Drift, ausência de grupos, mudança de labels ou feedback loop. | Linhagem desconhecida ou quality gate falhou. |
| Documentação, Art. 11 | Docs-as-code derivados de registry, arquitetura, versões, performance, limites e mudanças. | Bundle alinhado ao Annex IV. | Runtime diverge da configuração documentada. | Documentação ausente, stale ou inconsistente. |
| Logs, Art. 12 | Eventos automáticos com versões, input reference, output, ação humana, tempo e trace IDs. | Schema, retenção, integridade, acesso e replay. | Perda, quebra de schema, clock drift ou decisão sem rastro. | Evento necessário não pode ser reconstruído. |
| Informação, Art. 13 | Instruções versionadas com finalidade, limites, métricas, input, supervisão, manutenção e circunstâncias. | Pacote aprovado ligado ao artefato. | Uso fora das instruções. | Deployer não opera/interpreta com segurança. |
| Supervisão, Art. 14 | Fila, autoridade, competência, contexto, override/stop, defesa contra automation bias e escalonamento. | Testes de cenário e intervenção. | Override, alerta ignorado, atraso e erro. | Ninguém qualificado entende, intervém ou para. |
| Acurácia/robustez/cyber, Art. 15 | Evals, métricas declaradas, testes de falha/ataque, fail-safe, redundância e feedback-loop control. | Relatório por contexto e grupo. | Drift, ataque, outage, fallback ou amplificação. | Nível declarado ou fallback falhou. |
Release → modelo/prompt → commit/container → data manifests → evals → controles → documentação → instruções → supervisão → segurança → conformidade/registro → deployment. Cada evidência tem autor, reviewer, timestamp, ferramenta, fonte, assinatura, validade e supersession. PDF é export, não source of truth.
Providers respondem pelo design, quality management, documentação, conformidade, correção e pós-mercado. Deployers seguem instruções, designam supervisão competente, monitoram, retêm logs sob seu controle e tratam inputs; órgãos públicos e certos serviços essenciais podem precisar de avaliação de impacto sobre direitos fundamentais.
Defina o que o humano vê, competência, momento, obrigatoriedade, prazo, auto-stop e reversibilidade. Meça idade da fila, sucesso da intervenção, overrides, automation bias, discordância, escalonamento e outcomes.
Registre o necessário para reconstrução e monitoring com minimização, retenção, acesso, integridade e segurança. Prefira referências, hashes e contexto estruturado a prompts e PII indiscriminados. Separe analytics, segurança, evidência regulatória e casos sensíveis.
Finalidade, segmento, país, autoridade de decisão, autonomia, fonte de dados, threshold, UI, tool permission, integração ou vendor podem alterar risco e papel. PR e pipeline calculam impacto, invalidam evidência, solicitam reviews e rerodam evals.
Assessment, declaração UE, CE quando aplicável, registro, retenção e cadeia de valor viram estados: dev-only, sandbox, pending, aprovado por mercado/finalidade, registrado, suspenso, recall ou retired. Artefato aprovado para um uso não pode migrar silenciosamente para outro.
Defina antes do launch: performance, drift, grupos, overrides, misuse, reclamações, recursos, precursores, contexto, avisos de provider e interação com outros sistemas. Cada sinal tem threshold, owner, playbook, correção e atualização de evidência.
Preserve versão, timeline, outputs, logs, ações humanas, dados, impacto, contenção e comunicação. O fluxo avalia reportabilidade pelo Artigo 73, coordena atores/autoridades, impede exclusão e acompanha correção até eficácia verificada.
Registre provider, modelo/versão, release, integração, documentação, acceptable use/copyright, evals, systemic risk, hosting e change notices. Alias que aponta silenciosamente para novo modelo é mudança de supply chain.
O Artigo 50 pode exigir aviso de interação com IA e marcação/divulgação de conteúdo. Incorpore notices, provenance metadata, suporte à detecção, disclosure, idioma, acessibilidade e prova de entrega. Policy no footer não equivale a aviso oportuno.
Registry e actor graph; serviço de baseline jurídica; engine de classificação; data/model BOM; evidence graph; eval service; gerador de docs; policy-as-code gateway; allow-list de deployment; logging schema; console de supervisão; provenance/transparência; signal bus pós-mercado; incident workflow; state machine de conformidade; monitor de vendor; e exports auditáveis.
O AI Act fica gerenciável quando compliance deriva do software, modelo, dados, finalidade, mercado e evidência em produção. Arquitetura não substitui julgamento jurídico, mas conecta cada decisão a controles executáveis e fatos reconstruíveis.
Nota jurídica: interpretação de engenharia, não aconselhamento jurídico. Verifique texto formalmente aplicável, guidelines, standards e regras nacionais.
Artigo sobre EU AI Act como arquitetura de software: registry, classificação, dados, documentação, logs, supervisão, gates, conformidade, monitoramento, incidentes, GPAI e transparência.