Saltar para o conteúdo principal
Um checklist de framework é uma lista de cláusulas. Um compliance pack é o mesmo checklist com cada cláusula conectada a um controle que realmente roda no gateway. Quando você instala um pack, o OrcaRouter lê seu mapeamento de cláusula-para-controle e materializa objetos de política reais e editáveis no seu workspace — de modo que “SOC 2 CC6.1” deixa de ser uma linha em uma planilha e se torna um guardrail que bloqueia PII confidencial antes que chegue ao modelo. Esta página explica o que um compliance pack de IA contém, como seus dois planos de enforcement mapeiam de volta para as cláusulas, e a linhagem de proveniência que permite a um auditor rastrear qualquer cláusula até a política exata que a aplica. Para o fluxo de instalação e o relatório assinado, siga os links no final.

​
1. Um pack é um mapeamento de cláusula-para-controle, não novo enforcement

Um pack não traz nenhum novo motor de runtime. Cada controle que ele carrega reutiliza a mesma maquinaria de Guardrails e Firewall que você já configura à mão — um pack é o mapeamento autorado que diz qual controle existente satisfaz qual cláusula. Cada pack abrange dois planos de enforcement:

Plano de guardrail

Os controles de texto / dados — cláusulas sobre dados confidenciais, divulgação de PII, defesa contra injeção ou divulgações exigidas mapeiam para regras de guardrail (pii, regex, llm_judge e afins) com uma ação block, mask ou flag.

Plano de firewall

Os controles de chamada de ferramenta — cláusulas sobre agência excessiva, ações perigosas ou egress mapeiam para regras de firewall com um veredito allow / audit / deny na superfície inbound, response, mcp ou egress.
Instalar o pack mescla seus controles selecionados em um guardrail e uma política de firewall, marcados com a proveniência do pack, de modo que eles co-aplicam através do resolver normal e cada caminho existente de attachment e histórico continua funcionando.
Um pack cobre apenas controles aplicáveis pelo gateway. Cláusulas organizacionais — treinamento de força de trabalho, Business Associate Agreements, acesso físico — nunca podem ser aplicadas por um proxy, então o relatório as divulga como gaps (ou como owner-attested) em vez de afirmar cobertura falsa. Veja a matriz de controles.

​
2. Uma cláusula, de ponta a ponta — um exemplo concreto

Tome o pack SOC 2. Ele mapeia três cláusulas de Trust Services para três controles ao vivo:
CláusulaPlanoControle
CC6.1 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
Você o instala a partir do console — Compliance → Catalog → SOC 2 → Install — que é só para Admin do workspace e chama POST /api/compliance/packs/soc2/install por você sob a sua sessão de console. Você nunca entrega uma chave de relay sk-orca-… a uma rota de configuração; o conteúdo e a política vivem inteiramente atrás do seu login de console. Após a instalação, a linha CC6.1 não é mais prosa — é uma regra de guardrail que você pode abrir, ler e ajustar como qualquer outra.

​
3. Linhagem de proveniência — cláusula até política aplicadora

A razão pela qual um pack é auditável é que o vínculo entre uma cláusula e a política que a aplica é registrado, não implícito. Cada controle que o pack materializa carrega:
Um control_id estável (ex.: soc2.confidentiality) e o texto literal da cláusula (TSC CC6.1 Logical access controls), além de um link de fonte oficial para que um auditor leia a regulação, não apenas a nossa paráfrase.
Se o controle vive no plano guardrail ou firewall, e o id da política exata de guardrail ou firewall que a instalação materializou. Esse id é o que liga uma linha no relatório de volta a um objeto ao vivo e editável no seu workspace.
covered, observe, gap ou attested — e, ao longo do período do relatório, quantas vezes aquele controle de fato disparou. Uma cláusula com zero correspondências e uma cláusula que bloqueou 4.000 requisições leem diferente para um auditor, e o relatório mostra ambas.
Cada pack carrega uma linha MappedBy — quem autorou o mapeamento de cláusula-para-controle, sua versão e o aviso honesto de que ele cobre apenas controles aplicáveis pelo gateway e não é, ele mesmo, uma certificação. Essa linha é carimbada na capa do relatório assinado.
Juntando tudo, esta é a linhagem que um auditor percorre: cláusula → id de controle → política de guardrail ou firewall que a aplica → as correspondências que ela produziu neste período → quem autorou o mapeamento. Nenhum passo é inferido.
A mesma matriz de cobertura alimenta tanto o console quanto o relatório, então as duas nunca podem divergir silenciosamente. Uma cláusula que o framework espera mas que nenhum pack instalado cobre sempre renderiza como um gap divulgado em ambas as superfícies.

​
4. Observe primeiro, depois aplique

Um pack não começa a bloquear tráfego no momento em que você o instala. 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). O pack produz evidência de “would-have-blocked” para que você possa ver exatamente o que ele faria contra o tráfego real antes de fazê-lo. Quando você está satisfeito, um Admin do workspace chama o go-live, que restaura as ações declaradas dos controles (mask / block / deny) e, opcionalmente, promove as políticas materializadas para padrão do workspace. Esta é a mesma disciplina de observar-depois-aplicar descrita em Observe vs enforce.
Navegar pelo catálogo, pelos packs instalados e pela prontidão é aberto a todo membro do workspace e é gratuito. Instalar um pack e ir ao ar são ações de Admin do workspace que exigem um plano pago — o servidor aplica ambos os gates, então um viewer ou um workspace gratuito não pode materializar enforcement chamando a API diretamente. Gerar um relatório também é Admin: o plano gratuito inclui um relatório PDF, enquanto exports CSV/JSON e relatórios adicionais exigem um plano pago. Definir a residência de dados também é Admin do workspace, mas não é, em si, paywalled.

​
5. O que um pack não contém

Para manter a fronteira honesta:
  • Nenhuma certificação. Um pack mapeia seus controles de gateway para as cláusulas de um framework e produz evidência assinada. Não é uma auditoria, uma atestação de toda a sua organização, nem aconselhamento jurídico.
  • Nenhum controle organizacional. Cláusulas de pessoas-e-processo são exibidas como gaps divulgados ou atestações do owner, nunca como cobertura automatizada.
  • Nenhum catálogo mágico. Os frameworks no catálogo são aqueles com um mapeamento autorado — SOC 2, HIPAA, GDPR / UK GDPR, o EU AI Act, ISO 27001 / 42001, NIST AI RMF, PCI DSS, o OWASP LLM Top 10 e as leis regionais de privacidade. Navegue pelo conjunto ao vivo em Frameworks.

​
6. Para onde ir a seguir

Instale um pack

O fluxo completo de instalação — selecionar controles, observe mode e go-live.

O relatório assinado

O que o relatório de evidência assinado com Ed25519 contém e como a linhagem renderiza para um auditor.

Matriz de controles

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

Guardrails vs Firewall

Os dois planos para os quais um pack escreve, e como o resolver os roda juntos.
Um compliance pack é a ponte entre a linguagem de um regulador e o enforcement do gateway: ele mapeia cada cláusula para um controle real, materializa esse controle em uma política que você possui e pode ajustar, e registra a linhagem para que a evidência resista à inspeção.