Der Aufstieg des Compliance Engineers

Die verworrene Stellenanzeige

Die Stellenanzeige war im Februar auf einer dieser Plattformen erschienen, wo italienische mittelständische Unternehmen technische Profile suchen, ohne sich allzu sicher zu sein, was sie suchen. Der Titel der Position lautete „Senior Software Engineer with Regulatory Background“, und schon dort war etwas Seltsames, weil eine solche Formel auf Italienisch nichts Präzises bedeutet. Der Anzeigentext klärte wenig auf. Verlangt wurden mindestens fünf Jahre Erfahrung in Backend-Entwicklung, vorzugsweise Java oder Python, Kenntnisse von Kubernetes, Erfahrung mit CI/CD-Pipelines. Bis hierhin ein normales Senior-Developer-Profil. Dann wechselte der Text das Register und begann, vertiefte Kenntnisse der DSGVO zu fordern, Beherrschung des AI Act in Bezug auf Hochrisiko-Systeme, die Fähigkeit, DSFA und Risikobewertungen zu erstellen, Erfahrung mit Compliance-Frameworks wie ISO 27001 und SOC 2, die Fähigkeit, mit externen Auditoren zu kommunizieren. Das angegebene Gehalt entsprach dem eines Senior Developers zu Marktpreisen, mit einem kleinen, nicht quantifizierten Aufschlag für die regulatorischen Kompetenzen.

Ich habe diese Anzeige etwa zehnmal gelesen und versucht zu verstehen, wen sie wirklich suchten. Eine solche Person, mit dieser Kombination von Kompetenzen, existiert in Italien heute nicht in nennenswerter Zahl, und wenn sie existiert, kostet sie das Doppelte dessen, was das Unternehmen bot. Ob das Unternehmen das wusste oder nicht, ist schwer zu sagen. Was sicher ist, ist, dass es einen realen Bedarf hatte, weil es im Begriff war, ein System an einen regulierten Kunden auszuliefern, und die richtige Person nicht im Haus hatte. Es hatte Senior-Entwickler, die keine europäische Verordnung lesen konnten, einen internen Juristen, der keinen Code lesen konnte, und einen externen Compliance-Berater, der mit einem der beiden sprechen konnte, aber nicht mit dem anderen. Die Person, die es suchte, existierte in seinem Kopf als Übersetzer zwischen Welten, die nicht miteinander sprachen, aber diese Person hatte noch keinen stabilen Berufsnamen.

Die Anzeige wurde im März unter einem anderen Titel neu veröffentlicht, „Compliance Engineer“, ohne weitere Änderungen am Text. Dann verschwand sie. Ich weiß nicht, ob das Unternehmen jemanden gefunden oder aufgegeben hat. Was ich weiß, ist, dass ich Anzeigen wie diese mit minimalen Varianten ein- bis zweimal pro Woche auf italienischen Plattformen vorbeiziehen sehe, und viele mehr auf europäischen. Ich sehe einem Handwerk zu, das nach seinem Namen sucht und ihn in den nächsten zwei oder drei Jahren finden wird, weil es keine Alternative hat.

Der technologische Einwand

Der Einwand, den ich sofort behandeln möchte, weil er der ernsthafteste von allen ist und immer von C-Levels vorgebracht wird, die sich um Kosten kümmern, ist der technologische. Er klingt so: Die ganze Arbeit, die du beschreibst, wird die KI in drei Jahren tun. Ein Agent wird das System lesen, die Verordnung lesen, die Kartierung erstellen, die Dokumentation aktualisieren, Inkohärenzen melden. Es braucht keine neue Berufsfigur, es braucht nur, auf die Reife der Technologie zu warten. Es ist ein Einwand mit scheinbarer Plausibilität und so verbreitet, dass er eine Antwort verdient. Die Antwort ist, dass die KI tatsächlich neunzig Prozent der mechanischen Arbeit erledigen wird, und ich treffe hier keine vorsichtig-vorsichtigen Vorhersagen, ich beschreibe, was sie heute schon tut, wo sie ernsthaft eingesetzt wird. Was übrig bleibt, die zehn Prozent, entspricht nicht den Restprozent, von denen man annimmt, sie würden mit der Verbesserung der Modelle verschwinden. Es sind die interpretativen und politischen zehn Prozent, und es ist genau der Teil, der einen Menschen erfordert, der gleichzeitig die Architektur des Systems und die Struktur der Verordnung versteht und der zu wählen weiß, wie die beiden auszurichten sind, wenn der Buchstabe der Norm und die Wirklichkeit der Software in Spannung geraten — was viel häufiger geschieht, als die Regulierer zugeben möchten.

