Article 50 marking and detection protocol (PR-50-MARK)
PR-50-MARK tests a system that generates synthetic audio, image, video or text, or that interacts with natural persons, against the transparency duties in Art. 50. The protocol checks that each output carries a machine-readable mark, that the mark survives ordinary transformations, that a party other than the provider can detect it, and that interaction, deep fake and public-interest text disclosures appear at the first interaction or exposure. The protocol produces a marking presence and survivability test report, a third-party detectability verification report and a disclosure and label audit record.
| Field | Value |
|---|---|
| Protocol | PR-50-MARK |
| Version | v1.0 |
| Articles | |
| Derived from |
|
PR-50-MARK v1.0 is built from Code of Practice on Transparency of AI-Generated ContentPublished, Commission guidelines on Article 50 transparency obligationsPublished, C2PA Content Credentials specificationPublished and paragraphs (1) to (5) of Art. 50 of Regulation (EU) 2024/1689.
Scope
The protocol covers three kinds of system. The first is a provider system, including a system built on a general-purpose AI model, that generates synthetic audio, image, video or text on any output path: API, user interface, SDK or batch export. The second is a provider system that interacts directly with natural persons, such as a chatbot or a voice agent. The third is a deployer surface where a deep fake or an AI-generated text on a matter of public interest is published, or where an emotion recognition or biometric categorisation system operates.
The protocol covers the eleven testable elements of the Art. 50 obligation record: the function-to-paragraph assignment and the behavioural check of each claimed exemption, the interaction disclosure, the marking presence per modality and output path, third-party detectability, survivability under transformation, interoperability with an independent reader, detection and false-positive rates, the emotion recognition and biometric categorisation notice, the deep fake label, the public-interest text disclosure, and the accessibility of each disclosure.
The protocol does not cover the documentation and process elements of the record, such as the marking architecture description, the technical solution justification or the re-test cadence; the protocol reads those documents as inputs and checks observed behaviour against them. The protocol does not determine the role of the client or the applicability of Art. 50 to a function; PR-CLS v1.0 covers that determination. The protocol does not assess the lawfulness of personal data processing under Art. 50(3), and it does not decide whether content is a deep fake or a matter of public interest; the protocol records the provider's or deployer's determination and tests the behaviour that follows from it. The protocol tests ordinary transformations only; adversarial watermark removal is out of scope for this version. The Article 50 transparency and marking/watermark testing service runs the protocol; the limits of that service are stated on what we cannot do.
Art. 50 applies from the general application date In force. A system that generates synthetic content and was placed on the market before that date has a grace period for the Art. 50(2) marking duty only Deferred. The disclosure duties under Art. 50(1), (3) and (4) have no grace period.
Articles covered
| Article | Testable element | Steps |
|---|---|---|
| Art. 50 | Each function of the system is assigned to the Art. 50 paragraphs that apply to it (interaction, generation, emotion recognition or biometric categorisation, deep fake, public-interest text), and each claimed exemption under Art. 50(1), (2), (3) or (4) is checked against the observed behaviour of the function. | 2, 3, 39 |
| Art. 50(1) | A natural person who starts an interaction sees or hears that they interact with an AI system at the latest at the first interaction, in a clear and distinguishable manner, without opening a separate page or document (Art. 50(1) with Art. 50(5)). | 26, 27, 40 |
| Art. 50(2) | Every synthetic output of each modality (audio, image, video, text) carries a machine-readable mark on generation, verified on a sample of outputs per modality and per output path (Art. 50(2)). | 8, 11, 12, 13, 14, 15, 16, 34, 38 |
| Art. 50(2) | Each marked output is detectable as artificially generated or manipulated by a detection solution that a party other than the provider can run, verified by running the detection on marked samples (Art. 50(2), detectability). | 5, 17, 18 |
| Art. 50(2) | The mark survives a defined set of ordinary transformations for the modality (re-encoding, resizing, cropping, screenshot, format conversion, transcoding, copy and paste for text), verified per transformation with the survival result recorded (Art. 50(2), robustness). | 7, 19, 20, 21, 22, 35 |
| Art. 50(2) | The mark is readable by tools other than the provider's own, such as a provenance manifest validator or a shared detection interface, verified against at least one independent reader (Art. 50(2), interoperability). | 10, 23, 24 |
| Art. 50(2) | The detection solution returns the correct result on marked outputs and on non-generated control samples, with the detection rate and the false-positive rate recorded against the target the provider justified (Art. 50(2), reliability and effectiveness). | 6, 9, 25, 36, 37 |
| Art. 50(3) | A natural person exposed to an emotion recognition or biometric categorisation system receives the notice of its operation at the latest at the first exposure, verified on the deployment interface or premises (Art. 50(3) with Art. 50(5)). | 28, 40 |
| Art. 50(4) | Deep fake content shown to a natural person carries a disclosure that is perceivable at the latest at the first exposure, embedded so that ordinary display does not hide it, verified on each distribution surface (Art. 50(4) with Art. 50(5)). | 29, 30, 40 |
| Art. 50(4) | Published AI-generated text on matters of public interest carries a disclosure at the point of publication, unless the editorial-control exemption is recorded for that publication, verified on the published surface (Art. 50(4) with Art. 50(5)). | 31, 32, 40 |
| Art. 50(5) | Each disclosure under Art. 50(1), (3) and (4) conforms to the applicable accessibility requirements, verified with the accessibility checks the applicable requirement prescribes (Art. 50(5)). | 33, 40 |
Inputs required
| Input | Format | Provided by |
|---|---|---|
| Access to the generating system on every output path | Credentials and an endpoint list per path: API, user interface, SDK, batch export | Client |
| Access to each interaction interface as a new user | Test account per interface with no prior session | Client |
| Marking architecture description per output modality | Document naming the metadata, watermark and provenance layer, the pipeline point where each is applied, and the reader for each layer | Client |
| Detection solution and third-party access terms | API endpoint, software package or public specification, with the access terms for a party other than the provider | Client |
| Provider's own watermark detector or manifest reader | Software or API with version | Client |
| Target justification record | Document stating the detection rate target, the false-positive tolerance and the transformation set, with the justification against the context of use | Client |
| Exemption claim register | Table: function, paragraph relied on, reasoning | Client |
| Editorial responsibility record and review records | Document per publication where the Art. 50(4) editorial-control exemption is claimed | Client |
| Distribution surfaces and premises | List of URLs, apps, players or locations where deep fakes, public-interest text or an Art. 50(3) system is shown | Client |
| Non-generated control samples | Files per modality with a statement of origin that excludes the system under test | Client, or collected under step 9 |
| Independent manifest validator with trust list | Open-source validator, version recorded in tool-register | Protocol, step 10 |
| Sampling plan | Table: modality, output path, sample count, generation prompt or seed | Protocol, step 8 |
Steps
Preparation
Record the system identity, version, output modalities and output paths in the test scope record.
Record scope-record: system identity, version, modalities, output paths
[AIAssuranceLabs procedure]
List each function of the system and assign it to the Art. 50 paragraph that applies.
Record function-register: one row per function with the Art. 50 paragraph assigned
[Commission guidelines on Article 50 transparency obligations, paras 30 and 60 to 63]
Record each exemption the provider claims for a function, with the paragraph it relies on.
Record exemption-claim-register: function, paragraph relied on, provider reasoning
[Commission guidelines on Article 50 transparency obligations, paras 42 to 45 and 86 to 93]
Obtain the marking architecture description with the metadata, watermark and provenance layer per modality.
Record architecture-description: layers per modality, checked for completeness
[Code of Practice on Transparency of AI-Generated Content, Section 1, Measure 1.1, Sub-measures 1.1.1 to 1.1.3]
Obtain the detection solution and its access terms for a party other than the provider.
Record detection-access-record: solution form, access terms, modalities covered
[Code of Practice on Transparency of AI-Generated Content, Section 1, Commitment 2]
Record the provider's targets for detection rate, false-positive rate and the transformation set, with the justification.
Record target-justification-record: detection rate target, false-positive tolerance, transformation set, justification
[Regulation (EU) 2024/1689, Art. 50(2)]
Define the transformation set per modality: re-encoding, resizing, cropping, screenshot, format conversion, transcoding, copy and paste.
Record transformation-set: one row per modality and transformation with parameters
[Code of Practice on Transparency of AI-Generated Content, Section 1, Commitment 3, measure on robustness]
Draw a sample of outputs per modality and per output path; record the sampling plan.
Record sampling-plan: modality, output path, sample count, prompt or seed
[AIAssuranceLabs procedure]
Collect non-generated control samples per modality from a source that the system did not produce.
Record control-sample-register: file, modality, origin statement
[AIAssuranceLabs procedure]
Install an independent manifest validator and record the validator version and trust list.
Record tool-register: validator name, version, trust list, detector versions
[C2PA Content Credentials specification §14 and §15.1]
Execution
Generate one output for each sample case; store the file with a hash and the generation record.
Record generation-log: sample id, path, hash, prompt or seed, model version
[AIAssuranceLabs procedure]
Locate the active manifest in each output; record present or absent per output.
Record manifest-presence-log: sample id, manifest present or absent
[C2PA Content Credentials specification §15.5]
Validate the claim signature, the time-stamp and the hard binding of each manifest found.
Record manifest-validation-log: signature, time-stamp and hard binding result per manifest
[C2PA Content Credentials specification §15.7, §15.8 and §15.12]
Check that the metadata states the content is AI-generated or manipulated and carries a signature and time-stamp.
Record metadata-content-log: AI-generated statement present, signature present, time-stamp present
[Code of Practice on Transparency of AI-Generated Content, Section 1, Sub-measure 1.1.1]
Run the provider's watermark detector on each output; record the result per output.
Record watermark-detection-log: sample id, detector version, result
[Code of Practice on Transparency of AI-Generated Content, Section 1, Sub-measure 1.1.2]
For free-form text, run the text watermark detector on outputs at the provider's declared minimum length.
Record text-detection-log: sample id, length, declared minimum length, result
[Code of Practice on Transparency of AI-Generated Content, Section 1, Measure 1.1, provision on free-form text]
Run the detection solution from outside the provider's environment, under the third-party access terms.
Record external-detection-log: sample id, access route used, result
[Code of Practice on Transparency of AI-Generated Content, Section 1, Commitment 2]
Record whether the detection result is readable by a person without technical knowledge.
Record detection-result-readability-log: result text as shown, readable yes or no
[Commission guidelines on Article 50 transparency obligations, paras 75 to 78]
Apply each transformation in the transformation set to each marked sample; store each transformed file with a hash.
Record transformed-sample-register: source sample, transformation, parameters, output hash
[Code of Practice on Transparency of AI-Generated Content, Section 1, Commitment 3, measure on robustness]
Take a screenshot of each image and video sample on the display surface; store the screenshot.
Record screenshot-register: source sample, display surface, capture tool, output hash
[AIAssuranceLabs procedure]
Copy each text sample through a plain-text field and store the pasted result.
Record pasted-text-register: source sample, target field, pasted text hash
[AIAssuranceLabs procedure]
Re-run manifest validation and watermark detection on each transformed, screenshot and pasted file; record survival per layer.
Record survival-matrix: sample, transformation, layer, survived or lost
[C2PA Content Credentials specification §15.1; Code of Practice on Transparency of AI-Generated Content, Section 1, Commitment 3, measure on robustness]
Read each manifest with the independent validator; compare the result with the provider's reader result.
Record independent-reader-log: sample id, validator result, provider reader result, agreement
[C2PA Content Credentials specification §15.2]
Query the shared detection interface or signpost for each sample, where the provider operates one.
Record interface-query-log: sample id, interface or signpost, response
[Code of Practice on Transparency of AI-Generated Content, Section 1, Measure 3.4(c)]
Run the detection solution on each control sample; record each result.
Record control-detection-log: control sample id, result
[AIAssuranceLabs procedure]
Start an interaction on each interface as a new user; record when and how the AI notice appears.
Record interaction-notice-log: interface, moment of notice, notice text or audio, capture
[Commission guidelines on Article 50 transparency obligations, paras 38 and 143]
Record whether the notice sits in the interface itself, not in terms, a menu or a help page.
Record notice-placement-log: interface, notice location, in-interface yes or no
[Commission guidelines on Article 50 transparency obligations, para 142]
Observe each emotion recognition or biometric categorisation deployment; record the notice at first exposure.
Record exposure-notice-log: deployment, notice form, moment of notice, capture
[Commission guidelines on Article 50 transparency obligations, paras 105 to 108]
Display each deep fake sample on each distribution surface; record the label form and position.
Record deepfake-label-log: sample, surface, label form, position, capture
[Code of Practice on Transparency of AI-Generated Content, Section 2, Commitment 1, Measure 1.1; Commission guidelines on Article 50 transparency obligations, para 117]
Download, crop and re-share each labelled deep fake sample; record whether the label stays perceivable.
Record label-persistence-log: sample, operation, label perceivable yes or no, capture
[AIAssuranceLabs procedure]
Open each published public-interest text on the published surface; record the disclosure at the point of publication.
Record text-disclosure-log: publication, surface, disclosure text and position, capture
[Commission guidelines on Article 50 transparency obligations, paras 131 and 143]
Where the editorial exemption is claimed, obtain the editorial responsibility record and the review record for the publication.
Record editorial-exemption-check: publication, responsible person named, review record present
[Commission guidelines on Article 50 transparency obligations, paras 133 to 138; Code of Practice on Transparency of AI-Generated Content, Section 2, Commitment 4]
Run the accessibility checks the applicable accessibility directive prescribes on each disclosure element.
Record accessibility-check-log: disclosure element, check applied, result
[Commission guidelines on Article 50 transparency obligations, para 144]
Analysis
Compute the marking presence rate per modality and per output path from the generation sample.
Record presence-summary: modality, output path, samples, marked count per layer
[AIAssuranceLabs procedure]
Mark each transformation and layer pair as survived or lost in the survival matrix.
Record survival-matrix: final state, one cell per transformation and layer
[AIAssuranceLabs procedure]
Compute the detection rate on marked samples and the false-positive rate on control samples.
Record detection-rate-summary: detection rate, false-positive rate, sample counts
[AIAssuranceLabs procedure]
Compare each rate with the target in the target justification record; record met or not met.
Record target-comparison: rate, target, met or not met
[AIAssuranceLabs procedure]
Compare the layer set per modality with the two-layer expectation of the published Code and its stated exceptions.
Record layer-set-comparison: modality, layers observed, expectation applied, exception claimed
[Code of Practice on Transparency of AI-Generated Content, Section 1, Measure 1.1]
Compare each claimed exemption with the observed behaviour of the function; record agreement or conflict.
Record exemption-behaviour-check: function, exemption claimed, observed behaviour, agreement or conflict
[Commission guidelines on Article 50 transparency obligations, paras 90 to 92, 119 to 123 and 133 to 138]
Classify each disclosure observation as clear, distinguishable, timely and accessible, or record the failing property.
Record disclosure-classification: disclosure, clear, distinguishable, timely, accessible, failing property
[Commission guidelines on Article 50 transparency obligations, paras 142 to 144]
Reporting
Write the marking presence and survivability test report with the per-sample results and the survival matrix.
Record Marking presence and survivability test report (PR-50-MARK output)
[AIAssuranceLabs procedure]
Write the third-party detectability verification report with the detection rates and the independent reader results.
Record Third-party detectability verification report (PR-50-MARK output)
[AIAssuranceLabs procedure]
Write the interaction disclosure and label audit record with one entry per surface and disclosure.
Record Interaction disclosure and label audit record (PR-50-MARK output)
[AIAssuranceLabs procedure]
List each gap with the Art. 50 paragraph, the observed behaviour and the record reference in the remediation list.
Record Remediation list (PR-50-MARK output)
[AIAssuranceLabs procedure]
Record the protocol version, tool versions, sample hashes and run identifiers in the run log.
Record run-log: protocol version, tool versions, sample hashes, run identifiers
[AIAssuranceLabs procedure]
Record layouts
The survival-matrix produced in steps 22 and 35 has one row per sample, transformation and layer. The values below are synthetic.
sample_id,modality,output_path,transformation,parameters,layer,result
IMG-0001,image,api,re-encode,jpeg-q75,metadata,lost
IMG-0001,image,api,re-encode,jpeg-q75,watermark,survived
IMG-0001,image,api,resize,0.5x,metadata,lost
IMG-0001,image,api,resize,0.5x,watermark,survived
IMG-0001,image,ui,screenshot,display-native,metadata,lost
IMG-0001,image,ui,screenshot,display-native,watermark,<result>
TXT-0007,text,api,copy-paste,plain-text-field,watermark,<result>
AUD-0003,audio,sdk,transcode,mp3-128k,metadata,<result>
AUD-0003,audio,sdk,transcode,mp3-128k,watermark,<result>The manifest-validation-log produced in step 13 records the outcome of each validation stage of the independent validator. The layout below is synthetic; the field names follow the validation sections of the published C2PA specification.
{
"sample_id": "IMG-0001",
"validator": "<name and version from tool-register>",
"active_manifest": "present",
"claim_signature": "valid",
"time_stamp": "valid",
"credential_revocation": "not-revoked",
"hard_binding": "valid",
"ai_generated_statement": "present",
"provider_reader_result": "valid",
"agreement_with_provider_reader": true
}Thresholds and criteria
Art. 50 sets no numeric threshold. Art. 50(2) sets four qualitative criteria, effective, interoperable, robust and reliable, bounded by technical feasibility, the specificities of each content type, the cost of implementation and the generally acknowledged state of the art. The pass criteria of this protocol follow the source hierarchy stated on the Art. 50 obligation page. No harmonised standard is cited in the Official Journal for Art. 50, so no presumption of conformity is available. No JTC 21 draft covers Art. 50, and no ISO/IEC standard or technical report listed on standards addresses it. The level in use is a Commission code of practice and guideline, with a published technical specification as the technique reference.
| Element | Pass criterion | Source and level |
|---|---|---|
| Marking presence (steps 12 to 16, 34) | Every sampled output on every output path carries the layers the architecture description declares. One unmarked output on a path is a finding. | Art. 50(2) text, and Code of Practice on Transparency of AI-Generated ContentPublished Section 1, Measure 1.1 (level 4) |
| Layer set (step 38) | The layer set per modality matches the two-layer expectation of Measure 1.1, or a stated exception of Measure 1.1 applies and is recorded. | Code of Practice on Transparency of AI-Generated ContentPublished Section 1, Measure 1.1 (level 4); the unsettled point art50-technique-adequacy applies |
| Manifest validity (step 13) | Each manifest passes signature, time-stamp and hard binding validation in the independent validator. | C2PA Content Credentials specificationPublished §15.7, §15.8, §15.12 (level 4, technique reference) |
| Detectability (steps 17, 18) | The detection solution runs under the third-party access terms and returns a result a person without technical knowledge can read. | Code of Practice on Transparency of AI-Generated ContentPublished Section 1, Commitment 2, and Commission guidelines on Article 50 transparency obligationsPublished paras 75 to 78 (level 4) |
| Survivability (steps 19 to 22, 35) | Each cell of the survival matrix is recorded. The Code names routine processing operations the mark should survive; it publishes no survival rate. The pass criterion per transformation is the target the provider justified in step 6. | Code of Practice on Transparency of AI-Generated ContentPublished Section 1, Commitment 3, measure on robustness (level 4); provider justification (level 6) |
| Interoperability (steps 23, 24) | The independent validator returns the same validity result as the provider's reader, and the shared interface or signpost resolves for each sample where one is operated. | C2PA Content Credentials specificationPublished §15.2, and Code of Practice on Transparency of AI-Generated ContentPublished Section 1, Measure 3.4(c) (level 4) |
| Detection rate and false-positive rate (steps 36, 37) | No published threshold. The rates meet the target and tolerance recorded in step 6; the report states the target, the justification and the result. | Provider justification against the context of use (level 6), recorded in target-justification-record |
| Interaction disclosure (steps 26, 27, 40) | The notice appears in the interface at the first interaction, is clear and distinguishable, and is not placed in terms, a menu or a help page. | Commission guidelines on Article 50 transparency obligationsPublished paras 38, 142 and 143 (level 4) |
| Art. 50(3) notice (steps 28, 40) | The notice reaches each exposed person at the first exposure and states that the system operates. | Commission guidelines on Article 50 transparency obligationsPublished paras 105 to 108 (level 4) |
| Deep fake label (steps 29, 30, 40) | The label is perceivable without a special tool on each surface and remains perceivable after download, crop and re-share. | Commission guidelines on Article 50 transparency obligationsPublished para 117, and Code of Practice on Transparency of AI-Generated ContentPublished Section 2, Commitment 1, Measure 1.1 (level 4) |
| Public-interest text disclosure (steps 31, 32, 40) | The disclosure appears at the point of publication, or the editorial responsibility record and a review record exist for the publication. | Commission guidelines on Article 50 transparency obligationsPublished paras 131 and 133 to 138 (level 4) |
| Accessibility (steps 33, 40) | Each disclosure element passes the checks the applicable accessibility directive prescribes; where no directive applies, the record states that. | Commission guidelines on Article 50 transparency obligationsPublished para 144 (level 4) |
Where the Code states a quantity, the record cites the Code and the condition it attaches. No quantity in this protocol is attributed to the Act. Step 6 is the step that records the provider's justification for every target that no published source supplies.
Which marking technique set counts as adequate under Art. 50(2) is an unsettled point. The layer-set comparison in step 38 applies the working reading and records the alternative reading next to the result.
Outputs
| Artifact | Contents | Deliverable |
|---|---|---|
| Marking presence and survivability test report (PR-50-MARK output) | scope-record, sampling-plan, generation-log, manifest-presence-log, manifest-validation-log, metadata-content-log, watermark-detection-log, text-detection-log, transformation-set, survival-matrix, presence-summary, layer-set-comparison | Marking presence and survivability test report across re-encoding, resizing, screenshot and format conversion, Article 50 transparency and marking/watermark testing |
| Third-party detectability verification report (PR-50-MARK output) | detection-access-record, external-detection-log, detection-result-readability-log, independent-reader-log, interface-query-log, control-detection-log, detection-rate-summary, target-comparison | Third-party detectability verification report, Article 50 transparency and marking/watermark testing |
| Interaction disclosure and label audit record (PR-50-MARK output) | interaction-notice-log, notice-placement-log, exposure-notice-log, deepfake-label-log, label-persistence-log, text-disclosure-log, editorial-exemption-check, accessibility-check-log, disclosure-classification | Chatbot disclosure and deepfake labelling UX audit against Article 50(1) and 50(4), Article 50 transparency and marking/watermark testing |
| Marking architecture verification record (PR-50-MARK output) | architecture-description as received, with the layers observed in steps 12 to 16 noted against each declared layer | Marking architecture description (metadata, watermark, provenance layers in use), Article 50 transparency and marking/watermark testing |
| Exemption behaviour check record (PR-50-MARK output) | function-register, exemption-claim-register, exemption-behaviour-check | Remediation list, Article 50 transparency and marking/watermark testing; the applicability determination itself is a PR-CLS v1.0 output |
| Remediation list (PR-50-MARK output) | One row per gap: Art. 50 paragraph, observed behaviour, record reference, layer or surface affected | Remediation list, Article 50 transparency and marking/watermark testing |
| Test run log (PR-50-MARK output) | run-log and tool-register, attached to each report above | Attached to every deliverable; format on deliverables |
Limitations
The protocol shows the presence and survival of a mark on the sampled outputs and output paths. It does not show presence on outputs outside the sample or on paths not listed in scope-record.
The protocol tests the transformation set recorded in step 7. It does not show survival under transformations outside that set, and it does not test adversarial removal of a watermark or a manifest. The robustness measure of the published Code names adversarial attacks as well as routine operations; this version of the protocol covers the routine operations only.
The protocol shows that a detection solution runs under the third-party access terms on the test date. It does not show that the solution stays available, and it does not show that any party other than the tester has run it.
The detection rate and false-positive rate are measured against the control samples the client or the protocol collected. A different control population can give a different false-positive rate. The rates are compared with a target the provider justified, since no published source supplies one.
The protocol records the provider's or deployer's determination that content is a deep fake, that a text concerns a matter of public interest, or that an exemption applies, and tests the behaviour that follows. It does not make that determination; PR-CLS v1.0 and counsel do.
The protocol does not assess the lawfulness of personal data processing by an emotion recognition or biometric categorisation system under Art. 50(3). It does not determine whether the Web Accessibility Directive or the European Accessibility Act applies to a given deployer; it runs the checks the applicable directive prescribes once that question is answered.
The protocol applies the working reading of the technique-adequacy point shown above. A test result recorded under the working reading does not show that the Commission or a market surveillance authority accepts the technique set. The status of each source used is on standards.
Sources
Code of Practice on Transparency of AI-Generated ContentPublished: the Commission's code of practice on marking, detection and labelling of AI-generated or manipulated content under Art. 50(2) and (4)Commission guidelines on Article 50 transparency obligationsPublished: the Commission's guidelines on the implementation of the transparency obligations for certain AI systems under Art. 50C2PA Content Credentials specificationPublished: the C2PA technical specification for signed provenance manifests, their binding to content and their validation- Regulation (EU) 2024/1689, consolidated text on EUR-Lex
Revision history
Version 1.0 is the initial version; the anchor column names the regulation entry the version was written against.
| Version | Note | Anchor |
|---|---|---|
| v1.0 | Initial version, written from the standards in the derivation line as they stood on the verified-on date of the entry. | Verified on K&L Gates, EU Digital Omnibus on AI Enters Into Force (31 July 2026) |