Skip to content
Δημοσιεύθηκε στις April 15, 2026 · από Coinator Team

The AI Act and Blockchain Forensics: What Documentation Duties Investigators Now Face

From August 2026, the high-risk obligations of the EU AI Act take effect — affecting blockchain forensics tools with ML components as well. What does this mean for authorities, banks and investigators using such systems?

#ai-act #compliance #methodology #transparency

The EU AI Act was adopted in July 2024, and its provisions take effect on staggered deadlines. The decisive stage for forensics users is now approaching: from 2 August 2026, the full obligations for high-risk AI systems apply. Anyone deploying AI-supported blockchain analysis should check now whether their tool meets these requirements.

What makes a system "high-risk"?

The AI Act classifies AI systems into four risk tiers. Two annexes are relevant to our industry:

  • Annex III No. 6 — Law enforcement: AI systems used by law-enforcement authorities to evaluate evidence or profile natural persons.
  • Annex III No. 5c — Creditworthiness & risk assessment: AI systems for evaluating the financial risk of natural persons, for example in AML screening.

Many modern blockchain forensics tools fall directly or indirectly under one of these categories — as soon as they produce cluster attributions, risk scores or suspicion-based assessments relating to concrete persons or wallets.

Core obligations at a glance

For high-risk systems, from August 2026, the following apply — among others:

  1. Documentation of training data — origin, representativeness, bias review (Art. 10)
  2. Technical documentation and transparency — algorithms, metrics, known limitations (Art. 11)
  3. Logging of decisions — audit trail for every AI-supported classification (Art. 12)
  4. Human oversight — no fully automated operational use without control capability (Art. 14)
  5. Accuracy, robustness and cybersecurity requirements (Art. 15)

Anyone integrating an AI system into core processes bears co-responsibility as the deployer (Art. 26) — not just the manufacturer. Banks, tax authorities and investigative agencies therefore need to check whether they can maintain the required documentation from their suppliers.

Where blockchain forensics classically falls short

Many widely-used forensics suites on the market work with proprietary, undisclosed risk models:

  • The origin score for an address is returned as a single number, without clear breakdown of the heuristics that fed in.
  • Training data of the internal ML models (e.g. mixer classifier or change-detection networks) is undocumented.
  • The audit log is limited to API calls — not to the decision rationale per wallet.

This will no longer suffice from August 2026. In expert-opinion contexts, such results can already be challenged today because the traceability is missing.

Our approach: transparency as an architectural principle

Coinator was built from the start with the assumption that every attribution must hold up in court if challenged. Concretely, this means:

  • All 40+ heuristics are openly documented — visible on our methodology page and citable in expert-opinion appendices.
  • Every ML-supported assignment includes the classical heuristic derivation — you see which multi-input, change or pattern heuristics contributed to the classification.
  • Training data for our GNN models is traceable: we use only addresses from our own, manually verified clusters — no anonymous third-party feeds.
  • Audit log per request: every cluster attribution is logged with timestamp, input parameters and the heuristic decision chain.

With this, Coinator is already compliant with the core requirements of the AI Act — without our customers having to retrofit.

What you should do now

If your authority or institution deploys AI-supported blockchain forensics (or plans to):

  1. Check the classification: does your current use fall under Annex III of the AI Act?
  2. Request documentation: ask your tool vendor for written information about training data, algorithms, limitations and audit capabilities.
  3. Establish oversight workflows: any automated cluster assignment feeding into a case should be reviewed and signed off by a qualified person before publication.
  4. Document your own deployment: deployer obligations (Art. 26) require your own protocols — not just the manufacturer's.

We're happy to support you — with training, expert-opinion templates and compliance consulting. Get in touch.


This post does not replace legal advice. The assessments presented here are based on the published version of Regulation (EU) 2024/1689 and the current state of secondary implementing acts.

This post is currently only available in the language shown above.