EU AI Act

Regulation (EU) 2024/1689, known as the EU AI Act, imposes logging, traceability, and post-market monitoring requirements on providers and deployers of high-risk AI systems. This page documents how chio's receipts, Merkle checkpoints, DPoP binding, and evidence export align with the Act's technical articles. It frames chio as infrastructure that supplies Article 19-grade logs, not as a certified AI system.

Article 19: Automatically Generated Logs

Article 19(1) requires high-risk AI systems to automatically generate logs of their operation for a period appropriate to the intended purpose, with sufficient detail to enable traceability of the system's actions during its lifetime. Chio satisfies this at the tool-invocation layer without any manual recording.

Every tool call produces a signed receipt:

• Automatic: the kernel emits a receipt on every allow and every deny. There is no code path that produces a decision without a corresponding signed record.
• Tamper-evident: every batch of receipts is Merkle-committed into a signed kernel checkpoint. Any alteration after the fact breaks the Merkle root.
• Attributable: every receipt carries capability_id, tool_server, tool_name, policy_hash, parameter_hash, decision, and a kernel key reference.
• Cost-tracked: monetary invocations embed FinancialReceiptMetadata recording cost_charged, attempted_cost, and settlement_status.

{
  "receipt_id": "rcpt-01HQ...",
  "sequence": 31417,
  "capability_id": "cap-01HQ...",
  "tool_server": "billing-api",
  "tool_name": "charge.create",
  "parameter_hash": "sha256:5b7f...",
  "decision": "allow",
  "policy_hash": "sha256:a39c...",
  "kernel_key": "ed25519:80f2b577...",
  "guard_evidence": [
    { "guard": "velocity", "verdict": "ok" },
    { "guard": "secret_leak", "verdict": "ok" }
  ],
  "financial": {
    "cost_charged_usd_cents": 1250,
    "attempted_cost_usd_cents": 1250,
    "settlement_status": "succeeded"
  },
  "emitted_at_unix": 1768042512,
  "signature": "ed25519:4e2f..."
}

Denials Carry Equal Weight

Article 19 expects logs to record denied operations with sufficient detail for audit. Chio's kernel fails closed: every error path, every guard denial, and every revocation hit produces a signed deny receipt with the same field set as allow. There is no code path that emits a decision and no receipt.

# Filter the receipt store for deny events.
$ chio receipts query \
    --receipt-db ./receipts.sqlite3 \
    --decision deny \
    --since 2026-04-01T00:00:00Z

# Pull the first deny receipt and verify its signature against the kernel key.
$ chio receipts verify \
    --receipt-db ./receipts.sqlite3 \
    --receipt-id rcpt-01HQ0A...

Annex IV: Retention and Archival

Annex IV Section 2(g) expects records to be retained for a period appropriate to the intended purpose and to remain accessible for post-hoc review. Chio's retention config ships with configurable time-based and size-based rotation plus checkpoint-preserving archival.

Annex IV Section 7: Tamper-Evident Monitoring

Annex IV Section 7 expects technical documentation to describe measures that ensure log integrity. Chio's Merkle checkpoint pipeline is the implementation answer.

• Every checkpoint-sized batch of receipts produces a signed KernelCheckpoint carrying the Merkle root over the batch.
• Individual receipts can be verified to belong to the log via Merkle inclusion proofs, without re-reading the full batch.
• Archived receipts remain verifiable against checkpoint rows copied into the archive database.
• The checkpoint signature is canonical JSON (RFC 8785) signed by the kernel's Ed25519 keypair, so an auditor can verify the signature with public information alone.

# Build an inclusion proof for a specific receipt.
$ chio checkpoint prove \
    --receipt-db ./receipts.sqlite3 \
    --receipt-id rcpt-01HQ0A...

# Verify the proof against the signed checkpoint root.
$ chio checkpoint verify \
    --proof ./proof.json \
    --checkpoint ./checkpoint.json \
    --kernel-pubkey ed25519:80f2b577...

Article 14: Human Oversight

Article 14 requires that high-risk AI systems enable human oversight. Actions must be attributable to the invoking entity, replay of oversight evidence must be prevented, and stale oversight material must be rejected.