Wenn man die Perspektive umkehrt, ist es gerade die KI, die die Figur des Compliance Engineers wirtschaftlich tragbar macht. Ohne generative Assistenz wäre das von dem neuen europäischen Regime geforderte Dokumentationsvolumen für jeden, der nicht ein multinationaler Konzern mit einem dedizierten Team von dreißig Personen ist, unbeherrschbar. Ein Software-Haus von zehn oder fünfzehn Personen kann sich nicht zwei Vollzeitstellen für diese Funktion leisten, und tatsächlich hat es sie heute nicht. Aber mit gut konfigurierter KI-Assistenz kann eine einzige, gut ausgebildete Person die Compliance aller Projekte des Unternehmens mit einer Qualität überwachen, für die vor fünf Jahren ein kleines Team nötig gewesen wäre. Die Frage ist also nicht, ob die KI den Compliance Engineer ersetzen wird, sondern genau das Gegenteil. Ohne KI würde der Compliance Engineer nicht als Rolle existieren, die KMU zugänglich ist, sondern nur als Abteilung großer Unternehmen. Mit der KI wird er zur Synthesefigur, die es auch mittelgroßen Organisationen erlaubt, in regulierten Märkten zu operieren, ohne ihre normative Intelligenz auszulagern.

Eine institutionelle Distanz

Die Rekonstruktion der Bedingungen, unter denen diese Figur entstand, verdient einige Details, weil ihre Genese typisch italienisch und europäisch ist und weil das Verständnis der Genese hilft zu verstehen, warum das Handwerk die Form hat, die es hat. Der Ausgangspunkt ist eine institutionelle Distanz zwischen zwei akademischen und beruflichen Traditionen, die in Italien, mehr als anderswo, sich nie ernsthaft begegnet sind. Auf der einen Seite die Informatikingenieurkunst, ausgebildet in den Ingenieurfakultäten, mit historischer Aufmerksamkeit für die Funktionsweise der Software als technisches Objekt. Auf der anderen Seite das Recht, ausgebildet in den juristischen Fakultäten, mit historischer Aufmerksamkeit für Normen, verstanden als zu interpretierende Texte. Die zwei Traditionen sprechen nicht miteinander, nicht weil es keine Menschen guten Willens gäbe, die Brücken zu bauen versuchen, sondern weil die Studienprogramme die Brücke nicht als strukturierten Studiengegenstand vorsehen. Der Ingenieur verlässt die Universität mit der Fähigkeit, Code zu schreiben und Systeme zu entwerfen, aber mit einer Exposition zum Recht, die sich im besten Fall auf einen einsemestrigen Kurs zum IT-Recht beschränkt, oft erteilt von einem Dozenten, der die Software als Phänomen und nicht als Praxis studiert hat. Der Jurist verlässt die Universität mit der Fähigkeit, Normen zu interpretieren, aber mit einer Exposition zur Software, die sich im besten Fall auf einige Tagungen und einige populärwissenschaftliche Handbücher beschränkt.

Diese Distanz war kein ernsthaftes Problem, solange Software auf der Grundlage funktionaler, leistungsbezogener und kommerzieller Kriterien bewertet wurde. Als Software auch nach normativen Kriterien bewertet wurde, ist das Problem explodiert, weil sich Organisationen plötzlich gegenüber dem Regulator zertifizieren mussten, dass ihr System Pflichten einhielt, die weder ihre Entwickler noch ihre Juristen vollständig zu übersetzen wussten. Die DSGVO, ab Mai 2018 anwendbar, war der erste ernsthafte Test. Über Jahre bestand die Antwort der italienischen Unternehmen darin, die Compliance an spezialisierte Berater auszulagern, die angemessene Dokumente erstellten, aber selten in den Code eingingen, oder einen internen oder fraktionierten Datenschutzbeauftragten zu ernennen, der mit dem Recht sprach, aber wenig mit dem Engineering. Es funktionierte schlecht, aber es funktionierte ausreichend, weil die DSGVO allein nicht genug Druck erzeugte, um eine neue Berufsfigur hervorzubringen.

