A maior parte das ferramentas de segurança de IA aposta em detecção — métricas de desvio, monitoramento, capturar a alucinação. Isso funciona para o erro recuperável. Mas tem um ponto cego estrutural.
A falha catastrófica é uma função degrau. Ela cruza a fronteira da API antes de qualquer derivada existir para capturá-la. E diante da ruína não há "próximo ciclo" para aprender — antifragilidade pressupõe que você sobreviva ao impacto.
Ou seja: ruína é problema de contenção, não de detecção.
É esse o núcleo da IGO (Infraestrutura de Governança Observacional) — 4 camadas, 2 lanes:
Lane recuperável (Camadas 1–3): métricas dinâmicas de desvio, um circuit-breaker por previsibilidade cognitiva (CPI) e red teaming sintético. Cuida do que dá para consertar.
Lane da ruína (Camada 4): contenção. Trata o output como vetor hostil, isolado em zero-trust antes de tocar qualquer coisa. Não confia em detecção — torna a ação ruinosa inalcançável.
As fórmulas dos indicadores (KAPIs, incluindo o CPI) são públicas, com DOI no Zenodo, e foram medidas em produção em 4 instituições, auditando 4 LLMs.
Não estou vendendo invulnerabilidade — a cauda de risco é aberta e não-estacionária. O ponto não é ser inquebrável; é governar o resíduo continuamente.
Repositório: https://github.com/joseteiadirector/teia-igo-vs-claude-opus-4.8
Artigo (Zenodo): https://doi.org/10.5281/zenodo.19765674
Top comments (1)
Escrevi isto porque vejo muita empresa tratando segurança de LLM como problema de detecção — filtrar a saída, pegar a alucinação. Mas detecção não cobre a falha catastrófica: quando ela acontece, já passou.
Fico curioso pra ouvir a comunidade: vocês confiam só em filtros de saída, ou já testaram alguma camada de contenção / zero-trust em produção? E como lidam com o risco de cauda longa?