Die Lage im April 2026

Am 2. August 2026 greifen die Hochrisiko-Pflichten aus Annex III des EU AI Act. Für fast alle Mittelständler, die KI in Kreditvergabe, Versicherungspricing, HR-Screening, Bildung oder öffentlichen Diensten einsetzen, heißt das, dass sie ab diesem Datum mit einer vollständigen Dokumentation aufwarten müssen. Wer nicht liefern kann, riskiert Bußgelder, die laut Art. 99 bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes erreichen können. Für KMU nach Recommendation 2003/361/EC gilt die niedrigere der beiden Grenzen (Art. 99(6)), aber auch diese ist substanziell.

Laut Bitkom haben weniger als 30 Prozent der europäischen KMU konkrete Schritte zur AI-Act-Compliance unternommen. Gleichzeitig kostet ein Eigenbau der nötigen Toolchain zwischen 25.000 und 300.000 Euro upfront plus 400.000 bis 1,2 Millionen Euro pro Jahr an Teamkosten. Für die meisten Betriebe rechnet sich das nicht.

Wir haben agents.renemurrell.de in den letzten Wochen von einer Agent-Runtime zu einem EU-AI-Act-Compliance-Toolkit ausgebaut. Dieser Artikel dokumentiert das neue Feature-Set und wofür es konkret gebaut wurde.

Was ein KMU ab August 2026 wirklich braucht

Bevor man Tools baut, muss klar sein, welche Artefakte der Act fordert. Der Act sortiert die Pflichten nach Provider (wer das System auf den Markt bringt) und Deployer (wer es in einem Prozess einsetzt). Ein typischer KMU-Einsatz von KI ist die Deployer-Rolle, also das Einsetzen eines vortrainierten Modells wie GPT-4 oder Claude im eigenen Workflow. Für dieses Profil sind acht Artefakte relevant:

  1. FRIA (Art. 27): Fundamental Rights Impact Assessment. Verpflichtend vor dem ersten Einsatz für Bonitätsprüfung, Versicherungspricing und öffentliche Dienste.
  2. Annex IV (Art. 11): Technische Dokumentation mit neun Sektionen. Pflicht für Provider, Aufbewahrung 10 Jahre.
  3. PMM-Plan (Art. 72): Post-Market Monitoring Plan. Metriken, Review-Cadence, Trigger für Re-Assessment.
  4. QMS-Handbuch (Art. 17): Qualitätsmanagementsystem mit 13 Elementen. Microenterprises dürfen eine vereinfachte Form verwenden (Art. 63).
  5. EU-Datenbank-Registrierung (Art. 49): Annex-VIII-Eintrag für jedes High-Risk-System, bevor es auf den Markt kommt.
  6. Data Sheet (Art. 10): Dokumentierte Datenherkunft, Qualitätskriterien, Bias-Bewertung.
  7. Incident-Report (Art. 73): Bei schweren Vorfällen innerhalb von 2, 10 oder 15 Tagen an die Marktüberwachungsbehörde.
  8. Literacy-Zertifikat (Art. 4): AI-Literacy-Nachweis für Mitarbeitende. Seit Februar 2025 bereits verpflichtend.

Jedes dieser Dokumente hat eine eigene juristische Struktur, eigene Platzhalter und eigene Aufbewahrungsfristen. Der naheliegende Ansatz wäre, alle acht getrennt zu bearbeiten, jeweils mit einer eigenen Word-Vorlage. Genau das wollten wir Deployern ersparen.

Der Setup-Flow: ein Fragebogen, ein ZIP

Das Kernstück der neuen Iteration ist ein dreistufiger Setup-Flow unter /compliance/setup. Er funktioniert so:

Schritt 1: Use-Case auswählen. Vier Kategorien sind kartiert auf die FRIA-Trigger nach Art. 27(1): Kreditscoring (Annex III §5(b)), Versicherungspricing (§5(c)), öffentlicher Dienst, sonstiger High-Risk-Einsatz. Der Flow entscheidet daraus automatisch, ob FRIA Teil des Pakets wird oder nicht.

