EU AI Act Summary: What Actually Binds a Deployer

The reason is structural: the headline obligations of Regulation (EU) 2024/1689 sit on the provider — conformity assessment, technical documentation, the compute thresholds that designate systemic risk. An operator running inference on its own GPUs finds no chair with its name on it, and either concludes the Act does not apply or that all of it does.

Neither is right, and the correction is an ordering rather than a longer list: classification and role are separate tests, decided independently, and the obligation list falls out of the pair. What follows is the deployer's version, dated against the consolidated text.

The Deployer's List, and the Date It Starts

Article 3(4) defines a deployer as "a natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity". A wide net: a retrieval-augmented assistant for your own staff is inside it, and so is a batch job calling a model.

The net is wide because the definition does nothing on its own. Article 26 opens "Deployers of high-risk AI systems shall…" — every paragraph is addressed to deployers of high-risk systems, not to deployers. So what decides your list is whether the thing you deploy is high-risk under Article 6; Stribog's walkthrough of the Article 6(3) conditions and the profiling override covers that test.

The dates matter as much. Regulation (EU) 2026/1744 of 8 July 2026 — the Digital Omnibus, first amending act in the 27 July 2026 consolidation — rewrote Article 113(c) so Chapter III, Sections 1, 2 and 3, where Article 26 lives, applies "from: (i) 2 December 2027 as regards AI systems classified as high-risk pursuant to Article 6(2) and Annex III; and (ii) 2 August 2028" for those under "Article 6(1) and Annex I". Guides still putting Article 26 on 2 August 2026 predate it.

The deferral is not a reason to ignore it: Article 99(4)(e) prices non-compliance with the Article 26 deployer obligations at "up to EUR 15 000 000 or, if the offender is an undertaking, up to 3 % of its total worldwide annual turnover for the preceding financial year, whichever is higher".

Click to zoom

Deployer or Provider? Article 3 First, Then Article 25

The role test is usually taught as one question with an Article 25 twist at the end. It is two gates in order, and the first catches more self-hosted operators.

Gate one is the primary definition. Article 3(3) makes a provider of a body that "develops an AI system or a general-purpose AI model", or has one developed, "and places it on the market or puts the AI system into service under its own name or trademark". The trap sits next door: Article 3(11) defines putting into service as supply for first use "directly to the deployer or for own use in the Union". Fine-tune an open-weight model, wrap it in your own service, stand it up internally under your own name, and Article 3(3) can be met directly — no Article 25 required.

Gate two is conversion, reaching a party already a distributor, importer, deployer or third party. Article 25(1) makes it "a provider of a high-risk AI system … subject to the obligations of the provider under Article 16" on three triggers, each reaching a system "placed on the market or put into service" — and that second limb is where a purely internal deployment sits. They are: putting your name or trademark on such a system; making "a substantial modification" after which "it remains a high-risk AI system pursuant to Article 6"; or modifying "the intended purpose" of a non-high-risk one so that it "becomes a high-risk AI system".

That middle term is defined, not argued. Article 3(23) makes a substantial modification a change "not foreseen or planned in the initial conformity assessment carried out by the provider" that either affects compliance with Chapter III, Section 2, or "results in a modification to the intended purpose for which the AI system has been assessed". Adapter training inside a foreseen envelope is not automatically that; changing what the system is for generally is.

Click to zoom

What Already Binds You in September 2026

Four things need separating, and most compliance registers collapse them into one row marked "AI Act".

First, the duties that bind every deployer whatever the system class. Article 4 is one, and its text changed. As amended it requires providers and deployers to "take measures to support the development of AI literacy of their staff", then adds: "This obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual." The duty applied from 2 February 2025; this wording dates from July 2026, so guidance telling you to certify a literacy level describes a text that no longer exists.

Second, the prohibitions that are scheduled, not current. Article 113(a) excepts "Article 5(1), first subparagraph, points (ba) and (bb), and Article 5(1a) and (1b)", which "shall apply from 2 December 2026" — non-consensual intimate imagery among them. For a deployer the test is purpose, not capability: use is "only prohibited where the deployer uses the system for the purpose of generating or manipulating such material". A model that could produce such output is not thereby prohibited; a September 2026 register carries these as scheduled.

Third, Chapter IV. Article 113's list of exceptions omits Chapter IV, where Article 50 sits, so it stayed on the general 2 August 2026 date — a reading of what Article 113 leaves untouched, not a sentence the Act prints. Article 50(3) and 50(4) are the only transparency duties addressed to deployers, and both are narrow: 50(3) binds "deployers of an emotion recognition system or a biometric categorisation system"; 50(4), deployers of a system generating "image, audio or video content constituting a deep fake", and, in its second subparagraph, those publishing AI-generated text "informing the public on matters of public interest" — excepting content under "human review or editorial control". An internal RAG assistant is generally none of these — publishing its output as public-interest text is the edge that reaches 50(4).

Fourth, the deferred Chapter III duties — Article 26 and the rest of Sections 1 to 3. That is the live picture. If you also carry NIS2 or DORA duties, the overlapping-regimes piece maps the three onto one estate.

Article 26, Paragraph by Paragraph, as Infrastructure

Where classification lands on high-risk, Article 26 has twelve paragraphs — not twelve controls. Some are systems to build, one is a savings clause, one is not addressed to you.

• 26(1) — instructions-for-use measures. "[A]ppropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use accompanying the systems." Those instructions are your baseline; drift is the non-compliance.
• 26(2) — oversight with authority. Assign oversight "to natural persons who have the necessary competence, training and authority, as well as the necessary support". Authority is in the text: a roster who cannot stop the system will not do.
• 26(3) — a savings clause, preserving other obligations and "the deployer's freedom to organise its own resources and activities". Nothing to build.
• 26(4) — input data, conditionally. "[T]o the extent the deployer exercises control over the input data", it must be "relevant and sufficiently representative in view of the intended purpose".
• 26(5) — monitor, then suspend. Monitor on the basis of the instructions for use, informing providers "in accordance with Article 72". On reason to consider an Article 79(1) risk: inform the provider or distributor and the market surveillance authority "without undue delay" and "suspend the use of that system". On a serious incident, inform "first the provider, and then the importer or distributor and the relevant market surveillance authorities".
• 26(6) — a six-month floor on automatically generated logs, "to the extent such logs are under their control".
• 26(7) — workplace notice. Before workplace use, employers "shall inform workers' representatives and the affected workers".
• 26(8) — registration, for public bodies only. Deployers "that are public authorities, or Union institutions, bodies, offices or agencies" comply with Article 49, and where the system is unregistered "shall not use" it.
• 26(9) — DPIA input from the provider's Article 13 information, for the GDPR Article 35 assessment.
• 26(10) — probably not yours. It binds "the deployer of a high-risk AI system for post-remote biometric identification" in a criminal investigation, needing authorisation ex ante or within 48 hours.
• 26(11) — tell the person. Deployers of Annex III systems "that make decisions or assist in making decisions related to natural persons shall inform" them.
• 26(12) — cooperate with competent authorities acting on the system.

Two paragraphs redirect financial institutions rather than adding to them: 26(5)'s monitoring duty is "deemed to be fulfilled" by internal-governance compliance under Union financial services law, and 26(6)'s logs sit inside "the documentation kept pursuant to" it.

Article 27's fundamental rights impact assessment is narrower still, and routinely misattributed to all deployers: it binds public-law bodies, "private entities providing public services, and deployers of high-risk AI systems referred to in points 5 (b) and (c) of Annex III" — credit scoring, and life and health insurance pricing.

One Retention Plane: Article 26(6), CERT-In, DPDP — and DORA's Own Rule

Article 26(6) turns into infrastructure fastest, and its qualifiers do the work: keep logs "to the extent such logs are under their control, for a period appropriate to the intended purpose … of at least six months, unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data".

