Key Takeaways
- SOC 2 e ISO 27001 certificam os controles da sua organização, não uma ferramenta — nunca afirme "o Ollama é compatível com SOC 2" ou "o vLLM é certificado ISO 27001". Apresente tudo como preparação para os controles que um auditor vai verificar.
- SOC 2 avalia com base em cinco Trust Services Criteria (segurança, disponibilidade, confidencialidade, integridade de processamento, privacidade); ISO 27001 avalia com base nos controles Annex A dentro de um ISMS documentado.
- O endpoint de inferência precisa de controle de acesso e log estruturado de requisições — a maioria das engines auto-hospedadas (Ollama, vLLM, TGI) não oferece nada disso por padrão e precisa de um gateway na frente.
- Criptografe os pesos do modelo e os logs de prompts/respostas em repouso (criptografia de disco) e em trânsito (TLS) — os mesmos controles já aplicados a qualquer outro repositório de dados de produção.
- Mesmo modelos open-weight precisam de uma avaliação documentada de risco de fornecedor: identidade do publicador, verificação de checksum, termos de licença e CVEs conhecidas no stack de serving.
- Plataformas de automação de compliance (Vanta, Drata, Secureframe) podem coletar evidências automaticamente da infraestrutura em nuvem, mas um servidor de inferência auto-hospedado geralmente precisa de integração customizada ou upload manual de evidências.
- Este artigo não é aconselhamento jurídico ou de compliance — a decisão final de escopo e controles é do seu auditor.
Isso É Aconselhamento Jurídico ou de Compliance?
Não — este guia não é aconselhamento jurídico ou de compliance. Ele explica, em nível técnico, as categorias de controles que um auditor SOC 2 ou ISO 27001 costuma verificar e como elas se aplicam a um deployment de LLM auto-hospedado. Se um controle específico satisfaz sua auditoria depende do julgamento do seu auditor, da avaliação de riscos da sua organização e da declaração de escopo exata que você apresentar. Consulte um auditor qualificado ou sua área de compliance antes de agendar uma auditoria ou fazer qualquer declaração de compliance.
O Que Exigem os Trust Services Criteria da SOC 2?
A SOC 2 avalia uma organização com base em cinco Trust Services Criteria (TSC), e cada um deles se aplica a um sistema de LLM auto-hospedado assim que ele toca dados de produção. Um auditor não testa o modelo — testa se sua organização consegue demonstrar que o controle existiu e funcionou durante o período de revisão.
| Critério | O que os auditores verificam | Controle no stack de LLM |
|---|---|---|
| Segurança | Controle de acesso, log, gestão de vulnerabilidades | RBAC + MFA no gateway de inferência |
| Disponibilidade | Uptime, redundância, plano de DR | Serving multi-nó + backups testados |
| Confidencialidade | Classificação de dados, necessidade de saber | Pesos + logs criptografados em repouso |
| Integridade de processamento | Precisão, completude, tempestividade | Modelos fixados por versão + logs de saída |
| Privacidade | Aviso, consentimento, minimização de dados | Política documentada de retenção de prompts |
O Que Exige o Annex A da ISO 27001?
A ISO 27001 certifica o Sistema de Gestão de Segurança da Informação (ISMS) de uma organização, e o Annex A é a lista de referência de controles da qual o ISMS se abastece — não um checklist aplicado diretamente a um único sistema. Um LLM auto-hospedado está dentro do escopo do ISMS como qualquer outro ativo: precisa de avaliação de risco, uma entrada na Declaração de Aplicabilidade e evidências de que os controles relevantes funcionam.
| Área do Annex A | Aplicação ao stack de LLM |
|---|---|
| A.5 Organizacional | Revisão de risco de fornecedor do publicador do modelo |
| A.5.19–22 Relações com fornecedores | Procedência do modelo e verificação de licença |
| A.8 Tecnológico | Hardening de endpoint, criptografia, log |
| A.8.16 Atividades de monitoramento | Logs de auditoria de requisições/respostas |
| A.8.24 Criptografia | TLS em trânsito, criptografia de disco em repouso |
| A.5.29 Continuidade | Runbook de resposta a incidentes para o serving do modelo |
Que Controle de Acesso e Log o Endpoint de Inferência Precisa?
Um auditor espera ver quem chamou o modelo, com qual credencial e quando — uma exigência que nenhuma das engines auto-hospedadas comuns cumpre sem um gateway na frente. O Ollama vincula por padrão a `127.0.0.1:11434` e não tem contas de usuário; vLLM e Hugging Face TGI expõem uma API HTTP compatível com OpenAI sem autenticação integrada.
Use um API gateway (Kong, Envoy, ou a camada de gestão de API de um provedor cloud) na frente da engine de inferência para adicionar chaves de API ou OAuth2 por chamador, e registre cada requisição com identidade, timestamp, versão do modelo e contagem de tokens em um sistema que seu SIEM consiga ingerir.
- Autenticação: chaves de API ou OAuth2 no gateway, nunca um token compartilhado por todos os chamadores
- Autorização: acesso baseado em papéis — quem pode chamar qual modelo, quem vê endpoints de admin/métricas
- Campos do log de auditoria: identidade do chamador, timestamp, modelo + versão, endpoint chamado, status da resposta
- Acesso admin: MFA obrigatória para qualquer pessoa com acesso shell ou de configuração ao host de inferência
Como Criptografar os Pesos do Modelo e os Logs de Prompts?
Os pesos do modelo, logs de prompts e de respostas precisam da mesma criptografia em repouso e em trânsito que um auditor já espera para qualquer outro repositório de dados de produção. Os pesos em si geralmente não são secretos, mas o disco do servidor de inferência costuma armazenar também prompts em cache, adaptadores fine-tunados e logs que são.
Use criptografia de disco completo (LUKS no Linux, BitLocker no Windows, FileVault no macOS) no host de inferência como base. Adicione terminação TLS no gateway para toda chamada de API de entrada — nunca exponha a porta de inferência bruta em HTTP em texto claro, mesmo dentro de uma VPC.
- Em repouso: criptografia de disco completo no host, volume criptografado para o banco de logs de prompts
- Em trânsito: TLS entre chamador → gateway → engine de inferência, sem salto interno em texto claro
- Gestão de chaves: chaves armazenadas em um KMS/vault, rotacionadas conforme cronograma documentado
Como É a Gestão de Mudanças para Atualizações de Modelo?
Toda troca de versão de modelo, mudança de quantização ou edição de prompt de sistema é uma mudança de produção e precisa da mesma trilha de aprovação que um deployment de código. Auditores procuram especificamente evidências de que as mudanças foram revisadas e aprovadas antes de irem para produção.
- Fixar o artefato exato do modelo (checksum, não uma tag mutável "latest")
- Exigir uma etapa de aprovação documentada antes de qualquer mudança de modelo ou prompt de sistema em produção
- Registrar cada mudança com quem aprovou, quando e por quê
- Manter um caminho de rollback para o artefato anterior fixado por versão
Como Avaliar o Risco de Fornecedor em Modelos Open-Weight?
"Open-weight" não significa "sem fornecedor" — o publicador do modelo é uma parte da cadeia de suprimentos assim como um fornecedor SaaS, e um auditor espera uma avaliação de risco documentada para isso. Este é um dos controles mais comumente esquecidos: times tratam um arquivo GGUF ou safetensors baixado como interno, não como de terceiros, mesmo que ele venha de fora da organização.
- Identidade do publicador: organização conhecida (Meta, Mistral AI, Alibaba/Qwen, Microsoft) vs. fonte anônima
- Verificação de checksum: correspondência SHA-256 com o hash publicado pelo editor antes do deployment
- Revisão de licença: termos de uso comercial, restrições de redistribuição
- CVEs do stack de serving: rastrear vulnerabilidades conhecidas em llama.cpp, vLLM ou TGI — não só o arquivo do modelo
Como É a Resposta a Incidentes para um Sistema de Serving de Modelo?
Um sistema de serving de modelo tem categorias de incidentes que um runbook padrão de aplicação web não cobre — exfiltração de modelo, prompt injection que vaza dados através da própria saída do modelo, e comprometimento do endpoint de inferência — cada uma precisa de um caminho de resposta nomeado.
- Exemplos de gatilhos: mudança não autorizada no arquivo de pesos, pico de requisições em nível de credencial, padrão de prompt injection nos logs
- Etapa de contenção: capacidade de isolar ou tirar do ar o endpoint de inferência sem uma interrupção total do sistema
- Preservação de evidências: manter logs brutos durante a janela do incidente
- Frequência de testes: exercício de mesa pelo menos anual, documentado
O Que Uma Política de Retenção Para Logs de Prompts Deve Cobrir?
Logs de prompts são os dados de maior risco produzidos pelo seu stack de LLM, porque frequentemente contêm o mesmo conteúdo sensível que um usuário digitaria em qualquer outro sistema de negócio. Uma política de retenção por escrito é um controle que um auditor vai pedir para ver especificamente, não algo que se infere da sua política geral de retenção de dados.
- Janela de retenção: defina um número específico de dias/meses, não "indefinidamente"
- Controle de acesso: o repositório de logs de prompts tem sua própria lista de acesso restrita
- Minimização: registre metadados por padrão; log de conteúdo completo apenas quando justificado e com prazo limitado
- Processo de exclusão: documentado e idealmente automatizado
Como o Servidor de Inferência Deve Ser Segmentado na Rede?
O servidor de inferência deve ficar em sua própria zona de rede, acessível apenas via gateway autenticado — não na mesma sub-rede que os servidores de aplicação gerais. Isso limita o raio de impacto caso outro serviço na rede seja comprometido e dá ao auditor um diagrama de rede claro para revisar.
Quais Ferramentas Auto-Hospedadas Oferecem Controles Relevantes para Auditoria?
Nenhuma das engines de inferência comuns entrega uma trilha de auditoria pronta — a diferença está em quanto você precisa construir versus quanto uma plataforma já oferece. Isto é uma comparação de prontidão, não uma declaração de compliance sobre qualquer uma dessas ferramentas.
| Ferramenta | Auth/Log integrado | Instrumentação necessária |
|---|---|---|
| Ollama | Nenhum (vincula a localhost) | Reverse proxy + auth + exportação SIEM |
| vLLM | Apenas métricas Prometheus | API gateway (OAuth2/chaves) + log de auditoria |
| Hugging Face TGI | Apenas métricas Prometheus | API gateway + log de auditoria, igual ao vLLM |
| Plataformas corporativas | RBAC + log de auditoria integrados | Ainda exige documentação ISMS |
Uma Plataforma de Automação de Compliance Pode Ajudar com um LLM Auto-Hospedado?
Plataformas de automação de compliance — Vanta, Drata e Secureframe são as três mais usadas — coletam evidências automaticamente de infraestrutura em nuvem, sistemas de RH e provedores de identidade, mas um servidor de inferência auto-hospedado on-premise geralmente fica fora da lista de integrações padrão delas.
Use uma plataforma de automação de compliance se você opera um programa SOC 2 ou ISO 27001 mais amplo em toda a empresa e quer monitoramento contínuo para tudo, exceto a camada de LLM auto-hospedada.
| Plataforma | Foco |
|---|---|
| Vanta | Ampla cobertura de frameworks, comum em startups |
| Drata | Monitoramento contínuo de controles, integrações profundas |
| Secureframe | Fluxos combinados SOC 2 + ISO 27001 |
Essas plataformas automatizam a coleta de evidências para o seu ambiente de controle mais amplo — elas não certificam sua infraestrutura de LLM auto-hospedada por si mesmas, e a PromptQuorum não tem atualmente relação de afiliação com nenhuma delas (apenas links de produto divulgados).
Quais São os Erros Mais Comuns na Preparação para Auditoria?
A maioria dos achados de auditoria em LLMs auto-hospedados vem de tratar o servidor de inferência como algo fora do ambiente normal de controle de TI.
- Erro: Assumir que uma ferramenta open source "auditável" (código visível) já foi auditada. Correção: documente sua própria avaliação de risco do publicador e do stack de serving.
- Erro: Deixar a API de inferência acessível sem gateway "porque é só interna". Correção: acessibilidade de rede não é o mesmo que controle de acesso — adicione autenticação mesmo assim.
- Erro: Registrar o texto completo do prompt no mesmo log de acesso usado para monitoramento de uptime. Correção: separe os dois repositórios.
- Erro: Tratar uma troca de versão de modelo como um deploy de rotina sem trilha de aprovação. Correção: aplique a mesma aprovação de gestão de mudanças usada para deployments de código.
- Erro: Não ter um plano de resposta a incidentes específico para os modos de falha do serving de modelo. Correção: adicione esses gatilhos ao seu plano de IR existente e teste-os pelo menos uma vez.
Qual É a Checklist de Preparação para Auditoria de um LLM Auto-Hospedado?
Percorra esta checklist antes de o trabalho de campo do seu auditor começar — cada item corresponde a uma categoria de controle abordada acima.
- 1Adicionar o sistema de LLM auto-hospedado à sua declaração de escopo ISMS/SOC 2
Why it matters: Um sistema não documentado dentro do escopo é um achado mesmo que todo controle técnico esteja implementado. - 2Mapear os Trust Services Criteria ou controles Annex A relevantes ao seu stack real
Why it matters: Auditores testam contra o mapeamento que você fornece. - 3Colocar um gateway autenticado na frente de cada endpoint de inferência
Why it matters: Elimina o achado mais comum: uma API de modelo sem autenticação. - 4Ativar o log estruturado de requisições com identidade do chamador e timestamps
Why it matters: É a evidência principal que um auditor solicita para o critério de segurança. - 5Criptografar o disco do host e o repositório de logs de prompts; exigir TLS no gateway
Why it matters: Satisfaz o critério de confidencialidade e os controles criptográficos A.8.24. - 6Escrever e seguir um procedimento de gestão de mudanças para atualizações de modelo
Why it matters: Prova integridade de processamento e dá um caminho de rollback documentado. - 7Documentar uma avaliação de risco de fornecedor para cada modelo open-weight em produção
Why it matters: Fecha o controle mais comumente esquecido. - 8Publicar uma política de retenção e exclusão para logs de prompts/respostas
Why it matters: Diretamente exigido para o critério de privacidade. - 9Segmentar o servidor de inferência em sua própria zona de rede
Why it matters: Limita o raio de impacto e dá ao auditor um diagrama de rede claro. - 10Escrever um runbook de resposta a incidentes com gatilhos específicos do modelo e testá-lo uma vez
Why it matters: Auditores verificam se o plano existe e foi exercitado.
Perguntas Frequentes
Este artigo é aconselhamento jurídico ou de compliance?
Não. Este guia explica, em nível técnico, as categorias de controles que um auditor SOC 2 ou ISO 27001 costuma verificar. Ele não substitui um auditor qualificado ou sua área de compliance — consulte um antes de agendar uma auditoria ou fazer qualquer declaração de compliance.
Usar Ollama, vLLM ou Hugging Face TGI torna nossa infraestrutura de IA compatível com SOC 2?
Nenhuma ferramenta sozinha torna uma organização compliant. Compliance é um resultado de auditoria sobre o conjunto completo de controles da sua organização. Ollama, vLLM e TGI podem sustentar os requisitos técnicos (uma vez que você adicione autenticação, log e criptografia), mas nenhum é "compatível com SOC 2" ou "certificado ISO 27001" como produto de software.
Qual é a diferença entre SOC 2 Type I e Type II para infraestrutura de IA?
Type I avalia se os controles foram desenhados adequadamente em um determinado momento. Type II avalia se esses controles funcionaram efetivamente ao longo de um período de revisão, geralmente 6–12 meses. Para um endpoint de inferência, Type II significa que seus logs de acesso e evidências de gestão de mudanças precisam existir continuamente ao longo dessa janela inteira.
Modelos open-weight precisam de avaliação de risco de fornecedor mesmo sem um fornecedor de software?
Sim. O publicador do modelo (Meta, Mistral AI, Alibaba/Qwen ou outros) é uma parte da cadeia de suprimentos assim como um fornecedor SaaS. Uma avaliação documentada deve cobrir identidade do publicador, verificação de checksum dos pesos baixados, termos de licença e CVEs conhecidas no stack de serving que carrega o modelo.
Auto-hospedar um LLM reduz nosso escopo de auditoria em comparação com uma API de LLM em nuvem?
Isso muda o escopo em vez de simplesmente reduzi-lo. Auto-hospedagem elimina a relação de processador de dados terceirizado criada por uma API em nuvem, mas também significa que sua organização agora é dona de todo controle antes gerenciado pelo provedor de nuvem.
Que log um auditor espera ver no endpoint de inferência?
No mínimo: identidade do chamador (chave de API ou usuário autenticado), timestamp, modelo e versão chamados, endpoint e status da resposta, exportados para um repositório com acesso de escrita restrito. O conteúdo completo de prompts/respostas geralmente fica em um repositório separado e com controle de acesso mais rígido.
Por quanto tempo devemos reter logs de prompts como evidência de auditoria?
Não existe um número universal — depende da avaliação de risco da sua organização e das expectativas do seu auditor, equilibradas com os princípios de minimização de dados sob qualquer lei de privacidade aplicável. Defina uma janela de retenção específica por escrito, nunca "indefinidamente".
Plataformas como Vanta, Drata ou Secureframe conseguem monitorar um servidor de LLM auto-hospedado?
Elas automatizam bem a coleta de evidências para infraestrutura em nuvem, provedores de identidade e sistemas de tickets, mas um servidor de inferência auto-hospedado on-premise geralmente fica fora da lista de integrações padrão delas.
Qual é o achado de auditoria mais comum em infraestrutura de IA auto-hospedada?
Uma API de inferência acessível sem autenticação, justificada internamente como "só é acessível dentro da nossa rede". Acessibilidade de rede e controle de acesso são afirmações diferentes — um auditor espera autenticação no endpoint independentemente da posição na rede.
Devemos escolher vLLM/TGI ou uma plataforma de inferência corporativa para facilitar a preparação de auditoria?
vLLM e Hugging Face TGI dão controle total, mas exigem que você construa a camada de autenticação, log e criptografia. Plataformas corporativas costumam trazer RBAC e log de auditoria integrados, reduzindo o trabalho de instrumentação — mas de qualquer forma você precisa da documentação ISMS e da avaliação de risco de fornecedor ao redor.
Onde Encontrar Fontes Adicionais?
- AICPA SOC 2 Trust Services Criteria (aicpa-cima.com) — o framework oficial Trust Services Criteria contra o qual auditorias SOC 2 são avaliadas
- ISO/IEC 27001:2022 (iso.org) — o texto oficial do padrão e a referência de controles Annex A
- OWASP Top 10 for LLM Applications (owasp.org/www-project-top-10-for-large-language-model-applications) — riscos de segurança específicos de deployments de LLM, incluindo risco de cadeia de suprimentos e prompt injection