O EU AI Act costuma ser discutido como documento jurídico. Builders precisam de outra lente: o que precisa existir no repositório, no pipeline de deploy, na observabilidade, no processo de review de produto e no fluxo de incidentes antes de uma feature de IA ir para produção?
O AI Act classifica sistemas de IA por risco e conecta obrigações a providers, deployers, importadores, distribuidores e outros atores. Esse vocabulário importa, mas o trabalho começa com artefatos: inventário de sistemas de IA, registro de classificação de risco, documentação técnica, evidências de avaliação, logs, instruções de uso, monitoramento e ownership claro.
Isto não é aconselhamento jurídico. É um mapa de engenharia para conversas com produto, segurança, privacidade, jurídico e operações. Times fortes não tratam compliance como PDF no lançamento; tratam como ciclo de vida dentro do sistema de entrega.
A Comissão Europeia descreve uma implementação em fases. O Act entrou em vigor em agosto de 2024, com práticas proibidas e obrigações de alfabetização em IA já aplicáveis desde fevereiro de 2025. Governança e obrigações de IA de propósito geral começaram a valer em agosto de 2025. A Comissão também trata 2026 como um ano importante de aplicação, com datas posteriores para alguns sistemas de alto risco após o acordo de simplificação de 2026.
Para builders, a lição é simples: não espere um prazo único. Crie checks versionados de prontidão que possam se adaptar conforme guias, códigos de prática, padrões harmonizados e escopo do produto evoluem.
Quando um caso de uso pode afetar emprego, educação, acesso a serviços essenciais, segurança, migração, infraestrutura crítica ou comportamento de produto relacionado à segurança, classificação não é uma etiqueta escondida em uma planilha. Ela muda a arquitetura. Você precisa de inputs rastreáveis, outputs explicáveis quando apropriado, limitações documentadas, controles de segurança, supervisão humana, qualidade e monitoramento pós-mercado.
A pergunta de engenharia é: você consegue mostrar como o sistema foi construído, testado, lançado, monitorado e alterado? Se não consegue, está confiando em memória no lugar de evidência.
O exercício mais útil é transformar termos de política em critérios de aceite. "Supervisão humana" vira permissões administrativas, filas de review, botões de override, audit logs, material de treinamento e runbooks. "Precisão e robustez" vira suites de avaliação, testes adversariais, dashboards de monitoramento, versionamento de modelo e gates de release.
| Tema regulatório | Artefato de engenharia | Onde deveria viver |
|---|---|---|
| Inventário de IA | Registro com owner, papel, provider, modelo, fonte de dados, mercado e classificação. | Base de governança e metadados do repositório. |
| Documentação técnica | Diagrama de arquitetura, descrição do modelo, uso previsto, limitações, testes e release notes. | Docs-as-code junto ao serviço. |
| Governança de dados | Linhagem, checks de qualidade, análise de viés, controle de acesso, retenção e exclusão. | Catálogo de dados, CI e review de privacidade. |
| Supervisão humana | Fila de review, orientação ao operador, override, escalonamento e rollback. | UI do produto, painel admin, runbook e audit log. |
| Logs e monitoramento | Versão do modelo, classe de input, classe de output, status de decisão, erros, abuso e drift. | Observabilidade e fluxo de incidentes. |
| Gestão de mudança | Reavaliação de risco quando modelo, dado, mercado, feature ou provider muda. | Template de pull request e checklist de release. |
Eu construiria um gateway de release para IA entre desenvolvimento de produto e produção. Cada feature de IA teria que se registrar com um arquivo de inventário, declarar caso de uso, apontar para documentação de modelo e dados, definir thresholds de avaliação, expor campos de log e passar por policy-as-code antes do deploy.
Para times usando agentes, eu adicionaria uma regra: features de IA geradas por agente não podem ser mergeadas se o agente não atualizar a evidência. Se o código muda chamada de modelo, prompt, schema, caminho de dados ou fluxo de decisão, inventário, testes e monitoramento precisam mudar no mesmo pull request.
Regulação de IA não é só prazo jurídico. É pressão para tornar sistemas de IA legíveis. Boa engenharia já quer isso: ownership claro, comportamento observável, mudança controlada, afirmações testáveis e trilha de auditoria quando algo dá errado. Os times que vencem vão transformar compliance em subproduto de entrega disciplinada.
Artigo sobre EU AI Act para engenharia cobrindo compliance de IA, sistemas de IA de alto risco, inventário de IA, governança de dados, supervisão humana, logs, monitoramento, resposta a incidentes, documentação de modelo e gates de release.