Governança de IA que chega à produção é um conjunto de travas no pipeline, não um comitê no fim

A data em que as regras da União Europeia para sistemas de IA de alto risco começariam a valer mudou em dezesseis meses num único ano legislativo. Quando a Lei de IA (Regulamento 2024/1689) entrou em vigor, em agosto de 2024, suas obrigações para sistemas autônomos de alto risco, os usados em contratação, pontuação de crédito, educação e áreas semelhantes listadas no Anexo III, venciam em 2 de agosto de 2026. Em novembro de 2025, a Comissão propôs um "omnibus digital" para adiá-las. O Parlamento adotou o texto em 16 de junho de 2026, o Conselho o seguiu em 29 de junho, e o regulamento alterador foi publicado no Jornal Oficial em 24 de julho de 2026. As novas datas são 2 de dezembro de 2027 para os sistemas do Anexo III e 2 de agosto de 2028 para a IA embutida em produtos cobertos por legislação setorial de segurança, como máquinas e dispositivos médicos.

Uma equipe que montou seu programa de conformidade em torno da data de agosto de 2026 ganhou dezesseis meses. Uma equipe que o montou em torno de uma revisão documental antes do lançamento ganhou outra coisa, que é uma fila mais longa. O prazo mudou, e as obrigações não sumiram. Outras partes da Lei nunca foram adiadas: as proibições de certas práticas e o dever de letramento em IA valem desde fevereiro de 2025, as obrigações dos provedores de modelos de uso geral desde agosto de 2025, e os deveres de transparência do artigo 50 se aplicam a partir de 2 de agosto de 2026. O omnibus ainda acrescentou uma nova proibição, de sistemas que geram material de abuso sexual infantil e imagens íntimas não consentidas, com transição até dezembro de 2026.

O Brasil está num capítulo anterior da mesma história. O Senado aprovou o projeto de lei PL 2338/2023, um marco baseado em risco para a IA, em dezembro de 2024 e o enviou à Câmara dos Deputados, onde uma comissão especial o analisa. Segundo a cobertura mais recente que consegui verificar, de meados de 2026, as votações vinham sendo remarcadas, com os direitos autorais entre os pontos de impasse, e ele não havia sido sancionado. Convém que o leitor confira a situação atual, e o ponto prático vale de qualquer modo. Uma empresa que atua no Brasil e na Europa não pode esperar o texto legal se assentar para decidir como governa seus sistemas. A LGPD já se aplica. Seu artigo 20 dá aos titulares o direito de solicitar a revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses, inclusive perfis de crédito, e de pedir informações claras sobre os critérios utilizados.

Meu argumento é que essa incerteza é um motivo para desenhar a governança de outro modo. Quando o calendário legal não para de se mover, uma organização precisa de um mecanismo interno capaz de absorver mudanças nas regras sem ser reconstruído: níveis de risco, controles associados a cada nível e evidências coletadas à medida que o trabalho de engenharia acontece. Uma governança desse tipo chega à produção junto com o produto. A alternativa, um comitê que revisa uma apresentação de slides perto do fim do projeto, falha de duas maneiras, porque atrasa projetos bons e deixa passar os ruins.

Por que o comitê no fim falha

Um conselho de revisão que vê um sistema uma única vez, pouco antes do lançamento, tem a pior informação possível e o maior incentivo possível para aprovar. O projeto está construído, a equipe prometeu uma data, e as perguntas que o conselho pode fazer se limitam ao que os apresentadores escolhem mostrar. Se o conselho levanta uma preocupação séria, as opções são um redesenho caro ou uma exceção, e as exceções se acumulam.

Esse tipo de governança também trata todos os sistemas do mesmo modo. O assistente que resume anotações de reuniões internas passa pelo mesmo processo que o modelo que decide quem recebe um empréstimo, o que torna o processo pesado demais para o primeiro ou leve demais para o segundo. Na prática, é pesado demais para todos, e as equipes aprendem a evitá-lo chamando seus projetos de experimentos, que é como um sistema vai parar em produção sem que ninguém tenha decidido que ele devia estar lá.

Comece por um inventário e por um nível

A base é um registro de todo sistema de IA em uso ou desenvolvimento: sua finalidade, responsável, modelo e fornecedor, os dados que toca, quem é afetado por suas saídas e seu nível de risco atual. Sem ele, nada mais pode ser administrado, porque uma empresa não consegue governar o que não consegue listar. O registro deve incluir sistemas construídos por terceiros e embutidos em software comprado, já que a empresa continua responsável pelas decisões que esses recursos tomam sobre seus clientes e funcionários.

