A UE quer certificar a IA antes de a lançar. Mas não é assim que a IA falha.

Qualquer engenheiro que tenha posto algo a correr em escala aprendeu a mesma lição humilhante: não se consegue provar que um sistema complexo é seguro antes de ele correr. Revê-se o código, testa-se, raciocina-se sobre cada caminho que se consegue imaginar — e mesmo assim ele surpreende-nos em produção, porque produção é onde os inputs que nunca imaginámos acabam por aparecer. Por isso deixámos de fingir. Instrumentamos o sistema, observamo-lo, e desenvolvemos os reflexos para reagir quando ele faz algo que não previmos. A União Europeia está a regular a IA como se o contrário fosse verdade.

A 11 de junho, a Bruegel publicou um policy brief de Mario Mariniello — The right balance: how to fix European Union artificial intelligence regulation — que diz, na linguagem comedida de um think tank de Bruxelas, mais ou menos o que um SRE nos diria depois de uma má noite de plantão: o AI Act aposta demasiado em provar a segurança antes do deployment, e muito pouco em apanhar o dano depois dele. E põe um preço na aposta. Citando Haataja e Bryson, Mariniello estima a conformidade de um sistema de IA médio entre 14 623 € e 29 277 € — 9 a 17 por cento de um orçamento de desenvolvimento de 170 000 €. Leia-se em dinheiro: entre 9 e 17 cêntimos de cada euro que se gasta a construir um sistema de IA vão para provar que ele é conforme, antes de chegar a um único utilizador.

Lanço sistemas de IA em produção que caem sob este regime, e antes disso passei anos em DevOps e resposta a incidentes, onde o trabalho todo vivia no fosso entre o que tínhamos assinado e o que de facto acontecia às 3 da manhã. Na Conectia construímos a nossa pré-seleção de candidatos segundo as regras de alto risco do AI Act antes de a lei lá chegar por isso não sou um estranho a resmungar contra a burocracia. Paguei esta fatura de propósito. O meu problema não é que a Europa regule a IA. É que gasta o máximo de rigor no único dia em que sabe menos.

Não se certifica um sistema cujo comportamento se descobre depois do lançamento

O AI Act ordena os sistemas pela sua finalidade prevista no momento em que são colocados no mercado, e demonstra a segurança em grande parte através de papelada de conformidade entregue antes do lançamento. Mas a IA não fica quieta para a fotografia. A maior parte das capacidades reais de um modelo — e dos seus modos de falha reais — descobre-se depois do deployment (o brief apoia-se em Bengio et al., 2024, para isto, e quem já lançou uma funcionalidade com LLM já o sente no corpo). Um sistema que é de risco mínimo no dia do lançamento torna-se de alto risco no momento em que um utilizador faz algo que quem o desenvolveu nunca pretendeu e não controla.

As provas acumulam-se precisamente na categoria que o Act deixa passar como de baixo risco: os chatbots. Um estudo de maio de 2026 sobre perguntas eleitorais na Escócia concluiu que 34,1% das respostas dos chatbots de IA continham erros factuais sobre como votar. No Nevada, quatro em cada cinco chatbots testados deram informação errada sobre o recenseamento eleitoral. E em agosto de 2025, Raine contra OpenAI levou o papel de um chatbot no suicídio de um adolescente perante um tribunal de São Francisco. Nenhum destes danos é algo que uma checklist pré-lançamento pudesse ter apanhado — porque nenhum deles existia no lançamento. A conformidade ex ante certifica uma fotografia. O sistema é um filme.

Já saímos deste filme antes, chama-se waterfall

Os engenheiros já correram esta experiência exata, e fomos embora. Durante anos tentámos certificar uma release como correta antes de a lançar: aprovações, comités de aprovação de mudanças, uma porta que se passava uma vez e depois se rezava. Abandonámo-la — não por nos termos tornado imprudentes, mas porque a prova nunca conseguia acompanhar o ritmo da mudança. Todo o movimento DevOps e SRE foi a migração do rigor de antes da release para à volta do sistema em funcionamento: observabilidade, error budgets, rollback, postmortems sem culpados. Não deixámos de nos importar com a segurança. Mudámo-la para onde o risco realmente vive.

Infraestrutura de deteção modelada no sistema Sentinel da FDA — amostrar o tráfego em produção, vigiar eventos adversos quase em tempo real. Um esquema de reporte de quase-acidentes sem caráter punitivo modelado no da aviação, o Aviation Safety Reporting System que funciona desde 1976 — que é um postmortem sem culpados à escala da indústria. Uma taxonomia normalizada de incidentes e um registo público, construídos sobre o quadro de 2025 da OCDE, para que todo o mercado aprenda com cada falha uma vez em vez de cada empresa a aprender à força. Instrumentar, reportar, responder. Confio nesta abordagem por uma razão maçadora: é assim que já giro tudo aquilo de que sou responsável.

A fatura à cabeça entrega discretamente o mercado aos incumbentes

Há um segundo problema em carregar o custo no início, e nada tem a ver com segurança — tem a ver com quem fica de pé no fim. Essa fatura de conformidade não escala para baixo. Quinze a trinta mil euros e um sistema de gestão de qualidade são um erro de arredondamento para uma empresa grande e um muro para uma startup de duas pessoas. O RGPD contribuiu para a concentração do mercado ao penalizar de forma desproporcionada as empresas mais pequenas. Assim, um regime vendido como proteção das pessoas contra a IA poderosa pode acabar discretamente por proteger as empresas de IA poderosas da concorrência.

Há uma correção que vai buscar inspiração ao Digital Services Act: graduar o peso ao alcance do deployment. Um nível de auditoria leve para PME — abaixo de 50 M€ de faturação, ou menos de 100 000 pessoas afetadas — e apenas para usos de dano reversível; um nível padrão no meio; e um nível intenso para os gigantes, acima de 150 M€ ou mais de um milhão de pessoas afetadas, onde a avaliação por terceiros é obrigatória e a autocertificação acaba. Ajustar o escrutínio ao raio de impacto, em vez de apontar uma única porta a toda a gente. Vale a pena olhar para quem estaria a fazer essa deteção hoje: mais de 2000 autoridades nacionais de fiscalização do mercado, a maior parte concebida para inspecionar produtos físicos, contra um AI Office de cerca de 125 pessoas — o tipo de aplicação fragmentada que já atrasa as regras tecnológicas da UE. O aparato pensado para apanhar um algoritmo perigoso foi em grande parte desenhado para apanhar uma torradeira perigosa.

«Lançar e observar» é também uma ótima forma de deixar o dano acontecer primeiro

Aqui está a objeção mais forte, e não a vou contornar: a monitorização ex post pode soar a «mexe-te depressa e parte coisas» com a bênção do regulador. E o custo é real e feio — o ex post significa que o dano às vezes acontece antes de a resposta chegar. Um registo de incidentes não faz nada pelo adolescente do caso Raine. Uma eleição envenenada por desinformação de chatbots não se faz rollback como um deploy mau. Quem vender a monitorização puramente a posteriori como um upgrade limpo está a enterrar esse número, e não o devem deixar.

Mas não é essa a proposta, e o eixo que a resolve é a irreversibilidade. Não se observa-e-responde através de um diagnóstico médico ou de um carro autónomo — aí a porta mantém-se à cabeça, e Mariniello mantém a responsabilidade objetiva para os sistemas proibidos e de alto risco precisamente porque o dano pode ser grave e definitivo. O nível de toque leve está explicitamente cercado ao dano reversível — emprego, scoring de crédito — e não a diagnósticos ou veículos autónomos. Por isso a tese verdadeira não é «ex ante mau, ex post bom». É pôr porta no que não se pode desfazer; instrumentar o que se pode.

