Every AI rollout in a regulated marketing team dies in the same meeting. Marketing shows what the tool can produce in an afternoon. Regulatory asks one question: which of these sentences has been approved?
Nobody in the room can answer, so the answer becomes no. Or worse, the answer becomes yes, and every generated sentence joins the review queue that was already the bottleneck.
The problem was never tone of voice or brand consistency. In medical devices, pharma and financial services the problem is claims. Every sentence a model writes is a potential claim, and a claim is the one thing in your marketing a regulator reads.
The Risk Is Not Tone. It Is Claims.
The rules are written around claims, not adjectives. Under the EU Medical Device Regulation, Article 7 prohibits any text, name or picture in labelling, instructions or advertising that may mislead the user about a device’s intended purpose, safety or performance: ascribing functions it does not have, creating a false impression of treatment or diagnosis, hiding a likely risk, or suggesting a use outside the purpose it was assessed for.
The United States enforces the same idea at scale. In 2025 the FDA issued more than 200 enforcement letters challenging prescription drug advertising and promotion. 74 went to pharmaceutical and biologic manufacturers, and only 5 of those were issued before 9 September, when the agency’s promotion office began a wave of action without precedent in a generation. A further 32 letters targeted medical device marketing, most of them for marketing without clearance or for implying an unapproved intended use.
Financial services runs on the same logic with different vocabulary. The UK’s Financial Conduct Authority reports that in 2024 authorised firms amended or withdrew 19,766 financial promotions after the regulator intervened, almost double the 10,008 of the year before.
None of these regimes cares whether the sentence was written by a person or a model. They care whether the claim was true, approved, in date and in scope. That is the standard AI has to meet, and it is a standard most AI deployments are not designed around.
What Review Costs Today
Before AI arrives, most regulated teams already have a queue. Every asset passes through medical, legal and regulatory review, or its equivalent, before it ships. EY puts the average time to approval at 24 days and describes the cost to the pharma and medtech industries as tens of millions a year. We rebuilt that queue on our own brand and wrote down what broke: an email, a page, three buttons, and a record an auditor can read.
Twenty-four days is not the cost of care. It is the cost of reviewing the same claims again on every asset, because nothing in the process remembers that the claim was approved last time. The reviewer opens a brochure and reads every sentence as if for the first time, because the system gives them no reason not to.
Now add a model that produces ten variants where a writer produced one. The queue does not get faster. It gets ten times longer, and the reviewer’s job gets harder, because the variants are fluent and plausible and each one has to be checked against the approved wording by eye.
The people doing the work know this. In a small survey of 40 promotional review professionals in the US, run by Klick Health and Momentum Events in 2025, 65% said they did not trust AI to create regulatory submissions. Their reasons are the point of this piece: hallucination came first at 40%, then the lack of a traceable audit trail at 20%, then the lack of transparency at 12.5%. Only one respondent in the group had deployed AI for review at all.
They are right to distrust it. Not because the models are bad at writing, but because the way most teams deploy them gives regulatory nothing to hold on to.
Three Ways Teams Handle It, and Why Each Fails
The ban. Marketing is told not to use generative tools for anything external. It fails quietly, because people use them anyway on their own accounts, and the output arrives in the review queue with no marker on it. The team now has the risk without the visibility.
The disclaimer. The tools are allowed, and every generated draft is flagged for full review. This is honest, and it is the version that makes the queue ten times longer. It treats the model as a junior writer who cannot be trusted, and then spends senior reviewer time proving it.
The checker. A second model reads the first model’s output and flags sentences that look like unapproved claims. This is the most common answer in 2026 and it is better than nothing. It also inherits the problem it was meant to solve: it is a judgment about wording, made by a system that can be wrong, with no record of why it passed what it passed. The second concern in the Klick Health and Momentum Events survey, no audit trail, applies to the checker exactly as it applied to the writer.
All three share an assumption: that the claim is decided at the end of the process, on the finished asset, by a person reading it. Everything downstream of that assumption is a queue.
Approve Once. Enforce Everywhere.
There is a fourth way, and it moves the decision to the start.
Treat every approved claim as a rule, not as a sentence in a document. Write it down once, verbatim, with the things a regulator will ask about attached to it: who approved it, on what date, when it must be reviewed again, in which jurisdictions it may be used, and which variants must never appear. A claims library, held in the same place as the brand’s colours and typefaces, under the same version control.
Then make it the only wording the system can produce. The model does not write claims. It places approved claims, and writes the connective copy around them under the brand’s rules. When a draft is rendered, a mechanical check reads every sentence against the library: is each claim present in its approved form, is it in date, is it approved for this market, and does any forbidden variant appear anywhere on the page? The check takes seconds, it runs before every release, and it cannot be skipped by anyone in a hurry.
This is how we built the regulated variant of our own brand system. The claims library is a rule category beside colour and type. The check is one of fourteen that run before a release. When a claim passes its review date the release fails until someone with the right role re-approves or retires it, and nobody has to remember the date. We describe it in one page, Design Catalyst for regulated teams, and we run the same mechanism, without the claims, on every page of this website.
The effect on the queue is the interesting part. Regulatory reviews the claim once, when it enters the library. After that, the reviewer of any individual asset is not re-reading claims. They are reading the connective copy, and the check has already told them the claims are in order. The 24 days do not shrink to zero. They shrink to the time it takes to read what is genuinely new. The signatory still reads every asset before it ships. What changes is what they are reading for: not whether the claims are right, which the check has already proved, but whether the copy around them says anything new. On a brochure that is minutes, and it is a better use of a regulatory professional than proof-reading a sentence they approved in March.
What “Traceable” Means to an Auditor
The reviewers in that survey put the missing audit trail second. It deserves its own answer, because it is the one that decides whether regulatory will ever say yes.
An auditor’s question is never “did you use AI?”. It is “why does this brochure say this, who approved it, and was it approved at the time you shipped?”. A traceable system answers that in four steps, none of which involves asking a person to remember.
- The brochure carries the version it was rendered from.
- That version contains the claims library as it stood on that date.
- Each claim in it names its approver role, approval date, review date and jurisdiction, and every change to it since is a dated history entry, never an edit of the old text.
- The decision to approve it sits in a numbered, dated log, and the approval itself was recorded under the approver’s own login in a ledger that cannot be edited afterwards.
That is a controlled-document system, described in the vocabulary quality teams already use: change control, not brand evolution. It is also, not by coincidence, the thing a model cannot fake. A hallucinated claim has no approver, no date and no history. The check catches it not because it reads as false but because it does not exist in the library.
Where to Start
Not with the model, and not with the whole library.
Pick one asset type. The one that is reviewed most often and changes least: a product page, a core brochure, a standard email sequence. Its claims are already known; they are just held in the reviewers’ heads and in the last approved PDF.
Write the claims down as rules. Verbatim, with the five fields. Most teams find twenty to forty claims cover the majority of what they ship. This is a week of work for one regulatory person and one marketer, and it is the first time the two have agreed on a list.
Put the check in front of the release. Before anything ships, every sentence is read against the library. Start by running it in report mode, so the team sees what it catches. Then make it blocking.
Only then let the model write. Connective copy around approved claims, under the brand’s rules, with the check as the last step. The first assets through will be slower than the old process, because the library is new and the reviewer is learning what the check does and does not cover. By the tenth, the review is a read of the connective copy, and the sign-off takes the time the sign-off deserves.
Set the review dates and let them bite. The first time a release fails because a claim has expired, and someone with the right role re-approves it in an hour instead of the whole team re-reading a brochure, regulatory will understand what changed.
The Question Worth Asking
The debate about AI in regulated marketing has been framed as speed against safety: how much faster can we go before compliance says stop. It is the wrong frame. The queue was never protecting you. It was re-checking, by hand, decisions that had already been made, and the model only made that visible.
The right question is not how much AI your reviewers will tolerate. It is: how many of your approved claims could you list right now, with their approval dates, without opening a single PDF?
If the honest answer is none, that is the constraint, and it was there before the model arrived.
Start with a call about the one asset type you review most. We will tell you whether a claims library is the constraint for your team, or whether something upstream is, and if it is the latter we will say so.
Book a discovery call → Design Catalyst for regulated teams →
FAQ
Frequently asked questions
Does a claims library replace regulatory review?
No. It makes each review count once. Regulatory approves a claim as a rule, with its wording, jurisdiction and review date. Every asset rendered after that can only use the approved wording, and a check fails the release if a forbidden variant appears or a claim goes out of date. Reviewers spend their time on what is new, not on re-reading what they approved last quarter.
Is this different from an AI compliance checker?
Yes, in one way that matters. A checker judges wording after the fact and leaves no record of why it passed what it passed. A claims library decides the wording before the fact, in a rule with an approver and a date, and the check is a lookup against that rule, not a judgment. The audit trail is the library itself.
How many claims does a team usually have?
For one asset type, typically twenty to forty. Across a product line, a few hundred. The number matters less than the fact that they are written down once, verbatim, with an owner and a date, rather than living in reviewers’ memories and in the last approved PDF.
What happens when the regulation or the label changes?
The claim gets a new history entry, a new approval and a new review date. The old wording is not deleted; it stays in the history so that any asset rendered under it can still be explained. Assets rendered after the change fail the check until they are regenerated with the new wording.
Does the model ever write a claim?
No. It places approved claims and writes the copy around them. If it produces a sentence that reads like a claim and is not in the library, the check flags it. That is the behaviour that makes regulatory comfortable with the model in the first place.