Eine Szene begegnet mir oft, ich erkenne sie nach einer Minute. Jemand erwähnt Compliance, in einer Projektrunde oder in einem Call mit etwas strukturierter Kundschaft, und die Antwort kommt fast automatisch.
„Macht das Recht.“
Nicht aus Zynismus. Es ist nur, dass dieser Satz 2026 zu einem der teuersten gehören dürfte, den ein europäisches Softwareunternehmen aussprechen kann.
Denn das, was kommt, sieht nicht nach einem Policy-Update aus oder nach einer Runde Aufklärung. Es sieht nach einem Wechsel der Fundamente aus. Und, noch unbequemer, mit eng gesetzten Fristen.
Der perfekte Sturm: fünf Fristen in zu engem Fenster
Wenn du Software für den europäischen Markt machst, ist der Kalender kein Detail mehr in einer geteilten Datei. Es ist eine Timeline, die in deine Architektur eindringt.
Zwischen Ende 2024 und 2026 ballen sich Normen, die du einzeln vielleicht mit Mühe schultern könntest. Zusammen aber greifen sie absichtlich ineinander.
NIS2 ist seit Oktober 2024 in Kraft und hat den Kreis derer, die Cybersicherheit ernst nehmen müssen, samt Lieferkette ausgeweitet. Erste Überraschung: man muss nicht „kritisch“ sein, um die Wirkung zu spüren. Es reicht, Lieferant von jemandem zu sein, der es ist.
Der European Accessibility Act gilt seit Juni 2025 und verschiebt Barrierefreiheit von „Verbesserung“ zu „Anforderung“.
Dann kommt 2026, das Jahr, in dem sich der Knoten zuzieht.
Im August 2026 tritt der AI Act für Hochrisikosysteme voll in Kraft. Nicht nur Ethik oder Transparenz. Es geht um Konformitätsbewertungen, technische Dokumentation, Datengovernance, menschliche Aufsicht. Und ja, um echte Strafen, bis zu 3 % des globalen Umsatzes oder 15 Millionen.
Im September 2026 bringt der CRA Pflichten, die nicht „nachträglich aufgesetzt“ werden können. Darunter die Meldung aktiv ausgenutzter Schwachstellen binnen 24 Stunden und schwerer Vorfälle binnen 72. Und was viele unterschätzen: das gilt nicht nur für künftige Produkte. Es gilt auch für das, was du schon am Markt hast. Legacy inklusive.
Im Dezember 2026 definiert die PLD den „Produktbegriff“ für das digitale Zeitalter neu. Software, auch standalone oder als SaaS, wird vollwertiges Produkt mit objektiver Haftung. Bugs sind nicht mehr nur betriebliches Ärgernis, sondern potenzieller Produktdefekt mit unmittelbaren rechtlichen Folgen. Die Verantwortung endet nicht beim Release, sie endet, wenn du keine Updates mehr liefern kannst.
Und im Hintergrund bleibt die DSGVO, die nie weg war, mit zunehmend selbstbewusstem Vollzug.
Vielleicht das Beunruhigendste: diese Normen addieren sich nicht linear. Sie verstärken sich.
Der Grundfehler: Compliance als externe Schicht
Die häufigste Reaktion ist verständlich: „Wir holen den Berater, aktualisieren die Policies, machen die Doku, haken die Listen ab.“ Compliance-as-paperwork.
Mit der DSGVO, oft schlecht gemacht, hat das gelegentlich getragen. Du konntest auf ein bestehendes System Prozesse, Hinweise, Register, Rollen aufkleben.
Mit dem 2026er Paket trägt das nicht mehr. Nicht aus mangelndem guten Willen. Sondern weil Anforderungen drinstecken, die ohne architektonische Stütze schlicht nicht existieren.
Konkret: um den CRA einzuhalten, musst du, wenn eine aktiv ausgenutzte Schwachstelle auftaucht, fristgerecht reagieren und melden können. Dafür musst du genau wissen, was in deinem Produkt steckt. Nicht „ungefähr“. Genau.
Direkte und transitive Abhängigkeiten, Komponenten, Versionen, Builds. Alles.
Das führt geradewegs zu einem Objekt, das nicht juristisch und nicht bürokratisch ist: dem SBOM. Und nicht ein einmaliges PDF, um jemanden zu beschwichtigen. Ein lebendiges SBOM, bei jedem Build neu erzeugt, maschinenlesbar, in der Pipeline verankert.
Erzeugt der Build kein SBOM als natürliche Ausgabe, bist du nicht „etwas in Verzug mit Compliance“. Du kannst nicht konform sein, Punkt.
Hier kristallisiert sich der wichtigste Satz dieser ganzen Diskussion: Compliance ist keine Anforderung, die du hinzufügst. Es ist eine emergente Eigenschaft deiner Architektur.
Compliance als Architekturzwang
In der Softwarearchitektur sind wir an Zwänge gewöhnt. Latenz, Verfügbarkeit, Skalierung, Kompatibilität, Kosten. Sie verengen den Lösungsraum.
Die EU-Compliance 2026 ist ein Architekturzwang. Kein Ticket, das man „am Projektende“ zuweist, kein Dokument, das man „vor der Ausschreibung“ produziert. Ein systemumfassender Zwang.
Wenn du es so siehst, werden Folgen fast offensichtlich.
Observability ist kein Extra mehr
Der AI Act verlangt für bestimmte Systeme Logs und Nachvollziehbarkeit. Der CRA drängt zu Erkennung und Reaktion. Die PLD zwingt dich, den Softwarezustand zum Vorfallszeitpunkt nachzuweisen.
Ohne ausreichende Audit Trails ist es nicht so, dass du „wenig monitorst“. Du baust ein System, das den Fragen, die Markt und Norm stellen, nicht standhält.
Dependency-Management wird kritischer Prozess
Jahrelang haben wir normalisiert, dass Bibliotheks-Updates „wenn Zeit bleibt“ gemacht werden. Ein hektisches npm install, ein Lockfile, das niemand ansieht, ein verschobenes Update, „läuft ja“.
Mit CRA und NIS2 wird dieser Leichtsinn zum Supply-Chain-Risiko. Und Supply-Chain-Risiko bleibt 2026 nicht im Tech-Bereich. Es greift in Verträge, Ausschreibungen, Partnerschaften.
Die Frage, die du beantworten können musst, ist einfach und hart: „betrifft dieses neue CVE unsere produktiven Systeme?“. Antwort in Minuten oder Stunden, nicht in Wochen.
Der Begriff „fertiges Produkt“ zerbröselt
PLD und CRA zusammen machen die Idee unglaubwürdig, ein Release schließe ein Kapitel. Ein Release wird Auftakt einer langjährigen Beziehung mit einem System, das gepflegt, beobachtet, betreut werden muss.
Das ändert auch, wie wir schätzen, planen, verkaufen. Denn ein Teil des Werts — und der Verantwortung — lebt nach der Auslieferung.
Barrierefreiheit ist Eigenschaft des Designsystems
Der EAA ist mit Retrofits nicht zimperlich. Hast du ein barrierefreies Designsystem von Haus aus, hast du strukturellen Vorteil. Musst du ein über Jahre regellos gewachsenes Frontend „barrierefrei machen“, werden die Findings unbeherrschbar.
Ich frage mich oft, ob wir nicht unterschätzen, dass Barrierefreiheit in Wirklichkeit eine Form interner Standardisierung ist. Nicht nur eine externe Anforderung.
Human Oversight ist kein Knopf
Eines der häufigsten Missverständnisse zum AI Act ist, „menschliche Aufsicht“ heiße einen Genehmigungsschritt am Ende einbauen.
Praktisch ist es eine Frage der Flüsse: wo darf der Mensch eingreifen, mit welchen Informationen, mit welcher Override-Möglichkeit, mit welcher Nachvollziehbarkeit. Architektur des Entscheidungsprozesses, noch vor Softwarearchitektur.
Die Schnittstelle, die viele übersehen
Der spannendste — und vielleicht gefährlichste — Punkt sind nicht die einzelnen Pflichten. Es ist, wie sie ineinandergreifen.
Die PLD sagt, ein Softwareprodukt sei mangelhaft, wenn es die geltenden Cybersecurity-Anforderungen nicht erfüllt. Der CRA definiert einen großen Teil dieser Anforderungen. Der AI Act fügt Spezifika für KI hinzu.
Mangelnde CRA-Konformität kann also zum Produktdefekt im Sinne der PLD werden.
Wir reden nicht mehr nur von Bußgeld oder „zu behebender“ Nichtkonformität. Wir reden von zivilrechtlicher Schadenshaftung, mit Mechanismen wie Beweislastumkehr.
Zur Verteidigung musst du nachweisen können, dass das Produkt zum Vorfallszeitpunkt konform war. Was dich wieder zu SBOM, Audit Trails, Logging, technischer Doku führt. Nicht als Compliance-Theater, sondern als Verteidigungsarchitektur.
Das italienische Paradox: fragil, aber schnell
Hier ein Stück, das mir nahe ist, weil es Alltag in vielen Firmen ist, mit denen ich rede.
Der italienische Software-Markt besteht zu großen Teilen aus KMU: Teams von 5 bis 20, vertikale Produkte, Wachstum durch Schichten, kundengetriebene Roadmap, feature-first angehäufte technische Schulden.
Viele sind unvorbereitet. Nicht aus Unfähigkeit, aus Struktur.
Und doch ein Paradox: dieselbe Struktur, die sie verletzlich macht, kann zum Vorteil werden.
Eine Zehn-Personen-Firma kann, wenn sie wirklich entscheidet, wichtige Architekturanteile in 12 Monaten neu zeichnen. Ein Großunternehmen braucht oft Monate, nur um zu verstehen, was es in Produktion hat.
Ein kleines Team kennt seine Domäne und sein Produkt intim. Eine realistische Gap-Analyse in Wochen.
Und ein Founder-CTO, der heute in Compliance-by-design investiert, kann sich in einem Fenster bewegen, das in 18 Monaten geschlossen sein wird. Nicht weil es unmöglich wird, sondern weil es zu spät wird, in Ruhe zu handeln.
Compliance-by-design: Architekturentscheidungen, keine Slogans
Mit Compliance-by-design meine ich nicht „Dinge gut machen“ im Allgemeinen. Ich meine konkrete Entscheidungen, die du jetzt beginnen kannst, ohne alles umzukrempeln.
SBOM als First-Class-Artefakt etwa. Jeder Build erzeugt ein SBOM in CycloneDX oder SPDX. Die Pipeline erzeugt, speichert, gleicht es mit Schwachstellendatenbanken ab und blockiert ggf. ein Deployment. Werkzeuge wie syft, grype oder trivy machen das viel zugänglicher als es scheint.
Dann der Audit Trail — nicht der Systemlog. Ein Domain-Audit-Trail: wer hat was, wann, warum, mit welcher Rolle, in welchem Kontext getan. Ob Event Sourcing oder Append-only-Log, die Idee: First-Class-Bürger des Datenmodells.
Technische Doku als Code, weiterer Schlüssel. Lebt die Doku in einem manuell gepflegten Wiki, hört sie irgendwann auf, die Realität abzubilden. Mit versionierten ADRs, deklarativen Spezifikationen und aus Code generierter Doku wird sie zum unvermeidlichen Nebenprodukt der Arbeit.
Vulnerability Management darf kein Jahresereignis sein. Es muss kontinuierlicher Prozess sein: automatisches Scanning, Triage, Remediation mit definierten Zeiten. Wenn die Meldung einer ausgenutzten Schwachstelle kommt, soll dir das System helfen, in Stunden zu reagieren.
Bei Barrierefreiheit funktioniert, sie als Design Tokens und Regel im Designsystem zu behandeln. Werden Komponenten barrierefrei geboren, bleibt das Produkt es. Muss man nachträglich korrigieren, ergänzt jeder neue Screen Schulden.
AI-native Entwicklung als Beschleuniger, nicht nur als Risiko
Eine kleine Ironie: der AI Act kommt, während KI die Art verändert, wie wir Software schreiben.
Viele sehen AI-native Entwicklung als Compliance-Risiko: mehr generierten Code, weniger Kontrolle. Ich vermute oft das Gegenteil.
Ein spec-driven-Ansatz, in dem Software aus lesbaren, prüfbaren deklarativen Spezifikationen entsteht, ist strukturell compliance-freundlicher. Weil Spezifikationen Doku sind. Weil sie versioniert sind. Weil sie Annahmen explizit machen, die sonst im Kopf desjenigen bleiben, der den Code vor zwei Jahren geschrieben hat.
Werkzeuge wie eine Projektdatei claude.md, speckit, Pipelines, die Compliance-Artefakte als Teil des Flows erzeugen — keine Science-Fiction. Eine andere Art zu arbeiten, die Beweise, Nachvollziehbarkeit, Rekonstruierbarkeit erleichtert.
Vielleicht ist die Zukunft nicht „mehr Doku schreiben“. Es ist Software so zu bauen, dass Doku unvermeidlich wird.
Die wahren Kosten der Nicht-Konformität sind viel näher als eine Strafe
Sanktionen beeindrucken, doch für viele KMU bleiben sie abstrakt. Es ist nicht die Angst vor der Strafe, die Prioritäten verändert.
Die echten Kosten sind alltäglicher.
Es ist die öffentliche Ausschreibung, an der du nicht teilnimmst, weil du die Sicherheitsanforderungen des Lastenhefts nicht erfüllst.
Es ist der Enterprise-Kunde, der das SBOM verlangt und du weißt nicht, wo anfangen.
Es ist der Partner, der Supply Chain Risk Management betreibt und dich aus der Shortlist nimmt.
Es ist der Vorfall, den du nicht in den CRA-Fristen managen kannst und der in einen härteren Haftungsrahmen rückt.
Für viele italienische Unternehmen sind das keine theoretischen Szenarien. Es ähnelt sehr dem Jahr 2027.
Das Fenster ist jetzt — und im Kern ist es gute Ingenieurskunst
Als Softwarearchitekt, oft zwischen Roadmap, Budget, technischen Schulden und Marktanforderungen, verstehe ich, dass das alles erdrückend wirken kann.
Aber ein Aspekt sollte vorne stehen: viele der von diesen Normen geforderten Praktiken sind schlicht gute Ingenieurskunst.
Ein SBOM zu erzeugen, ist gute Ingenieurskunst. Einen Audit Trail zu haben, auch. Abhängigkeitsverwundbarkeiten zu managen, auch. Architekturentscheidungen zu dokumentieren, auch. Barrierefreie Oberflächen zu bauen, auch.
Was die EU-Compliance 2026 vielleicht tut: sie macht zur Pflicht, was wir ohnehin hätten tun sollen. Sie verwandelt Best Practices in Baseline.
Und sie schafft einen Markt, in dem, wer Compliance als Architekturproblem behandelt — und nicht als ans Recht zu delegierende Sache —, robuster, wartbarer und auch verkäuflicher wird.
Das Fenster, diesen Vorteil zu bauen, ist jetzt offen. In achtzehn Monaten wird, wer nicht begonnen hat, hinterherrennen. Wer jetzt beginnt, steht vermutlich auf der anderen Seite.
Was du mitnimmst
Compliance 2026 ist eine Architektureigenschaft, kein juristisches Artefakt: liefert die Pipeline kein SBOM nativ, ist Konformität unmöglich, nicht nur teuer.
Die fünf Verordnungen verstärken sich gegenseitig: isoliert betrachtet verstecken sich Kosten an den Schnittstellen (CRA × PLD, AI Act × NIS2).
Design-in kostet 5–10× weniger als Retrofit unter Vollzugsdruck.
Das Wettbewerbsfenster ist jetzt offen für jene, die früh handeln, und schließt sich schnell, sobald öffentliche Ausschreibungen und Großkunden Compliance vertraglich verlangen.
AI-native Entwicklung ist ein Beschleuniger, nicht nur ein Risiko — wenn die KI-Pipeline mit derselben Strenge geführt wird wie das Produkt.
Fragen & Antworten
Welche fünf EU-Normen verändern Software zwischen 2024 und 2026?
NIS2 (in Kraft seit Oktober 2024, weitet Cybersicherheit auch auf Lieferanten kritischer Akteure aus), EAA (Juni 2025, macht Barrierefreiheit zur Anforderung statt zur Verbesserung), AI Act (August 2026 für Hochrisikosysteme), CRA (September 2026, Sicherheitspflichten auch für bereits am Markt befindliches Legacy), PLD (Dezember 2026, Software wird Produkt mit objektiver Haftung). Plus die DSGVO im Hintergrund.
Warum funktioniert Compliance-as-paperwork nicht mehr?
Weil das 2026er Paket Anforderungen enthält, die nicht existieren, wenn sie nicht von der Architektur getragen werden. Beispiel: eine aktiv ausgenutzte Schwachstelle (CRA) innerhalb von 24 Stunden zu melden, setzt ein lebendiges, bei jedem Build neu erzeugtes, in die Pipeline integriertes SBOM voraus. Kein einmal erstelltes PDF. Wenn der Build kein SBOM als natürliche Ausgabe liefert, ist Konformität unmöglich — keine Checkliste hilft.
Was bedeutet ‚Compliance als emergente Eigenschaft der Architektur'?
Dass Pflichten wie 24h-Schwachstellenmeldung, Nachvollziehbarkeit von Abhängigkeiten, Audit Logs, menschliche Aufsicht über Hochrisiko-KI, technische Dokumentation — Folgen sind, wie du das System entwirfst, keine später aufgesetzten Schichten. Sind Pipeline, Logging und Observability nicht bestimmten Mustern folgend, ist Compliance unmöglich, nicht nur teuer.
Was ist das echte Risiko für ein italienisches Software-KMU, das sich nicht vorbereitet?
Das konkrete Risiko ist nicht zuerst die Strafe (auch wenn beim AI Act bis zu 3 % des globalen Umsatzes drohen). Zuerst sind es verlorene öffentliche Ausschreibungen und Großkunden, die Compliance vertraglich verlangen, dann die Kosten des Architektur-Retrofits unter Druck — 5–10× teurer als Design-in heute. Das Wettbewerbsfenster öffnet sich jetzt für die, die handeln, schließt schnell für die, die warten.
Der Autor
