Warum August 2026 eine echte Deadline ist
Der EU AI Act trat im August 2024 in Kraft. Die Bestimmungen zu verbotenen Praktiken griffen ab Februar 2025. Pflichten für General-Purpose-AI-Modelle ab August 2025. Und die vollen Anforderungen an Hochrisiko-Systeme werden am 2. August 2026 durchsetzbar. Das ist das Datum, dem die meisten Produktteams Aufmerksamkeit schenken sollten, denn es bringt die größte Engineering-Last.
Dieser Beitrag ist keine Rechtsberatung. Wir haben dafür Anwälte; Sie sollten das auch. Dieser Beitrag behandelt, was die Verordnung von Software-Systemen verlangt – in einer Sprache, mit der ein Engineer etwas anfangen kann –, und wie Sie die häufigen Pflichten umsetzen, ohne Ihre Codebase in ein Compliance-Ödland zu verwandeln.
Die vier Risikostufen
Der Act klassifiziert AI-Systeme in vier Stufen, jede mit unterschiedlichen Pflichten.
| Stufe | Definition | Was Sie tun müssen |
|---|---|---|
| Unacceptable | Social Scoring, biometrische Echtzeit-Identifizierung im öffentlichen Raum, manipulative Systeme | Verboten – nicht bauen |
| High-risk | Gelistete Use Cases in Annex III (Beschäftigung, Kredit, Bildung, kritische Infrastruktur, Strafverfolgung usw.) | Volles Pflichtenset – Dokumentation, Oversight, Logging, Monitoring |
| Limited risk | Chatbots, generative AI, Emotionserkennung | Transparenzpflichten |
| Minimal risk | Alles andere | Freiwillige Codes of Conduct |
Die meisten Startup-Teams fallen in eine von zwei Kategorien: limited risk für ein nutzerseitiges LLM-Feature oder high risk, wenn Sie HR, Kredit, Bildung oder andere Annex-III-Bereiche berühren. Im Zweifel eher Richtung high risk irren.
High-Risk: Was das wirklich verlangt
Ein Hochrisiko-AI-System unter Artikel 9–15 muss mindestens implementieren:
- Ein Risikomanagement-System (fortlaufend, dokumentiert, mit Weiterentwicklung des Systems aktualisiert).
- Daten und Data-Governance-Praktiken – Qualität, Repräsentativität, Bias-Analyse.
- Technische Dokumentation, die einem Prüfer die Konformitätsbewertung erlaubt.
- Record-Keeping (automatisierte Logs über den Lifecycle).
- Transparenz und Informationen für Betreiber.
- Menschliche Aufsicht – das System muss für sinnvolle menschliche Überwachung gestaltet werden können.
- Accuracy, Robustness, Cybersecurity.
- Ein Qualitätsmanagement-System.
- Post-Market-Monitoring.
- Meldung schwerwiegender Vorfälle.
Gehen wir die durch, die im Code auftauchen.
Record-Keeping: Prompt- und Response-Logging
Artikel 12 verlangt automatisches Logging über den Betrieb eines Hochrisiko-AI-Systems. Für eine LLM-Anwendung heißt das: jeder Prompt, jede Response, jeder Tool-Call, jede Entscheidung. Die Logs müssen erlauben, das Systemverhalten auf Inputs zurückzuverfolgen.
Eine minimale Logging-Middleware für eine FastAPI-App:
from __future__ import annotations
import hashlib
import json
import time
import uuid
from datetime import datetime, timezone
from typing import Any
from fastapi import FastAPI, Request
from pydantic import BaseModel, Field
import structlog
logger = structlog.get_logger()
app = FastAPI()
class LLMInteraction(BaseModel):
interaction_id: str = Field(default_factory=lambda: str(uuid.uuid4()))
timestamp_utc: str = Field(
default_factory=lambda: datetime.now(timezone.utc).isoformat()
)
system_id: str
system_version: str
model: str
model_version: str
user_id_hash: str
input_hash: str
input_tokens: int
output_tokens: int
latency_ms: int
safety_flags: list[str] = []
human_review_requested: bool = False
def hash_user_id(raw: str) -> str:
salt = b"eu-ai-act-log-salt-v1"
return hashlib.sha256(salt + raw.encode()).hexdigest()[:16]
@app.middleware("http")
async def log_llm_interaction(request: Request, call_next):
start = time.monotonic()
response = await call_next(request)
latency = int((time.monotonic() - start) * 1000)
if request.url.path.startswith("/v1/generate"):
interaction = LLMInteraction(
system_id="hr-screening",
system_version=request.app.state.version,
model="claude-sonnet-4.6",
model_version="20260115",
user_id_hash=hash_user_id(request.headers.get("x-user-id", "anon")),
input_hash=request.state.input_hash,
input_tokens=request.state.input_tokens,
output_tokens=request.state.output_tokens,
latency_ms=latency,
safety_flags=getattr(request.state, "safety_flags", []),
)
logger.info("llm.interaction", **interaction.model_dump())
return response
Zwei Anmerkungen. Erstens hashen wir Nutzer-Identifier mit einem Salt – Sie sind nicht verpflichtet, in den Logs selbst zu pseudonymisieren, wollen es aber aus DSGVO-Gründen fast immer. Zweitens loggen wir Token-Counts statt Rohinhalt. Der Act verlangt Record-Keeping, nicht zwingend vollständige Inhaltsaufbewahrung; Sie können Hashes oder Zusammenfassungen speichern, sofern eine Policy das festhält. Wählen Sie einen Ansatz und dokumentieren Sie ihn.
Aufbewahrung
Es gibt keine einzelne Aufbewahrungszahl im Act. Erwägungsgründe und Artikel 19 verlangen vom Provider, Logs „dem Zweck angemessen" aufzubewahren – in der Regel mindestens sechs Monate, oft länger. Wir setzen Kunden standardmäßig auf 12 Monate Hot Storage, 5 Jahre Cold Storage, mit dokumentierter Löschung auf Nutzeranfrage für personenbezogene Bestandteile.
Technische Dokumentation: Die Model Card
Annex IV listet, was die technische Dokumentation abdecken muss. Für ein modellgestütztes System ist das effizienteste Format eine Model Card, die im Version Control neben dem Code lebt.
Ein Pydantic-Model-Registry-Eintrag, der gleichzeitig als Model Card dient:
from __future__ import annotations
from datetime import date
from typing import Literal
from pydantic import BaseModel, Field, HttpUrl
class IntendedPurpose(BaseModel):
description: str
deployers: list[str]
geographic_scope: list[str]
not_intended_for: list[str] = []
class DataGovernance(BaseModel):
training_data_sources: list[str]
training_data_licensing: list[str]
bias_evaluation: str
bias_metrics: dict[str, float]
pii_handling: str
class HumanOversight(BaseModel):
oversight_type: Literal["human-in-the-loop", "human-on-the-loop", "human-in-command"]
override_mechanism: str
escalation_path: str
class PostMarketMonitoring(BaseModel):
metrics: list[str]
alerting: str
review_cadence_days: int
class ModelCard(BaseModel):
system_id: str
name: str
provider: str
version: str
risk_tier: Literal["unacceptable", "high", "limited", "minimal"]
annex_iii_category: str | None = None
intended_purpose: IntendedPurpose
data_governance: DataGovernance
human_oversight: HumanOversight
monitoring: PostMarketMonitoring
known_limitations: list[str]
accuracy_estimate: float = Field(ge=0, le=1)
robustness_notes: str
last_reviewed: date
reviewed_by: list[str]
documentation_url: HttpUrl
Speichern Sie eine davon pro System in einem model-cards/-Verzeichnis. CI validiert, dass jedes vom Produktionscode referenzierte System eine Card hat und dass sie in den letzten 180 Tagen reviewt wurde.
Menschliche Aufsicht: Darauf hin entwerfen
Artikel 14 verlangt, dass Hochrisiko-Systeme wirksam durch natürliche Personen beaufsichtigt werden können. Für Entwickler reduziert sich das meist auf drei Fragen:
- Kann der Mensch sehen, was das System tut und warum?
- Kann der Mensch eingreifen?
- Kann der Mensch den Output überstimmen, bevor er Wirkung entfaltet?
Konkret: Wenn Ihr System Bewerbungen automatisch ablehnt, darf es keine Fire-and-forget-Pipeline sein. Ein Mensch muss die Entscheidung sehen, die Begründung sehen und sie überstimmen können, bevor der Kandidat benachrichtigt wird.
Ein einfaches Muster: Die AI produziert eine Empfehlung mit Konfidenz und Begründung; der Workflow reiht sie in ein Human Review ein; erst nach expliziter Freigabe wird die Aktion ausgeführt.
class Recommendation(BaseModel):
candidate_id: str
decision: Literal["proceed", "reject", "uncertain"]
confidence: float
reasoning: str
model_version: str
generated_at: str
class ReviewOutcome(BaseModel):
recommendation: Recommendation
reviewer_id: str
reviewer_decision: Literal["approved", "overridden", "escalated"]
reviewer_notes: str
reviewed_at: str
Der Prüfer erwartet Beispiele für overridden-Ergebnisse. Werden 100 % der Empfehlungen unverändert genehmigt, ist entweder Ihr Modell perfekt oder Ihre Aufsicht Theater.
Transparenz: Was der Nutzer sieht
Artikel 52 deckt Transparenzpflichten für Limited-Risk-Systeme ab. Die wichtigsten:
- Nutzer müssen informiert werden, dass sie mit einem AI-System interagieren (sofern nicht offensichtlich).
- AI-generierte oder -manipulierte Inhalte (Deepfakes, synthetische Bilder) müssen gekennzeichnet werden.
- Nutzer von Emotionserkennung und biometrischer Kategorisierung müssen informiert werden.
- General-Purpose-AI-Modelle müssen synthetische Outputs, wo technisch machbar, mit Wasserzeichen versehen.
In der Praxis ist das eine kleine UI-Änderung. Ein persistentes Badge neben dem Chat-Interface: „Sie sprechen mit einem AI-Assistenten. Antworten können unzutreffend sein." Für generierte Bilder: ein Metadaten-Tag und ein sichtbarer Indikator.
Deployment Gating in CI
Der sauberste Weg, das im Alltag durchzusetzen, ist ein CI-Check, der das Promotion nach Produktion verweigert, wenn die zugehörige Model Card fehlt, veraltet ist oder offene Lücken hat.
name: AI Compliance Gate
on:
pull_request:
paths:
- "apps/**"
- "model-cards/**"
jobs:
gate:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- run: pip install pydantic==2.9 pyyaml==6.0
- name: Validate model cards
run: python scripts/validate_model_cards.py
- name: Check referenced systems have cards
run: python scripts/check_coverage.py
- name: Enforce staleness
run: python scripts/check_staleness.py --max-days 180
Und das Validierungs-Skript ist nur wenige Zeilen:
from __future__ import annotations
import pathlib
import sys
from datetime import date, timedelta
import yaml
from compliance.model_card import ModelCard
root = pathlib.Path("model-cards")
max_age = timedelta(days=180)
today = date.today()
errors: list[str] = []
for path in root.glob("*.yaml"):
raw = yaml.safe_load(path.read_text())
try:
card = ModelCard.model_validate(raw)
except Exception as exc:
errors.append(f"{path}: {exc}")
continue
if today - card.last_reviewed > max_age:
errors.append(f"{path}: stale, last reviewed {card.last_reviewed}")
if card.risk_tier == "high" and not card.annex_iii_category:
errors.append(f"{path}: high-risk card missing Annex III category")
if errors:
print("Compliance gate failed:")
for e in errors:
print(f" - {e}")
sys.exit(1)
print(f"All {len(list(root.glob('*.yaml')))} model cards valid.")
Post-Market-Monitoring
Artikel 72 verlangt einen Post-Market-Monitoring-Plan – nicht nur Metriken, sondern einen dokumentierten Prozess, wie Sie Realdaten erheben, analysieren und darauf reagieren. Ihr bestehender Observability-Stack ist 80 % der Antwort. Die übrigen 20 % sind ein geplanter Review, in dem eine benannte Person die Daten sichtet, aufschreibt, was sie gesehen hat, und es ablegt. Quartalsweise ist das Minimum; monatlich ist für neuere Systeme besser.
Schwerwiegende Vorfälle – wenn das System Schaden oder einen Beinahe-Schaden verursacht – müssen der zuständigen nationalen Behörde innerhalb von 15 Tagen gemeldet werden (Artikel 73). Ihr Incident-Runbook braucht dafür einen Zweig: „Ist das nach EU AI Act meldepflichtig?" Wenn ja, wird das Compliance-Team neben Engineering paged.
Eine pragmatische Readiness-Checkliste
- Alle AI-Systeme in Risikostufen klassifiziert
- Hochrisiko-Systeme haben Model Cards, die Annex IV abdecken
- Prompt-/Response-Logging mit definierter Aufbewahrung
- Menschliche Aufsicht in jeden Hochrisiko-Workflow eingebaut
- Transparenz-Hinweise in der UI für Limited-Risk-Systeme
- CI-Gate verhindert Deployment von Systemen ohne Card
- Incident-Runbook enthält AI-Act-Meldezweig
- Post-Market-Monitoring-Plan dokumentiert und terminiert
Nächste Schritte
Die Deadline August 2026 ist nah genug, dass Produktteams dies als Quartals-Thema behandeln sollten, nicht als Jahres-Thema. Das Implementierungsmuster ist nicht exotisch – ein Registry, etwas Middleware, ein CI-Gate und eine Review-Kadenz –, aber langweilig genug, dass es ohne Planung nicht passiert. Planen Sie die Arbeit jetzt ein. Wenn Sie Unterstützung beim Mapping Ihrer Systeme auf den Act und beim Aufbau der Gating-Pipeline wünschen, nehmen Sie Kontakt auf.