Saídas de IA: validar antes de executar

O risco é a passagem de texto a efeito

A página OWASP GenAI LLM Top 10 2026 está datada de 3 de agosto. Não a tratamos como novidade de 5 de setembro nem atribuímos à nova edição uma numeração que não verificámos. A referência técnica específica aqui usada continua publicada como LLM05:2025, Improper Output Handling.

Essa referência descreve validação e tratamento insuficientes das saídas antes de serem entregues a outros sistemas. Distingue o problema da confiança excessiva na resposta: aqui, uma aplicação interpreta o conteúdo como código, consulta, caminho ou instrução operacional. A OWASP recomenda validação no backend, codificação adequada ao destino e consultas parametrizadas.

O contrato pertence ao sistema que recebe

O ASVS fornece requisitos para verificar controlos técnicos e recomenda identificar requisitos pela versão. A página oficial indica 5.0.0 como versão estável e exemplifica um requisito de prevenção de injeção de comandos. Isto permite ligar a revisão de uma integração de IA a testes de segurança da aplicação, sem inventar uma certificação de modelo.

Perspetiva Velqory: comece pela última fronteira antes do efeito. Um campo chamado «destinatário» pode ter o tipo correto e apontar para a pessoa errada. Uma descrição pode parecer inofensiva no chat e ser interpretada de outra forma num template. A equipa proprietária do consumidor deve definir o que esse campo pode significar.

Checklist de aceitação de uma saída

Propomos o seguinte ensaio para uma integração existente, em ambiente isolado e com dados sintéticos. É um plano de teste, não um resultado já obtido nem uma garantia universal.

• Inventarie os destinos: interface, base de dados, ficheiro e API. Para cada um, registe o efeito possível e o serviço responsável por o impedir.
• Valide estrutura e significado: campos permitidos, tipos, comprimentos, enumerações, identificadores existentes e pertença ao cliente correto. Rejeite campos inesperados; não os converta silenciosamente em instruções.
• Use mecanismos próprios do destino: consultas parametrizadas, codificação contextual para apresentação e operações específicas em vez de construir comandos livres. Um único «sanitizador universal» não deve ser o contrato.
• Introduza respostas sintéticas inválidas, valores fora do âmbito e referências a outro cliente. O critério é zero chamadas com efeito para casos rejeitados, acompanhado de um motivo identificável.
• Teste o caso aprovado e o caso de falha do validador. Defina antecipadamente se o sistema devolve um rascunho, pede revisão ou recusa; não permita que a indisponibilidade do controlo autorize execução.

Guardar a decisão, não duplicar dados sensíveis

Como desenho operacional, recomendamos associar o identificador do pedido, a versão do contrato, o resultado da validação e o efeito efetivamente realizado. Registos de rejeição devem permitir reproduzir o problema com uma amostra minimizada. Guardar indiscriminadamente prompts e respostas completos pode criar outro repositório de informação sensível.

O proprietário da integração deve conseguir responder: que regra passou, que regra falhou e quem autorizou uma exceção? Uma segunda resposta do mesmo modelo a dizer «está seguro» não substitui estes controlos.

Âmbito e revisão

Este artigo trata de aplicações que consomem saídas de LLM; não compara modelos, não altera permissões e não anuncia um incidente. A checklist é recomendação editorial e precisa de adaptação à arquitetura, aos dados e ao impacto do serviço.

Reveja o contrato quando mudar o modelo, o formato de resposta, a ferramenta ou o destino. Até um teste controlado demonstrar rejeição sem efeitos, mantenha a nova integração em modo de rascunho. A qualidade linguística da resposta não é evidência de aceitação técnica.