Machine-readable marking: content provenance as certification evidence before 2 December 2026

The duty, in the words of the paragraph

Article 50(2) addresses providers of AI systems, including general purpose AI systems, that generate synthetic audio, image, video or text content. It requires them to ensure that the outputs of the system are marked in a machine-readable format and detectable as artificially generated or manipulated. The technical solutions used have to be effective, interoperable, robust and reliable as far as this is technically feasible, taking into account the specificities and limitations of various types of content, the costs of implementation and the generally acknowledged state of the art.

That sentence contains two different requirements, and organisations routinely satisfy one while assuming it has covered both. Marked in a machine-readable format is a property of the file: something is written into or alongside the artefact that a machine can read. Detectable as artificially generated or manipulated is a property of the system as a whole: there has to be a way to tell. A provenance record that travels in a metadata field satisfies the first and satisfies the second only for as long as the field survives.

The paragraph then carves out cases. The obligation does not apply where the AI systems perform an assistive function for standard editing, or do not substantially alter the input data provided by the deployer or its semantics. A further exception covers systems authorised by law to detect, prevent, investigate or prosecute criminal offences. Each exception is a scope decision, and a scope decision is the kind of thing that has to be recorded at the time rather than reconstructed under pressure. That is the fourth artefact below.

The date that is already close

Article 50 applies from 2 August 2026 and was not moved by the AI Omnibus. The one piece of relief is narrow, and the European Commission states it plainly: a limited grace period is envisaged only for AI systems placed on the market before 2 August 2026 and only as regards the marking and detection obligation for AI-generated content in Article 50(2), and providers of such systems must comply with those obligations only as from 2 December 2026.

Three consequences follow for an assessment. First, a system placed on the market after 2 August 2026 has no relief at all and the duty is live today. Second, the relief that exists is tied to a fact about the system, its date of placing on the market, which means the evidence file needs that date recorded per system rather than per organisation. Third, the relief covers one paragraph only. The Article 50(1) interaction disclosure and the Article 50(4) deployer disclosures have been in application since August and are unaffected by it.

A note on the source text, because it changes how the article numbering should be read. On 25 September 2026 the European Commission AI Act Service Desk page for Article 50 carried a notice stating that the provision has been amended by the Digital Omnibus on AI and that the text displayed had not yet been updated to reflect those amendments. The description above is of the text as served, and this framework has not read an amended text of Article 50. The wider problem of an authoritative surface serving superseded text is set out on the regulatory desk in the note on unamended article text.

Why this duty is harder to evidence than the others

Consider what the evidence looks like for three obligations in this regime. For a risk management system, the evidence is a document describing a process, and the assessment question is whether the process described is the process run. For human oversight, the evidence is a design and a set of records showing people exercising it. Both are assessed by reading and by interviewing.

For marking, the evidence is a property of an output. It cannot be read off a policy, and an organisation can hold a complete and sincere set of documents describing a marking approach while shipping files that carry nothing. The gap does not open through negligence. It opens because outputs leave a system through more paths than anybody has listed: the main product surface, an export function, a public API, a batch job, a partner integration, an internal tool, a legacy endpoint that three customers still use. Marking is typically implemented on the path that was in front of the person who implemented it.

So the first question this framework asks is not about watermarking technology. It is: how many ways does content leave this system, who wrote that list, and when was it last checked against the routing configuration rather than against memory. An organisation that cannot answer within a day does not have a marking problem yet. It has an inventory problem, and the inventory is the prior artefact: see the AI asset inventory as the first evidence artefact.

The six artefacts

1. The output path map. Every route by which generated content leaves the system, with the marking status of each and the date the list was last reconciled against configuration. Partial coverage is not a failure in itself. Unrecorded partial coverage is, because it means nobody knows.

2. The marking specification. What is applied, to which content types, where it lives in the artefact, and what a recipient needs in order to read it. If more than one mechanism is used across content types, which is common because audio, image and text behave differently, each is specified separately. The specification states its own interoperability claim: who other than the provider can read this mark, and with what.

3. The robustness test record. A named set of transformations applied to marked outputs, with results. Recompression at stated quality levels, resizing, cropping, screenshotting, format conversion, and for text the ordinary operations of copying into another document and editing part of it. The value of this record is not a pass rate. It is the honest boundary: this survives that, and does not survive this. Article 50(2) sets a technical feasibility standard, and a documented boundary is how an organisation shows it engaged with feasibility rather than asserting it.

4. The exception coverage statement. For each output path not marked, which limb of the exception is relied on, who decided, on what date, and on what basis. An assistive editing function and a system that does not substantially alter the input data are defined categories, and a product feature can drift out of one of them through ordinary development. The statement is dated for that reason.

