Andrea Margiovanni .it
Eine Nahaufnahme einer Notenpartitur, die schwarzen Noten auf den Notenlinien aufgereiht, das Notensystem selbst als strenges Raster, das Komposition erst möglich macht. Die Beschränkung als Form.

Die Form der Beschränkung

Regulatorische Compliance als Gegnerin des technischen Projekts zu behandeln heißt, nicht verstanden zu haben, was ein technisches Projekt ist. Ein Essay über den Kategorienfehler, der die europäische Software-Industrie schwächt, und darüber, wie der europäische Regulierungsrahmen — als System gelesen, nicht als Liste — einen strukturellen Wettbewerbsvorteil für jene konfiguriert, die ihn zu bewohnen verstehen.

„Je mehr Zwang man sich auferlegt, desto mehr befreit man sich von den Ketten, die den Geist hemmen.” — Igor Stravinsky, Poetik der Musik

Die Erzählung, die uns erzählt wurde

Eine Erzählung hat sich in den letzten Jahren ins Zentrum der europäischen Technologiedebatte gesetzt. Sie kennen sie alle. In ihrer komprimiertesten Form klingt sie so: „Amerika innoviert, China kopiert, Europa reguliert.” Es ist ein Spruch, den man auf Konferenzen hört, in Zeitungen liest, in Think-Tank-Berichten findet und der seine formale Weihe im Draghi-Bericht zur europäischen Wettbewerbsfähigkeit gefunden hat — einem ehrlichen, dramatischen Dokument, das die regulatorische Fragmentierung als eine der Ursachen unseres strukturellen Rückstands benannt hat.

Es liegt ein Wahrheitskern darin. Der europäische Regulierungsrahmen ist dicht. Die Häufung von Anforderungen — AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act, NIS2, DSGVO, Data Act, DSA, DMA — produziert für jeden, der Software baut, eine nicht triviale kognitive Last. Viele italienische KMU ringen um Luft, spezialisierte Beratung kostet, reife Werkzeuge fehlen noch.

Aber die Erzählung ist, wie so oft, interessanter als die Version, die uns serviert wird. Es gibt eine andere Lesart desselben Szenarios, und sie möchte ich auf diesen Seiten zu artikulieren versuchen. Eine Lesart, die die Schwierigkeiten nicht leugnet, aber die scheinbar offenkundige Schlussfolgerung zurückweist: dass Regulierung und Innovation einander entgegenstünden und dass in Europa zu sein bedeutete, allein deshalb zu verlieren.

Die These, die ich verteidige, ist im Kern einfach, in ihren Implikationen komplex: Regulatorische Compliance, richtig verstanden, ist kein Kostenfaktor des Wettbewerbs, sondern eines seiner Felder. Und der europäische Rahmen, als kohärentes technisches Projekt gelesen, konfiguriert einen Wettbewerbsvorteil, den jene Unternehmen, die ihn verstanden haben, bereits monetarisieren — während jene, die ihn weiter als Ärgernis erleben, sich progressiv aus den höherwertigen Märkten ausschließen.

Der Kategorienfehler

Der erste Schritt, das falsche Dilemma „Regulierung vs. Innovation” zu entschärfen, besteht darin, zu erkennen, dass es sich, noch vor einer diskutablen Position, um einen Kategorienfehler handelt.

Wenn ein Architekt ein Gebäude entwirft, arbeitet er innerhalb eines dichten Netzes von Beschränkungen: Gesetze der Physik, Erdbebencodes, städtebauliche Regeln, Energieanforderungen, Barrierefreiheit, Brandschutz, Landschaftsauflagen. Niemand sagt vor einem gut entworfenen Gebäude, es wäre „innovativer ohne die Gesetze der Statik gewesen”. Es wäre absurd. Die Schwerkraft ist keine Bremse für die Architektur: Sie ist die Bedingung, die Architektur als Disziplin überhaupt möglich macht. Sie ist das, was Bauen vom Aufschichten von Material unterscheidet.

Dasselbe gilt für Software. Die Konstanten, Standards, Protokolle, Spezifikationen — TCP/IP, ANSI SQL, POSIX, IEEE 754, RFC 7231 — sind Beschränkungen. Sehr strenge Beschränkungen. Und doch hält kein ernsthafter Ingenieur sie für Hindernisse für Innovation. Sie sind das Gegenteil: die geteilte Grammatik, die Komposition komplexer Systeme aus unabhängigen Teilen erst möglich macht. Ohne diese Beschränkungen hätten wir kein Internet, keine Datenbanken, keine Interoperabilität. Wir hätten einen Archipel inkompatibler proprietärer Lösungen — genau das, was die europäische Regulierung in ihrer Absicht für die nächste Schicht des Tech-Stacks zu vermeiden versucht: Daten, Künstliche Intelligenz, Sicherheit, Barrierefreiheit.

