Capítulo 1 — Por Que a Segurança de IA É Diferente

Primeiro post do passeio capítulo a capítulo pelo LLM Primer VII: Segurança de IA. O capítulo que sustenta que a segurança de IA não é apenas segurança tradicional com um adjetivo de ML colado — o substrato mudou, e todo capítulo posterior decorre dessa mudança.

Por que este capítulo existe

Por três décadas, a engenharia de segurança descansou sobre uma fundação estável: código e dados são coisas distintas, vulnerabilidades são discrepâncias entre comportamento especificado e real, e patches as fecham. Modelos de linguagem grandes quebram essa fundação de uma maneira específica. O comportamento que precisa ser defendido está codificado não em código-fonte, mas em bilhões de pesos aprendidos, executados contra entradas que misturam instruções confiáveis com conteúdo não confiável na mesma string. A "vulnerabilidade" muitas vezes não é um bug — é o modelo fazendo exatamente aquilo para o qual foi treinado, em um contexto que os projetistas não anteciparam. Não existe patch para "o modelo foi prestativo demais". Existe apenas redesenho, retreinamento ou contenção adicional. Este capítulo nomeia as diferenças estruturais que moldam tudo o que se segue.

1.1 O substrato mudou

A segurança de aplicações tradicional funciona porque o comportamento está especificado em código e os defeitos são localizáveis. SQL injection tem correção estrutural — consultas parametrizadas — porque existe distinção sintática entre query e parâmetro. Um modelo de linguagem não tem tal especificação. Ele tem um objetivo de treinamento e uma distribuição de pesos, e seu comportamento em qualquer entrada específica é emergente. Quando um modelo recusa uma formulação e obedece a outra, não existe linha a corrigir. A pergunta de segurança muda de "existe um bug neste caminho de código" para "do que este sistema é capaz, e sob quais condições essa capacidade se torna perigosa?" A segurança tradicional também assumia determinismo como baseline; aqui o baseline é probabilístico. Um filtro de segurança que passa em mil casos de teste pode falhar no milésimo primeiro porque o sampling desenhou um caminho diferente. O defensor raciocina em distribuições e intervalos de confiança, não em provas de inalcançabilidade. O OWASP Top 10 para Aplicações LLM, revisado em 2025, é uma tentativa de nomear essa nova camada — com prompt injection em LLM01 e consumo ilimitado em LLM10 — mas é um piso acima do piso já existente para aplicações web, não uma substituição dele.

1.2 A superfície de ataque se ampliou

Uma aplicação integrada a LLM introduz superfícies que antes não existiam. O próprio prompt é uma concatenação de instruções do desenvolvedor, contexto recuperado, entrada do usuário e saídas de ferramentas — tudo em forma de tokens que o modelo lê sem fronteiras de confiança nativas. Se o usuário pode influenciar qualquer parte, ele compartilha o mesmo canal que o desenvolvedor. O caminho de recuperação é a segunda superfície nova: todo documento indexado se torna uma entrada indireta, e qualquer um que possa influenciar o que entra no índice pode influenciar o que o modelo vê. Greshake e colegas nomearam isso como injeção indireta de prompt em 2023 e mostraram que o canal é real e difícil de fechar. A fronteira de uso de ferramenta é a terceira: cada ferramenta concedida ao modelo é um privilégio cujas consequências deixam o texto de resposta e alcançam sistemas reais. O pipeline de treinamento é a quarta, já que qualquer dado usado para atualizar o modelo se torna parte da fronteira de confiança. O artefato do modelo é a quinta — binários grandes cuja desserialização, como demonstrou o CVE-2024-3568, pode executar código no carregamento. O manejo de saída é a sexta, já que conteúdo gerado por modelo repassado adiante é entrada não confiável com outro nome. O MITRE ATLAS cataloga as táticas e técnicas contra essa superfície ampliada.

1.3 Modelos estão se tornando infraestrutura

Entre 2012 e 2022, modelos eram funcionalidades dentro de aplicações. Um sistema de recomendação que falhava produzia recomendações piores. Modelos de linguagem grandes, sobretudo com uso de ferramentas, mudaram isso. O modelo passa cada vez mais a ser a camada de orquestração — lendo documentos, decidindo qual ferramenta chamar, redigindo a mensagem, gerando o código que outro componente executa. Ele costuma ser o componente mais poderoso do sistema e é também o mais maleável, guiado por entradas em linguagem natural que qualquer um pode redigir. Um banco de dados tradicional tem linguagens de consulta e controles de acesso; um LLM agindo como orquestrador não tem nenhuma dessas restrições intrínsecas, apenas as que a aplicação ao redor adicionou. É isso que "infraestrutura" significa aqui: componentes portantes cuja comprometição se propaga. Infraestrutura ganha SLOs definidos, logging abrangente, controle de mudança e resposta a incidentes. A maioria dos deployments de LLM entre 2024 e 2025 ainda não havia atingido essa maturidade. O enquadramento como infraestrutura chega também ao procurement: quando uma organização embute um serviço de LLM gerenciado na sua stack, a disciplina de atualização de modelo do fornecedor, os gates de avaliação e as práticas de disclosure passam a fazer parte do perfil de risco do comprador.

O que o Capítulo 1 prepara

O restante do livro é resposta às mudanças estruturais nomeadas aqui. O Capítulo 2 introduz threat modeling adaptado a sistemas LLM — os frameworks STRIDE e PASTA voltados para ativos, adversários e superfícies de ataque que não aparecem em diagramas convencionais. O Capítulo 3 percorre a dimensão de dados ao longo de todo o ciclo de vida. Os capítulos 4 a 6 percorrem o interior de prompt e interação: injeção, filtragem e RAG. Os capítulos 7 a 9 percorrem a camada do modelo. Os capítulos 10 a 12 percorrem a arquitetura de sistema em torno dele. Os capítulos 13 a 15 adicionam o perímetro regulatório, de IA responsável e organizacional. O Capítulo 16 percorre o fine-tuning como sua própria superfície de segurança, e o Capítulo 17 olha para as ameaças que ainda estão se formando. Todo o arco descansa sobre a premissa que este capítulo estabeleceu: o substrato mudou, e a disciplina precisa mudar com ele.

Próximo — Capítulo 2: Threat Modeling para Sistemas LLM. As quatro perguntas de Shostack, STRIDE e PASTA aplicados a ativos LLM e o MITRE ATLAS como catálogo de táticas dos adversários que esta nova superfície atrai.