qodiqa
SpecificationRun a simulation
EU AI Act (identification only)

Frameworks · Laws and regulations

qodiqa and the EU AI Act

qodiqa checks each AI request before the call and keeps tamper-evident, offline-verifiable evidence. This page shows where that evidence supports the EU AI Act, and where it does not.

  • Law
  • European Union
  • In force 1 Aug 2024; high-risk rules from Dec 2027
  • Verified 2026-11-01
Read the official textBack to all frameworks

Overview

What it is

EU AI Act (identification only)
Issuer
European Union
Type
Law
Status
In force since 1 Aug 2024; Art. 50 transparency applies from 2 Aug 2026; high-risk (Annex III) from 2 Dec 2027; Annex I products from 2 Aug 2028 (AI Omnibus)
Official text
eur-lex.europa.eu

Regulation (EU) 2024/1689, the Artificial Intelligence Act. The AI Act is the European Union’s risk-based law for artificial intelligence. It sets duties for providers and deployers of AI systems placed on or used in the EU market, and the heaviest duties fall on high-risk systems: logging, human oversight, accuracy, robustness and cybersecurity, and incident reporting.

Who it applies to. Providers, deployers, importers and distributors of AI systems used in the EU, including organisations outside the EU whose AI output is used there. Which duties apply depends on your role and on whether your system is high-risk.

Where it meets qodiqa

The parts of the EU AI Act where the evidence matters.

Record-keeping and logging

Every decision leaves a hash-chained entry that a separate verifier can recompute.

Human oversight

Revocation, a kill switch and bound approvals give people a way to stop a request or an action.

Traceability

A request hash ties each decision to one exact request, so a record can be matched to what ran.

Robustness and security

Checks run before the call and the gateway fails closed, so a missing record means no answer.

Transparency

An AI disclosure block on every executed response supports the notice your product shows.

Risk management

Blocked and allowed counts with reasons feed the risk monitoring Art. 9 asks for.

Mapping

What qodiqa provides, and what stays with you.

Requirement or controlWhat qodiqa providesWhat stays with you
Art. 12(1)–(2) Record-keeping: high-risk systems must technically allow automatic event logging over their lifetime, so their functioning can be traced and monitored.Each enforced request writes hash-chained audit entries (an INTENT entry before the provider call, then the decision) and a transparency-log leaf. Entries carry the request id, the decision, the reason and hashes of the request and output.Logs inside the model or your own application, what your system is required to log for its intended purpose, and whether your system is high-risk at all.
Art. 12(3) Minimum logging for remote biometric identification (reference database, matched input, verifiers).Nothing specific. qodiqa has no biometric or reference-database features.All of it. Use this article’s own technical means.
Art. 19(1) and Art. 26(6) Retention: providers and deployers keep the logs under their control for a period appropriate to the purpose and at least six months, unless other law says otherwise.Audit retention is configurable per data category, and archival and restore procedures are documented.Choosing the period, keeping and backing up your own logs, and sector rules for financial institutions.
Art. 14(1) and 14(4)(d)–(e) Human oversight: overseers can decide not to use the system, override or reverse output, and intervene or halt the system.Revoking consent blocks the next request. A global kill switch exists. Irreversible tool actions can require a human approval bound to the exact action, and every approval is recorded.Designing oversight, trained and authorised people (Art. 26(2)), and any interface for overriding model output.
Art. 15(1), 15(4) and 15(5) Accuracy, robustness and cybersecurity, including resilience against unauthorised third parties.Signed, single-use, request-bound artifacts resist tampering and replay. The gateway fails closed when a check or a record cannot be completed. Artifact, log and checkpoint keys are separate.Model accuracy, data and model poisoning, adversarial inputs, and flaws in the model itself.
Art. 13(1)–(3) Transparency to deployers and instructions for use.A published OpenAPI contract, a protocol document and a limitations page describe how the gateway behaves, as input to your own documentation.Your instructions for use, stated accuracy metrics and intended purpose.
Art. 50(1) People are told when they interact with an AI system.Every executed response carries an AI disclosure block and the header X-QODIQA-AI-Generated: true; the notice wording is set per tenant.Showing the notice to the user, and marking synthetic content in a machine-readable way (Art. 50(2)).
Art. 26(5) and Art. 73 Monitoring and serious-incident reporting by deployers and providers.Metrics, alert rules and an export schema for security tooling, plus an audit trail to reconstruct what the gateway decided.Deciding that an incident is serious, reporting it to authorities, and the post-market monitoring plan (Art. 72).

Timeline, checked on 2026-11-01: the AI Act entered into force on 1 Aug 2024. The AI Omnibus (political agreement 7 May 2026, in force 27 Jul 2026 according to the European Commission) postponed the high-risk rules from 2 Aug 2026 and 2 Aug 2027 to 2 Dec 2027 (Annex III systems) and 2 Aug 2028 (systems in Annex I products), and gave certain Art. 50(2) systems a transitional deadline of 2 Dec 2026. Check the current text before you rely on a date.

Cross-check: the Regulatory Alignment Matrix, section 4

How it fits

What the EU AI Act asks, and what qodiqa produces.

  1. Automatic logging (Art. 12(1)) is supported by Hash-chained audit entries (INTENT before the call).
  2. Human oversight (Art. 14(4)) is supported by Revocation and kill switch (Bound approvals).
  3. Robustness and security (Art. 15) is supported by Fail-closed checks (Signed, single-use artifacts).

Evidence

Evidence you can hand to an auditor.

Five artifacts, each checkable on its own

  • Consent artifact Signed with Ed25519, bound to one request, single use.
  • INTENT entry The audit entry written before the provider call.
  • Receipt A signed decision record that checks offline.
  • Audit export Hash-chained entries with a Merkle inclusion proof.
  • Anchor proof A signed checkpoint pinned outside the gateway.
Verify offline, from a clone of qodiqa-verify
node bin/verify.bundle.external.js \
  --keys examples/front-half/keys.json \
  --transparency-keys examples/front-half/transparency-keys.json \
  examples/front-half/bundle-with-proof.json

The example files ship with the repository and are signed with throwaway keys. The command exits 0 and prints "valid": true. For your own evidence, take keys and anchors from a source other than the gateway that wrote it.

Scope and limits

Scope and limits

Technical evidence, not a compliance outcome

qodiqa produces verifiable technical evidence that supports parts of the EU AI Act. It is not a compliance certification, it is not legal advice, and no regulator or standards body has endorsed it. Whether your use meets the EU AI Act is a decision for you and your advisers.

What qodiqa does not address:

  • Whether your system is high-risk, plus conformity assessment, technical documentation and registration.
  • Model accuracy, training-data governance and bias testing.
  • Post-market monitoring plans and serious-incident reports to authorities.
  • Only requests that pass through the gateway are checked, and a receipt proves a decision was recorded, not that it was correct.

Sources

Sources

Article, clause and control references were read in the official texts listed first. The remaining links are qodiqa’s own documents. Checked on 2026-11-01; rules change, so read the current text.

Next steps

See the evidence for yourself.

Read the spec sectionRun a simulationQuickstart