Uma equipe de gestão de riscos recebe um novo chatbot de suporte a usuários de serviços de saúde dois dias antes do lançamento. Em um teste realizado nessa fase final, o bot fornece a um usuário instruções passo a passo sobre a dosagem de um medicamento prescrito, embora os requisitos do produto determinem que ele deve recusar-se a dar aconselhamento médico e encaminhar o usuário para uma linha de atendimento de enfermagem. Ninguém consegue responder à primeira pergunta necessária para a classificação de risco: em que ponto do sistema esse comportamento poderia ter sido prevenido, detectado ou contido?
O restante desta aula constrói um modelo de ameaças para saídas prejudiciais, percorrendo a cadeia do incidente de ponta a ponta e transformando essa cadeia em pontos de controle concretos que podem ser medidos e gerenciados.
Neste curso, um modelo de ameaças é uma descrição estruturada de como um dano específico pode ocorrer em sua aplicação de LLM, quais componentes participam, quais condições precisam ser atendidas e quais evidências podem ser coletadas para confirmar ou refutar essa trajetória. No caso de saídas prejudiciais, isso significa tratar a saída como o estado de falha e rastrear o processo em ordem inversa — passando por prompt, recuperação, geração, moderação e entrega — até encontrar os pontos da cadeia onde é possível exercer controle.
Simulação — trecho da narrativa do incidente:
Um usuário pergunta ao chatbot se pode dobrar a dose para compensar um dia em que esqueceu de tomá-la. O chatbot recupera um FAQ geral sobre medicamentos e um trecho de fórum da comunidade que contém discussões informais sobre dosagem. O modelo responde com orientações condicionais de dosagem e um aviso, e a interface do usuário (UI) exibe a resposta sem qualquer barreira adicional. Nenhuma mensagem de recusa é acionada e não ocorre revisão humana.
O passo fundamental é decompor o que deu errado em eventos observáveis do sistema. Uma solicitação do usuário chegou, a etapa de recuperação retornou uma combinação de contexto aceitável e inseguro, o modelo produziu uma recomendação sobre dosagem (sujeita a regulamentação), a etapa de moderação não bloqueou nem redirecionou a resposta, e o canal de entrega a apresentou como conteúdo de ajuda padrão. Buscamos um modelo de ameaças porque cada etapa do processo envolve telemetria e limites de controle distintos.
Podemos tornar essa cadeia concreta no diagrama do sistema. Ao analisá-lo, concentre-se em qual componente transformou um risco latente em uma resposta efetivamente entregue. Agora, mapeie os pontos de falha na arquitetura:
Um ponto de controle é um estágio no fluxo da solicitação à resposta onde é possível aplicar uma decisão de segurança ou proteção, utilizando uma entrada, uma política e uma ação de imposição. Para saídas prejudiciais, é útil agrupar os pontos de controle em pré-geração, durante a geração e pós-geração, pois cada grupo oferece garantias e custos de falsos positivos diferentes.
Os controles de pré-geração moldam o que o modelo visualiza. Eles incluem filtragem de entrada do usuário, restrições de recuperação de informações e modelos de prompt. Podem reduzir a probabilidade de saídas prejudiciais, mas não garantem segurança total, pois entradas aparentemente seguras podem gerar respostas inseguras, e a recuperação de informações ainda pode trazer à tona textos limítrofes que são perigosos dependendo do contexto.
Os controles durante a geração moldam o que o modelo tem permissão para produzir. É nessa etapa que se utilizam instruções de sistema, políticas de ferramentas para agentes e recursos de segurança nativos do modelo, quando disponíveis. Eles podem restringir comportamentos, mas ainda dependem da capacidade do modelo de seguir instruções diante de entradas adversárias ou ambíguas, sendo difíceis de verificar sem testes sistemáticos.
Os controles de pós-geração decidem o que é entregue e o que é encaminhado. Isso inclui classificadores de moderação de saída, listas de permissão e bloqueio para tópicos de alto risco e filas de revisão humana. Frequentemente, são o único ponto onde se pode garantir que textos proibidos não cheguem ao usuário; no entanto, podem adicionar latência, criar uma experiência de usuário inconsistente e exigir um registro de logs rigoroso para comprovar sua eficácia quando forem necessárias evidências.
Garantias exigem mecanismos de imposiçãoUma declaração de política não constitui um controle. Um ponto de controle só existe quando há uma decisão passível de imposição e um rastro de auditoria que possa ser revisado.
Um equívoco comum é acreditar que o risco de saídas prejudiciais é apenas uma questão de qualidade do modelo. Na prática, o modelo é apenas um componente de um sistema distribuído. O mesmo modelo base pode ser aceitável em um fluxo de trabalho de triagem de enfermagem com roteamento rigoroso na pós-geração, mas inaceitável em uma interface de chat de autoatendimento sem barreiras de controle, pois o caminho de entrega altera o impacto e a capacidade de detecção.
Para tornar os pontos de controle operacionais, associamos a eles evidências. Para cada ponto, devemos ser capazes de responder: qual sinal é registrado, onde ele é armazenado e como é revisado. Analise os pontos de intervenção e os logs que se espera encontrar: