Era uma vez um belo dia em que o “AI governance de fachada” não segurou uma crise (Parte 1)

Era uma vez um belo dia em que o “AI governance de fachada” não segurou uma crise (Parte 1)
*qualquer semelhança com a realidade é mera coincidência*

Era uma vez uma organização com tudo “no lugar”: certificação em segurança da informação, extensão em privacidade, políticas aprovadas, comitê de IA montado e apresentações bonitas sobre governança. No papel, IA estava “coberta” pelos mesmos processos que já atendiam ao sistema de gestão de segurança e privacidade.

O detalhe é que nada disso tinha sido de fato traduzido em um sistema de gestão de IA nos termos da ISO 42001: escopo para IA, papéis e responsabilidades específicos, objetivos de IA, avaliações de risco de IA e avaliações de impacto de sistemas de IA integradas ao ciclo de vida. A gestão de riscos de IA também não seguia as orientações de 23894: contexto, critérios e fontes de risco específicas de IA eram tratados como “mais um item” no registro genérico de TI.

Um dos sistemas de IA foi ganhando espaço em decisões relevantes, tomando as decisões “solo”.
Oficialmente, ele “apoiava” a tomada de decisão em um processo crítico. Na prática, o nível de automação foi crescendo sem que se estruturasse um AI system impact assessment como o descrito na ISO 42005: não havia documento formal sobre escopo, usos pretendidos e não pretendidos, impactos em indivíduos e grupos ou critérios de reavaliação do negócio.

O fato gerador da crise veio quando uma sequência de decisões passou a ser questionada por viés, erro ou dano percebido, resultado prejuízo.
Até que alguém pediu “provas” do que ocorreu, ficou claro que os logs existentes eram quase todos de infraestrutura (disponibilidade, CPU, memória, status de serviço) e de acesso genérico ao aplicativo.

Faltavam justamente os registros de eventos de IA: entradas relevantes para decisão, saídas do modelo, indicação de decisões automatizadas versus revisadas por humano, versões de modelo e dados, drift etc.

Como critérios de uso pretendido e não pretendido eram vagos e o propósito estava descrito de forma genérica (“automatizar apoio à análise”), sem limites claros para o grau de automação, sem restrições explícitas para certos tipos de dados ou populações, e sem documentação sobre “misuse”, o resultado era sem responsáveis.

A combinação de decisões contestadas, ausência de AI system impact assessment estruturado e falta de trilha técnica de IA tornou difícil até caracterizar o incidente. Sem monitoramento contínuo de desempenho, impactos e desvios, o problema só apareceu quando já havia dano percebido e pressão externa.
A partir daí, cada área tinha uma versão diferente da história — mas ninguém tinha evidências completas sobre o que o sistema fez, em que condições e sob quais parâmetros.

Na Parte 2, entra a parte menos “mágica” da fábula: o que mudou quando essa organização decidiu sair da Governança de IA de fachada e alinhar rotinas, logs, resposta a incidentes e métricas com 42001, 23894, 42005, 27035‑3 e 27701.