Article 50 compliance evidence checklist for product teams

1. Scope and role evidence

• AI system name, version, owner and intended purpose.
• Markets, languages and user groups, including how EU use was assessed.
• Provider, deployer and other value-chain roles with a dated rationale.
• Architecture and supplier map showing who controls the interface and output pipeline.
• Relevant contracts, white-label arrangements and release ownership.
• A trigger for reassessment after supplier, model, feature or market changes.

2. Interaction-disclosure evidence

• Exact notice wording for every supported locale.
• Screenshot, recording or automated test showing the first interaction.
• Persistent label or information surface available during the exchange.
• Keyboard, screen-reader, zoom and contrast test results.
• Human-handoff wording where the product offers escalation.
• Component version, deployment URL and production verification date.

3. Machine-readable marking evidence

• Output-format and distribution-channel inventory.
• Chosen marking or provenance method and technical design decision.
• Original asset plus validator output.
• Resize, transcode, copy, screenshot, metadata-stripping and platform tests.
• Detection success criteria, known limitations and unsupported formats.
• Signer, key-management, tool-version and specification-version records where relevant.

4. Visible content-label evidence

• Deepfake or public-interest text classification facts.
• Label wording, placement, prominence and accessibility evidence.
• The publication URL and first-exposure experience.
• A link between the visible label and the exact asset version.
• Artistic or other context analysis where relied upon.
• Proof that the visible label survives embeds and distribution.

5. Human review and editorial responsibility

• Reviewer identity, role and relevant competence.
• Sources checked and substantive issues considered.
• Material edits, challenges or approvals recorded by the reviewer.
• The person or legal entity holding final editorial responsibility.
• Evidence that this party could approve, change or reject publication.
• A clear distinction between substantive review and grammar, spelling or formatting checks.

6. Governance and change evidence

• Control owner, approver and review frequency.
• Official source URL, access date and rule version.
• Decision log for exceptions and ambiguous cases.
• Release evidence connecting code, configuration and deployed behaviour.
• Incident and remediation records when a notice or mark fails.
• Retention, access, export and deletion rules for the evidence itself.

7. Reproducible testing

A reviewer should be able to reproduce the result. Record the environment, test inputs, expected outcome, actual outcome, timestamp and tester. For client-side notices, include automated assertions and a production screenshot. For content marking, preserve both a known-valid fixture and known-failure fixtures.

8. Evidence quality gate

Before closing a control, ask:

1. Does the record identify the exact system or asset version?
2. Is the evidence from production or clearly labelled as local, test or mock?
3. Can another person reproduce the check?
4. Is the official source current and directly linked?
5. Are limitations and unresolved professional-review questions visible?
6. Will a future product change reopen the control automatically?

Article 50 Hub uses versioned systems, controls, evidence assets, reviews and immutable receipts to keep these relationships inspectable. Start with the free readiness checker, then create a workspace when ongoing ownership and export are needed.