2026-06-08·5 min read·sota.io Team

EU AI Act Art.12 & Art.19 Record-Keeping: Why Your Log Storage Jurisdiction Matters

Post #1 in the sota.io EU AI Act Infrastructure Compliance Series

EU AI Act Art.12 record-keeping and Art.19 log storage: CLOUD Act jurisdiction risk for high-risk AI systems

With 55 days until the EU AI Act's August 2, 2026 full enforcement deadline, high-risk AI providers are scrambling to implement compliance obligations. Most technical guides focus on the process: risk management systems, conformity assessment, technical documentation. Fewer focus on the infrastructure question that underpins all of it: where do your audit logs live, and who can compel access to them?

This guide covers Articles 12 and 19 of Regulation (EU) 2024/1689 — the record-keeping and automatic log generation requirements for high-risk AI systems — and why the jurisdiction of your log storage infrastructure is a compliance variable, not a deployment detail.


What Art.12 Actually Requires

Article 12 — Record-keeping applies to providers of high-risk AI systems listed in Annex III. The obligation is specific:

High-risk AI systems shall technically allow for the automatic recording of events ('logs') throughout the lifetime of the system. Such logging capabilities shall ensure a level of traceability appropriate to the intended purpose of the system.

Three compliance obligations flow from this:

1. Logs must be automatically generated — Not manually created, not reconstructed after incidents. The system itself must produce them. This means your AI inference pipeline, monitoring layer, and decision-making components need structured log emission baked in at build time.

2. Logs must cover the "lifetime of the system" — From market release through decommissioning. For a deployed high-risk AI system, this means log retention planning over years, not months.

3. Logs must enable "traceability appropriate to the intended purpose" — This is deliberately outcome-based language. For a credit-scoring AI (Annex III), traceability means reconstructing why a specific decision was made for a specific individual at a specific time. For a biometric identification system, it means reconstructing what data was processed and when.

What Art.19 Adds

Article 19 — Automatically generated logs complements Article 12 with a minimum retention standard:

Providers of high-risk AI systems shall retain the logs automatically generated by their high-risk AI systems, to the extent such logs are under their control, for a period that is appropriate and proportionate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in applicable Union or national law or in Union or national law applicable to the deployer.

Key constraints:


The CLOUD Act Jurisdiction Problem

Here's where infrastructure decisions become compliance variables.

The US Clarifying Lawful Overseas Use of Data (CLOUD) Act (18 U.S.C. § 2713) requires US cloud providers — Microsoft, Google, Amazon, Oracle — to comply with US law enforcement requests for data stored anywhere in the world, including EU-based data centers.

For EU AI Act compliance, this creates a specific risk pattern:

Scenario: National Competent Authority (Art.74) investigates a serious incident

Your log trail for Art.12/19 compliance lives in:
  → AWS CloudWatch (eu-west-1, Frankfurt)
  → Azure Monitor (Germany West Central)
  → GCP Cloud Logging (europe-west3)

US DOJ issues CLOUD Act request to AWS/Microsoft/Google
  → Cloud provider receives and evaluates request
  → Data can be compelled without EU judicial review
  → Your "complete audit trail" now has a sovereignty gap

The NCA asking "show me the complete record of decisions made by your system" expects logs that have not been accessed or altered by a third-party legal process. A CLOUD Act-compelled disclosure creates a chain-of-custody break in your audit evidence.

This is not hypothetical. The DOJ's CLOUD Act request volume has grown ~40% year-over-year since the law took effect.


What the EU AI Act Says About NCA Access

Article 74 — Market Surveillance gives National Competent Authorities (NCAs) the right to:

request that providers and deployers take all necessary corrective actions to bring the AI system into conformity, to withdraw the AI system from the market, to recall it, or to restrict its availability

NCAs can also request access to training data, technical documentation, and — critically — the automatically generated logs required by Articles 12 and 19.

When an NCA exercises this right, they expect:

  1. Complete logs — no gaps from third-party compelled disclosure
  2. Tamper-evident logs — the chain of custody is clear
  3. Jurisdictionally accessible logs — no bilateral legal treaty required to access them

If your logs reside on US-jurisdictioned infrastructure, satisfying an NCA request may require the NCA to invoke mutual legal assistance treaty (MLAT) procedures — or accept logs whose integrity you cannot fully vouch for.


Implementing Art.12/19-Compliant Log Infrastructure

Pattern 1: EU-Native Log Pipeline

The most straightforward compliance architecture routes all AI system logs through EU-jurisdictioned infrastructure from the point of generation:

// EU-native structured logging for Art.12/19 compliance
import { createLogger } from 'winston';
import { createWinstonLogger } from '@sotaio/eu-native-logs';

const aiSystemLogger = createLogger({
  // All transport targets must be EU-native, non-US-parented
  transports: [
    new EUNativeTransport({
      endpoint: process.env.EU_LOG_ENDPOINT,  // sota.io / Hetzner / OVH / Scaleway
      retention_days: 180,  // Art.19 minimum 6 months
      encryption: 'AES-256-GCM',
      jurisdiction: 'EU',
    })
  ],
  defaultMeta: {
    system_id: process.env.AI_SYSTEM_ID,
    regulation: 'EU_AI_ACT_2024_1689',
    article: 'Art12_Art19',
  }
});

