O que uma revisão burocrática revela sobre a maturidade técnica do setor
Em 24 de julho de 2026, a União Europeia publicou o chamado Digital Omnibus on AI — Regulamento (UE) 2026/1744 —, que representa a primeira revisão formal do AI Act desde sua adoção em 2024. A alteração mais noticiada foi o adiamento de prazos para sistemas de IA classificados como "de alto risco". Para o engenheiro de software que está na trincheira, essa notícia não deve soar como alívio. Ao contrário: ela escancara a distância entre o que a letra da lei exige e o que a infraestrutura técnica atual consegue entregar.
Passei os últimos anos lidando com arquiteturas de sistemas que processam dados sensíveis em nuvem, e posso afirmar que regulamentações como essa não são apenas textos legais — são especificações técnicas que impactam diretamente decisões de design, custos operacionais e prazos de entrega. Quando a UE adia a aplicação de regras para IA de alto risco, não está apenas dando mais tempo para as empresas se adaptarem. Está, de fato, reconhecendo que existem gargalos técnicos e operacionais que o mercado ainda não resolveu.
Este artigo não vai recontar o que a legislação diz. Vou analisar por que esse adiamento importa para quem projeta, desenvolve e opera sistemas de IA em produção — e o que podemos aprender com esse sinal vindo de Bruxelas.
O problema real não é o prazo, é a implementação
Para entender a relevância desse adiamento, é preciso sair da superfície. O AI Act classifica como alto risco sistemas usados em áreas como recrutamento, crédito, aplicação da lei, infraestrutura crítica e acesso a serviços essenciais. A exigência central é que esses sistemas passem por avaliação de conformidade antes de chegar ao mercado. Isso inclui documentação técnica detalhada, registro público, supervisão humana efetiva e — ponto crítico para engenheiros — explicabilidade sobre o funcionamento do modelo.
Traduzindo para o nosso dia a dia: o time de produto precisa demonstrar que o modelo não está enviesado, que os dados de treinamento são representativos, que os resultados são auditáveis e que um operador humano pode reverter decisões automatizadas. Isso soa razoável no papel. Na prática, porém, implementar auditoria contínua para modelos de aprendizado profundo, especialmente aqueles baseados em transformers ou arquiteturas de rede neural complexas, é um desafio de engenharia da mais alta ordem.
Já vi projetos inteiros travarem por meses na tentativa de produzir logs de inferência que sejam simultaneamente completos para auditoria e eficientes para armazenamento. Quando o AI Act fala em "documentação técnica", o que está por trás são pipelines de CI/CD adaptados, testes de bias automatizados, versionamento de datasets e modelos, e uma infraestrutura de observabilidade que raramente existe fora de empresas de tecnologia de primeiro mundo.
Os trade-offs técnicos que a lei ignora
Um dos pontos mais interessantes dessa revisão é que ela reconhece, implicitamente, a complexidade de estabelecer padrões técnicos universais. A lei exige, por exemplo, que sistemas de alto risco sejam treinados com dados "relevantes, representativos e livres de erros". Qualquer engenheiro de ML sabe que datasets "livres de erros" não existem em produção. O que existe é um trade-off contínuo entre qualidade dos dados e viabilidade operacional.
O adiamento dá fôlego para que consórcios técnicos e organismos de normalização — como o CEN-CENELEC — terminem de redigir as normas harmonizadas que vão dizer, em termos concretos, como implementar essas exigências. Sem essas normas, cada empresa faz sua interpretação, o que gera insegurança jurídica e, mais grave, diferenças profundas na qualidade da conformidade. Empresas com times de ML maduros conseguem implementar trilhas de auditoria robustas; startups de IA com equipes enxutas podem acabar empurrando soluções de fachada que passam pelo checklist formal, mas não garantem segurança real.
Outro trade-off que merece atenção é o custo computacional da explicabilidade. Técnicas como LIME e SHAP, comuns para interpretar modelos tabulares, se tornam computacionalmente proibitivas em modelos de linguagem com centenas de bilhões de parâmetros. O adiamento dos prazos pode ser lido como um reconhecimento de que a indústria precisa de mais tempo para desenvolver métodos de interpretabilidade viáveis para modelos de última geração — ou, quem sabe, abandonar de vez a pretensão de que todo modelo de alto risco precisa ser totalmente explicável, em favor de uma abordagem mais pragmática baseada em testes de comportamento.
O que muda no roadmap de produtos digitais
Quem trabalha com produtos digitais sabe que um prazo regulatório que se move é um risco de planejamento. Times de produto que estavam correndo para entregar conformidade até 2026 agora podem recalibrar. Mas atenção: adiamento não é suspensão. O que a UE fez foi postergar a aplicação de sanções para sistemas de alto risco já em uso, não cancelar as obrigações. Empresas que usarem esse tempo extra apenas para adiar investimentos em governança de IA vão se lascar quando a regulamentação finalmente entrar em vigor.
Na minha experiência, o movimento mais inteligente é usar esse fôlego para construir fundação técnica, não para empurrar a conformidade com a barriga. Isso significa implementar agora:
- Sistemas de versionamento de modelos e datasets — não adianta ter um modelo auditável se você não consegue reproduzir a versão exata que tomou uma decisão seis meses atrás
- Pipelines de teste de bias automatizados — integrados ao processo de deploy, não como uma etapa manual e eventual
- Logs de inferência estruturados — com informações suficientes para rastrear decisões sem explodir o custo de armazenamento
- Mecanismos de intervenção humana — que não sejam apenas um botão fictício, mas sim fluxos de aprovação reais incorporados ao sistema
Essas não são tarefas que se resolvem em um sprint. Em organizações que construí do zero, a implantação de um sistema razoável de governança de modelos levou entre seis e doze meses, dependendo da maturidade da equipe de dados. Quem começar esse processo só quando o prazo final estiver próximo vai entregar soluções frágeis.
Riscos, limitações e a visão crítica que falta ao debate
Precisamos ser honestos sobre as limitações desse modelo regulatório. A classificação de "alto risco" é binária, mas a realidade técnica é contínua. Um sistema de recomendação de conteúdo para crianças pode ter um risco social muito maior que um sistema de recrutamento bem projetado, mas a categorização legal não captura essa nuance. O adiamento não corrige essa rigidez conceitual — apenas empurra o problema para frente.
Outro risco é o da fragmentação do mercado. Grandes empresas de tecnologia, com times jurídicos robustos e infraestrutura global, conseguem absorver o custo da conformidade e transformá-lo em barreira de entrada. Startups europeias de IA podem acabar desfavorecidas, não por falta de talento, mas por incapacidade de arcar com a burocracia técnica exigida. O resultado paradoxal pode ser uma Europa com regulação exemplar, mas com um ecossistema de inovação em IA mais concentrado e menos vibrante.
Também não podemos ignorar o risco de que o adiamento crie uma falsa sensação de segurança no mercado. Se sistemas de alto risco continuam operando sem fiscalização efetiva durante o período de transição, e se um incidente grave ocorrer — digamos, um sistema de diagnóstico médico com viés racial causar danos reais —, a reação política pode ser um endurecimento excessivo e mal calibrado das regras. Esse cenário de "pêndulo regulatório" já vimos em outros setores, como na privacidade digital pós-Case Snowden.
O que engenheiros e líderes de produto devem fazer agora
Se eu pudesse dar um conselho direto para colegas engenheiros e gestores de produto que estão nesse dilema, seria este: não trate a regulação como um problema exclusivo do jurídico ou do compliance. O AI Act, em sua essência, é um conjunto de requisitos de engenharia de software — qualidade de dados, rastreabilidade, auditabilidade, segurança. Times de engenharia que incorporarem esses princípios como parte da cultura de desenvolvimento, e não como uma camada adicional de burocracia, vão sair na frente.
Algumas ações práticas para começar agora:
- Faça um mapeamento dos sistemas de IA que sua empresa opera e classifique-os segundo os critérios do AI Act — não espere o jurídico fazer isso sozinho
- Inicie um processo de documentação técnica dos modelos, mesmo que preliminar — o custo de reconstruir retrospectivamente é muito maior que o de manter atualizado
- Converse com provedores de nuvem sobre as ofertas de conformidade para IA — AWS, Azure e GCP já estão lançando serviços específicos para atender a requisitos regulatórios, e pode ser mais barato terceirizar parte da infraestrutura de auditoria
- Participe de grupos de normalização técnica — a voz de quem implementa precisa estar representada nas discussões que vão definir as normas harmonizadas
O prazo adiado não é um cheque em branco
A revisão de 2026 não é um evento isolado. Ela inaugura um ciclo de ajustes que provavelmente se repetirá. O AI Act é um marco legal vivo, e a intenção declarada da Comissão Europeia é revisá-lo periodicamente. Isso significa que os requisitos vão evoluir, os prazos podem se mover novamente, e o que hoje é considerado conformidade aceitável amanhã pode ser insuficiente.
Para quem constrói sistemas de IA professionalmente, o recado é claro: regulação não é um obstáculo a ser contornado, mas sim uma especificação técnica a ser incorporada. As empresas que entenderem isso — e agirem agora, não quando o próximo prazo estiver batendo na porta — vão construir produtos mais robustos, confiáveis e, acima de tudo, sustentáveis no longo prazo. A União Europeia nos deu mais tempo. Cabe a nós não desperdiçá-lo fingindo que o problema é só do jurídico.