EU AI Act Compliance Roadmap 2026: 90-Tage-Plan für Deployer

Der EU AI Act wird für Unternehmen nicht durch ein einzelnes Policy-Dokument beherrschbar. Entscheidend ist, ob ihr für jedes relevante AI-System nachvollziehen könnt: Was ist das System? Wer verantwortet es? Welche Rolle habt ihr? Welche Risikoklasse gilt? Welche Pflichten folgen daraus? Welche Controls sind implementiert? Und welche Nachweise zeigen den aktuellen Stand?

Diese Roadmap richtet sich an Deployer, also Organisationen, die AI-Systeme beruflich einsetzen. Sie ersetzt keine Rechtsberatung. Sie hilft aber dabei, aus einer abstrakten Regulierung ein prüfbares Arbeitsprogramm zu machen.

Kurzfassung

In 90 Tagen solltet ihr nicht versuchen, jedes Detail perfekt zu lösen. Das Ziel ist ein belastbarer Compliance-Kern:

1. eine vollständige und verantwortete AI-System-Inventur,
2. eine dokumentierte Risikoklassifizierung je System,
3. eine klare Provider-/Deployer-Rollenentscheidung,
4. ein Pflichten-Mapping auf Controls,
5. eine FRIA-Entscheidung für relevante Hochrisiko-Systeme,
6. Evidence je Control,
7. ein Audit-Trail für Entscheidungen, Änderungen und offene Lücken.

Wenn diese sieben Bausteine stehen, kann ein Compliance-Team priorisieren, Lücken schließen und gegenüber Management, Auditoren oder Aufsicht nachvollziehbar erklären, wo das Programm steht.

Warum 2026 der richtige Zeitpunkt für Struktur ist

Der AI Act ist seit 1. August 2024 in Kraft. Die Europäische Kommission beschreibt ihn als risikobasierten Rahmen mit unterschiedlichen Pflichten je nach Risiko. Für Unternehmen ist besonders wichtig, dass Hochrisiko-Systeme strengere Anforderungen erfüllen müssen, etwa Risikominderung, Datenqualität, Nutzerinformationen und menschliche Aufsicht.

Parallel sind seit 2. August 2025 Pflichten für Anbieter von General-Purpose-AI-Modellen in Anwendung. Die Durchsetzungsbefugnisse der Kommission für GPAI-Pflichten greifen ab 2. August 2026; für Bestandsmodelle gelten weitere Übergangsregeln. Auch wenn viele Deployer keine Modellanbieter sind, erhöht diese Timeline den Druck auf die gesamte AI-Governance-Kette: Einkaufsentscheidungen, Vendor-Dokumentation, Modellinformationen und interne Nutzung müssen besser zusammenpassen.

Der praktische Fehler vieler Organisationen ist, mit einzelnen Dokumenten zu starten: eine AI-Policy hier, ein Spreadsheet dort, ein DPIA-Ordner irgendwo im Datenschutzteam. Das fühlt sich schnell produktiv an, erzeugt aber selten einen auditierbaren Zusammenhang. Besser ist ein System-Record pro AI-System, der Klassifizierung, Pflichten, Controls und Evidence verbindet.

Phase 1: Tage 1-15 - AI-Systeme vollständig erfassen

Startet mit der Inventur. Ohne Systemliste gibt es keine verlässliche Risikoklassifizierung und kein vollständiges Pflichten-Mapping. Ein AI-System ist dabei nicht nur das große Sprachmodell im Produkt. Relevant können auch Scoring-Systeme, Empfehlungslogiken, Entscheidungsunterstützung, Klassifikatoren, agentische Workflows oder eingebettete Modelle in SaaS-Tools sein.

Ein guter Inventur-Record enthält mindestens:

Feld | Warum es wichtig ist
Systemname | eindeutige Referenz für Governance und Reports
Business Owner | Verantwortung für Zweck, Nutzung und Risiken
Technischer Owner | Verantwortung für Betrieb, Änderungen und Schnittstellen
Zweck | Grundlage für Risikoklasse und Annex-III-Prüfung
Nutzergruppe | relevant für Transparenz, Schulung und menschliche Aufsicht
Betroffene Personen | relevant für Grundrechte, Datenschutz und FRIA
Datenquellen | relevant für Qualität, Datenschutz und Nachweise
Provider/Vendor | relevant für Lieferkette und Dokumentationspflichten
Rolle | Provider, Deployer, Importeur, Distributor oder Mischrolle
Einsatzland | relevant für lokale Aufsicht und Sprache
Status | geplant, Pilot, produktiv, pausiert, außer Betrieb

Ein bestehender Einstieg dazu ist der Octangle-Artikel zur AI-System-Inventur. Für die Roadmap ist wichtig: Die Inventur ist kein einmaliger Fragebogen. Sie muss lebendig bleiben, weil neue Workflows, Modellwechsel und Vendor-Updates die Bewertung verändern können.

Ergebnis nach 15 Tagen:

• alle bekannten AI-Systeme sind erfasst,
• jedes System hat Owner,
• Schatten-KI und SaaS-Nutzung sind zumindest als Discovery-Backlog sichtbar,
• Systeme mit Personenbezug oder regulierten Domänen sind markiert.

Phase 2: Tage 16-30 - Risikoklasse und Annex III dokumentieren

Danach wird jedes System klassifiziert. Für viele Unternehmen ist Annex III der entscheidende Prüfpunkt, weil dort Hochrisiko-Anwendungsbereiche beschrieben sind. Wichtig ist: Nicht jedes AI-System in einem sensiblen Bereich ist automatisch Hochrisiko. Es zählt der konkrete Einsatzkontext.

Prüft pro System:

1. Gibt es Anhaltspunkte für verbotene Praktiken?
2. Fällt der Einsatz in eine Annex-III-Kategorie?
3. Unterstützt oder trifft das System Entscheidungen über Personen?
4. Wird das Ergebnis in einem rechtlich, wirtschaftlich oder sozial relevanten Prozess genutzt?
5. Gibt es Ausnahmen oder Gründe, warum das System trotz Kategorie nicht hochriskant ist?

Die Entscheidung sollte nicht nur als Label gespeichert werden. Dokumentiert die Begründung. Ein späterer Auditor interessiert sich weniger dafür, dass irgendwo "high risk: no" steht. Entscheidend ist, warum ihr zu dieser Entscheidung gekommen seid, wer sie getroffen hat und welche Informationen zu diesem Zeitpunkt vorlagen.

Der vorhandene Octangle-Artikel Annex III: Wann gilt ein AI-System als Hochrisiko? ist hier der natürliche Anschluss. Er sollte perspektivisch um Beispiele, Grenzfälle und einen Entscheidungsbaum ergänzt werden.

Ergebnis nach 30 Tagen:

• jedes inventarisierte System hat eine Risikoklasse,
• Annex-III-Entscheidungen sind begründet,
• offene Grenzfälle sind als Decisions erfasst,
• Systeme mit hoher Priorität sind für Phase 3 markiert.

Phase 3: Tage 31-45 - Rolle und Pflichten-Mapping klären

Die gleiche Technologie kann je nach Organisation unterschiedliche Pflichten auslösen. Deshalb muss die Rollenfrage früh sauber beantwortet werden: Seid ihr Provider, Deployer oder beides? Nutzt ihr ein fremdes System nur intern, integriert ihr es in ein eigenes Produkt oder verändert ihr es wesentlich?

Für Deployer ist besonders wichtig, dass Pflichten nicht abstrakt bleiben. Übersetzt sie in prüfbare Anforderungen:

Frage | Governance-Output
Welche Artikel sind einschlägig? | Pflichtenliste je System
Welche Controls decken die Pflicht ab? | Control-Mapping
Wer ist verantwortlich? | Owner und Fälligkeit
Welche Evidence belegt Umsetzung? | Nachweislink oder Nachweisbedarf
Was fehlt noch? | Decision, Gap oder Remediation

Ein gutes Pflichten-Mapping erzeugt keine Textwüste. Es verbindet Rechtsanforderung, Kontrollziel, konkrete Maßnahme und Nachweis. Genau an dieser Stelle kippen viele Programme, wenn sie nur mit Tabellen arbeiten: Die Tabelle sagt, dass eine Pflicht existiert, aber nicht, ob sie für ein konkretes System erfüllt ist.

Ergebnis nach 45 Tagen:

• jedes priorisierte System hat ein Pflichten-Mapping,
• Provider-/Deployer-Rolle ist dokumentiert,
• Controls sind mit Anforderungen verknüpft,
• Lücken sind als Aufgaben oder Entscheidungen sichtbar.

Phase 4: Tage 46-60 - FRIA-Entscheidung und Grundrechtsprüfung

Die Fundamental Rights Impact Assessment, kurz FRIA, ist für viele Deployer der Punkt, an dem AI-Act-Compliance operativ ernst wird. Sie zwingt Teams, den Nutzungskontext, betroffene Gruppen, Risiken, Aufsicht und Gegenmaßnahmen strukturiert zu betrachten.

Nicht jedes System braucht eine FRIA. Aber jedes System sollte eine dokumentierte FRIA-Entscheidung haben: erforderlich, nicht erforderlich oder unklar. Bei "unklar" braucht es eine verantwortete Entscheidung mit Frist.

Eine FRIA sollte mindestens diese Bereiche abdecken:

• Zweck und Einsatzkontext,
• betroffene Personen oder Gruppen,
• erwartete Vorteile,
• spezifische Schadensrisiken,
• Diskriminierungs- und Benachteiligungsrisiken,
• menschliche Aufsicht,
• Beschwerde- oder Eskalationswege,
• technische und organisatorische Maßnahmen,
• Restrisiko und Freigabeentscheidung.

Der wichtigste Praxistipp: Behandelt die FRIA nicht als separates PDF. Sie muss mit dem System-Record, der Klassifizierung, den Controls und den Nachweisen verbunden sein. Sonst entsteht genau die Lücke, die später teuer wird: Das Assessment beschreibt Risiken, aber niemand kann zeigen, welche Maßnahmen tatsächlich umgesetzt wurden.

Ergebnis nach 60 Tagen:

• FRIA-Status je relevantem System ist dokumentiert,
• erforderliche FRIAs haben Owner und Frist,
• Risiken sind mit Controls und Decisions verbunden,
• offene Restrisiken sind sichtbar.

Phase 5: Tage 61-75 - Controls und Evidence operationalisieren

Jetzt wird aus Governance Nachweisfähigkeit. Controls sind nur dann belastbar, wenn sie einem System, einer Pflicht und einer Evidence zugeordnet werden können.

Beispiele:

Control | Mögliche Evidence
Menschliche Aufsicht ist definiert | Review-Prozess, Schulungsnachweis, UI-Screenshot, Rollenbeschreibung
Datenquellen sind dokumentiert | Data Sheet, Vendor-Dokumentation, Datenflussdiagramm
Klassifizierung ist geprüft | Entscheidung mit Datum, Reviewer und Begründung
Modell- oder Vendor-Änderungen werden bewertet | Change Ticket, Release Note, Impact Assessment
Nutzer werden informiert | Produkttext, Help-Center-Artikel, UI-Hinweis

Evidence sollte nicht nur hochgeladen werden. Sie muss aktuell, verknüpft und prüfbar sein. Wenn ein Jira-Ticket geschlossen wird, aber der Nachweis fehlt, ist die Compliance-Arbeit nicht abgeschlossen. Wenn ein Confluence-Dokument geändert wird, kann ein alter Evidence-Link plötzlich weniger aussagekräftig sein. Wenn ein GitHub-Workflow eine sicherheitsrelevante Prüfung ausführt, kann dessen Status ein Nachweis sein - aber nur, wenn er dem richtigen Control zugeordnet ist.

Ergebnis nach 75 Tagen:

• Top-Pflichten haben Controls,
• Controls haben Owner,
• Evidence ist verlinkt oder als Lücke markiert,
• veraltete oder fehlende Nachweise sind priorisiert.

Phase 6: Tage 76-90 - Audit-Trail, Reports und Management-Review

Die letzten 15 Tage dienen nicht dem Aufräumen am Rand, sondern dem Aufbau einer wiederholbaren Steuerung.

Stellt für jedes priorisierte System diese Fragen:

1. Können wir erklären, warum das System in dieser Risikoklasse ist?
2. Können wir zeigen, welche Pflichten gelten?
3. Können wir zeigen, welche Controls die Pflichten abdecken?
4. Können wir Evidence vorlegen?
5. Können wir offene Lücken priorisieren?
6. Können wir Änderungen seit dem letzten Review nachvollziehen?
7. Können wir einen Report exportieren, der für Management oder Audit verständlich ist?

Ein Management-Review sollte nicht aus 40 Folien bestehen. Besser ist ein kompakter Status:

• Anzahl inventarisierter Systeme,
• Anzahl Hochrisiko- oder Grenzfall-Systeme,
• FRIA erforderlich/offen/abgeschlossen,
• Controls implementiert vs. offen,
• Evidence vollständig vs. fehlt/veraltet,
• Top-Entscheidungen,
• Top-Risiken,
• nächste 30 Tage.

Ergebnis nach 90 Tagen:

• priorisierte Systeme haben auditierbare Records,
• offene Lücken sind nicht versteckt, sondern steuerbar,
• Reports können erzeugt werden,
• die nächste Review-Routine ist definiert.

Entscheidungsmodell: Was zuerst bearbeiten?

Wenn die Inventur mehr Systeme findet, als ihr in 90 Tagen vollständig bearbeiten könnt, priorisiert nach Wirkung und Risiko.

Priorität | Kriterium | Warum
Sehr hoch | Entscheidungen über Personen | hohes Grundrechts- und Reputationsrisiko
Sehr hoch | Annex-III-Nähe | mögliche Hochrisiko-Pflichten
Hoch | produktiver Einsatz mit vielen Nutzern | größerer Impact bei Fehlern
Hoch | externe Vendor-Abhängigkeit | Dokumentations- und Lieferkettenrisiko
Mittel | interne Assistenz ohne Personenentscheidung | oft Transparenz-, Schulungs- oder Governance-Thema
Niedrig | experimenteller Prototyp ohne produktive Wirkung | beobachten, aber nicht zuerst voll ausbauen

Dieses Modell ist bewusst einfach. Es soll keine juristische Bewertung ersetzen, sondern Compliance-Teams helfen, Arbeit sichtbar zu priorisieren.

Checkliste für die ersten 90 Tage

• AI-System-Inventur angelegt
• Owner je System definiert
• Zweck, Nutzer, betroffene Personen und Datenquellen dokumentiert
• Provider-/Deployer-Rolle entschieden
• Risikoklasse je System dokumentiert
• Annex-III-Prüfung begründet
• Pflichten je System gemappt
• Controls mit Pflichten verknüpft
• FRIA-Status je System entschieden
• Evidence je Control verlinkt oder als Lücke markiert
• offene Decisions priorisiert
• Audit-Trail für Klassifizierung und Änderungen vorhanden
• Management-Report erzeugbar
• Review-Rhythmus für die nächsten 30 Tage festgelegt

Was ihr nicht auf später verschieben solltet

Drei Dinge wirken am Anfang klein und werden später teuer.

Erstens: unklare Ownership. Wenn niemand für ein System verantwortlich ist, wird jede Klassifizierung zur Diskussion und jede Evidence zur Suchaktion.

Zweitens: unverbundene Dokumente. Eine Policy, ein Spreadsheet und ein FRIA-PDF helfen wenig, wenn sie nicht auf dasselbe System und dieselbe Entscheidung zeigen.

Drittens: fehlende Änderungsverfolgung. AI-Systeme verändern sich schnell: neuer Vendor, neues Modell, neuer Workflow, neue Datenquelle. Ohne Versionierung wirkt der Compliance-Status aktueller, als er ist.

Wie Octangle dabei unterstützt

Octangle ist auf genau diesen Zusammenhang ausgelegt: AI-Systeme inventarisieren, Risikoklassen deterministisch ableiten, Pflichten nach Rolle mappen, FRIA-Workflows strukturieren, Controls mit Evidence verknüpfen und Reports auditierbar exportieren.

Wichtig ist dabei der Read-only-Ansatz. Octangle muss eure Produktionsumgebung nicht steuern, um Compliance sichtbar zu machen. Die Plattform dokumentiert, verknüpft und versioniert den Governance-Status. Das ist für viele Teams der pragmatische Mittelweg: genug Struktur für Audit und Management, ohne Compliance-Arbeit in operative Systeme zu verlagern.

Nächster Schritt

Wenn ihr erst beginnt, startet mit der AI-System-Inventur. Wenn ihr bereits eine Systemliste habt, prüft als Nächstes die Annex-III-Klassifizierung. Der 90-Tage-Plan funktioniert am besten, wenn beides zusammenläuft: vollständige Inventur und begründete Risikoklassifizierung.