AI Transparency Law Should Regulate Evidence That Survives Model Change
AI transparency law is entering a difficult phase.
The first wave of rules asked large AI developers to disclose more about their systems: safety frameworks, model capabilities, risk assessments, system cards, incident reports, governance processes. That was a necessary beginning. It also exposed a structural weakness: a law written around a specific disclosure format starts aging the moment the underlying models, workflows and deployment patterns change.
In July 2026, WIRED reported that Anthropic — after backing landmark AI transparency laws in California and New York — now argues that some of those same rules may already lag the technology they were built to govern. Its June 2026 Advanced AI Framework goes further, proposing external evaluations, ongoing risk reporting and government authority to act on the results. The position is not less regulation. It is regulation that can keep pace.
That is a fair diagnosis. It also leaves one question open, and the question is sharper than the diagnosis: if the architecture cannot be the fixed point, what should be?
For anyone licensing content into AI systems — publishers, rights organizations, and the governance teams drafting the rules — the answer is not abstract. It decides whether a transparency obligation is still enforceable in three years, or already obsolete on the day it is signed.
In short
Static disclosure rules describe a system's design. When the design changes, the rule ages out.
The durable alternative is to regulate what a system can demonstrate, not how it is built: which protected content it accessed, under which rights, and how that content contributed to a given output.
That shift is not a softer rule. It is a more verifiable one. An architecture-based rule asks a provider to explain a method that will change. An evidence-based rule asks a provider to produce a record that stays readable when the method changes.
For content usage specifically, the fixed point is the event: a protected work was used, at a moment, under a right, toward an output. That event can be logged the same way whether the model behind it is a 2026 transformer or something not yet named.
At Citations Logic, we call that record usage evidence. This article is about how to write it into a rule — or a contract — so it does not expire.
The problem with architecture-based disclosure
AI systems do not stand still. Models are updated, fine-tuned, routed, distilled, combined with retrieval systems, wrapped in agents, and embedded into products that behave differently from the base model.
A disclosure regime built mainly around how a system is designed will always be chasing the last release cycle. It can describe a model card, a safety process or a technical architecture at a point in time. But the commercial and legal question usually appears later: what did the system actually use?
That distinction matters for copyright and content licensing. A publisher does not only need to know that an AI developer had permission to access a corpus. Permission is not proof of use. Nor does a general transparency report show whether a specific article, legal commentary, medical reference or scholarly abstract contributed to a service, an answer, a summary or a workflow.
Architecture explains the system. Evidence explains the event.
What recent AI safety laws reveal
The safety laws are not copyright laws — but they show the pattern content markets are about to inherit.
California's SB 53, the Transparency in Frontier Artificial Intelligence Act, requires large frontier developers to publish a frontier AI framework, issue transparency reports for new or substantially modified models, summarize catastrophic-risk assessments and report critical safety incidents. It defines frontier models by training-compute thresholds and large developers by revenue thresholds.
New York's RAISE Act follows the same movement: large developers must publish safety-protocol information, report incidents within 72 hours, and operate under a new oversight office inside the Department of Financial Services.
Both fix requirements to today's technical vocabulary — compute thresholds, model cards, current risk categories. That is defensible for catastrophic-risk safety, where the concern is the frontier model itself. It travels poorly to content usage, where the concern is what a system did with a specific work, through mechanisms that keep changing. Lawmakers are trying to define what must be disclosed before the technology stabilizes. For content, betting the rule on any one generation's design is the failure mode, not the fix.
Why "future-proof" and "verifiable" are not the same trade-off
There is a quiet assumption in AI policy debate: that making a rule adaptable means making it looser. That assumption is wrong, and separating two ideas shows why.
A rule is future-proof if it still applies after the technology changes. A rule is verifiable if a third party can check whether it was followed. These are independent properties — a rule can be one without the other.
A vague principle ("providers must be transparent about content use") is future-proof but not verifiable. It survives any architecture because it demands nothing checkable.
A method mandate ("providers must disclose their retrieval-augmented generation pipeline configuration") is verifiable today but not future-proof. The day retrieval design changes, the disclosure describes nothing.
The quadrant most rules miss is the useful one: future-proof and verifiable at once. You reach it by fixing the rule to the thing that does not change when the architecture does. In content licensing, that thing is the usage event. Whatever the model is, a protected work either contributed to an output or it did not — a question answerable in 2026 and still answerable in 2030, because it does not depend on the design that produced the output.
This is the same distinction we draw between content provenance and usage evidence: provenance tells you where a work came from; only usage evidence tells you what happened to it inside the system. A future-proof rule regulates the second.
The durability test: four questions for any transparency obligation
Before a transparency requirement goes into a statute, a code of practice or a licensing contract, it can be stress-tested. The test is not "is this strict enough?" It is "does this still mean anything after the architecture changes?" Four questions decide it.
1. Does the obligation reference a technical design, or an observable event?
If the words name a method — a training technique, a model class, a pipeline stage — the clause ages with that method. If they name an event (a protected work was accessed and contributed to an output), the clause outlives it. Rewrite design references as event references.
2. Can compliance be checked by someone who did not build the system?
An obligation verifiable only by inspecting proprietary internals is not verifiable in practice. One satisfied by producing an exportable, event-level record can be checked by a rights holder, an auditor or a regulator. If checking requires the provider's help to interpret the provider's own black box, the rule is weak.
3. Would the obligation still produce the same evidence if the model were replaced tomorrow?
The core future-proofing question. Imagine the provider swaps its entire model stack overnight. Does the required record still exist, in the same shape? If yes, the rule is anchored correctly. If the record depended on the old architecture, the rule broke on swap day.
4. Is the unit of measurement defined independently of any one platform?
If "a use" means whatever each platform decides, the obligation cannot be compared across providers or across time. A durable rule defines the unit — access, retrieval, grounding, display, generation — so the same event counts the same way everywhere. Without this, every provider reports in its own currency and no regulator can add the numbers up.
A clause that passes all four is both adaptable and enforceable. A clause that fails any one is either obsolete-on-arrival or unfalsifiable. Most current disclosure language fails on question 1 — it describes methods — which is exactly the failure mode Anthropic flagged.
From principle to clause: how to draft it
The durability test tells you whether a clause survives. It does not write the clause. Here is the translation, for both a regulator drafting an obligation and a rights holder drafting a contract term. The pattern is the same in both settings: name the event, name the required record, name the unit, name the export right.
Element | Architecture-based (ages out) | Evidence-based (durable) |
|---|---|---|
What is disclosed | The training method or pipeline design | The event: a protected work contributed to an output |
When it is captured | Described once, at model-documentation time | Logged at each interaction, continuously |
Unit of measurement | Left to the provider | Defined: access, retrieval, grounding, display, generation |
Who can verify | Only the provider, by inspecting internals | Any authorized party, from an exportable record |
On model change | The disclosure describes a system that no longer exists | The record keeps the same shape |
A drafter can turn the right-hand column into operative language directly. A minimal durable clause has four commitments:
Event capture. The provider records, at the point of interaction, each instance in which protected content contributes to an output — regardless of the technical mechanism by which it contributes.
Rights binding. Each recorded event is tied to the right under which the content was used, so that permitted and non-permitted use stay distinguishable after the fact.
Defined unit. The record distinguishes use types — access, retrieval, grounding, display, generation — using definitions that do not depend on the provider's architecture.
Export and audit. The record is exportable in machine-readable form to the rights holder or a designated auditor, independent of the provider's own reporting interface.
None of the four names a model, a training technique or a pipeline. That is deliberate. It is what lets the same clause govern a system that has not been designed yet.
The objection: isn't event logging its own architecture mandate?
A fair challenge. If you require providers to log usage events, aren't you doing exactly what you warned against — freezing a technical design into law? Logging is a technical choice too.
The distinction holds. An architecture mandate specifies how the system must be built — use this method, expose this component — and constrains design. An evidence mandate specifies what the system must be able to show — produce a record of this event, on request — and constrains output, not design. The provider stays free to build any system it likes, by any method, as long as it can demonstrate what it did with protected content.
That is the logic that already governs financial audit. Regulators do not dictate a company's accounting software; they require statements a third party can verify. The software changes constantly; the obligation to produce checkable evidence does not. Content-usage evidence applies that settled principle to AI — the point we develop in proof of AI content usage.
Why this matters for publishers and rights holders
Publishers are asked to evaluate AI licensing opportunities before usage evidence exists. A deal defines access rights, permitted uses, restrictions and economics. The renewal question comes later: was the content used, how often, in which workflows, did usage cluster around high-value assets?
Without durable evidence, the rights holder is left with belief, estimates or platform-level summaries. Those support a conversation; they do not support a strong licensing position. This is the same asymmetry we describe in usage reporting in AI licensing deals: whoever defines what counts as a use controls the number.
One caution. Most transparency obligations, including the ones Anthropic backed, fall on model providers, not on publishers. An evidence standard for content usage does not change that — the drafting burden sits with regulators, the production burden with providers. But the party with the most to gain from getting the standard right is the rights holder. A provider logs what it is required to log; a regulator requires what stakeholders make the case for. If publishers and rights organizations do not specify what content-usage evidence should look like — event-anchored, rights-bound, unit-defined, exportable — someone else will specify it for them, in a shape easier to report than to verify. In regulation, whoever defines the evidence standard controls what is provable. The drafting stage is the leverage stage.
The policy choice ahead
The next phase of AI transparency will not be settled by choosing between regulation and innovation. That framing is too shallow. The real choice is between disclosure that ages with the architecture and evidence that survives model change.
Anthropic's admission is useful precisely because it comes from inside the industry that wrote the rules. Static disclosure ages badly — the company is right. The answer is not to regulate less. It is to regulate the one thing that does not change when the technology does: what a system can demonstrate about its use of protected content.
Architecture is a moving target. Evidence is a fixed one. A rule aimed at the second keeps working after the first has moved.
Frequently asked questions
Does regulating outcomes instead of methods mean weaker AI regulation?
No. Future-proofing and verifiability are separate properties. An outcome-based rule requiring providers to produce an exportable, event-level record of content usage is more checkable than a method disclosure, not less — it can be verified by a third party without inspecting proprietary internals, and it survives changes to the underlying model.
What is the "fixed point" a durable transparency rule should target?
For content usage, the fixed point is the usage event: a protected work was accessed and contributed to an output, at a moment, under a right. Unlike a model's architecture, this event is observable and definable regardless of how the system that produced the output is built, so a rule anchored to it does not age when the design changes.
Isn't requiring usage logs just another technical mandate?
No. A technical mandate constrains how a system is built. An evidence mandate constrains what a system must be able to demonstrate, leaving design free. The parallel is financial audit: regulators require verifiable statements, not a specific accounting system. The obligation to produce checkable evidence persists while the underlying technology changes.
Who is responsible for producing content-usage evidence?
The production burden sits with AI model providers, the regulated party under transparency laws like California's and New York's. Publishers and rights organizations are not directly regulated, but they have the strongest interest in specifying what the evidence standard should require, because whoever defines the standard determines what can later be proven, priced and audited.
Continue the evidence chain
AI Usage Evidence for Publishers: The Proof Layer for AI Licensing
EU AI Act and Content Licensing: Why Access Is Not a Usage Record
Usage Reporting in AI Licensing Deals: Who Audits the Number?
Book an AI usage evidence assessment
Sources
WIRED — "Here's Why Anthropic Is Pushing States to Regulate AI Faster" (July 2026)
https://www.wired.com/story/why-anthropic-is-pushing-states-to-regulate-ai-faster/
Anthropic — Advanced AI Framework (June 2026)
https://www-cdn.anthropic.com/files/4zrzovbb/website/0a58d567024a8b448ff15158ebc3625328dfcc1f.pdf
California SB 53 — Transparency in Frontier Artificial Intelligence Act
https://leginfo.legislature.ca.gov/
New York Governor's Office — RAISE Act announcement
https://www.governor.ny.gov/