"Under their control" is a property of your pipeline, not a clause you negotiate. If the audit trail lives in a vendor's console and leaves on their schedule, those logs are not under your control. Self-hosting resolves it by construction, and the floor becomes the maximum of the duties reaching each system, with a recorded reason.

Two other floors commonly reach the same store, and neither is an AI Act number. CERT-In's directions of 28 April 2022 bind "[a]ll service providers, intermediaries, data centres, body corporate and Government organisations" to "maintain" ICT logs "securely for a rolling period of 180 days" within Indian jurisdiction — see the CERT-In piece. India's DPDP Rules, 2025 add a longer one for Data Fiduciaries: Rule 6(1)(e) requires retaining "such logs and personal data for a period of one year". Not yet live — Rule 1(4) commences it "eighteen months after the date of publication of this Gazette", dated 13 November 2025, landing around mid-May 2027 on ordinary arithmetic; the Rules print no date. The DPDP article covers the rest.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  # Stamp classification and role onto every record, so a retention query
  # never has to infer them from a workload name.
  attributes/ai-act:
    actions:
      - key: ai_act.role
        value: deployer
        action: insert
      - key: ai_act.system_class
        value: high_risk_annex_iii
        action: insert
      # Day-counted floors only: CERT-In 180 rolling days, DPDP one year.
      # Article 26(6) is six calendar months and is tracked as its own clock.
      - key: retention.floor_days
        value: 365
        action: insert
  batch: {}

exporters:
  otlp_http/audit: # own storage; no vendor log console in the path
    # Full URL. The base 'endpoint' field appends /v1/logs itself.
    logs_endpoint: https://audit-sink.internal.example.com/v1/logs
    tls:
      ca_file: /etc/otel/pki/internal-ca.pem

service:
  pipelines:
    logs/ai-audit:
      receivers: [otlp]
      processors: [attributes/ai-act, batch]
      exporters: [otlp_http/audit]

Failure Modes: How Deployers Actually Get This Wrong

Three patterns account for most of it, each visible in infrastructure before it reaches a document. The silent role flip: a team fine-tunes a model, gives the service its own product name and ships it to internal users. Nobody files a decision, because nothing felt like a legal event — but Article 3(3) and the own-use limb of Article 3(11) may already be met, and Article 25(1)(a) and (c) wait behind them. The mitigation is making role a declared, admission-time property.

Oversight assigned without authority. Article 26(2) names competence, training and authority together, and 26(5) requires suspension on an Article 79(1) risk. If the named person cannot take the endpoint out of rotation without a change-advisory board, the paragraphs and the runbook disagree. The fix is an interlock that role can pull.

A retention floor colliding with data minimisation. The six months is expressly subject to other law, "in particular in Union law on the protection of personal data". Holding prompt bodies that long when the personal data in them cannot be justified for the period trades one breach for another. Separating the audit record from the payload survives both, decided before the pipeline exists.

Building the Deployer Evidence Plane

Three artefacts carry most of the weight, and the Act prescribes none of them. The first forces role and retention to be answered before a workload runs — an admission-time assertion, not a spreadsheet row that ages.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-ai-act-declaration
spec:
  background: true
  rules:
    - name: inference-workloads-declare-role
      match:
        any:
          - resources:
              kinds: [Deployment, StatefulSet]
              selector:
                matchLabels:
                  workload-class: inference
      validate:
        # Rule-level failureAction; spec.validationFailureAction is deprecated.
        failureAction: Enforce
        message: >-
          Declare ai-act.stribog.dev/role, /system-id and
          /retention-floor-days on inference workloads.
        pattern:
          metadata:
            annotations:
              ai-act.stribog.dev/role: "deployer|provider"
              ai-act.stribog.dev/system-id: "?*"
              ai-act.stribog.dev/retention-floor-days: "?*"

