Es gibt einen Satz, den ich in den letzten Wochen mehrfach gehört habe. In Gesprächen mit Gründern, in Briefings mit Produktverantwortlichen, in Pitch-Decks, die für den europäischen Markt aufbereitet wurden: „Wir warten erst mal ab, bis der Digital Omnibus durch ist.“
Dieser Satz ist verständlich. Er ist strategisch. Und er ist gefährlich.
Was der „Digital Omnibus“ ist — und was er nicht ist
Die Europäische Kommission hat am 19. November 2025 einen sogenannten Digital Omnibus-Vorschlag vorgelegt 📎, der unter anderem die Anwendung der Hochrisiko-Regeln des EU AI Act an die Verfügbarkeit konkreter Unterstützungsinstrumente — Standards, Common Specifications, Leitlinien — koppeln soll. Die Kommission beschreibt dabei eine Obergrenze für diesen Aufschub. Das ist keine pauschale Fristverlängerung per politischem Beschluss. Es ist ein spezifischer Mechanismus, der bestimmte Bedingungen voraussetzt.
Das Wort, auf das es ankommt: voraussetzt.
Stand März 2026 hat der Rat eine Verhandlungsposition beschlossen 📎 mit festen Spätest-Terminen — 2. Dezember 2027 für eigenständige Hochrisiko-KI-Systeme, 2. August 2028 für in regulierte Produkte eingebettete Systeme. Die Kopplung an Standards und Leitlinien bleibt, aber mit klarer Obergrenze. Am 26. März 2026 stimmt das Europäische Parlament voraussichtlich über seine Position zum Omnibus ab. Der Ausgang ist offen — der Trilog folgt danach. Der 2. August 2026 bleibt bis auf Weiteres die rechtlich geltende Frist.
Und selbst wenn der Omnibus in Kraft tritt: Risikomanagement, Logging-Architektur, technische Dokumentation und Human Oversight lassen sich nicht auf Knopfdruck aktivieren. Diese Pflichten müssen vorbereitet sein, bevor das Anwendungsdatum gilt — unabhängig davon, wann genau es kommt.
Wer heute aufhört, sich vorzubereiten, wettet darauf, dass dieser Prozess rechtzeitig abgeschlossen wird. Und dass das Ergebnis tatsächlich die erhoffte Kopplung enthält. Und dass die Unterstützungsinstrumente dann tatsächlich bereitstehen.
Alles möglich. Nichts garantiert.
Was am 2. August 2026 gilt, wenn nichts passiert
Wenn der Omnibus nicht rechtzeitig in Kraft tritt, gelten die ursprünglich vorgesehenen Anwendungszeitpunkte und Anforderungen des EU AI Act 📎 — und zwar gestaffelt. Hier ist eine Präzisierung wichtig, die im öffentlichen Diskurs regelmäßig untergeht:
Für Hochrisiko-KI-Systeme nach Annex III — also eigenständige KI-Anwendungen in Bereichen wie kritische Infrastruktur, Bildung, Beschäftigung oder Strafverfolgung — gelten die Anforderungen grundsätzlich ab dem 2. August 2026. Für Hochrisiko-KI, die nicht als eigenständiges System betrieben wird, sondern als Bestandteil regulierter Produkte eingesetzt wird — also Systeme, die Teil eines bereits regulierten Produkts sind, etwa in Medizinprodukten oder Sicherheitssystemen — gilt eine verlängerte Übergangsfrist bis zum 2. August 2027. Juristisch bedeutet das vereinfacht: Diese Kategorie fällt unter Article 6(1) in Verbindung mit Annex I des AI Act.
Wer sein Produkt voreilig aus der Hochrisiko-Kategorie herausrechnet, übersieht möglicherweise Annex III. Ein konkretes Beispiel: Ein Startup, das eine KI-gestützte Anomalieerkennung für Industrienetzwerke verkauft — also ein System, das Angriffe oder Fehler in industriellen Netzwerken erkennt, wie SIEM, OT-Monitoring oder Bedrohungsanalyse — ist kein Fall, den man ohne fundierte Prüfung aus dem Hochrisiko-Bereich herausdefinieren sollte. Je nach konkreter Funktion und Einbindung in den Betrieb kann sich ein solches System in Annex-III-Territorium bewegen, insbesondere wenn es als Sicherheitskomponente (Safety Component) in der Steuerung kritischer Infrastruktur eingesetzt wird. Nicht weil das Produkt gefährlich ist. Sondern weil es dort eingesetzt wird, wo der AI Act genau hinschaut. Die Einordnung ist in vielen Fällen nicht trivial und bewegt sich häufig in Auslegungsbereichen, die ohne fundierte Analyse leicht falsch bewertet werden.
Die Anforderungen, die für relevante Hochrisiko-Systeme greifen, umfassen unter anderem: vollständige technische Dokumentation vor dem Inverkehrbringen, Konformitätsbewertungsverfahren je nach Systemkategorie, Transparenzpflichten gegenüber Nutzern, Anforderungen an menschliche Aufsicht (Human Oversight) — die sich nicht nachträglich ins Produkt einbauen lassen — sowie Registrierungs- und Datenbankpflichten, also die Pflicht, bestimmte Hochrisiko-Systeme vor ihrem Einsatz in einer zentralen EU-Datenbank zu erfassen. Diese Datenbank macht einen Großteil der registrierten Informationen öffentlich zugänglich — wobei bestimmte Bereiche nicht öffentlich sind und Hochrisiko-Systeme in kritischer Infrastruktur teils auf nationaler Ebene registriert werden. Die Registrierung ist dabei kein administrativer Schritt, sondern die sichtbare Spitze eines Systems, dessen technische und organisatorische Grundlagen — Intended Use, Risikomanagement, Human Oversight, Logging, Nachvollziehbarkeit — vollständig dokumentiert und intern belegbar sein müssen. Was in der Datenbank steht, muss im Audit standhalten.
Diese Anforderungen sind typischerweise nicht kurzfristig erfüllbar, insbesondere wenn Produktarchitektur und Dokumentation nicht vorbereitet sind. Wer heute mit der Klassifizierung beginnt, kauft sich Zeit. Wer wartet, hat sie nicht mehr.
Zur Einordnung, wo der Markt heute steht: Marktbeobachtungen zeigen konsistent, dass die große Mehrheit der betroffenen Unternehmen — auch innerhalb der EU — weder ein vollständiges KI-Inventar abgeschlossen hat, noch einen dokumentierten Verantwortlichkeitsrahmen für KI-Governance etabliert hat, noch mit Konformitätsbewertungen begonnen hat. Für Anbieter aus Nicht-EU-Märkten, die den Regulierungsrahmen in einer Fremdsprache lesen und ohne gewachsene Compliance-Infrastruktur arbeiten, ist die Ausgangslage strukturell noch schwieriger.
Was das konkret bedeutet, lässt sich an einem typischen Fall zeigen. Ein israelisches Startup bringt eine Industrial Anomaly Detection Platform — also ein KI-System zur Erkennung von Angriffen und Anomalien in industriellen Netzwerken — auf den deutschen Markt, zur OT-Überwachung für Energie- und Wasserversorger. Die Grunddaten sind kein Problem. Der Intended Use auch nicht: „Erkennung von Anomalien in industriellen Steuerungsnetzwerken zur Unterstützung von Sicherheitsentscheidungen.“ Klingt harmlos. Regulatorisch bedeutet es: KRITIS plus operative Entscheidungsunterstützung — potenziell Annex-III-Hochrisiko.
Dann kommt die Systembeschreibung. Input: Netzwerk-Traffic, Logs, Sensorwerte. Output: Alerts, Risikoscores, Handlungsempfehlungen. Beim Wort „Handlungsempfehlung“ hakt der Auditor ein: Wie kommt diese zustande? Ist sie nachvollziehbar? Kann ein Mensch eingreifen — und stoppen? Die typische Antwort: „Das System unterstützt den Operator bei Entscheidungen.“ Das reicht nicht.
Beim Logging dasselbe Muster. Alerts wurden gespeichert. Was fehlt: Warum wurde der Alarm ausgelöst? Welche Daten haben dazu geführt? Welche Modellversion war aktiv? Ohne das keine Auditierbarkeit. Genau an diesem Punkt kippt ein Formalthema in ein Produktproblem. Das ist kein Datenbankproblem. Es ist ein Architektur- und Prozessproblem — bereits vorhanden, nur jetzt sichtbar gemacht.
Warum das Anbieter aus Nicht-EU-Märkten besonders betrifft
Unternehmen, die außerhalb der EU entwickeln und in Europa verkaufen wollen, operieren in einer spezifischen Ausgangslage. Die Produktentwicklung geschieht in einem regulatorischen Umfeld, das dem EU AI Act in Struktur und Anforderungstiefe wenig ähnelt — unabhängig davon, wie erfahren das jeweilige Unternehmen in anderen regulatorischen Kontexten ist. Und der Vertriebsdruck Richtung Europa ist hoch, während die Zeit für belastbare Nachweisführung knapp wird.
Das gilt besonders für Anbieter aus Märkten mit starker Sicherheitstechnologie-Tradition — Israel, USA, Großbritannien, Singapur — die technisch exzellente Produkte mitbringen, aber selten eine gewachsene Compliance-Kultur für den spezifischen europäischen Regulierungsrahmen.
Hinzu kommt: Der AI Act unterscheidet nicht danach, wo ein Unternehmen seinen Sitz hat. Wer ein KI-System in der EU in Verkehr bringt oder betreibt, fällt unter den Geltungsbereich. Punkt. Und wer nicht in der EU niedergelassen ist, hat eine zusätzliche Pflicht, die in der Planung fast immer übersehen wird: die Benennung eines EU-Bevollmächtigten (Authorised Representative) — einer in der EU ansässigen natürlichen oder juristischen Person, die gegenüber Behörden als verbindlicher Ansprechpartner fungiert, Dokumentation vorhält, mit Aufsichtsbehörden kooperiert und Registrierungsaufgaben übernehmen kann. Das ist keine Formsache. Das ist eine strukturelle Voraussetzung für den Marktzugang.
Als jemand, der Unternehmen beim Markteintritt in Deutschland begleitet, erlebe ich diesen Irrtum regelmäßig — und er kostet Deals. Der häufigste Irrtum: Die Annahme, dass das eigene System kein Hochrisiko-System sei. Diese Einschätzung wird oft ohne fundierte Analyse getroffen — und oft stellt sie sich als falsch heraus, sobald man die Systematik von Annex III ernsthaft prüft. Was es bedeutet, wenn KI-Systeme in regulierten Umgebungen eingesetzt werden und die Nachweislage nicht stimmt, hat CyberAtlas am Beispiel eines einzelnen Satzes ausführlich herausgearbeitet 📎.
Der blinde Fleck: Compliance ist kein Beiwerk. Es ist der Deal.
Es gibt einen zweiten Irrtum, der noch folgenreicher ist als die falsche Risikoklassifizierung.
Viele Security-Startups aus Nicht-EU-Märkten sehen Compliance als Hindernis, das irgendwie zu überwinden ist — am besten schnell, am besten kostengünstig, am besten ohne zu viel Aufwand in der Produktarchitektur. Der Gedanke dahinter: Wir haben das bessere Produkt. Die Technik überzeugt. Den Rest regeln wir schon.
Das ist falsch. Und in regulierten Umgebungen ist es ein Deal Breaker.
Spätestens mit dem AI Act wird die Frage der Nachweisfähigkeit governance-, sanktions- und beschaffungsrelevant — auf Ebene von Management und Betreiberorganisation. Die Kosten für Non-Compliance können erheblich sein: Bußgelder von bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes — je nachdem, welcher Betrag höher ist —, verlorene Ausschreibungen, Verzögerungen im Marktzugang und im Einzelfall auch Organverantwortung nach anwendbarem nationalem Recht. Das ist keine theoretische Gefahr. Das ist die Logik regulierter Märkte.
Der typische Moment sieht so aus: Die Technologie hat überzeugt, der Pilotbetrieb war erfolgreich, die Entscheidung ist gefallen — und dann fordert die Vergabestelle eine Konformitätserklärung — also den formalen Nachweis, dass das System die regulatorischen Anforderungen erfüllt — oder eine technische Dokumentation nach AI-Act-Standard. Das Startup hat beides nicht. Der Auftrag geht an einen Wettbewerber, der schlechter ist, aber vorbereitet.
Der AI Act ist kein Dokumentationsgesetz. Er ist ein Architekturgesetz.
Hier ist eine Unterscheidung wichtig, die in der Praxis fast nie gemacht wird: Es gibt zwei verschiedene Arten von Compliance-Problemen — und nur eine davon ist wirklich lösbar.
Dokumentationslücken sind schmerzhaft und teuer. Aber sie sind behebbar. Fehlende technische Dokumentation, unvollständige Konformitätsnachweise, keine Registrierung — das sind Probleme, die mit Aufwand und Zeit geschlossen werden können.
Die zweite Art ist fundamentaler: Architekturentscheidungen, die Compliance im Nachhinein faktisch unmöglich machen. Ein Startup, das seine Erkennungslogik als Black Box gebaut hat — ohne Interpretierbarkeitsschicht, ohne Logging-Architektur, ohne die Möglichkeit, menschliche Aufsicht nachzuweisen — hat kein Dokumentationsproblem. Es hat ein Neubau-Problem — oder zumindest einen so tiefgreifenden Umbau, dass er wirtschaftlich einem Neubau entspricht.
Branchenschätzungen — darunter eine Kostenanalyse von SoftwareSeni 📎 — gehen für die vollständige AI-Act-Compliance eines Hochrisiko-KI-Systems von erheblichen Initial- und laufenden Kosten aus: mehrere hunderttausend Euro für die Umsetzung, sechsstellige Jahresbeträge für laufende Dokumentation und Monitoring. Das sind die Kosten, wenn man es von Anfang an richtig macht. Wer nachträglich nachrüstet, zahlt nach übereinstimmenden Brancheneinschätzungen ein Vielfaches davon 📎 — weil Architektur, Logging und Oversight-Mechaniken nicht additiv eingebaut werden können, sondern das bestehende System fundamental verändern. Auch auf Komponentenebene zeigt sich dieselbe Logik: Frühzeitig investierte Mittel in Observability sparen typischerweise ein Vielfaches in späteren Rework-Zyklen 📎. Wer wartet, zahlt nicht nur mehr — er zahlt mit Kapital, das für Wachstum gedacht war. Das ist kein Randphänomen. Das ist einer der häufigsten stillen Wertvernichter in der späten Seed- und Series-A-Phase von Startups, die in regulierte Märkte expandieren wollen.
Hinzu kommen drei weitere Kostendimensionen, die in der Planung fast nie auftauchen. Erstens die Opportunitätskosten: Während das Team umbaut, entwickelt ein Wettbewerber, der bereits compliant ist, sein Produkt weiter. Der Zeitverlust ist doppelt — Umbau plus verpasstes Wachstum. Zweitens die Teamkosten: Engineering-Kapazität, die für den Umbau gebunden ist, fehlt im Produkt. Bei kleinen Teams ist das existenziell. Drittens der Vertrauensschaden: Ein Pilot, der wegen fehlender Compliance abgebrochen wird, hinterlässt einen Schaden, der über den einzelnen Deal hinausgeht. Referenzen fehlen, Reputation leidet, der nächste Gesprächspartner kennt die Geschichte.
Für Unternehmen, die heute strukturiert anfangen wollen, gibt es einen bewährten Einstiegspfad: ISO/IEC 42001 📎 — der weltweit erste KI-Management-System-Standard, veröffentlicht im Dezember 2023. Er definiert Anforderungen an Governance, Risikomanagement, Transparenz und Human Oversight für KI-Systeme — also die organisatorische Schicht, die der AI Act voraussetzt. Realistisch betrachtet liefert eine vollständige ISO-42001-Implementierung allein eine solide Basis für 35 bis 45 Prozent der Governance- und Dokumentationsarchitektur, die der AI Act verlangt. Was sie nicht abdeckt, sind regulatorische Anforderungen, die keine Management-System-Frage sind: die Hochrisiko-Klassifizierungsmethodik nach Annex III, Konformitätsbewertungsverfahren nach Art. 43, CE-Kennzeichnung, EU-Datenbankregistrierung nach Art. 51 und GPAI-spezifische Pflichten. ISO 42001 ist ein Fundament — kein Pass.
Für Unternehmen, die bereits ISO 27001 📎 oder BSI Grundschutz 📎 implementiert haben — beides im deutschen KRITIS-Umfeld weit verbreitet und oft regulatorisch gefordert — ändert sich das Bild erheblich. Die Kombination leistet, was jeder Standard allein nicht schafft: ISO 42001 liefert den KI-spezifischen Risikomanagement-Layer — Impact Assessments, Human Oversight Frameworks, AI-spezifische Datengouvernance. ISO 27001 liefert das Cybersecurity- und Datengouvernance-Skelett, das Art. 15 und Art. 10 des AI Act tatsächlich voraussetzen — keine Behauptung, sondern strukturelle Überschneidung. BSI Grundschutz geht bei technischen Sicherheitskontrollen tiefer als ISO 27001 und ist das stärkste Marktzugangs-Signal speziell für Deutschland: Procurement Officer in KRITIS-nahen Behörden erkennen BSI Grundschutz in einer Weise, die ISO-Zertifizierung allein nicht erzeugt.
Mit dem vollständigen Stack — ISO 27001 + ISO 42001 + BSI Grundschutz — ist eine Überschneidung von 60 bis 70 Prozent mit den AI-Act-Anforderungen vertretbar, möglicherweise höher für Hochrisiko-Systeme, bei denen Art. 9, 10, 12, 15 und 17 den Großteil der Pflichten bündeln. Organisationen mit bestehender ISO-27001-Basis erreichen ISO-42001-Compliance nach Branchenerfahrungen 30 bis 40 Prozent schneller 📎 als solche ohne diese Basis.
Was dieser Stack nicht überträgt, hat kein ISO-Äquivalent — es ist reine EU-Regulierungsarchitektur: die Hochrisiko-Klassifizierungsmethodik nach Annex III, Konformitätsbewertungsverfahren nach Art. 43, CE-Kennzeichnung mit technischer Dokumentationsakte, die EU-Bevollmächtigtenpflicht und GPAI-Pflichten nach Titel VIII. Kein Standard der Welt ersetzt diese Anforderungen. Aber das Team, das mit ISO 27001 + ISO 42001 + BSI Grundschutz antritt, spricht bereits die richtige Sprache. Der Stack schließt die letzten 30 bis 40 Prozent nicht — aber er macht die verbleibende Arbeit zu einem strukturierten Sprint statt einem Neubau von Grund auf.
Die Zahl tatsächlich akkreditiert zertifizierter Organisationen 📎 ist bislang sehr klein — darunter bekannte Namen wie Microsoft, IBM, Anthropic, AWS, SAP und KPMG. Wer jetzt beginnt, ist nicht spät. Er ist früh.
Es gibt eine Formulierung, die ich in Gesprächen mit CCOs auf der Kundenseite immer wieder höre — und die das Problem präziser beschreibt als jede regulatorische Definition: KRITIS braucht kein langsameres System. Es braucht ein beobachtbares. Das ist nicht dieselbe Anforderung. Aber wer nie für Observability — also die Fähigkeit eines Systems, seinen eigenen Zustand und seine Entscheidungen transparent zu machen — gebaut hat, weiß nicht, wo er anfangen soll.
Der häufigste Moment, in dem das sichtbar wird: Die Technologie hat überzeugt. Dann zieht jemand am Faden — zeig mir deine Logging-Architektur, zeig mir, wie ein menschlicher Supervisor in die Entscheidungskette eingreifen kann — und der Raum wird still.
Einen solchen Architekturumbau habe ich einmal funktionieren sehen. Ein Team, das seinen Detection-Core unangetastet ließ und eine parallele Schicht baute, die vollständig protokollierte, welche Faktoren zu jedem Alarm geführt hatten — ohne Latenzwirkung auf das laufende System. Human Override wurde als verpflichtender Bestätigungsschritt implementiert, bevor eine automatisierte Reaktion ausgelöst wird. Sauber genug für eine AI-Act-Readiness-Bewertung durch eine akkreditierte Konformitätsbewertungsstelle — einen unabhängigen Prüfdienstleister, der die regulatorische Anschlussfähigkeit des Systems bewertet.
Was den Unterschied machte: Ein Ingenieur im Team hatte vorher Medical-Device-Software entwickelt. Er wusste, was „dokumentierter Entscheidungspfad“ in der Praxis bedeutet. Ohne dieses Vorwissen hätten sie die Architektur nicht gefunden.
Dieser Umbau dauerte acht Monate. Heute sind es noch vier Monate bis zum 2. August 2026. Das Zeitfenster für einen solchen Umbau ist für Teams, die jetzt erst beginnen, bereits geschlossen — es sei denn, sie haben die Arbeit im vergangenen Jahr still begonnen. Teams, die warten bis der Raum still wird, haben diese acht Monate nicht mehr.
Der AI Act bewertet nicht primär, was dokumentiert ist — sondern ob ein System überhaupt so gebaut ist, dass es sinnvoll dokumentiert werden kann. Das ist der Unterschied, den die meisten Anbieter zu spät verstehen.
Was ich besonders häufig sehe: Die Architekturentscheidungen wurden für Geschwindigkeit und operative Leistungsfähigkeit getroffen — ein Muster, das sich bei Anbietern aus Israel, den USA und Großbritannien gleichermaßen zeigt. Beides richtig für den ursprünglichen Use Case. Beides oft falsch für die KRITIS-Beschaffung in Deutschland. Niemand hat ihnen gesagt, dass das häufig zwei verschiedene Produkte sind.
Die Dokumentationslücke ist der Ort, wo Deals kurzfristig scheitern. Die Architekturfrage ist der Ort, wo der Marktzugang dauerhaft verloren geht.
KRITIS-Betreiber, Behörden, kritische Infrastrukturen in Deutschland — sie kaufen nicht nur Technologie. Sie kaufen Nachweisfähigkeit. Sie brauchen ein Produkt, das in ihre bestehenden Governance-Strukturen passt, das auditierbar ist, das die Fragen ihrer eigenen Compliance-Abteilung beantwortet. Wenn ein Produkt nicht in das Sicherheitsmodell eines regulierten Kunden passt, spielt die Technologie keine Rolle mehr. Der Deal findet schlicht nicht statt.
Das Startup, das seinen Kunden aktiv bei der Compliance-Arbeit unterstützt — das ihnen nicht nur das Produkt liefert, sondern auch die Dokumentation, die Nachweise, die Einordnung in den regulatorischen Rahmen — erzeugt einen Mehrwert, der über die technische Leistung hinausgeht. Es wird zum Partner, nicht zum Lieferanten. Die Anbieter, die den europäischen Markt am schnellsten erschließen, behandeln Compliance nicht als Checkbox, sondern als Feature — und nutzen NIS-2- oder AI-Act-Readiness aktiv als Differenzierungsmerkmal im Enterprise-Vertrieb.
Das ist kein Nice-to-have. In vielen Fällen ist es die Voraussetzung dafür, dass der erste Vertrag überhaupt unterschrieben wird. Wie der europäische Luftfahrtmarkt zeigt, gilt das auch dort, wo technologische Leistungsfähigkeit außer Frage steht — entscheidend ist die regulatorische Anschlussfähigkeit, wie CyberAtlas für den Luftfahrtsektor analysiert hat 📎.
Der unterschätzte Hebel: Förderprogramme als Türöffner
Wenn das Produkt nicht ins Sicherheitsmodell des Kunden passt, hilft auch das beste Förderangebot nicht. Aber wenn die regulatorische Grundlage stimmt, verändert Förderung die Wirtschaftlichkeit eines Deals grundlegend — und das ist ein Hebel, den die meisten Anbieter aus Nicht-EU-Märkten nicht kennen.
Was ich in Erstgesprächen fast immer erklären muss: Die Compliance-Arbeit, die ein Startup seinem deutschen Kunden abnimmt oder gemeinsam mit ihm erledigt, ist in vielen Fällen förderfähig.
Wer mit deutschen Behörden, KRITIS-Betreibern oder öffentlich geförderten Einrichtungen zusammenarbeitet, bewegt sich in einem Umfeld, das aktiv Förderprogramme bereitstellt, die je nach Zuschnitt des Vorhabens auch für Digitalisierungs- und Compliance-nahe Themen in Betracht kommen.
Konkret prüfenswert sind heute unter anderem: Das BAFA-Programm zur Förderung von Unternehmensberatungen für KMU 📎, das allgemeine unternehmerische Beratungsleistungen mit bis zu 80 Prozent der förderfähigen Kosten bezuschusst — je nach Standort und Programmkonstellation, mit einem Förderhöchstbetrag von bis zu 2.800 Euro pro Beratung. Der ERP-Förderkredit Digitalisierung der KfW 📎, der seit Februar 2025 ergänzend einen Zuschuss von 3 Prozent des ausgezahlten Kreditbetrags gewährt — maximal 200.000 Euro — und Digitalisierungs- sowie Innovationsvorhaben bis zu 25 Millionen Euro finanziert. Darüber hinaus gibt es auf Bundes- und Länderebene eine Reihe weiterer Programme im Bereich KI und Cybersicherheit, deren konkrete Verfügbarkeit und Ausschreibungszyklen jeweils aktuell geprüft werden sollten — die Förderkulisse in diesem Bereich entwickelt sich fortlaufend weiter.
Wie das in der Praxis aussieht: Ein Anbieter, der seinem deutschen KRITIS-Kunden beim BAFA-Antrag hilft, verwandelt eine 5.000-Euro-Beratungsleistung in eine 2.800-Euro-Förderung für den Kunden. Der Eigenanteil schrumpft. Die Entscheidungsbarriere sinkt. Und der Anbieter ist nicht mehr Kostenfaktor — er ist derjenige, der den Deal wirtschaftlich erst möglich gemacht hat.
In vielen Fällen entscheidet nicht das Budget des Kunden über den Deal — sondern seine Förderfähigkeit. Der Punkt ist nicht, dass jedes dieser Programme für jeden Anwendungsfall greift. Der Punkt ist, dass ein Startup, das seinen deutschen Kunden aktiv dabei begleitet, die passenden Fördermöglichkeiten zu identifizieren und zu bewerten, eine andere Gesprächsposition hat als eines, das nur sein Produkt verkauft. Es wird zum Partner in einem Prozess, den der Kunde ohnehin durchlaufen muss.
Das ist kein Vertriebstrick. Es ist das Verständnis dafür, wie öffentliche Beschaffung in Deutschland tatsächlich funktioniert.
Was jetzt zu tun ist
Nicht alles auf einmal. Aber das Richtige zuerst.
Der erste Schritt ist eine ehrliche Risikoklassifizierung. Nicht als Compliance-Übung, sondern als strategische Entscheidungsgrundlage: Fällt das eigene Produkt unter Annex III oder unter Article 6(1) mit Annex I? Welches Datum gilt dann konkret — und ändert der Omnibus daran etwas? Was würde eine Hochrisiko-Einstufung für Produktarchitektur, Markteintrittsplanung und Partnerstrukturen bedeuten?
Und — das ist die Frage, die zu früh gestellt werden kann: Ist die eigene Architektur überhaupt noch compliance-fähig? Oder wurden Entscheidungen getroffen, die den Weg in den regulierten Markt strukturell versperren? Diese Frage ist unbequem. Aber sie ist die einzige, die zählt, bevor man über Fristen und Förderprogramme redet.
Wer diese Analyse noch nicht gemacht hat, wartet gerade auf ein Ergebnis, das er nicht einordnen kann. Was das konkret für Hardware-nahe Produkte mit digitalen Elementen bedeutet, hat CyberAtlas im Kontext des Cyber Resilience Act für israelische Hersteller ausgeführt 📎 — die strukturellen Parallelen zur AI-Act-Situation sind nicht zufällig.
Im europäischen KI-Markt entscheidet nicht Time-to-Market, sondern Time-to-Compliance.
Auch wenn der Omnibus kommt: Die Anforderungen kommen. Die Dokumentationspflichten kommen. Die Nachweisfähigkeit kommt. Unternehmen, die jetzt anfangen, werden 2027 oder 2028 eine andere Ausgangslage haben als die, die gewartet haben. Warum das auch für strategische Investoren und Family Offices relevant ist, die in Cybersecurity-Technologie aus Nicht-EU-Märkten investieren, hat CyberAtlas in dieser Analyse ausgeführt 📎.
Wer heute mit der Klassifizierung beginnt, ist in sechs Monaten in einer anderen Position als jemand, der wartet. Das ist keine Prognose. Das ist Erfahrung.
Der einzige Unterschied zwischen einem Unternehmen, das vorbereitet ist, und einem, das es nicht ist: Der erste hat irgendwann angefangen.
Der Omnibus verschiebt möglicherweise die Uhr. Er ändert nicht das Spielfeld.
Sie sind KI- oder Security-Anbieter aus einem Nicht-EU-Markt und fragen sich, wie Ihr Produkt regulatorisch in den deutschen Markt passt — und welche Fördermöglichkeiten konkret genutzt werden können? Oder Sie betreiben KRITIS-Infrastruktur und müssen KI-Einsatz jetzt nachweisfähig machen? Lesen Sie auch: Was der Cyber Resilience Act für israelische Hardware-Hersteller bedeutet 📎 — und wie der europäische Luftfahrtmarkt zeigt, dass Marktzugang keine Technikfrage ist 📎. Schreiben Sie mir direkt. 📎
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar