ComplianceMarch 2026 · 10 min read

How the EU AI Act's Article 13 Changes How We Build Software

The liability sits at runtime. Here is what the Act demands in practical engineering terms.

By the ADJUDON Compliance Team

What Article 13 Actually Means at the Code Level

Article 13 of the EU AI Act mandates "transparency and provision of information to deployers." In non-legal terms, this means: if your AI system makes a decision, you must be able to explain how it arrived at that decision, in a way that is auditable and reproducible.

This is not a UX problem. This is not a documentation problem. This is a runtime instrumentation problem.

For every decision your AI makes, you need to log:

The input that triggered the decision
The model version and configuration used
The confidence score or uncertainty estimate
The reasoning path or chain-of-thought (if applicable)
Whether a human reviewed or overrode the decision
The timestamp and user context

And crucially: this log must be immutable and tamper-proof. You cannot edit it after the fact. You cannot delete entries. You cannot backfill missing data when an auditor shows up.

What Article 14 Means for Your System Architecture

Article 14 builds on Article 13 by introducing the concept of "human oversight". This is where things get architecturally interesting.

The Act distinguishes between three types of oversight:

Human-in-the-loop: A human approves every decision before it is executed.
Human-on-the-loop: A human can intervene and override decisions in real-time.
Human-in-command: A human can deactivate the system at any time.

For high-risk AI systems (which includes most enterprise use cases), you need all three.

This means your architecture must support:

A review queue for decisions that require human approval
A real-time dashboard for monitoring and intervention
A kill switch that can halt all AI decision-making instantly
A fallback mechanism to route decisions to human operators when confidence is low

A Concrete Example: Automated Loan Decisioning

Let's say you're building an AI system that approves or denies loan applications. Here's what a compliant implementation looks like:

const decision = await ai.evaluate(application);

// Article 13: Log the decision
await auditLog.record({
  input: application,
  modelVersion: ai.version,
  confidence: decision.confidence,
  reasoning: decision.reasoning,
  timestamp: Date.now(),
  user: currentUser.id
});

// Article 14: Human oversight routing
if (decision.confidence < 0.85) {
  await reviewQueue.enqueue({
    applicationId: application.id,
    aiRecommendation: decision,
    requiresHumanApproval: true
  });
} else {
  await executeDecision(decision);
}

Notice what's happening here:

Every decision is logged before it is executed
Low-confidence decisions are routed to human review
The AI's recommendation is preserved even if a human overrides it
The entire chain is auditable and reproducible

What Changes for Engineering Teams

The EU AI Act fundamentally changes how you think about AI deployment. You can no longer treat an LLM as a black box API call. Instead, you need to build:

Confidence scoring: Every AI output must include a confidence metric
Policy-based routing: Decisions are routed based on confidence and risk level
Immutable audit logs: Every decision is logged with full context
Human review workflows: Low-confidence decisions go to human operators
Override mechanisms: Humans can intervene at any stage
Kill switches: The entire system can be halted instantly

This is not optional. This is not a "nice to have." This is the legal baseline for deploying AI in the EU starting in 2026.

And if you're thinking "we'll just wait and see," consider this: the penalties for non-compliance are up to €35 million or 7% of global annual turnover, whichever is higher.

From ADJUDON Engineering

ADJUDON provides the Confidence Engine, Policy Router, and immutable Audit Log as a single SDK integration — without latency overhead. Purpose-built for EU AI Act Article 13 and 14 compliance.

ComplianceMarch 2026 · 10 min read

How the EU AI Act's Article 13 Changes How We Build Software

The liability sits at runtime. Here is what the Act demands in practical engineering terms.

By the ADJUDON Compliance Team

When the EU AI Act's obligations for high-risk AI systems became enforceable, most discussions inside engineering teams focused on the wrong thing: model selection, training data governance, bias testing. Important topics, but not the ones that create the liability.

The liability sits at runtime. Article 13 does not ask what model you are running. It asks whether you can prove, to a regulator and to an affected individual, that your system operated transparently.

What Article 13 Actually Means at the Code Level

The Act's transparency requirement sounds abstract until you read Recital 47, which specifies that transparency includes the ability to explain the individual outputs and the logic behind them. For an AI agent making a real-time decision — approving a loan, assigning a triage priority, routing an insurance claim — this means every output must carry a traceable record of:

The input context that informed the decision
The confidence level, independently evaluated
The routing outcome — pass, flag, mask, or hold
A tamper-evident cryptographic fingerprint of the entire decision event

A log file in a database does not meet this requirement unless it is cryptographically anchored. This is not a philosophical difference — it is exactly what a compliance auditor will check.

What Article 14 Means for Your System Architecture

Human oversight under Article 14 is more demanding than it sounds. The Act does not require that a human could intervene — it requires that the system is designed so that humans do intervene in cases where the risk profile warrants it. Specifically, the system must be capable of:

1. Detecting when intervention is appropriate — which requires a meaningful signal about its own uncertainty. A model that does not know when it is guessing cannot reliably escalate.

2. Enforcing that intervention — meaning it must have the architectural capability to pause execution and route to a human queue, not just log a warning and continue.

3. Giving the reviewer everything they need — the full context, confidence assessment, and policy trigger must be surfaced in a usable format. An auditor will distinguish between genuine oversight and the appearance of oversight.

A Concrete Example: Automated Loan Decisioning

Without a compliance layer:

User application → LLM inference → Approval/Rejection → Database

Every output is acted on immediately. No audit record. No confidence signal. No human intervention point.

With a compliance layer:

User application → LLM inference → [Evaluate: CPI score, PII check, Policy routing]
                       ↓
           CPI > 0.85:  approve, log, commit
           CPI 0.65–0.85: mask PII, log, flag for review
           CPI < 0.65:  hold, route to human queue, log

The audit trail captures every branch. The human reviewer receives full context. The cryptographic log is exportable to regulators on demand.

What Changes for Engineering Teams

If your organisation is deploying autonomous AI into high-risk workflows, compliance is not a legal checkbox — it is an engineering deliverable, and it needs to be in the sprint. The specific work required:

Add an evaluation layer between model inference and action
Implement deterministic policy routing using confidence score and output metadata
Build a structured human review queue with complete decision context
Implement cryptographic audit logging before action, not after
Ensure all of this runs in under 10ms on your critical path

The question is not whether to build it. The question is how fast.

From ADJUDON Engineering

ADJUDON provides the Confidence Engine, Policy Router, and immutable Audit Log as a single SDK integration — without latency overhead. Purpose-built for EU AI Act Article 13 and 14 compliance.

EU AI Act Guide →Book a demo →