Segurança de IA Certificável: Portas de Deployment Com Prova para LLMs Que Usam Ferramentas
Há um modo de falha específico nos LLMs modernos que usam ferramentas que não recebe atenção suficiente: os dados que o sistema gera não são estatisticamente independentes dos dados que o monitor vê depois. O LLM emite uma distribuição de tokens. O sistema amostra dela. Algumas amostras invocam ferramentas. As saídas das ferramentas regressam ao contexto. A próxima distribuição de tokens está condicionada nessas saídas. Tudo é adaptativo, dependente, recursivo.
O monitoring estatístico padrão assume observações independentes. A detecção de drift padrão assume uma distribuição de referência fixa. O testing A/B padrão assume que o teste não influencia os dados. Nenhuma destas assunções aguenta para um LLM a usar ferramentas em produção. O próprio comportamento do agente — e as respostas das ferramentas — muda a distribuição que o monitor está a observar.
O paper recente Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Fradelos, fevereiro 2026) aborda isto directamente. A contribuição é um framework matemático para certificar a segurança exactamente desta classe de sistemas, usando monitoring estatístico anytime-valid (e-processos) que estão explicitamente desenhados para dados adaptativos e dependentes.
A matemática é densa. O padrão de engenharia é mais acessível. Vale a pena entendê-lo porque a alternativa — fingir que o problema da dependência não existe — é o modo de falha silencioso da maioria do monitoring actual de IA em produção.
Porque "Com Prova" Importa
A ideia central: em cada ponto de decisão — cada vez que o agente quer tomar uma acção, invocar uma ferramenta, emitir uma resposta — constrói-se um certificado mostrando que a acção pertence a um conjunto seguro. O runtime verifica o certificado em tempo polinomial. Se o certificado é válido, a acção procede. Se não é, o sistema ou recorre a um default seguro ("dummy output") ou projecta a acção para uma alternativa segura próxima ("convex repair").
Esta é a mesma ideia do código com prova no software de sistemas: o produtor de uma acção fornece um certificado que um verificador pode verificar barato. A confiança muda de "o produtor comporta-se bem" para "o certificado é válido".
Para sistemas de IA, isto é operacionalmente importante porque:
- A verificação é mais barata do que o re-treino. Uma vez fixado o formato do certificado, verificar é rápido. Re-treinar um modelo para que seja mais seguro é caro e incerto.
- O verificador pode ser confiado independentemente do modelo. Um verificador pequeno, simples, formalmente especificado pode ser confiado a um nível mais alto do que um modelo grande e opaco.
- O fallback é principial. Quando o certificado falha, o sistema sabe falhar com segurança, ou emitindo uma saída dummy ou projectando para uma alternativa segura.
O Problema dos Dados Adaptativos
O movimento técnico central do paper é usar e-processos (um tipo específico de acumulador de evidência estatística baseado em supermartingales) para o monitoring. Os e-processos têm uma propriedade que os p-valores normais não têm: mantêm-se válidos sob stopping opcional e recolha de dados adaptativa.
Em termos simples: com testes estatísticos regulares, a validade do teste depende de te teres comprometido antecipadamente sobre quantos dados recolherás e o que vais testar. Se espreitas os dados e decides se continuar a recolher baseado no que viste, partiste as garantias do teste. Este é o problema "early stopping".
Para um sistema de IA em produção, não podes evitar o early stopping. Estás a monitorizar continuamente, vais agir sobre o monitoring (a alertar, throttling, a bloquear), e as tuas acções afectam os dados que o monitor observa. Os testes estatísticos regulares dão-te garantias que não aguentam neste regime.
Os e-processos aguentam. Dão validade uniforme no tempo: podes monitorizar continuamente, parar quando quiseres, e a garantia de falso positivo ainda se aplica. Esta é a base matemática que faz funcionar o monitoring contínuo de segurança de IA.
A implicação prática: se estás a usar detecção de drift baseada em p-valores num sistema de IA em produção, estás a operar fora do regime válido do método estatístico. Isto é algo a que quase ninguém está a prestar atenção em 2026, e é o tipo de erro que produz tanto falsa confiança (quando não morde) como falsos alarmes inexplicados (quando morde).
A Camada de Construção do Monitor
O paper especifica uma construção canónica do monitor com quatro componentes:
1. Logging de confiança
Cada input, cada saída do modelo, cada tool call, cada resposta de ferramenta é registado de uma maneira que o agente não consegue forjar. O log é o substrato para tudo o resto.
2. Aleatoriedade privada do monitor
O monitor usa números aleatórios a que o agente não tem acesso. Esta é a mesma ideia que manter secreta a seed de uma auditoria baseada em aleatoriedade do auditado. Impede que o agente jogue com o monitor antecipando o que o monitor vai verificar.
3. Shadow sampling
Para algumas verificações, o monitor amostra saídas adicionais do modelo com o mesmo prompt para estimar a distribuição de saída. Estas amostras sombra não chegam ao utilizador; existem apenas para caracterizar a distribuição de comportamento que o modelo está a produzir.
4. Re-execução de ferramentas
Para verificações que envolvem resultados de ferramentas, o monitor pode re-executar tool calls deterministicamente (ou num ambiente em sandbox) para verificar que a resposta era o que devia ter sido.
Estes quatro juntos dão ao monitor evidência independente suficiente para construir os certificados que o runtime requer. Nenhum deles é exótico; todos os quatro estão ao alcance de qualquer equipa que leva o monitoring a sério. A contribuição é especificar exactamente o que é necessário e porquê.
Composição Modular: Porque Importa
Uma dor de cabeça prática na segurança de IA é a composição. Podes certificar que dois componentes são seguros individualmente e ter um sistema composto não-seguro. O caso clássico: uma ferramenta que é segura chamar individualmente, chamada muitas vezes em rápida sucessão, pode produzir efeitos agregados não-seguros (denial-of-service contra um sistema downstream, escalation por chamadas repetidas, etc.).
O paper fornece um teorema de composição modular: sob condições específicas, os certificados de segurança dos componentes compõem-se num certificado de segurança para o sistema. As condições são reais e não-triviais, mas explícitas. Uma equipa a construir sistemas agênticos compostos pode verificar as condições e saber se a sua composição está no regime onde a segurança dos componentes implica a segurança do sistema.
O enquadramento honesto importa. O paper rotula isto como "um primeiro regime composicional" — significa um ponto de partida útil, não uma teoria completa de segurança composicional. As equipas de engenharia devem tratá-lo da mesma forma: útil para os casos que cobre, não uma garantia para os casos que não cobre.
O Orçamento Global de Risco
Uma contribuição subtil mas importante: um corolário que aloca um orçamento global de risco através dos tempos de decisão em runtime. Isto aborda o modo de falha "seguro por passo, inseguro em agregado".
Cada ponto de decisão tem uma pequena probabilidade de produzir uma acção insegura. Somado através de milhares ou milhões de decisões, a probabilidade agregada de pelo menos uma acção insegura torna-se grande. O paper fornece uma forma de alocar o orçamento global de risco através do calendário de decisões para que o agregado se mantenha limitado.
Na prática, isto significa estabelecer limiares de segurança por acção baseados em quantas acções esperas que o sistema tome, com tracking explícito do orçamento. Um sistema que toma um milhão de acções por dia e quer probabilidade agregada de acção insegura ≤1% precisa de um limiar por acção muito mais apertado do que um sistema que toma mil acções.
Este é o tipo de contabilidade que a maioria dos sistemas de IA em produção não faz explicitamente. Estabelecem um limiar por acção baseado na intuição e não verificam o agregado. CAST dá o framework para fazer isto correctamente.
Convex Repair: Quando o Certificado Falha
Quando uma acção falha a certificação, existem duas opções:
- Fallback dummy: emite uma saída default segura. Conservadora, simples, frequentemente degrada a experiência do utilizador.
- Convex repair: projecta a saída insegura para o ponto mais próximo no conjunto seguro. Requer que o conjunto seguro seja convexo e que a projecção seja tratável.
O paper fornece teoremas de projecção para a segurança em geometrias KL/Bregman e de transporte óptimo, com um caminho de tratabilidade explícito para a reparação baseada em transporte. A matemática diz: sob condições específicas, podes calcular uma acção que é "tão próxima quanto possível" da acção original insegura enquanto está dentro do conjunto seguro.
A conclusão de engenharia: quando desenhas o teu conjunto seguro, desenha-o convexo. Os conjuntos seguros convexos admitem projecção em tempo polinomial. Os conjuntos seguros não-convexos geralmente não. Esta é uma escolha de design que fazes quando especificas a política de segurança, e determina se o convex repair está sequer disponível.
O Que Significa para Equipas de IA em Produção
Três acções práticas para qualquer equipa a executar sistemas LLM com uso de ferramentas em produção:
1. Verifica a tua metodologia de monitoring
Se a tua detecção de drift ou monitoring de segurança usa métodos padrão baseados em p-valores sobre dados recolhidos adaptativamente, as garantias estatísticas não aguentam. Ou move-te para monitoring baseado em e-processos (a resposta certa) ou sê explícito que o teu monitoring é heurístico em vez de estatisticamente rigoroso (uma resposta intermédia defensável).
2. Especifica o conjunto seguro explicitamente
A frase "o modelo é seguro" não tem um significado preciso. "As saídas são membros do conjunto S" tem. Especifica S em código ou descrição formal. Depois podes verificar pertinência, projectar falhas em S e raciocinar sobre composição.
3. Conta o risco global
Se o teu sistema toma muitas acções, define limiares por acção baseados em orçamento de risco agregado, não em intuição por acção. A matemática não é difícil uma vez que decidiste o orçamento; a disciplina é decidir fazê-lo.
Onde CAST Não Se Aplica
O paper é explícito sobre o scope: não é uma teoria de robótica, não assume superinteligência, e está posicionado como "contenção e certificação finance-grade / scientific-computing-grade". É para leis de segurança explicitamente especificadas em sistemas LLM com uso de ferramentas.
Este é o regime onde vive a maioria do deployment de IA em produção em 2026. CAST está bem direccionado ao problema prático. As equipas a entregar agentes baseados em LLM que tocam ferramentas reais — a maior parte da IA agêntica em produção — deviam estar a ler este paper e a adaptar os padrões.
A alternativa é monitoring que está matematicamente errado nos dados que processa. Este é o tipo de erro que produz incidentes que ninguém consegue explicar a posteriori.
Fonte: Fradelos, G. Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Genebra, 12 de fevereiro de 2026). SSRN 6307158.
A executar LLMs com uso de ferramentas em produção e queres monitoring que seja realmente estatisticamente válido para os dados que estás a recolher? Fala com um CTO sobre desplegar capacidade de engenharia nearshore que possa construir segurança certificável no runtime.
