2026 California AB 853 AI Detection Tool: Build And Test

The common assumption is simple: if your generative AI product shows an “AI-generated” label, the California requirement is probably covered.

That assumption misses the harder part.

The California AI Transparency Act also deals with how users verify image, video, and audio provenance. The tool must support practical inspection paths, expose system provenance data, avoid exposing personal provenance data, and connect with the disclosures created by the provider’s own system. California AB 853 delays the operative date to August 2, 2026, but it does not turn compliance into a single front-end label. (leginfo.legislature.ca.gov)

If you are building a California AB 853 AI detection tool, the real work is deciding what the tool accepts, what it returns, what it stores, and how you prove that each path works.

What AB 853 actually changes

AB 853 was approved on October 13, 2025. Its most important timing change is that the California AI Transparency Act becomes operative on August 2, 2026, rather than January 1, 2026. (leginfo.legislature.ca.gov)

The law defines a covered provider as a person that creates, codes, or otherwise produces a generative AI system that:

• Has more than 1,000,000 monthly visitors or users.
• Is publicly accessible within California.
• Generates synthetic content such as text, images, video, or audio.

For the detection tool requirement, the covered provider must make the tool available at no cost. The tool must allow a user to assess whether image, video, audio, or combined media was created or altered by that provider’s generative AI system. It must also output detected system provenance data without outputting personal provenance data. (leginfo.legislature.ca.gov)

AB 853 also creates later obligations for large online platforms and GenAI hosting platforms. Those provisions become operative on January 1, 2027, not August 2, 2026. Capture-device requirements become operative on January 1, 2028. Do not place all three timelines into one launch checklist. (leginfo.legislature.ca.gov)

The official source should be your starting point: California’s official AB 853 bill text.

Why a label alone is not enough

A visible label and a verification tool solve different problems.

A manifest disclosure is designed for people. It should identify content as AI-generated in a clear, conspicuous, appropriate, and understandable way. A latent disclosure is embedded or otherwise present in a less visible form. It carries structured information and should be detectable by the provider’s AI detection tool. (leginfo.legislature.ca.gov)

The distinction creates at least four engineering problems.

First, a visible label can be removed during editing, export, or reposting. A product that only adds text below an image has no reliable verification path after the content leaves the original interface.

Second, a watermark or metadata record may exist but remain unreadable to the provider’s own detection system. This creates a disclosure verification gap: the generator claims provenance, while the detector returns “unknown.”

Third, provenance records can contain information that identifies a person, device, or service account. The law separates system provenance data from personal provenance data. Your result page must not treat every metadata field as safe to display.

Fourth, the public tool must be usable without forcing every user through an authenticated product workflow. The statute requires public accessibility, although reasonable limits may be imposed to address demonstrable security or integrity risks. (leginfo.legislature.ca.gov)

The acceptance target is not “the tool returns a result.” It is “the tool returns the right result without exposing the wrong data.”

First step: determine whether your team is a covered provider

Start with the legal role, not the software architecture.

Use this internal decision sequence:

1. Do you create, code, or otherwise produce the GenAI system?
   If you only use an external model through a third-party service, you may not be the covered provider for that model. Keep your contractual and technical role documented.

2. Is the system publicly accessible in California?
   A private internal prototype and a public service should not be treated as the same deployment.

3. Does the system exceed 1,000,000 monthly visitors or users?
   Define how you measure the threshold. Keep the relevant analytics methodology, time period, and regional assumptions in your compliance file.

4. Does it generate or alter image, video, audio, or combinations of those formats?
   The detection tool requirement is focused on these media types. Text-only functionality should be assessed separately against the applicable provisions.

5. Are you licensing the system to another party?
   The law requires a covered provider to contractually require a licensee to maintain the capability to include the required latent disclosure. If the provider discovers that a licensee modified the system so it can no longer create the disclosure, the provider must revoke the license within 96 hours of discovery. (leginfo.legislature.ca.gov)

Model developers, application companies, hosted inference providers, and enterprises integrating external models may occupy different roles. Have product counsel map the chain before engineering starts. Do not assume that calling an external API automatically transfers every compliance responsibility.

Second step: design the three required access paths

A practical California AB 853 AI detection tool should have three user paths:

Content upload detection

The upload flow should accept the media types your system generates or alters. At minimum, test:

• Original image files.
• Exported images with metadata preserved.
• Images stripped of metadata.
• Audio files with and without embedded provenance.
• Video files after compression.
• Mixed media files containing image, audio, or video tracks.

The user should receive a clear status such as:

• Created or altered by this GenAI system.
• Provenance data detected, but source system is not this provider.
• No supported provenance data detected.
• File could not be processed.

Avoid presenting “not detected” as proof that a human created the content. A detector can establish the presence or absence of supported signals. It cannot reliably establish human authorship in every case.

URL content detection

The URL path should fetch only the content needed for verification. Define how your service handles:

• Direct media URLs.
• HTML pages containing embedded media.
• Redirects.
• Expired links.
• Login-required pages.
• Robots and access restrictions.
• Large files and slow origins.
• URLs that return a different file type than expected.

