Capítulo 18 — Segurança de IA e aprendizado de máquina: controles
Mapa da aula
Aula 18 publicada. Mapa, exemplo, EX052.
flowchart TD
N0["18.1 Serviço de políticas"]
N1["18.2 Controles de entrada"]
N2["18.3 Controles de saída"]
N3["18.4 Confirmação humana"]
N4["18.5 Verificando os controles"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX052"]
Desenho lógico
flowchart LR
N0["18.1 Serviço de políticas"]
N1["18.2 Controles de entrada"]
N2["18.3 Controles de saída"]
N3["18.4 Confirmação humana"]
N4["18.5 Verificando os controles"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX052"]
[18.1 Serviço de políticas]
|
v
[18.2 Controles de entrada]
|
v
[18.3 Controles de saída]
|
v
[18.4 Confirmação humana]
|
v
[18.5 Verificando os controles]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX052]
Objetivos de aprendizagem
Você vai (1) implementar um serviço de políticas para as ferramentas dos agentes; (2) configurar controles de entrada e de saída; (3) implementar corretamente a confirmação humana; e (4) verificar cada controle com testes.
18.1 Serviço de políticas
O serviço de políticas recebe uma ação proposta (ferramenta, parâmetros, identidade do usuário, tipo de conversa) e devolve "permitir" ou "negar", com uma justificativa. As regras são código: "start_return allowed only if order.owner == user and order.status == delivered and today − delivered_date ≤ 30 days and value ≤ €1,000" (start_return só é permitido se o pedido pertence ao usuário, foi entregue há no máximo 30 dias e vale até 1.000 euros). O modelo nunca vê essa lógica nem a contorna. Mantenha as regras pequenas e legíveis para que os revisores possam conferi-las, e registre cada decisão com sua justificativa. A regra espelha a política de devoluções em 30 dias publicada pela Brightwell, de modo que o serviço impõe a mesma promessa que os clientes leem no site.
18.2 Controles de entrada
Limite o tamanho das mensagens; restrinja as fontes de recuperação; marque o conteúdo não confiável com delimitadores; opcionalmente, rode um classificador de injeção como sinal. Abordagens de consulta estruturada, como o StruQ (arXiv:2402.06363), separam instruções de dados na interface do modelo; elas reduzem o risco, mas não o eliminam. Os controles de entrada diminuem a frequência de saídas ruins; não limitam o dano quando uma delas passa. No Ask Brightwell, os controles de entrada são o limite de tamanho do gateway, a recuperação restrita a documentos públicos sem avaliações e os delimitadores em torno do texto recuperado. O prompt com conteúdo separado reduziu as propostas prejudiciais no estudo de Jonas, mas o serviço de políticas continua sendo o controle que limita o dano quando uma injeção passa.
18.3 Controles de saída
Valide as ações estruturadas; escape o texto para seu destino; remova ou limite a uma lista de permitidos os links e as imagens nas respostas (para impedir o vazamento de dados por URLs); confira, onde for viável, as respostas sobre preços ou políticas contra os documentos de origem. No Ask Brightwell, as respostas só podem conter links para o próprio domínio da Brightwell, e as imagens não são renderizadas, porque, do contrário, uma instrução injetada poderia esconder dados de clientes numa URL. As respostas sobre o prazo de devolução são comparadas com a página de políticas atual, o que teria detectado mais cedo a página vencida da campanha de 60 dias. As verificações de saída são testadas com casos plantados, como qualquer outro controle.
18.4 Confirmação humana
Mostre ao usuário exatamente o que vai acontecer, a partir de dados estruturados: "Iniciar uma devolução do pedido 100245 — sofá Oslo, € 899 — com reembolso no cartão final 4421? Sim / Não". Não mostre resumos escritos pelo modelo na confirmação, já que um texto injetado pode fazer ações prejudiciais parecerem inofensivas. Mantenha as confirmações raras o bastante para que as pessoas ainda as leiam. A confirmação do Ask Brightwell usa exatamente esse formato, com os valores do registro do pedido. Como a confirmação aparece apenas para devoluções e mudanças de endereço, os clientes a veem raramente e têm mais chance de lê-la.
18.5 Verificando os controles
Cada controle recebe testes de unidade (as regras permitem e negam os casos certos) e testes de conjunto (os casos de injeção já não provocam ações prejudiciais). Execute-os de novo a cada mudança; um controle que quebra em silêncio durante uma refatoração é pior do que um controle ausente, porque as pessoas confiam nele. O serviço de políticas do Ask Brightwell tem 40 testes de unidade cobrindo casos-limite, como uma entrega feita exatamente 30 dias antes, e o conjunto reservado de injeções roda todas as noites contra a homologação. Quando, mais tarde, uma mudança no prompt feita por um desenvolvedor aumentou as propostas prejudiciais, esses testes e o critério de liberação a detectaram antes do lançamento. Cada teste nomeia a regra que verifica, de modo que uma falha diz ao desenvolvedor qual regra quebrou.
18.6 Exemplo resolvido (caso sintético da Brightwell)
Depois de acrescentar o serviço de políticas e a confirmação estruturada, Jonas executa de novo o conjunto reservado: as devoluções prejudiciais caem de 31 em 80 casos indiretos para 0 em 80 (limite superior ≈ 4%); as devoluções normais ainda se completam em 97% de 500 conversas de teste. Ele acrescenta 40 testes de unidade para as regras de política, incluindo casos-limite como pedidos entregues exatamente 30 dias antes. O limite superior importa: zero em 80 não prova risco zero, apenas que uma taxa alta é improvável. Medir as devoluções normais ao mesmo tempo mostra que o controle não comprou segurança recusando tudo.
18.7 Erros e limites
Três erros são comuns: regras de política escritas no prompt; texto de confirmação escrito pelo modelo; e controles sem testes. O desenho do Ask Brightwell evita cada um. As regras de devolução ficam no serviço de políticas, e não no prompt; a tela de confirmação é montada a partir do registro do pedido; e toda regra tem testes de unidade. Uma regra escrita no prompt pode ser contornada na conversa por uma avaliação plantada. Um controle sem testes pode desaparecer numa refatoração sem que ninguém perceba até o próximo incidente. A tela de confirmação agora tem seu próprio teste.
Exercícios
- EX052 — Regras. Escreva regras de política para uma ferramenta de "atualizar endereço de entrega". Rubrica: 3 = titularidade, situação, verificação, limites, negação por padrão; 2 = três ou quatro; 1 = uma ou duas; 0 = nenhuma.
- EX053 — Controle de links. Por que remover os links externos das respostas? Rubrica: 3 = exfiltração de dados por parâmetros de URL ou carregamento de imagens; 2 = parcial; 1 = vago; 0 = errado.
- EX054 — Resultado. Relate numa frase, com as condições, os resultados da nova execução após o serviço de políticas. Rubrica: 3 = números, limite, conclusão, condições; 2 = falta um; 1 = vago; 0 = nenhum.
Síntese
Os controles que importam são código fora do modelo — serviços de políticas, validadores, confirmação estruturada —, cada um comprovado por testes.
Continue estudando — capítulo 18 de 30
← Capítulo 17 (rascunho) · Índice de capítulos do curso · Capítulo 19 (rascunho) →