Saltar para o conteúdo principal
Se sua app de IA toca consumidores da Califórnia, três deveres do CCPA / CPRA caem no próprio caminho da requisição: não vaze informações pessoais de consumidor para um modelo que não precisa delas (§1798.100), dê às informações pessoais sensíveis um tratamento reforçado (§1798.140), e mantenha registros que você possa mostrar a um regulador (§1798.130). O pack CCPA / CPRA transforma essas em controles aplicados que você instala em uma chamada — sem autorar política do zero. Esta página é o ponto de partida de ccpa ai: o que instalar o pack de fato materializa, um fluxo de instalação concreto, e onde o direito de opt-out do consumidor se encaixa. Para a referência completa da camada de conteúdo, siga os links em vez de relê-las aqui.

​
1. O que o pack CCPA / CPRA instala

Navegar pelo catálogo é gratuito para qualquer Member do workspace; instalar é uma ação de Admin do workspace em plano pago (o mesmo gate que ir ao ar — veja Plan gating). Uma instalação materializa linhas reais e editáveis de Guardrail mapeadas para seções do California Civil Code:
Um guardrail de PII estrito que bloqueia a requisição no stage de input quando informações pessoais de consumidor (email, telefone, SSN, cartão de crédito, IP) estão presentes — de modo que nunca cheguem ao provedor. Este é um controle de rejeição total, não um redator.
Um guardrail de PII que mascara identificadores sensíveis — SSN, cartão de crédito e IBAN — em ambos os stages. As entidades mascaradas renderizam como tags tipadas tais como [SSN] e [CREDIT_CARD], de modo que a categoria SPI recebe tratamento reforçado e redigido.
Um guardrail de logging que sinaliza ocorrências de PII e registra cada decisão de guardrail como evidência de recordkeeping — sem bloquear ou modificar o tráfego — alimentando o relatório assinado que seu auditor lê.
O pack é um ponto de partida que você possui, não uma caixa-preta. Cada regra que ele escreve é uma linha comum de guardrail que você pode editar, reordenar, re-direcionar (input / output / both) ou desabilitar no console depois. O conjunto de entidades incluído e os overrides de ação por entidade vivem na referência de Guardrails.

​
2. Instale o pack CCPA / CPRA (um fluxo concreto)

Instale a partir do console em Compliance → Packs, logado como Admin do workspace em um plano pago. O console conduz a rota de gerenciamento por você usando a sua sessão — esta é uma rota UserAuth, nunca uma chave de relay (sk-orca-…): 
POST /api/compliance/packs/ccpa/install
Authorization: Bearer <your console session>
Antes de se comprometer, abra o catálogo como Member para confirmar exatamente para qual framework você está mapeando: 
GET /api/compliance/catalog
Authorization: Bearer <your console session>

{
  "key": "ccpa",
  "name": "CCPA/CPRA",
  "framework": "California Consumer Privacy Act (as amended by CPRA)",
  "jurisdiction": "US-CA"
}
Instale em observe primeiro se você preferir observar antes de aplicar. O controle §1798.100 é um block rígido — rodar a regra materializada em modo audit por uma semana mostra a você exatamente qual tráfego ela teria rejeitado antes que qualquer requisição de consumidor seja de fato interrompida. Veja Observe vs enforce.

​
3. O controle de PII de consumidor na requisição

O controle load-bearing do CCPA é manter as informações pessoais de consumidor fora do modelo, e no gateway isso é um guardrail de PII avaliado antes que a requisição chegue ao provedor. O pack vem com duas posturas complementares:
ControleAçãoO que ele cobre
Informação pessoalblock (input)email, telefone, SSN, cartão de crédito, IP
PI sensívelmask (both)SSN, cartão de crédito, IBAN
O bloqueio rejeita a requisição imediatamente; o mascaramento a deixa passar com identificadores sensíveis trocados por tags tipadas. Você decide qual postura se encaixa em qual tráfego — ambas são linhas comuns de guardrail após a instalação, então você pode virar uma entidade de block para mask, estreitar o conjunto de entidades ou adicionar seus próprios padrões de entidade customizada (regex, checagem de Luhn opcional) para identificadores específicos do seu produto.
Os controles de stage de input estão totalmente ao vivo. O mascaramento ao vivo de saída streaming está no roadmap — hoje, o mascaramento de stage de output é apenas não-streaming, enquanto um block de output é aplicado tanto em respostas streaming quanto não-streaming. Planeje sua minimização de PII de consumidor em torno do stage de input, onde ela é totalmente aplicada.