Der nötige Druck ist in den letzten drei Jahren mit der Anhäufung der Akte des europäischen Regulierungspakets zum Digitalen gekommen. AI Act, Cyber Resilience Act, Überarbeitung der Product Liability Directive, NIS2, Digital Operational Resilience Act für den Finanzsektor, Data Act, European Accessibility Act. Jede dieser Verordnungen wäre einzeln genommen mit traditionellen Methoden bewältigbar gewesen. Zusammen genommen, und in den komprimierten Zeiten, in denen sie zwischen 2024 und 2027 in Kraft getreten sind oder treten, haben sie die Lage strukturell anders gemacht. Organisationen, die Software für den europäischen Markt produzieren, haben sich plötzlich mit Dokumentations-, Risikobewertungs-, Sicherheits-, Nachverfolgbarkeits- und Accountability-Pflichten konfrontiert gesehen, die sich vermehren und überschneiden auf Weisen, die eine integrierte Sicht erfordern. Der externe Berater, der ein Dokument nach dem anderen produziert, reicht nicht. Der interne Jurist, der keinen Code liest, reicht nicht. Der Senior-Entwickler, der das System den Auditoren zweimal im Jahr erklärt, reicht nicht, und auch die Kombination der drei Figuren, die sich in periodischen Sitzungen abstimmen, reicht nicht, denn die Koordination durch periodische Sitzungen ist genau die Vorrichtung, die Spezifikationsschulden erzeugt. Es braucht jemanden, der nur dies tut, und der es jeden Tag tut, innerhalb der Organisation.

Drei Scheiben in einer einzigen Person

Auf der Ebene der Taxonomie der Berufsfiguren passiert Folgendes: Der Compliance Engineer absorbiert Arbeitsscheiben, die heute auf drei verschiedene Rollen verteilt sind. Erste Scheibe, der Senior-Entwickler, der heute den Auditoren das System erklärt. Es ist eine Figur, die in fast allen Organisationen einer gewissen Größe existiert, fast immer ein Senior, der das System seit Jahren kennt und aus Entwicklungsprojekten herausgezogen wird, um Dritten Präsentationen zu geben. Er macht die Arbeit ungern, weil das nicht das ist, wofür er eingestellt wurde, er macht sie mit mittelmäßiger Qualität, weil ihm die dokumentarischen Werkzeuge fehlen, sie gut zu machen, und er füllt seine Zeit mit Aktivitäten, die der Hauptrolle Wert entziehen. Zweite Scheibe, der Architekt, der heute die regulatorischen Anforderungen in Designentscheidungen übersetzt. Auch diese Figur ist fast überall präsent, in der Regel ein Architekt, der sich selbst auf den Verordnungen ausgebildet hat, weil es jemand tun musste, und der das in der Zeit tut, die ihm von technischen Entscheidungen übrig bleibt, mit dem Ergebnis, dass seine Designentscheidungen übermäßig vorsichtig sind, wo die Verordnungen mehrdeutig sind, und dass er das System oft überreguliert und unnütze operative Reibungen erzeugt. Dritte Scheibe, der interne Jurist oder der Compliance-Berater, der heute versucht, Code zu lesen, ohne ihn lesen zu können. Das ist die frustrierteste Figur von allen, weil sie die formale Verantwortung hat, ihr aber die technischen Werkzeuge fehlen, sie auszuüben, und sie endet damit, den Entwicklern Dinge zu fragen, die diese nicht in die Praxis übersetzen können, was eine kommunikative Schleife erzeugt, die formal korrekte, aber inhaltlich tote Dokumente produziert.

Ein typischer Tag

