Logs explicam depois; uma camada de intervenção governa antes
Auditoria é necessária, mas não impede uma transferência, publicação ou alteração indevida. Agentes com efeitos reais precisam de gates que permitam, limitem, escalem ou parem a ação em runtime.
- Natureza
- Padrão de governação operacional
- Base
- ISACA, NIST AI RMF, monitorização NIST, OECD e OWASP
- Âmbito
- Agentes e sistemas de IA com ações externas
- Limite
- Não existe um único produto ou threshold adequado a todos os riscos
Em resumo
A ISACA propõe uma camada de intervenção entre decisão da IA e efeito, complementando prova retrospectiva. NIST e OECD pedem override, resposta, desativação segura e gestão contínua. A arquitetura prática transforma políticas em decisões executáveis: contexto, risco e autoridade entram; allow, constrain, escalate ou stop saem; a prova preserva política, versão, input relevante, resultado e ação tomada.
- Coloque o gate fora do modelo e imediatamente antes do efeito na ferramenta ou serviço.
- Defina quatro resultados explícitos e comportamento fail-safe para indisponibilidade do policy engine.
- Vincule aprovações humanas ao payload final, prazo e recurso; não aceite consentimento genérico.
- Meça falsos positivos, escapes, latência, overrides e tempo até contenção.
Observabilidade responde ao que aconteceu; intervenção decide o que pode acontecer
Um trace completo pode provar que o agente chamou uma ferramenta com determinado payload. Se a chamada já enviou dinheiro ou publicou dados, a prova chega tarde. O gate precisa de avaliar política, identidade, recurso, valor, reversibilidade e contexto antes do commit.
O resultado não é sempre bloquear. `Constrain` reduz valor, dados ou ferramentas; `escalate` pede aprovação; `stop` impede; `allow` executa dentro do mandato. Todos devem gerar uma decisão estruturada e correlacionável.
Caminho da ação
- PLANEARAgente propõe
A intenção e o payload ainda não produziram efeito externo.
- AVALIARPolicy gate
Identidade, risco, limites e estado são verificados.
- INTERVIRQuatro resultados
Allow, constrain, escalate ou stop, com razão estruturada.
- PROVAREfeito reconciliado
Resultado real, override e alteração ficam ligados à decisão.
Desenhe regras pela consequência e pelo custo de reversão
Uma consulta interna de baixo impacto pode ser permitida automaticamente; exportar dados, mudar permissões ou comunicar externamente exige gates mais fortes. Defina limites mensuráveis e inputs que a ferramenta possa verificar sem interpretar linguagem natural.
O fail mode é decisão de risco. Para pagamentos e eliminação, falha do gate deve bloquear. Para alertas urgentes, pode existir uma rota degradada pré-aprovada. Documente a escolha e teste indisponibilidade, timeout e conflito de políticas.
Quatro respostas
| Resposta | Quando | Exemplo de controlo | Prova |
|---|---|---|---|
| Allow | Risco baixo dentro do mandato | Scope e limite válidos | Política/version |
| Constrain | Ação útil mas excessiva | Reduz dados/valor | Payload alterado |
| Escalate | Impacto alto ou ambiguidade | Aprovação vinculada | Pessoa e prazo |
| Stop | Proibido ou sem prova | Negação fail-safe | Razão e alerta |
Implemente primeiro no efeito mais caro e ensaie o botão de parar
Escolha uma ação externa de alto impacto, mova enforcement para o serviço que a executa e teste os quatro resultados. O agente pode receber uma explicação segura para replanear, mas não pode alterar a política.
Ligue kill switch, revogação de credenciais e isolamento de fila a um runbook humano. Um stop que depende do mesmo agente comprometido não é uma salvaguarda independente.
- Não usar prompt do sistema como único gate.
- Não aprovar antes de conhecer o payload final.
- Não deixar timeout cair em allow por conveniência.
- Não lançar sem métricas de escapes e falsos bloqueios.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.