Governança de Modelos: Quem Assina em Baixo Quando a IA Erra?

Neste artigo · 11 seções

1. A pergunta que ninguém quer responder até que precisa
2. O que governança de modelos significa de verdade
3. Ownership: o conceito que precisa existir antes de qualquer modelo entrar em produção
4. Comitês técnicos: o passo que separa empresa madura de POC perpétuo
5. Processo de aprovação: as portas que cada modelo atravessa
6. Registro de decisões: a memória institucional
7. Aprovação de mudanças: nem toda atualização é igual
8. Resposta a incidentes: o teste real de governança
9. A relação com o fornecedor: quem responde pelo modelo subjacente
10. Conclusão
11. Insights & Takeaways

A pergunta que ninguém quer responder até que precisa

Acontece um incidente. Um modelo de IA em produção tomou uma decisão errada que afetou um cliente real. Pode ser uma negativa de crédito sem base, uma resposta com informação incorreta sobre política da empresa, uma classificação que disparou um processo equivocado. Chega notícia no jurídico, vira pauta de reunião com a liderança, alguém da auditoria interna entra na conversa. E aí vem a pergunta que ninguém quer responder:

Quem é responsável por isso?

O time de engenharia que implementou? Quem aprovou o deploy? O dono do produto? O fornecedor do modelo? A área de negócio que pediu a feature? Ninguém sabe direito, porque ninguém combinou antes. Cada um aponta pro outro, ou pior, ninguém aponta pra ninguém e o problema fica em um limbo organizacional até que o cliente desista, ou até que o regulador encerre a questão de forma menos confortável.

Esse padrão se repete na maioria das empresas que colocaram IA em produção sem combinar governança antes. Não porque os times sejam irresponsáveis; porque governança de modelo não vinha junto no pacote de implementação. Era assunto deixado pra depois, e depois virou o momento em que já havia incidente pra resolver.

Esse artigo é sobre como combinar essa parte antes. Quem assina embaixo, em que momentos, com base em que informação. Não é sobre burocracia; é sobre criar a infraestrutura mínima de responsabilidade que permite operar IA em produção sem que cada decisão vire risco difuso.

O que governança de modelos significa de verdade

Governança em IA é frequentemente confundida com compliance, e os dois se sobrepõem mas não são idênticos. Compliance é cumprir requisitos externos (LGPD, regulações setoriais, política interna). Governança é o conjunto de processos, papéis e registros que permitem que a organização tome decisões conscientes sobre o que o modelo faz, como evolui, e quem responde quando algo dá errado.

Em termos práticos, governança de modelos engloba quatro coisas:

Definição de ownership. Quem é dono de cada modelo em produção, no sentido de quem tem autoridade pra decidir mudanças e responsabilidade pelo comportamento.

Processo de mudança. Como modelos entram em produção, como são atualizados, como são desativados. Quem aprova cada etapa.

Registro de decisões. O que foi decidido, com base em que dados, por quem, quando. Auditável.

Resposta a incidentes. Quando algo dá errado, qual o caminho de investigação, comunicação e correção.

Sem essas quatro, governança vira documento esquecido na pasta compartilhada. Com elas, vira parte da operação.

Ownership: o conceito que precisa existir antes de qualquer modelo entrar em produção

Cada modelo em produção precisa ter um owner identificável. Não um time vago, uma pessoa nominal. Esse owner não precisa ser quem implementou; precisa ser quem tem autoridade pra responder por aquele modelo.

A definição típica de ownership envolve responder algumas perguntas concretas:

Quem decide mudanças no comportamento do modelo? Atualização de prompt, troca de modelo subjacente, mudança no pipeline de RAG. Essas decisões precisam ter um responsável.

Quem é acionado quando há reclamação relacionada ao modelo? Cliente reportou resposta errada, área interna identificou comportamento estranho. Tem que ter alguém pra acionar.

Quem aprova nova versão pra produção? Cada versão do modelo deveria passar por aprovação de quem tem autoridade pra dizer "estou ciente do que está mudando e aceito o risco".

Quem responde por incidentes? Se acontece problema, quem participa da resposta e da análise pós-incidente.

Em empresas maiores, ownership distribui entre um owner técnico (geralmente um tech lead ou arquiteto que entende a engenharia) e um owner de negócio (gerente de produto ou área que usa o modelo). Os dois assinam embaixo, cada um do seu ângulo. O owner técnico responde por comportamento e implementação; o owner de negócio responde por adequação ao caso de uso e impacto operacional.

Sem ownership claro, a primeira coisa que acontece num incidente é o famoso "vai com Deus" organizacional: ninguém sabe quem chama quem, e enquanto isso o problema continua.

Comitês técnicos: o passo que separa empresa madura de POC perpétuo

Em empresas com várias features de IA, ownership individual por modelo não basta. Precisa ter uma instância que olha o conjunto, define padrões, aprova exceções, e atua quando incidente passa o nível que um owner individual resolve.

