June 10, 2026 · 7 min read

How to Comply with EU AI Act Article 12 Using Aira

Article 12 of the EU AI Act requires automatic logging of AI system activities throughout their lifecycle. Enforceable from August 2026, non-compliance carries fines up to €15M or 3% of global turnover. This guide walks through exactly how Aira's authorize/notarize flow satisfies every logging requirement — with code examples, architecture details, and compliance report generation.

What Article 12 Actually Requires

Article 12 ("Record-keeping") is deceptively short but technically demanding. It mandates that high-risk AI systems include "logging capabilities that enable the recording of events relevant to identifying situations that may result in the AI system presenting a risk" and allow for "post-market monitoring."

Broken down, the regulation requires five things:

Automatic logging — the system must record events without manual intervention
Traceability — each decision must be traceable to inputs, models, and policies
Tamper evidence — logs must be resistant to post-hoc modification
Lifecycle coverage — logging must span development, deployment, and operation
Risk identification — logs must be sufficient to identify when the system poses a risk

Most observability tools (Datadog, Splunk, CloudWatch) satisfy requirement #1 and stop there. They produce mutable logs stored in infrastructure the operator controls. A regulator or auditor has no way to verify those logs haven't been edited. Article 12 demands more than "we logged it." It demands proof.

The Authorize/Notarize Pattern

Aira's compliance model is built around two API calls that bracket every AI decision: authorize() before execution and notarize() after. Together, they produce a cryptographic chain that satisfies all five Article 12 requirements automatically.

from aira import Aira

aira = Aira(api_key="aira_live_xxx")

# STEP 1: Authorize — before the AI acts
auth = aira.authorize(
    action_type="credit_decision",
    details="Evaluate loan application #LA-9921. Applicant income: €72K, requested: €180K, credit score: 761.",
    agent_id="credit-underwriting-agent",
    model_id="claude-sonnet-4-6",
    metadata={
        "application_id": "LA-9921",
        "risk_category": "high",
        "regulatory_framework": "eu_ai_act",
    },
)

# Aira evaluates all matching policies:
# - "High-value credit decisions require consensus" → triggers 3-model eval
# - "Loans > €150K require human approval" → queues for compliance officer
#
# auth.status == "pending_approval"
# auth.action_uuid == "act_8f3a2b..."
# auth.policy_evaluations == [{ policy, decision, reasoning, receipt_id }]

# STEP 2: Wait for human approval (if required)
# Compliance officer receives email with Approve/Deny links
# Officer clicks Approve → auth.status becomes "approved"

# STEP 3: Execute the AI action
result = execute_credit_decision("LA-9921")

# STEP 4: Notarize — after execution
receipt = aira.notarize(
    action_uuid=auth.action_uuid,
    outcome="completed",
    outcome_details=f"Loan approved for €180K at 4.2% APR. Decision: {result.decision}",
    metadata={
        "final_decision": result.decision,
        "interest_rate": "4.2%",
        "model_confidence": result.confidence,
    },
)

# receipt.receipt_id == "rct_7d4e1a..."
# receipt.signature == "ed25519:..."  (Ed25519 digital signature)
# receipt.timestamp == "2026-06-10T14:32:00Z"  (RFC 3161)
# receipt.payload_hash == "sha256:..."  (SHA-256 of full context)

Every field that Article 12 requires is captured automatically: the action type, the models involved, the policies that evaluated, the human who approved, the final outcome, and cryptographic proof tying it all together.

Cryptographic Audit Trail: Why Logs Aren't Enough

Traditional logs fail Article 12's tamper-evidence requirement for a simple reason: the operator controls the logs. A company can edit, delete, or backdate any log entry in their own infrastructure. Regulators know this.

Aira produces cryptographic receipts instead of log entries. Each receipt contains three layers of proof:

Ed25519 digital signature — a public-key signature that proves the receipt was issued by Aira and hasn't been modified. Anyone with Aira's public key can verify it independently.
RFC 3161 trusted timestamp — issued by an independent Timestamp Authority (TSA), not by Aira. This proves when the event occurred, even if Aira's own systems are compromised.
SHA-256 payload hash — a fingerprint of the entire action context (inputs, models, policies, verdicts, approvals). Any modification to any field invalidates the hash.

These receipts form an immutable chain. The authorization receipt references the policy evaluation receipts. The notarization receipt references the authorization. A human approval receipt sits between them. The entire decision lineage is cryptographically linked.

# Receipt chain for a single governed action:
#
# 1. Policy evaluation receipt  (rct_pol_001)
#    → Ed25519 sig + RFC 3161 timestamp
#    → Proves which policies evaluated and what they decided
#
# 2. Consensus receipt  (rct_con_001)
#    → Proves 3 models evaluated: Claude (APPROVE), GPT-5.2 (APPROVE), Gemma 4 (REVIEW)
#    → Agreement score: 0.67
#
# 3. Human approval receipt  (rct_apr_001)
#    → Proves compliance@bank.eu approved at 2026-06-10T14:32:00Z
#    → Links to rct_pol_001 and rct_con_001
#
# 4. Notarization receipt  (rct_not_001)
#    → Proves final outcome: loan approved at 4.2% APR
#    → Links to rct_apr_001, completing the chain
#
# Each receipt is independently verifiable at:
# GET /verify/receipt/{receipt_id}
# No authentication required. No Aira account needed.

Compliance Report Generation

Article 12 compliance isn't just about having logs — it's about producing structured reports for auditors and national authorities. Aira generates compliance reports on demand, covering any time period, agent, or policy.

# Generate an Article 12 compliance report via the API
report = aira.reports.generate(
    report_type="eu_ai_act_article_12",
    date_from="2026-01-01",
    date_to="2026-06-10",
    agent_ids=["credit-underwriting-agent", "fraud-detection-agent"],
    format="pdf",  # or "json" for machine-readable
)

# report.download_url → signed URL, valid 24 hours
# report.summary:
#   total_actions: 14,821
#   governed_actions: 14,821  (100% coverage)
#   policy_evaluations: 29,642
#   human_approvals: 1,203
#   consensus_evaluations: 8,912
#   receipts_generated: 54,478
#   receipt_verification_rate: 100%

The report includes every data point an auditor needs: action volumes, policy coverage rates, consensus scores, human intervention frequency, approval latencies, and a complete receipt inventory. Each receipt in the report can be independently verified using its ID.

Traceability: From Decision to Evidence

Article 12 requires that events are logged in a way that enables tracing decisions back to their causes. Aira's receipt chain provides exactly this. Given any action, you can reconstruct the full decision path:

What triggered the action? — The agent ID, action type, and input context are recorded in the authorization receipt.
Which policies applied? — Every matching policy and its verdict are recorded with individual receipts.
Which models evaluated? — In consensus mode, each model's response, reasoning, and agreement score are captured.
Did a human intervene? — The approver's identity, timestamp, and decision are recorded.
What was the outcome? — The notarization receipt captures the final result and any post-execution metadata.

This chain is queryable via the API and searchable in the Aira dashboard. Compliance teams can filter by agent, policy, time range, or risk category. When a regulator asks "show me every high-risk credit decision from Q1 2026," the answer is one API call away.

RFC 3161 Timestamps: Independent Time Proof

One subtlety of Article 12 that most implementations miss: the timestamps must be trustworthy. If your logging system timestamps its own events, you're self-attesting. A regulator has no reason to trust that your system clock wasn't manipulated.

Aira uses RFC 3161 trusted timestamps issued by an independent Timestamp Authority. The TSA is a third party — it has no relationship with Aira or the operator. When a receipt is minted, its hash is sent to the TSA, which returns a signed timestamp token. This proves the receipt existed at a specific point in time, independent of any party's infrastructure.

This matters for regulatory investigations. If a bank claims a credit decision was made before a policy change, the RFC 3161 timestamp proves it. If a company claims they implemented governance before a compliance deadline, the timestamps prove when receipts started being generated.

Merkle Tree Settlements: Batch Verification

For high-volume systems processing thousands of actions per day, Aira periodically settles receipt batches into Merkle trees. Each tree root is a single hash that summarizes an entire batch of receipts. An auditor can verify the entire batch by checking one hash, then drill down into individual receipts as needed.

This is particularly useful for Article 12's "post-market monitoring" requirement. National authorities can request Merkle roots for specific time periods and verify that no receipts have been added, removed, or modified since settlement.

Integration: Two Lines of Code

The most common objection to governance infrastructure is integration cost. "We can't refactor our entire pipeline for compliance." With Aira, you don't. The authorize/notarize pattern wraps around your existing code:

# Your existing agent code — unchanged
def process_application(app_id: str) -> Decision:
    data = fetch_application(app_id)
    decision = model.evaluate(data)
    return decision

# Add governance: 2 calls, no refactoring
auth = aira.authorize(
    action_type="credit_decision",
    details=f"Evaluate application {app_id}",
    agent_id="credit-agent",
    model_id="claude-sonnet-4-6",
)

if auth.status in ("approved", "auto_approved"):
    result = process_application(app_id)

    receipt = aira.notarize(
        action_uuid=auth.action_uuid,
        outcome="completed",
        outcome_details=f"Decision: {result.decision}",
    )
    # Article 12 compliance: done.

No changes to your model, your pipeline, or your infrastructure. Policies are configured in the dashboard by compliance teams. When regulations change, policies update — no code redeployment.

What Auditors Actually Ask For

We've worked with compliance teams at banks, insurers, and healthcare providers preparing for August 2026. The questions they get from auditors and national authorities follow a predictable pattern:

"Show me all AI-driven decisions in the last 90 days." — Dashboard filter + API query.
"Prove this decision was made before the policy change." — RFC 3161 timestamp on the receipt.
"How do I know these logs haven't been tampered with?" — Ed25519 verification at /verify/receipt/{id}.
"Was a human involved in this high-risk decision?" — Human approval receipt in the chain.
"Which models were used and did they agree?" — Consensus receipt with individual model verdicts.

Every answer is backed by cryptographic proof. Not a screenshot of a dashboard. Not a CSV export. A cryptographic receipt that anyone can verify independently.

Getting Started Before August 2026

Article 12 enforcement begins August 2, 2026. If your organization deploys high-risk AI systems in the EU, the time to implement logging infrastructure is now — not after the first audit request arrives.

# Install the SDK
pip install aira-sdk

# Start governing your AI actions today
from aira import Aira

aira = Aira(api_key="aira_live_xxx")

# Every authorize() + notarize() pair creates a complete
# Article 12 audit trail — automatically.
#
# Configure policies at: https://airaproof.com/dashboard/policies
# Generate reports at:   https://airaproof.com/dashboard/reports

Two API calls. Cryptographic receipts. RFC 3161 timestamps. Compliance reports. Full Article 12 coverage. Governance becomes infrastructure — not a last-minute scramble before the deadline.

Try Aira — free Read the docs