eu-ai-act-transparency-assessor-oliver-schmidt-prietz
GitHub评估欧盟AI法案第50条透明度义务,生成合规报告与检查清单。适用于识别AI系统披露、水印及通知要求,辅助快速排查或制定实施计划。
Trigger Scenarios
Install
npx skills add lawve-ai/awesome-legal-skills --skill eu-ai-act-transparency-assessor-oliver-schmidt-prietz -g -y
SKILL.md
Frontmatter
{
"name": "eu-ai-act-transparency-assessor-oliver-schmidt-prietz",
"metadata": {
"author": "Oliver Schmidt-Prietz",
"license": "agpl-3.0",
"version": "2026-07-05"
},
"description": "Assesses which of the Art. 50(1)-(5) transparency obligations of the EU AI Act apply to a given AI system's provider or deployer, grounded in the final Code of Practice on Transparency of AI-Generated Content (June 2026) and the Commission's draft Art. 50 Guidelines. Covers AI-chatbot disclosure, deepfake and synthetic-content marking\/watermarking, emotion-recognition and biometric-categorisation notices, the machine-readable marking duty, the obviousness exceptions, and the implementation timeline. Outputs a formal mini-report plus a per-obligation compliance checklist with gap flags. For breadth-first tier triage use the EU AI Act System Classifier; for raw Art. 50 text and Q&A use the EU AI Act Knowledge Base; for the full role x tier matrix use the EU AI Act Obligations Mapper."
}
EU AI Act — Article 50 Transparency Assessor
Identify which Article 50 transparency duties (Regulation (EU) 2024/1689) apply to a system, decide
what must be implemented and by when, and produce a formal mini-report plus a per-obligation
compliance checklist. Works standalone, or ingests a prior classifier ASSESSMENT CONTEXT block.
Disclaimer (show at session start, do not block)
Important: This skill provides structured Art. 50 transparency guidance based on the EU AI Act (Regulation (EU) 2024/1689), the final Code of Practice on Transparency of AI-Generated Content (10 Jun 2026), and the Commission's draft Art. 50 Guidelines (8 May 2026). It is not legal advice; final decisions need qualified counsel, and only the CJEU can authoritatively interpret Art. 50. • Penalty band: non-compliance is Tier 2 — up to EUR 15,000,000 or 3% of worldwide annual turnover (Art. 99(4)(g); €750k for EU bodies). Not the €35M / 7% band (that is Art. 5 prohibited practices). • Dates: Art. 50 applies from 2 August 2026 (Chapter IV general application — not the 2 Aug 2025 tranche). The 50(2) legacy-system marking grace to 2 December 2026 is now adopted — the Digital Omnibus cleared the European Parliament (Jun 2026) and the Council (final green light, 29 Jun 2026) and is awaiting OJ publication ("shortly"; in force the 3rd day after). Treat 2 Dec 2026 as near-settled; only until the OJ text appears does the statutory 2 Aug 2026 date formally still govern legacy systems. Recommend a quick live OJ / law-tracker check. • Soft law: the Code of Practice is final but voluntary and under adequacy assessment (still pending) — adherence is not conclusive evidence of compliance. The Commission Guidelines are still draft (8 May 2026; consultation closed 3 Jun 2026). See references/sources.md for the live source manifest and uncertainty tiers.
Start here: pick a mode (ask this first)
Before intake, offer the user a route — do not default straight to the full report:
How deep do you need to go? 1. Quick triage — a yes/no on which duties bite and the earliest deadline (a few questions, a short answer). 2. Full assessment — the formal mini-report + per-obligation checklist + portable compliance block. 3. Implementation plan — what product / legal / engineering actually has to build, per triggered duty.
- Quick triage → run a compressed intake (role + what it does + market date), output only the Bottom line block (see Phase 6.0) and the top gaps; then offer to escalate to Full.
- Full assessment → the whole six-phase workflow.
- Implementation plan → Phases 1–4 focused on the build, load references/implementation-checklists.md.
If the user doesn't choose, assume Quick triage and offer to go deeper — leading light beats a wall of report.
Uncertainty markers (use these in every output)
Tag each material statement so the user can see how firm it is (this is the user-facing view of the statute / soft-law / open-issue strata — see references/sources.md):
- [Settled law] — the Regulation (Art. 50, 3(60), 99(4)(g)); in force.
- [Draft guidance] — the Commission Art. 50 Guidelines (draft, 8 May 2026); persuasive, non-binding.
- [Best practice] — the voluntary Code of Practice / EU icon set; adherence ≠ conclusive evidence.
- [Open issue] — adopted-but-unpublished (Omnibus/OJ), pending (CoP adequacy assessment), or un-litigated (no CJEU ruling on Art. 50).
State the most load-bearing uncertainty explicitly (e.g. "the 2 Dec 2026 grace is [Open issue] until OJ").
When to Search the Web (run quietly; report as one line)
Do these checks without narrating the research. Collapse the result into a single Source status line
in the output (Phase 6.0), e.g.:
Source status (checked <date>): Guidelines draft · Omnibus adopted, awaiting OJ · CoP adequacy pending · icons published.
On activation — always search for (these change month to month):
EU AI Act Article 50 Commission guidelines final adopted 2026
Code of Practice transparency AI-generated content adequacy assessment AI Board 2026
Digital Omnibus OJ check — always (the 2 Dec 2026 grace is adopted, awaiting OJ publication):
Digital Omnibus AI Act Article 50 watermarking grace 2 December 2026 Official Journal published
For 50(2) marking / standards:
EU AI Act Art 50(2) machine-readable marking C2PA implementing act standard 2026
AI Office transparency code signatories list 22 July 2026
For 50(4) labelling / icons:
EU official AI-generated content labelling icons set 2026
If web results conflict with this skill's reference files, prefer the newer official source and tell the user what changed.
Workflow: Ask Questions ONE AT A TIME
Read the reference files as each phase needs them. Do not dump all questions at once — this is a conversational assessment.
Phase 1: Intake
Prior Assessment Context (optional):
"If you have already run another EU AI Act skill (e.g. the classifier), paste its
ASSESSMENT CONTEXTblock here. I'll useArt. 50:,Role:,Classification:, andGPAI:to skip questions you've already answered."
If a block is provided:
- a non-empty
Art. 50: [triggers]→ pre-populate Phase 3 and confirm rather than re-derive; Role:→ satisfies Phase 2;Classification:/GPAI:→ informs the Art. 50 ↔ Art. 53 layering note (Phase 4);- if any field conflicts with the user's answers, flag the inconsistency before proceeding.
If no block is provided, run the intake as a short decision-tree, one step at a time — not one dense four-part question (honour the "one at a time" rule below). Walk these in order, adapting to answers:
- What does the system do? (one-line description)
- Does it generate content? If yes, which modalities — audio / image / video / text?
- Does it interact directly with people? (chatbot, voice agent, autonomous agent)
- What's your role — do you build/place it on the market (provider), use it under your authority (deployer), or both?
- When was it / will it be placed on the EU market? — this date drives the 50(2) grace logic.
In Quick triage mode, ask only 2, 4 and 5 (plus 3 if relevant) and skip to the Bottom line. Once you have the facts, echo them back as a "Facts I'm relying on" block (Phase 6.6) and ask the user to correct anything before you analyse.
Read references/art50-duties.md for the duty definitions before Phase 3.
Phase 2: Role determination
Art. 50 splits duties by role:
| Duty | Binds |
|---|---|
| 50(1) interaction disclosure, 50(2) synthetic-content marking | Provider |
| 50(3) emotion/biometric notice, 50(4) deepfake/PI-text labelling | Deployer |
| 50(5) delivery quality | whoever owes (1)–(4) |
- If the context block carries
Role:, use it. - Otherwise ask whether the organisation builds/places the system on the market (provider), uses it under its own authority (deployer), or both (a provider that also deploys owes all four duties).
- For Art. 25 quasi-provider / substantial-modification depth (a rebrand or material fine-tuning can make
a deployer a provider), route to
ai-act-rolesrather than re-deriving it here.
Phase 3: Trigger determination (one sub-section per duty)
For each duty: apply the trigger test, then the obviousness / exception test. Read references/obviousness-and-exceptions.md.
3.1 — Art. 50(1) interaction disclosure (provider). Trigger: the system interacts directly with natural persons. Then test obviousness against the average-consumer multi-factor standard (context, vulnerable groups, AI literacy, realism); dev-only code assistants and in-game NPCs are plausibly "obvious", but for general-audience systems and AI companions the exemption is largely closed. What does not satisfy 50(1) (draft Guidelines para. 35): disclosure buried in T&Cs, machine-readable signals alone, a generic "assistant" label, or "this system uses LLMs". Agentic AI must self-disclose in every reasonably-foreseeable human interaction (para. 28). Authorised law-enforcement use is the only statutory exception.
3.2 — Art. 50(2) synthetic-content marking (provider). Trigger: the system generates synthetic audio/image/video/text — not GPAI-specific; single-purpose tools count, and machine translation is IN scope (a translation engine generates new text; draft Guidelines para. 54). Test the assistive-function exemption (trivial in-place editing that preserves meaning → out; generation → in). Note the Guidelines' carve-outs: source code (para. 64), narrow cumulative B2B/industrial (para. 81), in-game generation (para. 82). Flag the market-placement date — it decides whether the legacy grace applies (Phase 5).
3.3 — Art. 50(3) emotion-recognition / biometric-categorisation notice (deployer). Trigger: the system performs emotion recognition or biometric categorisation. First check Art. 5: if the use is in the workplace/education (5(1)(f)) or targets sensitive characteristics (5(1)(g)) it is prohibited — 50(3) does not apply and the Art. 5 violation governs. Otherwise the 50(3) notice is owed in addition to any high-risk/Art. 5 analysis and regardless of risk tier — it covers all biometric categorisation, including non-high-risk age- or gender-inference for ads or analytics (para. 98). Race/ethnicity inference is not a 50(3) example — it is a prohibited 5(1)(g) categorisation; see the Art. 5 gate above. Coordinate with GDPR Art. 13/14.
3.4 — Art. 50(4) deepfake & public-interest-text labelling (deployer). Two steps, not one categorical rule. Step 1 — is it a deepfake? Apply the Art. 3(60) four-element test (draft Guidelines para. 107): appreciable resemblance · capable of existing in reality · existing persons/ objects/places/entities/events · false authenticity judged by the actual audience (para. 108). A photorealistic invented person is IN (plausibly could exist); dragons/impossible content are OUT; a substantive AI edit of a journalistic image can be IN. Step 2 — exception? law enforcement; evidently artistic/creative/fictional → proportionate disclosure (form only); public-interest text under human editorial review. Marketing has no blanket pass — primarily-commercial content gets full disclosure (para. 114); don't say marketing categorically qualifies, nor that it never can. (Or the AI-text limb: public-interest text without human editorial control.)
3.5 — Art. 50(5) delivery quality (cross-cutting). For every triggered duty, disclosure must be clear, distinguishable, timely (≤ first interaction/exposure) and accessible — conform to the applicable accessibility requirements (assess EAA applicability; use WCAG AA as the design benchmark for web/mobile UI). Art. 50(5) does not itself name the EAA.
Close Phase 3 with the trigger-summary table:
| Duty | Binds | Triggered? | Trigger basis | Obviousness / Exception verdict |
|---|---|---|---|---|
| 50(1) | Provider | [Y/N] | … | … |
| 50(2) | Provider | [Y/N] | … | … |
| 50(3) | Deployer | [Y/N] | … | … |
| 50(4) | Deployer | [Y/N] | … | … |
| 50(5) | [owner] | [Y/N] | … | … |
Phase 4: Implementation deep-dive (per triggered duty)
For each triggered duty, explain what to build. Load the matching reference:
- 50(2) marking → references/code-of-practice-final.md. Distinguish three tiers: (1) statutory floor [Settled law] — machine-readable + detectable, four criteria "as far as technically feasible" (no technique and no "two layers" mandated); (2) Code route [Best practice] — ≥ 2 layers (signed metadata + imperceptible watermark), detection is half the duty (free-of-charge, per-technique), text > 200 tokens must be watermarked; (3) robust best practice. Adherence to the Code is not conclusive evidence of compliance. If the system uses a GPAI model: Art. 50(2) binds it at the system layer; model-level marking is encouraged best practice (Guidelines paras. 24/70; Code Measure 1.1.2) — not an Art. 53(1)(d) duty (53(1)(d) is the training-data summary).
- 50(4) labelling → references/eu-labelling-icons.md: the three official EU icons (Basic, Fully AI-Generated, Partially AI-Modified) — icons optional, the mandatory core is the capitalised "AI" acronym; GENERATED/MODIFIED is optional and copyright- sensitive; audio needs a mandatory audible disclaimer; embed-by-default placement, WCAG contrast, persistence. For published text, the Commitment 4 editorial-responsibility policy.
- 50(1) / 50(3) notices → notice content, placement, and timing (Art. 50(5)); for 50(3), the GDPR Art. 13/14 coordination.
Concrete action items per role are in references/implementation-checklists.md.
Phase 5: Dated roadmap
Read references/timeline-and-grace.md. Anchor the roadmap on:
- 22 Jul 2026 — Code initial-signatory form deadline (to appear on the list published before 2 Aug 2026; signing is encouraged, not mandatory, and possible later too).
- 2 Aug 2026 — 50(1)/(3)/(4) and 50(2) for newly-placed systems apply, no transition.
- 2 Dec 2026 — legacy 50(2) marking — [Open issue → near-settled]: the Digital Omnibus grace is adopted (EP Jun 2026; Council final green light 29 Jun 2026) and awaiting OJ publication (in force the 3rd day after). Until the OJ text appears, 2 Aug 2026 formally still governs legacy systems. Recommend a quick live OJ / law-tracker check — but do not overstate the residual risk.
- 2 Feb 2027 — the Code's watermark-detection interoperability obligation (distinct from the superseded original legacy-marking proposal of the same date).
- Content already public before 2 Aug 2026 needs no retrospective marking/labelling.
Phase 6: Output (lead light, then the formal artifacts)
Read references/report-template-art50.md. Always show 6.0–6.6 first as a short conversational answer; only produce the heavy artifacts (a)–(c) when the user is in Full mode or asks for them.
- 6.0 Bottom line (always, ≤ 6 lines): role · duties triggered · earliest deadline · biggest gap · the one load-bearing legal uncertainty (tagged with an uncertainty marker).
- 6.5 Readiness (operational indicator, not legal advice):
Readiness: Low / Med / High·Critical blockers: N·Must-fix before deadline: N·Counsel review needed: yes/no. - 6.6 Facts I'm relying on: the intake echoed back, so the user can correct a misread before trusting the analysis.
- Source status line: one line,
checked <date>, per the uncertainty markers.
Then, on request / in Full mode:
- (a) the mini-report (Subject/Scope → Role → Trigger analysis → Implementation → Exceptions → Roadmap → Gaps + penalty exposure → Conclusion);
- (b) the per-obligation checklist with
✓ / ◐ / ✗ / N/Agap flags and a SUMMARY line; - (c) the portable
ART. 50 TRANSPARENCY COMPLIANCE BLOCKfor chaining.
Offer an optional .docx export by handing the report to the ai-act-report skill (its Phase 4
Word export) — do not re-implement document generation here. This skill does not emit RoPA's
interchange-schema.json.
Related skills
ai-act-classifier— upstream triage: is it an AI system, which risk tier, which 50 triggers fire. Paste itsASSESSMENT CONTEXTinto Phase 1 to skip re-triage.ai-act-roles— Art. 25 quasi-provider / substantial-modification depth (defer the role-edge cases).ai-act-knowledge— verbatim Art. 50 regulation text, recitals, and Q&A.ai-act-obligations— the full role × tier obligation matrix (Art. 50 is a slice of it).ai-act-report— consolidated 9-section Prüfbericht and the .docx export this skill defers to.
Critical Reminders
- Penalty is €15M / 3% (Tier 2, Art. 99(4)(g); €750k EU bodies) — never the €35M / 7% Art. 5 band.
- The 2 Dec 2026 legacy-marking grace is ADOPTED, awaiting OJ — the Digital Omnibus cleared EP (Jun 2026) and Council (final green light 29 Jun 2026); treat 2 Dec 2026 as near-settled, recommend a live OJ check, and note 2 Aug 2026 formally governs only until the OJ text appears. Do not call it "politically agreed" or "conditional / may not happen".
- The Code of Practice is voluntary and adherence is not conclusive evidence of compliance — it is a strong evidentiary anchor, not a safe harbour; do not call it a "presumption of conformity". Separate the statutory floor from the Code's layered architecture.
- The Commission Art. 50 Guidelines are draft (8 May 2026) — non-binding; only the CJEU is authoritative.
- Agentic AI self-discloses in every reasonably-foreseeable human interaction (Guidelines para. 28). 50(1) is not satisfied by T&Cs, machine-readable signals alone, "assistant", or "uses LLMs" (para. 35).
- 50(3) is gated by Art. 5 (workplace/education emotion recognition and sensitive biometric categorisation are prohibited — a notice cannot cure it), but otherwise applies additively and to all biometric categorisation, incl. non-high-risk age- or gender-inference (para. 98) — race/ethnicity inference is itself prohibited under 5(1)(g), not a 50(3) case.
- Deepfake = Art. 3(60) — apply the four-element test (para. 107); a photorealistic invented person is IN. Marketing has no blanket pass: primarily-commercial content gets full disclosure — but don't say marketing can never be artistic. Machine translation is IN scope (para. 54).
- Model-level GPAI marking is encouraged best practice — NOT an Art. 53(1)(d) duty (53(1)(d) is the training-data summary). Art. 50(2) binds the AI-system layer, including GPAI systems.
- 50(2): no single technique satisfies all four criteria; text > 200 tokens must be watermarked; detection is half the duty. No retrospective marking of content already public before 2 Aug 2026.
- Provider 50(2) marking ≠ deployer 50(4) labelling — distinct duties on distinct parties; a deepfake can require both. A platform merely passing on third-party content is not a deployer (para. 12).
Version History
- 8e51264 Current 2026-07-31 02:37


