RatedWithAI

RatedWithAI

Accessibility scanner

Privacy & ComplianceAugust 12, 2026

The Request Didn't Come From Your Customer. It Still Has a 45-Day Clock.

Privacy request volume no longer arrives one consumer at a time. It arrives in batches from authorized agents — commercial deletion services, browser extensions, nonprofit privacy tools — and the verification rules for agent-submitted requests are not the rules most intake processes were built for.

45 days
Response deadline — starts at receipt, not at completed verification
Signed permission
What you may require from an agent, unless they hold a valid power of attorney
No registration
Anyone a consumer authorizes can be an agent — 'unrecognized service' is not a denial ground

Why This Became a Volume Problem

CCPA has always permitted a consumer to designate an authorized agent to submit requests on their behalf. For years that provision was mostly theoretical — requests trickled in from individuals through a web form. What changed is the arrival of services that submit on behalf of thousands of consumers at once, and of the Delete Act's registered-broker deletion mechanism, which normalized the idea that a consumer can hand their entire request workload to a third party.

The result: intake processes designed around a human consumer answering a confirmation email now receive structured submissions from an intermediary who cannot answer that email. Businesses respond by inventing verification steps that the regulations do not authorize, and the denial that follows is the violation.

What You May and May Not Require

The CCPA regulations set out a closed list. Anything outside it is friction you are adding at your own risk, and regulators read added friction as an obstruction of consumer rights.

Proof the consumer authorized the agent (signed permission)

Status: Permitted

You may require the agent to submit written, signed authorization from the consumer. This is the core document — request it in your published process, not ad hoc.

Direct verification of the consumer's own identity

Status: Permitted

You may require the consumer to verify their identity directly with you, at the standard applicable to the request type (reasonable degree for access to categories, high degree for specific pieces or deletion).

Direct confirmation from the consumer that they granted permission

Status: Permitted

You may require the consumer to confirm the agent's authority with you directly. Note this is a confirmation, not a re-submission of the whole request.

Any of the above when the agent holds a valid power of attorney

Status: Not permitted

If the agent provides a power of attorney valid under California Probate Code sections 4000-4465, you may not demand signed permission or direct consumer confirmation. Train intake staff to recognize a POA.

Rejecting requests because they arrived in bulk or via API

Status: Not permitted

Channel is not a denial ground. If your published intake channel cannot accept the format, that is your process gap — the request is still received and the clock is still running.

Requiring an account login the consumer does not have

Status: Not permitted

You may require login for consumers who already maintain an account. You may not force account creation as a condition of exercising a right.

Collecting a government ID by default

Status: Not permitted as a default

Verification must use the least amount of information necessary, and you may not collect new categories of personal information solely to verify. Escalate to stronger evidence only when weaker evidence genuinely fails.

The Clock Runs During Verification

This is the single most common process defect. A business receives an agent request on day one, emails the consumer for confirmation on day three, waits, re-emails on day twenty, and starts the substantive search on day thirty-five — treating the response deadline as though it began when verification finished. It did not. The deadline runs from receipt.

Two operational consequences follow. First, verification and search should run in parallel, not in sequence — begin locating the data while you confirm the agent's authority, so a late confirmation does not compress the hard work into the final week. Second, if you need the additional 45-day extension, the notice of extension must go out inside the first window, with a reason. An extension notice sent on day fifty is not an extension; it is a late response.

Where AI Systems Break the Search

Verification is the procedural half. The substantive half is producing a complete answer, and this is where AI infrastructure quietly puts businesses out of compliance. Your CRM can be queried by email address. Most of the places AI systems put personal information cannot.

Vector / embedding stores

Documents containing customer details are chunked and embedded. The vectors are addressable by similarity, not by consumer identity, so a name search returns nothing while the data is plainly present.

Fix: Write the consumer identifier into chunk metadata at ingestion time and index it. Retrofitting this after a deletion request arrives is not a 45-day project.

Prompt and completion logs

Support agents paste customer information into prompts. Logs retained for debugging or evaluation then hold personal information nobody inventoried.

Fix: Set a short retention window on raw prompt logs, and scan for personal information at write time rather than search time.

Fine-tuning and evaluation datasets

Snapshots exported months ago for training sit in object storage outside the production data model, unreachable by any consumer-keyed query.

Fix: Maintain a dataset registry recording source, extraction date, and whether consumer identifiers were preserved. A dataset you cannot map to consumers is one you should not be retaining.

Model weights themselves

