Build an AI-Origin Content Filter

Suppose a user says:

Exclude AI-generated content from my browser experience.

The request is clear. The underlying fact often is not.

Once text has been copied, edited, translated, mixed with human work or stripped of metadata, its origin may be impossible to establish from the content alone. A serious filter must therefore manage evidence and uncertainty rather than pretend to possess an infallible detector.

1. Define the claim precisely

“AI-generated” can mean several things:

• produced entirely by a generative model;
• drafted by a model and edited by a person;
• human-written but translated or proofread by AI;
• accompanied by an AI-generated image;
• published by an automated account;
• merely written in a style associated with model output.

One binary label cannot represent all of these. The policy should name the claim it cares about, such as “the publisher declares that this unit contains generated text” or “signed provenance records a generative action.”

The filter we build acts on evidence of AI origin, not metaphysical certainty about authorship.

2. Use an evidence ladder

Prefer direct provenance over inference:

Absence of provenance is not proof of human creation. A screenshot, copy-and-paste or ordinary transformation may discard the evidence.

3. Preserve useful decision states

The evidence resolver can produce:

type OriginAssessment =
  | "verified-ai"
  | "declared-ai"
  | "likely-ai"
  | "unknown"
  | "verified-non-generative-workflow";

The final state is deliberately narrow. It means the available provenance records a workflow without a generative step; it does not prove that no AI was used outside that record.

Avoid a broad human label unless the evidence can truly support it.

Each assessment also carries evidence references, confidence where relevant, provider identity and limitations.

4. Write the user’s rule

A strict provenance-based rule might be:

{
  "schema": "browser-policy/1",
  "id": "exclude-declared-generative-content",
  "when": {
    "signal": "origin-assessment",
    "operator": "in",
    "value": ["verified-ai", "declared-ai"]
  },
  "action": "hide",
  "unknownAction": "show",
  "allowReveal": true
}

A more aggressive rule may blur likely-ai content above a threshold. That is a different policy with a higher false-positive risk. The interface should make the difference explicit rather than quietly enabling a detector.

5. Build a staged classifier

For each extracted unit:

1. inspect embedded or linked provenance;
2. verify signatures and claims when supported;
3. inspect explicit site labels through a site adapter;
4. consult publisher declarations and known workflow metadata;
5. run an optional local classifier only if policy needs more evidence;
6. resolve the evidence without erasing disagreement;
7. apply the policy action;
8. write the decision trace.

This order is both more defensible and often cheaper than beginning with model inference.

The system should never turn a classifier score into a provenance claim. “This resembles generated text” and “this was generated by AI” are different statements.

6. Render the decision honestly

A hidden card leaves a compact placeholder:

Hidden by “Exclude declared generative content”
Evidence: platform declaration
[Show once] [Why?] [Change rule]

For a heuristic result:

Blurred by “Flag likely generated content”
Evidence: local classifier, uncertain
[Reveal] [Mark incorrect] [Inspect evidence]

The wording must match the strength of the evidence. The user should not see “AI-generated” when all we know is that one classifier returned 0.71.

7. Cache decisions without creating a tracking system

Repeated evaluation wastes computation, but a global content fingerprint database creates privacy and correlation risks.

A conservative cache can use:

• an origin-scoped keyed digest;
• normalized unit content and relevant metadata;
• policy, provider and model versions;
• a short retention period;
• local storage only by default.

Changing the unit, policy or evidence provider invalidates the decision. A user can clear the cache and inspect its approximate size.

8. Evaluate the costly errors

The evaluation corpus should include:

• content with verifiable generative provenance;
• declared and undeclared generated content;
• human-authored material across domains and languages;
• heavily edited and mixed-authorship work;
• very short units;
• quoted material and templates;
• adversarial paraphrases and metadata removal.

Measure coverage separately from accuracy. A provenance verifier may be highly precise when evidence exists while covering only a small fraction of the web.

For classifiers, record false positives, false negatives, calibration, abstention and subgroup performance. A false positive may hide important human speech, so the cost cannot be reduced to one aggregate score.

The release gate should be tied to the action. A model acceptable for adding a subtle label may be unacceptable for silently hiding content.

9. Trace one complete decision

The Observatory should be able to replay:

unit extracted
  → platform label found
  → provenance absent
  → classifier skipped
  → assessment: declared-ai
  → policy matched
  → placeholder rendered
  → user revealed once

This trace makes the filter accountable. It also creates the data needed to improve site adapters, thresholds and user controls without collecting the original content centrally.

10. State the limit in the product

The product must say plainly:

This filter acts on available provenance, declarations and optional probabilistic signals. It cannot identify all AI-generated or AI-assisted content.

That is not a footnote. It is part of the feature contract.

An honest, adjustable filter can still be useful. A fictional oracle cannot be debugged, evaluated or trusted.

Conclusion

An AI-origin filter is possible as a personal browser policy, but not as a universal truth machine.

The defensible design is provenance-first, explicit about the claim being made, cautious with classifiers, reversible in its effects and complete in its evidence trace. The final chapter places this filter inside a broader argument: the user should be able to govern their interface even when the platform would choose differently.

Sources and further reading

1. Coalition for Content Provenance and Authenticity, C2PA specifications.
2. Content Authenticity Initiative, Content Credentials.
3. Chrome for Developers, Content scripts.