Der Compliance Engineer nimmt die drei Scheiben und vereint sie in einer einzigen Person, mit dedizierter Zeit und dedizierten Werkzeugen. Ein typischer Tag in einem mittelgroßen Unternehmen, das Software für regulierte Kunden produziert, beginnt mit der Durchsicht der Wochen-Tickets, um zu identifizieren, welche Code-Änderungen die Compliance betreffen. Er setzt sich fort mit einer Arbeitssitzung an einer spezifischen Pull Request, um mit dem architektonischen Reviewer die Auswirkungen einer Änderung auf personenbezogene Datenflüsse zu besprechen. Er geht weiter mit einem Anruf beim internen Juristen, um eine Vertragsklausel zu klären, die der Kunde vorgeschlagen hat und die in Spannung mit unserem technischen Sicherheitsanhang geraten könnte. Nachmittag mit Arbeit an der Aktualisierung der DSFA des Projekts X, weil der Drittanbieter den Hosting-Datacenter gewechselt hat und das die Kartierung der grenzüberschreitenden Datenflüsse verändert. Abschluss mit einer Sprint-Planning-Sitzung, in der der Compliance Engineer die Dokumentationsanforderungen der nächsten drei Tasks vorstellt, damit das Team weiß, was es neben dem Code zu produzieren hat. Nichts davon ist juristisch im engen Sinne, nichts davon ist technisch im engen Sinne. Alles ist techno-juristisch, und es ist die hybride Natur der Arbeit, die die Figur rechtfertigt.

Die zwei Entartungen

Das Risiko der Figur, und es muss explizit benannt werden, weil es das Hauptrisiko ist, ist, dass sie in zwei pathologische Richtungen entarten kann, die beide bereits beobachtbar sind. Die erste Entartung ist der Compliance Engineer als bürokratischer Gate-Keeper, der die Releases blockiert. Es ist die sichtbarste und schädlichste Version, weil sie die Compliance-Aufsicht gegen das Delivery stellt, und wenn diese Gegenüberstellung sich stabilisiert, verliert die Organisation sowohl an Geschwindigkeit als auch an Compliance-Qualität. Der Gate-Keeper produziert immer längere Checklisten, verlangt immer artikuliertere Genehmigungen, verzögert die Releases mit Begründungen, die Entwicklern wie Formalismen erscheinen, und endet damit, als Kostenposten wahrgenommen zu werden, den es zu minimieren gilt, statt als Investition, die zu erhalten ist. Die zweite Entartung, in den Symptomen entgegengesetzt, aber in der Wurzel identisch, ist der Compliance Engineer als Policy-Dekorateur, der Dokumente unterschreibt, ohne den Code zu lesen. Das sieht man eher in Unternehmen, in denen die Figur eingeführt wird, weil ein regulierter Kunde oder ein bevorstehendes Audit es verlangt, und in denen die Aufgabe einer Person übertragen wird, die wegen ihrer Bereitschaft ausgewählt wurde, dokumentarische Lasten zu tragen, eher als wegen ihrer tatsächlichen Fähigkeit, das System zu lesen. Der Dekorateur produziert formal perfekte Dokumente, füllt alle erforderlichen Felder aus, lässt das Management unterzeichnen, und währenddessen entwickelt sich das reale System in Richtungen, die das Dokument nicht mehr beschreibt. Das ist genau die Bedingung, die ich im vorigen Stück dieser Reihe als Spezifikationsschulden bezeichnet habe und gegen die der Compliance Engineer ankämpfen sollte, die er aber stattdessen miterzeugt, wenn er falsch interpretiert wird.

Beide Entartungen haben eine gemeinsame Ursache, das Fehlen einer strukturierten Ausbildung der Figur. Wenn das Handwerk keinen akademischen Referenzpfad hat, baut sich jeder es aus seiner eigenen Herkunft auf. Der Entwickler, der zum Compliance Engineer wird, bringt das Vorurteil mit, die Compliance sei eine Servicefunktion des Codes, und neigt dazu, die juristischen Konsequenzen technischer Entscheidungen zu unterschätzen. Der Jurist, der zum Compliance Engineer wird, bringt das umgekehrte Vorurteil mit, der Code sei eine Servicefunktion der Norm, und neigt dazu, mit schweren technischen und organisatorischen Folgen zu überregulieren. Eine dritte, immer häufigere Bahn ist die des Systemadministrators, der durch natürliche Affinität zu dokumentarischen Praktiken zum Compliance Engineer wird und dazu neigt, Zertifizierungspipelines zu bauen, die parallel zu und nie verbunden mit dem Anwendungsentwicklungszyklus leben. Es gibt auch eine vierte, seltenere, aber vielversprechendere Bahn, die jener, die über gemischte Wege zu der Figur kommen, etwa derer, die jahrelang im Product Management an regulierten Produkten gearbeitet und Sensibilität für beide Seiten der Bruchlinie entwickelt haben. Keine der ersten drei Bahnen produziert allein einen Compliance Engineer, der der Aufgabe gewachsen ist. Sie produzieren Halbfiguren, die in einigen Unternehmen und Kontexten funktionieren und anderswo scheitern.