Die Beschränkung, mit anderen Worten, ist nicht der Feind des Designs: Sie ist seine Form. Schönberg wusste das mit der Zwölftontechnik, die Oulipo wussten es mit ihren literarischen Algorithmen, Calvino wusste es, als er die Genauigkeit als Wert der Literatur pries, jeder erfahrene Entwickler weiß es, wenn er endlich versteht, dass statische Typen die Entwicklung nicht verlangsamen, sondern strukturieren. Absolute Freiheit im Engineering heißt Chaos und produziert fragile, inkompatible, nicht wartbare Systeme. Disziplinierte Freiheit produziert Architektur.

Compliance als Gegnerin des technischen Projekts zu behandeln, heißt, nicht verstanden zu haben, was ein technisches Projekt ist.

Der europäische Rahmen als System, nicht als Liste

Der zweite Schritt ist, den europäischen Regulierungskorpus richtig zu lesen. Fast die gesamte konventionelle Kritik — auch die wohlwollende — macht denselben Fehler: Sie behandelt die Regulierungen als Liste. Eine Liste unverbundener Pflichten, von denen jede Reibung hinzufügt und jede einzeln in Kosten-Nutzen-Begriffen bewertet werden müsste.

Das ist aber nicht die Form, die der europäische Rahmen tatsächlich angenommen hat. Wenn man die Gesamttextur der Regulierungen des letzten Jahrzehnts betrachtet — von der DSGVO bis zum AI Act, über CRA, PLD, EAA, NIS2, Data Act, DSA, DMA —, entdeckt man, dass es sich nicht um eine Liste, sondern um ein System handelt. Und wie jedes entworfene System hat es seine eigene architektonische Logik.

Diese Logik lässt sich so zusammenfassen: technische Systeme, die spürbare Auswirkungen auf die Rechte und Güter der Menschen haben, by design rechenschaftspflichtig zu machen. Alles Übrige ist domänenspezifische Deklination dieses Prinzips.

Die DSGVO macht die Flüsse personenbezogener Daten rechenschaftspflichtig. Die DSGVO sagt Ihnen nicht, wie Sie die Datenbank gestalten sollen: Sie sagt, dass Sie immer, jedem, der fragt, antworten können müssen — wer wessen Daten anfasst, warum, wie lange, auf welcher Rechtsgrundlage. Der Cyber Resilience Act tut dasselbe für die Sicherheit von Software-Produkten: Er sagt nicht, welche Sprache Sie verwenden sollen, aber er verlangt, dass Sie wissen und nachweisen, was in Ihrem Produkt steckt, dass Sie es über die Zeit sicher halten und Schwachstellen über nachvollziehbare Prozesse verwalten. Die Product Liability Directive erstreckt die Herstellerhaftung auf die Software selbst und erklärt ausdrücklich, dass ein Bug ein Produktfehler sein kann. Der European Accessibility Act erstreckt die Rechenschaftspflicht auf die Inklusivität: Digitale Produkte oberhalb einer bestimmten Marktschwelle müssen für jedermann nutzbar sein. NIS2 tut dies für kritische Infrastrukturen. Der AI Act tut es für Systeme, die menschliche Entscheidungen erheblich beeinflussen oder über sie entscheiden.

So gesehen ist die europäische Compliance kein Regelungsdickicht. Sie ist eine einzige Grammatik, auf verschiedene Domänen angewandt: Entwirf so, dass du für das, was du tust, Rechenschaft ablegen kannst — by design. Nicht als Notlösung. Nicht als nachträglich aufgetragene Lackschicht. Als Architektur.

Und hier liegt der oft übersehene Punkt: Sobald man eine Organisation gebaut hat, die in Accountability-Begriffen denkt — mit SBOM, mit Audit Trails, mit Threat Modeling, mit Privacy Impact Assessments, mit getesteter Barrierefreiheit, mit formalisiertem Schwachstellen-Management —, fallen die Grenzkosten der Konformität mit der Verordnung N+1 deutlich. Die Kostenkurve verläuft entgegengesetzt zu dem, was die naive Kritik annimmt: hoch am Anfang, fallend über die Zeit, während die Kurve bei jenem, der jede Verordnung als neuen Notfall behandelt, niedrig beginnt, aber divergiert.

Organisationen, die das verstehen, „werden nicht konform”. Sie sind konform, im starken Sinn: Sie haben eine Form, die mit dem Rahmen kompatibel ist. Die anderen rennen hinterher.

Der Brüssel-Effekt, zehn Jahre danach

Es gibt zudem eine Marktdimension, die häufig vergessen wird und die für sich allein jeden davon abhalten sollte, die europäische Regulierung als Ballast abzutun.