// Art.12-compliant event logging for high-risk AI decisions
function logHighRiskDecision(decision: AIDecision): void {
  aiSystemLogger.info('ai_decision', {
    timestamp: new Date().toISOString(),
    system_version: process.env.SYSTEM_VERSION,
    decision_id: decision.id,
    subject_pseudonym: decision.subjectPseudonym,  // GDPR-compliant
    input_hash: decision.inputHash,  // Hash, not raw data
    output: decision.output,
    confidence: decision.confidence,
    model_version: decision.modelVersion,
    // Art.12: traceability chain
    upstream_data_sources: decision.dataSources,
    human_oversight_required: decision.highRisk,
  });
}

Pattern 2: Log Integrity Verification

For NCA audit purposes, logs must be verifiable. A tamper-evident log chain uses cryptographic chaining:

import { createHash } from 'crypto';

interface LogEntry {
  timestamp: string;
  event_type: string;
  data: Record<string, unknown>;
  previous_hash: string;
  entry_hash: string;
}

class Art12LogChain {
  private lastHash: string = '0'.repeat(64);  // Genesis block

  append(event_type: string, data: Record<string, unknown>): LogEntry {
    const timestamp = new Date().toISOString();
    const entry_content = JSON.stringify({ timestamp, event_type, data, previous_hash: this.lastHash });
    const entry_hash = createHash('sha256').update(entry_content).digest('hex');
    
    const entry: LogEntry = {
      timestamp,
      event_type,
      data,
      previous_hash: this.lastHash,
      entry_hash,
    };
    
    this.lastHash = entry_hash;
    return entry;
  }

  verifyChain(entries: LogEntry[]): boolean {
    let expectedPrevHash = '0'.repeat(64);
    for (const entry of entries) {
      if (entry.previous_hash !== expectedPrevHash) return false;
      const content = JSON.stringify({
        timestamp: entry.timestamp,
        event_type: entry.event_type,
        data: entry.data,
        previous_hash: entry.previous_hash,
      });
      const computedHash = createHash('sha256').update(content).digest('hex');
      if (computedHash !== entry.entry_hash) return false;
      expectedPrevHash = entry.entry_hash;
    }
    return true;
  }
}

This gives you an immutable, verifiable audit chain that an NCA can independently verify without needing access to a US-jurisdictioned cloud provider.

Pattern 3: Retention Policy Enforcement

Art.19's six-month minimum requires programmatic retention enforcement:

# EU-native log retention policy (Kubernetes / Docker Compose)
# Deploy on EU-hosted infrastructure (Hetzner, OVH, Scaleway, sota.io)

version: "3.8"
services:
  ai-log-store:
    image: loki:latest
    environment:
      - RETENTION_PERIOD=180d  # Art.19 minimum 6 months
      - JURISDICTION=EU        # Document in technical docs (Art.11)
      - PROVIDER=sota_io       # Non-US-parented cloud provider
    volumes:
      - log-data:/loki/data
    # EU-only deployment constraint
    deploy:
      placement:
        constraints:
          - node.labels.datacenter==hetzner-nbg  # Nuremberg, Germany

The Deployer Obligation Chain

Article 26 — Obligations of deployers creates a downstream obligation: deployers must inform providers if they observe "serious risks or incidents." This means:

  1. Your deployers' logs are part of your compliance picture — A SaaS platform deploying your high-risk AI must be contractually obligated to retain and provide you with their logs
  2. Cross-border deployer relationships — If your deployer is in the EU but stores logs on US infrastructure, the chain-of-custody problem propagates downstream
  3. Contract requirements — Art.26 obligations must be reflected in your deployer agreements

A minimal Art.26-compliant deployer contract addendum for log jurisdiction:

### Log Storage and Jurisdiction Requirements (EU AI Act Art.12/19/26)

Deployer shall:
1. Store all AI system decision logs on infrastructure located in the EU and operated 
   by providers without US parent company exposure to the US CLOUD Act.
2. Retain such logs for a minimum of 6 months from the date of generation.
3. Provide Provider access to logs within 48 hours of written request.
4. Notify Provider of any third-party legal process (including foreign law enforcement 
   requests) relating to AI system logs within 24 hours of receipt.
5. Document log storage jurisdiction in Deployer's technical documentation.

Jurisdiction Selection Guide for Art.12/19 Compliance

ProviderEU DatacentersUS Parent CompanyCLOUD Act ExposureArt.12/19 Safe?
AWS (eu-central-1)✅ Frankfurt✅ Amazon.com Inc✅ Yes❌ No
Azure (Germany WC)✅ Frankfurt✅ Microsoft Corp✅ Yes❌ No
GCP (europe-west3)✅ Frankfurt✅ Alphabet Inc✅ Yes❌ No
Hetzner✅ Germany/Finland❌ EU-only❌ No✅ Yes
OVHcloud✅ 8 EU DCs❌ FR-only❌ No✅ Yes
Scaleway✅ France/NL❌ Iliad Group❌ No✅ Yes
IONOS✅ Germany❌ United Internet AG❌ No✅ Yes
sota.io✅ Hetzner DE❌ EU-native PaaS❌ No✅ Yes

Art.12/19 Compliance Checklist (55 Days to Deadline)

Infrastructure (before August 2, 2026):

Documentation (Art.11 Technical Documentation):

Contracts (Art.26 deployer chain):

Incident Readiness (Art.73):


What Comes Next in This Series

This is the first post in our EU AI Act Infrastructure Compliance series. Upcoming posts cover:

If you're deploying AI systems that fall under EU AI Act Annex III high-risk categories, the infrastructure questions in this series determine whether your compliance documentation will hold up under NCA scrutiny.


sota.io is an EU-native managed PaaS (Hetzner Germany, no US parent) designed for developers building GDPR-compliant and EU AI Act-aligned applications. No CLOUD Act exposure. Deploy any language from git. From €9/month.

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.