A plataforma de IA de atendimento ao cliente de uma empresa havia sido configurada com retenção zero: as conversas dos clientes eram processadas pela infraestrutura de inferência de LLM do fornecedor e nenhum dado das conversas era retido após o fim de cada sessão. A empresa havia verificado essa configuração por meio da DPA do fornecedor e das configurações do console de administração. O que a empresa não havia avaliado era a exposição de dados dentro da sessão, durante a própria chamada de inferência. A plataforma de IA do fornecedor carregava o contexto do cliente no início de cada sessão de atendimento (histórico da conta, chamados abertos, detalhes da assinatura e interações anteriores) e mantinha esse contexto na janela de contexto do modelo durante toda a sessão. Um pesquisador de segurança que testava a plataforma demonstrou que, em determinadas condições, entradas de usuário cuidadosamente elaboradas podiam levar o modelo a reproduzir conteúdo anterior do mesmo contexto de sessão que não fizera parte da conversa explícita, especificamente detalhes da conta e o histórico de chamados que haviam sido carregados como contexto do sistema na inicialização da sessão, mas não exibidos ao usuário. A configuração de retenção zero impedia corretamente que os dados persistissem após a sessão. Ela não impedia que os dados presentes no contexto da sessão ficassem acessíveis à manipulação de prompts dentro da sessão. A janela da sessão era a janela de exposição dos dados.
O que é, de fato, o vazamento de dados na inferência de IA?
O vazamento de dados na inferência de IA é a exposição de dados presentes no ambiente de inferência de um modelo de IA (a janela de contexto, o prompt de sistema aumentado por recuperação, as fontes de dados conectadas carregadas como contexto e os estados intermediários de processamento do modelo) à extração por meio de entradas de usuário, manipulação de prompts ou técnicas de canal lateral durante a sessão de inferência. Ao contrário da retenção de dados após a sessão, que mantém os dados depois do fim da sessão, o vazamento de dados no momento da inferência ocorre durante a sessão ativa e pode ser explorável independentemente da configuração de retenção.
O problema da exposição da janela de contexto é o mecanismo principal. Assistentes de IA modernos e aplicações de LLM voltadas ao cliente carregam um contexto significativo na janela de contexto do modelo na inicialização da sessão: perfis de clientes, históricos de contas, permissões, conteúdo da base de conhecimento e instruções do sistema. Esse contexto é usado pelo modelo para gerar respostas informadas e personalizadas. Ele também está presente no ambiente de processamento do modelo e pode ficar acessível a técnicas de manipulação de prompts que levam o modelo a mencionar ou reproduzir conteúdo do contexto sobre o qual não foi explicitamente questionado.
A dimensão da extração do prompt de sistema é uma superfície de ataque relacionada. Aplicações de IA normalmente incluem prompts de sistema, instruções ao modelo que definem seu papel, suas restrições e seu acesso a recursos conectados. Esses prompts de sistema podem conter informações de configuração sensíveis, restrições de segurança ou referências a fontes de dados conectadas. Ataques de injeção de prompt que levam o modelo a reproduzir ou descrever seu prompt de sistema expõem informações de configuração que deveriam ser opacas para os usuários finais. Em implantações de IA multilocatário, os prompts de sistema podem conter configurações específicas de um locatário que outro locatário não deveria conseguir extrair.
O risco de contaminação entre sessões se aplica a implantações de IA em que o histórico de conversas é mantido entre sessões: sistemas de memória de longo prazo, resumo de conversas e recursos de contexto persistente. Nessas configurações, dados de uma sessão podem estar presentes no contexto de sessões subsequentes. A contaminação entre sessões ocorre quando dados de uma sessão anterior se tornam acessíveis em uma sessão posterior por meio do mecanismo de contexto persistente, podendo expor dados da sessão de um usuário a outro usuário que interaja com o sistema em uma sessão subsequente.
O problema do isolamento multilocatário é o risco corporativo específico dos modelos de implantação de IA compartilhada. Plataformas de IA de fornecedores que atendem vários clientes corporativos em infraestrutura compartilhada criam riscos de vazamento de dados de inferência entre locatários, especificamente o risco de que o contexto carregado para a sessão de um locatário fique acessível às chamadas de inferência de outro locatário por meio de estado compartilhado do modelo, isolamento insuficiente entre contextos de locatários ou injeção de prompt que ultrapasse os limites entre locatários. Esses riscos entre locatários são análogos às falhas de isolamento de bancos de dados entre locatários, mas aplicados à camada de inferência de IA.
Por que isso importa
O vazamento de dados na inferência de IA é importante para TPRM porque a configuração de retenção zero, embora necessária, não é suficiente para proteger dados sensíveis que passam pelo ambiente de inferência de IA. Dados de clientes carregados como contexto de sessão, prompts de sistema e conteúdo recuperado da base de conhecimento estão todos presentes no ambiente de inferência durante a sessão e exigem proteção na camada de inferência, além da camada de retenção.
Onde a maioria das equipes erra
A falha mais constante é tratar a configuração de retenção zero como a resposta completa de proteção de dados para implantações de IA, sem avaliar os riscos de exposição dentro da sessão que os controles de retenção não abordam.
- Retenção zero equiparada a proteção de dados completa
- Exposição da janela de contexto dentro da sessão não avaliada
- Confidencialidade do prompt de sistema não avaliada
- Contaminação entre sessões em implantações com contexto persistente não avaliada
- Isolamento multilocatário da inferência não avaliado em implantações de plataforma compartilhada
Como é uma boa prática
Programas maduros de proteção de dados na inferência de IA abordam tanto os controles de retenção quanto os controles de exposição dentro da sessão, especificamente a delimitação da janela de contexto, os testes de confidencialidade do prompt de sistema e a validação do isolamento multilocatário, junto com a configuração padrão de retenção.
- Minimização do escopo da janela de contexto: carregar apenas o contexto necessário para cada sessão
- Testes de confidencialidade do prompt de sistema: testar especificamente se os prompts podem ser extraídos
- Validação do isolamento multilocatário: confirmação do isolamento de contexto entre locatários
- Testes de injeção de prompt dentro da sessão: testes de extração de contexto por meio de prompts na sessão
- Avaliação de contaminação entre sessões: para implantações com contexto persistente
Ferramentas
Testes de segurança de LLM: Garak, PromptBench para testes de extração dentro da sessão
Ferramentas de testes de segurança de LLM que testam especificamente a extração de contexto e a divulgação do prompt de sistema fornecem a avaliação de segurança dentro da sessão que as auditorias de retenção não oferecem. Para profissionais de TPRM, perguntar se o fornecedor realizou testes de injeção de prompt dentro da sessão voltados especificamente à extração da janela de contexto é uma pergunta específica sobre segurança no momento da inferência.
Desafios de governança
O desafio de governança do vazamento de dados na inferência de IA é a lacuna de visibilidade no momento da inferência: a empresa não consegue observar diretamente quais dados estão presentes na janela de contexto do modelo durante a inferência. A solução de governança é a transparência do fornecedor sobre as práticas de carregamento de contexto e testes independentes de segurança dentro da sessão que validem o isolamento entre as camadas de contexto.
- Pergunte quais dados são carregados na janela de contexto na inicialização da sessão
- Solicitar os resultados dos testes de injeção de prompt dentro da sessão para extração de contexto
- Pergunte sobre o isolamento multilocatário da inferência em infraestrutura compartilhada
- Avaliar a confidencialidade do prompt de sistema: os usuários conseguem extrair os prompts?
- Avaliar os controles contra contaminação entre sessões em implantações com contexto persistente
Se você faz parte de uma equipe pequena
Para qualquer plataforma de IA de fornecedor em que dados sensíveis de clientes sejam carregados como contexto de sessão, faça uma pergunta que a avaliação de retenção zero não responde: quais dados de clientes são carregados na janela de contexto do modelo na inicialização da sessão, e a plataforma foi testada especificamente para confirmar que a manipulação de prompts dentro da sessão não consegue levar o modelo a reproduzir conteúdo do contexto que não fazia parte explicitamente da conversa com o usuário? Essa pergunta revela se a exposição no momento da inferência foi avaliada junto com a retenção após a sessão.
- Pergunte quais dados de clientes são carregados na janela de contexto no início da sessão
- Pergunte se foram realizados testes de injeção de prompt dentro da sessão para extração de contexto
- Pergunte sobre o isolamento multilocatário da inferência em infraestrutura compartilhada
- Pergunte sobre testes de confidencialidade do prompt de sistema
O que exigir
Pergunte diretamente:
“Quais dados de clientes são carregados na janela de contexto do modelo na inicialização da sessão, e sua plataforma foi testada especificamente para confirmar que a manipulação de prompts dentro da sessão não consegue reproduzir conteúdo do contexto que não fazia parte da conversa explícita com o usuário?”
O que esperar como evidência
- Descrição do conteúdo da janela de contexto: o que é carregado no início da sessão
- Resultados dos testes de injeção de prompt dentro da sessão para extração de contexto
- Validação do isolamento multilocatário da inferência
- Resultados dos testes de confidencialidade do prompt de sistema
Um fornecedor que confirme a configuração de retenção zero deve ser questionado sobre a exposição do contexto dentro da sessão. A retenção zero trata da persistência após a sessão. Os testes dentro da sessão tratam da janela de exposição durante a própria sessão. Ambos são necessários.
Como comprovar
- Documentação do conteúdo da janela de contexto
- Registros de testes de segurança dentro da sessão
- Registros de validação do isolamento multilocatário
- Avaliação da confidencialidade do prompt de sistema
Principal conclusão
Retenção zero: configurada. Contexto da conta do cliente na janela de contexto: presente durante toda a sessão. Manipulação de prompts dentro da sessão para extrair esse contexto: possível em condições específicas. O controle de retenção tratou corretamente a persistência após a sessão. A exposição no momento da inferência era um risco diferente, que a avaliação de retenção não abrangeu. A retenção zero é um controle necessário. Ela não é suficiente quando os dados que não devem persistir estão presentes no ambiente de inferência durante a sessão e acessíveis à extração dentro da sessão. A minimização do escopo da janela de contexto, os testes de confidencialidade do prompt de sistema e os testes de injeção dentro da sessão são os controles que tratam do que os controles de retenção não tratam.