E mais uma ressalva honesta, porque corta contra a ideia toda: o ex post só funciona se a deteção for real. A própria aplicação a posteriori do RGPD foi fragmentada e subdimensionada. Se a Europa muda o peso para o «depois» e depois subfinancia o «depois» — 125 pessoas, 2000 autoridades desajustadas, e ainda nenhum quadro de responsabilidade específico para a IA — não reequilibrou nada. Desregulou e chamou-lhe monitorização. Mariniello tem um nome para a versão global desse escorregar: «desregulação mutuamente assegurada». A peça da responsabilidade é crucial: tirar o ónus da prova de cima da vítima, com uma presunção ilidível de defeito para os sistemas correntes, para que um utilizador lesado não seja obrigado a fazer engenharia inversa de um modelo que não consegue ver. A Diretiva da UE sobre Responsabilidade decorrente de Produtos só se torna aplicável a 9 de dezembro de 2026. Até a deteção financiada e a responsabilidade real estarem ambas em vigor, «ex post» é só uma palavra mais bonita para «ninguém está a vigiar».

O que eu poria na minha stack de IA independentemente do caminho que Bruxelas seguir

O que há de discretamente útil no kit ex post de Mariniello é que a maior parte dele é só boa engenharia que se devia ter, à margem da lei. Se eu estivesse a montar — ou a auditar — um produto de IA neste trimestre, é este o trabalho, e nada dele espera por uma regulação:

1. Mapeia a cadeia de responsabilidade antes de lançar, não depois do processo judicial. Para cada funcionalidade de IA, escreve quem fica na linha de fogo quando ela causa dano a um utilizador: tu, o fornecedor do modelo, a fonte dos dados. O exemplo do crédito à habitação negado por engano de Mariniello — banco, programador, fornecedor do LLM, fornecedor dos dados de treino, todos a apontar uns para os outros — é o teu RACI de incidentes. Se essa célula estiver em branco, o réu por omissão és tu.
2. Mantém já o teu próprio registo de incidentes. Adota a taxonomia de incidentes da OCDE e regista hoje cada falha de IA segundo ela. Não esperes por um registo obrigatório da UE para começares a aprender com as tuas próprias avarias.
3. Abre um canal de quase-acidentes sem culpados. O sistema de reporte da aviação funciona porque reportar é seguro. Torna seguro para os teus engenheiros assinalarem o modelo a fazer algo estranho antes de isso se formar num postmortem.
4. Amostra o teu próprio tráfego. Põe observabilidade nos inputs e outputs do modelo como monitorizarias qualquer serviço em produção — drift, respostas anómalas, os casos de uso para que nunca o desenhaste. É a ideia do Sentinel à escala da empresa, e é assim que encontras o uso de alto risco antes de um regulador ou um jornalista o fazer.
5. Gradua o teu próprio escrutínio pela irreversibilidade, não pelo organograma. Concentra a revisão humana onde uma resposta errada não pode ser desfeita; deixa o trabalho reversível andar depressa por trás da monitorização. É a tese inteira do brief, aplicada um andar abaixo — e é só boa priorização.

Regular a IA como um sistema que corre, não um produto que se lança

O equilíbrio certo nunca foi «mais regulação» ou «menos». É regulação apontada ao momento onde o risco realmente vive. O AI Act gasta o seu rigor no dia do deployment — o único dia em que menos sabemos sobre como o sistema se vai comportar — e fatura-o a toda a gente por igual, o que cai com mais força sobre os mais pequenos. A correção de Mariniello é mudar esse rigor para onde os engenheiros já guardam o deles: à volta do sistema em funcionamento, escalado ao alcance, proporcional ao que não se pode desfazer, e pago sobretudo por quem for grande o suficiente para o suportar. Isso não é desregulação. É a maturidade operacional para a qual o resto de nós foi forçado há anos — a noite em que aprendemos que não se prova que um sistema é seguro, só se pode observá-lo de perto e estar pronto a agir.

O brief defende que a UE não devia esperar até 2031 para alterar o Act. Eu iria um passo mais longe: não esperem por Bruxelas de todo. A disciplina de observabilidade e de incidentes que faria a regulação ex post funcionar de facto é a mesma disciplina que faz o teu produto sobreviver ao contacto com utilizadores reais. Se ainda estás a mapear onde o AI Act aterra na tua própria stack, começa por como Bruxelas reclassificou uma ferramenta de contratação vulgar como alto risco — e depois vai construir a vigilância, porque o regulador acabará por perguntar se o fizeste.