Capítulo 36 — Segurança de IA e aprendizado de máquina: desempenho e escala
Mapa da aula
Aula 36 publicada. Mapa, exemplo, EX106.
flowchart TD
N0["36.1 Controles de segurança custam desempenho"]
N1["36.2 Consumo ilimitado"]
N2["36.3 Dimensionando cotas"]
N3["36.4 Escala e eficácia dos controles"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX106"]
Desenho lógico
flowchart LR
N0["36.1 Controles de segurança custam desempenho"]
N1["36.2 Consumo ilimitado"]
N2["36.3 Dimensionando cotas"]
N3["36.4 Escala e eficácia dos controles"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX106"]
[36.1 Controles de segurança custam desempenho]
|
v
[36.2 Consumo ilimitado]
|
v
[36.3 Dimensionando cotas]
|
v
[36.4 Escala e eficácia dos controles]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX106]
Objetivos de aprendizagem
Você vai (1) relacionar a engenharia de desempenho (latência, vazão, custo) aos controles de segurança; (2) defender-se contra consumo ilimitado e negação de serviço; (3) dimensionar cotas e orçamentos; e (4) manter os controles eficazes em escala.
36.1 Controles de segurança custam desempenho
Cada guardrail, classificador, segundo modelo e etapa de aprovação acrescenta latência e custo. Sob carga, as equipes ficam tentadas a desativar controles. Projete os controles com orçamentos de desempenho desde o início e meça-os como qualquer outra funcionalidade. Um orçamento torna o trade-off explícito: por exemplo, os guardrails podem acrescentar no máximo 150 ms a uma resposta do Wrench. Se um controle excede seu orçamento, a equipe o otimiza ou muda o lugar onde ele roda, em vez de removê-lo sob pressão. Medir os controles continuamente também mostra quando um deles vai ficando mais caro aos poucos, como pode acontecer com um classificador quando os documentos ficam mais longos.
36.2 Consumo ilimitado
O OWASP LLM10 cobre ataques que esgotam recursos ou orçamentos: entradas extremamente longas, prompts que provocam saídas muito longas, laços recursivos de agentes e altos volumes de requisições. Controles: limites de tamanho de entrada, tetos de tokens de saída, timeouts de computação por requisição, número máximo de passos do agente, cotas de tokens por cliente e alertas de custo. O laboratório de token bucket mostra como as configurações de taxa e de rajada trocam o atendimento aos usuários normais pela proteção contra inundações.
"""Lab R: token-bucket limits against unbounded consumption (synthetic).
Simulates 60 seconds of requests from a normal client and a flooding client
against a model endpoint with a per-client token bucket."""
import random
rng = random.Random(4)
def simulate(rate_per_s, burst, reqs):
tokens, last, ok = burst, 0.0, 0
for t in reqs:
tokens = min(burst, tokens + (t - last) * rate_per_s); last = t
if tokens >= 1: tokens -= 1; ok += 1
return ok
normal = sorted(rng.uniform(0, 60) for _ in range(90))
flood = sorted(rng.uniform(0, 60) for _ in range(3000))
for rate, burst in ((5, 20), (2, 10), (1, 5)):
print(f"limit={rate}/s burst={burst:2d} normal_served={simulate(rate, burst, normal):3d}/90 "
f"flood_served={simulate(rate, burst, flood):4d}/3000")
Saída esperada:
limit=5/s burst=20 normal_served= 90/90 flood_served= 319/3000
limit=2/s burst=10 normal_served= 90/90 flood_served= 129/3000
limit=1/s burst= 5 normal_served= 62/90 flood_served= 64/3000
Cada controle limita uma dimensão diferente, e os atacantes vão encontrar a que estiver faltando. O laço descontrolado do Wrench mostrou que faltava o limite de passos.
36.3 Dimensionando cotas
Use percentis do uso observado (por exemplo, o percentil 99 de tokens por usuário por hora) mais uma folga, e diferencie níveis. Reajuste à medida que o uso muda. Combine as cotas com detecção de anomalias, já que os atacantes podem ficar logo abaixo de limites fixos. A terceira configuração do laboratório mostra o risco de chutar: um limite de 1 por segundo com rajada de 5 recusa 28 de 90 requisições normais. O dimensionamento por percentis evita isso partindo do que os usuários reais fazem. Os níveis permitem que uma integração intensa, mas legítima, tenha uma cota maior sem aumentar a de todos. Um atacante que descobre o limite pode ficar logo abaixo dele, então a detecção de anomalias em padrões, como a razão de entradas distintas, cobre o que limites fixos não conseguem.
36.4 Escala e eficácia dos controles
Em escala, eventos raros se tornam comuns: uma taxa de sucesso de injeção de 0,1% sobre 10 milhões de documentos por mês dá 10.000 sucessos. Controles que dependem de revisão humana precisam ser dimensionados para esse volume, ou projetados de modo que cada sucesso tenha impacto limitado. Dez mil sucessos por mês não podem ser revisados um a um com cuidado por uma equipe pequena, então o projeto precisa tornar cada um deles inofensivo por si só: uma proposta contaminada que exige confirmação, uma ferramenta que pode comentar, mas não fechar. Taxas aceitáveis em um piloto podem se tornar inaceitáveis em produção apenas por causa do volume, por isso Sam recalcula as contagens esperadas sempre que o uso cresce.
36.5 Exemplo resolvido (caso sintético da NRS)
Uma integração com defeito fez o Wrench entrar em laço: cada resultado de ferramenta disparava outra busca, chegando a 400 passos em uma tarefa e consumindo o orçamento de um dia. Sam definiu um máximo de 12 passos por tarefa, um teto de tokens por tarefa e um alerta de custo em 150% da mediana diária. O classificador de injeção passou a rodar apenas sobre o conteúdo recuperado, e não sobre todas as mensagens, o que cortou seu custo em 60% sem reduzir a cobertura do caminho não confiável. Mover o classificador é seguro porque o caminho não confiável é por onde chegam as injeções; mensagens digitadas por técnicos autenticados não são o risco para o qual ele foi construído.
36.6 Erros e limites
Três erros são comuns: limites por contagem de requisições que ignoram o custo de tokens e de computação; desativar controles sob carga; e projetos de revisão humana que não escalam com o volume. Contar apenas requisições permite que um único prompt enorme custe tanto quanto milhares de pequenos. Desativar controles sob carga cria exatamente as condições que um atacante escolheria, já que inundações podem ser usadas para provocar isso. Projetos de revisão que supõem um número fixo de casos quebram quando o volume cresce. A revisão de operações de Sam pergunta, para cada controle, qual é seu custo por requisição e o que acontece com ele a dez vezes o tráfego atual.
Exercícios
- EX106 — Leitura do laboratório. Qual configuração do laboratório protege contra a inundação atendendo plenamente o cliente normal com o limite mais apertado? Rubrica: 3 = 2/s com rajada 10: 90/90 normal, 129/3000 inundação; 2 = só a configuração; 1 = vago; 0 = errado.
- EX107 — Aritmética de escala. Com 0,05% de sucesso sobre 4 milhões de documentos por mês, quantos sucessos há por mês? Rubrica: 3 = 2.000, com a implicação; 2 = só o número; 1 = deslize; 0 = nenhum.
- EX108 — Limites de laço. Liste quatro limites para laços de agentes. Rubrica: 3 = máximo de passos, tokens por tarefa, tempo de relógio, alertas de custo/botão de desligamento; 2 = três; 1 = um ou dois; 0 = nenhum.
Síntese
Desempenho e segurança estão acoplados. Controles com orçamento, cotas atentas ao custo de computação e limites de laço defendem contra o consumo ilimitado e mantêm a proteção acessível em escala.
Continue estudando — capítulo 36 de 50
← Capítulo 35 (rascunho) · Índice de capítulos do curso · Capítulo 37 (rascunho) →