Marketing Claims Compliance Check: Review Copy With an AI Agent on Rails

Who this is for: compliance reviewers, lifecycle marketing leads and copy owners in banks, insurers, healthcare and other regulated sectors. This page belongs to the AI agent rails method and the lifecycle marketing playbook.

Before: the manual workflow

The manual claims review is a queue of documents and comments between a copy owner and compliance. Time goes on repeat objections, on finding the evidence behind a number, and on rereading variants. Errors follow set paths: an approved line changes in a later variant, evidence expires unnoticed, or context implies a claim nobody stated. FINRA says speed and volume make mandatory pre-use approval hard to apply to AI-generated retail communications 6.

Which marketing claims need a compliance check?

Marketing claims need a compliance check when they state or imply something objective, or when sector law controls the message. The table is a starting map for counsel to adapt.

AI disclosure needs care in two ways. The European Commission's FAQ does not name marketing copy, though its public-interest topics include economic and financial developments open to public debate 10. A bank's market commentary could raise the question, so take advice. The FAQ says spell-checking is not human review 10, and on our reading an agent's pass is not either. Disclosure also does not repair a false claim: the ASA says it is very unlikely to mitigate a fundamentally misleading message 8.

After: the job on rails, step by step

The claims check on rails runs rules first, then the model, then a person, and each step leaves a record. Writing the register comes first and is most of the work.

1. Trigger. The copy owner submits one version with its market, product, channel and audience description.
2. Rules run. A lint checks disclosures, banned phrases, figures and expiry dates. Failures block sign-off whatever the model says.
3. Model reads. The Claims Checker extracts stated and implied claims and maps each to a register entry, or marks it "no entry".
4. Validator checks citations. A separate service rejects any finding citing a rule or evidence ID outside the approved set.
5. People decide. The copy owner resolves ordinary findings. A compliance reviewer, never the copy owner, signs off regulated claims.
6. Sign-off binds. Approval attaches to the hash of the exact copy, so a later edit voids it. A timeout expires the request and never approves it.
7. Publishing checks. The publishing system refuses copy whose hash has no sign-off. The agent holds no publishing tool.
8. Ledger and learning. A system outside the agent writes the record. The Trainer proposes new seeded claims from decisions and escaped errors.

What rules do and what the model does

Rules handle anything with an exact right answer, and the model handles reading in context, where it can only raise a question. A model's pass never overrides a failed rule, and its silence does not mean correct.

The rail card

The rail card below fixes what the Claims Checker may do, and systems enforce each limit, so a prompt cannot widen it.

The level stays at L2, as the rail levels explain, because approving a claim is a legal judgement. The Rule of Two gives a second reason 12. Agency copy is untrusted input that can carry hidden instructions, and pre-release product details are confidential. So the session must not gain the third property, the power to change state. An external model is acceptable where the contract allows, and a private model suits regulated teams.

What the ledger shows for one run

The ledger entry for one run shows an auditor what was checked, what was found and who decided. The JSON is illustrative: its fields and values are invented, and it is not a product API.

{
  "rail": "claims-checker",
  "correlation_id": "c-19be",
  "copy_version_hash": "sha256:3fd0...",
  "market": "UK",
  "rule_set_version": "uk-finprom-14",
  "register_version": "112",
  "checks_run": ["disclosure_lint", "number_check", "register_match", "implied_claims"],
  "findings": [
    {"id": "f1", "location": "para-2", "type": "no_register_entry", "severity": "high"}
  ],
  "decisions": [
    {"finding": "f1", "by_role": "compliance reviewer", "outcome": "claim removed"}
  ],
  "sign_off": {"by_role": "compliance reviewer", "bound_to": "sha256:a81c..."},
  "model_version": "model-v7"
}

Three ways it fails, and the control for each

The Claims Checker fails in predictable ways, and each control below sits outside the model.

Metrics that are honest

Honest metrics for claims review count what was caught and what escaped, by regulated topic, using the roadmap's definitions. Baseline them first, and treat vendor review-time figures as claims to test.

• Catch rate on seeded claims, by topic, so a good total cannot hide a blind spot in health or credit.
• False-flag rate: findings a reviewer rejects as wrong. High rates teach people to dismiss flags.
• Escaped error rate: corrections, complaints or rulings after publication, counting human and agent misses alike.
• Register coverage: share of regulated claims with a live entry.
• Override rate. A rate near zero may mean rubber-stamping, so sample decisions.
• Audit coverage. Anything below 100% is a defect.

Report by rail and role, not by named reviewer. Annex III point 4(b) of the EU AI Act lists monitoring and evaluating workers' performance as a high-risk use 11, so take advice before building a per-person view.

How vendor tools compare

Vendor tools for claims review are the better answer for many regulated firms, because they arrive with workflows and audit trails. The table records each vendor's page, checked on 1 November 2026, with no accuracy claim tested.

Choose a vertical tool for a steady review queue under an acceptable contract. Build this rail only if you need your own ledger, a private model or a register already in your systems. A lint alone is enough when copy comes from a few locked templates. Doing nothing new is fair when volume is low and one reviewer reads everything.

PrivyCDP's immutable audit ledger records each AI-assisted action with the human or system actor that authorised it, which is the kind of record this rail needs. For how evidence stays reproducible, read explainable AI for customer decisions.

Checklist

Use this checklist before the agent reads live copy.

• ☐ A claims register exists, with wording, evidence, owner, market and expiry per claim.
• ☐ Rule sets are versioned by market and reviewed by counsel.
• ☐ A lint checks disclosures, banned phrases, figures and dates, and a failure blocks sign-off.
• ☐ The compliance reviewer is never the copy owner.
• ☐ Sign-off binds to a copy hash, and publishing refuses anything else.
• ☐ The seeded-claim set covers each regulated topic and is rerun on any model, prompt or tool change.
• ☐ Service templates are checked for promotional text.
• ☐ The ledger is written outside the agent.

Back to the AI agent rails hub. To write this rail for your own team, download the rail card template.