
10²⁵ FLOPs. Diese Zahl entscheidet künftig darüber, ob ein KI-Modell als systemisches Risiko gilt – mit allen Konsequenzen für Red-Teaming, Incident-Meldepflichten und Governance-Strukturen. Was die EU-Kommission hier als technische Kennzahl vermarktet, ist in Wirklichkeit Infrastrukturpolitik: die Definition dessen, welche KI-Fähigkeiten Europa für gesellschaftlich kritisch hält.
Wer die neuen GPAI-Leitlinien des AI Office liest, stößt schnell auf eine Zahl: 10²⁵ FLOPs. Das sind zehn Millionen Trillionen Rechenoperationen – kumuliert über den gesamten Trainingsprozess eines KI-Modells. Modelle, die diesen Wert erreichen oder überschreiten, werden nach Artikel 51 des EU AI Acts als potenziell hochgefährlich eingestuft. Für sie gilt ein deutlich schärferes Pflichtenheft.
Das klingt nach Technik. Es ist aber vor allem Politik. Die EU-Kommission hat mit diesem Schwellenwert eine Entscheidung getroffen, die weit über Compliance-Fragen hinausgeht: Sie definiert, ab welcher Rechenleistung ein Foundation Model als so mächtig gilt, dass der Staat zwingend eingreifen muss. Das ist KI-Infrastrukturpolitik – verkleidet als Parameterdefinition.
Der Unterschied zu normalen GPAI-Modellen ist juristisch erheblich. Unterhalb von 10²⁵ FLOPs gelten Pflichten wie Transparenzdokumentation und Urheberrechtskonformität. Oberhalb dieser Schwelle kommen Risikobewertung, Red-Teaming, Cybersicherheitsanforderungen und Incident-Meldepflichten gegenüber der EU-Kommission hinzu. Der Sprung ist keine lineare Eskalation, sondern ein qualitativer Regimewechsel.
Für die Einordnung wichtig: Der AI Act selbst ist rechtsverbindlich. Die konkreten GPAI-Leitlinien, die das AI Office entwickelt, sind teilweise noch im Konsultationsstadium. Das bedeutet, Unternehmen müssen schon heute mit den Anforderungen arbeiten, die sich aus dem Gesetzestext ergeben – auch wenn die Auslegungsdetails noch evolvieren.
FLOPs steht hier für Floating Point Operations – also die absolute Gesamtzahl von Gleitkommaoperationen, die beim Training eines Modells anfallen. Wichtig: Es geht nicht um Operationen pro Sekunde (FLOPS), sondern um die kumulierte Trainingsarbeit. Diese Verwechslung findet sich überraschend häufig, auch in offiziellen Dokumenten.
Zur Einordnung: Bereits erste Open-Source-Modelle überschreiten diese Schwelle. Metas Llama-3-405B liegt laut Einschätzung der österreichischen Regulierungsbehörde RTR bei etwa 3,8 × 10²⁵ FLOPs Trainingsaufwand – damit deutlich jenseits der Grenze. Modelle der GPT-4- oder Gemini-Klasse bewegen sich nach Angaben der EU-Kommission in vergleichbaren Größenordnungen, wobei exakte FLOPs-Zahlen für proprietäre Modelle nicht offiziell veröffentlicht wurden und auf Schätzungen beruhen.
Wichtig für die Bewertung: 10²³ FLOPs ist die untere Schwelle, ab der ein Modell überhaupt als GPAI-Modell gilt – vorausgesetzt, es ist funktional allgemein einsetzbar, also kein reines Spezialsystem für Wettervorhersage oder Transkription. 10²⁵ FLOPs ist dann die systemische Risikoschwelle. Zwischen diesen beiden Größenordnungen liegt ein Faktor 100 – und damit die Trennlinie zwischen geregeltem GPAI-Modell und hochreguliertem System mit systemischem Risiko.
Das Problem: FLOPs allein sagen wenig über tatsächliche Fähigkeiten oder Risikoprofile. Eine hocheffiziente Architektur kann mit weniger Trainingsrechenleistung gefährlichere Fähigkeiten entwickeln als ein ineffizientes Modell knapp über der Schwelle. Das ist kein akademischer Einwand – das ist eine strukturelle Schwäche des Kriteriums, die die juristische Fachgemeinschaft bereits intensiv diskutiert.
Für GPAI-Modelle mit systemischem Risiko schreibt der AI Act ein Bündel zusätzlicher Anforderungen vor. Red-Teaming ist dabei eines der anspruchsvollsten: Anbieter müssen ihr Modell systematisch auf gefährliche Fähigkeiten testen – Exploit-Generierung, Bio-Risiken, Manipulation, Desinformation. Das ist kein einmaliger Prozess, sondern eine laufende Bewertungspflicht.
Dazu kommt das Incident-Reporting: Schwerwiegende Zwischenfälle müssen der EU-Kommission gemeldet werden. Was genau als „schwerwiegend“ gilt, wird in den laufenden Leitlinien konkretisiert. Die Meldepflicht greift auch früher: Anbieter müssen die Kommission innerhalb von zwei Wochen informieren, wenn sie vernünftigerweise erwarten oder feststellen, dass ihr Modell die 10²⁵-FLOPs-Schwelle erreicht oder überschreitet. Das ist keine Kannbestimmung, sondern eine explizite Frühwarnanforderung.
Cybersicherheitsmaßnahmen müssen robust ausgestaltet sein – konkret bedeutet das: Schutz gegen Modelldiebstahl, Zugriffskontrolle für kritische Kapazitäten, Monitoring auf Missbrauchsmuster. Hinzu kommen Transparenzpflichten: technische Dokumentation, Evaluationsergebnisse, Angaben zum Energieverbrauch. All das muss nachvollziehbar und für eine Plausibilitätsprüfung durch die Aufsicht zugänglich sein.
Meiner Einschätzung nach unterschätzen viele Unternehmen, was das operativ bedeutet. Hier geht es nicht darum, ein paar Formulare auszufüllen. Red-Teaming in diesem Umfang erfordert spezialisierte Teams, definierte Angriffsszenarien und dokumentierte Ergebnisse. Das ist Sicherheitsforschung – keine Compliance-Checkliste.
In der öffentlichen Diskussion dominiert die 10²⁵-FLOPs-Schwelle. Was dabei zu kurz kommt: Die EU-Kommission kann Modelle auch unterhalb dieser Schwelle als systemisches Risiko einstufen. Artikel 51 Absatz 1 lit. b des AI Acts gibt ihr diese Ermessensbefugnis – gestützt auf Benchmarkergebnisse, Nutzerzahlen, Missbrauchsfälle oder Expertenwarnungen.
Das hat strategische Implikationen. Wer glaubt, mit einem Modell bei 9 × 10²⁴ FLOPs auf der sicheren Seite zu sein, sitzt einem Irrtum auf. Die Kommission kann handeln, wenn ein Modell trotz knapp unterschrittener Rechenleistungsschwelle Fähigkeiten zeigt, die systemische Risiken begründen. Sicherheitsforscher weisen seit Längerem darauf hin, dass gefährliche Fähigkeiten – automatisierte Exploit-Suche, Biowaffenassistenz, großskalige Desinformation – schon weit unterhalb der 10²⁵-Marke entstehen können.
Die offiziellen FAQ der EU-Kommission zu GPAI-Modellen machen deutlich, dass der FLOPs-Wert eine Vermutungsregel ist, keine abschließende Definition. Das Ermessen der Kommission ist das eigentliche Steuerungsinstrument – und damit auch das politisch sensibleste.

Die GPAI-Sicherheitsstandards treffen nicht alle Akteure gleich. Große Anbieter wie Google, Meta oder Microsoft haben die Kapazitäten für umfassende Risikobewertungen, Red-Teaming-Teams und juristische Compliance-Abteilungen. Europäische Start-ups und Open-Source-Projekte, die in dieselbe Rechenleistungsklasse vordringen, stehen vor einer anderen Realität.
Das Llama-3-405B-Beispiel ist hier aufschlussreich. Meta hat das Modell open source veröffentlicht – aber die regulatorischen Pflichten für systemische GPAI-Modelle treffen den Anbieter. Was bedeutet das für Community-Forks, für Forscher, die das Modell fine-tunen, für europäische Unternehmen, die darauf aufbauen? Die Zurechnung von Downstream-Verantwortung ist noch nicht abschließend geklärt. Grundsätzlich liegt die Verantwortung beim ursprünglichen Modellentwickler – aber Downstream-Akteure können zusätzliche Pflichten treffen, wenn sie Modelle in Hochrisikosysteme integrieren.
Das schafft ein Asymmetrieproblem: Wer ein systemisches GPAI-Modell von einem großen US-Anbieter nutzt, operiert unter anderem Regulierungsregime als ein europäisches Team, das ein vergleichbares Modell selbst entwickelt. Die GPAI-Sicherheitsstandards sind formal neutral – sie wirken strukturell aber zugunsten kapitalintensiver, integrierter Anbieter.
Zugleich – und das ist mir wichtig zu betonen – ist das kein Argument gegen die Regulierung. Es ist ein Argument dafür, dass Förderinstrumente für europäische Modellentwicklung und Compliance-Kapazitäten Hand in Hand gehen müssen. Die EU kann nicht einerseits Sicherheitsstandards für Foundation Models setzen und andererseits europäische Akteure in der Entwicklung dieser Modelle strukturell benachteiligen.
Die Wahl von FLOPs als primäres Kriterium für systemisches Risiko ist pragmatisch – und hat erkennbar ein Ablaufdatum. Die Messgröße funktioniert als grober Proxy für Trainingsaufwand und Modellfähigkeit solange, wie die Beziehung zwischen Rechenleistung und Capability-Niveau stabil bleibt. Das ist sie nicht zwingend.
Effizientere Trainingsverfahren, neue Architekturen, Mixture-of-Experts-Modelle – all das kann dazu führen, dass ein Modell mit deutlich weniger FLOPs vergleichbare oder überlegene Fähigkeiten entwickelt. Die GPAI-Leitlinien erkennen dieses Problem an und sehen ergänzend Parameter wie Datensatzgröße, Trainingszeit und Energieverbrauch als Indikatoren vor. Aber die FLOPs-Schwelle bleibt der zentrale Auslöser für die Systemrisiko-Vermutung.
Die Bundesnetzagentur und die österreichische RTR weisen in ihren Dokumentationen darauf hin, dass mehrdimensionale Kriterien zunehmend an Bedeutung gewinnen werden. Das ist der richtige Richtungspfeil. Bis ein robusteres Bewertungsframework etabliert ist, bleibt FLOPs das Instrument – mit allen Unschärfen, die das mit sich bringt. Anbieter sollten FLOPs-Schätzungen immer transparent als solche dokumentieren, da exakte Zahlen aus Trainingsdokumentationen abgeleitet werden und Annahmen enthalten.
Was in Brüssel als Regulierung definiert wird, ist international gesehen eine Standardsetzung. Die USA und das Vereinigte Königreich verfolgen prinzipienbasierte Ansätze, die keine harte FLOPs-Grenze kennen und stattdessen auf Capabilities und Nutzungskontexte fokussieren. Die EU zieht eine quantitative Linie – das ist kein technisches, sondern ein gouvernanzpolitisches Signal.
Für internationale Anbieter bedeutet das: Sie entwickeln Modelle unter unterschiedlichen regulatorischen Regimes. Ein Modell, das in den USA ohne spezifische Systempflichten betrieben wird, kann in der EU als systemisches Risiko eingestuft sein – mit Red-Teaming-, Meldepflicht- und Governance-Anforderungen, die in anderen Jurisdiktionen nicht gelten. Die naheliegende Konsequenz sind EU-spezifische Modellvarianten oder -dokumentationen, die sich an den GPAI-Sicherheitsstandards ausrichten.
Das ist keine dystopische Spekulation, sondern die logische Folge divergierender regulatorischer Anforderungen. Wie das AI Office diesen Spagat moderiert – zwischen europäischer Regulierungsambition und globalem KI-Entwicklungstempo – wird eine der entscheidenden Fragen der nächsten Jahre sein. Modellentwickler, die für den EU-Markt entwickeln oder dort verbreitet genutzte Modelle betreiben, sollten die Einstufungskriterien frühzeitig in ihre Entwicklungsstrategie integrieren.
Die Einführung quantitativer Schwellenwerte wie 10²⁵ FLOPs als Regulierungsinstrument ist nicht unumstritten – und die Gegenargumente verdienen eine sachliche Auseinandersetzung, statt weggewischt zu werden.
Ein gewichtiger Einwand lautet: Regulierung durch Rechenleistungsgrenzen verlangsamt legitime Forschung, ohne die eigentlichen Risikoquellen zu adressieren. Wer argumentiert, dass gefährliche Fähigkeiten schon bei 10²³ FLOPs entstehen können – etwa bei spezialisierten Modellen für Cyberangriffe oder chemische Synthese –, hat einen Punkt: Die FLOPs-Grenze schützt nicht vor spezialisierten Hochrisikomodellen, die unterhalb der Schwelle operieren, aber konzentrierte Schäden anrichten können.
Ein zweiter Einwand betrifft die Messbarkeit: FLOPs-Schätzungen sind keine exakten Naturkonstanten, sondern Näherungswerte, die von Trainingsinfrastruktur, Präzisionsgrad der Rechenoperationen und Dokumentationspraktiken abhängen. Zwei verschiedene Methoden zur FLOPs-Berechnung desselben Modells können zu erheblich abweichenden Ergebnissen führen. Die Frage, welche Berechnungsmethode die EU-Kommission als standardkonform anerkennt, ist noch nicht abschließend beantwortet – und genau hier entsteht Rechtsunsicherheit für Entwickler, die im Grenzbereich der Schwelle operieren.
Ein dritter, oft gehörter Einwand aus der Industrie: Compliance-Pflichten dieser Größenordnung wirken de facto als Markteintrittsbarriere, die established players schützt und neue Wettbewerber – insbesondere aus Europa – strukturell benachteiligt. Dieses Argument sollte nicht reflexartig als Lobbyismus abgetan werden. Es beschreibt eine reale Dynamik, die Regulierer im Blick behalten müssen.
Gleichzeitig hat die Gegenseite starke Argumente: Ohne verbindliche Mindeststandards für Sicherheitsprüfungen gibt es keinen Anreiz, kostspielige Red-Teaming-Prozesse durchzuführen. Ein race to the bottom bei Sicherheitsstandards zwischen Jurisdiktionen wäre die wahrscheinlichere Alternative – und das kann nicht im Interesse von Gesellschaft oder Industrie sein. Die Frage ist nicht ob reguliert wird, sondern wie präzise und anpassungsfähig das Instrument ist.
Für Entwicklerteams und Unternehmen, die mit Foundation Models arbeiten oder diese entwickeln, lassen sich aus dem bestehenden Rechtsrahmen konkrete Schritte ableiten – auch wenn einzelne Auslegungsfragen noch offen sind.
Der AI Act ist rechtsverbindlich. Die FLOPs-Schwelle von 10²⁵ steht im Gesetzestext. Wer ein GPAI-Modell über dieser Schwelle betreibt oder in absehbarer Zeit entwickelt, muss mit den Systemrisikopflichten rechnen: Risikobewertung, Red-Teaming, Cybersicherheitsmaßnahmen, Incident-Reporting, technische Dokumentation. Die Zweiwochenfrist für die Kommissionsmeldung gilt explizit.
Noch offen sind konkrete Auslegungsfragen: Was genau zählt als „funktional allgemein“? Welche Methoden für FLOPs-Schätzungen akzeptiert die Kommission als plausibel? Wie granular müssen Incident-Reports sein? Hier werden Leitlinien, Praxisfälle und möglicherweise Gerichtsverfahren die Konturen schärfen.
Für Unternehmen und Entwicklerteams bedeutet das: Wer Modelle in der Nähe der 10²⁵-FLOPs-Schwelle entwickelt oder betreibt, sollte jetzt handeln – Trainingsdokumentation lückenlos führen, FLOPs-Schätzverfahren etablieren und intern klären, ob ein Modell unter die GPAI-Definition fällt. Wer erst wartet, bis Leitlinien vollständig konsolidiert sind, wartet zu lang. Das systemische Risiko-Framework ist keine Zukunftsmusik mehr.
Die größere Frage bleibt: Wird die EU ihre Sicherheitsstandards für Foundation Models zum globalen Referenzpunkt machen – oder entsteht ein Flickenteppich aus inkompatiblen Anforderungen, der europäische Innovationskapazitäten mehr kostet als er schützt? Schreiben Sie uns Ihre Einschätzung – die Debatte hat gerade erst begonnen.
Um Ihnen ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn Sie diesen Technologien zustimmen, können wir Daten wie Ihr Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn Sie Ihre Zustimmung nicht erteilen oder widerrufen, können bestimmte Merkmale und Funktionen beeinträchtigt werden.