Existe uma pergunta capaz de derrubar qualquer política de governança de IA em trinta segundos. Ela foi formulada por David DuChene, gerente de pré-vendas de dados e IA da SHI International, e funciona como um raio X.
Se o seu sistema de IA gerar uma resposta errada e custar dinheiro à empresa amanhã, quem vai ser o responsável?
David DuChene, SHI International, à Computerworld
Se a resposta demora, ou se ela é um nome de área em vez de um nome de pessoa, a responsabilização não existe. Existe um documento. E documento não responde por prejuízo.
Uma reportagem da Computerworld reuniu líderes de TI para mostrar como transformar responsabilização de IA em algo exigível. Neste artigo eu vou além do diagnóstico: pego os seis movimentos que eles descrevem e amarro cada um a um padrão formal (NIST, ISO, AI Act) e à realidade regulatória brasileira, para que a coisa saia do slide e vire processo.
Por que a responsabilização quebra quando a IA age
Software tradicional é determinístico: mesma entrada, mesma saída. Sistemas inteligentes produzem resultados imprevisíveis à medida que interagem dinamicamente com dados, APIs e fluxos de negócio. Quando algo dá errado, a culpa cai sobre quem estava mais perto da dor, e não sobre quem tinha a responsabilidade.
O deslocamento decisivo é de papel: a IA deixou de ser conselheira e virou executora dentro do fluxo. Enquanto ela apenas sugeria, a última palavra era humana e a cadeia de responsabilidade se resolvia sozinha. Agora ela clica, escreve, aprova e envia. É o mesmo salto que descrevemos em CRM autônomo, com agentes que agem sozinhos na retenção e em comércio agêntico.
Os seis movimentos que tornam a responsabilização possível
1. Dono único, definido no dia zero
Joe Wilson, vice-presidente sênior e CIO da CSG, é categórico sobre o modelo mais comum nas empresas, o da responsabilidade compartilhada.
Responsabilidade compartilhada não é responsabilidade. Você precisa de um dono direto.
Joe Wilson, CIO da CSG, à Computerworld
Na CSG, iniciativas de IA passam por revisões de governança com a liderança executiva e o dono é atribuído no início do projeto. A empresa criou ainda representantes do CIO embutidos nas unidades de negócio, para que a responsabilidade acompanhe todo o ciclo de vida da iniciativa, e não só o lançamento.
2. Governança antes da escala, não depois
DuChene chama isso de problema de sequenciamento: construíram-se as paredes antes de concretar a fundação. O resultado é retrabalho caro. Times descobrem tarde que não têm classificação de dados, controle de identidade e acesso ciente de IA, rastreamento de linhagem, capacidade de auditoria e canais de escalonamento.
Seth Dobrin, CEO da Arya Labs e ex-líder global de IA da IBM, conta o caso de uma seguradora que passou 18 meses construindo um sistema inteligente e viu o jurídico barrar a implantação por completo. O problema não era a tecnologia, era a ausência de governança no início. O trabalho foi jogado fora.
A leitura correta, e aqui está o ponto que a maioria erra: governança não é freio. Wilson usa uma analogia melhor, a de suspensão. Ela não existe para reduzir a velocidade, existe para permitir que você mantenha a velocidade em terreno acidentado. O objetivo nunca deve ser dizer não, e sim descobrir como chegar ao sim.
3. Governança de dados como fundação
Sem linhagem e proveniência, não há análise de causa raiz. É simples assim. Quais Taraki, CTO da EnterpriseDB, resume o buraco: sem saber de onde veio o dado e como ele se transformou, você não consegue determinar o que mudar nem entender como as coisas mutaram de forma inesperada.
O risco concreto é banal e frequente: um assistente que resume interações de clientes pode puxar dado regulado ou confidencial de sistemas que nunca foram pensados para alimentar IA generativa. Se a sua casa de dados ainda não está em ordem, comece por dados unificados e governança antes da IA, porque não existe atalho aqui.
4. Observabilidade além do modelo
Monitoramento tradicional foi feito para medir disponibilidade e desempenho. IA exige outra coisa: rastrear caminhos de raciocínio, cadeias de decisão e desvio de comportamento. Nik Kale, integrante da Coalition for Secure AI, propõe o conceito de Investigation Graph, uma trilha que mostra o que o sistema observou, quais ferramentas acessou, a que conclusões chegou e que ações executou.
O modelo não agiu. O sistema em volta do modelo agiu.
Nik Kale, Coalition for Secure AI, à Computerworld
A consequência prática é que a pergunta “por que a IA decidiu isso?” é a pergunta errada. A pergunta certa é “o que o sistema de fato fez?”. E responder a ela exige registro de cinco coisas: prompts, saídas do modelo, chamadas de ferramenta, eventos de acesso a dados e ações do agente.
Essa observabilidade tem um efeito colateral valioso: ela expõe a IA sombra. Política define qual ferramenta o funcionário deveria usar; observabilidade revela qual ele está usando de verdade. Padrões estranhos de acesso a dados, chamadas de API inesperadas e tráfego para serviços externos de IA são os sinais.
5. Mecanismos de escalar e de parar
Segundo Kale, é a peça mais subdesenvolvida das implantações corporativas. A maioria das empresas já aprendeu a monitorar. Quase nenhuma construiu a terceira parte: quando o sistema para e pede ajuda?
A exigência é dupla e não admite meio-termo. Precisa existir um ponto de parada explícito, e precisa existir um humano nomeado, com autoridade real para dizer não. Carimbo não é supervisão.
Há ainda um ponto que muda o desenho do plantão: falha de IA não é queda. Wilson observa que incidente tradicional de TI é binário, o serviço está de pé ou não está. Falha de IA é sutil: o modelo desvia aos poucos, a saída degrada, o fluxo passa a produzir resultado estranho sem nada tecnicamente cair. Isso exige resposta multidisciplinar, com jurídico, comunicação, segurança, auditoria, negócio e operações na mesma sala.
6. Trate a IA como trabalhador, não como software
Software se aprova no lançamento porque seu comportamento é estável entre versões. IA não é assim: modelos evoluem, prompts mudam, sistemas de recuperação são atualizados e a informação disponível ao agente muda o tempo todo. Você não contrata uma pessoa, treina e some por dois anos. Você supervisiona, dá retorno e intervém quando o comportamento desvia.
O alerta mais afiado de Kale vale para todo mundo que depende de fornecedor de IA:
O fornecedor que aprovamos no trimestre passado é, funcionalmente, um fornecedor diferente neste trimestre.
Nik Kale, Coalition for Secure AI, à Computerworld
Ou seja: aprovação de fornecedor precisa ter validade e data de revisão, como um exame médico. É a mesma lógica de vigilância contínua que discutimos em confiabilidade como gargalo dos agentes de IA.
Onde apoiar isso: os padrões que já existem
A boa notícia é que ninguém precisa inventar essa estrutura do zero. Existem três referências que transformam cada um dos seis movimentos em obrigação verificável, com artefato que sobra para auditoria.
| Referência | O que ela obriga você a ter | Artefato que sobra |
|---|---|---|
| NIST AI RMF | As quatro funções: Govern, Map, Measure e Manage, com documentação sistemática atravessando todas | Inventário de sistemas, mapa de risco e registro de decisões |
| ISO/IEC 42001 | Um sistema de gestão de IA, análogo ao que a ISO 27001 é para segurança da informação | Certificação auditável, útil em contrato e em due diligence |
| EU AI Act, art. 26 | Supervisão humana por pessoa com competência, treinamento e autoridade, e retenção de logs por no mínimo seis meses | Nome do responsável e trilha de auditoria com prazo definido |
Vale destacar dois pontos. O NIST AI Risk Management Framework trata a função Govern como transversal, algo que atravessa as outras três, exatamente o oposto de tratá-la como etapa de aprovação no fim. E o artigo 26 do AI Act europeu não pede um comitê genérico: ele exige pessoas físicas com competência, treinamento, autoridade e apoio. É a versão jurídica do “dono nomeado” que Wilson defende. A família de normas da ISO para governança de IA fecha o pacote com um sistema de gestão certificável.
O recorte brasileiro: o que já vale e o que está chegando
Empresa que opera no Brasil não precisa esperar lei nova para ter obrigação. O artigo 20 da LGPD já garante ao titular o direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses. Se um agente de IA nega um crédito, reprova um cadastro ou cancela um pedido, esse direito já está valendo hoje. E ele é inexequível sem log.
No horizonte está o PL 2338/2023, o Marco Legal da IA, aprovado pelo Senado em dezembro de 2024 e em tramitação na Câmara, com votação final adiada para 2026 em meio a impasses políticos. O texto segue o modelo europeu: classifica sistemas por nível de risco, cria direitos de transparência, explicação e contestação para as pessoas afetadas, institui um sistema nacional de regulação e governança e prevê sanções que chegam a R$ 50 milhões por infração.
A leitura estratégica é direta. Quem construir rastreabilidade agora não vai fazer isso duas vezes. Quem esperar a lei sair vai fazer sob prazo, sob pressão e mais caro. Como o texto ainda está em tramitação e sofreu mudanças, acompanhe a versão final antes de fechar qualquer política.
O kit mínimo aplicável: o que montar nesta semana
Traduzindo tudo em ação, este é o conjunto mínimo que já sustenta uma responsabilização exigível. Nenhum item exige orçamento novo, todos exigem decisão.
- Inventário de sistemas de IA. Toda IA em produção, inclusive a embutida em ferramenta de terceiro. O que não está na lista não tem dono.
- Um nome por sistema. Pessoa física, não área. Ela assina o postmortem. Registre isso onde outras pessoas consigam ler.
- Os cinco logs. Prompt, saída, chamada de ferramenta, acesso a dado e ação executada. Retenção mínima de seis meses, seguindo a régua do AI Act.
- Um ponto de parada por fluxo. Defina, por escrito, em que condição o sistema para e chama um humano, e quem é esse humano.
- Runbook de incidente de IA. Diferente do runbook de TI, porque a falha é gradual. Precisa prever jurídico, comunicação e negócio, não só operações.
- Revisão trimestral de fornecedor. Com data marcada. O modelo que você homologou mudou desde então.
- O teste do postmortem. Faça a pergunta do DuChene em reunião, uma vez por trimestre. Se ninguém responder em trinta segundos, você tem uma lacuna, não uma política.
Governança de custo e governança de risco andam juntas, e a instrumentação é a mesma. Se você já leu o que escrevemos sobre governança de custo de IA no Claude Enterprise e sobre MCP e governança de agentes, vai reconhecer o padrão: o log que corta desperdício é o mesmo log que prova responsabilidade.
O erro que se repete
A falha mais comum não é técnica, é de sequência. Empresas escrevem a política, aprovam em comitê, arquivam o PDF e acham que resolveram. Quando o sistema quebra, tudo é relitigado e a conta volta a cair sobre quem estava mais perto da dor.
Responsabilização deixou de ser um exercício de definição e virou uma capacidade operacional, embutida em governança de dados, observabilidade, escalonamento e supervisão contínua. O desafio dos líderes não é mais definir de quem é a responsabilidade. É tornar essa responsabilidade exigível.
Perguntas frequentes
Como saber se a minha empresa tem responsabilização de IA de verdade?
Faça o teste do postmortem: se um sistema de IA errar amanhã e custar dinheiro, quem escreve a análise pós-incidente? Se a resposta demora ou aponta uma área em vez de uma pessoa, existe política, mas não existe responsabilização.
Responsabilidade compartilhada funciona?
Não em produção. Segundo Joe Wilson, CIO da CSG, responsabilidade compartilhada não é responsabilidade. É preciso um dono direto, atribuído no início do projeto e presente em todo o ciclo de vida, não apenas no lançamento.
Quais registros são obrigatórios para auditar um agente de IA?
No mínimo cinco: prompts, saídas do modelo, chamadas de ferramenta, eventos de acesso a dados e ações executadas pelo agente. O artigo 26 do AI Act europeu exige ainda a retenção desses logs por pelo menos seis meses.
O que a lei brasileira já exige hoje?
O artigo 20 da LGPD garante o direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem os interesses do titular. Isso já vale, e é inexequível sem trilha de registro. O PL 2338/2023, com votação final adiada para 2026, deve ampliar as obrigações.
Governança de IA atrasa os projetos?
Não quando é embutida no fluxo de trabalho desde o início. O caso oposto é que atrasa: uma seguradora citada pela Computerworld passou 18 meses construindo um sistema que o jurídico barrou na implantação, e o trabalho foi descartado.