Schritt 2: System beschreiben. Entweder ein Agent, der auf unserer Plattform registriert ist, oder ein externes System mit sechs Feldern (Name, Version, Risikoklasse, Domäne, verwendetes Modell, Kurzbeschreibung). Dieser Manual-Agent-Modus ist entscheidend für KMU, deren KI-Einsatz ein Tool wie ChatGPT, Claude oder ein internes System ist, nicht ein bei uns gelisteter Agent.

Schritt 3: Prüfen und generieren. Das System baut in einem Durchgang alle einschlägigen Artefakte, packt PDFs plus Markdown-Quellen plus JSON-Payloads in ein ZIP und übergibt es zum Download. Für einen Credit-Scoring-Agent kommen heraus: FRIA, Annex IV, PMM-Plan, Data Sheet, EU-DB-Registrierungsentwurf. Fünf PDFs, ein Manifest, ein README mit Hinweisen zur Aufbewahrung.

Voraussetzung für wirklich sinnvolle Inhalte ist ein einmal eingerichtetes Organisationsprofil. Unter /settings/org hinterlegt der Compliance-Verantwortliche einmalig den Firmennamen, die Adresse, den zuständigen Kontakt, die Größenkategorie und drei Governance-Rollen (Accountability Owner, PMM Owner, Authority Liaison). Ab dann werden alle Assistenten automatisch mit diesen Daten vorbelegt. Statt jedes Feld in jeder der acht Vorlagen erneut auszufüllen, konzentriert sich der Nutzer auf die qualitativen Sektionen, die wirklich nur seine Organisation beantworten kann.

Persona-Durchlauf: von der Landing Page zum fertigen Dokumentenset

Konkret: Elena leitet Compliance bei einem Berliner Fintech mit 50 Mitarbeitenden. Sie öffnet die Plattform, sieht in der Hero-Sektion “AI-Agenten, die ihr wirklich auditen könnt”, registriert sich als Consumer/Deployer (die Rollenauswahl erklärt unten, welche Rolle dem EU-AI-Act-Deployer entspricht), bekommt eine E-Mail plus Passwort-Flow.

Nach dem Login landet sie direkt auf /compliance, dem Workspace-Dashboard. Ein Banner prompt sie auf den Organisationsprofil-Setup. Sechzig Sekunden später sind Legal Name, Adresse, Kontakt und Größenkategorie hinterlegt. Sie klickt auf “Run compliance setup”.

Im Setup-Flow wählt sie Credit Scoring, beschreibt den internen Scoring-Agent (Name, Version, Risikoklasse “hoch”, Domäne “Fintech”, Modell “Claude Sonnet 4.6”), klickt Generate. Drei Sekunden später lädt das Browser-Download-Popup ein 163-KB-ZIP mit siebzehn Dateien. Darin fünf PDFs, fünf Markdown-Quellen, fünf JSON-Payloads, ein Manifest und ein README.

Die PDFs sind nicht leer. Sie sind bereits zu etwa 60 bis 80 Prozent ausgefüllt. Elenas Organisationsdaten sind drin. Die Plattform-seitigen Maßnahmen (ephemere Compute-Umgebung, unveränderbares Event-Log, Art.-50-Provenance, Approval Gates bei hohem Risiko) sind in den passenden Sektionen eingetragen. Der Agent-Kontext ist in Section 1 der FRIA zitiert. Die offenen Felder sind klar als [DEPLOYER: …] oder [PROVIDER: …] markiert. Sie füllt die drei qualitativen Sektionen (Deployer-Prozessbeschreibung, vulnerable Gruppen, interne Governance) aus und hat ein übergabefertiges Dokument.

Was nach dem Walkthrough noch fehlt: der eigentliche Text der qualitativen Teile, die Unterschrift, ggf. die DPIA-Referenz. Das ist die Arbeit, die nur Elena leisten kann. Alles drumherum läuft automatisch.

Die Artefakte im Einzelnen

Jedes der acht Dokumente hat eine dedizierte Seite für den Fall, dass ein Nutzer nur eines davon braucht.

FRIA (/fria)

Sechs Sektionen nach Art. 27(1)(a-f). Section 1 (Prozessbeschreibung) und Section 5 (Aufsichtsmaßnahmen) werden aus der Agent-Beschreibung automatisch abgeleitet. Hochrisiko-Agents bekommen automatisch den “Mandatory approval gate”-Hinweis aus Art. 14 in die Platform-Measures-Liste. Die DPIA-Bridge nach Art. 27(4) wird im Dokument explizit referenziert.

Annex IV (/annex-iv)

Alle neun Sektionen aus Annex IV. Zwei Varianten: full (Standard für Provider) und simplified (SME-Form nach Art. 11(1) Unterabsatz 3, collapsed Section 2, 4 und 6). Observed-Runtime-Metriken (Total Executions, Success Rate, Trust Score, Average Duration) werden aus der Event-Log-Historie automatisch in Section 3 eingetragen.

PMM-Plan (/pmm)

Post-Market Monitoring Plan mit vier Datenquellen (Event Log, Trust Score, User Ratings, Incident Register) und fünf default Metriken mit konkreten Alert-Thresholds (z.B. “Success rate drop über 10 Prozentpunkte vs. Baseline im 24-Stunden-Fenster”). Review-Cadence konfigurierbar als weekly, monthly, quarterly oder annual. Integrierte Verweise auf den Art.-73-Incident-Flow.

QMS-Handbuch (/qms)

Alle 13 Art.-17(1)(a-m)-Sektionen. ISO/IEC 42001 als Baseline-Standard explizit referenziert, ebenso ISO/IEC 23894 (Risk Management), 5259 (Data Quality) und 24029 (Robustness). Simplified-Variante für Microenterprises lässt Section L (Budget/Staffing) und Section M (Audit-Schedule, Board-Reporting) weg. Optionales System-spezifisches Addendum bei Bezug auf einen bestimmten Agent.

EU-Datenbank-Registrierung (/eu-db)

Alle elf Felder aus Annex VIII Section B, von Provider-Identifikation über System-Beschreibung bis zur CE-Markierung. Art.-6(3)-Non-High-Risk-Declaration steht als optionale Sektion bereit, wenn die Risikoklasse minimal oder limited ist.

Data Sheet (/data-governance)

Art.-10-konformes Dokument mit Input/Output-Schema, Tool-Access, Model+Training-Data-Statement, Bias-Assessment-Methoden und Platform-seitigen Controls (3-Pfad-Secret-Isolation, Ephemeral Compute, Egress Firewall). Zusätzlich eine aggregierte Inventory-View über alle Agents der Organisation.

Incident-Reporting (/incidents)

Sechs Severity-Kategorien nach Art. 3(49) mit automatischer Deadline-Berechnung: 2 Tage für kritische Infrastruktur und widespread infringement, 10 Tage für Fundamental-Rights-Incidents, 15 Tage sonst. Live-Countdown im Dashboard, farbcodiert (amber laufend, rot overdue, grün gefiled). Art.-73-Report-Template wird beim Filing automatisch generiert, zum Download als PDF oder Markdown.

AI-Literacy (/literacy)

Drei Module à 5 bis 6 Minuten: AI-Agents-Fundamentals, EU-AI-Act-für-Deployer, Human-Oversight-in-Practice. Nach jedem Modul ein Multiple-Choice-Quiz mit 70-Prozent-Pass-Threshold. Ausgabe ist ein deterministisches Zertifikat mit SHA-256-Fingerprint, Lernername, Organisation, Modulkennung, Score und Zeitstempel. Die deployende Organisation sammelt diese Zertifikate als Art.-4-Nachweis.

Der Workspace: von Einzeldokumenten zu Compliance-Organismus

Einzelne Dokumente sind nützlich. Erst das Zusammenspiel ergibt Wert.

Alle gespeicherten Dokumente landen im Compliance-Workspace (/compliance). Eine generische Tabelle mit polymorphem doc_type-Discriminator, org_id-Ownership und Review-Flow (draft, submitted, approved, archived). Jedes Dokument trägt die Agent-Version zum Zeitpunkt der letzten Prüfung. Ändert sich danach die Agent-Version, wird das Dokument automatisch als stale markiert. Das Dashboard zeigt einen Banner mit der Anzahl veralteter Dokumente und ermöglicht das direkte Nachziehen durch einen Klick auf “Load saved” im zugehörigen Wizard, der die alten Deployer-Inputs in das neue Formular vorfüllt.