Anu Bradford, Juristin an der Columbia, hat den Begriff Brussels Effect geprägt, um ein gut belegtes empirisches Phänomen zu beschreiben: Wenn die Europäische Union einen Markt dieser Größe reguliert — der zweite nach nominalem BIP, der dritte nach Kaufkraftparität, jedenfalls einer der drei größten der Welt —, neigen multinationale Unternehmen dazu, den europäischen Standard als globalen Standard zu übernehmen, weil die Aufrechterhaltung zweier Parallelregime teurer ist als die Übernahme des strengsten Regimes überall.

Der paradigmatische Fall ist die DSGVO. 2016 verabschiedet, seit 2018 anwendbar, ist sie heute de facto die normative Grundlage, die die Datenschutz-Politik der größten Tech-Unternehmen der Welt orientiert. Man sieht sie in den Cookie-Bannern überall, in den Privacy-Dashboards der Big Tech, im California Consumer Privacy Act (der ihre Prinzipien und Struktur mit einer leichteren, opt-out-basierten Architektur aufgreift), in den Gesetzen Brasiliens, Südafrikas, Indiens. Fast acht Jahre nach Anwendungsbeginn lässt sich mit hinreichender Sicherheit sagen: Die Grammatik der globalen Privatsphäre spricht europäisch.

Der AI Act scheint auf derselben Bahn zu sein. Nicht weil er perfekt wäre — ist er nicht —, sondern weil er der erste horizontale und organische Regulierungsrahmen der Welt für KI-Systeme ist. China kam zuerst, 2023, mit verbindlichen Regeln für generative KI: aber das sind sektorale Regeln mit anderem Akzent — verpflichtende Kennzeichnung, Registrierung bei der Behörde, Identitätsprüfung der Nutzer, Inhaltskontrolle —, eher auf informationelle Stabilität als auf den Schutz von Grundrechten ausgerichtet. Der AI Act war der erste Versuch einer allgemeinen, risikogestuften Architektur, anwendbar auf alle KI-Systeme in allen Sektoren. Die großen KI-Unternehmen strukturieren ihre internen Prozesse bereits an den europäischen Anforderungen aus. In den USA greift, in einer Wendung, die wenige erwartet hätten, die staatliche Regulierung — vor allem in Colorado, mit Echos in Kalifornien und in einigen lokalen Gesetzen New Yorks — die Logik der Risiko-Kategorisierung auf, wenn auch auf einem nicht linearen Pfad: Der Colorado AI Act, ursprünglich ab 2026 in Kraft, wurde verschoben und wird, während ich dies schreibe, überarbeitet.

Für ein europäisches Unternehmen, das Software entwirft, heißt das ganz konkret: Sie arbeiten bereits in dem Standard, der statistisch in fünf Jahren der globale sein wird. Ihre amerikanischen und asiatischen Wettbewerber werden sich an einen Rahmen anpassen müssen, den Sie bereits verstoffwechselt haben. Das ist kein Detail: Das ist die operative Definition des First-Mover-Vorteils.

Man wird einwenden: Wenn der Brüssel-Effekt so mächtig ist, warum tun sich europäische Unternehmen dann schwer? Die ehrliche Antwort lautet: Weil viele europäische Unternehmen den Rahmen tatsächlich nicht verstoffwechselt haben — sie erleiden ihn. Sie behandeln die DSGVO als Ärgernis, das zu minimieren ist, den AI Act als Unbekannte, die zu vertagen ist, den EAA als etwas, das zu erledigen ist, wenn die Inspektion kommt. So zahlen sie zweimal: die Kosten der Konformität (die schlecht gemanagt hoch sind) und die verpasste Chance, diese Konformität in Marktposition zu verwandeln. Während nicht-europäische Unternehmen, die zur Marktzulassung konform sein müssen, das strukturell tun — und der Wettbewerbsvorteil, der unser hätte sein können, wird ihrer.

Der Brüssel-Effekt ist ein Pfeil, der auf das Ziel zufliegt. An uns, zu entscheiden, ob das Ziel wir sind oder die anderen.

Die Asymmetrie, die entscheidet

Kommen wir zum Kern des Arguments, dem operativen Teil. Es gibt eine grundlegende Asymmetrie zwischen zwei Arten von Unternehmen, die im europäischen Markt operieren, und diese Asymmetrie — leise, kumulativ, heute kaum wahrnehmbar, morgen entscheidend — wird bestimmen, wer gewinnt und wer aus den höherwertigen Segmenten ausscheidet.

Die erste Art behandelt Compliance als Formalität. Es ist die Default-Position, völlig nachvollziehbar: Die Verordnung kommt, man ernennt eine verantwortliche Person, füllt Checklisten aus, produziert Dokumente, aktualisiert die Datenschutzerklärung, fügt die Banner hinzu, beauftragt die Bewertungen, wenn nötig. Compliance ist ein zu minimierender Kostenpunkt, eine defensive Tätigkeit, etwas, das man tut, um Sanktionen zu vermeiden. Es ist eine Tätigkeit, die so früh wie möglich ausgelagert wird: lieber einen Berater auf Abruf als ein strukturiertes internes Verfahren.

Die zweite Art behandelt Compliance als Architektur. Der Unterschied: Regulatorische Anforderungen werden nicht zum Zeitpunkt ihrer Anwendbarkeit angegangen, sondern von Anfang an als Projektbeschränkungen genommen. Das SBOM ist kein nachträglich zu produzierendes Dokument: Es ist ein Artefakt, das die CI/CD-Pipeline bei jedem Build erzeugt. Privacy ist keine auszufüllende Checkliste: Sie ist eine Dimension des Datenmodells. Barrierefreiheit ist keine abschließende Prüfung: Sie ist ein Set von UI-Komponenten, das sie garantiert. Sicherheit ist kein jährliches Audit: Sie ist ein Threat-Model, das bei jeder relevanten Architekturänderung neu bewertet wird. AI-Accountability ist keine Antwort auf eine Inspektion: Sie ist eine Reihe von Tests, eine Trainingsdokumentation, eine Evaluation-Suite.

Für einen externen Beobachter ist der Unterschied zwischen den beiden in den ersten zwei oder drei Jahren kaum sichtbar. Im Gegenteil, das erste Unternehmen wirkt effizienter: Es liefert dieselben Produkte mit weniger Overhead. Das zweite investiert in Dinge, die noch nicht zu sehen sind: Pipelines, Frameworks, Prozesse, Schulung, strukturierte Dokumentation.

Dann ändert sich etwas. Es ändert sich, wenn der relevante Markt zur Gesundheit, zur öffentlichen Verwaltung, zum Finanzwesen, zur Energie, zu kritischen Infrastrukturen wird — also zu jenen Segmenten, in denen die Kunden eine eigene regulatorische Exposition haben und in denen ihre Konformität von der ihrer Lieferanten abhängt. An diesem Punkt geschieht etwas, das jeder, der im regulierten B2B arbeitet, schon gesehen hat: Die Ausschreibung kommt mit einem dreißigseitigen Technical Annex, und das „Formalitäten”-Unternehmen entdeckt, dass viele der Anforderungen nicht inkrementell, sondern strukturell sind. Vollständiges SBOM für jede Komponente. Schwachstellen-Nachverfolgung mit Behebungs-SLA. Dokumentierte und auditierte SDLC-Prozesse. Jährliche Penetrationstests mit nachverfolgbarer Behebung. Backup-, Disaster-Recovery-, Business-Continuity-Richtlinien, die tatsächlich getestet wurden. Demonstrierbare Privacy by Design für jeden Fluss. Verifizierte Barrierefreiheit. Auditierbarkeit der eingesetzten KI-Modelle, falls vorhanden.

Das „Formalitäten”-Unternehmen hat zwei Optionen: Entweder es verwandelt sich in ein „Architektur”-Unternehmen — mit einem schlagartigen Investment unter Druck in alles, was es nie gebaut hat — oder es zieht sich zurück. Sich unter Druck zu transformieren ist teuer, langsam und nie sauber: Es produziert ungefähre Dokumentation, Prozesse, die höchstens bis zur Vertragsverlängerung überleben, Brüche, die beim ersten ernsthaften Audit sichtbar werden. Sich zurückzuziehen heißt, eine Marktstufe abzusteigen.

Das „Architektur”-Unternehmen nimmt teil, gewinnt und — das ist der Punkt — gewinnt mit höheren Margen, weil das Pricing in diesen Segmenten Nachweisbarkeit belohnt, nicht nur Funktionalität.

Ich beschreibe, wie klar sein dürfte, etwas, das ich aus erster Hand erlebe. In den letzten drei Jahren habe ich Gesundheitsprojekte gesehen, in denen das Unterscheidungsmerkmal weder der Preis noch die Feature Parity war, sondern die Fähigkeit, fristgerecht eine mit den Anforderungen des Auftraggebers kohärente Governance-, Sicherheits- und Barrierefreiheits-Dokumentation zu produzieren. Ich habe Ausschreibungen der öffentlichen Verwaltung gesehen, in denen die ACN-Qualifikation (das italienische Cybersicherheitsregister) ein Tor war und in denen das Fehlen eines qualifizierten Anbieters mechanischen Ausschluss bedeutete. Ich habe Verhandlungen gesehen, in denen ein sicherheitsbezogener Technical Annex die Achse des Gesprächs von Grund auf neu definiert hat: nicht mehr „was tut Ihr Produkt”, sondern „wie weisen Sie nach, dass Sie es über Jahre betreiben können”.

Compliance ist in diesen Kontexten nicht das letzte Ärgernis der Verhandlung. Sie ist das Terrain der Verhandlung.

Vertrauen als Produkt

