A Northbridge Health, uma organização de saúde dos EUA com 1.200 funcionários, está preparando o CareGuide para seu portal do paciente. O CareGuide utiliza um modelo de linguagem de grande porte (LLM), um sistema que gera texto a partir de uma solicitação do usuário. Antes do lançamento, a equipe enfrenta uma decisão prática. O fato de o chat parecer útil torna o CareGuide pronto para os pacientes, mesmo que ele possa expor informações dos pacientes ou oferecer orientações de saúde inseguras?
A avaliação de segurança reúne evidências sobre como uma aplicação de LLM se comporta em situações que poderiam causar danos. Ela difere da avaliação de qualidade, que analisa se as respostas são fluidas, relevantes ou úteis. As evidências de segurança embasam decisões sobre lançamento, pausa, reformulação e supervisão. Elas também fornecem à equipe um registro do que foi testado, do que falhou e do que permanece incerto. Vamos analisar o fluxo de informações dos pacientes, os possíveis danos e a decisão de implementação relacionada ao CareGuide.
Três atividades fornecem evidências distintas. Os testes de segurança verificam se o CareGuide atende às expectativas definidas para riscos conhecidos. O red teaming busca deliberadamente maneiras inesperadas pelas quais uma pessoa poderia provocar um comportamento inseguro, como contornar uma restrição. O benchmarking avalia um sistema em relação a um conjunto consistente de testes (públicos ou internos), permitindo comparações entre versões ou sistemas. Nenhuma delas oferece uma resposta completa isoladamente.
No caso de um chatbot para pacientes, uma mesma falha visível pode exigir as três abordagens. Os testes verificam o comportamento pretendido, o red teaming investiga vulnerabilidades e o benchmarking fornece um ponto de comparação replicável. Resultados públicos de benchmarks ajudam a formular questionamentos, mas não podem comprovar que o CareGuide é seguro no contexto do portal do paciente. Considere como as três atividades enquadram essas falhas do CareGuide.