Am 2. August 2026 werden die GPAI-Pflichten des EU AI Act scharfgeschaltet — Transparenz, Dokumentation, Copyright-Policy, Trainingsdaten-Zusammenfassungen. Für Mittelständler, die mit GPAI-Agenten Software bauen, fliessen diese Pflichten flussabwärts. Wer nicht weiss, welches Modell hinter seinen Agenten steckt, hat ein Problem.
Countdown: noch rund vier Wochen bis zum 2. August 2026
Heute ist der 7. Juli 2026. In rund vier Wochen, am 2. August 2026, wird der grösste verbleibende Block des EU AI Act aktiv — und mit ihm die Pflichten für General-Purpose-AI-Modelle (GPAI). Das sind genau jene Modelle, die heute die KI-Agenten antreiben, mit denen Mittelständler ihre Software entwickeln lassen.
Ich schreibe diesen Beitrag bewusst nicht als weiteren Rundumschlag zum AI Act. Über die allgemeinen Fristen und den Digital Omnibus haben wir an anderer Stelle geschrieben. Hier geht es um eine einzige Frage: Was bedeutet der 2. August konkret für ein DACH-Unternehmen, das GPAI-basierte Agenten in der Softwareentwicklung einsetzt — also für fast jedes Tech-Team, das 2026 ernsthaft mit KI arbeitet.
Was am 2. August 2026 konkret in Kraft tritt
Klingt interessant?
Ab diesem Datum gelten für Anbieter von GPAI-Modellen verbindliche Pflichten. Die wichtigsten:
- Technische Dokumentation des Modells — Architektur, Trainingsprozess, Evaluierung, Grenzen der Nutzung.
- Transparenz gegenüber nachgelagerten Anbietern, also gegenüber jedem, der das Modell in eigene Systeme integriert. Dazu gehört Information, die ihr braucht, um eure eigenen Pflichten zu erfüllen.
- Copyright-Policy: Anbieter müssen eine Richtlinie zur Einhaltung des EU-Urheberrechts vorhalten.
- Zusammenfassung der Trainingsdaten nach einer von der EU bereitgestellten Vorlage — öffentlich, damit Rechteinhaber nachvollziehen können, was verwendet wurde.
Ein wichtiges Detail zum Zeitplan: Modelle, die vor dem 2. August 2025 in Verkehr gebracht wurden, haben bis zum 2. August 2027 Zeit, diese Pflichten zu erfüllen — eine verlängerte Übergangsfrist für Bestandsmodelle. Neue Modelle ab August 2025 müssen ab dem 2. August 2026 liefern.
Der Hebel dahinter ist nicht zaghaft: Bei Verstössen drohen Bussgelder von bis zu 35 Mio. Euro oder 7 % des weltweiten Jahresumsatzes — je nachdem, welcher Betrag höher ist.
Und ja, der separate Digital Omnibus verschiebt einige Pflichten im Hochrisiko-Bereich nach hinten. Das ist real, aber es ist nicht das Thema dieses Beitrags und es betrifft die GPAI-Pflichten nicht. Wer auf eine generelle Verschiebung hofft, verwechselt zwei verschiedene Baustellen.
Warum euch das betrifft, obwohl ihr keine Modelle baut
Der erste Reflex vieler Tech-Leads: "Wir trainieren keine Modelle, also betrifft uns das nicht." Das ist genau der Trugschluss.
Die GPAI-Pflichten liegen formal beim Anbieter des Modells. Aber sie fliessen flussabwärts. Wer einen GPAI-basierten Agenten in seiner Entwicklung einsetzt, ist ein nachgelagerter Akteur — und braucht spätestens jetzt belastbare Antworten auf drei Fragen:
- 1.Welches Modell steckt eigentlich hinter unseren Agenten? Nicht die Marke des Tools, sondern das konkrete Modell, das den Code generiert.
- 2.Können wir die Compliance-Unterlagen dieses Anbieters vorzeigen? Dokumentation, Copyright-Policy, Trainingsdaten-Zusammenfassung — habt ihr Zugriff darauf oder verlasst ihr euch blind?
- 3.Was tun wir, wenn dieses Modell die Pflichten nicht erfüllt? Könnt ihr es austauschen, oder ist euer Stack hart daran gekoppelt?
Genau hier wird Architektur zur Compliance-Frage. Wer seinen Agenten-Stack intransparent an einen einzigen ausländischen Anbieter gebunden hat, hat zwei Probleme gleichzeitig: Er kann die nötige Dokumentation schwerer beschaffen, und er kann ein nicht-konformes Modell schwerer ersetzen.
Was das für CTOs und Tech-Leads bedeutet
Drei konkrete Konsequenzen für die nächsten vier Wochen:
Erstens: Inventar vor Frist. Ihr braucht eine klare Liste, welches Modell welche Aufgabe in eurer Entwicklung übernimmt. Wenn niemand im Team diese Frage aus dem Stand beantworten kann, ist das die erste Lücke. Ein Audit fragt nicht nach dem Tool-Namen, sondern nach dem Modell dahinter.
Zweitens: Dokumentierbarkeit ist eine Architektur-Eigenschaft. Die Fähigkeit, auf Knopfdruck zu sagen "diese Komponente wurde mit Modell X erzeugt, hier ist dessen Compliance-Unterlage" ist kein Excel-Sheet, das man kurz vor dem Audit füllt. Es ist eine Eigenschaft des Systems — entweder die Plattform weiss es, oder ihr ratet.
Drittens: Austauschbarkeit ist eure Versicherung. Wenn ein Anbieter die GPAI-Pflichten nicht erfüllt — oder seine Übergangsfrist bis 2027 ausreizt, während ihr Sicherheit braucht — dann ist die entscheidende Frage, ob der Wechsel auf ein konformes Modell ein Quartalsprojekt oder eine Konfigurationsänderung ist. Harte Single-Vendor-Kopplung macht aus jeder Compliance-Frage einen Notfall.
Und genau hier kommt nopex ins Spiel
Der 2. August bestätigt, was wir seit Langem sagen: Die Abhängigkeit von einem einzigen, intransparenten Modell-Anbieter ist kein theoretisches Risiko mehr. Sie ist jetzt ein regulatorisches.
nopex ist genau dafür gebaut. Unsere Plattform gibt euch Transparenz darüber, welches Modell welche Aufgabe übernimmt — nicht als nachträgliche Liste, sondern als Eigenschaft des Systems. Und weil die Anwendungslogik nicht hart an einen Anbieter gekoppelt ist, könnt ihr von einem Modell, das die GPAI-Pflichten nicht erfüllt, wegrouten, ohne euer Produkt anzuhalten. Dazu kommen europäische Rechenzentren und offene Modelle, wo es sinnvoll ist.
Das Ergebnis: AI-Act-Bereitschaft ist bei nopex in die Plattform eingebaut, statt ein Last-Minute-Kraftakt zu sein. Während andere in den nächsten vier Wochen herausfinden, welches Modell überhaupt hinter ihren Agenten steckt, ist die Antwort bei euch bereits dokumentiert — und das Modell jederzeit austauschbar. Der 2. August 2026 ist dann kein Stichtag zum Bangen, sondern ein Datum wie jedes andere.