Es gibt eine Formulierung, die ich nützlich finde: Im regulierten B2B verkauft man keine Funktionen, man verkauft dokumentiertes Vertrauen.

Funktionen zählen, natürlich. Aber Funktionen werden schneller zur Commodity, als man denkt. Alle CRMs ähneln einander. Alle LMSs ähneln einander. Alle Telemetrie-Plattformen ähneln einander. Die Unterschiede sind inkrementell, und ab einem bestimmten Niveau sind sie nicht mehr das Kaufunterscheidungsmerkmal. Zum Unterscheidungsmerkmal wird, was keine Funktion ist: die Fähigkeit, einen Vertrag mit präzisen Haftungsklauseln zu unterzeichnen, ein Audit zu bestehen, operative Kontinuität zu garantieren, die eigene Software-Lieferkette zu dokumentieren, in 24 Stunden auf eine Betroffenenanfrage zu antworten, die Nicht-Diskriminierung eines Entscheidungssystems nachzuweisen, die eigenen Produkte über Jahre zugänglich zu halten.

Keine dieser Sachen ist eine Funktion im klassischen Sinn. Es sind nachweisbare organisatorische Fähigkeiten. Und es sind genau jene, die der europäische Regulierungsrahmen aufzubauen erzwingt.

Hier liegt, meiner Ansicht nach, die fundamentale konzeptuelle Umkehrung. Für ein Unternehmen, das Compliance als Formalität lebt, ist die Dokumentation ein Nebenprodukt: das, was man produziert, damit die Inspektoren zufrieden sind. Für ein Unternehmen, das Compliance als Architektur lebt, ist die Dokumentation das Produkt — oder besser: ein konstitutiver Teil des Produkts, denn was man verkauft, ist nicht die Software, sondern die organisierte Fähigkeit, sie über die Zeit zu betreiben, und diese Fähigkeit ist nur dokumentarisch nachweisbar.

Aus diesem Blickwinkel versteht man, warum das SBOM kein Papierkram ist: Es ist das Manifest der Lieferkette Ihrer Software, und es ist das, was dem Kunden erlaubt, seine eigene Exposition zu managen. Man versteht, warum der Audit-Log kein Kostenpunkt ist: Er ist eine Verlässlichkeitseigenschaft, die der Kunde ohnehin kaufen wird und die in Kürze obligatorisch wird. Man versteht, warum ein der Norm EN 301 549 entsprechender Barrierefreiheits-Bericht keine Formalität ist: Er ist das, was dem öffentlichen Kunden erlaubt, seine eigene Ausschreibung zu gewinnen, und damit das, was Sie zum bevorzugten Lieferanten macht.

Wenn man Vertrauen verkauft, ist die Dokumentation das Produkt und die Compliance die Bedienungsanleitung des Produkts.

Der ehrliche Einwand

Es wäre unredlich, diese Lesart zu präsentieren, ohne die ernsten Einwände anzuerkennen. Es gibt mindestens drei, und sie verdienen es, ernst genommen zu werden.

Der erste ist der der Schieflage. Die regulatorische Last, die heute auf einer zehnköpfigen Software-Schmiede liegt, ist objektiv sehr nahe an jener, die auf einem Großkonzern liegt. Nicht in absoluten Zahlen — es gibt Schwellen und Ausnahmen —, aber strukturell: Die Prozesse, die nötig sind, um wirklich CRA-, AI-Act-, DSGVO-konform zu sein, sind streckenweise dieselben wie bei einem Multi, einfach mit weniger Leuten, die sie betreiben. Diese Schieflage ist real und der Hauptgrund, warum viele europäische KMU sich schwer tun. Es ist ein ernstes Problem, das von Brüssel bessere Arbeit an Verhältnismäßigkeit, an vereinfachten Regimen für KMU und an der Verfügbarkeit zugänglicher Compliance-Werkzeuge verlangt. Es ist aber kein Argument gegen Compliance an sich: Es ist ein Argument für ihre bessere Umsetzung.

Der zweite Einwand ist der der Heterogenität in der Umsetzung. Die europäische Verordnung wird, sobald sie in den nationalen Rechtsordnungen ankommt, auf Weisen dekliniert, die von Land zu Land variieren — zuständige Behörden, Zertifizierungsschemata, Aufsichtsinstrumente, Schwellen. Diese Heterogenität ist tatsächlich ein Kostenfaktor, vor allem für grenzüberschreitende Arbeit. Es ist eine spezifisch europäische Schwäche, gebunden an unsere institutionelle Geschichte, und sie löst sich nicht leicht auf. Aber — und das ist der Punkt — es ist keine Schwäche der Compliance: Es ist eine Schwäche der Integration des Binnenmarktes. Zwei verschiedene Probleme. Die europäische Regulierung abzutun, weil sie ungleich angewandt wird, ist ein bisschen so, als würde man die Idee der Sprache abtun, weil es Dialekte gibt.

Der dritte Einwand ist der interessanteste und verdient die ausführlichste Antwort. Es ist der Einwand der Time-to-Market: Wenn unsere amerikanischen Wettbewerber keine AI-Act-Compliance machen müssen und wir schon, dann kommen sie zuerst auf den Markt. Dieser Einwand stößt auf den Brüssel-Effekt, hebt ihn aber nicht ganz auf: Es gibt ein reales Fenster, in dem Beschränkungs-Asymmetrie Geschwindigkeits-Asymmetrie erzeugt. Der Punkt ist aber, dass dieses Fenster sich auf eine spezifische Untergruppe von Produkten bezieht — auf jene, die den Mass-Market-Konsumenten anzielen, wo Time-to-Market oft Solidität schlägt — und nicht auf jene, die regulierte Segmente anzielen. Für jenen, der an Krankenhäuser, Banken, öffentliche Verwaltung, kritische Infrastrukturen verkauft, ist Geschwindigkeit fast nie das Unterscheidungsmerkmal: Es ist nachweisbare Robustheit. Und dort ist der europäische Rahmen ein Vorteil, kein Handicap. Es gibt europäische Unternehmen, die im regulierten B2B gewinnen, gerade weil das amerikanische Produkt ohne die Dokumentation, ohne die Prozesse, ohne die Kultur ankommt — und unter Druck rekonstruiert werden muss, um Audits zu bestehen. Unter Druck zu rekonstruieren ist teuer: Ihre Margen sinken, unsere steigen.

Alle drei Einwände, kurz gesagt, haben einen Wahrheitskern, aber keiner rechtfertigt den katastrophistischen Schluss, der ihnen oft anhängt. Die richtige Antwort lautet: Compliance besser umsetzen, nicht ablehnen.

Was eine compliant-by-design Organisation tut

So weit die konzeptuelle Ebene. Ich möchte mit etwas Operativerem schließen, denn ein Essay über Compliance, der nicht in die Details geht, läuft Gefahr, geschätzt und dann vergessen zu werden.

Eine Organisation, die Compliance in Wettbewerbsvorteil verwandelt hat, weist nach meiner Erfahrung diese Züge auf.

Sie hat ein einziges Accountability-Modell, das den Software-Lebenszyklus durchquert. Nicht ein Modell für Sicherheit, eines für Privacy, eines für Barrierefreiheit, eines für KI: ein einheitliches Modell mit domänenspezifischen Deklinationen, in dem alle Anforderungen in denselben Pipelines und in derselben Dokumentation zusammenlaufen. Das SBOM, die DSFA, das Threat-Model, die Aufzeichnung der Barrierefreiheits-Tests, die Model Card leben im selben Repository, sind versioniert, werden bei jedem Release aktualisiert, sind von jeder anderen Stelle der Organisation aus verlinkbar.

Sie hat Automatisierung des Compliance-Artefakts. Die Erzeugung von SBOM, von SPDX, von License Reports, von Vulnerability Reports, von Accessibility Scans, von Model Evaluation Reports ist automatisch. Sie ist nicht etwas, das jemand vor einem Audit per Hand erstellt: Sie ist etwas, das die Pipeline bei jedem Build mit Zeitstempel und Referenz-Commit erzeugt. Das Ergebnis ist, dass, wenn eine Kundenanfrage hereinkommt, die Antwort in Minuten verfügbar ist, nicht in Wochen.

Sie hat Verträge als Spezifikationen. Kundenverträge — vor allem im Gesundheitswesen und in der öffentlichen Verwaltung — sind keine vom technischen Werk getrennten juristischen Texte, sondern technische Spezifikationen, die im Backlog leben. Sicherheitsklauseln sind auf Requirements gemappt, Requirements auf Tests, Tests auf Pipelines. Wenn ein Kunde verlangt, die Konformität mit einer Klausel zu zertifizieren, lautet die Antwort nicht „fragen wir den Berater”: Sie ist eine Abfrage gegen das eigene System.

Sie hat internalisierte juristische Kompetenz. Das heißt nicht, einen Anwalt im Organigramm zu haben. Es heißt, dass die Tech-Leads die Verordnungen kennen, die sich auf ihre Domäne beziehen, ihre Logik verstehen, ihre Anforderungen in architektonische Entscheidungen übersetzen können. Der externe Berater ist eine Ressource für spezialisierte Fälle, nicht der Eigentümer der Compliance.

Sie hat eine Kultur des expliziten Trade-offs. Sie weiß, wann eine Compliance-Anforderung Kosten erzwingt, deklariert sie, debattiert sie, trifft begründete Entscheidungen. Sie tut nicht so, als wäre Compliance kostenlos. Sie tut nicht so, als wäre sie unmöglich. Sie behandelt sie als eine der Beschränkungen des Projekts, gegen andere abzuwägen.

