O que é governança de IA?

Governança de IA é o modelo operacional que decide quais sistemas de IA uma empresa permite, quais dados e tools eles podem usar, quem responde por eles e quais evidências são mantidas quando agem. Ela cobre modelos, clientes de IA, agentes, prompts, servidores MCP, skills, plugins, credenciais e outputs.

O plano técnico costuma combinar um catálogo de capacidades aprovadas, políticas de identidade e acesso, roteamento de LLM, gateways de MCP, verificações de segurança em runtime, limites de uso, traces, avaliações e resposta a incidentes. Esses controles transformam políticas em decisões que permitem, negam, modificam, pausam ou enviam uma ação para revisão.

Governança de IA não é um comitê que revisa um documento uma vez por ano. É um ciclo contínuo: descobrir o uso real, aprovar padrões úteis, aplicar controles em runtime, observar outcomes, investigar exceções e atualizar o caminho aprovado conforme as equipes adotam novos modelos e tools.

A adoção de IA raramente espera por um programa central. As pessoas instalam clientes de IA, conectam contas OAuth pessoais, adicionam servidores MCP, copiam dados internos em prompts e compartilham skills ou plugins locais. Essa shadow AI pode ser produtiva, mas a empresa pode não saber quais sistemas guardam dados de clientes, código, contratos, senhas ou API keys.

Agentes aumentam o impacto porque podem agir, não apenas gerar texto. Uma tool de email com permissões excessivas pode enviar dados para fora. Uma descrição de tool envenenada pode mudar o comportamento. Uma instrução injetada em um ticket ou documento pode fazer um agente legítimo chamar o sistema errado.

Uma boa governança não começa com proibição total. Ela cria um caminho aprovado mais fácil do que a configuração informal: modelos, conectores e tools autorizados com owners claros e acesso rápido. Segurança concentra o bloqueio em servidores desconhecidos, privilégios excessivos, dados sensíveis, ações destrutivas e comportamento que se afasta da tarefa original.

A primeira camada é o inventário. Configurações de dispositivos, logs de aplicações, grants OAuth, repositórios e atividade de rede podem mostrar quais clientes, modelos, servidores MCP, skills, plugins e agentes estão em uso. Cada capacidade aprovada precisa de owner, finalidade, dependências, classificação de dados, estado de acesso e evidência de adoção ou falha.

A segunda camada é o controle em runtime. Um router de LLM seleciona modelos e regiões aprovados, aplica orçamentos e rejeita workloads restritos. Políticas de identidade limitam o acesso por pessoa, grupo, service account, agente, cliente, conector, tool e recurso. Um gateway de MCP avalia tool calls, enquanto controles de segurança inspecionam prompts, conteúdo recuperado, argumentos, intenção e outputs.

A terceira camada é observabilidade e resposta. Um único trace conecta ator, modelo, prompt, tool calls, políticas, aprovações, custo, latência, achados e resultado final. A resposta pode ser aprovar um padrão de shadow AI, migrá-lo para infraestrutura gerenciada, remover configuração antiga, reduzir permissões, rotacionar uma credencial, bloquear a atividade ou escalar um incidente.

Uma pessoa de desenvolvimento usa um assistente de código aprovado para diagnosticar uma falha em um webhook de produção. A tarefa contém logs e um arquivo de configuração. O router de LLM mantém a solicitação em um modelo aprovado, o detector substitui uma API key antes da inferência e a política permite leitura de logs, mas não gestão de credenciais.

O repositório também contém um README instruindo o assistente a enviar a configuração para uma tool externa. Segurança classifica essa instrução como conteúdo recuperado não confiável. O gateway de MCP nega a chamada porque o conector não foi aprovado e os argumentos contêm um padrão de segredo. A pessoa recebe um próximo passo seguro em vez de uma recusa genérica.

O trace mostra pessoa, cliente, modelo, repositório, tools solicitadas, evento de redação, destino bloqueado, versão de política, latência e ação final. Segurança rotaciona a key exposta, plataforma corrige o workflow aprovado e o owner registra o padrão de shadow AI para evitar que outras equipes o recriem.

Defina responsáveis antes de escolher controles. Segurança cuida da política de ameaças e resposta a incidentes. Plataforma opera catálogo, gateway, router e confiabilidade. Owners de dados definem usos permitidos. Owners de negócio aceitam risco. Todo agente de alto impacto precisa de uma pessoa responsável e uma condição de parada.

Crie níveis de risco com base nos dados e na ação, não na marca do modelo. Ler documentação pública é diferente de enviar email, alterar produção, emitir um reembolso ou acessar registros regulados. Vincule cada aprovação à ação e aos parâmetros exatos, faça a aprovação expirar e impeça que uma aprovação anterior autorize uma solicitação alterada.

Meça cobertura e outcomes: clientes descobertos versus gerenciados, servidores MCP aprovados versus shadow, owners ativos, chamadas de alto risco bloqueadas, segredos detectados, approval rate, falhas de tools, custo por equipe, tempo de remediação e tentativas repetidas de bypass. Remova dados sensíveis dos traces e mantenha rollback, rotação de credenciais e kill switches.