The result should show whether the URL was scanned successfully, not silently convert a fetch failure into a “human-created” conclusion.

Use a separate fetch worker or sandbox. Do not let arbitrary URLs reach internal services, private network ranges, metadata endpoints, or administrative interfaces. URL scanning is both a provenance feature and a server-side request security problem.

API access

The statute expressly requires support for an application programming interface that lets a user invoke the tool without visiting the provider’s website. (leginfo.legislature.ca.gov)

A useful API design should define:

• Authentication and rate limits.
• Accepted media types.
• Maximum request size.
• Upload versus URL parameters.
• Synchronous and asynchronous processing.
• Stable result codes.
• Provenance field filtering.
• Request and response identifiers.
• Error handling and retry behavior.
• Deletion behavior after processing.

For teams asking AI detection tool API how to build, the safest pattern is to keep the API response narrower than your internal metadata model. Return only the system provenance fields required for user verification. Keep raw parser output in a restricted diagnostic channel, if it must be retained at all.

What system provenance data should the result show?

The statute defines provenance data as information embedded in digital content or included in metadata to verify authenticity, origin, or modification history. System provenance data is provenance information that is not reasonably capable of being associated with a particular user and that describes the generating device, system, service, or content authenticity. (leginfo.legislature.ca.gov)

A reasonable result model may include:

• Whether supported provenance data was found.
• Whether the content matches your GenAI system.
• The system name.
• The system version.
• Creation or alteration time, where available.
• A unique content or provenance identifier.
• Whether the record appears intact.
• Whether a digital signature is available.
• Whether the content was modified after creation.

These fields map to the practical meaning of system provenance data output requirements. They help the user understand what happened without exposing an individual’s identity.

Do not automatically display:

• Account email addresses.
• User IDs.
• Device serial numbers.
• Precise device identifiers.
• IP addresses.
• Personal file paths.
• Session tokens.
• Unique service information tied to a particular user.

Personal provenance data includes personal information and unique device, system, or service information reasonably capable of being associated with a particular user. The statute specifically says the tool must not output personal provenance data detected in submitted content. (leginfo.legislature.ca.gov)

Create a field-level allowlist. Do not rely on a generic “remove PII” function after the metadata has already been rendered to logs, analytics, or error traces.

Third step: connect latent disclosure with verification

A latent disclosure is not useful if your own detector cannot recognize it.

The provider’s generation pipeline should write a disclosure that can carry, where technically feasible and reasonable:

• Provider name.
• GenAI system name and version.
• Creation or alteration time and date.
• A unique identifier.
• A durable or difficult-to-remove representation.
• A format consistent with widely accepted industry standards.

The disclosure must also be detectable by the provider’s AI detection tool. (leginfo.legislature.ca.gov)

Build a closed-loop test:

1. Generate an image, video, or audio file.
2. Inspect the raw output before any user editing.
3. Submit it to the public web tool.
4. Submit the same file through the API.
5. Submit it through the URL path.
6. Export it through supported editing workflows.
7. Compress, crop, transcode, or remix it.
8. Re-run detection.
9. Record which provenance fields remain detectable.
10. Confirm that personal provenance fields never appear in the public result.

This is the core of latent disclosure detection verification. A successful test is not merely “a watermark exists.” The test must prove that the disclosure survives realistic handling and remains discoverable by the verification service.

The older California framework also distinguishes manifest disclosure from latent disclosure. A provider may offer a manifest disclosure that is visible to a reasonable person, while the latent disclosure supports machine-assisted verification. Keep these requirements separate in product tickets and test cases. (leginfo.legislature.ca.gov)

Fourth step: set privacy and retention controls

The most important privacy rule is direct: the tool must not retain personal provenance data from content submitted by a user. (leginfo.legislature.ca.gov)

Your implementation should therefore separate four data classes:

1. Transient media bytes
   The uploaded file or fetched content required for processing.

2. System provenance result
   The filtered fields that can be returned to the user.

3. Personal provenance data
   Data that should be excluded from the result and should not be retained from the submitted content.

4. Operational security logs
   Minimal records used for abuse prevention, rate limiting, incident response, and service reliability.

A practical retention design should include:

• Stream processing where possible.
• Automatic deletion of temporary media after processing.
• No raw media in application logs.
• No full metadata dumps in error reports.
• Redaction before observability pipelines.
• Short-lived request identifiers.
• Separate access controls for security logs.
• Documented retention periods.
• A user feedback flow that does not silently retain the original file.

The AI detection tool privacy retention requirements are not satisfied by deleting files from one storage bucket while copies remain in CDN caches, worker disks, debugging systems, or analytics tools.

If a user reports a false negative or false positive, ask for explicit consent before retaining the sample for investigation. Offer a metadata-only report where possible. Feedback is an important engineering control, but it should not become an unannounced secondary data collection process.

Fifth step: test the tool before launch

Your pre-launch test set should cover both clean and damaged provenance.

Test at least these scenarios:

• Native output from the production generation pipeline.
• Output with manifest disclosure intact.
• Output with latent disclosure intact.
• Metadata stripped by export.
• Image recompression.
• Video transcoding.
• Audio re-encoding.
• Cropped or resized media.
• Screen-recorded video.
• A file generated by another system.
• Human-created media containing unrelated metadata.
• Malformed metadata.
• Conflicting provenance records.
• Unsupported file types.
• Oversized files.
• Malicious URLs.
• Expired URLs.
• API retries and duplicate requests.
• Concurrent submissions.
• Rate-limit enforcement.
• Unauthorized access attempts.

For each case, record:

• Expected result.
• Actual result.
• Returned system fields.
• Confirmed absence of personal provenance data.
• Processing time.
• Deletion evidence.
• API response consistency.
• User-facing explanation.

Detection quality should be measured separately from interface quality. A clear interface cannot repair a detector that fails after ordinary compression. Conversely, a technically strong detector still fails the product requirement if users cannot upload content or invoke the API.

Where teams usually fail

A tool may return results and still create compliance risk.

It supports only a website.
The API path is missing, so enterprise workflows and automated verification cannot use the required interface.

It exposes raw metadata.
The response includes a device identifier, account value, or service-specific identifier that can reasonably be linked to a person.

It stores uploads indefinitely.
The product team keeps samples “for model improvement” without a separate consent and retention decision.

It treats unknown as human-created.
This overstates what provenance detection can prove.

It adds a watermark but never tests the detector.
The latent disclosure exists in theory but fails after export, transcoding, or API processing.

It confuses California deadlines.
The covered-provider detection tool and disclosure requirements operate on August 2, 2026. Large online platform obligations are scheduled for January 1, 2027, while capture-device provisions are scheduled for January 1, 2028. (leginfo.legislature.ca.gov)

What can be reused for EU AI Act Article 50?

Some engineering capabilities can be reused, but the legal duties are not interchangeable.

EU AI Act Article 50 requires providers of systems generating synthetic audio, image, video, or text to mark outputs in a machine-readable format that can be detected as artificially generated or manipulated, where technically feasible. It also includes disclosure obligations for deepfakes and certain AI-generated text published to inform the public. (ai-act-service-desk.ec.europa.eu)

You can reuse:

• Machine-readable provenance structures.
• Latent disclosure generation.
• Signature verification.
• Media transformation tests.
• Public verification interfaces.
• Field-level privacy filtering.
• Audit logs and test evidence.

You cannot assume that a California detection tool alone satisfies EU AI Act Article 50. The EU framework separately addresses provider marking, deployer disclosures, direct AI interaction, deepfakes, and public-interest text. Treat the shared technical layer as reusable infrastructure, not as a single cross-border compliance answer. (ai-act-service-desk.ec.europa.eu)

AB 853 acceptance matrix

The following matrix is a product and engineering checklist, not a legal opinion. Mark each row with an owner, test date, evidence location, and release decision.

The matrix should remain versioned. If you change the generator, provenance format, parser, URL fetcher, or API response model, rerun the relevant tests.

A compact launch plan

Three questions teams ask before launch

Does AB 853 require a detector to prove that content was made by a human?

No. The required workflow is focused on assessing whether covered-provider content was created or altered by that provider’s GenAI system and returning detected system provenance data. “No supported provenance detected” should not be presented as proof of human authorship. (leginfo.legislature.ca.gov)

Can we keep uploaded files for debugging?

Do not assume so. The statute prohibits retaining personal provenance data from submitted content, and raw files may contain such data. Use transient processing, redact diagnostic records, and obtain explicit permission before retaining a sample for investigation. (leginfo.legislature.ca.gov)

Is a visible “AI-generated” label the same as a latent disclosure?

No. A manifest disclosure is human-facing. A latent disclosure is designed to carry structured provenance information and must be detectable by the provider’s AI detection tool. Treat them as separate controls. (leginfo.legislature.ca.gov)

Choosing the validation environment

Many teams first validate this workflow on a mixed set of developer laptops, shared Windows workstations, and temporary cloud instances. That approach can work for an early prototype, but it often creates three practical weaknesses: inconsistent browser behavior, different media codecs, and hard-to-reproduce capture or export results.

For a production acceptance run, a controlled macOS environment can be useful when your test plan includes Safari, QuickTime-based capture, microphone and camera permissions, Apple media frameworks, or Apple Silicon-specific processing. Renting a dedicated Mac from ZilCloud lets product and QA teams reproduce those paths without purchasing another workstation or sharing one employee’s machine.

This does not replace the California compliance review. It gives you a cleaner test surface. You can compare the ad hoc setup against a managed Mac environment, run the same upload, URL, and API cases, and preserve evidence from a known configuration. If your current validation process depends on borrowed laptops, inconsistent local settings, or a cloud image that does not match real macOS behavior, a Mac rental workflow may reduce those operational gaps.

Save the acceptance matrix, then have product, engineering, privacy, and legal review the scope together. Confirm the three access paths, test provenance after media transformation, and audit every place uploaded content or metadata could be retained. This article is an engineering and product planning guide, not legal advice.