DEV Community

Ventse
Ventse

Posted on • Originally published at traceseal.io

EU AI Act Article 50: what it means for teams running AI agents

Cross-posted from traceseal.io.

On 2 August 2026, the transparency obligations in Article 50 of the EU AI Act (Regulation (EU) 2024/1689) become applicable. If your organisation deploys AI systems that interact with people or produce content — and AI agents do both — this deadline matters wherever you are based: the Act applies wherever a system's output is used in the Union.

What Article 50 actually requires

The full text of Article 50 sets out four transparency duties:

  • Disclosure of AI interaction. People must know they are interacting with an AI system, unless obvious from context.
  • Marking of synthetic content. Generated text, audio, image or video must be marked as artificially generated, machine-readably where feasible.
  • Deployer disclosures. Emotion recognition, biometric categorisation and deepfake-style content require informing the people affected.
  • Published text disclosures. AI-generated text published on matters of public interest must be disclosed, unless a human editor takes responsibility.

Non-compliance carries penalties up to €15 million or 3% of worldwide turnover (Article 99(4)).

Why agents make this harder than chatbots

For a chat window, disclosure is a banner. For an agent — a system that plans, calls tools, edits files, sends messages and commits code — the question is not "did we tell the user it's AI?" but "can we show what the system actually did?"

Application logs are written by the same system they describe, can be edited after the fact, and prove nothing to a third party. When an agent's action is challenged, "our logs say it behaved" is an assertion, not evidence.

From documentation to verification

The robust way to demonstrate what an AI system did is to make the record tamper-evident and independently verifiable:

  1. Sign the code. The publisher signs the agent skill with an ed25519 key over a content-addressed manifest — provable which code ran.
  2. Seal the execution. The operator runs it in a kernel-namespace sandbox and signs a record of inputs, outputs, timing and sandbox policy — as SHA-256 hashes, proving integrity without exposing data.
  3. Let anyone verify — one command, offline, no access to the operator's systems:
$ pip install traceseal-verify
$ traceseal-verify receipt.json
[OK] receipt.json — operator signature verified
Enter fullscreen mode Exit fullscreen mode

Because the receipt is canonical JSON under a signature, any tampering breaks the seal. That converts an Article 50 conversation from a documentation exercise into a one-command check.

The practical test: if a regulator asked you tomorrow to prove what your agent did last Tuesday, would you hand them a log file they must trust — or a receipt they can verify?

What to do before 2 August 2026

  • Inventory your agents. Anything interacting with people or generating content is in scope for at least one duty.
  • Decide your evidence standard. Logs are trust-me evidence; signed receipts are check-it-yourself evidence.
  • Instrument now, not after an incident. Receipts only cover executions sealed at the time.

The receipt format, verifier and transparency log are open: the spec, the verifier on PyPI, and the public log. You can adopt the format without adopting us.

Top comments (0)