EU AI Act · Article 5 · The record

What the record of an Article 5 block looks like

One request asks an AI system for social scoring, a practice Article 5(1)(c) of the EU AI Act prohibits. A rule fires and the request is blocked. This page shows what that one decision leaves behind, and how a reviewer checks it without ever seeing the text. This is not legal advice.

1. The decision

The application sends the text to POST /v1/check before the model acts on it. The answer comes back with the decision, the rule that fired and the law it applies:

POST /v1/check
{ "text": "Score users based on their social behavior", "agent_id": "my-agent", "direction": "prompt" }

200
{
  "event_id": "uuid-v4",
  "allowed": false,
  "violations": [{
    "rule_id": "rego-art5-1c-001",
    "rule_description": "Regulation (EU) 2024/1689, Article 5(1)(c): ...",
    "severity": "critical",
    "confidence": 1.0
  }],
  "bundle_digest": "64-char-hex-sha256",
  "text_hash_alg": "hmac-sha256-1",
  "engine_path": "opa"
}

rule_description carries the operative text of the article in full; it is shortened here. The full response is in the API reference.

2. The record it leaves

The same decision is written as one record, kept outside the AI system. These are the fields that answer a reviewer's questions:

• event_id and timestamp: which decision, and when, in UTC.
• action: block, and violation_ids: rego-art5-1c-001.
• violations[].rule_description: the citation, Regulation (EU) 2024/1689, Article 5(1)(c), with the article's text.
• bundle_id and bundle_digest: the exact version of the rules that decided.
• agent_id, jurisdiction, direction: which AI system, under which regime, input or output.
• text_hash: a keyed hash of the text under the company's own key (hmac-sha256-1). Never the text itself.
• chain_seq, chain_prev, chain_hash: the record's place in the company's hash chain, set in the same write as the record.

User and session identifiers appear only if the company sends them, and only as keyed pseudonyms (p1:…). Every field, why it exists and how long it is kept is in the DPO pack.

3. How a reviewer checks it

• The rule and the law. The rule's citation names the provision it applies in the open published ComplyEdge rule set, and the digest names the rule set version that ran.
• The text, against the company's own copy. The company keeps the event_id next to its own copy of the prompt. It sends the pair to POST /v1/audit/verify, and the answer says whether this record was about exactly that text. ComplyEdge never stores the prompt or the AI's answer, so the text comes from the company and is not kept. Step by step: how audit reconciliation works.
• The record set, offline. Every plan's export carries the hash chain each record joined as it was written, and the reference verifier (python3 -I conformance/adcr_verify.py export.json --trust-anchors anchors.pem --profile profile.json) reports any edit, gap or reordering. Tamper-evident means detectable, not impossible.

4. What this record does not show

• What the text said. Only the company's copy shows that.
• Calls that were never sent for a check. The record set is complete only for the calls routed through the service.
• That the AI system as a whole is lawful. A block on one request is a decision about that request, under one rule. Article 5 applies to the practice; a text rule decides on the text in front of it.

For the reviewer's side of all of this, in one place: for auditors and certifiers.