Vai al contenuto principale
Se la tua app AI tocca i consumatori californiani, tre doveri CCPA / CPRA atterrano sul percorso della richiesta stesso: non far trapelare le informazioni personali dei consumatori a un modello che non ne ha bisogno (§1798.100), dai alle informazioni personali sensibili una gestione rafforzata (§1798.140), e mantieni record che puoi mostrare a un regolatore (§1798.130). Il pack CCPA / CPRA trasforma quelli in controlli applicati che installi in una sola chiamata — nessuna autorazione di policy da zero. Questa pagina è l’atterraggio ccpa ai: cosa materializza davvero installare il pack, un flusso di installazione concreto, e dove si colloca il diritto di opt-out del consumatore. Per il riferimento completo del content-layer, segui i link anziché rileggerli qui.

​
1. Cosa installa il pack CCPA / CPRA

Sfogliare il catalogo è gratis per qualsiasi Member del workspace; installare è un’azione da Admin del workspace su piano a pagamento (lo stesso gate dell’andare live — vedi Plan gating). Una sola installazione materializza righe reali e modificabili di Guardrail mappate su sezioni del California Civil Code:
Un guardrail PII stretto che blocca la richiesta in fase di input quando sono presenti informazioni personali del consumatore (email, telefono, SSN, carta di credito, IP) — così non raggiunge mai il provider. Questo è un controllo di rifiuto netto, non un redattore.
Un guardrail PII che maschera gli identificatori sensibili — SSN, carta di credito e IBAN — su entrambe le fasi. Le entità mascherate rendono come tag tipizzati quali [SSN] e [CREDIT_CARD], così la categoria SPI ottiene una gestione rafforzata e redatta.
Un guardrail di logging che segnala le occorrenze di PII e registra ogni decisione del guardrail come evidenza di recordkeeping — senza bloccare o modificare il traffico — alimentando il report firmato che il tuo auditor legge.
Il pack è un punto di partenza che possiedi, non una scatola nera. Ogni regola che scrive è una riga ordinaria di guardrail che puoi modificare, riordinare, ri-targettare (input / output / both), o disabilitare nella console dopo. L’insieme di entità incluse e gli override di azione per-entità vivono nel riferimento Guardrails.

​
2. Installa il pack CCPA / CPRA (un flusso concreto)

Installa dalla console sotto Compliance → Packs, loggato come Admin del workspace su un piano a pagamento. La console guida la rotta di management per te usando la tua sessione — questa è una rotta UserAuth, mai una chiave di relay (sk-orca-…): 
POST /api/compliance/packs/ccpa/install
Authorization: Bearer <your console session>
Prima di impegnarti, apri il catalogo come Member per confermare esattamente su quale framework stai mappando: 
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"
}
Installa prima in observe se preferisci osservare prima di applicare. Il controllo §1798.100 è un block netto — eseguire la regola materializzata in audit mode per una settimana ti mostra esattamente quale traffico avrebbe rifiutato prima che una qualsiasi richiesta di consumatore venga effettivamente fermata. Vedi Observe vs enforce.

​
3. Il controllo sulle PII dei consumatori sulla richiesta

Il controllo CCPA portante è tenere le informazioni personali dei consumatori fuori dal modello, e sul gateway è un guardrail PII valutato prima che la richiesta raggiunga il provider. Il pack esce con due posture complementari:
ControlloAzioneCosa copre
Informazioni personaliblock (input)email, telefono, SSN, carta di credito, IP
PI sensibilimask (entrambe)SSN, carta di credito, IBAN
Il blocco rifiuta la richiesta del tutto; il masking la lascia passare con gli identificatori sensibili scambiati con tag tipizzati. Decidi quale postura si adatta a quale traffico — entrambe sono righe ordinarie di guardrail dopo l’installazione, così puoi passare un’entità da block a mask, restringere l’insieme di entità, o aggiungere i tuoi pattern di entità personalizzata (regex, controllo Luhn opzionale) per identificatori specifici del tuo prodotto.
I controlli in fase di input sono pienamente live. Il masking live dell’output streaming è in roadmap — oggi, il masking in fase di output è solo non-streaming, mentre un block in output è applicato sulle risposte sia streaming che non-streaming. Pianifica la tua minimizzazione delle PII dei consumatori attorno alla fase di input, dove è pienamente applicata.

​
4. Il diritto all’opt-out (il lato umano)

Il diritto del consumatore distintivo del CCPA — opt-out dalla vendita o condivisione delle informazioni personali (§1798.120) — e il dovere di notice al momento della raccolta (§1798.130) sono controlli organizzativi nella checklist di readiness, non regole che il gateway può autorare per te. Dipendono dai tuoi processi di business, non dal percorso della richiesta.
OrcaRouter li traccia come item di readiness così il tuo auditor vede il quadro CCPA completo, ma il workflow Do-Not-Sell e le tue disclosure della privacy policy sono tuoi da operare. Il gateway evidenzia ciò che applica (i controlli PII e di recordkeeping sopra); tu attesti ciò che non può vedere. Lo split è mappato sulla pagina Responsabilità condivisa.

​
5. Residency, retention e cancellazione del consumatore

Tre impostazioni a livello di workspace completano una postura CCPA:

Residency per le tue evidenze

Marca i report firmati con una regione (us / eu / uk / ap / cn / global) così un auditor californiano legge evidenze US-resident. Impostala prima di generare i report — governa l’artefatto, non dove gira l’inferenza.

Retention dei log

La retention dei log delle richieste ha default di 30 giorni, server-clamped a un massimo di 180 giorni. Abbassarla riduce la finestra in cui i dati del consumatore stanno nei log affatto.
Una richiesta di cancellazione del consumatore (§1798.105) mappa sull’auto-cancellazione dell’account di OrcaRouter: un flusso grazia-poi-scrub — soft-delete e blocco del login alla richiesta, una finestra cancellabile di 30 giorni, poi uno scrub PII irreversibile che fa cascade su un purge attraverso log delle richieste, match dei guardrail ed eventi del firewall. Il flusso completo è sulla pagina Diritto alla cancellazione. Imposta la residency come Admin del workspace — una rotta UserAuth, guidata dalla console: 
PUT /api/compliance/residency
Authorization: Bearer <your console session>
Content-Type: application/json

{ "region": "us" }

​
6. Dimostralo con un report firmato

Una volta che il pack è live, genera un report di compliance: è hashato SHA-256 e firmato Ed25519, così un auditor può verificare che è stato prodotto da OrcaRouter e non alterato — pubblicamente, senza un login. 
POST /api/compliance/reports
Authorization: Bearer <your console session>
Content-Type: application/json

{ "framework": "ccpa" }
Chiunque può verificare la firma contro la chiave pubblica, e puoi consegnare a un auditor un link di condivisione con scope e limitato nel tempo. La meccanica vive in Report firmato e Verifica un report.

​
7. Dove si colloca

CCPA / CPRA è un framework nel loop di compliance più ampio — installa un pack, osservalo, applica, dichiara la residency, poi spedisci evidenze firmate.

Panoramica sulla compliance

L’intero loop — installa, osserva, applica, e spedisci evidenze firmate.

Cosa installa un pack

Come un pack materializza righe di guardrail e firewall che possiedi.

GDPR

Il framework di privacy UE — minimizzazione, trasferimenti e cancellazione.

Guardrails

Il riferimento del content-layer — entità PII, masking e override.
Per il confine tra ciò che il gateway applica sotto il CCPA e ciò che resta tuo — il workflow di opt-out, le tue disclosure, attivare le cancellazioni — la mappa di Responsabilità condivisa mette il pack CCPA / CPRA in contesto.