5. The deployer disclosure record. Where the organisation is a deployer rather than a provider, this replaces artefacts 1 to 4 and is addressed in the next section.

6. The statement of what was not tested. Every serious evidence file contains one, and its absence is itself a finding. Content types out of scope, transformations not attempted, paths not reconciled, versions not retested since a named release. This is the artefact that makes the other five readable by somebody who did not write them, and it is the one that most distinguishes an evidence file from a marketing claim.

A deployer evidences something else entirely

Article 50(2) does not address deployers. Two other paragraphs do. Under Article 50(3), deployers of an emotion recognition system or a biometric categorisation system inform the natural persons exposed to it of the operation of the system, and process personal data in accordance with the applicable data protection rules. Under Article 50(4), deployers of an AI system that generates or manipulates image, audio or video content constituting a deep fake disclose that the content has been artificially generated or manipulated, and deployers of a system that generates or manipulates text published with the purpose of informing the public on matters of public interest disclose that the text has been artificially generated or manipulated. The text limb carries its own exception where the AI-generated content has undergone a process of human review or editorial control and a natural or legal person holds editorial responsibility for the publication, and both limbs carry an exception for authorised law enforcement use. Article 50(4) also carries an exception for evidently artistic, creative, satirical, fictional or analogous work, where the disclosure is made in an appropriate manner that does not hamper the display or enjoyment of the work. Under Article 50(5) the information is provided in a clear and distinguishable manner at the latest at the time of the first interaction or exposure, and conforms with the applicable accessibility requirements. Deep fake is defined in Article 3(60).

None of that is a property of a file. All of it is a property of an interface and of a publishing process. The deployer's evidence is accordingly: a list of the surfaces where covered content is published, a screenshot or reference implementation of the disclosure as a person actually encounters it, the accessibility treatment of that disclosure, the editorial review process where the Article 50(4) text exception is relied on, and a record of who decides that a given piece of content is inside or outside scope. Where an organisation is both provider and deployer, which is the normal position for a company that builds a generative feature and also publishes with it, both sets are required and they are kept separately, because they answer to different paragraphs and would be disclosed to different parties.

What an assessment can and cannot say

This framework does not certify that a given piece of content is detectable. Nobody can. Detection depends on what a platform, a messaging application or a recipient's software does to a file after it leaves the system, and the provider controls none of it. An assessment that implied otherwise would be asserting a property of the world on the strength of a test run in a laboratory.

What an assessment states is bounded and checkable: that the output paths were enumerated and reconciled on a date, that marking is applied on the paths recorded as marked, that robustness was tested against a stated transformation set with stated results, that exceptions are attributed to a limb of the paragraph and to a person, and that the untested surface is written down. That is a statement about the organisation's control of its own outputs. It is what an underwriter, a procurement reviewer or a supervisory authority can do something with, and it is the same shape as the rest of this framework's evidence standard, set out in the trust and transparency dimension.

One further limit, recorded because the alternative is to imply a certainty that does not exist. Article 50(2) names no technology and no standard. It sets a functional test and refers to the generally acknowledged state of the art, which moves. The European Commission describes a Code of Practice on Transparency of AI-generated content as a voluntary practical tool to help providers and deployers of generative AI systems demonstrate compliance with the marking and labelling obligations. This framework has not read that code, does not describe its contents, and does not treat adherence to any named technical scheme as satisfying the paragraph. Where an organisation has adopted one, the assessment records which, and records that the choice is the organisation's own.

What to do in the ten weeks remaining

For a provider of a generative system placed on the market before 2 August 2026, the relief runs out on 2 December 2026, and the work that takes the time is not the marking. It is the enumeration. Reconciling output paths against routing configuration, deciding and recording which exceptions apply, and running a first robustness pass are each a matter of days. Discovering in December that an export endpoint was never in scope is a different kind of problem, because by then the duty has applied for a month and the record shows nobody looked.

For a deployer, the equivalent work is a publishing audit: which surfaces carry generated content, which of them fall inside Article 50(4), what the disclosure looks like at first exposure, and who is accountable for the editorial review where that exception is relied on.

For both, the same closing discipline applies as everywhere in this framework. A certificate is not a defence, and this framework does not present one as such. What an assessment does is force the evidence to exist, to be attributable to a version and a date, and to be tested for retrievability by somebody other than its author, before the first time it matters. How the same file is read downstream by an underwriter is covered at agentinsured.eu, on the documentation and insurance evidence chain, and the position of operators outside the Union is set out at agentliability.co, on Article 50 and non-EU operators.

Sources and basis