Governance & evidence
Transparency and Synthetic Content Marking
Article 50 requires three disclosures that are often built by different teams but audited together: telling people they are interacting with an AI (50(1)), marking synthetic content so it is identifiable as artificially generated (50(2), C2PA provenance, watermark, or metadata), and disclosing deep-fake provenance with a disclaimer (50(4)). The Transparency register keeps those three notice types in one place, each with a method and an optional evidence file.
Transcript
Article 50 has three disclosures: tell people they are interacting with AI, mark synthetic content as artificially generated, and disclose deep-fake provenance.
The Transparency register keeps those three notice types in one place, each with a method like watermark, C2PA or metadata, and an optional evidence file.
Previously the Art.50 obligation looked completed as soon as you had a system. Now it requires at least one Transparency record, which is the honest evidence.
Create an interaction disclosure for a chatbot, a synthetic marking with watermark or C2PA for a generator, or a deep-fake disclaimer with a screenshot.
Each notice type is independent. A recommender may need only interaction disclosure, a generative image model likely needs all three.
Why this is required
Article 50's three duties land on providers and deployers of different system types, but an auditor checks them as a group. Three separate spreadsheets or a single undifferentiated 'transparency done' toggle both make that check harder than a typed register.
Synthetic-content marking in particular needs a method claim (watermark vs C2PA vs metadata) plus proof (a screenshot or a sample file with the mark intact). Storing the notice type separately from the method and linking an EvidenceFile makes that proof queryable rather than anecdotal.
What EuroCompliant does
TransparencyRecord (models.py:1015) stores company_id, optional system_id, notice_type (interaction_disclosure / synthetic_marking / deep_fake_disclosure), method, description, and optional evidence_file_id. Evidence engine _has_transparency_notices (evidence_engine.py:310) now returns true only when at least one row exists, previously it vacuously returned true for any tenant with a system, which made ai_act_50 look completed before any disclosure was documented.
Obligation ai_act_50 remains platform_managed but is now honest: transparent_notices_handled is completed only when the register has ≥1 row, otherwise not_started. The obligation applies when uses_ai is true (the same gate as before), so a tenant with no AI systems correctly sees it as not applicable via the smart tracker, not as a false completion.
POST/GET /transparency/records (and GET/PUT/DELETE /transparency/records/{id}) are tenant-scoped and audit-logged as transparency.record_create/update/delete. Frontend /transparency is the register: a three-type form, optional system link, method/description, optional EvidenceFile link, and a table with delete per row.
Walking through it
Create an interaction disclosure
Notice type interaction_disclosure, method e.g. in-app banner, and where users see it. Link a system if it belongs to a specific AI system.
Open /transparency →Mark synthetic content
Notice type synthetic_marking, method watermark / C2PA / metadata, and the tool or pipeline that applies the mark. Attach a proof file via EvidenceFile where you have a screenshot or sample.
Open /transparency →Disclose a deep fake if you generate one
Notice type deep_fake_disclosure, method disclaimer_screenshot or provenance record, and where the disclosure is shown to recipients.
Open /transparency →The law
Frequently asked
Why did ai_act_50 previously show as completed before I had documented anything?
The old _has_transparency_notices returned true for any tenant with a system, so ai_act_50 looked completed as soon as you registered a system. It now requires at least one TransparencyRecord, which is the honest evidence for Art.50.
Do I need all three notice types?
Only those that apply to your systems. A non-generative recommender that never creates synthetic content needs interaction_disclosure but not synthetic_marking; a generative image model likely needs all three. The register tracks what you actually have.
Related guides
Risk classification
The Article 6 assessment that decides which obligations a system carries, and why the reasoning matters as much as the result.
Compliance checklists
How Articles 9 to 15 become tracked, owned, evidenced work rather than a document nobody reads.
Evidence vault & audit trail
Turning completed checklist items into artefacts a regulator can inspect, and the logging duties behind Articles 12 and 26.
Try it on your own systems
Everything in this guide runs in the live product. Start a free trial and follow along with your own data.
Start free trial