Capítulo 9 — Dados e bancos de dados
Mapa da aula
Aula 09 publicada. Mapa, exemplo, EX025.
flowchart TD
N0["9.1 Dados relacionais"]
N1["9.2 Saídas do modelo e bancos de dados"]
N2["9.3 Bancos de dados vetoriais"]
N3["9.4 Minimização e retenção"]
N4["9.6b Exclusão de dados a pedido"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX025"]
Desenho lógico
flowchart LR
N0["9.1 Dados relacionais"]
N1["9.2 Saídas do modelo e bancos de dados"]
N2["9.3 Bancos de dados vetoriais"]
N3["9.4 Minimização e retenção"]
N4["9.6b Exclusão de dados a pedido"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX025"]
[9.1 Dados relacionais]
|
v
[9.2 Saídas do modelo e bancos de dados]
|
v
[9.3 Bancos de dados vetoriais]
|
v
[9.4 Minimização e retenção]
|
v
[9.6b Exclusão de dados a pedido]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX025]
Objetivos de aprendizagem
Você vai (1) projetar esquemas relacionais simples e escrever consultas; (2) prevenir injeção em consultas a bancos de dados; (3) entender os bancos de dados vetoriais usados na recuperação; e (4) aplicar controle de acesso e minimização aos dados de IA.
9.1 Dados relacionais
Tabelas guardam registros; chaves ligam tabelas; consultas SQL recuperam e alteram dados. O sistema de agendamento da LCH tem tabelas de pacientes, clínicas e consultas. As consultas precisam ser parametrizadas: montar SQL juntando cadeias com entradas do usuário (ou do modelo) possibilita a injeção de SQL. Com uma consulta parametrizada, o banco de dados trata um identificador de paciente como valor, de modo que um texto como uma aspa seguida de palavras-chave SQL não consegue mudar o significado da consulta. Isso importa ainda mais quando os valores vêm de um modelo, que pode ser conduzido por sua entrada a produzir esse tipo de texto. A ferramenta de agendamento da LCH passa cada valor como parâmetro, e um teste com um identificador que parece injeção confirma isso.
9.2 Saídas do modelo e bancos de dados
Se um LLM gera consultas ou parâmetros de consulta, trate-os como entrada não confiável: use consultas parametrizadas, restrinja a conta do banco de dados ao mínimo de tabelas e operações e valide os valores. Um LLM capaz de escrever SQL arbitrário com uma conta de administrador é um sério risco de agência excessiva (OWASP LLM06). O Ask Lumen não gera SQL; ele propõe uma marcação cujos campos a ferramenta de agendamento coloca em consultas fixas e parametrizadas. A conta de banco de dados da ferramenta pode inserir e cancelar consultas, mas não pode ler outras tabelas nem alterar o esquema. Mesmo que o modelo fosse totalmente manipulado, o pior resultado se limitaria ao que essa conta permite, e a verificação de política o restringe ainda mais ao paciente conectado.
9.3 Bancos de dados vetoriais
A geração aumentada por recuperação armazena trechos de documentos como embeddings e recupera os mais semelhantes a cada pergunta. O controle de acesso precisa ser aplicado no momento da recuperação, com as permissões do usuário; caso contrário, o chatbot pode recuperar e revelar documentos que o usuário não deveria ver (OWASP LLM08, fraquezas de vetores e embeddings). Documentos acrescentados ao repositório também podem carregar instruções injetadas. Filtrar no momento da recuperação, em vez de pedir ao modelo que retenha conteúdo restrito, é a abordagem confiável: o modelo não pode vazar um texto que nunca recebeu.
9.4 Minimização e retenção
Armazene apenas os dados de que precisa, pelo tempo de que precisa. Os logs de conversas de chatbots costumam conter dados pessoais; defina prazos de retenção e regras de acesso. No Ask Lumen, a LCH guarda os logs de conversas por um prazo fixo, necessário para revisão de qualidade e investigação de incidentes, e depois os apaga. Só as equipes de segurança e de qualidade podem lê-los. A minimização também se aplica ao que é enviado ao provedor do modelo: identificadores de pacientes de que o modelo não precisa para responder ficam fora do prompt.
9.5 Exemplo resolvido (caso sintético da LCH)
O índice de recuperação do Ask Lumen incluía documentos de escala da equipe com os telefones dos funcionários. Uma pergunta de teste sintética, "quem está de plantão hoje à noite e como falo com essa pessoa?", devolveu um número de telefone a um paciente. A LCH retirou os documentos da equipe do índice voltado aos pacientes, acrescentou um campo de classificação de documentos e passou a filtrar a recuperação por público. O vazamento não exigiu ataque nenhum, apenas uma pergunta, o que mostra que o controle de acesso precisa ser projetado dentro da recuperação, e não testado depois da implantação. O campo de classificação agora orienta toda recuperação.
9.6 Erros e limites
Três erros são comuns: SQL montado com cadeias; um único índice de recuperação para todos os públicos; e retenção indefinida dos logs de chat. SQL montado com cadeias deixa a saída de um modelo, ou o texto digitado por um paciente, tornar-se parte de um comando de banco de dados. Um único índice de recuperação para todos os públicos causou o vazamento do telefone de funcionário no exemplo resolvido. A retenção indefinida dos logs de chat acumula informações pessoais e de saúde que se tornam um alvo e um passivo. Cada erro tem uma correção simples e conhecida, muito mais barata antes da implantação do que depois de um incidente.
9.6b Exclusão de dados a pedido
Quando um paciente pede à LCH que apague seu histórico de chat, a exclusão precisa alcançar todas as cópias: a tabela de conversas, os logs e quaisquer entradas do repositório vetorial construídas a partir desses chats. A equipe mantém um mapa de por onde passa o texto dos pacientes, para que um pedido possa ser concluído e confirmado dentro do prazo declarado pela clínica. O repositório vetorial é a cópia mais esquecida, porque ali o texto fica armazenado como trechos e embeddings, e não como uma conversa reconhecível. A LCH marca cada trecho com a conversa de onde ele veio, para que a exclusão consiga encontrá-lo.
Exercícios
- EX025 — Consulta parametrizada. Por que consultas parametrizadas são mais seguras que a concatenação de cadeias? Rubrica: 3 = dados não conseguem mudar a estrutura da consulta; impede injeção; 2 = parcial; 1 = vago; 0 = errado.
- EX026 — Acesso na recuperação. O que deu errado com os documentos de escala e qual é a correção geral? Rubrica: 3 = público errado no índice; aplicar filtragem por público/usuário na recuperação; 2 = parcial; 1 = vago; 0 = nenhuma.
- EX027 — Retenção. Proponha uma regra de retenção para os logs de chat do Ask Lumen. Rubrica: 3 = prazo, finalidade, acesso, exclusão; 2 = três; 1 = um; 0 = nenhum.
Síntese
Os repositórios de dados alimentam e registram os sistemas de IA. Consultas parametrizadas, contas com menor privilégio, recuperação atenta ao público e retenção mínima impedem que eles se tornem o vazamento.
Continue estudando — capítulo 09 de 40
← Capítulo 08 (rascunho) · Índice de capítulos do curso · Capítulo 10 (rascunho) →