Eine echte doppelköpfige Kompetenz

Was nötig wäre und heute nicht existiert, ist ein strukturierter Bildungsweg, der von der Annahme ausgeht, dass die Disziplin echt zweiköpfig ist, ingenieurmäßig und juristisch zugleich, und dass beide Hälften Solidität und nicht Oberflächlichkeit verlangen. Die Software-Ingenieurkunst des Compliance Engineers unterscheidet sich von der vereinfachten und allgemeinen Version, die man in populären Kursen findet, und verlangt echte Software-Ingenieurkunst, mit Beherrschung verteilter Architekturen, Anwendungssicherheit, Code-Lebenszyklus, DevOps-Praktiken, Datenmodellierung. Die Compliance des Compliance Engineers geht ebenso über die operative und checklist-getriebene Version hinaus, die man in Business-School-Kursen findet, und verlangt echte europäische Jurisprudenz, mit Beherrschung der Verordnungen, Fähigkeit, Erwägungsgründe zu lesen, Kenntnis der Rechtsprechung des Gerichtshofs, Fähigkeit, die interpretative Entwicklung der nationalen Behörden vorwegzunehmen. Eine Person, die all das hat, formt sich nicht in einem sechsmonatigen Master, sie formt sich in einigen Jahren Arbeit, geleitet von ernsthaften Mentoren, und ernsthafte Mentoren sind noch wenige.

Die italienische Universität ist aus dieser Sicht strukturell verspätet. Die Studiengänge in Informatik-Ingenieurwesen, auch die besten, widmen der regulatorischen Compliance eine Stundenzahl, die im Vergleich zum Gewicht, das diese Disziplin auf dem Markt angenommen hat, lächerlich ist. Die Studiengänge in Jura, auch die besten, widmen der Software als reguliertem Objekt eine Stundenzahl, die im Vergleich zur Zentralität, die die Software in der Wirtschaft hat, lächerlich ist. Es gibt postgraduale Master-Programme, die versuchen, die Lücke zu schließen, und einige sind gut gemacht, aber es sind Master, also komplementäre Ausbildungen von sechs oder zwölf Monaten, die die doppelte Kompetenz nicht von Grund auf aufbauen, sondern sie auf eine bestehende Kompetenz überlagern. Das Ergebnis ist, dass Unternehmen, die Compliance Engineers suchen, sie nicht im universitären System ausgebildet finden und sie intern selbst ausbilden müssen, mit den Zeiten und Kosten, die das mit sich bringt. Es ist eine klassische Marktverzerrung, in der die Nachfrage existiert und das Angebot sich noch nicht konsolidiert hat, und sie produziert über Monate vakante Stellen und volatile Gehälter.

Die großen Beratungen und die Lücke

Das Marktsegment, das das Phänomen hingegen bereits bemerkt hat und sich daran macht, es vor den anderen zu besetzen, sind die großen Beratungsfirmen. Es ist das sichtbarste und ambivalenteste Phänomen, und es muss ohne Moralismus, aber mit Realismus bewertet werden. Die großen Beratungen haben kommerzielle Schlagkraft, Präsenz bei Corporate-Kunden, industrielle Prozesse zur Bereitstellung von Berufsfiguren und Budgets, um interne Ausbildung in Geschwindigkeiten zu produzieren, die Universitäten nicht aufrechterhalten können. Sie bauen „Compliance as a Service“-Angebote auf, die die Arbeit des Compliance Engineers in verkäufliche Pakete bündeln. Das Problem, und ich sage es, ohne einen spezifischen Akteur zu nennen, weil das Problem kategorial und nicht individuell ist, ist, dass die Version der Figur, die die großen Beratungen aufbauen, fast immer die Policy-Dekorateur-Version ist. Es ist die kommerziell skalierbarste, am leichtesten zu verkaufende, am leichtesten zu industrialisierende. Der Compliance Engineer als wirklicher techno-juristischer Übersetzer, jener, der in den Code geht und die architektonischen Entscheidungen verändert, skaliert nicht gut im Beratungsmodell, weil er Kontinuität beim Kunden verlangt, die das für große Beratungen typische Projektmodell nicht leicht liefert.

Die Lücke, die die großen Beratungen nicht schließen werden und die hingegen die italienischen Software-Häuser schließen könnten, ist die des internen Compliance Engineers in Organisationen, die Software für regulierte Kunden produzieren. Mittelgroße Software-Häuser, zwischen zehn und fünfzig Personen, sind strukturell besser positioniert, diese Figur aufzubauen, als sowohl die großen Beratungen als auch die regulierten Unternehmen selbst. Sie haben die technische Nähe zum Code, die den Beratungen fehlt, sie haben die Vielzahl von Kunden, die regulierten Unternehmen fehlt, sie haben die Größe, die es erlaubt, eine dedizierte Person zu unterhalten, ohne sie auslagern zu müssen. Was viele italienische Software-Häuser nicht haben, und das ist der Grund, warum sie sich nicht schnell genug bewegen, ist das Bewusstsein, dass die Transformation bereits im Gange ist und dass derjenige, der sie als Erster abdeckt, einen Positionsvorteil erlangen wird, der in den folgenden fünf Jahren schwer zu erodieren ist.

Auf operativer Ebene bedeutet der Aufbau eines internen Compliance Engineers, vierundzwanzig bis sechsunddreißig Monate in eine Person zu investieren, die bereits die Hälfte der nötigen Kompetenzen hat. Der typische Kandidat ist ein Senior-Entwickler mit Neugier für die regulatorische Dimension, oder ein Architekt mit Sensibilität für Sicherheits- und Datenschutzthemen, oder eine Person aus dem Product Management mit einem gewissen Geschmack für Formalisierung. Der Wachstumspfad sieht Begleitung an realen Fällen vor, systematische Lektüre der europäischen Verordnungen in vergleichenden englischen und italienischen Sprachfassungen, Teilnahme an Audits bei Kunden, Erstellung von DSFA und Risikobewertungen unter Aufsicht, Aufbau von Dokumenten-Repositories, allmähliche Exposition zu internen Juristen und externen Beratern, um Vokabular und juristische Praktiken durch Osmose aufzunehmen. Es ist eine bedeutende Investition für ein kleines Software-Haus, und es ist genau die Art von Investition, die einen schwer reproduzierbaren Wettbewerbsvorteil schafft.

Disclosure: eine Bahn, die ich bewohne

Ich muss transparent sein, weil ich zu diesem Thema ein Phänomen beschreibe, dessen Teil ich bin, und die Analyse wäre unaufrichtig, wenn ich es nicht erklärte. Die Bahn, die ich beschreibe, ist die, die ich persönlich in meinem eigenen Unternehmen lebe, und ein nicht zweitrangiger Teil meiner Arbeit der letzten zwei Jahre bestand darin, den Compliance Engineer von Oltrematica intern aufzubauen, indem ich diese Position direkt besetze und gleichzeitig versuche, sie für jene zu formalisieren, die nach mir kommen. Ich schreibe diesen Text nicht als neutraler Beobachter eines Trends anderer, ich schreibe ihn als jemand, der ihn von innen bewohnt und der nach einigen Jahren Praxis den Eindruck hat, die Form verstanden zu haben, die die Figur annimmt, und etwas dazu sagen zu können, was funktioniert und was nicht. Ich bin weder besonders glücklich noch besonders stolz auf diese Bahn. Es ist einfach, was der Augenblick demjenigen abverlangt, der weiterhin Software für regulierte Kunden machen will, ohne seine eigene normative Intelligenz auszulagern, und ich habe sie angenommen, wie man Übergangsaufgaben annimmt, im Wissen, dass die Figur in zehn Jahren selbstverständlich sein wird und dass es heute an uns ist, sie tastend aufzubauen.

Verbindung, und eine Vorhersage

Es gibt eine direkte Verbindung, und es lohnt sich, sie explizit zu machen, zwischen der Figur, die ich beschreibe, und den beiden vorhergehenden Essays dieser Reihe. In dem Stück, das ich Cruft, keine Patina genannt habe, argumentierte ich, dass Software nicht altern kann, weil die Drift zwischen dem Code und der Umgebung, in der er läuft, ihn schneller erodiert, als die Ingenieurkultur sie verstoffwechseln kann. Im darauffolgenden Stück, Die Spezifikationsschulden, argumentierte ich, dass die Spezifikation der Software noch schlechter altert als der Code, weil die kontinuierliche Praxis fehlt, die sie am Leben halten würde, und dass der europäische normative Rahmen dieses Altern mit zuvor nicht existierenden juristischen Konsequenzen auflädt. Der Compliance Engineer ist die Figur, deren Handwerk genau darin besteht, die Spezifikationsschulden im Alltag zu bekämpfen, die Spezifikation an das System anzupassen, während sich das System ändert, und das mit der doppelköpfigen Kompetenz zu tun, die es erlaubt, weder in Dokumentenformalismus noch in Code-Trägheit zu verfallen. Es ist die Person, die in einer Organisation, die Software produziert, die Übereinstimmung zwischen geschriebenem Versprechen und beobachtetem Verhalten überwacht, im Wissen, dass unter dem neuen Regime die Kohärenz zwischen den beiden Ebenen das ist, was der Richter bewerten wird, falls je der Tag der Bewertung kommt.

Das Stück schließt mit einer Vorhersage, die zugleich ein Aufruf zum Handeln ist für jene, die mich aus dem Inneren einer Organisation lesen, die in Europa Software macht. In fünf Jahren, um 2031, wird die Figur des Compliance Engineers selbstverständlich sein. Es wird Studiengänge geben, es wird ernsthafte Zertifizierungen geben, es wird in irgendeiner Form berufsständische Organisationen geben, es wird feste Kolumnen in der Fachpresse geben. Was zu verstehen bleibt, ist nicht ob es geschehen wird, sondern nur in welchem Tempo. Die Organisationen, die sie jetzt aufbauen, handwerklich und aus Notwendigkeit, werden einen strukturellen Vorteil haben gegenüber jenen, die auf die Marktreife warten werden. Der Vorteil spielt sich jenseits der kommerziellen Ebene ab, er ist vor allem kognitiv, weil der, der die Rolle heute bewohnt, auch die Praktiken definiert, die zu Standards werden, und wer die Praktiken definiert, definiert sie nach Maß seiner eigenen Arbeitsweise.

Die Figur des Compliance Engineers ist keine Nische, sie ist die Rolle, die neu zeichnet, wie die europäische Software unter dem neuen regulatorischen Regime produziert wird. Es geschieht langsam, in Stille, in verworrenen Anzeigen, die Personen suchen, die noch nicht existieren, mit Titeln, die sich von Monat zu Monat ändern. Wenn die Anzeigen ihren stabilen Namen finden werden, und das wird bald geschehen, wird sich die Industrie aufteilen in jene, die rechtzeitig in diese Figur investiert haben, und jene, die sie auf einem konsolidierten Markt zum dreifachen Preis importieren werden. Wer mich aus dem Inneren eines mittelgroßen italienischen Software-Hauses liest, hat wahrscheinlich gerade jetzt im Unternehmen die richtige Person zum Ausbilden. Es ist ein Senior-Entwickler mit dem Kopf schief in den Verordnungen, oder ein Architekt, der allein angefangen hat, die DSGVO aus Neugier zu lesen, oder noch ein Systemadministrator, der sich der Dokumentation angenommen hat, weil sich niemand sonst darum kümmerte, und in einigen Fällen eine hybridere Figur, die über gemischte Wege gekommen ist, die in keine der drei klassischen Bahnen passen. Sie zu erkennen und ihr ein explizites Mandat zu geben, mit Investition in Zeit und strukturierter Ausbildung, ist die Managemententscheidung, die in den nächsten fünf Jahren den größten zusammengesetzten Wert produzieren wird. Nicht weil die Figur in Mode wäre. Sondern weil ohne sie, in einigen Jahren, Software für regulierte Kunden in Europa zu machen ein Handwerk werden wird, das sich italienische Software-Häuser nicht mehr leisten können werden.

Der Autor

Andrea MargiovanniKI

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 →