Konkret: Aktualisiert der Agent-Provider seinen Credit-Scorer von v3 auf v4, werden alle FRIAs, Annex-IV-Dokumente und PMM-Pläne, die auf v3 referenzieren, automatisch geflaggt. Der Compliance-Officer sieht das, lädt das alte Dokument, reconciled die qualitativen Sektionen mit der neuen Version und reicht es zur Freigabe erneut ein. Der Approval-Flow ist zweistufig: Draft, Approved, Archived. Approvals werden mit approved_by und approved_at im Dokument gespeichert. Die zehnjährige Aufbewahrungspflicht nach Art. 18 läuft im Hintergrund: Event-Logs werden auf 180 Tage Minimum (Art. 19) in der Datenbank gehalten, Dokumente länger.

Die KMU-Hebel, die der Act selbst anbietet

Der EU AI Act wurde nicht für Konzerne optimiert. Er enthält explizite Erleichterungen für kleinere Organisationen, die häufig übersehen werden:

Art. 62 Reduced Conformity Fees: Benannte Stellen müssen KMU und Startups bevorzugte Zugänge zu Regulatory Sandboxes gewähren und die Konformitätsbewertungsgebühren proportional zur Unternehmensgröße reduzieren. Auf unserer Plattform liegt der Wert primär darin, dass wir durch Platform-seitige Nachweise und die Integration mit dem Incident-Reporting-Pfad einen Großteil der Anforderungen bereits abdecken, sodass benannte Stellen seltener involviert werden müssen.

Art. 63 Simplified QMS: Microenterprises (weniger als 10 Mitarbeitende und weniger als 2 Millionen Euro Umsatz) dürfen das Qualitätsmanagementsystem in vereinfachter Form führen. Unsere QMS-Variante “simplified” ist genau dafür gebaut: sie lässt die Sektionen weg, die bei dieser Größenordnung keinen operativen Mehrwert haben (Budget-Allokation, interner Audit-Schedule, Board-Reporting).

Art. 99(6) Fine Cap: Für KMU gilt bei Ordnungswidrigkeiten immer der niedrigere der beiden Bußgeldrahmen, nicht der höhere. Konkret bedeutet das, dass ein 100-Mitarbeitenden-Fintech bei einem Art.-17-Verstoß mit maximal 7,5 Millionen Euro rechnet, nicht mit 7 Prozent des globalen Umsatzes. Das ist immer noch ein relevantes Risiko, aber ein kalkulierbares.

Art. 57 Priority Sandbox Access: Jedes Mitgliedsland muss bis August 2026 mindestens eine Regulatory Sandbox betreiben. KMU haben gegenüber Enterprise-Teilnehmern Priorität und bekommen die Teilnahmegebühren erlassen. Deutschland setzt das per KI-MIG (Kabinettsbeschluss vom 11. Februar 2026) um, die BNetzA wird Marktüberwachungsbehörde.

Die Homepage zeigt diese vier Entlastungen prominent unter “Built for SMEs”. In den Wizards reflektieren sich die Erleichterungen automatisch, sobald die Größenkategorie im Organisationsprofil gesetzt ist. Ein Microenterprise bekommt bei QMS direkt die vereinfachte Variante vorausgewählt. Ein Unternehmen im Sandbox-Modus kann in der FRIA auf die Sandbox-Teilnahme verweisen.

Was wir bewusst nicht automatisieren

Wichtig ist, was das Toolkit nicht tut. Vier Dinge bleiben ausdrücklich in der Verantwortung des Deployers:

  • Qualitative Bewertung: Die Beschreibung der konkreten Harm-Risiken, die Severity- und Likelihood-Einschätzung, die Identifikation vulnerabler Gruppen. Diese Teile kann nur der Deployer selbst liefern, weil er den Kontext kennt.
  • Rechtsberatung: Das Toolkit ersetzt keinen Fachanwalt. Es liefert auditfähige Dokumente, aber die Freigabe vor dem ersten produktiven Einsatz bleibt Aufgabe der Compliance-Funktion.
  • Laufende Überwachung: Der PMM-Plan schlägt Metriken und Thresholds vor. Das tatsächliche Monitoring, die Reaktion auf Abweichungen und die kontinuierliche Anpassung gehören dem operativen Team.
  • Incident-Handling: Ein Incident melden, Root-Cause-Analyse durchführen, korrektive Maßnahmen umsetzen. Das Toolkit strukturiert diese Arbeit, automatisiert sie aber nicht.

