Políticas como código para governança de IA

O artigo executivo "Comitê de IA: quem decide, quem aprova, quem responde" define a estrutura de decisão. Este texto trata do problema seguinte, que costuma travar em empresas que já têm o comitê: como transformar o que foi decidido em algo que o sistema efetivamente cumpre, sem depender de treinamento de time e boa vontade.

Por que política em documento não basta

Uma política de uso de IA escrita em PDF define regras, mas não as aplica. O gap entre "está escrito que" e "o sistema impede que" é onde a maioria dos incidentes de governança de IA acontece: alguém usa um modelo não aprovado, um agente executa uma ação sem aprovação humana, um caso de uso de alto risco entra em produção sem passar pela revisão que o comitê exigiu.

Policy as code fecha esse gap: a política vira regra executável, testável e versionada, avaliada em tempo de execução ou em pipeline de CI, com o mesmo rigor que se aplica a código de produção.

Classificação de risco por caso de uso como regra

O primeiro artefato de policy as code é a classificação de risco. Em vez de uma planilha mantida manualmente, o caso de uso declara seus atributos e uma regra determina a categoria:

caso_de_uso: "triagem-curriculo"
atributos:
  decide_sobre_pessoa: true
  reversivel: false
  dados_sensiveis: ["dados_trabalhistas"]
  volume_decisoes_mes: 4200
regra_classificacao:
  - se: decide_sobre_pessoa == true e reversivel == false
    entao: risco = "alto"
  - se: dados_sensiveis contem "saude" ou "biometria"
    entao: risco = "alto"
  - default: risco = "medio"

Essa regra roda automaticamente quando um novo caso de uso é cadastrado, e recalcula a classificação se os atributos mudarem — por exemplo, se o volume de decisões cresce o suficiente para mudar o patamar de risco.

Autorização por atributos (ABAC)

Controle de acesso baseado em papel (RBAC) não é granular o suficiente para IA: a mesma pessoa pode estar autorizada a usar um modelo para um caso de uso e não para outro, dependendo do risco, do tipo de dado e do horário. Autorização por atributos (ABAC) resolve isso combinando atributos do usuário, do recurso e do contexto:

permitir SE
  usuario.papel == "analista_credito"
  E recurso.caso_de_uso.risco IN ("baixo", "medio")
  E recurso.dado.classificacao != "restrito"
  E contexto.aprovacao_humana_pendente == false

A vantagem de expressar isso como regra, e não como permissão fixa em uma tabela, é que a mesma engine de decisão pode ser reutilizada por múltiplos serviços — API de inferência, orquestrador de agentes, painel de administração — sem duplicar lógica.

Guardrails de entrada e saída

Guardrails são as regras que interceptam a chamada ao modelo antes de ela sair (entrada) e a resposta antes de ela ser entregue (saída):

Guardrails devem ser implementados como camada separada da aplicação, não embutidos no código de cada serviço que chama o modelo — assim, uma mudança de política se propaga sem exigir deploy de cada consumidor.

Aprovação humana obrigatória como estado, não como convenção

Casos de uso de risco alto exigem aprovação humana antes da execução. A forma robusta de implementar isso não é uma checagem manual "por fora": é modelar a aprovação como um estado obrigatório na máquina de estados da decisão.

estados: pendente -> aguardando_aprovacao -> aprovado -> executado
                                          -> rejeitado -> encerrado

Uma decisão de risco alto simplesmente não tem caminho de transição de "pendente" para "executado" sem passar por "aprovado". Isso é aplicado pela engine de estado, não por um processo que alguém pode pular sob pressão de prazo.

Testes de política em CI

Se a política é código, ela é testável como código. Cada regra de governança deve ter um conjunto de casos de teste que roda no pipeline de CI antes de qualquer alteração de política ir para produção:

teste: "caso_de_uso_alto_risco_sem_aprovacao_deve_ser_bloqueado"
dado: caso_de_uso com risco=alto, aprovacao_humana=pendente
quando: solicitar_execucao()
entao: resultado == "bloqueado"

teste: "dado_restrito_sem_mascaramento_deve_bloquear_entrada"
dado: prompt contendo CPF nao mascarado
quando: validar_entrada()
entao: resultado == "bloqueado"

Isso captura regressões de política — uma alteração de regra que, sem querer, libera algo que deveria continuar bloqueado — antes que cheguem a produção.

Evidência automática para auditoria

O benefício colateral de policy as code é que cada avaliação de regra já gera, por construção, um registro estruturado: qual regra foi avaliada, com quais atributos de entrada, qual foi o resultado, e quando. Isso substitui a reconstrução manual de evidência de conformidade — que normalmente acontece sob pressão, na véspera de uma auditoria — por uma consulta a um log que já existe.

O que fazer na segunda-feira

• Escolha uma regra de política já decidida pelo comitê de IA (por exemplo, "casos de uso de risco alto exigem aprovação humana") e formalize-a como regra executável, mesmo que rodando só em modo de simulação no início.
• Identifique onde hoje existem guardrails "no código de cada aplicação" e planeje a extração para uma camada compartilhada.
• Escreva o primeiro teste de política em CI cobrindo o cenário de maior risco atual da empresa.
• Verifique se a máquina de estados de aprovação impede — e não apenas desencoraja — a execução sem aprovação registrada.

Leitura complementar

Trilha executiva:

• Comitê de IA: quem decide, quem aprova e quem responde — a leitura de negócio deste mesmo tema.