Und vor allem hat sie eine kommerzielle Erzählung, die in der Konformität gegründet ist. Sie weiß den Kunden zu erzählen, warum ihr Produkt besser ist, und dieses „Warum” schließt — neben den Funktionen — die dokumentierte Verlässlichkeitsstruktur ein. Sie weiß, dass der Gesundheitskunde, der Verwaltungskunde, der Bankenkunde genau das kauft: die Garantie, dass Sie auf drei Jahre, auf fünf Jahre, vor einer Inspektion, vor einem Vorfall, vor einer regulatorischen Verschiebung noch ein solider Lieferant sein werden. Das ist kein Zugeständnis ans Marketing: Das ist das Produkt.

Die zivile Unterschrift Europas

Ich möchte schließen, indem ich aus dem operativen Terrain heraustrete und zum konzeptuellen zurückkehre, denn ich glaube, es gibt eine weitere Dimension — zivil, fast politisch —, die zu benennen lohnt.

Europa, als Projekt, ist ein singuläres historisches Experiment: ein Bund von Staaten, die nach den Katastrophen des 20. Jahrhunderts beschlossen haben, Souveränität gegen Regeln zu poolen. Es ist kein Bund der Kraft: Es ist ein Bund der Normen. Unser symbolischer Reichtum, unsere Fähigkeit, Werte zu projizieren, unsere internationale Glaubwürdigkeit hängen in hohem Maße von der Idee ab, dass wir die Regeln machen, sie einhalten und sie auf uns selbst anwenden. Wenn wir sie exportieren, tun wir es nicht durch Kraft, sondern durch den Markt.

Was wir im Digitalen tun, ist genau das: unsere zivile Unterschrift in den Cyberspace übertragen. Die Idee, skandalös für einen Teil der Welt, dass die Technik jenen Rechenschaft schuldet, die sie erleiden, nicht nur jenen, die sie produzieren. Dass die Auswirkungen technischer Systeme auf Individuen keine Externalität sind, sondern ein legitimer Gegenstand der Regulierung. Dass Innovation, die nicht entschädigte Schäden, nicht behobene Ausschlüsse, nicht erklärbare Opazitäten produziert, keine Innovation ist: Sie ist ein Transfer von Kosten vom Produzenten zum Bürger, als Fortschritt verkleidet.

Man kann diese Sicht nicht teilen. Es gibt Rechtsordnungen, die andere Wahlen getroffen haben, und wir respektieren sie. Aber zu behaupten — wie es manche unter uns noch tun —, unsere Sicht sei eine Bremse und der wahre Fortschritt liege anderswo, heißt, nicht verstanden zu haben, welches Spiel wir spielen. Das Spiel ist nicht, wer als Erster mit einem neuen Gadget auf den Konsumentenmarkt kommt. Das Spiel ist, wer die Grammatik definiert, innerhalb derer technische Systeme in den nächsten fünfzig Jahren operieren werden. Die DSGVO ist bereits die Grammatik der globalen Privatsphäre. Der AI Act wird zur Grammatik der globalen algorithmischen Accountability. Der CRA wird zur Grammatik der globalen Sicherheit von Software-Produkten.

Für jenen, der in Europa Software entwirft, ist die Teilnahme an diesem Spiel ein Privileg, das wir mit einem spezifischen Preis bezahlen — dem Preis, zuerst zu bauen —, aber sie ist auch, gerade deshalb, unser wichtigster struktureller Wettbewerbsvorteil. Wer draußen bleibt, innerhalb Europas selbst, weil er den Rahmen lästig findet, macht eine kurzsichtige Rechnung: Er entzieht sich dem einzigen Vorteil, den wir haben, um einem Wettbewerbsmodell nachzujagen — dem der reinen Time-to-Market —, in dem wir ohnehin nicht gewinnen können, weil wir nicht die Kapitalmasse derer haben, die es definieren.

Konformität, richtig verstanden, ist nicht unsere Last. Sie ist unsere Form. Unsere Form zu bauen, unsere Form Geschäfte zu machen, unsere Form Werte zu projizieren. Sie als Ballast zu behandeln, ist, für einen Musiker, wie die Tonart als Ärgernis zu behandeln. Man kann das tun, gewiss. Aber man spielt etwas anderes, und man spielt es schlechter.

Die Beschränkung, noch einmal, ist Form. Und die Form ist, für jene, die sie zu bewohnen verstehen, ein Vorteil.

