Saltar para o conteúdo principal
A primeira pergunta de um auditor nunca é “você tem uma política?” — é “mostre-me, cláusula por cláusula, qual controle a satisfaz, e prove que ele rodou.” Uma matriz de controles responde exatamente isso: uma linha por cláusula em escopo, o plano para o qual ela mapeia, o objeto de política ao vivo que a aplica, e se aquele controle está covered, ainda em observe, um gap divulgado, ou owner-attested. O OrcaRouter constrói essa matriz para você a partir dos packs que você instala — o mesmo mapeamento que alimenta o relatório assinado, de modo que a visão de prontidão e a evidência nunca podem divergir. Esta página mostra como ler e montar a matriz de controles de compliance de IA para o seu workspace, com uma cláusula concreta percorrida de ponta a ponta. Para o que um pack de fato contém, siga os links no final.

​
1. O que uma matriz de controles de compliance de IA é aqui

A matriz é a união de duas listas por framework:
  • as cláusulas que um pack instalado cobre — cada uma unida à política exata de guardrail ou firewall que a instalação materializou;
  • as cláusulas que nunca podem ser automatizadas pelo gateway — treinamento de força de trabalho, Business Associate Agreements, acesso físico — autoradas como gaps honestos para que a matriz as divulgue em vez de implicar um falso 100%.
A matriz é uma visão, não um segundo motor. Cada linha covered aponta para uma regra de guardrail ou política de firewall real e editável que você já possui — abra-a, leia-a, ajuste-a. A matriz apenas registra qual delas responde qual cláusula.
Cada cláusula mapeia para exatamente um de dois planos:

Plano de guardrail

Cláusulas de conteúdo — PII confidencial, segredos, divulgações exigidas — mapeiam para uma regra de guardrail com uma ação block, mask ou flag.

Plano de firewall

Cláusulas de ação — agência excessiva, chamadas de ferramenta perigosas, egress — mapeiam para uma regra de firewall com um veredito allow / audit / deny na superfície inbound, response, mcp ou egress.

​
2. Os estados de prontidão que uma linha pode carregar

Cada linha da matriz carrega um estado. Estas são as palavras que um auditor lê, então elas significam exatamente o que dizem:
EstadoO que significa
coveredUm controle de pack está instalado e aplicando a cláusula.
observeInstalado mas apenas-log — coletando evidência de would-have-blocked, ainda não aplicando.
gapNenhum controle instalado cobre a cláusula (ou ela é organizacional e não pode ser).
attestedUma cláusula organizacional que um Admin owner-atestou em vez de automatizar.
Um gap não é uma falha — é honestidade. Uma cláusula organizacional como o treinamento de força de trabalho HIPAA 45 CFR §164.308(a)(5) nunca pode ser aplicada por um proxy, então a matriz a exibe como um gap divulgado (ou, uma vez que um Admin atesta a propriedade, como attested) em vez de fingir que o gateway a cobre.
Há também uma sobreposição drift: se o mapeamento de um pack instalado fica atrás da versão atual do catálogo, suas linhas renderizam como drift para que você saiba que deve reinstalar antes de confiar na evidência.

​
3. Leia a matriz (uma chamada concreta)