O nível decorre de uma lista curta de perguntas. O sistema toma ou informa de forma relevante decisões sobre o acesso das pessoas a crédito, trabalho, moradia ou serviços essenciais? Ele age por conta própria, ou uma pessoa revisa cada saída? Ele trata dados pessoais ou sensíveis? Atende o cliente diretamente? Um erro poderia causar um dano difícil de reverter? As categorias da UE oferecem um vocabulário útil mesmo fora da Europa: usos proibidos, usos de alto risco, usos com deveres de transparência e o resto. Para uma matriz interna, três níveis costumam bastar.

Controles associados aos níveis

Cada nível carrega um conjunto definido de controles. O conjunto cresce com o risco, e o nível mais baixo é deliberadamente leve para que os experimentos andem depressa.

Nível	Usos típicos	Exigido antes do lançamento	Exigido em operação
Baixo	Ajuda para redigir, busca interna, resumo de documentos para funcionários	Responsável nomeado, entrada no registro, verificação do tratamento de dados	Logs de uso, um canal para relatar problemas
Médio	Assistentes voltados ao cliente, roteamento e priorização com revisão humana	Suíte de avaliação com critérios de aprovação, testes de red team, revisão de privacidade, alternativa humana	Monitoramento de qualidade e deriva, reavaliação periódica, processo de incidentes
Alto	Decisões sobre crédito, contratação, sinistros, elegibilidade, segurança	Tudo o que está acima, mais finalidade prevista documentada, testes de viés e desempenho por subgrupo, relatório de impacto à proteção de dados, desenho da supervisão humana, aprovação jurídica	Monitoramento contínuo, trilha de auditoria das decisões, direito de revisão para os afetados, revisão independente programada

Os nomes dos controles importam menos do que a propriedade de que cada um possa ser verificado. Um controle que diz "garantir equidade" não pode ser conferido. Um que diz "relatar taxas de falso negativo e falso positivo para cada grupo que tenha ao menos 200 casos no conjunto de teste, e ter o relatório assinado pelo responsável do modelo e pelo líder de risco" pode ser conferido, e a falta do relatório bloqueia o lançamento.

Os arcabouços existentes ajudam a preencher o conteúdo. O NIST AI Risk Management Framework, publicado em janeiro de 2023 e ampliado por um Perfil de IA Generativa em julho de 2024, organiza o trabalho em quatro funções: governar, mapear, medir e gerenciar. A ISO/IEC 42001, publicada em 2023, define um sistema de gestão certificável para IA, que alguns clientes e reguladores aceitam como evidência de processo. Nenhum dos dois diz a uma empresa quais devem ser seus limites, o que é decisão do negócio, mas ambos fornecem listas de verificação que poupam a equipe de inventar a sua.

Ponha as travas no pipeline

O passo que transforma isto de política em prática é a automação. Cada controle vira uma verificação no pipeline de entrega, e a evidência dele é produzida pelo próprio trabalho.

A suíte de avaliação já existe numa equipe bem conduzida, de modo que seus resultados são a evidência de desempenho. A suíte roda a cada mudança no prompt, no índice de recuperação ou no modelo, e um lançamento é bloqueado se ficar abaixo do limite definido para o nível. O registro de versões de prompts e modelos fornece a trilha de auditoria do que foi implantado e quando. Ferramentas de linhagem de dados mostram de onde vieram os dados de treino e de recuperação, o que sustenta a avaliação de proteção de dados. As aprovações acontecem na mesma ferramenta da revisão de código, assinadas pelos papéis nomeados, de modo que o registro de quem aceitou qual risco fica ao lado da mudança a que se refere.

Um sistema de alto risco então não precisa de um projeto de conformidade à parte para reunir evidências antes de uma auditoria. A evidência é subproduto de construí-lo, e é possível mostrar o pipeline a um auditor. É isso também que torna o programa barato. O custo marginal de governança para um novo sistema do nível médio é o custo de escrever seus casos de avaliação, o que a equipe deveria ter feito de qualquer modo.

Considere um modelo de triagem de sinistros que recomenda quais sinistros de seguro pagar rapidamente e quais enviar para investigação. Ele está no nível alto, já que uma recomendação errada atrasa ou nega o pagamento a uma pessoa. A trava pede um dossiê de evidências que o pipeline em grande parte monta. Contém a finalidade prevista em duas frases, os resultados de avaliação com intervalos, as taxas de falso negativo e falso positivo por região e por segmento de cliente, as fontes de dados e a base legal para usá-las, o desenho da supervisão humana e o plano de monitoramento. A autoridade de liberação lê o dossiê, faz perguntas e assina ou recusa.

O desenho da supervisão merece exame, porque a supervisão pode ser meramente nominal. Um revisor que vê uma recomendação sem justificativas, sob uma cota de duzentos sinistros por dia, concordará com o modelo quase sempre. A Lei da UE pede uma supervisão que seja efetiva na prática. Um teste mensurável é a taxa de revogação. Se os revisores contrariam o modelo em 0% dos casos, ou o modelo é perfeito ou a revisão é carimbo, e a segunda explicação é a mais provável. Acompanhe as revogações, amostre-as todo mês e veja se as correções dos revisores estão certas.

Fornecedores e a carga compartilhada

Boa parte da exposição de uma empresa à IA chega dentro de software comprado. A Lei distingue provedores, que constroem ou colocam sistemas no mercado, de implantadores, que os usam sob sua própria autoridade, e dá aos implantadores deveres próprios para sistemas de alto risco: usar o sistema conforme as instruções, atribuir supervisão humana competente, monitorar a operação e guardar os logs que o sistema gera por um período adequado, que a Lei fixa em no mínimo seis meses. Os contratos devem, portanto, pedir aos fornecedores o que a empresa precisa para cumprir esses deveres: documentação do uso previsto e das limitações, acesso aos logs, aviso de incidentes e de mudanças relevantes no modelo e uma declaração de como os dados do cliente são usados. Um fornecedor que não consegue fornecê-los é um risco a registrar.

Direitos de decisão, e quem pode dizer não

As travas precisam de pessoas com autoridade para mantê-las. Para o nível alto, nomeie uma autoridade de liberação, em geral um líder de risco independente da equipe de entrega, e deixe escrito que a autoridade pode barrar um lançamento. Estabeleça quem pode conceder uma exceção, por quanto tempo e como ela é registrada. Sem um responsável assim, uma trava é uma sugestão, e a pressão para entregar a tratará como tal.

Mantenha a via rápida honesta também. Se um projeto de nível baixo leva seis semanas para ser liberado, as equipes vão disfarçar seus projetos de outra coisa. Defina metas por nível, por exemplo um dia para o baixo, uma ou duas semanas para o médio e um mês para o alto, e acompanhe-as. Uma equipe de governança que mede o próprio tempo de resposta tem muito mais chance de ganhar confiança.

Trate as regras como restrições que se movem

O omnibus mostra que a data de uma obrigação é a parte menos confiável de uma regulação. A estrutura é mais estável: a classificação baseada em risco, a ênfase em documentação, supervisão humana, qualidade de dados, transparência e monitoramento pós-comercialização. Um projeto que satisfaz a estrutura para cada nível resiste quando os prazos mudam. A prática sensata é construir para o requisito mais rigoroso provável do nível e tratar o calendário legal como o tempo disponível, não como o alvo do projeto.

O custo da falha também é grande o bastante para justificar o esforço. As penalidades da Lei de IA para práticas proibidas chegam ao maior valor entre 35 milhões de euros e 7% do faturamento anual mundial, e as da maioria das demais violações, a 15 milhões de euros ou 3%. Para uma empresa que vende para a Europa de fora, essas disposições podem se aplicar, já que a Lei alcança provedores e implantadores cujos sistemas têm saídas usadas na União.

Um programa de governança deve ser julgado por resultados que consiga medir. Acompanhe a fração de sistemas do registro com revisão em dia, o tempo mediano para liberar cada nível, o número de incidentes e a rapidez com que foram detectados e encerrados, e o número de exceções concedidas e ainda abertas. Tempos de aprovação crescentes no nível baixo são um aviso de que o processo está voltando ao comitê que substituiu. Uma fração decrescente de sistemas com revisão em dia significa que o registro virou decoração.

Um primeiro trimestre

Um primeiro trimestre razoável para uma empresa sem programa é assim. No primeiro mês, monte o registro pedindo a cada unidade de negócio que liste o que usa, inclusive ferramentas compradas, e atribua níveis provisórios. No segundo, defina os três níveis e seus controles em uma página e conecte as suítes de avaliação dos dois ou três sistemas mais importantes a uma verificação de lançamento. No terceiro, nomeie a autoridade de liberação do nível alto, passe um sistema por todo o caminho como ensaio e meça quanto tempo levou. O ensaio revelará quais controles são pouco claros ou impraticáveis, e é melhor descobri-los num ensaio do que durante uma auditoria.

Fontes

1. Regulamento (UE) 2024/1689 (Lei de Inteligência Artificial), Jornal Oficial da União Europeia, 12 de julho de 2024.
2. Regulamento (UE) 2026/1744 que altera a Lei de IA ("AI Omnibus"), publicado no Jornal Oficial em 24 de julho de 2026; Future of Privacy Forum, The AI Act implementation timeline: what changes under the AI Omnibus; Gibson Dunn, EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes.
3. Brasil. Projeto de Lei nº 2.338/2023 (marco legal da inteligência artificial), aprovado pelo Senado em 10 de dezembro de 2024; tramitação na Câmara dos Deputados, acompanhamento da imprensa especializada até meados de 2026.
4. Brasil. Lei nº 13.709/2018 (LGPD), arts. 6º e 20.
5. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0); e NIST AI 600-1, Generative Artificial Intelligence Profile (2024).
6. ISO/IEC 42001:2023. Information technology, Artificial intelligence, Management system.