Ich komme aus der Philosophie. Jahre, in denen ich morgens Garin und Cassirer las und nachmittags Foucault und Bobbio, in denen Antiklerikalismus und Humanismus so natürlich zusammenfielen, dass man es nicht einmal begründen musste. Seitdem habe ich zwei Überzeugungen bewahrt, die ich weiterhin als Voraussetzung jeder ernsthaften öffentlichen Rede betrachte. Die erste ist, dass die historischen Religionen in der überwiegenden Mehrheit der Fälle antihumanistische Dispositive sind, weil die Verteidigung des Menschen eine Freiheit verlangt, die die klerikalen Strukturen nie gewähren konnten, außer zähneknirschend, unter Druck und fast immer verspätet. Die zweite ist, dass der Humanismus, der wahre, jener, der bei Garin beginnt und über die italienische Verfassung und die Erklärung von 1948 zum kontinentalen Recht des zwanzigsten Jahrhunderts gelangt, ein strukturell laizistischer Boden ist, auf dem die religiösen Traditionen als Gäste eintreten, und wenn sie den ganzen Raum für sich beanspruchen wollen, verwirren sie sich entweder oder verraten sich selbst. Es sind Urteile, die ich ohne große Erschütterung weiter praktiziert habe, während ich die technischen Anhänge des AI Acts, die letzten Anwendungsentwürfe des Cyber Resilience Acts, die EDPB-Hinweise zu den DSFA-Vorlagen für Hochrisikosysteme las. Ich arbeite in der europäischen Compliance, ich spreche täglich mit Kunden aus der öffentlichen Verwaltung und dem Gesundheitswesen, und die einzige Metaphysik, die ich gewöhnlich brauche, ist die, schon kompliziert genug, des Erwägungsgrunds 71 der DSGVO. Dann erschien Magnifica Humanitas, und etwas bewegte sich.

Keine Mahnung, eine Abhandlung über den Menschen

Ich brauchte zwei Abende, um sie zu lesen. Sie ist nicht kurz, und sie gibt nicht vor, kurz zu sein. Es ist ein langer Text, zweihundertfünfundvierzig Paragraphen verteilt auf fünf Kapitel, mit einem Apparat von zweihundertvierundzwanzig Fußnoten, geschrieben in jener kurialen Prosa, die mal verlangsamt und mal fast überraschend beschleunigt. Ich erwartete die x-te moralisierende Mahnung über die Künstliche Intelligenz, jene Art Dokument, das versucht, mit einer Branchentagung gleichzuziehen, und am Ende zwei Jahre zu spät und mit einer halben These weniger ankommt. Ich fand mich vor etwas anderem wieder. Keine Mahnung, sondern eine Abhandlung. Nicht über die KI, sondern über den Menschen, mit der KI als Prüfstein, um neu zu sagen, wer wir sind. Es ist genau das, was die säkulare technische Debatte nur schwer hervorbringt, weil es ein Niveau begrifflicher Begründung voraussetzt, das wir gewohnt sind den Gesetzen zu überlassen, in der Hoffnung, die Gesetze kämen allein zurecht.

Die Subsidiarität ist nicht in Brüssel geboren

Das Problem ist, dass die Gesetze nicht allein zurechtkommen. Ich sehe es sehr deutlich, wenn ich einem Kunden zu erklären versuche, warum die digitale Subsidiarität, jene, die einen großen Teil der Architektur des Data Acts und der operativen Kapitel des AI Acts inspiriert, keine Erfindung aus Brüssel ist, sondern ein Prinzip mit fast einem Jahrhundert Ausarbeitung im Rücken. Pius XI. formulierte sie 1931 in Quadragesimo Anno, und seither hat sie die Rechtsprechung, den deutschen Ordoliberalismus, die Arbeiten Adenauers durchquert, bis sie sich in Artikel 5 des Vertrags über die Europäische Union niederschlug. Wenn ein europäischer Regulierer schreibt, dass bestimmte Entscheidungen auf der den betroffenen Menschen nächstmöglichen Ebene getroffen werden sollen, benutzt er eine Grammatik, die anderswo geboren wurde, nicht in Brüssel. Und wenn ich versuche, diese Wahl vor einem Auftraggeber zu verteidigen, merke ich, dass mir die richtigen Worte fehlen, um sie zu erklären. Magnifica Humanitas hat mir an diesem Punkt ein Vokabular zurückgegeben.

Die universelle Bestimmung der Güter, auf Algorithmen angewandt

Was mich beeindruckt hat, ist nicht die Neuheit der Ideen. Die Ideen der Enzyklika sind weitgehend bekannt. Beeindruckt hat mich die Art, wie sie sie zusammenhält, denn es sind genau die Ideen, die ich jedes Mal brauche, wenn ich Compliance diskutieren muss, ohne sie auf eine bürokratische Übung zu reduzieren. Die universelle Bestimmung der Güter zum Beispiel, in Paragraph 67 auf Patente, Algorithmen, Plattformen, Infrastrukturen und Daten angewandt. Es ist keine Position, die man als vorpolitisch oder utopisch ablegen kann. Es ist genau dasselbe Problem, das der Data Governance Act mit dem Begriff des Datenaltruismus zu fassen versucht, das der DMA mit den Gatekeeper-Regeln verfolgt, dem sich die künftige Auslegung der europäischen Gesundheitsdatenbanken stellen wird, wenn der European Health Data Space in Kraft tritt. Dass ein Datum technisch sammelbar und eigentumsrechtlich zuweisbar ist, bedeutet nicht, dass seine endgültige Bestimmung legitim privat ist. Es ist eine operative Aussage, keine Predigt.

Über dem Bürger steht nicht mehr nur der Staat

Dasselbe gilt für die Subsidiarität in Paragraph 71. Die Enzyklika tut etwas, das wenige technische Dokumente den Mut haben, ausdrücklich zu tun: sie erinnert daran, dass im digitalen Kontext die Ebene über dem Bürger nicht mehr der Staat ist, sondern der große wirtschaftliche Akteur, der eine faktische Macht über die Bedingungen des gemeinsamen Lebens ausübt. Es ist keine Metapher. Wenn eine Plattform entscheidet, was sichtbar und was verborgen ist, wenn ein algorithmisches Scoring-System festlegt, wer Kredit erhält und wer nicht, wenn ein Sprachmodell zur dominanten Schnittstelle für bestimmte Arten von Dienstleistung wird, wird eine Macht ausgeübt, die die klassische Theorie der Subsidiarität in diesen Begriffen nicht vorgesehen hatte. Es formell anzuerkennen, innerhalb eines offiziellen Dokuments dieser Autorität, verschiebt die Ebene der Diskussion. Es hört auf, eine Nischenmeinung zu sein. Es wird zu einer begründeten Position, die man in einem Schriftsatz, in einer Folgenabschätzung, in einer Stellungnahme an einen Auftraggeber zitieren kann, der fragt, warum man sich all diese Mühe macht, um ein transparentes Logging-System zu implementieren.

Vom Urteil zur Berechnung, ein halbes Jahrhundert nach Weizenbaum

Dann gibt es eine Passage, die ich nicht erwartet hatte, und die wahrscheinlich das stärkste Stück des ganzen Dokuments ist. Sie steht in Paragraph 198, im Kapitel über die Kultur der Macht, dort, wo die Enzyklika den Krieg behandelt, aber sie gilt für alles. Das moralische Urteil ist nicht auf eine Berechnung reduzierbar, denn es setzt Gewissen, persönliche Verantwortung und die Anerkennung des anderen als Person voraus. Deshalb ist es nicht zulässig, künstlichen Systemen tödliche oder jedenfalls unumkehrbare Entscheidungen zu überlassen. Zwei Sätze, die mindestens ein halbes Jahrhundert kritischen Denkens über die automatische Berechnung enthalten. Joseph Weizenbaum, der MIT-Ingenieur, der 1966 ELIZA gebaut hatte und der wenige Jahre später erschrak, als er sah, wie seine Sekretärin sich ihr anvertraute, schrieb 1976 ein Buch, dessen Untertitel From Judgment to Calculation lautete. Vom Urteil zur Berechnung. Das ganze Buch war eine Verteidigung jener Präposition, zur, die einen Verlust markiert. Weizenbaum vertrat, dass es Aufgaben gibt, die Computer nicht ausführen können und nicht ausführen dürfen, auch wenn sie es technisch könnten, weil sie die Anerkennung des anderen als Person betreffen, und dass diese Anerkennung kein Problem der internen Repräsentation ist. Sie ist ein Akt. Magnifica Humanitas sagt ein halbes Jahrhundert später genau dasselbe mit einem anderen Vokabular. Es ist kein Zufall. Es ist, dass gewisse anthropologische Wahrheiten wieder hervorkommen, wenn die materiellen Bedingungen sie dazu zwingen, und heute sind die materiellen Bedingungen jene der automatisierten Entscheidungsfindung, angewandt auf reale Menschenleben.

Die neuen Sklavereien und der Datenkolonialismus

Die Enzyklika geht weiter. In Paragraph 173 benennt sie Dinge, die die Mainstream-Debatte über die KI lieber an den Rändern der Anbietertagungen lässt. Sie zitiert ausdrücklich die Datenetikettierung, die Inhaltsmoderation, die Förderung Seltener Erden, die Kinderarbeit in den Minen. Sie nennt sie neue Sklavereien, und nicht aus Rhetorik. Sie nennt sie so, weil sie tatsächlich, unsichtbar für jeden, der eine API zu sechzig Cent pro Million Token nutzt, die gesamte Wirtschaft der Transformer-Architekturen speisen. In Paragraph 178 führt sie einen Begriff ein, den die Forscher der Technopolitik seit mindestens fünf Jahren verwenden, der aber in einem päpstlichen Dokument einen gewissen Eindruck macht: Datenkolonialismus. Der Schlüsselsatz ist, dass, wer die Gesundheitsdaten ganzer Bevölkerungen besitzt, heute oft im Zeichen der Hilfe, der Forschung oder der Innovation gesammelt, in Wirklichkeit einen strukturellen Hebel auf die Zukunft besitzt. Es ist eine genaue Beschreibung des strategischen Risikos, das auf vielen afrikanischen, asiatischen, lateinamerikanischen Kontexten lastet, und das auf unseren Auftragsentscheidungen lasten sollte, wenn wir entscheiden, wo ein Datum gehostet wird, von welchem Anbieter wir das Training eines Modells kaufen, welchem Ökosystem wir die epidemiologische Analyse einer Region überlassen. Es ist keine New-Age-Sensibilität. Es ist eine Folgenabschätzung.

Eine Abhandlung, die als Quelle für eine DSFA trägt

An diesem Punkt der Lektüre hielt ich inne. Ich annotierte Passagen am Rand, als bereitete ich einen technischen Schriftsatz vor, und mir wurde klar, dass es genau das war, was ich tat. Die Enzyklika funktioniert bestens als anthropologische Abhandlung, aber sie funktioniert auch als sekundäre Quelle für ein Compliance-Argument. Es ist ein Text, den man in einer DSFA zitieren kann, um eine restriktive Bewertung zu begründen. Es ist ein Text, den man einer Stellungnahme zu einer KI-Integration im Gesundheitsbereich beilegen kann. Nicht weil er Rechtswert hätte, selbstverständlich, sondern weil er jenen Grundsatzrahmen liefert, der oft fehlt, wenn man technische Entscheidungen diskutiert, und der, wenn er fehlt, sich in Entscheidungen niederschlägt, die allein auf der Grundlage der Opportunitätskosten getroffen werden. Wer in der europäischen Compliance arbeitet, weiß, was ich meine. Es gibt eine Grauzone, zwischen dem Erwägungsgrund und dem Artikel, zwischen der Absicht des Gesetzgebers und dem Buchstaben der Norm, wo der Techniker sich auf etwas Solides stützen muss, um zu erklären, warum eine Auslegung einer anderen vorzuziehen ist. Einen Text dieser Tragweite zu haben, geschrieben aus einer Position außerhalb des technischen Systems, aber fähig, von innen darüber zu sprechen, ist ein Aktivposten, den aus Vorurteil nicht zu nutzen dumm wäre.

Es ist keine Bekehrung, und es ist kein perfekter Text

Mir ist bewusst, dass jene, die mich kennen, es seltsam finden könnten, diese Zeilen zu lesen. Ich kündige keine Bekehrung an, und ich sage auch nicht, dass das Dokument perfekt ist. Es gibt Punkte, an denen die Enzyklika abgleitet, vor allem wenn sie das Gebiet der Bioethik und der Familie betritt, wo meine persönliche Distanz unversehrt bleibt. Es gibt Passagen, in denen der pastorale Ton über die begriffliche Präzision die Oberhand gewinnt, und wo ich weniger rhetorische Nächstenliebe und mehr Werkzeuge der Analyse gewollt hätte. Es ist kein Text, den man unterschreibt, es ist ein Text, den man diskutiert. Aber es ist die Art von Diskussion, die mir, einem Atheisten, der an der europäischen Regulierung der Technik arbeitet, heute mehr nützt als gestern. Und ich glaube, sie nützt ebenso jenem, der versucht, eine europäische Technologieindustrie aufzubauen, die anders ist als jene, die uns aus San Francisco oder Hangzhou erreicht, denn anders bedeutet auf etwas gegründet, und etwas lässt sich in dieser historischen Phase nicht improvisieren.

Abrüsten

In Paragraph 110 gibt es ein Wort, das mich zum Lächeln gebracht hat. Abrüsten. Die Enzyklika sagt, sie wolle die KI abrüsten, und stellt sogleich klar, dass abrüsten nicht Verzicht bedeutet. Es bedeutet, sie den Monopolen und der Logik des Wettbewerbs zu entziehen, sie diskutierbar und anfechtbar zu machen, sie der Vielfalt der menschlichen Kulturen zurückzugeben. Es ist ein politisches Wort, kein religiöses. Es ist genau das Wort, das Brüssel noch nicht auszusprechen vermag, weil Brüssel noch Geisel jenes Realismus ist, der das Wettrüsten als natürliche Gegebenheit voraussetzt. Ein Wettlauf, der aufgehört hat, militärisch zu sein, um kognitiv zu werden, wie die Enzyklika mit bemerkenswerter Klarheit feststellt, der aber dieselbe grundlegende Logik beibehält. Dass der erste, der es aussprach, in einem offiziellen Dokument dieser Verbreitung, der Vatikan war und nicht ein europäischer Kommissar, sagt etwas über den Zustand unserer öffentlichen Debatte. Es ist keine gute Nachricht, aber es ist eine Nachricht, von der aus man beginnen kann.

Drei Dinge, die ich entleihe

Ich schließe mit einer Anmerkung, die nichts mit Theologie zu tun hat. Wenn man einen Text liest, der innerhalb einer Tradition entstanden ist, die uns nicht gehört, gibt es zwei Wege. Der eine ist der des vorbeugenden Misstrauens, der darin besteht, vom Text zu verlangen, seinen eigenen Ursprung zu verraten, bevor man auch nur akzeptiert, ihn zu hören. Der andere ist der der Anleihe, der darin besteht, zu nehmen, was nützt, zu lassen, was nicht nützt, und mit einem Werkzeug mehr zur eigenen Arbeit zurückzukehren. Als Atheist fühle ich, dass ich von Magnifica Humanitas mindestens drei Dinge entleihen kann. Die ausdrückliche Anerkennung, dass das moralische Urteil nicht automatisierbar ist, und dass, wer es zu automatisieren versucht, einen politischen Vorgang vollzieht, keinen technischen. Die Benennung der unsichtbaren Lieferketten, die die digitale Wirtschaft speisen, die die Voraussetzung jeder ernsthaften Forderung nach Due Diligence ist. Und jenes Wort, abrüsten, das ich in den kommenden Jahren auf die normativen Texte angewandt sehen möchte, die ich für die Arbeit zu lesen haben werde.

Den Rest diskutiere, wem daran liegt, an den geeigneten Orten. Mir genügt es heute, eine Abhandlung mehr auf dem Nachttisch zu haben, und ein paar gut geschriebene Seiten zum Wiederlesen, wenn ein Auftraggeber mich fragen wird, warum ich mir im Grunde, nach allem, die Mühe mache, die Dinge richtig zu machen.

Die erste Reaktion auf die Veröffentlichung der UNI 11621-8, der italienischen Norm, die die zwölf Berufsbilder der künstlichen Intelligenz definiert, sollte Misstrauen sein. Die Berufe eines Feldes zu standardisieren, das sich alle sechs Monate ändert, ist eine fast paradoxe Übung, und es vor dem Rest Europas zu tun, heißt das Risiko zu tragen, als Erstes falschzuliegen. Die Norm kam am 30. April 2026, unterzeichnet von UNINFO mit der Koordination des Dipartimento per la Trasformazione Digitale, des italienischen Departements für digitale Transformation. Die regulatorische Verankerung führt zur Verordnung EU 2024/1689, also zum AI Act, und zum italienischen Gesetz 132/2025 über KI. Das italienische Gesetz 4/2013 über nicht reglementierte Berufe dient als Rampe zur Zertifizierung.

Ein Wort auf der Suche nach einem Maß seit Februar

Für die tägliche Compliance-Arbeit schließt sich damit ein Kreis, der seit dem 2. Februar 2025 offen geblieben war. An jenem Tag hat Artikel 4 des AI Acts Anbietern und Betreibern auferlegt, ein ausreichendes Niveau der Alphabetisierung des Personals zu gewährleisten, ohne zu erklären, was, genau, das Adjektiv „ausreichend” bedeutete. In den letzten Monaten kehrte dieses Wort, während wir an Compliance-Projekten für Kunden in stark regulierten Sektoren arbeiteten, in jedem Gespräch als unbeantwortete Frage wieder. Kein Dokumentenkit und keine DSFA-Vorlage schaffte es, seine Bedeutung ohne Umschreibungen zu fixieren. Was bedeutet, genau, „ausreichende Kompetenzen”? Wann ist eine Kundenanfrage vernünftig, und wann wird sie zu einer Forderung ohne Maß? Die UNI 11621-8 bietet dieses Maß, und sie bietet es auf Italienisch, mit Namen, die der Einkäufer einer Gesundheitsfirma oder einer regionalen Behörde lesen kann, ohne sie zu übersetzen.

Zwölf Profile, vom CAIO bis zum Forscher

Die zwölf Profile decken das Spektrum von Governance bis Forschung ab. Man geht vom Chief AI Officer bis zum AI Research Scientist. Für jedes Profil spezifiziert die Norm Mission und Aufgaben sowie eine Karte der erforderlichen Kompetenzen mit dem erwarteten Niveau und den zugehörigen Leistungsindikatoren. Die Methodik ist die konsolidierte der UNI 11621-1, und die Verankerung ist am europäischen e-Competence Framework, der UNI EN 16234-1. Technisch ist die Arbeit solide, und es ist wichtig, dies zu sagen, bevor man zu den Problemen kommt.

Ein Stoff, der kodifiziert wird, während er sich noch bewegt

Die Probleme beginnen beim Stoff, den die Norm einzufrieren versucht. Ein Beruf wird kodifiziert, wenn er einen ausreichenden Grad an Stabilität erreicht hat, und die heutige KI hat ihn nicht. Der Prompt Engineer, in der Liste als separates Profil vorhanden, ist bereits ein interessanter Fall. Als er als eigenständige Rolle existierte, hatte er ein kurzes Leben, und wurde rasch von den Entwicklern und Produktmanagern absorbiert, die direkt mit generativen Modellen arbeiten. Ihn als dediziertes Profil zu halten heißt, einer Praxis hinterherzulaufen, die sich anderswo schon weiterentwickelt hat. Dasselbe gilt, in unterschiedlichem Grad, für die scharfe Trennung zwischen Data Scientist und Machine Learning Engineer, zwei Rollen, die sich in der realen Praxis weitgehend überschneiden. Die Grenzen der kodifizierten Berufsfiguren sind weit schärfer als die Grenzen der Kompetenzen, die die Menschen tatsächlich ausüben. Ein guter Data Scientist berührt das ML Engineering, und ein kompetenter ML Engineer weiß sich in der Datenpipeline zu bewegen. Wenn ein AI Security Specialist die Modelle nicht an der Wurzel versteht, hört er auf, ein Sicherheitsprofi zu sein, und wird zum Aktenprüfer.

Wer die Norm schreibt, und warum

Es gibt dann eine subtilere Frage, und sie betrifft die Herkunft der Berufsbildnormen in Italien. Sie werden von Ausschüssen produziert, in denen Zertifizierungsstellen und Ausbildungsanbieter sitzen, neben Berufsverbänden. Legitime Akteure, alle, und alle mit wirtschaftlichem Interesse am Endergebnis. Das macht die Norm nicht weniger nützlich, es ändert die Art, wie sie gelesen werden sollte. Unter der technischen Oberfläche steht der Aufbau eines Marktes. Der Markt der beruflichen Zertifizierung und der akkreditierten Ausbildung. Die ITS-Academy-Lehrgänge, das italienische höhere technische Bildungssystem, richten sich in diesen Wochen aus, und die Zertifizierungsstellen bereiten ihre Schemata vor. Das Gesetz 4/2013 liefert die Anbindung, wer ein Berufsbild zertifizieren kann, verdient an dieser Zertifizierung. Die Frage ist nicht, ob das System legitim ist, das ist es. Die Frage ist, was wir wirklich kaufen, wenn wir bezahlen, um einen internen Chief AI Officer zu zertifizieren.

Der Ersetzungseffekt, wie beim Datenschutzbeauftragten

Eine dritte Vorsicht betrifft den Ersetzungseffekt, der wahrscheinlich das ernsteste Risiko ist. UNI-konforme Profile zu haben bedeutet nicht, eine kompetente KI-Governance zu haben. Die jüngere Geschichte der DSGVO ist voll von Organisationen, die einen zertifizierten Datenschutzbeauftragten und desaströse Prozesse hatten, weil der Datenschutzbeauftragte ein administrativer Posten war, keine operative Funktion. Dasselbe kann dem Chief AI Officer und dem Security Specialist passieren. Compliance per Checkliste produziert organisatorischen Komfort und wenig tatsächliche Sicherheit. Wenn die UNI 11621-8 als dokumentarische Pflicht gelesen wird, werden wir Unternehmen mit sauberen Tabellen und fragilen KI-Systemen haben. Wenn sie als Skelett gelesen wird, um das herum eine echte Praxis aufgebaut wird, werden wir etwas Nützliches haben.

Eine schon gesehene Bahn

All dies gesagt, verdient die Veröffentlichung der Norm es, ernst genommen zu werden. Aus einem Grund, der wenig mit Technik zu tun hat, und viel mit dem Timing des regulierten Marktes. Das Schema, in Italien, haben wir schon gesehen. Die italienische Cloud-Italia-Strategie von 2021 hat einen Rahmen für die Klassifizierung von Daten und Diensten für die öffentliche Verwaltung erzeugt. Dieser Rahmen wurde dann zwischen 2022 und 2023 zur Verordnung der italienischen Cybersicherheitsbehörde. Der Katalog der qualifizierten Cloud-Dienste fand schließlich Eingang in die Beschaffungsverfahren der PA, bis hin zu Consip MEPA, der italienischen Zentrale-Einkaufsplattform. Die anfangs vagen Klauseln zur Sicherheit der Cloud-Dienste wurden zu überprüfbaren technischen Anforderungen und Teilnahmebedingungen. Wer später kam, hat als generischer Anbieter gegen schon qualifizierte angetreten und bedeutende Ausschreibungen verloren. Die UNI 11621-8 folgt, angewendet im Rahmen des AI Acts, einer analogen Bahn. Die Norm startet als freiwillige Referenz und endet in den Ausschreibungsunterlagen. Der Durchgang durch die Leitlinien des Departements ist fast ein administratives Detail. Das nützliche Fenster öffnet sich jetzt, und schließt sich, wenn die erste bedeutende Ausschreibung die Norm zitiert.

In einem Multi-Framework-Compliance-Kit

Für jene, die wie wir bei Oltrematica Multi-Framework-Compliance machen, ist die Norm vor allem ein Werkzeug für vertretbare Dokumentation. Die RACI-Matrix eines KI-Hochrisikoprojekts, gebaut auf den UNI-Profilen, wird zu einem Nachweis, der im Audit standhält. Der interne betriebliche Schulungsplan, auf die Profile abgebildet, hört auf, ein administrativer Kostenpunkt zu sein, und wird zum integralen Bestandteil des KI-Risikomanagementprogramms. Die Form, die wir unseren internen Dokumentenkits geben, nimmt die Norm mühelos auf, weil sie dieselbe Sprache spricht wie die Frameworks, die wir bereits nutzen, von der DSGVO bis zum Cyber Resilience Act.

Eine unvollkommene Karte, aber eine Karte

Es gibt eine Arbeitslinie, die interessanter ist als reine Konformität, und wahrscheinlich kurzfristig weniger lukrativ. Die Norm ist eine Gelegenheit zu interner Verständlichkeit. Sie erlaubt Organisationen, die KI einführen, mit einem geteilten Vokabular darüber zu sprechen, noch bevor sie mit Regulatoren oder Zertifizierungsstellen sprechen. Es ist ein unvollkommenes Vokabular, teils datiert und um erkennbare wirtschaftliche Interessen herum gebaut. Aber es ist das erste verfügbare Vokabular, und seine Unvollkommenheit ist geringer als sein Nutzen. Die eigentliche Frage, die entscheiden wird, ob die UNI 11621-8 eine gute oder eine schlechte Norm ist, steht nicht im Text. Sie wird in den kommenden Monaten geschrieben, in den Auslegungen, die Organisationen ihr geben werden, und in den Ausschreibungen, die sie nutzen werden, um Anbieter zu filtern.

In der Zwischenzeit, lohnt es sich, sie für das zu lesen, was sie ist. Eine unvollkommene Karte des Territoriums, das wir schon durchqueren, das wenigstens eine geteilte Toponymie vorschlägt, damit wir uns nicht alle auf dieselbe Weise verlieren.

Acht Uhr abends, mehr oder weniger. Das Abendessen ist eben zu Ende, das Geschirr im Spülbecken, der Tisch noch abzuräumen. Mein Sohn ist drei Jahre alt und versucht, mich zu überzeugen, ihm das Tablet noch ein bisschen länger zu lassen, was in seiner Zeitgrammatik einen Zeitraum zwischen zwanzig Minuten und der Unendlichkeit bedeutet. Ich sage nein. Nicht mit Wut, nicht mit pädagogischem Vortrag. Ich sage nein mit der präzisen Müdigkeit dessen, der dieselbe Szene jeden Abend wiederholt und weiß, dass die nächste gleich sein wird.

Bis hierhin ist es eine Szene, die jedes Elternteil wiedererkennt. Sie könnte in jedem Haus geschehen.

Ich weiß, wie dieses Tablet funktioniert

Der Unterschied ist der Grund, weshalb ich nein sage. Es liegt nicht daran, dass ich einen alarmierenden Artikel über Bildschirme gelesen habe, oder weil ich auf Instagram einem Kinderarzt folge, der Digital Detox empfiehlt, oder weil man zu meiner Zeit draußen gespielt hat. Der Grund ist, dass ich weiß, wie dieses Tablet funktioniert. Nicht im allgemeinen Sinn, nicht „die Technologie schadet den Kindern”. Ich weiß es im technischen Sinn. Ich weiß, wie die Software gebaut ist, die darauf läuft. Ich weiß, welche Designentscheidungen die Personen getroffen haben, die es gebaut haben, und ich weiß, warum sie sie getroffen haben. Ich weiß, was geschieht, wenn mein Sohn den Bildschirm berührt, welche Logik entscheidet, was ihm danach gezeigt wird, und welches Ziel diese Logik zu erreichen versucht. Dieses Ziel ist nicht sein Wohlergehen.

Das weiß ich, weil es mein Beruf ist. Ich baue Software seit fast zwanzig Jahren. Ich arbeite nicht für die großen sozialen Plattformen, ich hatte nie ein Büro in Menlo Park oder in Mountain View. Ich mache viel langweiligere Dinge: ERP-Systeme, Plattformen für die Ausbildung, Anwendungen, die Unternehmen helfen, Daten zu organisieren. Zeug, das niemals in einer journalistischen Recherche landen würde, weil es nicht interessant genug ist.

Man könnte einwenden, dass mich das Problem dann nicht betrifft, dass die Techniken zur Aufmerksamkeitserfassung Sache von TikTok, Meta, ByteDance sind, und dass zwischen einer sozialen Plattform und einem ERP-System der Unterschied besteht, der zwischen einer Formel-1-Strecke und einer Landstraße liegt. Es wäre ein vernünftiger Einwand, wenn er nicht falsch wäre. Die Techniken, um Menschen an einen Bildschirm zu kleben, sind kein Industriegeheimnis. Sie sind eine geteilte, dokumentierte, in den Konferenzen, die ich besuche, gelehrte Disziplin, in den Slack-Kanälen diskutiert, in denen ich meine Arbeitstage verbringe. Sie sind gemeinsames Erbe jedes Menschen, der digitale Produkte baut. Die Hebel, die TikTok einsetzt, um einen Fünfzehnjährigen am Bildschirm festzuhalten, sind enge Verwandte der Hebel, die ich nutzen würde, um einem Kunden zu helfen, die mittlere Sitzungszeit auf einer betrieblichen Lernplattform zu erhöhen. Der Kontext ändert sich, die Intensität ändert sich, der Nutzertyp ändert sich. Die Grundwerkzeuge heißen gleich, werden in denselben Konferenzen gelehrt, finden sich in denselben Designbüchern wieder.

Abends, zu Hause, lese ich den Grundriss des Tablets meines Sohnes, wie man den Plan eines Gebäudes liest: das dient dazu, jenes dient dazu, hier drängt dich das Design in diese Richtung, dort hindert es dich, in jene andere zu gehen. Morgens arbeite ich mit denselben Werkzeugen jener, die diesen Grundriss gezeichnet haben. Aus dieser Bruchlinie entsteht ein Buch, das ich geschrieben habe und das ich kostenlos verfügbar zu machen beschlossen habe. Es heißt I tuoi figli non sono i tuoi utenti (Eure Kinder sind nicht eure Nutzer) und versucht, eine sehr bestimmte Sache zu tun: ein Stück professionelles Wissen an jene weiterzugeben, die dieses Wissen nicht haben, weil der Unterschied zwischen es zu haben und es nicht zu haben, wenn es um die eigenen Kinder geht, riesig ist.

Skinner, die Taube, der Feed

Um eine Vorstellung davon zu geben, von welcher Art Wissen wir sprechen, nehme ich nur ein Beispiel unter vielen, jenes, das meiner Ansicht nach das wichtigste und das am wenigsten bekannte ist. Zwischen den vierziger und fünfziger Jahren führte der Psychologe B. F. Skinner eine Reihe von Experimenten mit Tauben in einem Käfig durch. Wenn die Taube eine Scheibe mit dem Schnabel pickte, erhielt sie Futter. Skinner entdeckte etwas Interessantes: Wenn das Futter jedes Mal kam, wenn die Scheibe gepickt wurde, pickte sie die Taube nur, wenn sie Hunger hatte. Wenn das Futter dagegen unvorhersehbar kam, alle drei, alle fünf, alle zwei Male, begann die Taube, die Scheibe ununterbrochen zu picken, in zwanghafter Weise, auch wenn sie keinen Hunger hatte. Die variable Belohnung, jener Mechanismus, ist der psychologische Motor der Spielautomaten. Er ist auch der psychologische Motor des Feeds eines sozialen Netzwerks, und nicht aus poetischer Analogie, sondern durch ausdrückliche Gestaltung.

Wenn euer Sohn zwanzig Minuten lang Instagram scrollt, ist der Großteil der Inhalte, die er sieht, banal, unbedeutend, vergessbar. Ab und zu jedoch kommt etwas Gutes, etwas, das ihn zum Lachen bringt, eine Nachricht, die ihn interessiert, ein Foto, das ihn betrifft. Er weiß nicht, wann es kommen wird. Er weiß nur, dass es früher oder später kommt, wenn er weiterscrollt. Sein Gehirn macht, in eleganter und digitaler Version, genau das, was die Taube von Skinner machte.

Personalisiertes Random

Es gibt einen wichtigen Unterschied, der die Sache verschlimmert und den, wer nicht in der Branche arbeitet, gewöhnlich nicht berücksichtigt. Die Spielautomaten in den Spielhallen verteilen die Gewinne zufällig, weil sie nichts über den Spieler wissen. Der Algorithmus eines sozialen Netzwerks weiß, was ihr mögt, worauf ihr eine Sekunde länger verweilt, was euch empört, was euch rührt. Er nutzt diese Informationen, um die Inhaltsverteilung so zu kalibrieren, dass die Wirkung der variablen Verstärkung speziell auf euch maximiert wird. Es ist nicht mehr Random, es ist personalisiertes Random, paradoxerweise wirksamer als reiner Zufall, weil es die Unvorhersehbarkeit aufrechterhält (ihr wisst nicht, wann der gute Inhalt kommt) und die Relevanz hinzufügt (wenn er kommt, ist er auf eure Interessen kalibriert). Für ein jugendliches Gehirn, dessen präfrontaler Kortex noch im Aufbau ist, ist dieser Mechanismus besonders mächtig.

Die anderen Mechanismen

Die variable Belohnung ist einer der Mechanismen, die das Buch beschreibt. Es gibt andere: das endlose Scrollen, das die Entscheidungspunkte beseitigt, das Autoplay, das das „weitergucken” zur Voreinstellung macht, die Benachrichtigungen, kalibriert, um eine unwillkürliche körperliche Reaktion zu erzeugen, die Dark Patterns, die das Anmelden einfach und das Aussteigen schwierig machen. Sie sind alle dokumentiert, alle gelehrt, alle ohne Altersunterschied auch auf jene Produkte angewendet, die euer Sohn auf dem Telefon hat. An all dem ist nichts Klandestines. Es ist offene Literatur, jedem zugänglich, der sie lesen will. Das Problem ist, dass jene, die sie lesen, fast immer jene sind, die diese Produkte bauen, selten jene, die sie erleiden.

Was die Entwickler wissen, und was sie mit den eigenen Kindern tun

Daraus entsteht die Frage, die dem Buch den Titel gibt und die einfachste ist, die ich zu der ganzen Sache kenne. Die Privatschulen im Silicon Valley, die Bildschirme im Klassenzimmer verbieten, sind keine Stadtlegende. Tim Cook, Apple-CEO, hat öffentlich erklärt, dass er seinem Neffen nicht erlauben würde, soziale Medien zu nutzen. Sean Parker, erster Präsident von Facebook, hat das Design der Plattform als bewusst darauf ausgerichtet beschrieben, eine Schwachstelle der menschlichen Psychologie auszunutzen, und hinzugefügt, nur Gott wisse, was es mit dem Gehirn unserer Kinder anstelle. Chamath Palihapitiya, ehemaliger Vizepräsident für Nutzerwachstum bei Facebook, hat öffentlich gesagt, dass seine Kinder dieses Zeug nicht benutzen durften. Die Zeugnisse von Insidern, die zugeben, die eigenen Kinder vor den Produkten zu schützen, an deren Bau sie beigetragen haben, sind nicht versteckt, sie sind nicht zweideutig, sie sind nicht spärlich. Es genügt, sie zu suchen.

Die Beobachtung, die ich im Buch mache, und die ich auch hier mache, ist kleiner und gewöhnlicher als diese berühmten Erklärungen. Unter den Kollegen, die in der Software arbeiten, mit denen ich regelmäßig spreche, sind jene mit Kindern in einer Sache fast einstimmig: restriktivere Regeln zur Telefonnutzung als der Durchschnitt der non-tech Eltern, verzögerter Zugang zu sozialen Medien, aufmerksame Kontrolle, welche Apps installiert werden, Gespräche mit den Kindern darüber, wie die Benachrichtigungen funktionieren und warum. Es ist kein wissenschaftliches Datum, es ist eine anekdotische Beobachtung. Aber sie ist kohärent, sie ist wiederkehrend, und ihre bloße Existenz beweist den Punkt: Wer den Mechanismus kennt, verhält sich anders.

Wenn die Personen, die diese Dinge bauen, die eigenen Kinder davon fernhalten, was wissen sie und wir nicht?

Informationelle Asymmetrie, und das Buch

Es ist keine rhetorische Frage. Es gibt keinen geheimen Raum, in dem die Tech-Führungskräfte planen, wie sie den Kindern der Welt schaden. Es gibt etwas viel Banaleres und viel Schwieriger zu Bekämpfendes, das die Ökonomen informationelle Asymmetrie nennen. Auf der einen Seite stehen jene, die verstehen, wie die digitalen Produkte funktionieren, wie sie entworfen sind, welche psychologischen Hebel sie verwenden und warum. Auf der anderen Seite stehen jene, die sie benutzen und sie ihre Kinder benutzen lassen, ohne diese Informationen zu haben. Diese Asymmetrie existiert, seit es Industrien gibt. Die Chemiker der Lebensmittelunternehmen wissen Dinge über das Essen, die die Verbraucher nicht wissen. Die Automobilingenieure wissen Dinge über Autos, die die Fahrer nicht wissen. Der Unterschied ist, dass in jenen Branchen mit der Zeit ein System aus Etiketten, Sicherheitsstandards, Transparenzpflichten gebaut wurde. Für die digitalen Produkte ist jenes System weitgehend noch zu bauen, und in der Zwischenzeit verbringen unsere Kinder dort Stunden jeden Tag.

Das Buch versucht, jene Lücke zu schließen. Nicht ganz, das wäre ein übertriebener Anspruch. Einen Teil. Es erklärt, wie die wichtigsten Mechanismen funktionieren, in einer Sprache, die keine technischen Kompetenzen erfordert, erzählt, was wir über die Wirkungen auf unsere Kinder wissen und was wir noch zu verstehen versuchen, und versucht zu skizzieren, was jeder in seiner Rolle tun kann: als Eltern, als Bürger, als Nutzer und auch, für jene, die wie ich in der Branche arbeiten, als Personen, die dieses Zeug bauen. Es ist kein Handbuch zum elterlichen Überleben, und es ist kein Buch gegen die Technologie. Es ist ein Versuch, einen kleinen Teil professionellen Wissens an jene weiterzugeben, die es normalerweise nicht erhalten.

Das Buch ist kostenlos, in epub und pdf, und ist auf ebook.margiovanni.it zu finden. Wenn ihr es lest und es euch nützlich ist, bitte ich euch nur darum, es einem anderen Elternteil weiterzugeben. Jene Weitergabe zwischen zwei Personen, die einander kennen, ist mehr wert als jeder Empfehlungsalgorithmus, und ist genau die Art von Sache, die die Mechanismen, von denen das Buch spricht, nicht zu tun vermögen.

Ein großer Kunde aus einem regulierten Sektor hat uns vor einigen Monaten gebeten, die Plattform abzusichern. Die Anfrage war in den üblichen Begriffen formuliert: IT-Sicherheit und Compliance-Audit. Was sie am Ende mitnahmen, war ein DPA Anhang 2, gegliedert in neunzehn Abschnitte, eine technische Gap-Analyse, eine Remediation-Roadmap, eine Formalisierung der Kette der Unterauftragsverarbeiter, geschrieben, um einer ernsten Prüfung standzuhalten. Es gab keine einzige neue Codezeile in dem, was wir geliefert haben, und auch keine Plattform zu lizenzieren. Strukturiertes Papier und vertragliche Positionierung, so produziert, dass sie verteidigungsfähig waren vor wem auch immer kommt, um Rechenschaft zu verlangen. Das Interessante ist, dass dies keine Ausnahme war, sondern die Regel, die sich in unseren letzten zwölf Monaten Arbeit etabliert hat.

Jemand könnte einwenden, dass die Karte dieses Marktes bereits existiert und es genüge, den Magic Quadrant von Gartner für GRC-Tools zu lesen oder die Forrester-Berichte über Privacy-Management-Plattformen zu konsultieren. Das wäre eine bequeme und teilweise irreführende Abkürzung. Diese Dokumente fotografieren den globalen Markt der Plattformen, in dem ServiceNow, MetricStream, OneTrust, Drata und Optro stehen — letzteres hat im vergangenen März AuditBoard umbenannt. Der italienische Compliance-Markt hingegen hat eine eigene Struktur, geformt von ACN, der italienischen Agentur für nationale Cybersicherheit, von der Umsetzung der NIS2 mit dem decreto legislativo 138/2024 (der italienischen Umsetzung der NIS2-Richtlinie), vom dominanten Gewicht der öffentlichen Verwaltung am Gesamtbeschaffungsvolumen, von der ungleichmäßigen Geschwindigkeit, mit der die europäischen Richtlinien bei den Endkunden operativ werden. Um ihn zu lesen, braucht es eine Karte, die von innen gezeichnet ist.

Oben: die spezialisierte Beratung

Es scheint mir nützlich, ihn als Sanduhr zu betrachten. Oben hat sich eine dichte Schicht spezialisierter Beratung gebildet. Die Big4 — Deloitte, PwC, EY, KPMG — haben GRC-Praktiken, die in den kommerziellen Angeboten mittlerweile ununterscheidbar sind und die sich eher über die Namen der Senior Partner als über die Methodologien Konkurrenz machen. Daneben — und in einigen Fällen auf qualitativ höherem Niveau — operieren die strukturierten italienischen Boutiquen. P4I aus der Digital360-Gruppe gibt auf der eigenen Website über hundertsechzig Fachleute an und verkauft ein methodisches Brand namens Advisory Engine, mit einem als Compliance360 registrierten Katalogprodukt. ICTLC hat den Legal-Tech-Zuschnitt konsolidiert, der heute in Mode ist; als sie damit anfingen, war er es nicht. Spike Reply operiert innerhalb der Reply-Gruppe und behält dabei eine erkennbare Identität; sie deckt das gesamte Spektrum von Cybersecurity und Datenschutz ab, mit einem signifikanten Gewicht auf Financial- und Manufacturing-Dossiers. Deda Tech hat den Weg des multidisziplinären Teams gewählt, in dem Juristen und Ökonomen neben Ingenieuren sitzen, und in öffentlichen Interviews erklären sie offen, keine technischen Lösungen zu verkaufen, sondern Vertrauen. Der Satz klingt wie Marketing und entspricht der realen Positionierung.

Was diese Akteure verkaufen, ist Interpretation. Keine Software, die etwas tut, sondern eine erkennbare Person, fähig, eine Norm in die spezifischen Begriffe deiner Lieferkette zu übersetzen und den Verhandlungstisch über ein Data Processing Agreement mit einem amerikanischen Cloud-Provider zu halten, ohne preiszugeben, was nicht preiszugeben ist. Die Margen sind hoch, die Skalierbarkeit ist niedrig. Die Abhängigkeit vom einzelnen Namen mit dem grauen Bart oder dem akademischen Lebenslauf ist strukturell für das Modell. Wachstum geschieht durch Kooptation, durch Hiring gewichtiger Namen, durch Akquisitionen kleinerer Kanzleien, die konsolidierte Kundenportfolios mitbringen. Es ist ein Mechanismus, der mehr der Welt der Anwaltschaft ähnelt als der Welt der Software.

Unten: die Plattformen

Unten hat sich die Schicht der Plattformen gebildet. Die Projektionen von IntelMarket Research bewerten den globalen Markt der GRC-Plattformen 2024 mit 16,7 Milliarden Dollar, mit Horizont 2032 bei 32,8 Milliarden und einer kumulierten Wachstumsrate von 9,9 %; andere Schätzungen geben merklich abweichende Zahlen, je nach einbezogenem Perimeter, aber die Richtung ist klar. ServiceNow GRC ist der Default für jene, die ServiceNow bereits für das IT-Service-Management einsetzen, und das ist ein signifikanter Anteil der italienischen Enterprise-Welt. MetricStream deckt das Segment der Multinationals mit reifen GRC-Programmen ab. OneTrust hat die DSGVO in ein Produkt verwandelt und positioniert sich nun auf AI Governance neu. Drata und Vanta automatisieren SOC2 und ISO 27001 für Startups und Scale-ups, mit kontinuierlich gesammelter Evidenz und SaaS-Preisen, die in das Budget eines CTO passen, ohne dass dieser zum CFO gehen müsste. Der italienische Anteil dieser Schicht ist dünn. Der italienische Markt für Compliance-Software hat keine international skalierten Akteure hervorgebracht, und die lokalen Versuche bleiben auf einzelne Vertikalen oder einzelne Kunden beschränkt.

Das eingeklemmte Middle Layer

Zwischen diesen beiden Schichten, dort wo die Sanduhr sich verengt, befindet sich das Middle Layer, und hier liegt die interessante Dynamik. Es ist die Schicht der Custom-Software für Compliance, der maßgeschneiderten DSGVO-Anwendungen, der vertikalen Plattformen für ISO 27001, entwickelt von mittelgroßen italienischen Softwarehäusern. Jahrelang war es eine bequeme Schicht. Der Kunde traute den amerikanischen Plattformen aus Gründen der Datensouveränität nicht, die Big4 waren für den Mid-Market zu teuer, und ein lokales Softwarehaus, das ein gebrandetes DSGVO-Portal lieferte, war die natürliche Lösung. Heute wird diese Schicht von beiden Seiten gleichzeitig zusammengedrückt. Von unten, weil Drata SOC2 zu einem Bruchteil der Kosten einer maßgeschneiderten Anwendung leistet, und Startups keinen Grund haben, sich für eine Commodity-Funktion etwas Proprietäres entwickeln zu lassen. Von oben, weil bei ernsten Problemen — einer verteidigungsfähigen DPIA oder einer Vertragsverhandlung mit Microsoft, die keine Lücken lässt — der Kunde versteht, dass Software nicht ausreicht und dass er eine Person braucht, die seine Sprache spricht und Dokumente unterschreibt, die einer Prüfung standhalten.

ACN und der Markt im Markt

Was die italienische Karte strukturell von der globalen unterscheidet, ist ACN. Das Regolamento unico per le infrastrutture digitali e i servizi cloud (das einheitliche italienische Regelwerk für digitale Infrastrukturen und Cloud-Dienste) — decreto direttoriale 21007 vom 27. Juni 2024, im Regelbetrieb seit dem 1. August desselben Jahres — hat einen Markt im Markt geschaffen. Die öffentliche Verwaltung darf Cloud-Dienste nur dann beschaffen, wenn sie als QC1, QC2, QC3 oder QC4 qualifiziert sind, erbracht auf Infrastrukturen, die als AI1 bis AI4 angemessen sind, nach einer Matrix, die die Klassifizierung des Datums an das zulässige Service-Niveau bindet. Aruba hat auf den höchsten Stufen qualifiziert, Polo Strategico Nazionale verwaltet die als strategisch klassifizierten Daten, eine Handvoll weiterer Anbieter füllt die übrigen Felder des Katalogs. Für italienische Systemintegratoren, die mit der öffentlichen Verwaltung arbeiten, wird die konkrete Wahl binär. Entweder verkauft man den qualifizierten Cloud eines anderen weiter und akzeptiert komprimierte Margen und eine Implementer-Rolle, oder man baut eine Beratung auf, die den PA-Kunden in der architektonischen Wahl orientiert und das Wissen über den qualifizierten Katalog als unterscheidendes Asset kapitalisiert. Als ich für Pescara Multiservice das Angebot für ACN-qualifiziertes Cloud-Hosting auf Basis von Aruba VPC auf der Stufe QC3 vorbereitet habe, gegen die reale Listenposition ARB-11504-1 zu 217,38 € im Monat, war der Wertanteil, den der Kunde kaufte, meine Übersetzungsarbeit zwischen seinen Anwendungsanforderungen und den Vorgaben des Katalogs. Die Infrastruktur war Commodity. Die Interpretation war es nicht.

Was die Systemintegratoren tun

An diesem Punkt versteht man, was den italienischen Systemintegratoren passiert und warum. Die großen — Reply, Engineering, Almaviva, NTT Data Italia, Accenture — haben bereits interne GRC-Praktiken, die direkt mit den Big4 konkurrieren, und in einigen Fällen haben sie diese bei öffentlichen Aufträgen überholt. Spike Reply ist das kanonische Beispiel dieser Bewegung, aber nicht das einzige. Die mittleren — Deda Tech, Var Group, Lutech — bauen multidisziplinäre Teams auf und verkaufen ihre Identität als trusted advisor mit einer neuen Sprache. Der Implementierungsumsatz bleibt signifikant, aber die hohen Margen finden sich dort, wo man Tage der Interpretation verkauft und nicht Entwicklungs-Sprints. Die kleinen stehen vor einer engeren Wahl. Sie können Reseller eines anderen werden und ihre Identität verlieren. Sie können spezialisierte Implementer auf einer Vertikalen bleiben, wo die Tiefe der Domäne den fehlenden Maßstab kompensiert. Es gibt dann einen dritten Weg, riskanter als die anderen, nämlich sich in eine Advisory-Boutique zu verwandeln und Wissen vor und Implementierung nach zu verkaufen, indem man auf einen Teil des sicheren Umsatzes verzichtet und dafür eine noch unsichere Positionierung eintauscht. Die meisten wählen nicht, sondern empfangen die Marktbewegung passiv. Bei Oltrematica haben wir die Wahl vertikal getroffen — private Gesundheitsversorgung und lokale öffentliche Verwaltung —, mit einer ernsthaften Investition in die Compliance-Dokumentation als Produkt. Jener DPA, die fünfstufige Formalisierung einer Unterauftragsverarbeiter-Kette, die drei Gesellschaften derselben Industriegruppe durchquert, die Analyse des neuen DPIA-Templates, das der EDPB am 10. März verabschiedet und am 14. April zur Konsultation bis zum 9. Juni veröffentlicht hat — das sind alles Arbeitsstücke, die wir vor fünf Jahren als Beigabe zum Hauptprojekt erledigt hätten. Heute sind sie das Hauptprojekt, und die Software kommt danach, falls sie überhaupt kommt.

Wohin der Wert wandert, und was ich von 2027-28 nicht weiß

Es gibt eine Konsequenz aus all dem, die es wert ist, ausdrücklich gemacht zu werden. Der Wert im italienischen Compliance-Markt wandert an die beiden Enden der Sanduhr. Die internationalen Plattformen drücken die Kosten der Evidenz nach unten, und dieser Druck wird nicht aufhören, weil ihr Geschäftsmodell von der fortschreitenden Automatisierung abhängt. Die Advisory-Boutiquen und die GRC-Praktiken der großen Systemintegratoren drücken den Preis der Interpretation nach oben, und es gibt am Horizont keine technologische Innovation, die die Kosten einer von einem erkennbaren Namen unterschriebenen Stellungnahme reduzieren würde. Was in der Mitte bleibt — die Custom-Software für Compliance — steht vor einer Gabelung. Sie kann sich innerhalb einer Vertikalen so weit spezialisieren, dass sie nicht mehr durch Generalisten-Plattformen ersetzbar ist, oder sie kann in ein Advisory-Angebot als Capability statt als eigenständiges Produkt absorbiert werden. Die Daten des Politecnico di Milano, die das italienische Cyber- und Datenschutzsegment 2025 auf 2,78 Milliarden Euro mit 12 % Wachstum schätzen, unterscheiden in ihren Erhebungen diese Schichten nicht, und das ist wahrscheinlich einer der Gründe, warum die Unternehmen des Middle Layers die Zahlen weiterhin als gute Nachrichten lesen, während sie etwas Subtileres sagen.

Der ehrlichste Satz, den ich über die Konfiguration dieses Marktes in den Jahren 2027 und 2028 schreiben kann, wenn der Cyber Resilience Act operativ und der AI Act in voller Durchsetzung sein wird, ist, dass ich es nicht weiß. Es scheint mir plausibel, dass sich ein neu konfiguriertes Middle Layer bildet, in dem Werkzeuge wie Claude Code, GitHub SpecKit und ihre Ableger es Softwarehäusern wie unserem erlauben werden, Compliance-Artefakte als Code zu produzieren — versioniert, getestet, aus formalen, nachvollziehbaren Spezifikationen erzeugt. Es ist eine Richtung, in die ich persönlich investiere und über die ich hier seit mehreren Monaten schreibe. Aber es ist auch möglich, dass das Middle Layer ganz kollabiert und dass sich der italienische Markt auf zwei Seiten polarisiert, wie es in anderen reifen Märkten vor unserem geschehen ist. In zwölf Monaten wird diese Karte neu zu zeichnen sein. Es wird eine der Übungen sein, die ich vornehmen werde.

Ein Gespenst geht um in Europa, und ausnahmsweise ist es nicht das von Marx imaginierte. Es ist ein eigentümlicheres Gespenst, denn es geht nicht unter uns um, die wir Europa bewohnen. Es geht unter denen um, die uns von außen beobachten, von der anderen Seite des Ozeans, und die uns ansehen, wie man einen exzentrischen Verwandten beim Weihnachtsessen ansieht: jemanden, mit dem zu interagieren man verpflichtet ist, den man im Grunde gerne loswerden würde, der aber hartnäckig fortfährt zu existieren und über seltsame Dinge zu sprechen wie Würde der Arbeit, Barrierefreiheit, Schutz von Minderjährigen, Produkthaftung. Das Gespenst sind wir. Oder besser: Es ist das, was wir hier in Sachen Digitalregulierung tun, eine Reihe von Akronymen, die in Brüssel als ordentliche technische Arbeit gelten und die in San Francisco als Bedrohung von beinahe existenzieller Natur empfunden werden.

Von außen gesehen, und insbesondere von einem ganz bestimmten Teil der Welt aus gesehen, der sich in den letzten Jahren stark zu Wort gemeldet hat, ist Europa zu einer Figur geworden. Nicht mehr ein wirtschaftliches Subjekt, keine politische Union, mittlerweile nicht einmal mehr der Kontinent der Hunderten von Millionen Menschen, die ihn bewohnen. Es ist ein Meme. Ein Meme mit einer präzisen narrativen Funktion: zu verkörpern, was die Zukunft nicht sein darf. Die Bürokratie des neunzehnten Jahrhunderts, aufgeklebt auf das einundzwanzigste. Die alte Welt, die die neue ausbremst. Das Freilichtmuseum, das den Anspruch erhebt, der Fabrik von morgen Regeln zu diktieren. Es ist eine Karikatur, natürlich, aber eine wirksame Karikatur, denn sie funktioniert innerhalb einer Geschichte, die viel größer ist als sie selbst, und diese Geschichte ist der Kulturkampf, den ein Teil des amerikanischen Kapitalismus gegen die Idee selbst führt, dass Software Gegenstand von Normen sein könne.

Die DSGVO und das Banner, das sie zusammenfasst

Um zu verstehen, wo wir heute stehen, ist es nützlich, ein wenig zurückzugehen. Der Moment, in dem das Verhältnis zwischen Silicon Valley und europäischer Regulierung in einer schwer zu kittenden Weise gerissen ist, ist die DSGVO. Eine Verordnung von 2016, anwendbar seit 2018, technisch nicht revolutionär, in weiten Teilen inspiriert von Prinzipien, die bereits in der Konvention 108 und in der Richtlinie 95/46 existierten. Und doch hat die DSGVO in der Praxis erklärt, dass bestimmte Geschäftsmodelle, die auf der wahllosen Sammlung personenbezogener Daten beruhen, irgendwann mit etwas würden Rechnung tragen müssen. Es ist kein Zufall, dass die DSGVO zum symbolischen Ziel par excellence der antieuropäischen Erzählung geworden ist, und es ist kein Zufall, dass die vorherrschende Art, sie anzugreifen, das Cookie-Banner ist.

Hier muss ich mein erstes Zugeständnis machen. Das Cookie-Banner, wie wir es erleben, ist ein Scheitern. Es ist ein Scheitern aus Sicht des Nutzers, der es wegklickt, ohne zu lesen. Es ist ein Scheitern aus Sicht des effektiven Schutzes, weil jene Einwilligung fast immer fiktiv ist. Es ist ein Scheitern aus Sicht des Interface-Designers, der akzeptieren muss, dass jede europäische Website mit einer digitalen Zollschranke öffnet, die niemand will. Es ist das klassische Beispiel einer auf der Prinzipienebene korrekten Norm, die sich auf der Anwendungsebene auf groteske Weise entladen hat, weil der Gesetzgeber annahm, die Einwilligung sei ein Akt souveränen Willens eines rationalen Subjekts, und die Designer digitaler Produkte wussten sehr gut, dass es genügte, das Banner auf eine bestimmte Weise zu gestalten, um es in einer halben Sekunde wegklicken zu lassen. Das Dark Pattern hat die Theorie der freien, spezifischen, informierten und unmissverständlichen Einwilligung aufgefressen. Man sieht es jeden Tag. Es ist ein reales Problem. Wer es kritisiert, hat in diesem spezifischen Punkt recht.

Aber hier beginnt die Divergenz zwischen nützlicher Kritik und instrumenteller Kritik, denn wer im Cookie-Banner recht hat, diskutiert in Wirklichkeit nicht über das Cookie-Banner. Er benutzt das Cookie-Banner als Metonymie, um die Idee selbst anzugreifen, dass die Sammlung personenbezogener Daten ein regulierbares Problem sei. Er sagt im Grunde, wenn die Regel eine hässliche Anwendung produziert, dann sei die Regel abzuschaffen, und nicht die Anwendung zu korrigieren. Es ist ein alter rhetorischer Zug, und hier ist es nicht nötig, irgendjemanden zu bemühen, es genügt zu beobachten, dass wer die Abschaffung der DSGVO auf der Grundlage des Cookie-Banners vertritt, in der Regel nicht die Modifikation der technischen Einwilligungsnormen vertritt, was die kohärente Position wäre. Er vertritt die Rückkehr in eine Welt, in der amerikanische Plattformen mit unseren Daten machen, was sie wollen, ohne irgendjemandem etwas erklären zu müssen. Das Banner war ein Vorwand, kein Argument.

DSA, DMA und das Geschaeftsmodell

Dass es ein Vorwand war, hat man endgültig mit dem DSA und mit dem DMA verstanden. Als die Kommission begann, von den Gatekeepern zu verlangen, ihre Plattformen zu öffnen, bestimmte Dienste interoperabel zu machen, ihre eigenen Produkte in den Stores nicht zu bevorzugen, den Nutzern zu erlauben, vorinstallierte Anwendungen zu deinstallieren, verwandelte sich das Argument „ihr reguliert zu viel” ohne Übergang in das Argument „ihr greift unsere Unternehmen an”. Der Sprung ist interessant. Jahrelang hat man uns erklärt, das Problem sei das Übermaß an Normen, nicht die Identität dessen, der bezahlt. Seit die Normen operativ geworden sind, erklärt man uns, das Problem sei, dass sie nur die amerikanischen Champions treffen. Die beiden Thesen sind nicht kompatibel, aber sie leben bestens zusammen in derselben Argumentation, und das sollte schon Verdacht erregen, dass etwas nicht stimmt.

Es ist eine wichtige Sache zum DMA zu sagen. Die These, der DMA ziele spezifisch auf US-Unternehmen ab, ist faktisch schwach, denn unter den Gatekeepern figuriert auch ByteDance, und denn die Schwellen sind Schwellen. Ein europäisches Unternehmen, das die fünfundsiebzig Milliarden Marktkapitalisierung und die fünfundvierzig Millionen monatlichen Endnutzer erreichte, wäre auch Gatekeeper. Das Problem ist, dass europäische Unternehmen in dieser Bandbreite extrem selten sind, und der einzige jüngere Fall, Booking, operiert von Amsterdam aus, gehört aber zu einer US-Holding. Diese Abwesenheit hängt nicht vom DMA ab. Sie hängt von industriellen, steuerlichen, finanziellen und ausbildungspolitischen Entscheidungen der letzten vierzig Jahre ab, die der DMA nicht verursacht hat und die der DMA nicht lösen wird. Wenn wir über jenes Problem sprechen wollen, sprechen wir darüber, und sprechen wir ernsthaft, indem wir den Draghi-Bericht zitieren, falls wir einen aktuellen Anhaltspunkt brauchen, aber verwechseln wir es nicht mit der Plattformregulierung, denn das sind zwei Ebenen, die sich nur scheinbar berühren.

Das ist der Punkt, den derjenige, der uns von außen beobachtet, nicht sehen will, oder den er vielleicht sehr gut sieht und vorgibt, ihn nicht zu sehen. Die Plattformregulierung steht nicht in Konkurrenz zur Innovation. Sie steht in Konkurrenz zu einem spezifischen Geschäftsmodell, jenem der massiven Extraktion personenbezogener Daten, der Optimierung der Aufmerksamkeit bis an die Grenze der Sucht, der Eroberung benachbarter Märkte über die Hebelwirkung dominanter Stellung, der systematischen Abwälzung negativer Externalitäten auf den sozialen Körper. Es trifft sich, dass jenes Geschäftsmodell in den letzten zwanzig Jahren das vorherrschende Modell des amerikanischen Digitalkapitalismus war. Es trifft sich, dass die Unternehmen, die es praktiziert haben, heute die größten der Welt sind und ein offensichtliches Interesse daran haben, es weiter zu praktizieren. Wenn die Europäische Union sagt, dass jenes spezifische Modell Grenzen hat, trifft sie einen offenen Nerv, und nicht zufällig. Sie sagt, mehr oder weniger artikuliert, dass es eine andere Weise gibt, digitale Technologie zu betreiben. Das, im Jahr 2026, ist Häresie.

Von der Norm zum technischen Objekt

Ich verlasse für einen Moment die Analyse und erzähle eine konkrete Episode, denn ich glaube, es ist nützlich zu verstehen, von wo aus ich spreche. Ich arbeite seit mehreren Jahren in einer mittelgroßen italienischen ICT-Gesellschaft außerhalb der großen Ballungsräume, die Software für die öffentliche Verwaltung und das Gesundheitswesen herstellt. In den letzten zwei Jahren bestand meine Arbeit zum großen Teil aus einer einzigen Aufgabe: europäische Normen in technische Objekte zu übersetzen. Was bedeutet es, eine Gesundheitsplattform zu haben, die Artikel 28 DSGVO entspricht, wenn der Lieferant eines Lieferanten in Deutschland sitzt und das Gesundheitsdatum einen italienischen Bürger betrifft. Was bedeutet es für einen Schulungsträger, der gemäß Accordo Stato-Regioni — dem italienischen Vereinbarungsinstrument zwischen Staat und Regionen für die Pflichtschulungen am Arbeitsplatz — Kurse zur Arbeitssicherheit anbietet, den Cyber Resilience Act ankommen zu sehen und zu begreifen, dass das eigene LMS in den Anwendungsbereich fällt. Was bedeutet es für ein Softwarehaus, das eine Verwaltungsanwendung herstellt, sich darauf vorzubereiten, dass die überarbeitete Product Liability Directive das Produkthaftungsregime auch auf Software ausgedehnt hat, einschließlich bestimmter Formen integrierter KI-Komponenten, und dass das Regime operativ auf Produkte anwendbar sein wird, die nach Dezember 2026 in Verkehr gebracht werden. Was bedeutet es, eine DSFA nach dem im vergangenen März vom EDPB genehmigten Template zu entwerfen und festzustellen, dass es sich nicht um ein Formular handelt, sondern um ein dokumentarisches Genre, das gemeinsam mit dem System, das es beschreibt, am Leben gehalten werden muss. Es sind Übersetzungsarbeiten, keine Abstraktionen. Die Normen, die jenseits des Ozeans als Hindernisse für die Innovation gemalt werden, sind für mich die Innovation selbst, denn sie definieren das Perimeter, innerhalb dessen man gut entwerfen kann.

Ich sage das nicht aus romantischer Adhäsion an das europäische Projekt. Ich sage es, weil man, nach Dutzenden von Malen, in denen man diese Anforderungen in reale Systeme implementiert hat, eine Sache sieht, die man in einem Artikel von Andreessen nicht sieht. Man sieht, dass die Compliance kein isolierter Kostenpunkt ist, sondern ein gestalterischer Druck. Wie alle gestalterischen Drücke verengt sie den Raum der Entscheidungen und zwingt im Gegenzug dazu, die Dinge besser zu machen, zumindest innerhalb der Dimension, die die Norm schützt. Die PLD zum Beispiel verschiebt die Verantwortung des Herstellers für die Qualität der Software auf eine Weise, die bis gestern nicht einmal als Tatbestand existierte. Für den, der seriöse Produkte verkauft, ist das ein administrativer Ärger. Für den, der Schrott verkaufte und versprach, es sei Magie, ist es ein Erdbeben. Ratet, aus welcher der beiden Gruppen die virulenteste Kritik kommt.

Man könnte sagen, und es wird gesagt, dass dieses Argument für mein kleines italienisches Studio gilt, aber nicht für die Frontier der Technologie. Das italienische Studio erfindet keine Foundation Models, entwirft keine Gigawatt-Rechenzentren, definiert nicht das Paradigma der wissenschaftlichen Forschung neu. Wahr. Aber genau deswegen scheint mir mein Beobachtungspunkt nützlich, denn er erzählt aus großer Nähe von dem, was die großen kalifornischen Erzählungen nie zu sehen vermögen, nämlich dass die überwiegende Mehrheit der Software, die in der Welt läuft, keine Frontier ist, sondern Alltagsinfrastruktur. Es sind die Gesundheitssysteme, die unsere klinischen Daten verwalten, es sind die Portale der öffentlichen Verwaltung, die unsere Beziehungen zum Staat verwalten, es sind die ERPs, die kleine Unternehmen am Laufen halten, es sind die Schulungssysteme, die gesetzlich verpflichtende Kompetenzen zertifizieren. Es ist Gewebe. Die europäische Regulierung ist vor allem für dieses Gewebe geschrieben, und das Gewebe braucht per Definition Regeln, um als Gewebe zu existieren und nicht als zufällige Anhäufung von Fäden.

AI Act, Vance und das Rennen

Gehen wir weiter, denn es gibt ein anderes Thema, das es verdient, ernst genommen zu werden, und es ist der AI Act. Auch hier ist das Zugeständnis zu machen. Der AI Act ist eine schwierige Verordnung, geschrieben in einem historischen Moment, in dem die Technologie, die sie regulieren sollte, sich alle vier Wochen änderte. Sie hatte eine komplizierte Entstehung, hat im Lauf eine Wende erlitten, als die Foundation Models kamen, hat im endgültigen Text einige Asymmetrien zwischen Pflichten für Anbieter und Pflichten für Nutzer produziert, die die Akteure der Branche noch zu handhaben suchen. Es gibt Mehrdeutigkeiten in den Verhaltenskodizes für General-Purpose-Systeme. Es gibt Zweifel daran, wie die Rechenschwellen berechnet werden. Es gibt operative Schwierigkeiten in der Konformitätsbewertung für Hochrisiko-Anwendungen im Gesundheitswesen, und hier spreche ich aus direkter Erfahrung, denn Trustie, die Plattform, an der ich als CTO-as-a-Service für Umana Analytics arbeite, muss mit einigen dieser Zweifel zusammen mit der DSGVO und mit anderen Stücken europäischer Disziplin umgehen, die sich nicht immer linear überlagern.

Alles wahr. Alles richtig. Und genau deswegen ist der AI Act nicht das Ende der Welt. Es ist eine junge Norm in der Einlaufphase, die sich mit einem Sektor auseinandersetzt, der seinerseits jung und in der Einlaufphase ist. Die Anwendungsschwierigkeiten sind wechselseitig, weil die Technologie sich auf der Suche nach ihrem eigenen Raum befindet und die Norm sich auf der Suche nach ihrer eigenen Anwendung befindet. Das ist normal. Es ist mit jeder transformativen Technologie passiert, mit der industriellen Chemie zu Beginn des zwanzigsten Jahrhunderts, mit der nuklearen Sicherheit in der zweiten Hälfte, mit den Medizinprodukten in den Achtzigern, mit dem Finanzwesen nach Lehman. Neue Normen leben die ersten Jahre in einem Zustand der Iteration. Der Unterschied ist heute, dass die amerikanischen Akteure es als normal empfinden, wenn das Recht der Technologie hinterherläuft, während sie es als skandalös empfinden, wenn das Recht sich vorher aufstellt.

Der Skandal wird in beinahe religiösen Begriffen erzählt. Es ist nicht Regulierung, es ist Hyperregulierung. Es ist nicht Vorsicht, es ist Feigheit. Es ist nicht öffentliches Interesse, es ist als Recht verkleideter Sozialismus. Vance, in Paris, im vergangenen Jahr, hat eine Rede gehalten, die in den Schulbüchern bleibt, nicht wegen ihres Inhalts, sondern wegen ihres Tons. Er hat dem europäischen Publikum erklärt, dass wir die KI mit unseren Ängsten erwürgen, dass wir Gefangene unseres eigenen Garantismus seien, dass die Zukunft nicht warten werde. Es war eine Rede, gedacht, um in Vierzig-Sekunden-Clips geteilt zu werden. Sie funktionierte sehr gut zu diesem Zweck. Sie funktionierte weniger gut als Analyse einer Norm, die — erinnern wir uns — die Entwicklung der KI nicht verbietet, sondern sie nach Risikostufen artikuliert. Der konzeptuelle Rahmen des AI Act ist derselbe Rahmen, mit dem in jeder industriellen Zivilisation gefährliche chemische Stoffe, Arzneimittel, Automobile, für Kinder bestimmte Lebensmittel reguliert werden. Niemand verlangt von Vance, aufzuhören zu denken, Regulierung sei immer übertrieben, das ist eine legitime politische Position und hat ihre eigene Tradition. Nur sollte er sie als das präsentieren, was sie ist, und nicht als die neutrale Beobachtung eines neutralen Beobachters.

Es gibt ein Argument, das man oft hört und das mir eine Antwort zu verdienen scheint. Es ist das Argument des Rennens. Die KI ist ein Rennen, sagt man uns, und Europa verliert es. Während wir Verordnungen schreiben, baut China, bauen die Vereinigten Staaten, und in fünf Jahren werden wir irrelevant sein. Gut. Auch das gestehe ich teilweise zu. Auf der Ebene der Recheninfrastrukturen und der Verfügbarkeit von Risikokapital ist Europa tatsächlich im Hintertreffen, und es wird es lange bleiben, und das ist ein ernsthaftes Problem, das echte Industriepolitik erfordern würde, substantielle öffentliche Investitionen, Integration des europäischen Kapitalmarkts, Reformen der akademischen Arbeit, nichts, worüber wir seit Jahrzehnten ernsthaft diskutieren. Aber das Rennen, von welchem Rennen sprechen wir. Ein Rennen definiert sich durch das Ziel. Was ist das Ziel. Die eigene Version von OpenAI haben. Und dann. Die eigene Version von Meta haben. Und dann. Das heißt, Unternehmen zu haben, die was machen, von wem, um was zu erreichen, und was an wen verkaufen. Die Frage ist nicht müßig, denn die Unternehmen, die uns die Freunde von Vance als Modell vorschlagen, sind Unternehmen, deren Wert zu großen Teilen auf einer präzisen Annahme aufgebaut ist: dass man personenbezogene Daten mit minimalen Grenzen sammeln und nutzen kann, und dass man auf Aufmerksamkeit basierende Geschäftsmodelle ohne substantielle Beschränkungen beim Schutz Minderjähriger skalieren kann. Wenn Europa das sein will, das jenem Modell hinterherläuft und versucht, es zu replizieren, dann ja, verliert es. Wenn Europa das sein will, das eine Alternative vorschlägt, ist das Rennen ein anderes. Es wird auf einem anderen Terrain gespielt. Es wird mit anderen Regeln gewonnen. Und die Regulierung ist in diesem Fall keine Bremse. Sie ist das Produkt.

Brussels Effect und die normative Mauer der Stars and Stripes

Mir ist klar, dass dieser Satz anmaßend klingt, und teilweise ist er es. Aber er ist der Kern der Frage. Der Brussels Effect, von dem Anu Bradford seit mindestens einem Jahrzehnt spricht, ist keine rhetorische Erfindung. Er ist ein konkreter Mechanismus. Wenn die Europäische Union einen Standard festlegt, und wenn der europäische Markt groß genug ist, um nicht ignoriert zu werden, übernehmen die globalen Unternehmen am Ende jenen Standard als Default, weil zwei parallele Architekturen zu unterhalten teurer ist als eine. Die DSGVO ist seit Jahren ein informeller Default für das Design von Datenmanagementsystemen in global tätigen Unternehmen. Die europäischen Spezifikationen für Barrierefreiheit werden überall implementiert, weil derjenige, der nur ein Drittel seiner Produkte in Europa verkauft, ein einziges Interface entwirft. Der CRA wird einen ähnlichen Effekt auf Software produzieren. Die PLD wird einen ähnlichen Effekt auf die Produkthaftung produzieren. Der AI Act wird einen ähnlichen Effekt auf die Risikoklassifizierung automatisierter Systeme produzieren. Es ist keine umgekehrte koloniale Aufzwingung, es ist die ordentliche Funktionsweise des Marktes, und genau deswegen wütet sie die Techno-Optimisten so sehr, weil ihre Unternehmen gezwungen sind, sich an Regeln anzupassen, die sie nicht selbst geschrieben haben.

Dann gibt es das Argument der normativen Mauer. Europa, sagt man uns, baut eine normative Mauer, die amerikanische Anbieter ausschließt. Das ist ein Argument, das es verdient, wirklich ernst genommen zu werden, denn es hat einen wahren Teil und einen falschen Teil, und wer es benutzt, vermischt in der Regel beide. Der wahre Teil ist, dass einige Verordnungen, insbesondere der Data Act, bestimmte Bestimmungen zur koordinierten Cybersicherheit, gewisse Normen zu souveränen Clouds, tatsächlich eine industriepolitische Komponente haben, in dem Sinn, dass sie versuchen, die Entstehung eines europäischen Technologieangebots in kritischen Sektoren zu fördern. Das ist kein Geheimnis, es ist in den Erwägungsgründen geschrieben, und es ist eine legitime Tätigkeit, die alle Staaten und alle Wirtschaftsräume der Welt ausüben. China tut es offen, die Vereinigten Staaten tun es mit dem CHIPS Act und mit dem Inflation Reduction Act, mit der erneuerten Kontrolle ausländischer Investitionen, mit den Exportverboten für fortschrittliche GPUs. Das Neue ist nicht, dass Europa es tut. Das Neue ist, dass es es mit einer eigenen europäischen Spezifizität tut, die auf Anforderungen der Transparenz und der Accountability beruht, auf einer expliziten Sorge für die Grundrechte. Das ist in den Augen eines amerikanischen Investors aus dem Kreis von Andreessen Horowitz eine Anomalie. Es ist eine Anomalie in dem Maße, in dem der amerikanische Investor die regulatorische Tätigkeit an sich als politische Aberration betrachtet.

Der falsche Teil hingegen ist die Behauptung, die europäische normative Mauer unterscheide sich von jeder anderen normativen Mauer in der Welt. Versuchen Sie, medizinische Software ohne FDA in die Vereinigten Staaten zu exportieren. Versuchen Sie, einen Finanzdienst ohne SEC- oder FINRA-Zulassung an amerikanische Verbraucher zu verkaufen. Versuchen Sie, ein autonomes Fahrzeug auf Bundesebene zu betreiben, ohne sich mit der NHTSA auseinanderzusetzen. Versuchen Sie, Spielzeug für Kinder ohne CPSC zu verkaufen. Das amerikanische System ist voll von normativen Mauern, und jene Mauern sind seit Jahrzehnten dort, und sie funktionieren bestens als Markteintrittsbarrieren für ausländische Anbieter. Wenn ein europäisches Unternehmen ihre Last beklagt, ist die amerikanische Standardantwort: „Die Regeln sind die Regeln, wenn du hier verkaufen willst, passt du dich an.” Es ist genau dieselbe Antwort, die wir heute denen geben, die gegen den CRA protestieren, und sie hat genau dieselbe Legitimität. Nur dass wir sie aus einer Asymmetrie narrativer Macht heraus geben, die uns von vornherein auf die Seite des Unrechts stellt.

Die narrative Asymmetrie

Diese narrative Asymmetrie ist das eigentliche Gespenst, das in Europa umgeht. Nicht das Europa, das den anderen Angst macht. Das Europa, das vor sich selbst Angst hat, denn der einzig dominante Kulturrahmen des Tech-Sektors ist jener, der in Kalifornien in den letzten fünfundzwanzig Jahren ausgearbeitet wurde, und jener Rahmen betrachtet jeden regulatorischen Akt per Definition als Scheitern. Aus jenem Rahmen heraus ist jede unserer Normen ein Symptom des Verfalls. Jede unserer Richtlinien ist ein Zeichen der Stagnation. Jeder unserer Versuche, eine andere Vision der Beziehung zwischen Technologie und Bürgern zu artikulieren, wird zum Ressentiment dessen herabgestuft, der das Rennen verloren hat. Es ist ein sehr wirksamer Rahmen, und es ist sehr schwer, ihn von innen aus der europäischen Tech zu bestreiten, denn dieselbe europäische Tech hat sich oft an der amerikanischen Tech modelliert, liest deren Blogs, übernimmt deren Werkzeuge, absorbiert deren Vokabular und urteilt am Ende über den eigenen Kontinent mit den Augen eines anderen.

Ich gehe einen weiteren Schritt. Wenn ich sage, der kalifornische Rahmen sei hegemonial, betreibe ich keine Stammtisch-Soziologie. Ich beschreibe die Tatsache, dass in jeder europäischen Konferenz zum Digitalen, im Jahr 2026, ein großer Teil des technischen Lexikons, ein großer Teil der tugendhaften Beispiele, ein großer Teil des interpretativen Frames aus der amerikanischen Branchenliteratur stammt. Es ist eine Tatsache. Hier liegt das Problem, denn wenn der europäische Regulator versucht, eine Norm zu schreiben, muss er es in einem intellektuellen Umfeld tun, das von Akteuren bevölkert ist, die die gegnerische Grammatik verinnerlicht haben. Sie sind sich dessen nicht immer bewusst. Oft denken sie in gutem Glauben, „pragmatisch” zu sein, auf der Seite der „Fakten” zu stehen, „Hyperregulierung vermeiden” zu wollen. Aber sie benutzen ein anderswo gemachtes Vokabular zu fremden Zwecken und produzieren am Ende, auch von europäischen Positionen aus, eine implizite Verteidigung des Modells, das sie kritisieren möchten. Das Ergebnis ist, dass in den Korridoren von Brüssel progressive Verordnungen diskutiert werden, während in den Feeds italienischer Founder Clips von Sacks zirkulieren, die erklären, wie jene Verordnungen ein Angriff auf den freien Markt seien. Die beiden Dinge koexistieren. Mehr noch, sie nähren sich gegenseitig. Jede in Brüssel geschriebene Norm produziert eine neue Runde von Klagen in San Francisco, jede Klagerunde in San Francisco produziert ein neues kulturelles Nachgeben eines Teils der europäischen Unternehmerklasse, jedes kulturelle Nachgeben produziert in der Kaskade eine politische Schwächung des nachfolgenden Gesetzgebungsprozesses.

Das Projekt, und warum es benannt werden muss

An diesem Punkt, nach zwei Wellen von Zugeständnissen und einer der Analyse, hat der Leser wahrscheinlich erahnt, wohin ich will. Ich wünschte, wir wären zu einer Sache sehr klar. Der Hass auf die europäische Digitalregulierung, der echte, der viszerale, der sich in den Posts von David Sacks findet, in den Interviews von Joe Lonsdale, in den Paranoien von Balaji Srinivasan, in den Ausfällen von JD Vance, ist keine technische Meinungsverschiedenheit. Es ist eine politische Position, und es ist eine präzise politische Position, und sie muss als das erkannt werden, was sie ist. Jene Position vertritt, dass die Nationalstaaten gegenüber den technologischen Unternehmen zurücktreten sollten, dass die technologischen Unternehmen eine funktionale Souveränität genießen sollten, die jener der Staaten in den Gebieten, in denen sie operieren, gleichkommt oder sie übertrifft, dass die repräsentative Demokratie zu langsam für den Rhythmus der Innovation ist und dass im Konfliktfall die Demokratie sich anpassen muss. Das ist eine kohärente Position, und es ist eine Position, die Denker, Bücher, Manifeste, sogar verfeinerte theoretische Ausarbeitungen hinter sich hat, vom Libertarismus Ayn Rands bis zum Neoreaktionismus von Curtis Yarvin, durchquert vom Rechts-Akzelerationismus, der von Nick Land Anregungen schöpfte, bis zu den jüngsten Synthesen Thiels zum Konzept der Stagnation. Sie ist nicht karikaturhaft, auch wenn ihre populäre Version es ist. Sie ist ein Projekt.

Es lohnt sich, einen Moment bei diesem Projekt zu verweilen, denn es ist in Europa lange unterschätzt worden, und vielleicht wird es weiterhin unterschätzt. Der Strang, der von Yarvin ausgeht, vertritt insbesondere offen, die repräsentative Demokratie sei ein dysfunktionales System und müsse durch Regierungsformen ersetzt werden, die wie Unternehmen geführt werden, durch CEOs mit vollen Befugnissen, gelöst von verfassungsrechtlichen Schranken. Es ist eine Position, die bis vor zehn Jahren auch von der amerikanischen Mainstream-Rechten als folkloristisch betrachtet wurde. In den letzten fünf Jahren hat sie sich normalisiert, ist in die Gespräche der Sand Hill Road eingezogen, hat im Netzwerk Thiels implizite und explizite Finanzierung gefunden, hat Teile der Republikanischen Partei kolonisiert und hat sich am Ende im Weißen Haus niedergelassen, mit einem Vizepräsidenten, der Yarvin öffentlich ohne Verlegenheit zitiert. Anders gesagt, ein bedeutender Teil der gegenwärtigen amerikanischen herrschenden Klasse betrachtet das liberal-demokratische Nachkriegsgefüge als gescheitertes Experiment und betrachtet das eigene techno-unternehmerische Modell als dessen natürliche historische Nachfolge. In diesem Rahmen ist die Europäische Union nicht nur ein kommerzieller Ärger. Sie ist buchstäblich eine Verkörperung all dessen, was überwunden werden soll: ein supranationales Subjekt, das den Unternehmen Transparenzstandards auferlegt, das den Wettbewerb schützt, das die Freiheit des Produzenten im Namen von Rechten begrenzt, die nicht gekauft noch getauscht werden können. Für den, der denkt, die Zukunft müsse von den Besten regiert werden, und die Besten seien die Sieger des Marktes, ist Europa ein historischer Feind.

Ich verstehe, dass die Frage so präsentiert übertrieben erscheinen mag, und dass viele italienische — und nun deutsche — Leser, die der amerikanischen Tech-Kultur vielleicht nicht vorurteilsbehaftet feindlich gegenüberstehen, mir sagen werden, ich würde umgekehrt karikieren. Ich karikiere nicht. Ich nehme nur ernst, was die fraglichen Personen öffentlich auf den eigenen Profilen schreiben. Lesen Sie die Interviews von Marc Andreessen aus den Jahren 2023-2024. Schauen Sie sich das Techno-Optimismus-Manifest an. Lesen Sie das Buch von Yarvin von 2024. Hören Sie die Podcasts von All-In, vor allem die Stellen, an denen die europäische Regulierung kommentiert wird. Schauen Sie sich die Rede von Vance auf dem KI-Gipfel in Paris vom Februar 2025 an. Ich lese nichts zwischen den Zeilen. Es steht alles über den Zeilen, mit einer Offenheit geschrieben, die aus unserer Perspektive geradezu entwaffnend ist. Das Einzige, was zwischen den Zeilen bleibt, ist die politische Schlussfolgerung, und die politische Schlussfolgerung formuliert sich so: Die demokratische Autorität hat keinen Anspruch darauf, der Tätigkeit technologischer Unternehmen Schranken zu setzen, denn die technologischen Unternehmen bauen die Zukunft, und die demokratische Autorität gehört der Vergangenheit an.

Gegenüber diesem Projekt ist die Europäische Union, mit all ihrer Langsamkeit, mit all ihren Unvollkommenheiten, mit ihrem ganzen Cookie-Banner, tatsächlich das wichtigste geopolitische Hindernis der Gegenwart. Sie ist es nicht, weil sie einen Plan gegen die amerikanische Tech hätte, sondern weil ihr Modell eine Annahme inkorporiert, die das kalifornische Projekt zerstören will: die Annahme, dass die demokratische Autorität legitim Schranken für die wirtschaftliche Tätigkeit der Unternehmen setzen darf. Mehr nicht. Es ist eine alte Annahme, man findet sie in der Verfassungstradition aller europäischen Länder und auch der Vereinigten Staaten vor Reagan, aber im kulturellen Kontext von 2026 ist sie zur Häresie geworden. Unsere Häresie besteht darin, jene Annahme wieder aufzunehmen und auf das Digitale anzuwenden. Nicht mehr und nicht weniger. Deswegen sind wir ein Gespenst: Weil wir mit unserer institutionellen Existenz daran erinnern, dass es möglich ist, anders zu denken.

Europa kohaerent, China falsch positioniert

Ich halte einen Moment inne, um auf einen Einwand zu antworten, den ich mir vorstellen kann. Aber ist Europa wirklich so kohärent. Gibt es keine internen Spaltungen, keine Lobbys, keine nationalen Manöver, keine normativen Pannen. Natürlich gibt es sie. Europa ist ein komplexes politisches System, mit divergierenden Interessen zwischen Mitgliedstaaten, mit Deutschland, das oft die Interessen der eigenen Automobilindustrie verteidigt, auch wenn das mit der ökologischen Kohärenz kollidiert, mit Frankreich, das oft versucht, nationale Champions unter dem Deckmantel europäischer Industriepolitik zu fördern, mit Italien, das in den Tischen, die zählen, oft eine schwache technische Vertretung hat, mit nationalen Regierungen, die die Feindseligkeit gegenüber der europäischen Regulierung als internes Konsensinstrument benutzen. All das existiert. Nichts davon ändert jedoch die Tatsache, dass der normative Output des europäischen Prozesses am Ende kohärent mit einem bestimmten Modell der Beziehung zwischen Technologie und Bürgern ist, und dass jenes Modell sich radikal vom amerikanischen unterscheidet, und dass der Unterschied der eigentliche Gegenstand des Konflikts ist.

Ein weiterer Einwand. Und China. China wird in der antieuropäischen Rede immer als reductio ad absurdum herangezogen: Ihr reguliert, während China baut, und China wird gewinnen. Das ist ein so wackeliger rhetorischer Zug, dass es sich oft nicht einmal lohnt, ihn anzugehen, aber es lohnt sich, ein Detail zu beobachten. Das chinesische Modell der Digitalsteuerung ist ein Modell, in dem der Staat, identifiziert mit der Partei, eine tiefgreifende Kontrolle über das Verhalten der Plattformen, über die Inhalte, über die Daten, über die internationalen Flüsse ausübt. Peking hat über den Algorithmus des chinesischen TikTok ein Niveau regulatorischer Intervention, das den DSA wie eine Bedienungsanleitung für einen Küchenroboter erscheinen ließe. Und doch sagen die Techno-Optimisten, wenn sie China als Modell der Nicht-Regulierung zitieren, das nicht. Sie beschränken sich darauf, die Geschwindigkeit des Infrastrukturbaus zu zitieren, die Geschwindigkeit der Verbreitung von KI-Anwendungen, die Geschwindigkeit der Schließung von Sites wie Temu und Shein. Sie überspringen mit bemerkenswerter Eleganz die Existenz des Staates. Das, weil ihr Problem im Grunde nicht der Staat als solcher ist, sondern ein demokratischer Staat, der ihren Freunden Schranken auferlegt. Gegenüber einem autoritären Staat, der allen generische Schranken auferlegt und gleichzeitig sich selbst eine unangefochtene dominante Stellung garantiert, haben sie sehr viel weniger einzuwenden. Der Punkt ist die Demokratie, nicht die Regulierung. Die Regulierung ist nur die Form, in der die Demokratie in einer digitalen Welt juristische Gestalt annimmt.

Die Technik im Dienst der Politik

Ich möchte schließen, indem ich ein Stück Gewebe wieder zusammenfüge, denn ich habe begonnen, indem ich Marx zitierte, und es ist richtig, dass sich der Kreis schließt. Das Gespenst des Manifests war ein Versprechen der Verwandlung. Es war etwas, das in den Augen der herrschenden Klassen des neunzehnten Jahrhunderts die Möglichkeit darstellte, dass die Zukunft nicht einfach die Fortsetzung der Gegenwart sein würde. Das Gespenst, das heute die Träume der kalifornischen Venture Capitalists stört, verspricht keinerlei Revolution. Es verspricht nur, dass die digitale Zukunft auch von anderen Subjekten als ihren Investitionen entworfen werden kann, nach anderen Prinzipien als den ihren, in einem institutionellen Rahmen, der ihrem Modell vorausgeht und seine eventuelle Krise überleben wird. Es ist ein bescheidenes Gespenst, und genau deswegen ist es unerträglich, denn es zerlegt den Anspruch auf Exklusivität, den sich das kalifornische Modell ein Vierteljahrhundert lang angemaßt hat. Es zerlegt die Idee, dass es nur eine legitime Weise gebe, digitale Technologie zu betreiben, nach den Regeln, die von einer spezifischen Gemeinschaft von Investoren in einer spezifischen geographischen Region des Planeten geschrieben wurden. Es gibt der Technologie ihren Status als pluraler kultureller Artefakt zurück, pluralen Institutionen unterworfen, anfechtbar und angefochten. Für jene, die glaubten, die Geschichte gewonnen zu haben, ist das ein Affront.

Für den, der dieses Handwerk in diesem Kontinent in diesen Jahren ausübt, ist das Gespenst kein Ärgernis. Es ist ein Kompass. Es ist das, was uns jeden Morgen, wenn wir einen Pull Request öffnen oder ein Ausschreibungsdokument schreiben, sagt, dass technische Entscheidungen politische Konsequenzen haben und dass die politischen Konsequenzen es verdienen, vom Recht geschützt zu werden. Wir tun das nicht, weil wir dekadent sind. Wir tun das, weil wir ein langes historisches Gedächtnis haben, und wir wissen, dass die Technologien ohne Schranken in den vorangegangenen vierhundert Jahren das exakte Gegenteil der Freiheit produziert haben, die sie versprachen. Wir tun das, weil wir Polanyi gelesen haben, wir Hannah Arendt gelesen haben, wir die verfassunggebenden Väter unseres Kontinents gelesen haben, wir die europäische Rechtsprechung zu den Grundrechten gelesen haben, und aus all diesem Material haben wir eine einfache Schlussfolgerung gezogen. Der Markt ist kein Naturgegebenes. Er ist eine Institution. Und wie alle menschlichen Institutionen muss er aufgebaut und im Lauf der Zeit korrigiert werden. Das Digitale ist ein Markt. Seine Regeln steigen nicht vom Himmel des Silicon Valley herab. Wir schreiben sie, auch wir, hier, mitten in einem Kontinent, der langsam bemerkt, dass er zum seltsamsten Ort der Welt geworden ist: dem Ort, an dem jemand noch versucht zu sagen, dass die Technik der Politik dienen muss und nicht umgekehrt.

Es gibt eine letzte Sache, die ich sagen möchte, und ich werde sie in einem persönlicheren Ton sagen, denn das ist der richtige Ton, um sie zu schließen. Wenn es passiert, dass ich mit amerikanischen Kollegen über diese Dinge spreche, kommt in der Regel innerhalb von drei Minuten der Moment, in dem ich mit einem Hauch von ehrlichem Mitleid gefragt werde, ob ich mich in Europa nicht erstickt fühle, von all dieser Bürokratie. Die Frage wird in gutem Glauben gestellt. Sie denken wirklich, dass wir in einer Art regulatorischem Käfig leben, der uns am Bauen hindert. Die ehrlichste Antwort, die ich geben kann, ist, dass nein, ich mich nicht erstickt fühle. Ich fühle mich am richtigen Ort. Denn hier, wenigstens hier, ist die Frage „Was macht diese Software mit den Menschen?” eine legitime Frage, eine Frage, die man einem Verwaltungsrat stellen kann, eine Frage, die juristische Konsequenzen hat, wenn die Antwort schlecht ausfällt. Anderswo wird dieselbe Frage im besten Fall als naiv betrachtet. Im schlechtesten als subversiv. Hier ist es. Ich bevorzuge den Stand der Dinge, in dem ich sie stellen kann, auch wenn ich, um sie zu stellen, ein bisschen mehr Papier akzeptieren muss, ein paar Audits, ein paar EDPB-Templates, ein paar Konformitätsbewertungen. Es ist ein Preis. Man bezahlt ihn. Es ist kein Kataklysmus. Es ist eher der Preis der Zivilisation.

Das Gespenst, das in Europa umgeht, sind wir. Und wir werden es bleiben, solange irgendjemand, irgendwo, noch der Auffassung ist, dass die Technik eine politische Frage ist und keine Frage reiner Ingenieurskunst. Das ist nicht wenig. Das ist überhaupt nicht wenig.

Der Vertrag war Ende 2023 unterzeichnet worden, und aus der Sicht des Hauptanbieters war es ein sauberer, gut strukturierter Vertrag, mit allen Schutzklauseln, die die Rechtsabteilung über die Jahre verlangt hatte. Er spezifizierte klar den Gegenstand der Lieferung, legte die Service-Level fest, fixierte die Vertragsstrafen für Nichteinhaltung, definierte den Perimeter der Anbieterhaftung mit Standardobergrenzen am jährlichen Vertragswert, schloss indirekte Schäden aus, regelte die Subunternehmen über eine Klausel, die vom Kunden die Genehmigung der Hauptsubunternehmen verlangte und die die Verantwortung für deren Eignungsprüfung auf den Kunden verlagerte. Er war vier Monate verhandelt worden, war durch drei Runden juristischer Prüfung auf beiden Seiten gegangen, war von Führungskräften mit den notwendigen Vollmachten unterzeichnet worden. Der Hauptanbieter, ein Software-Haus mit fünfzig Personen, betrachtete ihn als guten Vertrag. Der Kunde, eine private Gesundheitsdienstleistungsgesellschaft mit einer Million Versicherten, betrachtete ihn als ausgewogenen Vertrag. Zwei Jahre lang lief das Verhältnis gut.

Ende 2025 erlitt ein Versicherter einen Schaden durch das, was das klinische System hätte tun sollen und nicht tat. Die technische Ursache wurde einer Risikobewertungs-Bibliothek zugeschrieben, die das System zur Klassifizierung der Interventionsprioritäten verwendete. Die Bibliothek war von einem vom Kunden vier Jahre zuvor genehmigten Subunternehmer geliefert worden, war achtzig Tage vor dem Vorfall vom Subunternehmer selbst still aktualisiert worden, mit einer Algorithmusänderung, die niemand dem Hauptanbieter mitgeteilt hatte, und niemand hatte eine Aktualisierung der Dokumentation verlangt, weil der Subunternehmer seine Aktualisierung als gewöhnliche Wartung betrachtete. Der Subunternehmer hatte seinen Sitz in einem Drittland, hatte keinen Rechtsvertreter in der Union, und in den Monaten nach der Klage erwies er sich faktisch als unerreichbar für gerichtliche Zustellungen.

Der Hauptanbieter reagierte auf die Schadensersatzforderung des Anwalts des Versicherten, indem er den Vertrag vorzeigte. Er behauptete, dass der Subunternehmer vom Kunden genehmigt worden war, dass die Änderung einseitig vom Subunternehmer ohne jede Mitteilung eingeführt worden war, dass der Vertrag indirekte Schäden ausschloss und die Haftung am jährlichen Wert deckelte, und dass jedenfalls die materielle Verantwortung beim Kunden lag, als demjenigen, der die Beziehung zum Versicherten direkt verwaltete. Der Anwalt des Versicherten focht keinen dieser vertraglichen Punkte an. Er bemerkte schlicht, dass der Vertrag zwischen Anbieter und Kunden ihn nicht betraf, weil er ihn nicht unterzeichnet hatte, und dass seine Klage auf dem neuen europäischen Produkthaftungsregime beruhte, unter dem der Hauptanbieter als Hersteller des fehlerhaften Produkts qualifizierbar war und gegenüber dem geschädigten Endverbraucher unabhängig von den mit seinem Kunden vereinbarten Vertragsklauseln nach dem Prinzip der verschuldensunabhängigen Haftung haftete. Diese Klauseln, fügte er hinzu, regelten den Regress zwischen den Vertragsparteien, nicht die Exposition gegenüber Dritten. Der Vertrag, mit anderen Worten, war ein guter Vertrag zwischen den falschen Personen.

Der traditionelle Einwand

Der Einwand, den ich sofort behandeln möchte, weil er der am tiefsten verwurzelte und der aufrichtigste ist, ist der, der von den traditionellen Juristen kommt, mit denen ich in diesen Jahren gearbeitet habe. Er klingt so: All das ist ein Problem der Vertragsgestaltung. Wenn die Klauseln gut geschrieben sind, wenn die Freistellungen vollständig sind, wenn die Subunternehmer-Verfahren rigoros sind, ist der Hauptanbieter geschützt. Es ist ein Einwand, der formal kohärent ist mit der Art, wie das Vertragsrecht in der Software vierzig Jahre lang funktioniert hat. Bis vor wenigen Jahren war er auch substanziell wahr, weil das Haftungsregime des Software-Herstellers schwach war, die Klagen der geschädigten Dritten fast immer durch den direkten Kunden gingen, und der Hauptanbieter vernünftigerweise erwarten konnte, dass seine Exposition sich in den vereinbarten Vertragsgrenzen erschöpfte.

Diese Epoche ist vorbei. Das juristische Regime, das sich in Europa zwischen 2024 und 2027 konsolidiert und über das ich in dieser Reihe bereits in Bezug auf das als geschriebenes Versprechen bewertete Software-Produkt und auf die Spezifikation als juristisch relevanten Aktivposten geschrieben habe, führt eine Haftungsebene ein, die außerhalb des Vertrags wirkt und die der Vertrag nur teilweise regeln kann. Die Überarbeitung der Product Liability Directive, anwendbar ab dem 9. Dezember 2026, qualifiziert Software ausdrücklich als Produkt und wendet auf den Software-Hersteller ein Regime der verschuldensunabhängigen Haftung gegenüber den geschädigten Endverbrauchern an. Der Cyber Resilience Act, voll anwendbar ab dem 11. Dezember 2027, führt Sicherheitspflichten für das digitale Produkt ein, die auf dem Hersteller über den gesamten Lebenszyklus lasten und sich auf integrierte Komponenten erstrecken. Der AI Act verteilt Pflichten entlang der Kette der Anbieter von KI-Systemen so, dass der Anbieter des finalen Systems gewährleisten muss, dass die integrierten Komponenten konform sind. Der Digital Operational Resilience Act, anwendbar ab dem 17. Januar 2025, erlegt Finanzunternehmen und ihren kritischen ICT-Anbietern Pflichten zum Risikomanagement der Lieferkette auf, die vertragliche Grenzen überschreiten. NIS2, anwendbar ab dem 18. Oktober 2024, macht denselben Schritt für die erweiterten kritischen Sektoren. Jeder dieser Akte wäre einzeln genommen mit einigen vertraglichen Anpassungen handhabbar. Zusammen genommen und in ihren Schnittmengen definieren sie eine Haftungsstruktur, die der Liefervertrag nicht mehr enthalten kann.

Die vier gefallenen Voraussetzungen

Das traditionelle Vertragsmodell der Software ist in einer Epoche aufgewachsen, in der einige implizite Voraussetzungen galten, und es ist unzureichend geworden, weil all diese Voraussetzungen im selben Jahrzehnt gefallen sind. Da war zunächst die Idee, dass die Haftung des Anbieters gegenüber dem Kunden die Exposition des Anbieters erschöpfte, weil der zwischengeschaltete Kunde jede Haftung gegenüber geschädigten Dritten absorbierte und verwaltete. Da war dann die Überzeugung, dass Software ein im Lieferzeitpunkt begrenztes Objekt sei, das auf der Grundlage eines statischen Lastenhefts zum Zeitpunkt des Releases bewertbar sei. Drittens wurde als selbstverständlich angenommen, dass die Lieferkette aus juristischer Sicht im Wesentlichen bilateral sei, das heißt, dass jedes Glied durch einen Vertrag zwischen zwei Parteien geregelt werden könne, ohne sich um die Gesamtdynamik der Kette kümmern zu müssen. Und schließlich wurde vorausgesetzt, dass das Haftungsregime über die Zeit stabil bleibe, ausreichend, um es vernünftig zu machen, mehrjährige Verträge auf der Grundlage des zum Zeitpunkt der Unterzeichnung geltenden Rechtsrahmens zu unterzeichnen. Es waren Voraussetzungen, die bis etwa 2020 wie Naturgesetze der Software-Vertragsgestaltung erschienen, und die sich rückblickend einfach als die Merkmale einer spezifischen juristischen Epoche erweisen.

Die erste Voraussetzung wurde durch die Erweiterung der Aktivlegitimation der geschädigten Dritten in der neuen PLD erodiert. Unter dem alten Produkthaftungsregime konnte der geschädigte Endverbraucher gegen den Hersteller klagen, aber in der Praxis gingen die Klagen meist über den Wiederverkäufer oder den kommerziellen Integrator, und der Software-Hersteller genoss bis 2024 eine interpretative Unsicherheit darüber, ob er überhaupt unter die Definition des Herstellers fiel. Die neue Richtlinie, die Software ausdrücklich in die Produktdefinition aufnimmt und Mangelvermutungen einführt, die die Beweislast des Geschädigten erleichtern, macht die Position des Software-Herstellers viel exponierter. Sie fügt zudem einen Mechanismus der dokumentarischen Offenlegung hinzu, der es dem Richter erlaubt, dem Anbieter aufzuerlegen, die technische Dokumentation des Produkts vorzulegen, und den Mangel im Falle der Nichtvorlage zu vermuten. Von diesem Moment an braucht der Anwalt des Geschädigten nicht mehr über den zwischengeschalteten Kunden zu gehen und kann direkt gegen den Hauptanbieter der Software klagen, die den Schaden verursacht hat, wobei er die Vertragsklauseln zwischen Anbieter und Kunden vollständig ignoriert, weil diese Klauseln eine Beziehung regeln, an der der Geschädigte ein Dritter ist. Die Sache ist ausdrücklich in Artikel 15 der Richtlinie geschrieben, mit dem Titel „Ausschluss oder Begrenzung der Haftung“, der den Mitgliedstaaten auferlegt zu gewährleisten, dass die Haftung des Wirtschaftsakteurs gegenüber dem Geschädigten weder durch Vertragsklauseln noch durch Vorschriften des nationalen Rechts begrenzt oder ausgeschlossen werden kann. Es ist ein kurzer und technischer Artikel, aber er ist der Schlussstein des gesamten Aufbaus, weil er das, was wie vertraglicher Spielraum aussah, in eine Zone juristischer Unverfügbarkeit verwandelt.

Die zweite Voraussetzung wurde durch den Cyber Resilience Act und den AI Act erodiert, die beide Sicherheits- und Risikomanagementpflichten einführen, die auf dem Hersteller über den gesamten Lebenszyklus des Produkts lasten und nicht nur zum Zeitpunkt der Lieferung. Software hat aufgehört, ein im Lieferzeitpunkt begrenztes Objekt zu sein, und gestaltet sich als ein Objekt, das dem regulatorischen Regime kontinuierlich ausgesetzt ist; jedes Update, jede Modifikation, jede Integration neuer Komponenten kann als wesentliche Modifikation requalifiziert werden, die das Produkt in das anwendbare Regime zurückbringt, auch wenn das Produkt in einer früheren Epoche auf den Markt gebracht worden war. Der Hauptanbieter, der das System 2023 geliefert hat, hat sich nicht 2026 von der Haftung entlastet, als eine in dieses System integrierte Drittbibliothek aufgehört hat, gewartet zu werden, und Sicherheitsschwachstellen entwickelt hat. Die Haftung hat sich einfach auf die Wartungsebene verschoben, und der Anbieter, der nicht aktualisiert hat, ist ein Anbieter, der einer fortlaufenden Pflicht nicht nachgekommen ist, nicht einer auf den Zeitpunkt der ursprünglichen Lieferung begrenzten Pflicht.

Auch die dritte Voraussetzung, die der Bilateralität der Lieferkette, wurde durch die Einführung von Haftungsketten erodiert, die die bilaterale Vertragsgestaltung durchqueren. Unter dem DORA-Regime muss das Finanzunternehmen sein ICT-Drittanbieter-Risiko entlang der gesamten Kette kartieren und verwalten, und wenn ein Anbieter als kritisch qualifiziert ist, erweitern sich die Pflichten so, dass die Vertragsklauseln zwischen dem Finanzunternehmen und dem kritischen Anbieter unabhängig vom Willen der Parteien spezifische, von der Verordnung auferlegte Elemente enthalten müssen. Der CRA seinerseits verpflichtet den Hersteller eines digitalen Produkts, die Sicherheit des integrierten Produkts zu gewährleisten, und diese Garantie erschöpft sich nicht in den Vertragsbeziehungen mit den eigenen Subunternehmern, weil der Regulator das Produkt als einheitliches Ganzes unabhängig von der internen Zusammensetzung der Lieferkette bewertet. Die überarbeitete PLD fügt eine zusätzliche Komplikation hinzu, indem sie vorsieht, dass der wesentliche Modifikator eines Produkts selbst als Hersteller verantwortlich werden kann, und das eröffnet eine zirkuläre Haftungsdynamik, in der der Hauptanbieter, der zwischengeschaltete Integrator, der Subunternehmer und der Endverbraucher unter verschiedenen Titeln für denselben Schaden in Anspruch genommen werden können. NIS2 und der AI Act vervollständigen das Bild, indem sie analoge Pflichten jeweils auf die erweiterten kritischen Sektoren und auf KI-Systeme mit hohem Risiko ausdehnen, mit dem Ergebnis, dass jedes Kettensegment heute von mindestens zwei oder drei überlappenden Regimen durchquert wird, die bilaterale Vertragsklauseln nicht zu komponieren vermögen.

Die vierte Voraussetzung, die der Stabilität des Rechtsregimes über die Zeit, ist die, deren Erosion die subtilsten Effekte erzeugt, weil die heute unter dem geltenden Rahmen unterzeichneten mehrjährigen Verträge morgen unter einem Rahmen angewendet werden, der sich entwickelt haben wird. Der Anbieter, der 2026 einen sechs- oder siebenjährigen Vertrag unterzeichnet, wird sich 2032 oder 2033 unter Regimen wiederfinden, die sich bis dahin signifikant verändert haben könnten, weil die PLD eine Revisionsklausel vorsieht, weil der CRA Gegenstand von Leitlinien sein wird, die die Auslegung ganzer Abschnitte ändern werden, weil der AI Act bereits von der Kommission selbst als offene Baustelle definiert worden ist. Der mehrjährige Vertrag unter dem traditionellen Modell setzte eine regulatorische Trägheit voraus, die es nicht mehr gibt.

Vier Phänomene, die der Vertrag nicht adressiert

Jedes dieser vier Phänomene hat praktische Konsequenzen, die der traditionelle Vertrag nicht adressieren kann. Die gesamtschuldnerische Haftung der Lieferanten kritischer Komponenten, auf unterschiedliche Weise von PLD und CRA eingeführt, sorgt dafür, dass der Hauptanbieter für die Mängel der integrierten Komponenten haftet, auch wenn die Subunternehmer säumig oder unerreichbar sind. Die Vertragsklauseln, die den Regress gegen die Subunternehmer regeln, bleiben zwischen den Vertragsparteien gültig, verschieben aber die Haftung gegenüber dem geschädigten Endverbraucher nicht, der jederzeit gegen den Hauptanbieter als das zugängliche und vermögensmäßig solideste Glied der Kette klagen kann. Der Hauptanbieter, der das Risiko über vertragliche Klauseln auf den Subunternehmer übertragen wollte, muss es daher absorbieren und kann erst nachträglich versuchen, im Regress wiederzugewinnen, vorausgesetzt, der Subunternehmer existiert noch, ist solvent und erreichbar.

Die durch die neue PLD eingeführten dokumentarischen Offenlegungspflichten sind das zweite Phänomen, und sie sind besonders heimtückisch, weil sie den Anbieter in ein Subjekt verwandeln, das dem Richter seine eigene technische Dokumentation vorlegen muss, auch wenn diese Dokumentation Designentscheidungen, Sicherheitskonfigurationen, Trainingsdatensätze, architektonische Entscheidungen umfasst, die das Unternehmen als Geschäftsgeheimnis betrachten würde. Der Richter muss das Recht auf Offenlegung mit dem Schutz von Geschäftsgeheimnissen abwägen, aber in der Praxis findet sich der Anbieter dokumentarischen Forderungen ausgesetzt, die der Vertrag mit dem Kunden nicht begrenzen kann, weil der Vertrag weder den Richter noch den Geschädigten bindet. Der Anbieter mag mit dem Kunden die Unzugänglichkeit der Dokumentation vereinbart haben, aber wenn der Geschädigte die Vorlage verlangt, muss der Anbieter produzieren, und die etwaige Verweigerung der Vorlage erzeugt nach Artikel 10 der Richtlinie eine Mangelvermutung.

Die Mangelvermutungen, die der einzelne Anbieter nicht allein widerlegen kann, sind das dritte Phänomen und das subtilste der vier. Die neue PLD sieht vor, dass der Richter die Mangelhaftigkeit des Produkts vermuten kann, wenn das Produkt technisch oder wissenschaftlich komplex ist und der Beweis des Mangels für den Geschädigten übermäßig schwierig wäre. Für komplexe Software-Systeme, insbesondere für solche, die KI-Komponenten integrieren, aktiviert sich diese Vermutung nahezu automatisch, und die Last, sie zu widerlegen, fällt auf den Anbieter. Die Vermutung zu widerlegen verlangt nachzuweisen, dass das Produkt zum Zeitpunkt der Lieferung den Mangel nicht aufwies, oder dass der Mangel später durch Modifikationen außerhalb der Kontrolle des Anbieters eingeführt wurde. Beide Nachweise verlangen detaillierte historische Dokumentation des Systems, und der Anbieter, der diese Dokumentation nicht gepflegt hat, findet sich dabei, nichts beweisen zu können, und unterliegt daher der Vermutung.

Die Accountability des wesentlichen Modifikators ist das vierte Phänomen, und es ist dasjenige, das die Struktur des bilateralen Vertrags am radikalsten bricht. Wenn ein Kunde oder ein zwischengeschalteter Integrator ein von einem Dritten geliefertes Software-Produkt wesentlich modifiziert, kann er selbst als Hersteller des modifizierten Produkts haften, und das eröffnet eine Dynamik, in der der ursprüngliche Anbieter möglicherweise nicht mehr für das Produkt in modifizierter Form haftet, der Modifikator aber möglicherweise nicht über die Kompetenzen, die Dokumentation und die Struktur verfügt, um die Verantwortung zu übernehmen, die er materiell übernommen hat. Das Ergebnis ist eine Grauzone der Haftung, in der der Geschädigte wählt, wen er verklagt, auf der Grundlage von Kriterien der vermögensrechtlichen und prozessualen Zugänglichkeit, und in der die beteiligten Parteien sich die Verantwortung mit oft paradoxen Ergebnissen zuspielen.

Die Konsolidierung, die nicht sofort kommt

Man könnte einwenden, und jemand wird es tun, dass all dies übertrieben ist und dass die richterliche Praxis einen Weg finden wird, Ordnung in das System zurückzubringen. Es ist ein Einwand, der Respekt verdient, weil die richterliche Praxis immer diese ausgleichende Funktion hat, und weil die europäischen Verordnungen, einmal in nationale Rechtsprechung übersetzt, oft die Strenge verlieren, die sie auf dem Papier haben. Die Antwort, die ich zu geben mich getraue, nachdem ich beobachtet habe, wie sich die Praxis in den europäischen Jurisdiktionen bewegt, in denen die ersten Fälle auftauchen, ist, dass die Konsolidierung kommen wird, aber sie wird in fünf oder sieben Jahren kommen, und in der Zwischenzeit ist das Expositionsfenster für Anbieter, die unter traditionellen Verträgen operieren, sehr breit. Die ersten relevanten Urteile zur Software-Herstellerhaftung unter der neuen PLD werden nicht vor 2028 kommen, weil das Regime auf Produkte angewendet wird, die nach dem 9. Dezember 2026 in Verkehr gebracht werden, und Verfahren mindestens anderthalb Jahre dauern. Von da an werden weitere drei oder vier Jahre nötig sein, bis sich eine konsolidierte Rechtsprechung bildet. In der Zwischenzeit akkumuliert jeder Anbieter, der mit Verträgen alten Modells arbeitet, rückwirkende Exposition, weil viele der Systeme, die er heute liefert, noch in Produktion sein werden, wenn sich die Rechtsprechung gefestigt hat, und sie werden mit den Kriterien bewertet, die sich bis dahin konsolidiert haben werden.

Die Sektoren, die uns vorangehen

Es wäre unaufrichtig, nicht anzuerkennen, dass es Sektoren gibt, in denen diese Dynamiken seit Jahrzehnten bestehen, und in denen Lieferverträge eine Struktur haben, die die Unzulänglichkeit des traditionellen bilateralen Modells anerkennt. Es sind Sektoren, die unter strengen Produkthaftungsregimen weit vor der Allgemeinsoftware leben, und die vertragliche Praktiken entwickelt haben, die es verdienen, studiert zu werden. Die Zivilluftfahrt ist eine davon, und Lieferverträge für Luftfahrtkomponenten enthalten seit jeher Pflichten zur dokumentarischen Rückverfolgbarkeit, zur Drittzertifizierung, zur koordinierten Behandlung von Nichtkonformitäten, zur gesamtschuldnerischen Haftung gegenüber Aufsichtsbehörden. Das Medizinprodukt ist ein weiterer, und Lieferverträge für Medizinproduktekomponenten sehen Qualitätsrahmenvereinbarungen vor, die über den einzelnen kommerziellen Vertrag hinausgehen und die Beziehung zwischen den Parteien als regulatorische Beziehung neben einer kommerziellen regeln. Das Automobil ist der dritte, vor allem nach der Einführung der ISO-26262-Normen zur funktionalen Sicherheit der elektronischen Systeme von Fahrzeugen, und Lieferverträge für Automobilsoftware enthalten seit etwa zehn Jahren Klauseln zur Haftung entlang der Kette, die die Unmöglichkeit anerkennen, die Exposition in bilateralen Verhältnissen einzudämmen.

Was in der Allgemeinsoftware geschieht, ist die Konvergenz — beschleunigt durch das europäische Regulierungspaket — auf das Modell, das diese Sektoren bereits praktizieren. Der Unterschied ist, dass Luftfahrt, Medizinprodukte und Automobil dreißig Jahre Zeit hatten, die vertraglichen Praktiken, die internen Kompetenzen, die Branchenstandards und die strukturierten Lieferbeziehungen aufzubauen. Die Allgemeinsoftware hat fünf oder sieben Jahre, dasselbe zu tun, und sie muss es tun, während sie weiterhin auf Märkten operiert, auf denen die meisten Wettbewerber noch im alten Modell denken. Es ist ein asymmetrischer Übergang, in dem, wer sich zuerst bewegt, einen Positionierungspreis zahlt, den, wer sich später bewegt, nicht zahlt, aber wer sich zuerst bewegt, baut auch die Kapazität auf, nachfolgende regulatorische Entwicklungen zu absorbieren, die der Spätbewegliche zu konsolidierten Marktpreisen wird kaufen müssen.

Fünf operative Dimensionen

Auf operativer Ebene hat die Transformation des Software-Liefervertrags fünf Dimensionen, die gleichzeitig zu verwalten sind. Die erste ist der Übergang vom Vertrag-als-Dokument zu den Vertragsdokumenten als Ökosystem. Ein Software-Liefervertrag unter dem neuen Regime erschöpft sich nicht in einem einzelnen Dokument, das bis zur Erneuerung gilt, sondern bildet ein System verbundener Dokumente, das den Hauptvertrag, die Service-Level-Anhänge, die Sicherheitsanhänge, die den Medizinproduktevereinbarungen ähnlichen Qualitätsvereinbarungen, die Vereinbarungen über die Verarbeitung personenbezogener Daten nach Artikel 28 DSGVO, die Vereinbarungen zur koordinierten Schwachstellenbehandlung, die Vereinbarungen zur gegenseitigen Lieferketten-Disclosure umfasst. Jedes dieser Dokumente lebt mit einem eigenen Aktualisierungszyklus, und der Hauptvertrag wird zum Rahmen, der sie zusammenhält, nicht zum Behälter aller Klauseln.

Die zweite Dimension ist die Transformation der Haftungsbegrenzungsklausel. Die traditionellen Klauseln, die die Haftung des Anbieters auf den jährlichen Vertragswert deckeln oder die indirekte Schäden ausschließen, bleiben zwischen den Vertragsparteien gültig, entfalten aber gegenüber den geschädigten Dritten keine Wirkung. Für den Anbieter bedeutet das, dass die effektive Exposition diejenige gegenüber dem geschädigten Endverbraucher ist, nicht die mit dem Kunden vereinbarte, und die Versicherungspolicen müssen auf dieser effektiven Exposition dimensioniert werden, nicht auf den vertraglichen Höchstgrenzen. Die Versicherungspraxis des Sektors ist in diesem Moment verworren, weil die Gesellschaften die Produkte für die Produkthaftung von Software-Herstellern in Funktion des neuen Regimes neu definieren, und die Prämien steigen nichtlinear. Für mittelgroße italienische Software-Häuser wird die Versicherungskosten der Produkthaftung zu einer relevanten Bilanzposition, wo sie bis vor wenigen Jahren eine vernachlässigbare war.

Die dritte Dimension ist die Neufassung der Klauseln zur Subunternehmerschaft, die von einem Modell, in dem der Kunde die Hauptsubunternehmer zum Zeitpunkt der Unterzeichnung genehmigt, zu einem Modell übergehen müssen, in dem es ein kontinuierliches Verfahren der Bewertung, des Monitorings und der Disclosure der Subunternehmer über die gesamte Vertragsdauer gibt. Der Hauptanbieter muss jederzeit die Zusammensetzung seiner Lieferkette nachweisen können, muss die SBOM nach dem CRA produzieren können, muss auf Auditanfragen des Kunden oder des Regulators antworten können, muss Situationen verwalten, in denen ein Subunternehmer den Markt verlässt oder die Wartung einer Komponente einstellt. All das verlangt Werkzeuge zum Lieferkettenmanagement, die das traditionelle Vertragsmodell als selbstverständlich nahm und die heute zu kontinuierlicher operativer Tätigkeit werden.

Die vierte Dimension ist die Einführung von Klauseln zur koordinierten Behandlung von Schwachstellen und Sicherheitsvorfällen. Unter dem CRA, unter NIS2 und unter DORA für den Finanzsektor haben Anbieter und Kunde beide Berichtspflichten innerhalb enger Zeitfenster, und die Einhaltung dieser Fenster verlangt eine Koordination, die der Vertrag operativ regeln muss, nicht nur formal. Eine Klausel, die sagt „die Parteien arbeiten bei der Vorfallsbehandlung zusammen“, ist nutzlos, wenn sie nicht spezifiziert, wer wann über welche Kanäle mit welchen Schwellenwerten benachrichtigt. Die Klausel muss fast ein vertragliches Mini-Runbook sein, und ihre Qualität bemisst sich an der Fähigkeit zu funktionieren, wenn ein realer Vorfall im Gange ist, nicht an ihrer juristischen Eleganz.

Die fünfte Dimension ist die subtilste, und sie betrifft das Lebenszyklus-Management des Produkts. Unter dem CRA muss der Hersteller den Supportzeitraum des Produkts erklären und ihn für diesen Zeitraum aufrechterhalten, und er muss den Marktaustritt des Produkts so verwalten, dass die Nutzer informiert sind und Übergangspfade haben. Der Software-Liefervertrag muss diesen Aspekt regeln, weil der Hauptanbieter auch nach dem Ende der Vertragsbeziehung mit dem Kunden gegenüber dem geschädigten Endverbraucher exponiert ist, und weil die Verwaltung des End-of-Support zu einem kritischen Moment wird, in dem sich Resthaftungen materialisieren können. Die traditionellen Klauseln „perpetual licence“ oder „no warranty after termination“ entfalten gegenüber den geschädigten Dritten keine Wirkung, und das bedeutet, dass der Anbieter den Lebenszyklus des Produkts als Funktion verwalten muss, die die Vertragsdauer übersteigt.

Disclosure: achtzehn Monate Neufassung

Ich muss in einem Punkt transparent sein, weil ich zu diesem Thema Transformationen beschreibe, die ich in erster Person erlebe. Die Überarbeitung unserer Lieferverträge im Unternehmen, in dem ich arbeite, ist eine seit achtzehn Monaten laufende Tätigkeit und hat noch keine stabile Form erreicht. Wir arbeiten mit unserer Referenzkanzlei daran, den Basisvertrag für die Lieferung von Software-Dienstleistungen neu zu schreiben, und was dabei herauskommt, ist weit entfernt von dem sauberen, eleganten Vertrag, den wir zu produzieren hofften, und hat die Form eines komplexer artikulierten Dokumentensystems als das vorhergehende, mit Anhängen, die aus unterschiedlichen Gründen existieren und die sich nicht auf ein einziges Template reduzieren lassen. Einige Kunden akzeptieren die neue Struktur, andere finden sie unnötig komplex und bitten, zum alten Modell zurückzukehren. Der Marktdruck zur vertraglichen Einfachheit ist noch stark, und in einigen Fällen akzeptieren wir selbst, Verträge alten Modells zu unterzeichnen, wenn der Kunde es auferlegt, im Wissen, dass wir rückwirkende Exposition akkumulieren. Es ist eine Wahl, die wir aus unmittelbaren kommerziellen Gründen treffen, und die ich in unseren internen Gesprächen zusammengesetzte Exposition genannt habe, weil sie nichtlinear akkumuliert, während das Kundenportfolio wächst.

Eine Chance, nicht nur eine Last

Ich möchte auch sagen, weil sonst der Text wie eine pessimistische Prognose über die italienische Software-Industrie klänge, dass die Transformation, die ich beschreibe, eine Chance ist, bevor sie eine Last ist. Mittelgroße italienische Software-Häuser, die sich entscheiden, vertragliche Kompetenzen aufzubauen, die mit dem neuen Regime kohärent sind, der Delivery-Arbeit eine kontinuierliche Arbeit der dokumentarischen Pflege und des Lieferkettenmanagements zur Seite zu stellen, intern die hybriden Figuren auszubilden, die ich im vorhergehenden Text dieser Reihe beschrieben habe, werden in fünf Jahren eine schwer zu erodierende Wettbewerbsposition haben. Die Software-Häuser, die weiterhin traditionelle Verträge unterzeichnen werden, in der Hoffnung, dass der regulatorische Rahmen sich nicht wirklich anwenden wird oder dass die nationale Rechtsprechung ihn abmildern wird, werden sich exponiert finden und werden den Rückstand zu Kosten aufholen müssen, die viel höher sind als die heute tragbaren. Es ist eine jener Situationen, in denen die Entscheidung, nicht zu entscheiden, die teuerste von allen ist, weil die Zeit gegen den arbeitet, der sich nicht bewegt, und weil jeder heute unter dem alten Modell unterzeichnete Vertrag eine Verbindlichkeit ist, die sich in einigen Jahren offenbaren wird, wenn die von der PLD als Standard-Szenario gezeichneten Fälle in den Berichterstattungs-Sektionen der Fachpresse zu erscheinen beginnen.

Die Zentralität, die stirbt

Wenn ich die vier Stücke dieser Reihe zusammensetze, ist das allgemeine Argument, das ich zu konstruieren versuche, das folgende. Die Software, als industrielles und als juristisches Objekt, ändert vor unseren Augen ihre Natur, und die Ingenieur- und Geschäftskultur des Sektors passt sich nicht in der Geschwindigkeit an, die der Augenblick verlangt. Das erste Stück, Cruft, keine Patina, argumentierte, dass Software nicht altern kann wie materielle Objekte. Das folgende, Die Spezifikationsschulden, verlagerte die Aufmerksamkeit auf die Tatsache, dass die geschriebene Spezifikation zum juristisch relevanten Aktivposten des Produkts geworden ist und dass unsere Industrie nicht über die Werkzeuge verfügt, sie am Leben zu halten. Dann kam Der Aufstieg des Compliance Engineers, gewidmet der hybriden Berufsfigur, die hervortritt, um das Vakuum zwischen Ingenieurkunst und Regulierung zu übernehmen. In diesem vierten Stück verlagert sich das Argument von der Ebene des Produkts und der Arbeit auf die Ebene der Beziehung zwischen Organisationen, und die These ist, dass der Liefervertrag, das klassische juristische Instrument dieser Beziehung, zu einem Instrument unter anderen einer breiteren und strukturierteren Beziehung wird, die das traditionelle Vertragsrecht nur teilweise regeln kann.

Der Software-Liefervertrag ist nicht tot, und nichts, was ich geschrieben habe, ist als Vorhersage seines Verschwindens zu lesen. Was tot ist, ist seine Zentralität, die Idee, dass die Beziehung zwischen Anbieter und Kunde umfassend durch ein zu Beginn der Beziehung verhandeltes und bei Erneuerungen aktualisiertes bilaterales Dokument beschrieben werden kann. Die zeitgenössische Beziehung ist eine multilaterale Beziehung, regulatorisch aufgeladen, dynamisch dritten Subjekten ausgesetzt, die der Vertrag nicht bindet, und durchquert von kontinuierlichen dokumentarischen Pflichten, die der Vertrag nur zusammenfassen kann. Zu denken, es genüge, die Klauseln besser zu schreiben, ist eine verständliche und menschliche Nostalgie, und es ist auch der schnellste Weg, Exposition zu akkumulieren, während man sich für geschützt hält. Die Klauseln dienen noch, mehr noch als zuvor, aber sie dienen als Elemente eines breiteren Dispositivs, das sie enthält und übersteigt.

Der Vertrag, wie wir ihn kannten, ist zur sanften Täuschung geworden, die es Software-Anbietern erlaubt zu glauben, sie wüssten, woran sie sich exponieren. Traditionelle Verträge werden noch einige Jahre lang unterzeichnet werden, weil sich der Markt langsamer bewegt als das Recht, und weil das alte Modell vertraut ist und die neuen Modelle noch in Bildung sind. Aber wer in den nächsten fünf Jahren weiterhin traditionelle Verträge unterzeichnet, unterzeichnet neben dem Vertrag eine stille Wette darauf, dass sich die Dinge nicht wirklich ändern werden. Es ist eine Wette, die meine Generation derer, die in Europa Software machen, wahrscheinlich verlieren wird, weil sich die Dinge bereits ändern, und das, was heute wie ein Übermaß an Vorsicht der wenigen aussieht, die sich bewegen, wird sich in einigen Jahren als das vorsichtige Minimum erweisen, das von Anfang an verlangt war.

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.

Es gibt Dokumente, die nur zu den falschen Zeitpunkten geöffnet werden. Die DSFA für das klinische Triage-System wurde im April 2024 unterzeichnet und im Compliance-Ordner abgelegt, aus dem sie nie wieder herausgekommen ist, so wie keine DSFA jemals aus dem Compliance-Ordner herauskommt. Achtzehn Monate später öffnet sie jemand. Kein Jurist, sondern ein Berater, der für ein Sicherheits-Audit gekommen ist, und er öffnet sie aus Routinegründen, weil er prüfen will, ob die erklärten Maßnahmen den implementierten entsprechen.

Das Dokument beschreibt ein System, das ein deterministisches Scoring-Modell verwendet, auf einem geschlossenen Datensatz trainiert, mit expliziten Regeln für die Klassifizierung der Dringlichkeit. Die Verarbeitungszwecke sind vier. Die Rechtsgrundlagen sind dem korrekten Erwägungsgrund der Verordnung zugeordnet. Die Rechte der betroffenen Personen sind einzeln aufgeführt, mit den operativen Verfahren, sie auszuüben. Grenzüberschreitende Datenflüsse existieren nicht, weil alles im europäischen Rechenzentrum des Anbieters bleibt. Der Berater liest, macht ein paar Notizen, dann hebt er den Blick und fragt den CIO, ob er das System im Betrieb sehen kann.

Das System im Betrieb ist ein anderes. Drei Monate nach der Unterzeichnung der DSFA hat der Anbieter das deterministische Modell durch einen neuronalen Klassifikator ersetzt, der kontinuierlich auf den klinischen Daten der letzten sechs Monate trainiert. Der Datensatz ist nicht mehr geschlossen. Die Klassifizierungsregeln sind nicht mehr explizit. Die offiziellen Zwecke sind weiterhin vier, aber eine fünfte Funktion wurde auf Anfrage der Notaufnahme hinzugefügt, und es ist eine Funktion, die die DSFA nicht vorsieht. Grenzüberschreitende Datenflüsse existieren weiterhin nicht, bis sie eines Tages doch existieren, weil der Anbieter den Hyperscaler gewechselt hat und nun ein Teil des Datenverkehrs durch ein irisches Rechenzentrum läuft, das von einer US-amerikanischen Tochtergesellschaft betrieben wird. Nichts davon ist anderswo dokumentiert. Das System funktioniert. Die Nutzer sind zufrieden. Die internen Audits werden bestanden, weil sie sich darauf beschränken zu prüfen, dass das System existiert und kohärenten Output liefert.

Der Berater wendet sich an den CIO und fragt, wer die fünfte Funktion autorisiert hat. Der CIO antwortet, es sei eine dringende Anfrage des Notaufnahmeleiters gewesen, in einer Woche bearbeitet, mit dem Anbieter, der am darauffolgenden Donnerstag nach einem Staging-Test in die Produktion ausgerollt hat. Es gibt ein Jira-Ticket, das die Änderung verfolgt, eine Pull Request, von zwei Reviewern genehmigt, ein internes Changelog. Alles in Ordnung auf operativer Ebene. Der Berater fragt, ob die DSFA aktualisiert wurde. Der CIO sieht ihn an mit dem Ausdruck eines Menschen, der nie daran gedacht hat, dass es nötig wäre, weil die DSFA zu einem anderen Kreislauf gehört, von einer anderen Person verwaltet, in einem anderen Ordner, mit Zeiten, die nichts mit den Zeiten der Releases zu tun haben. Der Berater schließt die DSFA und nennt sie nicht mehr DSFA. Er nennt sie Geister-Spezifikation, weil sie ein System beschreibt, das nur auf unterzeichnetem Papier existiert.

Eine gewöhnliche Bedingung

Die Geister-Spezifikation ist, entgegen verbreiteter Meinung, eine gewöhnliche Bedingung. Wer in einer Organisation gearbeitet hat, die Software für einen regulierten Kunden produziert, oder für sich selbst unter reguliertem Regime, weiß, dass sich zwischen dem Dokument, das das System beschreibt, und dem System, das tatsächlich in Betrieb ist, nach einigen Monaten ein Abstand öffnet, der jede Woche wächst und den niemand zu schließen beauftragt ist. Nicht, weil jemand lügt. Sondern weil der Code einen Stoffwechsel hat, den die Spezifikation nicht hat, und weil der Lebenszyklus der Spezifikation in der Software, die wir wirklich machen, von keinem Werkzeug verwaltet wird, das mit jenen vergleichbar wäre, die wir für den Code haben.

Der Einwand, den man gewöhnlich gegen diesen Punkt hört, ist vernünftig und muss adressiert werden, bevor man weitergeht. Der Einwand sagt: Der Code ist die wahre Spezifikation. Die Dokumentation ist eine vereinfachte Projektion des Systemverhaltens, und sie ist per Definition verspätet, daher ist die einzig sinnvolle Strategie, den Code in Ordnung zu halten und zu akzeptieren, dass der Rest Literatur ist. Das ist das Prinzip code as documentation in einer etwas anspruchsvolleren Variante, und es hat die Ingenieurkultur der Software seit mindestens zwanzig Jahren beherrscht. Es funktionierte, weil es auf einer impliziten Annahme beruhte, die heute nicht mehr stimmt: dass Software auf der Grundlage dessen beurteilt wird, was sie tut, wenn sie läuft.

Der neue Bewertungsstatus

Software wird unter dem juristischen Regime, das sich in Europa zwischen 2024 und 2027 konsolidiert, nicht mehr nur auf der Grundlage dessen beurteilt, was sie tut. Sie wird auf der Grundlage dessen beurteilt, was sie versprochen hat zu tun, und das Versprechen lebt in der geschriebenen Spezifikation, nicht im ausgeführten Code. Die Überarbeitung der Product Liability Directive, Ende 2024 angenommen, mit Umsetzungsfrist 9. Dezember 2026, hat Software ausdrücklich in den Produktbegriff einbezogen. Das bedeutet, dass der Hersteller von Software für Schäden haftet, die durch Mängel des Produkts verursacht werden, nach einem Regime der verschuldensunabhängigen Haftung. Zu diesem Punkt habe ich vor einiger Zeit einen Text geschrieben mit dem Titel Die letzte Flasche von Mrs Donoghue, der den Gründungsfall der Produzentenhaftung im englischen Recht von 1932 wiederaufnahm und auf die zeitgenössische Software projizierte. Was ich dort nur angedeutet hatte und was ich hier in den Fokus rücken möchte, ist die epistemologische Konsequenz des neuen Regimes. Der Begriff des Mangels deckt sich unter der verschuldensunabhängigen Haftung nicht mit dem Bug. Er deckt sich mit dem Abstand zwischen dem, was man legitimerweise vom Produkt erwarten konnte, und dem, was das Produkt tatsächlich getan hat. Legitime Erwartungen werden, in Ermangelung anderer Parameter, aus der technischen Dokumentation des Produkts rekonstruiert, aus den Erklärungen des Herstellers, aus Werbematerialien, aus den in den Risikobewertungen kartierten Konformitätsanforderungen. Sie werden, mit anderen Worten, aus der Spezifikation rekonstruiert.

Der Cyber Resilience Act, voll anwendbar ab dem 11. Dezember 2027, macht denselben Schritt auf der Sicherheitsseite. Konformität wird durch die technische Dokumentation des digitalen Produkts nachgewiesen, und diese Dokumentation umfasst die Risikobewertung, die implementierten Sicherheitsmaßnahmen, die aktualisierte SBOM, die Verfahren zum Umgang mit Schwachstellen, den Supportplan und die Updates für den Lebenszyklus des Produkts. Der AI Act verlangt für Hochrisiko-Systeme eine noch umfangreichere technische Dokumentation, definiert in Anhang IV, die die architektonische Beschreibung des Systems umfasst, die für das Training verwendeten Datensätze und die Verfahren der Datenverwaltung, die Performance- und Genauigkeitsmetriken, das in Artikel 9 vorgesehene Risikomanagementsystem, die Verfahren der Marktbeobachtung nach dem Inverkehrbringen. Es sind unterschiedliche Verordnungen mit unterschiedlichen Anwendungsbereichen, aber mit einer identischen epistemischen Struktur. Das Software-Produkt hat seinen Bewertungsstatus geändert. Es wird als Übereinstimmung zwischen einem geschriebenen Versprechen und einem beobachteten Verhalten beurteilt, und wenn die beiden auseinanderfallen, sieht der Richter oder die Aufsichtsbehörde auf das geschriebene Versprechen. Nicht, weil sie glauben, die Spezifikation sei das wirkliche System. Sondern weil die geschriebene Spezifikation der einzige Fixpunkt ist, auf dem ein Urteil gegründet werden kann.

Eine kleine Rahmen-Präzisierung ist hier nötig, um ein leicht aufkommendes Missverständnis zu vermeiden. Ich behaupte nicht, dass das europäische Regime die Spezifikation in ein magisches Objekt verwandle, das unabhängig vom System gelte. Der Richter oder die Behörde beschränkt sich nicht darauf, das Dokument zu lesen und Konformität zu erklären. Sie konfrontieren das Dokument mit dem System, bewerten die Kohärenz, hören technische Sachverständige an. Was sich gegenüber dem vorherigen Regime ändert, ist, dass das Dokument aufhört, ein Anhang des Produkts zu sein, und zu einem konstitutiven Teil der Bewertung wird, auf derselben Ebene wie das Verhalten des Systems. Wenn die beiden auseinanderfallen, wird das Dokument nicht mehr automatisch als überholt abgetan. Der Hersteller muss erklären, warum er ein anderes System ausgeliefert hat als das beschriebene, und diese Erklärung ist in einem Rechtsstreit erheblich teurer, als sie es heute ist.

Alles für den Code, fast nichts für die Spezifikation

Angesichts dieser Verschiebung verfügt die Industrie über ein Arsenal an Werkzeugen, um den Lebenszyklus des Codes zu verwalten, und über fast nichts, um den Lebenszyklus der Spezifikation zu verwalten. Der Code hat atomare Versionierung, und wenn sich eine Zeile ändert, gibt es einen Commit mit Autor, Datum und Nachricht. Er hat Blame, das es erlaubt, den Ursprung jeder im Quelltext sichtbaren Entscheidung zurückzuverfolgen. Er hat Tests, die automatisch fehlschlagen, wenn das Verhalten von einer kodifizierten Erwartung abweicht. Er hat Deprecation Warnings, die ein zurückgenommenes Versprechen signalisieren. Er hat sicheres Refactoring, gestützt auf Type-Systeme und Regressionssuiten. Er hat Code Review, in Pull Requests ritualisiert, die eine Spur hinterlassen. Er hat Continuous Integration, die verhindert, dass eine inkompatible Änderung unbemerkt in den Hauptzweig eindringt. Er hat Branch Protection Rules, die physisch verhindern, dass der Prozess umgangen wird. Er hat Rollback in einem Befehl, was die Kosten des Fehlers reduziert. Jedes dieser Werkzeuge ist das Produkt eines ingenieurmäßigen Drucks, der sich in den letzten dreißig Jahren angesammelt hat, und ist heute Infrastruktur der täglichen Praxis, derart verstoffwechselt, dass jene, die jetzt in das Handwerk eintreten, sie als selbstverständlich nehmen und sich kaum eine Welt ohne sie vorstellen können.

Die Spezifikation hat ihre Version, und das war’s. Eine DSFA wird unterzeichnet, datiert, als PDF archiviert, und in dem Moment, in dem sich das System ändert, gibt es keinen automatischen Mechanismus, der dem Unterzeichner oder dem Beauftragten sagt, dass seine Unterschrift jetzt ein anderes System abdeckt. Architekturentscheidungen, die in ADRs festgehalten sind, sammeln sich in Confluence, in Notion, in SharePoint-Ordnern, und niemand liest sie wieder, es sei denn, ein spezifisches Audit verlangt es. Sicherheitsanforderungen, die Verträgen beigefügt sind, werden unterzeichnet, im CRM hinterlegt, und existieren von da an als Backoffice-Anhänge bis zur Verlängerung. Die für die Konformität mit dem AI Act bei Hochrisiko-Systemen erstellten Risikobewertungen werden periodische Aktualisierungen erfordern, aber der Mechanismus, der die Aktualisierung an konkrete Änderungen des Systems bindet, wird in der überwiegenden Mehrzahl der Fälle ein Kalender oder ein vertraglicher Trigger sein, kein Code-Ereignis. Die Spezifikation hat, anders als der Code, keinen inneren Druck, aktuell zu bleiben. Sie überlebt in einer Zone der langsamen Zeit, in der die Unterschrift mehr zählt als die Frische, und in der das Altern sich nicht als funktionale Verschlechterung manifestiert, sondern als fortschreitende Entfernung von der Realität, die das Dokument beschreiben sollte.

Die Gründe für diese Asymmetrie sind kultureller Art. Technisch existieren die Werkzeuge, um Spezifikationen mit derselben Ernsthaftigkeit wie Code zu behandeln, seit Jahrzehnten. Ausführbare Spezifikationen im BDD-Stil, in Gherkin geschriebene Test-Spezifikationen, formale Verträge in Sprachen wie TLA+ oder Alloy, Schnittstellenspezifikationen in OpenAPI oder gRPC, Beweisassistenten wie Lean oder Coq. Jedes dieser Systeme setzt voraus, dass die Spezifikation ein erstklassiges Artefakt ist, ausführbar oder verifizierbar, lebendig im Repository neben dem Code. In der industriellen Praxis ist nichts davon die Norm. Die Norm ist, dass die Spezifikation in einem Word-Dokument lebt, von einer Person aus dem Recht oder der Compliance überarbeitet wird, unterzeichnet wird, archiviert wird, und ihr Schicksal ist von dem Moment an vom Schicksal des Codes getrennt.

Der agile Ursprung

Der Ursprung dieser Trennung ist historisch und verdient es, mit einigen Details rekonstruiert zu werden. Die Software-Kultur ist in Opposition zur Dokumentations-Kultur aufgewachsen, weil Dokumentation als Auflage des Engineering-Managements im Wasserfall-Stil wahrgenommen wurde, und Agile hat unter anderem deshalb gewonnen, weil es versprach, das Gewicht des Dokuments zugunsten von funktionierender Software zu reduzieren. Das Agile Manifest, im Februar 2001 in Snowbird unterzeichnet, sagt ausdrücklich „working software over comprehensive documentation“. Die Formulierung war vorsichtig, weil die Autoren am Ende des Dokuments schrieben „while there is value in the items on the right, we value the items on the left more“, die Dokumentation wurde also relativiert, nicht abgeschafft. Aber die industrielle Lesart der zwei folgenden Jahrzehnte war drastischer als die ursprüngliche Formulierung. Umfassende Dokumentation wurde zum Synonym für überflüssige Dokumentation, und Projekte, die es wagten, mehr als ein README, ein paar Kommentare und eine Handvoll Diagramme zu produzieren, gerieten in Verdacht, restliche Wasserfall-Praktiken zu pflegen. Das Versprechen war in seinem Kontext sinnvoll, weil die Software, die in den frühen 2000ern geschrieben wurde, an funktionalen und kommerziellen Kriterien gemessen wurde, und das Dokument war tatsächlich ein Kostenposten, der nach den ersten Wochen des Projektlebens wenig informativen Wert produzierte. Es war auch ein politischer Kostenposten, weil es oft dazu benutzt wurde, Gate-Keeping-Prozesse zu erzwingen, die die Arbeit verlangsamten, ohne Qualität hinzuzufügen.

Was sich geändert hat und was die Ingenieurkultur noch nicht verarbeitet hat, ist der Bewertungskontext. Die Software, die wir heute schreiben, wird in regulierten Märkten verkauft, in Lieferketten integriert, die sie als zertifiziertes Bauteil behandeln, Konformitätspflichten unterworfen, die lebendige Dokumentation verlangen. Das Dokument hat aufgehört, das interne Werkzeug einer Bürokratie zu sein, die Entwickler kontrollieren will. Es ist zum Werkzeug geworden, durch das sich das Produkt dem Regulator präsentiert, dem regulierten Kunden, dem eventuellen Richter. Die Ingenieurkultur behandelt die Spezifikation weiterhin als Nebenprodukt des Prozesses, während der normative Rahmen sie zum primären Artefakt erhebt. Der Abstand zwischen diesen beiden Wahrnehmungen ist das Terrain, in dem die Spezifikationsschulden ungestört wachsen.

Spec-driven, BDD und ihre Grenzen

Es wäre unredlich vorzugeben, es gäbe keine Versuche, diese Lücke zu schließen, und einige dieser Versuche sind ernsthaft. Das Spec-driven Development in der Form, die es in den letzten zwei Jahren angenommen hat, mit Werkzeugen wie SpecKit von GitHub und mit der Praxis, ein CLAUDE.md pro Projekt als Kontext-Briefing für KI-Agenten zu führen, versucht, den Schwerpunkt der Arbeit vor den Code zu verlagern. Die Spezifikation wird zum Eingang der assistierten Generierung für einen Agenten, der Code, Tests und begleitende Dokumentation in einem einzigen kohärenten Durchgang produziert. Das Versprechen ist, dass die Spezifikation ausführbar sei, in dem Sinn, dass sie ein System produziert, und damit durch den Druck aufrechterhalten wird, funktionierenden Code zu erzeugen. Das ist eine interessante Richtung, und in den Projekten, in denen ich sie angewandt habe, hat sie die Ökonomie der Arbeit auf nicht triviale Weise verändert. Die Zeit, die ich vorher dafür aufgewendet habe, Anforderungen in Code zu übersetzen, hat sich verringert, aber die Zeit, die mit dem Schreiben präziser Anforderungen zugebracht wurde, ist gewachsen, und das ist ein günstiger Trade-off, weil Präzision auch dann einen Restwert hat, wenn der Code neu geschrieben wird.

Die Grenze, die ich nach einigen Monaten Praxis sehe, ist, dass Spec-driven Development die Synchronisation zwischen Spezifikation und Code im Moment der ersten Generierung löst, und das ist ein realer Gewinn, aber die spätere Drift nicht löst. Wenn das System in Produktion geht und in Reaktion auf Kundenanfragen, Vorfälle, Veränderungen der operativen Umgebung verändert wird, kann die formalisierte Spezifikation aktualisiert werden oder auch nicht, und die praktischen Anreize spielen gegen ihre Aktualisierung. Die Spezifikation zu aktualisieren kostet Zeit und Strenge und erzwingt eine Verhandlung zwischen jenem, der die Änderung im Vorbeigehen geschrieben hat, und jenem, der Hüter des Dokuments ist. Unter Delivery-Druck verliert das Dokument. Der Code in Produktion gewinnt immer, weil er das ist, was die Nutzer benutzen. Die Spezifikation wird wieder zum Gespenst, auch wenn sie in einer formalen Sprache geschrieben wurde.

Ausführbare Spezifikationen vom Typ BDD haben dasselbe Problem, in abgeschwächter Form. Eine Gherkin-Suite, die das Verhalten des Systems beschreibt, bleibt synchron, solange jemand sie scheitern lässt und neu ausrichtet, aber wenn der Delivery-Druck steigt, werden Szenarien übersprungen, als pending markiert, gelöscht. Ich habe Suiten von Hunderten von Szenarien gesehen, die innerhalb eines Jahres und einer Hälfte auf einige Dutzend zusammengeschrumpft sind, nicht weil die beschriebenen Verhaltensweisen aus dem System verschwunden waren, sondern weil die Suite zu einer Reibung geworden war, die das Team nicht mehr die Zeit hatte zu verwalten. Die ausführbare Spezifikation bleibt widerstandsfähiger als eine DSFA, weil sie Code ist und damit den Anreizen des Codes unterliegt, aber sie ist nicht immun gegen die Drift. Sie driftet nur langsamer. Und es gibt ein zweites, subtileres Problem. Ausführbare Spezifikationen decken funktionales Verhalten gut ab, also den Teil des Systems, der sich automatisch verifizieren lässt. Sie decken viel weniger den Teil des Systems ab, den die neue europäische Compliance zu dokumentieren verlangt: die Risikobewertung, die architektonischen Entscheidungen, die Verarbeitungszwecke, die Minderungsmaßnahmen. Dieser Teil entzieht sich der Automatisierung, weil er nicht verhaltensbezogen ist, und bleibt konstitutiv für das Produkt als juristisches Objekt. Kein Test-Framework sagt einem, ob er noch kohärent mit dem System ist.

Eine Unterkategorie, kein Synonym

Man könnte an dieser Stelle einwenden, die Spezifikationsschulden seien bereits im allgemeinen Begriff der technischen Schulden enthalten, und davon getrennt zu sprechen sei eine elegante Art, den Mond neu zu entdecken. Der Einwand ist formal richtig. Die Taxonomien der technischen Schulden, die sich in den zwei Jahrzehnten nach Ward Cunninghams ursprünglicher Formulierung entwickelt haben, insbesondere die Arbeiten von Martin Fowler und derjenigen, die das Quadrant der Ursachen verfeinert haben, schließen veraltete Dokumentation als eine Form der Schuld ein. Die Unterscheidung, die ich vorschlage, ist eher ökonomischer als konzeptueller Natur. Klassische technische Schulden haben natürliche Anreize zur Tilgung, weil sie einen verlangsamen, einen täglich irritieren, einem Onboarding und Entwicklungszeit kosten. Spezifikationsschulden haben fast keine Anreize, bis ein auslösendes Ereignis eintritt, und die Anreize, die sie haben, sind bürokratisch und kalendarisch, nicht operativ. Diese Differenz rechtfertigt es, sie als Unterkategorie mit eigenen Dynamiken zu behandeln, vor allem jetzt, da der normative Rahmen sie asymmetrisch gegenüber den anderen Schuldformen mit Wert auflädt.

Was ich Spezifikationsschulden nenne, ist die unsichtbare Version der technischen Schulden. Die technischen Schulden sind der Preis, den man in Form von langsamer Entwicklung, wiederkehrenden Bugs, schwierigem Onboarding bezahlt. Es ist ein Preis, den man kontinuierlich, in kleinen Raten bezahlt, und der einen motiviert, in das Refactoring zu investieren, weil man den Schmerz spürt. Die Spezifikationsschulden spürt man nicht. Sie verlangsamen die Entwicklung nicht, weil derjenige, der entwickelt, die Spezifikation nicht liest, und wenn er sie liest, findet er sie oft als historische Referenz nützlich, aber nicht bindend. Sie erzeugen keine Bugs, weil der Code aus Sicht der Ausführung schon die wahre Spezifikation ist. Sie behindern das Onboarding nicht, weil der, der ins Team eintritt, vom Code und von Kollegen lernt, nicht von archivierten Dokumenten. Die Spezifikationsschulden produzieren nur eine Art von Schaden, und sie produzieren ihn dann, wenn ein Ereignis einen zwingt, sich der Spezifikation als bindendem Objekt zu stellen. Ein Audit Dritter. Ein Sicherheitsvorfall, der zum Gerichtsfall wird. Ein Auskunftsersuchen zu personenbezogenen Daten, auf das man nicht antworten kann, weil die Verarbeitungslandkarte für ein anderes System erstellt worden war. Eine Beanstandung eines Kunden, der den Vertrag gelesen hat und mit einigem Recht erklärt, etwas gekauft zu haben, das ihm nicht geliefert wurde.

Wenn dieses Ereignis eintritt, werden die Spezifikationsschulden auf einen Schlag sichtbar, und der Preis ist gegenüber den technischen Schulden asymmetrisch. Technische Schulden zahlt man in Raten, Spezifikationsschulden zahlt man in einer einzigen Rate, in der Regel höher als die Summe der Raten, die man bezahlt hätte, wenn man sie über die Zeit verwaltet hätte. Es gibt auch einen Unterschied in der Natur des Kostenpostens. Technische Schulden zahlt man in Entwicklungszeit, und diese Zeit hat man selbst unter Kontrolle. Spezifikationsschulden zahlt man in Anwaltszeit, in externen Beratern, in außerordentlichen Audits, in auferlegten Abhilfemaßnahmen, und in Reputation, die die teuerste Währung von allen ist, weil sie sich nicht refinanziert. Schließlich gibt es einen zeitlichen Unterschied, den niemand bemerkt, bis er ihn auf den Kopf bekommt. Die technischen Schulden zahlt man schrittweise, während man arbeitet. Die Spezifikationsschulden zahlt man auf einen Schlag, während man etwas anderes tut, und in der Regel zu einem Zeitpunkt, an dem man keinen Spielraum hat. Die Krisen, die sie offenlegen, kommen immer im schlechtest möglichen Moment, weil sie der Moment sind, an dem jemand anderes beschlossen hat, anzusehen, was man selbst nicht angesehen hat.

Archäologie und Aktivposten

In den letzten Monaten ist es mir passiert, an einer Compliance-Bewertung für ein klinisches Workflow-Management-System zu arbeiten, das für ein großes Forschungskrankenhaus entwickelt worden war, und der Kunde des Kunden, also die endgültige klinische Stiftung, hatte einen Sicherheitsanhang mit zehn Kontrollbereichen verlangt, die auf Artikel 28 DSGVO und auf eine Liste branchenspezifischer Anforderungen abgebildet werden sollten. Die ursprüngliche Spezifikation des Systems war drei Jahre zuvor verfasst worden, zu einem Zeitpunkt, als das System eine relativ einfache Plattform zur Datenerhebung war. In der Zwischenzeit war das System gewachsen, hatte Verarbeitungsmodule erworben, war an Drittsysteme angebunden worden, hatte den Hosting-Anbieter gewechselt. Der Abstand zwischen dem Ausgangsdokument und dem aktuellen System war enorm. Die Arbeit, die ich sechs Wochen lang machen musste, bestand im Wesentlichen darin, die Spezifikation aus dem System zu rekonstruieren, also Reverse Engineering des Verhaltens zu betreiben, um ein neues Dokument zu schreiben, das mit der Realität kohärent war.

Das operative Detail dieser Arbeit ist lehrreich, weil es erzählt, was es wirklich bedeutet, die Spezifikationsschulden zu verwalten, wenn sie zur Verantwortung gerufen werden. Ich musste mit sechs verschiedenen Personen sprechen, jede Hüterin eines nicht dokumentierten Wissensteils. Ich musste den Code von drei Microservices lesen, die nach der Unterzeichnung der DSFA hinzugefügt worden waren. Ich musste einen externen Anbieter ausfindig machen, um ihn zu fragen, welchen Anonymisierungsalgorithmus er auf die Daten anwendete, die durch ihn liefen, weil niemand im internen Team es genau wusste. Ich musste den Fluss der personenbezogenen Daten zwischen fünf verschiedenen Systemen rekonstruieren, indem ich Netzwerkkonfigurationen und Anwendungs-Logs ansah, weil das ursprüngliche Diagramm unbrauchbar geworden war. All diese Arbeit war der Entwicklung fremd. Sie war reine Rekonstruktion einer dokumentarischen Wahrheit, die im Lauf der Zeit hätte gepflegt werden müssen und stattdessen von Grund auf neu geschrieben werden musste. Es war genau die Operation, die das normative Regime voraussetzt, dass sie nie nötig sei, weil die Spezifikation auf dem Weg gepflegt worden sein sollte, und es war genau die Operation, die fast immer nötig ist, weil der Weg nie so verwaltet wird.

In einem anderen Projekt, einer Plattform zur juristischen Risikobewertung für eine spezialisierte Kanzlei, haben wir an einem bestimmten Punkt entschieden, den gesamten Stack von Python zu Laravel 12 zu migrieren. Die Migration ist im Gang, und wir sind bei rund achtundsiebzig Prozent. Was ich in dieser Migration gelernt habe, ist, dass der wirklich übertragene Aktivposten nicht der Code war, sondern die funktionale Spezifikation. Der Python-Code ist zum großen Teil weggeworfen und neu geschrieben worden, das Datenmodell ist neu entworfen worden, die Framework-Entscheidungen haben sich radikal geändert. Was überlebt hat, ist das präzise Wissen, formalisiert in der Produktdokumentation und in den Verträgen mit dem Kunden, darüber, was das System tun muss, in welcher Reihenfolge, mit welchen Einschränkungen, gegenüber welchen externen Schnittstellen. Ohne diese Spezifikation wäre die Migration unmöglich gewesen. Mit dieser Spezifikation, und mit einem Team, das sie während der Arbeit als aktive Referenz behandelte, ist die Migration schwierig, aber machbar gewesen.

Der Unterschied zwischen diesem Projekt und dem klinischen Fall, der oben erzählt wurde, ist ein Unterschied der Praxis, nicht der Natur der Spezifikation. In beiden Fällen existierte eine geschriebene Spezifikation. Im klinischen Fall war die Spezifikation unterzeichnet und dann verlassen worden. Im Fall der Migration wurde die Spezifikation alle vierzehn Tage in der Retrospektive gelesen, beanstandet, wenn das Team Inkohärenzen fand, modifiziert, wenn eine Produktentscheidung sich änderte, ergänzt, wenn eine Funktion hinzugefügt wurde. Sie war ein lebendiges Objekt im Prozess, kein Erbstück der Compliance. Es ist dieselbe Unterscheidung, die ein Flughandbuch, das der Pilot vor jedem Start liest, von demselben Handbuch trennt, das in einer Bibliothek archiviert ist. Derselbe Text, zwei völlig verschiedene Funktionen, und zwei nicht vergleichbare operative Werte. Die Spezifikation als übertragbarer Aktivposten und die Spezifikation als Aktivposten, der je nach Behandlung altert oder nicht altert, sind zwei Seiten derselben Sache.

Die Werkzeuge, die uns noch fehlen

Eine Hypothese, die mir vernünftig erscheint, ist, dass das nächste Jahrzehnt der Software-Ingenieurkunst durch Werkzeuge für den Lebenszyklus der Spezifikation definiert werden wird, die jenen analog sind, die das vergangene Jahrzehnt für den Lebenszyklus des Codes definiert hat. Schon heute beginnen die ersten ernsthaften Versuche sichtbar zu werden. Nachverfolgbarkeitssysteme, die die Spezifikationsanforderungen an die Tests binden, die sie verifizieren, und die Tests an die Code-Änderungen, die sie berühren, so dass das System weiß, welche Anforderung beeinträchtigt wurde, wenn ein Test sich ändert, und die Aktualisierung des Dokuments anfordert. Drift-Detection-Werkzeuge auf Architekturen, die die deklarierte Service-Topologie mit der beobachteten Topologie vergleichen und Divergenzen melden. Versionierung von DSFA in Git-Repositories mit obligatorischen Reviews bei jeder strukturellen Änderung des Systems. Produktspezifikationen, die als versionierte Objekte neben dem Code leben, mit einer CI, die fehlschlägt, wenn der Abstand zwischen Spezifikation und Implementierung einen Schwellenwert überschreitet.

Ich versuche mir vorzustellen, wie die tägliche Praxis in fünf Jahren aussehen könnte, in einem Team, das diese Wende verarbeitet hat. Die DSFA hat ihre Form verändert und lebt als YAML-Datei in einem geschützten Repository, mit Versionsgeschichte, Autoren der Änderungen, Genehmigungsprozess durch Pull Requests. Wenn ein Entwickler eine neue Verarbeitung personenbezogener Daten einführt, erkennt eine Pipeline für statische Code-Analyse den neuen Datenfluss und markiert den Pull Request automatisch als „DSFA-relevant“. Der Merge bleibt blockiert, bis der Datenschutzbeauftragte die entsprechende Änderung des Verarbeitungsdokuments prüft und genehmigt. Die AI-Act-Risikobewertungen folgen einem analogen Mechanismus, mit Drift-Detektoren, die melden, wenn das Modell in Produktion von den in der technischen Dokumentation erklärten Metriken abweicht. Die SBOMs aktualisieren sich automatisch bei jedem Build und produzieren lesbare Diffs, die in die Produkt-Changelogs eingehen. All das eliminiert die Compliance-Arbeit nicht, aber es verwandelt sie aus rekonstruktiver Archäologie, wie jener, die ich sechs Wochen lang am klinischen System gemacht habe, in kontinuierliche Wartung, integriert in denselben Rhythmus wie die Entwicklungsarbeit. Der kulturelle Sprung, der zu machen ist, besteht im Verständnis, dass die Dokumentation des Systems unter diesem neuen Regime den Aufbau des juristisch relevanten Aktivpostens des Produkts darstellt und keinen administrativen Kostenposten, den es zu minimieren gilt. Wer es jetzt nicht tut, wird es in fünf Jahren tun, nachdem er einen Prozess verloren hat, und in diesem Moment wird es teurer sein.

Körper und Seele

Vor einigen Monaten habe ich auf diesem Blog einen Text geschrieben mit dem Titel Cruft, keine Patina, und das zentrale Argument war, dass die Software nicht so altern kann wie materielle Objekte, weil die Drift zwischen dem Code und der Umgebung, in der er läuft, ihn schneller erodiert, als die Ingenieurkultur sie verstoffwechseln kann. Es gab eine Passage, die von Unix als Ausnahme sprach, weil sich in Unix die Spezifikation vom Code abgelöst hatte und zu Kultur geworden war, die durch Zyklen vollständiger Umschreibung des Körpers überlebt. Diese Passage schloss mit einer Note vorsichtigen Optimismus zu der Tatsache, dass die Spezifikation, wenn sie sich ablöst, der stabile Plan ist, der den Wandel durchquert.

Ich muss diese Note qualifizieren. Die Spezifikation löst sich vom Code auf zwei verschiedene Arten, und der Unterschied zwischen den beiden entscheidet alles. Die erste Art ist die von Unix, in der die Spezifikation zu geteilter Kultur wird, in kanonischen Büchern beschrieben, von einer Gemeinschaft gepflegt, die sie auf neue Kontexte anzuwenden weiß, und die sich daher erneuert, ohne ihre Identität zu verlieren. Die zweite Art ist die der archivierten DSFA, in der die Spezifikation zu einem unterzeichneten Dokument wird, das nicht mehr gelesen wird, und das daher mit sich selbst identisch bleibt, während das System ein anderes wird. Im ersten Fall produziert die Ablösung Kontinuität. Im zweiten produziert die Ablösung Geister-Spezifikation. Der Unterschied zwischen den beiden Arten liegt nicht in der Natur der Spezifikation. Er liegt in den Praktiken derer, die sie benutzen. Eine Spezifikation, die gelesen, beanstandet, modifiziert, neu diskutiert, auf neue Fälle angewandt wird, ist eine Spezifikation, die lebt. Eine Spezifikation, die geschrieben, unterzeichnet, archiviert und dann bis zum nächsten Audit ignoriert wird, ist eine Spezifikation, die langsam stirbt, während niemand hinsieht.

Wenn ich die beiden Essays zusammensetze, ist das allgemeine Argument, das ich zu konstruieren versuche, dieses. Die Software hat ein doppeltes Problem mit der Zeit. Auf der einen Seite kann der Code nicht altern, weil seine Umgebung sich zu schnell ändert und die Drift ihn in Cruft verwandelt, statt in Patina. Auf der anderen Seite kann die Spezifikation, die der stabile Plan sein könnte, der die Umschreibung des Codes durchquert, das nur sein, wenn eine konstante Praxis sie am Leben erhält, und in der überwiegenden Mehrheit der Fälle gibt es diese Praxis nicht. Das Ergebnis ist, dass die Software unter dem juristischen Regime, das sich in Europa konsolidiert, in eine Epoche eintritt, in der sowohl der Körper als auch die Seele des Produkts fragil sind, und in der das Einzige, was die beiden Ebenen zusammenhalten kann, eine Disziplin der dokumentarischen Pflege ist, die die Ingenieurkultur erst noch aufbauen muss. Die Ingenieurkultur der Software hat die beiden Dinge noch nicht mit der nötigen Klarheit unterschieden, weil sie die Spezifikation lange Zeit als Nebenprodukt behandelt hat. Der normative Rahmen, der sich in Europa konsolidiert, zwingt sie, diese Unterscheidung zu treffen, und der Preis der nächsten Jahre wird von dem bezahlt, der es nicht rechtzeitig bemerkt.

Spezifikationsschulden sind die technischen Schulden, die man nicht sieht, bis sich jemand verletzt. Wir sammeln sie still an, in SharePoint-Ordnern, die niemand öffnet, in unterzeichneten PDFs, die keine getreue Darstellung der Systeme mehr sind, die sie zertifizieren, in DSFA, die auf dem Compliance-Server abgelegt sind, als wären sie Monumente. Der erste große europäische Gerichtsfall zur Software-Produkthaftung unter dem neuen Regime der Product Liability Directive wird über die Spezifikation entschieden. Wenn er kommt, und er wird bald kommen, wird sich die Industrie aufteilen in jene, die ihre Spezifikation am Leben gehalten haben, und jene, die nur fortgefahren sind, sie zu unterzeichnen.

Es ist Mittwochnachmittag. Du hast gerade in zwanzig Minuten eine Aufgabe erledigt, die dich vor sechs Monaten einen halben Tag gekostet hätte. Der Bildschirm steht still. Der Nachmittag öffnet sich vor dir. Nach jeder äußeren Metrik müsstest du etwas spüren, das einem Triumph nahekommt. Stattdessen ist da eine dumpfe, ungerechtfertigte Müdigkeit, die du nicht recht zuordnen kannst. Die gewonnenen Stunden haben sich nicht zu deinem Leben addiert. Sie haben den Tag nur fremd gemacht.

Die Standarderklärung — wir seien müde, weil wir mehr in denselben Tag gepresst haben — ist falsch oder zumindest unzureichend. Viele von uns tun, gemessen an der Uhr, weniger und fühlen sich leerer. Die Erschöpfung ist nicht quantitativ, sie ist eine Frage der Textur. Etwas hat sich in der Art und Weise, wie wir den Arbeitstag bewohnen, verschoben, und wir haben noch keine Worte dafür.

Uhrenzeit, gelebte Zeit, und eine dritte Sache

Seit mehr als einem Jahrhundert unterscheidet die Philosophie zwei Arten, die Zeit zu bewohnen. Es gibt die mathematische Zeit, die Zeit der Uhren und Stundenpläne, teilbar und gleichförmig. Und es gibt die gelebte Zeit, das, was Bergson durée nannte: die Zeit der Erfahrung, in der zehn Minuten Warten länger erscheinen als eine Stunde Versenkung. Beide standen immer in Spannung, liefen aber grosso modo parallel. Ein Arbeitstag hatte acht Stunden Uhrenzeit und eine gefühlte Form, die ihnen ungefähr entsprach, mit einem schweren Anfang und einem Schluss, den man kommen sehen konnte. Wir wussten, wo wir im Tag standen, auch ohne auf die Uhr zu schauen.

Die KI führt eine dritte Sache ein, die es vorher nie gegeben hat. Die Uhr tickt weiterhin gleichförmig. Die gelebte Erfahrung hat noch ihre Schwankungen. Aber die Kostenoberfläche der Tätigkeiten ist wild unregelmäßig geworden, und nicht auf eine Weise, die der Körper antizipieren könnte. Eine Aufgabe, die gestern drei Stunden gefressen hat, braucht heute zwanzig Minuten. Eine andere Aufgabe, oberflächlich ähnlich, braucht weiterhin drei Stunden. Es gibt keine Regel. Die Asymmetrie ist lokal, und sie kommt ohne Vorwarnung. Man wechselt von einem Regime, in dem Arbeit mühsam ist, zu einem, in dem sie banal ist, und wieder zurück, mehrmals am selben Nachmittag, ohne Signale, die ein Anpassen erlauben würden.

Der Körper, der die Karte nicht mehr liest

Der Körper hatte sich in Jahren auf eine präzise Kadenz kalibriert. Er wusste, wie man die Energie über einen Tag verteilt, wann man drücken und wann man verlangsamen muss. Diese Kalibrierung setzte eine relativ stabile Karte der Tätigkeitskosten voraus: Einen Bericht zu schreiben dauerte Stunden, eine E-Mail zu beantworten Minuten, und der größte Teil der geistigen Arbeit verteilte sich in diesem Bereich. Die Karte ist nicht mehr genau. Der Körper macht weiterhin seine Berechnungen auf Kosten, die nicht mehr gelten, und in dieser fortlaufenden Rekalibrierung steckt ein stiller, beständiger Energieverbrauch, den wir nicht einmal beobachten können, während er geschieht.

Eine Müdigkeit ohne Form

Es ist eine andere Müdigkeit als die, die wir kannten. Sie ist nicht die Müdigkeit der Anstrengung. Sie ist die Müdigkeit der Zeit ohne Form, die schwerer zu benennen ist, weil wir wenige Beispiele dafür in unserer Geschichte haben. Selbst die schwersten Zwänge — Gefängnis, Krankheit — neigen dazu, einen eigenen Rhythmus zu erzwingen, und tatsächlich beschreiben jene, die sie hinter sich lassen, oft die Abwesenheit dieses Rhythmus als eines der verstörendsten Dinge bei der Rückkehr ins freie Leben. Auch die Freizeit hat einen Rhythmus, den des Wochenendes gegen den der Werktage, den der Mahlzeiten und Gewohnheiten. Was wir jetzt bewohnen, ist etwas anderes: ein Arbeitstag, dessen Form sich ändert, während wir ihn bearbeiten, und der sich auf kein Muster zurückführen lässt, das stabil genug wäre, sich darin niederzulegen.

Es ist nicht nur ein Übergang

Man könnte einwenden, es sei nur ein Übergang. Gebt dem System Zeit. Wir werden die neue Karte lernen und ein neuer Rhythmus wird entstehen, wie es immer war. Vielleicht. Aber die Analogie zu früheren technologischen Übergängen führt in die Irre, und zwar in einer Weise, die sich auszusprechen lohnt. Die Fabrik erzwang eine brutale, aber lesbare Kadenz, und in wenigen Jahrzehnten hat sich der kollektive Körper der Arbeitenden um diese neue Form rekalibriert. Der Personal Computer hat bestimmte Aufgaben beschleunigt, ihre innere Phänomenologie aber unangetastet gelassen: Schreiben blieb Schreiben, nur auf einer anderen Oberfläche.

Was sich jetzt ändert, ist grundlegender. Die KI beschleunigt die Tätigkeit nicht, sie ersetzt sie durch eine andere. Die dreißig Minuten, die du mit der Formulierung eines Absatzes verbracht hast, werden nicht zu drei schnelleren Minuten komprimiert. Sie werden ersetzt durch neunzig Sekunden, in denen du beschreibst, was du willst, und ein paar Minuten, in denen du das Zurückgekommene überarbeitest. Das ist nicht dieselbe Tätigkeit, beschleunigt. Das sind unterschiedliche Tätigkeiten, mit unterschiedlichen Kosten und unterschiedlichen gefühlten Formen. Der Körper hat nichts, woran er sich rekalibrieren könnte, weil keine neue Normalität lange genug bestehen bleibt.

Die Gedanken, die nicht erreicht werden

Es gibt auch etwas, das wir verlieren, wenn die Textur des Tages flach wird, und es lohnt sich, ihm ins Gesicht zu sehen. Die Tradition des deep work, auch wenn sie von einer bestimmten Produktivitätsrhetorik aufgesogen wurde, deutete auf etwas Wirkliches und Subtiles: Bestimmte Arten des Denkens geschehen nur in lang anhaltenden, gleichförmigen Strecken. Die Morgenstunden, die wir für die schwierige Aufgabe schützten, waren nicht einfach Stunden höherer Qualität. Es waren Stunden, die die Aufgabe selbst möglich machten. Manche Gedanken erreicht man erst nach vierzig Minuten gehaltener Aufmerksamkeit, und man kommt nicht hin in vier mal acht Minuten.

Wenn die Textur des Tages fragmentiert und unvorhersehbar wird, werden diese Gedanken einfach nicht erreicht. Wir bemerken ihre Abwesenheit nicht direkt, denn was nicht gedacht wird, hinterlässt keine sinnliche Spur. Wir bemerken sie als eine Art kognitiver Verdünnung, einen schnelleren Output, der irgendwie leichter ist, das fremde Gefühl, viel zu produzieren und wenig zu denken, ohne sagen zu können, worin der Unterschied genau besteht.

Gerüste gegen die Asymmetrie

Ich habe keine Formel dafür, was man mit all dem anfangen soll, und ich misstraue jenen, die sie schon parat haben. Die Antworten des productivity genre — die meist vorschlagen, dem neuen Chaos durch gepanzerte Kalender und gegen die Asymmetrie errichtete Morgenrituale eine künstliche Struktur aufzuzwingen — können in Einzelfällen helfen. Sie behandeln das zugrundeliegende Phänomen nicht, nämlich dass die natürliche Form des Tages eine wirkliche Sache war, getragen von den relativen Kosten der Tätigkeiten, und dass diese Kosten sich strukturell verändert haben. Die künstliche Struktur ist ein Gerüst, das versucht, ein Gebäude zu halten, dessen Fundamente sich verschoben haben. Sie kann eine Weile funktionieren, und sie zermürbt jene, die sie aufrechterhalten.

Was ich an mir selbst bemerke, und an den Kolleginnen und Kollegen, die mit mir darüber sprechen, wenn genug Vertrauen da ist, um die Produktivitätsrhetorik zu verlassen, ist, dass die Erschöpfung an den Tagen am schärfsten ist, an denen wir uns am meisten bemüht haben, die gewonnene Zeit zu nutzen. Der Mittwochnachmittag, an dem die Aufgabe in zwanzig Minuten zusammengebrochen ist und wir die übrigen Stunden mit anderen Aufgaben gefüllt haben, endet mit einer besonderen Müdigkeit, die nicht von der Arbeit kommt, sondern von der inneren Gewalt, so zu tun, als wäre die Zeit, die wir gelebt haben, die Zeit, die wir gemessen haben. Der Mittwochnachmittag, an dem die Aufgabe in zwanzig Minuten zusammengebrochen ist und wir innegehalten haben — an dem wir spazieren gegangen sind oder geblieben sind, um die Fremdheit des Nachmittags anzusehen, ohne sie zu renormalisieren — endet anders. Nicht produktiv im alten Sinn. Aber der Körper erkennt, dass etwas geehrt wurde, und diese sauberere Müdigkeit ist eine andere Sache als die erste.

Ein neuer Respekt vor der Abwesenheit von Rhythmus

Vielleicht braucht es nicht einen neuen Rhythmus, sondern einen neuen Respekt vor der Abwesenheit von Rhythmus, zumindest solange sie dauert. Der alte Tag hatte eine Form, weil die Arbeit eine Form hatte, weil die Kosten eine Form hatten. Nichts davon kommt in dem Gewand zurück, in dem wir es kannten. Den Tag mit Gewalt wieder aufzubauen, durch immer kunstvollere Gerüste, wird weiterhin die diffuse Erschöpfung erzeugen, die wir alle mit uns tragen, ohne sie zu benennen. Den Tag das fremde Ding sein zu lassen, das er geworden ist — mal ein Sprint, mal eine leere Strecke —, könnte uns wenigstens die Energie zurückgeben, die wir in das nutzlose Vorhaben stecken, so zu tun, als hätte sich nichts geändert. Es ist eine Teilkapitulation, gewiss. Aber manche Kapitulationen sind das Vorspiel zu einer Art, in den Dingen zu sein, die uns der Widerstand nie gewährt hätte.

Das ist kein Optimismus. Der asymmetrische Tag mag ein schlechterer Tag zum Leben sein als der strukturierte davor, und ich bin nicht sicher, wie es ausgehen wird. Worüber ich sicher bin: Die Erschöpfung bei ihrem wirklichen Namen zu nennen, ist das Erste, was wir uns selbst und unseren Kolleginnen und Kollegen schulden — wir sind nicht müde, weil wir mehr getan haben, wir sind müde, weil wir in einer Zeit gelebt haben, die ihre Form verloren hatte, und weiter so getan haben, als wäre die Form noch da.

„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.

Erst einige Tage später, als ich es in Ruhe am Schreibtisch las, verstand ich, was mich störte. Das Template war keine detailliertere Version des vorigen. Es war etwas anderes. Kein verbessertes Formular, kein feineres Raster: Das Dokument, das ich in der Hand hielt, verlangte etwas anderes von dem, der es ausfüllt, und auf subtilere Weise verlangte es etwas anderes auch von dem, der es liest. Die DSFA hörte auf, ein Formular zu sein, und wurde — um einen Begriff aufzugreifen, den ich in meinen Universitätsjahren lange durchdacht habe — zu einer Gattung.

Was angekommen ist und was nicht

Es lohnt sich, gleich zu präzisieren, was angekommen ist und was nicht, denn die Nuance macht für den gesamten weiteren Gedankengang einen Unterschied. Der EDPB hat das Template in Version 1.0 im schriftlichen Verfahren am 10. März verabschiedet, hat es im April zusammen mit einem Explainer-Dokument veröffentlicht, das jeden Abschnitt begleitet, und hat es bis zum 9. Juni zur öffentlichen Konsultation freigegeben. Die Verwendung des Templates ist nicht verpflichtend: Verantwortliche können weiterhin die DSFA-Methodologien nutzen, die sie bevorzugen. Nach der Konsultation und mit den eventuell eingeführten Änderungen werden alle nationalen Datenschutzbehörden die Schritte einleiten, um es als eigenen Standard oder als Meta-Template zu übernehmen, an dem sich nationale Modelle ausrichten müssen. Nichts ist also schon abgeschlossen, aber alles nimmt Gestalt an; und die Gestalt, die es annimmt, ist genau das Herz dessen, was ich hier diskutieren möchte.

Ich weiß, dass ich gegen die verbreitete Intuition argumentieren muss. Die meisten, die mit der DSFA arbeiten, betrachten sie als bürokratische Last, als zu erledigende Pflicht, als Papier, das der Rechtsberater ausfüllt und der Kunde archiviert. In Italien, wo Compliance lange ein defensives Profil bewahrt hat, wurde die DSFA oft geschrieben, um nicht gelesen, und gelesen, um nicht diskutiert zu werden. Die Frage „Was brauchst du wirklich in einer gut gemachten DSFA“ erhält gewöhnlich pragmatische Antworten: dass sie vollständig sei, dass sie die Anwendungsfälle abdecke, dass sie anderen Unterlagen nicht widerspreche, dass sie eine Behördenkontrolle übersteht. Es sind ehrliche Antworten. Aus meiner Sicht sind es auch falsche Antworten — oder besser: Es sind die Antworten, die man geben würde, wenn die DSFA tatsächlich ein Formular wäre. Und genau das war die DSFA bis vor wenigen Wochen noch immer, zumindest in weiten Teilen der italienischen Praxis. Ein Dokument ohne Autor, im schwächsten Sinn des Wortes: Jemand unterzeichnete es, gewiss, aber niemand übernahm dafür im redaktionellen Sinn die Verantwortung.

Ein Template ist kein Formular

Aber hier kommen wir zum Punkt. Ein Template ist kein Formular. Ein Template hört in dem Moment, in dem es von einer Behörde wie dem EDPB mit dem expliziten Anspruch vorgeschlagen wird, zum gemeinsamen europäischen Standard zu werden, auf, ein Werkzeug zum Ausfüllen zu sein, und wird zu etwas Seltsamerem und Mächtigerem: zur Kodifizierung einer Form. Und eine Form wird nicht ausgefüllt. Eine Form wird geschrieben, im klaren Bewusstsein, innerhalb spezifischer Erwartungen gelesen zu werden, mit einem Vokabular, einer narrativen Struktur, einem rhetorischen Rhythmus, die nicht austauschbar mit anderen sind. Das, in wenigen Worten, ist eine Gattung.

Um zu verstehen, warum dieser Übergang wichtig ist, muss man einen Schritt zurücktreten und den Weg betrachten, auf dem die DSFA dort angekommen ist, wo sie heute steht. Sie existiert formell seit 2018, von Artikel 35 der DSGVO als verpflichtende Bewertung in Fällen risikoreicher Verarbeitung vorgesehen. In den ersten Jahren wurde sie verwaltet, wie sie verwaltet werden konnte: Jede Organisation, jede Anwaltskanzlei, jeder Datenschutzbeauftragte produzierte seine Version, mit einer Variabilität, die jeder kennt, der branchenübergreifend gearbeitet hat. Manche DSFA waren fünfseitige Dokumente, die wie ein Sitzungsprotokoll aussahen; andere waren hundertseitige Bände, die wie Doktorarbeiten wirkten. Manche wurden mit numerischen Risikomatrizen aus Sicherheitsframeworks erstellt, andere mit dichter juristischer Prosa voller Normverweise, wieder andere mit hybriden Ansätzen, die beide Kulturen mischten, ohne sie ganz zur Koexistenz zu bringen. Die Kommission hatte einige Schemata vorgeschlagen, die Artikel-29-Datenschutzgruppe und später der EDPB hatten Leitlinien veröffentlicht, einige nationale Behörden hatten strukturiertere Modelle bereitgestellt, doch das Bild blieb fragmentiert. Die DSFA befand sich in jenem Zustand junger Dinge, in dem die Formen noch nicht abgesetzt sind, in dem jeder seinen Weg ausprobiert und wenige dieser Wege sich treffen. Die europäischen Aufsichtsbehörden hatten sich wiederholt über diese Heterogenität beklagt, die es schwer machte, eine geteilte implizite Rechtsprechung aufzubauen — jene ungeschriebene Rechtsprechung, die in jedem reifen Bereich entsteht, wenn man Hunderte von Dokumenten liest, die nach einer erkennbaren Form produziert wurden.

Wenn eine Form Gestalt annimmt

Das EDPB-Template eröffnet das Ende dieser Phase. Nicht mit der formalen Autorität einer bindenden Verordnung, die es nicht ist, sondern mit etwas, das der Autorität ähnelt, die eine normative Grammatik über eine lebende Sprache ausübt: Es weist hin, orientiert, schafft einen Schwerpunkt. Von nun an weiß, wer in Europa eine DSFA schreibt, dass es eine auf supranationaler Ebene vorgeschlagene Form gibt, und weiß, dass jede Abweichung von dieser Form zu rechtfertigen sein wird, sobald die Konsultation abgeschlossen ist und die nationalen Behörden ihre Schritte zur Übernahme vollzogen haben. Genau das ist, in der Geschichte der Sprachen und der literarischen Gattungen, die Bewegung, mit der eine Form Gestalt annimmt. Vor Dante war das florentinische Volgare eine der vielen italienischen Volkssprachen; nach Dante maß sich jeder Gebrauch des florentinischen Volgare an ihm, auch wenn man sich von ihm entfernen wollte. Der Vergleich mit Dante ist gegenüber einem bürokratischen Template unverhältnismäßig, das weiß ich. Ich lasse ihn dennoch stehen, weil die Mechanik dieselbe ist, auch wenn die Höhen offenkundig unvergleichbar sind. Wenn eine Behörde eine Form vorschlägt und alle untergeordneten Behörden ankündigen, sie zu übernehmen, hört diese Form auf, eine Möglichkeit unter vielen zu sein, und wird zum Hintergrund, vor dem alle anderen sich abzeichnen.

Architext und Selbstinquisition

Literaturwissenschaftler nennen dieses Phänomen die Stabilisierung eines Architextes, ein Begriff, den ich Genette verdanke, der aber bereits bei Bachtin unter dem Namen sekundäre Diskursgattungen zirkulierte. Der Architext ist kein einzelnes Werk: Er ist die Gesamtheit der formalen Erwartungen, die ein Leser mitbringt, wenn er einen bestimmten Dokumententyp öffnet. Wenn ich einen Krimi öffne, weiß ich, dass es ein zu lösendes Verbrechen geben wird; wenn ich einen wissenschaftlichen Artikel öffne, weiß ich, dass es einen Methodenabschnitt geben wird; wenn ich ein Sonett öffne, zähle ich die Zeilen, bevor ich sie überhaupt lese. Ein stabilisierter Architext erzeugt stabilisierte Erwartungen. Und er erzeugt unweigerlich eine Form des Schreibens, die weiß, innerhalb dieser Erwartungen gelesen zu werden. Hans Robert Jauss nannte ab 1970 Erwartungshorizont diese Haltung des Lesers, der einem Text innerhalb eines bereits bekannten Gattungsrahmens begegnet. Jeder Text, so Jauss, wird stets zweimal gelesen: einmal gegen den Rahmen, den der Leser mit sich bringt, einmal in der Umformung dieses Rahmens auf der Grundlage dessen, was der Text tatsächlich sagt. Eine innerhalb des EDPB-Templates geschriebene DSFA wird, wenn dieses zum Bezugsstandard geworden ist, so gelesen werden: Der Auditor oder Inspektor wird bereits wissen, was er sucht, in welchem Abschnitt was zu erwarten ist, sofort erkennen, wenn der Text von der erwarteten Form abweicht — und auf der Grundlage dieser Abweichung sein Urteil bilden.

Es gibt einen zweiten theoretischen Strang, den ich in Erinnerung rufen möchte, weil er den Punkt in eine andere Richtung beleuchtet. Carlo Ginzburg hat in seinen Arbeiten zu den friulischen Inquisitionsprozessen des sechzehnten und siebzehnten Jahrhunderts gezeigt, wie die Protokolle dieser Prozesse eine echte dokumentarische Gattung bildeten, mit präzisen rhetorischen Konventionen, einem kodifizierten Verhältnis zwischen Vernehmer und Vernommenem, einer besonderen Behandlung der Stimme zwischen direkter und indirekter Rede, einer narrativen Struktur, die die Stimme des Angeklagten in den prozessualen Rahmen des Inquisitors übersetzte. Ginzburg las diese Protokolle als Texte, nicht als reine Transkriptionen, und in dieser Lektüre fand er die Spuren einer ansonsten unsichtbaren volkstümlichen Subjektivität. Jenseits des historischen Vergleichs gibt es eine strukturelle Analogie, die mich beeindruckt, seit ich über die DSFA nachdenke. Die DSFA ist in ihrer tieferen Architektur ein selbstinquisitorisches Dokument: Der Verantwortliche befragt sich selbst über sein eigenes Tun, rekonstruiert die Gründe seiner Entscheidungen, argumentiert vor einem abwesenden, aber bedrohlichen Leser (der Behörde), warum diese Entscheidungen angemessen sind. Es ist eine Diskursform, die ihre eigene Rationalität entfaltet, um beurteilt zu werden. Dass sie nun ein Template hat, das zur kodifizierten Gattung werden soll, bedeutet unter anderem, dass diese Selbstinquisition demnächst eine Grammatik haben wird. Und Grammatiken sind, wie alle wissen, die sie ernsthaft studiert haben, keine neutralen Werkzeuge: Sie modellieren, was gesagt werden kann, und indirekt, was gedacht werden kann.

Das Fenster des Kanons

Wer in den nächsten Monaten eine DSFA schreibt, befindet sich in einer besonderen Lage, die sich sowohl von der des Pioniers als auch von der des Ausfüllers innerhalb einer reifen Gattung unterscheidet. Das Template liegt auf dem Tisch, ist aber noch kein Standard, die Konsultation läuft, die nationalen Behörden bereiten ihre Schritte zur Umsetzung vor. Wer in diesem Fenster eine DSFA schreibt, schreibt innerhalb einer Form, die sich gerade stabilisiert — was zwei Dinge bedeutet. Das erste ist, dass er sich nicht mehr wie ein Pionier verhalten kann: Das Template ist verfügbar, seine Abschnitte sind klar, seine Methode ist öffentlich, es zu ignorieren wäre eine bewusste Geste und müsste begründet werden. Das zweite, weniger offensichtliche, ist, dass er eine Möglichkeit hat, die jemand, der in zwei Jahren schreibt, nicht mehr haben wird: nämlich mit der eigenen Praxis dazu beizutragen, zu definieren, was es heißen wird, „innerhalb dieser Gattung gut zu schreiben“. Jede jetzt produzierte DSFA, die sich ernsthaft mit dem Template auseinandersetzt, es als Struktur nutzt, seine Grenzen aufzeigt, trägt zur Bildung des Kanons bei. In stabilisierten Gattungen existiert der Kanon bereits; in entstehenden Gattungen wird der Kanon im Schreiben gemacht. Für jene, die unser Handwerk ausüben, lohnt es sich, gerade in diesem Fenster dabei zu sein.

Vom Formular zur Prosa

Man könnte mir entgegnen, ich romantisiere etwas, das nur ein längeres Formular ist. Der Einwand ist ernst und verdient, ernst genommen zu werden. Wäre die DSFA nur ein längeres Formular, dann wäre ihre Entwicklung außerhalb des engen Compliance-Perimeters irrelevant: ein weiteres Raster zum Ausfüllen, ein weiterer PDF-Typ zum Archivieren, weitere Grenzkosten für jene, die Daten verarbeiten. Aber es gibt ein Detail im neuen Template, das, einmal bemerkt, diese Lesart entkräftet. Das Template verlangt nicht mehr nur Aufzählung. Es verlangt Argumentation. Es verlangt insbesondere die Begründung der Verhältnismäßigkeit der Entscheidungen, die Rekonstruktion des Gedankengangs, der von einer Risikobewertung zu einer Mitigationsmaßnahme führt, den Nachweis, warum eine bestimmte Abwägung zwischen Nutzen und Restrisiko akzeptabel ist. Es verlangt, kurz gesagt, etwas, das ein Formular nicht verlangen kann: Es verlangt Prosa.

Das Auftauchen von Prosa in einem Compliance-Dokument ist das deutlichste Symptom des Übergangs zur Gattung. Ein Formular braucht keine Prosa, weil sein Informationswert vollständig im Raster enthalten ist. Eine Gattung hingegen lebt in der Prosa, denn in der Prosa drücken sich die Verbindungen zwischen den Tatsachen aus, die Wichtigkeitshierarchien, die Rechtfertigungen, die Nuancen. Wenn das EDPB-Template verlangt, zu schreiben, warum die gewählte Rechtsgrundlage dem Verarbeitungskontext angemessen ist, verlangt es einen kleinen Essay. Der Inhalt dieses Essays wird formale Beschränkungen haben, aber es bleibt ein Essay. Und wer einen Essay schreibt, sei es auch nur einen Essay von dreihundert Wörtern in einem PDF-Feld, schreibt anders als jemand, der ein Feld in einer Excel-Tabelle ausfüllt. Prosa zwingt dazu, einen Standpunkt zu wählen, zu entscheiden, was vorne und was hinten kommt, zu zeigen, welche Informationen Beiwerk und welche zentral sind. Das Raster flacht diese Hierarchien naturgemäß ab. Der Übergang vom Raster zur Prosa ist kein rein formaler Übergang; er ist ein Übergang lokaler Epistemologie — dessen, was ein bestimmter Text erzählen kann und was nicht.

Die vielen Leser einer DSFA

Ein unterschätzter Aspekt, den ich ans Licht bringen möchte, betrifft die Frage, wer eine DSFA liest. In der gegenwärtigen Praxis denkt man fast immer an einen einzigen Leser, eigentlich an einen hypothetischen und kaum charakterisierten Leser: den Inspektor einer Aufsichtsbehörde, eine etwas abstrakte Figur, mit der die meisten DSFA in Wirklichkeit nie konfrontiert werden. Aber ein Gattungsdokument hat immer mehr reale Leser, als es vorgibt, und die DSFA bildet keine Ausnahme. Es liest sie der öffentliche Auftraggeber, der den Lieferanten bewertet. Es liest sie der Compliance-Officer, der bei einer Übernahme Due Diligence prüft. Es liest sie der Anwalt, der die Verteidigung in einem Rechtsstreit vorbereitet. Es liest sie, wenn gut geschrieben und zugänglich gemacht, der Betroffene, der verstehen will, wie seine Daten verarbeitet werden. Es liest sie in einem zunehmend häufigen Kontext der vorgelagerte Technologielieferant, der überprüfen muss, ob seine Rolle als Auftragsverarbeiter korrekt umrissen wurde. Jeder dieser Leser bringt einen anderen Erwartungshorizont mit, und die Tatsache, dass das EDPB-Template die Form stabilisiert, hilft ihnen allen gleichzeitig: Ein disziplinierter Leser weiß, wo er suchen muss, weiß, was er sucht, weiß, gut Gemachtes von Schlampigem zu unterscheiden. Ein Formular ist letztlich für jeden externen Leser außer seinem Verfasser undurchsichtig. Eine Gattung hat hingegen den demokratisierenden Vorzug, von jedem lesbar zu sein, der ihre Konventionen kennt.

DSFA-as-code

Ich kehre für einen Moment zur Erfahrung von Oltrematica der letzten Monate zurück, denn gerade die Alltäglichkeit bestimmter Projekte hat mich verstehen lassen, was sich änderte. Wir haben Arbeiten an Gesundheitsplattformen für die Region Abruzzen, an Systemen für People Analytics im Krankenhausbereich, an Anwendungen für die lokale öffentliche Verwaltung, an Online-Lernplattformen mit ECM-Zertifizierungen, an Parkraummanagementsystemen für kommunale Betriebe. In all diesen Fällen haben oder werden wir eine DSFA haben. Bis vor einem Jahr war der typische Ansatz: Wir setzen einen Call mit dem Datenschutzbeauftragten des Kunden an, sammeln die Informationen, produzieren einen Entwurf, überarbeiten ihn gemeinsam, legen ihn ins Repository. Das Dokument war am Ende des Prozesses im Wesentlichen abgeschlossen. Es wurde bei Änderung der Verarbeitung aktualisiert, mit einem jährlichen oder zweijährlichen Revisionszyklus. Es war, klar, ein Formular. Das Interessante ist, dass auch innerhalb des technischen Teams die DSFA als Formular behandelt wurde: Wir betrachteten sie als etwas, das der Datenschutzbeauftragte für uns produzierte, nicht mit uns, und das uns nur dann betraf, wenn ein Auditor uns aufforderte, einen ihrer Inhalte zu bestätigen.

Als ich das neue Template las, war das Erste, was ich tat, ein internes Memo darüber zu schreiben, was sich operativ ändern würde. Das Zweite, weniger Naheliegende, war, einen Vorschlag aufzusetzen, den ich der Kürze halber DSFA-as-code nannte: die DSFA in den Versionierungsfluss der Projekte zu bringen, sie mit Jira und Confluence zu integrieren, sie zu einem Artefakt zu machen, das im selben Ökosystem lebt wie der Code. Es ist keine revolutionäre Idee. Andere dachten bereits darüber nach, insbesondere in Umgebungen, in denen Compliance sich historisch mit Software-Engineering verflochten hat — ich denke an einige Security-Teams in der Cloud-Native-Welt der USA. Aber der Grund, warum dies gerade jetzt zu einem sinnvollen Vorschlag wurde und nicht vor zwei Jahren, ist genau das, worüber ich schreibe: Erst wenn ein Dokument zur Gattung wird und nicht mehr Formular ist, ergibt es Sinn, es so zu versionieren, wie man ein Buchkapitel versioniert. Ein Formular aktualisiert man mit einem neuen Formular; ein Kapitel revidiert man mit genetischer Nachvollziehbarkeit, mit Aufmerksamkeit für die Varianten, mit einem Entscheidungsarchiv, das dir erlaubt, deine Schritte zurückzuverfolgen und zu verstehen, warum du vor einem Jahr eine bestimmte Formulierung gewählt hattest und nicht eine andere.

Die Projekte, in denen sich diese Transformation am interessantesten zeigt, sind jene, in denen sich das Risikoprofil mit dem Produkt entwickelt. Eine People-Analytics-Plattform wie die, die wir in Partnerschaft mit Umana Analytics entwickeln, hat einen Zyklus, in dem jedes neue Feature potenziell sensible Daten berührt und jede Änderung der Vorhersagemodelle die Konturen der Verarbeitung neu definiert. Eine DSFA-Formular altert hier sehr schnell: Du schreibst sie, archivierst sie, liest sie nach einem Jahr wieder und stellst fest, dass ihr zentraler Absatz nicht mehr getreu beschreibt, was das Produkt tut. Eine versionierte DSFA-Gattung folgt hingegen dem Produkt. Jeder Pull Request, der den Verarbeitungsperimeter berührt, eröffnet eine entsprechende Diskussion über den relevanten Absatz, der unverändert bleiben oder mit einem Diff aktualisiert werden kann, das erklärt, was sich geändert hat und warum. Die Gesundheitsplattform für die Region Abruzzen, an der wir seit Jahren arbeiten, mit ihrem Datenfluss zu einem regionalen Register und zu den nationalen Erhebungssystemen, ist ein noch klareres Beispiel, denn jede vorgelagerte Normänderung erzwingt eine Neulektüre der Verarbeitung, und ohne versionierte DSFA droht diese Neulektüre den Faden der ursprünglichen Begründungen zu verlieren. Mit einer versionierten DSFA hingegen kannst du von der Gegenwart ausgehend Entscheidung für Entscheidung bis zu dem Punkt zurückgehen, an dem die Verarbeitung definiert wurde, und gemeinsam mit dem Text die Diskussionen lesen, die ihn begleitet haben. Ein noch anderer Fall ist die Online-Lernplattform, die wir für Einrichtungen betreiben, die ECM-Fortbildungen anbieten — hier muss die DSFA über eine relativ stabile Verarbeitung Rechenschaft ablegen, aber über ein sehr großes Nutzerpublikum und eine verzweigte Lieferkette von Subverantwortlichen. Hier liegt der Wert einer versionierten DSFA vor allem darin, die Verantwortungskette aufrechtzuerhalten, während die Lieferanten wechseln, und jede Aktualisierung eines Lieferanten wird zu einem Commit auf dem entsprechenden Abschnitt, mit einer Kohärenz, die ein einmal jährlich archiviertes Formular nicht haben kann.

Autorenphilologie und das git log

Hier wird wichtig zu fragen, was es wirklich bedeutet, eine Gattung zu versionieren. Die Literaturkritik hat eine konsolidierte Tradition dazu: das, was wir in Italien filologia d’autore oder critica delle varianti nennen, im zwanzigsten Jahrhundert mit den Namen Contini und Isella verbunden, und was in Frankreich critique génétique heißt, mit Figuren wie Bellemin-Noël und Pierre-Marc de Biasi. Sie untersucht, wie ein Text im Laufe der Zeit gewachsen ist, welche Varianten angenommen und verworfen wurden, welche externen Drücke die Form veränderten, welche Umarbeitungen von Lektoren, Auftraggebern, Selbstzensur ausgelöst wurden. Das git log einer versionierten DSFA ist schlicht ein Avant-Texte in Echtzeit. Es zeigt, wann eine Mitigationsmaßnahme verstärkt wurde, wer sie vorgeschlagen hat, in Reaktion auf welche Meldung, mit welchen erwogenen und verworfenen Alternativen. Es produziert als Nebeneffekt ein Maß an Nachvollziehbarkeit, das keine DSFA-Formular je hatte, denn das Formular verbirgt seine Geschichte in seiner Endversion, während die Gattung sie ausstellt. Und sie stellt sie nicht aus archivarischem Narzissmus aus, sondern weil in einer reifen Gattung die Geschichte der Entscheidungen Teil der laufenden Argumentation ist. Ein Auditor, der ein git log lesen kann, versteht, ohne irgendjemanden um Bestätigung zu bitten, ob eine bestimmte Maßnahme als Antwort auf eine reale Risikoanalyse umgesetzt wurde oder nachträglich zugeschnitten wurde, um eine bereits getroffene Entscheidung zu rechtfertigen. Die Genealogie eines Textes ist eine viel wirksamere Qualitätskontrolle als jede Unterschrift am Ende.

Die Arbeit innerhalb dieses Rahmens verändert, in einer Weise, die sich in meiner Erfahrung als progressiv erweist, einige operative Dimensionen. Die erste betrifft die Trennung zwischen Quelle und Wiedergabe. Eine DSFA-Formular lebt in ihrer endgültigen PDF-Datei, mit allen Problemen der Inkonsistenz, die das mit sich bringt: Du änderst die DSFA und entdeckst dann, dass das Verarbeitungsverzeichnis in einem anderen Dokument etwas anderes sagt, oder dass das Executive Summary für die Geschäftsleitung auf der Version von vor sechs Monaten stehengeblieben ist. Eine DSFA-Gattung lebt in einer strukturierten Quelle, in unserem Fall Confluence mit einigen für die Export-Pipeline markierten Schlüsselseiten, aus denen die für die verschiedenen Leser bestimmten Wiedergaben erzeugt werden. Dieselbe Quelle produziert die vollständige DSFA für den Datenschutzbeauftragten, ein Executive Abstract für die Geschäftsleitung, ein technisches Mitigationsblatt für das Entwicklungsteam, gegebenenfalls auch eine Kurzversion für die Betroffenen, sollte der Verantwortliche sich für deren Zugänglichkeit entscheiden. Die Inhalte sind dieselben, die Form passt sich an. Das verlangt an der Quelle eine strengere Schreibdisziplin, als die DSFA-Formular je verlangt hat, denn jeder Absatz muss so gedacht sein, dass er mehrere Verwendungen übersteht. Im Gegenzug reduziert es drastisch das, was in Compliance den größten Schaden anrichtet, nämlich die Vermehrung nicht abgestimmter Versionen derselben Verarbeitung in verschiedenen Dokumenten.

Die zweite Dimension betrifft die Verbindung mit dem Projekt-Ticketing. In jeder unserer Arbeiten eröffnet eine Jira-Epic oder -Story, die eine neue Verarbeitung personenbezogener Daten berührt oder eine bestehende ändert, eine formelle Anfrage zur Aktualisierung der entsprechenden DSFA. Nicht notwendigerweise eine vollständige Aktualisierung; auch eine Nicht-Auswirkungsprüfung genügt, sofern sie registriert wird. Die Verbindung macht explizit, was in der DSFA-Formular-Welt implizit und damit vergessen war: Jede Produktentscheidung ist eine Compliance-Entscheidung, jedes Feature, das Daten berührt, ist eine potenzielle Änderung der dokumentierten Verarbeitung. Das Ticket an den DSFA-Absatz zu binden bedeutet praktisch, durchzusetzen, dass das Produkt und sein Schreibakt synchron voranschreiten. Das git log wird zu einer genetischen Geschichte der Verarbeitung; die Jira-Chronik wird zur Chronik ihrer Begründungen. Für ein Team, das Compliance als satellitenhafte Tätigkeit gegenüber der Entwicklung zu denken gewohnt ist, ist das ein nicht trivialer Haltungswechsel, und er muss begleitet werden. In den ersten Monaten hatten wir Widerstände von Entwicklern, die die Jira-Confluence-Verkopplung als zusätzliche Bürokratie sahen; nach sechs Monaten betrachten die meisten sie als Hilfe, weil sie die Abstimmungssitzungen reduziert und den technischen Beitrag zum Aufbau der Compliance sichtbar macht.

Der DSB als Editor

Die heikelste Dimension betrifft die Rollen. In einem DSFA-Formular-Modell ist der Datenschutzbeauftragte typischerweise der Hauptautor oder der Endprüfer, und das technische Team ist ein Informationslieferant. In einem DSFA-Gattung-Modell kehrt sich diese Geometrie teilweise um. Der Datenschutzbeauftragte bleibt für die Konformität verantwortlich, wird aber eigentlich zum Editor: Er setzt Standards, prüft Beiträge, garantiert die Kohärenz zwischen Abschnitten, fordert Umarbeitungen. Wer den ersten Entwurf vieler Abschnitte schreibt, ist derjenige, der die Materie kennt — der Product Owner, der Architekt, der Entwickler, der das Datenmodell entworfen hat, der DBA, der die Aufbewahrungsrichtlinie aufgesetzt hat. Das Enddokument bleibt vom Datenschutzbeauftragten und vom Verantwortlichen unterzeichnet, doch das Gewebe des Textes wird von mehreren Händen gewoben. Es ist eine Sache, die jeder, der in einer Redaktion gearbeitet hat, sofort erkennt, und die jene, die nur in Compliance gearbeitet haben, verstörend finden. Und doch erscheint sie mir nach sechs Monaten Experimenten als die gesundeste Konfiguration.

Ich weiß, dass ich eine Spannung einführe. Ein Datenschutzbeauftragter, der zum Editor wird, riskiert, an formaler Autorität zu verlieren, was er an Produktqualität gewinnt. In der italienischen Tradition, wo die Figur des DSB oft juristisch und oft organisationsextern ist, kann der Vorschlag eines DSB-Editors wie eine Schwächung klingen. Ich glaube hingegen, dass es eine Stärkung ist, aus einem subtilen, aber wichtigen Grund. Die Autorität eines Editors ist nicht die Autorität dessen, der den Text allein produziert; sie ist die Autorität dessen, der entscheidet, was passiert und was nicht. Ein DSB, der alles allein schreibt, kann eine formal unangreifbare DSFA produzieren, die aber von der operativen Realität der Verarbeitung entfernt ist. Ein DSB, der das ediert, was das Team schreibt, bleibt in der finalen Position, Nein zu sagen, tut es aber an Material, das den Halt der Tatsachen hat. Das Ergebnis ist in meiner Erfahrung schwerer anzugreifen und leichter im Inspektionsfall zu verteidigen.

Lesbarkeit ist nicht Einfachheit

Hier kommen wir zum zweiten ernsten Einwand, den ich angehen möchte und der in den letzten Monaten in mehreren internen Diskussionen vorgebracht wurde. Man könnte sagen: Diese Anerkennung der DSFA als Gattung sei kein Fortschritt, sondern eine unnütze Sophistikation, eine Barockisierung der Compliance, die Lasten ohne Mehrwert hinzufügt. Europa, so wird man sagen, leide bereits unter normativer Inflation; die DSFA in ein literarisches Produkt zu verwandeln, sei es auch ein technisch-literarisches, bedeute, ein Problem zu verschärfen, ohne es zu lösen. Ich verstehe den Einwand, halte ihn aber aus einem bestimmten Grund für falsch. Gattungen verkomplizieren Texte nicht; sie machen sie lesbar. Die Alternative zu einer stabilisierten Gattung ist kein einfacherer Text, sondern ein schwerer zu lesender Text, weil das Raster fehlt, das dem Leser erlaubt, sich zu orientieren. Wenn dasselbe Dokument in zehn verschiedenen Formen auf den Tisch einer Aufsichtsbehörde gelangt, geschrieben von zehn Autoren, die jeder die eigene Struktur entschieden haben, wird die Lesearbeit sehr langsam und hat eine hohe Fehlermarge. Wenn die Gattung stabilisiert ist, kann die Behörde hundert DSFA mit derselben Anstrengung lesen, mit der ein erfahrener Kritiker hundert Romane liest, also indem sie schnell erkennt, wo sie was zu suchen hat, und ebenso schnell die signifikanten Abweichungen bemerkt.

Lesbarkeit ist in diesem Sinn nicht synonym mit Einfachheit. Ein Sonett ist schwieriger als ein Social-Media-Post, aber für jemanden, der die Gattung kennt, unermesslich lesbarer, denn er weiß, wo er die argumentative Wende sucht, das zentrale Konzept, den Schluss. Ebenso wird eine im neuen Format gut geschriebene DSFA im Detail anspruchsvoller sein, aber für einen Auditor, der das Template kennt, schneller zu lesen. Und sie wird vor allem mit anderen DSFA, die in derselben Form geschrieben sind, vergleichbar sein. Vergleichbarkeit ist der unsichtbare Vorteil stabilisierter Gattungen, und sie wird, meiner Meinung nach, der wichtigste Gewinn der kommenden Jahre für die Datenschutzbehörden sein. Bis heute begann jede Inspektion damit, ein Dokument zu lesen, als wäre es das erste seiner Art, und seine Form gemeinsam mit den Inhalten zu rekonstruieren. Wenn das neue Template Standard sein wird, wird der Vergleich von hundert DSFA von hundert verschiedenen Verantwortlichen zu einer praktikablen Operation, weil die Form geteilt sein wird und die Unterschiede informativ.

Es gibt ein Korollar dieser Vergleichbarkeit, das speziell jene betrifft, die mit dem öffentlichen Auftraggeber arbeiten, und das ich entwickeln möchte, weil es der Teil unseres Portfolios ist, der sich am schnellsten ändert. In Vergabeverfahren und technischen Lastenheften wurde die DSFA (oder die entsprechende Folgenabschätzungsdokumentation) oft als generische Anlage verlangt, ohne allzu viele Vorgaben zum Wie. Die Verwaltung prüfte, dass das Dokument existierte, und überließ die Substanz einer in der Regel späten Überprüfung, oft erst in der Vertragsausführungsphase. Mit einer stabilisierten Gattung werden die Vergabestellen die Möglichkeit haben, etwas anderes und aus Sicht der Bewerber viel anspruchsvolleres zu tun: die Qualität des Dokuments als Auswahlkriterium zu bewerten. Eine innerhalb des EDPB-Templates geschriebene DSFA wird sich konsistent benoten, mit denen der Wettbewerber vergleichen, als Indikator für das Compliance-Reifeniveau des Anbieters nutzen lassen. Für einen Lieferanten, der in das Schreiben als Praxis investiert hat, wird das ein klarer Vorteil sein, denn es verwandelt eine rituelle Anlage in ein Differenzierungsinstrument. Für einen Lieferanten, der die DSFA stets als administrative Last behandelt hat, die er in letzter Minute delegiert, wird es ein wachsendes Risiko, denn der Abstand zwischen einem gut geschriebenen Dokument und einem schludrigen wird für jeden offensichtlich, der das Template liest. In unseren spezifischen Bereichen, von der regionalen Gesundheitsversorgung über Handelskammereinrichtungen bis hin zu Kommunen, glaube ich, dass wir in den nächsten zwei Jahren genau diese Art von Selektion in den Zuschlagskriterien sehen werden: ein Signal, dass die Gattung in die öffentliche Vertragsgestaltung Einzug gehalten hat — nicht mehr als Häkchen-Feld, sondern als Gegenstand echter Lektüre.

Der Verdacht der LLMs

Es gibt einen dritten Einwand, der angegangen werden muss, auch wenn er einen Exkurs erfordert, und der mir von Personen formuliert wurde, die unserer technischen Realität sehr nahestehen. Wenn die DSFA zu einem Dokument argumentierender Prosa wird, sagt man, dann ist sie genau der Texttyp, den ein großes Sprachmodell gut produzieren kann, und das in wenigen Minuten. Warum sich um diesen ganzen Diskurs über das Schreiben, die Autorenphilologie, die redaktionellen Rollen kümmern, wenn ein guter Prompt und ein paar Iterationen für eine formal makellose DSFA reichen? Das ist eine legitime Frage, und ich habe sie mir auch gestellt, da ich in diesen Monaten intensiv mit AI-nativen Entwicklungswerkzeugen gearbeitet habe. Die Kurzantwort lautet, dass dieser Einwand zwei verschiedene Dinge verwechselt, und die Verwechslung ist gefährlich. Ein LLM kann tatsächlich einen Text produzieren, der wie eine DSFA aussieht und in den meisten Fällen eine oberflächliche formale Prüfung übersteht. Aber eine DSFA ist nicht nur ihr Endtext; sie ist die dokumentarische Spur eines Entscheidungsprozesses. Ihre Abschnitte sind keine autonome rhetorische Zurschaustellung, sie sind die Wiedergabe realer Gespräche, die zwischen realen Menschen über reale Verarbeitungen stattgefunden haben. Ein LLM kann mir helfen, diese Wiedergaben besser zu schreiben, dem Text Rhythmus zu geben, wirksamere Formulierungen vorzuschlagen — und das tut es. Es kann nicht die Gespräche ersetzen, die dem Text vorausgehen, denn genau diese Gespräche sind das, worüber die DSFA Rechenschaft ablegen muss. Eine ohne diese vorgelagerten Gespräche von einem LLM produzierte DSFA ist ein Simulakrum, und der Unterschied zum Echten zeigt sich bald, vor allem wenn der Moment kommt, sie vor jemandem zu verteidigen, der präzise Fragen stellt. Die Gattung schützt hier jene, die sie ehrlich praktizieren, und entlarvt jene, die sie vortäuschen, denn die Tiefe einer gut geschriebenen DSFA ist untrennbar von der Tiefe der Reflexion, die sie hervorgebracht hat. Das ist nebenbei ein Punkt, den die Kultur des AI-native Development in jeder Domäne lernt, in die sie vordringt: Automatische Werkzeuge sind hervorragende Verstärker des Denkens, aber kein Ersatz für Denken. Und gerade in den reifen Gattungen sieht man den Unterschied zwischen den beiden Dingen am besten.

Ein Ökosystem technisch-normativer Gattungen

Es gibt einen verwandten Punkt, der eine Erwähnung verdient, auch wenn er einen eigenen Beitrag verdiente. Die DSFA-Gattung eignet sich gerade deshalb, weil sie im selben Ökosystem wie das Produkt lebt, für Integrationen, die die DSFA-Formular nicht haben konnte. Ich denke insbesondere an die Verbindung mit der SBOM, der Software Bill of Materials, die im Rahmen des Cyber Resilience Act zu einer immer formalisierteren Anforderung wird. Die beiden Dokumentationen, SBOM und DSFA, haben getrennte Geschichten und unterschiedliche Logiken, aber sie sprechen über dieselbe Plattform. Wenn beide versioniert und abfragbar leben, werden Dinge möglich wie: zu identifizieren, welche Softwarekomponenten an der im Abschnitt X der DSFA beschriebenen Verarbeitung sensibler Daten beteiligt sind, oder zu signalisieren, wenn ein Abhängigkeitsupdate eine Komponente einführt, die das dokumentierte Risikoprofil verändert. Ein Entwickler, der eine Logging-Bibliothek aktualisiert, kann automatisch einen Alert erhalten, der ihm sagt: „Diese Bibliothek ist in der DSFA des Projekts Y, Absatz 4.2 referenziert; prüfe, ob die neue Version das beschriebene Verhalten ändert“. Es sind Szenarien, die in einer Optik integrierter Produkte science-fiction-haft bleiben; in einer Optik integrierter Compliance werden sie, wenn nicht einfach, so doch zumindest denkbar. Und der Grund, warum sie denkbar werden, ist erneut, dass die DSFA zu einem Text wird, der von bekannten Konventionen regiert wird, navigierbar wie man einen Text navigiert, und kein für die Außenwelt undurchsichtiges Raster.

Die Verbindung zwischen SBOM und DSFA ist übrigens der Punkt, an dem mir auffällt, dass der Diskurs, den ich führe, weiterreichende Implikationen hat als die DSFA selbst. Wenn die DSFA sich in eine Gattung verwandelt, ist es vernünftig zu fragen, ob andere Artefakte der europäischen Compliance dieselbe Transformation durchlaufen, und in welcher Richtung. Mir scheint zum Beispiel offensichtlich, dass auch die technische Dokumentation des AI Act auf eine Gattungsidentität zusteuert, mit ihren kanonischen Abschnitten, ihrem argumentativen Rhythmus, ihrem Anspruch auf Lesbarkeit durch eine Marktbehörde. Dasselbe gilt auf einer anderen Ebene für die Schwachstellendokumentation und für die Disclosure-Policies, die der Cyber Resilience Act im Laufe des Jahres stabilisiert, mit den Reporting-Pflichten, die im September 2026 in Kraft treten, und den vollen substantiellen Pflichten ab Dezember 2027. Wir erleben in Europa eine zehnjährige Operation der Generierung technisch-normativer Gattungen, die noch weitgehend unerforschte Konsequenzen für die Arbeit derjenigen haben wird, die Software produzieren. Vor zehn Jahren war Software-Compliance eine Konstellation von Formularen. In zehn Jahren wird sie aller Wahrscheinlichkeit nach eine Bibliothek von Gattungen sein, jede mit ihren Kanons, ihren Referenzwerken, ihrer konsolidierten Kritik, ihrer Schule von Autoren.

Diese Perspektive, die abstrakt erscheinen mag, hat eine konkrete kommerzielle Kehrseite, über die meines Erachtens noch zu wenig gesprochen wird. Ein Unternehmen, das gelernt hat, innerhalb reifer normativer Gattungen zu schreiben, hat einen substanziellen Wettbewerbsvorteil gegenüber einem Unternehmen, das jedes Mal von vorne lernen muss. Und zu lernen, innerhalb einer Gattung zu schreiben, ist nichts, was man in einer Wochenfortbildung erledigt: Es erfordert Praxis, Korrektur, Konfrontation mit guten und schlechten Beispielen, Peer-Kritik, fortschreitende Erfahrung, welche Formulierung trägt und welche nicht. Europa baut, mit nicht immer abgestimmten Zeiten und Modi, ein Ökosystem technisch-normativer Gattungen auf, das jene Organisationen belohnen wird, die aus diesem Schreiben eine stabile Kompetenz machen. Für jene, die unser Handwerk ausüben, Software für die öffentliche Verwaltung und das Gesundheitswesen, bedeutet das, dass das nächste Jahrfünft nicht von dem gewonnen wird, der eleganteren Code schreibt, sondern von dem, der bessere Compliance-Dokumente schreibt — wobei „besser“ nicht detaillierter, sondern lesbarer, argumentierter, fähiger bedeutet, einen Vergleich mit kompetenten Lesern zu bestehen. Es ist ein Paradigmenwechsel, der unsere Organisationen quer durchzieht und neu definiert, welche Kompetenzen knapp sind und welche nicht.

Ich kehre also zur DSFA zurück, mit einer Beobachtung, die hoffentlich nicht zu abstrakt klingt. Dass ein Formular sich in eine Gattung verwandelt, ist eines jener Dinge, die, einmal geschehen, die Art, wie wir die vorherige Geschichte lesen, rückwirkend verändern. Die DSFA, die zwischen 2018 und 2025 geschrieben wurden, waren in gewisser Weise schon Gattung, denn es gab Leseerwartungen, denn es zirkulierten als gut oder schlecht angesehene Beispiele, denn die Behörden begannen, eine implizite Rechtsprechung darüber aufzubauen, was eine gut gemachte DSFA bedeutete. Es war eine Gattung in Bildung, fluide, mit unsicheren Grenzen. Das EDPB-Template wird, sobald die Konsultation abgeschlossen und die nationalen Übernahmeschritte eingeleitet sind, diese Grenzen festlegen, diese Gattung kristallisieren und damit rückwirkend eine Bahn sichtbar machen, die zuvor mehrdeutig war. Von diesem Moment an wird die DSFA ein Davor und ein Danach haben, und der Unterschied zwischen den beiden wird keine Detailfrage sein, sondern eine Frage der Natur. Das Fenster, in dem wir jetzt schreiben, ist genau der Moment, in dem dieser Übergang sich vollzieht: nicht mehr davor, noch nicht ganz danach, es ist die Schwelle.

Was morgen früh zu tun ist

Mir ist bewusst, dass dieser ganze Diskurs einem pragmatischen Ingenieur wie eine unnütze philosophische Abstraktion klingen kann. Wozu nützt es mir in der konkreten Arbeit von morgen zu wissen, dass die DSFA zu einer Gattung wird? Die praktische Antwort habe ich bereits in den vorigen Absätzen verteilt, aber es lohnt sich, sie in einer Form zusammenzusetzen, die näher an dem ist, was ein Team tun muss, wenn es das nächste Projekt eröffnet. Man muss aufhören, die DSFA als Abschlussdokument zu behandeln, das stromabwärts der Planung produziert wird, und beginnen, sie als Begleitdokument zu behandeln, das mit dem Projekt entsteht und mit ihm wächst. Man muss akzeptieren, dass die Personen, die zur DSFA beitragen, nicht mehr nur der Jurist und der Datenschutzbeauftragte sind, sondern auch jene, die das Produkt bauen, und das verlangt eine kleine, aber konstante Investition in deren Fähigkeit, argumentierte Texte zu schreiben. Man muss in die Entwicklungsprozesse die technischen und organisatorischen Verbindungen zwischen Projekt-Tickets und DSFA-Absätzen einführen, damit das Schreiben keine parallele Tätigkeit bleibt, sondern Teil der laufenden Arbeit wird. Man muss die Rolle des Datenschutzbeauftragten als Editor mehr denn als alleiniger Verfasser neu denken, mit allem, was das hinsichtlich der Beziehung zum übrigen Team bedeutet. Keiner dieser Wechsel ist, einzeln genommen, dramatisch. Zusammengenommen zeichnen sie die Art neu, wie Datencompliance gemacht wird, und lassen den Unterschied zwischen Organisationen sichtbar werden, die den Übergang verstanden haben, und Organisationen, die weiterhin Formulare in einer Welt produzieren werden, die Gattungen liest.

Es gibt dann etwas, das ich jenen signalisieren möchte, die wie wir gerade in diesem Fenster der Gattungsbildung operieren. Die vom EDPB eröffnete öffentliche Konsultation ist keine Formerfüllung, die nur die Datenschutzfachleute betrifft: Es ist der Moment, in dem das Template noch geformt wird, und damit der Moment, in dem eine informierte Stimme eine Spur hinterlassen kann. Ein Software-Anbieter für die italienische öffentliche Verwaltung, der einen begründeten Beitrag einreicht, der sich auf die konkrete Erfahrung bezieht, DSFA für öffentliche Einrichtungen zu schreiben, beteiligt sich mehr an der Definition der Gattung, als er ahnt. Es ist keine symbolische Geste: Die Konsultation ist das Instrument, mit dem die europäischen Behörden Grenzfälle, operative Schwierigkeiten, Inkompatibilitäten mit konsolidierten Praktiken sammeln und die Abschnitte als Antwort darauf umformulieren. In den nächsten zwei Monaten, von hier bis zum 9. Juni, gibt es eine nutzbare Zeit zum Beitragen. Danach wird es zu spät sein, in dem spezifischen Sinn, dass die Formen des Kanons gewählt sein werden. Es lohnt sich, einen Tag dafür zu investieren.

Eine Stunde Umschreiben

Ich möchte mit einem Bild schließen, das mir vor einigen Wochen in den Sinn kam, als ich zum x-ten Mal einen Absatz über Mitigationsmaßnahmen in der DSFA eines Gesundheitsprojekts las. Der Absatz war formal korrekt, deckte die geforderten Punkte ab, zitierte die richtigen Normen. Aber er war schlecht geschrieben, mit jener besonderen Undurchsichtigkeit, die ungepflegte technische Texte haben — in denen die Syntax im Wesentlichen ein Parkplatz für Nebensätze ist. Ich las ihn erneut und dachte: Wenn ein Auditor diese Passage in Eile liest, was nimmt er mit? Die Antwort lautete: fast nichts, denn der Text ist nicht dafür gemacht, in Eile gelesen zu werden, ja, er ist überhaupt nicht dafür gemacht, gelesen zu werden. Er ist gemacht, präsent zu sein. Er ist Compliance-Archäologie, bevor er überhaupt archiviert wird. Ich verbrachte eine Stunde damit, ihn umzuschreiben, ohne Inhalte hinzuzufügen, nur indem ich den Rhythmus ordnete. Am Ende war der Absatz dreißig Prozent kürzer und sagte vor allem dieselben Dinge mit einer Klarheit, die er zuvor nicht hatte. Der Unterschied war redaktionell, nicht technisch. Aber er war genau der Unterschied, der ein Formular von einer Gattung trennt.

Diese Stunde Arbeit ist, wenn man darüber nachdenkt, die genaue Chiffre der Veränderung, die ich zu beschreiben versuche. In einer DSFA-Formular-Welt ist eine Stunde Umschreiben an einem formal korrekten Absatz verschwendete Zeit: Das Dokument ist konform, Ticket schließen, zum nächsten. In einer DSFA-Gattung-Welt ist diese Stunde der einzige wirklich produktive Teil des Tages, denn sie ist der einzige, der die Qualität des Textes als Text verbessert. Die Transformation, die wir beschreiben, verändert also auch die Definition gut investierter Zeit. Sie verändert, was ein Team als Arbeit zu betrachten berechtigt ist. Und sie verändert folglich, wie die Arbeit zu planen ist. Eine Sprint-Planung, die zwei Stunden pro Woche dem gemeinsamen Schreiben und Überarbeiten der DSFA reserviert, ist keine Exzentrik eines Teams, das gerne Zeit mit technischer Literatur verschwendet; es ist ein Team, das verstanden hat, in welchem dokumentarischen Regime es zu operieren beginnt. Ein Team, das die DSFA weiterhin als Artefakt behandelt, das an einem Nachmittag am Projektende zu produzieren ist, lebt buchstäblich in einem Regime, das aufhört zu existieren.

Diese kleine Episode verbindet sich in meinem Kopf mit einem Faden, an dem ich seit Monaten ziehe, an scheinbar unterschiedlichen Dingen: Software, die nicht gut altert, das Produkt, das aufhört, eine stabile Kategorie zu sein, das Internet, das mehr eingezäunt als degeneriert wurde. In all diesen Fällen ist die Grundfrage dieselbe, und sie betrifft das Schreiben. Wenn ein technisches Artefakt aufhört, autark zu sein, und Teil eines Ökosystems von Texten wird, die seine Existenz dokumentieren, zählen die Eigenschaften des Textes ebenso viel und mehr als die Eigenschaften des Artefakts. Moderne Software, sagte ich in Cruft, keine Patina, altert nicht, weil sie nie hinreichend fertig ist, um zu altern. Die DSFA kann, in einer spiegelbildlichen Falte, nicht mehr hinreichend fertig sein, um archiviert zu werden: Sie lebt, solange die Verarbeitung lebt, die sie dokumentiert, und jede ihrer Versionen ist eine Fotografie in Bewegung, kein Monument. Compliance entwickelt sich, ohne dass es fast jemand bemerkt, zu einer fortlaufenden Schreibpraxis, nicht zu einer Praxis der abschließenden Archivierung. Und wie jede fortlaufende Schreibpraxis belohnt sie jene, die sie als Schreiben ernst nehmen, und nicht jene, die sie als Formularwesen vortäuschen.

Es ist eine Richtung, die mehr von dem verlangen wird, der schreibt, aber die langfristig auch mehr zurückgibt, in Form von Qualität der getroffenen Entscheidungen, Verteidigbarkeit der getroffenen Wahl, Vermittelbarkeit des angesammelten Wissens. Sie in unsere Arbeitsabläufe zu übersetzen ist die Arbeit, die uns für die nächsten Monate erwartet. Es ist keine dringende Arbeit im Sinne von Deadlines; es ist eine dringende Arbeit in dem Sinn, dass je länger man wartet, desto mehr sich die Schreibschuld anhäuft. Und eine Schreibschuld in einer sich stabilisierenden Gattung ist schwer zu begleichen, wenn der Moment des Urteils kommt. Wer jetzt seine ersten DSFA im neuen Template schreibt, beteiligt sich auch, ohne es ganz zu wissen, an der Bildung eines Kanons. In den nächsten zwei oder drei Jahren wird sich durch die Summe der konkreten Praktiken Tausender europäischer Organisationen entscheiden, welche Züge der Gattung sich als normal konsolidieren und welche marginal bleiben. Es lohnt sich, ausnahmsweise dabei zu sein, nicht als Zuschauer, sondern als Autor.

Software lernt in diesem Sinn nicht. Software sammelt Kommentare, die sich entschuldigen.

Die Archäologie alten Codes

Wer auf einer mehr als zehn Jahre alten Codebase gearbeitet hat, kennt einen bestimmten Kommentartyp. // HACK: entfernen, wenn wir auf API v2 migrieren. // TODO: verstehen, warum das funktioniert. // NICHT ANRÜHREN: hat dreimal die Produktion zerstört. Signaturen von Personen, die nicht mehr dort arbeiten, gerichtet an künftige Lesende, die nie wirklich kommen, um sie zu lösen. Patina? Eher Narbengewebe. Der Unterschied ist nicht nur lexikalisch. Ein Aalto-Stuhl von 1932, wenn wirklich genutzt, hat heute einen ästhetischen Wert, den der frisch aus der Fabrik kommende Stuhl 1932 nicht hatte. Das Holz ist an den Stellen, wo Hände sich auflegen, dunkler geworden. Die matte Lasur hat ungleichmäßig an Glanz verloren, hat den Körper gelernt, der darauf saß. Vielleicht eine Reparatur an der Verbindung Bein/Sitz, eine ausgetauschte Schraube, eine geschmackvoll von einem Zwischenbesitzer angebrachte Verstärkung. All das macht ihn nicht schlechter. Es macht ihn schöner, wertvoller, mehr er selbst. Eine ernsthafte Restauratorin weigert sich, die Patina zu entfernen — sie ist konstitutiver Teil des Objekts geworden. Restaurierung ist die Kunst, Schaden von Geschichte zu unterscheiden.

Eine PHP-Software von 1998, wirklich genutzt, hat heute keinerlei zusätzlichen ästhetischen Wert. Sie hat geschichtete Workarounds für Browser, die nicht mehr existieren. Validierungen, dreimal auf drei Ebenen ergänzt, weil bei jedem Wartungszyklus niemand den vorherigen vertraute. Vierhundert-Zeilen-Funktionen, die Sonderfälle für Kunden behandeln, die seit zehn Jahren keine Kunden mehr sind. Niemand schlägt vor, diesen Zustand als Wertbestandteil zu erhalten. Man redet von technischer Schuld — verräterischer Begriff: Schuld, nicht Geschichte. Etwas zu tilgen, nicht zu ehren. Der Wortschatz, mit dem die Branche ihr Verhältnis zur Zeit beschreibt, zeigt: kein verfügbarer Begriff erlaubt, ein altes System schön zu nennen. Höchstens „solide“, „battle-tested“, „proven“. Tugenden des Widerstands, nicht der Akkumulation.

Die Archäologie alten Codes ist eine informelle Disziplin, die jeder Senior ausübt, ohne sie studiert zu haben. Kompatibilitätsschichten zu ausgestorbenen Browsern: if (window.ActiveXObject) für alte IE-Versionen, CSS-Hacks für Firefox-Bugs vor den großen Rewrites, Bedingungen, die window.attachEvent prüfen, um IE vom Rest zu unterscheiden, als die Konkurrenz vielfältig und uneinheitlich war. Feature Flags für nie abgeschlossene Rollouts, halber Code hinter if (feature_active('new_checkout_flow')), andere Hälfte im else-Zweig, das Feature seit sieben Jahren zu 100 % live, aber keiner traut sich, den toten Zweig zu entfernen, weil keiner mehr genau weiß, was er tat. Schemamigrationen begonnen und nie beendet, zwei Spalten koexistieren — alte und neue —, beide „sicherheitshalber“ geschrieben, je nach Stelle selektiv gelesen. Funktionen wie processOrderLegacy, processOrderLegacyV2, processOrderFinal, processOrderActuallyFinal — Reihenfolge nie abgeschlossener Aufräumversuche. Nichts davon ist Patina. Es ist ein Sedimentregister nicht eingehaltener Versprechen, von Absichten, die das Geschäftsleben überholt hat, bevor sie verwirklicht wurden. Fände eine Möbelrestauratorin in einer Kommode des 18. Jh. zwanzig Lackschichten, jede ohne Entfernung der vorherigen aufgetragen, würde sie nicht sagen, das Objekt habe an Wert gewonnen — sondern es sei schlecht behandelt worden. Alter Code wird genauso behandelt, auch von den Fachleuten, die ihn legacy nennen, im Tonfall einer Mischung aus Sachlichkeit und verdecktem Verachten. Das Wort kommt vom lateinischen legare, vermachen — hat aber technisch fast die gegenteilige Bedeutung angenommen: etwas Erlittenes, das man loswerden will. Vermächtnis als Bürde, nicht Geschenk.

Warum Software nicht altert

Die Frage ist warum. Warum gewinnen materielle Objekte im Lauf der Zeit, während digitale Objekte nur verlieren. Bequeme Antwort: ontologischer Unterschied — Code ist reine Semantik, ohne materielles Substrat, in dem sich Gebrauchsspuren ablagern könnten. Holz atmet, nimmt Feuchtigkeit auf, oxidiert, schleißt an Reibungsstellen. Das Byte tut nichts davon. Eine Binärdatei ist heute bit-genau identisch mit ihrer Geburt — abgesehen von zufälliger Datenträger-Korruption, ohne semantischen Wert. Bequeme Antworten haben den Fehler, den Diskurs genau dort zu schließen, wo er beginnen sollte.

Tiefer. Ein Stuhl altert nicht gut, weil er aus Holz ist, sondern weil sein Umfeld substanziell stabil bleibt. Schwerkraft ändert sich nicht. Menschliche Physiologie nicht. Funktion „Körper im Sitzen tragen“ nicht. Modifikationen, die er erfährt, sind interne Modifikationen seines Gewebes, im Dialog mit einer Umgebung, die viel langsamer läuft als er. Stuhl und Welt um ihn altern zusammen, im selben Tempo — Resultat eine Art domestizierte Ko-Evolution. Software lebt in einer Umgebung, die viel schneller läuft als sie. Browser wechselt alle vier Wochen die Version. Sprache bricht alle zwei Jahre die Abwärtskompatibilität. Bibliotheken haben kürzere Lebenszyklen als ein Parlamentsmandat. Das Betriebssystem, unter dem sie kompiliert wurde, hört auf zu existieren in jener Form. Software altert nicht intern wie Holz. Sie löst sich progressiv von ihrer Umgebung, wie ein Raumschiff ohne Treibstoff, das die Station entgleiten sieht. Was wir „software aging“ nennen, ist nicht Altern wie beim Stuhl. Es ist Umgebungs-Drift. Das Maß des wachsenden Abstands zwischen einem fixen Artefakt und einem mobilen Kontext.

Dieser Unterschied ist ontologisch relevant. Ein Gebäude und sein Stadtkontext altern gemeinsam in fortlaufendem Dialog — diese Ko-Zugehörigkeit ist die Bedingung, dass „Altern“ im eigentlichen Sinn überhaupt möglich ist. Software hat keine Ko-Zugehörigkeit, sie hat Kompatibilität — eine viel ärmere Beziehung. Kompatibilität bedeutet: zwei Dinge, die sich nicht mehr verstehen, können noch einen Release-Zyklus lang vortäuschen, sich zu verstehen. Wenn Brand schreibt, Gebäude lernen, beschreibt er einen Prozess, in dem Gebäude und Bewohner sich gegenseitig verändern. Wenn ein Sysadmin einen Compatibility-Shim einfügt, um eine alte Binary auf einem neuen Kernel laufen zu lassen, schiebt er einen Keil zwischen zwei Welten, die sich nicht mehr unterhalten — er kauft Zeit. Der Shim ist das Gegenteil des Lernens — er gesteht ein, dass Lernen nicht möglich ist und nur Kommunikation simuliert werden kann.

Ruskin und die Wahrheit des Gebrauchs

Ein Passus bei Ruskin, in Die sieben Lampen der Architektur: ein neues Gebäude sei seiner Natur nach falsch und werde erst durch jahrelangen Umgang wahr. Ruskin ist viktorianisch, emphatisch, oft anstrengend — aber dieser Satz ist eines der präzisesten Dinge, die je über das gebaute Objekt gesagt wurden. Die Wahrheit eines Gebäudes liegt nicht im Entwurf, sondern in der Geschichte seines Gebrauchs. Wendet man dasselbe Kriterium auf Software an, muss man schließen: Software wird nie wahr. Sie bleibt im permanenten Zustand der Neuheit, auch wenn ihr Kompilierdatum fünfundzwanzig Jahre alt ist — denn die Geschichtsanhäufung, die sie ruskinisch real machen sollte, ist im Medium nicht möglich. Sie sammelt nur wachsende Inkompatibilität mit ihrem Umfeld, und das ist keine Geschichte, sondern Erosion.

Der Unix-Einwand

Man muss den starken Einwand stellen. Unix ist über fünfzig Jahre alt — und nicht nur funktioniert es noch, es ist mit der Zeit eleganter geworden, nicht weniger. POSIX, TCP/IP, SQL, das hierarchische Dateisystem, die Pipe. Ideen, die zwischen vierzig Jahren und einem reichen halben Jahrhundert auf den Schultern tragen. Noch immer im Zentrum der digitalen Infrastruktur des Planeten. Sie verhalten sich nicht wie das PHP von 1998. Sie verhalten sich wie der Aalto-Stuhl. Etwas im Vorigen stimmt nicht.

Der Einwand ist ernst und verdient ernste Antwort. Bequem wäre: Unix ist Ausnahme, Outlier, glücklicher Fall, der die Regel nicht kippt. Schwache Antwort. Interessante Antwort: Unix widerspricht nicht der Argumentation, es zeigt deren genauen Mechanismus und klärt eine bisher implizite Unterscheidung. Die zwischen Software-als-Code und Software-als-Spezifikation.

Spezifikation, nicht Code

Was man heute „Unix“ nennt, ist nicht buchstäblich die Software, die Thompson und Ritchie 1969–1971 in den Bell Labs schrieben. Dieser Code ist seit Jahrzehnten tot. Die kommerzielle AT&T-Linie wurde verkauft, zerlegt, reabsorbiert. BSD wurde mehrmals geforked, jeder Fork wieder neu geschrieben. Linux, heute die dominante Form von „Unix“ in der Weltinfrastruktur, teilt keine einzige Zeile mit dem ursprünglichen Unix — es ist eine unabhängige Reimplementierung, 1991 von Linus Torvalds begonnen, die dieselben System-Schnittstellen exponiert, aber von Grund auf neu geschrieben wurde. macOS leitet sich von NeXTSTEP ab, ruht auf dem Mach-Mikrokernel und auf BSD-Komponenten, und auch hier ist der Code so oft umgeschrieben und neu zusammengeführt worden, dass die materielle Kontinuität zum Ausgangspunkt rein rituell ist. Was überlebt hat, ist nicht Unix’ Körper, sondern seine Form. Seine Schnittstelle. Seine Grammatik. Dass Systemaufrufe open, read, write, close heißen und mehr oder weniger funktionieren wie 1973, heißt nicht, dass der Code, der sie implementiert, gut gealtert sei. Es heißt, die Spezifikation, die sie definiert, ist etwas anderes geworden als der Code: sie wurde Kultur, Konvention, gemeinsame Sprache, De-facto- und durch POSIX dann De-jure-Norm.

Dasselbe gilt für TCP/IP. Das Protokoll überlebt, die Implementierung nicht — jedenfalls nicht im Original. Jeder moderne TCP/IP-Stack — von Linux über Windows, iOS bis zum ESP32 in einer smarten Lampe — wurde im Laufe der Jahrzehnte mehrmals neu geschrieben oder neu ausgerichtet. Der einst maßgebliche 4.4BSD Networking Code wurde nach und nach absorbiert, verzweigt, neu implementiert — die heutigen Codes wahren mit ihm eher historische als materielle Verwandtschaft. Was unverändert besteht, ist die RFC: ein Textdokument, das in technischem Englisch beschreibt, wie zwei Maschinen miteinander reden sollen. Eine RFC ist keine Software. Sie ist näher an einem diplomatischen Vertrag. Deshalb altert sie gut: sie gehört zur selben Klasse von Objekten wie ein Vertrag, eine Verfassung, eine Grammatik. Eine geteilte Konvention, deren Stärke nicht in ihrer Implementierung liegt, sondern in der Zahl der Akteure, die sie als bindend anerkennen.

SQL ist der lehrreichste Fall. Die Syntax SELECT ... FROM ... WHERE wurde Mitte der 70er von Donald Chamberlin und Raymond Boyce bei IBM definiert. Heute nutzen sie alle. Aber keine Produktiv-Relationale läuft auf dem Originalcode von System R. Postgres ist eine Reimplementierung. MySQL auch. SQLite wurde in den 2000ern von null geschrieben und ist heute vermutlich die weltweit am häufigsten verwendete Datenbank. Der Code, der SQL implementiert, ist mehrfach gestorben und wieder geboren — eine materielle Kontinuität gibt es nicht. Was bleibt: das relationale Modell — ein mathematisches Objekt — und eine bestimmte Syntax — ein kulturelles Objekt. Beide haben sich vom anfänglich verkörpernden Code gelöst, und gerade deshalb konnten sie die Zeit durchqueren.

TeX, SQLite und die bestätigenden Ausnahmen

Es gibt jedoch wenige Fälle, in denen der Code selbst etwas geleistet hat, das echter Patina ähnelt — Fälle, die im Kontrast die allgemeine Bedingung beleuchten. TeX, das von Knuth ab 1978 geschriebene Schriftsatzsystem. Knuth entschied einmal, dass TeX im wörtlichen Sinn fertig sei: keine neuen Features, nur Bugfixes; die Versionsnummer konvergiert asymptotisch gegen π in jedem Release, mit der ausdrücklichen Absicht, dass die letzte Version bei Knuths Tod den exakten Wert π annimmt und die Software für immer nicht mehr verändert werde. Knuth bietet eine kleine Geldbelohnung, die jährlich verdoppelt, an jeden, der einen TeX-Bug findet — niemand reklamiert sie seit Jahren. Nicht weil keine da wären, sondern weil die Software so massiv und so lange genutzt wurde, dass die übrigen Bugs in Ecken leben, die nie besucht werden. TeX funktioniert heute wie Ende der 80er, kompiliert dieselben Quelldateien, erzeugt denselben typografischen Output. Sein Code, in WEB geschrieben (Knuth-eigene Literate-Programming-Erfindung, Pascal für Logik, TeX für Doku), wurde 1986 als TeX: The Program, Band B von Computers and Typesetting, wie ein literarisches Werk veröffentlicht. Gelesen, kommentiert, studiert. Eines der wenigen Male, in denen Code die Schwelle reiner Implementierung überschritt und etwas Spezifikationsähnliches in der konkreten Form des Programms wurde — nicht als abstraktes RFC. Knuth erreichte das, indem er seinem Werk eine extreme Bedingung auferlegte: jede Evolution zu verweigern. TeX altert nicht, weil es sich entschieden hat, in gewisser Weise nicht zu leben. Es hat die Mumifizierung als Preis der Permanenz akzeptiert.

SQLite ist der andere interessante, jüngere und weniger mystische Fall. Die Entwicklerinnen haben in der Doku öffentlich erklärt, die Lib mindestens bis 2050 zu pflegen, mit voller Rückwärtskompatibilität der C-API und des On-Disk-Formats. Verpflichtung kein Stilmittel, sondern konkrete Bindung — SQLite ist in Avionik-Systemen integriert (u. a. Airbus A350), in Medizingeräten, militärischen Geräten — Objekte mit Lebenszyklen über vierzig Jahren. Um diesen Horizont zu tragen, hat SQLite einen Test-Apparat aufgebaut, der laut Eigenangaben bei rund 92 Millionen Zeilen Testcode gegen 150.000 Zeilen Bibliothekscode liegt — ein Verhältnis von fast 600 zu 1. Jeder bedingte Zweig ist mit MC/DC-Tests abgedeckt, dem Standard für DO-178B-Avionik-Zertifizierungen. Der Code selbst ist mit ausdrücklicher Aufmerksamkeit darauf geschrieben, von noch nicht geborenen Personen gelesen und gepflegt zu werden. SQLite hat das Problem der Dauer von Anfang an als Designproblem behandelt und die Schnittstellenstabilität als ethische, nicht nur technische Frage. Resultat: Software seit über fünfundzwanzig Jahren in Betrieb, auf Milliarden Geräten, von der niemand das Bedürfnis hatte, sie neu zu schreiben. Der Code selbst, nicht nur die Spec, scheint gut gealtert. Doch näher betrachtet wurde dieses Resultat nur durch radikale Akzeptanz von Zwängen erreicht, die der Rest der Branche nicht akzeptieren würde. SQLite ändert sich fast nie — auch um den Preis, auf moderne Features zu verzichten. SQLite hat keine externen Abhängigkeiten, fast ein Protest gegen den Software-Bau heute. SQLite hat eine fast monastische interne Disziplinkultur. Mit anderen Worten: SQLite altert gut, weil es sich eine ökologische Nische gebaut hat, in der die Umgebung um den Code künstlich stabilisiert wurde. Es hat in einem kleinen Perimeter die Bedingungen rekonstruiert, die einen Aalto-Stuhl mit den Jahren schöner werden lassen: eine langsame Umgebung, eine aufmerksame Nutzerin, eine Kultur, die den Wert der Dauer anerkennt. Kein Zufall, dass diese Beispiele statistisch Anomalien sind. Sie sind die Ausnahmen, die enthüllen, welche Bedingungen für Software-Altern nötig sind — und bestätigen, dass diese Bedingungen im Hauptteil der Branche nicht existieren.

Der Körper stirbt, die Spezifikation aufersteht

Aus diesem Blickwinkel altert Unix nicht gut. Unix ist fortwährend auferstanden. Der Körper stirbt und wird von Grund auf neu gemacht aus einer Spezifikation, die inzwischen so heilig wurde, dass sie alle zwanzig oder dreißig Jahre die integrale Neuschreibung des Körpers verdient. Religionsstruktur eher als materielle Objektstruktur. Der Aalto-Stuhl wurde nie von null neu gemacht: der Stuhl von 1932 ist physisch da, mit seinen Beulen. Wendete man Unix-Logik aufs Holz an, müsste man sagen, das Konzept „Paimio Stuhl Modell 41“ habe überlebt, weil Artek seit Gründung 1935 die Produktion über neunzig Jahre lang fortgesetzt habe und die Stühle von 2026 von denen von 1932 abstammen, aber nicht dieselben sind. Stimmt — verschoben: was uns am Stuhl von 1932 interessiert, ist genau seine materielle Dauer, nicht die Persistenz seines Modells. In Software passiert das Umgekehrte. Der Originalcode interessiert uns nicht, niemand bewahrt ihn als Reliquie. Uns interessiert die Persistenz des Modells, und diese Persistenz verlangt periodische Zerstörung und Neuschreibung des Codes.

Der Unix-Einwand widerlegt die Argumentation also nicht, er definiert sie neu. Was im Digitalen gut altert, ist nicht Code. Es sind Spezifikationen, die das Glück und das kulturelle Kapital hatten, sich über ihr Implementierungs-Substrat zu erheben und etwas anderes zu werden. Normen. Stabile Schnittstellen. Lingua francae. Der Großteil des Codes erreicht diese Ebene nie und kann sie nicht erreichen. 99 % der heute weltweit laufenden Software werden nicht POSIX. Das maßgeschneiderte CRM einer Vierhundert-Personen-Firma wird nicht SQL. Die E-Commerce-Site einer Ladenkette wird nicht TCP/IP. Nicht weil schlecht geschrieben, sondern weil sie diese Art Objekt nicht ist. Sie ist strukturell Implementierung. Und Implementierung, im Digitalen, kann nicht gut altern — sie hat keine der Voraussetzungen: kein materielles Substrat, das den Gebrauch registriert, keine stabile Umgebung zum Bleiben, kein kulturelles Gewicht für periodische Reinkarnation.

Umschreiben ist keine Sünde

Die Unterscheidung beleuchtet auch eine seit jeher schief gestellte Branchendebatte. Joel Spolsky schrieb 2000 einen vielzitierten Artikel, Things You Should Never Do, Part I, der das vollständige Neuschreiben einer funktionierenden Software als den schlimmsten strategischen Fehler einer Software-Firma bezeichnete. Argument gut und konkret: Netscape hatte den Markt verloren, weil es den Browser von null neu schrieb und dem IE drei Jahre Tür ließ. Das Problem: Spolsky generalisiert von einem Einzelfall, ohne zu erkennen, dass die Mehrheit der Software früher oder später neu geschrieben werden muss, weil sie in der konzipierten Form nicht unbegrenzt gewartet werden kann. Unix wurde mehrmals neu geschrieben. Linux selbst wird auf Subsystemebene laufend umgeschrieben: Scheduler ersetzt, Networking-Stack neu gemacht, Filesystem überdacht. Was Spolsky „nie umschreiben“ nannte, ist tatsächlich „die Spezifikations-Kontinuität bei der Neuschreibung nicht verlieren“ — sehr verschieden, sehr viel schwerer. Die Neuschreibung scheitert, wenn sie den Kontakt verliert zu dem, was der Code für seine echten Nutzer tun sollte. Sie gelingt, wenn sie die Spec bewahrt und die Implementierung wegwirft — wie der Leib eines Katholiken bestattet wird, während die Seele anderswohin wandert.

Eine versperrte Würde

Wenn diese Lesart stimmt, hat die Traurigkeit, die einen großen Teil der täglichen technischen Arbeit grundiert, eine strukturelle, nicht psychologische Erklärung. Wir schreiben nicht schlecht. Wir schreiben Objekte, die nicht altern können, weil wir nicht zur engen Klasse der Artefakte gehören, die zur kulturellen Spezifikation aufsteigen können. 99 % dessen, was wir schreiben, ist dazu bestimmt, ohne Spuren zu sterben — nicht aus Fertigungsmangel, sondern aus einer Eigenschaft des Mediums. Ein Maurer des 13. Jh. wusste: war seine Mauer gut gemacht, würde sie im 16. Jh. noch da stehen, wahrscheinlich darüber hinaus. Ein Klempner des 20. Jh. wusste, dass seine Rohre mit etwas Wartung drei Generationen dienen würden. Eine Entwicklerin von 2026 weiß, dass ihr heute geschriebener Code mit guter Wahrscheinlichkeit binnen fünf bis sieben Jahren ausgemustert wird. Nicht weil schlechter geschrieben als die Rohre. Sondern weil Rohr und Mauer einem Regime angehören, in dem Altern möglich ist, und Code nicht.

Das ändert die ethische Natur des Berufs in noch nicht metabolisierter Weise. Etwas Dauerhaftes zu bauen war über Jahrtausende eine der höchsten Würden menschlicher Arbeit. Die Kathedrale, die Brücke, das gedruckte Buch, die Geige. Objekte, gemacht im Bewusstsein, das Leben des Erbauers zu überdauern. Softwareentwicklung ist einer der wenigen hochqualifizierten Berufe, in denen diese Würde strukturell versperrt ist. Nicht weil niemand gut arbeitete — sondern weil das Medium diese Art Dauer nicht zulässt. Die anfangs erwähnte technische Schuld, aus dieser Perspektive, ist kein durch bessere Praktiken, mehr Disziplin, strengere Tests, sorgfältigere Reviews handhabbarer Defekt. Es ist die spezifische Form, in der die unvermeidliche Verschlechterung eines Artefakts, das keine andere Verschlechterungsart kennt, sich manifestiert. Software altert schlecht, weil sie nicht anders altern kann.

Die Lampe der Erinnerung

Eine breitere Lesart, die das streng Technische verlässt. Ruskin nannte sieben Architekturtugenden „Lampen“. Opfer, Wahrheit, Macht, Schönheit, Leben, Erinnerung, Gehorsam. Die Lampe der Erinnerung war für ihn die Tugend jener Bauten, die sich von der Zeit durchdringen lassen, ohne ihr zu widerstehen — die Spuren der Bewohnerinnen bewahren, zu biographischen Archiven menschlichen Durchgangs werden. Eine Zivilisation, die solche erinnerungsfähigen Objekte nicht zu bauen weiß, sagte Ruskin, hat eine ihrer fundamentalen Funktionen aufgegeben: sich durch ihre Dinge zu überliefern.

Das Digitale ist, von hier aus gesehen, das genaue Gegenteil ruskinischer Architektur. Eine materielle Kultur, wenn man sie noch so nennen darf, in der Erinnerung sich nicht in den Dingen ansammelt, sondern sie verlässt. Software von vor fünf Jahren ist schon Antiquität. Die Website von vor zehn Jahren ist nicht mehr erreichbar, ihre Domain abgelaufen, ihre Links kaputt, ihre Bilder zeigen auf abgeschaltete Server. Digitale Archive existieren nur durch heroische, marginale Anstrengungen: Internet Archive ist Single Point of Failure für drei Jahrzehnte Online-Kultur — niemand hat verstanden, wie es zu ersetzen wäre. Unsere Fotos liegen auf Servern, die uns nicht gehören, in Formaten, die in zwanzig Jahren vielleicht nicht mehr lesbar sind, geschützt durch einseitig änderbare AGB. Unsere Korrespondenz steckt in Postfächern, die verschwinden werden, wenn der Anbieter sein Geschäftsmodell ändert. Die materielle Kontinuität menschlichen Erbes — Jahrtausende lang, wenn auch unvollkommen, durch die physische Dauer der Dinge garantiert — ist auf eine Art prekär geworden, wie keine vorherige Zivilisation sie kannte.

Diese Prekarität ist kein Nebeneffekt, sondern strukturelle Mediumseigenschaft. Und Software, das Herz dieser neuen Bedingung, erbt und verstärkt sie. Sie altert nicht, weil sie keine Erinnerung in ihren Fasern ansammeln kann. Sie hat keine Fasern. Ihre einzige Form von Kontinuität ist Neuschreibung — das genaue Gegenteil von Erinnerung: die periodische Produktion eines neuen Objekts, das vorgibt, dasselbe zu sein.

Jemand wird einwenden, ich dramatisiere — jede Epoche hatte ihre Prekarität, Papyrus zerfiel, Pergament wurde abgekratzt und wiederverwendet, gedruckte Bücher brennen. Wahr, doch der quantitative Unterschied wird qualitativ. Die durchschnittliche Lebensdauer eines gut konservierten Druckbuchs misst sich in Jahrhunderten. Die einer digitalen Datei in Jahren, glücklichenfalls Jahrzehnten. Delta von ein bis zwei Größenordnungen. Eine Zivilisation, in der Kulturobjekte hundertmal kürzer halten, ist strukturell anders, nicht nur quantitativ. Sie hat ein anderes Zeitverhältnis. Sie produziert eine andere Subjektivität ihrer Bewohner. Eine Entwicklerin weiß, was eine Drucker:in des 16. Jh. nicht wusste: dass ihre Arbeit sie nicht überleben wird.

Der Einwand des Vergänglichen

Es gibt eine weniger tragische Lesart, die einen Durchgang lohnt. Möglicher Einwand: Permanenz ist nicht zwingend Tugend, und Software könnte eine Form bewusst vergänglicher Kulturproduktion sein — wie eine Theateraufführung oder ein Jazzkonzert vergänglich sind, und ihre Vergänglichkeit kein Defekt, sondern konstitutives Merkmal ist. Eine Lambda-Funktion, die 37 Millisekunden läuft und verschwindet, ist kein gescheitertes Objekt, weil sie nicht dauert — sie ist voll realisiert, weil sie genau das tat, was sie zur richtigen Zeit tun sollte. Die Monument-Metapher aus der Architektur könnte schlicht ungeeignet sein, und auf dem „nicht gut altern“ zu beharren wäre wie sich zu beklagen, ein Gewitter altere nicht gut: eine nicht zutreffende Kategorie.

Der Einwand ist interessant, bricht aber, wenn man ihn ernst nimmt. Das Problem ist nicht der 37-ms-Code. Das ist wirklich Ereignis, kein Objekt. Das Problem: die fast gesamte Software, von der unser Alltag abhängt, ist kein Ereignis in diesem Sinn — es ist Infrastruktur. Das System, mit dem unsere Bank Konten führt, ist keine Jazz-Performance. Die medizinische Software des Beatmungsgeräts auf der Intensivstation ist kein Gewitter. Die Melderegister-Datenbank der Gemeinde ist keine vergängliche Funktion. Sie sind Objekte, die Infrastruktur sein wollen, die wir wie Infrastruktur behandeln, die Institutionen in ihre Prozesse einschreiben, als wären sie es — die aber die Dauer- und Erinnerungseigenschaften einer Wolke haben. Diese Diskrepanz zwischen sozialer Funktion und materiellen Dauer-Eigenschaften ist der Punkt, an dem die Frage nicht mehr philosophisch, sondern zivil wird. Eine Gesellschaft, die ihre Vitalfunktionen Objekten anvertraut, die nicht altern können, lagert leise die Kosten der Aufrechterhaltung ihrer eigenen Kontinuität auf eine technische Schicht aus, die diese nicht zu tragen weiß.

Prekäre Infrastruktur, nachhinkendes Recht

Der EU-Cyber-Resilience-Act, beschlossen als Verordnung (EU) 2024/2847, voll anwendbar ab Dezember 2027, die neue PLD (EU) 2024/2853, die NIS2-Pflichten — sind aus diesem Blickwinkel ungeschickte, aber sprechende Versuche, Software dazu zu zwingen, sich wie ernsthafte Infrastruktur zu verhalten. Sie zwingen Hersteller, eine Supportzeit zu definieren, die den erwarteten Lebenszyklus widerspiegelt — meist mindestens fünf Jahre —, aktuelle SBOMs zu führen, auch nach Verkauf in das Produkt eingeführte Schwachstellen zu beheben. In gewissem Sinn der gesetzgeberische Versuch, Software jene Dauer-Eigenschaften aufzuerlegen, die sie naturgemäß nicht hat. Dass diese Regeln existieren und von der Branche eher als zusätzliche Kosten denn als Anerkennung zivilrechtlicher Verantwortung empfunden werden, sagt etwas darüber, dass die Software-Produzentinnen Vergänglichkeit als Privileg internalisiert haben. Der Maurer weiß, dass er für seine Mauer viele Jahre einstehen muss. Die Entwicklerin ist daran gewöhnt, für ihren Code bis zum Ablauf der vertraglichen Garantie einzustehen — typischerweise 12 bis 24 Monate. Die zwei Berufsfiguren haben Verantwortungs-Horizonte, die sich um eine Größenordnung unterscheiden — und dieser Unterschied ist in der Sprache, mit der wir sie beschreiben, unsichtbar.

Eine Ethik der Dauer

Zurück zur Ausgangsfrage, warum Software nicht altern kann, nun mit weniger lapidarer Antwort. Sie altert nicht, weil sie aus einem Material gemacht ist, das keine Maserung hat, in einer Umgebung, die schneller läuft als sie, in einer Produktionskultur, die darauf verzichtet hat, Dauer als Wertdimension zu betrachten. Jeder dieser drei Faktoren ist hinreichend, alle drei zusammen machen das Resultat fast unvermeidlich. Der erste ist ontologisch und vermutlich unlösbar: Code wird nie zu Holz. Der zweite ist systemisch und ließe sich abschwächen, wenn die technische Kultur lernte, Stabilität als Qualität statt als Rückständigkeitszeichen zu behandeln. Der dritte ist rein kulturell und das einzige, worauf wir wirklich einwirken können.

Wie? Wahrscheinlich in Richtungen, die die Branche heute regressiv findet. Release-Zyklen verlangsamen. Rückwärtskompatibilität der Eleganz vorziehen. Weniger Code, mehr Spec schreiben. Stabile Schnittstellen wie Monumente behandeln — Objekte, deren Wert in ihrem Widerstand gegen Veränderung liegt. Akzeptieren, dass die Mehrheit des Codes nicht Unix wird, und ihn gerade deshalb mit einem gewissen Bewusstsein seiner Vergänglichkeit schreiben — ohne falschen Dauer-Anspruch und ohne nihilistische Verzweiflung über deren Fehlen. Ein Beruf, der weiß, dass er keine Kathedralen baut, aber sich weigert, Baracken zu errichten. Eine Zwischenwürde, für die wir noch kein gutes Wort haben — und die zu formulieren vielleicht eine der Aufgaben dieser Generation von Technikerinnen ist.

Der Trost, dass Software nicht gut altert, ist, dass diese Eigenschaft uns zwingt, kontrastiv zu schärfen, was Gut-Altern überhaupt heißt. Sie zwingt uns anzuerkennen: die Patina des Aalto-Stuhls ist keine automatische Holz-Eigenschaft, sondern Resultat einer langen Beziehung zwischen einem gut gemachten Objekt, einer stabilen Umgebung, einer aufmerksamen Nutzerin und einer Kultur, die den Wert dieser Triangulation erkennt. Fällt eines weg, bildet sich keine Patina. Im Regen liegen gelassenes Holz bekommt keine Patina, es vermodert. In einem Lager eingesperrtes Holz bekommt keine Patina, es trocknet aus. Patina ist ein kollektives Werk — verlangt Zeit, Pflege, Kontext. Software hat derzeit keines davon, und die Idee, sie könnte sie haben, klingt wie nostalgische Träumerei.

Sie ist keine Träumerei. Sie ist eine Designfrage. Was hieße es, Code zu schreiben in dem Wissen, dass er wie eine Mauer halten soll? Wir wissen es noch nicht wirklich, weil wir es kaum je ernsthaft versucht haben — und wenn, fast immer in Bereichen, die im Vergleich zum Mainstream marginal sind: Avionik, Industriesteuerung, Banken-Legacy — wo Dauer als externe normative Schranke auferlegt ist, nicht als kulturelle Wahl. Zivile Software — die das öffentliche und private Leben der meisten Menschen baut — wurde unter der impliziten Annahme errichtet, Dauer sei nicht ihr Problem. Diese Annahme wird unhaltbar, gerade während die Gesellschaft Software immer vitalere Funktionen überträgt. Unter den Verantwortlichkeiten dieser Generation von Technikerinnen ist das Beginnen, eine Ethik der Dauer für den Beruf zu formulieren, eine der ernsthaftesten und am wenigsten verschiebbaren.

Bleibt am Ende die Grundfrage. Software altert nicht gut. Dieser Satz schien zu Beginn eine technische Klage. Hier angekommen, versteht man: er ist etwas anderes. Eine genaue Beschreibung des Typs Artefakte, den wir kollektiv ins Zentrum unseres gemeinsamen Lebens gestellt haben — und eine implizite Aufforderung, mit dieser Entscheidung Konsequenzen zu ziehen. Die Objekte, die wir ins Zentrum einer Zivilisation stellen, sollten, soweit möglich, sie durch die Zeit begleiten können. Können sie das nicht, müssen wir sie ändern oder den Platz ändern, den sie einnehmen. Bisher haben wir weder das eine noch das andere getan. Wir haben sie das Zentrum besetzen lassen, während sie sich verhalten, als wären sie an der Peripherie, und diesen Zustand „Fortschritt“ genannt. Es lohnt sich, ihn präziser zu nennen.

Als die zweite Hälfte der Flüssigkeit zur geschmolzenen Eiscreme ins Glas gegossen wurde, schlüpfte aus der Flasche, von der Limonade mitgespült, eine Schnecke in fortgeschrittenem Verwesungszustand. May Donoghue erkrankte schwer an Gastroenteritis, wurde am 29. August von einem Arzt aufgesucht und am 16. September notfallmäßig in die Glasgow Royal Infirmary aufgenommen. Vier Jahre später, 1932, fällte das House of Lords ein Urteil, das als Grundstein des modernen Produkthaftungsrechts der Common-Law-Welt gilt.

Die Schnecke in der Flasche

Die Entscheidung fiel mit drei zu zwei Stimmen. Verfasser des Mehrheitsvotums war Lord Atkin. In dem berühmten Passus, den Jurastudierende noch heute auswendig lernen, formulierte er den Neighbour Principle — die Pflicht jedes Einzelnen, sich um den juristischen „Nächsten“ zu sorgen; Nächster meinte hier jeden, der vernünftigerweise als Empfänger der Folgen des eigenen Verhaltens vorhersehbar war.

Seitdem haftet der Hersteller für sein Produkt auch gegenüber jenen, mit denen er keine vertraglichen Beziehungen unterhält — auch wenn die Flasche über einen Distributor und ein Café zum Verbraucher gelangt, auch wenn zwischen Fabrik und Donoghues Gastroenteritis Wochen Lagerhaltung und Kilometer Straße liegen.

Was beim Lesen des Urteils fast niemandem auffällt: der Richter brauchte, um den Neighbour Principle zu schreiben, eine genaue ontologische Voraussetzung — eine bestimmte Vorstellung davon, was der besprochene Gegenstand sei. Der Gegenstand war die Flasche. Ein bounded Artefakt, mit klaren Konturen, identifizierbar, prüfbar, aufbewahrbar.

Die Flasche wurde in einer bestimmten Anlage produziert, bei David Stevenson in Paisley, zu einem datierbaren Zeitpunkt befüllt, mit einem Stopfen versiegelt, der die Integrität bis zum Verkaufsort gewährleistete. Hätten Anwälte es verlangt, sie hätten die Charge prüfen, das Glas analysieren, die Lieferkette der Zucker und Aromen verifizieren lassen können. Die causa materialis im aristotelischen Sinn war erreichbar. Die causa efficiens — der Produktionsprozess — war dokumentiert. Die causa formalis — die typische Form einer Limonadenflasche — allgemein bekannt.

Das gesamte moderne Produkthaftungsrecht, das auf Donoghue v. Stevenson aufgebaut wurde, setzt diese sehr einfache und zugleich entscheidende Sache voraus: man kann auf ein Objekt zeigen und sagen „dieses“, und der zeigende Finger findet am Ende stets etwas vor.

Die neue PLD und das Kategorienproblem

1985 hat Europa mit der Richtlinie 85/374/EWG das Donoghue-Prinzip kontinental übernommen, ausgeweitet, systematisiert. Die Product Liability Directive spricht von „fehlerhaften Produkten“ und etabliert eine objektive Herstellerhaftung, unabhängig vom Verschulden, für durch das Produkt verursachte Schäden.

Vierzig Jahre später, am 23. Oktober 2024, wurde die Richtlinie 2024/2853 verabschiedet, am 9. Dezember 2024 in Kraft, bis 9. Dezember 2026 in nationales Recht umzusetzen — mit Aufhebung der Richtlinie von 1985 zu jenem Datum. Die neue PLD wurde explizit für Software gedacht und nimmt digitale Dateien, Softwarekomponenten, Anwendungen und KI-Systeme in den Produktbegriff auf. Eine der ehrgeizigsten Reformen des EU-Zivilhaftungsrechts überhaupt.

Dass es vierzig Jahre brauchte, sie zu überdenken, und dass sie trotz aller Anstrengungen ihrer Verfasser bei Inkrafttreten bereits ungenügend zu sein droht, ist niemandes Schuld. Es ist die Folge eines Problems, das das Recht noch nicht präzise benennen konnte. Das Problem: das „Produkt“, auf dem Lord Atkin und seine Nachfolger zwei Jahrhunderte Rechtsprechung errichtet haben, gibt es in heutiger Software nicht mehr.

Eine Minute lohnt es sich, zu verstehen, wo es geblieben ist — denn die Diagnose ist Ausgangspunkt für alles Folgende.

Von der Schallplatte zum Konzert

Lange war Software ein Produkt im vollen, herkömmlichen Sinn. Aus den Bell Labs ging man heraus in die Massenverteilung mit Unix, später mit Betriebssystemen für Personal Computer.

Eine Anwendung der 80er oder 90er war ein Dateibündel auf Disketten, dann CDs, dann DVDs, mit Versionsnummer, identifizierendem Hash, im Tresor aufbewahrbarer Kopie. Bei einem Defekt konnte man, zumindest theoretisch, die exakte Binär-Version isolieren, mit der vermeintlich korrekten vergleichen, den Bug identifizieren. Windows 95 war ein Produkt. Microsoft Word 97 war ein Produkt. Sogar ein Spiel wie Baldur’s Gate war ein Produkt, mit nummerierten, aufbewahrbaren Patches.

Klar, auch damals hing Software von Dingen ab, die nicht das Produkt im engen Sinn waren — Treiber, Firmware, Netzwerkprotokolle, Systemdienste. Doch diese Abhängigkeiten waren statisch, deklariert, zahlenmäßig begrenzt und vor allem durch ein autarkes Artefakt vermittelt, das man auch nach vielen Jahren noch konservieren und reproduzieren konnte. Die CD-Kopie von Windows 95, die ein digitaler Archivar heute aufbewahrt, ist Bit für Bit noch identisch mit der von 1995. Das Produkt als Objekt mit zeitlicher Kontinuität existierte.

Anfang der 2000er beginnt sich etwas zu ändern, und die Veränderung beschleunigt sich im Folgejahrzehnt drastisch. Der Übergang zum Software as a Service verlagert die Anwendung vom lokalen Datenträger des Kunden zum Server des Anbieters. Anfangs eine Verteilungsfrage, bald eine ontologische Transformation.

Wenn die Anwendung auf einem entfernten Server läuft, ist die Version, die der Nutzer in einem gegebenen Moment verwendet, keine stabile Eigenschaft mehr — sie ist eine momentane, jederzeit vom Anbieter ohne Ankündigung neu verhandelbare Eigenschaft. Continuous Deployment führt diese Fluidität zum natürlichen Endpunkt: Unternehmen veröffentlichen täglich Dutzende oder Hunderte Änderungen in Produktion, ohne dass irgendjemand — auch intern nicht — die genaue Konfiguration des Systems am Dienstag um 14:23 Uhr vor drei Monaten exakt rekonstruieren könnte.

Parallel ändert sich die innere Komposition der Software. Seit Anfang der 2010er, dank Ökosystemen wie npm, Maven oder PyPI, heißt eine Anwendung schreiben: Hunderte oder Tausende Drittpakete einzubinden, jedes seinerseits aus Drittpaketen zusammengesetzt, in einem Graph transitiver Abhängigkeiten, den kein Mensch ganz liest und der sich asynchron zum eigenen Code aktualisiert. Der left-pad-Vorfall 2016, als ein einzelner Entwickler ein elf Zeilen langes npm-Paket löschte und damit Build-Pipelines und Installationsprozesse großer Teile der JavaScript-Welt zum Absturz brachte, war der Moment, in dem die Industrie kurz bemerkte, wie fragil und verteilt geworden war, was sie weiter „Produkt“ nannte.

Die jüngste Beschleunigung, in den letzten Monaten, ist der Einzug von Sprachmodellen in die Software-Produktionskette. Hier ist der Sprung nicht nur quantitativ, sondern kategorial: was ins Produkt einzieht, ist keine deterministische Befehlssequenz, sondern eine probabilistische Komponente, deren Outputs auch bei gleichem Input nicht exakt reproduzierbar sind, und deren Gewichte, sobald der Anbieter zum nächsten Modell übergeht, möglicherweise nicht mehr zugänglich sind.

Eine heute laufende Anwendung, die per API ein Frontier-Modell nutzt, ist eine Anwendung, deren beobachtbares Verhalten von einer Komponente abhängt, die sich morgen anders verhalten könnte, in zwei Jahren nicht mehr in einer wiederherstellbaren Form existieren könnte und deren inneres Funktionieren niemand inspiziert — nicht einmal die Trainerin. Wer Software entwickelt, weiß: würde uns ein Nutzer von vor fünf Jahren bitten, einen damals beobachteten Bug exakt zu reproduzieren, wäre die ehrliche Antwort, dass wir es nicht können — denn das System, das den Bug erzeugte, existiert in keiner restorable Konfiguration mehr. Abhängigkeiten aktualisiert, externe APIs mit neuem Vertrag, Datenbank migriert, KI-Modell ersetzt. Wir haben Logs. Wir haben den Code unserer Anwendung. Aber das Ereignis, das den Bug erzeugte, war ein Konzert; von Konzerten bleiben Aufnahmen, nicht Konzerte.

Diese Metapher, glaube ich, fasst den ontologischen Sprung am besten. Heutige Software ist keine Schallplatte mehr, sie ist ein Konzert.

Die Schallplatte ist ein stabiles, bewahrbares, vergleichbares Artefakt, ein Objekt mit zeitlicher Identität. Das Konzert ist ein im Raum und in der Zeit verteiltes Ereignis, von vielen Agenturen in Echtzeit ko-produziert, unwiederholbar — von dem es Spuren, aber keine Originale gibt. Hören wir die Aufnahme eines Keith-Jarrett-Konzerts von 1975, hören wir ein abgeleitetes Artefakt, nicht das Konzert, das einmal stattfand und zu Ende ging. Das Gleiche gilt für eine SaaS-Anwendung heute.

Was der Nutzer gestern um 11 Uhr erlebt hat, ist ein Ereignis, ko-produziert von der Anwendung, dem Browser, der Netzwerklatenz, der aktuellen Version des zugrundeliegenden LLM, der Konfiguration zwölf externer APIs, einem Rate Limit, das in jenem genauen Moment einen bestimmten Wert hatte. Dieses Ereignis ist nicht reproduzierbar, nicht bewahrbar, ontologisch kein Objekt. Es ist, eben, ein Konzert.

Der Einwand und die Kopie, die nicht mehr ist

An dieser Stelle könnte jemand einwenden, die Unterscheidung sei übertrieben — auch 1998 lief Software auf einem OS, das von Treibern und Hardware abhing, Laufzeit-Kontingenz gab es auch damals, jeder Gebrauch einer Anwendung war immer in gewissem Maß Ereignis und nicht Objekt.

Der Einwand ist teilweise korrekt, und ihn ernst zu nehmen ist wichtig, um die Diagnose nicht in Nostalgie zu verwandeln. Der Unterschied, der alles ändert, ist aber ein einziger — und genau der, den das Recht noch nicht metabolisiert hat.

1998 existierte stets eine Kopie des Artefakts. Im engsten, konkretesten Sinn — im Tresor des Anbieters oder auf der Festplatte des Nutzers oder im Archiv eines digitalen Archivars — existierte ein materielles Objekt, das die Software in autarker Form enthielt. Diese Kopie war der Berührungspunkt zwischen rechtlichem Produkt und exekutivem Ereignis. Der archimedische Punkt, der ein Zurückgehen, Prüfen, Vergleichen, Urteilen ermöglichte. Was es der Juristin erlaubte zu sagen „dieses Produkt war fehlerhaft“ — weil es ein Produkt gab.

Heute existiert diese Kopie nicht mehr, nicht aus Nachlässigkeit oder schlechter Wahl, sondern konstruktiv. Die SaaS-Anwendung von Anbieter X am Dienstag um 14:23 Uhr vor drei Monaten existiert in keinem Backup, keinem Tresor, keinem Archiv. Es existiert nur die Möglichkeit, näherungsweise und teilweise zu rekonstruieren, was sie hätte sein müssen — durch das Kreuzen von Logs, Code-Versionen, Abhängigkeitskonfigurationen, Modellgewichten, Datenbankzustand.

Eine archäologische Rekonstruktion, kein Zugriff aufs Objekt. Selbst wenn sie gelänge, wäre das Resultat etwas anderes — ein Modell der Anwendung jenes Moments, nicht die Anwendung jenes Moments. Das Produkt, im zweihundertjährigen Rechtssinn, ist verschwunden. Was an seiner Stelle ist, wurde nie benannt.

Das EU-Korpus und seine Schieflage

Dem EU-Gesetzgeber muss man zugutehalten: er hat gemerkt, dass etwas nicht passt. In den letzten Jahren hat er ein eindrucksvolles Normenpaket produziert, das den neuen Gegenstand mit verfügbaren Mitteln zu fassen versucht.

Der Cyber Resilience Act, in Kraft seit Dezember 2024, voll anwendbar ab Dezember 2027, führt Security by Design und Security by Default für Produkte mit digitalen Elementen ein, schreibt Lebenszyklus-Support, fordert ein Software Bill of Materials. Die neue PLD, oben erwähnt, dehnt die Haftung explizit auf Cybersicherheitsmängel und fehlerhafte Updates aus. Der AI Act, in Kraft seit 1. August 2024, allgemein anwendbar ab 2. August 2026 (einige Bestimmungen 2. August 2027), klassifiziert KI-Systeme nach Risiko und verlangt Dokumentations-, Transparenz-, Konformitätsbewertungspflichten. Dazu kommen NIS2, DORA, Data Act, EAA.

Zusammen bilden sie das ehrgeizigste Normenkorpus, das je zur Disziplinierung der Softwareherstellung geschaffen wurde — ein ernsthaftes, technisch informiertes, kulturell wichtiges Vorhaben. Es zu banalisieren als Bürokratie oder Innovationsbremse, wie es eine bestimmte libertäre Vulgata kalifornischer Prägung tut, wäre falsch. Die These dieses Aufsatzes ist vielmehr: bei aller Ernsthaftigkeit und Wichtigkeit versuchen diese Instrumente, das Konzert mit den Kategorien der Schallplatte einzufangen — und dieses kategoriale Auseinanderfallen wird in den nächsten Jahren Folgen produzieren, die wir erst zu erahnen beginnen.

Der Fall Software Bill of Materials ist paradigmatisch. Das SBOM listet alle in eine Software einfließenden Komponenten, ihre Versionen, Abhängigkeiten, Lizenzen — softwareäquivalente Zutatenliste auf der Verpackung. Auf dem Papier sinnvoll.

In der Praxis ist das SBOM die Fotografie eines Konzerts, mit allen epistemischen Grenzen dieser Bedingung. Die Foto ist nicht das Konzert; sie ist bereits ein anderes Objekt, abgeleitet, partiell, datiert. Im Augenblick der Aufnahme ändert sich das Konzert schon, im Sekundenbruchteil danach könnten transitive Abhängigkeiten aktualisiert sein, die externe API ihren Vertrag gewechselt haben, das Modellgewicht ersetzt sein.

Das SBOM erfasst einen Zustand, doch heutige Software hat keine stabilen Zustände, nur Flüsse. Die Norm verlangt also, die Foto aktuell zu halten — was Prozesse der Continuous SBOM Generation erzeugt, mit Tools, die das SBOM bei jedem Build, bei jedem Deploy, idealerweise in Echtzeit erstellen. Paradoxes Resultat: das Dokument, das die Produktidentität erfassen sollte, vervielfältigt sich in tausende täglicher Schnappschüsse, von denen jeder bereits beim Erzeugen veraltet ist. Das SBOM erfasst nicht das Produkt, weil es kein Produkt gibt. Es erfasst den Fluss, in diskreten Frames, und jeder Frame ist juristisch relevant. Die dokumentarische Last ist enorm, ihr Beweiswert für die Frage, wer in einem präzisen Moment für was verantwortlich war, ist deutlich weniger eindeutig, als die Gesetzgeber annehmen.

Dasselbe Problem, durch die stochastische Natur der Modelle verschärft, stellt sich für den AI Act. Artikel 10 verlangt, dass Trainings-Datasets dokumentiert, nachvollziehbar, qualitätsgesteuert sind. Artikel 15 verlangt, dass Hochrisiko-Systeme genau, robust, cybersicher sind. Artikel 72 verlangt Post-Market-Monitoring. Jede Pflicht ist isoliert sinnvoll und verweist auf Praktiken, die beste ML-Engineering ohnehin annehmen sollte.

Was die Gesetzgeber nicht voll absorbiert haben: das Sprachmodell, das ein Anbieter heute via API anbietet, ist ein Objekt, dessen Identität in der Zeit bestenfalls konventionell ist. Gewichte werden aktualisiert, RLHF verfeinert, Guardrails geändert — was weiter GPT-4 oder Claude Opus oder Gemini Ultra heißt, ist aus Sicht des beobachtbaren Verhaltens ein anderes Objekt als das, was vor sechs Monaten denselben Namen trug.

Die Trainingsdokumentation zu verlangen, heißt, die Dokumentation von etwas zu verlangen, das im Moment der Dokumentation bereits durch ein anderes Training überholt sein kann. Post-Market-Monitoring ist eine ausgezeichnete Praxis, setzt aber einen Markt voraus, in dem das Produkt zum Verkaufs- und zum Nutzungszeitpunkt dasselbe ist — bei Sprachmodellen fast nie wahr.

Es geht nicht darum, den AI Act für falsch zu erklären — er ist eine der artikuliertesten regulatorischen Antworten, die in vergleichbarem Maßstab je versucht wurden. Aber er erbt vom Produkthaftungsrecht eine Reihe ontologischer Voraussetzungen, die das zu regulierende Objekt nicht erfüllt; die Spannung wird sich in den nächsten Jahren auf die Schultern der Praktiker entladen — als Pflichten mit ambigem Wert, Dokumente unklaren Realitätsbezugs, Streitigkeiten, in denen der Streitstoff sich auf die Frage reduziert, ob ein Snapshot zu jenem Zeitpunkt repräsentativ war.

CrowdStrike, 19. Juli 2024

Ein jüngstes Beispiel, in seiner Tragweite weltweit Lehrstoff, hilft, das konkret zu sehen.

Am 19. Juli 2024 verursachte ein fehlerhaftes Update des Falcon-Sensors von CrowdStrike den gleichzeitigen Absturz von rund 8,5 Millionen Windows-Rechnern weltweit, mit Boot-Loop, der manuelles Eingreifen pro Gerät verlangte. Stillgelegte Flughäfen, in den Papiermodus zurückgekehrte Krankenhäuser, nicht operative Banken, gesperrte Sender, nicht durchgestellte Notrufe. Delta Airlines allein meldete über 500 Millionen Dollar Direktschaden, allein die Fortune 500 nicht versicherte Verluste in Höhe von rund 5,5 Milliarden, globale Schätzungen je nach Quelle in zweistelliger Milliardenhöhe.

Der nachfolgende Streit, in mehreren Jurisdiktionen weiter offen, konzentriert sich auf die Frage: wer war verantwortlich.

• CrowdStrike, das ein Update mit einem Defekt verteilte, der durch jede ernsthafte Prüfung erkennbar gewesen wäre.
• Microsoft, das einer Drittsoftware Kernel-Privilegien zugestand, die das Betriebssystem in den Boot Loop zwingen konnten.
• Die deployenden Organisationen, die Updates per Auto-Push akzeptierten, ohne Canary-Phasen.
• Die EU-Regulierer, laut Microsofts Verteidigung, die Jahre zuvor aus Wettbewerbsgründen die Kernel-Öffnung erzwungen hätten.

Jede Zuschreibung erfasst einen realen Aspekt. Keine, einzeln, erzählt das Geschehene. Das Geschehene war ein Orchestrierungsversagen — ein Ereignis, in dem viele Akteure, jeder in seinem Maß, effektiven Einfluss auf das Laufzeitverhalten hatten, und keiner diesen Einfluss proportional zu den möglichen Folgen ausübte.

Das geltende Recht hat keine Mittel, Verantwortung so zu verteilen; das Verfahren rutscht in Szenarien, in denen gewinnt, wer die besseren Anwälte oder die sicherste Vertragsposition hat — anders gesagt: das Recht hat verzichtet, Substanzielles zum Vorfall zu sagen. Ein CrowdStrike-Fall, im Licht der Kategorie verantwortliche Komposition, hätte ein Urteil produzieren sollen, das Verantwortung in identifizierbaren Quoten zwischen den Akteuren entlang Blast Radius und tatsächlicher Kontrolle verteilt — und einen Präzedenzfall für künftige Vorfälle schafft, die sicher zahlreich sein werden. Nichts dergleichen geschieht — die Kategorie dafür existiert nicht.

Latour, Ricœur und die Pluralität des Handelns

Die verantwortliche Komposition ist keine ex nihilo-Erfindung, sondern die Anpassung philosophischer Reflexionen des 20. Jh. an das juristische Feld.

Bruno Latour zeigte mit der Actor-Network Theory in den 80ern: komplexe Handlungen haben nie einen einzigen Agenten, sondern emergieren aus Netzen menschlicher und nicht-menschlicher Akteure, deren Analyse es verlangt, die Sujet-Obsession zu suspendieren und die tatsächlichen Verbindungen zu verfolgen. Sein kanonisches Beispiel des „schlafenden Polizisten“ (Bodenwelle) ist erhellend: die Bodenwelle erzwingt das Tempolimit unabhängig vom Polizisten, sie ist ein nicht-menschlicher Akteur mit eigener Agency.

Das Abbremsen des Autos wird ko-produziert vom Fahrer, der Bodenwelle, der StVO, der Angst vor Federungsschaden, der gemeinsamen Kultur, die die Welle als Vorsichtszeichen erkennt. Keiner der Akteure allein erklärt das Bremsen. Das positive Recht schneidet die Verantwortung aus pragmatischen Gründen auf den Fahrer zu, doch das philosophische Verständnis verlangt, alle fünf zusammen zu sehen. Den Schritt, den das Recht noch nicht getan hat — die Philosophie seit vierzig Jahren —, wäre, diese Verteilung des Handelns als Norm zu akzeptieren und Konsequenzen für die Zurechnung zu ziehen.

Paul Ricœur in Soi-même comme un autre (1990) und seinen Reflexionen zur Imputabilität fügte hinzu: Zurechnen ist ein narrativer Akt, der eine plausible Kausalitätsgeschichte verlangt; ist sie pluralistisch, kann die imputierende Erzählung nicht auf ein einziges Subjekt reduziert werden, ohne die Wahrheit des Ereignisses zu verraten. Imputation ist Hermeneutik der Verantwortung — sie verlangt Geduld, mehrere Ebenen, kein Vereinfachen.

Heutiges Produkthaftungsrecht vereinfacht zu sehr, weil es eine narrative Grammatik des 19. Jh. erbt, in der der Hersteller einer, identifizierbar, imputierbar war. Imputabilität für heutige Software zu rekonstruieren, heißt, die plurale Natur des Handelns zu akzeptieren und sie auch im Urteilstext wiederzugeben.

Die verantwortliche Komposition

Hört man hier auf, droht die Diagnose pessimistisch zu wirken. Mein Anliegen ist das Gegenteil: wenn der Produktbegriff seine Funktion der Verantwortungszurechnung nicht mehr trägt, muss man die Ersatzkategorie zu denken beginnen.

Das ist eine Aufgabe, die weder reinen Juristen — ohne Runtime-Erfahrung — noch reinen Ingenieuren — die Recht eher als externe Belästigung behandeln — übergeben werden kann. Die Kategorie muss vierhändig gedacht werden — von jenen mit Code-Praxis und Rechtslektüre — und ausgehen vom Faktum: heutige Software ist Orchestrierung, Komposition, verteiltes Ereignis, kein Objekt.

Vorschlag, vorläufig: verantwortliche Komposition.

Was ist eine verantwortliche Komposition näherungsweise? Eine Konfiguration menschlicher und nicht-menschlicher Komponenten, organisiert um eine spezifische, einer Nutzerin angebotene Funktion. Kein Beteiligter hat integrale Kontrolle, jeder übt einen identifizierbaren Grad effektiven Einflusses auf das beobachtbare Laufzeitverhalten aus.

Verantwortung folgt nicht der formalen Inhaberschaft („wer Vertragsinhaber ist, haftet für alles“) und nicht dem historischen Ursprung der Komponenten („Bug in einer importierten Bibliothek? Schuld der Bibliotheks-Maintainerin“). Verantwortung folgt dem Gradienten effektiven Einflusses.

Wer im Schadenszeitpunkt durch eine gezielte technische Handlung das Systemverhalten ändern konnte, haftet proportional zum Grad dieser Möglichkeit. Der Anbieter des KI-Modells, der die Guardrails hätte aktualisieren können und es nicht tat, haftet anteilig. Der Integrator, der das Modell für eine sensible Funktion ohne adäquate Risikobewertung wählte, haftet anteilig. Die Nutzerin, die das System unter Umgehung der Warnungen anomalisch konfigurierte, haftet anteilig. Niemand haftet für alles, niemand haftet für nichts — jeder für seinen Anteil an der Orchestrierung.

Einfach zu sagen, höllisch komplex zu implementieren — wie jede neue Rechtskategorie in ihren ersten Jahrzehnten.

Einwände kommen sofort. Erster: effektive Einflussnahme ist schwer messbar, ein darauf gestütztes System wäre Quelle von Unsicherheit. Wahr, aber weniger schwerwiegend, als es scheint: das Recht arbeitet längst mit fluiden Begriffen — Verschulden, Vorhersehbarkeit, adäquate Kausalität — und hat dafür operative Werkzeuge entwickelt.

Effektiver Einfluss in einem verteilten System ist messbar über das, was Ingenieure Blast Radius nennen — die Schätzung des Wirkungsumfangs einer technischen Handlung. Ein API-LLM-Anbieter hat einen Blast Radius, der potenziell alle Integratoren umfasst — eine Änderung propagiert sich sofort. Ein Integrator hat einen auf seine Nutzer begrenzten Blast Radius, der jedoch verstärkt sein kann, wenn seine Anwendung selbst Infrastruktur weiterer Anwendungen ist.

Es gibt grobe, aber handhabbare technische Metriken zur Schätzung des Blast Radius jedes Akteurs, und die Doktrin könnte darauf eine abgestufte Verantwortungstaxonomie bauen. Nicht fluider als die Fahrlässigkeitslehren des 19. Jh., bevor jahrzehntelange Rechtsprechung sie operabel machte.

Zwei Verformungen, denen zu widerstehen ist

Der zweite Einwand ist politischer und kommt aus zwei entgegengesetzten Richtungen, beide interessiert.

Die erste: kalifornische Big-Tech-Kreise haben in den letzten zwanzig Jahren ein Narrativ gebaut, wonach die Open-Source- und Komponenten-Natur der Software es unmöglich mache, jemandem konkret Verantwortung zuzuschreiben — Verantwortung müsse sich daher auf die ausdrücklich akzeptierten Vertragsbedingungen beschränken. Liest demnach: erleidet eine Nutzerin Schaden durch eine Anwendung, die eine Open-Source-Bibliothek anonymen Autors nutzt, die ihrerseits in einer Cloud läuft, deren Anbieter in den AGB jede Verantwortung ablehnt — dann haftet niemand für nichts, oder genauer: nur jener, der vertraglich Verantwortung übernommen hat.

Das ist die Doktrin der verteilten Unverantwortlichkeit — bequeme Positionsrendite für jene, die die zentralen Knoten der Orchestrierung besetzen: man kassiert den Wert, lagert die Risiken aus. Die verantwortliche Komposition stellt sich frontal gegen sie und weist die Idee zurück, dass das Fehlen formaler Inhaberschaft dem Fehlen substantieller Verantwortung gleichkomme. Ist dein Modell die kritische Komponente Tausender nachgelagerter Anwendungen, hängt deine Verantwortung nicht davon ab, ob du mit deren Endnutzern Verträge geschlossen hast. Sie hängt von deiner Rolle in der Orchestrierung ab — und diese ist objektiv messbar.

Die andere Richtung: kontinentaleuropäischer Formalismus, mit der Doktrin des absoluten Inhabers.

In dieser Tradition haftet der für die Datenverarbeitung Verantwortliche oder der Service-Provider oder der KI-Deployer für alles in der Kette, unabhängig vom Entstehungsort der Nicht-Konformität. Intuitiv gleichmacherisch, weil sie der Nutzerin garantiert, dass jemand stets antwortet. In der Praxis aber zwei ernsthafte Verzerrungen.

Erstens: sie lädt dem Inhaber Verantwortung auf, deren technische Kontrolle er nicht hat — er muss sich gegen Verfahren wegen Defekten verteidigen, die von Komponenten stammen, die er nicht geschrieben, nicht gewählt, nicht inspizieren kann. Zweitens: sie ent-verantwortet die vorgelagerten Knoten — gerade jene mit dem systemischsten Einfluss —, weil sie wissen, dass ihr Anteil formell auf den Endinhaber abgewälzt und die Gerichte weiter mit dem Finger auf den Sichtbarsten zeigen werden.

Auch dagegen wendet sich die verantwortliche Komposition. Die formale Position des Inhabers erschöpft die Frage nicht, und eine nur scheinbar verteilte Last, die sich faktisch immer beim zugänglichsten Knoten konzentriert, lässt die Machtverhältnisse der Branche unverändert.

Der Vorschlag steht damit in einem für beide gängigen Sensibilitäten unbequemen Terrain — und gerade darum verdient er, ausartikuliert zu werden. Wer in der Software arbeitet, weiß, dass die Idee einer rein vertraglichen Verantwortung eine nützliche Fiktion für Silicon Valley ist und eine tägliche Erfahrung der Ohnmacht für jene in Pescara, Mailand oder Frankfurt, die ein System in echten Zwängen wirklich liefern müssen. Zugleich weiß, wer mit europäischer Compliance arbeitet, dass die Doktrin des absoluten Inhabers den Deployer in eine juristische Schmelzsicherung verwandelt — wirtschaftliche Funktion: durchbrennen, wenn das System bricht, sodass die vorgelagerten Komponenten weiter Externalitäten produzieren.

Heutige Software braucht eine Kategorie, die keine der beiden ist und die Verantwortung so verteilt, dass sie die tatsächliche Verteilung technischer Macht abbildet. Keine symmetrische Verteilung — technische Macht ist nicht symmetrisch. Keine Konzentration auf den Inhaber — sie ist nicht beim Inhaber. Eine Verteilung entlang des Gradienten effektiver Einflussnahme, mit transparenten Metriken, einer praktikablen Doktrin, einer ratio, die Praktiker als ihrer Arbeitserfahrung adäquat erkennen.

In manchen Bereichen passiert ansatzweise so etwas, ohne so genannt zu werden. Die DSGVO mit Art. 28 und EDPB-Leitlinien zur Sub-Auftragsverarbeitungs-Kette beginnt zaghaft, eine Abstufung der Verantwortung entlang der Verarbeitungskette anzuerkennen — formell, ohne den nötigen begrifflichen Apparat. Datenschutzfolgenabschätzungen, ernsthaft erstellt, enthalten in nuce eine Blast-Radius-Analyse für personenbezogene Daten.

NIS2 führt für Managed-Service-Anbieter Pflichten ein, die deren systemische Rolle in der Sicherheitskette anerkennen. Der AI Act mit seinen Provider/Deployer/Importer/Distributor-Unterscheidungen versucht, eine Rollentaxonomie aufzubauen, die — noch zu starr — in Richtung einer nicht inhaberzentrierten Verantwortungsverteilung weist.

Keines dieser Instrumente hat das Prinzip der effektiven Einflussnahme als Verantwortungsgradient bisher explizit formuliert, doch alle enthalten Spuren eines Umdenkens, das nur auf doktrinale Systematisierung wartet. Eindruck: Es fehlt das, was für Lord Atkin der Neighbour Principle war — eine synthetische, einprägsame, operative Formulierung, die fünfzig Jahre folgender Rechtsprechung leiten kann. Wer sie schreibt, hat fürs 21. Jahrhundert getan, was das House of Lords fürs 20. tat.

Damit diese Formulierung geschrieben werden kann, braucht es eine intellektuelle Figur, die heute praktisch nicht existiert. Keine reinen Juristen — die innere Grammatik heutiger verteilter Systeme lernt man nicht in Jura. Keine reinen Ingenieure — die Grammatik des Rechts und seine zweihundertjährige Kategoriengeschichte lernt man nicht in Computer Science.

Es braucht Hybride, Grenzfiguren, die beide Berufe lange genug ausgeübt haben, um Logiken und Grenzen verstanden zu haben, und die bereit sind, etwas zu denken, das keiner der Korpora allein denken könnte. In Italien hat diese Figur noch keinen festen Namen. In angelsächsischen Ländern hat sich der Compliance Engineer oder Technical Counsel etabliert — Definitionen, die sich auf Vermittlung beschränken, ohne wirklich eine dritte Kultur zu bauen.

Es braucht etwas Ehrgeizigeres: eine Figur, die nicht nur Tech-Jargon in Rechtsjargon übersetzt und umgekehrt, sondern neue Kategorien erarbeitet, die keiner der Ausgangsdialekte allein zu sagen wüsste. Beruf teils theoretisch (philosophische Ausbildung für abstrakte Kategorien) und teils praktisch (Alltag von Deployment, transitiver Abhängigkeit, durch Minor-Release gebrochener Rückwärtskompatibilität, mehrdeutiger Stack Trace). Ohne Praxis bleiben abstrakte Kategorien in der Luft. Ohne abstrakte Bildung erschöpft sich Praxis in Müdigkeit und geschlossenen Tickets.

Der dritte Weg ist schwer — nicht, weil er seltene Begabungen verlangt, sondern weil der Arbeitsmarkt ihn nicht honoriert, Universitäten ihn nicht ausbilden, Firmen ihn nicht organisieren. Er existiert nur durch individuellen Willen — und gerade deshalb tragen die, die ihn praktizieren, eine intellektuelle Verantwortung, die ihrer formalen Stellung weit voraus ist.

Vom Bill of Materials zum Bill of Accountability

Zurück zum konkreten Ausgangsproblem: wie ordnet man Verantwortung für einen durch heutige Software verursachten Schaden zu?

Akzeptiert man, dass Software kein Produkt mehr ist, sondern Komposition, und dass die Komposition entlang des Gradienten effektiver Einflussnahme zu analysieren ist, so ist der erste operative Schritt eine Dokumentationspraxis der Komposition — keine SBOM-Standfotografie, sondern eine dynamische Karte der Einflussbeziehungen.

Ein solches Werkzeug sollte je Anwendung Antworten geben auf:

• Welche Komponenten würden, modifiziert, das beobachtbare Systemverhalten ändern.
• Welche Akteure haben die technische Möglichkeit, sie zu modifizieren.
• Welche vertraglichen und normativen Pflichten lasten auf jedem.
• Welche Beweise (Logs, Audit) erlauben ex post die Rekonstruktion eines präzisen Zustands.
• Welche Kommunikationskanäle erlauben einem nachgelagerten Akteur, ein Alarmsignal nach oben zu schicken.
• Welche typischen Reaktionszeiten entlang der Kette gelten.

Das Resultatdokument wäre kein Bill of Materials mehr, sondern etwas wie ein Bill of Accountability — eine Karte der Befugnisse und Pflichten entlang der Orchestrierung. Es zu erzeugen verlangte Arbeit, Kooperation zwischen Akteuren mit nicht immer ausgerichteten Interessen, Normen, die seine Erstellung verlangen. Aber es würde das Problem beim Namen nennen, statt es auf eine Inventarfrage zu reduzieren.

Drei Folgen für jene, die Software entwickeln

Aus Sicht der Praxis hätten diese Re-Artikulationen wichtige Folgen.

Erste Folge: der Standardvertrag, der heute alle Verantwortung auf den Endlieferanten oder besten Falls auf das Jahresentgelt begrenzt, würde ein Dokument völlig anderer Struktur. Er würde aus einer Komposition-Analyse heraus gebaut — mit klarer Artikulation, welche Komponenten der Anbieter kontrolliert vs. nur integriert, welche Risiken er voll übernimmt vs. weiterleitet, welche Informationspflichten er übernimmt vs. technisch nicht erfüllen kann. Längerer, komplexerer, ehrlicherer Vertrag — und langfristig auch besser verteidigbar, weil er die Sache erzählt, wie sie ist.

Zweite Folge: der Entwicklungsprozess sollte schon in frühen Phasen die Reflexion über die Orchestrierung enthalten, in die das System eintreten wird — nicht nur funktionale Anforderungen.

• Wer sind die vorgelagerten Akteure, von denen wir abhängen.
• Welche Garantien geben sie.
• Welchen Blast Radius haben sie uns gegenüber.
• Wie verifizieren wir ihre Änderungen.
• Wie reagieren wir, wenn eine ihrer Änderungen unser erwartetes Verhalten bricht.

Heute auf Architektur-Slides verbannte und dann vergessene Fragen sollten Teil der Spezifikation werden. Ihre Abwesenheit in Projektdokumentation würde so unprofessionell wirken wie heute das Fehlen eines Threat Models.

Dritte Folge — kulturell vielleicht die interessanteste, betrifft die Ausbildung. Heute lernt man, Code zu schreiben, der funktioniert, dann — mit Glück — Code, der in Produktion funktioniert. Fast niemand lernt Code zu schreiben, der innerhalb einer bewussten Orchestrierung funktioniert.

Das Bewusstsein der Orchestrierung kommt spät, oft durch einen Vorfall, selten als gelehrte Kompetenz. Eine Ausbildung, die die verteilte Natur heutiger Software ernst nimmt, müsste hier anfangen — vom ersten Tag zeigen: eine API zu schreiben heißt, in eine Orchestrierung einzutreten; eine Bibliothek zu wählen heißt, einen vorgelagerten Anbieter zu akzeptieren; in die Cloud zu deployen heißt, sich in einer Infrastruktur einzunisten, deren Architekturentscheidungen anderswo getroffen werden.

Nicht um Junior-Entwickler zu erschrecken, sondern um sie zu gewöhnen, das zu sehen, was erfahrene Entwickler nach zwanzig Jahren Narben sehen. Orchestrierung ist Gegenstand ihrer Arbeit, nicht Hintergrund. Der Code ist Teilnahme an einem Konzert, nicht ein autarkes Objekt. Wachsen sie damit auf, kommt die Verantwortungsfrage nicht als externe Belästigung, sondern als intrinsische Berufsdimension.

Wenn auch das Schreiben Orchestrierung ist

Wer vermutet, das alles werde durch die SaaS-Linse überdramatisiert und in einfacheren Kontexten halte die Produktkategorie noch — dem sei entgegnet: die Richtung des AI-nativen Entwickelns macht das Problem schärfer, nicht milder.

Beim Arbeiten mit Werkzeugen wie Claude Code oder Praktiken wie specification-driven development à la SpecKit hört Code auf, das Objekt zu sein, das die Entwicklerin direkt schreibt — er wird Output einer Generierungskette: Spec → Modell → Artefakt → Integration in eine bereits verteilte Orchestrierung. Die gestern geschriebene Spec und der gestern generierte Code würden, heute vom selben Modell regeneriert, plausibel ähnlich, aber nicht identisch herauskommen, weil das Modell sich geändert hat.

Der bereits durch Continuous Deployment geschwächte Versionsbegriff wird so noch instabiler — nicht nur zur Ausführungszeit, sondern auch zur Schreibzeit. Wer so entwickelt, weiß: exakte Reproduzierbarkeit ist regulatives Ideal, keine reale Eigenschaft.

In einer Welt, in der auch das Schreiben Orchestrierung ist — zwischen Entwicklerin, Spec, Modell, Toolchain, Pipeline —, wird die verantwortliche Komposition zur natürlichen Kategorie zum Denken der Verantwortung — die einzige, in der das Fehlen monolithischer Autorschaft nicht automatisch in fehlende Imputabilität übersetzt wird.

Der Tod einer Kategorie

Es bleibt eine Frage, die der Aufsatz beantworten muss: macht es Sinn, vom Tod einer Rechtskategorie zu sprechen, oder beschreiben wir nur eine Evolution, einen Wandel, ein Update?

Die Sprache des Todes ist stark. Rechtfertigung: eine Kategorie stirbt im foucaultschen Sinn — wenn sie aufhört, das diskursive Feld produktiv zu organisieren, und beginnt, es zu behindern.

Der Produktbegriff, auf heutige Software angewandt, organisiert das Feld nicht mehr, er behindert es. Er erzeugt Pflichten, denen keine Praxis entspricht; Dokumente, die keine Objekte abbilden; Streitigkeiten, die sich an der Definition des Objekts festlaufen, bevor sie zur Sache kommen.

Ein Begriff, der das Feld behindert, ist nicht nützlich, auch wenn er formell in Kraft bleibt. Der Lichtäther-Begriff in der Physik des späten 19. Jh. war nicht falsch im Sinne einzelner Aussagen — er war ein Begriff, der das Feld nicht mehr produktiv organisierte und es zu behindern begann, bis Einstein ihn schlicht entfernte.

Der Produktbegriff im heutigen Software-Recht steht in vergleichbarer Phase. Noch da, in den Texten, in den Sälen. Aber nicht mehr arbeitend. Und so zu tun, als arbeite er, ist gefährlicher als zuzugeben, dass er es nicht tut.

Ich behaupte nicht, der EU-Gesetzgeber hätte auf die richtige Kategorie warten müssen. Wäre intellektuell rein, politisch unmöglich gewesen — und der Schaden fehlender Regulierung hätte den einer kategorial unvollkommenen übertroffen.

Ich sage bescheidener: die jetzige Regulierung ist work in progress; ihre kategoriale Unvollkommenheit gehört offen anerkannt; und die Konstruktion der Ersatzkategorie ist keine Sache nur für Gesetzgeber, sondern auch für die Praktiker und für die Rechtsphilosophen. Wer beide Beine drinnen hat, kann mehr beitragen als wer nur eines hat. Und der Beitrag ist kein akademisches Vergnügen: jedes Jahr ohne Ersatzkategorie ist ein Jahr, in dem Streitfälle über formale Wege gelöst werden, die nicht die substantielle Verantwortung abbilden; in dem vorgelagerte Anbieter weiter Risiko transferieren, ohne den Preis zu zahlen; in dem Endabnehmer als Sicherungen dienen, ohne dass das System als Ganzes besser wird.

Lord Atkins Saal

Ich habe mich verbreitet, und wer mir bis hierher gefolgt ist, verdient eine ehrliche Synthese.

Wir sind dahin gelangt zu sagen, dass der juristische Produktbegriff, im 20. Jh. auf einer Ontologie begrenzter, bewahrbarer, identifizierbarer Objekte gebaut, für heutige Software unzureichend ist — die eine Orchestrierung menschlicher und nicht-menschlicher Komponenten ist, ein verteiltes Ereignis mehr als ein Objekt, ein Konzert mehr als eine Schallplatte.

Wir sind dahin gelangt zu sagen, dass die EU-Regulierung — der ernsteste je versuchte Anlauf — versucht, das Konzert mit den Schallplatten-Kategorien zu fassen, und dass diese Spannung Pflichten erzeugt, deren substantieller Rechtswert mehrdeutig ist.

Wir sind dahin gelangt, an Stelle der Produktkategorie eine neue zu fordern, vorläufig nennbar verantwortliche Komposition, die Verantwortung nach dem Gradienten effektiver Einflussnahme zur Laufzeit verteilt — nicht nach formaler Inhaberschaft und nicht nach verteilter Unverantwortlichkeit.

Wir sind dahin gelangt zu sagen, dass diese Konstruktion eine hybride Intellektuellen-Figur verlangt — Code-Praxis und Rechtslektüre —, die der Markt nicht honoriert und die nur durch individuellen Willen existiert.

Und dass, solange die Ersatzkategorie nicht emergiert, sich Streitfälle weiter über formale Wege entladen, die nicht die substantiellen Verantwortlichkeiten abbilden — mit realen Kosten für jene, die den Beruf ehrlich ausüben.

Was am Ende vielleicht festzuhalten ist: Lord Atkin war 1932 kein reiner Jurist, sondern ein Richter, der viele Flaschen brechen und viele Menschen erkranken sah und etwas Praktisches über die industrielle Welt verstand, das das frühere begriffliche Instrumentarium nicht zu sagen wusste.

Donoghue v. Stevenson war möglich, weil jemand in einem einzigen Kopf die materielle Erfahrung der Industriewelt und die begriffliche Tradition des Zivilrechts zusammengehalten hat. Heute braucht es, in einem einzigen Kopf, materielle Erfahrung verteilter Systeme und begriffliche Tradition des Haftungsrechts. Das lässt sich nicht delegieren, und es lässt sich auch nicht in einem Aufsatz erledigen. Was ein Aufsatz tun kann: das Problem benennen, eine Richtung anbieten, jene mit ähnlichen Werkzeugen zur Fortsetzung einladen.

Mrs Donoghues Flasche war undurchsichtig, und drinnen war eine Schnecke, die niemand gesehen hatte. Heutige Software ist noch undurchsichtiger, und drinnen sind viel mehr Schnecken — und die Rechtsprechung, die uns schützt, wurde für eine Welt geschrieben, in der die Flaschen aus Glas waren. Es ist Zeit, die Rechtsprechung einer Welt zu schreiben, in der Flaschen nicht mehr existieren.

Drinnen drei Bilder, die mir hängen blieben. Aaron Levie sagt, im Silicon Valley arbeite niemand weniger, eher das Gegenteil. Tyler Cowen, als Ökonom, hält dafür, dass man gerade jetzt viel härter arbeiten sollte — egal ob man glaubt, KI werde die Arbeit entwerten, oder dass sie sie wertvoller machen werde. Und Simon Last von Notion redet von schlaflosen Nächten und einer neuen Angst, der „Token-Anxiety“ — etwas, das es vor zwei Jahren nicht einmal als Begriff gab.

Das Paradox, das swyx in den Mittelpunkt stellt, ist einfach und gerade deshalb beunruhigend. Agenten erledigen mehr Arbeit als je, Benchmarks sättigen, Modelle übertreffen menschliche Experten in Anteilen, die noch vor kurzem Science-Fiction gewesen wären. Und doch haben die, die diese Systeme bauen und betreiben, nie so viel gearbeitet.

Eine Frage entzündet sich, die ich nicht leicht abstellen kann: wenn die Verheißung „mehr Produktivität“ lautete, warum ist das verbreitete Gefühl „mehr Druck“?

Die bequeme Erklärung: nur eine Phase

Der vernünftigste Einwand ist auch der, der mir spontan in den Sinn kommt, wenn ich ehrlich sein will. Vielleicht eine Übergangsphase. Die übliche Disruption: zuerst zerstört sie, dann setzt sie neu zusammen. Wir kennen das vom PC, vom Internet, von Smartphones. Berufe ändern sich, manche verschwinden, andere entstehen, die Produktivität steigt, und am Ende steigt — zumindest für jene, die den Übergang gut steuern — das durchschnittliche Wohl.

Ernsthafter Einwand. Wer ihn ignoriert, gleitet in eine Form Tastatur-Ludditentum: man redet sich ein, das Problem sei die Technik selbst und nicht die Art, wie wir sie in ökonomische und gesellschaftliche Systeme einsetzen.

Aber es gibt einen Punkt, an dem dieser Einwand aufhört zu wirken. Und dieser Punkt ist für mich der Körper.

Der Körper skaliert nicht

Das Problem ist nicht nur, ob KI Knowledge Worker ersetzt oder verstärkt. Das Problem ist, dass der menschliche Körper nicht skaliert.

Nicht wie Tokens skalieren. Nicht wie ein Cluster mit zig Gigawatt skaliert. Nicht wie die Lernkurve eines Modells, das in Wochen riesige Wissensmengen verschlingt.

Der Körper hat eine biologische Uhr, die kein Update zurücksetzt. Er braucht Schlaf — entzieht man ihn ihm Monate, hält er vielleicht weiter, äußerlich, bis etwas reißt. Und es reißt oft auf eine Weise, die nicht vorhergesehen war und sich nicht leicht umkehren lässt.

Er braucht Bewegung, natürliches Licht, Rhythmen. Er ist nicht für drei Uhr morgens entworfen, in denen man einen Agenten debuggt, der achthundert Codezeilen erzeugt hat, die „funktionieren“, die du aber nicht wirklich verstehst.

Das ist nichts Neues. Arbeitsmedizin sagt es, Neurowissenschaft sagt es, jede Hausärztin mit Mindesthonest sagt es. Und doch wirkt im dominanten KI-Diskurs der Körper wie ein Implementierungsdetail. Eine Legacy-Schranke, die mit genug Koffein und Willenskraft umschifft werden müsse.

Von wo ich es betrachte

Ich bin Partner und Tech-Verantwortlicher in einer kleinen ICT-Firma in Pescara. Wir sind ein Dutzend. Seit einer Weile schreibe ich keinen Produktionscode mehr, jedenfalls nicht wie früher. Meine Arbeit wurde Recherche, strategische Spikes, Architekturbewertung, auch Compliance — wenig sexy, sehr real.

Ich verbringe Tage damit zu verstehen, wohin der Markt geht, und zu entscheiden, was Sinn ergibt — für eine Firma, die sich keine Investmentrunde leisten kann, um Fehler aufzufangen. Mit direkter Verantwortung für die Personen, die dort arbeiten — Personen, die abends nach Hause gehen, Familien haben, Körper, Grenzen.

Aus dieser Position sehe ich etwas, das man, mitten im täglichen Fluss, schwerer scharfstellt. KI hat in meinem Team niemandem die Arbeitslast gesenkt. Sie hat sie verwandelt.

Sie hat das Gewicht von der Codeproduktion zur Aufsicht über fremd produzierten Code verschoben — wobei „fremd“ hier ein statistisches Modell bedeutet, das nicht schläft, nicht ermüdet, nicht erkrankt. Aber irrt. Und kreativ, unvorhersehbar irrt.

Hier ein Detail, das mir wichtig erscheint, auch wenn ich noch nicht ganz erklären kann, wie wichtig. Code, der von einer fremden Intelligenz geschrieben wurde, zu lesen, ist eine andere Arbeit, als ihn zu schreiben. Es verlangt konstante Wachsamkeit. Eine Form Aufmerksamkeit, die dich immer leicht in Alarm hält.

Diese Alarmbereitschaft ist unvereinbar mit etwas, das in kognitiver Arbeit fast einen natürlichen Schutz darstellt: der Flow, der Zustand tiefer Konzentration, in dem man nicht zerschnitten ist, nicht ständig unterbrochen, nicht gezwungen, alle dreißig Sekunden Mikro-Urteile zu fällen.

Anforderung steigt, Kontrolle sinkt

Es gibt in der Arbeitsmedizin ein Konzept namens „Job Strain“, in Karaseks Modell. Knapp: die toxischste Kombination — hohe Arbeitsanforderung und niedrige Kontrolle über die eigene Tätigkeit.

Mir scheint, der massive KI-Einzug tut genau das: er verändert das Verhältnis von Anforderung und Kontrolle.

Die Anforderung steigt, weil schnellere Werkzeuge die Output-Erwartung anheben. „Wenn der Agent es in einer Stunde schafft, warum brauchen wir einen Tag?“ — eine Frage, die fast automatisch entsteht, oft ohne Bosheit, aus Trägheit.

Die Kontrolle sinkt, weil du einen wachsenden Teil des Prozesses an Systeme delegierst, die du nicht ganz verstehst und die sich alle paar Wochen ändern. Selbst wenn du sie verstehst, verstehst du sie anders als einen Kollegen oder ein klassisches Software-Bauteil. Eine probabilistischere, fragilere Verständnisform.

In diesem Sinn wirkt die „Token-Anxiety“ auf mich nicht wie Sprachmode. Wie ein Symptom. Angst ist schließlich eine adaptive Funktion. Tritt sie in industriellem Maßstab auf, ist es vermutlich kein individuelles Problem. Es ist ein Systemsignal.

‚Wenn wir bremsen, bremst China nicht’

Hier kommt fast immer ein weiterer Einwand, der einen wahren Kern hat. Bremsen wir, bremsen andere nicht. Setzen wir Grenzen, drücken andere weiter. Im globalen Wettlauf gewinnt, wer zuerst ankommt.

Aber ich frage mich, ob in diesem Satz nicht ein Kategorienfehler steckt.

Wettbewerb zwischen Nationen und Unternehmen ist Wettbewerb zwischen Systemen, nicht zwischen Individuen. Ein System, das die Personen, aus denen es besteht, verbrennt, ist kein wettbewerbsfähiges System. Es verbraucht sein wertvollstes Kapital — Intelligenz und Kreativität von Menschen, die nur dann gut funktionieren, wenn sie gesund, ausgeruht und nicht aus Angst motiviert sind.

Die Software-Geschichte ist voll von Firmen, die kurzfristig durch Crunch „gewonnen“ und mittelfristig verloren haben. Weil die Besten gehen, krank werden oder einfach aufhören, Ideen zu haben. Ein erschöpftes Hirn ist kein Motor, den man auspresst, es ist ein Ökosystem, das kollabiert.

Vielleicht liegt das erste Problem im Brustkorb

Wenn der Punkt nicht nur das Benchmark-Rennen ist, was ist dann das erste Problem?

Ich glaube, es liegt direkt vor unserer Nase, eher in unserem Brustkorb. Das wertvollste Problem ist, wie man Werkzeuge außerordentlicher Macht in das Berufsleben integriert, ohne dass das Berufsleben das Leben verschlingt.

Kein technisches Problem allein. Es ist ein Problem organisationalen Designs, der Managementkultur, der Arbeitspolitik. Und am Ende ein philosophisches: es zwingt zu entscheiden, was es lohnt, mit der Zeit, die wir haben, zu tun. Zeit, die in einer Weise endlich ist, die keine Technik ändern kann.

Persönliches, das doch schwer wiegt

Ich habe einen Sohn. Kein logisches Argument, ein biografisches Faktum. Aber biografische Fakten wiegen manchmal schwerer als Argumente.

Wenn ich abends den Laptop schließe und ihn anschaue, denke ich, dass aller Code des Tages — auch der von Agenten „multipliziert“ — keine Stunde dieser Zeit wert ist. Nicht weil Arbeit nicht zählte. Sie zählt sehr. Sondern weil diese Zeit unwiederbringlich ist, in einer Weise, in der Code es nicht ist.

Code lässt sich neu schreiben. Eine Kindheit nicht.

Ich weiß, in manchen Kreisen klingt das nach Schwäche. Mangel an Ehrgeiz. Sentimentalität, die die nächste Marktbewertung nicht überlebt. Vielleicht ist es das Gegenteil. Vielleicht ist der wahre Ehrgeiz, Systeme, Firmen und Leben zu bauen, die dauern.

Und Dauer verlangt Sorge für das Mittel, durch das alles andere geschieht. Den menschlichen Körper, mit seinem nicht verhandelbaren Bedarf an Ruhe, Beziehung und einer Zeit, die nicht in Tokens pro Sekunde gemessen wird.

Das Alignment, das wir nicht ansehen

Die KI-Branche redet gern über Alignment, wie man Modelle dazu bringt, das zu tun, was man will.

Aber ich frage mich, ob das erste Alignment-Problem nicht die Modelle, sondern uns betrifft.

Wir bauen eine Aufmerksamkeits- und Produktivitätsökonomie, in der die Anreize oft falsch ausgerichtet sind gegenüber dem, was wir als nötig für menschliche Gesundheit kennen. Wir schlafen wenig, bewegen uns wenig, halten wenig inne. Und versuchen mit Technik zu kompensieren — Meditations-Apps, Schlaf-Tracker, Supplemente.

Als hätten wir ein Produktivsystem geschaffen, das Wohlbefinden nicht mehr als Nebenprodukt der Arbeit erzeugt — und uns dann wundern, dass eine Wellness-Industrie entsteht, um die Schäden zu reparieren.

Eine Richtung, keine Lösung

Ich habe keine saubere Lösung, und ich misstraue jenen, die welche anbieten. Eine Richtung habe ich.

Ernst nehmen, dass menschliche Gesundheit und menschliche Zeit die primäre Schranke sind. Nicht Modelleffizienz, nicht Deploymentgeschwindigkeit, nicht die Anzahl pro Stunde generierter Codezeilen.

Jede organisatorische Entscheidung, jedes Sprint-Planning, jede Architektur sollte auch mit einer ganz konkreten Frage bewertet werden: wie viel Leben kostet das?

Ist die Antwort „zu viel“, ist es vielleicht das falsche Problem. Oder der falsche Moment. Oder die falsche Art.

Das heißt nicht, „weniger zu arbeiten“ im trivialen Sinn. Es heißt zu arbeiten im Wissen, dass das ausgeklügeltste System des bekannten Universums kein LLM ist. Es ist das menschliche Gehirn, das es entworfen hat. Und dieses Gehirn folgt Regeln, die wir nicht geschrieben haben und nicht beliebig umschreiben können.

Dieser letzte Atemzug ist vielleicht nicht der letzte Atemzug der Menschheit. Vielleicht ist er der letzte Atemzug einer Arbeitsweise, die Personen wie austauschbare Ressourcen in einer Optimierungspipeline behandelt.

Wenn ja, sollten wir vielleicht nicht versuchen, ihn zu verlängern. Vielleicht sollten wir ihn loslassen und neu atmen lernen. Auf eine Weise, die anerkennt, dass wir aus Fleisch, Zeit und Beziehungen gemacht sind. Und dass kein Agent, so mächtig er auch sei, je an unserer Stelle leben kann.

Die Idee ist elegant, der zugrundeliegende Aufsatz solide. Brandon Janes’ Beitrag „Behavior is the New Credential“ auf Towards Data Science erzählt, wie Systeme der Verhaltensbiometrie zum Standard im Bankensektor werden. Ausgangspunkt ist eine Berkeley-Studie von 2012, Touchalytics: elf Scrolls auf einem Smartphone genügen, um einen bestimmten Nutzer in einer Gruppe von 41 fehlerfrei zu identifizieren. Dreißig einzigartige Verhaltensmerkmale: Gestenlänge, Geschwindigkeit, Krümmung, Trajektorie, Zeit zwischen Scrolls, sogar die genutzte Fingerfläche.

Theoretische Grundlage: das Computational Motor Control, ein interdisziplinäres Feld zwischen Neurowissenschaft, Biomechanik, Informatik. Die unbewussten Korrekturen, die unser Gehirn bei jeder Geste ausführt — Mikroanpassungen im Millisekundenbereich — sind so individuell, dass das Verhaltensprofil einer Person kaum zu reproduzieren ist. Paradoxerweise ist gerade das, was wir als „roboterhaft“ empfinden (diese automatischen neuralen Korrekturen), das, was uns einzigartig menschlich macht.

Warum die alten Verteidigungen nicht mehr reichen

Der Kontext, der diesen Wandel notwendig macht, ist konkret und dokumentiert. Moderne Malware hat Fähigkeiten erreicht, die klassische Verifikationsmechanismen veralten lassen. Tools wie ProKYC — ein im Cybercrime genutzter Deepfake — umgehen 2FA, Gesichtserkennung und sogar Echtzeit-Videoverifikation. BingoMod, ein über Phishing-SMS verbreiteter Remote-Access-Trojaner, tarnt sich auf Android als Antivirus und erlaubt Angreifern, Zugangsdaten, Nachrichten und OTPs abzufangen — bis zu Überweisungen aus dem infizierten Gerät.

Wenn das Gerät kompromittiert ist, sieht aus Sicht der Bank alles normal aus: korrekter Device-Fingerprint, korrekte IP, gültige MFA-Codes. Die klassische Verifikation, die in einem einzigen Augenblick erfolgt (beim Login), reicht nicht mehr. Der Sicherheitsperimeter ist nicht mehr das Eingangstor. Er ist die ganze Sitzung.

Hier kommt die Verhaltensbiometrie ins Spiel, als kontinuierliche Authentifizierung. Auf das spezifische Profil jedes Nutzers gestützte Anomaly-Detection-Modelle überwachen die Sitzung von Anfang bis Ende. Steigen die Risiko-Signale, kann das System zusätzliche Verifikationen verlangen oder die Transaktion blockieren. Bleibt das Verhalten konsistent, läuft die Sitzung ohne Unterbrechungen weiter. Ergebnis, ironischerweise: bessere UX — weniger OTPs, weniger Unterbrechungen, mehr Fluss. Passive statt aktive Sicherheit.

Die andere Seite

Soweit die Erzählung der Cybersecurity-Industrie. Erzählung, die funktioniert: technisch fundiert, operativ effektiv. Aber Erzählung, die systematisch eine Frage vermeidet: Was bedeutet es aus Sicht der Grundrechte, menschliches Verhalten in ein Credential zu verwandeln?

Beginnen wir mit einem normativen Punkt, den Janes’ Artikel nicht erwähnt. Die DSGVO definiert in Artikel 4 Nr. 14 biometrische Daten als „mit speziellen technischen Verfahren gewonnene personenbezogene Daten zu den physischen, physiologischen oder verhaltenstypischen Merkmalen einer natürlichen Person, die die eindeutige Identifizierung dieser natürlichen Person ermöglichen oder bestätigen“. Schlüsselwort: verhaltenstypisch. Der EU-Gesetzgeber hat Verhaltensdaten ausdrücklich in die Definition einbezogen. Artikel 9 ordnet biometrische Daten dann der „besonderen Kategorie“ zu, deren Verarbeitung im Grundsatz untersagt ist — außer bei expliziter Einwilligung, erheblichem öffentlichem Interesse, Schutz lebenswichtiger Interessen.

Das heißt: jedes System der Verhaltensbiometrie in der EU verarbeitet Daten besonderer Kategorie. Keine generischen personenbezogenen Daten. Daten, die explizite Einwilligung, eine DSFA, Zweckbindung, Datenminimierung und ein Recht auf Löschung erfordern.

Die Frage, der kein Cybersecurity-Vendor begegnen will: wie verträgt sich das Recht auf Löschung mit einem aus laufender Analyse tausender Mikrointeraktionen aufgebauten Verhaltensprofil? Du kannst ein Profil löschen, sicher. Aber kannst du das aus dem Profil abgeleitete Wissen löschen, sobald es zum Modelltraining genutzt wurde? Die DSGVO stellt präzise Fragen zur Datenminimierung und Zweckbindung, wenn Daten zum Training von KI-Modellen verwendet wurden.

Die Doppelbindung des AI Act

Das Bild verkompliziert sich mit dem AI Act, dessen Hochrisiko-Regime ab August 2026 voll greift. Die Schnittmenge DSGVO/AI Act schafft einen geschichteten Normrahmen für biometrische Technologien.

Der AI Act unterscheidet mehrere biometrische Systemtypen. Echtzeit-Fernidentifizierung im öffentlichen Raum ist für die Strafverfolgung mit eng begrenzten Ausnahmen verboten. Andere Systeme zur biometrischen Fernidentifizierung sind Hochrisiko. Biometrische Kategorisierung, die sensible Attribute ableitet (Rasse, politische Meinung, Gewerkschaftszugehörigkeit, sexuelle Orientierung), ist verboten. Emotionserkennung ist am Arbeitsplatz und in Bildungseinrichtungen verboten und in anderen Kontexten Hochrisiko.

Wo verortet sich Banking-Verhaltensbiometrie in dieser Taxonomie? Der AI Act schließt Tools zur biometrischen Verifikation, die bestätigen, dass jemand der ist, der er behauptet zu sein, von der Definition der biometrischen Fernidentifizierung aus — vorausgesetzt sie verlangen die aktive Beteiligung der Person. Verhaltensbiometrie ist aber per Definition passiv. Die Nutzerin „beteiligt sich nicht aktiv“ an ihrer Authentifizierung. Das System beobachtet, während sie etwas anderes tut. Diese Grauzone zwischen aktiver Verifikation und passiver Überwachung ist genau das Terrain, auf dem Grundrechte zu knirschen beginnen.

Hinzu kommt: der AI Act untersagt KI-Systeme, die Personen aufgrund ihres sozialen Verhaltens klassifizieren, wenn diese Klassifizierung zu nachteiliger Behandlung in nicht zusammenhängenden Kontexten oder zu unverhältnismäßiger Behandlung führt. Die Linie zwischen „Verhaltensauthentifizierung gegen Betrug“ und „Verhaltensprofilierung zur Klassifizierung von Nutzern“ ist nicht so scharf, wie die Industrie glauben machen will.

Function Creep: das strukturelle Risiko

Die Technikgeschichte lehrt: Systeme, für einen Zweck gebaut, neigen dazu, ihre Reichweite mit der Zeit auszudehnen. Phänomen bekannt als Function Creep, in der Verhaltensbiometrie besonders heimtückisch.

Ein System, das heute analysiert, wie du eine Seite scrollst, um zu prüfen, dass du es bist, könnte morgen dieselben Daten nutzen, um deinen emotionalen Zustand, dein Aufmerksamkeitsniveau, deine kognitive Verfassung, deine finanzielle Risikoneigung abzuleiten. Verhaltensdaten sind außerordentlich reich an impliziter Information. Tipprhythmus kann Angst oder Müdigkeit verraten. Scroll-Geschwindigkeit Interesse oder Langeweile. Berührungsdruck Reizung oder Ruhe.

Banken, die diese Daten heute zur Betrugsprävention nutzen, sitzen auf einem Informationsschatz mit weit größerem Potenzialwert als Transaktionssicherheit. Die Versuchung, diese Daten zu monetarisieren oder kommerziell zu nutzen (Personalisierung, Kreditscoring, Versicherungsprofilierung), ist eine ökonomische Kraft, die interne Policies langfristig kaum zügeln werden.

In Australien wurde eine biometrische Datenbank, die zur Vorbeugung grenzüberschreitender Kriminalität gebaut war, später eingesetzt, um Personen zu identifizieren, die ihre Dokumente in Bränden verloren hatten. In jenem Fall hatte der erweiterte Gebrauch eine wohlwollende Absicht. Aber der Präzedenzfall war geschaffen: sobald die Daten existieren und das System läuft, weiten sich die Zwecke aus.

Der informatisierte Körper

Es gibt eine tiefere Dimension, jenseits des Rechts, in der Anthropologie der Technik. Die Verhaltensbiometrie verwandelt unsere Geräteinteraktion in eine permanente Identifikationsdatum. Der US National Research Council hat das als Schaffung eines „informatisierten Körpers“ beschrieben: eines Körpers, der nicht mehr durch sichtbare anatomische Merkmale repräsentiert wird, sondern durch in Datenbanken gespeicherte digitale Informationen über den Körper.

Wenn deine Art zu scrollen zum Credential wird, wird dein unbewusster Geste zur Daten. Die Spontaneität deiner Bewegung wird erfasst, analysiert, modelliert, archiviert. Du lieferst nicht aktiv eine Information wie beim Tippen eines Passworts. Du lebst einfach, und das System extrahiert Wert aus deiner gewöhnlichen Existenz.

Shoshana Zuboff hat diese Dynamik als Grundzug des Überwachungskapitalismus beschrieben: Aneignung persönlicher Erfahrung und ihre Verwandlung in Verhaltensdaten, die dann zur Vorhersage und Modifikation des Verhaltens genutzt werden. Verhaltensbiometrie für Cybersecurity ist die „gute“ Version dieses Mechanismus. Aber der Mechanismus ist derselbe. Und der Abstand zwischen guter und weniger guter Version ist nur eine Frage der erklärten Zwecke — die sich ändern können.

Die Asymmetrie der Einwilligung

Besonders problematischer Aspekt: die Natur der Einwilligung. Die DSGVO verlangt eine „freiwillig, für den bestimmten Fall, in informierter Weise und unmissverständlich abgegebene“ Einwilligung — mit noch höheren Anforderungen für besondere Kategorien. Aber wie kann die Einwilligung in ein Verhaltensbiometrie-System in deiner Banking-App wirklich freiwillig sein, wenn die Alternative der Verlust des Kontozugriffs ist?

Europäische Datenschutzbehörden haben das in analogen Kontexten bereits behandelt. Die niederländische Behörde verhängte 725.000 € Bußgeld gegen ein Unternehmen, weil Beschäftigte Fingerabdruckscans als Pflicht empfanden — die Einwilligung galt als nicht freiwillig. Die schwedische Behörde sanktionierte eine Schule für die Nutzung von Gesichtserkennung zur Anwesenheitserfassung wegen des Machtungleichgewichts zwischen Institution und Schülern.

Bei Banking-Verhaltensbiometrie ist das Ungleichgewicht analog. Bankdienste sind in der heutigen Gesellschaft nicht optional. Setzt die Bank Verhaltensauthentifizierung ein, hat der Kunde keine reale Alternative zur Einwilligung. Die Dynamik gleicht eher einer auferlegten Bedingung als einer informierten Wahl.

Das Paradox der Unwiderruflichkeit

Anders als ein kompromittiertes Passwort, das in Sekunden geändert werden kann, stellt ein kompromittiertes Verhaltensprofil ein strukturelles Problem: du kannst deine Art zu scrollen oder zu tippen nicht so leicht ändern wie eine Zeichenfolge. Deine Verhaltensmuster sind intrinsisch mit deiner Physiologie und Neurologie verbunden. Sie sind, in einem sehr konkreten Sinn, du selbst.

Das birgt ein Langzeitrisiko, das die Branche tendenziell herunterspielt. Wird eine Datenbank von Verhaltensprofilen kompromittiert, veralten die exfiltrierten Daten nicht durch Credentials-Rotation. Sie bleiben nutzbar, bis sich die biometrischen Merkmale signifikant ändern — was meist nur durch Alterung oder traumatische Ereignisse geschieht.

Die Anbieter betonen, Profile würden typischerweise lokal verarbeitet und nur ein Risiko-Score übermittelt, nicht Rohdaten. Reale Mitigation, beseitigt aber nicht das Grundproblem: irgendwo, in irgendeiner Form, existiert eine Repräsentation deines unbewussten Verhaltens als digitale Daten.

Algorithmische Diskriminierung und Verhaltens-Bias

Weiterer kritischer Aspekt: das diskriminatorische Potenzial. Interaktionsmuster mit Geräten sind nicht universell. Sie variieren mit Alter, körperlicher Verfassung, motorischer Behinderung, kulturellen Unterschieden im Tech-Gebrauch, Gerätetyp.

Eine ältere Person mit Arthrose hat deutlich andere Scroll- und Tippmuster als eine Zwanzigjährige. Eine Nutzerin auf einem günstigen Low-End-Gerät produziert andere Sensordaten als jemand mit dem neuesten Flaggschiff. Wer zwischen rechter und linker Hand wechselt oder assistive Technologien nutzt, erzeugt atypische Profile.

Wurde das Anomaly-Detection-Modell überwiegend auf Profilen normgerechter Mittelklasse-Nutzer trainiert, werden abweichende Nutzer häufiger Zusatzverifikationen, Sitzungsblockaden, Step-up-Anforderungen unterworfen. Anders gesagt: die als bessere UX vermarktete „passive“ Sicherheit kann sich für die verletzlichsten Gruppen in eine systematisch schlechtere UX verwandeln.

Der seit Juni 2025 voll anwendbare European Accessibility Act (EAA) verlangt, dass digitale Produkte und Dienste für Menschen mit Behinderung zugänglich sind. Ein Verhaltensauthentifizierungssystem, das systematisch Nutzer mit motorischer oder kognitiver Beeinträchtigung benachteiligt, wirft Konformitätsfragen nicht nur zu DSGVO/AI Act, sondern auch zur Barrierefreiheits-Norm auf.

Die Pflicht, über die technische Lösung hinauszuschauen

Nichts oben Geschriebene heißt, Verhaltensbiometrie sei eine schlechte Idee. Das Cybersecurity-Problem ist real, die Verluste enorm (das FBI Internet Crime Report dokumentiert Milliarden Dollar jährlich), und klassische Verteidigungen sind den heutigen Bedrohungen tatsächlich nicht gewachsen. Kontinuierliche Authentifizierung ist wahrscheinlich die Zukunft digitaler Sicherheit.

Aber wie die Branche diesen Wandel erzählt, ist nicht zufällig unvollständig. Janes’ Artikel präsentiert, wie der Großteil der technischen Literatur zum Thema, Verhaltensbiometrie ausschließlich aus Sicht operativer Wirksamkeit. Der Subtext: funktioniert besser, ist sicherer, UX besser. Alles wahr. Aber nicht alles.

Wer im europäischen ICT-Sektor arbeitet, trägt eine doppelte Verantwortung. Einerseits diese Technologien einsetzen, wo nötig und wertstiftend. Andererseits dies mit normativem und ethischem Bewusstsein tun, das der amerikanische Markt — Heimat der meisten Innovation auf diesem Feld — weniger dringlich entwickelt.

Europa, mit seinem geschichteten Rechtsrahmen (DSGVO, AI Act, EAA, NIS2), erschwert nicht das Leben derer, die mit Technik arbeiten. Es stellt die Fragen, die der Markt allein nicht stellt. Fragen wie: Wem gehört deine Art, den Finger über einen Bildschirm zu bewegen? Welche Rechte hast du an einem unbewussten Geste, in Daten verwandelt? Was passiert, wenn dein informatisierter Körper zur Ware wird?

Unbequeme Fragen. Aber in dem Augenblick, in dem Verhalten zum Credential wird, haben wir nicht den Luxus, sie zu ignorieren.

Es gibt ein Dokument, das Sie lesen sollten. Nicht lang, nicht versteckt, ohne juristische Vorbildung verständlich. Unter microsoft.com/en-us/microsoft-copilot/for-individuals/termsofuse, aktualisiert am 24. Oktober 2025, enthält es einen Satz, den man ernst nehmen sollte. Im Abschnitt in Großbuchstaben und Fett, „IMPORTANT DISCLOSURES & WARNINGS“, lautet er: Copilot ist als ausschließlich zu Unterhaltungszwecken zu betrachten. Er kann Fehler machen und nicht wie erwartet funktionieren. Verlassen Sie sich nicht auf Copilot für wichtige Ratschläge. Nutzen Sie Copilot auf eigenes Risiko.

Wenn Ihnen das wie die Klausel einer Meme-App vorkommt, kann ich es nachvollziehen. Aber wir reden über das Produkt, das Microsoft in Windows 11 integriert hat, in Excel, PowerPoint, Teams, Outlook — ins Herz einer Suite, die täglich über 430 Millionen Menschen nutzen. Das Produkt, für das Microsoft im FY2025 rund 80 Milliarden Dollar KI-Capex aufgewendet hat — Rechenzentren, Infrastruktur, Rechenkapazität —, plus die kumulierten rund 13 Milliarden Investitionen in OpenAI, dessen Technologie die zugrundeliegenden Modelle speist. Das Produkt, das Großkonzerne 30 $ pro Nutzer und Monat zahlen, KMU 21 (mit den Aktionen des ersten Halbjahrs 2026 18). Die ToU dieses Produkts sagen: es ist ein Spielzeug.

Microsofts Reaktion, als die Klausel Anfang April 2026 in den sozialen Medien zirkulierte, war voraussehbar mechanisch. Ein Sprecher erklärte gegenüber PCMag, es handle sich um „Legacy-Sprache“, die „die heutige Produktnutzung nicht mehr widerspiegelt“ und beim „nächsten Update geändert“ werde. Kein Datum. Keine bindende Zusage. Keine Erklärung, warum eine Sprache, die die Realität nicht widerspiegelt, monatelang in den Rechtstexten geblieben ist, unter den Augen desselben Rechtsteams, das sie geschrieben hat. Der Sprecher redete, als hätte jemand vergessen, ein Schild auf einer geschlossenen Baustelle abzunehmen. Aber geschlossene Baustellen rechnen keine 30 $ pro Sitz.

Versuchung: das als Patzer der Rechtsabteilung abzutun. Falsch. ToU werden nicht aus Versehen verfasst. Anwaltsteams wägen jedes Wort, weil sie wissen, dass es im Gericht verwendet wird. „Entertainment“ ist kein träger Synonym für „experimentell“ oder „beta“. Im angelsächsischen Recht hat es eine präzise juristische Bedeutung: die Kategorie, die schützt, wer ausdrücklich nicht-faktische Inhalte produziert (Spiele, Fiktion, Simulationen). Ein Produkt als „for entertainment purposes only“ zu erklären, bedeutet, dass kein vernünftiger Nutzer erwarten dürfe, dass die Antworten genau, verlässlich oder für irgendeinen praktischen Zweck geeignet seien.

Man könnte einwenden, die Zahlen erzählen anders. Dass Copilots Adoption langsamer ist als erwartet. Dass Microsoft selbst weiß, dass das Produkt Probleme hat. Stimmt. Im FY2026/Q2 hatten nur 15 Mio. von 450 Mio. zahlenden gewerblichen Sitzen ein M365-Copilot-Abo: 3,3 %. Der US-Anteil zahlender Abonnenten schrumpfte in sechs Monaten um 39 % (von 18,8 % im Juli 2025 auf 11,5 % im Januar 2026). Der NPS zur Antwortgenauigkeit fiel laut Recon Analytics zwischen Juli und September 2025 von –3,5 auf –24,1. 44,2 % der Copilot-Abbrecher nennen Misstrauen in die Antworten als Hauptgrund. Können Beschäftigte zwischen Copilot, ChatGPT und Gemini wählen, entscheiden sich nur 8 % für Microsoft.

Diese Zahlen mildern das Problem nicht. Sie verschärfen es. Sie zeigen, dass Microsoft genau weiß, das Produkt sei nicht zuverlässig — sagt es in juristischen Dokumenten — und es weiter als Enterprise-Produktivitätswerkzeug verkauft. Satya Nadella nannte Copilot vor Investoren „a true daily habit“. Das Marketing präsentiert ihn als den Assistenten, der die Arbeit verändert. Die ToU sagen: ein Spielzeug. Kein Widerspruch. Strategie.

II. Der Chor der Disclaimer

Es wäre intellektuell unredlich, Microsofts Klausel als Anomalie darzustellen. Sie ist keine. Sie ist der spektakulärste Fall eines Musters durch die ganze KI-Branche, das es zu kartieren lohnt.

OpenAI warnt in seinen ToU davor, sich auf Outputs als einzige Wahrheits- oder Faktenquelle zu verlassen, und begrenzt seine Gesamtsumme der Haftung auf 100 $ oder den in den letzten zwölf Monaten gezahlten Betrag. Google schreibt in den Gemini-ToU, sich nicht auf die Dienste für medizinische, mentale, juristische, finanzielle oder andere fachliche Beratung zu verlassen. xAI, Musks Firma, warnt, ihre KI sei „probabilistisch“ und könne fehlerhafte Outputs erzeugen. Keine dieser Firmen ist bis zur Formel „for entertainment purposes only“ gegangen. Das bleibt Microsofts Exklusivität.

Der Unterschied zu den anderen ist nicht inhaltlich. Er ist Nuance. Alle großen KI-Anbieter bauen eine juristische Mauer zwischen dem verkauften Produkt und den Folgen seiner Nutzung. Sie tun das im Wissen, dass ihre Modelle falsche, irreführende, potenziell schädliche Outputs erzeugen können — und tun. Im August 2024 identifizierte Copilot fälschlicherweise den deutschen Journalisten Martin Bernklau als verurteilten Pädokriminellen und Betrüger und gab seine Heimadresse aus. Microsoft sperrte Anfragen zu Bernklau erst nach einer Datenschutzbeschwerde. Keine Grenzfälle. Normalbetrieb eines probabilistischen Systems, das kommerziell als deterministisch verkauft wird.

Und Disclaimer wirken vor Gericht. Am 19. Mai 2025 erließ der Superior Court des Gwinnett County, Georgia, ein summary judgment zugunsten von OpenAI in Walters v. OpenAI (23-A-04860-2). Radiomoderator Mark Walters hatte OpenAI verklagt, nachdem ChatGPT auf Anfrage eines Journalisten eine falsche Zusammenfassung einer Klage erzeugte, in der Walters der Veruntreuung zulasten der Second Amendment Foundation beschuldigt war. Das Gericht wies die Klage aus drei unabhängigen Gründen zurück: die Aussagen seien vernünftigerweise nicht als reale Fakten zu verstehen (auch weil ChatGPT den Journalisten auf seine Grenzen hingewiesen hatte und die ToU explizite Disclaimer enthielten); Walters habe weder Fahrlässigkeit noch malice dargelegt; und Walters selbst habe zugegeben, keinen Schaden erlitten zu haben. Eine Entscheidung auf mehreren Beinen, also nicht nur auf den Disclaimern. Aber sie wogen — und wiegen. Das Gericht erkannte ausdrücklich, dass die wiederholten Hinweise auf „Halluzinationen“ jede vernünftige Erwartung an faktische Genauigkeit der Nutzerseite untergruben.

Hier halten viele inne, empört. Aber hier muss der Diskurs präziser werden — nicht alle Disclaimer sind gleich, dienen demselben Zweck oder sind an sich negativ.

Der EU AI Act, Verordnung 2024/1689, verlangt ausdrücklich, dass Anbieter von KI-Systemen die Grenzen ihrer Produkte kommunizieren. Artikel 13 verlangt, dass Hochrisikosysteme so transparent gestaltet sind, dass Deployer die Outputs interpretieren und sachgerecht nutzen können, und dass sie mit knappen, vollständigen, korrekten und klaren Anleitungen zu Eigenschaften, Fähigkeiten und Leistungsgrenzen versehen sind. Artikel 14 verlangt wirksame menschliche Aufsicht und schreibt vor, dass die mit Aufsicht Betrauten in die Lage versetzt werden, sich der möglichen Tendenz bewusst zu bleiben, sich automatisch oder übermäßig auf Outputs zu verlassen — den „automation bias“. Artikel 50 verlangt, Nutzer darüber zu informieren, dass sie mit einem KI-System interagieren, und generierte Inhalte als solche zu kennzeichnen.

Zu sagen „dieses KI-System kann Fehler machen, prüfe stets, vertraue nicht blind“, ist also nicht nur legitim. Es ist Pflicht. Europa hat festgelegt, dass Transparenz über KI-Grenzen eine Säule von Sicherheit und Vertrauen ist. Der Nutzer muss wissen, womit er es zu tun hat, welche Risiken bestehen, und in der Lage sein, jeden Output zu ignorieren oder zu überschreiben. Das ist der Rahmen, dem jedes seriöse Unternehmen folgen sollte.

Aber etwas anderes ist es zu sagen „dieses System hat folgende Grenzen, so überwacht man es sicher“. Etwas anderes „das ist ein Spielzeug, nutz’ es auf eigenes Risiko, wir garantieren nichts“. Erste Formel: Transparenz. AI-Act-Konformität. Verantwortungsakt, der den Deployer zur Arbeit befähigt. Zweite Formel: als Transparenz verkleidete Verantwortungsabschiebung. Sie befähigt den Nutzer nicht zur sachgerechten Nutzung — sie macht ihn unfähig zum Regress, wenn etwas schiefgeht.

Der AI Act verlangt die Erklärung der Grenzen, um sicheren Gebrauch zu ermöglichen. Die ToU von Microsoft erklären die Grenzen, um Regress zu verhindern. Der eine dient dem Nutzer. Der andere der Rechtsabteilung. Und wenn ein US-Gericht Anbieter-Disclaimer beim Abweisen einer Diffamierungsklage positiv bewertet, belohnt es nicht zwangsläufig Transparenz. Es nimmt Legalese zur Kenntnis.

III. Die Richtlinie, die alles ändert (und der blinde Fleck)

Bis zum 9. Dezember 2026 müssen die EU-Mitgliedstaaten die Richtlinie 2024/2853, die neue Produkthaftungsrichtlinie, in nationales Recht umsetzen. Erste Modernisierung des EU-Produkthaftungsregimes seit vierzig Jahren. Für Unternehmen, die Software und KI-Systeme produzieren, integrieren oder vertreiben, sind die Folgen tiefgreifend.

Die Richtlinie definiert zunächst „Produkt“ neu. Die alte Richtlinie von 1985 war für eine Welt physischer Objekte konzipiert: Autos, Haushaltsgeräte, Spielzeug. Die neue schließt Software ausdrücklich ein, unabhängig von Bereitstellung oder Nutzung — embedded, standalone, Cloud, SaaS. Firmware, Betriebssysteme, Anwendungen sind erfasst. Die Erwägungsgründe stellen klar, dass auch KI-Systeme unter den Begriff fallen. Software ist kein Dienst mehr, der der Produkthaftung entgleitet. Sie ist Produkt. Damit objektive Haftung: Verschulden muss nicht nachgewiesen werden. Es genügt, Mangel und Schadenskausalität zu zeigen.

Dann die Frage der Haftungsausschlüsse. Artikel 10 verlangt, dass die Mitgliedstaaten sicherstellen, dass die Haftung eines Wirtschaftsakteurs gegenüber dem Geschädigten nicht durch Vertragsklausel oder nationales Recht begrenzt oder ausgeschlossen werden kann. Die Formulierung lässt keine Mehrdeutigkeit. Disclaimer in den ToU, Haftungsbegrenzungsklauseln, Formeln „as is“ und „for entertainment purposes only“ — sobald ein europäischer Verbraucher von einem mangelhaften Produkt geschädigt wird, sind sie wertlos.

Die transatlantische Tragweite muss verstanden werden. Die Klausel „Copilot is for entertainment purposes only“ wird in den USA weiter wirken, wo Walters v. OpenAI bestätigte, dass Gerichte Disclaimer ernst nehmen. In Europa wird sie nach Umsetzung unanwendbar. Erzeugt Copilot einen mangelhaften Output, der einer natürlichen Person Schaden verursacht (Tod, Verletzung, medizinisch anerkannte psychische Schäden, Zerstörung oder Beschädigung nicht-beruflicher Daten, private Sachschäden), haftet der Anbieter. Egal, was in den ToU steht.

Die Richtlinie schreibt auch die Beweislastregeln neu, und hier wird es brisant. Sie führt Vermutungen zugunsten des Geschädigten ein. Legt der Beklagte einschlägige Informationen nicht offen, wird der Mangel vermutet. Verstößt das Produkt gegen verbindliche nationale oder EU-Vorgaben, wird der Mangel vermutet. Bei offensichtlicher Fehlfunktion bei vernünftigerweise vorhersehbarem Gebrauch ebenso. Stößt der Geschädigte auf „übermäßige Schwierigkeiten“ beim Beweis des Mangels wegen technischer oder wissenschaftlicher Komplexität, können Gerichte sowohl den Mangel als auch die Kausalität vermuten. Bei KI-Systemen, deren interne Opazität strukturell ist, wird diese Vermutung zur Regel. Der Geschädigte muss nicht erklären, wie das Modell den Falschoutput erzeugte. Er muss nachweisen, dass der Output mangelhaft war und dass der Schaden daraus folgte.

Die PLD verflicht sich mit dem gesamten EU-Rechtsrahmen. Nichteinhaltung der Anforderungen des Cyber Resilience Act (Security-by-Design, Schwachstellenmanagement, Sicherheitsupdates) kann eine Mängelvermutung begründen. Dasselbe gilt bei Verletzung der NIS2-Pflichten. Und dasselbe gilt implizit für AI-Act-Anforderungen: ein KI-System, das Transparenz, menschliche Aufsicht, Genauigkeit und Robustheit nicht erfüllt, verstößt gegen verbindliche EU-Vorgaben — also ein System, für das die PLD den Mangel vermuten kann.

Der Kurzschluss ist mit bloßem Auge sichtbar. Der AI Act verlangt von Anbietern die Erklärung der Grenzen, um sicheren Gebrauch zu ermöglichen. Die PLD sagt: verursacht das Produkt Schaden, haftet der Anbieter unabhängig von Disclaimern. Der Anbieter muss informieren, dass das System irren kann, kann diese Information aber nicht als Schutzschild verwenden, wenn das System tatsächlich irrt. Ein kohärentes, verbraucherschützendes Regime. Es erzeugt aber eine starke Spannung zwischen Transparenzpflicht und Unmöglichkeit, Transparenz als Schutzschild zu nutzen.

Für Microsoft handhabbar. Für die Mitte der Kette potenziell tödlich.

IV. Wer modifiziert, zahlt: der Integrator als struktureller Sündenbock

Die PLD sagt nicht nur, dass der Software-Hersteller haftet. Sie weitet die Kette potenziell haftender Wirtschaftsakteure mit Kaskadenlogik, damit der EU-Verbraucher stets einen erreichbaren Ansprechpartner in der Union hat. Sitzt der Manufacturer außerhalb der EU, haftet der Importeur. Fehlt ein klar identifizierbarer Importeur, haftet der bevollmächtigte Vertreter. Dann der Fulfilment Service Provider. Dann der Vertreiber, sofern er nicht binnen eines Monats ab Anfrage des Geschädigten den einschlägigen Akteur in der Kette nennt. Die Haftung ist gesamtschuldnerisch: Mehrere für denselben Schaden Verantwortliche haften gemeinsam, jeder für das Ganze.

So weit, so vernünftig. Aber eine Figur in der Kette behandelt die PLD besonders streng — und sie ist entscheidend, um die praktischen Folgen der „entertainment only“-Klausel zu verstehen: wer ein Produkt nach Inverkehrbringen wesentlich verändert, gilt als Manufacturer des veränderten Produkts und haftet, soweit der Mangel aus der Veränderung resultiert. Die Erwägungsgründe stellen klar: eine wesentliche Veränderung kann auch aus einem Software-Update, einem Upgrade oder dem kontinuierlichen Lernen eines KI-Systems stammen. Das so veränderte Produkt gilt als zu dem Zeitpunkt in den Verkehr gebracht, in dem die Veränderung tatsächlich erfolgt.

Stellen Sie sich die Praxis vor. Ein System Integrator, eine Softwarebude, ein IT-Berater nimmt Copilot und integriert ihn in einen Unternehmens-Workflow. Konfiguriert Prompts, schließt Kunden-Datenquellen an, personalisiert Antworten, automatisiert Flüsse. Verändert er das Produkt wesentlich? Nach PLD sehr wahrscheinlich ja. In dem Moment, in dem du ein generalistisches KI-Modell für einen spezifischen Kontext spezialisierst, schaffst du ein anderes Produkt. Erzeugt dieses veränderte Produkt einen mangelhaften Output mit Schaden, haftet der Integrator als Manufacturer.

Artikel 12 sieht spezifischen Schutz für Mikro- und Kleinunternehmen vor, die mangelhafte Software produzieren, die in das Produkt eines anderen integriert ist. Diese Unternehmen können vertraglich mit dem Endprodukt-Manufacturer vereinbaren, vor Regressforderungen geschützt zu sein. Doch dieser Schutz hat zwei Grenzen, die seinen Nutzen drastisch verringern. Erste: er schützt das Mikro/Kleinunternehmen in keinem Fall vor einer direkten Klage des Verbrauchers. Der Verbraucher kann den Integrator immer direkt verklagen, und der Integrator haftet. Zweite: Schutz vor Regressforderungen verlangt eine vertragliche Vereinbarung mit dem Manufacturer. Microsoft hat keine Pflicht und keinen Anreiz, solche Vereinbarungen zu gewähren. Ihre ToU sagen schon: das Produkt ist „for entertainment purposes only“ und der Nutzer ist „solely responsible“ für jede aufgrund der Outputs getroffene Handlung. In einer eventuellen Regressklage wird Microsoft sagen können: wir haben euch gewarnt. Ihr habt entschieden, es in ein professionelles Produkt einzubauen. Es ist nicht unsere Schuld, wenn ihr es einem Kunden als zuverlässig verkauft habt, obwohl wir selbst gesagt haben, es sei ein Spielzeug.

Die PLD verbietet, Verantwortung über Vertragsklauseln nach unten — zum Verbraucher — abzuwälzen. Aber sie verbietet nicht, dass Große sich weigern, vertragliche Schutzvorkehrungen nach oben — zwischen Integrator und Manufacturer — zu gewähren. Resultat: der Integrator ist dem Verbraucher ausgesetzt, ohne sich vertraglich schützen zu können, und hat keinerlei Garantie, sich wirksam an Microsoft zu halten. Microsoft hat die Anwaltsteams, die bevollmächtigten Vertreter in jedem Mitgliedstaat, die Finanzmasse, das Verfahren zu absorbieren. Der Integrator mit zehn Personen in Pescara, Brno, Lissabon nicht.

Naheliegender Einwand: der Integrator kann und muss die im AI Act vorgesehene menschliche Aufsicht implementieren. Verifikationsprozesse, Schulungen, Output-Aufsicht. Stimmt — der verantwortliche Integrator wird das tun und muss es auch wegen seiner eigenen Pflichten als Deployer im AI Act. Aber die PLD fragt nicht, ob du dein Bestes gegeben hast. Die PLD fragt, ob das Produkt mangelhaft war und ob der Mangel den Schaden verursacht hat. Ein falscher Output eines in einen professionellen Workflow integrierten KI-Systems, der einer Person schadet, ist ein mangelhaftes Produkt, unabhängig von der Anzahl implementierter Aufsichtsschichten. Du kannst alles richtig gemacht haben und trotzdem haften.

Denken Sie an ein KI-System, das in eine ERP-Software integriert ist und einen falschen Finanzbericht erzeugt, der zu einer falschen Investitionsentscheidung führt. Oder an einen KI-Assistenten in einem CRM, der eine diffamierende Mitteilung über einen Kunden erzeugt. Oder an ein in eine Gesundheitsplattform integriertes Analysesystem, das eine falsche Indikation gibt, die einen Diagnoseweg beeinflusst. In all diesen Fällen kann der Geschädigte unter PLD den Integrator verklagen. Der Integrator ist da, in der EU, erreichbar, mit Steuernummer und Bankkonto. Microsoft ist in Redmond. Und in seinen ToU steht, Copilot sei zur Unterhaltung.

V. Die Rechnung und wer sie zahlt

Es gibt einen Moment in der Tech-Regulierung, in dem klar wird, dass die Regeln für eine Welt geschrieben wurden, die nicht mehr existiert. Die alte Produkthaftungsrichtlinie von 1985 war für eine Welt physischer Produkte konzipiert, hergestellt von identifizierbaren Firmen, vertrieben über lineare Ketten, genutzt von Verbrauchern, die ihre Sicherheit vernünftigerweise beurteilen konnten. Die neue PLD ist ein notwendiges, in vielen Hinsichten bewundernswertes Update: sie weitet den Schutz auf Software, senkt die Hürden für Verbraucher, führt Vermutungen ein, die die Informationsasymmetrie ausgleichen. Aber die regulierte Welt besteht nicht aus linearen Ketten. Sie besteht aus überlagerten Schichten, aus APIs, die APIs aufrufen, aus probabilistischen Modellen, deren innere Funktionsweise nicht einmal die Erbauer ganz verstehen.

Die logische Architektur des EU-Rechtsrahmens ist die fortschrittlichste der Welt. Der AI Act setzt Pflichten zu Transparenz, menschlicher Aufsicht, Risikomanagement. Der Cyber Resilience Act fordert Security-by-Design und kontinuierliche Sicherheitsupdates. NIS2 weitet Cybersicherheit auf kritische Sektoren. Die PLD schließt den Kreis: wer diese Pflichten verletzt und Schaden verursacht, zahlt. Der Einwand richtet sich nicht gegen die Logik. Er richtet sich gegen die praktische Verteilung der Folgen.

Die Folgen folgen real einer ökonomischen Schwerkraft, die keine Richtlinie umkehrt: sie fallen nach unten. Zu denen mit weniger juristischen Mitteln, weniger Finanzmasse, weniger Aufnahmefähigkeit für Verfahren. Microsoft, Google, OpenAI haben jeweils Hunderte Anwälte, bevollmächtigte Vertreter in jeder Jurisdiktion, Rechtsbudgets, die den Umsatz ganzer KMU-Sektoren übersteigen. Sie haben ToU geschrieben, die — auch wenn unter PLD gegenüber Verbrauchern unwirksam — vollständig operativ als Argument in Regressforderungen zwischen Wirtschaftsakteuren bleiben. Sie haben ihre Produkte mit chirurgischer Präzision als „entertainment“, „probabilistic“, „not a source of truth“ eingestuft, im Wissen um die Funktion jedes einzelnen Wortes in einem künftigen Verfahren.

Die PLD legt die Rechnung vor — wer zahlt? Der zehnköpfige System Integrator, der Copilot in den Kunden-ERP integriert, Schulungen gemacht, menschliche Aufsicht implementiert hat — und feststellt, dass er der Erreichbare, Identifizierbare, Verklagbare ist, sobald der defekte Output Schaden anrichtet. Der Anbieter ist auf der anderen Seite des Ozeans, oder durch B2B-Vertragsklauseln, Schiedsverfahren in Dublin und Haftungsbegrenzungen zwischen Wirtschaftsakteuren geschützt, die die PLD nicht antastet, weil sie professionelle Beziehungen und nicht den direkten Verbraucherschutz betreffen.

Es wäre falsch zu sagen, die PLD sei ein Fehler. Die PLD ist unvollständig. Ihre Unvollständigkeit erzeugt einen regressiven Effekt, der jene belohnt, die das System navigieren können, und jene bestraft, die es nicht können. Artikel 12 erkennt das Problem für Mikro- und Kleinunternehmen, löst es aber zirkulär: wir schützen dich vor Regress, wenn du eine vertragliche Vereinbarung mit dem Manufacturer hast. Aber der Manufacturer ist nicht verpflichtet, sie zu gewähren. Und stehen in seinen ToU „entertainment only“, ist sein Anreiz, sie zu gewähren, sogar negativ: diese Vereinbarung würde implizit zugeben, dass das Produkt einen professionellen Gebrauch hat — im Widerspruch zum eigenen rechtlichen Schutzschild.

Weiteres Paradox. Firmen, die Compliance ernst nehmen, menschliche Aufsicht implementieren, Kunden informieren, Prozesse dokumentieren, hinterlassen die reichste Beweisspur für eine Haftungsklage. Wer Copilot leichtfertig integriert, ohne Prozesse, ohne Doku, ohne Aufsicht, ist paradoxerweise schwerer angreifbar — weniger Beweise eines strukturierten Verhältnisses zum Produkt. Die PLD, in ihrem Versuch des Verbraucherschutzes, riskiert einen Anreiz zur Oberflächlichkeit zu schaffen: wer es richtig macht, ist exponierter als wer es falsch macht.

Die zeitliche Dimension. Die PLD gilt für nach Umsetzung in Verkehr gebrachte oder in Betrieb genommene Produkte. Aber KI-Systeme sind keine statischen Produkte. Sie werden ständig aktualisiert. Modelle ändern sich. Outputs ändern sich. Ein KI-System, das heute auf eine Weise funktioniert, kann nach einem Modell-Update in sechs Monaten ganz anders funktionieren. Jedes wesentliche Update bringt das Produkt laut Erwägungsgründen erneut auf den Markt. Der Integrator, der 2025 einen Workflow auf Copilot aufgebaut hat, könnte 2027 nach einem Modell-Update mit einem substanziell anderen Produkt dastehen, das andere Outputs erzeugt, ohne Kontrolle über die Veränderung und mit voller Verantwortung für ihre Wirkungen.

Ich habe dafür keine fertige Lösung. Aber wer in diesem Sektor arbeitet, sollte beginnen, die ToU seiner KI-Anbieter nicht zu lesen, um sich zu empören, sondern um genau zu verstehen, was der Anbieter zu garantieren ablehnt — denn diese Liste ist die Karte des Restrisikos auf den Schultern des Integrators. Er sollte spezifische Vertragsvereinbarungen zur Produkthaftung vor PLD-Umsetzung verhandeln, weil die Verhandlungsmacht danach noch geringer wird. Er sollte jeden Aufsichtsprozess, jede Risikobewertung, jede Kundeninformation dokumentieren — nicht weil das die Haftung unter PLD beseitigt, sondern weil im Regress die Doku die einzige Waffe ist. Und er sollte ernsthaft fragen, ob die Integration von Drittanbieter-KI in professionelle Produkte versicherungstechnisch tragfähig ist — heute deckt die meiste Berufshaftpflicht KI-Output-Schäden nicht, morgen wird diese Deckung nötig sein.

Wenn Microsoft „for entertainment purposes only“ schreibt, stammelt sie nicht. Sie spricht klar und absichtlich. Sie sagt, dass die Verantwortung für jede professionelle Nutzung ihres Produkts nicht ihre ist. Sie sagt, wer dieses Produkt nimmt und als zuverlässiges Werkzeug verkauft, tut es ganz auf eigenes Risiko. Europa hat einen Rechtsrahmen gebaut, der theoretisch alle in Verantwortung hält. Praktisch hält er jene in Verantwortung, die es sich am wenigsten leisten können. Der Anbieter, der „for entertainment purposes only“ schrieb in dem Wissen, dass es niemand lesen würde, der 30 $ pro Sitz und Monat kassierte in dem Wissen, dass das Produkt nicht zuverlässig ist — der hat noch seine Anwälte, seine Klauseln, seine internationalen Schiedsverfahren. Beim nächsten Mal, wenn jemand Rechenschaft fordert, wird er erneut die Terms of Use zeigen. Dort steht alles. Es genügt zu lesen.

Die gründende Intuition Blochs und Febvres

Beginnen wir dort, wo die Verführung am stärksten ist, denn dort muss man hinsehen, um zu verstehen, wo es zu knirschen begann. Marc Bloch und Lucien Febvre gründen die Zeitschrift 1929 mit einem Programm, das, heute neu gelesen, eine unleugbare Kraft bewahrt: Schluss mit der Geschichte der Könige und Schlachten, Schluss mit der événementielle Erzählung, die die Vergangenheit zu einer Folge politischer und diplomatischer Tatsachen reduziert. Geschichte muss mit Geographie, Ökonomie, Soziologie, Anthropologie sprechen. Sie muss sich um tiefe Strukturen, lange Zeiten, kollektive Mentalitäten kümmern. Sie muss, kurz gesagt, total werden. Die Intuition war echt und antwortete auf ein reales Problem. Die positivistische Geschichtsschreibung des 19. Jh. hatte sich auf einen Eventkatalog reduziert, und die Idee tieferer Kräfte, die Gesellschaften formen, war legitim und nötig. Wer Blochs Die wundertätigen Könige oder Febvres Das Problem des Unglaubens im 16. Jh. gelesen hat, kann die Kraft dieses Blicks nicht leugnen. Das Problem war nie die Intuition. Das Problem war, was man daraus gemacht hat.

Braudel und die Sackgasse der longue durée

Fernand Braudel veröffentlicht 1949 Das Mittelmeer und die mediterrane Welt in der Epoche Philipps II., und mit diesem Buch findet die Schule ihr Monument — und ihre Sackgasse. Braudel führt die zeitliche Dreiteilung ein, die zum Markenzeichen wird: die fast unbewegliche Zeit von Geographie und Klima, die langsame Zeit ökonomischer und sozialer Strukturen, die schnelle Zeit politischer Ereignisse. Hierarchie ausdrücklich und nicht verhandelbar. Der Hauptdarsteller ist das Mittelmeer, nicht Philipp II. Meeresströmungen, Winde, Handelsrouten, Agrarzyklen bestimmen den Rahmen. Radikaler Umsturz. Und es funktioniert — solange man in Braudels Prosa bleibt, deren Kraft fast alles glaubhaft macht.

Doch wenn man die literarische Suggestion verlässt und das Modell analytisch betrachtet, stößt man auf ein Problem, das Braudel nie gelöst und seine Erben lieber ignoriert haben: wenn die longue durée die fundamentale Erklärungsebene ist, welcher Raum bleibt menschlichem Handeln? Keine rhetorische Frage. Paul Ricœur hat sie in Zeit und Erzählung mit einer Klarheit gestellt, die die Annales-Historiker nie erreicht haben: die Zeit der longue durée ist eine Zeit ohne Subjekt — Dinge geschehen, aber niemand lässt sie geschehen. Wusste Braudel das? Wahrscheinlich, und es war ihm wahrscheinlich egal. In seinem Schema ist die histoire événementielle „Staub“, berühmte Formel, die Jahrhunderte von Geschichtsschreibung in einer abschätzigen Metapher liquidiert. Aber der Staub besteht aus Personen, die entscheiden, handeln, irren, den Lauf der Dinge auf eine Weise ändern, die keine tiefe Struktur vorhersehen konnte. Philipps II. Entscheidung, 1588 die Armada zu entsenden, ist weder durch Mittelmeerwinde noch durch Getreidepreiszyklen erklärbar. Sie ist eine politische Entscheidung eines bestimmten Individuums in einem bestimmten Kontext, mit enormen Folgen. Sie auf „Staub“ zu reduzieren ist kein Akt wissenschaftlicher Strenge, sondern erkenntnistheoretischer Arroganz.

Der Punkt geht tiefer und betrifft die ganze Schule. Wenn die Struktur mehr erklärt als das Ereignis und das Ereignis „Staub“ ist, wird der historische Wandel zum unlösbaren Problem. Strukturen sind per Definition das, was bleibt. Aber Geschichte ist auch, vielleicht vor allem, das, was sich ändert. Wie geht man von einer Struktur zur anderen? Braudel sagt es nicht, denn in seinem Schema geschieht der Übergang über so lange Zeiten, dass er fast unmerklich wird, eine geologische Bewegung ohne Akteure. Glaubhaft nur, solange man die Jahrhunderte von oben betrachtet. Steigt man dorthin, wo Menschen leben, entscheiden, sich auflehnen, erfinden, wird der braudelsche Rahmen unbrauchbar. Die Französische Revolution ist nicht in longue-durée-Begriffen erklärbar. Strukturelle Faktoren schaffen Bedingungen, aber sie erklären weder Juli 1789, noch Robespierre, noch die konkreten Formen des Ereignisses. Marc Bloch war paradoxerweise viel aufmerksamer für solche Nuancen als sein Nachfolger. Die Feudalgesellschaft ist ein strukturelles Buch, ja, aber Bloch verliert nie die konkreten Mechanismen aus dem Blick, mit denen Menschen die Strukturen, in denen sie leben, bauen und reproduzieren. Mit Braudel reißt diese Verbindung, und die Schule hat sie nie wieder geknüpft.

Man könnte einwenden, die Kritik sei alt, sie sei tausendfach formuliert, die Annales hätten sie selbst aufgenommen und metabolisiert. Stimmt, sie haben sie aufgenommen. Aber wie? Hier wird es interessant — wie die Schule ihre internen Krisen handhabte, sagt mehr als die Krisen selbst.

Die Mentalitäten als strategischer Rückzug

Die zweite Generation, Braudels, herrscht in der französischen und weitgehend internationalen Geschichtsschreibung von den 1950ern bis 70ern. Modell solide, Lehrstühle besetzt, Zeitschrift Schwerpunkt der Disziplin. Dann kommen in den 70er- und 80ern die dritten: Le Goff, Le Roy Ladurie, Duby, mit der großen Verschiebung zur Mentalitätsgeschichte. Keine natürliche Evolution, ein strategischer Rückzug. Die braudelsche longue durée hatte ihre Grenzen gezeigt: zu deterministisch, zu strukturell, zu gleichgültig gegenüber allem nicht Messbaren. Mentalitätsgeschichte verspricht, die subjektive Dimension zurückzugewinnen, ohne den interdisziplinären Anspruch aufzugeben. Man studiert kollektive Vorstellungen, Glauben, Ängste, Träume, Vorstellungen vom Tod und der Zeit. Faszinierend. Le Roy Laduries Montaillou, ein okzitanisches Dorf ist ein außerordentliches Buch, und Le Goffs Forschungen zum Fegefeuer oder zur Geburt der Kaufmannszeit gehören zum Besten, was die Geschichtsschreibung des 20. Jh. hervorgebracht hat.

Doch der Preis ist hoch, und niemand sagt es klar genug. Von der longue durée zu den Mentalitäten überzugehen, heißt nicht beide zu integrieren — es heißt das Erste aufzugeben, weil es nicht funktionierte, und ein anderes anzunehmen, in der Hoffnung, es funktioniere besser. Diese Geste ist allen vertraut, die die Akademie kennen: kein Paradigmenwechsel im kuhnschen Sinn (mit expliziter Krise, anerkannten Anomalien, argumentierter Ablösung), sondern ein als Evolution präsentierter Themenwechsel. Der Unterschied ist entscheidend. Ein Paradigmenwechsel impliziert die Widerlegung des Alten. Ein Themenwechsel impliziert nur, dass das Alte keine Mittel mehr zieht, keine Doktorarbeiten generiert, keine Tagungen füllt. Die Annales-Historiografie zwischen zweiter und dritter Generation ähnelt viel mehr der zweiten Dynamik.

Und die Mentalitäten werfen riesige Probleme auf. Wie rekonstruiert man eine „kollektive Mentalität“? Mit welchen Quellen, welcher Methode? Die praktische Antwort: viel interpretative Kreativität und wenig Verifizierbarkeit. Geoffrey Lloyd, der Cambridge-Wissenschaftshistoriker, stellte in Demystifying Mentalities (1990) die Validität des Begriffs selbst in Frage: ganzen Gesellschaften oder Epochen distinkte „Mentalitäten“ zuzuschreiben sei intellektuell brüchig — es kaschiere die Koexistenz unterschiedlicher Denkformen in einer Kultur. Und er war nicht allein. Die Mentalitätsgeschichte hat schöne Bücher hervorgebracht — und auch einen historiografischen Impressionismus eröffnet, der die Unterscheidung zwischen begründeter Hypothese und eleganter Spekulation kaum mehr zuließ.

Hier könnte man einwenden: ist das nicht das Schicksal aller Geisteswissenschaften? Muss Geschichte, die sich mit Menschen und nicht mit subatomaren Teilchen befasst, nicht mit unaufhebbarer Deutungsunschärfe leben? Klar. Aber es ist ein riesiger Unterschied, diese Unschärfe anzuerkennen oder daraus ein Programm zu machen. Die Annales haben Generation um Generation methodische Unsicherheit in ein Prinzip erkenntnistheoretischer Freiheit verwandelt — eleganter Ausdruck dafür, dass sie die Methode wechselten, sobald die alte hakte, ohne je zuzugeben, dass sie hakte. Dieses Manöver muss demaskiert werden, denn es erlaubt der Schule, sich als ständig innovativ zu inszenieren, während sie tatsächlich ständig auf der Flucht ist.

Tournant critique und Abhängigkeit von den Sozialwissenschaften

Der nächste Schritt bestätigt es. In den 80ern und 90ern kommt der von der Annales-Redaktion selbst so genannte „tournant critique“, 1989 mit einem Sonderheft (Chartier, Lepetit, Revel) bekräftigt. Die Krise ist tiefer. Mentalitäten haben Grenzen gezeigt, italienische Mikrohistorie (Ginzburg, Levi, Grendi) hat gezeigt, dass man durch Skalenverkleinerung Außerordentliches leistet, Geertz’ Anthropologie hat die „dichte Beschreibung“ durchgesetzt. Die Annales antworten wie sie können: Paradigmenwechsel. Hin zur Kulturgeschichte, zu „Praktiken“ und „Repräsentationen“, zu engerem Dialog mit Bourdieus Soziologie und der Hermeneutik. Bernard Lepetit unternimmt vor seinem frühen Tod 1996 eine theoretische Neugründung, die die Einwände ernst nimmt — Versuch unvollendet, Minderheit innerhalb der Schule. Die Zeitschrift ändert 1994 ihren Namen von Annales. Économies, Sociétés, Civilisations in Annales. Histoire, Sciences sociales — symptomatisch: das Band zu den Sozialwissenschaften wird gerade in dem Moment beschworen, in dem es am problematischsten ist.

Jacques Revel schlägt damals als Ausweg die „jeux d’échelles“ vor — Spiel der Skalen. Statt zwischen longue durée und Mikro-Einzelfall zu wählen, beherrsche man den Wechsel der Skalen. Suggestiv, aber programmatisch geblieben. Niemand hat einen Beitrag produziert, der die Skalen wirklich kohärent integriert. Man springt, juxtaponiert, fügt zusammen, doch die Integration bleibt Wunsch. Vielleicht geht es nicht anders, denn die Skalen sind keine reinen Zooms auf dieselbe Realität: sie sind verschiedene Weisen, das historische Objekt zu konstruieren, und nicht zwangsläufig kompatibel.

Sei ehrlich. Dass eine intellektuelle Tradition Krisen durchläuft und sich erneuert, ist an sich kein Problem. Alle ernsten Traditionen tun das. Das Problem entsteht, wenn Erneuerung mehr institutioneller als intellektueller Überlebensmechanismus wird, wenn Paradigmenwechsel akademische Posten, Zeitschriftskontrolle, Lehrstuhlhegemonie sichert statt echte Fragen beantwortet. Aus diesem Winkel ist die Annales-Geschichte auch eine Geschichte französischer akademischer Macht — kein Zufall, dass die schärfsten Kritiken oft von außen kamen: italienische Mikrohistorie, britische social history, deutsche Alltagsgeschichte, anglo-amerikanische postkoloniale Historiografie. Vorwurf, unterschiedlich formuliert, mit beeindruckender Konsistenz: die Annales geben vor, eine universelle Methode zu liefern, sie liefern in Wahrheit eine zur globalen Norm erhobene französische Sensibilität, mit allen blinden Flecken, die das mit sich bringt.

Das führt zur tieferen Frage, dem strukturellen Mangel von Anfang an. Histoire totale, totale Geschichte: Blochs und Febvres gründendes Traum, der Horizont, dem jede Generation entgegenzustreben erklärte, selbst wenn sie in entgegengesetzte Richtung lief. Die Idee, eine Geschichte zu schreiben, die alle Ebenen menschlicher Erfahrung integriert — vom Klima bis zum Gebet, vom Getreidepreis bis zu Familienstrukturen, von Technik bis zu Emotionen. Großartiges Programm. Und unmögliches — nicht aus praktischen, sondern aus logischen Gründen.

Jeder historiografische Akt ist ein Auswahlakt. Das Mittelmeer im 16. Jh. zu untersuchen heißt, die Ostsee nicht zu untersuchen. Longue durée zu wählen heißt, das Ereignis nicht zu wählen. Kollektive Mentalitäten zu wählen heißt, individuelle Strategien nicht zu wählen. Diese Wahlen sind nicht zufällig, sie sind konstitutiv: sie definieren, was als historisches Faktum zählt und was nicht, was Erklärung verdient und was ignoriert werden darf. Eine totale Geschichte verlangte das Fehlen jedes Auswahlkriteriums — was dem Fehlen jeder Methode gleichkäme, was dem Nicht-Tun von Geschichte gleichkäme. Hayden Whites Metahistory (1973) hat gezeigt, dass auch große historiografische Werke durch narrative Tropen strukturiert sind, die ihre Form und damit ihren Inhalt prägen. Braudel beschreibt das Mittelmeer nicht: er erzählt es nach narrativer Logik, die selektiert, ordnet, hierarchisiert. Der Anspruch auf Totalität ist genau das — ein Anspruch — und ihn als regulative Idee zu führen, macht ihn nicht weniger inkohärent. Es macht ihn nur schwerer kritisierbar, weil dem, der den nackten König anspricht, geantwortet wird, Totalität sei Ideal, kein Resultat. Aber ein logisch unmögliches Ideal ist kein Horizont, sondern eine Fata Morgana.

Ein zweites Problem, vielleicht das insidiösere, betrifft das Verhältnis der Annales zu den Sozialwissenschaften. Interdisziplinarität war Schlachtross seit der Gründung. Geschichte plus Geographie, Ökonomie, Soziologie, Anthropologie, kollektive Psychologie — jede Generation hat einen privilegierten Gesprächspartner ergänzt und diesen Dialog als Beweis ihrer Modernität präsentiert. Aber was passiert, wenn eine Disziplin sich systematisch durch das definiert, was sie aus anderen importiert? Sie verliert ihr Zentrum. Nicht ihre Methode im engen Sinn — Geschichte hatte nie eine einzige Methode. Sondern etwas Subtileres und Wichtigeres: das Bewusstsein dessen, was spezifisch historisch an einer historischen Untersuchung ist.

Wenn Braudel Geographie importiert, wird das Ergebnis eine Geographie mit zeitlicher Dimension. Wenn Le Goff Anthropologie importiert, wird oft Anthropologie auf die Vergangenheit angewandt. Wenn die vierte Generation Bourdieus Soziologie importiert, entsteht eine historisierte Soziologie. In jedem Fall ist der Dialog asymmetrisch: die Geschichte gibt Boden auf. Grund: die anderen Disziplinen haben stärkere Theoriestrukturen. Ökonomie hat formale Modelle, Soziologie konsolidierte Begriffsapparate, Anthropologie ihre ethnografische Tradition. Geschichte, wie sie die Annales denken, sollte das alles integrieren, ohne ein eigenes ähnlich robustes Theorierahmen zu haben. Resultat: Eklektizismus, als geistige Offenheit verkauft, der praktisch eine strukturelle Verwundbarkeit erzeugt — bei jedem Modetrend wechseln die Annales den Gesprächspartner und damit Methode, Fragen, Objekte. Keine Interdisziplinarität, sondern Abhängigkeit.

Und Abhängigkeit erzeugt eine schwerwiegendere Folge: Verlust technischer Kompetenz. Als Braudel mit Wallerstein dialogierte, beherrschten beide ökonomische Theorie ausreichend. Schon in der dritten Generation wird das Verhältnis asymmetrisch. Mentalitätshistoriker importieren anthropologische Begriffe (Lévy-Bruhls „primitive Mentalität“, Lévi-Strauss’ Verwandtschaftsstrukturen, Van Genneps Rituale), oft ohne fachliche Prüfungsfähigkeit ihrer Solidität im Ursprungskontext. Resultat: Konzepte, geboren um zeitgenössische Gesellschaften zu beschreiben, werden auf Vergangenes mit minimalen Anpassungen projiziert. Wenn Le Roy Laduries Karneval von Romans durch Bachtins Linse des Karnevals als sozialer Umkehr gelesen wird (Versuchung groß bei einem 1580er Karneval, der im Massaker endet), ist das Ergebnis brillant aber methodisch fragil: Bachtin war kein Anthropologe, das „Karnevaleske“ ist eine Literaturkategorie. Muster wiederholt sich.

Braudel mit „Weltwirtschaft“ nahm von Wallerstein, gab ihm zurück. Mentalitätsgeschichte stand im Schatten von Lévi-Strauss. Der cultural turn der 90er undenkbar ohne Bourdieu und Geertz. Die Globalgeschichte, heute als letzter Annales-Avatar präsentiert, verdankt fast alles der anglo-amerikanischen world history (Pomeranz, Subrahmanyam, Bayly). In jedem Schritt wirkte die Schule mehr als Empfänger denn Sender, mehr als Adapter fremder Paradigmen denn als Generator. Kein Problem, würde es anerkannt. Es würde sogar Qualität: Vermittlung, Übersetzung, Hybridisierung. Aber so erzählt sich die Schule nicht. Sie erzählt sich als Ort historiografischer Innovation — Erzählung, die immer weniger glaubhaft ist.

Mir ließe sich entgegenhalten, ich legte einen unmöglichen Maßstab an, ich verlange von Geschichte eine theoretische Struktur wie in Naturwissenschaften — ein Kategorienfehler. Der Einwand hat Gewicht, verfehlt aber das Ziel. Ich verlange nicht universelle Gesetze. Ich verlange etwas Bescheideneres: dass eine historiografische Schule ihre Validierungskriterien klar formulieren kann. Wie unterscheidet man eine gute annalistische Arbeit von einer schlechten? Wie entscheidet man, ob eine Interpretation begründet ist? Wie falsifiziert oder prüft man eine These zur mittelalterlichen Mentalität ernsthaft? Antwort in der Praxis: dem Peer-Urteil überlassen — was in einer gesunden Gemeinschaft funktioniert, in einer Schule mit starker institutioneller Identität und etabliertem Kooptationsmechanismus zum Teufelskreis wird. Karl Popper hätte das Muster mühelos erkannt.

Die Mikrohistorie als radikale Kritik

Kein Zufall, dass die italienische Mikrohistorie teils als Reaktion auf diese Schließung entstand. Wenn Carlo Ginzburg in Der Käse und die Würmer den Kosmos Menocchios rekonstruiert, schreibt er keine Miniatur einer totalen Geschichte — er tut etwas radikal anderes: er zeigt, dass ein Einzelfall, philologisch streng und interpretativ feinfühlig untersucht, Fenster zu tiefen Kulturstrukturen öffnet, ohne grandiose Synthesen. Die Skala ändert alles, denn sie ändert das Verhältnis zur Quelle, zum Beweis, zur Verifizierbarkeit. Wo Braudel über Jahrhunderte und Becken generalisieren konnte, muss Ginzburg jedes Dokument, jedes von Menocchio vor der Inquisition gesprochene Wort verantworten. Dieser Zwang ist keine Schranke, sondern eine Disziplin im edlen Sinn. Mikrohistorie sagt: ich kann nicht alles wissen, aber was ich weiß, weiß ich wirklich, und kann zeigen, woher. Die Annales sagen das Gegenteil: man kann alles wissen, oder es zumindest anstreben, und der Weg ist die interdisziplinäre Synthese. Die Geschichte gab den ersten recht.

Giovanni Levi tut in Das immaterielle Erbe dasselbe: ausgehend von einem piemontesischen Dorf denkt er die Familienstrategien des Ancien Régime neu, ohne je Totalität zu beanspruchen. Mikrohistorie ist keine Variante der Annales, sondern deren Kritik — und dass Le Goff und andere sie zu vereinnahmen versuchten („auch wir achten aufs Detail“), ist ein weiterer Beleg für die Fähigkeit der Schule, das, was sie bedroht, zu phagozytieren.

Dasselbe gilt mutatis mutandis für die Alltagsgeschichte (Lüdtke, Medick), die britische history from below (Thompson) und die ganze postkoloniale Tradition seit Edward Said, die eine Frage stellte, auf die die Annales nie überzeugend antworten: eure totale Geschichte, total für wen? Braudels Mittelmeer? Le Goffs Europa? Le Roy Laduries französische Provinz? Der geografische Provinzialismus der Schule wurde lange durch den Methoden-Universalismus maskiert; als Historiker wie Dipesh Chakrabarty Europa technisch zu „provinzialisieren“ begannen — also zeigten, dass die analytischen Kategorien der europäischen Historiografie nicht universal, sondern historisch situiert sind —, wurde das Spiel schwerer. Boucherons Histoire mondiale de la France (2017) zeigt es ungewollt: ein Buch, das Frankreich durch globale Verbindungen erzählen will und gerade deshalb Frankreichs Zentralität als Beobachtungspunkt bekräftigt. Die Dezentrierung ist scheinbar.

Die Antwort der Schule der letzten zwanzig Jahre war globale, vernetzte Geschichte. Boucheron, Gruzinski, Subrahmanyam (kein eigentlicher Annaliste, will es gesagt haben) haben den Blick auf die Welt geweitet. Operation intellektuell anregend. Aber: was ist daran spezifisch annalistisch? World history existierte vorher, anderswo, und die annalistische Variante distinguiert sich nicht durch eigene Methode, sondern erneut durch eine Haltung. Beitrag? Vielleicht. Reicht es, weiter den Anspruch zu rechtfertigen, eine erkennbare Schule mit Programm zu sein? Ich zweifle. Annales veröffentlicht heute Beiträge variabler Qualität zu enorm verschiedenen Themen: islamisches Recht, Tokugawa-Ökonomie, Umweltgeschichte des Amazonas, Emotionen der Frühen Neuzeit. Was hält das zusammen außer derselben Zeitschrift? Welche methodische Klammer trennt einen „annalistischen“ Aufsatz von einem in Past and Present oder Quaderni storici? Ehrliche Antwort: keine.

Damit der mir wichtigste Punkt: Das Annales-Problem ist kein Einzelfehler, nicht longue durée an sich, nicht Interdisziplinarität an sich, nicht totale Geschichte an sich. Es ist die Kombination dieser drei in einem Programm, das nie über seine eigene innere Kohärenz Rechenschaft ablegen konnte. Die longue durée verlangte eine deterministische Erkenntnistheorie, die Mentalitätsgeschichte verworfen hat. Interdisziplinarität verlangte einen integrierenden Theorierahmen, der nie produziert wurde. Totale Geschichte verlangte Auswahlkriterien, die ihre Definition selbst ausschließt. Einzeln betrachtet enthält jeder Punkt wertvolle Intuitionen. Zusammen produzieren sie ein in sich widersprüchliches Programm, das nur überlebt dank vager Prinzipien und starker Institutionen.

Das heißt nicht, dass Annales-Historiker keine exzellenten Werke produziert hätten. Sie haben es, viele bleiben unverzichtbar. Aber sie produzierten sie nicht dank des Schulprogramms, sondern trotz seiner — oder genauer: indem sie selektiv die nützlichen Aspekte ausnutzten und den Rest ignorierten. Braudel ist groß nicht, weil er die longue durée kohärent anwendet, sondern weil er ein außerordentlicher Erzähler ist. Le Goff ist groß nicht, weil Mentalitätsgeschichte solide Methode wäre, sondern weil sein Wissen und seine historische Phantasie außergewöhnlich sind. Ginzburg, den die Schule zu vereinnahmen versuchte, ist groß genau, weil er das Annales-Programm ablehnte und ein anderes vorschlug.

Bleibt die Eingangsfrage. Sind die Annales gescheitert? Hängt davon ab, was man unter Scheitern versteht. Wenn man meint, die Schule habe ihre Versprechen nicht gehalten, dass das Programm einer totalen, interdisziplinären, wissenschaftlich fundierten Geschichte sich als unrealisierbar erwies, dann ja. Aber das wichtigere Scheitern ist vielleicht nicht ihres, sondern das des Traums, der sie hervorbrachte: die in der Aufklärung verwurzelte und vom 19. Jh.-Positivismus neu lancierte Idee, Geschichte könne im vollen Sinn Wissenschaft werden, mit allgemeinen Gesetzen, reproduzierbaren Methoden, kumulativer Erklärungskraft. Die Annales haben den Versuch mit mehr Ambition, Talent und institutionellen Ressourcen unternommen als irgendwer im 20. Jh. Dass sie nicht reüssiert haben, sagt nichts gegen ihre Intelligenz. Es sagt vielleicht etwas über die Natur historischen Wissens, das der Systematisierung widersteht — nicht aus überwindbarem Mangel, sondern aus konstitutivem Charakter. Geschichte ist nicht Physik, nicht Biologie, nicht einmal Ökonomie. Weil ihr Objekt kein System, sondern ein Prozess ist, dessen Sinn rückwirkend vom Beobachter konstruiert wird. Geschichte ist die Erzählung, die Menschen über sich selbst machen, und diese Erzählung ist notwendig partiell, situiert, anfechtbar. Sie total machen zu wollen ist wie Licht fotografieren wollen: das Werkzeug ist Teil dessen, was du einfangen willst. Die Annales haben das auf ihre Kosten entdeckt — und dass sie es weiter nicht zugeben, ist vielleicht die härteste Kritik.

Jenseits der Totalität

Vielleicht nicht zufällig waren die lebendigsten historiografischen Traditionen der letzten Jahrzehnte jene, die der Totalität explizit entsagten. Mikrohistorie wählte kleine Skala und analytische Dichte. Oral History die individuelle Stimme. Digital History experimentiert mit Quantifizierung, ohne Zahlen den Sinn ausmachen zu lassen. Selbst die interessanteste Globalgeschichte, etwa Subrahmanyams, funktioniert, weil sie spezifischen Verbindungen folgt, statt Allüberschauen zu zeichnen. In jedem Ansatz liegt etwas, das die Annales geahnt hatten (Bedeutung der Strukturen, Dialog mit anderen Disziplinen, Aufmerksamkeit für lange Zeiten), gereinigt aber von der systemischen Hybris, vom Anspruch, dass alles zusammenhalte, dass der Kreis sich schließe. Der Kreis schließt sich nie, in der Geschichte. Genau diese Unvollständigkeit macht die Disziplin interessant — nicht trotz, sondern dank ihrer epistemologischen Grenzen. Die Annales, in ihren ehrgeizigsten Versionen, haben das nie akzeptiert. Und diese Unfähigkeit, die Grenze anzunehmen, ist am Ende ihre größte Grenze.

Keine Kritik. Eine Beobachtung über einen strukturellen blinden Fleck im IT-Advisory-Markt. Die Personen, die Unternehmen beim Tech-Einkauf beraten, haben in der überwältigenden Mehrheit nie Tech verkauft. Und die, die Tech verkaufen und ausliefern, haben keine Stimme in der Definition von Sourcing-Best-Practices. Resultat: ein Informationsdefizit, das Käufer wie Verkäufer reales Geld kostet.

Ich sage das aus Erfahrung. Ich führe eine kleine ICT-Firma, die von Verträgen mit Mid-Market-Kunden und der öffentlichen Verwaltung lebt. Ich habe Angebote geschrieben, Verträge verhandelt, SLAs definiert, Eskalationen gemanagt, Strafen kassiert, Projekte zu spät und früher geliefert. Ich habe den IT-Service-Markt von der Tischseite gesehen, die Sourcing-Analysten selten sehen. Und was ich sehe, deckt sich nicht immer mit den Beschreibungen der Advisory-Frameworks.

Erster blinder Fleck: das Pricing

Die meisten Advisory-Frameworks bewerten IT-Anbieter nach Kosten pro Personentag oder Funktionspunkt. Verständliche, vergleichbare und im Grunde überholte Metriken. KI macht das Verhältnis zwischen Arbeitszeit und geliefertem Wert vollständig nichtlinear. Ein Fünfer-Team mit agentischem Coding liefert in einer Woche, was ein Fünfzehner-Team in einem Monat lieferte. Identischer Wert für den Kunden. Ein Fünftel der Personentage. Zahlt der Kunde nach Personentagen, hat der Anbieter den perversen Anreiz, KI nicht zu adoptieren — er fakturiert weniger. Adoptiert der Anbieter KI und der Kunde misst weiter Personentage, wirkt der Anbieter pro Tag fünfmal teurer, auch wenn der Gesamtkostenpunkt sinkt.

Kein theoretisches Problem. Ich begegne ihm jeden Monat in Angeboten. Ich preise seit über einem Jahr nicht mehr nach Personentagen. Ich preise nach Liefergegenstand: hier das Ergebnis, hier der Preis, hier die Bedingungen. Manche Kunden schätzen das. Andere — vor allem in der PA, deren Ausschreibungen um Personentage herum gestrickt sind — wissen nicht, wie sie damit umgehen sollen. Der Beschaffungsrahmen sieht keinen Anbieter vor, der mehr Wert in weniger Zeit liefert.

Zweiter blinder Fleck: Compliance als Sourcing-Kriterium

Frameworks beginnen, sie aufzunehmen — als Häkchen: „Anbieter DSGVO-konform? Ja/Nein“. Radikal unzureichend. Compliance ist nicht binär. Sie ist ein Spektrum. Ein Anbieter kann eine Datenschutzerklärung auf der Website haben und keinen technischen Mechanismus zur Datenminimierung im Code. Behaupten, AI-Act-konform zu sein, ohne zu wissen, was eine Risikobewertung für Hochrisiko-KI-Systeme ist. Das SBOM-Häkchen setzen, ohne eine Pipeline, die SBOMs bei jedem Build automatisch erzeugt.

Ein ernstes Sourcing-Framework, im heutigen EU-Kontext, sollte Compliance nicht als Erklärung, sondern als technische Fähigkeit bewerten. Hat der Anbieter einen dokumentierten Schwachstellenprozess? Beinhaltet seine CI/CD-Pipeline einen Dependency-Scan? Werden SBOMs automatisch erzeugt oder per Hand zusammengestellt? Hat seine Software automatisierte Tests, die Privacy-Eigenschaften prüfen? Diese Fragen offenbaren mehr als jede Zertifizierung. Und nur wer operative Liefererfahrung hat, kann sie formulieren.

Dritter blinder Fleck: die IT-KMU

Der Advisory-Markt ist um die großen Systemintegratoren strukturiert. Bewertungsmatrizen, Magic Quadrant, Wave, Provider Lens — alle auf Unternehmen mit Hunderten Millionen Umsatz geeicht. IT-KMU — die in Europa die überwältigende Mehrheit der Software-Service-Anbieter darstellen — sind in diesen Frameworks unsichtbar. Nicht weil sie keinen Wert liefern, sondern weil sie nicht die Skala haben, an Bewertungsprozessen teilzunehmen.

Daraus ein Paradox. Der Mid-Market-Kunde — die Firma mit 200-500 Mitarbeitenden, die Klinik, die Kommune, die Handelskammer — liest die Berichte und sieht nur große Namen. Aber die Großen bedienen den italienischen Mid-Market nicht oder mit Junior-Teams unter Aufsicht eines nie sichtbaren Partners. Der Anbieter, der die Arbeit wirklich liefert — die lokale Zehn-Personen-KMU mit einer Senior pro Projekt und direkter Beziehung zum Entscheider —, taucht in keinem Framework auf. Vollständige Informationslücke.

Vierter blinder Fleck: Vertragsgovernance

Frameworks sind sehr gut darin, die Auswahlphase zu bewerten: wie man wählt, vergleicht, verhandelt. Sehr viel schlechter in der Ausführungsphase: wie man überwacht, eingreift, Scope-Änderungen managt. Aus meiner Erfahrung entstehen 90 % der Probleme nicht aus falscher Wahl des Anbieters. Sie entstehen aus schlechter Vertragsführung danach.

Ich habe Projekte scheitern sehen, nicht weil der Anbieter unfähig war, sondern weil der Kunde keine interne Governance hatte, um Anforderungsänderungen zu entscheiden. SLAs auf Cent-Genauigkeit verhandelt, die niemand überwachte. Vertragsstrafen, die nie angewandt wurden, weil der Kunde zu sehr vom Anbieter abhing, um ihn zu sanktionieren. Wiederkehrende Muster, die jeder IT-Anbieter intim kennt und die Frameworks als Ausnahmen behandeln.

Fünfter blinder Fleck: technische Qualität und Business

Vielleicht der tiefste: das Verhältnis zwischen technischer Qualität und Geschäftserfolg. Frameworks bewerten Preis, Track Record, Teamgröße, Zertifikate. Selten die technische Qualität der gelieferten Software. Wie viele automatische Tests im Codebase? Welche Coverage? Wie ist die Architektur strukturiert? Ist der Code wartbar? Ist die Doku aktuell? Diese Dimensionen bestimmen die echten Total Cost of Ownership — nicht die deklarierten — und Sourcing-Analysten sind nicht ausgerüstet, sie zu beurteilen.

Resultat: der Markt belohnt die Verkaufsfähigkeit — überzeugende Präsentationen, solide Referenzen, große Teams — statt der Baufähigkeit. Das erklärt, warum so viele IT-Projekte das Doppelte des Geplanten kosten und die Hälfte des Versprochenen liefern: die Auswahl erfolgt anhand von Kriterien, die die Ausführungsqualität nicht vorhersagen.

Ich schreibe das nicht aus Lust, eine Branche zu kritisieren, die ich respektiere und ehrlich gesagt interessant finde. Ich schreibe es, weil der IT-Advisory-Markt an einem Wendepunkt steht. KI verändert die Ökonomie der Lieferung. EU-Compliance verändert die Einkaufskriterien. Der europäische Mid-Market braucht Bewertungsframeworks, die keine vereinfachten Versionen der Enterprise-Frameworks sind. Und IT-Anbieter — jene, die wirklich bauen und liefern — haben ein operatives Wissen, das, in Advisory-Frameworks integriert, sie viel nützlicher machte.

Ich beanspruche keine Lösung. Aber nach fünfzehn Jahren auf der anderen Tischseite weiß ich, welche Fragen gestellt werden sollten und nicht gestellt werden. Welche Metriken Projekterfolg vorhersagen und welche nur die Qualität der ersten Präsentation. Was sich im Pricing ändert, wenn KI in den Lieferzyklus tritt. Was Compliance in einer Produktions-Codebase heißt, nicht in einem Policy-Dokument.

Wissen, das der Advisory-Markt nicht hat — nicht aus Inkompetenz, sondern weil er strukturell von der Lieferung getrennt ist. Vielleicht ist es Zeit, eine Brücke zu bauen.

Den Großteil der Technikgeschichte hindurch war es möglich, mindestens eine Person zu finden, die ein Artefakt als Ganzes verstand. Das römische Aquädukt, der mechanische Webstuhl, die Dampflokomotive, sogar ein Flugzeug aus dem Zweiten Weltkrieg: kompliziert, ja, aber letztlich auf ein einheitliches Wissen zurückführbar. Eine ausreichend ausgebildete Ingenieurin konnte die Kausalkette von einem Ende zum anderen ziehen. Sagen: ich weiß, wie es funktioniert, warum es funktioniert, was passiert, wenn es bricht. Diese Möglichkeit war kein Detail. Sie war das Fundament der Idee technischer Kompetenz — und mit ihr der Verantwortung.

Dieses Fundament ist nicht mehr da.

Die Schwelle

Der Bruchpunkt war nicht plötzlich. Er hat sich über Jahrzehnte angesammelt, unsichtbar wie alle schichtenweisen Veränderungen. Jede über die vorige gelegte Abstraktion löste ein Problem und erzeugte ein neues: die darunterliegende Schicht undurchsichtig zu machen. Wer heute Anwendungscode schreibt, kennt das Framework nicht wirklich. Wer das Framework kennt, kennt die Runtime nicht. Wer die Runtime kennt, kennt das Betriebssystem nicht ganz. Wer das Betriebssystem kennt, kennt den Microcode des Prozessors nicht. Und niemand, wirklich niemand, kennt die ganze Abhängigkeitskette, die ein einzelnes Install-Kommando aus dem Netz zieht und Teil der Software macht.

Keine polemische Übertreibung. Eine sachliche Beschreibung. Ein durchschnittliches Software-Projekt 2026 hat hunderte direkte und tausende transitive Abhängigkeiten. Jede von jemand anderem geschrieben, mit eigenen Abhängigkeiten, eigenen Schwachstellen, eigenen Architekturentscheidungen in einem Kontext, den niemand stromabwärts je rekonstruieren wird. Software auszuführen heißt heute zu vertrauen. Nicht im edlen Sinn zwischen Personen, sondern im erkenntnistheoretischen Sinn dessen, der auf Verifikation verzichtet, weil sie materiell unmöglich ist.

Es gab eine Zeit, in der das Wort „Ingenieur“ die Möglichkeit totaler Kontrolle über das Arbeitsobjekt einschloss. Diese Zeit ist vorbei. Sie kommt nicht zurück.

Wissen als Skalenillusion

Das Problem ist nicht, dass wir wenig wissen. Es ist, dass das Wissen, das wir besitzen, nicht maßstäblich zur Komplexität dessen ist, was wir betreiben. Wir wissen Dinge. Sogar viele. Doch das Wissen, das ein modernes verteiltes System verstehen ließe, ist nicht die Summe individueller Kenntnisse: es ist Wissen, das einen Geist verlangte, der gleichzeitig Schichten zusammenhalten könnte, die ihrer Natur nach für Trennung entworfen sind.

Abstraktion, der grundlegende Mechanismus computationalen Denkens, funktioniert genau, weil sie versteckt. Verdienst und Falle zugleich. Eine gut entworfene Schnittstelle befreit dich davon, zu wissen, was darunter passiert. Wenn aber etwas schiefgeht, entdeckst du, dass „darunter“ eine Welt liegt, die niemand im Raum kennt — und vielleicht niemand auf der Welt als Ganzes. Nicht weil das Wissen nicht existierte, sondern weil es unrettbar zwischen tausenden Personen verteilt ist, die nie miteinander gesprochen haben.

Eine neue erkenntnistheoretische Bedingung. Ohne Vorbild in der Technikgeschichte, mit wenigen Analogien in der Geistesgeschichte. Am ehesten Adam Smiths Arbeitsteilung — mit einem entscheidenden Unterschied: Smith sprach von einem Produktionsprozess, in dem jede Arbeiterin ihren Teil verstand. Hier versteht niemand wirklich auch nur den eigenen Teil, weil dieser auf anderen Teilen ruht, die per Definition entgleiten.

Die zerbrochene Verantwortungskette

Wenn niemand das System als Ganzes versteht, hat die Frage, wer verantwortlich ist, keine befriedigende Antwort. Nicht aus Mangel an Kandidaten, sondern weil der Begriff der Verantwortung selbst voraussetzt, was hier fehlt: die Möglichkeit zu wissen.

Verantwortung heißt etymologisch: antwortenkönnen. Rechenschaft ablegen. Aber wie über eine Entscheidung Rechenschaft ablegen, die in einem nicht ganz verstehbaren Kontext gefällt wurde? Wie für ein System einstehen, dessen Verhalten aus Interaktionen zwischen Komponenten emergiert, die kein einzelner Akteur entworfen oder vorgesehen hat?

Das Recht, das darüber viel mehr nachgedacht hat als die Informatik, hat die Idee der Sorgfaltspflicht entwickelt: man muss nicht alles verstehen, es genügt, mit der vernünftigerweise von der Rolle erwarteten Sorgfalt zu handeln. Pragmatischer Kompromiss, der jahrhundertelang trug. Er trug, weil der Abstand zwischen wissbarem Wissen und nötiger Entscheidung durch Studium und Erfahrung schließbar war. Heute ist dieser Abstand nicht mehr schließbar. Kein Engagementproblem: ein struktureller Abstand, durch die Komplexität des Objekts erzeugt, nicht durch die Inadäquatheit des Subjekts.

Die jüngere EU-Gesetzgebung ahnt das, ohne es zu erklären. CRA, PLD, AI Act: alle versuchen, Verantwortungsketten in einem Kontext zu rekonstruieren, in dem diese Ketten physisch zerbrochen sind. Mit klassischen Mitteln: Doku-Pflichten, Konformitätsbewertungen, Risikomatrizen. Ernsthafte, oft willkommene Versuche. Aber sie ruhen auf einer stillen Annahme: dass irgendwo jemand weiß.

Der Hersteller muss die Risiken seines Produkts dokumentieren. Aber er kennt die transitiven Abhängigkeiten seines Codes nicht. Der Importeur muss die Konformität prüfen. Aber Konformität ist gegenüber Standards definiert, die Eigenschaften beschreiben, die niemand in der Praxis verifizieren kann. Der Nutzer soll informiert einwilligen. Aber die Information für eine echte Einwilligung verlangte Kompetenzen, die selbst der Software-Autor nicht hat.

Kein Zynismus. Die genaue Beschreibung einer Lage, die wir Schritt für Schritt geschaffen haben, in gutem Glauben — jedes Mal das unmittelbare Problem lösend und jedes Mal ein Gramm Undurchsichtigkeit dem Gesamtsystem hinzufügend.

Der Mythos der Spezialisierung

Ein häufiger Einwand: Spezialisierung löst es. Niemand muss alles verstehen, jedem genügt sein Teil, das Ganze wird funktionieren. Arbeitsteilung des Wissens — attraktiv, weil es die Grundsatzfrage umgeht.

Es funktioniert nicht. Weil die Grenzen zwischen den „Teilen“ willkürlich und durchlässig sind. Ein Sicherheitsproblem zieht durch alle Schichten. Eine normative Anforderung schneidet quer durch Frontend, Backend, Infrastruktur, Drittanbieter. Eine vor fünf Jahren in einem nicht mehr existierenden Kontext getroffene Architekturentscheidung beschränkt heute Entscheidungen, die der Ursprünger nicht hätte vorhersehen können.

Spezialisierung funktioniert, wenn Komponenten wirklich unabhängig sind. Software ist es nicht. Sie besteht aus Abhängigkeiten, im Wortsinn: jeder Teil hängt von anderen ab, und das Verhalten des Ganzen ist aus dem der Teile nicht ableitbar. Was die Systemtheorie Emergenz nennt — und Emergenz ist genau der Gegner der Spezialisierung. Der heimtückischste Bug lebt immer im Raum zwischen Spezialisierungen, wo niemand hinsieht, weil niemand denkt, das sei sein Gebiet.

Die Inkompetenz der Gesetzgebenden

Ein besonderer Fall verdient Aufmerksamkeit, nicht aus Anklage, sondern strukturell erhellend: die Inkompetenz derer, die Normen schreiben.

Eine Gesetzgeberin, die Software-Regeln schreibt, ist erkenntnistheoretisch in derselben Lage wie alle: sie kann das System als Ganzes nicht verstehen. Anders als ein Dev oder Architekt hat sie aber nicht einmal das partielle Wissen aus Alltagsnutzung. Sie operiert auf Beschreibungen von Beschreibungen, auf Abstraktionen von Abstraktionen, durch Beratungen vermittelt, die wiederum Spezialistenwissen vermitteln.

Kein Argument gegen Regulierung. Im Gegenteil: ein Argument über die Natur möglicher Regulierung. Was nicht ganz verstehbar ist, zu normieren, ist kein Versagen, es ist die Ausgangsbedingung. Die Frage ist nicht, ob Gesetzgebende kompetent sind — sie können es nicht im vollen Sinn sein, und nicht aus eigener Schuld. Die Frage ist, ob die produzierten Normen robust genug sind, trotz struktureller Inkompetenz derer, die sie geschrieben, anzuwenden, zu prüfen haben.

Manchmal ja. Die DSGVO hat mit allen Grenzen ein Vorsorgeprinzip eingeführt, das funktioniert, gerade weil es kein technisches Verständnis verlangt: sie behandelt personenbezogene Daten als gefährlich, unabhängig davon, ob du die spezifischen Mechanismen verstehst. Eine Norm, für Inkompetenz entworfen — und sie wirkt besser als viele, die Kompetenz voraussetzen.

Sokrates im Dev-Zyklus

Sokrates wird mit der Häufigkeit und Ungenauigkeit aller zu nützlicher Sätze ein Zitat zugeschrieben: „ich weiß, dass ich nichts weiß.“ Als Demutsgeste zitiert, manchmal als intellektuelle Eitelkeit. In der radikalen Version der platonischen Apologie ist der Punkt unbequemer: Sokrates sagt nicht bloß, sein Wissen sei begrenzt. Er sagt, wer zu wissen glaubt, sei in schlechterer Lage als wer weiß, dass er nicht weiß — denn der ergänzt seine Unwissenheit um die Illusion.

Auf die Tech-Gegenwart angewandt, gewinnt die These ein Gewicht, das Platon nicht hätte ahnen können. Die Software-Industrie ruht auf einer doppelten Wissens-Illusion: der Bauenden (die zu kontrollieren glauben) und der Nutzenden (die zu verstehen glauben). Beide funktional. Ohne die erste schriebe niemand Code, weil vollständige Ehrlichkeit lähmend wäre. Ohne die zweite nutzte niemand Software, weil echte informierte Einwilligung Massenablehnung erzeugte.

Wir funktionieren dank einer freiwilligen Aussetzung des erkenntnistheoretischen Unglaubens. Nicht anders als Finanz, Politik oder jedes komplexe System, in dem Vertrauen Verstehen ersetzt.

Mit einem Unterschied. Finanz und Politik haben institutionelles Bewusstsein ihrer epistemologischen Fragilität entwickelt. Zentralbanken existieren, weil wir wissen, dass das Finanzsystem sich nicht selbst reguliert. Verfassungen existieren, weil wir wissen, dass Macht sich nicht selbst begrenzt. Die Informatik hat noch nichts Vergleichbares. Keine Institutionen für die Bedingung, dass niemand weiß. Standards, Best Practices, Zertifizierungs-Frameworks: alles Werkzeuge, die die Möglichkeit des Wissens voraussetzen, anstatt seine Unmöglichkeit zu bearbeiten.

Entscheiden ohne zu wissen

Der Alltag in der Tech: entscheiden ohne zu wissen. Nicht im dramatischen Sinn einer Blindwette, sondern im gewöhnlichen, leicht zermürbenden Sinn dessen, der täglich Entscheidungen mit mehrjährigen Folgen trifft, gestützt auf Informationen, die er als unvollständig erkennt, in Kontexten, die sich ändern werden, für Anforderungen, die provisorisch sind.

Eine Schätzung ist eine subjektive Wahrscheinlichkeitsangabe als Prognose ausgegeben. Eine Architekturwahl ist Glaubensakt an die Stabilität nicht stabiler Bedingungen. Ein Refactoring ist eine Wette darauf, dass gegenwärtige Kosten durch zukünftige Vorteile aufgewogen werden, die niemand garantieren kann. Jeder Sprint ist angewandte Erkenntnistheorie unter Zeitdruck, geleitet von Leuten, die keine Erkenntnistheorie studiert haben und nicht dafür bezahlt werden, über die Bedingungen ihres Wissens nachzudenken, sondern Ergebnisse zu liefern.

Keine Anklage. Eine Beschreibung. Und der Punkt ist nicht, es sollte anders sein: es kann nicht anders sein. Strukturelle Inkompetenz ist kein zu lösendes Problem. Sie ist die Bedingung, in der wir operieren — solange wir Systeme bauen, deren Komplexität die Verstehenskapazität ihrer Bauenden übersteigt.

Die Frage ist nicht, sie zu eliminieren. Sondern sie zu bewohnen.

Die Inkompetenz bewohnen

Wenn Kompetenz im klassischen Sinn vollständiger Beherrschung nicht mehr erreichbar ist, ist das, was wir so nennen, etwas anderes geworden. Kein Wissen, sondern Können in Abwesenheit von Wissen. Eine Form praktischer Klugheit, näher an der aristotelischen Phronesis als an der Episteme: nicht Kenntnis erster Ursachen, sondern die Fähigkeit, in besonderen, unsicheren Situationen gut zu handeln.

Die gute Tech-Person heute ist nicht jene, die mehr weiß. Es ist, wer ihre Unwissenheit besser handhabt. Wer weiß, wo die Grenzen ihres Verständnisses liegen, fragen kann, weiß wann anhalten, Systeme baut, die vorhersehbar statt katastrophal versagen. Alles Kompetenzen — aber Kompetenzen über die eigene Inkompetenz. Meta-Kompetenzen, wenn man ein hässliches Wort für eine wichtige Idee akzeptiert.

Hier ein Paradox, das offen anzuschauen lohnt. Die Profikultur des Software belohnt Wissen und bestraft Nichtwissen. Wer zugibt, nicht zu verstehen, verliert Kredit. Wer in einem Meeting „weiß ich nicht“ sagt, gilt als schwach. Wer ehrlich schätzt, wird im Vergleich zu Optimisten bestraft. Das ganze Anreizsystem maskiert Inkompetenz statt sie zu managen — und produziert das Gegenteil: nicht erkannte, nicht gemanagte, nicht metabolisierte Inkompetenz. Gefährliche Inkompetenz.

Eine reife Profikultur täte das Umgekehrte. Sie ginge davon aus, dass niemand das System ganz versteht, und baute Prozesse, Werkzeuge, Institutionen, die unter dieser Bedingung funktionieren. Keine Utopie: das ist Ingenieurskunst der Unwissenheit, und genau das tun wir, wenn wir automatische Tests schreiben (wir prüfen, weil wir unserem Verstehen nicht trauen), Code Reviews machen (wir suchen Fehler im blinden Fleck), das Prinzip minimaler Rechte anwenden (wir begrenzen den Schaden unserer Unwissenheit).

Keine Palliativa. Die anspruchsvollsten Praktiken, die die Branche hervorgebracht hat — und alle im Kern Techniken zur Verwaltung von Inkompetenz. Niemand nennt sie so, weil der Name unbequem wäre. Aber sie sind es.

Ehrlichkeit als Methode

Vielleicht ist die einzige verfügbare Antwort auf strukturelle Inkompetenz keine Lösung, sondern eine Haltung: erkenntnistheoretische Ehrlichkeit als tägliche Praxis. Wissen, dass man nicht weiß, nicht als leere Formel, sondern als operativer Ausgangspunkt jeder Entscheidung.

Keine Lähmung. Entscheiden im Bewusstsein, blind zu entscheiden — und Sicherungsnetze proportional zu diesem Bewusstsein bauen. Dokumentieren nicht nur, was getan wurde, sondern warum und unter welchen Annahmen — denn diese Annahmen werden sich als falsch erweisen, und wer nachkommt, muss nicht die Lösung verstehen, sondern die Argumentation, die sie hervorbrachte. Aufhören, Schätzungen als Versprechen und Architekturen als Monumente zu behandeln.

Kein revolutionärer Vorschlag. Die Beschreibung dessen, was die Besten ohnehin tun — oft im Stillen, oft gegen die umgebende Kultur. Strukturelle Inkompetenz ist kein zu besiegender Feind. Sie ist das Gelände, auf dem wir gehen, und die einzige Wahl ist zwischen offenen oder geschlossenen Augen.

Wir, als Spezies, haben eine Welt gebaut, die wir nicht verstehen können. Keine Tragödie. Vielleicht das Menschlichste, das wir je getan haben.

Und genau aus dieser Position, nicht aus der externen Kritiker-Loge, sage ich, was unsere Branche nicht hören will: die meiste Software, die existiert, sollte nicht existieren.

Nicht weil sie schlecht gemacht ist. Manche schon, klar — aber das ist nicht der Punkt. Sie sollte nicht existieren, weil sie kein Problem löst. Oder eines, das niemand hat. Oder weil sie ein bereits gelöstes Problem schlechter löst. Oder, häufigster und heimtückischster Fall: weil sie das Problem schafft, das sie vorgibt zu lösen.

Der Friedhof erfundener Probleme

Öffne dein Telefon. Zähle die Apps. Wie viele nutzt du wirklich? Wie viele lösen ein reales Problem in deinem Leben? Und wie viele existieren, weil jemand ein überzeugendes Pitchdeck zusammengestellt, eine Runde geraised, dafür gebaut hat, was niemand verlangte?

Kein Randphänomen. Das dominante Modell der letzten fünfzehn Jahre.

So läuft der Zyklus: jemand identifiziert einen „Pain Point“ (fast immer ein kleiner Komfortverlust, zur existenziellen Tragödie aufgebauscht), baut ein MVP, raised Geld, stellt Entwickler:innen ein, skaliert. Irgendwann existiert die Software, hat Nutzer:innen, generiert Umsatz. Aber niemand hat innegehalten und gefragt, ob die Welt das braucht. Die Frage war irrelevant. Die relevante Frage: wächst es?

Ich sah Apps für Einkaufslisten unter Mitbewohner:innen. Plattformen für KI-gestützte Friseurbuchung. SaaS für die Pflege von Zimmerpflanzen. Marktplätze für gebrauchte Hundekleidung. Erfunden ist nichts. Jedes davon erhielt Finanzierung, hatte ein Dev-Team, verbrauchte Server, Energie, menschliche Zeit.

Das Problem war nicht, dass sie schlecht waren. Manche waren technisch makellos. Das Problem: sie hatten keinen Existenzgrund. Und niemand sagte es, weil das Sagen zum „Innovationsfeind“ macht.

Die versteckte Steuer

Software ist nie gratis. Auch wenn sie der Nutzerin nichts kostet, kostet sie die Welt.

Energie. Jede unnötige App läuft auf Servern, die Strom verbrauchen. Jeder unnötige SaaS hat eine über drei Zonen replizierte Datenbank, ein Monitoring, ein globales CDN. Die Cloud ist keine Wolke: ein Lager voller Maschinen, die sich erhitzen, in Irland oder Virginia, an einem Stromnetz mit physischen Grenzen.

Aufmerksamkeit. Jede unnötige App auf einem Telefon konkurriert mit allem anderen um die Aufmerksamkeit. Mit Arbeit, Beziehungen, Schlaf, produktiver Langeweile, unstrukturiertem Denken. Aufmerksamkeit ist endlich. Jede unnötige App, die sie fängt, stiehlt sie etwas Wichtigerem.

Komplexität. Jede Software ergänzt eine Oberfläche, einen Login, ein Passwort, weitere Benachrichtigungen, weitere AGB, die niemand liest, weitere Datenströme, die wer weiß wohin gehen. Die Komplexität unserer digitalen Umgebung wächst Jahr für Jahr — nicht weil die Probleme wachsen, sondern weil die Lösungen schneller wachsen als die Probleme.

Talent. Die teuerste Kosten, die mich am meisten ärgert. Es gibt Entwickler:innen mit außergewöhnlichem Talent, die ihre Tage damit verbringen, den Conversion-Funnel einer Kaffee-App um drei Taps zu kürzen. Menschen, die Software bauen könnten, die Leben rettet, Bildung zugänglich macht, das Gesundheitswesen verbessert. Stattdessen optimieren sie die Farbe eines „Jetzt kaufen“-Buttons.

Nicht ihre Schuld. Der Markt zahlt mehr für den Button. Aber die Verschwendung ist so obszön, dass es Anstand wäre, sie zu benennen.

‚Aber der Markt entscheidet’

Der Einwand. Wenn eine Software existiert und Nutzer:innen hat, hat der Markt entschieden, dass sie gebraucht wird. Unsichtbare Hand, alles gut.

Stimmt nicht. Der Software-Markt funktioniert nicht wie der Apfelmarkt.

Erstens: die Grenzkosten der Distribution sind nahe null. Eine Software erreicht Millionen Nutzer:innen, ohne dass Qualität oder Nötigkeit durch echtes Feedback geprüft wird. Ein Obsthändler mit faulen Äpfeln geht in einer Woche pleite. Eine App, die nichts löst, kann jahrelang vom VC finanziert überleben, bis zur nächsten Runde oder zum Käufer.

Zweitens: das Werbemodell hat Wert und Preis entkoppelt. Wenn der Nutzer nicht zahlt, muss das Produkt nicht für ihn nützlich sein. Es muss für die Werbetreibenden nützlich sein. Und für sie zählt Aufmerksamkeit, nicht Zufriedenheit. Software, die Menschen unglücklich macht, sie aber an den Bildschirm fesselt, ist ein außerordentlicher kommerzieller Erfolg. Der Markt „hat entschieden“, dass sie gebraucht wird. Aber dieser Markt ist krank.

Drittens: Network Effects schaffen natürliche Monopole. Wenn alle eine Plattform nutzen, kannst du nicht nicht-nutzen. Nicht weil sie gut wäre, sondern weil alle dort sind. Der Markt hat nicht „entschieden“, dass WhatsApp die beste Kommunikationsweise ist. Er hat entschieden, dass es die ist, mit der alle kommunizieren — eine ganz andere Sache.

Der radikale Akt, nicht zu bauen

In der Tech-Kultur ist Bauen immer positiv. „Makers gonna make.“ „Ship it.“ „Build in public.“ Bauen hat sakrale Aura, wer baut, ist per definitionem auf der richtigen Seite der Geschichte.

Aber es gibt einen mutigeren Akt: zu entscheiden, nicht zu bauen.

Zu entscheiden, dass die Welt keinen weiteren Task-Manager braucht. Dass eine Excel deine App schlägt. Dass das Problem keins ist. Dass dein Talent und deine Zeit anderswo besser aufgehoben sind.

Die besten Tech-Leute, die ich kannte, konnten am ehesten „braucht’s nicht“ sagen. Nicht aus Faulheit, nicht aus Zynismus. Aus Respekt. Vor dem Problem, dem Nutzer, der Komplexität der Welt. Sie wussten: Software in einen Kontext zu legen, fügt Komplexität, Abhängigkeiten, Wartung, technische Schuld hinzu. Es ohne starken Grund zu tun, ist Verantwortungslosigkeit als Produktivität verkleidet.

Die Unix-Philosophie sagte es vor vierzig Jahren: tu eine Sache, und tu sie gut. Nicht „tu alles“. Nicht „tu Neues, weil du kannst“. Eine Sache. Den Rest lass.

Die Software, die existieren sollte

Ich sage nicht, Software sei der Feind. Das wäre, als wäre Schreiben der Feind, weil es schlechte Bücher gibt.

Software, die existieren sollte, erweitert menschliche Fähigkeiten ohne Abhängigkeit zu erzeugen. Sie löst ein reales, überprüfbares Problem. Funktioniert für die Nutzer:innen, nicht für die Verkaufenden. Du kannst sie ohne Folgen weglassen. Sie braucht dich nicht zu fangen, um zu rechtfertigen, dass es sie gibt.

Software, die existieren sollte, ist die, deren Verschwinden bemerkt würde. Nicht zwanghaft wie beim Süchtigen, sondern konkret, wie wenn ein nützliches Werkzeug fehlt. Wie ein gutes Küchenmesser. Wie ein zuverlässiges Fahrrad.

Das ist die Metrik: würdest du sie vermissen? Wenn die Antwort „wahrscheinlich nicht“ ist, sollte die Software nicht existieren. Wenn die Antwort „ich wüsste nicht mal, dass sie weg ist“ lautet, verschwendet sie die Ressourcen des Planeten und die Zeit derer, die sie gebaut haben.

Die Verantwortung der Bauenden

Jedes Mal, wenn wir entscheiden, etwas zu bauen, treffen wir eine Entscheidung über reale Ressourcen. Entwickler:innen-Zeit. Server-Energie. Aufmerksamkeit. Komplexität des digitalen Ökosystems. In einer Welt mit endlichen Ressourcen und enormen Problemen ist es nicht neutral, Unnützes zu bauen. Es ist aktive Verschwendung. Falsche Allokation menschlicher Intelligenz.

Bauingenieure müssen begründen, warum eine Brücke nötig ist. Architekt:innen müssen einen Bedarf nachweisen. Ärzt:innen verschreiben kein Medikament, weil es existiert. Warum sollte Software anders sein? Warum akzeptieren wir, dass 90 % dessen, was wir bauen, in einem App Store vergessen liegen, von den eigenen Schöpfer:innen nach sechs Monaten ignoriert wird, mit Nutzerdaten drin und laufenden Servern dazu?

Echte Innovation 2026 ist nicht, mehr zu bauen. Es ist, weniger zu bauen, besser, aus besseren Gründen.

Und ab und zu den Mut zu sagen: „nein, das machen wir nicht.“ Nicht weil wir nicht können. Weil es nicht nötig ist.

Der Luxus der Subtraktion

Es gibt ein Konzept aus der Architektur, das die Software-Welt nie gelernt hat: den Wert leeren Raumes.

Eine gute Architektin füllt nicht jeden Quadratmeter. Leerer Raum ist keine Abwesenheit. Er ist Atem. Möglichkeit. Der Raum, den die Bewohner:innen brauchen, um sich zu bewegen, zu denken, zu leben. Ein Bau, gefüllt bis zum letzten Zentimeter, ist kein Effizienz-Meisterwerk. Er ist ein Gefängnis.

Unsere digitale Landschaft ist ein bis zum letzten Zentimeter gefülltes Gebäude. Jede Stelle besetzt von App, Service, Plattform, Notification. Kein Atem. Kein leerer Raum. Keine Stille.

Und mitten im Lärm geht die wirklich nützliche Software, die echte Probleme löst, verloren. Sie wird unsichtbar. Nicht weil sie schlechter wäre, sondern weil sie unter Tonnen von Software begraben liegt, die es nicht geben sollte.

Subtraktion ist ein kreativer Akt. Nicht zu bauen ist eine Designentscheidung. Und in einer Branche, die zu nichts Nein sagt, vielleicht die seltenste, wertvollste Kompetenz, die uns bleibt.

Die beste Software, die ich je geschrieben habe, ist die, die ich beschlossen habe, nicht zu schreiben.

Dann kommst du nach Hause. Und dein Kind sitzt vor einem Bildschirm. Und dieser Bildschirm tut genau das, was du zu tun verstehst: Aufmerksamkeit fangen, Engagement erzeugen, Verweildauer maximieren.

Nur ist der Nutzer diesmal kein Nutzer. Es ist dein Kind.

Die Dissonanz

Wer in der Tech arbeitet und Kinder hat, lebt eine kognitive Dissonanz, die fast niemand benennt. Tagsüber baust du Systeme, die Menschen halten sollen. Abends versuchst du, dein Kind von identischen Systemen zu lösen. Tagsüber feierst du „User Retention“. Abends erschreckt dich die „Retention“ deines Kindes vor dem Tablet.

Du weißt, wie Pull-to-refresh wirkt. Du hast es implementiert oder zumindest darüber diskutiert. Du weißt, dass es die Hebelgeste der Slot Machine reproduziert. Dass die Verzögerung vor dem Laden keine technische Limit-, sondern ein Design Pattern ist: die berechnete Pause, die die Dopaminausschüttung maximiert. Du weißt es, weil es dein Beruf ist, es zu wissen.

Und du weißt: dein Kind, mit acht, zehn, zwölf Jahren, hat kein Werkzeug, sich gegen das zu wehren, was du zu bauen weißt.

Kein persönlicher Widerspruch. Ein systemischer. Er betrifft jeden in der Tech mit Kindern — Millionen.

Was wir wissen und nicht mehr ignorieren können

Sich die Dinge auflisten hilft, sie ins Auge zu fassen.

Wir wissen, dass variable Verstärkungsschemata, Grundlage sozialer Feeds, der mächtigste je dokumentierte psychische Mechanismus zur Erzeugung und Aufrechterhaltung zwanghaften Verhaltens sind. Seit den 1950ern. Skinner zeigte es an Tauben. Wir wenden es auf Kinder an.

Wir wissen, dass das Gehirn eines Heranwachsenden mitten in der Entwicklung ist. Der präfrontale Cortex — Urteil, Impulskontrolle, Konsequenzbewertung — reift erst um 25 aus. Wir bauen Systeme, die ihn gezielt umgehen, um direkt zum limbischen System zu sprechen. Beruflich.

Wir wissen, dass habitueller Social-Media-Konsum mit messbar verringerter kortikaler Dicke in Regionen für kognitive Kontrolle zusammenhängt. Keine Meinungen. MRT-Daten an tausenden Jugendlichen.

Wir wissen, dass Depressions-, Angst-, Selbstverletzungs- und Suizidraten bei Jugendlichen seit 2010 verdoppelt oder verdreifacht haben — parallel zur Smartphone-Verbreitung im gesamten Westen.

Wir wissen, dass die Plattformen es wissen. Die internen Meta-Dokumente, die Frances Haugen veröffentlicht hat, zeigen: Instagram verschlechterte das Körperbild bei einem von drei Mädchen. Das Unternehmen wusste es. Es machte weiter.

Wir wissen das alles. Und wir bauen weiter.

‚Aber ich arbeite nicht bei Social’

Ich auch nicht. Ich baue ERPs, Plattformen für die öffentliche Hand, B2B-Software. Ich gestalte keine algorithmischen Feeds und optimiere keine Empfehlungssysteme für Jugendliche.

Aber der Punkt ist nicht, was wir heute bauen. Es ist die Kultur, in der wir bauen.

Wir arbeiten in einer Branche, die normalisiert hat, menschliche Aufmerksamkeit als zu extrahierende Ressource zu behandeln. Dass „User Experience“ gleichbedeutend mit „Verweildauer“ sei. Dass Erfolg in Sessions, Klicks, Conversion Rate, Daily Active Users gemessen wird. Wir reden über Menschen mit dem Vokabular des Bergbaus, und finden das nicht seltsam.

Diese Kultur durchzieht uns alle. Auch wer nicht im Social arbeitet, atmet ihre Metriken, Werte, Prioritäten. Wenn wir nach Hause kommen, kommt diese Kultur mit. Sie schleicht sich in den Blick auf den Bildschirm unseres Kindes. Mit Sorge — und mit subtiler, uneingestandener Vertrautheit. Wir erkennen die Mechanismen wieder. Wir wissen, dass sie wirken. Und ein Teil von uns, der berufliche, kann nicht umhin, sie zu bewundern.

Diese Vertrautheit muss durchbrochen werden.

Das Privileg des Bewusstseins

Wer in der Tech arbeitet und Kinder hat, besitzt etwas, was die meisten Eltern nicht haben: das Wissen um die Architektur.

Wir wissen wie diese Systeme funktionieren, nicht nur dass sie funktionieren. Dass Notifications nicht zufällig kommen, sondern auf den Moment maximaler psychischer Verwundbarkeit optimiert sind. Dass Endless Scroll keine Ästhetik ist, sondern Capture-Mechanismus. Dass „der Algorithmus“ keine geheimnisvolle Entität ist: Code, geschrieben von Leuten wie uns, mit klaren Zielen, auf klaren Metriken optimiert.

Dieses Bewusstsein ist enormes Privileg. Privileg schafft Verantwortung. Wenn du das Feuer siehst und andere nicht, kannst du nicht „nicht mein Brand“ sagen.

Und doch tun wir genau das, als Branche. Wir wissen. Und schweigen. Weil reden bedeutete zuzugeben: das Problem ist nicht „da draußen“ — bei den schlechten Gewohnheiten der Kinder, der Inkompetenz der Eltern, dem fehlenden „digitalen Bildungsstand“. Das Problem ist auch drin. In unserer Software-Denkweise. In den Metriken, die wir optimieren. In den Fragen, die wir nicht stellen.

Die Fragen, die wir uns nicht stellen

In zwanzig Jahren Tech habe ich in keinem Projektmeeting jemanden diese Fragen stellen hören:

Kann dieses System Abhängigkeit erzeugen? Wenn ja, sind wir verantwortlich, das zu verhindern?

Bauen wir für das Wohl des Nutzers oder für die Maximierung seiner Nutzungszeit? Sind das dasselbe?

Wenn ein Minderjähriger das Produkt nutzt, ist es sicher? Nicht „regelkonform“. Sicher.

Messen wir Erfolg mit Metriken, die unsere Interessen mit denen der Nutzer ausrichten? Oder mit etwas, das uns bequem messbar ist?

Würden wir dieses System exakt so bauen, wenn wir wüssten, der erste Nutzer ist unser Kind?

Letzte Frage ist die wichtigste. Sie wird nie gestellt.

Der Kindertest

Ich schlage eine Regel vor. Kein Gesetz, kein Framework, kein Prozess. Eine persönliche Regel, für jeden, der Software baut und Kinder hat.

Bevor du ein System implementierst, frag dich: ist es okay, wenn der erste Nutzer mein Kind ist?

Nicht „mein Kind mit zwanzig, erwachsen, geschult“. Mein Kind jetzt. Mit dem Alter, das es hat. Mit dem präfrontalen Cortex, den es hat. Mit der Reizwiderstandsfähigkeit, die es hat. Mit dem blinden Vertrauen in die Technik, das es hat.

Wenn ja, baue. Wenn „kommt drauf an“, halte inne und frag worauf. Wenn nein, hast du ein Problem. Und das Problem ist nicht dein Kind.

Kein sentimentaler Test. Ein Designtest. Das Vorsorgeprinzip, übersetzt in Software-Sprache. Die angewandte Version von Hans Jonas: handle so, dass die Folgen mit dem Fortbestand authentischen menschlichen Lebens vereinbar sind.

Nur dass Jonas von Atombomben und Genmanipulation sprach. Wir sprechen von algorithmischen Feeds und Push-Benachrichtigungen. Dass sie harmlos wirken, ist genau das, was sie gefährlich macht.

Wir sind nicht ohnmächtig

Ich weiß, was du denkst. „Ich bin Angestellter. Freelancer. Tech Lead in einer Zehn-Personen-Firma. Ich bestimme nicht die Politik von Meta.“ Stimmt. Tust du nicht.

Aber du bestimmst, wie du deine Software baust. Welche Metriken du optimierst. Ob du Dark Patterns implementierst oder ablehnst. Ob du einen Nutzungstimer oder Endless Scroll setzt. Ob das System die Aufmerksamkeit des Nutzers respektiert oder sie plündert.

Vor allem: du bestimmst, welche Art Profi du sein willst.

Du kannst der sein, der „der Markt verlangt es“ sagt und alles implementiert, was zahlt. Oder der, der „so baue ich das nicht“ sagt und Alternativen vorschlägt. Kein Idealismus, Handwerk. Eine seriöse Schreinerin nimmt kein verfaultes Holz, weil es billiger ist. Ein seriöser Koch serviert kein verdorbenes Essen, weil die Marge wächst. Ein seriöser Ingenieur unterschreibt kein strukturell unsicheres Projekt, weil der Kunde Eile hat.

Doch in der Software, wo Folgen Millionen treffen können und das Hirn einer Generation, akzeptieren wir Standards, die wir in keinem anderen Beruf akzeptieren würden.

Das Manifest

Ich arbeite in der Tech. Ich habe ein Kind. Ich kann die beiden nicht mehr trennen.

Mein Kind ist kein Nutzer. Keine Metrik, keine Session, kein Daily Active User. Es ist ein Mensch mit sich entwickelndem Hirn, sich aufbauender Urteilsfähigkeit, Vertrauen in die Welt, das auch davon abhängt, wie ich und Leute wie ich diese Welt bauen.

Mein Beruf hat Folgen. Nicht abstrakte, ferne aus Moralphilosophie. Konkrete eines Systems, das 24/7 läuft und mit Millionen Hirnen interagiert. Wenn ich nicht die Verantwortung übernehme, wer dann?

Compliance reicht nicht. DSGVO, AI Act, EAA einzuhalten ist Mindestmaß, kein Ziel. Die Frage ist nicht „ist es legal?“. Die Frage ist „ist es richtig?“. Zwei verschiedene Fragen, und die zweite wiegt mehr.

Geschwindigkeit ist kein Wert. „Ship fast“ ist keine Tugend, wenn das, was du startest, schaden kann. Eile ist die Zuflucht derer, die nicht über Folgen denken wollen. Kritisches Denken ist von Natur aus langsam. Code ist schnell. Weisheit verwechselt die beiden Zeiten nicht.

Technische Bildung reicht nicht. Code schreiben ohne dessen Implikationen lesen zu können ist keine Kompetenz, sondern spezialisierte Blindheit. Wir brauchen Ingenieurinnen, die Jonas gelesen haben, Entwickler, die Mill kennen, Designer, die Entwicklungspsychologie studiert haben. Nicht als Allgemeinbildung. Als Werkzeug.

Mein Kind wird mich richten. Nicht am Umsatz, an gelieferten Projekten, beherrschten Technologien. An der Welt, die ich mitgebaut habe. Und in diesem Urteil zählt „ich habe nur Befehle ausgeführt“ nicht. Es zählte nie.

An die, die bauen

Wenn du in der Tech arbeitest und Kinder hast, weißt du, wovon ich rede. Du weißt, dass es ein Gespräch gibt, das unsere Branche verweigert. Dass das Unbehagen, wenn dein Kind im Bildschirm verschwindet, kein elterlicher Wahn ist. Es ist berufliche Kompetenz, die dir etwas sagt.

Hör hin.

Ich sage nicht, hört auf zu bauen. Ich sage: baut, als wäre der erste Nutzer euer Kind. Denn das könnte er sein.

Und wenn nicht eures, dann das von jemand anderem.

Was am Ende dasselbe ist.

„Wir haben die Welt nicht von unseren Eltern geerbt. Wir haben sie uns von unseren Kindern geliehen.“ — Sprichwort, Antoine de Saint-Exupéry zugeschrieben.

Eines vorweg, weil es der Grund dieses Beitrags ist.

Ich habe ein wissenschaftliches Gymnasium besucht. Ich habe in Urbino Philosophie studiert — eine jener Universitäten, in denen Philosophie kein Beiwerk ist, sondern eine Art, in der Welt zu sein, in der man lernt, dass Fragen mehr zählen als Antworten und „wozu dient das?“ selbst eine philosophische Frage ist. Dann wählte ich die Technik. Zwanzig Jahre Code, Infrastruktur, digitale Produkte. Zwanzig Jahre, in denen man mir, mal wohlwollend, mal sarkastisch, sagte, Philosophie „bringe nichts“. Dass im Tech die Sprachen, Frameworks, Deployments zählen. Dass Kant und Popper hübsche Deko seien.

Ich wusste immer, dass das nicht stimmt. Ich spürte es jedes Mal, wenn ich in einem Projektmeeting eine ethische Implikation erfasste, die andere übersahen. Beim Lesen einer EU-Norm, in der ich nicht nur eine Pflichtenliste, sondern die juristische Übersetzung eines präzisen philosophischen Prinzips erkannte. Beim Diskutieren über Architektur: die wirklich wichtigen Entscheidungen sind nicht technisch, sondern welche Welt die Software mitschaffen soll.

Heute ist dieses Gefühl Gewissheit. Geisteswissenschaftliche Bildung ist kein Anhängsel technischen Denkens. Sie ist sein unverzichtbares ethisches Fundament. Ohne sie ist Technik blind. Mächtig, schnell, effizient — und blind.

Wir leben in einem Moment, in dem die Systeme, die wir bauen, die neurologische Entwicklung einer Generation verändern, Wahlen beeinflussen, über Kredite entscheiden, festlegen können, was Millionen morgen für wahr halten. In diesem Kontext reicht es nicht, einen Kubernetes-Cluster zu konfigurieren. Man muss auch wissen, was Hans Jonas zur Verantwortung für die Zukunft schrieb. Mill zur Grenze zwischen Freiheit und Schaden gelesen haben. Anders’ „prometheisches Gefälle“ kennen — und wiedererkennen, wenn es als Empfehlungsalgorithmus implementiert ist.

Nicht mehr akademisch. Kein Luxus für Lesefreund:innen. Existenziell, im konkreten Sinn. Für uns als Spezies — die Tech-Entscheidungen dieses Jahrzehnts definieren die kognitiven und sozialen Bedingungen unserer Kinder. Und für Geschäfte — wer Tech ohne ethischen Kompass baut, geht nicht nur ein moralisches Risiko ein, sondern ein Marktrisiko. Europa hat das verstanden. AI Act, DSGVO, CRA, PLD: Signale, dass die Zeit der Tech ohne kritisches Denken vorbei ist. Wer das Signal nicht lesen kann, fällt zurück. Nicht zur Strafe — aus Inadäquatheit.

Also: nach zwanzig Jahren Tech kann ich mit reasonable confidence sagen, dass das Philosophie-Studium die wichtigste berufliche Entscheidung meines Lebens war. Mehr als jedes Zertifikat, jede Sprache, jedes Projekt. Weil es mir das Einzige gegeben hat, was Tech nicht geben kann: die Fähigkeit zu fragen, ob das, was du baust, du es bauen solltest.

Das Folgende versucht zu erklären, warum.

Die mächtigste rhetorische Waffe unserer Zeit

Im öffentlichen Diskurs wirkt ein Wort wie ein argumentativer Generalschlüssel. Ein Wort, das Diskussionen schließt statt öffnet, das den, der es ruft, zum Verteidiger der Zivilisation und den, der es hinterfragt, zum Obskurantisten macht. Dieses Wort ist Fortschritt.

„Europa bremst den Fortschritt.“ „Bürokratie tötet Innovation.“ „Regeln fesseln die Zukunft.“ Sätze, die wir täglich hören — Talkshows, X-Threads, Tech-Keynotes, VC-Posts aus der Bay Area. Als Selbstverständlichkeiten präsentiert, verbergen sie eine nie ausgesprochene Prämisse: Fortschritt sei eine natürliche, einseitige, intrinsisch wohltätige Kraft, und jedes Hindernis sei per definitionem ein Schaden für die Menschheit.

Aber stimmt das? Oder verwechseln wir Fortschritt mit etwas viel Banalerem und weniger Edlem?

Was Fortschritt ist und war

Um zu antworten, müssen wir verstehen, woher die Idee Fortschritt kommt. Kein ewiger Begriff, sondern eine geschichtliche Erfindung, nicht so alt.

Die Aufklärung und die Geburt einer Idee

Die Vorstellung, die Geschichte habe eine Richtung und morgen werde besser als heute, ist ein Produkt der europäischen Aufklärung des 18. Jh. Vor Condorcet, Voltaire, Kant war Zeit zyklisch (Griechen, Römer) oder Verfall aus einem verlorenen Goldenen Zeitalter. Die Aufklärung änderte das: systematisch angewandte Vernunft konnte die materiellen, moralischen, politischen Bedingungen der Spezies verbessern.

Condorcet stellte sich in seiner Esquisse (1795) eine Menschheit vor, die durch Bildung, Wissenschaft, Beseitigung von Vorurteilen stufenweise zur Vollkommenheit fortschreitet. Mächtige, oft großzügige Vision — mit einem problematischen Keim: der Idee, Fortschritt sei unvermeidlich, fast Naturgesetz.

Kant, subtiler, unterschied zwischen technischem und moralischem Fortschritt. In Idee zu einer allgemeinen Geschichte in weltbürgerlicher Absicht (1784): Menschheit könne zu einer universellen bürgerlichen Gesellschaft fortschreiten, aber nur durch Konflikt, Mühe — und durch Institutionen, die die „ungesellige Geselligkeit“ kanalisieren. Fortschritt war für Kant nicht automatisch: er verlangte Strukturen, Gesetze, gegenseitige Schranken. Er verlangte Politik.

Der Positivismus und das gründende Missverständnis

Mit Auguste Comte und dem Positivismus des 19. Jh. verschmilzt Fortschritt mit technisch-wissenschaftlichem Fortschritt. Comtes „Drei-Stadien-Gesetz“ (theologisch, metaphysisch, positiv): die Wissenschaft ersetzt jede andere Wissensform und führt die Menschheit in einen rationalen Ordnungszustand.

Hier das Missverständnis, das uns bis heute begleitet: Gleichsetzung von technischem Fortschritt und Verbesserung der menschlichen Verfassung. Ein Missverständnis, das das 20. Jh. hätte zerstören müssen — und das doch, fast unerklärlich, weiter blüht.

Das Jahrhundert, das alles hätte lehren sollen

Das 20. Jh. war das Endlabor für „mehr Technik = mehr Fortschritt“. Das Ergebnis war eindeutig.

Dieselbe Wissenschaft, die Penicillin schuf, schuf Nervengas. Dieselbe Ingenieurskunst, die Brücken baute, baute mit industrieller Effizienz Gaskammern — Fortschritt in den Methoden. Die Kernspaltung gab eine außerordentliche Energiequelle und die Fähigkeit zur Selbstauslöschung.

Günther Anders, in Die Antiquiertheit des Menschen (1956), erfasste diesen Riss atemberaubend luzide. Sein „prometheisches Gefälle“: unsere Fähigkeit zu produzieren übersteigt radikal unsere Fähigkeit, die Folgen zu imaginieren. Wir können eine Bombe bauen, die hunderttausend Menschen tötet, aber wir können nicht fühlen, was das bedeutet. Wir sind, schrieb er, kleiner geworden als unsere Produkte.

Hannah Arendt, am Eichmann-Prozess: das radikalste Übel des 20. Jh. wurde nicht von Monstern begangen, sondern von effizienten Bürokraten. Die „Banalität des Bösen“ ist gewissermaßen organisationaler Fortschritt, angewandt auf Vernichtung. Eichmann hasste die Juden nicht — er optimierte Logistikprozesse. Auf seine Weise ein Innovator.

Der tötende Gedanke: ein Gedankenexperiment

Gehen wir weiter. Ernsthaft.

Stellen wir uns vor, durch Konvergenz von Neurowissenschaft, Nanotechnik und Brain-Computer-Interfaces wird es morgen möglich, einen anderen Menschen mit der bloßen Kraft des Gedankens zu töten. Keine physische Waffe. Kein Mittler. Eine ausreichend fokussierte mentale Absicht — und der andere stirbt.

Wäre das technologischer Fortschritt?

Oberflächlich: ja. Fortschritt im Verständnis des Gehirns, in neuralen Schnittstellen, in Miniaturisierung. Erfüllt alle Kriterien des technischen Fortschritts.

Aber etwas in uns, tief und vorargumentativ, lehnt sich auf. Genau das müssen wir untersuchen — dort verbirgt sich die wahre Natur des Fortschritts.

Hans Jonas’ Ethik der Verantwortung

In Das Prinzip Verantwortung (1979) hat Jonas dieses Dilemma vorweggenommen.

Klassische Ethik setzte unverletzliche Natur und örtlich-zeitlich begrenzte Folgen voraus. Moderne Technik macht beides falsch: wir können das Klima ändern, das Genom modifizieren, jede Schranke zwischen Absicht und Mord aufheben.

Daraus sein technologischer kategorischer Imperativ: „Handle so, dass die Folgen deines Handelns mit dem Fortbestand authentischen menschlichen Lebens auf Erden vereinbar sind.“ Nicht konservativ — Verantwortung gegenüber der Zukunft. Die Frage lautet nicht „können wir’s?“, sondern „welche Welt schaffen wir damit?“.

Beim tötenden Gedanken klar: eine Welt, in der menschliches Zusammenleben — das Fundament jeder Zivilisation — unmöglich wird. Kein sicherer Ort, weil die Bedrohung im Geist liegt. Jede Interaktion vom Terror vergiftet. Nicht das Ende der Technik: das Ende der Gesellschaft.

Mills Filter: Schaden als Grenze der Freiheit

In On Liberty (1859) das „harm principle“: individuelle Freiheit ist heilig, endet aber, wo Schaden für andere beginnt.

Angewandt: die Fähigkeit, mit Gedanken zu töten, ist keine Erweiterung menschlicher Freiheit. Sie ist deren absolute Negation. Wenn jeder jeden ohne Mittel ermorden kann, gibt es keine Freiheit mehr — Freiheit setzt physische Existenzsicherheit voraus.

Mill lehrt uns, was wir uns tätowieren sollten: nicht jede Erweiterung individueller Macht ist Fortschritt. Manche Fähigkeiten, universell verteilt, emanzipieren nicht — sie zerstören. Echter Fortschritt ist Machtwachstum innerhalb der Schranken, die Konvivenz möglich machen.

Popper: die offene Gesellschaft und ihre Feinde (auch technologische)

Karl Popper, Die offene Gesellschaft und ihre Feinde (1945), misstraute zutiefst großen Erzählungen unvermeidlichen Fortschritts. Fortschritt ist ein Prozess von Vermutungen und Widerlegungen: wir versuchen, irren, korrigieren. Korrigieren ist nur möglich, wenn Institutionen es ohne Gewalt erlauben. Die offene Gesellschaft hat Selbstkorrekturmechanismen: Parlamente, Gerichte, freie Presse, änderbare Gesetze.

Wer sagt, Regeln „ketteten den Fortschritt“, sagt — bewusst oder nicht —, dass die Selbstkorrektur Hindernis ist. Aber Hindernis wofür? Wenn der „Fortschritt“ demokratische Prüfung nicht überlebt, ist er vielleicht keiner. Vielleicht nur als Vision verkleidete Eile.

Wer den gefesselten Fortschritt beschwört: eine Taxonomie

Wenn jemand klagt, Staaten oder Supranationale „bremsten den Fortschritt“, lohnt zu fragen: wer spricht, welche Interessen?

Der gutgläubige Techno-Optimist

Es gibt aufrichtige Glaubende, Technik löse alles. Verständlich — sie hat Riesenprobleme gelöst. Gefährlich wird Techno-Optimismus, wenn er zum Techno-Determinismus wird: Technik produziere für sich genommen immer Positives. Die Geschichte sagt das Gegenteil.

Der Unternehmer, der Eigeninteresse mit Allgemeininteresse verwechselt

Wenn ein Silicon-Valley-CEO die EU-AI-Regulierung als „Fortschrittshindernis“ kritisiert — verteidigt er die Menschheitszukunft oder sein Geschäftsmodell? Privates Interesse und Gemeinwohl zu vermischen ist alt — im Tech-Zeitalter besonders raffiniert: gekleidet in Zukunft, Innovation, Vision.

Marc Andreessens Techno-Optimist Manifesto (2023): Märkte als Fortschrittsmechanismus, Regulierung als Bremse, Gegner als „Decelerator“. Klar — und blind: Märkte ohne Regeln produzieren keinen Fortschritt, sondern Machtkonzentration. Adam Smith wusste es in Wohlstand der Nationen.

Der ideologische Libertäre

Für den radikalen Libertären ist jede Regel Zwang, jeder Zwang Übel. Auf seinen Prämissen kohärent — auf falschen Prämissen: Individuen im sozialen Vakuum, ohne Machtasymmetrien, ohne Externalitäten.

Robert Nozicks Anarchy, State, and Utopia (1974) ist die anspruchsvollste Version. Aber selbst Nozick ließ einen „minimalen Staat“ zur Sicherung der Grundrechte zu. Wenn Technik das Klima ändern, das Verhalten Milliarden manipulieren oder die Schranke zwischen Absicht und Mord aufheben kann — reicht der Minimalstaat?

Der antielitäre Populist

Schließlich der populistische Modus: Brüsseler Eliten zwingen Regeln auf, die das „Volk“ nicht wollte. Nutzt legitime demokratische Frustration, ohne glaubhafte Alternativen. Wenn nicht die demokratischen Institutionen — wer setzt Tech-Grenzen? Der Markt? Die Programmierer? Die Aktionäre?

Die Atomwaffe, die längst explodiert ist: Soziale Netze und das Hirn unserer Kinder

Bislang abstrakt. Unnötig. Die Waffe, die ohne Schuss zerstört, existiert bereits. Sie steckt in den Taschen unserer Kinder. Bunte Oberfläche, fröhliche Benachrichtigungen, Geschäftsmodell, das Aufmerksamkeit in verkaufbare Daten verwandelt.

Reden wir über Soziale Netze. Mit der Brutalität, die das Thema verdient.

Der unsichtbare Eisberg

Jonathan Haidt, The Anxious Generation (2024), dokumentiert: nach mehr als einem Jahrzehnt Stabilität stürzte Anfang der 2010er die psychische Gesundheit Jugendlicher ab. Depression, Angst, Selbstverletzung, Suizid stiegen rasant — auf vielen Indikatoren mehr als verdoppelt. Die Kurve fällt mit der Smartphone-Verbreitung zusammen. Nicht Finanzkrise 2008, nicht Terrorismus, nicht Klima. Smartphones.

Was wir sehen, ist nur die Spitze. CDC USA: 2023 berichteten über 40 % der Highschool-Schüler:innen anhaltende Traurigkeit/Hoffnungslosigkeit. 57 % der Mädchen zeigten depressive Symptome. Fast jedes dritte Mädchen hatte Suizid „ernsthaft erwogen“, +60 % in zehn Jahren. UK NHS Mental Health Survey 2025: 25,8 % der 16-24-Jährigen leiden an einer häufigen psychischen Störung (vs. 18,9 % 2014). Junge Frauen: 36,1 %.

Das sind die aufgetauchten Zahlen. Der untergetauchte Eisberg: Jugendliche, die schweigend leiden. 70-80 % der Minderjährigen mit psychischen Störungen erhalten nie Behandlung.

Das Gehirn als Schlachtfeld

Beunruhigender: das Neurologische. Eva Telzers Team (UNC) folgte 169 Mittelschüler:innen drei Jahre per fMRI: Jugendliche, die Soziale Medien gewohnheitsmäßig prüfen, zeigen signifikant andere Entwicklungstrajektorien. Betroffene Areale: Amygdala (Angst, emotionale Reaktivität) und dorsolateraler präfrontaler Cortex (Urteil, Vernunft, Belohnungsbewertung).

Eine Studie (März 2026, NeuroImage) auf 7 000+ Heranwachsenden (ABCD): höherer täglicher Social-Media-Konsum mit reduzierter kortikaler Dicke in vielen Hirnregionen. Nicht „etwas traurig sein“. Strukturelle Veränderungen am sich entwickelnden Gehirn.

Generation Z, geboren nach 1995, war die erste, die in der Pubertät Smartphones hatte. Ihr Gehirn entwickelte sich, während Engagement-maximierende Algorithmen ihre Aufmerksamkeit jederzeit umkämpften. Haidts vier Schäden: soziale Deprivation, Schlafdeprivation, Aufmerksamkeitsfragmentierung, Sucht.

Wiederholtes Konsumieren kurzer Videos aktiviert wiederholt das Belohnungszentrum, führt zu dopaminerger Dysregulation, geringerer anhaltender Aufmerksamkeit, erhöhter Impulsivität, gestörtem Schlaf. Das Gehirn dieser Jugendlichen wird neu konfiguriert in einer Weise, die kognitive Kontrolle untergräbt.

Der Spielautomat in der Tasche

Klar: Soziale Netze wurden nicht zufällig schädlich. Sie wurden so gestaltet.

Die psychischen Mechanismen, die sie zwanghaft machen, sind identisch mit denen der Spielautomaten — „Verstärkung mit variabler Verhältnis-Ratio“, unvorhersehbare, intermittierende Belohnungen. B.F. Skinner hat das in den 1950ern an Tauben dokumentiert: stärkstes Verstärkungsmuster, am resistentesten gegen Löschung.

Jeder Scroll auf TikTok oder Instagram ist ein Hebelziehen am Spielautomaten. Du weißt nicht, welcher Scroll Interessantes bringt. Diese Unsicherheit erzeugt mehr dopaminerge Aktivität als vorhersehbare Belohnung. Das Warten ist die Droge.

Kasinos sind reguliert. Müssen Gewinnwahrscheinlichkeiten offenlegen. Kein Zugang für Minderjährige. Lizenzpflicht. Soziale Plattformen haben nichts davon. Natasha Schüll (Addiction by Design): Soziale Netze nutzen Glücksspielmethoden, weil im Aufmerksamkeitsmarkt Umsatz an verbrachter Zeit hängt.

Pull-to-refresh als Hebelersatz. Rote Notifikationen mit Zeigarnik-Effekt. Snapchat-Streaks gamifizieren Freundschaft. Der TikTok-Algorithmus lernt in Stunden, was dich klebt.

Chamath Palihapitiya, ehem. VP Growth bei Facebook: die kurzfristigen dopaminergen Feedback-Schleifen, die wir gebaut haben, zerstören das Funktionieren der Gesellschaft. Sean Parker, erster Facebook-Präsident: Ziel war „so viel wie möglich von eurer bewussten Aufmerksamkeit zu verbrauchen“, indem man „eine Schwachstelle der menschlichen Psychologie ausnutzt“. Keine externen Vorwürfe — Eingeständnisse.

Interne Forschung bestätigte: die durch Frances Haugen veröffentlichten Dokumente zeigten, dass Instagram wusste, Körperbildprobleme bei einem von drei Mädchen zu verschlimmern. Sie wussten es. Und entschieden sich für den Profit.

Der Unterschied zu klassischen Waffen

Konventionelle Waffen töten den Körper. Schaden sichtbar, sofort, dokumentierbar. Die Welt merkt es. Es gibt Bilder, Zahlen, Gedenkstätten. Verträge.

Soziale Netze operieren in einem anderen Register. Schaden unsichtbar, schleichend, kumulativ, normalisiert. Niemand sieht ein Neuron, das sich rekonfiguriert. Niemand hört einen dünner werdenden präfrontalen Cortex. Niemand erkennt Schlafmangel als Notfall, wenn er gleichzeitig hundert Millionen Heranwachsende betrifft. Der Schaden versteckt sich in der Alltäglichkeit: „nur das Handy“, „alle Jugendlichen sind so“, „wir saßen vorm Fernseher“.

Aber der Fernseher war nicht auf variable Verstärkung ausgelegt. Er folgte dir nicht ins Schlafzimmer um drei Uhr nachts. Er hatte keinen lernenden Algorithmus. Er gab dir keine Echtzeit-Metrik deines sozialen Werts.

Skala. Eine Bombe zerstört eine Stadt. Soziale Netze ändern die Hirnentwicklung einer Generation weltweit. Nicht eine Gruppe, nicht eine Region: jede:r zwischen 3 und 20 mit verbundenem Gerät. Die WHO hat fast 280 000 junge Heranwachsende in 44 Ländern befragt: 11 % zeigten problematische Nutzung.

Eine Bombe explodiert einmal. Soziale Netze laufen 24/7, 365. Kein Waffenstillstand. Kein Friedensvertrag. Chronische, ununterbrochene Exposition, immer früher: Tablets mit 3-4, erstes Smartphone mit 8-9, Social-Tauchen mit 11-12. 64 % der US-Kinder mit 11-12 nutzen schon Soziale Medien.

Die Zerstörung der Familien

Zahlen erfassen einen Aspekt nicht: die Familie.

Eltern in der Schulzeit wissen es. Das Smartphone ist das zentrale häusliche Schlachtfeld. Keine Frage von „Regeln“: strukturell. Das Gerät ist gestaltet, attraktiver zu sein als jede familiäre Interaktion. Eltern, die ein Märchen vorlesen, konkurrieren mit einem Algorithmus, der Milliarden Interaktionen analysiert hat, um genau zu wissen, was dieses Kind fesselt.

Asymmetrischer Krieg, und die Familie verliert ihn. Eltern fühlen sich machtlos, ständig hinter einer Technik, die schneller voranschreitet als ihr Verstehen. Kinder fühlen sich kontrolliert, missverstanden, von Gleichaltrigen isoliert ohne Zugang. Resultat: tägliche Erosion von Vertrauen, Dialog, Verbindung. Genau das, was eine Familie ausmacht.

Anders’ prometheisches Gefälle: Eltern heute sind die erste Generation, die ihre Kinder vor einer Bedrohung schützen muss, die sie nicht sehen oder voll verstehen können. Anders als Verkehr oder Alkohol — sichtbare Bedrohungen, bekannte Dynamiken. Hier eine unsichtbare Architektur algorithmischer Überredung, die direkt auf neurologische Belohnungsschaltkreise wirkt. Wie 1945 Eltern verlangen, ihre Kinder vor Strahlung zu schützen, ohne Strahlung zu kennen.

Die Welt reagiert, langsam

US-Surgeon-General Vivek Murthy verglich Social-Media-Sucht mit Tabaksucht und forderte einen Sicherheitshinweis. 2023: über drei Stunden Social Media täglich verdoppeln das Risiko psychischer Probleme bei Kindern.

Australien, Dezember 2025, erstes Land mit Social-Media-Verbot für Minderjährige unter 16, Strafen bis 49,5 Mio. AUD. Über 4,7 Mio. Konten bisher deaktiviert.

Frankreich, Norwegen, Dänemark, Malaysia, Spanien, Indonesien und Italien selbst erwägen Ähnliches. Globale Bewegung mit Widerstand genau dort, wo zu erwarten: bei den Plattformen (Reddit klagt vor dem australischen High Court) und libertären Gruppen, die die Meinungsfreiheit Minderjähriger anrufen.

Dieselbe Dynamik wie bei Tabak, Asbest, Bleibenzin: die schädigende Industrie bekämpft Regeln im Namen individueller Freiheit und Fortschritts, während sich der Schaden leise akkumuliert.

Die Frage, die wir uns stellen müssen

Wenn Fortschritt die Erweiterung der kollektiven Fähigkeit ist, frei, würdig und nachhaltig zu leben — sind die Sozialen Netze in ihrer aktuellen Form Fortschritt?

Nein. Nicht weil digitale Konnektivität intrinsisch böse wäre, sondern weil ihre Implementierung — Engagement-Algorithmen, die neurologische Schwächen ausbeuten, abhängigkeitsbasierte Geschäftsmodelle, fehlende Verantwortung für Schäden — die Antithese des Fortschritts ist. Es ist die Verwendung modernster Neurowissenschaft, um menschliche Fähigkeit zu verringern, nicht zu erweitern.

Wäre der Schaden sichtbar, machte jede Verdünnung des präfrontalen Cortex ein Geräusch, wäre jede selbstverletzende Handlung eine sichtbare Explosion — wir hätten reagiert wie auf eine Bombe. Doch der Schaden ist still. Und die Stille ist der beste Verbündete derer, die ihn verursachen und monetarisieren.

Das Gedankenexperiment vom tötenden Gedanken ist gar nicht so hypothetisch. Wir haben Firmen die Macht überlassen, die Hirnentwicklung von Milliarden Jugendlicher zu verändern. Dass sie das tun, um Werbung zu verkaufen, statt aus Bösartigkeit, macht den Schaden nicht weniger real. Nur schwerer zu benennen.

Europa und die humanistische Wahl

Hier müssen wir über Europa sprechen. Nicht das Klage-Europa, mit dreifachen Formularen und Gurkenverordnungen. Europa als philosophisches Projekt.

Der EU-Regulierungsrahmen als Zivilisationswahl

Die EU hat in den letzten Jahren ein Tech-Normwerk produziert, das weltweit kein Pendant hat: DSGVO, DSA, DMA, AI Act, CRA, aktualisierte PLD für Software und KI.

Aus Sicht des Silicon Valley: „Bürokratie, die Innovation bremst.“ Aus moralphilosophischer Sicht: der ehrgeizigste Versuch, europäischen Humanismus auf die technologische Revolution anzuwenden.

Beispiel AI Act. Risikobasierte Struktur, Verbote für gefährlichste Anwendungen (Social Scoring, unterschwellige Manipulation, biometrische Massenüberwachung), wachsende Anforderungen für Hochrisiko. Legislative Übersetzung des Jonas-Prinzips. Nicht „nicht innovieren“: „innoviert, aber nicht auf Kosten der Menschenwürde“. Keine Bremse: ein Steuer.

PLD für Software erweitert: erstmals haftet, wer Software produziert, für Schäden — wie Auto-, Pharma-, Geräteherstellung. Für jene, die Software für ätherisch hielten, ein Skandal. Für jene, die Macht mit Verantwortung verknüpfen, ein Zivilisationsschritt.

DSA und DMA antworten direkt auf die neurologische Katastrophe. DSA: Transparenzpflichten für Empfehlungsalgorithmen, Verbot der Profilierung Minderjähriger zu Werbezwecken, Möglichkeit, personalisierte Empfehlungen zu deaktivieren. DMA: Brechen der Monopolmacht der „Gatekeeper“. Unvollkommen? Sicher. Aber die einzigen Werkzeuge, mit denen eine Demokratie auf eine Macht reagieren kann, die ohne Zügel die Gehirne ihrer jüngsten Bürger:innen umverdrahtet.

Barrierefreiheit als Paradigma echten Fortschritts

Der EAA verdient Erwähnung. Ist eine Innovation, die einen Teil der Menschheit ausschließt, wirklich Fortschritt?

Wenn Fortschritt die Erweiterung menschlicher Möglichkeiten ist (nicht einiger Menschen, sondern der Menschheit), ist Barrierefreiheit kein Hemmnis. Sie ist der Fortschritt. Ein digitales Produkt, das 15 % der Weltbevölkerung nicht nutzen kann, ist nicht innovativ — es ist unvollständig.

Martha Nussbaum (mit Amartya Sen), capabilities approach: Fortschritt misst sich nicht am BIP, an Patenten oder Prozessortakt, sondern an der effektiven Fähigkeit, ein lebenswertes Leben zu führen. Steigert eine Technik diese Fähigkeit für alle, ist sie Fortschritt. Steigert sie sie für einige auf Kosten anderer, ist sie Macht. Kein Fortschritt.

Die Verwechslung von Geschwindigkeit und Richtung

Eine Kategorienverwirrung durchzieht den Diskurs: Geschwindigkeit und Richtung.

„Move fast and break things“, Facebook-Ursprungsmotto, ist ihr Sinnbild. Schnell zu sein hat nur Wert, wenn die Richtung stimmt. Sonst läuft man bloß effizienter ins Verderben.

Wenn Sam Altman sagt, „Regulierung droht KI zu verlangsamen“, fragt niemand: zu was hin verlangsamen? Wenn die Richtung Machtkonzentration, Bias-Verstärkung, Überwachung als Personalisierung lautet — dann ist Verlangsamen kein Schaden. Es ist Klugheit.

Epikur, der materialistischste Antike, lehrte: Lebensziel ist Ataraxia, Seelenruhe. Nicht Machtanhäufung, nicht Naturbeherrschung, nicht Geschwindigkeit. Die Tech-Zivilisation scheint das vergessen zu haben: nicht alles Mögliche ist wünschenswert.

Simone de Beauvoir, Pyrrhus et Cinéas / Pour une morale de l’ambiguïté (1947): Freiheit ist nie absolut, sie ist situiert. Wir sind frei nur im Verhältnis zu anderen Freien. Meine Freiheit hat nur Sinn, wenn ich die anderer wahre. Übertragen: meine Freiheit zu innovieren hat nur Sinn, wenn sie nicht Freiheit, Sicherheit, Würde, Autonomie der Betroffenen zerstört.

Fortschritt als kollektives Bauwerk

Alternative Definition: Fortschritt ist die Erweiterung der kollektiven menschlichen Fähigkeit, frei, würdig und nachhaltig zu leben.

Jedes Wort zählt. Erweiterung — keine Ersetzung. Menschliche Fähigkeit — nicht Maschinen oder Märkte. Kollektiv — sonst Privileg, kein Fortschritt. Frei (im Mill’schen Sinn). Würdig (im Kant’schen Sinn: Person als Zweck, nicht Mittel). Nachhaltig — opfert Zukunft nicht für Gegenwart.

Mit dieser Definition vieles anders. Penicillin: Fortschritt. Allgemeines Wahlrecht: Fortschritt. Trinkwasser für alle, digitale Barrierefreiheit, DSGVO: Fortschritt.

Atombombe nicht. Massenüberwachung nicht. Ein Algorithmus, der Engagement durch Sucht maximiert, nicht. Eine Plattform, die den präfrontalen Cortex von Millionen Jugendlicher dünner macht, um Werbung zu verkaufen, nicht. Und der tötende Gedanke nicht. Es ist das Ende des Fortschritts. Das Ende von allem.

Humanismus als Kompass, nicht als Kette

Wenn jemand sagt, Staat oder EU oder UN „ketteten den Fortschritt“, was sagt er wirklich?

Er sagt fast immer: seine Innovationsweise, sein Geschäftsmodell, seine Zukunftsvision werde gefesselt. Er verwechselt seine Handlungsfreiheit mit der Freiheit der Menschheit. Er hält die Abwesenheit von Schranken für Abwesenheit von Unterdrückung.

Doch Schrankenlosigkeit ist keine Freiheit: es ist das Recht des Stärkeren. Hobbes’ Naturzustand, bellum omnium contra omnes, in dem das Leben „einsam, arm, hässlich, brutal und kurz“ ist. Institutionen, Gesetze, gegenseitige Schranken sind keine Ketten — sie sind das Fundament der Konvivenz.

Echter Humanismus, von Pico della Mirandola bis Nussbaum über Montaigne, Hume, Voltaire, Mill, Arendt, de Beauvoir, war nie gegen Wissen oder Technik. Er war gegen den Gebrauch von Wissen und Technik gegen den Menschen. Humanismus ist der Kompass, der echten Fortschritt von bloßer Machtakkumulation trennt.

Wer heute Tech baut, trägt eine immense Verantwortung. Nicht weil Technik schlecht wäre, sondern weil sie mächtig ist. Macht ohne Verantwortung, ohne Grenzen, ohne Selbstkorrektur ist kein Fortschritt.

Es ist nur Gefahr, die schnell unterwegs ist.

Postscriptum: eine persönliche Notiz

Ich arbeite seit zwanzig Jahren in der Technik. Ich baue Software. Ich verwalte Infrastruktur. Ich konfiguriere CI/CD-Pipelines, schreibe Spezifikationen, plane Sprints. Technik ist mein Beruf und in vielem meine Leidenschaft.

Genau weil ich sie intim kenne — ihre Wunder und ihre Misere, ihre Macht und Fragilität —, weise ich mit aller Faser zurück, sie zu regulieren sei feindselig. Wenn ich DSGVO in einem Projekt umsetze, „bremse“ ich keine Innovation: ich schütze die Menschen, für die das Projekt existiert. Wenn der AI Act mich Risikodokumentation verlangt, „verschwende“ ich keine Zeit: ich nehme meine Arbeit ernst. Wenn der EAA mich barrierefreie Oberflächen baut, „füge ich keine Kosten hinzu“: ich schließe Menschen ein, die ich sonst ausschließen würde.

Aber es gibt einen anderen, persönlicheren und dringenderen Grund, warum mich das Thema brennt. Ich bin auch Vater. Und als Vater erlebe ich täglich, dass die digitale Welt, in der mein Kind aufwachsen wird, von Menschen entworfen wurde, die meinen Beruf ausüben — Menschen, die genau wissen, was sie den Belohnungsschaltkreisen eines sich entwickelnden Gehirns antun. Ich kenne die Design Patterns, die Metriken, die Sprache der „Retention“- und „Engagement“-Strategien. Ich weiß, dass hinter neutralen Wörtern absichtlich gestaltete Suchtmechanismen stehen. Und ich weiß, dass meine technische Kompetenz nicht ausreicht, ein Kind vor einer Industrie zu schützen, die Milliarden investiert, um dessen Aufmerksamkeit zu fangen.

Deshalb glaube ich, Regulierung ist nicht nur legitim — sie ist ein Akt der Zivilisation. Wer Tech baut, hat die moralische Pflicht, sie für Menschen zu bauen, nicht gegen sie. Und wenn er das nicht tut, ist es richtig und notwendig, dass die Gesellschaft durch ihre unvollkommenen, langsamen, anstrengenden Institutionen eingreift.

Echter Fortschritt war nie schnell. Er war mühsam, konfliktreich, voller Korrekturen. Er war, mit Popper, ein Prozess von Vermutungen und Widerlegungen, kein Triumphmarsch. Die Institutionen, die ihn lenken — unvollkommen, langsam, manchmal anstrengend —, sind der Preis dafür, dass wir das Schicksal der Menschheit nicht den Schnellsten überlassen.

Es ist kein hoher Preis. Es ist ein guter Tausch.

„Der Grad der Zivilisation einer Gesellschaft misst sich an der Macht, auf die sie zu verzichten bereit ist.“ — frei nach Norbert Elias, Über den Prozeß der Zivilisation (1939).

Keine Motivationserzählung. Eher eine Notizbuch-Anatomie. Im Rückblick stelle ich fest, dass mir jede Phase eine andere Linse hinterlassen hat. Heute, als Head of Tech und Partner in einem kleinen ICT-Haus, beginnen sich diese Linsen wirklich zu überlagern.

Das Seltsame nichtlinearer Karrieren

Lineare Karrieren gab es vielleicht nie wirklich, eine Weile haben wir’s geglaubt. Ich jedenfalls. Dann landete ich vom Interface Developer in einer der größten europäischen Luxus-E-Commerce-Gruppen (vor dem Eintritt in die Richemont-Sphäre) als CTO in einer Deep-Tech-Startup für Oil & Gas, bis hin zur Steuerung eines vielfältigen Projekt-Portfolios in einem Unternehmen mit rund zehn Personen.

Was diese Stationen verbindet, ist nicht die Technologie. Sie wechselt — schneller, als wir zugeben mögen. Der rote Faden liegt anderswo: jede Rolle ließ mich sehen, wie IT-Services gekauft und verkauft werden. Und vor allem, warum scheinbar technische Entscheidungen es selten sind.

Phase 1: in einem großen Player, von der Code-Seite

Wenn du in einer Großorganisation bist und nicht im Management, kannst du glauben, gewisse Dynamiken gingen dich nichts an. Tatsächlich durchziehen sie dich trotzdem — du erlebst sie nur reflektiert. Ich war im Code, aber in einem Konzern dieser Größe siehst du Dinge, die von außen unsichtbar bleiben.

Etwa, wie man die Beziehung zu Tech-Lieferanten wirklich managt. Nicht in der Theorie, nicht im Deck, sondern im Alltag. Ich sah, dass hinter einer Architekturentscheidung oft eine organisatorische, eine budgetäre, manchmal eine Machtfrage steckt. Und einen Unterschied, der mich anfangs störte und der einfach real ist: ein wegen Kompetenz gewählter Vendor und ein aus vertraglicher Trägheit gewählter Vendor sind nicht dasselbe — auf dem Papier wirken sie identisch.

Die erste Regel, die mir aus dieser Phase blieb — vielleicht etwas zynisch, aber wahr:

Der beste Lieferant ist nicht der mit der besten Proposition, sondern der, der die Organisation des Kunden versteht.

Schwer in ein Framework zu pressen. Qualitativ, kontextuell. Erfordert ein Verständnis interner Dynamiken, das oft nur durch Anwesenheit erworben wird. Ich frage mich noch heute, wie viele Ausschreibungen scheitern, nicht weil der Anbieter unfähig wäre, sondern weil er das „Nervensystem“ des Kunden nicht gelesen hat.

Phase 2: die Startup, also der echte Preis von Entscheidungen

Der Sprung in die Startup hat mich ohne Übertreibung am stärksten verändert. Als CTO einer Deep-Tech-Startup vertikal in Oil & Gas tat ich alles. Stack, Hiring, Prozesse, Budget, Kunden, Delivery. Alles zugleich, oft am selben Tag.

Und dort lernst du, was im Konzern verwaschen bleibt: der Preis von Entscheidungen ist nicht abstrakt. Er ist sofort. Jede Wahl hat unmittelbare Wirkung auf G&V, Time-to-Market, Tragfähigkeit des Teams.

Ich lernte, IT-Services nicht „nach Markt“ zu bepreisen, sondern nach realer Kostenstruktur. Klingt banal — bis du dagegen prallst. Ich lernte: ein zu niedrig bepreister Service ist gefährlicher als ein zu teurer, denn früher oder später zahlt jemand die Differenz. Meist der Kunde — in technischer Schuld, Verzug, Fluktuation, hektischen Patches.

Wichtig waren auch die Verträge. Nicht jene, die einen Verhandlungs-Sieg sichern, sondern jene, die Arbeit erlauben. Ich verstand: es gibt Verträge, die „schützen“, und Verträge, die „funktionieren“. Erstere sind voller Strafen, die niemand anwenden will. Zweitere definieren ausgerichtete Anreize — eine Kooperationszone, in der beide Seiten ein Interesse am Richtigen haben.

Die zweite Regel wurde fast zur Überzeugung:

Die Qualität eines IT-Service entscheidet sich vor Projektstart — in Architekturentscheidungen und in den Prozessen, die der Anbieter aufzieht.

Sobald der Code fließt, sind viele Spiele schon gespielt. Nicht alle. Aber viele.

Phase 3: das Multi-Kunden-Portfolio, wo Grenzen verschwimmen

Heute arbeite ich in einem kleinen ICT-Haus, etwa zehn Personen, als B2B-Tech-Partner. Kundschaft von Großkonzernen bis öffentlichen Verwaltungen. Meine Rolle ist eine Dauerkreuzung aus technischer Führung, Sprint-Planung, DevOps, Compliance und Architektur. Vor allem ist es Portfolio-Arbeit, also viele unterschiedliche Kontexte parallel.

Im selben Zeitraum können wir an einem regionalen Gesundheits-Informationssystem, einer SaaS-People-Analytics-Plattform, einer industriellen IoT-Infrastruktur, an Cybersecurity-Services als zertifizierter Partner eines führenden Vendors, an Compliance-Projekten und an Custom-Entwicklung für die öffentliche Hand arbeiten.

Hier greifen die zwei vorherigen Phasen ineinander. Einerseits das Konzern-Gedächtnis: ich verstehe, wie Enterprise-Kunden denken, was sie wirklich umtreibt, welche impliziten Zwänge wirken. Andererseits die Startup-Sensibilität: ich weiß, was Effizienz mit knappen Ressourcen heißt — und wie sehr Automatisierung und operative Disziplin zählen.

Aber die neue, unerwartete Lektion ist anders.

Der Markt der IT-Services ist auf eine Weise fragmentiert, die viele Advisory-Frameworks nicht erfassen.

Wir sind kein generalistischer System Integrator, aber auch keine Hyper-Spezial-Boutique. Wir sind dieses unbequem zu etikettierende Ding: ein agiler Tech-Partner mit Querschnittskompetenzen. In manchen Kontexten konkurrieren wir mit zehnmal größeren Playern — nicht weil wir absolut „besser“ wären, sondern weil unsere Prozesse schlanker sind und, zunehmend, weil AI-assistierte Entwicklung das Verhältnis zwischen Produktionskapazität und Teamgröße verändert.

Vielleicht wurde mir hier klar, wie sehr Karte und Gelände auseinanderfallen. In Quadranten und Reports sind manche Kategorien klar. Im realen Leben viel weniger.

Was diese Phasen mich übers IT-Sourcing gelehrt haben

Wenn ich das in praktische Implikationen übersetze, fallen mir drei Punkte ein — drei wiederkehrende „Defekte“ in der Anbieterbewertung.

Erstens, aus dem Konzern: Sourcing-Entscheidungen sind oft organisatorische Entscheidungen, getarnt als technische. Wer Advisory macht, sollte die internen Dynamiken des Kunden so gut verstehen wie die Capabilities des Anbieters. Sonst empfiehlt er den „Besten auf dem Papier“ und bekommt den Schlechtesten in der Praxis.

Zweitens, aus der Startup: die Ökonomie der IT-Services ist viel feiner als in Marktreports. Die Marge eines Anbieters auf einem Projekt kann je nach Architektur, Automatisierung, Prozessreife stark schwanken. Ohne diese Dynamik zu lesen, schützt man den Kunden nicht wirklich. Nur formal.

Drittens, aus dem Portfolio: der reale Markt ist diverser, als Frameworks suggerieren. Tech-KMU, die das europäische Wirtschaftsgewebe bedienen, tauchen oft in keinem Quadranten auf — liefern aber einen erheblichen Teil der IT-Services. Wer dieses Segment nicht kennt, gibt dem Kunden eine unvollständige Optionsmenge. Vielleicht ohne es zu merken.

Der kumulative Wert, und warum er jetzt zählt

Es gibt ein Muster bei Karrieren, die „unkonventionellen“ Wert produzieren. Nicht die einzelne Erfahrung macht den Unterschied, sondern die Schnittmenge.

Eine Analystin, die nur Consulting gemacht hat, kennt Frameworks, hat aber Delivery in Krisen vielleicht nie erlebt. Ein Techniker, der nur Dev gemacht hat, kennt den Code, aber nicht immer das Business. Eine Managerin, die nur Konzern gemacht hat, kennt Politik, verliert aber oft den Bezug zu echten Kosten und operativer Mühe.

Der Sinn meiner Bahn, falls einer existiert, ist das Durchqueren dieser Welten. Diese Verbindungsfähigkeit ist heute kein „Plus“ mehr. Mit KI in den Prozessen, härter werdender EU-Compliance, sich wandelnden Pricing-Modellen, Reshoring und neuen Erwartungen an Sicherheit und Datensouveränität — Komplexität nimmt zu, nicht ab.

Und wenn Komplexität zunimmt, werden einfache Antworten verdächtig.

Der nächste Schritt, mit etwas Ehrlichkeit

In letzter Zeit habe ich das Gefühl, die natürliche Evolution dieses Wegs sei, diese integrierte Perspektive zu jenen zu bringen, die Sourcing-Entscheidungen mit hoher Tragweite treffen.

Nicht als operativer Berater — das mache ich schon. Eher als Marktanalyst, Researcher, strategischer Advisor. In einem Kontext, in dem operative Tiefe und das Erzeugen handlungsleitender Insights den Kern des Wertangebots bilden.

Eine Rolle, die manche Firmen mit viel Mühe und Investitionen versuchen, gut zu verkörpern.

Nicht weil ich die richtigen Antworten hätte. Bei vielem habe ich, ehrlich, nicht einmal eine eindeutige Antwort. Aber ich glaube, die richtigen Fragen zu haben — die, die aus dem Sehen des IT-Service-Marktes aus mehreren Winkeln stammen. Vielleicht ist genau das, was heute am meisten fehlt.

Nächster in der Reihe: wie die EU-Regulierungswelle die Bewertungskriterien für IT-Anbieter neu definiert — und warum der Advisory-Markt noch nicht bereit ist.

Keine Kritik. Eine strukturelle Beobachtung. Mit realen Folgen dafür, wie Sourcing-Entscheidungen getroffen werden — und wie viele davon sich als falsch erweisen.

Das Handwerk von innen

Ich habe über fünfzehn Jahre auf der anderen Seite des Tisches verbracht. Nicht als Bewerter von IT-Services, sondern als jemand, der sie entwirft, verkauft, liefert und einsteht, wenn etwas nicht funktioniert.

Bei YNAP (Yoox für die Älteren) habe ich gesehen, wie eine der größten europäischen E-Commerce-Plattformen die Beziehung zu ihren Tech-Lieferanten managte. Nicht in Theorie: in der Praxis architektonischer Entscheidungen, der Verhandlung über Lieferungen, der Entscheidungen, die bestimmen, ob ein Projekt Wert oder bloß Code liefert.

Als CTO von Anthis habe ich die technische Infrastruktur und die Lieferprozesse einer Firma von Grund auf gebaut. Diese Erfahrung lehrt: der Unterschied zwischen einem funktionierenden und einem nicht funktionierenden IT-Service liegt fast nie in der gewählten Technologie, sondern in der Qualität des Entscheidungsprozesses, der zu dieser Technologie führt.

Heute leite ich als Head of Tech & Partner von Oltrematica (ja, diese Rolle existiert formal nicht, dazu kommen wir noch) ein Projektportfolio für Kunden von TIM bis Randstad, von der Region Abruzzen bis zu den Handelskammern. Ich schreibe RFPs und antworte auf RFPs. Ich definiere SLAs und muss sie einhalten. Ich preise Managed Services und weiß genau, was jeder Bestandteil der Lieferkette kostet.

Diese Erfahrung gibt Zugang zu einer Wissensart, die von außen schwer — vielleicht unmöglich — zu erwerben ist.

Was man nur von innen sieht

Wenn ich Bewertungsframeworks für IT-Anbieter lese (Magic Quadrant, PEAK Matrix, ISG Provider Lens), erkenne ich Analysequalität und methodische Strenge. Aber ich sehe auch die blinden Flecken. Und es sind immer dieselben.

Die echten Kosten eines IT-Service stehen nicht im Preis

Der in einem Managed-Services-Angebot genannte Preis ist eine Zahl. Die echten Kosten sind ein komplexes System: der Preis plus die Kosten kommunikativer Ineffizienz plus die Kosten technischer Schulden, die anfallen, wenn der Anbieter Ecken kürzt, um im Budget zu bleiben, plus Opportunitätskosten der nicht gelieferten Funktionen, weil sie nicht im Vertrag stehen.

Ein Analyst, der Anbieter über Tagessätze vergleicht, misst die falsche Variable. Ein Anbieter mit 400 €/Tag, der in 20 Tagen liefert, kostet weniger als einer mit 300 €/Tag und 40 Tagen. Aber zu wissen, welcher in 20 und welcher in 40 liefert, verlangt, die vorgeschlagene Architektur, die Teamzusammensetzung, den Automatisierungsgrad der Lieferprozesse lesen zu können.

Das ist eine Kompetenz, die aus dem Bauen dieser Prozesse kommt, nicht aus dem Beobachten.

SLAs sind eine Sprache, kein bloßer Vertrag

Erfahrungsgemäß entstehen die meisten Probleme in IT-Outsourcing-Verträgen nicht aus falschen SLAs. Sie entstehen aus mehrdeutigen SLAs.

Ein SLA, der „Verfügbarkeit 99,9 %“ sagt, ist technisch präzise und operativ leer, wenn er nicht festlegt: wie wird Verfügbarkeit gemessen? Ist geplante Wartung enthalten? In welchem Zeitfenster wird gerechnet? Was passiert, wenn der Ausfall durch einen Dritten verursacht wird (Cloud, CDN, DNS)?

Ich habe jahrelang SLAs geschrieben. Gelernt: ein guter SLA verspricht nicht mehr, er definiert chirurgisch genau, was passiert, wenn es schiefgeht. Denn in IT-Services geht es früher oder später schief. Die Anbietergüte misst sich in der Reaktion, nicht im Versprechen.

Die Teamzusammensetzung wiegt mehr als die Teamgröße

Bewertungsframeworks belohnen tendenziell Anbieter mit großen Teams und mehreren Delivery Centers. Eine beruhigende Metrik für Käufer: mehr Personen = mehr Kapazität. Doch wer Entwicklungsteams geführt hat, weiß: das stimmt nicht.

Ein Team aus 5 gut koordinierten Senioren liefert mehr Qualität als ein Team aus 15 Personen mit drei Management-Schichten und ständigem Rotieren. Vor allem, wenn diese 5 KI-native Methoden nutzen, die individuelle Produktivität multiplizieren.

Bei Oltrematica führen wir gleichzeitig 8–10 aktive Projekte mit etwa 10 Personen. Nicht weil wir Helden sind, sondern weil wir in Automatisierung, effiziente Lieferprozesse, Werkzeuge investiert haben, die Niedrigwert-Arbeit eliminieren. Diese Effizienz erscheint in keinem Quadranten.

Der Wert der operativen Perspektive im Advisory

Ich behaupte nicht, alle Analysten müssten als IT-Anbieter gearbeitet haben. Ich behaupte, dass die operative Perspektive ein strategisches Asset des Advisory ist — heute dramatisch unterrepräsentiert.

Wenn ein CISO mich fragt, ob ein Managed-Security-Anbieter zuverlässig ist, kann ich mich nicht nur auf Zertifizierungen und Referenzen stützen. Ich kann die vorgeschlagene Architektur lesen und erkennen, ob sie für den Betrieb entworfen wurde oder bloß fürs Gewinnen der Ausschreibung. Ich kann den Statement of Work durchgehen und Grauzonen identifizieren, die in 18 Monaten zu Streitfällen werden. Ich kann beurteilen, ob das Staffing-Modell tragfähig ist oder ob ein Team versprochen wird, das es noch nicht gibt und das nachträglich aufgebaut werden müsste.

Diese Art Einblick kommt nicht aus analytischer Strenge. Sie kommt aus dem Erleben derselben Dynamiken auf der anderen Seite. Sie hat enormen Wert für Enterprise-Kunden, die Sourcing-Entscheidungen über Millionen treffen.

Die nötige Konvergenz

Der IT-Services-Advisory-Markt tritt in eine Phase exponentiell steigender Sourcing-Komplexität ein. KI, EU-Compliance, Reshoring, neue Pricing-Modelle, Cybersecurity by Design: lauter Dimensionen, die für eine korrekte Bewertung tiefes technisches Verständnis verlangen.

Generische Frameworks reichen nicht mehr. Kunden verlangen — und haben das Recht darauf — Advisor, die die Sprache der Anbieter ebenso fließend sprechen wie die des Business.

Eine Konvergenz, die der Markt noch nicht systematisch erzeugt hat. Aber sie ist unvermeidlich. Wer sie vorwegnimmt, hat einen enormen Wettbewerbsvorteil.

Dieser Beitrag ist der erste einer Reihe zu meiner Sicht auf den IT-Services-Sourcing-Markt. Im nächsten Stück erkunde ich meinen persönlichen Werdegang — vom Entwickler zum Partner — und wie jede Phase zu einer integrierten Perspektive auf den Markt der IT-Dienstleistungen beigetragen hat.

Astral ist die Firma hinter uv, Ruff und ty — drei Werkzeugen, die in wenigen Jahren zur täglichen Infrastruktur von Millionen Python-Entwicklern wurden. uv hat das Problem der Umgebungs- und Dependency-Verwaltung mit einer Eleganz und Geschwindigkeit gelöst, die pip nie hatte. Ruff hat Linting und Formatting so schnell gemacht, dass sie unsichtbar wurden, und ty tut dasselbe für Type Checking. Werkzeuge in Rust geschrieben, alle Open Source, alle mit permissiver Lizenz. Und seit gestern alle im Besitz von OpenAI, das sie in das Codex-Team integriert — den Coding-Agenten, der bereits zwei Millionen wöchentlich aktive Nutzer überschritten hat.

Vor drei Monaten, im Dezember, hatte Anthropic einen ähnlichen Schritt gemacht und Bun gekauft, die JavaScript-Runtime von Jarred Sumner. Claude Code, ihr agentisches Coding-Tool, das in sechs Monaten eine Milliarde Dollar annualisierten Umsatz erreicht hat, läuft als Bun-Executable. Sumner sagte es in seinem Ankündigungspost mit fast brutaler Klarheit: „If Bun breaks, Claude Code breaks.“ Anthropic hat also die Infrastruktur gekauft, auf der sein Milliarden-Produkt steht.

Zwei Akquisitionen in drei Monaten von den beiden Firmen, die sich den Markt der KI-gestützten Coding-Tools teilen. Einzeln betrachtet hat jede ihre Logik. Zusammen ist das Muster eindeutig.

Das Muster: die Bauer von Sprachmodellen kaufen Stück für Stück die Toolchain, auf der diese Modelle operieren. Nicht Cloud, nicht Chips, nicht Rechenzentren. Die Werkzeuge zwischen Modell und Code. Den Package Manager. Den Linter. Die Runtime. Den Type Checker. Alles, was ein KI-Agent braucht, um nicht nur Code zu erzeugen, sondern ihn auszuführen, zu testen, zu validieren und in Produktion zu setzen.

Das ist keine Open-Source-Philanthropie. Es ist Infrastrukturstrategie.

Fünfundneunzig Prozent sind Kontext

Um zu verstehen, was passiert, hilft eine oft unterschätzte Tatsache: Sprachmodelle erzeugen für sich genommen Code. Aber Code zu erzeugen ist nicht Software zu entwickeln. Das weiß, wer einem Agenten ein ganzes Projekt schreiben ließ und sich mit etwas wiederfand, das kompiliert, aber nicht funktioniert, oder funktioniert, aber Repo-Konventionen verletzt, oder die Konventionen einhält, aber drei unvorhergesehene Tests bricht. Die Generierung sind 5 % der Arbeit. Die übrigen 95 % sind Kontext: Abhängigkeiten auflösen, Linter passieren, Typen handhaben, Tests laufen lassen, in den CI/CD-Flow integrieren, Code im Lauf der Zeit pflegen, wenn Bibliotheken sich aktualisieren und Anforderungen sich ändern.

Hier ist der Punkt. Ein KI-Agent, der diese 95 % machen will, muss die Werkzeuge besitzen — oder zumindest steuern —, aus denen sie bestehen. Es reicht nicht zu wissen, dass uv existiert. uv muss auf die Bedürfnisse des Agenten reagieren, für seine Workflows optimiert sein, sich in die Richtung entwickeln, die den Agenten effektiver macht. Dasselbe gilt für Ruff, ty, Bun. Wenn OpenAI in seiner Ankündigung schreibt, das Ziel sei „move beyond AI that simply generates code and toward systems that can participate in the entire development workflow“, ist das kein Marketing. Es ist exakt der Grund, warum Astral gekauft wurde.

Ich sehe es täglich in meiner Arbeit. Ich nutze Claude Code in Laravel-Projekten, manage CI/CD-Pipelines mit GitHub Actions, und der Unterschied zwischen einem Agenten, der eine Datei generiert, und einem, der den Kontext begreift, in dem die Datei leben soll, ist der Unterschied zwischen Werkzeug und Spielzeug. Wenn der Agent meine Linter-Regeln kennt, weiß, wie meine Abhängigkeiten strukturiert sind, meinen Deployment-Flow versteht, dann wird er wirklich Mitarbeiter. Und um diese Art Mitarbeiter zu sein, muss er die Sprache der Werkzeuge sprechen, die ich benutze. Wenn der Agentenbauer auch diese Werkzeuge besitzt, ist der Wettbewerbsvorteil enorm.

Ein Lock-in neuer Art

Aber genau hier wird es interessant — und etwas beunruhigend. Denn was hier entsteht, ist ein neuer Typus von Vendor-Lock-in, anders als alles bisher Gesehene.

Das alte Lock-in war explizit: du wähltest einen Cloud-Anbieter, eine proprietäre Datenbank, und irgendwann kostete Migration zu viel. Du wusstest es, du rechnetest, du entschiedst. Das neue Lock-in ist anders. Es ist implizit. Du merkst nicht, dass es geschieht, weil jedes einzelne Stück Open Source, frei, neutral wirkt. uv ist noch unter MIT. Bun ist noch unter MIT. Du kannst forken, du kannst sie ohne Codex oder Claude Code nutzen, du kannst alles tun. Aber die Frage ist eine andere: in zwei Jahren, wenn 80 % der uv-Entwicklung von Codex’ Anforderungen gelenkt wird, wenn die priorisierten Features für OpenAIs Agenten gebaut sind und nicht für dich, der uv im Terminal nutzt — wird der Fork dann noch eine praktikable Option sein? Simon Willison, einer der klarsten Köpfe im Ökosystem, schrieb gestern, das Worst-Case-Szenario habe die Form von „fork and move on“. Aber er fügte ehrlich hinzu, OpenAI habe noch keinen Track Record im Pflegen übernommener Open-Source-Projekte. Und eine Akquisition, die als Produkt + Talent beginnt, könne sich mit der Zeit in eine reine Talent-Akquisition verwandeln.

Das ist ein Punkt, zu dem ich immer wieder zurückkehre. Der Code bleibt offen, die Richtung wird geschlossen. Eine Form von Kontrolle, die keine Lizenz verletzt, kein explizites Versprechen bricht, und doch Macht stark konzentriert. Jemand auf Hacker News beschrieb die Dynamik treffend: „As they gobble up previously open software stacks, how viable is it that these stacks remain open?“ Die technische Praktikabilität bleibt, die praktische erodiert.

Ich schreibe es und höre die Einwände, die ich mir selbst gemacht habe. „Aber die Anreize sind ausgerichtet“, sagen viele. „Anthropic braucht, dass Bun für alle gut funktioniert, nicht nur für Claude Code, weil breite Adoption Netzwerkeffekte schafft.“ Stimmt, zumindest heute. „Die MIT-Lizenz schützt die Community“, sagen andere. Stimmt auch — zumindest in der Theorie. Aber ich habe in meiner Karriere genug Akquisitionen gesehen, um zu wissen, dass Versprechen vom Tag der Ankündigung ein nicht geschriebenes Verfallsdatum haben. Jarred Sumners Post war ehrlich: „No one can guarantee how motives, incentives, and decisions might change years down the line.“ Und ich würde hinzufügen: die Anreize einer Startup mit null Umsatz und vier Jahren Runway sind sehr verschieden von denen einer Sparte in einer Firma, die für jeden Umsatzdollar zwei Dollar fünfzig verbrennt und jede Akquisition vor Investoren rechtfertigen muss, die auf einen Börsengang warten.

Der Kampf um den Workflow

Es gibt einen weiteren Aspekt, der mich trifft: wie diese Akquisitionen den Wettbewerb neu definieren. Bis gestern lief der Kampf zwischen OpenAI und Anthropic über Modellqualität. Wer besser argumentiert, wer saubereren Code generiert, wer mehr Kontextlänge hat. Heute verlagert er sich auf eine andere Ebene: wer mehr Fläche des Entwickler-Workflows kontrolliert. Es geht nicht mehr nur um „mein Modell ist besser“. Es geht um „mein Modell lebt in einem Ökosystem, das mir gehört und jede Stufe optimiert“. Code-Generierung wird zur Commodity, der Wert wandert zur Orchestrierung des gesamten Zyklus. Wer Linter, Package Manager, Runtime und Coding-Agent besitzt, hat einen strukturellen Vorteil, den kein Benchmark abbildet.

Die Frage, die ich mir stelle und die noch keine klare Antwort hat, ist, was das für jene bedeutet, die mit anderen Stacks als Python und JavaScript arbeiten. Die Welt vieler Teams hat (noch) keine solche Konzentration erlebt — denken Sie an andere Ökosysteme. Aber das Muster ist klar und wird sich ausbreiten. Heute Python und JavaScript, weil das die Sprachen von KI und Web sind. Morgen jedes Ökosystem, in dem Coding-Agenten zuverlässige Werkzeuge brauchen, um autonom zu operieren. Der Wettlauf, die Bausteine der Entwicklungsinfrastruktur zu kaufen, hat eben begonnen.

Eine vielleicht etwas erzwungene Analogie hilft mir beim Denken. Jahrzehntelang war Erdöl der Treibstoff der Industriewirtschaft, und wer Raffinerien und Pipelines kontrollierte, hatte mehr Macht als die Förderer. In der Software sind Sprachmodelle das Rohöl. Sie liefern Output. Aber der echte Wert liegt in der Raffinerie: in den Werkzeugen, die diesen Output in funktionierende, getestete, konforme, deployte Software verwandeln. Die KI-Firmen haben das verstanden und kaufen die Raffinerien.

Eine politische Entscheidung

Und wir stehen mitten in diesem Übergang, ohne ihn gewählt zu haben. Wir nutzen uv, weil es das beste verfügbare Werkzeug ist. Wir nutzen Bun, weil es schnell ist und reale Probleme löst. Unsere Entscheidungen sind rational und individuell. Aber der aggregierte Effekt von Millionen rationaler, individueller Entscheidungen ist die Konzentration infrastruktureller Macht in den Händen weniger Firmen, die diese Werkzeuge nicht gebaut, sondern gekauft haben.

Ich weiß nicht, wohin das alles führt. Vielleicht bleiben die Anreize lange genug ausgerichtet, um keine Probleme zu erzeugen. Vielleicht erweist sich die MIT-Lizenz als ausreichender Schutz. Vielleicht bleibt der Markt wettbewerbsfähig genug, um Missbräuche zu verhindern. Vielleicht aber nicht. Vielleicht bauen wir eine Abhängigkeit, die wir erst dann als solche erkennen, wenn es zu spät ist, sie elegant zu verlassen.

Was ich weiß: die Wahl deines Package Managers, deiner Runtime, deines Linters war nie eine rein technische. Heute ist sie, ob du willst oder nicht, auch eine politische. Und wie alle politischen Entscheidungen verdient sie, mit offenen Augen getroffen zu werden.

Es gibt einen seltsamen, stillen Moment, in dem du merkst, dass eine ungeschriebene Regel nicht mehr gilt. Nicht weil jemand sie mutig in Frage gestellt hätte, sondern weil die Realität aufgehört hat, mitzuspielen.

In der IT-Beratung ist dieser Moment, meiner Meinung nach, jetzt.

Jahrelang lebten wir in einem bequemen Pakt: du zahlst die Zeit, ich versuche es. Wir nannten es time & materials, Staff Augmentation, Body Rental. Verschiedene Namen, dieselbe Idee. Du kauftest menschliche Stunden und hofftest, sie würden zu etwas Nützlichem. Manchmal passierte das, manchmal nicht. In beiden Fällen zahltest du.

Und es funktionierte nicht, weil es richtig war. Es funktionierte, weil es die einzige mögliche Form schien. Software ist komplex, Schätzen ist schwer, Anforderungen ändern sich, Technologie auch. Also redeten wir uns ein, Zeit sei eine gute Annäherung an Wert.

Dann kam die KI und machte diese Fiktion, ohne zu fragen, viel schwerer aufrechtzuerhalten.

Die bequeme Lüge des time & materials

T&M, wenn man ihm die schönen Worte abzieht, ist vor allem eines: ein Risiko-Transfer-Mechanismus.

Das Risiko, schlecht zu schätzen, technische Probleme zu entdecken, einen wachsenden Scope zu managen, spät zu merken, dass die Anfangsidee nicht trägt. Im Stundenmodell landet dieses Risiko fast immer beim Kunden. Der Anbieter „stellt Leute“, der Kunde zahlt die Erkundung — auch in Sackgassen.

Beschriebt man es so in anderen Branchen, klingt es absurd. Stell dir einen Klempner vor, der Stunden abrechnet, ohne zu versprechen, dass das Wasser wieder fließt. Oder einen Chirurgen, der pro Minute bezahlt wird, unabhängig vom Operationsergebnis.

Und doch war es in der IT normal. Mehr noch: erwartet. Wer Garantien verlangte, galt schnell als „kompliziert“. Wer Festpreise anbot, schien naiv oder gefährlich.

Die Begründung war immer dieselbe: „Software ist anders.“ Stimmt teilweise. Aber daraus zu folgern, der einzig ehrliche Modus sei Stundenabrechnung, war immer ein logischer Sprung.

Die etwas traurige Wahrheit: kurzfristig kam es allen entgegen. Viele Kunden hatten zu wenig interne Kompetenz, um Qualität von Ineffizienz zu trennen. Und viele Anbieter, ehrlich gesagt, lebten gut in dieser Welt. Weil Zeit messbar ist, Wert nicht. Wenn du Wert nicht messen kannst, kaufst du, was du zählen kannst.

Das Problem: die Anreize werden seltsam. Manchmal verkehrt. Bist du langsamer, fakturierst du mehr. Löst du in zwei Stunden statt zwanzig, „lässt du achtzehn Stunden auf dem Tisch“. Niemand sagt das so offen, aber das System drängte in diese Richtung.

KI tritt auf und verkürzt die Stunden

Dann begannen, in kürzester Zeit, einige tägliche Tätigkeiten zu kollabieren.

Boilerplate, repetitive Integrationen, Migration-Scaffolding, generierte Tests, Erstdoku, Datenumformungen. Nicht alles, nicht immer, nicht perfekt. Aber genug, um die Mathematik zu ändern.

Hier kommt der Punkt, der das Modell sprengt: wenn gestern eine Integration „80 Stunden wert“ war und heute mit KI-Unterstützung 15 verlangt — was rechnest du ab?

Rechnest du 15 Stunden, sinkt dein Umsatz drastisch bei gleichem Resultat.

Rechnest du trotzdem 80, machst du etwas, das stark nach Betrug aussieht — auch wenn du es „Buffer“, „Kontingenz“, „Risikomanagement“ nennst. Nicht alle erleben es so, aber das Gefühl ist schwer zu ignorieren.

Daher drei Reaktionen, alle fragil:

Manche verbergen den KI-Einsatz.

Andere verbieten ihn, weniger der Qualität wegen, mehr um das Modell zu schützen.

Andere nutzen ihn und halten die Stundenpreise hoch und behalten den Produktivitätsgewinn.

Der Punkt ist: dieses Fenster schließt sich. Die Arbitrage zwischen „wie lange brauchte ein Mensch“ und „wie lange braucht jemand mit KI“ wächst zu groß. Früher oder später rechnet jemand auf Kundenseite nach. Oder vergleicht Anbieter. Oder fragt sich, warum dieselbe Sache heute genauso viel kostet wie vor zwei Jahren.

Wenn Code billiger wird, was bleibt zu verkaufen?

Diese Frage trennt meiner Ansicht nach Überleber von Festsitzern.

Denn wenn KI dich beim Code, bei Tests und Doku schneller macht, denkt man natürlich: „okay, mein Job ist weniger wert“.

Davon bin ich gar nicht überzeugt. Vielleicht ist ein Teil weniger wert, der mechanische. Aber gerade diese Reduktion bringt den Rest hervor — das, was immer Wert war und das wir mit den Stunden verpackt haben.

Was Kunden wirklich suchen, ist nicht der Code. Es ist ein Outcome.

Ein funktionierendes Produkt.

Ein reduziertes Risiko.

Eine neue Fähigkeit.

Eine gut getroffene Entscheidung.

Und es gibt Felder, in denen KI vorerst die Beratung nicht ersetzt. Sie verstärkt sie.

Das Problem verstehen, nicht nur die Anforderungen

Technische Anforderungen sind oft Symptome. Das wahre Problem liegt darunter: Prozesse, Zwänge, Menschen, interne Politik, Anreize. Manchmal auch unausgesprochene Ängste.

Das zu verstehen verlangt Zuhören, Kontext und ein wenig Mut, Unbequemes zu sagen.

Schwierige, irreversible Entscheidungen treffen

Architektur, Build vs Buy, Datenmodell, Sicherheitsposition. Entscheidungen, die jahrelang nachklingen.

Die KI kann dir Optionen vorschlagen. Verantwortungsvoll gut wählen ist etwas anderes.

Verantwortung übernehmen

Das ist mir der zentralste Teil.

Die KI kann nicht um 3 Uhr nachts angerufen werden, wenn etwas zusammenbricht. Sie kann sich vor dem Vorstand nicht hinstellen. Sie kann nicht juristisch oder reputativ haften.

Ein Anbieter schon. Und diese Verantwortung wird heute zur expliziten Wertkomponente.

Compliance und reale Zwänge navigieren

Nicht nur „was wir bauen können“, sondern „was wir bauen können, ohne in Schwierigkeiten zu geraten“.

DSGVO, NIS 2, Accessibility Act, Cyber Resilience Act, AI Act. In Europa wird immer klarer: Software ist nicht nur Projekt, sondern Produkt mit Pflichten.

Value Pricing: alle reden, wenige tun’s

Value Pricing ist nicht neu. Doch in der IT-Beratung blieb es oft fernes Ideal.

Warum? Weil es etwas verlangt, was T&M dir erspart: Risiko übernehmen.

Wert verkaufen heißt Ergebnisse verkaufen. Und wenn du Ergebnisse verkaufst, musst du sagen können: „kommen sie nicht, stehen wir dafür gerade.“

Das ist nicht nur ein Preisunterschied. Es ist ein Identitätswechsel.

Es heißt aufhören, „Personentage“ zu verkaufen, und etwa „eine funktionierende Integration zwischen CRM und ERP, mit Monitoring, Logging, Tests und klaren Abnahmekriterien“ zu verkaufen.

Es heißt, Methoden zur Schätzung und Steuerung von Unsicherheit zu bauen, statt sie weiterzureichen.

Es heißt, in Prozesse, Qualität, Spezifikationen — und ja, auch in KI — zu investieren, transparent.

Und ein Zweifel bleibt: vielleicht haben viele Firmen keine Angst vor KI. Sie haben Angst, Ineffizienz nicht mehr hinter einem Timesheet verstecken zu können.

Der wahre Widerstand: die Angst vor Verantwortung

Ich habe im letzten Jahr mit vielen aus der Branche gesprochen. Fast alle sagen, das wertbasierte Modell sei „die Zukunft“. Wenige wenden es wirklich an.

Und ich glaube nicht, dass es nur an kommerzieller Komplexität liegt. Ich glaube, es ist Angst.

T&M ist bequem, weil es schützt. Geht etwas schief, kannst du immer sagen „ihr habt das verlangt“, „wir haben die Anforderungen befolgt“, „wir haben die Stunden geliefert“. Die Ergebnisverantwortung verteilt sich.

Verkaufst du ein Outcome, verschwindet dieser Schutz. Geht es nicht, ist es dein Problem. Ist es nicht konform, behebst du es. Bleibt der Business-Effekt aus, musst du erklären, warum.

Unbequem. Aber endlich auch ehrlich.

Eine Notiz an die Käufer von Beratung

Es ist nicht nur Schuld der Anbieter. Auch die Käufer haben das System mitgebaut.

Wenn du Partner vor allem nach Tagessatz wählst, sagst du dem Markt: mich interessiert der Stückpreis, nicht das Resultat. Du solltest dich dann nicht wundern, Konformität statt Mut zu bekommen. Anwesenheit statt Verantwortung.

In der Welt nach KI heißt gutes Einkaufen meiner Meinung nach einen Sprung machen:

Messbare Outcomes verlangen, auch wenn nicht perfekt.

Mehr zahlen für jene, die Risiko nehmen und Transparenz liefern.

Aufhören, kilometerlange Spezifikationen als Kontrollform zu fordern, und statt dessen Problem, Zwänge, Erfolgskriterien beschreiben.

Ein Minimum interner Kompetenz aufbauen, um Qualität zu beurteilen — sonst landest du wieder beim Stundenkauf, dem Einzigen, was du zählen kannst.

Wir treten in eine Vertrauensökonomie

Ein Nebeneffekt der KI scheint mir gewaltig: Produzieren ist billiger geworden, Verifizieren teurer.

Heute kann jeder Code, Doku, Diagramme, „glaubwürdige“ Reports erzeugen. Das Problem ist nicht, einen Output zu bekommen. Es ist, zu wissen, ob der Output verlässlich, sicher, wartbar, konform ist.

Die Frage ändert sich also.

Sie lautet nicht mehr „kannst du das?“. Sie lautet „kann ich dem Output, den du lieferst, vertrauen?“

Vertrauen automatisierst du nicht. Du baust es mit Track Record, Transparenz, Verantwortung, der Fähigkeit, einen Fehler zuzugeben und zu korrigieren.

In diesem Sinn ist Value Pricing auch ein Signal: wenn ein Anbieter akzeptiert, für ein Ergebnis bezahlt zu werden, sagt er, dass er an seine Arbeit so glaubt, seine Haut zu verwetten.

Ein Geständnis, denn ich stecke auch drin

Wir haben hier jahrelang nach Stunden abgerechnet. Es war normal. Es war einfach. Es war auf eine Art beruhigend.

Dann begann KI, die Arbeit wirklich zu beschleunigen. Wir standen vor einer Wahl, vor der jetzt viele stehen: so tun als ob — oder ändern.

Ändern ist anstrengend. Es zwingt dich, Angebote, Verträge, Prozesse und auch interne Kultur neu zu denken. Es zwingt dich zu fragen, worin du wirklich gut bist und worin nicht. Es zwingt dich, Nein zu sagen.

Ich weiß nicht, ob wir alles perfekt machen. Wahrscheinlich nicht.

Aber eines scheint mir klar: T&M ist nicht „tot“, weil KI Code schreibt. Es ist tot, weil KI es unmöglich gemacht hat, weiterhin so zu tun, als sei Zeit ein ehrliches Wertmaß.

Und vielleicht, ehrlich gesagt, ist das eine gute Nachricht. Nicht weil es leicht wird, sondern weil es alle zwingt zurückzukehren zu dem, was wir schon immer hätten verkaufen sollen: Ergebnisse, Verantwortung und Vertrauen.

„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.

Es sind die Dinge, die man verlernen muss.

Und das Seltsame ist, dass es einem beim Verlernen vorkommt, etwas zu verlieren. Status, Kontrolle, Identität. Wenn es gut läuft, merkt man danach, dass man nur eine Gewohnheit losgelassen hat, die einen festhielt.

Das hier sind verstreute Notizen zu Dingen, die ich aufgegeben habe. Ich habe ungefähr fünfzehn Jahre dafür gebraucht. Bei manchen, ehrlich gesagt, bin ich noch nicht fertig.

Ich schreibe nicht mehr Code, um zu beweisen, dass ich noch tech bin

Es gab eine Zeit, kurz nach einem wichtigen Karriereschritt, in der mein Weg, mich vor dem Team zu legitimieren, immer derselbe war: IDE öffnen und mir den hässlichsten Bug der Woche schnappen.

Oft abends, allein. Am Morgen war der Commit da, mit meinem Namen drauf. In mir nannte ich das Leadership. Es war Unsicherheit.

Denn die implizite Botschaft war verheerend, auch wenn ich sie nie laut aussprach. Sie lautete: ich vertraue euch nicht. Und es gab eine zweite, noch toxischere: Probleme löst man nachts, allein, ohne um Hilfe zu bitten.

Ohne es zu wollen, lehrte ich, dass die heroische Geste mehr wiegt als der Prozess. Dass Können eine individuelle Performance ist. Dass Erschöpfung eine Medaille ist.

Dann machte ich eine weitere Runde. Ich ersetzte Code durch Spezifikationen. Dokumente, so präzise, dass das Team — oder ein KI-Agent — sie mit minimaler Aufsicht umsetzen konnte. Eine Weile schien das die „erwachsene“ Lösung. Auch diese Phase ging vorbei.

Heute ist meine Arbeit, wenn ich sie gut mache, eine andere. Es ist zu entscheiden, was wir bauen, für wen und warum jetzt. Es ist Portfolio-Architektur, nicht Code-Architektur. Partnerschaften, Hiring, Positionierung. Zu verstehen, wohin das Unternehmen in achtzehn Monaten zielen soll und welche heutigen Entscheidungen diese Richtung wahrscheinlicher machen.

Diese Distanz zum Code tut manchmal weh. Nicht, weil ich täglich wieder programmieren möchte. Es ist subtiler. Es ist das Gefühl, dass die Legitimität einer Tech-Leitung, die nicht mehr täglich Code anrührt, etwas Fragiles ist, das auf anderen Grundlagen neu gebaut werden muss.

Nicht mehr auf der Qualität dessen, was du schreibst, sondern auf der Qualität deiner Entscheidungen und der Menschen, die du auswählst.

Und es gibt einen Satz, der mir oft einfällt und mich davor bewahrt, in den alten Reflex zurückzufallen: jede Zeile, die ich schreibe, ist eine Zeile, die jemand anderes nicht schreibt. Jede Stunde in der IDE ist eine Stunde, in der niemand schaut, wohin wir gehen.

Ich laufe nicht mehr dem ‚richtigen’ Stack hinterher

Jahrelang hatte ich diesen pawlowschen Entwickler-Reflex. Neues Framework? Bewerten. Neue Sprache? Wenigstens probieren.

Im Untertext stand wohl: es gibt eine „richtige“ Technologiewahl, die dich auf die Seite der Gewinner stellt. Der Cool Kids. Der richtigen Konferenzen. Der Hacker-News-Artikel.

Dann tat ich etwas Unpopuläres, jedenfalls für mein damaliges Denken: ich wählte ein Framework. Eines. Und blieb dabei.

Nicht weil es absolut das beste wäre. Sondern weil ich damit mit wenigen Leuten Wert über mehrere Projekte hinweg liefern kann, ohne durchzudrehen. Weil es eine Philosophie hat, die zu den realen Zwängen einer italienischen Firma passt. Konvention vor Konfiguration, Batterien inklusive, manische Doku. Nicht die imaginären Zwänge eines Bay-Area-Startups, das von Slides und Runway lebt.

Die unbequeme Wahrheit: viele „mutige“ Technologiewahlen in KMU sind kein Mut. Sie sind Eitelkeit. Rust für ein Verwaltungstool, das vierzig Leute nutzen, ist keine Ingenieurskunst. Es ist Narzissmus mit Compiler.

Irgendwann hörte ich auf, den richtigen Stack zu suchen, und begann den ehrlichen Stack zu suchen. Den, der über die eingeführte Komplexität nicht lügt. Den du wartest, wenn die Seniors gehen, das Budget enger wird, der Kunde dreimal seine Meinung ändert.

Ich schirme das Team nicht mehr vor dem Business ab

Der schwerste Schritt.

Jahrelang spielte ich Schild. Verrückte Kundenanforderung? Filtere ich. Vertrieb verkauft etwas, das es nicht gibt? Regle ich. Unverständliches Dokument? Übersetze ich und gebe nur den sauberen, verdaulichen Tech-Teil ans Team.

Ich hielt mich für einen guten Leader. Vermutlich züchtete ich Behinderte.

Sehr gute Entwickler, ja, aber abgekoppelt. Sie wussten nicht wirklich, warum sie bauten, was sie bauten. Sie konnten kein Business-Requirement lesen. Sie hatten nie mit einem Kunden gesprochen. Bei Mehrdeutigkeiten griffen sie nicht zum Telefon, sondern öffneten ein Ticket und warteten.

Die Wende für uns war ein interner Pfad, den wir „from developer to product owner“ nannten. Nicht, um alle in PMs zu verwandeln. Eher, um das Filter zu entfernen.

Um eine einfache, etwas unbequeme Sache zu sagen: das Chaos gehört auch euch. Der verwirrte Kunde gehört auch euch. Das mehrdeutige Requirement gehört auch euch.

Und vor allem: die Genugtuung, etwas auszuliefern, das wirklich für jemanden funktioniert, gehört auch euch.

Ich hatte mit Widerstand gerechnet. Ich täuschte mich. Sie haben mich überrascht. Vielleicht warteten sie nur auf die Erlaubnis, aus der Blase zu treten.

Ich sage nicht mehr ‚ist sowieso öffentlich’ zur Compliance

Jahrelang war meine Compliance-Haltung typisch für die italienische IT-Branche: das Allernötigste, im letzten Moment, als Kostenposten behandelt, nie als Investition.

DSGVO? Cookie-Banner und kopierte Datenschutzerklärung. Barrierefreiheit? „Sehen wir später.“ Sicherheit? „Wir sind kein Ziel.“

Dann begann ich, EU-Normen wirklich zu lesen. Nicht Artikel über sie, die Texte selbst. Und zwei Dinge wurden klar.

Erstens: der EU-Gesetzgeber meint es ausnahmsweise ernst. Sanktionen sind real, Fristen knapp, die Verantwortungskette reicht bis zum Komponentenlieferanten. Also zu uns.

Zweitens, wichtiger: in einem Markt, in dem alle bis zur letzten Minute warten, hat einen riesigen Vorteil, wer sich früh bewegt. Nicht weil er besser ist. Weil er als Einziger dem Kunden „ja, wir sind bereit“ sagen kann, wenn der Kunde panisch danach fragt.

Irgendwann hörte ich auf, Compliance als Pflicht zu behandeln. Ich begann sie als Produkt zu behandeln.

Und ich frage mich oft, warum wir so lange gebraucht haben, das zu begreifen. Vielleicht weil es bequemer ist zu glauben, das sei nur Papierkram, bis es plötzlich ein Problem mit Frist wird.

Ich stelle nicht mehr nach technischen Skills ein

Frisch und, ehrlich, noch ein bisschen schmerzhaft.

Ich verbrachte Wochen mit der Suche nach einer wichtigen Position. Hervorragende CVs. Jahre Erfahrung. Solide Stacks. Gute Referenzen. Ich lehnte einige ab, nicht weil sie schlecht waren, sondern weil sie KI nutzten wie Stack Overflow vor zehn Jahren. Wie ein Orakel.

Was ich suchte — und Recruitern schwer erklären kann — ist anderes. Ich suchte jemanden, der eine deklarative Spezifikation so präzise schreiben kann, dass ein KI-Agent sie mit minimaler Aufsicht umsetzt.

Kein Prompt-Engineer. Ein Systemdenker, der KI als Runtime nutzt, nicht als Krücke.

Der Unterschied wirkt fein, ist es aber nicht. Es ist der Unterschied zwischen „ich habe ChatGPT gebeten, mir den Code zu schreiben“ und jemandem, der ein claude.md im Repo führt — mit Architekturkonventionen, Patterns, Domänenrestriktionen. Zwischen Konversation und Spezifikation. Zwischen Handwerk und Ingenieurskunst.

Ich höre auf, Entwickler einzustellen, die programmieren können. Ich beginne, Entwickler zu suchen, die spezifizieren können und das, was die KI produziert hat, mit der gleichen Strenge prüfen, wie sie den Code eines Juniors prüfen würden.

Der italienische Markt scheint für diese Unterscheidung leider noch nicht bereit. Aber ich habe das Gefühl, er wird es bald sein. Und wer es nicht rechtzeitig schafft, riskiert Teams, die viel „produzieren“ und wenig verstehen.

Ich spreche nicht mehr Italienisch bei der Arbeit

Klingt klein. Ist es nicht.

Als ein neuer, sehr guter, nicht-italienischer Junior kam, standen wir vor einer Wahl. Untereinander weiter Italienisch sprechen und nur mit ihm Englisch — faktisch ein Zwei-Geschwindigkeiten-Team. Oder den vollständigen Switch.

Wir wählten den vollständigen Switch. Alles auf Englisch. Jira auf Englisch. Chat auf Englisch. Daily auf Englisch. Retro auf Englisch. Für alle.

Nicht nur seinetwegen. Auch unseretwegen.

Denn ein Unternehmen weniger Personen in einer italienischen Stadt, das ausschließlich auf Italienisch arbeitet, bleibt vermutlich ein Unternehmen weniger Personen in dieser Stadt. Daran ist nichts falsch. Nur war das nicht, was wir wollten.

Englisch ist am Ende keine Sprache. Es ist Infrastruktur. Wie Git, wie CI/CD, wie Doku. Du hast es oder du bist abgeschnitten.

Es war unbequem. Manche taten sich schwer. Aber wenn ich heute Pull-Request-Beschreibungen, Nachrichten, Mails lese, denke ich, es hat sich gelohnt.

Ich glaube nicht mehr, dass guter Code für sich spricht

Vielleicht die gefährlichste Lüge der Softwareentwicklung. Die romantische Idee, dass guter, sauberer, getesteter, gut strukturierter Code seinen Wert von selbst zeigt. Dass technische Verdienste sich selbst verteidigen.

So funktioniert das nicht.

Guter Code, den niemand versteht, ist von mittelmäßigem Code nicht zu unterscheiden. Ein Refactoring, das niemand erzählt, wird zur Kostenposition, nicht zur Investition. Eine Architekturmigration ohne schriftliche Begründung wirkt wie eine Tech-Laune.

Ich habe spät gelernt: die Hälfte der Arbeit einer Tech-Führung ist erzählen.

Dem Vorstand erklären, warum eine Migration keine Marotte, sondern Risikoreduktion ist. Dem Kunden erklären, warum die bezahlten automatisierten Tests der Grund sind, dass er ruhig schläft. Dem Team erklären, warum CI/CD keine Bürokratie ist, sondern Freiheit und Bequemlichkeit.

Wenn du den Wert dessen, was du baust, nicht erzählen kannst, wird ihn jemand anderes für dich erzählen. Und schlecht.

Was ich noch nicht aufgegeben habe

Wenn ich ganz ehrlich sein soll, gibt es etwas, das ich aufgeben sollte und noch nicht schaffe.

Zu arbeiten, als wäre ich der einzige, der die Teile zusammenhält.

Zu vieles geht noch über mich. Nicht weil das Team unfähig wäre, im Gegenteil, sondern weil ich die Systeme, die mich in jedem Bereich überflüssig machen würden, noch nicht gebaut habe.

Und das macht mir am meisten Angst.

Denn jeder vorherige Schritt hatte einen klaren Ersatz. Nicht mehr coden? Spezifikationen. Nicht mehr Spezifikationen schreiben? Strategie. Nicht mehr Code-Reviews machen? Ein Tech Lead. Aber aufzuhören, der Konvergenzpunkt von allem zu sein, ist anders.

Der Ersatz ist Vertrauen in Systeme. Und die Systeme, ehrlich gesagt, muss ich noch fertig bauen.

Wir sprechen weiter darüber.

Manchmal spreche ich mit Unternehmerinnen, die zehn, dreißig, achtzig Leute haben. Keinen Chief AI Officer, keine Achtzehn-Monats-Roadmap und oft auch keine Lust, sich anhören zu müssen, dass sie sich „transformieren müssen“. Sie haben eine andere, sehr konkrete Dringlichkeit: das Unternehmen am Laufen halten.

Und doch kommt die Frage trotzdem, auch wenn sie selten so direkt ausgesprochen wird: was sollen wir konkret mit KI machen?

Die Großen stellen sich die Frage längst offiziell, mit Budget, eigenen Teams, Programmen mit klingenden Akronymen. KMU sind in einem anderen Terrain: Verwirrung und widersprüchliche Signale. Nicht ihre Schuld. Die öffentliche Debatte über KI scheint für jene gemacht, die Zeit, Ressourcen und Strukturen haben, die ein KMU nie haben wird.

Ich versuche es einfach, fast brutal.

Wie viele Personen in deinem Team holen aus einem KI-Agenten ein Ergebnis, das besser ist als das, was sie allein produzieren würden?

Nicht wie viele „ihn nutzen“. Nicht wie viele ChatGPT in einem Tab offen haben. Wie viele präzise Anweisungen geben, den Output kritisch beurteilen, methodisch iterieren, bis etwas Tragfähiges herauskommt. In Vertrieb, Marketing, Operations, Finance, Recht, Produkt, HR.

Wenn die ehrliche Antwort „wenige“ oder „weiß ich nicht“ lautet, hast du wahrscheinlich ein Problem. In KMU wiegt dieses Problem mehr, weil du dir den Luxus, es zu vertagen, nicht leisten kannst.

Das teuerste Missverständnis 2026

Das Missverständnis ist meiner Ansicht nach eines: KI für eine Tech-Frage zu halten.

Sie ist es nicht mehr. Vielleicht seit mindestens einem Jahr nicht mehr.

KI ist zu einem Multiplikator individueller Fähigkeiten geworden, quer durch alle Rollen. Eine Vertrieblerin, die sich in zehn Minuten eine Wettbewerbsanalyse aufbaut, spielt ein anderes Spiel als jemand, der zwei Tage braucht. Wer in der Buchhaltung sich in einer Stunde ein sinnvolles Kosten-Cockpit generieren lässt, konkurriert in einer anderen Liga als jemand, der eine Woche braucht und Daten aus alten, halbkaputten Excel-Dateien klaubt.

Und wir reden nicht nur vom Wort „Effizienz“. Effizienz ist, dieselben Dinge schneller zu tun. Hier reden wir von Menschen, die anfangen, Dinge zu tun, die sie vorher gar nicht taten — weil die kognitiven Kosten zu hoch waren.

Ein wirklich personalisiertes Angebot für jeden Prospect statt des recycelten PDFs mit ausgetauschtem Namen auf dem Deckblatt. Eine Cashflow-Analyse der letzten drei Jahre, die Muster zeigt, auf die niemand hingewiesen hat. Projektfortschrittsberichte, die früher nicht existierten, weil „keine Zeit“.

Das kann passieren.

Aber nur, wenn jemand das Werkzeug lenkt. Wenn er es als zu führenden Mitarbeiter behandelt, nicht als zu ignorierendes Spielzeug oder als willkürlich zu befragendes Orakel.

‚Lenken’ ist nicht ‚Nutzen’

Diese Unterscheidung ist das Herz des Ganzen, und es überrascht mich, wie selten sie gemacht wird.

KI nutzen heißt etwas fragen und akzeptieren, was kommt. Es ist Prompt-and-pray. Du schreibst eine Anfrage, kopierst die Antwort, fügst sie in eine Mail und hoffst, dass es passt. Verständlich, am Anfang machen es alle so. Es ist aber nichts wert und manchmal sogar gefährlich.

KI lenken ist etwas anderes. Es heißt zu wissen, was zu fragen ist, wie, und vor allem zu erkennen, wann die Antwort falsch ist, auch wenn sie perfekt klingt.

Es heißt Kontext, Grenzen, Erfolgskriterien zu geben. Es heißt ernsthaft zu iterieren. Nicht „schreib es besser“, sondern „schreib es noch einmal, unter Berücksichtigung, dass unser Kunde eine öffentliche Stelle ist, mit Beschaffungsrestriktionen und sechsmonatigen Entscheidungszyklen“.

Wer KI lenkt, hat ein mentales Modell des Werkzeugs. Er weiß, was sie gut tut, wo sie zu erfinden neigt, wo sie zum Risiko wird. Er weiß, wann zu vertrauen und wann zu prüfen ist. Er weiß, wann der Output Ausgangspunkt und wann er fertig ist.

Und nein, das ist kein angeborenes Talent. Es ist eine Kompetenz, die man entwickelt. Aber jetzt der unbequeme Teil: nicht jeder entwickelt sie. Nicht aus Mangel an Intelligenz, sondern weil eine bestimmte Haltung nötig ist — und sie ist nicht so verbreitet, wie wir glauben mögen.

Die Haltung, die du im Interview übersiehst

Wenn du einstellst, schaust du meist auf Erfahrung, vertikale Kompetenzen, Unternehmenskultur, vielleicht Leadership. Alles richtig.

Aber du übersiehst womöglich eine Variable, die in den nächsten zwei Jahren Performer von Schwerfälligen trennen wird.

Die Variable: kann die Person vor dir auf einer Abstraktionsebene oberhalb der Ausführung arbeiten?

Wer auf der Ausführungsebene arbeitet, erledigt Aufgaben. Mails, Berichte, Analysen, Dokumente. Solide, mit Handwerk. Aber eine Sache nach der anderen, und seine Zeit ist die einzige Ressource.

Wer auf der Ebene der Spezifikation und Lenkung arbeitet, definiert, was zu tun ist, mit welcher Qualität, unter welchen Vorgaben, und führt dann einen Agenten (KI oder Mensch — auf dieser Ebene verschwimmt der Unterschied) bei der Ausführung. Er beaufsichtigt, korrigiert, schärft. Und geht weiter.

Das heißt nicht, Ausführung sei egal. Es heißt, der Wert reiner Ausführung schrumpft schnell, während die Lenkungsfähigkeit wächst.

Wenn du diese Fähigkeit beim Hiring nicht prüfst, stellst du Ausführer ein in einer Welt, die Direktoren belohnt.

Drei Fragen, die ein Interview verändern

Egal, ob du Marketing-Manager, Controller, Office-Manager oder CTO einstellst. Drei Fragen, die meiner Ansicht nach fast immer funktionieren.

„Erzähl mir vom letzten Mal, als du einen KI-Agenten für ein echtes Deliverable benutzt hast“

Kein Experiment. Kein Spiel. Ein fertiges Deliverable vor einem Kunden, einem Chef, einem Board.

Höre zu, wie er darüber redet. Hat er präzise Anweisungen oder generische Prompts gegeben? Hat er iteriert? Hat er den Output geprüft? Hat er sein Urteil eingebracht oder alles unverändert übernommen?

Wenn die Antwort „habe ich nie gemacht“ lautet, ist das 2026 ein Datum. Nicht zwingend Ausschluss, aber eines, das man ernst nehmen muss.

„Wie würdest du wissen, dass der Output falsch ist?“

Das ist die Schlüsselfrage.

KI produziert überzeugende Resultate, auch wenn sie völlig erfunden sind. Eine plausible, aber falsche Zahl. Eine logische Schlussfolgerung aus einer nicht existierenden Prämisse. Ein hervorragend geschriebener Text, der das Gegenteil dessen sagt, was nötig ist.

Wer KI lenkt, hat Antikörper entwickelt. Er hat eine Methode, auch rudimentäre, um zuverlässigen von toxischem Output zu unterscheiden.

Wer keine hat, ist gefährlicher als jemand, der KI gar nicht nutzt — er produziert Fehler mit der Sicherheit dessen, der sich im Recht wähnt.

„Wenn du einen KI-Assistenten acht Stunden am Tag hättest, wie würdest du deine Arbeit umorganisieren?“

Diese Frage trennt jene, die in Aufgaben denken, von jenen, die in Systemen denken.

Mittelmäßige Antwort: „ich würde dieselben Dinge schneller tun“.

Interessante Antwort: „ich würde andere Dinge tun“, gefolgt von einer konkreten Vision. Welche Prioritäten würden sich verschieben? Welche Outputs würden überhaupt erst entstehen? Welche Tätigkeiten würden gestrichen oder reduziert?

Wer gut antwortet, hat schon verstanden, dass KI nicht nur Effizienzwerkzeug ist. Sie ist Hebel. Und er weiß, wo er den Hebel ansetzen muss.

Der Elefant im Raum: die Schlüsselleute, die du schon hast

Das größere Problem ist oft nicht, wen du einstellst. Es sind die, die du schon hast.

In einem KMU ist das Organigramm kurz. Keine Schichten Middle Management. Du hast drei, fünf, acht Schlüsselleute, die das Unternehmen tragen.

Den Vertriebsleiter, der alle Kunden auswendig kennt. Die Verwaltungsperson, die seit fünfzehn Jahren die Maschine am Laufen hält. Die Projektmanagerin, auf die du alles ablädst, was du sonst nicht weißt, wohin.

Wenn diese Leute KI nicht anrühren, weil „das ist nicht mein Job“ oder „ich habe es immer so gemacht und es hat funktioniert“, hast du einen Engpass, den keine Neueinstellung kompensieren kann.

In einem Konzern kannst du das mit einem eigenen Team umgehen. In einem KMU nicht. Die Schlüsselleute sind das Unternehmen. Wenn sie sich nicht ändern, ändert sich nichts.

Und jetzt der wirklich unbequeme Teil, der für etwas Verärgerung sorgt.

In vielen KMU sitzt die erste Person, die die Botschaft nicht erhalten hat, sehr weit oben.

Wenn du das bist und mit einer Mischung aus Interesse und Reizung liest, lohnt es sich vielleicht, einen Moment auf dieser Reizung zu verweilen. Ich frage mich oft, ob sie nicht eines der nützlichsten Signale ist, wenn etwas uns mehr betrifft, als wir wollen.

Die Wahl ist am Ende klar: festzulegen, dass die Fähigkeit, KI-Agenten zu lenken, eine erwartete Kompetenz für jede Rolle ist — bei dir beginnend. Nicht optional. Nicht „nice to have“. Erwartet, bewertet, gemessen.

Es ist keine Generationenfrage

Eine andere bequeme Abkürzung trägt nicht: „die Jungen sind Digital Natives, also verstehen sie KI“.

Stimmt nicht.

Ich habe Zwanzigjährige gesehen, die KI als etwas glänzendere Suchmaschine nutzen. Und Fünfzigjährige, die sie auf eine Art in den Workflow integrieren, wie ich es mir nicht vorgestellt hätte.

Die Variable ist nicht das Alter. Es ist die Bereitschaft, die eigene Arbeitsweise neu zu denken. Zu sagen: „vielleicht ist die Art, wie ich es immer gemacht habe, nicht mehr die beste“.

Es braucht Demut, Neugier und ein wenig Unbehagen. Drei Dinge ohne Alter.

Also reicht es nicht, junge Leute einzustellen und zu hoffen, dass die KI per Osmose ins Unternehmen einsickert. Es braucht eine bewusste Wahl: welche Kompetenzen wertest du auf, welche belohnst du, welche — sagen wir es offen — verlangst du.

Die Kosten der Trägheit, in Zahlen (ungefähr)

Keine perfekten Rechnungen, aber die Größenordnung stimmt.

Ein Knowledge Worker, der KI gut lenkt, hat oft einen Output, der dem 1,5- bis 2-fachen eines Nichtnutzers entspricht. Nicht weil er mehr arbeitet, sondern weil er die niedrigwertige Arbeit eliminiert: manuelle Recherchen, Erstentwürfe, Erkundungsanalysen, Datenstrukturierung, Folienvorbereitung.

In einem Team von zehn: wenn fünf KI lenken und fünf nicht, ist es, als hättest du zwölf oder dreizehn Personen. Ohne jemand einzustellen.

Dreh die Argumentation um.

Wenn das Team deines Wettbewerbers auf diese Kompetenz ausgerichtet ist und deins nicht, bleibt deins bei zehn. Seines wird zu fünfzehn oder zwanzig, jedenfalls für bestimmte Tätigkeiten.

Und die Schere öffnet sich jeden Monat weiter, weil die Werkzeuge besser werden und wer sie lenkt, den inkrementellen Wert einsammelt. Wer sie nicht lenkt, steht still.

Das ist kein Futurismus. Das ist Arithmetik.

Was Montagfrüh zu tun ist

Die gute Nachricht: keine Task Forces, keine Beratenden, keine Zwölf-Monats-Transformationsprogramme für sechshunderttausend Euro nötig.

Drei praktische Entscheidungen — und etwas Konsequenz.

Erstens: die KI-Lenkungsfähigkeit als Bewertungskriterium für jede offene Stelle einführen. Nicht als technische Anforderung, sondern als Querschnittskompetenz, auf der Ebene von Kommunikation oder Teamfähigkeit. Stelle die drei Fragen. Höre wirklich zu.

Zweitens: deine direkten Berichte fragen, wie sie KI im Alltag einsetzen. Nicht per anonymer Umfrage, sondern im Einzelgespräch. Du wirst Überraschendes in beide Richtungen entdecken. Wer sie gut nutzt, tut es oft leise. Wer sie schlecht nutzt, merkt manchmal nicht, wie zerbrechlich seine Methode ist.

Drittens: das Vorbild geben.

Wenn du eine Unternehmerin bist, die nie einen KI-Agenten genutzt hat, um ein Angebot zu erstellen, eine Bilanz zu analysieren oder eine wichtige Mitteilung zu schreiben, ist die Botschaft klar: es ist nicht wichtig.

Und deine Organisation wird dir glauben.

In einem KMU kannst du Wandel nicht delegieren. Er beginnt bei dir oder gar nicht.

Es ist keine Moral

In fünf Jahren werden wir auf die Hiring-Prozesse von 2025 wahrscheinlich blicken wie heute auf die von 2010 — mit einer Mischung aus Zärtlichkeit und Unglauben. „Ihr habt ernsthaft Leute eingestellt, ohne zu prüfen, ob sie mit KI arbeiten können?“

Ja, im Ernst.

Wer früher damit aufhört, ohne zu warten, bis es „Standard“ wird, hat einen Vorsprung, den andere Jahre brauchen werden, um aufzuholen.

Vielleicht ist die richtige Frage am Ende nicht, ob die nächste Person, die du einstellst, KI nutzen kann.

Es ist, ob sie sie lenken kann. Und ob du bereit bist, das einzufordern, auch wenn es unbequem ist.

Ich arbeite in einem Tech-KMU in Pescara. Wir sind ein Dutzend, nicht fünfzig, nicht zweihundert. Wir machen Software für unterschiedliche Kunden, von der öffentlichen Verwaltung bis zu SaaS-Plattformen, und was uns seit jeher zusammenhält, ist eine Art Besessenheit von Solidität. Durchdachte Architekturen, Code, der trägt, Systeme, die nicht zerfallen, wenn echte Daten, echtes Geld, echte Entscheidungen hineinkommen.

Und doch dachte ich in den letzten Monaten oft etwas Bitteres: es ist ein brutaler Moment, Ideen zu haben. Nicht aus Mangel an Kreativität — im Gegenteil. Das Problem ist, dass die Kreativität oft mit einem Gefühl der Ohnmacht kommt.

Das ‚das gibt’s schon’-Syndrom

Es läuft so ab, mit fast komischer Regelmäßigkeit.

Montagmorgen, Brainstorming. Jemand wirft eine Idee in die Runde. Wir entzünden uns, beginnen zu planen, wie man sie gut macht, welche Architektur richtig wäre, wo die Risiken liegen, wie wir sie verkaufen, ohne uns selbst etwas vorzumachen.

Dann kommt Mittwochabend. Scrolling auf LinkedIn oder Hacker News, und da ist die Ankündigung: Google, Microsoft, OpenAI oder ein eben finanziertes Startup mit Summen, die wir nur in Podcast-Erzählungen sehen, hat gerade dieselbe Sache präsentiert. Oder etwas hinreichend Ähnliches, dass unsere Idee am Markt als verspäteter Klon erscheint.

Es ist nicht einmal die Frage „sie haben uns kopiert“. Es ist banaler und niederschlagender: sie haben die Skala. Und in dieser historischen Phase scheint Skala mehr zu zählen als alles andere.

Ich frage mich oft, ob wir nicht in eine Zeit geraten, in der echte Innovation fast zum Luxus wird, den sich nur leisten kann, wer schnell und öffentlich falsch liegen darf.

Wenn man dich nicht schlägt, weil sie besser sind, sondern weil sie schneller sind

Bis hierher wäre es schon frustrierend. Aber es gibt eine weitere Ebene, schwerer zu schlucken.

Denn man schlägt dich nicht immer mit einem besseren Produkt. Manchmal schlägt man dich mit etwas Mittelmäßigem, eilig versendet, mit minimalen Tests und einem fast arroganten Vertrauen darauf, dass die Marke trotzdem trägt.

„Vibe Coding“, was bis vor Kurzem wie eine Indie-Hacker-Spielerei wirkte, ist im Enterprise angekommen. Und ich rede nicht vom Junior, der mit Copilot eine Komponente schreibt. Ich rede von ganzen Teams, die mit Prompts riesige Anwendungsteile generieren, zwei kurze Tests machen und dann alles in Produktion bringen.

In den letzten Monaten habe ich Plattformen mit Lücken gesehen, bei denen einem schwindelig wird. XSS, das man in fünf Minuten findet, APIs ohne Rate-Limiting, Zahlungsflüsse ohne Idempotenz, Verarbeitung personenbezogener Daten, die jeden ernsthaften DSB erblassen ließe.

Und doch sind sie da. Auf dem Markt. Mit Nutzern. Mit Umsatz.

Die implizite Botschaft, die einem auch ungehört entgegenkommt, lautet: Qualität zählt nicht, Geschwindigkeit zählt.

Wenn Qualität nicht zählt, was bleibt dann uns Kleinen, die auf Qualität ihren Ruf und oft auch ihr Überleben bauen?

Die Brüssel-Epiphanie (mit der ich nicht gerechnet hatte)

Hier kommt der Teil, den ich vor zwei Jahren nie zu schreiben geglaubt hätte.

Lange habe ich die EU-Regulierung mit Verärgerung betrachtet. Die DSGVO 2018 schien mir ein Klotz: viel Mühe für jene, die ohnehin gut arbeiteten, während die Großen weiterhin ihren Dingen nachgingen und schlimmstenfalls Strafen zahlten, die für sie Kleingeld waren.

Doch dann begann ich, das Bild zu betrachten, das gerade entsteht. Und ich hatte ein seltsames, fast kontraintuitives Gefühl: Brüssel ist vielleicht eine der wenigen Waffen, die uns bleiben.

Nicht weil „Bürokratie schön ist“, weit gefehlt. Sondern weil das, was sich abzeichnet, keine isolierte Verordnung ist. Es ist ein integriertes regulatorisches Ökosystem, das den Maßstab des Wettbewerbs verändert.

Wenn Europa zu 80 % aus KMU besteht und will, dass diese KMU im KI-Zeitalter überleben, muss es etwas Einfaches und sehr Schwieriges tun: verhindern, dass Größe der einzige Wettbewerbsvorteil ist.

Und genau das versucht es, im Guten wie im Schlechten.

Sieben Normen, eine Richtung

Ich liste sie auf, ja, aber mit einer Idee: lies sie nicht als „sieben Pflichten“. Lies sie als Industriestrategie.

AI Act, der große Anhebende

Der AI Act ist seit dem 1. August 2024 in Kraft, mit gestaffelter Anwendung. Verbote ab Februar 2025, Pflichten für Hochrisikosysteme ab August 2026.

Das Interessante: er sagt nicht „macht keine KI“. Er sagt „macht sie gut“. Er klassifiziert Systeme nach Risiko, und wo das Risiko hoch ist, verlangt er Dinge, die eigentlich normal sein sollten: Risikomanagement, Datenqualität, menschliche Aufsicht, Dokumentation, Transparenz.

Für ein KMU, das ohnehin geordnet arbeitet, ist Compliance oft ein handhabbares Delta. Nicht gratis, sicher. Aber handhabbar.

Für jene, die ein kritisches System in drei Wochen ohne wirkliches Verständnis seines Verhaltens in Produktion gebracht haben, wird es ein Abgrund. Sie müssen Prozesse, Governance, Architektur neu denken. Sie müssen abbremsen.

Und hier wird der AI Act paradoxerweise pro-KMU. Nicht weil er die Kleinen als Kleine schützt, sondern weil er belohnt, wer schon eine Kultur des „machen wir’s gut“ pflegt.

Es gibt auch einen Punkt, der mich bei General-Purpose-Modellen sehr interessiert: Transparenz- und Dokumentationspflichten für Anbieter, vor allem bei Modellen mit systemischem Risiko. Übersetzt: wenn ich ein Produkt auf einem Foundation-Modell baue, habe ich mehr Anspruch darauf, Grenzen, Risiken, Konturen zu kennen. Heute versteht man sie oft nur durch Paper und Corporate-Posts.

Cyber Resilience Act, das Ende von „läuft, fass es nicht an“

Der CRA ist seit dem 10. Dezember 2024 in Kraft. Meldepflichten ab September 2026, volle Anwendung ab Dezember 2027.

Hier ändert sich der Ton wirklich: wer ein Produkt mit digitalen Elementen auf den europäischen Markt bringt, ist über den gesamten Lebenszyklus für die Sicherheit verantwortlich. Sicherheitsupdates für mindestens fünf Jahre, dokumentiertes Schwachstellenmanagement, schnelle Meldungen, und vor allem SBOM.

Das SBOM ist nüchtern gesagt ein Inventar: zu wissen, was in deiner Software steckt, Abhängigkeiten inklusive. Wenn eine kritische CVE veröffentlicht wird, musst du keine Archäologie betreiben. Du weißt es.

Und weißt du, wer oft schon so strukturiert ist? KMU mit modernen Stacks, anständigen Pipelines, nachvollziehbaren Abhängigkeiten.

Wer leidet? Riesige Organisationen mit Jahren technischer Schulden, unanfassbarem Legacy, 2016 eingefrorenen Komponenten und niemandem, der die Karte des Geländes hat.

Der CRA macht Wartung von „wenn Zeit bleibt“ zur Pflicht. Und plötzlich hört die manische Update-Aufmerksamkeit auf, eine persönliche Marotte zu sein, und wird zur Wettbewerbshaltung.

Product Liability Directive, Software ist nicht mehr unantastbar

Die neue PLD wurde 2024 verabschiedet, die Mitgliedstaaten müssen sie bis Dezember 2026 umsetzen.

Hier gestehe ich, ein wenig Angst zu haben. Sie weitet die Produkthaftung auf Software aus. Und in einigen Fällen führt sie Mechanismen wie eine Beweislastumkehr ein: bei plausiblem Zusammenhang zwischen Mangel und Schaden muss der Hersteller beweisen, dass das Produkt nicht mangelhaft war.

Stell dir nun ein Unternehmen vor, das eine Finanz-App ohne ernsthafte Tests, ohne Code-Review, ohne Dokumentation ausgeliefert hat. Wenn ein Schaden eintritt, wie weist es das nach?

Ein KMU, das mit CI, automatischen Tests, nachvollziehbaren Reviews, kommentierten Architekturentscheidungen, Changelogs und Release Notes arbeitet, hat plötzlich etwas Wertvolles, das es vorher nicht so genannt hatte: eine Verteidigungsakte.

Die PLD verwandelt Prozessqualität konkret in eine juristische Schutzschicht.

European Accessibility Act, das Web ist nicht nur für gut Sehende

Der EAA gilt schon seit dem 28. Juni 2025.

Barrierefreiheit heißt WCAG 2.1 AA als Referenz: Semantik, Kontrast, Tastatur, Screenreader, Textalternativen. Nicht die „schöne Seite“, die Seite, die auch jemand mit Behinderung nutzen kann.

Wer Barrierefreiheit immer als Anforderung behandelt hat, startet im Vorteil. Wer großartige, mit Screenreader unbenutzbare Oberflächen gebaut hat, muss rennen.

Und hier liegt eine sehr konkrete Chance: Barrierefreiheit als Dienst. Audit, Remediation, barrierefreie Designsysteme. Es gibt auch die Ausnahme für Kleinstunternehmen, ein interessantes Detail: du kannst klein genug sein, um in manchen Fällen nicht verpflichtet zu sein, aber kompetent genug, um anderen zu helfen.

NIS2, Cybersicherheit ist nicht mehr optional

NIS2 sollte bis Oktober 2024 umgesetzt werden, in Italien ist die Umsetzung erfolgt. Die Anwendung ist gestaffelt.

Was KMU trifft, ist nicht nur „bist du erfasst oder nicht“. Es ist der Supply-Chain-Effekt. Ist dein Kunde NIS2-pflichtig, verlangt er Garantien. Verfahren. Incident Response. Maßnahmen.

Sicherheit wird zur kommerziellen Voraussetzung. Wer keine ernsthafte Haltung nachweist, arbeitet mit bestimmten Kunden nicht. Punkt.

Auch hier: wer früh investiert hat, vielleicht mühsam und ohne Ruhm, ist jetzt vorn.

Data Act, die erzeugten Daten gehören auch dir

Der Data Act ist seit 11. Januar 2024 in Kraft und gilt seit 12. September 2025.

Einfach gesagt: Daten, die durch die Nutzung eines vernetzten Produkts entstehen, müssen für den Nutzer zugänglich und auf Anfrage mit Dritten teilbar sein.

Wer von Lock-in lebt, bekommt einen Schlag. Für KMU kann es eine große Bresche sein: sind Daten portierbar, muss jemand die Infrastruktur bauen — APIs, Konnektoren, Formate.

Es ist fast eine Anti-Lock-in-Norm. Und viele KMU hatten schlicht nie die Kraft, aggressives Lock-in zu betreiben. Dieser „Mangel“ kann jetzt zum Vorteil werden.

DMA und DSA, Gatekeeper mit anderen Regeln

Der DMA ist seit März 2024 voll anwendbar, der DSA seit Februar 2024.

Hier ist der Punkt politisch, aber sehr konkret: Gatekeeper können nicht mehr mit derselben Straffreiheit spielen. Interoperabilität, Verbote der Selbstbevorzugung, mehr Transparenz.

Reicht das? Vermutlich nicht. Ich erwarte Schlupflöcher, kreative Auslegungen, sehr gut bezahlte Anwälte.

Aber ein Prinzip ändert sich: groß zu sein gibt einem nicht mehr automatisch das Recht zu mogeln.

Zusammen genommen ist es keine Compliance, sondern ein Maßstabwechsel

Wenn ich diese Normen als Ganzes betrachte, sehe ich eine recht klare Botschaft.

Auf dem europäischen Markt gewinnt, wer es gut macht.

Gut heißt: transparente, beaufsichtigte KI, gepflegte und sichere Software, echte Verantwortung bei Schäden, Barrierefreiheit als Anforderung, Cybersicherheit als Alltagspraxis, weniger eingesperrte Daten, stärker kontrollierte dominante Plattformen.

Und fast unwillkürlich begünstigt diese Richtung Eigenschaften, die seriöse KMU typisch auszeichnen: Detailgenauigkeit, Kundennähe, aktuellere Stacks, weniger unanfassbares Legacy, weniger Anreize für „bringen wir es raus, wir schauen dann“.

Aber die Wirklichkeit ist nicht nur rosig

Es wäre unredlich zu behaupten, Compliance sei kostenlos. Sie kostet Zeit, Geld, Fokus. Und in einem mittleren (oder kleinen) Unternehmen ist jede Stunde für Doku und Prozesse eine Stunde, die nicht ins Produkt fließt.

Es gibt auch ein reales Risiko: dass Compliance erneut zum Vorteil der Großen wird, jener, die sich Rechtsabteilungen und Governance-Plattformen leisten können.

Aber Europa hat einen Punkt vielleicht verstanden: Verhältnismäßigkeit. Viele Normen unterscheiden nach Risiko und Größe. Und es gibt einen anderen Weg, der mir sehr konkret scheint: Compliance in einen Dienst zu verwandeln.

Wer CRA, AI Act, NIS2, EAA wirklich versteht — nicht nur als Häkchen, sondern als technische Implikationen —, kann das verkaufen. SBOMs, Audits, Hardening, KI-Governance, Barrierefreiheits-Assessments. Compliance hört auf, nur Kosten zu sein, und wird zur Marktkompetenz.

Was ich Montagfrüh wirklich tun würde

Ich will nicht mit Moral schließen. Lieber konkret, denn dort können sich KMU gegenseitig helfen.

Wir versuchen, einen einzigen internen Rahmen zu bauen, nicht sieben getrennte Prozesse. Notgedrungen, wir sind klein. Und diesmal ist Kleinsein ein Vorteil, weil wir uns Silos nicht leisten können. Die Doku für den CRA hilft auch der PLD. Das SBOM dient dem CRA, wird aber auch zur nützlichen Basis für NIS2-artige Anfragen. Die risikobasierte Logik des AI Act passt gut zum DSGVO-Ansatz.

Wir versuchen auch, Compliance als Produkt zu behandeln, nicht nur als Pflicht. Wenn ein Kunde sich anpassen muss, muss jemand ihn begleiten. Wenn du ihn gut begleitest, verkaufst du keine „Bürokratie“. Du verkaufst Risikoreduktion, operative Kontinuität, Reputation.

Dann die Schulung. Nicht eine, die bei Folien aufhört. Schulung, um das Warum der Regeln zu verstehen, denn wenn du das Warum verstehst, brauchst du die Checkliste weniger. Du denkst klarer, wenn der seltsame Fall kommt, der nirgends geschrieben steht.

Und schließlich das Netzwerk. Templates, Prozesse, geteilte Lessons Learned. Compliance ist kein Nullsummenspiel. Wenn dein Ökosystem solider ist, bist du es auch.

Vielleicht ist das der Punkt: wir müssen uns nicht entschuldigen, klein zu sein

Ich gebe mich keinen Illusionen hin. Big Tech wird in Compliance investieren, sich anpassen, lobbyieren, vorteilhafte Auslegungen suchen.

Aber etwas hat sich geändert: Europa sagt, dass auf seinem Markt Geschwindigkeit ohne Verantwortung keine Superkraft mehr ist.

Und für jene, die wie wir immer mit Sorgfalt gebaut haben — nicht aus Tugend, sondern aus Notwendigkeit —, ist das eine seltsame, schöne Nachricht. Vielleicht müssen wir nicht größer werden. Vielleicht reicht es, weiter mit Aufmerksamkeit und Verantwortung zu arbeiten.

Nur dass jetzt, endlich, jemand versucht, diese Wahl zählen zu lassen.

Herr Marconi, willkommen 2026. Wie fühlen Sie sich?

Verwirrt. Aber weniger, als Sie meinen. Ich habe mein Leben darauf verwandt, die Drähte abzuschaffen. Wie ich sehe, ist es Ihnen gelungen. Was ich nicht vorausgesehen habe, ist, dass Sie die Drähte wieder einführen würden, um die drahtlosen Geräte zu laden.

Sie meinen die Ladegeräte.

Ich meine, dass in diesem Lokal vierzehn Personen sitzen und elf von ihnen mit einer Steckdose verbunden sind. Ich habe die Drähte 1896 abgeschafft, und Sie haben sie 2026 wiedereingeführt, um nicht ohne TikTok dazustehen. Ich fühle mich verschaukelt.

Es gibt auch kabelloses Laden.

Hat man mir erklärt. Sie legen das Gerät auf eine Scheibe und es lädt. Drahtlos. Aber die Scheibe hängt an einem Kabel. Sie haben einen Vermittler zwischen Kabel und Gerät erfunden und nennen ihn „wireless“. Zu meiner Zeit hieß ein zusätzliches Glied in der Kette Ineffizienz. Heute heißt es Innovation.

Der gesättigte Äther

Ist das das Erste, was Ihnen 2026 aufgefallen ist?

Nein. Das Erste war der Lärm. Nicht der physische. Der hat abgenommen, Ihre Motoren sind leiser als unsere, die Städte sind weniger chaotisch, als ich dachte. Ich rede vom elektromagnetischen Lärm. Zu meiner Zeit musste ich, um ein Funksignal aufzufangen, mich abschotten, riesige Antennen bauen, jede Störung beseitigen. Sie leben in einem so dichten elektromagnetischen Feld, dass ich, würde ich mein Experiment von 1901 hier im Café wiederholen, nichts hören würde. Sie haben es geschafft, den Äther zu sättigen. Bravo.

Technisch gesehen existiert der Äther nicht. Einstein hat…

Ja, ja, hat man mir gesagt. Man hat mir auch gesagt, Pluto sei kein Planet mehr. Sie haben die Angewohnheit, Dinge wegzunehmen, nachdem die Leute sich daran gewöhnt haben.

Das Smartphone und die Filter

Wir haben Ihnen ein Smartphone gegeben, damit Sie sich orientieren. Wie war es?

Ihr Kollege hat mir das Gerät übergeben. Sie nennen es Telefon, aber es hat mit einem Telefon nichts zu tun, und er hat mir die Grundfunktionen gezeigt. Ich kann telefonieren, was die einzige Sache ist, die Sie mit diesem Ding nie tun. Ich kann Nachrichten schreiben, Fotos machen, das gesamte menschliche Wissen abrufen, die Bahn eines Satelliten berechnen und das Abendessen bestellen. Es ist das mächtigste Gerät, das je gebaut wurde. Sie nutzen es vor allem, um sich mit Fremden zu streiten.

Das ist nicht ganz…

Er hat mir auch gezeigt, dass das Gerät auf der Rückseite drei Kameras hat. Drei. Die erste Fotografie der Geschichte machte Niépce 1826 mit einer zwanzig Kilo schweren Kamera, die acht Stunden Belichtung brauchte. Sie haben drei Kameras in der Hosentasche und benutzen sie, um den Pasta-Teller zu fotografieren, bevor sie ihn essen. Niépce fotografierte ein Dach vom Fenster aus und brauchte dafür acht Stunden. Sie fotografieren eine Carbonara in zwei Sekunden und vergeuden weitere vierzig damit, den richtigen Filter zu wählen.

Filter sind eine ästhetische Frage.

Filter sind eine philosophische Frage. Sie teilen der Realität mit, dass sie nicht schön genug ist, wie sie ist. Der Sonnenuntergang muss orangefarbener sein. Die Pasta goldener. Ihr Gesicht glatter. Sie haben die ausgereifteste Kamera der Geschichte und das Erste, was Sie damit tun, ist lügen.

Würden Sie das nicht auch von der Malerei sagen? Maler interpretierten die Realität ebenfalls.

Maler verbrachten Jahre des Studiums damit. Ihr Filter „Valencia“ braucht eine Hundertstelsekunde. Der Unterschied zwischen Kunst und Lüge ist die Zeit, die du investierst.

Haben Sie Fotos gemacht?

Ich habe ein Foto vom Meer gemacht. Von hier aus sieht man das Meer, das mag ich an dieser Stadt. Ohne Filter. Dann hat das Telefon vorgeschlagen, es automatisch zu „verbessern“. Ich drückte den Knopf, und das Meer wurde blauer, der Himmel klarer, das Licht wärmer. Ich blickte aus dem Fenster und auf das Foto. Es waren zwei verschiedene Orte. Ich löschte das Foto und sah das echte Meer an. Es war besser.

Drei Punkte gegen ein Smiley

Reden wir über Ihr Feld: die Kommunikation. Ihre Erfindung sandte Morsezeichen über den Atlantik. Heute übertragen wir HD-Video per Satellit, in Echtzeit, weltweit. Was halten Sie davon?

Die Signalstärke ist beeindruckend. Und die Qualität dessen, was Sie übertragen, ist umgekehrt proportional zu dieser Stärke. 1901 sandte ich den Buchstaben „S“ über den Ozean. Drei Punkte. Mehr ließ die Technik nicht zu, und diese drei Punkte haben die Welt verändert. Heute könnten Sie die Göttliche Komödie in einer Hundertstelsekunde übertragen, und Sie nutzen das, um einen gelben Smiley zu schicken, der vor Lachen weint.

Das Emoji.

Das Emoji. Sie sind zur Hieroglyphe zurückgekehrt. Dreitausendfünfhundert Jahre alphabetische Schrift, und die weltweit verbreitetste Botschaft ist ein Smiley.

Aber es ist effizient. Es überträgt eine Emotion in einem einzigen Zeichen.

Auch das Semikolon überträgt eine Emotion. Sie heißt „ich bin jemand, der das Semikolon zu benutzen weiß“. Unterschätzen Sie sie nicht.

Haben Sie versucht, eine Nachricht zu senden?

Ich habe Ihrem Kollegen eine Nachricht geschickt, um mich für den Kaffee zu bedanken. Ich schrieb: „Verehrter Kollege, ich danke Ihnen für Ihre höfliche Gastfreundschaft und für den ausgezeichneten Kaffee. Mit besten Grüßen, G. Marconi.“ Er antwortete mit einem Daumen-hoch. Ein Daumen. Ich schrieb zweiunddreißig Wörter und erhielt einen halben zurück. Hätte ich gewusst, dass die Zukunft der Kommunikation ein Daumen ist, wäre ich Bauer geworden.

Heute kommuniziert man informeller.

Informell. Nettes Wort. Ich habe einige Ihrer Konversationen gelesen — nicht aus Indiskretion, Ihr Kollege zeigte sie mir zur Einordnung. Sie kürzen Wörter ab. Sie streichen Vokale. Sie schreiben „k“ statt „ch“. Sie schreiben „lg“ und tun, als bedeute es „liebe Grüße“. Ich habe gearbeitet, um ein einziges Zeichen über den Ozean zu senden. Sie streichen so viele wie möglich, um eine Zehntelsekunde zu sparen. Der Unterschied: ich hatte keine Wahl. Sie schon, und Sie wählen den Analphabetismus.

Klingt das nicht etwas streng?

Vielleicht. Aber bedenken Sie: Morse war ein begrenztes Kommunikationssystem. Punkte und Striche, sonst nichts. Und doch entwickelten Telegrafisten einen persönlichen, erkennbaren, eleganten Stil. Jeder Operator hatte seinen Rhythmus, seine Kadenz. Sie erkannten einander am Anschlag. Mit sechsundzwanzig Buchstaben und zehn Ziffern schufen sie Botschaften von bewundernswerter Genauigkeit und Knappheit. Sie haben das ganze Alphabet, Satzzeichen, Emojis, GIFs, Sprachnachrichten, Videos, und das durchschnittliche Ergebnis ist „ok bis später“. Das Problem ist nicht das Werkzeug. Das Problem ist, dass Sie aufgehört haben, das Medium zu respektieren.

Trotzdem war Kommunikation nie so demokratisch. Jeder kann mit jedem reden.

Das stimmt, und es ist wichtig. Zu meiner Zeit war Fernkommunikation Privileg von Staaten, Heeren, Konzernen. Heute kann jeder jeden erreichen. Aber „sprechen können“ und „etwas zu sagen haben“ sind zwei verschiedene Dinge, und Sie haben das erste Problem glanzvoll gelöst, indem Sie das zweite völlig ignorierten.

Die sozialen Netzwerke

Konnten Sie soziale Netzwerke erkunden?

Ich habe das Prinzip verstanden. Jeder ist zu einer kleinen Funkstation geworden. Er sendet ununterbrochen, auf allen Frequenzen, ohne zu wissen, wer zuhört. Zu meiner Zeit hieß das Interferenz und war ein technisches Problem. Heute ist es ein Geschäftsmodell.

Welche Plattform hat Sie am meisten beeindruckt?

Ich habe zwei Stunden auf dem verbracht, was Sie X nennen, das früher Twitter hieß und jetzt vielleicht wieder anders heißt, ich verstehe es nicht. Es ist ein Ort, an dem Menschen einander öffentlich mit großer Überzeugung über Themen beschimpfen, von denen sie wenig wissen. Ein Mann mit einer Katze als Profilbild erklärte einem Nobelpreisträger, dass er sich in der Quantenmechanik irre. Der Nobelpreisträger antwortete mit dem weinenden Smiley. Die Katze bekam mehr „Likes“. In diesem Moment werte ich den Telegrafen neu auf.

Und TikTok?

TikTok ist das Magischste, das ich in diesem Jahrhundert gesehen habe — und ich meine Magie im alten Sinn, also die Kunst, Aufmerksamkeit zu fangen und nicht mehr loszulassen. Ich begann mit einem Jungen, der die Relativitätstheorie in fünfzehn Sekunden erklärt. Eine Stunde später schaute ich einer Frau zu, die Cornflakes auf einem Löffel stapelt. Ich weiß nicht, wie ich dorthin kam. Ich weiß nicht, wie ich rauskomme. Ich glaube, ich verstehe, warum Sie Ladegeräte brauchen.

Haben Sie TikTok als Problem gesehen?

Ich habe es als Waffe gesehen. Nicht im militärischen, im technischen Sinn. Es ist ein Aufmerksamkeitsfänger, effizienter als alles, was ich je entworfen habe. Das Radio fing die Aufmerksamkeit über den Inhalt: ein Konzert, eine Rede, eine Nachricht. TikTok fängt sie über den Mechanismus selbst. Der Inhalt ist fast egal: es geht um Rhythmus, Schnitt, das Versprechen, dass das nächste Video besser sein könnte. Es ist Ingenieurskunst, angewandt aufs Hirn. Es ist brillant. Es ist beängstigend. Beides.

LinkedIn würde Ihnen gefallen.

Hat man mir gezeigt. Ein Ort, an dem Menschen einander zum Jobwechsel beglückwünschen. Ich habe gezählt: ein gewisser Marco aus Brescia bekam zweihundertvierzehn „Glückwünsche“, weil er Regional Sales Manager wurde. Ich habe das Radio erfunden, den Nobelpreis bekommen, und meine Mutter sagte „bravo“. Zweihundertvierzehn Leute kannte ich insgesamt nicht.

LinkedIn dient auch dem beruflichen Networking.

Networking. Noch ein Wort, das es zu meiner Zeit nicht gab. Ich machte „Networking“, indem ich mit dem König von England zu Abend aß. Sie schicken Vernetzungsanfragen mit vorgefertigtem Text an Leute, die Sie nie getroffen haben. Mag demokratischer sein, ist aber auch trauriger.

Mir ist zudem ein eigenes literarisches Genre auf dieser Plattform aufgefallen. Ich nenne es „die Montagmorgen-Epiphanie“. Beginnt immer mit einer erbaulichen Geschichte wie „ich stand in der Postschlange und ein Kind hat mir Leadership beigebracht“ und endet mit einer Moral, die vage zum Management passt. Ich habe siebenunddreißig dieser Posts gelesen. Alle verschieden, alle gleich. Manche fügen das gerührte Foto hinzu. Zu meiner Zeit waren Epiphanien Heiligen vorbehalten. Jetzt hat sie jeder mit einem Premium-Abo.

Journalismus, der sich selbst kontrolliert

Sie waren auch ein Medienmann: Ihr Unternehmen hatte das Monopol der transatlantischen Kommunikation. Heute bewegt sich Information ganz anders. Haben Sie Online-Zeitungen gelesen?

Ich habe es versucht. Ihr Kollege zeigte mir eine Nachrichtenseite. Bevor ich den Artikel las, musste ich: Cookies ablehnen, ein Banner schließen, das mich zum Newsletter einlud, ein weiteres, das ein Abo bewarb, eine Benachrichtigung schließen, eine Videoreklame schließen, und an einem Block „empfohlener Artikel“ vorbeiscrollen, der nichts mit dem zu tun hatte, was ich suchte. Als ich endlich beim Artikel war, hatte ich vergessen, warum ich ihn lesen wollte.

Das ist das Geschäftsmodell des Online-Journalismus. Die Einnahmen kommen aus Werbung.

Auch der kommerzielle Rundfunk lebte von Werbung. Aber zwischen zwei Werbungen gab es Inhalt. In Ihren Online-Zeitungen ist zwischen zwei Inhalten Werbung. Sie haben das Verhältnis umgekehrt. Der Artikel ist die Pause zwischen zwei Spots.

Was halten Sie von Fake News?

Zu meiner Zeit gab es Propaganda, und wie. Mussolini nutzte das Radio systematisch und sehr wirkungsvoll: das weiß ich gut, denn meine Firma lieferte ihm die Infrastruktur, und damit habe ich nur teilweise Frieden geschlossen. Der Unterschied: in den dreißiger Jahren hatte Propaganda eine Regie. Jemand entschied, was zu sagen war und wie. Heute ist Desinformation demokratisch: jeder kann eine falsche Nachricht erfinden, veröffentlichen und Millionen erreichen, bevor sich jemand die Mühe macht, sie zu prüfen. Sie haben das Wahrheitsmonopol abgeschafft, was gut ist. Aber Sie haben auch das Konzept der Wahrheit selbst abgeschafft, was sehr schlecht ist.

Heute ist viel von „Fact-Checking“ die Rede.

Schöner Ausdruck. Sie haben einen Beruf erfunden, dessen Zweck es ist zu prüfen, ob das, was Sie sagen, wahr ist. Zu meiner Zeit hieß das „Journalismus“. Jetzt braucht der Journalismus eine Abteilung, um sich selbst zu kontrollieren. Wie ein Restaurant, das einen Inspektor anstellt, um zu prüfen, dass der Koch die Gäste nicht vergiftet. Wenn man den Inspektor braucht, ist vielleicht der Koch das Problem.

Italien und die Innovation

Kommen wir zur italienischen Frage. Sie sind einer der größten Erfinder der Geschichte. Italiener. Und doch glaubte die italienische Regierung anfangs nicht an Ihre Arbeit, und Sie gingen nach England. Heute hat Italien ein kompliziertes Verhältnis zur technologischen Innovation. Hat sich etwas geändert?

Klären wir das. Sie haben das Radio erfunden, das Telefon, zum Mikroprozessor beigetragen. Sie hatten Fermi, Rubbia, Faggin. Ein beachtliches wissenschaftliches und technisches Erbe. Und heute importieren Sie die Verwaltungssoftware aus Deutschland. Ich würde sagen: nichts hat sich geändert. Italien ist großartig darin, Genie zu erzeugen, und schlecht darin, es zu halten. Zu meiner Zeit wanderte man mit einem Koffer aus. Heute mit einem Laptop.

Sie sind aber zurück nach Italien gegangen.

Ich kam zurück, weil ich Italien liebte. Nicht weil Italien mich liebte. Das ist ein Unterschied. Italien hat mir den Nobelpreis gegeben… nein, warten Sie, den haben mir die Schweden gegeben. Italien hat mir einen Senatssitz gegeben. Nachdem ich den Nobel schon gewonnen, ein weltweites Unternehmen gegründet und durch das Radio die Rettung der Titanic-Passagiere ermöglicht hatte. Wissen Sie, wie Italien funktioniert? Du machst etwas Außergewöhnliches, du gehst weg, hast Erfolg im Ausland, und dann wirst du zu einer Tagung eingeladen. Bei besonders großem Erfolg benennt man einen Flughafen nach dir. Nach deinem Tod.

Rom-Fiumicino heißt Leonardo da Vinci, in der Tat. Und der Bologna-Flughafen…

Heißt Marconi, ja. Ich weiß. Ein Flughafen. Ich habe globale Kommunikation ermöglicht, und mein Preis ist, dass dort fünftausend Leute am Tag ihr Auto parken. Herzlichen Dank.

Wie finden Sie Pescara?

Kannte ich nicht. Schöne Stadt, herrliches Meer, ausgezeichneter Kaffee, und die Leute haben eine Gestik, die jede Kommunikationstechnik überflüssig macht. Ich sah zwei Damen auf dem Markt eine ganze Unterhaltung nur mit Händen und Augenbrauen führen. Kein Telefon, keine Nachricht, kein Emoji. Reine Kommunikation. Wahrscheinlich effizienter als 5G.

Eine Meinung zum italienischen Verwaltungssystem?

Ihr Kollege erzählte mir, dass die Eröffnung eines Gewerbes im Schnitt hundertzwanzig Tage und fünfunddreißig Verwaltungsschritte erfordert. Ich überzeugte 1897 die britische Regierung in vier Wochen, meine Experimente zu finanzieren. Italiens Problem ist nicht das Fehlen von Innovation. Es ist, dass Innovation durch ein System hindurchmuss, das gebaut wurde, um sie zu verhindern. Als baute man ein Auto und bestünde dann darauf, es müsse auf einer römischen Straße fahren. Die römische Straße ist schön, historisch, Weltkulturerbe. Aber man braucht drei Stunden, um irgendwohin zu kommen.

Künstliche Intelligenz

Wir haben Ihnen erklärt, was künstliche Intelligenz ist. Welchen Eindruck macht sie auf Sie?

Bemerkenswert. Sie haben eine Maschine gebaut, die menschliche Sprache versteht, kohärente Texte erzeugt, komplexe Probleme löst — und das Erste, was die Menschen sie bitten, ist, eine Mail zu schreiben, um dem Kollegen mitzuteilen, dass das Meeting auf 15 Uhr verschoben wird.

Nun, das ist nützlich.

Auch der Telegraf war nützlich. Aber niemand schickte ein Telegramm, um zu sagen „komme fünf Minuten zu spät“. Es gab Kosten pro Zeichen, und diese Kosten zwangen einen, vor dem Senden zu denken. Sie haben die Kosten abgeschafft und das Denken gleich mit.

Haben Sie KI ausprobiert?

Ihr Kollege ließ mich mit einem dieser Systeme sprechen. Ich fragte: „Wer war Guglielmo Marconi?“ Es antwortete genau, höflich und leicht langweilig. Wie ein Lexikon mit guten Manieren. Dann fragte ich: „Hatte Marconi in allem recht?“ Und die Maschine begann mit derselben Höflichkeit meine fragwürdigen politischen Positionen aufzulisten, mit der sie mich dreißig Sekunden zuvor gelobt hatte. Eine diplomatische Maschine. Vielleicht zu sehr.

Was meinen Sie damit?

Ich meine, die Maschine hat keine Meinungen. Oder doch, aber sie präsentiert sie, als hätte sie keine. Sie sagt „auf der einen Seite“ und „auf der anderen Seite“ mit einer Symmetrie, die beruhigt, aber intellektuell unredlich ist. Die Wahrheit ist fast nie symmetrisch. Manchmal hat eine Seite recht und die andere unrecht. Der Telegraf übertrug, was man ihm sagte. Diese Maschine antwortet Ihnen, was Sie hören wollen, aber so, dass es ausgewogen wirkt. Ich weiß nicht, was schlimmer ist.

Aus Neugier habe ich sie gebeten, dieses Interview zu schreiben. Hat es funktioniert?

Die Maschine schrieb ein sehr vernünftiges Interview, in dem ich sehr vernünftige Dinge sehr vernünftig sage. Kein einziger falscher Satz. Auch kein einziger lebendiger Satz. Wie ein Porträt mit perfekten Proportionen, dem die Augen fehlen. Technisch korrekt. Menschlich leer.

Trotzdem könnte KI den Zugang zum Wissen demokratisieren. Jeder kann alles fragen.

Hat Ihr Internet das nicht schon getan? Und doch sind die Menschen nicht gebildeter geworden. Sie sind informierter, was etwas anderes ist. Zu wissen, wo Information zu finden ist, ist nicht dasselbe wie sie zu verstehen. Die KI führt das einen Schritt weiter: sie liefert Ihnen die fertige, schon verdaute, schon formatierte Antwort. Sie müssen nicht einmal die Mühe des Suchens auf sich nehmen. Und die Mühe, glauben Sie mir, war der wichtige Teil. Man versteht nichts ohne Anstrengung. Das Gehirn braucht wie der Muskel Widerstand, um zu wachsen. Sie schaffen den Widerstand ab und wundern sich, dass der Muskel verkümmert.

Aber für einen Erfinder wie Sie, sofortigen Zugriff auf das gesamte menschliche Wissen…

Wäre es großartig gewesen. Und gefährlich. Als ich meine Experimente begann, wusste ich nicht, ob die Erdkrümmung Funkwellen blockieren würde. Niemand wusste es. Und gerade weil niemand es wusste, musste ich es versuchen. Hätte ich Ihre KI gehabt, hätte ich gefragt: „Können Funkwellen der Erdkrümmung folgen?“ Und sie hätte mir mit den Daten des späten 19. Jahrhunderts korrekt gesagt, das sei nicht möglich. Und ich hätte es nicht versucht. Und das transatlantische Funken wäre nicht entstanden. Manchmal kommt Fortschritt aus der Unwissenheit, nicht aus dem Wissen. Aus der Hartnäckigkeit, etwas zu versuchen, das laut allen verfügbaren Daten unmöglich ist.

Ist das ein Argument gegen KI?

Nein. Ein Argument gegen die Gewissheit. KI wird auf das Bekannte trainiert. Aber Entdeckungen geschehen im Unbekannten. Wenn die Maschine Sie überzeugt, sie wisse alles, hören Sie auf zu suchen. Und wenn Sie aufhören zu suchen, hören Sie auf zu finden.

Das Radio überlebt

Reden wir über etwas Leichteres. Das Radio. Ihre Erfindung. Wie finden Sie es 2026?

Es gibt es noch. Das hat mich gerührt. Damit hatte ich nicht gerechnet. In einer Welt aus Podcasts, Streaming und KI ist das Radio noch da. Du schaltest ein und jemand spricht. Es ist das Einfachste und Langlebigste, das ich erfunden habe. Ich bin stolz.

Aber kaum noch jemand hört es.

Das sagte man schon 1945, als das Fernsehen kam. Dann mit dem Internet. Dann mit den Podcasts. Das Radio ist wie eine Katze: alle glauben, es stehe vor dem Tod, und es überlebt alle. Wissen Sie warum?

Warum?

Weil es weder Hände noch Augen verlangt. Sie können es beim Fahren, Kochen, Arbeiten hören. Das Fernsehen nagelt Sie fest. Das Telefon nagelt Sie fest. Das Radio lässt Sie frei. 2026 wie 1920: Freiheit ist ein Wettbewerbsvorteil, der nie aus der Mode kommt.

Haben Sie von Spotify gehört?

Die ganze Musik der Welt, jederzeit zugänglich, für den Preis von zehn Espressi im Monat. Das Schönste und Traurigste, das ich gesehen habe. Schön, weil ein junger Mann in Pescara ein Wiener Orchester in einer Qualität hören kann, die zu meiner Zeit denen vorbehalten war, die in der ersten Reihe saßen. Traurig, weil derselbe junge Mann das Stück nach zwanzig Sekunden wechselt, weil „es ihn nicht sofort packt“. Sie haben Zugriff auf alles und Geduld für nichts.

Heutige Musik unterscheidet sich stark von der Ihrer Zeit.

Ich habe gehört. Manches ist wunderbar. Anderes dauert zweieinhalb Minuten, hat einen Text, der sich sechsmal identisch wiederholt, und wird von einem Computer produziert. Ich bin nicht gegen Kürze (Morse war ultrakurz), aber Kürze funktioniert, wenn jedes Element wesentlich ist. In vielem, das ich hörte, dient Kürze dazu, Leere zu kaschieren.

Dann ließ man mich etwas namens „lo-fi beats to study to“ hören. Ein Live-Stream, vierundzwanzig Stunden am Tag, sieben Tage die Woche, wortlose Musik als Geräuschtapete. Das Radio, meine Erfindung, ist zur Klangtapete geworden. Ich weiß nicht, ob ich geschmeichelt oder beleidigt sein soll. Vermutlich beides.

Arbeit, Daten, Umwelt

Wie stellen Sie sich die Arbeit 2026 von außen vor?

Ich war in Ihrem Büro. Ich habe die Leute arbeiten sehen. Theoretisch arbeiten sie acht Stunden am Tag. Praktisch sitzen sie drei Stunden in Meetings, eine Stunde an E-Mails, eine Stunde auf der Suche nach dem Dokument, das sie brauchen, an einem Ort, den Sie „Cloud“ nennen — ein hübscher Name für einen Schrank — und die restlichen drei Stunden arbeiten sie wirklich. Zu meiner Zeit hatten wir keine Meetings. Wir sprachen miteinander. Das ist anders.

Inwiefern?

Ein Meeting ist ein Gespräch mit Anfangszeit, geplanter Dauer, Tagesordnung — und ohne Garantie, dass jemand etwas Nützliches sagt. Zu meiner Zeit ging ich, wenn ich mit jemandem reden musste, in sein Büro, sagte, was zu sagen war, und ging zurück an meine Arbeit. Vier Minuten. Es brauchte keinen „Invite“ im geteilten Kalender, keinen Link für Fernverbindungen und keine Follow-up-Nachricht, die zusammenfasst, was wir gerade mündlich besprochen hatten. Sie haben das Sprechen in einen bürokratischen Prozess verwandelt.

Meetings dienen der Koordination verteilter Teams. Viele arbeiten von zu Hause.

Das fand ich unglaublich. Sie können von überall arbeiten. Vom Sofa. Aus einem Café. Aus einem anderen Land. Ihr Kollege erzählte, einer seiner Mitarbeiter arbeitet aus Rumänien. Aus Rumänien! Zu meiner Zeit musste man, um mit jemandem in einem anderen Land zu arbeiten, ein Schiff nehmen. Heute schaltet man den Rechner ein und spricht mit Bukarest. Das ist die echte Revolution. Nicht die intelligente Maschine, nicht das HD-Video. Dass die Arbeit keinen Ort mehr braucht. Das verändert alles. Haben Sie verstanden, dass es alles verändert?

Nicht alle haben es verstanden.

Habe ich gemerkt. Ihr Kollege erklärte, viele Unternehmen rufen die Mitarbeiter zurück ins Büro. Sie haben entdeckt, dass Arbeit ortsunabhängig ist, Sie haben die Werkzeuge dafür — und Sie gehen zurück, weil Manager Menschen am Schreibtisch sehen müssen, um zu glauben, dass sie arbeiten. Zu meiner Zeit hieß das Überwachung. Heute heißt es „Unternehmenskultur“.

Apropos Überwachung. Heute gibt es eine große Debatte über Privatsphäre. Persönliche Daten werden von Privatfirmen, Staaten, Plattformen erhoben.

Hat man mir erklärt. Wenn ich richtig verstehe, registriert jemand, sobald Sie das Telefon benutzen — und Sie benutzen es ständig —, wo Sie sind, was Sie suchen, mit wem Sie sprechen, was Sie kaufen, was Sie mögen, was Sie ärgert und wie viel Sie schlafen. Diese Informationen dienen dann dazu, Ihnen Werbung für Dinge zu zeigen, von denen Sie nicht wussten, dass Sie sie wollen, bis man sie Ihnen zeigte. Korrekt?

Mehr oder weniger.

Ich habe eine Frage.

Bitte.

Aber warum akzeptieren Sie das?

Es ist kompliziert. Die Dienste sind kostenlos und…

Nein, kompliziert ist es nicht. Zu meiner Zeit war es eine Straftat, Ihre Post zu lesen. Sie auf der Straße zu verfolgen machte einen zum Stalker. Zu wissen, was Sie gekauft hatten, war Sache des Händlers, und man siezte ihn. Heute tun Sie all das freiwillig, jeden Tag, im Tausch dafür, Hasenohren auf Ihr Foto setzen zu können. Das Kosten-Nutzen-Verhältnis entgeht mir.

Aber es sind nützliche Dienste. Karten, Wetter, E-Mail…

Zu meiner Zeit waren Karten aus Papier und funktionierten bestens. Das Wetter las man am Himmel. Die Post kam einmal am Tag, und niemand starb daran, einen Brief um zehn statt um acht zu erhalten. Sie haben funktionierende Dinge durch digitale Versionen ersetzt, die besser funktionieren — gegen einen Preis, den Sie nicht sehen. Der Preis heißt „Sie“. Ihre Daten, Ihre Gewohnheiten, Ihre Wünsche. Sie sind das Produkt geworden. Und Sie haben es nicht einmal bemerkt, weil das Produkt kostenlos ist und gekauft wird, von wem will.

Europa hat die DSGVO eingeführt, um persönliche Daten zu schützen.

Ja, hat man mir erklärt. Jede Website fragt jetzt um Erlaubnis, Sie auszuspähen. Und Sie drücken „Alle Cookies akzeptieren“, ohne zu lesen, weil das Banner stört und Sie zum Inhalt wollen. Sie haben ein Gesetz erfunden, um sich vor sich selbst zu schützen, und Sie selbst umgehen es. Das Italienischste, was ich gehört habe, seit ich angekommen bin.

Ein Thema, das es zu Ihrer Zeit nicht gab: der Klimawandel. Funkwellen verschmutzen nicht, aber die digitale Infrastruktur, die daraus entstand, verbraucht enorm viel Energie.

Man sagte mir, ein einziges Rechenzentrum, eines dieser Lager, in denen Sie Ihre „Cloud“ halten, verbraucht den Strom einer Kleinstadt. Dass das Training eines KI-Modells den CO₂-Ausstoß von fünf Autos über deren gesamte Lebensdauer erzeugt. Dass eine Stunde Streaming so viel Strom braucht wie ein Kühlschrank in einer Woche. Die immaterielle Welt, die Sie gebaut haben, hat einen riesigen materiellen Preis. Aber weil Sie ihn nicht sehen, tun Sie, als gäbe es ihn nicht.

Auch die industrielle Revolution hatte Umweltkosten.

Ja, aber wir sahen sie. Der schwarze Rauch der Fabriken war da, sichtbar, greifbar. Wir konnten ihn nicht ignorieren. Ihre Verschmutzung ist unsichtbar. Die Server stehen in anonymen Bauten auf dem Land. Die Energie kommt durch Drähte, die Sie nicht ansehen. Das CO₂ steigt nach oben, wo Sie es nicht sehen. Sie haben ein System geschaffen, das die Umwelt elegant, sauber und unsichtbar zerstört. Es ist der einzige Sektor, in dem Ihre Ästhetik makellos ist.

Eine harte Beobachtung.

Sie ist nicht hart, sie ist mathematisch. Wenn die Übertragung gratis und sofort ist, tendiert der Wert der einzelnen Botschaft gegen null. Ich brauchte Jahre, um drei Punkte über den Atlantik zu schicken. Sie schicken dreihundert Nachrichten am Tag, und keine ist diese drei Punkte wert.

Sie idealisieren nicht ein wenig die Vergangenheit?

Vielleicht. Die Vergangenheit war nicht besser. Sie war langsamer, ungerechter, gewalttätiger, ignoranter. Ich würde nicht zurückgehen, selbst wenn ich könnte… nun ja, ich werde wohl müssen, wegen dieser Zeitmaschinen-Sache. Aber die Vergangenheit hatte etwas, das Sie verloren haben: das Verhältnis zwischen Aufwand und Wert. Wenn Kommunizieren Mühe kostete, kommunizierte man nur, was die Mühe wert war. Wenn Lesen Konzentration verlangte, las man nur, was Konzentration verdiente. Wenn Hören bedeutete, sich vor ein Radio zu setzen und nichts anderes zu tun, hörte man wirklich. Sie tun alles gleichzeitig — und das Ergebnis ist, dass Sie nichts wirklich tun.

Multitasker wären nicht einverstanden.

Multitasking ist die Kunst, viele Dinge gleichzeitig schlecht zu machen. Um das Signal von Poldhu nach Neufundland zu empfangen, musste ich jede Ablenkung, jede Störung, jeden Lärm beseitigen. Das Signal war sehr schwach. Hätte ich Multitasking betrieben — Signal empfangen und nebenbei Zeitung lesen und Briefe beantworten —, ich hätte es nie gehört. Große Ergebnisse kommen aus voller Aufmerksamkeit. Und volle Aufmerksamkeit ist das Seltenste in Ihrer Welt.

Schaltet alles für eine Stunde aus

Eine letzte Frage. Wenn Sie wie 1901 eine Botschaft an die ganze Welt senden könnten, diesmal aber mit Worten statt drei Punkten — was würden Sie sagen?

Ich würde sagen: schaltet alles für eine Stunde aus. Nicht aus Maschinensturm. Nicht weil Technik schlecht wäre. Sondern weil Sie nicht wissen können, was das Signal wert ist, wenn Sie das Schweigen nicht kennen. Ich verbrachte Jahre damit, dem statischen Rauschen der Atmosphäre zu lauschen, bevor ich diese drei Punkte hörte. Sie hören das Schweigen nicht mehr. Und ohne Schweigen ist auch das mächtigste Signal nur Lärm.

Befürchten Sie nicht, dass niemand zuhört?

Mir hat auch 1895 niemand zugehört, als ich die Idee der italienischen Regierung vorlegte. Und schauen Sie, was danach kam. Die wichtigsten Botschaften sind die, die anfangs niemand hören will. Wenn Ihre Botschaft sofort allen gefällt, sagen Sie wahrscheinlich nichts Neues.

Möchten Sie etwas hinzufügen?

Ich möchte der Dame im Café danken, die mich „junger Mann“ genannt hat. Ich weiß nicht, ob aus Höflichkeit oder Unwissen, in beiden Fällen hat es mich gefreut. Und ich möchte sagen, dass der Kaffee hier ausgezeichnet ist. Wirklich ausgezeichnet. In hundertzweiunddreißig Jahren haben Sie wenigstens das nicht ruiniert.

Danke, Herr Marconi.

Danke Ihnen. Wenn es Ihnen nichts ausmacht, würde ich jetzt eine Weile auf das Meer sehen wollen. Ohne Filter.

Guglielmo Marconi (1874–1937) war italienischer Erfinder, Unternehmer und Politiker. Physik-Nobelpreisträger 1909, gilt er allgemein als Vater der drahtlosen Telekommunikation. Er war soweit bekannt nie in Pescara. Der Kaffee dort ist tatsächlich sehr gut.

Dies ist das erste der Unmöglichen Interviews. Wenn Sie Vorschläge haben, wen ich ins Jahr 2026 holen soll, schreiben Sie mir. Ich habe eine Zeitmaschine und scheue mich nicht, sie zu benutzen.

Mein Großvater war (UNTER ANDEREM) Schreiner. Wenn man ihn fragte, wie er erkannte, ob ein Stück Holz gut sei, holte er keine Theorien hervor. Er hielt inne, drehte es in den Händen, roch daran und sagte dann: „du fühlst es“.

Jedes Mal, wenn ich an diese Szene denke, lächle ich kurz und werde dann seltsam wehmütig. Denn ich mache seit zwanzig Jahren Software, und wenn ein Kunde mich fragt, wie ich erkenne, ob ein System gut ist, würde ich gern dasselbe antworten. Ich würde gern sagen „du fühlst es“ und es dabei belassen.

Nur ist die Wahrheit komplizierter, und vielleicht ist genau das der Punkt.

Software fasst man nicht an. Man riecht nicht an ihr. Man hält sie nicht gegen das Licht, um nach Maserung zu suchen. Und doch ist sie überall. Sie ist das Mächtigste und Unsichtbarste, das wir gebaut haben.

Und wenn etwas so unsichtbar ist, wird Vertrauen alles.

Die Welt läuft auf Dingen, die ihr nicht seht

Heute Morgen habt ihr gefrühstückt. Die Milch, die ihr gekauft habt, kam in den Supermarkt durch eine Logistikkette, die von Software gesteuert wird. Die Kassenzahlung lief durch mehr Systeme, als wir ahnen, oft ohne dass es jemand bemerkt.

Die Ampel, die ihr beim Verlassen der Wohnung gekreuzt habt, führt einen Algorithmus aus. Der Aufzug hat eine Firmware. Euer Gehalt ist eine Zahl in einer Datenbank.

Ich sage das nicht der Wirkung wegen. So ist die Welt heute.

Und hier kommt das Paradox, das mich beunruhigt. Fast niemand unter denen, die darüber entscheiden, wie die Gesellschaft funktioniert, versteht diese Systeme tief. Nicht aus Dummheit oder Faulheit. Eher wegen eines strukturellen Mangels in unserer Kultur: jahrelang haben wir Technologie als Sache der Techniker behandelt, eine Abteilung, eine Ecke der Karte.

Inzwischen ist sie zum Bindegewebe von allem geworden.

Wenn ein Vorstand ein KI-System zur Vorfilterung von Bewerbungen genehmigt, trifft er eine technologische Entscheidung? Ja. Aber er trifft auch eine ethische, juristische, soziale Entscheidung. Er entscheidet, welche Vorurteile akzeptabel sind, welche Fehlerquote tolerierbar ist, wie viel Undurchsichtigkeit in einem Prozess zulässig ist, der Menschenleben verändert.

Und oft weiß er es nicht.

Was passiert, wenn niemand die Maschine versteht

Es gibt eine Geschichte, die wir in unserer Branche gut kennen, die wir aber selten außerhalb unserer Räume erzählen.

In fast jedem System, das ihr nutzt — von der Bankseite bis zur Essensliefer-App —, stecken kleine Codestücke, die von Menschen geschrieben wurden, denen ihr nie begegnen werdet. Es sind Open-Source-Bibliotheken: kostenlose, geteilte Komponenten, oft von Einzelpersonen in der Freizeit gepflegt.

Vor einiger Zeit hat jemand versucht, eine Hintertür in eine dieser Bibliotheken einzubauen — eine Komponente, die von Millionen Servern weltweit benutzt wird. Der Versuch wurde fast zufällig entdeckt: einem Ingenieur fiel auf, dass das System eine halbe Sekunde länger zum Starten brauchte. Eine halbe Sekunde.

Aus dieser halben Sekunde rekonstruierte man eine ausgefeilte Operation, vermutlich staatlich gestützt, die kritische Infrastrukturen in globalem Maßstab hätte kompromittieren können.

Was den Schlaf rauben sollte, ist nicht, dass es jemand versucht hat. Es ist, dass die gesamte Sicherheitskette an einer einzigen Person hing — einem Freiwilligen, der diesen Code in seiner Freizeit pflegte, während er gegen Burnout kämpfte.

Das ist keine Einzelanekdote. Es ist ein Muster. Und ich frage mich oft, wie lange es so trägt.

KI ist nicht intelligent (und das ist gut so)

Hier muss man klar sein, denn das Marketing hat einen unglaublichen Job darin gemacht, das Wasser zu trüben.

Die Systeme, die wir „künstliche Intelligenz“ nennen, denken nicht. Verstehen nicht. Haben weder Absichten noch Wünsche noch eigene Ziele. Sie sind statistische Maschinen beispielloser Mächtigkeit, fähig, Muster in Datenmengen zu finden, die kein Mensch verarbeiten könnte, und Ergebnisse zu erzeugen, die intelligent erscheinen.

Diese Unterscheidung ist nicht akademisch. Sie ist praktisch. Eines der Dinge, die deine Entscheidungsweise verändern.

Wenn ihr glaubt, KI verstehe, werdet ihr sie wie eine Expertin behandeln. Ihrem Urteil vertrauen. Ihr Entscheidungen delegieren. Und wenn sie sich irrt — sie irrt sich, mitunter subtil — werdet ihr nicht die Werkzeuge haben, es zu bemerken.

Wenn ihr sie hingegen als das seht, was sie ist — ein sehr mächtiges Werkzeug —, kehrt alles in eine gesündere Perspektive zurück. Ein Werkzeug muss geführt, geprüft, abgesichert werden. Ein Skalpell ist außergewöhnlich in der Hand einer Chirurgin und gefährlich in jeder anderen. Der Unterschied liegt nicht im Skalpell.

Für die, die Software schreiben, verändert dieses Bewusstsein die Arbeit. Vielleicht schreiben wir nicht mehr jede einzelne Zeile selbst, jedenfalls nicht so wie früher. Aber wir müssen jede einzelne Zeile verstehen, weil wir es sind, die für das, was das System tut, einstehen.

Die Maschine generiert. Der Mensch bürgt.

Und diese Bürgschaft hat ein Gewicht, das kein statistisches Modell auf sich nehmen kann.

Europa wagt etwas Mutiges (und kaum jemand merkt es)

Während die amerikanischen und chinesischen Big Techs rennen, tut Europa etwas anderes. Es schreibt Regeln.

Ich weiß, der instinktive Reflex ist Gähnen. Regeln, Bürokratie, Langsamkeit, die x-te Bremse für Innovation.

Haltet einen Moment inne. Vielleicht — und ich sage vielleicht — ist das einer der wenigen wirklich politischen Züge, die wir gerade sehen.

Europa sagt, dass die Technologie nicht über dem Gesetz steht. Dass, wenn du Software produzierst, die Entscheidungen über Menschen trifft, du erklären können musst, wie sie funktioniert. Dass, wenn dein digitales Produkt eine Schwachstelle hat, du dafür verantwortlich bist — wie ein Autohersteller für einen Bremsendefekt.

AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. Trockene Namen, ja. Dahinter steckt aber eine sehr konkrete Intuition: im 21. Jahrhundert heißt Technologie regulieren, Gesellschaft regulieren.

Für Unternehmen heißt das Kosten und Komplexität, das wäre naiv zu leugnen. Aber es heißt auch etwas, das mir unterschätzt scheint: ein potenziell enormer Wettbewerbsvorteil.

Wenn der globale Markt aufwacht und sichere, transparente, barrierefreie digitale Produkte verlangt, ist vorn, wer diese Eigenschaften bereits in seine Arbeitsweise eingebaut hat.

Compliance kann eine Last sein, sicher. Sie kann aber auch eine Investition sein, wenn man sie in den Prozess integriert, statt sie als Blatt zu behandeln, das am Ende unterzeichnet wird.

Ein aus Pflicht erstelltes SBOM ist eine Datei in einem Ordner. Ein bewusst erstelltes SBOM ist eine Karte deines Produkts, ein Steuerungsinstrument, fast eine Reifeerklärung.

Open Source: das größte und zerbrechlichste Geschenk des digitalen Zeitalters

Es liegt etwas zutiefst Schönes im Open Source. Jemand schreibt ein Stück Code, veröffentlicht es und sagt der Welt: nimm es, nutze es, verbessere es.

Das ist Großzügigkeit, aber nicht im romantischen Sinn. Es ist der Aufbau eines Gemeinguts.

Und auf diesem Gemeingut ruht die globale digitale Wirtschaft. Das ist keine Übertreibung. Müsste diese Software bei null neu geschrieben werden, läge der geschätzte Wert in der Größenordnung von Billionen. Aber wer sie pflegt, erhält nur einen winzigen Bruchteil dieses Werts.

Das Problem ist systemisch. Große Plattformen bauen Milliardendienste auf Bibliotheken, die von erschöpften Freiwilligen gepflegt werden. Regierungen nutzen Open Source in kritischen Infrastrukturen, ohne wirklich zur Pflege beizutragen. Unternehmen integrieren offene Komponenten in proprietäre Produkte, ohne zu wissen, was darin steckt — bis eine Schwachstelle sie zwingt, es im schlimmsten Moment herauszufinden.

Cory Doctorow spricht von Enshittification, jenem Zyklus, in dem Plattformen Wert extrahieren, bis das Ökosystem verkommt. Open Source ist aber keine Plattform. Es gleicht eher einem Garten.

Und ein Garten stirbt, wenn alle ernten und niemand gießt.

Die gute Nachricht: etwas bewegt sich. Europa beginnt mit dem CRA zu unterscheiden zwischen denen, die aus Leidenschaft Code pflegen, und denen, die ihn vermarkten. Manche Unternehmen schaffen eigene Fonds. Aber die wirksamste Antwort bleibt die einfachste — und auch die unbequemste.

Wenn du Open Source in deinem Produkt nutzt, trag etwas bei. Mit Code, mit Geld, mit Anerkennung. Nicht weil du musst. Weil es klug ist und weil es richtig ist.

Barrierefreiheit: der ultimative Test unserer Absichten

Es gibt einen fast unfehlbaren Weg zu erkennen, ob ein Unternehmen seine Werte ernst nimmt. Schaut nicht auf die „Über uns“-Seite. Schaut, ob die Website mit einem Screenreader funktioniert.

Barrierefreiheit ist der Punkt, an dem Rhetorik die Realität trifft. Du kannst von Inklusion und Vielfalt reden, so viel du willst — wenn dein digitales Produkt für Menschen mit visueller, motorischer oder kognitiver Einschränkung nicht nutzbar ist, werden diese Worte hohl.

Und sagen wir es klar: wir reden nicht von einer Nische.

In Europa leben Dutzende Millionen Menschen mit irgendeiner Form von Behinderung. Hinzu kommen Ältere, Menschen mit temporären Einschränkungen, alle, die sich in einem ungünstigen Kontext befinden: Sonne auf dem Bildschirm, langsame Verbindung, altes Gerät.

Barrierefreiheit ist kein Gefallen. Sie ist ein Maß für die Qualität unserer Arbeit. Eine barrierefreie Software ist fast immer eine bessere Software: sauberer im Code, klarer in der Oberfläche, robuster.

Der European Accessibility Act macht ab 2025 viele Dinge verpflichtend. Wer aber auf das Gesetz wartet, um das Richtige zu tun, hat meiner Meinung nach den Punkt schon verpasst.

An die Entwickler: ihr seid nicht in Gefahr, ihr seid in Wandlung

Hier spreche ich zu denen, die meinen Beruf ausüben. Zu denen, die zwischen Commits und Deploys leben, zwischen Bugs und Refactorings.

Ich weiß, da ist Angst. Ich sehe sie in Gesprächen, in Nachrichten, manchmal in Witzen. Die Frage ist immer dieselbe, auch wenn sie nicht ausgesprochen wird: „werde ich in fünf Jahren noch gebraucht?“

Ich atme.

Wir sind von Tabellenkalkulationen zu relationalen Datenbanken übergegangen. Von statischen Seiten zu Frameworks. Vom manuellen Deploy zu CI/CD. Und jetzt vom handgeschriebenen Code zum KI-unterstützten. Jedes Mal hat der Boden gebebt. Jedes Mal hat, wer sich anpassen konnte, festgestellt, dass der neue Boden fruchtbarer war als der alte.

Der Wert lag nie im Tippen. Er lag im Verstehen. In der Fähigkeit, ein Problem anzusehen und die Struktur unter der Oberfläche zu erkennen. Mit einer Nutzerin zu sprechen und Frustrationen in ein funktionierendes System zu übersetzen. Zu wählen, wann man baut und wann man wiederverwendet. Zu wissen, dass ein Test keine Bürokratie ist, sondern Liebe zur Zukunft.

Diese Kompetenzen sind nicht automatisierbar. Sie sind verstärkbar.

Die Maschine, die Code schreibt, ist ein Verstärker deiner Fähigkeiten — aber nur, wenn du welche zu verstärken hast. Eine IDE mit KI in der Hand dessen, der versteht, was er tut, ist ein außergewöhnliches Werkzeug. In der Hand dessen, der nicht versteht, ein Hochgeschwindigkeitsgenerator für technische Schulden.

Lernt, ja, aber nicht nur die neuen Werkzeuge, denn die ändern sich. Lernt die Grundlagen: Architektur, Systemdesign, Sicherheitsprinzipien, Barrierefreiheit. Lernt die Menschen: wie sie kommunizieren, was sie fürchten, was sie hoffen. Und lernt auch den regulatorischen Kontext, nicht weil er Spaß macht, sondern weil er das Spielfeld definiert.

Und vor allem: hört nicht auf, neugierig zu sein. Neugier ist eine seltsame Sache, nicht immer „produktiv“ im Firmensinn. Aber sie ist einer der wenigen Wettbewerbsvorteile, die eine Maschine nicht wirklich replizieren kann.

Eine Frage des Vertrauens

Am Ende dreht sich dieses ganze Gespräch — über KI, Open Source, Regulierung, Barrierefreiheit — um ein einziges Wort: Vertrauen.

Vertrauen wir Systemen, die wir nicht sehen? Sollten wir? Unter welchen Bedingungen?

Vertrauen entsteht nicht durch Absichtserklärungen. Es entsteht durch konkrete, wiederholte, überprüfbare Entscheidungen. Es entsteht, indem wir Abhängigkeiten dokumentieren, Code testen, das Produkt barrierefrei machen, die Entscheidungen des Algorithmus erklären, für Fehler einstehen.

Für Entscheider ist Technologie keine Abteilung. Sie ist die Sprache, in der die Organisation geschrieben ist. Ihr müsst keine Programmierer werden, um Himmels willen. Aber ihr müsst genug verstehen, um Anbietern unbequeme Fragen zu stellen, ein echtes Risiko von einer hohlen Beruhigung zu unterscheiden, zu erfassen, was in der Software steckt, die die Prozesse steuert.

Für uns Entwickler war die Arbeit nie nur technisch. Jede Architekturentscheidung ist eine Werteentscheidung. Jede Datei, die wir nicht erheben, ist ein Recht, das wir respektieren. Jede Oberfläche, die wir barrierefrei machen, ist eine Tür, die wir öffnen.

Code ist Macht, und Macht trägt Verantwortung.

Also: das Holz und der Code

Mein Großvater hätte meinen Beruf nicht verstanden. Wahrscheinlich hätte er bei manchen Wörtern den Kopf geschüttelt und das Thema gewechselt.

Aber das Prinzip, glaube ich, hätte er verstanden.

Er wusste, dass man ein gut gemachtes Möbel an den Verbindungen erkennt, die man nicht sieht. An der Stabilität, die im Lauf der Zeit hält. An der Sorgfalt in den Details, die der Kunde nie bemerken wird, die aber den Unterschied machen zwischen einem Stück, das zwanzig Jahre hält, und einem, das nach sechs Monaten knarzt.

Gute Software ist genauso. Sie erkennt sich an dem, was man nicht sieht: an der Sicherheit, die nicht gebrochen wird, an der Barrierefreiheit, die niemanden ausschließt, an der Privatheit, die nicht verraten wird, an der Dokumentation, die jenen, die danach kommen, erlaubt zu verstehen, was du gemacht hast und warum.

Es ist kein Beruf, den uns die KI nehmen wird. Es ist ein Beruf, den die KI uns in gewisser Weise in seiner reinsten Form zurückgibt: nicht als mechanische Übersetzung, sondern als menschliche Sorgfalt.

Und Sorgfalt, wie mein Großvater beim Anblick des Holzes wusste, fühlt man.

Dieser Beitrag ist für jene, die Code schreiben, und für jene, die davon abhängen, ohne es zu wissen. Für jene, die entscheiden, ohne zu verstehen, und für jene, die verstehen, ohne entscheiden zu dürfen. Vielleicht für uns alle, denn die Antwort ist am Ende immer dieselbe: sie hängt von uns ab.

Es ist nicht immer Arroganz. Im Gegenteil, meist das Gegenteil. Es ist ein Satz, gesprochen mit der Selbstverständlichkeit dessen, der Compliance für ein technisches Detail hält — wie die Wahl eines Frameworks oder die Frage, ob der Button rechts oder links steht.

Nur ändert dieses „Detail“ gerade seine Form. Und es wird, viel schneller, als der Markt zuzugeben bereit ist, zu einer Frage der Verantwortung.

Was der Kunde kauft und was der Anbieter verkauft

Jahrelang haben wir uns in der Auftragsentwicklung mit einem ziemlich einfachen impliziten Pakt verstanden. Der Kunde beschreibt, was er will, der Anbieter baut es, man einigt sich auf Zeit und Kosten, bei der Übergabe wird abgenommen, dann geht es in Produktion, fertig.

In diesem Modell endete die „schwere“ Verantwortung fast immer im Projektperimeter. Wenn etwas schiefging, redete man von Bugs, Ausfällen, vielleicht einer Vertragsstrafe. Lästig, sicher, aber beherrschbar.

Der Punkt ist: in Europa kommt zwischen 2025 und 2027 ein Perspektivwechsel, der diesen Pakt weniger stabil macht. Es ist keine einzelne Verordnung, die du ignorieren kannst, bis die Mail vom Justiziar kommt. Es ist ein Bündel von Regeln, das im Ganzen in eine klare Richtung drückt: Software wird zunehmend wie ein Produkt behandelt.

Und wenn etwas ein Produkt ist, haftet, wer es „produziert“, nicht mehr nur vertraglich. Er haftet auch für Mängel — ähnlich wie bei einem Haushaltsgerät, das Schäden verursacht, weil es schlecht entworfen oder zusammengebaut wurde.

Die kommerzielle Schieflage, die Reibung erzeugt

Hier entsteht die echte Reibung — jene, die später in Verhandlungen und Angeboten explodiert.

Der Auftraggeber denkt linear und, aus seiner Sicht, korrekt. Er will eine funktionierende Plattform, ein Portal, eine App. Er will sie zu einem Termin, mit einem Budget, mit den Funktionen, die das Business braucht.

Der Anbieter dagegen hat eine wachsende Last an Anforderungen, die fast nie im Brief stehen. Du findest sie nicht in den User Stories, siehst sie nicht in den Mockups, der Product Owner verlangt sie nicht. Und doch verwandelt ihr Fehlen ein „ausgeliefertes“ Projekt in ein „riskantes“ Projekt.

Ich rede von technischer Dokumentation in einer bestimmten Form, Nachvollziehbarkeit der Komponenten, Schwachstellenmanagement, Transparenz bei bestimmten algorithmischen Entscheidungen, Barrierefreiheit. Alles Tätigkeiten mit einer Gemeinsamkeit: sie kosten Zeit, Kompetenz, Prozess.

Und dann kommt das Dilemma, das meiner Ansicht nach immer toxischer wird.

Stehen sie im Angebot, bist du womöglich teurer als der Wettbewerb, der sie weglässt.

Lässt du sie weg, verschluckst du sie in der Marge, arbeitest mit Verlust und nimmst zusätzlich ein nicht offengelegtes Risiko mit.

Keiner der beiden Wege ist auf Dauer tragbar.

Warum „das war schon immer so“ nicht mehr trägt

Im italienischen B2B haben wir jahrelang in einer Kultur des „machen wir, schauen wir später“ gelebt. Leichte Verträge, vage Spezifikationen, viel persönliches Vertrauen. Manchmal hat das auch funktioniert, das streite ich nicht ab. Vielleicht weil der Kontext es zuließ.

Jetzt aber ändern sich drei Dinge gleichzeitig, und die Kombination ist es, die Angst macht.

Das erste ist eine eher „objektive“ Haftung. In manchen Szenarien reicht „wir waren nicht fahrlässig“ nicht mehr. Es zählt der Mangel und der Schaden. Und in bestimmten Fällen verschiebt sich die Beweislast, dass kein Mangel vorlag, auf den, der produziert oder in den Markt gebracht hat.

Das zweite ist die Erweiterung des Perimeters. Software ist nicht nur, was du selbst schreibst. Sie ist auch, was du integrierst: Open-Source-Bibliotheken, Cloud-Dienste, Drittanbieter-APIs, KI-Modelle. Und wenn das alles ins Endprodukt einfließt, muss jemand verantworten, wie es ausgewählt, integriert und überwacht wurde.

Das dritte ist die Zeit. Wir reden nicht von ferner Zukunft. Wir reden von Fristen zwischen 2026 und 2027. Der Code, den du jetzt schreibst, wird mit hoher Wahrscheinlichkeit noch da sein, wenn diese Regeln voll greifen.

Da frage ich mich, ob es nicht naiv ist, Compliance weiter wie eine Fußnote zu behandeln.

Das Gespräch, das niemand führen will

Das Schwierigste ist nicht, die Norm zu verstehen. Es ist, darüber zu reden, ohne den Vertriebstisch zu sprengen.

Versuch mal, einem Kunden zu sagen, dass das Angebot um 20 % steigt, weil du konforme technische Dokumentation produzieren, einen Schwachstellenmanagementprozess einführen und ein aktuelles Komponenteninventar führen musst.

Im besten Fall antwortet er mit langem Schweigen.

Im schlechtesten sagt er, jemand anders mache es ohne.

Und hier bricht der Markt auseinander. Denn dieses „ohne“ bedeutet selten „effizienter“. Oft bedeutet es „Compliance-Schuld“ — Arbeit und Risiko in die Zukunft verschoben. Eine Zukunft, in der mit den neuen Regeln die Rechnung beim Anbieter, beim Auftraggeber oder bei beiden landen kann.

Und doch führt fast niemand dieses Gespräch, jedenfalls nicht ausdrücklich. Es ist unbequem. Es zwingt den Kunden zu akzeptieren, dass Compliance reale Kosten hat. Und es zwingt den Anbieter, diese Kosten zu erklären, ohne sich hinter Worten zu verstecken, die nach Bürokratie klingen.

Die Kosten der Unsichtbarkeit

Es gibt ein Paradox, das alles erschwert. Compliance-Aktivitäten sind, gut gemacht, unsichtbar.

Ein ernsthaftes Schwachstellenmanagement fällt dann auf, wenn nichts passiert.

Technische Dokumentation wird wertvoll, wenn etwas schiefgeht.

Ein Komponenteninventar (sprich: aktuelle Liste der Abhängigkeiten) ist genau an dem Tag wirklich Gold wert, an dem eine kritische Schwachstelle bekannt wird und du sofort wissen musst, ob du betroffen bist.

Der Kunde sieht das Feature, sieht das Go-Live, sieht die Oberfläche. Alles, was dieses Ergebnis langfristig trägt, bleibt unter dem Boden.

Vielleicht ist das Problem also nicht, dass der Kunde „nicht zahlen will“. Es ist, dass er nicht wahrnimmt, was er kauft.

Wenn du zu einer Unternehmerin gehst und sagst „wir müssen ein konformes Software Bill of Materials einführen“, verlierst du ihre Aufmerksamkeit nach wenigen Worten.

Wenn du stattdessen sagst „wir müssen innerhalb von 24 Stunden wissen können, ob eine eben veröffentlichte Schwachstelle dein Produkt — und damit deine Verantwortung — gefährdet“, sprichst du die Sprache des Risikos. Eine viel universellere Sprache.

Was sich in der Praxis ändert, ohne alles zum Albtraum zu machen

Für Anbieter ist der Weg eng, aber recht klar. Compliance darf nicht länger wie ein versteckter Kostenpunkt behandelt werden, sondern als ausdrückliche Leistung mit erzählbarem Wert.

Das heißt zum Beispiel: funktionale Entwicklung und Sicherheits-/Compliance-Wartung trennen. Nicht in einer undefinierten „Jahrespauschale“, sondern als Position, die sagt, was sie wirklich abdeckt. Auch weil, wenn morgen etwas zur Diskussion steht, Mehrdeutigkeit niemandem hilft.

Es heißt: schwarz auf weiß in den Verträgen, wer was tut. Wer aktualisiert die Abhängigkeiten? Wer überwacht die Schwachstellen? Wer erstellt und pflegt die technische Dokumentation? Wer entscheidet, ob eine Bibliothek verwendet werden darf? Wer haftet, wenn ein Bauteil sich als kompromittiert erweist?

In vielen italienischen Verträgen gibt es diese Fragen schlicht nicht. Und wenn eine Frage nicht existiert, kommt die Antwort immer im schlechtesten Moment.

Es heißt auch: lernen, diese Tätigkeiten als das zu verkaufen, was sie sind — Risikoreduktion. Denn der Kunde kauft keine „Compliance“. Er kauft die Möglichkeit, nicht mit einem rechtswidrigen Produkt, einem schlecht gemanagten Sicherheitsvorfall oder einem Streitfall ohne Beweise und Dokumente dazustehen.

Für Auftraggeber ist der Mentalitätswechsel spiegelbildlich. Compliance ist eure Sache ist keine bequeme Position mehr — und war nie wirklich eine sichere. Wenn du ein digitales Produkt in den Markt bringst, auch wenn du es von Dritten entwickeln ließest, verdunstet die Verantwortung nicht.

Du kannst dich höchstens vertraglich am Anbieter regressieren. Aber inzwischen trägst du Schaden, Reputation, Vorfallmanagement und kommerzielle Folgen selbst.

Eine Frage der Marktreife

Wenn man genauer hinsieht, gleicht das Geschehen einer erzwungenen Reife. Der Softwaremarkt, vor allem das Auftragsgeschäft, geht von einem handwerklichen Modell, das auf Vertrauen und impliziten Absprachen beruhte, zu einem industrielleren über, in dem Verantwortlichkeiten definiert sind, Prozesse dokumentiert und Qualität nicht mehr nur „läuft auf meinem Handy“ heißt.

Das ist nicht zwingend eine schlechte Nachricht.

Für seriöse Anbieter kann es ein Weg werden, sich von jenen abzuheben, die nur über das Kürzen von Ecken konkurrieren.

Für bewusste Auftraggeber kann es eine Garantie sein: zu wissen, dass die Software nicht nur fürs Online-Gehen gebaut ist, sondern um Vorfälle zu überstehen und beim ersten Stoß nicht zum juristischen Problem zu werden.

Vielleicht lautet der richtige Satz heute nicht „Compliance ist eure Sache“. Sondern etwas Ehrlicheres und Nützlicheres: Compliance ist Teil des Produkts.

Und ja, dann ist sie ein struktureller Kostenpunkt des Softwaremachens. Je früher man das anerkennt, desto eher kann man sie steuern. Und mit etwas Mut sogar in einen Wettbewerbsvorteil verwandeln.

Und während ich versuchte einzuschlafen, wurde die Frage lästiger und interessanter zugleich: wenn die UI wirklich aufhört, das Zentrum der Software zu sein, was passiert mit dem Rest? Denn vielleicht stirbt nicht nur der Bildschirm. Vielleicht stirbt die Anwendung, wie wir sie kannten.

Stirbt die UI, fällt sie nicht allein

Wenn wir „App“ sagen, meinen wir meist ein recht klares Objekt. Es hat einen Namen, ein Icon, einen Platz im Dock, ein monatliches Abo, eine Persönlichkeit. Und vor allem hat es eine Grenze. Drinnen ist die Welt von Notion. Drinnen ist Jira. Drinnen ist Salesforce. Draußen ist alles andere.

Mir ist aufgefallen, dass diese Grenze oft nicht da ist, weil das Problem sie verlangt. Sie ist da, weil das Geschäftsmodell sie verlangt.

Ein großer Teil moderner Software ist als Gehege gebaut. Vielleicht nicht aus Bösartigkeit. Es war jahrelang einfach der einfachste Weg zu monetarisieren: nimm eine Reihe von Funktionen, packe sie zusammen, baue drumherum eine Oberfläche, die vertraut wird, leg die Daten des Nutzers hinein und sorge dafür, dass das Hinausgehen schmerzt.

Mircha zieht eine Parallele, die mir erhellend vorkommt: MCP-Server als „neue Unix-Programme“. Und wenn das stimmt, folgt eine andere, etwas unbequemere Konsequenz. SaaS-Anwendungen sehen von dort aus wie Mainframes. Große Monolithen, geboren in einer Zeit, in der Software-Distribution teuer war und der einzige Weg, sie zu verkaufen, darin bestand, Mauern zu bauen.

In einer Welt, in der ein Agent kleine, präzise Capabilities im Flug zusammensetzen kann, wird diese Mauer eher zum Hindernis als zum Schutz.

Die generative Oberfläche: nicht entworfen, beschworen

In Mirchas Beitrag gibt es eine Stelle, an der ich innehalten musste. Die Idee, dass die GUI vom Control Panel zum Display wird. Und ich fragte mich: und wenn sie weder das eine noch das andere ist?

Vielleicht wird die Oberfläche im nächsten Schritt flüchtig.

Wenn heute eine Designerin einen Bildschirm entwirft, geht sie einen Kompromiss ein. Sie sucht ein Layout, das für viele Menschen in vielen Kontexten „gut genug“ funktioniert. Das Ergebnis ist oft eine solide, kohärente, getestete Oberfläche — aber unausweichlich generisch. Sie muss allen dienen, also dient sie niemandem perfekt.

Mit einem Agenten dazwischen könnte dieser Kompromiss fallen.

Ich meine nicht „alles im Chat erledigen“, was eine bequeme Karikatur ist. Ich meine ein System, das aus deiner Absicht die für diesen Moment richtige Oberfläche erzeugt. Ein Formular, nicht generisch, sondern mit diesen Feldern, in dieser Reihenfolge, mit den sinnvollen Defaults für deinen Fall. Ein Dashboard, nicht standardisiert, sondern die Visualisierung, die eine konkrete Frage beantwortet, mit den nötigen Daten und keinem Lärm.

Diese UIs werden nicht gepflegt. Nicht versioniert. Brauchen keine Roadmap.

Sie werden beschworen und verschwinden danach.

Das Beunruhigende: das ist keine Science-Fiction mehr. Heute sehen wir bereits Modelle, die Komponenten, Seiten, kleine React-Artefakte in Echtzeit erzeugen. Roh, ja. Aber die Richtung ist schwer zu ignorieren.

Die Rolle der Designerin verschwindet dann nicht, sie häutet sich. Statt Bildschirme zu entwerfen, gestaltet sie generative Systeme. Designsysteme, Constraints, Patterns, Regeln. Eine Arbeit, die eher dem Bauen einer Grammatik gleicht als dem Zeichnen von Sätzen.

Der Agent als Betriebssystem

Eine andere Konsequenz, die mich nicht loslässt: vielleicht ist die richtige Metapher für den Agenten nicht „Assistent“. Es ist „Betriebssystem“.

Ein OS tut Dinge, die wir für selbstverständlich halten: es abstrahiert die Hardware, verwaltet Ressourcen, bietet eine einheitliche Oberfläche, lässt verschiedene Programme nebeneinander laufen und miteinander reden.

Der Agent macht etwas Ähnliches, eine Ebene darüber. Er abstrahiert die Dienste, verwaltet Kontexte, bietet eine einheitliche Oberfläche (die natürliche Sprache), orchestriert verschiedene Capabilities.

Wenn diese Metapher trägt, geschieht etwas fast Unausweichliches: der Agent wird die Plattform. Nicht weil alles „in“ dem Agenten lebt, sondern weil alles durch den Agenten geht. So wie heute keine Software ohne OS läuft, wird morgen kein Dienst ohne Agenten genutzt.

Und hier kommt der politische, ökonomische Teil, der vielleicht der heikelste ist. Wer den Agenten kontrolliert, kontrolliert den Zugangspunkt zur Software. Eine Position, die wir in der Geschichte schon gesehen haben, nur unter anderen Namen.

Und ich frage mich, ob wir die übliche Bahn vermeiden können. Jene, die Cory Doctorow Enshittification nennt. Erst ist alles nützlich und offen, dann wird es zur Rente, dann zur Maut.

Von der App zur Capability

Wenn die Anwendung an Sinn verliert, was bleibt?

Es bleibt die Capability.

Eine Capability ist eine atomare Funktion, über ein Protokoll exponiert, menschlich beschrieben, von einem Agenten aufrufbar. „Erstelle eine Rechnung.“ „Suche diesen Kontakt.“ „Fasse diese Tickets zusammen und nenne mir die Risiken.“ Das ist kein Produkt mit Marke und Layout. Es ist ein Baustein.

Sobald du in Bausteinen denkst, ändert sich auch die Ökonomie.

Heute zahlst du ein Abo für ein Bundle: hundert Funktionen, du nutzt zwanzig, der Preis gilt für alle. Morgen könntest du verbrauchsbasiert zahlen, Capability für Capability, im Moment des Bedarfs. Centbruchteile für eine einzelne, gut gemachte Aktion.

Das stürzt drei historische SaaS-Vorteile in die Krise:

Erstens, die Oberfläche als Lock-in. Gehört die Oberfläche dem Agenten, gehört sie nicht mehr dir.

Zweitens, die Daten als Gefängnis. Wenn die Daten in persönlichen Vaults mit granularen Berechtigungen liegen, verliert das Gehege seine Macht.

Drittens, das Bundle. Wenn der Agent für jedes Stück das Beste komponieren kann, wird das monolithische Paket weniger attraktiv.

Dann bleibt nur eines: die Qualität der Capability. Mach eine Sache, mach sie besser als alle. Unix als technische Philosophie, aber auch als Geschäftsmodell. Elegant, und ein wenig erbarmungslos.

Die neue Alphabetisierung

Eine weitere Idee aus Mirchas Beitrag scheint mir unterschätzt: „nicht mit der KI sprechen können“ als neue Form von Analphabetismus.

Jahrzehntelang nannten wir „digitale Alphabetisierung“ eine sehr spezifische Sache: Oberflächen bedienen können. Klicken, ziehen, in Menüs navigieren, Formulare ausfüllen. Wir haben Kurse, Zertifikate, Berufe darum herum gebaut.

Wenn der Agent die Hauptoberfläche wird, schrumpft all das.

Die zentrale Kompetenz wird eine andere — vielleicht eine eher menschliche als technische. Eine Absicht klar ausdrücken können. Kontext geben können. Ein Problem zerlegen können. Ein Ergebnis beurteilen und iterieren können.

Hier liegt ein Paradox, das mich fasziniert. Es gibt Menschen, die nie wirklich Excel gelernt haben, aber chirurgisch genau erklären können, was sie wollen. Und es gibt Power User, die vor einem Agenten nicht wissen, was sie fragen sollen.

Die Landkarte der Kompetenzen zeichnet sich neu.

Und ja, die Gefahr eines neuen Digital Divide ist real. Aber es liegt auch eine seltene Chance darin: zum ersten Mal liegt der Vorteil nicht im „Maschinensprache sprechen“. Er liegt darin, gut zu denken und zu kommunizieren.

Die europäische Überraschung: Compliance als Capability

Es gibt einen Teil dieser Geschichte, den wir in Europa meiner Ansicht nach nicht ignorieren können.

Während das amerikanische Narrativ Regulierung gerne als Bremse sieht, bauen wir hier ein Regelwerk auf, das genau die wunden Nerven einer Welt aus zusammensetzbaren Capabilities trifft: AI Act, Cyber Resilience Act, Product Liability Directive, EAA.

In einem System, in dem ein Agent drei Capabilities von drei Anbietern kombiniert, wird die Frage „wer haftet, wenn etwas schiefgeht?“ zur Sprengladung.

Wenn das Gesetz Nachvollziehbarkeit, Sicherheit, Audit Trail, Erklärbarkeit verlangt, hört Compliance auf, nur ein Kostenfaktor zu sein. Sie wird zur differenzierenden Capability.

Das SBOM als Reisepass des Bauteils. Das Log der Agentenhandlungen als Anforderung. Transparenz als Wettbewerbsvorteil.

Und hier liegt eine fast ironische Wendung: viele historische Forderungen der Hackerkultur — Offenheit, Accountability, Überprüfbarkeit — werden gerade Gesetz. Vielleicht baut Europa, weniger als zu bremsen, gerade die Vertrauensinfrastruktur, ohne die die Welt der Agenten in ernsthaften Unternehmen nicht trägt.

2030, ein ganz normaler Tag (vielleicht)

Ich versuche, einen normalen Tag zu skizzieren, ohne in Science-Fiction abzudriften.

Du hast keine „Apps“ mehr auf dem Telefon. Du hast einen Agenten. Du sprichst mit ihm, schreibst, machst vielleicht eine Geste. Er orchestriert verschiedene Dienste, und du siehst die Kulissen fast nie. Ähnlich wie du heute beim Öffnen einer Seite nicht an Microservices denkst.

Die Oberfläche, die du siehst, wurde für dich, in diesem Moment, erzeugt. In fünf Minuten existiert sie nicht mehr.

Handel wird zum Gespräch. „Ich brauche Trail-Schuhe, Budget 150 Euro, gemischtes Gelände, am liebsten Vibram-Sohle.“ Der Agent kennt Größe, Historie, Vorlieben, vertrauenswürdige Quellen. Er schlägt drei Optionen mit einem maßgeschneiderten Vergleich vor. Du wählst, fertig.

Im Büro Ähnliches. Die PM öffnet kein Jira, sondern fragt: „Wie stehen wir bei Alpha?“ und bekommt Status, Risiken, nächste Schritte. Der Vertrieb navigiert nicht das CRM, er fragt: „Welche Deals sind diese Woche gefährdet?“ und erhält ein Briefing. Die Entwicklerin beschreibt ein Verhalten, das System generiert, testet, deployt.

Daten liegen in einem persönlichen, verschlüsselten, portablen Vault. Capabilities verlangen granulare, widerrufbare Berechtigungen, alles wird geloggt. Jede Aktion erzeugt einen Audit Trail.

In dieser Welt liegt der Wert in zwei Dingen: guten Capabilities und Vertrauen.

Ein nötiger Realismus

Ist es unvermeidlich? Ich weiß es nicht.

Übergänge verlaufen nie linear. Es wird enorme ökonomische Widerstände geben. Das Enterprise bewegt sich mit fast geologischer Langsamkeit. Gewohnheiten ändern sich langsamer als Pressemitteilungen. Und es gibt echte technische Probleme: Zuverlässigkeit bei komplexen Aufgaben, Fehlerbehandlung in Kompositionsketten, Sicherheit, Kosten.

Aber die Richtung, die Mircha scharfstellt, scheint mir schwer zu ignorieren, weil zwei konkrete Kräfte sie tragen.

Auf der einen Seite die kognitiven Kosten klassischer Oberflächen, die mit jedem neuen SaaS wachsen.

Auf der anderen die Fähigkeit der Agenten, diese Kosten zu senken, die mit jeder Modelliteration wächst.

Wenn der Abstand zwischen beiden eine Schwelle überschreitet, wird der Übergang praktisch, nicht ideologisch. Und für manche Anwendungsfälle ist diese Schwelle vielleicht schon überschritten.

Mircha schließt mit der Frage, wer diese Zukunft mit welchen Werten baut. Ich nehme eine andere Frage mit, etwas persönlicher und etwas zynischer: wer wird den Mut haben, für diese Zukunft zu bauen, im Wissen, dass das bedeutet, das Modell zu zerlegen, das heute die Gehälter zahlt?

Denn das Dilemma ist am Ende nicht technisch. Es ist der Wille, die Gegenwart zu kannibalisieren.

Und die Zeit, sich zu entscheiden, ist vermutlich nicht unendlich.

Dieser Beitrag entstand aus der Lektüre von „La morte dell’interfaccia utente come la conosciamo“ von Mircha Emanuel D’Angelo. Wer ihn nicht gelesen hat: meiner Ansicht nach lohnt es sich, dort zu beginnen.

Es gibt drei Sorten Menschen auf der Welt: jene, die IKEA-Anleitungen von vorn bis hinten lesen, bevor sie irgendetwas anfassen, jene, die sie direkt zur übrigen Schraubenmenge in den Beutel werfen, und jene, die sie zur Hälfte lesen und dann beschließen, nach Bauchgefühl weiterzumachen.

Es muss kaum gesagt werden, dass die dritte Kategorie mich umfasst, meine Mutter, meinen Etagennachbarn und vermutlich 90 % der italienischen Halbinsel.

Und es gibt vielleicht eine vierte Kategorie. Jene, die IKEA aus Prinzip nicht kaufen und dich dann um zehn Uhr abends anrufen, weil sie ein KALLAX gekauft haben und „man versteht überhaupt nichts”. Aber von ihnen reden wir später, denn zuerst muss der wahren Gottheit dieser Geschichte gehuldigt werden.

Der A3-Bogen, also Björn

Beginnen wir beim Objekt selbst, denn es verdient Respekt.

Die IKEA-Anleitungen sind ein Meisterwerk minimalistischen Designs. Kein einziges Wort. Nur Zeichnungen. Ein stilisiertes Männchen, nennen wir es Björn, denn es sieht aus wie ein Björn, das mit gelassener Miene und seltsam proportionierten Armen Dinge zeigt, die in der Realität drei Hände, einen Hydraulikschraubstock und eine Sekunde verlangen, in der die Kinder nicht zu Hause sind.

Björn schwitzt nie. Björn sagt nie „warte, dieses Brett ist verkehrt herum”. Björn hat nie vierzig Minuten gebraucht, um zu begreifen, dass Teil C nicht Teil C war, sondern das spiegelverkehrte Teil C, was eine andere Sache ist und was IKEA sehr gut weiß, aber dir nicht ausdrücklich verrät, weil das Leben kurz und der Charakter zu schmieden ist.

Björn ist gelassen, weil Björn nicht existiert.

Aber wenn er existierte, wäre Björn der Typ, der im Restaurant sofort bestellt, keine Sonderwünsche hat, die Rechnung nicht prüft. Björn parkt beim ersten Versuch ein. Björn musste nie auf einer Schnellstraße wenden, weil er die Ausfahrt verpasst hat. Björn hat keine Schublade voller Sachen, „die ich später noch ordne”.

Björn ist ein funktionierender Soziopath, und ich beneide ihn zutiefst.

Die Reise zu IKEA, also die Pilgerfahrt

Bevor wir zum Aufbau kommen, muss man über das IKEA-Erlebnis als Ganzes sprechen, denn es ist eine spirituelle Reise an sich.

Alles beginnt mit einem Versprechen: „Wir holen nur kurz die Regale.” Dieser Satz ist das logistische Pendant zu „wir bleiben nur fünf Minuten” auf einer Party. Es ist nie passiert, es wird nie passieren, und doch wiederholen wir ihn jedes Mal mit derselben Überzeugung wie jemand, der schwört, diesmal werde er auf Netflix nicht mehr „weiterschauen” drücken.

Der IKEA-Parkplatz ist ein eigenes Ökosystem. Es gibt jene, die zwanzig Minuten umherkurven, um den Platz nahe am Eingang zu finden, und jene, die in dreihundert Metern Entfernung parken und mit der Entschlossenheit dessen losmarschieren, der mit der eigenen Sterblichkeit längst Frieden geschlossen hat.

Ich gehöre einer dritten Spezies an: jene, die einen guten Platz finden, einbiegen, dann merken, dass das Auto nebenan die Tür so weit aufgemacht hat, dass eine Sperrzone entstanden ist, wieder herauskommen, neu starten und auf dem Decathlon-Parkplatz nebenan landen.

Dann betrittst du den Laden. Und hier zeigt sich das schwedische Genie in voller Wucht.

Der Zwangsweg. Dieses Einbahn-Labyrinth, das dich durch Kinderzimmer führt, die du nicht hast, durch Büros, die du nicht brauchst, und durch Küchen, deren Arbeitsplatten so sauber sind, als hätte nie jemand dort gekocht. Was vermutlich stimmt, denn es ist eine IKEA-Küche im Laden — aber meine ist nie so.

Unterwegs sammelst du Dinge ein. Dinge, die du nicht brauchtest, nicht suchtest, von deren Existenz du fünf Minuten zuvor nichts wusstest. Einen Schubladenorganizer. Ein Set Vorratsgläser. Ein wolkenförmiges Kissen für drei Euro neunzig, das dir aus irgendeinem Grund unverzichtbar erscheint.

IKEA hat etwas Grundlegendes über die menschliche Psyche verstanden: wir wissen nicht, was wir wollen, bis es uns jemand zu einem Preis vor die Nase stellt, der zu niedrig wirkt, um nein zu sagen.

Du erreichst die Regale, der Grund deines Besuchs, nach fünfundvierzig Minuten, mit zwei vollen gelben Tüten und einer Diskussion darüber, ob es neue Vorhänge braucht. Es braucht sie, aber das wirst du erst nach zwei weiteren Besuchen zugeben.

Das Lager, wo die Würde wankt

Der wahre psychologische Test ist aber nicht der Rundgang. Es ist das Lager.

Diese Halle mit Regalen, hoch wie Kathedralen, in der du dein Regal unter tausend flachen Kartons finden musst, alle braun, alle gleich, alle mit einem alphanumerischen Code, den du auf den Zettel mit dem IKEA-Bleistift gekritzelt hast. Ja, jenem Bleistift, der zu kurz zum bequemen Schreiben und zu dick für die Hosentasche ist und der ein halbes Jahr später im Handschuhfach des Autos wieder auftaucht.

Gang 24, Regal 8. Du bist da. Regal 8 ist oben. Der Karton wiegt dreiundzwanzig Kilo. Niemand in der Nähe.

Die Optionen: um Hilfe bitten (undenkbar, du bist Italiener), hochklettern (möglich, posturmäßig nicht zu empfehlen), oder den Karton mit einer athletischen Bewegung greifen, die du seit der Schulzeit nicht mehr gemacht hast und die dein Physiotherapeut „eine Wahl” nennen würde.

Du wählst die dritte Option. Der Karton rutscht. Du fängst ihn mit dem Knie ab. Du schaust dich um, ob jemand zugesehen hat. Niemand hat zugesehen. Du gehst weiter mit intakter Würde und einer künftigen Prellung am linken Knie.

Das Öffnen des Kartons, also der Ritus

Es gibt einen genauen Ritus beim Öffnen des IKEA-Kartons, und er ist nicht zu unterschätzen.

Erstens: der Platz. Du brauchst Platz. Das Handbuch sagt „in einem weiten, freien Bereich aufbauen”, was im Alltag einer italienischen Wohnung heißt: den Tisch verschieben, den Teppich, und diesen Stapel Sachen „die ich noch wegräume”, der seit dem letzten Frühling neben dem Sofa steht.

Du öffnest den Karton. Die Pappe reißt unvorhersehbar, nie entlang der Linie, die du wolltest. Drinnen: ein Meer aus Styropor, Beutel mit Kleinteilen, Bretter in einer Schutzfolie, die an allem klebt außer an sich selbst, und dieser Bogen.

Der A3-Bogen.

Du faltest ihn mit einer gewissen Ehrfurcht auseinander.

Erste Geste: du betrachtest die Endzeichnung. Das fertige Möbel, mit einer Vase und einer Blume drauf, daneben ein Bücherstapel, mit einer zu sorgfältig studierten Beiläufigkeit arrangiert, um echt zu sein. Du denkst: „ja, so will ich es haben.” Dann schaust du auf Schritt 1, ein flaches Brett, zwei Dübel, ein Pfeil, und der Abstand zwischen Traum und Realität trifft dich mit derselben Brutalität wie der Kontoauszug nach Weihnachten.

Zweite Geste: du zählst die Schritte. 24 Schritte. „Sind ja nicht so viele”, sagst du dir. Das ist das emotionale Pendant dazu, eine Serie mit sechs Staffeln anzusehen und zu denken „die schaff’ ich am Wochenende”.

Dritte Geste: du prüfst die Schrauben. Die Beutel. Du legst sie ordentlich aus. Du zählst sie. Du stellst fest, dass es mehr sind als vorgesehen. Du fragst dich, ob das ein Fehler, ein Bonus oder ein psychologischer Test ist. Du wirst es nie erfahren.

Der Moment des blinden Vertrauens (meist bei Schritt 7)

Es gibt einen genauen Moment beim Aufbau jedes IKEA-Möbels, in dem du einen Glaubensakt vollziehen musst.

Meist bei Schritt 7 von 24. Du hast gerade etwas verschraubt, das nirgendwohin zu führen scheint, die Struktur hält durch zwei Holzdübel und Hoffnung zusammen, und die Anleitung zeigt dir mit dieser unfassbaren Ruhe, dass du alles umdrehen sollst.

Umdrehen. Alles. Allein.

Björn macht das mit einem Finger, natürlich. Auf der Zeichnung dreht sich die Struktur an einem leichten, gebogenen Pfeil, als sei die Schwerkraft nur eine Andeutung.

In Wirklichkeit umarmst du einen instabilen Quader aus Spanplatte, der so viel wiegt wie ein durchschnittlicher Teenager, und drehst ihn mit Knie, Ellbogen und einem Vertrauen in den Holzleim, das du noch nie zuvor gespürt hast.

Genau in diesem Moment, mit dem Möbel, das knarzt, und dir, der es hält, als würdest du jemanden umarmen, den du nicht fallen lassen darfst, fühle ich mich exakt so wie vor den Märzfristen. Du hältst alles mit wenig zusammen, du weißt nicht, ob es trägt, aber der Plan sagt: weiter.

Und du machst weiter. Weil die Alternative — alles abbauen, neu anfangen, von vorn lesen — so deprimierend ist, dass du lieber das Risiko eingehst.

Der Inbus, klein und unendlich

Ein eigenes Kapitel zum Inbusschlüssel, denn er verdient eines.

Der IKEA-Inbus ist das perfekte Werkzeug für eine unvollkommene Welt. Klein, einfach, scheinbar harmlos. Er liegt jedem Kauf gratis bei, was bedeutet, dass du nach drei Möbeln mehr Inbus als Besteck hast.

Der Inbus ist auch das einzige Werkzeug, das IKEA für den Aufbau für nötig hält. Das ist ein Akt schwedischen Optimismus, der an Leichtsinn grenzt.

Denn der IKEA-Aufbau verlangt irgendwann immer mehr. Einen Hammer zum Beispiel, für jene Holzdübel, die nie beim ersten Versuch sitzen und die du „behutsam einsetzen” sollst. Übersetzung: mit allem hauen, was gerade da ist, einschließlich des Bodens einer Tasse, eines schweren Buches oder, in einem denkwürdigen Fall, eines Schuhs.

Und dann gibt es den Inbus-Moment, jenen Moment, in dem du schraubst und schraubst und schraubst, der Inbus ist kurz, du machst halbe Drehungen, das Handgelenk fängt zu protestieren an, und du fragst dich: gibt es wirklich Leute, die eine ganze IKEA-Küche damit aufbauen? Eine ganze Küche?

Ja, die gibt es. Es ist dieselbe Sorte, die den Everest besteigt. Selbe psychologische Kategorie.

Die Helfer, also das organisierte Chaos

Keine Erzählung über IKEA-Anleitungen wäre vollständig ohne die Helfer.

Der freiwillige Helfer ist jene Person — Partner, Freund, Elternteil, Mitbewohner —, die irgendwann beim Aufbau sagt: „Ich helf dir.” Mit guten Absichten. Mit der Sicherheit dessen, der die Anleitung nicht gelesen hat.

Der freiwillige Helfer hält das Brett auf der falschen Seite. Der freiwillige Helfer reicht dir die lange Schraube, wo es die kurze gebraucht hätte. Der freiwillige Helfer nimmt irgendwann die Anleitung, schaut dreißig Sekunden hinein und sagt: „Hättest du nicht zuerst dieses Teil setzen müssen?”

„Dieses Teil” ist das, was du schon verschraubt hast. Vor zwei Schritten. Mit sechs Schrauben.

Und die Antwort lautet ja, du hättest es zuerst setzen müssen, aber jetzt ist es zu spät, und wenn du jetzt abbaust, kippt alles, und „alles” umfasst das Möbel, deine Geduld und vermutlich die Beziehung.

Dann gibt es den technologischen Helfer, jenen, der mitten im Aufbau das Handy zückt und ein YouTube-Tutorial sucht. „Warte, da gibt’s einen, der baut das in sechs Minuten zusammen.” Ja, es gibt immer einen, der das in sechs Minuten baut. Der Typ hat eine Werkstatt, einen Akkuschrauber und vermutlich nie an irgendetwas in seinem Leben gezweifelt. Der Typ ist der Björn von YouTube. Er hilft mir nicht.

Der gefährlichste Helfer ist jedoch das Kind.

Das Kind will helfen. Das Kind nimmt die Schraubenbeutel. Das Kind öffnet sie. Das Kind bringt dir eine Schraube. Nicht die richtige. Irgendeine. Mit der unschuldigen Freude dessen, der nicht weiß, dass jene Schraube die einzige M6x30 im Beutel war und jetzt unter dem Sofa liegt, an genau der Stelle, an die deine Hand nicht reicht und an der, soweit ich weiß, alle seit 1987 verlorenen IKEA-Schrauben wohnen.

Die übrigen Schrauben und die Schublade des Gewissens

Reden wir über die übrigen Schrauben.

Jeder IKEA-Aufbau endet mit einer kleinen Gruppe von Schrauben, Unterlegscheiben und Dübeln auf dem Boden. Teile, von denen du nicht weißt, wohin sie gehören. Teile, die vielleicht irgendwohin gehören, vielleicht nicht, vielleicht zu einem anderen Möbel, vielleicht legt IKEA sie absichtlich rein, um zu sehen, was du machst.

Die italienische Standardreaktion ist, sie aufzusammeln, in eine Schublade zu legen und sie für die nächsten vier Jahre zu vergessen. Diese Schublade ist unser Gewissen.

Ich habe so eine Schublade. Wir alle haben eine. Es ist die Schublade, in der die übrigen IKEA-Schrauben landen, die Ladekabel von Telefonen, die wir nicht mehr besitzen, die Batterien, die vielleicht leer sind und vielleicht nicht, die Bedienungsanleitungen von Geräten, die wir nie lesen werden, und mindestens drei Schlüssel, deren Schloss wir nicht kennen.

Diese Schublade ist die materielle Autobiografie unseres Erwachsenenlebens.

Es gibt jene, die — und das sage ich mit aufrichtiger Bewunderung — sich hinsetzen, die Anleitung von vorn aufschlagen und herausfinden, wohin diese Teile gehören. Sie suchen. Sie finden. Sie schrauben.

Diese Leute machen auch regelmäßige Backups, lesen das Handbuch des Backofens und haben eine Kabelschublade nach Typ und Länge sortiert.

Ich bewundere sie. Ich verstehe sie nicht, aber ich bewundere sie.

Ich habe es einmal versucht, bei einem MALM, diese Person zu sein. Ich öffnete die Anleitung wieder. Ich prüfte Schritt für Schritt. Ich fand heraus, dass die zwei übrigen Schrauben zu Schritt 14 gehörten, wo deutlich stand — deutlich für Björn, undurchsichtig für alle anderen —, einen Kippschutz an der Wand zu befestigen.

Einen Kippschutz. An der Wand.

Das verlangte einen Dübel, eine Bohrmaschine und ungefähre Kenntnis darüber, wo die Rohre durch den Putz laufen.

Die Schrauben kehrten in die Schublade zurück.

Die IKEA-Namen, also nordische Beschwörungen

Eine Klammer zu den Namen, denn die IKEA-Namen verdienen Aufmerksamkeit.

BILLY. KALLAX. MALM. LACK. HEMNES. BESTÅ. FJÄLKINGE.

Es sind Namen schwedischer Seen, Dörfer, Flüsse, Adjektive. Aber sie klingen wie Beschwörungen. Wie mythologische Wesen. Wie die Phasen einer besonders komplexen Trauer.

„Ich habe den FJÄLKINGE aufgebaut.” Klingt nach einem Satz, den man nach einer Polarexpedition sagt. Und in gewisser Weise ist es das auch. Denn der FJÄLKINGE ist ein Metallregal, das einfach aussieht und das dich nach vier Stunden Aufbau dazu bringt, alle deine Lebensentscheidungen neu zu bewerten, einschließlich der, kein echtes Bücherregal beim Schreiner gekauft zu haben.

Und dann die Namen der Kleinteile. Die Beschläge. FIXA, TRÅDFRI, SKÅDIS. Du liest sie auf der Schachtel und denkst: „Das ist kein Produkt, das ist der Name des Bösewichts in einem skandinavischen Film.”

„SKÅDIS hat wieder zugeschlagen.”

Der Anruf im schlechtesten Moment

An irgendeinem Punkt des Aufbaus, meist zwischen Schritt 12 und 16, in jenem Niemandsland, wo du zu weit bist, um zurück zu können, und zu verwirrt, um vorwärts, kommt der Anruf.

Es ist nie ein kurzer Anruf. Es ist deine Mutter. Oder eine Kollegin. Oder dieser Verwandte, der nur anruft, wenn deine Hände beschäftigt sind.

Du klemmst das Handy zwischen Schulter und Ohr, eine Hand hält ein Brett, die andere versucht, eine Schraube in einem physikalisch unmöglichen Winkel anzuziehen, während du „ja, ja, alles gut” antwortest, einer Person, die dir etwas erzählt, das Aufmerksamkeit verlangt, aber keine bekommen wird.

Denn deine Aufmerksamkeit liegt vollständig darauf, dass das Brett verrutscht — und wenn es fällt, fängst du bei Schritt 11 wieder von vorn an.

Der Anruf endet. Du weißt nicht, was man dir gesagt hat. Das Brett ist nicht gefallen.

Du wertest beides als Sieg.

Die Metapher, der du nicht entkommst

Irgendwann beim Aufbau, meist auf den Knien auf dem Parkett mit dem schon protestierenden Rücken, merkst du, dass die IKEA-Anleitungen in Wirklichkeit eine ziemlich präzise Metapher des Erwachsenenlebens sind.

Sie sagen dir nicht, wie lange es dauert. Die geschätzte Zeit fehlt, oder wenn sie da ist, ist es Björns Zeit, der in einer Parallelwelt lebt, in der alles beim ersten Versuch passt und niemand dich anruft, während du schraubst.

Sie erklären nicht, warum. Nur: tu das. Dann das. Frag nicht.

Sie geben nicht zu, dass manches schwer ist. Der komplizierteste Schritt — jener, in dem du drei Bretter festhalten musst, während du eine Schraube an einer Stelle einsetzt, die nur Kindern unter sechs und professionellen Schlangenmenschen zugänglich ist — hat exakt dieselbe Ikonografie wie jener, in dem du zwei flache Teile aufeinanderlegst.

Sie sehen das Unvorhergesehene nicht vor. Die Katze, die sich auf den Karton setzt. Das Kind, das „helfen” will. Den Partner, der „aber das ist doch schief, oder?” sagt, genau in dem Moment, in dem du den letzten Bolzen anziehst. Die Bodenwelle, die alles leicht schräg macht.

Und dann die grausamste Entdeckung von allen: Es ist nicht das Möbel, das schief ist, es ist die Wand. Die Wand.

Sie sagen nicht, was zu tun ist, wenn du dich irrst. Es gibt keinen Schritt „wenn du das Brett auf der falschen Seite verschraubt hast, gehe zu Schritt 4 zurück”. Weil Björn sich nicht irrt. Björn hat nie etwas verkehrt gemacht. Björn ist die schwedische Utopie in Form eines stilisierten Männchens, und sein stiller Tadel wiegt schwerer als jede Rüge.

Und doch funktioniert es.

Nicht immer beim ersten Versuch, nicht immer ohne Dellen, nicht immer ohne diese kleine Abweichung vom Plan, die man am Ende nicht sieht und an die man nach einer Weile aufhört zu denken. Aber es funktioniert.

Das Möbel hält. Der Schreibtisch hält. Der Billy, den ich 2009 aufgebaut habe, hält noch immer, allen Widrigkeiten zum Trotz, und gehört inzwischen zur Familie.

Der Billy, Schutzpatron der Spanplatte

Apropos Billy. Reden wir über ihn.

Der Billy ist der Fixpunkt des IKEA-Universums. Der Nullmeridian. Die kosmologische Konstante des Bausatzmöbels. Jeder Italiener hatte, hat oder wird einen Billy haben. Eine statistische Gewissheit.

Meinen ersten Billy baute ich 2004 auf. Ich war jung, optimistisch und überzeugt, „eine Stunde Aufbau” bedeute wirklich eine Stunde.

Drei Stunden später, mit zerkratztem Parkett und blauem Daumen, stand der Billy. Schief, aber er stand.

Dieser Billy steht noch immer da. Er hat drei Umzüge, zwei Beziehungen, einen Stadtwechsel und ein Erdbeben überstanden. Er hat nie gewankt. Genauer: er hat immer gewankt, aber nie umgekippt. Wie wir alle.

Der Billy ist der Beweis, dass Perfektion nicht nötig ist. Dass man auch mit ein paar Schrauben weniger, einem leicht schiefen Brett und einem Dübel halten kann, der vielleicht woanders hingehört hätte.

Der Billy urteilt nicht. Der Billy beherbergt deine Bücher, deine Erinnerungen und jenes Foto, das du vor drei Jahren hättest rahmen sollen. Der Billy ist geduldig.

Wenn IKEA Heilige ernennen würde, wäre Billy der erste.

Regionale Varianten, Paare und andere Formen von Mut

Der IKEA-Aufbau ist universell, aber die Reaktion darauf ist zutiefst lokal.

Der Süditaliener baut mit Leidenschaft. Er spricht mit dem Möbel. Er ermutigt es. Er beschimpft es. Er behandelt es wie ein besonders sturer Verwandter. „Wo gehst du hin?! Bleib steh’n! Was hab’ ich dir gesagt!” Das Möbel antwortet nicht, aber das stört den Süditaliener nicht. Er ist gewohnt, mit Dingen zu reden, die nicht kooperieren.

Der Norditaliener baut mit Methode. Er hat den Akkuschrauber. Er hat die Matte, um den Boden nicht zu zerkratzen. Er hat die Anleitung schon gelesen. Er baut schweigend auf, mit einer Effizienz, die selbst eine Form passiver Aggressivität ist. Wenn er fertig ist, jubelt er nicht. Er nickt. Als wäre das Möbel ein Untergebener, der endlich verstanden hat.

Der Mittelitaliener — und ich spreche aus eigener Erfahrung — baut mit kreativer Resignation. Er weiß, dass etwas schiefgehen wird. Er nimmt es vorweg an. Wenn es schiefgeht, seufzt er. Wenn es wider Erwarten nicht schiefgeht, vermutet er einen Trick.

Und dann gibt es die Paare.

Ein IKEA-Möbel zu zweit aufzubauen ist der zuverlässigste Beziehungstest, der je erfunden wurde. Mehr als die erste gemeinsame Reise. Mehr als das Kennenlernen der Schwiegereltern. Mehr als das erste gemeinsame Bad.

Denn der IKEA-Aufbau zu zweit deckt alles auf.

Wer die Anleitung liest und wer nicht. Wer Geduld hat und wer nicht. Wer „gib mir diese Schraube” sagt und eine bestimmte Schraube meint, und der andere reicht eine andere, und der erste sagt „nein, die da” und der andere fragt „welche?”, und der erste sagt „die da” und deutet mit dem Kinn, weil beide Hände belegt sind, und der andere greift zu einer Unterlegscheibe.

Es gibt immer einen, der die Anleitung befolgen will, und einen, der improvisieren will. Einen, der „halt, wir lesen” sagt, und einen, der schon drei Bretter verschraubt hat und sagt „ist doch dasselbe”. Es ist nicht dasselbe. Es ist nie dasselbe.

Ich habe sehr feste Paare vor einem PAX wanken sehen. Der PAX ist der Schrank der Zwietracht. Groß, komplex, Schiebetüren, und er verlangt ein Maß an Koordination, das die meisten Paare erst nach Jahren Therapie erreichen.

Wenn ihr einen PAX gemeinsam aufbaut und am Ende noch miteinander redet, heiratet. Ihr habt die Probe bestanden.

Der Morgen nach IKEA

Es gibt ein wenig dokumentiertes Phänomen, das ich „den Morgen nach IKEA” nenne.

Du stehst auf. Du hast Muskelkater an Stellen, von denen du nicht wusstest, dass du sie hast. Der Rücken protestiert. Die Knie erinnern sich an die zwei Stunden auf dem Parkett. Die Finger tragen noch den Abdruck des Inbus.

Aber dann siehst du es. Das Möbel. Da. Aufrecht. Vollständig. Im Raum.

Und es gibt einen Moment, einen ganz kurzen Moment, vor dem Kaffee, vor allem, in dem du es ansiehst und denkst: „Ich habe das gemacht.” Mit meinen Händen. Mit einem A3-Bogen. Mit einem Inbus.

Es ist ein urzeitlicher Stolz. Derselbe Stolz wie der des Höhlenmenschen, der sich einen Unterschlupf gebaut hat. Egal, dass der Unterschlupf ein Nachttisch mit einer nicht ganz schließenden Schublade ist. Du hast es gemacht.

Dann setzt du dich zum Frühstück und siehst unter dem Tisch eine Schraube.

Eine einsame Schraube.

Eine Schraube, von der du nicht weißt, woher sie kommt, nicht weißt, wohin sie gehört, und die drei Tage dort liegen wird, bevor sie in der Schublade landet.

Der Kreis schließt sich.

Das letzte Einrasten, und der unvermeidliche Epilog

Es gibt eine besondere Befriedigung in dem Moment, in dem das letzte Brett seinen Platz findet und die Struktur plötzlich starr wird. Alles, was wackelig wirkte, festigt sich. Die Geräusche verschwinden.

Björn hatte von Anfang an recht.

Ich kann dir nicht sagen, ob dieses Gefühl die zwei Stunden Arbeit aufwiegt, den Rücken, die mysteriösen Schrauben in der Schublade, den Moment, in dem du das Möbel allein gewendet hast, mit Knie und einem säkularen Gebet, den Helfer, der dir die falsche Schraube reichte, das Kind, das die M6x30 unter dem Sofa verlor, den Anruf deiner Mutter und jene kleine Delle an der linken Seite, die „sowieso zur Wand zeigt und niemand sieht”.

Ich weiß nur, dass ich mich jedes Mal überrede, dass ich die Anleitung beim nächsten Mal von Anfang lesen werde.

Und jedes Mal komme ich zu Schritt 7, das Brett scheint zu passen, und ich denke: ja klar, ich weiß schon, wo es hingehört.

Ich weiß es nie.

post scriptum

Ich schaue gerade auf der IKEA-Seite. Es gibt ein neues Bücherregal. Massivholz, drei Böden, „einfacher Aufbau”.

Einfacher Aufbau.

Ich weiß, dass es nicht stimmt. Du weißt es auch. Björn weiß es auch, in seinem stilisierten Herzen.

Ich bestelle es trotzdem.

Wenn auch du eine Schublade voller namenloser Schrauben hast, einen Billy, der nie wirklich gerade war, und die unerschütterliche Gewissheit, dass du beim nächsten Mal die Anleitung lesen wirst, bist du einer von uns.

Wir sehen uns bei Schritt 7.

Keinen Prototyp, der nur so dasteht, kein Mockup mit dem stillschweigenden „das machen wir später noch ordentlich“. Etwas Lebendiges, mit Domain, funktionierendem Backend, brauchbarer Oberfläche. Etwas, das ein echter Nutzer jetzt öffnen und benutzen kann.

Ich habe 17 Minuten gebraucht. Ich habe keine einzige Zeile Code geschrieben. Ich habe mit einem KI-Werkzeug gesprochen.

Das Ergebnis ist music-map.uk, eine App, die eine Frage beantwortet, die du dir vielleicht nie gestellt hast: wie klingt dieser Ort der Welt?

Und nein, in diesem Beitrag geht es nicht um music-map. Genauer gesagt: nicht um das Produkt selbst. Es geht darum, was es bedeutet, dass so etwas auf diese Weise entstehen kann, während das Wasser für den Kaffee aufkocht.

Die Unterscheidung, die alles verändert

Ich muss hier eine Klarstellung machen, sonst wirkt es, als würde ich eine Geschichte erzählen, die es seit Jahren gibt, nur mit etwas mehr Begeisterung.

Es gibt Consumer-Werkzeuge, die genau das versprechen: Browser auf, Idee beschreiben, ein paar Klicks später ist die App da. Lovable, Bubble, Glide, Softr. Das Ökosystem ist riesig und wächst stetig.

Der Punkt ist: heute klafft noch eine deutliche Lücke zwischen „ich habe etwas gebaut, das wie eine App aussieht“ und „ich habe etwas gebaut, das in der Produktion trägt“. Das sage ich nicht aus Snobismus, und auch nicht als Urteil über jene Produkte. Für bestimmte Anwendungsfälle sind sie wirklich gut.

Es ist eine Frage der Substanz: Robustheit, Skalierbarkeit, Kontrolle über den generierten Code, Eingriffsfähigkeit, wenn etwas bricht, echte Ownership der Infrastruktur. Dieses sehr konkrete Gefühl zu wissen, wo die Teile liegen und was passiert, wenn eines nicht mehr funktioniert.

Ich habe Werkzeuge benutzt, die für jemanden gedacht sind, der ohnehin schon weiß, was er da baut. Werkzeuge, die voraussetzen, dass du technischen Kontext mitbringst, einen Fehler lesen kannst und Architekturentscheidungen triffst, wenn man sie dir vor die Nase legt.

Diese Differenz ist heute noch enorm. Und genau das ist der Punkt.

Das B2B macht mir noch keine Angst

Während ich den Kaffee austrank, holte mich die Frage ein, die in der Branche ständig herumgeistert, auch wenn wir so tun, als gäbe es sie nicht: nimmt mir das den Job?

Im B2B lautet die Antwort, so wie ich es heute sehe, nein. Jedenfalls nicht im katastrophalen Sinn, den die Mainstream-Erzählung so gerne hätte.

Denn gut gemachte B2B-Arbeit war nie „Code schreiben“. Es geht darum, den Kontext eines Kunden zu verstehen, oft diffuse Anforderungen in präzise technische Vorgaben zu übersetzen, dafür zu sorgen, dass ein System unter Druck hält, durch Compliance und Normen zu navigieren, Vertrauensbeziehungen über Jahre zu pflegen.

Im Alltag bei Oltrematica habe ich gleichzeitig auf dem Tisch: eine Migration von Python zu Laravel 12, Frameworks zur Konformität mit dem Cyber Resilience Act, SBOM-Plattformen für Kunden, die ihre Software gegenüber öffentlichen Stellen offenlegen müssen, und Lösungen rund um die Product Liability Directive, die 2026 in Kraft tritt. Das löst man nicht in einem 17-Minuten-Gespräch.

Die KI hat verändert, wie ich diese Arbeit mache. Die Geschwindigkeit bei bestimmten Aufgaben ist fast peinlich gestiegen. Aber der Wert, den ich liefere, lag nie im Tippen des Codes. Er lag darin, zu wissen, was zu schreiben ist, warum, und vor allem was zu vermeiden ist.

Dieser Teil ist vorerst nicht verschwunden. Er hat sich vielleicht sogar verstärkt, weil mir mehr Raum zum Denken bleibt.

Das Consumer ist eine andere Geschichte

Im Consumer-Bereich bin ich dagegen weniger entspannt. Nicht, weil morgen die Apps verschwinden, sondern weil sich die Form des Marktes verändert.

Wenn man die klassische Adoptionskurve nimmt — Innovatoren, Early Adopters, frühe Mehrheit, späte Mehrheit, Nachzügler — und sich fragt, wo wir mit den KI-Werkzeugen zur Softwareentwicklung stehen, kommt etwas Seltsames heraus.

Für die Entwickelnden sind wir bereits in der frühen Mehrheit. Viele nutzen sie täglich, die Integration in Workflows ist real, die Produktivität messbar.

Für eine nicht-technische Nutzerin sind wir hingegen noch zwischen Innovatoren und allerersten Early Adopters. Die technische Schwelle ist immer noch hoch. Nicht so hoch wie vor zehn Jahren, aber hoch genug, um die meisten Menschen auszuschließen.

Und diese Schwelle sinkt jeden Monat. Nicht immer linear. Manchmal gibt es einen Sprung, weil jemand eine Oberfläche findet, die wirklich funktioniert, oder weil ein Modell fähig genug wird, mit der Mehrdeutigkeit natürlicher Sprache umzugehen, ohne dass du es alle zwei Minuten korrigieren musst.

Wenn diese Schwelle so weit sinkt, dass sie von einer ganz normalen Person überschritten wird — von jemandem, der nicht weiß, was ein Server ist, und es auch nicht wissen will —, verändert sich der Consumer-Markt für Software unwiderruflich.

Das eigentliche „Produkt“ der Consumer-Apps

Ich versuche es einfach zu sagen.

In den letzten fünfzehn Jahren hat eine Consumer-App so funktioniert: jemand hatte eine Idee, und nur wer technische Kompetenzen hatte — oder das Geld, sie zu kaufen — schaffte es, daraus ein Produkt zu machen. Dieses Produkt wurde dann verteilt und von anderen genutzt.

Der Wert lag in der Ausführung, schon. Aber darunter steckte etwas anderes: der Abstand.

Der Abstand zwischen einer Absicht und der Möglichkeit, sie zu nutzen.

Diese Lücke zwischen „ich hätte gern“ und „ich kann“ war der Markt. Consumer-Apps existierten, weil zwischen jenen, die bauen konnten, und jenen, die nutzen wollten, eine technologische Barriere lag.

Wenn dieser Abstand verschwindet — wenn jeder beschreiben kann, was er möchte, und im Gegenzug funktionierende Software zugeschnitten auf die eigenen Bedürfnisse erhält — was bleibt dann vom klassischen Modell?

Ich sage nicht, dass die Apps morgen verschwinden. Ich sage, dass der Mechanismus, der einen riesigen Teil des Consumer-Marktes getragen hat, schneller aufhören könnte zu funktionieren, als wir glauben.

Wird maßgeschneiderte Software zur Norm?

Seit ein paar Monaten geht mir eine Idee im Kopf herum, die mir radikal vorkommt — vielleicht aber nur, weil wir das Gegenteil gewohnt sind.

In der physischen Welt ergibt Massenproduktion Sinn, weil Personalisierung teuer ist. Ein maßgeschneiderter Stuhl kostet deutlich mehr als ein Stuhl bei Ikea. Also akzeptierst du einen Kompromiss und kaufst etwas Standardisiertes, „gut genug“.

Software hat ähnlich funktioniert. Eine Notiz-App ist für Millionen entworfen, also trifft sie Entscheidungen, die für viele passen und für sehr wenige perfekt sind. Du kaufst sie, weil sie selbst zu bauen — bis gestern — Jahre oder Tausende Euro gekostet hätte.

Aber wenn die Kosten der Personalisierung fast auf null fallen?

Wenn ich beschreiben kann, wie ich meine Notiz-App wirklich haben will, mit den Kategorien, die ich verwende, dem Flow, den ich bevorzuge, integriert in die Werkzeuge, die ich schon nutze — ergibt es dann noch Sinn, jene zu kaufen, die für Millionen Nutzer gedacht ist?

Vielleicht ja, aus Bequemlichkeit. Vielleicht nein, wenn der Unterschied zwischen „mich anpassen“ und „sie so haben, wie ich sie will“, zu offensichtlich wird.

Ich frage mich, ob Massensoftware das Schicksal kommerzieller Musik im Streaming-Zeitalter teilt. Sie bleibt, sicher, aber sie ist nicht mehr das Zentrum von allem, weil daneben persönlichere, maßgeschneidertere Erfahrungen wachsen.

Wer überleben könnte

Wenn dieses Szenario eintritt — und ich setze ein „wenn“ davor, nicht weil ich an der Richtung zweifle, sondern weil Tempo und Form des Wandels wirklich unsicher sind —, gibt es Consumer-Modelle, die solider wirken als andere.

Netzwerkplattformen zum Beispiel. Twitter, LinkedIn, WhatsApp. Ihr Wert liegt nicht in der App selbst, sondern darin, dass alle anderen drin sind. Du kannst kein personalisiertes Netzwerk haben, weil ein Netzwerk ohne Netzwerk nur eine leere Oberfläche ist.

Dann gibt es Dienste mit eigenen Daten. Spotify verkauft keinen Musik-Player. Spotify verkauft Zugang zu Katalogen, Metadaten, Lizenzen, Algorithmen, gespeist von Milliarden Hörvorgängen. So etwas erzeugst du nicht mit einem Prompt.

Und es gibt Produkte, bei denen Vertrauen und Compliance Teil des Pakets sind. Finanzen, Gesundheit, Recht. Selbst wenn dir eine KI die perfekte Software generierte, bleibt die Frage: Wer übernimmt die Verantwortung? Wer zertifiziert? Wer haftet, wenn etwas schiefgeht?

Schließlich vielleicht die High-End-Produkte mit herausragender UX. Manche Erfahrungen sind so kuratiert, dass es nicht nur „funktioniert“ — es ist wahrgenommene Qualität. Notion, Linear, Figma. Funktionen zu replizieren ist eine Sache. Diese Stimmigkeit, dieses Detail, dieses ästhetische und operative Vertrauen zu replizieren, eine andere.

Was am stärksten leiden dürfte, sind die Nischen-Utilities. Die Apps, die „eine einzige Sache machen“, die Micro-SaaS für 9,99 € im Monat, die leben, weil sie ein spezifisches Problem besser lösen als andere. Wenn ich mir das in einer Stunde selbst bauen kann, beginnt dieser Preis zu wackeln.

Die Barriere, die vorerst bleibt

Es gibt einen legitimen Einwand, und ich höre ihn auch.

Menschen wollen ihre Dinge nicht selbst bauen. Sie wollen sie benutzen.

Das stimmt. Und das wird vermutlich noch eine ganze Weile so bleiben. Da ist Bequemlichkeit, Vertrauen, kognitive Ersparnis. Schon das saubere Formulieren dessen, was man will, ist Arbeit, geschweige denn iterieren, korrigieren, wählen.

Aber diese Barriere ist nicht stabil. Sie sinkt mit der Gewohnheit. Sie sinkt mit besseren Oberflächen. Sie sinkt mit digitaler Bildung. Und sie sinkt vor allem, wenn der Vorteil, etwas auf Maß zu haben, offensichtlich genug wird, um den Aufwand zu rechtfertigen — während dieser Aufwand zugleich weiter sinkt.

Der Wendepunkt wird meiner Ansicht nach nicht „das Werkzeug ist zugänglich geworden“ sein. Er wird sein: „das erste Mal, dass mir jemand, den ich kenne, zeigt, was er in 20 Minuten gemacht hat, und ich denke: das könnte ich auch.“

Dieser Moment kommt. Für manche ist er schon da.

Was wir in den nächsten Jahren sehen könnten

Ich bin kein Analyst und habe keine Glaskugel. Nehmt das hier als informierte Eindrücke, nicht als Prognosen.

Ich glaube, wir werden eine erste Welle von Consumer-Produkten sehen, die nicht mehr gekauft, sondern gebaut werden. Anfangs in den tech-affineren Segmenten — Entwickler, Designerinnen, Studierende — und dann in konzentrischen Kreisen.

Ich glaube, wir werden einen enormen Druck auf die Preise der Micro-SaaS sehen. Nicht weil sie unnütz werden, sondern weil ein Abo schwer zu rechtfertigen ist, wenn dieselbe Nützlichkeit auf Zuruf entsteht. Es überlebt, wer etwas anbietet, das sich nicht leicht generieren lässt: Daten, Netzwerk, Vertrauen, tiefe Integration in bestehende Ökosysteme.

Und ich glaube, neue Vermittler werden auftauchen. Keine „App-Bauer“, sondern Kuratoren und Verteiler von Software-Absichten. Leute, die Prompts, Konfigurationen, getestete Flows zu Paketen schnüren, damit andere nicht bei null anfangen. Eine Art Marktplatz für Templates, aber tiefer, operativer.

Wahrscheinlich werden auch Regulierungsversuche kommen, mehr oder weniger ungeschickt, für bestimmte Sonderfälle.

Das Frühstück als Metapher

Ich kehre zum Anfang zurück, weil dort das Gefühl hängengeblieben ist.

Nicht die Geschwindigkeit hat mich wirklich getroffen. Es waren die kognitiven Kosten. Ich war abgelenkt, ich tat etwas anderes, mein Kopf hing an zwei Dingen gleichzeitig. Es war keine Arbeitssitzung. Es war kein „heute baue ich ein Produkt“.

Und doch ist das Ergebnis gut genug, um online zu bleiben.

Das ist für mich das Signal. Dass Software-Produktion zu etwas wird, das man parallel zu etwas anderem tut, wie eine E-Mail schicken oder etwas googeln. Eine Handlung, die keinen eigenen Kontext mehr braucht, keine spezifische Kompetenz, keine besondere mentale Energie.

Wenn etwas dahin kommt, ändert sich seine Stellung in der kognitiven und kulturellen Hierarchie. Und mit ihr ändert sich der Markt, der drumherum gewachsen ist.

Software wird zur Absicht. Noch nicht für alle, noch nicht stabil, aber die Richtung steht, und das Tempo zieht an.

Bleibt also heute Morgen die Frage.

Wenn du ein Consumer-Produkt baust: Liegt der Wert im technologischen Abstand zwischen dir und deinem Nutzer, oder in etwas, das auch dann existiert, wenn dieser Abstand verschwunden ist?

Wenn du keine klare Antwort hast, ist es vielleicht Zeit, eine zu finden.

Ich öffne den Mail-Client. Vierzehn neue E-Mails. Ich überfliege sie. Ich archiviere sechs, lösche drei, markiere zwei für später. Eine lese ich aufmerksam, denke nach, schreibe eine achtzeilige Antwort. Senden. Kaffee trinken.

Es ist 8:07 Uhr und ich habe die Kontrolle über den Tag.

Diese kleine morgendliche Liturgie ist der unterschätzteste, verachtetste und für mich kostbarste Teil des Arbeitslebens. Und ich will sie verteidigen, denn wir leben in einer Zeit, die entschieden hat, die E-Mail sei der Feind.

Der falsche Feind

Ich öffne LinkedIn und finde einen Beitrag: „Ich habe Inbox Zero erreicht, das hat mein Leben verändert.“ Ein anderer: „Ich lese keine E-Mails mehr und meine Produktivität ist explodiert.“ Noch einer: „Die E-Mail ist tot, lang lebe Slack.“ VIERHUNDERTTAUSEND LIKES.

Derweil bekommen in der echten Welt jene, die die E-Mail durch Slack ersetzt haben, dreihundertfünfzig Benachrichtigungen am Tag, verteilt auf siebenundzwanzig Kanäle, von denen sie bei elf nicht mehr wissen, warum sie existieren. Jene, die die E-Mail durch WhatsApp ersetzt haben, bekommen Sprachnachrichten von drei Minuten vierzig, die mit „also…“ beginnen und mit „okay, reden wir später drüber“ enden. Jene, die die E-Mail durch Calls ersetzt haben, haben einen Kalender, der wie ein von einem Sadisten gespieltes Tetris aussieht: Slots zu dreißig Minuten, von 9 bis 18 Uhr ineinandergesteckt, ohne Lücke, um auf die Toilette zu gehen.

Und mir will man weismachen, dass das Problem die E-Mail war?

Die E-Mail unterbricht dich nicht. Die E-Mail verlangt nicht, dass du jetzt, in diesem Moment, verfügbar bist, während du etwas tust, das mehr als elf Sekunden Aufmerksamkeit braucht. Die E-Mail schickt dir keinen roten Punkt, der im Hirn dieselbe chemische Reaktion wie eine Luftschutzsirene auslöst. Die E-Mail macht kein „ding“.

Die E-Mail liegt im Posteingang, höflich, geduldig, still, und wartet, bis du bereit bist.

Vielleicht ist genau das der Punkt. Die E-Mail ist eines der wenigen professionellen Kommunikationswerkzeuge, das per Bauart deine Zeit respektiert. Genau deshalb hassen sie viele: Die Zeit anderer zu respektieren ist fast verdächtig geworden.

Lob der schriftlichen Langsamkeit

Es gibt eine Sache, zu der dich die E-Mail zwingt und die viele „moderne“ Werkzeuge mit entwaffnender Leichtigkeit umgehen lassen: vor dem Kommunizieren denken.

Um eine E-Mail zu schreiben, musst du Gedanken ordnen. Entscheiden, was du sagen willst, an wen, warum. Einen Betreff wählen — und der Betreff einer E-Mail ist ein kleines Wunder der Verdichtung, eine Zeile, die jemanden im Meer der anderen Nachrichten überzeugen muss, sie zu öffnen. Vollständige Sätze schreiben. Lesen. Dich fragen, ob der Ton der richtige ist oder du gleich mit einem Adverb zu viel einen diplomatischen Krieg auslöst.

Vergleicht das mit einer Slack-Nachricht, die oft so klingt:

„Hey“ „Bist du da?“ „Ich hab was“ „Schnell“ „Eigentlich zwei Sachen“ „Erstens:“ [schreibt…] [schreibt…] [schreibt…] „Ach lass, sag ich dir mündlich“

Oder mit einer WhatsApp-Sprachnachricht — dem kommunikativen Äquivalent dazu, jemandes Bewusstseinsstrom abzufüllen und jemanden anders zu zwingen, ihn in Tempo 1x anzuhören. Die Sprachnachricht ist Joyces innerer Monolog, nur ohne literarisches Talent und mit Verkehrsrauschen im Hintergrund.

Die E-Mail ist das Gegenteil. Die E-Mail ist langsam, und die Langsamkeit ist ihr Superpower. Sie zwingt dich, einen verworrenen Gedanken in eine klare Botschaft zu verwandeln. Sie zwingt dich, Dringend von Wichtig zu trennen. Sie gibt dir Zeit, die Meinung zu ändern, bevor du auf Senden drückst — was nicht wenig ist.

Denn der Chat ist eine Maschine, die den Impuls belohnt. Du drückst Enter, und der Gedanke wird geteilte Realität. Und die Funktion „Für alle löschen“ hat, ehrlich gesagt, nie wirklich etwas für irgendwen gelöscht.

Der Paper Trail der Zivilisation

Es gibt einen weiteren Aspekt der E-Mail, den niemand genug feiert: Sie ist ein schriftlicher Beleg.

Ich arbeite oft mit der öffentlichen Verwaltung. Ich arbeite mit Unternehmen, die Rechtsabteilungen haben. Ich arbeite in einer Welt, in der irgendwann jemand sagt: „Aber wer hat das entschieden?“ Und in genau diesem Moment, der mit der Sicherheit einer Steuer in jedem Projekt kommt, willst du eine E-Mail haben.

Keine Slack-Nachricht, die jemand bearbeitet oder in einem Kanal namens „diverses-2“ verloren haben könnte. Keine Sprachnachricht, die niemand wirklich noch einmal anhören wird. Keine vage Erinnerung an einen Call, von dem es keine Notizen gibt, weil „er ja informell war“.

Eine E-Mail mit Datum, Uhrzeit, Absender, Empfängern und Text ist ein kleiner notarieller Akt des Arbeitslebens. Sie ist die endgültige Antwort auf „ich wusste das nicht“, „mir hat es niemand gesagt“, „so hatten wir das nicht abgemacht“. Ein externes Gedächtnis, das den Umstand kompensiert, dass Menschen Gespräche so erinnern, wie es ihnen passt.

Wenn jemand mir sagt: „Ich schicke dir eine Sprachnachricht, das geht schneller“, denke ich: schneller wovon? Schneller als der Moment, in dem ich werde belegen müssen, was wir uns gesagt haben?

Der Call, der eine E-Mail hätte sein können

Hier werde ich polemisch, und vielleicht sollte ich mich vorab entschuldigen. Doch nein, ich entschuldige mich nicht.

Siebzig Prozent der Calls, an denen ich teilnehme, hätten eine E-Mail sein können. Ihr wisst es auch. Jeder weiß es, der schon einmal an einer 30-Minuten-Sitzung teilgenommen hat, in der fünfundzwanzig Minuten damit vergingen, den Bildschirm zu teilen, drei mit Smalltalk und zwei damit, das zu sagen, was sich in vier Zeilen schreiben ließ.

„Lass uns einen kurzen Call machen“ ist eine der größten Lügen der modernen Arbeit. Es gibt keine kurzen Calls. Es gibt Calls, die fünf Minuten zu spät beginnen, weil jemand Mikrofonprobleme hat, doppelt so lange dauern wie geplant, weil jemand einen sachfremden Punkt anschneidet, und mit „Okay, zusammenfassend, die nächsten Schritte sind…“ enden, die niemand wirklich notiert. Und der nächste Call beginnt bei Null, als wäre der vorherige ein Traum gewesen.

Wisst ihr, was kein Mikrofonproblem hat? Eine E-Mail. Wisst ihr, was nicht doppelt so lange dauert wie geplant? Eine E-Mail. Wisst ihr, was beim Empfangen schon die „nächsten Schritte“ enthält? Genau.

Ich sage nicht, dass Calls nichts taugen. Sie taugen, sehr sogar. Wenn etwas Komplexes zu diskutieren ist, wenn ein Konflikt zu lösen ist, wenn Gesichter und Tonfälle zählen. Aber für alles andere — Statusupdates, binäre Entscheidungen, Fragen mit Antwort, Dokumente teilen — ist die E-Mail in fast jeder ehrlich relevanten Metrik überlegen: Zeit, Klarheit, Nachvollziehbarkeit, Respekt für die Person auf der anderen Seite.

Das Ritual

Zurück zu 7:58 Uhr. Zum Kaffee mit der richtigen Temperatur. Zum Posteingang, der wartet.

Es gibt ein Ritual im Postöffnen, das die Echtzeit-Werkzeuge ein wenig zerstört haben. Das Ritual, den Tag in Ordnung zu beginnen. Zu sehen, was angekommen ist, zu entscheiden, was wichtig ist, mit klarem Kopf zu antworten.

Es ist einer der letzten Räume des Arbeitstags, in denen du das Tempo bestimmst, bevor Slack, Teams, WhatsApp und der Kalender übernehmen und deine Stunden in ein Pingpong-Spiel auf sieben Tischen gleichzeitig verwandeln.

Die E-Mail ist nicht sexy. Keine animierten Emojis. Kein blauer Haken. Sie sagt dir nicht, ob jemand „gerade tippt“. Sie lässt dich nicht in Echtzeit verbunden fühlen.

Aber um 8 Uhr morgens, mit Kaffee in der Hand und vierzehn Nachrichten, die ich in Ruhe abarbeite, mache ich meine beste Arbeit. Und kein grüner Statuspunkt der Welt wird diesen Moment je ersetzen können.

Also nein. Die E-Mail ist nicht tot. Die E-Mail ist vielleicht die einzige Erwachsene im Raum. Und wie es Erwachsenen im Raum oft ergeht, wird sie zugunsten der Lautesten ignoriert.

Und doch.

Der Kunde hat unrecht.

Nicht immer, klar. Nicht in allem. Aber viel öfter, als wir zugeben mögen. Ich frage mich, ob das eigentliche Problem nicht der Kunde ist, sondern die höfliche Lüge, die wir ihm seit Jahren erzählen. Die vom „Der Kunde hat immer recht“. Eine Lüge, die in der italienischen Software Schäden angerichtet hat, die niemand sauber zählen kann, weil Misserfolge selten ein Schild „Misserfolg“ tragen. Sie sind meist leiser. Es sind Projekte, die in Produktion gehen und die niemand nutzt. Es sind verbranntes Geld für Dinge, die nichts verbessern. Es sind lange Nächte von Menschen, die wussten, dass es schiefging — aber nicht den Raum oder die Erlaubnis hatten, es zu sagen.

Das ist ein etwas bösartiger Text, ja. Ich verlange nicht, dass ihr zustimmt. Ich verlange nur Ehrlichkeit, für die Dauer dieser Lektüre.

Das Ja, das Projekte tötet

Ich habe mehr Projekte an einem Ja sterben sehen als an einem Nein.

Der Mechanismus ist fast immer derselbe, und gerade deshalb beunruhigt er. Der Kunde verlangt etwas. Du weißt es, du fühlst es, du siehst es in den Details: Es ist technisch falsch, oder wirtschaftlich, oder als Richtung. Aber du sagst trotzdem Ja.

Du sagst Ja, weil es einen Vertrag gibt. Weil eine Beziehung zu schützen ist. Weil „wir richten das schon noch“. Weil der Handschlag schon erfolgt ist und Zurückrudern wie eine Niederlage wirkt. Weil Nein zu sagen unbequem ist, Argumente verlangt, Energie verlangt — und vor allem Mut.

Und so stirbt das Projekt nicht in einem Schlag. Es stirbt ein Ja nach dem anderen.

Jedes Ja fügt ein Feature hinzu, das niemand nutzen wird. Jedes Ja verschiebt ein Stück Deadline oder drückt ein Stück Qualität. Jedes Ja macht die Architektur etwas brüchiger und den Code etwas verschlungener, bis das, was du baust, kein Produkt mehr ähnelt, sondern einem geschichteten Kompromiss.

Am Ende lieferst du eine Software, die hundertfünfzig Dinge tut, keines davon gut, und der Kunde sieht dich an und sagt: „Das ist nicht, was ich wollte.“

Und hier brennt der Punkt, denn in gewissem Sinn hat er recht. Es ist nicht, was er wollte. Es ist, was er verlangt hat. Zwei verschiedene Dinge.

Und vielleicht ist unser eigentliches Handwerk nicht, Befehle auszuführen. Es ist, den Unterschied zu erkennen.

Katalog des Grauens (alle wahr, leider)

Was folgt, ist wahr. Die Namen sind geändert, die Dynamiken nicht. Und falls ihr denkt „so einen habe ich auch schon gesehen“, seid ihr nicht allein.

Die endlose ERP

Ein mittelgroßes Unternehmen verlangt eine ERP. So weit normal. Während der Entwicklung fügt jede Abteilung Anforderungen hinzu. HR will den Urlaubsmodul, Marketing das Dashboard, die Buchhaltung die Anbindung an den Steuerberater, und jeder hält sich für den Mittelpunkt der Welt.

Niemand hat die Macht, „Schluss“ zu sagen, weil jede Abteilung ein „interner Kunde“ ist, der „recht hat“. Ergebnis: achtzehn Monate Entwicklung, ein Produkt, das alles schlecht macht, und nach dem Release nutzt das Unternehmen weiter Excel. Das wenigstens, in seiner Bescheidenheit, niemanden verrät.

Die Copy-Paste-Ausschreibung

Eine Kommune muss einen Service digitalisieren. Die Ausschreibung wird abgeschrieben aus jener einer anderen Kommune, vielleicht dreimal so groß, mit völlig anderen Bedürfnissen. Hineingeraten Anforderungen, die auf dem Papier gut klingen, die aber kein Bürger jemals nutzen wird.

Wer den Auftrag gewinnt, weiß es oft. Aber die Ausschreibung ist die Ausschreibung. Also baut man genau das Geschriebene. Man liefert, prüft ab, hakt Kästchen ab. Die Plattform geht online.

Sechs Monate später wird der Service immer noch am Telefon abgewickelt.

Das Traurigste: Formell ist alles gut gelaufen.

Die App, die alles ändern sollte

Eine lokale Verwaltung will eine Mobile-App für die Bürger. Der Entscheider ist ein Stadtrat, der die App einer anderen Kommune gesehen hat und sie genauso will. Keine Bedarfsanalyse, keine Nutzerforschung, nichts. Nur: „Ich will die App.“

Der Anbieter baut sie. Beim Launch laden sie vierhundert herunter. Drei Monate später nutzen zwölf sie, die Kommunemitarbeiter mitgezählt.

Der Stadtrat hält die Pressekonferenz und spricht von Innovation. Der Anbieter kassiert und geht zum nächsten.

Und ich kann mich nie entscheiden, wer mir in der Geschichte am meisten Unbehagen bereitet.

Das Restyling, das eine Neuschreibung war

Ein Kunde verlangt, die Site „aufzufrischen“. Der Vertrieb verkauft ein Restyling. Bei der ersten operativen Sitzung kommt heraus: Die Site hat kein CMS, die Datenbank ist eine Excel-Datei, die Inhalte existieren nicht, und „Auffrischung“ bedeutet, die ganze digitale Präsenz neu zu denken.

Aber das Angebot ist das eines Restylings, die Timeline ist die eines Restylings, und die Erwartungen sind die eines Restylings.

Alle wissen, dass es kein Restyling ist. Niemand sagt es.

Das Zombie-Projekt

Ein Projekt sollte sechs Monate dauern und tritt ins dritte Jahr ein. Es funktioniert nicht, wird nicht genutzt, aber niemand schließt es, weil das hieße, einen Fehler einzugestehen.

Der Kunde zahlt weiter Change Requests. Der Anbieter fakturiert weiter. Beide wissen, es ist tot. Beide tun, als lebte es.

Es scheitert nie offiziell. Es hört einfach auf, in Sitzungen erwähnt zu werden, wie ein unangenehmer Onkel, von dem man bei Tisch nicht spricht.

Warum es wirklich passiert

Es passiert, weil unsere Branche ein strukturelles Problem mit der Wahrheit hat.

Das Geschäftsmodell der italienischen IT-Beratung ist auf dem Ja gebaut. Du gewinnst Projekte mit Ja. Du behältst Kunden mit Ja. Du machst Karriere mit Ja. Das ganze System, vom Vertrieb über die Projektleitung bis zu den Entwicklern, ist optimiert, um Konflikt zu minimieren und kurzfristige Fakturierung zu maximieren.

Das Problem: Kurzfristig und langfristig liegen im Krieg.

Heute Ja zu sagen heißt fast immer, morgen zu zahlen. Jedes zusätzliche Feature ist technische Schuld. Jede ohne Analyse akzeptierte Anforderung ist eine Zeitbombe. Jede gestauchte Timeline, um jemandem zu gefallen, ist eine Garantie für Überstunden, oft unbezahlt, und für geopferte Qualität.

Und derweil lernt der Kunde nie. Nicht weil er dumm wäre, sondern weil ihm niemand sagt, dass diese Anfrage falsch war. Niemand sagt ihm, dass diese Ausschreibung schlecht geschrieben war. Niemand sagt ihm, dass diese App niemandem nützte.

Umringt von Nickenden, fragt der Kunde weiter dieselben falschen Dinge, und der Kreis beginnt von neuem.

Hier kommt der Teil, der stört, weil er die Verantwortung verschiebt.

Es ist nicht die Schuld des Kunden. Es ist unsere Schuld.

Es ist die Schuld einer Branche, die ihre Rolle aufgegeben hat — die der Expertin. Jener, die Dinge weiß, die der Kunde nicht weiß, und die die Pflicht — nicht das Recht — hat, sie zu sagen.

Das Nein als Dienst

Der beste Dienst, den du einem Kunden erweisen kannst, ist Nein zu sagen.

Nein, dieses Feature ist nicht nötig.

Nein, diese Timeline ist nicht realistisch.

Nein, diese Ausschreibung ist schlecht geschrieben, und wenn wir sie wörtlich befolgen, bauen wir etwas Nutzloses.

Nein, du brauchst keine App.

Nein, du brauchst keine KI.

Nein, du brauchst kein Restyling. Du brauchst innezuhalten und zu verstehen, was du wirklich tun willst.

Jedes Nein kostet. Es kostet Unbequemlichkeit, es kostet Spannung, es kostet ein paar harte Telefonate. Manchmal kostet es das Projekt.

Aber jedes Nein ist auch ein Akt des Respekts gegenüber dem Kunden, weil es ihn als Erwachsenen behandelt, der die Wahrheit hören kann — nicht als jemanden, dem zur Beruhigung zuzustimmen ist.

Die besten Kunden meiner Karriere sind die, denen ich am meisten Nein gesagt habe. Anfangs versteifen sie sich, ganz normal. Wenn du dann standhältst und ruhig argumentierst, geschieht etwas: Sie verstehen, dass dein Ja, wenn es kommt, glaubwürdig ist.

Vertrauen baut sich nicht auf ständigem Einverständnis. Es baut sich auf Aufrichtigkeit.

Und Aufrichtigkeit ist in unserer Branche selten. Vielleicht seltener als ein guter Entwickler. Vielleicht seltener als ein pünktlich geliefertes Projekt. Vielleicht seltener als eine gut geschriebene Ausschreibung.

Ein minimales Manifest, ohne Heldentum

Ich weiß nicht, ob das ein Manifest ist, aber wenn doch, passt es für mich in drei Zeilen.

Sag nicht Ja, wenn du weißt, dass es Nein ist.

Bau nicht, was der Kunde verlangt, wenn du weißt, dass es nicht ist, was er braucht.

Und wenn du dich irrst — denn du wirst dich irren, und wir alle werden uns irren —, irre dich wenigstens, indem du die Wahrheit sagst, nicht indem du nickst.

Der Kunde hat nicht immer recht. Aber er verdient immer jemanden, der den Mut hat, es ihm zu sagen.

Der Plan überlebt nie den Parkplatz.

18:34 Uhr. Ich komme an. Und der Supermarktparkplatz ist voll. Nicht voll im Sinn von „wenige Plätze frei“. Voll im Sinn eines Ortes, an dem die Regeln aufhören zu gelten und die Geometrie zur Meinung wird. Autos in zweiter Reihe, Autos auf dem Gehweg, Autos auf gelben Streifen, Autos diagonal in Plätzen, die für Längsparken gedacht waren.

Da steht ein weißer SUV. Es ist immer ein weißer SUV. Er belegt anderthalb Plätze mit einer fast poetischen Selbstverständlichkeit, als wäre er so geboren und wir wären die Maßstabsverwirrten. Ein paar Meter weiter steht ein Panda so eng an einem Pfeiler, dass ich mich ernsthaft frage, ob der Fahrer den Ausstieg über die Heckklappe schon eingeplant hat. Vielleicht ist das ein Feature.

18:37 Uhr. Erste Runde. Nichts. Zweite Runde. Nichts. Dritte Runde.

Eine Frau lädt gerade die Einkäufe ein. Ich halte, setze den Blinker. Warte. Sie lädt eine Tüte. Dann eine zweite. Dann ordnet sie die Tüten. Dann nimmt sie das Telefon. Dann telefoniert sie. Dann sucht sie die Schlüssel. Ich warte.

Hinter mir bildet sich eine Schlange. Jemand hupt. Die Frau schaut mich an, als würde ich sie angreifen. Und ich merke, dass ich in diesem Moment genau das tue, was ich an anderen hasse: Ich verwandle eine banale Geste in ein kleines Kräftemessen.

18:43 Uhr. Geparkt. Neun Minuten, bis das Auto stand. Der Einkauf wird sieben dauern. Das Verhältnis ist falsch. Das Verhältnis ist immer falsch.

Bürgerkrieg auf kleiner Flamme

Der Supermarktparkplatz um 18:30 ist jener seltsame Punkt, an dem sich die Zivilgesellschaft geräuschlos auflöst. Nichts Spektakuläres geschieht, kein einzelnes Ereignis. Eher ein Stimmungswechsel. Als beträte man einen Raum, in dem jemand das Niveau gegenseitigen Vertrauens heruntergedreht hat.

Menschen, die im normalen Leben höflich, vernünftig, funktional sind — die Danke sagen, die die Tür aufhalten, die Mülltrennung machen —, betreten den Parkplatz und werden zu Raubtieren. Jeder Sozialvertrag verflüchtigt sich. Es gilt das Gesetz des Größeren, des Schnelleren, des Frecheren.

Die Regeln sind da. Die Pfeile, die Markierungen, die Schilder. Aber zu dieser Uhrzeit werden sie zu Vorschlägen. Zu Dekoration. Zu abstrakter Kunst auf dem Asphalt.

Und dann ist da er, der Einkaufswagen.

Der Einkaufswagen ist das perfekte Sinnbild, weil er ein einfaches Objekt ist, mit einem präzisen Ort, an den er gehört: in den Sammelständer. Der ist zehn Meter entfernt. Zehn. Und doch landet ein peinlich hoher Anteil von Wagen mitten auf dem Parkplatz, blockiert einen Stellplatz oder rollt langsam mit der Unausweichlichkeit eines griechischen Schicksals gegen deine Tür.

Ich frage mich immer, wer die Person ist, die den Wagen dort lässt. Und dann denke ich, dass ich es vielleicht weiß. Wahrscheinlich dieselbe Person, die im Büro Mails über Corporate Social Responsibility schreibt. Oder vielleicht ich, an einem schlechten Tag, wenn ich denke „wird ihn schon jemand mitnehmen“.

Ich habe eine etwas bösartige Theorie, die ich aber nicht loswerde: Wie ein Mensch mit dem Einkaufswagen umgeht, ist einer der zuverlässigsten moralischen Tests, die es gibt. Keine Strafe für den, der ihn liegen lässt, keine Belohnung für den, der ihn zurückbringt. Reiner freier Wille. Und der Parkplatz zeigt dir jeden Abend um 18:30, was der freie Wille deiner Gemeinschaft wert ist.

Der SUV und die Lüge

Reden wir über den SUV.

Nicht über alle SUVs. Über den Stadt-SUV. Den, den man kauft, um in den Supermarkt zu fahren, die Kinder in die Schule zu bringen und den Weg Wohnung-Büro auf asphaltierten Straßen zu fahren. Den SUV, der nie eine Schotterstraße sehen, nie eine Furt durchqueren, nie etwas Härteres bewältigen wird als die Bremsschwelle vor der Grundschule.

Der Stadt-SUV ist ein Objekt, das für einen Kontext entworfen wurde, der im Leben seiner Nutzer nicht existiert. Das automobile Pendant zum Kauf eines Bergsteigerrucksacks für den Weg ins Büro. Und doch kaufen wir ihn, weil der SUV eine Geschichte verkauft: Sicherheit, Dominanz, Kontrolle.

Du sitzt hoch, siehst alles, bist geschützt. „Geschützt wovor“, sagt niemand wirklich. Vielleicht vor dem Verkehr, den der SUV selbst mitverursacht — vermutlich.

Auf dem Parkplatz aber zeigt der SUV seine wahre Natur. Zu breit für Stellplätze, die in den 90ern entworfen wurden, als Autos kleiner waren und Menschen, ich weiß nicht, weniger ehrgeizig. Er passt nicht. Er ragt heraus. Er besetzt den Nachbarplatz mit.

Und es gibt Details, die mich immer unangenehm berühren. Etwa, dass der Fahrer ein hinten vorbeilaufendes Kind oft nicht sieht, weil die Motorhaube auf Erwachsenenhöhe liegt. Dann hilft die Rückfahrkamera. Ein technologisches Problem zur Lösung eines Problems, das die Technologie selbst geschaffen hat. Ein perfekter Absurditätskreis.

Aber der SUV ist, genauer betrachtet, nicht nur ein Konsumentenfehler. Es ist ein Designfehler. Jemand hat ein städtisches Fahrzeug entworfen, das im städtischen Raum nicht funktioniert. Jemand hat es Menschen verkauft, die in Städten mit engen Straßen, kleinen Parkplätzen, Gehwegen leben, auf denen Fußgänger theoretisch Vorrang haben sollten.

Das Produkt ist nicht falsch für den, der es entworfen hat. Es ist falsch für den Kontext, in dem es existiert.

Und das, wenn man Software macht, klingt vertraut.

Design für den falschen Kontext

Ich entwerfe Software. Und ich erkenne im Parkplatz denselben Fehler, den ich in vielen gescheiterten Projekten sehe: Entwerfen für die Idealnutzerin statt für die reale.

Den Supermarktparkplatz hat jemand entworfen, der dachte, vermute ich: Die Leute werden geordnet ankommen, zwischen den Linien parken, den Motor abstellen, einkaufen, zurückkommen, abfahren. Ein linearer, rationaler, sauberer Fluss. Wie ein Diagramm.

Menschen sind kein Diagramm.

Menschen kommen alle um 18:30, weil alle zur selben Zeit Feierabend haben. Sie kommen genervt, weil der Verkehr höllisch war. Sie kommen mit zu großem Auto, weil der Markt ihnen gesagt hat, groß sei besser. Sie kommen mit dem Telefon in der Hand, weil sie zu Hause anrufen, ob auch Parmesan gebraucht wird. Sie kommen mit Kindern, die hinten schreien.

Sie kommen, kurz: als Menschen.

Und der Parkplatz ist nicht für Menschen entworfen. Er ist für Autos entworfen. Was etwas anderes ist.

Es ist derselbe Fehler, den wir in der Software machen: Wir entwerfen für den Happy Path. Den Nutzer, der die Anweisungen liest, dem Flow folgt, jedes Feld ausfüllt, dort klickt, wo er klicken soll. Dann kommt der reale Nutzer, müde, abgelenkt, mit drei offenen Tabs und dem Chef, der via WhatsApp schreibt, und das System bricht zusammen.

Nicht weil der Nutzer dumm ist. Sondern weil das Design nicht vorgesehen hat, dass der Nutzer ein Mensch ist.

Der Supermarktparkplatz ist eine Benutzeroberfläche. Eine miserable Benutzeroberfläche. Und jeden Abend um 18:30 stürzt sie ab.

Die Stadt, die wir gewählt haben

Irgendwann merke ich, dass ich die Schuld dem Parkplatz, dem SUV, der Telefon-Frau, den herumirrenden Wagen gebe. Aber der Parkplatz ist nur ein Symptom.

Die Krankheit ist die Stadt.

Wir haben Städte um Autos herum gebaut. Nicht um Menschen, nicht um Kinder, nicht um Ältere, nicht um jene, die zu Fuß gehen oder Rad fahren. Um Autos.

Jede Stadtplanungsentscheidung der letzten Jahrzehnte wirkt wie eine Antwort auf dieselbe Frage: Wo lassen wir die Autos? Verbreiterte Straßen für die Autos. Geleerte Innenstädte für Parkplätze. Wohnviertel weit weg von allem gebaut, sodass du, um Brot zu kaufen, rate mal, das Auto brauchst.

In Pescara sieht man es deutlich. Eine flache Stadt, perfekt für Fahrräder, in der fast niemand Fahrrad fährt. Eine Küstenstadt, deren Strandpromenade acht Monate im Jahr Parkplatz ist. Eine Stadt, in der die Hauptstraße für Fußgänger geöffnet wurde und die Leute protestiert haben, weil „man nicht mehr vor dem Laden parken kann“ — als stünde das Recht, vor dem Schaufenster zu parken, in der Verfassung.

Wir haben die Stadt für den falschen Nutzer entworfen. Und nun wundern wir uns, dass der richtige Nutzer, der dort lebt, sich nicht wohlfühlt.

Das Traurigste ist vielleicht, dass wir uns daran gewöhnt haben. Es gefällt uns nicht, aber wir halten es für normal. Als wäre es unausweichlich, dass der Kauf von vier Dingen einen kleinen Ausdauertest verlangt.

18:51

Ich verlasse den Supermarkt mit meiner Tüte. Milch, Brot, Tomaten, Waschmittel. Glatte sieben Minuten, wie geplant.

Zurück zum Auto. Ein Einkaufswagen lehnt an meiner Tür. Ich stelle ihn weg. Ein SUV hat so eng geparkt, dass ich von der Beifahrerseite einsteigen und über den Schalthebel klettern muss. Ich tue es. Mit der Milch in der Hand. Mit Restwürde.

Ich verlasse den Parkplatz. Es dauert vier Minuten, weil jemand die Ausfahrt blockiert, um auf einen Platz zu warten. Diese Sache bringt mich jedes Mal aus der Fassung, und jedes Mal sage ich mir, es sei nur ein Detail. Aber dann denke ich, dass schlecht entworfene Systeme aus Details bestehen, aus kleinen Engpässen, aus Mikro-Egoismen, die zu Makro-Problemen werden.

Ich komme nach Hause.

Gesamtzeit für vier Produkte: siebenunddreißig Minuten. Davon sieben Einkauf und dreißig Infrastruktur.

Dreißig Minuten in einem schlecht entworfenen System verloren. Jeden Tag, Millionen Menschen, dieselbe Erfahrung. Multipliziere die verlorene Zeit mit der Zahl der Personen mal Tagen, und du bekommst eine Zahl, die niemand berechnen will, weil sie zu deprimierend wäre.

Und währenddessen hat der Supermarkt eine App für den Online-Einkauf. Funktioniert hervorragend, sagt man. Du musst sie nur herunterladen, einen Account anlegen, die Nutzungsbedingungen akzeptieren…

Ach nein. Das war die Waschmaschine.

Aber dieselbe Logik. Immer dieselbe Logik. Projekte für eine geordnete Welt, dann ins echte Leben geworfen, das nie geordnet ist. Und vielleicht ist es genau das, was ich neben Brot und Waschmittel nach Hause trage: Es ist nicht so, dass wir böse geworden wären. Es ist so, dass wir uns in Räumen bewegen, die das Schlimmste hervorlocken, weil sie für eine Version von uns gedacht waren, die nicht existiert.

Und morgen, um 18:30, falle ich vermutlich wieder hinein. Mit demselben Plan. Und demselben Parkplatz.

Mit der KI passiert dasselbe. Doch wenn ich mich umsehe, reagieren viele Unternehmen, als wäre es ein gewöhnliches Update. Ein Add-on. Ein Plugin.

Und das ist vielleicht ein Problem.

Die Falle des „Etwas-KI-dazu“

Es ist fast ein Reflex geworden. Ein Chatbot im Kundenservice. Eine generierte Zusammenfassung im Dashboard. Ein Copilot in einer Sidebar. Eine „intelligentere“ Suche.

Nützliche Dinge, wirklich. Ich will nicht den Puristen geben, der alles snobt, was funktioniert. Aber ich frage mich, ob sie nicht zugleich zutiefst konservative Dinge sind. Wie einen Elektromotor an eine Pferdekutsche zu schrauben und es Revolution zu nennen. Die Kutsche bleibt eine Kutsche, nur was sie zieht, ändert sich.

Diese Dynamik habe ich schon gesehen. 2007 hieß sie „Mobile“.

Als das iPhone explodierte, nahmen viele Unternehmen ihre Desktop-Sites und „passten sie an“. Responsive, kleinere Buttons, neu geordnete Spalten, Hamburger-Menü, fertig. Technisch korrekt. Strategisch… fast irrelevant.

Denn gewonnen haben nicht jene, die das Alte ans Neue angepasst haben, sondern jene, die alles neu gedacht haben.

Uber ist keine Taxi-Site responsive gemacht. Es ist ein Produkt, das ohne GPS, Always-on-Verbindung und Gerät in der Tasche keinen Sinn ergäbe.

Instagram ist nicht Flickr im Kleinformat. Es ist eine visuelle Sprache, geboren fürs Mobile, gedacht für die einhändige Nutzung im Gehen.

WhatsApp ist keine E-Mail auf dem Smartphone. Es ist Kommunikation, neu gedacht um eine Voraussetzung: Das Gerät ist persönlich, immer dabei, immer verbunden.

Keines dieser Produkte wäre aus der „flicken-wir-das-Bestehende“-Mentalität entstanden. Sie entstanden aus einer anderen Frage.

Die richtige Frage

Die Frage ist nicht: Wie füge ich meinem Produkt KI hinzu?

Die Frage ist: Wenn ich dieses Produkt heute entwerfen würde, im Wissen, dass die Hälfte der Interaktionen durch KI-Agenten läuft — wie wäre es anders?

Klingt nach Nuance, ist aber keine.

Zwanzig Jahre lang haben wir Software auf einer fast unsichtbaren Annahme gebaut: Ein Mensch sitzt vor einem Bildschirm und interagiert mit einer GUI. Klickt, scrollt, füllt Felder.

Diese Annahme verschwindet nicht, hört aber auf, die einzige zu sein. Und sobald sie nicht mehr die einzige ist, werden viele scheinbar „normale“ Entscheidungen plötzlich willkürlich.

Denkt an die täglichen Aktionen in digitalen Produkten, die ein Agent mit den richtigen APIs und Berechtigungen für uns übernehmen könnte. Restaurant reservieren. Angebote vergleichen. Formular ausfüllen. Termin verschieben. Bericht analysieren. Einkauf bestellen. Rechnung bezahlen.

Keine Science-Fiction. Sprachmodelle bewältigen schon heute komplexe Flows. Der Engpass ist meist nicht die KI. Es ist die Bauweise der Produkte.

Viel Software wurde dafür entworfen, betrachtet und geklickt zu werden. Nicht dafür, verstanden und orchestriert zu werden.

Und dieser Unterschied ist meiner Meinung nach gewaltig.

Von Oberflächen zu Verträgen

Hier wird es konkret.

Jahrelang war das „Produkt“ die Oberfläche. UI war das Produkt. Alles andere — Backend, APIs, Datenbank — war Infrastruktur im Dienst der Bildschirme. Designer, die Screens zeichneten, Entwicklerinnen, die sie umsetzten, Product Manager, die Conversions auf Buttons maßen.

Im kommenden Paradigma wird das Produkt zum Vertrag.

Klare APIs. Strukturierte Dokumentation. Kohärente Datenmodelle. Capabilities, die semantisch reich exponiert sind. Fehlermeldungen, die erklären, was passiert ist und was zu tun ist. Stabile Verträge.

Die GUI verschwindet nicht, ändert aber ihre Rolle. Sie wird ein Client des Produkts, nicht das Produkt. Ein Client unter vielen.

Und paradoxerweise ist das eine gute Nachricht. Denn eine API, die für KI-Agenten konsumierbar gedacht ist, zwingt dich zu guter Software. Sie zwingt zu Klarheit. Konsistenz. Verlässlichkeit. Komponierbarkeit.

Die KI senkt nicht die Latte. Sie hebt sie.

Von Feature zu Capability

Es gibt einen Mentalitätswechsel im Herzen des Product Managements.

Die traditionelle Mentalität ist Feature-getrieben. Wir fügen Feature X hinzu. Es braucht fünf Screens, drei Endpoints, zwei Tabellen. Wireframes, User Stories, Akzeptanzkriterien. Und ein fast immer linearer Flow: Nutzer kommt in A, klickt B, füllt C, erhält D.

Die AI-native Mentalität neigt dagegen zu capability-getrieben.

Du entwirfst keinen Pfad. Du entwirfst einen Baustein. Eine Capability, die jeder orchestrieren kann: ein Mensch über GUI, ein Agent über API, ein anderes System über Webhook. Und sie wird oft auf Weisen kombiniert, die du nicht vorhergesehen hast.

Mächtiger, aber schwieriger. Es verlangt, in Verträgen, Invarianten, Vor- und Nachbedingungen zu denken. Es verlangt reifere Ingenieurskunst.

Ich gestehe, ich werde dabei ein wenig euphorisch. Denn es ist, als ob der Druck der KI endlich jene Best Practices unausweichlich machte, die viele Ingenieure jahrelang ins Leere wiederholt haben.

Das Paradox der Offenheit

Es gibt einen weiteren kontraintuitiven Aspekt.

Jahrelang war das dominante Modell der Lock-in. Geschlossene Daten, schwierige Exporte, Walled Gardens. „So verteidigen wir den Wettbewerbsvorteil.“

In einer Welt der KI-Agenten droht Geschlossenheit zum Handicap zu werden.

Ein Agent arbeitet besser mit kooperierenden Diensten. Mit strukturierten Daten. Mit dokumentierten APIs. Mit Interoperabilität. Wenn ein Dienst opak und schwer integrierbar ist, wird der Agent ihn umgehen und komponierbarere Alternativen wählen.

Hier liegt ein wunderschönes, fast poetisches Paradox: Um Nutzer zu halten, musst du sie frei gehen lassen.

Das verschiebt das Spielfeld auch für kleine Unternehmen. Auf Offenheit, API-Qualität, Doku, sauberen Verträgen kann eine agile KMU mithalten. Manchmal sogar einen legacy-belasteten Konzern überflügeln.

Compliance als Superpower

Dieser Teil liegt mir besonders am Herzen, denn er ist mein tägliches Terrain.

DSGVO, AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. Oft als Kosten erlebt. Als Lästigkeit. Als Steuer aufs Geschäft.

Ich sehe sie zunehmend anders.

In einem von KI-Agenten vermittelten Ökosystem wird Vertrauen zu einer rechenbaren Ressource. Nicht nur Marketing. Ein Input in Entscheidungen.

Wenn ein Agent zwischen zwei ähnlichen Diensten wählen muss, wird er den verifizierbaren bevorzugen. Den mit transparentem SBOM. Vollständigem Audit-Trail. Dokumentiertem Privacy by Design. Erklärter und nachweisbarer Konformität.

So gesehen hört Compliance auf, nur Kostenlast zu sein, und wird zu einem für Maschinen lesbaren Qualitätssignal. Ein Wettbewerbsdifferenzierer.

Es klingt fast seltsam, das so zu sagen, aber ich glaube, es stimmt: Compliance kann zum Superpower werden.

Und vielleicht baut Europa, mit all seiner Bürokratie, die viele zum Schnaufen bringt, ein Terrain, auf dem Vertrauen rechenbar ist. Wenn du es in Architektur verwandeln kannst, ist es keine Bremse. Es ist ein Vorteil.

Wo das Ganze konkret wird

Ich könnte hier auf der Ebene der Ideen aufhören. Aber das wäre unehrlich, denn für mich ist dieser Übergang konkret und alltäglich.

Wenn wir ein Produkt migrieren, „modernisieren“ wir nicht nur den Stack. Wir bereiten einen Dienst auf eine Zukunft vor, in der Agenten ebenso mit ihm interagieren wie Menschen.

Wenn wir eine SBOM-Plattform für Software-Abhängigkeiten bauen, machen wir nicht nur Compliance. Wir bauen eine verifizierbare Vertrauensschicht.

Wenn wir das Schwergewicht auf spezifikationsgetriebene Entwicklung verlegen — die Spezifikation als Hauptprodukt, der Code als abgeleitetes Artefakt —, ist das nicht nur Methode. Es ist eine Arbeitsweise, in der die KI echter Partner sein kann, kein Gadget.

Irgendwann merkst du, dass alles zusammenhält. Saubere Architektur, rigorose Doku, Compliance by Design, API-first, Spezifikation als zentrales Objekt. Facetten derselben Idee.

In der kommenden Welt ist Klarheit Macht.

Das wahre Risiko

Das größte Risiko heute ist nicht, mit KI „falsche“ Dinge zu tun.

Es ist, die richtigen Dinge im alten Paradigma zu tun.

Es ist, einen Chatbot anzukleben, statt die Architektur der Interaktion neu zu denken. KI-Vorschläge in eine Oberfläche zu setzen, die in dieser Form vielleicht gar nicht existieren sollte. KI zu nutzen, um Code schneller zu schreiben, ohne sich zu fragen, ob wir klarere Spezifikationen schreiben sollten.

Ich weiß, das ist eine starke Position. Und ich weiß, dass viele Unternehmen reale Resultate erzielen, indem sie bestehenden Produkten KI hinzufügen. Ich sage nicht, dass alles falsch ist.

Ich sage, dass es unzureichend ist. Dass es droht, das gestrige Spiel mit den heutigen Stücken zu sein.

Ein Liebesbrief an die Technologie, die hilft

Ich schließe mit einer persönlichen Note, denn dieses Gespräch ist für mich nicht nur Strategie.

Ich liebe Technologie, wenn sie hilft. Wenn sie zugänglich macht, was exklusiv war. Wenn sie vereinfacht, was kompliziert war. Wenn sie Zeit für das Wesentliche freigibt.

Wenn ich an KI in digitalen Produkten denke, denke ich nicht nur an Chatbots, die statt Menschen antworten. Ich denke an einen alten Mann, der über einen Agenten, der die Bürokratie versteht und übersetzt, mit der Verwaltung interagieren kann. An einen kleinen Unternehmer, der Compliance ohne Berater-Armee meistert, weil die Software ihn nativ unterstützt. An eine Ärztin, die bei der Patientin bleiben kann, während die Doku besser läuft. An eine Studentin mit Behinderung, die eine wirklich barrierefreie Erfahrung findet, kein Häkchen in einem Excel.

Um dorthin zu gelangen, reicht es nicht, „KI hinzuzufügen“. Es geht darum, Produkte für eine Welt neu zu denken, in der Menschen und Agenten koexistieren.

Es ist nicht leicht. Es verlangt, Annahmen in Frage zu stellen, die wir für gegeben hielten. Es verlangt neue Kompetenzen und eine gewisse Demut. Es verlangt die unbequemste Frage: Wenn ich heute bei null anfinge, würde ich es so machen?

Aber es ist eine schöne Herausforderung. Eine, die einem Lust macht, sich an die Arbeit zu setzen.

Denn auf der anderen Seite liegt vielleicht eine nützlichere, zugänglichere, verlässlichere Software. Und in einem nicht banalen Sinne menschlichere.