Article 9: Risk Management

Article 9 requires risk management that addresses monetary and operational consumption of AI systems. Chio's budget and velocity primitives are the tool-layer implementation.

• max_total_cost and max_cost_per_invocation are enforced atomically inside the kernel. Exhaustion produces a signed deny receipt.
• Velocity guards cap invocation rate and spend rate across time buckets, preventing runaway consumption.
• Allow receipts for monetary actions record the actual charged cost reported by the tool server, so downstream reconciliation can compare intended and actual cost.
• Deny receipts for monetary denials record the attempted cost and the reason, so non-execution is evidenced.

apiVersion: chio.dev/v1
kind: ToolGrant
metadata:
  name: quarterly-billing-agent
spec:
  capability_id: cap-billing-q2
  tool_server: billing-api
  tools:
    - charge.create
    - refund.create
  budget:
    max_total_cost_usd_cents: 500000
    max_cost_per_invocation_usd_cents: 2000
  velocity:
    calls_per_minute: 10
    calls_per_hour: 400
    calls_per_day: 2000
  expires_at: 2026-06-30T23:59:59Z
  autonomy_tier: TIER_2_DELEGATED

Article 50: Transparency

Article 50 imposes transparency obligations on certain AI systems, including the obligation to identify that the user is interacting with an AI system and to disclose the acting entity. Chio's identity stack is built to surface the actor on every call.

• The capability subject is a did:chio identifier. Every receipt carries that subject, so downstream consumers can name the acting entity in human-readable terms.
• WorkloadIdentity metadata on the capability can include operator-chosen display attributes. This is how a tool server can say "this call came from the quarterly billing agent operated by Acme Inc.".
• Agent passports bundle the subject's reputation and attribution into a signed artifact the downstream counterparty can show to its own users, so the transparency chain does not rely on out-of-band identity claims.

Article 72: Post-Market Monitoring

Article 72 introduces post-market monitoring obligations. Providers must observe their deployed system, collect data on its performance, and report serious incidents. Chio's receipt query API and reputation surfaces are the post-deployment observability layer.

Annex III High-Risk Systems

Annex III lists categories of systems that are treated as high-risk: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice. Agents that call tools in these domains benefit from chio's fail-closed posture:

• Fail-closed default: every unknown tool, every expired capability, every revoked capability, every evaluation error produces a deny receipt rather than a silent allow.
• Signed evidence as default: there is no code path that invokes a tool without emitting a signed receipt. Audit material is produced as a side effect of normal operation.
• Explicit autonomy tiers: GovernedAutonomyTier names the level of human involvement expected for each capability. Sensitive categories stay at tiers that require step-up approval.
• Revocation latency bounded: revocations propagate across the cluster on the next repair sync; edges re-check on every call.

Pipeline Diagram

Verification Commands

# Confirm every call in a window emitted a signed receipt.
$ chio receipts audit-coverage \
    --receipt-db ./receipts.sqlite3 \
    --since 2026-04-01T00:00:00Z

# Verify Merkle checkpoints for the window.
$ chio checkpoint verify-range \
    --receipt-db ./receipts.sqlite3 \
    --since 2026-04-01T00:00:00Z \
    --kernel-pubkey ed25519:80f2b577...

# Build the Article 19 evidence bundle for the quarter.
$ chio evidence export \
    --policy ./policy.yaml \
    --receipt-db ./receipts.sqlite3 \
    --since 2026-01-01T00:00:00Z \
    --until 2026-03-31T23:59:59Z \
    --output ./q1-article-19-bundle

Non-Goals

• Chio does not perform conformity assessment. It supplies the logs an assessor inspects.
• Chio does not register AI systems in the EU database (Annex VIII). Registration remains the provider's responsibility.
• Chio does not evaluate model-layer properties such as bias, robustness under distribution shift, or hallucination rate.
• Chio's evidence posture does not replace the technical file (Annex IV). It supplies inputs that populate sections about logging, oversight, and monitoring.

For the process-oriented management-system framing of these controls, continue with ISO/IEC 42001. For the operational log surface itself, see Receipts and Receipt Query API.