If a model was trained on personal information, deletion of the source record does not remove the influence on the weights.

Fix: Document your position and your retraining cadence. This is the hardest open question in the area — an articulated, evidenced approach is defensible; silence is not.

Third-party AI vendor systems

Your obligation follows the data to service providers and contractors, who must delete on your instruction — but only if you can tell them what to delete.

Fix: Confirm each vendor exposes a deletion API or documented request path, and record the completion evidence with the request file.

Valid Denial Grounds — and Invalid Ones

You are allowed to say no. You are not allowed to say no for the reasons most businesses use. Every denial should map to one of the first three rows below, and the response must state which.

✓ Valid: The agent submitted no proof of authorization

After you requested signed permission through your published process and it was not provided.

✓ Valid: The consumer's identity could not be verified

You attempted verification at the applicable standard using information you already hold, and the match failed. Document the attempt.

✓ Valid: A statutory exemption covers the data

Retention required to complete a transaction, comply with a legal obligation, detect security incidents, and similar enumerated exceptions. Cite the specific exception, not 'legal reasons'.

✗ Invalid: The request came from a commercial privacy service

Agents may be businesses. Their commercial character is irrelevant to the consumer's right.

✗ Invalid: The volume of requests is burdensome

Volume is a staffing and tooling question. The manifestly unfounded / excessive standard is narrow and applies per consumer, not per agent.

✗ Invalid: We could not find the consumer in our systems

If you genuinely hold no data, that is a substantive response — tell them so, in writing, and say what you searched. It is not a denial.

Action Checklist: Agent-Ready Request Handling

Publish an authorized-agent submission path that accepts a signed permission document, and state the format you accept
Train intake on the power of attorney exception — a valid POA removes your right to demand consumer confirmation
Start the 45-day clock at receipt in your ticketing system, automatically, with no manual 'verified' gate before it
Run verification and data search in parallel from day one
Template the extension notice and set an automatic reminder at day 30
Build a consumer-identifier map covering every AI artifact: vector store metadata, prompt logs, fine-tuning datasets, vendor systems
Record what you searched for each request — the search log is your evidence if the response is challenged
Map every denial to a specific enumerated ground and state it in the response
Confirm each AI vendor has a working deletion path and capture completion evidence per request
Review the request log quarterly for patterns — repeat gaps in the same system are a retention problem, not a request problem

Frequently Asked Questions

Can I require the consumer to verify identity when an agent submits?

Yes — you may require the consumer to verify their own identity with you directly, and to confirm directly that they authorized the agent. Both are expressly permitted by the regulations. The exception is a power of attorney valid under California Probate Code sections 4000-4465: when the agent holds one, you may require neither. Apply whatever process you choose consistently across all agents; selective friction is the pattern regulators look for.

Does the 45-day clock start at submission or at verification?

At receipt. Verification time runs inside the window, not before it. You may take one additional 45-day extension when reasonably necessary, but you must notify the consumer of the extension and the reason within the original 45 days. Treating verification as a pre-clock stage is the most common cause of late responses.

The agent won't give us a signed authorization — can we just close the ticket?

You can deny, but do it properly: state in your response that you denied for lack of proof of authorization, and keep the record showing you requested it through your published process. Silently closing the ticket produces no response at all, which is a separate violation from a denial.

Our AI vendor says they can delete the record but not retrain the model. Is that enough?

It is the current practical ceiling for most deployments, and the honest answer is that the law has not fully resolved it. What is clearly required is deleting the underlying records, removing the data from any dataset staged for future training, and stopping further use. What you should also have is a documented position on model influence and a stated retraining or model-refresh cadence. Regulators have shown far more patience with a documented, evidenced approach than with a business that never considered the question.

Do we have to honor requests from an agent for a consumer who isn't our customer?

If you hold personal information about that California resident, yes — CCPA rights attach to consumers whose personal information you process, not only to people with an account. This catches businesses that acquired data through advertising partners, data appends, or scraped enrichment, where the person has no relationship with you at all and no way to log in.

The Core Rule to Internalize

An authorized agent request is a consumer request. The only differences are the proof of authority you may demand and the exception that removes that right when a power of attorney is presented. Everything else — the deadline, the search obligation, the completeness standard, the denial grounds — is identical.

The failure mode is almost never a legal misreading. It is an intake process that assumes a human will answer a confirmation email, and a data architecture where nobody can say with confidence what the AI systems hold. Fix the second one before the volume arrives; the first is a form change.