DSFA als Gattung, nicht als Formular

Das EDPB-Template ist letzte Woche öffentlich erschienen. Ich habe es zum ersten Mal im Zug zwischen Pescara und Rom geöffnet, ein PDF von rund vierzig Seiten, das ich zu kennen schien, noch bevor ich es las, mit jener besonderen verstreuten Aufmerksamkeit, die man Dokumenten widmet, von denen man schon alles weiß. Die DSFA begleitet mich seit Jahren, ich habe Dutzende geschrieben oder zu schreiben geholfen, ich hatte mich daran gewöhnt, sie als stabiles Objekt zu betrachten: ein Formular, eine Checkliste, ein Compliance-Artefakt, das man dem Datenschutzbeauftragten übergibt und archiviert. Beim Öffnen des neuen Templates hielt ich etwas Vertrautes und leicht Verändertes in der Hand, wie wenn man in eine Wohnung zurückkehrt, in der man als junger Mensch gelebt hat, und jemand die Möbel umgestellt hat, ohne es einem zu sagen. Etwas irritierte mich, und ich konnte nicht benennen, was.

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.

Der Autor

Andrea MargiovanniEU-Compliance

Ich arbeite mit Teams, die Systeme unter AI Act, CRA, NIS2, DSGVO bauen. Die Regel ist keine Checkliste: sie ist eine architektonische Einschränkung, die schon beim Entwurf an Bord muss, nicht danach.

Zum Weg →