What Article 50(2) requires providers to mark in synthetic content
Article 50(2) requires the provider of an AI system that generates synthetic audio, image, video or text to mark those outputs in a machine-readable format, so that they can be detected as artificially generated or manipulated. The duty sits with the organization that builds or places the generator on the market, not with the person who prompts it, and it covers general-purpose AI systems as well as narrow tools. The risk it addresses is practical: a voice clone, a fabricated photograph or a machine-written news item can pass as human work, and once the content is copied and reposted, the trail back to the generator is usually lost. Marking is meant to keep a detectable signal attached to the output so that platforms, investigators and recipients can tell where it came from. The standard the regulation sets is that solutions must be effective, interoperable, robust and reliable as far as technically feasible. Each of those four words is a test an assessor will apply. Effective means the mark can actually be detected by the detection methods the provider documents. Interoperable means other parties can read the mark without relying on the provider's own tools. Robust and reliable mean the mark should survive ordinary handling and produce few false results. The qualifier "as far as technically feasible" leaves room for the state of the art, but it does not excuse a provider that has never tested its marks. The regulation also excludes assistive standard editing, such as spell checking or routine photo retouching, and systems that do not substantially alter the input or its meaning. Providers should document why their product falls inside or outside those exclusions before launch, because the exclusions are narrow and are read against what the system actually does. Marking is hard in mixed pipelines. A watermark embedded in pixels may weaken after resizing, recompression or cropping. Metadata is often stripped by social platforms, messaging apps and content management systems. A single output can also pass through several generators and editors, so the mark applied by one tool may be overwritten by the next. Organizations should confirm, with their own generator and the publishing channels they use, which marks survive which transformations, and record those test results as evidence. Where a product chains a third-party model with its own editing layer, the owner of each step needs a clear answer about who applies the mark. Teams should also decide early whether to combine a durable in-content watermark with signed provenance metadata, since each addresses a different failure.
Which systems, outputs and teams fall under the marking duty
Article 50(2) reaches providers of AI systems that generate synthetic audio, image, video or text, including general-purpose AI systems. Four cards below separate the scoping questions: which systems and outputs count, who is the provider, where the output is used, and which exclusions and timing rules apply.
Systems that generate synthetic content
The duty attaches to AI systems that generate synthetic audio, image, video or text. Inventory every system that produces these output types, including features inside products your teams did not build. Record the output modality for each system, because the same platform may generate text in one feature and images in another. A system that only classifies, ranks or summarizes existing content needs a separate check against the definitions before you assume it is in scope.
General-purpose AI systems
Article 50(2) names general-purpose AI systems expressly, so a general chat or image tool offered for many uses is not excused because its use case is broad. Check whether your self-hosted model is only one component of a larger system you offer to others. The system that users interact with, and that returns the generated output, is the one whose marking you must evaluate. Confirm with counsel where the boundary falls for your architecture.
EU establishment and EU output use
The obligation follows the market and the output, not only the company's address. Providers established in the EU are in scope, and so are non-EU providers whose generated output is used in the EU. Map where outputs are delivered, including API customers and end users in member states. A US or Asian team that serves EU users through an API should treat the duty as applicable unless counsel confirms otherwise.
Provider roles and downstream changes
Who must mark output depends on who places the system on the market. An API reseller, a team that fine-tunes a third-party model, or a product team that embeds a generation feature may become the provider under the Act's role definitions. Ask in writing which party controls the model, the system and the brand under which users receive output. Those answers decide which contract, technical marking and evidence files sit with each party.
Assistive editing and substantial alteration
The duty does not apply to assistive standard editing, or to systems that do not substantially alter the input or its meaning. Spellcheck, grammar suggestions, color correction and similar tools may fall outside the duty, but a system that rewrites a document, regenerates an image or changes a voice recording may fall inside it. Document each feature's test against the statutory wording, and record the reasoning so an assessor can follow it. Treat borderline features as in scope until the reasoning is reviewed.
Outputs generated before 2 August 2026
The Commission's FAQ says outputs generated and made available before 2 August 2026 need no retroactive marking. Systems placed on the market before that date have until 2 December 2026 to comply under Article 111(4). Tag output records with generation dates so you can show which outputs predate the obligation. Confirm how your systems treat outputs regenerated, edited or reissued after the cut-off, since those may be new outputs.
How the December 2026 grace period for existing systems works
The grace period is a transition rule for systems already on the market, and it does not switch off Article 50(2) for anything new. Article 50(2) applies from 2 August 2026. Under Article 111(4), providers of AI systems placed on the market before 2 August 2026 have until 2 December 2026 to comply. The dividing line is the placing on the market date of the system, not the date a given output was created. Teams should therefore sort their portfolio into two groups: systems first placed on the market before 2 August 2026, which have until 2 December 2026, and systems placed on the market on or after that date, which must mark their outputs from the start.
The grace period covers the system, but the Commission's FAQ makes clear that output timing still matters. Per the Commission FAQ, outputs generated and made available before 2 August 2026 need no retroactive marking. For a pre-existing system, the practical question is which outputs it generates and makes available after 2 August 2026, and whether those must carry machine-readable marks by 2 December 2026 at the latest. Providers should record the date each system was first placed on the market and confirm with counsel how that date should be evidenced, since the answer determines which deadline applies to each product line.
Signing the code of practice is one route to demonstrating compliance, not a requirement. The Commission FAQ states that non-signatories must demonstrate compliance by other adequate means and may face more information requests. A provider that does not sign should plan to document its own marking method, its detection tests and its interoperability choices, and to produce that evidence on request. Whichever route is chosen, confirm the status of each of your systems, including the placing on the market date and any substantial changes since, with qualified counsel before relying on the December 2026 date.
How to implement machine-readable marking in a generation pipeline
This sequence takes a provider from an inventory of generative outputs to a documented, tested marking design that runs before any synthetic audio, image, video or text leaves the system. Each step closes with a named record so an assessor or the Commission can trace how the marking decisions were reached.
Inventory generative outputs and modalities
Engineering and product owners list every path in which the system generates audio, image, video or text, including outputs produced by general-purpose models the provider builds on. For each path, record the modality, the output format, the delivery channel and whether the output is shown to, or downloaded by, people outside the organization. The step closes with a modality register that names each output path and its owner. Confirm the list against code and API routes, not product documentation alone, because undocumented endpoints are a common gap.
Classify each path against the exclusions
For each entry in the modality register, legal or compliance staff with engineering input decide whether the marking duty applies. Article 50(2) excludes assistive standard editing and systems that do not substantially alter the input or its semantics, so each exclusion claim needs a written rationale tied to what the system actually does to its input. Record the outcome as a scoping decision per path, with the reviewer and date. Paths that remain in scope move to marking design. Paths excluded on a rationale should be re-reviewed when the feature changes.
Select marking methods per modality
Engineers choose one or more marking methods for each in-scope modality, such as metadata fields, an embedded watermark, a provenance manifest that binds the asset to its generation record, or logging of each output with a retrievable identifier. Text, images, audio and video behave differently under editing and compression, so a single method rarely fits all modalities. Document why each method was chosen, which modalities it covers and what it cannot survive. The step closes with a marking design record that maps each modality to its methods and open limitations.
Integrate marking at the generation step
Platform engineers add the marking routine to the generation service so that it runs before an output is returned, stored for delivery or sent to a client. Marking placed only in a downstream export job leaves outputs unmarked on other paths. Logging of generation events should capture output identifiers, model version and timestamp, which supports later verification. Test that every delivery channel in the register receives marked output. The step closes with a configuration record and a code review that shows marking cannot be bypassed by a feature flag or alternate endpoint.
Build a detection and verification check
Engineers build a verification service or script that reads the marks back from a sample of outputs and reports whether each output is detectable as artificially generated. Article 50(2) asks for solutions that are detectable, so the check must confirm detection, not only that a field was written. Store verification results alongside generation logs. The step closes with a verification specification and a passing run on a representative sample of each modality, with failures logged and triaged.
Test robustness against editing and format conversion
The test team applies common transformations to marked samples, such as resizing, recompression, format conversion, cropping, re-encoding, screenshotting and text copy-paste, then re-runs detection. Marking is expected to be robust and reliable as far as technically feasible, so results should show which transformations defeat which methods. Where a method fails, the team documents the limit, adds a complementary method or narrows the claim. Adversarial removal attempts can be run through the security testing team. The step closes with a test report listing transformations, detection outcomes and accepted residual limits.
Document decisions and keep the evidence trail
The compliance lead assembles the marking design record, scoping decisions, configuration records, verification results and test report into one controlled document set, with version numbers and owners. The file should also record how the provider handles outputs created before 2 August 2026, and whether the provider has signed the code of practice or will demonstrate compliance by other adequate means. Confirm the retention period with counsel. The step closes when an independent reviewer can trace each in-scope modality from register entry to passing test. An external auditor or the relevant authority assesses this evidence; the organization and its implementation partner only prepare it.
What an assessor checks for Article 50(2)
A market surveillance or compliance reviewer starts with paper. They want to see how the provider decided what counts as synthetic output, which marking method applies to each modality, and why that method is effective, interoperable, robust and reliable as far as technically feasible. They also check whether the provider has documented the exclusions in Article 50(2), such as assistive standard editing and systems that do not substantially alter the input or its semantics, and whether the exclusion reasoning holds up against the actual product behavior.
- Modality coverage: a marking design for every output type the system generates, covering audio, image, video and text, with the reason for each method.
- Exclusion analysis: a written record showing why any output falls outside the duty, tied to the system's actual behavior.
- Architecture description: where marking happens in the pipeline, whether it is applied at generation, and what happens when outputs are exported or passed to downstream services.
- Standards mapping: the technical standard or specification the provider relies on, with the version and the reasons it was selected.
- Typical finding: marking is described for images and text, but the audio and video paths were added later and are not covered by the document.
Check that every claim in the design document can be traced to a configuration, code path or test result that the reviewer can inspect.
A technical tester runs the marking through the system and then tries to remove it or defeat detection. The test approach is to generate outputs across each modality, pass them through common transformations, and run the detection method on the results. The tester records whether the mark survives, whether detection returns a correct result, and how often it produces false positives on human-made content. Results are compared against the provider's own stated robustness claims.
- Baseline trials: generated outputs checked immediately after creation, with detection results logged for each modality.
- Common edits: compression, resizing, cropping, format conversion, re-encoding, screenshotting and, for text, paraphrasing or light rewriting.
- Export paths: outputs downloaded through the user interface, the API and any batch or integration route.
- Evidence requested: test scripts, input sets, raw detection logs and a summary that states pass and fail counts per modality.
- Typical finding: the mark survives a single re-encode but is lost after a screenshot or a second platform upload, and the provider has not documented that limit.
Illustrative only: a text watermark that holds through copy-paste but disappears after a sentence-level rewrite would need to be disclosed as a limit, not presented as robust.
The third reviewer checks timing and status. Article 50(2) applies from 2 August 2026, but providers of systems placed on the market before that date have until 2 December 2026 under Article 111(4). The reviewer confirms which systems fall into that group, when each was placed on the market, and whether outputs generated before 2 August 2026 are treated as outside retroactive marking, as the Commission's FAQ describes. The reviewer also checks whether the provider has signed the Code of Practice on Transparency of AI-generated Content, which the Commission published on 10 June 2026, or has chosen another way to demonstrate compliance.
- Placement dates: a dated inventory showing when each system or version was placed on the market.
- Grace period record: the date each system was assessed against the 2 December 2026 deadline, with the reasoning.
- Signatory status: a written record of whether the provider signed the code, and if not, the alternative means of demonstrating compliance.
- Information requests: a log of any Commission or authority requests and the responses sent.
- Typical finding: no record of signatory status, so the provider cannot show which route it relies on.
Confirm the current signatory position and any later implementing act under Article 50(7) with the Commission and your counsel before relying on either.
Evidence that shows marking works and stays current
Article 50(2) compliance is shown by a file of records, not by a single test. The cards below cover the artifacts an assessor or market surveillance authority will ask for, and they connect because each one must stay consistent with the marking design and the systems that produce the outputs.
Modality and output register
Keep a register listing every system that generates synthetic audio, image, video or text, the modality of each output, the release in which it first shipped, and whether it was placed on the market before 2 August 2026. That last field decides whether the 2 December 2026 grace period under Article 111(4) applies. Check that the register also covers general-purpose AI systems built on third-party models, since the duty reaches them too.
Marking design specification
Document which marking method applies to each modality, such as metadata, watermarking or provenance signals, and why it was chosen. Record how each method meets the Article 50(2) expectations that solutions be effective, interoperable, robust and reliable as far as technically feasible. Note the exclusions you rely on, such as assistive standard editing, and the reasoning that the system does not substantially alter the input.
Generation logs showing marks applied
Logs should tie each generated output to a marking event, with a timestamp, system version, modality and the mark or identifier written. Sample logs for each modality and confirm that marks survive the storage and export path. Gaps where an output left the system without a mark are the first finding an assessor will test, so alert on them rather than discover them during review.
Detection test results with edit and conversion cases
Keep test runs showing that a detector recovers the mark from unedited outputs and from outputs after common changes: cropping, recompression, format conversion, resizing, re-recording and light text paraphrasing. Record the pass rate, the failure cases and the fixes made. Results should be repeatable, so store the test inputs, tool versions and expected outcomes alongside the report.
Key and certificate management records
If marks depend on signing keys or certificates, keep records of key generation, storage, rotation, revocation and access. Automated issuance reduces manual steps, and the OpenBao PKI secrets engine issues dynamic X.509 certificates so services get them without hand-built key and CSR steps. Confirm that certificate lifetimes, revocation handling and the process for compromised keys are written down and tested.
Code of practice adherence or alternative compliance file
The Commission published the Code of Practice on Transparency of AI-generated Content on 10 June 2026, and its Section 1 covers marking and detection. Signatories should map their controls to that section. Non-signatories must show compliance by other adequate means and should expect more information requests, so keep a written file explaining the alternative approach and the evidence behind it.
Change records for model and marking updates
Every change to the generating model, the marking method, the detector or the signing configuration needs a record with the date, the reason, the test run repeated after the change and the approver. Keep the earlier marking design so you can show what outputs were marked and how. Refresh the modality register and detection tests whenever a model is swapped, since a new model can change output characteristics that affect detection.
How the Code of Practice on Transparency of AI-generated Content supports compliance
The Code of Practice on Transparency of AI-generated Content is the main route the Commission has prepared for showing that a provider meets Article 50(2). The Commission published it on 10 June 2026. Its Section 1 covers providers' marking and detection, which is the part a provider of a generative system needs to read first. In its opinion of 9 July 2026, the Commission found the code adequate for Article 50(2), (4) and (5). For a provider, that means the code's marking and detection measures are a credible benchmark to test an implementation against, though the provider still has to show that its own system meets the legal duty. The Commission's opinion on the code is the document to file with your compliance records.
Signing the code is voluntary, and the choice has practical consequences. A signatory can point to the code as a structured basis for its marking and detection approach. A non-signatory is not excluded from the Act, but it must demonstrate compliance by other adequate means and may receive more information requests from authorities, according to the Commission's FAQ on signing the code. Before deciding, confirm with your legal team which signatory obligations apply to your organization, and decide whether you can produce equivalent evidence of effective, interoperable and robust marking without the code's framework.
Amended Article 50(7) adds a fallback. If the Commission judges a code inadequate, it may adopt an implementing act setting common rules for the marking and labeling obligations. Because the code has been found adequate, that route is not in use today, but it means the requirements could change. Track the Commission's publications and keep your marking design documented in a way that can be re-mapped to any future common rules. Ask your marking vendor or integration partner to state which parts of the code's Section 1 they implement and which they do not, so that gaps are visible before an authority asks.
What meeting Article 50(2) costs in money and effort
This table lists the cost components of meeting Article 50(2), who is typically paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a quote request, since no price or duration for this work is published in the supplied sources and the real figure depends on your systems and scope.
| Cost component | One-time or recurring | Who is paid | What drives the cost |
|---|---|---|---|
| Marking method engineering | One-time, with updates on model or pipeline change | Internal engineers or an implementation partner building the marking step into generation pipelines | Number of output modalities (audio, image, video, text), number of generation pipelines, and how many systems are already live before 2 December 2026 |
| Detection tooling and interfaces | One-time build, recurring operation | Engineering time for detection checks, plus any licensed or self-hosted detection components you choose | Whether you offer detection to third parties, how many outputs must be checked, and whether detection runs inline or as a batch job |
| Testing and robustness work | Recurring, repeated with each model or marking change | Internal QA, security testers or an external testing provider probing whether marks survive common edits | Number of transformations tested (compression, cropping, re-encoding, paraphrase), frequency of model updates, and the target of an effective and robust solution |
| Evidence upkeep | Recurring | Internal compliance or engineering staff keeping test records, configuration history and logs | Volume of outputs logged, retention periods set by your own policy, and how many systems share one marking approach |
| Legal or code-of-practice review | One-time per system family, then periodic review | Internal legal counsel or outside counsel reviewing whether your approach follows the Code of Practice on Transparency of AI-generated Content | Whether you sign the code or demonstrate compliance by other adequate means, and how often the code or Commission guidance changes |
| Regulator information requests | Recurring when they occur | Internal staff preparing responses, with optional counsel support | Non-signatories may face more information requests, so documented evidence reduces the effort of each response |
| External assessment | Recurring if you commission one | Independent auditor or assessor you engage. Only an independent party issues reports or certificates | Scope of systems reviewed and whether the assessment is voluntary or required by a customer or contract. Ask each provider for a fixed scope and written deliverables |
Who owns marking, who can outsource it, and where the auditor stops
The provider remains legally responsible for Article 50(2). The organization that places the generative system on the market or puts it into service decides how outputs are marked, which marking techniques are used for each modality (audio, image, video and text), and whether it signs the Code of Practice on Transparency of AI-generated Content or demonstrates compliance by other adequate means. Those decisions belong to the provider and should be recorded with reasons, because an assessor or authority will ask why a given approach was chosen.
- Marking design: choosing the watermark, metadata or other machine-readable technique for each output type and accepting its limits.
- Signatory decision: deciding whether to sign the code, and what the non-signatory route would need to show.
- Scope calls: deciding whether assistive standard editing or systems that do not substantially alter the input fall outside the duty, and documenting that reasoning.
- Transition planning: tracking the 2 December 2026 grace period for systems placed on the market before 2 August 2026.
- Sign-off: approving the evidence pack before anyone external sees it.
Check that a named internal owner can explain every marking decision without the partner in the room.
An implementation partner can do the engineering and documentation work that the provider directs. DeployOpen, for example, prepares systems and evidence inside the client's own infrastructure, but it does not decide the legal position, choose the signatory route for the client, or issue any report. Work is usually agreed in a written, fixed scope that names the systems, modalities and deliverables covered.
- Pipeline integration: wiring the marking step into the generation path so every output passes through it.
- Test harnesses: building repeatable checks that confirm marks survive common edits and can be detected.
- Logging: capturing generation records so the provider can show which outputs were produced and when.
- Evidence packs: assembling configuration, test results and change records in a form the provider can review.
- Remediation support: fixing defects the tests expose, subject to the provider's sign-off.
Confirm in the scope who holds the decisions, who approves changes to the marking design, and who keeps the evidence after the engagement ends.
An independent assessor, auditor or market surveillance authority tests whether the provider's marking works and whether the evidence supports the claim. It can request documents, run its own checks and issue findings. It should not design the marking, because doing so would remove the independence that makes its findings useful to the provider and to regulators.
- Testing: checking whether outputs carry detectable marks and whether those marks meet the effectiveness and robustness expectations of Article 50(2).
- Document review: reading the provider's decisions, scope calls and evidence pack.
- Findings: reporting gaps, which the provider must then address.
- Information requests: for non-signatories, regulators may ask for more information more often, as the Commission's FAQ notes.
- Certification limits: only a certification body issues certificates, and no current fact in this page confirms that a certificate exists for Article 50(2).
Ask any assessor which parts of the work it will test itself and which it will accept from the provider's own records.
Some work can move to a partner, but the accountability and the decisions cannot. The line is usually drawn between execution, which can be outsourced, and judgment, which stays with the provider. Outsourcing an activity does not transfer the duty to comply.
- Usually outsourced: pipeline integration, test harness development, logging setup and evidence assembly.
- Usually kept in house: the legal reading of Article 50(2), the signatory decision and the acceptance of residual risk.
- Shared: technical testing, where the provider's team reviews partner results before relying on them.
- Ongoing: monitoring for changes to the code of practice, the Commission's opinion or any implementing act under amended Article 50(7).
- Contract terms: the written scope should state deliverables, owners and change control.
Before signing, ask the partner to list every deliverable and mark which ones the provider must approve personally.
Common gaps in AI content marking and how to close them
Most gaps in Article 50(2) programs come from treating marking as a final export step rather than a property of every generated output. The cards below cover where marking breaks down, how to detect it, and what to record, with a closing action for each.
Marking applied only at export
Some teams add a visible watermark or metadata tag when a user downloads a file, but outputs shown in the interface, returned through the API or cached for later use carry no marking. Article 50(2) expects outputs to be machine-readable as generated or manipulated wherever they leave the system. Check every output path, including streaming responses, batch jobs and stored drafts, and mark at the point of generation so no path skips it.
Metadata stripped downstream
Platforms that re-encode, resize, transcode or screenshot content often remove embedded metadata, which leaves a marked file looking unmarked. Test each marking method against the transformations your users and their distribution channels routinely apply. Where a single method is fragile, combine an embedded marker with a second signal that survives those transformations, and confirm the combination against the Code of Practice on Transparency of AI-generated Content.
No detection path
Marking only helps third parties if they can check it. Article 50(2) asks for outputs that are detectable, and the Code of Practice addresses detection as well as marking. Without a verification method, a marker is a claim no one can test. Decide how a reviewer, platform or regulator confirms that an output was generated, document the detector or verification service, and test it on known outputs before go-live.
Unmapped modalities
Teams often mark text and still-image output but miss generated audio, video frames or the audio track of a video. Each modality needs its own marking method, and a clip assembled from marked and unmarked segments can slip through. Build an inventory of every modality your systems produce, including outputs from third-party models you host, and record the marking method and test result for each one.
No record of pre-August 2026 outputs
Under the transitional rules, systems placed on the market before 2 August 2026 have until 2 December 2026 to comply, and outputs generated and made available before 2 August 2026 do not need retroactive marking. Teams still need to show which outputs predate the cut-off and which systems were already on the market. Keep a dated register of system versions, release dates and the first date each system made outputs available, so the transitional position can be proven.
Unclear signatory status
Signing the Code of Practice is voluntary, but the Commission's FAQ says non-signatories must demonstrate compliance by other adequate means and may face more information requests. Organizations often assume that signing ends the question, or that not signing means they are outside the duty. Decide and document the route you rely on, keep evidence of the marking and detection controls that support it, and confirm the position with your legal counsel and, where relevant, your national market surveillance authority.
Questions buyers ask about Article 50(2) marking
Does Article 50(2) apply to AI systems already on the market?
Yes, but with a transition period. Article 50(2) applies from 2 August 2026, and providers of systems placed on the market before that date have until 2 December 2026 to comply. The practical test is the placing-on-the-market date of each system and each significant release, so your team should record it per system. Whether a later version counts as a new placement is a legal question, so confirm the treatment with counsel before you plan around the older date. If your organization only deploys a third-party generator, the marking duty sits with that provider, so check what the contract commits the vendor to deliver and by when.
Do outputs generated before August 2026 need retroactive marking?
No. The Commission's FAQ states that outputs generated and made available before 2 August 2026 do not need retroactive marking. For engineering, this means the marking logic must apply to outputs generated from the relevant date onward, so you need a way to separate older outputs from newer ones. Keep generation timestamps, model versions and release identifiers in your logs so you can show which outputs fall under the new duty. If you decide not to sign the Code of Practice, the FAQ also notes that you must demonstrate compliance by other adequate means and may face more information requests, so keep this evidence ready. Read the Commission FAQ on signing the code for the exact wording.
What does the team need to build for machine-readable marking?
The team needs a marking method that is machine-readable, lets detectors identify content as artificially generated or manipulated, and is effective, interoperable and reliable as far as technically feasible. Typical work areas are:
- Mapping every generation path for audio, image, video and text, including fallback and batch jobs
- Choosing marking techniques for each modality and checking how they survive common transformations
- Building or wiring a detection check that can be run against sample outputs
- Writing down the exceptions you rely on, such as assistive standard editing or systems that do not substantially alter the input
You also need access to the output pipeline, change control for the marking code, and test records. Confirm each technical choice against the Act text and the Code of Practice before you commit to a design.
Can we implement AI content marking in-house?
Many teams can do the engineering in-house if they already own the generation pipeline and have people who understand each modality. The organization still owns the decision and the controls: it decides which marking approach to use, signs off the exceptions it relies on, and keeps the evidence. An implementation partner can prepare systems, pipelines and evidence under a written scope, but it does not issue audit reports or certificates. Only an independent auditor, assessor or certification body issues those. Tracing tools such as Langfuse record inputs, outputs, token usage and metadata for each request, which can help link an output to the model version and date that produced it. Whether that is enough for your system depends on your design, so test it against your own outputs.
What drives the cost and effort of Article 50(2) marking?
No public price or effort figure applies to this duty, so the answer depends on your estate. The main drivers are the number of modalities you generate, the number of generation paths and models, whether you run open-source models in your own infrastructure or call a vendor API, how mature your logging and release records are, and how much detection testing you need. Costs fall into internal engineering and legal time, tooling, and any partner fees. The build is largely one-time, while re-testing after model upgrades, monitoring new releases and keeping documentation current recur. To compare quotes, ask each provider for scope by modality and system, the deliverables, the timeline, the exclusions, and how retesting after upgrades is handled. DeployOpen agrees scope and deliverables in writing before work starts, and quotes follow from that scope.
Must we sign the Code of Practice on Transparency of AI-generated Content?
No. Signing is not mandatory under the Act. The Commission published the Code of Practice on Transparency of AI-generated Content on 10 June 2026, and its opinion of 9 July 2026 found the code adequate for Article 50(2), (4) and (5). Signing gives you a recognized route to show compliance with the marking duty. If you do not sign, the Commission's FAQ says you must demonstrate compliance by other adequate means and may face more information requests. In that case, document how each marking method meets the Article 50(2) requirements, test it, and keep the records. Under amended Article 50(7), the Commission can adopt an implementing act with common rules if it considers a code inadequate, so track any change to the code's status.
What will an auditor or regulator ask for to verify marking?
No certificate is issued for Article 50(2), and the national authorities that enforce the Act for AI systems decide what they request. Prepare for requests such as a description of the marking method for each modality, the date each system met the duty, detection test results, evidence of how the marking holds up under common changes, the exceptions you rely on, and your records of outputs generated before the transition date. Expect to show your signatory status or the alternative means you used. An independent assessor can review your readiness, but only an independent auditor or assessor issues a report, and an implementation partner prepares the evidence without issuing it. Confirm with counsel which authority is competent for each of your systems.
How DeployOpen prepares marking systems and evidence
DeployOpen's part in Article 50(2) work is to prepare the systems and the evidence, while the provider keeps ownership of its compliance position. Engagements are fixed-scope, so the scope, deliverables and timeline for the marking work are agreed in writing before any build starts. In practice that means naming which generative systems are in scope (audio, image, video and text outputs, including general-purpose systems that the provider exposes), which output paths must carry marks, which detection method the provider will offer, and which systems fall under the grace period for systems placed on the market before 2 August 2026. A written scope also defines what is excluded, such as assistive standard editing, so the provider can show a reasoned boundary.
On the technical side, DeployOpen implements and hardens self-hosted open-source components inside the client's own cloud accounts, data centers or air-gapped networks. Depending on the architecture, that work can cover the logging of generation events, the pipeline that attaches and verifies marks, and the certificate and key handling that signing depends on, using tools such as FreeIPA and OpenBao. It can also build test harnesses that submit generated samples through the marking and detection path and record whether marks survive common transformations. The resulting evidence pack is organized so the client can hand it to an independent assessor or to the market surveillance authority that asks for it. DeployOpen does not issue reports, attestations or certificates, and it does not decide whether a marking method is adequate. Confirm with your legal and compliance team which reviewer accepts the evidence.
Because marking pipelines change with every model release, plan for upgrades and re-testing from the start. Ongoing support, upgrades and continuous testing are available as retainers, which suits a provider whose code of practice position or detection method may be revisited after the Commission's opinion and the FAQ on non-signatories. Ask any implementation partner for a written description of who runs the test harness after go-live, how often evidence is refreshed, and who signs off the change record. Those answers determine whether the marking control remains evidenced when the system changes.