O endpoint de prontidão retorna a matriz inteira — porcentagens de cobertura por framework, os principais riscos ranqueados sobre a janela, e uma entrada coverage_rows por cláusula. Navegar pela prontidão é aberto a todo Member do workspace e é gratuito, então seus revisores de segurança e auditoria podem acompanhar a matriz sem acesso de escrita. O console conduz essa rota de gerenciamento sob a sua sessão — você nunca entrega uma chave de relay sk-orca-… a uma rota de compliance: 
GET /api/compliance/readiness?window=30d
Authorization: Bearer <your console session>
Uma única linha covered se parece com isto — cláusula, plano, estado e o id da política ao vivo à qual ela se une: 
{
  "framework": "soc2",
  "control_id": "soc2.confidentiality",
  "clause": "TSC CC6.1 Logical access controls",
  "reference": "https://www.aicpa-cima.com/resources/...",
  "plane": "guardrail",
  "state": "covered",
  "guardrail_id": 41,
  "observe_count": 0,
  "organizational": false
}
O guardrail_id (ou firewall_policy_id no plano de firewall) é o campo load-bearing: ele liga a cláusula direto a um objeto que você pode abrir no console e editar como qualquer outro. Essa é a linhagem que um auditor percorre — cláusula → id de controle → política que a aplica → as correspondências que ela produziu.
Ler a matriz é uma capacidade gratuita de Member. Construí-la — instalar um pack para que seus controles populem as linhas — é uma ação de Admin do workspace em um plano pago, e o servidor aplica ambos. Um viewer ou um workspace gratuito não pode materializar cobertura chamando a API diretamente. Veja Plan gating.

​
4. Monte a matriz para seus frameworks

Você constrói a matriz instalando packs. Cada instalação mescla seus controles em um guardrail e uma política de firewall marcados com a proveniência do pack, e suas cláusulas começam a popular coverage_rows:
  1. Escolha seus frameworks. A instalação roda no console em Compliance → Catalog, como Admin do workspace. O catálogo cobre regimes de segurança e governança de IA (soc2, iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, owasp_llm), regimes setoriais (hipaa, pci_dss, glba, nist_800_53) e um amplo conjunto de leis regionais de privacidade (gdpr, uk_gdpr, ccpa e mais). Navegue pelo conjunto ao vivo em Frameworks.
  2. Instale em observe primeiro. Uma instalação nova cai em observe mode — ações de guardrail forçadas para flag, a política de firewall em shadow — então cada nova linha começa como observe e produz evidência de would-have-blocked antes de aplicar.
  3. Observe as linhas se encherem. Re-busque a prontidão sobre uma janela real. As linhas covered mostram seu observe_count; os gaps permanecem divulgados; as cláusulas organizacionais aguardam atestação.
  4. Vá ao ar. Quando as linhas leem limpas, um Admin do workspace vai ao ar e as linhas observe viram enforcement covered.
O OWASP Top 10 for LLM Applications está no catálogo como o pack owasp_llm — suas cláusulas (por exemplo LLM05:2025 Supply Chain) caem na matriz da mesma forma que as de todo outro framework, mapeadas para controles ao vivo ou divulgadas como gaps. Veja OWASP LLM Top 10.

​
5. Da matriz à evidência assinada

A matriz que você lê no console é o mesmo dado de cobertura que o relatório serializa — então quando você gera evidência, o auditor vê os estados idênticos por cláusula, mais as contagens de enforcement que cada controle produziu sobre o período. Uma cláusula que bloqueou 4.000 requisições e uma cláusula com zero correspondências leem muito diferente, e o relatório mostra ambas. Os relatórios são hasheados com SHA-256, assinados com Ed25519 e verificáveis publicamente.
Os objetos exatos de guardrail e firewall que um pack materializa, e como cada cláusula se une à política que a aplica — veja Conteúdo do pack.
Por que cada linha começa em observe, o que ela registra e como o go-live a vira — veja Observe vs enforce.
Como a matriz renderiza para um auditor, com estados por cláusula e contagens de enforcement — veja Relatório assinado.

​
6. Para onde ir a seguir

Instale um pack

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

Todos os frameworks

O catálogo ao vivo de frameworks cujas cláusulas você pode construir na matriz.

Guardrails vs Firewall

Os dois planos para os quais uma linha da matriz pode mapear, e como o resolver os roda juntos.

Responsabilidade compartilhada

Por que algumas cláusulas são aplicáveis pelo gateway e outras continuam sendo suas — a fronteira que cada linha de gap reflete.
Uma matriz de controles é a ponte entre o checklist de um regulador e o seu gateway em funcionamento: uma linha por cláusula, unida ao controle ao vivo que a aplica, honesta sobre o que um proxy não pode cobrir, e idêntica à evidência assinada que você entrega a um auditor.