Quando um modelo de linguagem é usado para triagem de currículos, quem responde pelo viés que ele reproduz? A empresa que o treinou, a startup que o implantou, ou o regulador que não definiu limites claros para essa aplicação? Essa pergunta não é hipotética — ela está no centro do debate sobre regulamentação de inteligência artificial que ganha força em 2026. A frase que abriu o resumo do Olhar Digital — "Regular a IA não significa simplesmente proibir usos problemáticos. A ideia é estabelecer níveis de proteção de acordo com o impacto de cada aplicação" — captura bem o espírito da abordagem baseada em risco, mas, como engenheiro que já implementou sistemas de IA em produção, sei que a tradução desse princípio para o cotidiano do desenvolvimento é bem menos óbvia do que parece.
A regulamentação por nível de risco não é uma novidade teórica. O AI Act europeu já estrutura esse modelo há anos, classificando aplicações em inaceitável (proibido), alto risco (sistemas críticos para direitos fundamentais, saúde, segurança), risco limitado (exigências de transparência) e risco mínimo (livre). O que muda agora é a pressão para que essa classificação se torne prática corrente também fora da Europa, influenciando desde startups de IA generativa até gigantes de hardware que embarcam modelos em dispositivos, como o rumorado iPhone 18 com recursos locais de IA. A questão técnica que enfrentamos é: como implementar, no nível do código e da arquitetura, um sistema que respeite esses "níveis de proteção" sem que a burocracia mate a agilidade do produto?
Da classificação de risco à engenharia de conformidade
A primeira dificuldade prática é que a classificação de risco de uma aplicação de IA raramente é binária ou estática. Um mesmo modelo, quando usado para recomendar filmes, pode ser considerado de risco mínimo; usado para diagnosticar câncer a partir de tomografias, salta para alto risco. Na minha experiência com produtos de IA em saúde, a definição do nível de risco exigiu não apenas uma análise de impacto algorítmico, mas uma arquitetura que permitisse alternar entre modos de operação — com e sem supervisão humana — dependendo do contexto de uso. Isso significa que os pipelines de inferência precisam ser desenhados com pontos de intervenção explícitos, logs de auditoria e mecanismos de fallback para decisões não automatizadas.
Do ponto de vista de engenharia de software, essa flexibilidade impõe trade-offs reais. Adicionar camadas de governança — como validação por um humano antes de uma recomendação ser executada, ou rastreabilidade completa das features que influenciaram a saída do modelo — aumenta a latência, o custo computacional e a complexidade do código. Em um sistema com alta taxa de requisições, como um chatbot de atendimento ao cliente, cada "humano no loop" pode custar segundos preciosos. Por outro lado, a ausência desses mecanismos expõe a empresa a multas regulatórias e danos de reputação que podem ser fatais. O equilíbrio não está em uma regra geral, mas em uma engenharia fina que considere o pior caso de uso dentro do escopo de cada implantação.
O IPO da Anthropic e a pressão por maturidade regulatória
A notícia de que a Anthropic considera abrir capital em 2026 não é apenas um marco financeiro; é um termômetro de como a regulamentação de IA está se tornando um fator crítico para valuation. Empresas de IA que buscam IPO precisam demonstrar que seus modelos são seguros, auditáveis e que respeitam os níveis de risco das jurisdições onde atuam. Na prática, isso significa que equipes de engenharia terão que implementar desde explicações contrafactuais para decisões de modelos até testes de robustez contra adversarial attacks, tudo documentado de forma rastreável. Quem já lidou com compliance em setores regulados, como finanças, sabe que esse tipo de exigência pode dobrar o tempo de desenvolvimento de um recurso. Para startups acostumadas com ciclos semanais de deploy, a transição é dolorosa.
Por outro lado, a abertura de capital também força uma disciplina de engenharia que muitas vezes falta em times focados apenas em performance de modelo. A exigência de explicabilidade, por exemplo, leva a arquiteturas mais modulares: em vez de um modelo monolítico, dividir o pipeline em componentes de extração de features, inferência e pós-processamento, cada um com seus próprios logs e testes de viés. Já vi projetos em que essa modularização, inicialmente vista como "burocracia", acabou melhorando a manutenibilidade e a capacidade de depuração do sistema. A regulamentação, nesse sentido, pode ser um catalisador de boas práticas de engenharia, e não apenas um empecilho.
iPhone 18 e a regulação no dispositivo: um novo front
O rumor sobre o iPhone 18 com funcionalidades de IA generativa rodando localmente ilustra outro desafio da abordagem por risco: como regular modelos que executam no dispositivo, sem comunicação constante com a nuvem? A vantagem da IA on-device é a privacidade — os dados não saem do aparelho. Mas a regulação baseada em risco muitas vezes pressupõe que o desenvolvedor tem controle total sobre o comportamento do modelo e pode auditá-lo a qualquer momento. Com modelos locais que podem ser atualizados pelo fabricante, mas também por terceiros (apps que distribuem pacotes de modelo), a rastreabilidade se torna nebulosa. A Apple, por exemplo, terá que garantir que os modelos embarcados em seu sistema operacional cumpram os requisitos de transparência e segurança mesmo quando o dispositivo estiver offline. Isso exige arquiteturas de assinatura digital de modelos, verificações de integridade em tempo de execução e, em alguns casos, sandboxing restrito.
Do ponto de vista do engenheiro, essa é uma área onde a teoria regulatória ainda está atrasada em relação à prática. Classificar um modelo local como "risco limitado" pode ser um erro se ele tomar decisões que afetam privacidade ou segurança do usuário sem supervisão (por exemplo, um assistente que concede permissões de acesso a dados). Minha opinião técnica é que a regulação precisará evoluir para considerar a arquitetura de implantação como um fator tão relevante quanto o domínio de aplicação. Um mesmo modelo pode ser de alto risco na nuvem e de risco baixo no dispositivo, dependendo da granularidade dos dados que ele processa localmente. A classificação não pode ser estática.
Trade-offs que ninguém menciona no debate público
Um ponto que frequentemente fica de fora da discussão sobre "regular por impacto" é o custo de implementação para pequenas e médias empresas. Enquanto gigantes como Anthropic, OpenAI ou Apple têm recursos para montar times dedicados de compliance, auditoria de modelos e testes de viés, startups que dependem de modelos pré-treinados de terceiros podem simplesmente não saber qual o nível de risco de seus próprios sistemas — porque o modelo é uma caixa-preta fornecida por uma API. A regulamentação, se mal desenhada, pode concentrar o mercado ainda mais nas grandes players, já que elas conseguem absorver os custos de conformidade. Como profissional que já trabalhou nos dois lados, acredito que a regulação deve prever mecanismos de certificação simplificada para usos de baixo risco, como chatbots de FAQ, e exigir certificação externa apenas para casos de alto risco, como diagnóstico médico ou decisões de crédito.
Outro trade-off importante é entre explicabilidade e performance. Modelos complexos, como grandes transformadores, são notoriamente difíceis de explicar. Exigir explicações contrafactuais ou feature importance para cada decisão pode inviabilizar o uso de arquiteturas de ponta em cenários onde a precisão é crítica, como detecção de fraudes em tempo real. A solução pragmática que tenho adotado é usar modelos substitutos (surrogate models) para fornecer explicações aproximadas, combinados com testes de robustez offline. Não é perfeito, mas é um compromisso realista entre o ideal regulatório e as limitações da matemática. Reguladores precisam entender que "explicabilidade total" é um mito para modelos modernos; o caminho é transparência sobre as limitações do modelo e garantias de que ele não será usado em contextos que exigem certeza.
Mercado de trabalho: o engenheiro de IA regulada
A ascensão da regulação cria novas demandas de habilidades. Engenheiros de software que entendem de governança de dados, auditoria de modelos e documentação de risco estarão cada vez mais valorizados. Não se trata apenas de saber treinar um modelo; é preciso saber como provar que ele é justo, robusto e auditável. Isso abre espaço para cargos como "AI Compliance Engineer" ou "ML Reliability Engineer", que combinam conhecimentos de MLOps com entendimento de normas como o AI Act. Para profissionais de cloud, a capacidade de projetar infraestrutura que suporte rastreabilidade e logs de inferência em escala se torna diferencial competitivo. O mercado de trabalho está mudando, e quem ignorar esse movimento pode ficar para trás.
Além disso, a própria mentalidade de produto precisa mudar. Já não basta lançar um recurso de IA porque "funciona bem"; é preciso documentar o caso de uso, classificar o risco, implementar testes de viés e preparar relatórios de impacto. Isso significa que product managers e engenheiros precisam trabalhar juntos desde a concepção, e não apenas no final do ciclo. Na minha experiência, essa integração precoce reduz retrabalho e evita surpresas regulatórias. O custo de adicionar uma camada de auditabilidade depois de o modelo estar em produção é muito maior do que desenhá-la desde o início.
Riscos de uma regulação mal calibrada
Por fim, é preciso reconhecer que a abordagem por nível de risco não é imune a falhas. Um risco claro é o chamado "checkbox compliance": empresas fazem o mínimo para se enquadrar na classificação (preenchem formulários, criam documentação superficial) mas não implementam de fato as mitigações necessárias. Isso acontece especialmente quando a regulação é genérica demais. Outro risco é a classificação excessivamente conservadora, que leva sistemas de alto benefício social a serem inviabilizados por custos de conformidade. Um exemplo hipotético: um modelo que detecta evasão escolar em tempo real, se classificado como "alto risco", pode exigir validação humana para cada alerta, tornando o sistema lento e ineficaz. Reguladores precisam calibrar o nível de exigência com base no benefício potencial, e não apenas no dano potencial.
Como engenheiro, minha posição é que a regulamentação baseada em risco é o caminho mais sensato, desde que seja co-construída com a comunidade técnica. Enquanto não tivermos padrões claros de como auditar modelos de linguagem para viés, como medir robustez em tempo de execução ou como documentar pipelines de features, a regulação será apenas um jogo de intenções. O que a indústria precisa é de ferramentas concretas — bibliotecas de auditoria, dashboards de risco, frameworks de testes — que tornem a conformidade algo que se automatiza, e não um exercício manual e subjetivo. Até lá, a responsabilidade recai sobre cada engenheiro que decide onde colocar o "humano no loop", como registrar a decisão do modelo, e qual o limite aceitável de viés para seu caso de uso. A regulação pode dar as regras, mas é o código que executa a proteção — ou a falta dela.