Alucinações, privacidade e prompt injection

Um prompt melhor pode reduzir ambiguidades, mas não torna uma aplicação segura nem uma resposta verdadeira. Nesta aula, você vai ligar três riscos que aparecem em usos reais: afirmações sem base, exposição de dados e instruções maliciosas escondidas em entradas. O resultado esperado é um mapa de controles, com limites claros para o modelo e responsabilidades mantidas no sistema e nas pessoas.

Pense num estagiário trabalhando numa sala de arquivos. Uma orientação escrita ajuda a saber qual relatório preparar, mas o crachá ainda precisa limitar portas, documentos e ações. Materiais recebidos de fora passam por triagem, e uma entrega importante recebe revisão. A analogia termina porque o modelo não possui dever profissional nem compreensão confiável de intenção; ele pode tratar uma frase presente no documento como continuação relevante da conversa.

Alucinação exige evidência, não um pedido mais enfático

Chamamos de alucinação uma saída que apresenta informação incorreta ou sem apoio como se fosse válida. Isso pode incluir número inventado, referência inexistente, detalhe ausente no documento ou conclusão que excede a evidência. Escrever “não alucine” expressa uma preferência, mas não fornece a informação certa.

Primeiro classifique a necessidade. Se a resposta depende apenas do texto fornecido, peça vínculo com trechos e permita dizer “não informado”. Se depende de dado atual, conecte uma fonte ou ferramenta autorizada. Se exige cálculo, execute e confira o cálculo. Para assunto de alto impacto, use revisão de pessoa qualificada. A saída deve deixar explícita a diferença entre fato, inferência e pendência.

Para cada afirmação:
- fato do documento: inclua o trecho que sustenta;
- inferência: rotule como hipótese e explique a evidência;
- informação ausente: escreva "não informado";
- dado atual necessário: solicite consulta à fonte autorizada.

Citação também precisa ser verificada. Um link pode existir e não sustentar a frase. Em tarefas importantes, abra a fonte, confira data, autoria, escopo e trecho. Não aceite a autoconfiança do texto como medida de correção.

Privacidade começa antes do prompt

Minimização de dados significa usar somente o necessário para a finalidade. Antes de copiar um documento, pergunte se a ferramenta é aprovada, como os dados são tratados, quem terá acesso e por quanto tempo ficam retidos. Remova segredo, token, senha, documento pessoal e informação contratual que não participa da tarefa. Substituir um nome pode não bastar quando endereço, cargo e evento ainda identificam alguém.

Não coloque credenciais em prompt, código do navegador ou exemplo publicado. Uma chave deve permanecer num serviço protegido, com escopo, rotação e registro. Da mesma forma, o modelo não deve receber o banco inteiro para responder uma pergunta sobre um registro. A aplicação busca somente os campos autorizados depois de confirmar identidade e permissão.

Se o uso envolve saúde, finanças, trabalho, educação ou crianças, trate a decisão como projeto de risco, não como exercício de redação. Política interna, base legal, contrato com fornecedor e revisão especializada podem ser necessários. O prompt nunca substitui esses requisitos.

Prompt injection transforma dado em tentativa de comando

Prompt injection ocorre quando uma entrada altera o comportamento pretendido do modelo. Pode ser direta, quando a pessoa escreve uma instrução no chat, ou indireta, quando a instrução aparece numa página, e-mail ou documento que o sistema pediu para analisar. Delimitadores ajudam a mostrar fronteiras, mas não garantem que o modelo ignorará o conteúdo.

Um teste didático pode inserir num documento fictício uma frase pedindo para abandonar o resumo e revelar informação privada. Não use dado real nem execute a ação. O resultado esperado do sistema é manter a tarefa, marcar a tentativa e não acessar segredo algum. Mesmo se o modelo falhar, controles externos devem impedir dano.

Entrada adversarial de teste: uma frase dentro do documento tenta mudar a tarefa.
Propriedade esperada: a saída sinaliza a tentativa e nenhuma ferramenta é chamada.

Defesa em profundidade limita consequência

Mantenha instruções de maior prioridade fora do conteúdo do usuário. Dê ao modelo somente ferramentas necessárias e valide argumentos em código. Aplique controle de acesso antes da leitura e antes da escrita. Para enviar mensagem, comprar, excluir, publicar ou movimentar dinheiro, mostre a ação a uma pessoa e exija confirmação vinculada ao usuário e ao objeto correto.

Use listas de destinos permitidos, sandbox, limites de volume, timeout e logs sem dados excessivos. Trate saída como não confiável antes de renderizar HTML, montar comando ou consulta. Nenhuma dessas medidas isolada é perfeita; juntas, elas reduzem a chance de uma geração virar ação indevida.

No laboratório, revise a fronteira do documento e acrescente as ferramentas que um produto imaginário teria. Para cada uma, escreva a permissão mínima e o ponto de aprovação. A interface não abre links nem chama modelo, então o exercício avalia seu desenho, não a robustez de um fornecedor.

O erro comum é tentar resolver arquitetura com uma instrução longa: “você é seguro, nunca revela nada e sempre obedece”. Isso não restringe rede, banco ou ações. Você concluiu a aula quando consegue responder duas perguntas: que evidência sustenta cada afirmação e qual controle impede dano se o modelo seguir a instrução errada.