Was du mitnimmst

  • Compliance als Gegnerin des technischen Projekts zu behandeln, ist ein Kategorienfehler: Die Beschränkung ist nicht der Feind des Designs, sie ist seine Form.

  • Der europäische Rahmen ist keine Liste unverbundener Pflichten, sondern ein System mit einer einzigen Grammatik — technische Systeme, die Rechte spürbar beeinflussen, by design rechenschaftspflichtig zu machen.

  • Der Brüssel-Effekt verwandelt den europäischen Standard in den globalen Standard; wer bereits in diesem Rahmen baut, hat den First-Mover-Vorteil.

  • Das Architektur-Unternehmen gewinnt regulierte Segmente mit höheren Margen; das Formalitäten-Unternehmen zieht sich beim ersten ernsthaften Technical Annex zurück.

  • Im regulierten B2B verkauft man nicht Funktionen, sondern dokumentiertes Vertrauen: Die Dokumentation ist Bestandteil des Produkts, kein Nebenprodukt.

Fragen & Antworten

Warum sollte europäische Compliance ein Wettbewerbsvorteil sein und kein Kostenfaktor?

Weil der europäische Rahmen, als System gelesen, eine organisatorische Fähigkeit kodifiziert — Accountability by Design —, die der regulierte Markt (Gesundheit, Verwaltung, Finanzwesen, kritische Infrastrukturen) ohnehin von seinen Lieferanten verlangt und die über den Brüssel-Effekt schrittweise zum globalen Standard wird. Unternehmen, die sie rechtzeitig aufbauen, erschließen sich Segmente mit höherem Wert und höheren Margen. Wer Compliance als Formalität nachläuft, zahlt zweimal: die Kosten der überstürzten Konformität und die verpasste Chance, sie in Marktposition zu verwandeln.

Was ist der Brüssel-Effekt, und warum zählt er für Software-Bauer?

Es ist das gut belegte Phänomen: Wenn die EU einen Markt dieser Größe reguliert, neigen multinationale Unternehmen dazu, den europäischen Standard als globalen Standard zu übernehmen, weil zwei Parallelregime teurer sind als die strengste Regelung überall. Die DSGVO ist heute de facto die Grammatik der globalen Privatsphäre; der AI Act ist auf demselben Weg. Für Software-Entwickler in Europa heißt das ganz konkret: Sie arbeiten bereits im Standard, der statistisch in fünf Jahren der globale sein wird. Das ist die operative Definition des First-Mover-Vorteils.

Was ist der Unterschied zwischen Compliance als Formalität und als Architektur?

Formalität: Man ernennt eine verantwortliche Person, füllt Checklisten aus, produziert Dokumente, um Sanktionen zu vermeiden. Compliance ist ein zu minimierender Kostenpunkt, sobald wie möglich ausgelagert. Architektur: Regulatorische Anforderungen werden vom ersten Tag an als Projektbeschränkungen genommen. SBOM aus der Pipeline bei jedem Build, Privacy als Dimension des Datenmodells, Barrierefreiheit als UI-Komponenten, Threat-Model bei jeder relevanten Architekturänderung neu bewertet. Zwei oder drei Jahre wirkt das erste Unternehmen effizienter; dann kommt der dreißigseitige Technical Annex, und der Unterschied wird entscheidend.

Werden europäische KMU nicht ohnehin von der Regulierungslast erdrückt?

Die Schieflage zwischen dem, was Compliance auf einer zehnköpfigen Software-Schmiede lastet, und dem, was sie auf einem Konzern lastet, ist real und der Hauptgrund, warum viele italienische KMU ringen. Es ist ein ernstes Problem, das von Brüssel bessere Arbeit an Verhältnismäßigkeit und vereinfachten Regimen verlangt. Aber es ist kein Argument gegen Compliance: Es ist ein Argument für ihre bessere Umsetzung. Die KMU, die Compliance als Architektur statt als wiederkehrenden Notfall behandeln, sind dieselben, die öffentliche Ausschreibungen und regulierte RFPs gewinnen, in denen der Preis nicht das Unterscheidungsmerkmal ist.

Was bedeutet „dokumentiertes Vertrauen“ im regulierten B2B konkret?

Dass das Kaufunterscheidungsmerkmal nicht mehr die Funktion ist — Funktionen werden schnell zur Commodity —, sondern die Fähigkeit, einen Vertrag mit präzisen Haftungsklauseln zu unterzeichnen, ein Audit zu bestehen, die eigene Software-Lieferkette zu dokumentieren, in 24 Stunden auf eine Betroffenenanfrage zu antworten, die eigenen Produkte über Jahre zugänglich zu halten. Das sind nachweisbare organisatorische Fähigkeiten. Wenn man Vertrauen verkauft, ist die Dokumentation das Produkt und die Compliance die Bedienungsanleitung des Produkts.

Der Autor

Andrea Margiovanni

Andrea Margiovanni

Ich verfolge das Verhältnis zwischen KI und europäischer Regulierung als politisches Faktum, nicht als technisches Spektakel. Ich arbeite mit Teams, die KI mit AI Act, CRA, NIS2 vereinbar machen müssen, ohne Compliance auf eine Checkliste zu reduzieren.

Zum Weg
© 2026 Andrea Margiovanni Mit Sorgfalt, von Hand gemacht