Esse é o papel de um comitê de IA, que pode ter nomes diferentes (Comitê de IA, Conselho de Ética em IA, AI Review Board, Risk Committee, dependendo da empresa). O importante é a função, não o nome.

A composição típica funciona quando inclui:

Representante de engenharia, com profundidade técnica em IA. Pra entender o que está sendo proposto e discutir trade-offs com base técnica.

Representante de produto, com visão do impacto no usuário final. Pra avaliar adequação e priorização.

Representante de risco operacional ou compliance. Pra mapear consequências regulatórias e operacionais.

Representante de jurídico, em pelo menos parte das decisões. Especialmente as que envolvem decisões automatizadas com impacto pra cliente.

Representante de segurança da informação. Pra avaliar exposição de dados e vetores de ataque.

Esse comitê não é instância de aprovação de tudo. Vira gargalo se for. É instância de decisão pra:

Aprovar uso de IA em novos contextos sensíveis (regulados, com impacto financeiro direto, com dados sensíveis).

Definir padrões e políticas que se aplicam a todos os modelos da empresa.

Atuar em incidentes que ultrapassam o âmbito de um owner individual.

Decidir exceções a políticas estabelecidas, com registro do motivo.

Revisar periodicamente o portfólio de modelos em produção pra identificar riscos sistêmicos.

A frequência de reunião depende da maturidade. Em empresa que está estruturando, reuniões mensais ou quinzenais. Em empresa madura, reuniões mensais ou trimestrais com mecanismo de pauta extraordinária pra urgências.

Processo de aprovação: as portas que cada modelo atravessa

Antes de um modelo entrar em produção, ele deveria passar por alguns gates de aprovação. Não pra burocratizar; pra garantir que ninguém é pego de surpresa depois.

Cada gate tem um propósito específico:

Avaliação técnica. O time de engenharia revisa arquitetura, escolhas de modelo, qualidade de dados, segurança. Sai com lista de pontos a tratar ou aprovação técnica.

Avaliação de risco e compliance. Risco operacional revisa impacto potencial; compliance revisa adequação a regulações e políticas internas. Sai com mitigação exigida ou aprovação.

Aprovação dos owners. Confirmam que estão cientes do que está indo pra produção e assumem responsabilidade.

Aprovação do comitê em casos sensíveis. Para o que extrapola autoridade dos owners individuais.

Deploy controlado. Não vai direto pra produção completa. Shadow mode, canary release, ou rollout gradual permite detectar problemas com exposição limitada.

Monitoramento pós-deploy. As métricas combinadas no design são monitoradas. Se algo destoa, ação é tomada.

Esse processo soa pesado pra quem está acostumado a deploy contínuo. Mas duas observações importantes: nem todo modelo passa por todos os gates da mesma forma (modelos de baixo risco têm caminho mais leve); e os gates podem ser eficientes se forem operados como processo, não como burocracia. Comitê que se reúne semanalmente e decide em 15 minutos por proposta é eficiente; comitê que demora três meses pra agendar reunião é o que dá governança má reputação.

Registro de decisões: a memória institucional

Decisões sobre modelos precisam ser registradas. Não em e-mails dispersos; em um registro consultável que sobrevive a mudança de pessoas.

O que entra no registro:

Decisão de subir cada versão de modelo. Versão, data, owners aprovadores, eval set usado, métricas alcançadas, comparação com versão anterior.

Mudanças significativas. Troca de modelo subjacente, mudança de prompt principal, mudança de pipeline. Cada uma com justificativa e métricas que motivaram.

Decisões de exceção. "Decidimos aceitar esse risco específico porque..." Sem registro, exceções viram regra silenciosa.

Incidentes e suas resoluções. O que aconteceu, o que foi feito, o que mudou pra evitar repetir.

Esse registro pode ser num sistema de model registry (MLflow, Weights & Biases têm capacidades pra isso), num wiki estruturado, ou em ferramentas de governança específicas. O formato importa menos que a existência.

A pergunta que valida se o registro está cumprindo a função: "se a pessoa que tomou essa decisão sair da empresa amanhã, quem assume consegue entender o que foi decidido e por quê?" Se a resposta é não, o registro tem lacuna.

Aprovação de mudanças: nem toda atualização é igual

Modelos evoluem. Prompt é ajustado, modelo subjacente troca de versão, RAG pega documentos novos. Nem toda mudança precisa do mesmo nível de aprovação.

Categorias típicas que funcionam:

Mudança de baixo impacto. Ajuste fino de prompt, atualização de documentos no RAG, calibração de threshold. Owner técnico aprova, eval set roda no CI, deploy controlado.

Mudança de médio impacto. Troca de versão do modelo (mesmo provedor, modelo equivalente), mudança em pipeline de RAG, novo conjunto de tools. Owners técnico e de produto aprovam, eval set completo roda, monitoramento pós-deploy reforçado.

Mudança de alto impacto. Troca de provedor, troca de modelo pra um significativamente diferente, mudança no comportamento principal da feature. Aprovação do comitê, eval set rigoroso, deploy gradual com gates de promoção.

Mudança crítica. Aplicação em novo contexto sensível (regulado, com dados pessoais sensíveis, com impacto financeiro direto). Aprovação do comitê com participação de jurídico e risco. Revisão completa de governança.

Sem essas categorias claras, ou tudo vira aprovação pesada (e times param de tentar evoluir modelos), ou tudo vira mudança casual (e mudanças significativas escorregam pra produção sem revisão).

Resposta a incidentes: o teste real de governança

Governança boa não é a que evita 100% dos incidentes (não existe). É a que faz incidentes serem detectados rápido, respondidos com clareza, e aprendidos de forma estruturada.

O fluxo de resposta a incidente tem alguns elementos:

Detecção. Monitoramento ativo, ou reclamação do cliente, ou auditoria interna. O caminho de "como o problema chega na consciência do time" precisa estar definido.

Triagem inicial. Owner do modelo é acionado e avalia se é incidente real, qual a magnitude, se exige ação imediata. Tempo de resposta esperado precisa estar combinado (15 minutos? 1 hora? 24 horas?).

Contenção. Se o impacto é alto, o modelo é desligado ou rollback é executado. Não se debate; se contém primeiro.

Investigação. O que aconteceu? Por que? O log do AI Interaction (que discutimos no artigo de arquitetura) é essencial aqui. Sem o registro estruturado das chamadas, investigação é adivinhação.

Comunicação. Quem precisa saber? Cliente afetado, áreas internas, regulador em alguns casos. Tem fluxo definido?

Pós-mortem. Reunião pós-incidente. O que foi aprendido, o que vai mudar, quem vai fazer. Sem culpa pessoal, com foco em sistema.

Aprendizado institucionalizado. As lições viram melhoria em processo, em arquitetura, em eval set, em monitoramento. Sem isso, mesmo incidente acontece de novo daqui a seis meses.

O pós-mortem é a parte que mais separa governança de teatro. Pós-mortem que vira documento esquecido é tempo perdido. Pós-mortem que gera ações concretas com prazos e responsáveis, acompanhadas até conclusão, é o que faz a organização aprender.

A relação com o fornecedor: quem responde pelo modelo subjacente

Em muitas implementações, o modelo subjacente vem de um fornecedor externo. Isso adiciona uma camada à governança: o fornecedor também tem responsabilidades, e essas responsabilidades precisam estar contratualmente claras.

Algumas perguntas que valem ter respondidas:

O fornecedor notifica quando atualiza o modelo? Atualizações silenciosas geram drift que pode degradar comportamento sem aviso. Contratos sérios incluem notificação prévia.

O fornecedor responde por bugs do modelo? Em que medida? Limites de responsabilidade contratuais variam, mas precisam estar claros.

O fornecedor cumpre regulações que se aplicam ao seu setor? Em setores regulados, isso vira due diligence formal.

Existe processo de comunicação em caso de incidente que envolve o modelo? Telefone vermelho que funciona ou caminho via SAC do fornecedor?

Quanto mais crítico o uso, mais essas perguntas precisam ter respostas formais e contratuais. Em uso casual, contratos padrão de cloud bastam. Em uso crítico, contratos negociados com cláusulas específicas.

Conclusão

Governança de modelos não é burocracia adicionada depois do produto. É a infraestrutura mínima de responsabilidade que permite operar IA em produção com clareza sobre quem decide o que e quem responde por que.

A diferença entre empresa que opera IA com confiança e empresa que opera com risco difuso é exatamente essa: a primeira combinou ownership, processo de aprovação, registro de decisões e resposta a incidentes antes que precisasse. A segunda está descobrindo cada parte disso no meio do incidente.

A pergunta honesta que protege a empresa: "se um incidente sério com um dos nossos modelos acontecer amanhã, eu sei exatamente quem aciona quem, o que está documentado, e como respondemos?" Se a resposta vem com hesitação, governança tem lacuna que vai aparecer quando o incidente vier. E vai vir; é questão de quando, não de se.

Insights & Takeaways

1. Todo modelo em produção precisa de owner identificável, nominal, não vago. Sem isso, a primeira coisa que acontece num incidente é ninguém saber quem aciona quem, e o problema fica em limbo organizacional.

2. Comitê de IA com composição multifuncional (engenharia, produto, risco, jurídico, segurança) é o passo que separa empresa madura de POC perpétuo. Mas o comitê funciona se decide rápido em casos comuns; vira gargalo se demora.

3. Aprovação de mudanças deveria ter categorias com pesos diferentes. Sem isso, ou tudo vira aprovação pesada que paralisa evolução, ou tudo vira mudança casual e mudanças importantes escorregam.

4. Registro de decisões é memória institucional. Versão, justificativa, métricas, aprovadores. Se quem decidiu sair da empresa amanhã e quem assume não consegue entender o que foi decidido, o registro tem lacuna.

5. Pós-mortem que gera ações com responsáveis e prazos é o que faz a organização aprender. Pós-mortem que vira documento esquecido é tempo perdido. A diferença entre governança real e governança teatral está aqui.