Wenn Ihr Team die erste Hälfte des Jahres 2026 damit verbracht hat, sich auf eine August-Frist vorzubereiten: Sie hat sich verschoben. Wenn Sie daraus geschlossen haben, dass nun nichts zu tun ist: Es gibt weitere Neuigkeiten.
Dies ist eine technische Lesart eines Rechtstextes, keine Rechtsberatung. Wenn Sie in einem regulierten Bereich ausliefern, holen Sie juristischen Rat ein. Was folgt, ist der Teil, aus dem Tickets werden.
Die Frist, auf die Sie sich vorbereitet haben, hat sich verschoben
Im Rahmen des Digital Omnibus — einer vorläufigen politischen Einigung vom 6. Mai 2026, vom Rat eine Woche später bestätigt — verschieben sich die Hochrisiko-Pflichten für Systeme nach Anhang III vom 2. August 2026 auf den 2. Dezember 2027. Anhang I verschiebt sich vom 2. August 2027 auf den 2. August 2028. Regulatorische Sandboxes rücken um ein Jahr. Zusammenfassung der Einigung bei Gibson Dunn.
Zwei Dinge an dem Wort „vorläufig“ sind wichtig. Zum Zeitpunkt des Schreibens war die Einigung weder förmlich angenommen noch im Amtsblatt veröffentlicht — die Daten sind also die erwarteten, nicht die endgültigen. Und eine Frist, die sich einmal verschoben hat, kann sich erneut verschieben, in beide Richtungen. Das spricht dafür, die dauerhaften Teile jetzt zu bauen, statt einen Endspurt zu planen.
Die Hochrisiko-Fristen haben sich verschoben. Nichts von dem, was bereits galt, ist mitgegangen.
Verbotene Praktiken sind seit Februar 2025 untersagt. Die Pflichten für KI-Modelle mit allgemeinem Verwendungszweck gelten seit August 2025 und wurden ausdrücklich nicht verändert. Und zwei neue Verbote nach Artikel 5 — zu KI-generierten nicht einvernehmlichen intimen Darstellungen und zu Darstellungen sexuellen Kindesmissbrauchs — kommen mit einer Übergangsfrist bis zum 2. Dezember 2026. Dieses Datum liegt früher als jenes, um das Sie sich gerade nicht mehr sorgen.
Vier Stufen, technisch gelesen
Der AI Act klassifiziert Systeme, nicht Technologien. Dasselbe Modell hinter einem Spamfilter und hinter einer Einstellungsentscheidung liegt in zwei verschiedenen Stufen, und die Stufe ergibt sich daraus, was das System mit einem Menschen macht — nicht daraus, wie groß das Modell ist oder wer es geliefert hat.
Für die meisten Teams, die ein KI-Feature in ein bestehendes Produkt ausliefern, lautet die ehrliche Antwort: dritte Zeile — begrenztes Risiko, wo die Pflicht in der Offenlegung besteht. Nutzerinnen und Nutzer müssen wissen, dass sie es mit einem KI-System zu tun haben, und generierte Inhalte müssen entsprechend gekennzeichnet sein. Das ist ein Tag Arbeit — und ein Tag Arbeit, den die meisten Teams nicht erledigt haben.
Die Zeile darüber ist die, in der sich Budgets um eine Größenordnung ändern — und Teams landen dort häufiger, als sie erwarten. Alles, was Bewerbungen filtert, Kreditwürdigkeit bewertet, Zugang zu Bildung oder öffentlichen Leistungen zuteilt oder in kritischer Infrastruktur steckt, ist ein Kandidat. „Wir sortieren nur, ein Mensch entscheidet“ befreit Sie nicht automatisch — die Frage ist, wie viel dieser Mensch realistisch übersteuern kann.
Der praktische Weg zur Einstufung führt darüber, die Liste aus Anhang III gegen die eigene Feature-Liste zu lesen, statt aus Prinzipien herzuleiten. Die dort genannten Bereiche sind konkret: Biometrie, kritische Infrastruktur, allgemeine und berufliche Bildung, Beschäftigung und Personalmanagement, Zugang zu wesentlichen privaten und öffentlichen Leistungen einschließlich Kreditwürdigkeit, Strafverfolgung, Migration und Grenzkontrolle sowie Rechtspflege. Berührt Ihr Produkt einen davon, nehmen Sie hohes Risiko an, bis jemand Verantwortliches schriftlich begründet hat, warum nicht.
Sind Sie Anbieter oder Betreiber?
Das ist die nützlichste Unterscheidung im gesamten Text, und meist ist sie in einem Satz geklärt: Wer das Modell eines anderen über eine API aufruft, ist Betreiber. Die Pflichten drehen sich darum, Nutzern zu sagen, womit sie sprechen, echte menschliche Aufsicht zu ermöglichen, Aufzeichnungen zu führen und zu prüfen, ob der Modellanbieter die geschuldete Dokumentation veröffentlicht hat.
Die Falle: Die Grenze ist überschreitbar. Ein Modell zu fine-tunen, es wesentlich zu verändern oder unter eigenem Namen auszuliefern kann Sie zum Anbieter eines neuen Systems machen — und die Anbieterpflichten sind deutlich schwerer. Bevor ein Team mit dem Fine-Tuning beginnt, um ein paar Prozentpunkte Genauigkeit herauszuholen, sollte laut gefragt werden, ob diese Entscheidung auch die Spalte im Diagramm oben wechselt.
Betreiber zu sein heißt nicht, dass die Pflichten des Anbieters für Sie irrelevant sind — es heißt, dass Sie von ihnen abhängen. Dessen Dokumentation ist ein Eingang in Ihre eigene Compliance und gehört damit neben Verfügbarkeit und Preis in Ihre Lieferantenbewertung. Fragen Sie nach Modelldokumentation, Trainingsdaten-Zusammenfassung, Urheberrechtsrichtlinie und Zweckbestimmung — und danach, was mit allen vieren passiert, wenn die von Ihnen genutzte Version abgekündigt wird.
Was eine Hochrisiko-Einstufung im Bau kostet
Liest man diese Liste als Backlog statt als juristische Zusammenfassung, ändert sich ihre Gestalt. Vier der sechs sind technische Lieferergebnisse mit einem Schema, einer Testsuite oder einer Oberfläche — und keines davon lässt sich im Monat vor einem Audit rückwirkend erzeugen.
- Genauigkeit muss deklariert werden. Sie müssen Kennzahlen angeben und verteidigen können — das setzt ein repräsentatives, versioniertes Evaluierungsset voraus. Wenn Sie keines haben, ist das das erste Ticket.
- Data Governance ist Herkunftsarbeit. Woher jeder Trainings- oder Retrieval-Korpus stammt, auf welcher Grundlage Sie ihn nutzen dürfen und wie Sie ihn auf Verzerrungen geprüft haben. Überwiegend ein Dokumentationsproblem — und laufend erfasst deutlich billiger.
- Risikomanagement ist eine Schleife, kein Dokument. Es muss erneut durchlaufen werden, wenn sich das System ändert — bei einem KI-Feature also mindestens bei jeder Änderung von Modell oder Prompt.
Der sechste Punkt hat die längste Vorlaufzeit und den geringsten technischen Anteil. Die Konformitätsbewertung findet vor dem Inverkehrbringen statt, das System wird in eine EU-Datenbank eingetragen, und danach läuft die Marktbeobachtung. Für viele Systeme nach Anhang III ist die Bewertung eine Selbstbewertung gegen die Anforderungen statt eines externen Audits — was günstiger klingt, bis man merkt, dass Selbstbewertung bedeutet, sämtliche Nachweise selbst zu erzeugen, nach Zeitplan, mit jemandem, der unterschreibt.
Logging ist eine Schemaentscheidung, die Sie heute treffen
Hochrisiko-Systeme müssen über ihre Lebensdauer automatisch Aufzeichnungen führen. Schlicht gelesen sind das eine Aufbewahrungsrichtlinie und eine Tabellendefinition — und die Tabellendefinition ist der Teil, der sich später nicht mehr reparieren lässt, denn ein nie erfasstes Feld kann man nicht nachfüllen.
Das Feld, das Teams vergessen, ist retrieved_doc_ids. Ohne die Belege, die das Modell gesehen hat, hält ein Eintrag fest, dass eine Entscheidung fiel, aber nicht warum — und sie ein Jahr später zu reproduzieren wird zum Raten. Es ist dieselbe Disziplin, die ein Retrieval-System überhaupt debugbar macht: Die Trace-Detailtiefe, für die wir in der Kostenaufstellung argumentiert haben, ist im Ergebnis fast genau das, was die Verordnung aufzubewahren verlangt.
Zwei Design-Hinweise, die Schmerzen ersparen. Pseudonymisieren Sie die Subjekt-Kennung beim Schreiben, statt Rohdaten zu speichern, die Sie später auf Anfrage löschen müssen. Und speichern Sie Modell- und Prompt-Version als auflösbare Kennungen, nicht als Freitext — „gpt-latest“ ist keine Aufzeichnung von irgendetwas.
Bei der Aufbewahrung kollidiert das mit Ihren übrigen Pflichten. Der AI Act will Aufzeichnungen; die DSGVO will personenbezogene Daten nicht länger als nötig aufbewahrt und auf Verlangen gelöscht. Das ist vereinbar — pseudonymisieren, die Zuordnungstabelle trennen und die Aufbewahrung pro Feld statt pro Zeile festlegen —, aber vereinbar zur Entwurfszeit und teuer im Nachhinein. Entscheiden Sie die Aufbewahrungsfrist im selben Ticket, das die Tabelle anlegt.
Menschliche Aufsicht ist eine Schnittstelle, keine Richtlinie
Die Anforderung, dass ein Mensch das System beaufsichtigen kann, wird auf dem Papier regelmäßig durch einen Satz in einem Prozessdokument erfüllt — und im Produkt regelmäßig nicht. Der Test ist nicht, ob nominell ein Mensch eingebunden ist. Er lautet, ob dieser Mensch sehen kann, was das System entschieden hat, verstehen kann warum, und es übersteuern kann, ohne ein Ticket zu schreiben.
- Zeigen Sie die Belege, nicht nur das Urteil. Die prüfende Person braucht die abgerufenen Dokumente und die Konfidenz — auf demselben Bildschirm wie die Entscheidung.
- Machen Sie das Übersteuern zu einer erstklassigen Aktion. Ein Button, protokolliert, mit Begründungsfeld. Ist Übersteuern schwerer als Zustimmen, übersteuert niemand — und Ihre Aufsicht ist Dekoration.
- Beobachten Sie Ihre Übersteuerungsrate. Liegt sie nahe null, ist entweder das Modell exzellent oder die Oberfläche ein Abnickvorgang. Im Dashboard sieht beides gleich aus, im Audit sehr unterschiedlich.
Der AI Act benennt das Fehlerbild direkt: Automation Bias — die Neigung von Menschen, sich der Ausgabe einer Maschine gerade deshalb zu beugen, weil eine Maschine sie erzeugt hat. Aufsicht, die das nicht einkalkuliert, produziert eine prüfende Person, die vierhundertmal am Tag auf Zustimmen klickt. Konfidenz ehrlich darzustellen, Widersprüche sichtbar zu machen und gelegentlich eine schriftliche Begründung zu verlangen, sind die günstigen Gegenmaßnahmen — und es sind Entscheidungen der Oberfläche, getroffen von denjenigen, die den Prüfbildschirm entwerfen, nicht von denjenigen, die die Richtlinie schreiben.
Wofür die Bußgelder tatsächlich gedacht sind
Die in Compliance-Texten kursierende Schlagzahl lautet bis zu 35 Mio. € oder 7 % des weltweiten Umsatzes — eine Zahl, die man als Obergrenze für die schwerste Kategorie, verbotene Praktiken, lesen sollte und nicht als erwartete Kosten einer Dokumentationslücke. Sie stammt aus Sekundärzusammenfassungen, nicht aus der oben zitierten Kanzleinotiz, und ist entsprechend als Richtwert zu behandeln.
Nützlicher ist die Überlegung, dass Durchsetzung Beschwerden folgt und Beschwerden sichtbarem Schaden. Ein System, das seine Entscheidungen erklären kann, seine Belege zeigt und einen funktionierenden Übersteuerungspfad hat, erzeugt die Beschwerde meist gar nicht erst. Das ist dieselbe Eigenschaft, die es zu einem guten Produkt macht.
Es gibt auch ein wirtschaftliches Argument, das bei Budgetverantwortlichen besser ankommt als ein Bußgeld. Der Einkauf großer Unternehmen im DACH-Raum stellt diese Fragen bereits in Security-Reviews: Welche Stufe ist das, wo liegen die Logs, wer kann übersteuern. Ein Team, das im Termin antworten kann statt per Nachfass-E-Mail, schließt schneller ab. Die Compliance-Arbeit und die Vertriebsunterstützung erweisen sich als dieselben Artefakte.
Was Sie mit der gewonnenen Zeit tun sollten
- Stufen Sie jedes bereits ausgelieferte KI-Feature ein. Je eine Zeile mit Stufe und Begründung. Die meisten werden begrenztes Risiko sein — und das eine zu finden, das es nicht ist, ist der ganze Zweck der Übung.
- Liefern Sie die Offenlegung jetzt aus. Nutzern zu sagen, dass sie mit einer KI sprechen, ist die günstigste Pflicht des AI Act — und die am häufigsten übersprungene.
- Reparieren Sie das Log-Schema, bevor das Volumen kommt. Ein Feld hinzuzufügen ist eine Migration; es rückwirkend auf zwei Jahre Historie anzuwenden ist unmöglich.
- Bauen Sie das Eval-Set, das Sie ohnehin brauchen. Deklarierte Genauigkeit setzt gemessene Genauigkeit voraus. Das ist die Pflicht mit der längsten Vorlaufzeit und dem größten Produktnutzen jenseits der Compliance.
- Lesen Sie die Termine in sechs Monaten erneut. Sie haben sich einmal verschoben — durch eine vorläufige Einigung, die bei Abfassung dieses Textes noch nicht im Amtsblatt stand.
Fast alles auf dieser Liste würde ein sorgfältiges Team ohnehin bauen, unabhängig von der Verordnung. Das ist das Beruhigendste am AI Act — und der Grund, warum eine verschobene Frist den Zeitplan ändert, nicht die Arbeit.
