Durante os últimos anos, a conversa em torno da Inteligência Artificial tem sido dominada por duas preocupações legítimas: capacidade e conformidade. O que a IA consegue fazer — e se está conforme com regras, normas e princípios éticos.

Essas duas dimensões são necessárias. Nenhuma é suficiente.

À medida que sistemas de IA deixam de ser experimentais e passam a operar em contextos reais — decisões, priorizações, recomendações com impacto — surge um terceiro eixo, frequentemente ignorado: governança operacional.

Não a governança declarada em políticas.
Não a governança descrita em relatórios.
Mas a governança que existe — ou não existe — enquanto o sistema funciona.

Este texto não questiona a importância da certificação, da auditoria ou do compliance regulatório. Reconhece o seu valor. O seu propósito é outro: introduzir uma distinção conceptual que, uma vez compreendida, altera irreversivelmente a forma como sistemas de IA são avaliados, defendidos e responsabilizados.

Certificação valida processos. Governação valida comportamento.

A maioria dos mecanismos de conformidade avalia intenções, não resultados

A maioria dos mecanismos de conformidade existentes hoje avalia intenções, procedimentos e documentação. Perguntam se existem políticas, se foram seguidos processos, se há evidência escrita de boas práticas.

Isso é necessário.
Mas não responde à pergunta central que importa quando algo corre mal:

Como é que o sistema se comportou?

Um sistema pode estar certificado e ainda assim:

• tomar decisões imprevisíveis,
• falhar sob exceção,
• escalar incorretamente,
• produzir resultados difíceis de explicar,
• ou gerar impactos que ninguém antecipou operacionalmente.

Quando isso acontece, a certificação não governa o incidente.
O relatório não responde.
A framework não atua.

A responsabilidade permanece — sempre — no operador humano e na organização que colocou o sistema em produção.

O equívoco confortável da conformidade declarativa

Existe hoje um conforto institucional generalizado: a ideia de que a conformidade documental equivale a governação real. De que cumprir checklists, adotar frameworks e obter certificações cria uma espécie de transferência implícita de responsabilidade.

Não cria.

Em contexto regulatório — e em particular no espírito do AI Act europeu — a responsabilidade não é terceirizável. Nenhuma certificação substitui o dever de prever, mitigar e controlar o comportamento de sistemas que influenciam decisões.

A lei aponta consistentemente para:

• responsabilidade humana,
• previsibilidade,
• capacidade de explicação,
• mitigação prévia de risco.

Nada disto acontece por existir um certificado.
Acontece — ou não — por design do sistema.

Quando o problema não é legal nem técnico

Muitas das chamadas “dificuldades de implementação” da regulação em IA não são, na prática, problemas legais. Nem sequer são problemas técnicos no sentido clássico.

São problemas arquiteturais.

Resultam de sistemas que nunca foram concebidos para serem governados:

• modelos ligados diretamente a decisões,
• prompts usados como mecanismo de controlo,
• ausência de contenção por design,
• inexistência de resposta estruturada a exceções,
• logs que existem mas não explicam nada.

Nestes sistemas, a conformidade torna-se cara porque é defensiva.
Cada auditoria exige explicações.
Cada alteração exige reavaliação.
Cada incidente reabre o processo.

Não porque a lei seja excessiva — mas porque o sistema é frágil.

O teste mais simples (e mais ignorado)

Existe uma forma extremamente simples de avaliar se um sistema de IA é governável. Não requer frameworks complexas nem relatórios extensos.

Basta uma pergunta:

Existe governação operacional deste sistema?

Não “existe uma política”.
Não “existe um responsável nomeado”.
Não “existe um documento”.

Existe governação enquanto o sistema decide?

Se a resposta for não, então:

• o resto explica-se,
• os custos explicam-se,
• a ansiedade jurídica explica-se,
• e a fragilidade do compliance explica-se.

Quando não há governação, o problema não é a IA.
É o sistema.

Porque o prompt se tornou um sintoma

Um dos sinais mais claros de ausência de governação é a dependência excessiva de prompt.

Quando organizações tentam controlar comportamento apenas por linguagem — ajustando frases, restringindo instruções, afinando wording — estão, na prática, a compensar a falta de estrutura.

Prompting excessivo é um sintoma, não uma solução.

Um sistema governado:

• não depende da perfeição do prompt,
• não confunde instrução com controlo,
• não delega responsabilidade no modelo.

O modelo responde.
O sistema decide.

Essa separação é fundamental — e raramente existe.

Auditoria formal vs auditoria substantiva

Auditorias formais avaliam conformidade com requisitos definidos.
Auditorias substantivas avaliam comportamento observado.

A maioria dos sistemas atuais só suporta a primeira.
A segunda exige algo mais profundo: rastreabilidade real, previsibilidade e capacidade de reconstrução de decisões.

Quando um auditor precisa de:

• múltiplos workshops,
• explicações orais,
• documentos produzidos à pressa,
• interpretações posteriores,

não está a auditar comportamento.
Está a reconstruir narrativa.

Isso não é culpa da auditoria.
É consequência da arquitetura.

O papel legítimo da certificação (e o seu limite)

Certificação, auditoria e frameworks têm um papel legítimo e indispensável:

• criam linguagem comum,
• estabelecem mínimos,
• organizam expectativas,
• ajudam a alinhar organizações complexas.

O erro não está nelas.
Está em esperar que façam o que não foram desenhadas para fazer.

Nenhuma certificação governa um sistema em runtime.
Nenhuma auditoria substitui decisões arquiteturais.

O efeito mais interessante de sistemas verdadeiramente governados é outro: tornam o trabalho de certificação mais simples, mais barato e mais defensável.

Não por magia.
Mas porque o esforço desloca-se de explicação para verificação.

O custo real do AI compliance

O custo elevado do AI compliance não nasce da regulação.
Nasce da ausência de governação.

Sistemas não governados exigem mais horas humanas.
Cada mudança exige novo ciclo de avaliação.
Cada exceção gera retrabalho.
Cada incidente gera defensividade.

Governança por design não elimina compliance.
Elimina incerteza.

E incerteza é o que torna compliance caro.

Responsabilidade estrutural, não retórica

Em última análise, tudo converge para uma questão simples: quem governa o sistema quando ele opera fora do previsto?

Quando essa resposta é difusa — “depende”, “o fornecedor”, “o modelo”, “o processo” — o risco é estrutural.

A governação não é um papel.
É uma propriedade do sistema.

E essa propriedade não se adiciona depois.
Desenha-se antes.

Um deslocamento inevitável

À medida que a IA se integra em processos críticos, o mercado vai sofrer um deslocamento silencioso:

• de certificados para arquitetura,
• de intenção para comportamento,
• de conformidade declarada para governação operacional.

Não por ideologia.
Por necessidade.

Porque quando algo corre mal, ninguém pergunta pelo certificado.
Pergunta como o sistema foi concebido.

Fecho

Este texto não propõe soluções.
Não convida ao debate.
Não faz recomendações operacionais.

Limita-se a estabelecer um critério:

Quando não existe governação operacional, a conformidade explica-se — mas não protege.

A partir desse ponto, cada organização decide o que fazer com essa constatação.

Algumas continuarão confortáveis no papel.
Outras perceberão que governar sistemas de IA é uma questão estrutural, não declarativa.

E essa distinção, uma vez vista, não pode ser desvista.