Diese Trennung ist wichtig, weil sie erklärt, warum Compliance-Toolkits Deployer entlasten, aber nicht ersetzen können. Wir machen den bürokratischen Overhead planbar. Das Urteil über einen konkreten Einsatz bleibt bei den Menschen, die ihn operativ zu verantworten haben.

Technisch: was unter der Haube läuft

Für technische Entscheider eine Kurzfassung der Architektur.

Backend läuft als FastAPI auf einem Hetzner-Server in Nürnberg, Deutschland. Keine US-Cloud-Anbieter, keine CLOUD-Act-Exposition. PostgreSQL als Datenspeicher, alembic-verwaltete Migrationen, 500+ pytest-Tests in CI. Die fünf Compliance-Generatoren sind reine Python-Module, ohne externe API-Abhängigkeiten. PDF-Rendering erfolgt durch weasyprint mit lokalem Print-CSS, kein externer Service.

Frontend ist React 19 mit Vite und Tailwind CSS 4, serviert als statische Assets via nginx. Routing läuft client-seitig, die 22 Pages deckeln von Catalog, Compliance-Workspace und den fünf Wizards bis zu Docs, Providers, Enterprise und dem Setup-Orchestrator. Zweisprachig deutsch/englisch, mit browser-basiertem Language-Context und Header-Toggle. HTML lang Attribut wird zur Laufzeit synchronisiert.

Authentifizierung kombiniert API-Key (primary für API-Aufrufe) und bcrypt-hashed Passwort (für Web-Login mit E-Mail). Scoped API Keys (read, execute, admin) für Service-to-Service-Szenarien. Die neue Login-Rotation stellt jedem Login einen frischen API-Key aus, wodurch verlorene Keys automatisch invalidiert werden, sobald der Nutzer sich erneut anmeldet.

Compliance-Daten bleiben beim Deployer. Drafts laufen im Browser-LocalStorage. Workspace-Dokumente werden pro Organisation in PostgreSQL gehalten, aber niemals plattformübergreifend geteilt. Die Platform hat Leserechte auf die JSON-Payloads zwecks Stale-Detection, aber nicht auf die finalisierte PDF-Version, die der Deployer lokal archiviert.

Was als nächstes kommt

Die nächsten Wochen fokussieren sich auf drei Dinge:

Erste zahlende Kunden. Das Toolkit ist in einem Zustand, der für einen ernsthaften Einsatz durch einen Mittelständler reicht. Wir suchen drei bis fünf Design-Partner aus Fintech, HR-Tech und öffentlichem Dienst, die das System bis zum 2. August 2026 in ihre Compliance-Workflows integrieren und mit uns Feedback-Zyklen fahren.

Deutsche Vertiefung der Dokumentation. Die Wizards sind zweisprachig, die API-Dokumentation noch vorwiegend englisch. Für den DACH-Markt macht eine vollständige deutsche Docs-Version einen relevanten Unterschied, besonders für Compliance-Teams ohne tägliche Englisch-Nutzung.

Integration mit deutschen Sandboxes. Sobald das KI-MIG finalisiert ist und die BNetzA-Sandbox operativ wird, bauen wir einen expliziten Sandbox-Application-Flow, der die auf der Plattform vorliegenden Dokumente direkt bündelt und an die Antragsstelle übergibt. Für Prio-1-KMU ein Zeitsprung von Wochen auf Tage.

Zum Probieren

Die Plattform läuft unter agents.renemurrell.de. Für einen Eindruck ohne Account:

  • Fertig gefüllte Beispieldokumente: vier Szenarien (Credit Scoring, HR Hiring, Insurance Pricing, Security Audit), jeweils mit FRIA und Annex IV als PDF.
  • Beispiel-Evidence-Pack: das ZIP, das pro Task-Ausführung generiert wird. Event-Log, signed Capability Card, Provenance-Record.
  • Docs: technische Dokumentation der gesamten Plattform inklusive EU-AI-Act-Sektion.

Für einen konkreten Eindruck der Compliance-Pipeline reicht ein Klick auf “Run compliance setup” nach Login. Zehn Minuten reichen, um von der Registrierung über das Organisationsprofil bis zum heruntergeladenen Dokumentenset zu kommen.

Wer Fragen hat oder als Design-Partner einsteigen möchte: [email protected].