The second is an oversight-event record. An inference log holds what the model was asked and answered, not who was watching, what authority they held, or why they did or did not suspend. Those are the facts Article 26(2) and 26(5) turn on, so they need their own schema.

{
  "event_id": "oe-2026-09-08-0031",
  "system_id": "credit-triage-assistant",
  "observed_at": "2026-09-08T09:14:22Z",
  "oversight_actor": {
    "role": "designated_oversight",
    "authority": ["suspend_endpoint", "reject_output", "escalate_provider"],
    "competence_record": "training/oversight-2026-Q2/rec-118"
  },
  "trigger": { "kind": "article_79_1_risk", "detail": "output outside stated envelope" },
  "decision": {
    "suspended_use": true,
    "suspended_at": "2026-09-08T09:19:40Z",
    "notified": ["provider", "market_surveillance_authority"],
    "article_72_information_sent": true
  },
  "evidence_refs": ["audit-sink://credit-triage-assistant/2026-09-08T09"]
}

The third runs before an audit rather than during one: does the oldest retained record for each system still clear its floor? On a schedule, that is a monitor, not an archaeology project.

#!/usr/bin/env bash
# EXCERPT: AUDIT_SINK and the system list are environment-specific.
set -euo pipefail

AUDIT_SINK="${AUDIT_SINK:?set the audit sink base URL}"
now_epoch=$(date -u +%s)
fail=0

# system_id:floor_days — the max of the duties reaching it.
while IFS=: read -r system floor; do
  oldest=$(curl -sf "${AUDIT_SINK}/oldest?system=${system}") || {
    echo "FAIL ${system}: sink unreachable"; fail=1; continue; }
  age_days=$(( (now_epoch - $(date -u -d "${oldest}" +%s)) / 86400 ))
  if (( age_days < floor )); then
    echo "FAIL ${system}: oldest ${age_days}d < floor ${floor}d"
    fail=1
  fi
done <<'SYSTEMS'
credit-triage-assistant:365
internal-rag-assistant:180
SYSTEMS

exit "${fail}"

The Exit Ramp: Evidence That Survives a Platform Change

Article 26(6) contains an anti-lock-in argument that rarely gets read as one. It attaches to logs "under their control", so a deployer whose audit trail is a proprietary console has outsourced the evidence for its own compliance — and on the day it changes platform, that evidence does not move.

Three properties make it portable. The schema is yours and open — OTLP on the wire, a documented record shape at rest, no field only one vendor emits. The storage is yours, so retention is a policy you set, not a plan you buy. And the system identifier is stable across platforms: a migration that renames every system breaks the join between an oversight event and the records it names.

Article 25(2) is the contractual half: where conversion has happened, the initial provider owes "the reasonably expected technical access and other assistance" — worth naming log export in the agreement. The same reasoning holds below the audit plane: an inference stack built on vLLM you run yourself can change model, hardware or scheduler without the evidence trail changing shape. The management-system view of those records is ISO/IEC 42001.

The Long Game: December 2027 Is the Deadline, Not the Design

Fifteen months is enough to build one oversight and evidence plane properly, and equally enough to patch something on in the last quarter. A plane designed once is a schema, a store and an interlock; one assembled under deadline is a folder of exports.

Two caveats. The Article 6(5) classification guidelines exist in draft on the Commission's AI Act platform and are not adopted, so the test may sharpen before December 2027 — build the gate so its criteria can change without rebuilding the pipeline. And every quotation here was read from the consolidated text 02024R1689 — EN — 27.07.2026 — 001.001, which EUR-Lex labels a documentation tool with no legal effect; the authoritative pair is Regulation (EU) 2024/1689 and Regulation (EU) 2026/1744. Not legal advice.

The durable version of this work is not an AI Act project. It is an inference estate where every workload declares what it is and who holds the role, every oversight decision leaves a record, and the retention floor is enforced by a job, not remembered. That estate answers Article 26 in 2027, an auditor the year after, and whatever arrives next.