AI transparency is increasingly becoming more than a disclosure-design problem.
A disclosure may tell a person that AI was involved.
A relying party may need to answer deeper questions:
Which system produced the output?
Who operated it?
Which disclosure was shown?
When was it shown?
What provenance or evidence supports it?
Can that evidence still be resolved later?
This repository explores that evidence layer.
Start with the Article 50 practical briefing: https://mcp.ecocitizenz.com/article50
Human-facing transparency and machine-readable evidence solve different problems.
VISIBLE DISCLOSURE
↓
AI SYSTEM
↓
OPERATOR
↓
CONTENT / OUTPUT
↓
DISCLOSURE EVENT
↓
PROVENANCE / EVIDENCE
↓
TIMESTAMP / FRESHNESS
↓
INDEPENDENTLY RE-CHECKABLE STATE
The visible disclosure is what the person sees.
The evidence architecture is what systems, auditors, platforms and relying parties may need to inspect later.
Article 50 of the EU AI Act introduces transparency obligations covering particular circumstances involving AI systems and AI-generated or manipulated content.
Its application depends upon the system, role, output and circumstances.
MCP traffic is not automatically within Article 50 scope, and using ECZ-ID is not a legal requirement.
But Article 50 creates an important operational question:
If a transparency obligation applies, what evidence demonstrates what happened?
That is where implementation architecture begins to matter.
For an AI transparency implementation, consider whether you can determine:
- Which AI system generated or manipulated the relevant output?
- Which system/version was involved?
- Is that identity persistent enough to investigate later?
- Who operated or deployed the system?
- Is the relevant organisation attributable?
- Can responsibility changes be represented over time?
- Which content or interaction is being referenced?
- Is there a stable output/event identifier where appropriate?
- Can sensitive content be avoided while preserving useful evidence?
- What disclosure was presented?
- Which disclosure method/version was used?
- When was it presented?
- In which context?
- What generated or transformed the content?
- Which provenance mechanism was used?
- What supporting evidence exists?
- Can the evidence be independently inspected?
Evidence may need to distinguish:
when the content was created
from:
when the disclosure occurred
from:
when the evidence was published
from:
when a relying party checked it.
These are not necessarily the same moment.
A historical evidence record and today's state are also different concepts.
Evidence may subsequently be:
- corrected;
- superseded;
- withdrawn;
- replaced;
- updated.
A relying party should be able to distinguish historical occurrence from present state.
A useful transparency evidence record might connect:
AI SYSTEM IDENTITY
↓
OPERATOR IDENTITY
↓
OUTPUT / EVENT REFERENCE
↓
DISCLOSURE EVENT
↓
PROVENANCE REFERENCE
↓
TIMESTAMP
↓
EVIDENCE STATE
↓
RESOLVABLE RECORD
The objective is not to turn every disclosure into a compliance certificate.
The objective is to make the underlying evidence structured, attributable and re-checkable.
Evidence being present does not automatically mean:
“EU compliant.”
A machine-readable record should not silently become a legal conclusion.
A stronger separation is:
FACT / EVIDENCE
↓
RESOLVABLE STATE
↓
LOCAL OR LEGAL INTERPRETATION
ECZ-ID deliberately preserves that distinction.
Teams preparing transparency systems can ask:
-
Which Article 50 role or circumstance are we analysing?
-
Which disclosures are actually relevant?
-
Which system and operator identities sit behind them?
-
Which events should be recorded?
-
Which evidence should be machine-readable?
-
How will timestamps and versions be handled?
-
What happens when evidence changes?
-
Can another party independently re-check the evidence?
-
Can historical state be reconstructed?
-
Are legal conclusions kept separate from technical evidence?
EcoCitizenz has published a practical Article 50 resource for teams working through these questions.
https://mcp.ecocitizenz.com/article50
Use it to:
- review the implementation questions;
- access the executive briefing;
- examine evidence readiness;
- understand where identity, provenance and current state fit.
The same underlying problem extends beyond AI disclosure.
Machines increasingly need to establish:
who they are
who operates them
what authority they possess
what they are connected to
what happened
what evidence exists
and
whether that evidence remains current.
That is the broader ECZ-ID architecture.
IDENTITY
↓
OPERATOR
↓
AUTHORITY
↓
BINDINGS
↓
ACTION / EVENT
↓
EVIDENCE
↓
CURRENT STATE
↓
RESOLUTION
Explore:
https://mcp.ecocitizenz.com/article50
Inspect a live Resolver record:
https://resolver.ecocitizenz.org/passport/ECZ-GB-RBS1NW
Built by EcoCitizenz Ltd.
This repository provides technical and operational information. It is not legal advice, does not certify AI Act compliance and does not imply that ECZ-ID is legally required.