​
4. O direito de opt-out (o lado humano)

O direito de consumidor característico do CCPA — opt-out da venda ou compartilhamento de informações pessoais (§1798.120) — e o dever de notice-at-collection (§1798.130) são controles organizacionais no checklist de prontidão, não regras que o gateway pode autorar para você. Eles dependem dos seus processos de negócio, não do caminho da requisição.
O OrcaRouter rastreia esses como itens de prontidão para que seu auditor veja a imagem completa do CCPA, mas o fluxo de Do-Not-Sell e as suas divulgações de política de privacidade são seus para operar. O gateway evidencia o que ele aplica (os controles de PII e recordkeeping acima); você atesta o que ele não pode ver. A divisão é mapeada na página Responsabilidade compartilhada.

​
5. Residência, retenção e exclusão de consumidor

Três configurações em nível de workspace completam uma postura CCPA:

Residência para sua evidência

Carimbe os relatórios assinados com uma região (us / eu / uk / ap / cn / global) para que um auditor da Califórnia leia evidência residente nos EUA. Defina-a antes de gerar relatórios — ela governa o artefato, não onde a inferência roda.

Retenção de log

A retenção de log de requisição tem padrão de 30 dias, server-clamped a um máximo de 180 dias. Reduzi-la encolhe a janela em que dados de consumidor ficam em logs.
Uma requisição de exclusão de consumidor (§1798.105) mapeia para a autoexclusão de conta do OrcaRouter: um fluxo de carência-depois-scrub — soft-delete e bloqueio de login na requisição, uma janela cancelável de 30 dias, depois um scrub de PII irreversível que cascateia uma purga por logs de requisição, correspondências de guardrail e eventos de firewall. O fluxo completo está na página Direito ao apagamento. Defina a residência como Admin do workspace — uma rota UserAuth, conduzida a partir do console: 
PUT /api/compliance/residency
Authorization: Bearer <your console session>
Content-Type: application/json

{ "region": "us" }

​
6. Prove com um relatório assinado

Uma vez que o pack esteja ao ar, gere um relatório de compliance: ele é hasheado com SHA-256 e assinado com Ed25519, de modo que um auditor possa verificar que ele foi produzido pelo OrcaRouter e não foi alterado — publicamente, sem um login. 
POST /api/compliance/reports
Authorization: Bearer <your console session>
Content-Type: application/json

{ "framework": "ccpa" }
Qualquer pessoa pode verificar a assinatura contra a chave pública, e você pode entregar a um auditor um link de compartilhamento com escopo e tempo limitado. A mecânica vive em Relatório assinado e Verifique um relatório.

​
7. Onde isto se encaixa

O CCPA / CPRA é um framework no loop de compliance mais amplo — instale um pack, observe-o, aplique, declare a residência, depois entregue evidência assinada.

Visão geral de compliance

O loop completo — instale, observe, aplique e entregue evidência assinada.

O que um pack instala

Como um pack materializa linhas de guardrail e firewall que você possui.

GDPR

O framework de privacidade da UE — minimização, transferências e apagamento.

Guardrails

A referência da camada de conteúdo — entidades de PII, mascaramento e overrides.
Para a fronteira entre o que o gateway aplica sob o CCPA e o que continua sendo seu — o fluxo de opt-out, suas divulgações, disparar exclusões — o mapa de Responsabilidade compartilhada coloca o pack CCPA / CPRA em contexto.