Skip to main content
If your AI app touches California consumers, three CCPA / CPRA duties land on the request path itself: don’t leak consumer personal information to a model that doesn’t need it (§1798.100), give sensitive personal information heightened handling (§1798.140), and keep records you can show a regulator (§1798.130). The CCPA / CPRA pack turns those into enforced controls you install in one call — no policy authoring from scratch. This page is the ccpa ai landing: what installing the pack actually materialises, one concrete install flow, and where the consumer opt-out right fits. For the full content-layer reference, follow the links rather than re-reading them here.

​
1. What the CCPA / CPRA pack installs

Browsing the catalog is free for any workspace Member; installing is a paid-plan, workspace-Admin action (the same gate as going live — see Plan gating). One install materialises real, editable Guardrail rows mapped to California Civil Code sections:
A strict PII guardrail that blocks the request on the input stage when consumer personal information (email, phone, SSN, credit card, IP) is present — so it never reaches the provider. This is a hard-reject control, not a redactor.
A PII guardrail that masks sensitive identifiers — SSN, credit card, and IBAN — on both stages. Masked entities render as typed tags such as [SSN] and [CREDIT_CARD], so the SPI category gets heightened, redacted handling.
A logging guardrail that flags PII occurrences and records every guardrail decision as recordkeeping evidence — without blocking or modifying traffic — feeding the signed report your auditor reads.
The pack is a starting point you own, not a black box. Every rule it writes is an ordinary guardrail row you can edit, reorder, re-target (input / output / both), or disable in the console afterward. The bundled entity set and per-entity action overrides live in the Guardrails reference.

​
2. Install the CCPA / CPRA pack (one concrete flow)

Install from the console under Compliance → Packs, signed in as a workspace Admin on a paid plan. The console drives the management route for you using your session — this is a UserAuth route, never a relay (sk-orca-…) key: 
POST /api/compliance/packs/ccpa/install
Authorization: Bearer <your console session>
Before you commit, open the catalog as a Member to confirm exactly which framework you’re mapping to: 
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"
}
Install into observe first if you’d rather watch before you enforce. The §1798.100 control is a hard block — running the materialised rule in audit mode for a week shows you exactly which traffic it would have rejected before any consumer request is actually stopped. See Observe vs enforce.

​
3. The consumer-PII control on the request

The load-bearing CCPA control is keeping consumer personal information off the model, and on the gateway that is a PII guardrail evaluated before the request reaches the provider. The pack ships two complementary postures:
ControlActionWhat it covers
Personal informationblock (input)email, phone, SSN, credit card, IP
Sensitive PImask (both)SSN, credit card, IBAN
Blocking rejects the request outright; masking lets it through with sensitive identifiers swapped for typed tags. You decide which posture fits which traffic — both are ordinary guardrail rows after install, so you can flip an entity from block to mask, narrow the entity set, or add your own custom entity patterns (regex, optional Luhn check) for identifiers specific to your product.
Input-stage controls are fully live. Live masking of streaming output is on the roadmap — today, output-stage masking is non-streaming only, while an output block is enforced on both streaming and non-streaming responses. Plan your consumer-PII minimisation around the input stage, where it is fully enforced.

​
4. The right to opt out (the human side)

CCPA’s signature consumer right — opt out of the sale or sharing of personal information (§1798.120) — and the notice-at-collection duty (§1798.130) are organizational controls in the readiness checklist, not rules the gateway can author for you. They depend on your business processes, not the request path.
OrcaRouter tracks these as readiness items so your auditor sees the full CCPA picture, but the Do-Not-Sell workflow and your privacy-policy disclosures are yours to operate. The gateway evidences what it enforces (the PII and recordkeeping controls above); you attest to what it can’t see. The split is mapped on the Shared responsibility page.

​
5. Residency, retention, and consumer deletion

Three workspace-level settings round out a CCPA posture:

Residency for your evidence

Stamp signed reports with a region (us / eu / uk / ap / cn / global) so a California auditor reads US-resident evidence. Set it before you generate reports — it governs the artifact, not where inference runs.

Log retention

Request-log retention defaults to 30 days, server-clamped to a 180-day maximum. Lowering it shrinks the window consumer data sits in logs at all.
A consumer deletion request (§1798.105) maps to OrcaRouter’s account self-deletion: a grace-then-scrub flow — soft-delete and login-block on request, a cancellable 30-day window, then an irreversible PII scrub that cascades a purge across request logs, guardrail matches, and firewall events. The full flow is on the Right to erasure page. Set residency as a workspace Admin — a UserAuth route, driven from the console: 
PUT /api/compliance/residency
Authorization: Bearer <your console session>
Content-Type: application/json

{ "region": "us" }

​
6. Prove it with a signed report

Once the pack is live, generate a compliance report: it is SHA-256 hashed and Ed25519-signed, so an auditor can verify it was produced by OrcaRouter and not altered — publicly, without a login. 
POST /api/compliance/reports
Authorization: Bearer <your console session>
Content-Type: application/json

{ "framework": "ccpa" }
Anyone can verify the signature against the public key, and you can hand an auditor a scoped, time-boxed share link. The mechanics live in Signed report and Verify a report.

​
7. Where this fits

CCPA / CPRA is one framework in the broader compliance loop — install a pack, observe it, enforce, declare residency, then ship signed evidence.

Compliance overview

The full loop — install, observe, enforce, and ship signed evidence.

What a pack installs

How a pack materialises guardrail and firewall rows you own.

GDPR

The EU privacy framework — minimisation, transfers, and erasure.

Guardrails

The content-layer reference — PII entities, masking, and overrides.
For the boundary between what the gateway enforces under CCPA and what stays yours — the opt-out workflow, your disclosures, triggering deletions — the Shared responsibility map puts the CCPA / CPRA pack in context.