Trabalho há vinte anos no setor bancário. Uma coisa que esse tempo me ensinou é que frameworks de conformidade e segurança não existem por motivos burocráticos: eles existem porque alguém, em algum momento, pagou um preço alto por não tê-los.
Quando migrei para IA generativa e comecei a construir sistemas com LLMs para produção, meu primeiro impulso foi procurar o equivalente. Eu queria entender o que o setor já havia desenvolvido para evitar pagar o mesmo preço em uma nova categoria de sistemas. O que encontrei foi um cenário fragmentado, mas coerente. Sete frameworks distintos, cada um abordando o problema por um ângulo diferente. Nenhum suficiente por si só. Juntos, algo próximo de um mapa.
Esta série documenta como apliquei esse mapa a um sistema real em produção. Mas, antes de entrar nos detalhes, vale entender o que cada framework realmente cobre e, principalmente, o que não cobre.
Por que sistemas com LLMs precisam de seu próprio mapa#
A pergunta razoável é: por que não usar os frameworks de segurança e governança que já existem?
A resposta curta é que sistemas com LLMs possuem propriedades com as quais os frameworks tradicionais não foram projetados para lidar:
Comportamento emergente: esses sistemas não seguem um fluxo determinístico. O modelo recebe contexto e decide o que fazer: quais ferramentas chamar, o que dizer, como interpretar instruções ambíguas. Mesmo quando a entrada do usuário parece a mesma, o comportamento pode mudar conforme o contexto recuperado, o histórico da conversa, o estado das ferramentas, a versão do modelo e a configuração de decodificação.
Superfície de ataque semântica: ataques acontecem em linguagem natural, não em pacotes de rede. O adversário não precisa explorar uma vulnerabilidade de software: precisa construir uma frase que faça o modelo agir de maneiras não pretendidas. Essa é uma categoria de ataque que os frameworks de segurança de TI simplesmente não catalogavam até recentemente.
Dependência opaca de terceiros: o comportamento do sistema depende de um modelo que você não treinou, que pode ser atualizado sem aviso e cuja lógica interna você não consegue inspecionar. Há analogias em serviços de nuvem e plataformas SaaS gerenciadas, mas o comportamento do modelo introduz outro tipo de dependência: aquela em que a lógica não é totalmente inspecionável e pode mudar entre versões.
Impacto direto sobre pessoas: um agente com LLM que intermedeia decisões que afetam clientes — recomendações, aprovações, informações — afeta pessoas de maneiras que um sistema CRUD não afeta. Isso aciona obrigações éticas e regulatórias que os frameworks tradicionais de segurança não abordam.
Os sete frameworks que descreverei respondem a esses problemas, cada um por uma direção diferente.
Os sete frameworks#
NIST AI RMF 1.0: o framework de processos#
O National Institute of Standards and Technology publicou o AI Risk Management Framework em janeiro de 2023. É o mais abrangente dos sete e, deliberadamente, o menos prescritivo.
O AI RMF não diz o que fazer. Ele diz como pensar sobre o problema. Organiza a gestão de riscos de IA em quatro funções contínuas:
GOVERN: quem responde pelo sistema, quais valores e políticas orientam seu desenvolvimento e sua operação, e como são tomadas as decisões sobre ele.
MAP: identificar e contextualizar riscos: quem pode ser afetado, em quais circunstâncias, com que probabilidade e impacto.
MEASURE: definir métricas para os riscos identificados e monitorá-las continuamente.
MANAGE: responder aos riscos que se materializam: mitigar, transferir, aceitar ou evitar.
O ponto central do AI RMF é que essas quatro funções não são fases de projeto: são práticas permanentes ao longo de todo o ciclo de vida do sistema. Um sistema avaliado durante o desenvolvimento, mas não monitorado em produção, não está gerenciando seu risco: está ignorando o risco com documentação.
Onde ele ajuda: controles técnicos específicos. É um framework de processos, não um guia de implementação, e, para saber o que construir de fato, você precisa dos outros frameworks.
ISO/IEC 42001:2023: o sistema de gestão#
A ISO/IEC 42001 é a primeira norma internacional especificamente voltada a um sistema de gestão de IA. Publicada em dezembro de 2023, é auditável: as organizações podem buscar certificação segundo ela.
A diferença em relação ao AI RMF é o nível de formalismo. Enquanto o RMF prescreve funções e práticas, a ISO 42001 prescreve cláusulas com requisitos específicos de documentação, políticas e evidências.
Os requisitos mais relevantes para sistemas com LLMs em produção:
Cláusula 5.2 — Política de IA: a organização precisa de uma política documentada que declare seus princípios e compromissos quanto ao uso de IA. Não se trata de um documento técnico, mas de uma declaração de governança aprovada pela liderança.
Cláusula 8.2 — Avaliação de impacto de sistemas de IA: para sistemas que afetam pessoas, a organização deve avaliar formalmente o impacto, incluindo populações vulneráveis, possíveis vieses e mecanismos de contestação.
Cláusula 9.1 — Monitoramento e medição: o desempenho de sistemas de IA precisa ser medido continuamente, com métricas definidas, e não apenas avaliado durante o desenvolvimento.
Onde ela para: prescreve que evidências devem existir, mas não diz como construir os sistemas que as produzem. Um agente com LLM pode estar em plena conformidade com a ISO 42001 e ainda ser tecnicamente inseguro.
OWASP LLM Top 10 (2025): a superfície de ataque do modelo#
O Open Web Application Security Project publicou o primeiro LLM Top 10 em 2023 e o atualizou em 2025. É a taxonomia de vulnerabilidades em sistemas com LLMs mais citada.
As categorias mais relevantes para sistemas com LLMs em produção incluem:
LLM01 — Prompt Injection: o adversário manipula a entrada do modelo para fazer o sistema seguir instruções não autorizadas. A variante mais insidiosa é o prompt injection indireto, em que o ataque não vem diretamente da mensagem do usuário, mas de conteúdo recuperado de fontes externas: documentos, resultados de busca, dados de APIs ou respostas de ferramentas.
LLM02 — Divulgação de informações sensíveis: o modelo ou a aplicação ao seu redor expõe informações que não deveria, incluindo dados de usuários, contexto do sistema, instruções internas ou dados sensíveis recuperados durante a execução.
LLM05 — Tratamento inadequado da saída: a saída do LLM é repassada a sistemas downstream sem validação, sanitização ou autorização adequadas. Se o modelo gera código, SQL, parâmetros de API ou comandos que são executados sem verificações, quem influencia a saída pode influenciar a execução.
LLM09 — Desinformação: o modelo gera informações factualmente incorretas com confiança. Em contextos de decisão, como serviços financeiros, saúde ou suporte jurídico, esse erro pode afetar pessoas reais.
O que ele não oferece: cataloga ameaças, mas não prescreve arquitetura. Saber que prompt injection existe não diz como estruturar um sistema para resistir a ele. Para isso, você precisa dos frameworks de controles.
OWASP Agentic Top 10 (2026): a superfície de ataque do agente#
O OWASP Top 10 for Agentic Applications 2026, publicado em dezembro de 2025, reconhece que sistemas com agentes baseados em LLMs carregam uma categoria de risco distinta da de sistemas simples com LLMs.
A diferença fundamental: em um sistema simples com LLM, o modelo gera texto. Em um sistema agêntico, o modelo toma decisões que produzem efeitos no mundo: chama APIs, acessa bancos de dados, envia mensagens, modifica registros. O alcance do impacto de uma decisão errada é completamente diferente.
Os riscos mais relevantes do Agentic Top 10:
Autorização inadequada: o agente executa ações com mais privilégios do que deveria. Em um sistema multiagente com supervisor e subagentes, um agente comprometido pode elevar privilégios para acessar recursos que não deveria.
Confiança excessiva nas saídas de outros agentes: em um pipeline no qual agentes se comunicam, um agente malicioso ou comprometido pode enviar a agentes downstream instruções disfarçadas de resultados legítimos.
Memória persistente e contexto como vetor de ataque: o estado mantido pelo agente entre interações pode ser envenenado em um turno e explorado em outro. Sistemas com estado têm uma superfície de ataque que sistemas sem estado não possuem.
A lacuna que deixa: assim como o LLM Top 10, cataloga sem prescrever. E, por ser o mais recente dos sete frameworks, ainda possui cobertura mais limitada de casos extremos em sistemas complexos.
NIST SP 800-53r5: o catálogo de controles de segurança#
A NIST Special Publication 800-53, revisão 5, é o catálogo de controles de segurança e privacidade para sistemas de informação federais dos EUA, mas é amplamente adotada fora do contexto federal como referência de controles.
Organizada em famílias — AC: Controle de Acesso, AU: Auditoria e Responsabilização, SI: Integridade do Sistema e da Informação, entre outras —, a 800-53r5 prescreve o que os sistemas devem fazer para serem seguros.
A tradução para sistemas com LLMs não é direta: o framework foi escrito para sistemas determinísticos. Mas as famílias de controles podem ser mapeadas:
AC — Controle de Acesso aplica-se ao fato de que o LLM decide quais ferramentas chamar. Privilégio mínimo significa que as ferramentas acessíveis ao modelo devem ser estritamente necessárias e que o modelo nunca deve ter acesso direto a credenciais.
AU — Auditoria e Responsabilização aplica-se ao registro imutável do que o sistema decidiu: não apenas o que aconteceu, mas quais parâmetros foram enviados a quais ferramentas, com quais resultados.
SI — Integridade do Sistema e da Informação aplica-se à validação da saída: a resposta gerada pelo LLM precisa ser validada antes da entrega, não apenas a entrada recebida.
O que ainda precisa ser projetado: a família de controles SI não possui um controle específico para validação semântica da saída de LLMs. Você pode implementar o SI-15 (Information Output Filtering), mas precisará interpretá-lo para o contexto da linguagem natural.
CIS v8.1: os controles críticos priorizados#
O Center for Internet Security Controls, versão 8.1, define 18 Controles Críticos de Segurança priorizados por impacto. Enquanto a NIST SP 800-53r5 é abrangente, o CIS v8.1 é focado. Ele responde: “se você só puder fazer 18 coisas, faça estas”.
Os controles mais relevantes para sistemas com LLMs:
CIS Control 3 — Proteção de Dados: os dados de clientes que passam pelo contexto do LLM precisam ser tratados com as mesmas políticas de proteção de dados de qualquer outro sistema. O fato de os dados existirem apenas durante uma inferência não os isenta das obrigações de proteção.
CIS Control 8 — Gestão de Logs de Auditoria: logs centralizados, timestamps sincronizados, retenção adequada ao risco e proteção contra modificações. Em um sistema com LLM, isso inclui logs das decisões do modelo, não apenas logs de infraestrutura.
CIS Control 16 — Segurança de Software de Aplicação: segurança no desenvolvimento e nas dependências. Para sistemas com LLMs, isso inclui a cadeia de fornecimento do modelo: de onde vem, como foi validado e quem pode atualizá-lo.
O que o CIS v8.1 não resolve: é um framework de segurança de TI aplicado à IA por extensão. Não possui controles específicos para os vetores de ataque semânticos do OWASP LLM Top 10.
MITRE ATLAS: a base de conhecimento de IA adversarial#
O MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) está para sistemas de IA assim como o MITRE ATT&CK está para a TI tradicional: é uma base de conhecimento de táticas, técnicas e procedimentos usados por adversários para atacar sistemas de machine learning e IA.
A diferença em relação à OWASP é o nível de detalhe sobre atacantes e seus métodos. Enquanto a OWASP categoriza vulnerabilidades, o MITRE ATLAS documenta:
Táticas: o objetivo do adversário em cada fase do ataque — reconhecimento, acesso inicial, persistência, exfiltração
Técnicas: como o adversário realiza cada tática — envenenamento de dados de treinamento, manipulação de entradas no momento da inferência, extração de modelos
Procedimentos: instâncias documentadas de como as técnicas foram usadas em ataques reais
O MITRE ATLAS é particularmente útil para modelagem de ameaças. Ao estruturar “quem são os adversários, quais são seus objetivos e como atacam”, você pode priorizar controles com base em ameaças reais, em vez de hipóteses abstratas.
O que o MITRE ATLAS não resolve: assim como os demais frameworks baseados em ameaças, ele cataloga sem prescrever mitigações. É um mapa de onde vêm os ataques, não um manual para construir defesas.
Como os sete se encaixam#
A tentação é tratar esses frameworks como redundantes — sete maneiras de dizer a mesma coisa —, mas eles não são.
Cada um tem uma perspectiva diferente sobre o mesmo sistema:
NIST AI RMF 1.0 responde: como a organização gerencia riscos ao longo do ciclo de vida?
ISO/IEC 42001 responde: quais evidências a organização pode apresentar de que gerencia IA com responsabilidade?
OWASP LLM Top 10 responde: quais são as vulnerabilidades mais comuns em sistemas com LLMs?
OWASP Agentic Top 10 responde: quais riscos adicionais surgem quando o LLM pode agir no mundo?
NIST SP 800-53r5 responde: quais controles técnicos o sistema deve implementar?
CIS v8.1 responde: quais controles são mais críticos, priorizados por impacto?
MITRE ATLAS responde: como adversários reais atacam sistemas de IA?
Um sistema que usa apenas OWASP conhece suas vulnerabilidades, mas não possui processo de gestão. Um sistema que usa apenas o AI RMF possui processo, mas não orientação sobre quais ameaças enfrentar. Um sistema que usa apenas a ISO 42001 tem documentação, mas pode não possuir controle técnico algum.
Para o tipo de sistema no qual eu trabalhava, precisei das sete perspectivas.
O que esta série aborda#
Nos artigos seguintes, aplico esses frameworks a um agente conversacional com acesso a ferramentas, estado persistente entre turnos e integração com sistemas externos: o tipo de sistema que muitas organizações estão implantando em escala, frequentemente sem o mapa completo.
Mostrarei onde os frameworks ajudam, onde deixam lacunas reais e o que os profissionais que constroem esses sistemas precisam decidir por conta própria, porque a regulação ainda não chegou lá.
Duas décadas no setor bancário me ensinaram que frameworks de conformidade existem porque alguém pagou o preço de não tê-los. Na IA generativa, esse preço ainda está sendo descoberto. Mas os frameworks que temos hoje bastam para evitar começar do zero.
Fontes e referências:
NIST AI RMF 1.0: https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
ISO/IEC 42001:2023: https://www.iso.org/standard/42001
OWASP Agentic Top 10 (2025): https://owasp.org/Top10/2025/
OWASP Agentic Top 10 (2026): https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
NIST SP 800-53r5: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
CIS v8.1: https://www.cisecurity.org/controls/v8-1?utm_source=chatgpt.com
MITRE ATLAS: https://atlas.mitre.org/