Saltar para o conteúdo principal
Você está colocando um agente de IA na frente de dados de cliente e seu auditor quer saber quais cláusulas de Trust Services você pode de fato evidenciar. Em um gateway hospedado, a resposta honesta é: as cláusulas que mapeiam para um controle rodando no caminho da requisição — acesso lógico, monitoramento e auditoria de chamada de ferramenta — mais as cláusulas organizacionais que um proxy nunca pode aplicar e deve divulgar como gaps. Esta página é o passo a passo de soc 2 ai: quais cláusulas TSC o pack SOC 2 cobre, o único controle que ele materializa para confidencialidade, e como a evidência resultante é assinada. Para o fluxo de instalação e o formato do relatório em profundidade, siga os links no final — esta página é o mapa específico do SOC 2, não a referência completa de Compliance.

1. O que o pack soc 2 ai cobre

O pack SOC 2 mapeia os AICPA Trust Services Criteria para controles que rodam em cada requisição que cruza o gateway. Três cláusulas mapeiam para enforcement ao vivo; duas são organizacionais e são divulgadas como gaps em vez de afirmadas.
Cláusula TSCPlanoControle
CC6.1 Controles de acesso lógicoguardrailbloquear PII confidencial em prompts
CC7.2 Monitoramento de sistemaguardrailregistrar cada decisão de guardrail como evidência
CC7.2 Detecção de anomaliasfirewallauditar cada dispatch de ferramenta
CC8.1 Gestão de mudanças e CC3.1 Avaliação de risco são cláusulas de pessoas-e-processo. Um proxy não pode aplicá-las, então o pack as exibe como gaps divulgados (ou linhas owner-attested) tanto no console quanto no relatório — nunca como cobertura automatizada. Gaps honestos são o que torna o resto da evidência confiável. Veja a matriz de controles.
Os dois planos de enforcement são a mesma maquinaria de Guardrails e Firewall que você configura à mão. O pack é o mapeamento autorado que diz qual controle existente satisfaz qual cláusula — ele não traz nenhum novo motor de runtime. Veja Conteúdo do pack para a anatomia completa.

2. Instale o pack — um exemplo concreto

Instalar materializa o mapeamento em uma política de guardrail e uma política de firewall no seu workspace, cada uma marcada com a proveniência do pack. Você faz isso a partir do console, não de uma chave de relay: Compliance → Catalog → SOC 2 → Install Essa é uma ação de Admin do workspace em um plano pago, e o servidor aplica ambos. Por baixo dos panos a sua sessão de console chama:
POST /api/compliance/packs/soc2/install
Nunca entregue uma chave de relay sk-orca-… a uma rota de configuração. As rotas /api/compliance/* autenticam com a sua sessão de console, não com a chave de relay — apenas as chamadas de modelo /v1/* usam sk-orca-…. Navegar pelo catálogo, pelos packs instalados e pela prontidão é gratuito e aberto a todo membro do workspace; install, go-live, report e residência são as ações gated de Admin.
Após a instalação, a linha CC6.1 deixa de ser prosa. O controle de confidencialidade se torna uma regra de guardrail pii real — ação block, stage input — que você pode abrir, ler e ajustar como qualquer outra regra. O controle de monitoramento CC7.2 registra cada decisão de guardrail como evidência, e o controle de firewall define cada dispatch de ferramenta para o veredito audit.
Este controle age na requisição: a PII confidencial é bloqueada no stage de input antes que o modelo a veja. O tratamento de PII de saída / streaming ao vivo está no roadmap, então, para o lado de saída, a evidência de monitoramento é o que um auditor lê para CC7.2 sobre o período do relatório.

3. Observe primeiro, depois vá ao ar

Uma instalação SOC 2 não começa a bloquear tráfego no primeiro dia. As instalações caem em observe mode: as ações de guardrail são forçadas para flag e a política de firewall roda em shadow (apenas log). Você obtém evidência de “would-have-blocked” contra o tráfego real antes de qualquer coisa aplicar. Quando a evidência parece certa, um Admin do workspace promove o pack para go-live, que restaura as ações declaradas — o controle CC6.1 começa a bloquear, o controle de firewall continua auditando — e, opcionalmente, promove as políticas materializadas para padrão do workspace. Esta é a mesma disciplina descrita em Observe vs enforce.

4. Evidência assinada que seu auditor pode verificar

O ponto do pack é o relatório. A evidência SOC 2 é gerada como um relatório assinado com Ed25519 com um hash de conteúdo SHA256, exportável como CSV, JSON ou PDF, e verificável publicamente — seu auditor verifica a assinatura sem um login OrcaRouter.
Cada linha TSC carrega seu status — covered, observe, gap ou attested — e quantas vezes o controle de fato disparou sobre o período. Um controle CC6.1 que bloqueou 4.000 requisições lê diferente para um auditor do que um com zero correspondências, e o relatório mostra ambos.
Cada controle materializado registra seu control_id (ex.: soc2.confidentiality), a cláusula literal (TSC CC6.1 Logical access controls), o plano e o id do objeto de política ao vivo que o aplica — de modo que o auditor percorre cláusula → controle → política que a aplica → correspondências, sem nenhum passo inferido.
Busque a chave pública de assinatura em GET /api/public/compliance/pubkey, submeta o relatório a POST /api/public/compliance/verify, ou abra um link de compartilhamento com escopo para o auditor em GET /api/public/compliance/share/:token. Nenhuma conta necessária.
Veja o relatório assinado para o layout completo de capa a rodapé e Verifique um relatório para o passo a passo de verificação.

5. Carimbe por região sua evidência SOC 2

Os relatórios SOC 2 são armazenados e servidos sob a sua região de residência declarada — us / eu / uk / ap / cn / global — e um relatório só é servido sob uma região correspondente; as leituras cross-region são retidas. Um Admin do workspace a define via PUT /api/compliance/residency.
A residência aqui é a região do artefato de evidência — onde os relatórios assinados residem e são servidos. Não é a geo-fixação de dados de inferência. Veja Residência de dados e Cross-region para a fronteira.
Os logs de requisição têm padrão de retenção de 30 dias (server-clamped a um máx rígido de 180 dias), e uma exclusão de usuário roda uma janela de carência de 30 dias e depois um scrub de PII — ambos relevantes quando um auditor pergunta sobre sua postura de retenção. Veja Retenção e Direito ao apagamento.

6. Para onde ir a seguir

Conteúdo do pack

A anatomia completa de um pack — ambos os planos, status e proveniência.

Instale um pack

O fluxo de instalação de ponta a ponta, observe mode e go-live.

Relatório assinado

O que o relatório de evidência assinado com Ed25519 contém.

Matriz de controles

Cada cláusula, seu plano e se ela está covered, observed ou um gap.

Frameworks

O catálogo completo — HIPAA, GDPR, o EU AI Act, ISO 27001 e mais.

Guardrails vs Firewall

Os dois planos para os quais um pack SOC 2 escreve, rodados por um resolver.
SOC 2 em um gateway hospedado é a disciplina de ser preciso: mapeie as cláusulas que um proxy pode aplicar para controles ao vivo, divulgue as que ele não pode, e assine a evidência para que a linha entre as duas resista a uma auditoria.