netkiosk.digital

Autor und Sprecher

Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Diesen Satz kann ich aus Entwicklersicht gut nachvollziehen. Trotzdem lohnt sich eine zweite Frage:

Was genau muss an den Daten real sein?

Denn „realistisch testen“ bedeutet nicht automatisch, dass dafür ein vollständiger Produktivbestand benötigt wird.

Bei vielen Tests reicht es vollkommen aus, wenn Testdaten dieselbe Struktur, dieselben Wertebereiche, Beziehungen und fachlich relevanten Sonderfälle abbilden wie die produktiven Daten.

Bei Migrationen gibt es allerdings einen Punkt, an dem genau das nicht mehr genügt.

Wie weit reichen synthetische Testdaten?

Synthetische Daten können erstaunlich weit tragen.

Solange der Test prüfen soll, ob eine Anwendung oder Migration mit einer bestimmten Datenstruktur und bekannten fachlichen Konstellationen umgehen kann, müssen die einzelnen Datensätze nicht real sein.

Damit lassen sich zum Beispiel prüfen:

Auch komplexe Datenbestände können dafür künstlich erzeugt werden.

Entscheidend ist, dass nicht nur „irgendwelche Fake-Daten“ erzeugt werden. Gute synthetische Testdaten müssen die Eigenschaften des realen Datenbestands abbilden, die für den jeweiligen Test relevant sind.

Ein Beispiel:

Wenn ein Altsystem zehn unterschiedliche Varianten einer Kundenbeziehung kennt, hilft ein synthetischer Datenbestand mit ausschließlich idealtypischen Datensätzen wenig. Sind diese zehn Varianten aber bekannt, können sie gezielt nachgebildet werden.

Bis hierhin besteht normalerweise kein technischer Grund, personenbezogene Originaldaten einzusetzen.

Wo synthetische Daten an ihre Grenze kommen

Anders wird es, wenn nicht mehr nur geprüft werden soll, ob das Migrationsverfahren grundsätzlich funktioniert, sondern ob es mit dem konkreten vorhandenen Datenbestand funktioniert.

Produktive Datenbestände haben Geschichte.

Über Jahre entstehen Konstellationen, die niemand bewusst entworfen hat:

Was man nicht kennt, kann man auch nicht gezielt synthetisch erzeugen.

Spätestens wenn genau diese tatsächliche Datenrealität Gegenstand der Prüfung wird, kann die Nutzung des Originalbestands erforderlich sein.

Migrationen brauchen unterschiedliche Teststufen

Deshalb halte ich es für sinnvoll, nicht pauschal zwischen „Testdaten“ und „Produktivdaten“ zu unterscheiden.

Die Teststrategie kann stufenweise aufgebaut werden.

Frühe Entwicklungs- und Mappingtests können vollständig mit synthetischen Daten arbeiten.

Danach können synthetische Daten um gezielt konstruierte Grenz- und Sonderfälle ergänzt werden.

Auch Mengentests benötigen nicht zwingend Originaldaten. Wenn geprüft werden soll, ob zehn Millionen Datensätze innerhalb eines bestimmten Zeitfensters verarbeitet werden können, lässt sich die erforderliche Datenmenge häufig künstlich erzeugen.

Erst danach stellt sich die Frage:

Muss jetzt der konkrete Produktivbestand bewiesen werden, oder weiterhin nur die technische Funktionsfähigkeit?

Das ist für mich der entscheidende Übergang.

Cut-over-Tests können eine andere Datenrealität benötigen

Ein klassischer Fall ist der Cut-over-Test.

Vor einer produktiven Umstellung soll möglichst realitätsnah geprüft werden:

Hier kann der konkrete Originaldatenbestand notwendig werden.

Noch deutlicher wird es, wenn die Migration gegenüber Revision, Wirtschaftsprüfern oder anderen prüfenden Stellen nachweisbar sein muss.

Dann geht es nicht mehr nur um die Frage:

„Kann unsere Software solche Daten migrieren?“

Sondern möglicherweise um:

„Können wir nachweisen, dass genau dieser Bestand vollständig und korrekt migriert wurde?“

Dafür reichen synthetische Daten naturgemäß nicht immer aus.

Privacy by Design heißt nicht: niemals Originaldaten

Genau deshalb halte ich die einfache Regel „Produktivdaten gehören grundsätzlich nicht in Testumgebungen“ für zu pauschal.

Privacy by Design bedeutet vielmehr:

Für jeden Test wird bewusst entschieden, welche Datenrealität tatsächlich benötigt wird.

Wenn synthetische Daten ausreichen, sollten keine personenbezogenen Originaldaten kopiert werden.

Wenn Originaldaten erforderlich sind, muss diese Entscheidung nachvollziehbar begründet werden.

Und dann ändern sich die Anforderungen an die Testumgebung.

Originaldaten machen aus „Test“ keinen rechtsfreien Raum

Sobald reale personenbezogene Daten verwendet werden, ist „das ist doch nur Test“ keine ausreichende Sicherheitsstrategie.

Dann sollte unter anderem geklärt sein:

Datenminimierung bedeutet dabei auch, nicht reflexartig den kompletten Bestand bereitzustellen, wenn nur ein Teil davon benötigt wird.

Besonders wichtig: Dienstleister bei Migrationen

Migrationen werden häufig nicht ausschließlich intern durchgeführt.

Softwarehersteller, Implementierungspartner, Cloud-Anbieter, Datenbankspezialisten oder externe Migrationsteams erhalten unter Umständen Zugriff auf produktive Daten.

Spätestens dann reicht eine rein technische Betrachtung nicht mehr.

Vor der Bereitstellung sollte geklärt sein, in welcher Rolle der jeweilige Dienstleister handelt und welche vertragliche Grundlage dafür erforderlich ist.

Handelt ein Dienstleister als Auftragsverarbeiter, gehören insbesondere die Anforderungen an die Auftragsverarbeitung in die Vertragsstruktur. Bei anderen Rollen kann die rechtliche Einordnung anders aussehen. Ein Vertrag zur Auftragsverarbeitung ist deshalb nicht automatisch für jeden beteiligten Dienstleister die richtige Lösung.

Unabhängig von der konkreten Rollenverteilung sollten jedenfalls Fragen geregelt sein wie:

Gerade bei Migrationsprojekten darf diese Vertragsstruktur nicht erst diskutiert werden, nachdem der erste Datenbankdump bereits beim Dienstleister liegt.

Eine Migration muss auditierbar bleiben

Wenn Originaldaten eingesetzt werden, reicht es außerdem nicht, die Umgebung lediglich „abzusichern“.

Die Entscheidung und der Umgang mit den Daten sollten nachvollziehbar und prüfbar sein.

Dazu sollte beispielsweise dokumentiert werden:

Bei prüfungsrelevanten Migrationen kommen technische Nachweise hinzu.

Kontrollsummen, Datensatzanzahlen, Abstimmprotokolle oder definierte Reconciliation-Verfahren können beispielsweise zeigen, dass Ausgangs- und Zielbestand nachvollziehbar miteinander abgeglichen wurden.

Auditierbarkeit ist damit selbst eine Anforderung an das Migrationsdesign.

Zugriff ist nicht gleich Berechtigung für alles

Ein weiterer Klassiker: Das Migrationsteam benötigt Zugriff auf die Datenbank.

Daraus folgt nicht automatisch, dass jede beteiligte Person während der gesamten Projektlaufzeit Zugriff auf sämtliche Daten benötigt.

Berechtigungen können zeitlich, organisatorisch und technisch begrenzt werden.

Gerade bei Dienstleistern sollte nachvollziehbar sein:

Wer konnte wann auf welchen Bestand zugreifen – und warum?

Die Testumgebung sollte damit nicht zur dauerhaft weniger geschützten Kopie der Produktion werden.

Und nach der Migration?

Dieser Punkt wird erstaunlich leicht vergessen.

Für Cut-over-Tests oder prüfungsrelevante Nachweise werden Datenbestände bereitgestellt. Das Projekt geht produktiv. Die Migration ist abgeschlossen.

Und Monate später existiert der damalige Datenbestand immer noch:

Deshalb sollte bereits vor der Bereitstellung festgelegt werden, wann, von wem und wie diese Daten wieder gelöscht werden. Ebenso muss dies dokumentiert werden.

Bestehen Aufbewahrungs- oder Nachweispflichten, kann eine weitere Speicherung erforderlich sein. Dann sollte aber klar definiert sein, welche Daten für welchen Nachweis tatsächlich aufbewahrt werden müssen und wer darauf zugreifen darf.

Entfallen Zweck und gegebenenfalls bestehende Aufbewahrungserfordernisse, muss auch der Testbestand verschwinden.

Und das sollte im Idealfall nicht nur passieren, sondern nachweisbar passieren. Insbesondere dann, wenn Dienstleister Kopien erhalten haben.

Die eigentliche Frage lautet deshalb nicht „echt oder künstlich?“

Synthetische Daten sind kein Selbstzweck.

Originaldaten sind aber auch kein Qualitätsmerkmal für einen besonders realistischen Test.

Die richtige Datenrealität hängt vom Testziel ab.

Für Struktur, Logik, bekannte Sonderfälle und vielfach auch Performance können synthetische Daten sehr weit reichen.

Wenn dagegen der konkrete historische Bestand, seine Vollständigkeit oder seine nachweisbare Überführung geprüft werden muss, können Originaldaten erforderlich sein.

Privacy by Design beginnt deshalb nicht mit einem Verbot.

Es beginnt mit drei Fragen:

1. Welche Realität muss dieser Test tatsächlich abbilden?

2. Welche Daten benötigen wir dafür wirklich?

3. Und wie stellen wir sicher, dass diese Daten nach dem Test nicht einfach bleiben?

Genau dort wird Privacy by Design zur Engineering- und Governance-Aufgabe“

Autor und Sprecher

Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Der Angriff beginnt nicht immer mit einer technischen Schwachstelle

Stellen wir uns drei Beschäftigte vor, die sich in einem öffentlich zugänglichen Bereich über ihre Arbeit unterhalten.

Sie nennen keine Passwörter.

Sie geben keine Zugangsdaten weiter.

Und niemand legt vertrauliche Dokumente auf den Tisch.

Stattdessen sprechen sie über aktuelle IT-Projekte, problematische Systeme, technische Einschränkungen, bekannte Ausfälle und darüber, welche Lösung gerade nicht funktioniert.

Für die Beteiligten ist es ein normales Gespräch unter Kollegen.

Für jemanden, der zuhört, kann daraus jedoch ein erstaunlich detailliertes Bild einer Organisation entstehen.

Aus Einzelinformationen wird Kontext

Im Bereich der Informationssicherheit ist die Informationsbeschaffung häufig ein früher Teil eines Angriffs.

Welche Technologien werden eingesetzt?

Welche Systeme sind besonders wichtig?

Wo gibt es technische Probleme?

Welche Veränderungen sind geplant?

Welche Dienstleister oder Plattformen spielen eine Rolle?

Keine dieser Informationen muss isoliert betrachtet besonders kritisch sein.

Zusammengenommen können sie jedoch Zusammenhänge offenlegen.

Ein Angreifer muss dann bestimmte Dinge nicht mehr herausfinden.

Die Organisation hat ihm bereits Kontext geliefert.

Deshalb gehört zum Schutz von Informationen nicht nur die Frage:

Wer kann technisch auf ein System zugreifen?

Sondern auch:

Wo und mit wem sprechen wir über dieses System?

Nicht jedes IT-Gespräch ist ein Datenschutzverstoß

An dieser Stelle ist Differenzierung wichtig.

Technische Informationen sind nicht automatisch personenbezogene Daten.

Und ein Gespräch über eine interne Anwendung stellt nicht automatisch einen Verstoß gegen die DSGVO dar.

Trotzdem kann Datenschutz unmittelbar betroffen sein.

Etwa wenn personenbezogene Daten selbst genannt werden, wenn Informationen Rückschlüsse auf konkrete Personen zulassen oder wenn Details über Verarbeitungssysteme und bestehende Schutzmaßnahmen unbefugte Zugriffe erleichtern können.

Art. 32 DSGVO verlangt ein dem Risiko angemessenes Schutzniveau und nennt unter anderem die dauerhafte Sicherstellung von Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste.

Technische Maßnahmen sind dabei nur eine Seite.

Die DSGVO spricht ausdrücklich von technischen und organisatorischen Maßnahmen.

Eine Firewall verhindert kein Gespräch am Nachbartisch

Organisationen investieren zu Recht in Firewalls, Verschlüsselung, Multi-Faktor-Authentisierung und Berechtigungskonzepte.

Aber keine dieser Maßnahmen verhindert, dass jemand in einem öffentlichen Bereich über interne Schwachstellen spricht.

Hier greifen organisatorische Maßnahmen.

Dazu gehören klare Regeln, Verantwortlichkeiten und vor allem Sensibilisierung.

Beschäftigte müssen beurteilen können:

Ist dieser Ort für das Gespräch geeignet?

Wer kann mithören?

Muss der konkrete Systemname genannt werden?

Ist die Information für dieses Gespräch überhaupt erforderlich?

Kann das Thema warten, bis ein geschützter Rahmen vorhanden ist?

Das klingt banal.

Genau deshalb wird es leicht unterschätzt.

Awareness ist mehr als Phishing-Training

Awareness wird in vielen Organisationen stark mit Phishing-Simulationen verbunden.

Wer hat geklickt?

Wer hat die Schulung abgeschlossen?

Wer hat sein Passwort richtig gewählt?

Das sind sinnvolle Themen.

Sie bilden aber nur einen Teil der Sicherheitskultur ab.

Awareness bedeutet auch, Situationen einschätzen zu können.

Ein Gespräch im Büro ist etwas anderes als ein Gespräch im Zug.

Ein internes Projektmeeting ist etwas anderes als ein Restaurant.

Ein technisches Detail, das innerhalb eines Projektteams selbstverständlich ausgetauscht werden muss, muss nicht zwangsläufig im öffentlichen Raum diskutiert werden.

Manchmal ist deshalb eine der einfachsten Sicherheitsmaßnahmen:

Das Gespräch später an einem geeigneteren Ort fortzusetzen.

Der Datenschutzbeauftragte reicht nicht immer allein

Der Datenschutzbeauftragte hat unter anderem die Aufgabe, zu Datenschutzpflichten zu beraten und deren Einhaltung zu überwachen. Art. 39 DSGVO nennt in diesem Zusammenhang auch Sensibilisierung und Schulung der an Verarbeitungsvorgängen beteiligten Beschäftigten.

Daraus folgt aber nicht, dass Sicherheitskultur allein Aufgabe des DSB wäre.

Im Gegenteil.

Informationssicherheit funktioniert nur, wenn verschiedene Rollen zusammenarbeiten.

Eine operative Datenschutzfunktion kann Datenschutzanforderungen in Schulungen und Prozesse übersetzen.

Informationssicherheit bringt das Bedrohungsbild ein.

IT liefert technisches Kontextwissen.

Führungskräfte schaffen verbindliche Erwartungen.

Und die Beschäftigten müssen schließlich wissen, wie sich diese Anforderungen im Alltag auswirken.

Der DSB kann beraten und überwachen.

Die Organisation muss die Anforderungen leben.

Need-to-know ist keine Geheimniskrämerei

Dabei geht es nicht darum, offene Kommunikation zu verhindern.

Organisationen benötigen Austausch.

Probleme müssen benannt werden.

IT-Teams müssen über Fehler und Schwachstellen sprechen können.

Das entscheidende Prinzip lautet deshalb nicht „nichts sagen“.

Sondern:

Die richtige Information an die richtigen Menschen im richtigen Kontext.

Genau das ist Need-to-know in seiner praktischen Form.

Was Technical Governance daraus macht

Technical Governance betrachtet Sicherheit nicht ausschließlich als Eigenschaft eines Systems.

Sie verbindet Technik, Organisation, Compliance und Verhalten.

Eine Organisation braucht deshalb gleichzeitig technische Kontrollen, klare Prozesse und Menschen, die verstehen, warum bestimmte Informationen geschützt werden müssen.

Manchmal erfordert das eine neue technische Sicherheitsmaßnahme.

Manchmal einen besseren Prozess.

Manchmal eine Schulung.

Und manchmal genügt die Erkenntnis:

Dieses Gespräch führen wir besser woanders weiter.

Denn wirksame Governance sorgt nicht nur dafür, dass Informationen verfügbar sind, wenn sie gebraucht werden.

Sie sorgt auch dafür, dass sie dort bleiben, wo sie hingehören.

Autor und Sprecher

Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Eine gute Idee reicht noch nicht

Stellen wir uns eine Organisation vor, in der Beschäftigte wichtige Informationen heute nur umständlich am Arbeitsplatz oder über größere mobile Arbeitsmittel abrufen können.

Die Idee liegt nahe: Kleine mobile Geräte sollen die benötigten Informationen unmittelbar dort verfügbar machen, wo sie gebraucht werden. Identifizieren, abrufen, entscheiden , schnell und ohne unnötige Wege.

Fachlich ist das überzeugend.

Die Anforderungen werden beschrieben. Eine Lösung wird diskutiert. Das Projekt nimmt Gestalt an.

Erst später wird deutlich, dass eine wesentliche technische Voraussetzung nicht zuverlässig gegeben ist: Die notwendige Netzabdeckung steht nicht überall dort zur Verfügung, wo die Anwendung funktionieren müsste.

Das Problem ist damit nicht das Gerät.

Und auch nicht die ursprüngliche Idee.

Das Problem entstand früher: Technische Machbarkeit wurde behandelt, als wäre sie eine Eigenschaft der späteren Umsetzung, und nicht Bestandteil der Anforderung selbst.

Fachliche Anforderungen haben technische Voraussetzungen

„Informationen sollen mobil verfügbar sein“ klingt zunächst wie eine funktionale Anforderung.

Tatsächlich stecken darin zahlreiche weitere Fragen:

Ist das Netz verfügbar? Wie erfolgt die Authentisierung? Welche Berechtigungen gelten? Wie werden Geräte administriert? Welche Systeme müssen angebunden werden? Was passiert bei einem Ausfall?

Sobald personenbezogene Daten verarbeitet werden, kommen weitere Anforderungen hinzu.

Wer darf welche Informationen sehen? Welche Daten werden tatsächlich benötigt? Wie wird ein unbefugter Zugriff verhindert? Was passiert bei Verlust des Geräts? Welche Protokollierung ist erforderlich?

Datenschutz und Informationssicherheit sind damit keine zusätzlichen Prüfungen eines ansonsten fertigen Projekts.

Sie gehören zum Design.

Genau diesen Gedanken enthält auch Art. 25 DSGVO: Geeignete technische und organisatorische Maßnahmen sollen bereits bei der Festlegung der Mittel der Verarbeitung berücksichtigt werden. Art. 32 ergänzt die risikoorientierte Perspektive auf die Sicherheit der Verarbeitung.

IT ist keine Werkstatt am Ende des Projekts

In vielen Organisationen existiert noch immer ein lineares Bild:

Bei vernetzten digitalen Prozessen ist das zu kurz gedacht.

IT kennt nicht nur Server und Anwendungen. Sie kennt Abhängigkeiten, Schnittstellen, Betriebsmodelle, Grenzen der vorhandenen Architektur und vor allem technische Schulden.

Das gleiche gilt für Informationssicherheit und Datenschutz.

Wer diese Perspektiven erst hinzuholt, wenn wesentliche Entscheidungen bereits getroffen wurden, stellt am Ende häufig die falsche Frage:

„Könnt ihr das freigeben?“

Die bessere Frage wäre viel früher:

„Wie müssen wir es gestalten, damit es fachlich funktioniert, technisch tragfähig und regulatorisch belastbar ist?“

Datenschutz ist nicht gleich Datenschutzbeauftragter

Dabei bedeutet „Datenschutz frühzeitig einbinden“ nicht, jedes operative Detail beim Datenschutzbeauftragten abzuladen.

Sofern ein DSB bestellt ist, muss er nach Art. 38 DSGVO ordnungsgemäß und frühzeitig in datenschutzrelevante Fragen eingebunden werden. Seine Rolle besteht jedoch insbesondere in Beratung und Überwachung. Die Verantwortung für die Verarbeitung bleibt bei der Organisation.

Gerade in größeren Organisationen braucht es deshalb häufig zusätzlich eine operative Datenschutzfunktion.

Das kann ein zentrales Datenschutzmanagement sein, eine Datenschutzkoordination oder ein Netzwerk fachbereichsnaher Koordinatorinnen und Koordinatoren.

Diese Rollen ersetzen den DSB nicht.

Sie schaffen die operative Verbindung zwischen Anforderungen und Umsetzung.

Sie helfen beispielsweise dabei, Verarbeitungstätigkeiten früh zu identifizieren, Anforderungen in Projekte einzubringen, Dokumentation zu koordinieren, Maßnahmen nachzuverfolgen und Datenschutzwissen in Fachbereiche zu tragen.

Damit wird Datenschutz vom späteren Prüfschritt zu einem Bestandteil des Projektmodells.

Compliance by Design statt Abnahme am Ende

Das gleiche Prinzip lässt sich über Datenschutz hinaus anwenden.

Informationssicherheit, regulatorische Anforderungen, interne Standards oder Architekturvorgaben können ein Projekt wesentlich beeinflussen.

Wer sie erst am Ende prüft, produziert Konflikte.

Plötzlich heißt es:

„Die IT blockiert.“

„Der Datenschutz erlaubt es nicht.“

„Security hat noch Anforderungen.“

Manchmal liegt das eigentliche Governance-Problem jedoch darin, dass diese Perspektiven zu spät beteiligt wurden.

Eine perfekte Prüfung kurz vor dem Go-live hilft wenig, wenn die entscheidenden Weichen Monate zuvor gestellt wurden.

Vier Fragen vor der technischen Festlegung

Vor einer Beschaffung oder Architekturentscheidung sollten deshalb mindestens vier Dinge geklärt sein:

Gerade die letzte Frage entscheidet häufig darüber, ob eine theoretisch gute Lösung praktisch trägt.

Was Technical Governance daraus macht

Technical Governance bringt Fachlichkeit, Technik und Compliance zusammen, bevor aus einer Idee eine schwer veränderbare Festlegung wird.

Der Fachbereich kennt das Problem.

Die IT kennt die technische Realität.

Informationssicherheit bewertet Bedrohungen und Schutzmaßnahmen.

Datenschutz bringt Anforderungen an Verarbeitung und Schutz personenbezogener Daten ein.

Eine operative Datenschutz- und Governance-Funktion hilft dabei, diese Perspektiven in Anforderungen, Prozesse und Entscheidungen zu übersetzen.

Das Ziel ist nicht, Projekte durch zusätzliche Beteiligte langsamer zu machen.

Im Gegenteil.

Frühe Abstimmung ist meist deutlich günstiger als späte Korrektur.

Und genau deshalb ist technische und regulatorische Machbarkeit kein Abnahmekriterium.

Sie ist Teil der Anforderung.

Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Thorsten Ball glaubt, dass das Handwerk des Programmierens verschwindet. Ich glaube, dass er mit der Richtung recht haben könnte. Aber Zukunftsbild und heutige Verantwortung darf man nicht miteinander verwechseln.

Thorsten Ball ist Softwareentwickler, Autor von Writing An Interpreter In Go und Mitgründer von Amp, einem Coding-Agent-Research-Lab. Er beobachtet diese Entwicklung nicht nur, er baut daran mit. Das macht seine Thesen sehr interessant, und erklärt zugleich die Perspektive, aus der er argumentiert.

Seine Prognose ist radikal: Code Reviews, Unit Tests, Terminals, heutige Teamstrukturen. Vieles davon verschwindet.

Sein stärkstes Argument:

Most bugs won’t be „coding“ bugs. They’ll be „you asked for the wrong thing“ bugs.

Zwei Perspektiven, die man auseinanderhalten muss

Thorsten Balls Text ist ausdrücklich ein Blick in die Zukunft. Auf seiner eigenen Website schreibt er, dass einige seiner Prognosen bei Unternehmen wie Amp bereits Realität seien, andere aber Zeit brauchen. In einem älteren Interview mit dem Fraunhofer IEM wird die Perspektive noch deutlicher: Amp orientiert sich bewusst an der technologischen Frontier, nicht am durchschnittlichen Enterprise-Entwickler. Ball selbst unterscheidet dabei zwischen dem Handwerk des Codeschreibens, das verschwindet, und dem Handwerk des Softwarebauens, das seiner Prognose nach wichtiger wird denn je.

Genau an dieser Bruchstelle setze ich an.

Ich habe vor wenigen Tagen geschrieben (https://2s-datenschutz-entwicklung.de/de/wissen/beitrag/weniger-mikromanagement-ist-nicht-dasselbe-wie-weniger-governance-codequalitaet-in-der-ai-gestuetzten-softwareentwicklung), dass ich anfange, meine Schranken abzurüsten. Repository-Regeln, kleinteilige Arbeitsanweisungen, Prompt-Regelwerke: Vieles davon war eine Antwort auf frühere Modellgenerationen und behindert heute teilweise mehr, als es hilft. Aber u.a. ein Code Review gehört für mich immer noch zum Alltag.

Warum? Weil Softwareentwicklung unter organisatorischen und regulatorischen Rahmenbedingungen erfolgen muss.

Wo ich ihm zustimme

Der Engpass verschiebt sich. Wenn Code-Erzeugung immer billiger wird, gewinnen Anforderungen, Architekturentscheidungen und die Frage, welches Problem überhaupt gelöst werden soll, erheblich an Bedeutung.

Und Ball hat recht: Menschliche Kontrolle jeder einzelnen Codezeile wird mit zunehmender Autonomie von Coding Agents immer weniger skalieren.

Das heißt aber nicht, dass Kontrolle verschwindet.

Sie verändert ihren Gegenstand.

Wo ich beim heutigen Stand eine Grenze ziehe

Wenn der Fehler bereits im Auftrag steckt, ist ein klassisches Code Review sicherlich nicht der perfekte Kontrollpunkt. Aber Review kann heute sehr wohl der Ort sein, an dem ein fachlich falscher Auftrag sichtbar wird. Ein Entwickler mit Domänenwissen sieht im Ergebnis Zusammenhänge, die weder Spezifikation noch Test vollständig erfasst haben.

Dazu kommen Fehlerklassen, die mit der fachlichen Aufgabenstellung nur mittelbar zusammenhängen: unsichere Defaults, Injection-Pfade, fehlerhafte Autorisierung, personenbezogene Daten im Log, problematische Abhängigkeiten.

Ein korrekter Auftrag garantiert noch keine sichere Software.

Und vor allem gilt für regulierte Organisationen heute noch etwas anderes:

Software muss nicht nur funktionieren. Ihre Eignung, ihre Veränderungen und die angewandten Kontrollen müssen nachweisbar sein.

Das ist keine theoretische Governance-Forderung. DORA verlangt beispielsweise für betroffene Finanzunternehmen dokumentierte Entwicklungsverfahren, Tests und Freigaben. Bemerkenswert ist dabei, was dort nicht steht: Verlangt wird eine Quellcodeprüfung mit statischen und dynamischen Verfahren und ein nachverfolgter Aktionsplan. Nicht, dass ein Mensch den Code liest. Das Kontrollziel ist normiert, das Artefakt nicht.

Beim AI Act sieht man dasselbe Prinzip auf einer anderen Ebene: Bei Hochrisiko-KI-Systemen sollen technische Dokumentation und Protokollierung gerade ermöglichen, Entwicklung und Verhalten nachvollziehbar zu machen und Konformität prüfen zu können.

Deshalb ist für mich die entscheidende Frage nicht, ob das heutige Code Review überlebt.

Vielleicht hat Thorsten Ball recht und der Pull Request, wie wir ihn kennen, verschwindet tatsächlich.

Vielleicht werden Unit Tests teilweise durch andere Formen maschineller Verifikation ersetzt.

Vielleicht interessieren uns irgendwann weder Sourcecode noch Programmiersprache besonders.

Aber daraus folgt nicht, dass Nachweisbarkeit verschwindet.

Im Gegenteil: Wenn Menschen immer weniger von der konkreten Implementierung sehen, muss an anderer Stelle belastbar nachgewiesen werden können:

Die Artefakte dafür dürfen sich verändern.

Vielleicht besteht der Nachweis der Zukunft nicht mehr aus einem Menschen, der 800 geänderte Codezeilen liest. Vielleicht besteht er aus automatisiert erzeugter und kryptografisch nachvollziehbarer Evidence, Agent-Traces, reproduzierbaren Tests, Policy-as-Code und maschinenprüfbaren Constraints.

Das Kontrollziel bleibt trotzdem bestehen.

Gates prüfen die Spezifikation – nicht deren fachliche Wahrheit

Das ist für mich der Kern der Diskussion.

Ausführbare Governance ist richtig und notwendig. Aus Anforderungen werden überprüfbare Akzeptanzkriterien, aus Architekturprinzipien technische Constraints, aus „das sollte funktionieren“ reproduzierbare Evidence.

Aber auch die Spezifikation selbst ist ein menschliches Artefakt.

Akzeptanzkriterien können perfekt ausgeführt werden und trotzdem das falsche Problem beschreiben.

Automatisierte Verifikation kann sehr zuverlässig feststellen, ob ein System seiner Spezifikation entspricht. Sie beweist damit noch nicht, dass die Spezifikation fachlich richtig, regulatorisch vollständig oder geschäftlich sinnvoll war.

Wenn Balls These stimmt und künftig ein großer Teil der Fehler tatsächlich „you asked for the wrong thing“ lautet, wird genau diese Ebene wichtiger.

Was daraus folgt

Für mich entstehen deshalb zwei unterschiedliche Kontrollziele:

Implementierungs- und Konformitätsfehler erkennen. Das wird zunehmend automatisierbar. Hier bin ich sehr nah bei Thorsten Ball.

Entscheidungen verantworten und nachweisbar machen. Das ist Technical Governance.

Wenn ein Agent einen Pull Request erzeugt, oder künftig vielleicht gar keinen Pull Request mehr, muss eine Organisation trotzdem bestimmen können, warum diese Änderung gewollt war, wer sie verantwortet und auf welcher Grundlage ihre Eignung festgestellt wurde.

Deshalb dokumentiere ich auch weiterhin Architekturentscheidungen als ADRs.

Ein Constraint kann das Was erzwingen. Er dokumentiert nicht automatisch das Warum, die betrachteten Alternativen und die Konsequenzen einer Entscheidung.

Genau diese Information lässt sich später nicht verlässlich aus dem fertigen Code rekonstruieren.

Und genau sie wird relevant, wenn Monate oder Jahre später jemand fragt:

Warum wurde dieses System so gebaut? Und worauf beruhte die Entscheidung, dass es geeignet war?

Balls Zukunftsbild halte ich deshalb für ausgesprochen interessant.

Nur würde ich daraus für Organisationen im Jahr 2026 nicht ableiten:

Wir brauchen weniger Governance.

Sondern:

Wir müssen Governance schneller auf eine Ebene bringen, auf der sie auch mit zunehmend autonomer Softwareentwicklung funktioniert.

Nicht weniger Engineering. Nicht weniger Qualitätssicherung. Weniger menschliche Mikrokontrolle der Implementierung, und mehr systemische Governance von Anforderung, Entscheidung, Prozess und Ergebnis.

Welche Entwicklungspraktik wird durch AI Agents tatsächlich überflüssig, und welches Kontrollziel bleibt bestehen, auch wenn sich seine technische Umsetzung vollständig verändert?

P.S. Und nein: Das Terminal (CLI) wird niemals sterben

Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Warum Prozesse geschlossene Regelkreise brauchen

Eine Entscheidung ist noch keine Prozessänderung.

Das klingt zunächst banal. Im organisatorischen Alltag ist genau diese Unterscheidung aber erstaunlich relevant.

Vor einiger Zeit nahm ich im Rahmen eines mehrwöchigen Programms an verschiedenen Veranstaltungen teil. Eine davon fand regelmäßig statt.

Nach einigen Terminen war sowohl dem Verantwortlichen als auch mir klar: Diese Veranstaltung war für mich nicht besonders sinnvoll. Das Format passte schlicht nicht.

Wir besprachen das, waren uns einig und entschieden gemeinsam, dass ich künftig nicht mehr teilnehmen würde.

Damit war die Sache eigentlich geklärt.

Eigentlich.

Am nächsten Tag stand die Veranstaltung wieder in meinem persönlichen Ablaufplan.

Ich sprach den Verantwortlichen darauf an. Für ihn war das unproblematisch. Wir hatten schließlich miteinander gesprochen. Er wusste, dass ich nicht kommen würde.

Aus seiner Sicht war die Entscheidung getroffen.

Aus meiner Sicht begann das Problem erst jetzt.

Denn mein offizieller Plan sagte weiterhin etwas anderes.

Dort stand schwarz auf weiß, dass ich zu einem bestimmten Zeitpunkt an einem bestimmten Ort erwartet wurde.

Ich wusste zwar, dass die Absprache galt. Trotzdem entstand jedes Mal das unangenehme Gefühl, einem vorgesehenen Termin einfach fernzubleiben.

Also versuchte ich, die Veranstaltung aus meinem Plan entfernen zu lassen.

Nicht einmal.

Mehrfach.

An verschiedenen Stellen.

Immer mit demselben Hinweis: Die Teilnahme sei mit dem Verantwortlichen bereits abgestimmt und beendet.

Bis zum Ende des Programms blieb die Veranstaltung trotzdem in meinem Plan.

Der interessante Punkt daran ist nicht die Veranstaltung.

Der interessante Punkt ist die Frage:

Wann wird aus einer Entscheidung eigentlich eine wirksame Prozessänderung?

Der Unterschied zwischen Absprache und Prozess

Organisationen funktionieren zu einem erheblichen Teil über Kommunikation.

Menschen sprechen miteinander, treffen Entscheidungen, stimmen Ausnahmen ab und reagieren auf veränderte Situationen.

Das ist unverzichtbar.

Problematisch wird es dort, wo eine persönliche Absprache einen formalen Prozess verändern soll – der Prozess von dieser Absprache aber nichts erfährt.

Für die beiden beteiligten Personen kann eine Sache vollständig geklärt sein.

Für die Organisation ist sie es möglicherweise noch lange nicht.

In meinem Beispiel gab es mindestens zwei unterschiedliche Wahrheiten:

Die fachliche Realität:
Die Teilnahme war beendet.

Die organisatorische Realität:
Der Termin war weiterhin geplant.

Solange beide Welten nebeneinander existieren, entsteht Reibung.

Und diese Reibung betrifft nicht nur denjenigen, der einen falschen Termin in seinem Plan sieht.

Sie kann sich durch die gesamte Organisation fortsetzen.

Was ein nicht gestrichener Termin sichtbar macht

Ein Termin in einem Planungssystem ist mehr als eine Zeile in einem Kalender.

Er kann bedeuten:

Ob in meinem konkreten Fall tatsächlich eine Ressource blockiert wurde, konnte ich von außen natürlich nicht beurteilen.

Aber genau das ist der Punkt.

Ein Planungssystem sollte den tatsächlichen Zustand einer Organisation möglichst zuverlässig abbilden.

Wenn die Realität sagt:

„Diese Teilnahme findet nicht statt“

und das System sagt:

„Diese Teilnahme ist geplant“ stellt sich die Frage, welchem Zustand nachfolgende Prozesse vertrauen.

Je größer und stärker vernetzt eine Organisation ist, desto relevanter wird diese Differenz.

Ein falscher Eintrag bleibt selten nur ein falscher Eintrag.

Er kann zur Grundlage für die nächste Entscheidung werden.

Eine Entscheidung braucht einen geschlossenen Regelkreis

Ein funktionierender Prozess endet deshalb nicht mit einer Entscheidung.

Er benötigt einen geschlossenen Informationskreislauf.

Vereinfacht:

Entscheidung → Änderung → Planung → Information → Umsetzung → Rückmeldung

Erst wenn alle relevanten Stellen denselben neuen Zustand kennen, ist die Änderung organisatorisch wirksam.

Fehlt eine Verbindung, bleibt der Prozess offen.

Das ist im Grunde ein einfaches Prinzip.

Wenn ein Verantwortlicher feststellt, dass sich etwas ändert, muss diese Änderung dort ankommen, wo weitere Entscheidungen davon abhängen.

Im Beispiel also nicht nur beim Teilnehmer und beim Veranstaltungsleiter.

Sondern auch in der Planung.

Und möglicherweise bei anderen Stellen, die diese Planungsinformation verwenden.

Genau hier unterscheiden sich persönliche Kommunikation und Prozesskommunikation.

„Wir beide wissen Bescheid“ ist nicht dasselbe wie:

„Die Organisation weiß Bescheid.“

Closed Loop statt Zuruforganisation

Viele Organisationen kompensieren offene Regelkreise erstaunlich lange durch engagierte Menschen.

Man ruft jemanden an.

Man schreibt eine Nachricht.

Man läuft kurz ins Nachbarbüro.

Man bittet jemanden, einen Eintrag zu ändern.

Man erklärt denselben Sachverhalt einer zweiten und schließlich einer dritten Stelle.

Das funktioniert häufig.

Irgendwie.

Aber dieses „Irgendwie“ ist teuer.

Nicht unbedingt sofort in Euro.

Es kostet Aufmerksamkeit, Arbeitszeit und Verlässlichkeit.

Vor allem entsteht ein Prozess, dessen Funktionsfähigkeit davon abhängt, dass Menschen wissen:

Damit entsteht eine zweite Organisation neben der offiziellen.

Die formale Organisation besteht aus Systemen, Rollen und definierten Prozessen.

Die reale Organisation besteht zusätzlich aus Erfahrung, persönlichen Kontakten und Workarounds.

Das Problem beginnt dort, wo der zweite Teil notwendig ist, damit der erste überhaupt funktioniert.

Woran man unterbrochene Regelkreise erkennt

Offene Prozessketten sind nicht immer spektakulär.

Oft zeigen sie sich in ganz unscheinbaren Sätzen:

„Ich habe denen schon Bescheid gesagt.“

„Das müsste eigentlich geändert sein.“

„Rufen Sie dort noch einmal an.“

„Das steht zwar noch drin, aber das können Sie ignorieren.“

„Das System weiß davon noch nichts.“

„Ich kann das selbst leider nicht ändern.“

Diese Sätze sind interessant.

Nicht weil einzelne Beschäftigte etwas falsch machen.

Im Gegenteil: Häufig versuchen sie gerade, einen unvollständigen Prozess pragmatisch zu reparieren.

Aber solche Formulierungen zeigen, dass Information irgendwo im Ablauf ihre Verbindlichkeit verliert.

Das ist ein guter Anlass, genauer hinzusehen.

Wer darf eigentlich den Zustand verändern?

Damit kommt eine zweite Frage ins Spiel.

Nicht nur:

Wie gelangt die Information in das System?

Sondern:

Wer darf eine Änderung überhaupt wirksam auslösen?

In vielen Organisationen sind fachliche Entscheidung und technische Änderungsberechtigung voneinander getrennt.

Das kann sinnvoll und notwendig sein.

Ein Veranstaltungsleiter entscheidet beispielsweise fachlich über eine Teilnahme, darf aber möglicherweise selbst keinen zentralen Plan verändern.

Dann braucht es einen definierten Übergang:

Wer übernimmt die Änderung?

Wie wird sie ausgelöst?

Wie erkennt diese Stelle, dass es sich um eine verbindliche Entscheidung handelt?

Wie schnell muss sie umgesetzt werden?

Und woran erkennt der ursprüngliche Entscheider, dass dies tatsächlich geschehen ist?

Genau der letzte Punkt wird häufig vergessen.

Ein Prozess ist nicht geschlossen, wenn eine Nachricht abgesendet wurde.

Er ist geschlossen, wenn die beabsichtigte Änderung nachweisbar im Zielzustand angekommen ist.

Nicht jede Schnittstelle ist technisch

Bei „Schnittstellen“ denken wir schnell an APIs, Datenbanken oder Systemintegrationen.

Aber viele der wichtigsten Schnittstellen in Organisationen verlaufen zwischen Rollen.

Zwischen:

Eine technische Schnittstelle kann perfekt funktionieren und der Gesamtprozess trotzdem scheitern, wenn die organisatorische Übergabe unklar ist.

Umgekehrt kann ein technisch einfacher Prozess sehr zuverlässig sein, wenn Verantwortung und Rückmeldung eindeutig geregelt sind.

Deshalb ist Digitalisierung allein keine Garantie für einen Closed Loop.

Ein digitales Formular, ein Workflow oder ein Ticketsystem kann lediglich eine offene organisatorische Schleife digital nachbilden.

Dann ist der Prozess moderner.

Aber nicht unbedingt besser.

Fünf Fragen für die Prozessanalyse

Wenn Änderungen in einer Organisation regelmäßig „nicht ankommen“, helfen fünf Fragen:

Die fünfte Frage ist oft die interessanteste.

Denn viele Prozesse kennen einen Auslöser.

Aber keinen verlässlichen Rückkanal.

Planung braucht aktuelle Wahrheit

Planungssysteme entfalten ihren Nutzen nur, wenn man ihren Daten vertrauen kann.

Das gilt für Veranstaltungen genauso wie für:

Je stärker weitere Entscheidungen automatisiert oder datenbasiert getroffen werden, desto wichtiger wird die Aktualität des zugrunde liegenden Zustands.

Denn Digitalisierung skaliert nicht nur gute Informationen.

Sie skaliert auch falsche.

Ein veralteter Eintrag in einem einzelnen Kalender ist lästig.

Ein veralteter Status, der automatisiert in weitere Prozesse übernommen wird, kann eine ganze Kette falscher Entscheidungen auslösen.

Darum ist Datenqualität nicht nur eine technische Frage.

Sie ist auch eine Frage des Prozessdesigns.

Was Technical Governance daraus macht

Technical Governance betrachtet deshalb nicht ausschließlich Systeme.

Sie fragt nach dem Zusammenspiel von:

Entscheidung, Verantwortung, Prozess und technischer Abbildung.

Bei einer Prozessänderung interessiert nicht nur, ob ein entsprechendes Feld in der Software existiert.

Interessanter sind Fragen wie:

Damit verändert sich die Perspektive.

Aus:

„Warum wurde der Termin nicht gelöscht?“

wird:

„Wie stellt die Organisation sicher, dass eine fachlich getroffene Entscheidung zuverlässig den gesamten Prozess durchläuft?“

Das ist die eigentlich interessante Frage.

Denn eine gute Organisation zeichnet sich nicht dadurch aus, dass nie etwas geändert werden muss.

Im Gegenteil.

Änderungen gehören zum Alltag.

Termine ändern sich. Anforderungen verändern sich. Menschen fallen aus. Prioritäten verschieben sich. Entscheidungen werden revidiert.

Die Qualität eines Prozesses zeigt sich deshalb nicht nur daran, wie gut er seinen geplanten Normalfall abbildet.

Sondern auch daran, wie zuverlässig er mit Veränderungen umgeht.

Eine Entscheidung ist erst dann wirklich angekommen, wenn die Organisation danach handelt.

Alles davor ist lediglich eine Absprache.

Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Warum gute Governance einen sicheren und gangbaren Weg schaffen muss

Manchmal zeigt sich die Qualität von Governance nicht daran, wie gut eine Regel formuliert ist.

Sondern daran, was ein Mitarbeiter tun soll, nachdem die Regel ausgesprochen wurde.

Vor einiger Zeit musste in einer Organisation ein bereits abgestimmtes Dokument kurzfristig an eine externe Stelle übermittelt werden. Der Inhalt war personenbezogen und schutzbedürftig. Also kein Fall für einen völlig sorglosen Umgang.

Der vorgesehene Weg war allerdings bemerkenswert:

Ich fragte nach einer elektronischen Übermittlung.

Die Antwort war sinngemäß:

„Das dürfen wir aus Datenschutzgründen nicht per E-Mail versenden.“

Damit hätte die Diskussion eigentlich beendet sein können.

Für mich begann sie an dieser Stelle erst.

Denn die interessante Frage war nicht, ob sensible Informationen geschützt werden müssen. Natürlich müssen sie das.

Die interessante Frage war:

Welchen sicheren, praktikablen und freigegebenen digitalen Weg hat die Organisation ihren Mitarbeitern stattdessen zur Verfügung gestellt?

Die Antwort war offenbar: keinen.

Und genau dort wird aus Datenschutz ein Organisationsproblem.

E-Mail ist nicht gleich „unverschlüsselte E-Mail“

In solchen Situationen fällt erstaunlich häufig der Satz:

„Personenbezogene Daten dürfen nicht unverschlüsselt per E-Mail versendet werden.“

Das klingt eindeutig.

Technisch ist es aber wesentlich differenzierter.

Denn „E-Mail“ und „unverschlüsselt“ sind keine Synonyme.

Bei moderner E-Mail-Kommunikation muss mindestens zwischen Transportverschlüsselung und Inhaltsverschlüsselung unterschieden werden.

Transportverschlüsselung

Bei der Transportverschlüsselung wird die Verbindung zwischen den beteiligten Systemen geschützt, typischerweise über TLS.

Vereinfacht:

Absender → Mailserver → Mailserver → Empfänger

Die Übertragungsstrecken können dabei verschlüsselt sein.

Das ist heute bei professionell betriebenen Maildiensten weit verbreitet. Die klassische Vorstellung, eine E-Mail werde grundsätzlich als vollständig offener Klartext durchs Internet geschickt, beschreibt die heutige Praxis daher nur noch unzureichend.

Aber Transportverschlüsselung hat Grenzen.

Sie schützt die Übertragung zwischen den beteiligten Systemen. Sie bedeutet nicht automatisch, dass nur Absender und Empfänger den Inhalt lesen können.

Auf Mailservern kann die Nachricht weiterhin im Klartext vorliegen. Auch der Schutz der einzelnen Transportabschnitte hängt von der konkreten Konfiguration und den beteiligten Systemen ab.

Inhaltsverschlüsselung

Davon zu unterscheiden ist die Verschlüsselung des eigentlichen Nachrichteninhalts.

Dafür gibt es beispielsweise Verfahren wie:

Bei geeigneter Umsetzung bleibt der Inhalt selbst geschützt und kann nur von den vorgesehenen Empfängern entschlüsselt beziehungsweise über einen gesicherten Zugang abgerufen werden.

Die entscheidende Frage lautet deshalb nicht:

„E-Mail erlaubt oder verboten?“

Sondern:

„Welches Schutzbedürfnis hat die Information – und welcher Übertragungsweg erfüllt dieses Schutzbedürfnis angemessen?“

Das ist ein erheblicher Unterschied.

Warum Verbote noch keine Governance sind

Ein Verbot kann fachlich vollkommen nachvollziehbar sein.

Vielleicht möchte eine Organisation bestimmte Kategorien personenbezogener Daten nicht über normale E-Mail-Kommunikation versenden.

Das kann eine bewusste Sicherheitsentscheidung sein.

Problematisch wird es erst, wenn die Regel lautet:

„Dieser Weg ist nicht erlaubt.“

und auf die naheliegende nächste Frage

„Welcher Weg ist erlaubt?“

keine praktikable Antwort folgt.

Dann verlagert Governance das Problem lediglich auf die Beschäftigten.

Sie müssen improvisieren.

Sie drucken Dokumente aus.

Sie suchen Faxnummern.

Sie telefonieren hinter Unterlagen her.

Sie verschicken Briefe.

Oder sie entwickeln eigene Workarounds.

Genau das sollte Governance eigentlich verhindern.

Denn der Zweck einer Regel ist nicht, einen Arbeitsprozess zum Stillstand zu bringen.

Ihr Zweck ist, einen vertretbaren Rahmen für die Durchführung des Arbeitsprozesses festzulegen.

Datenschutz sollte Arbeit ermöglichen und nicht unmöglich machen

Datenschutz wird im betrieblichen Alltag gelegentlich als Gegenspieler effizienter Prozesse wahrgenommen.

Das ist nachvollziehbar, wenn Mitarbeiter Datenschutz hauptsächlich in dieser Form erleben:

Ein funktionierendes Datenschutzmanagement muss selbstverständlich Grenzen setzen.

Aber es darf dort nicht aufhören.

Nach dem Nein muss ein Ja, so geht es folgen.

Zum Beispiel:

Diese Daten bitte nicht als normale E-Mail-Anlage versenden. Dafür steht Ihnen unser sicherer Datenaustausch zur Verfügung.

Oder:

Für diese Schutzklasse verwenden wir S/MIME.

Oder:

Externe Empfänger erhalten einen zeitlich begrenzten Zugang zu einem geschützten Downloadbereich.

Oder möglicherweise auch:

Für diese Daten und diesen konkreten Zweck ist die vorhandene transportverschlüsselte E-Mail-Kommunikation nach unserer Bewertung ausreichend.

Welche Lösung richtig ist, hängt vom konkreten Risiko, vom Inhalt, von den Empfängern und von den organisatorischen Rahmenbedingungen ab.

Aber es braucht eine Lösung.

„Sicher“ ist keine binäre Eigenschaft

Gerade bei E-Mail-Kommunikation zeigt sich ein grundsätzliches Problem vieler Governance-Regeln.

Technische Sachverhalte werden binär formuliert:

Die Realität besteht aber aus Schutzmaßnahmen und Risiken.

Eine TLS-transportverschlüsselte E-Mail bietet einen anderen Schutz als eine Ende-zu-Ende beziehungsweise inhaltsverschlüsselte Nachricht.

Eine verschlüsselte Austauschplattform hat andere Eigenschaften als S/MIME.

Ein Brief hat wiederum völlig andere Risiken.

Auch das Fax ist nicht automatisch der magische sichere Gegenentwurf zur E-Mail.

Bei allen Übertragungswegen stellen sich Fragen:

Wer kann zugreifen?

Wie wird der Empfänger authentifiziert?

Wie wird eine Fehladressierung verhindert?

Wo liegen Kopien?

Wie lange werden Daten gespeichert?

Wie wird Zugriff protokolliert?

Was passiert bei Fehlzustellungen?

Die Wahl des Kommunikationsmittels sollte deshalb aus einer Risikobetrachtung entstehen.

Nicht aus einem Schlagwort.

Wenn „Datenschutz“ zum Prozessabbruch führt

Aus Sicht des Mitarbeiters ist eine Regel ohne Alternative besonders problematisch.

Dann erreicht ihn eine Governance-Vorgabe:

So nicht.

Wenn anschließend kein vorgesehener Weg existiert, wird Datenschutz nicht als Schutzmechanismus erlebt.

Sondern als Ursache zusätzlicher Arbeit.

Das ist gefährlich.

Nicht nur für die Akzeptanz des Datenschutzes.

Sondern auch für den Datenschutz selbst.

Denn Menschen suchen Wege, ihre Aufgaben trotzdem zu erledigen.

Je weniger praktikabel der offizielle Prozess ist, desto attraktiver werden informelle Alternativen.

Damit entsteht genau das Muster, das bereits beim Trampelpfad aus dem ersten Teil dieser Reihe sichtbar wurde:

Die Organisation entwirft einen offiziellen Weg.

Der Arbeitsalltag findet einen anderen.

Nur ist der Trampelpfad bei personenbezogenen Daten unter Umständen deutlich riskanter.

Governance muss bis zum Arbeitsplatz reichen

Eine Datenschutzrichtlinie ist noch keine funktionierende Datenschutzorganisation.

Auch eine Entscheidung des Datenschutzbeauftragten ist noch kein vollständiger Prozess.

Die entscheidende Frage lautet:

Kann der Mitarbeiter die Vorgabe in seinem konkreten Arbeitsablauf tatsächlich umsetzen?

Dazu gehört mehr als Recht.

Es braucht:

Regeln

Welche Daten dürfen auf welchem Weg verarbeitet werden?

Technik

Welche sicheren Werkzeuge stehen dafür zur Verfügung?

Berechtigungen

Wer darf sie nutzen?

Prozesse

Wie funktioniert der Arbeitsablauf konkret?

Schulung

Weiß der Mitarbeiter, welchen Weg er nehmen soll?

Support

Was passiert, wenn ein Sonderfall entsteht?

Erst zusammen ergibt das wirksame Governance.

Der Datenschutzbeauftragte allein kann das nicht lösen. Der Datenschutzkoordinator oder -manager auch nicht.

Hier liegt auch eine wichtige organisatorische Abgrenzung.

Es wäre zu einfach, jedes Problem dieser Art dem Datenschutzbeauftragten zuzuschreiben.

Der Datenschutzbeauftragte berät, bewertet und weist auf Risiken hin.

Aber daraus eine arbeitsfähige technische und organisatorische Lösung zu bauen, ist regelmäßig eine gemeinsame Aufgabe.

Dazu gehören je nach Organisation:

Wenn beispielsweise entschieden wird:

„Diese Dokumente sollen nicht als normale Mail-Anlage versendet werden“,

folgt daraus eine technische und organisatorische Aufgabe:

Genau an diesen Übergängen entscheidet sich, ob Governance funktioniert.

Vier Fragen, die sich Organisationen stellen sollten

Bei jeder Einschränkung eines digitalen Arbeitswegs helfen vier Fragen:

Welches konkrete Risiko wollen wir reduzieren?

Nicht „wegen Datenschutz“, sondern präzise: Vertraulichkeit, Fehladressierung, unberechtigter Zugriff, Manipulation, Nachweisbarkeit oder etwas anderes?

Welche Schutzmaßnahmen existieren bereits?

Transportverschlüsselung, Inhaltsverschlüsselung, Zugriffsschutz, sichere Portale, Berechtigungsmanagement oder andere Kontrollen?

Welcher freigegebene Alternativweg steht dem Mitarbeiter zur Verfügung?

Eine Regel ohne operativ nutzbaren Ersatz ist unvollständig.

Ist der sichere Weg mindestens annähernd so praktikabel wie der unsichere?

Wenn die sichere Lösung wesentlich komplizierter ist, entstehen mit hoher Wahrscheinlichkeit Workarounds.

Die vierte Frage wird häufig unterschätzt.

Sicherheit, die im Alltag nicht verwendet wird, schützt wenig.

Was Technical Governance daraus macht

Technical Governance verbindet regulatorische Anforderungen mit technischer und organisatorischer Realität.

Deshalb reicht die Aussage

„Das ist datenschutzrechtlich nicht zulässig“

als Endpunkt nicht aus.

Sie ist möglicherweise der Anfang einer Aufgabe.

Die nächste Frage lautet:

„Wie machen wir es zulässig, sicher und gleichzeitig praktikabel?“

Genau hier müssen Regulierung und Technik miteinander übersetzt werden.

Nicht jede Information braucht denselben Schutz.

Nicht jeder Kommunikationsweg hat dasselbe Risiko.

Und nicht jedes Problem lässt sich durch ein pauschales Verbot lösen.

Die Aufgabe besteht darin, aus Anforderungen umsetzbare Kontrollmechanismen zu machen.

Das kann bedeuten:

Dann verändert sich auch die Wahrnehmung von Governance.

Aus:

„Das dürfen Sie nicht.“

wird:

„Dafür verwenden Sie bitte diesen Weg.“

Das ist ein kleiner sprachlicher Unterschied.

Organisatorisch ist es ein fundamentaler.

Gute Governance definiert einen gangbaren Weg

Regeln sind notwendig.

Grenzen auch.

Gerade bei sensiblen personenbezogenen Daten wäre eine Haltung nach dem Motto „wird schon gutgehen“ keine vernünftige Alternative.

Aber gute Governance misst sich nicht an der Zahl ihrer Verbote.

Sie misst sich daran, ob eine Organisation ihre Aufgaben innerhalb dieser Regeln zuverlässig erledigen kann.

Datenschutz sollte deshalb nicht am Stoppschild enden.

Hinter dem Stoppschild muss ein anderer Weg beginnen.

Ein Weg, der angemessen sicher ist.

Ein Weg, den Mitarbeiter kennen.

Ein Weg, den die Technik unterstützt.

Und vor allem:

ein Weg, der tatsächlich gangbar ist.

Denn Governance ist nicht nur die Kunst, Nein zu sagen.

Wirksame Governance erklärt, wie es sicher geht.

Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Coding Agents haben sich in erstaunlich kurzer Zeit von brauchbaren Assistenten zu Werkzeugen entwickelt, die umfangreiche Entwicklungsaufgaben über längere Strecken selbstständig bearbeiten können.
Das bedeutet aber nicht, dass Qualitätskontrollen überflüssig werden. Im Gegenteil: Wenn die eigentliche Codeproduktion immer billiger und schneller wird, verlagert sich die Verantwortung auf Anforderungen, Architekturentscheidungen, automatisierte Nachweise und die Frage, wer am Ende bewusst die Verantwortung für das Ergebnis übernimmt.

Die Schranken beginnen zu fallen

Robert C. Martin – „Uncle Bob“ –, der durch seine Bücher „Clean Code“ und „Clean Architecture“ die Industrie maßgeblich geprägt hat, hat am 12. September etwas geschrieben, das ich wirklich bemerkenswert finde.

Er hatte mehrere Wochen daran gearbeitet, Coding Agents in ein relativ enges Korsett aus Prozessen, Gates, Tests und Werkzeugen zu zwingen. Während er diesen Harness perfektionierte, wurden die Modelle allerdings so viel besser, dass er sich anschließend fragte, ob er sie inzwischen schlicht überreguliert.

Unit Tests hält er weiterhin für wichtig. Ebenso CRAP-Metriken und Mutation Testing. Aber seine Erfahrung ist inzwischen offenbar eine andere: Einem Agenten eine größere Aufgabe mit einigen Leitplanken geben, weggehen und vierzig Minuten später brauchbaren, getesteten und architektonisch sauberen Code vorfinden.

Das Interessante daran ist für mich weniger die konkrete Leistungsbehauptung.

Interessant ist, was sich damit an unserer Vorstellung von Softwarequalität verändert.

Ich kenne dieses Gefühl

Mir geht es inzwischen ähnlich.

Ich habe in meinen Projekten zunächst ziemlich viele Schranken aufgebaut: Repository-Regeln, explizite Arbeitsabläufe, Architekturvorgaben, Tests, Build-Prüfungen und Dokumentationspflichten.

Das war alles andere als unbegründet. Noch vor relativ kurzer Zeit musste man Agents sehr genau führen, damit sie nicht nach fünf Änderungen drei neue Baustellen aufmachten.

Aber ich ertappe mich zunehmend dabei, solche Vorgaben wieder abzubauen.

Nicht, weil mir Qualität plötzlich weniger wichtig wäre.

Sondern weil eine gute Coding AI heute teilweise wirklich besser arbeitet, wenn ich ihr das Problem, die vorhandene Architektur und das gewünschte Ergebnis erkläre und ihr dann genügend Raum lasse, eine Lösung zu entwickeln.

Interessanterweise beschreibt auch OpenAI genau diese Entwicklung aus einer anderen Richtung. In einem 2026 veröffentlichten Bericht über ein agentengetriebenes Softwareprojekt entstand nach eigenen Angaben rund eine Million Zeilen Code ohne manuell geschriebenen Anwendungscode. Entscheidend waren dabei aber keineswegs fehlende Regeln: Das Team verlagerte seine Arbeit auf Repository-Wissen, maschinenlesbare Vorgaben, Feedback-Loops und überprüfbare Systemgrenzen. Ein riesiges AGENTS.md erwies sich sogar als kontraproduktiv; stattdessen wurde eine kurze Orientierung mit strukturierten Dokumenten als „System of Record“ aufgebaut.

Das ist ein wichtiger Unterschied.

Weniger Mikromanagement ist nicht dasselbe wie weniger Governance.

„Alle Tests grün“ ist noch keine Codequalität

Gerade Coding Agents führen zu einer interessanten Versuchung.

Der Agent liefert Code. Die Unit Tests laufen. Die Code Coverage liegt bei 95 Prozent. Static Analysis ist zufrieden. Vielleicht läuft sogar Mutation Testing durch.

Also: fertig?

Nicht unbedingt.

Code Coverage sagt zunächst nur, welcher Code während eines Tests ausgeführt wurde. Mutation Testing geht erheblich weiter: Dabei werden gezielt kleine Fehler in den Code eingebaut und geprüft, ob die Tests diese Veränderungen erkennen. Damit lässt sich wesentlich besser beurteilen, ob eine Testsuite tatsächlich Fehler entdeckt und nicht lediglich Code ausführt.

Auch der CRAP-Index kombiniert deshalb Testabdeckung mit zyklomatischer Komplexität. Die Grundidee: Komplexer Code ohne vernünftige Tests ist besonders riskant zu warten.

All das sind nützliche Signale.

Aber kein einzelnes davon beantwortet beispielsweise die Fragen:

Hat der Agent überhaupt das richtige Problem gelöst?

Passt die Lösung langfristig zur Architektur?

Hat er eine Sicherheitsannahme verändert?

Hat er bestehende Nebenbedingungen verstanden?

Ist die Entscheidung auch in sechs Monaten noch nachvollziehbar?

Und, gerade in regulierten Umgebungen wichtig, können wir erklären, warum das System heute so aussieht, wie es aussieht?

Deshalb werden Architecture Decision Records (ADRs) wichtiger, nicht unwichtiger

An dieser Stelle bekommen ADRs für mich eine neue Bedeutung.

Ein ADR dokumentiert nicht einfach, was entwickelt wurde. Es hält eine architektonisch relevante Entscheidung mitsamt Kontext, Alternativen, Begründung und Konsequenzen fest. Genau diese Entscheidungslogik ist der Teil einer Softwarearchitektur, der sich aus dem fertigen Quellcode häufig kaum noch rekonstruieren lässt.

Wenn wir ehrlich sind, war das schon bei menschlich entwickelter Software ein Problem.

Bei AI-gestützter Entwicklung wird es wichtiger.

Denn ein Agent kann in wenigen Minuten eine erstaunlich plausible Lösung erzeugen. Wenn wir anschließend nur den Code speichern, aber nicht die dahinterliegende Entscheidung, verschwindet das Wissen mit dem Kontextfenster der Session.

Mein bevorzugtes Modell lautet deshalb zunehmend:

Der Agent darf Lösungsspielraum bekommen. Architekturentscheidungen müssen dagegen explizit werden.

Das ist für mich eine sinnvollere Schranke als hundert kleinteilige Prompt-Regeln.

ADRs sind damit nicht nur Architekturdokumentation. Sie werden zu einer Schnittstelle zwischen menschlicher Verantwortung und maschineller Umsetzung.

Und dann schaut der Computer eben in den Spiegel.

Wie weit sich diese Arbeitsweise treiben lässt, zeigt gerade ein herrlich absurdes Beispiel aus dem Omarchy-Umfeld.

Justin Schroeder zeigte in einem Post ein MacBook, auf dem an der Unterstützung externer Displays mit AMD-Radeon-Grafik gearbeitet wurde. Der Rechner beobachtete dabei sein eigenes Display – über die Webcam und einen Spiegel.

Der Grund ist technisch durchaus nachvollziehbar: Ein normaler Screenshot kann korrekt aussehen, obwohl ein Fehler erst später in der tatsächlichen Display-Pipeline entsteht. Die Kamera sieht dagegen am Ende des Weges das, was auf dem physischen Bildschirm tatsächlich erscheint. Das ergibt einen Feedback-Loop vom Code bis zu den realen Photonen vor dem Display.

Das ist gleichzeitig genial und ziemlich verrückt.

Und vielleicht ein wunderbares Bild dafür, wo wir uns gerade befinden.

Hypothese aufstellen. Code ändern. Maschine neu konfigurieren. Ergebnis physisch beobachten. Nächste Iteration.

Man könnte es – etwas zugespitzt – den YOLO-Modus der Softwareentwicklung nennen.

Für Forschung, Prototyping und eine private Entwicklungsmaschine finde ich das faszinierend.

Für ein produktives System eines regulierten Unternehmens würde ich daraus noch kein Betriebsmodell ableiten wollen.

Das Problem ist nicht mehr primär das Schreiben von Code

Genau darin liegt meines Erachtens die entscheidende Verschiebung.

Lange Zeit war Quellcode ein knappes Gut. Änderungen waren teuer. Deshalb steckte ein großer Teil der Qualitätssicherung zwangsläufig im Entwicklungsprozess selbst.

Wenn ein Agent dagegen innerhalb einer Stunde Änderungen erzeugen kann, für die ein Entwickler früher Tage benötigt hätte, wird Code billig – Veränderung aber nicht.

Die Datenmigration kann immer noch Daten zerstören.

Die API kann immer noch einen Vertrag mit anderen Systemen brechen.

Eine falsche Autorisierungsentscheidung bleibt falsch.

Eine architektonische Abkürzung erzeugt weiterhin technische Schulden.

Und 10.000 automatisch erzeugte Zeilen schlechten Codes sind nicht besser, nur weil ihre Entstehung praktisch nichts gekostet hat.

Hinzu kommt die Security-Perspektive. Untersuchungen zu LLM-generiertem Code finden weiterhin relevante Schwachstellen; in einer 2025 veröffentlichten Untersuchung enthielten 275 von 600 generierten JavaScript-Beispielen mindestens eine Schwachstelle. Solche Laborergebnisse lassen sich nicht eins zu eins auf moderne agentische Entwicklungsumgebungen übertragen, zeigen aber, warum funktionierende Software und sichere Software zwei unterschiedliche Qualitätsmerkmale bleiben.

Meine Schranken werden deshalb weniger – aber anders

Ich halte es inzwischen für sinnvoll, zwischen zwei Arten von Schranken zu unterscheiden.

Die erste versucht, dem Agenten jeden einzelnen Arbeitsschritt vorzuschreiben. Diese Art von Harness kann mit besseren Modellen tatsächlich schnell zur Behinderung werden.

Die zweite definiert überprüfbare Eigenschaften des Ergebnisses.

Dazu gehören für mich heute insbesondere:

Auch Anthropic empfiehlt für agentisches Coding klare überprüfbare Ziele, testgetriebene Schleifen und bei Bedarf eine Trennung zwischen erzeugendem und prüfendem Agenten. Das Entscheidende daran ist für mich das Prinzip: Nicht den Denkweg vollständig vorschreiben, sondern ein Umfeld schaffen, in dem Fehler sichtbar werden.

Das dürfte langlebiger sein als ein ausgefeiltes Prompt-Regelwerk.

Wer trägt die Verantwortung für den Merge?

Damit landen wir bei einer Frage, die technisch klingt, letztlich aber Governance ist.

Wenn ein Coding Agent einen Pull Request erzeugt, wer erklärt anschließend:

Ja. Diese Änderung wollen wir in unserem System haben.

Momentan lautet meine Antwort darauf weiterhin: ein Mensch.

Das muss nicht zwangsläufig für immer so bleiben. Schon heute wird diskutiert, wie weit agentische Reviews menschliche Code Reviews ersetzen oder ergänzen können. Die Forschung ist dabei keineswegs eindeutig: Neuere Arbeiten sehen erhebliche Effizienzpotenziale, aber noch keinen automatischen Gewinn bei der Review-Qualität.

Deshalb würde ich für produktive Systeme derzeit nicht auf das persönliche Review verzichten.

Nicht aus Nostalgie.

Sondern weil Verantwortung etwas anderes ist als Fehlererkennung.

Mein Zwischenstand

Die vergangenen Monate haben meine Haltung zur AI-gestützten Softwareentwicklung verändert.

Ich vertraue guten Coding Agents inzwischen deutlich mehr Freiheit an als noch zu Jahresbeginn. Manche der Schranken, die ich gebaut habe, wirken tatsächlich schon wieder wie Relikte einer früheren Modellgeneration.

Tests verschwinden dadurch nicht.

Architektur verschwindet nicht.

Dokumentation verschwindet nicht.

Und Verantwortung verschwindet schon gar nicht.

Sie verlagert sich.

Mein persönlicher Stand heute ist deshalb ziemlich einfach:

Ich fange langsam an, die „Schranken“ abzurüsten, auch wenn sich das noch sehr ungewohnt anfühlt. Ganz ohne persönliches Review geht bei mir trotzdem keine Codezeile durch.

Aber: Vielleicht spricht da aber auch einfach der Compliance-Guy in mir.

Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Manchmal versteht man einen Prozess erst dann wirklich, wenn man beobachtet, wie Menschen ihn umgehen.

Vor einiger Zeit hatte ich über mehrere Wochen Gelegenheit, eine größere Organisation aus einer für mich ungewohnten Perspektive zu erleben: nicht als Berater, sondern als Nutzer ihrer Prozesse.

Ganz abschalten lässt sich der berufliche Blick dabei offenbar nicht. Vermutlich eine Art Berufskrankheit. Wenn Technik, Prozesse und Organisation nicht zusammenpassen, fällt mir das auf.

Ein Erlebnis gleich zu Beginn war dafür fast lehrbuchhaft.

Für einen regelmäßig wiederkehrenden Vorgang erhielt ich eine RFID-Karte. An einem digitalen Terminal konnte eine Auswahl getroffen werden. Anschließend wurde die Karte an ein Lesegerät gehalten und ein Bondrucker produzierte die entsprechende Bestätigung.

Terminal. RFID. Kartenleser. Drucker.

Auf den ersten Blick: ein digitalisierter Prozess.

Dann kam der entscheidende Moment.

An der Ausgabestelle wurde der ausgedruckte Bon entgegengenommen, ungelesen in einen Sammelbehälter geworfen – und anschließend mündlich gefragt, welche Auswahl ich getroffen hätte.

Damit war der gesamte vorherige Prozess faktisch bedeutungslos.

Ich habe es akzeptiert, und offensichtlich war ich damit nicht allein: Statt den vorgesehenen Auswahlprozess zu durchlaufen, nutzten viele Anwender den kürzeren Weg und erzeugten unmittelbar den benötigten Bon.

Der offizielle Weg existierte.

Der tatsächlich genutzte Weg war ein anderer.

Wie bei einem sorgfältig gepflasterten Weg durch eine Grünanlage, der zunächst geradeaus führt, später abbiegt und schließlich am Ziel ankommt. Genutzt wird aber der direkt zum Ziel führende, quer über die Wiese verlaufende, Trampelpfad.

Die Menschen haben entschieden.

Nicht in einem Workshop.
Nicht durch eine Prozessanalyse.
Nicht per Beschluss.

Sondern mit ihren Füßen.

Der interessante Befund war nicht die Technik.

Der interessante Befund war, dass der reale Prozess die Technik faktisch ignorierte.

Das ist ein wichtiger Unterschied.

Digitalisierung wird häufig daran gemessen, ob Software eingeführt wurde, Terminals vorhanden sind, Daten elektronisch erfasst werden oder Papier durch einen Bildschirm ersetzt wurde.

Das sagt jedoch wenig darüber aus, ob der Prozess tatsächlich besser geworden ist.

Ein digitaler Prozess kann technisch vollkommen funktionieren und organisatorisch trotzdem völlig wirkungslos sein.

Wenn Informationen zunächst elektronisch erfasst, anschließend ausgedruckt und danach nicht verwendet werden, hat man keinen durchgängig digitalen Prozess geschaffen.

Vielmehr wurde ein zusätzlicher Arbeitsschritt geschaffen.

Und möglicherweise sogar einen ziemlich teurer.

Die entscheidende Frage lautet deshalb nicht:

„Ist dieser Prozess digitalisiert?“

Sondern:

„Welche konkrete Wirkung erzeugt die Digitalisierung im tatsächlichen Arbeitsablauf?“

Spart sie Zeit?

Verhindert sie Fehler?

Verbessert sie die Informationsqualität?

Reduziert sie Medienbrüche?

Entlastet sie Beschäftigte?

Macht sie Entscheidungen schneller oder verlässlicher?

Wenn sich eine oder mehrere dieser Fragen nicht überzeugend bejahen lässt, sollte man genauer hinsehen.

Organisationen betrachten Workarounds häufig als Störung.

Mitarbeiter halten sich nicht an den vorgesehenen Ablauf. Kunden nutzen ein System anders als geplant. Informationen werden in Excel-Listen gepflegt, obwohl dafür eine Fachanwendung existiert. Aufgaben werden per Zuruf geklärt, obwohl es ein Ticketsystem gibt. Dokumente werden ausgedruckt, obwohl ein Workflow eingerichtet wurde.

Die naheliegende Reaktion lautet dann:

Die Menschen müssen den Prozess besser einhalten.

Manchmal stimmt das.

Sehr häufig lohnt sich aber eine andere Frage:

Warum ist der Workaround attraktiver als der vorgesehene Prozess?

Menschen optimieren ihren Arbeitsalltag permanent.

Sie suchen nach Wegen, um Wartezeiten zu vermeiden, unnötige Eingaben zu reduzieren, Informationen schneller zu bekommen oder schlicht ihre eigentliche Aufgabe erledigen zu können.

Ein Workaround kann deshalb ein Symptom mangelnder Disziplin sein.

Er kann aber ebenso gut ein sehr präzises Feedback zum Prozessdesign darstellen.

Wenn nahezu alle Beteiligten denselben Umweg wählen, sollte man zumindest die Möglichkeit in Betracht ziehen, dass nicht die Beteiligten das Problem sind.

Vielleicht ist es der Prozess.

Das bedeutet nicht, jeden improvisierten Arbeitsweg automatisch zum neuen Standard zu erklären. Workarounds können Sicherheitsrisiken schaffen, Kontrollmechanismen umgehen, Datenschutzprobleme verursachen oder zu unklaren Verantwortlichkeiten führen.

Ein beobachteter Umweg sollte daher analysiert und verstanden werden.

Nicht bekämpft, bevor man ihre Ursache kennt.

Prozesshandbücher beschreiben, wie eine Organisation funktionieren soll.

Workarounds, also die Trampelpfade, zeigen, wie sie tatsächlich funktioniert.

Diese Differenz ist für mich besonders interessant.

Auf dem Papier kann ein Prozess logisch wirken:

Jeder einzelne Schritt lässt sich wunderbar dokumentieren.

Erst die Beobachtung des realen Ablaufs zeigt, dass möglicherweise zwischen „Bestätigung übergeben“ und „Leistung bereitstellen“ überhaupt keine funktionale Verbindung besteht.

Die Folge: Information wurde erzeugt – aber niemand benötigt sie.

Genau an solchen Stellen entsteht organisatorische Verschwendung.

Das gilt weit über digitale Bestellprozesse hinaus.

Ein Formular kann vollständig ausgefüllt werden, obwohl die nächste Stelle nur zwei Felder daraus nutzt.

Ein Genehmigungsprozess kann fünf Unterschriften verlangen, obwohl niemand eine inhaltliche Prüfung vornimmt.

Eine Anwendung kann Daten erfassen, die anschließend in einem zweiten System erneut eingegeben werden.

Ein digitales Ticketsystem kann existieren, während dringende Fälle trotzdem ausschließlich über persönliche Kontakte funktionieren.

Technisch betrachtet können all diese Systeme ordnungsgemäß arbeiten.

Aus End-to-End-Perspektive funktioniert der Prozess trotzdem nicht gut.

Der Trampelpfad macht diese Lücke sichtbar.

Er zeigt, welche Abkürzung Menschen gefunden haben, nachdem Prozessdesign, Technologie und tatsächliche Arbeitssituation aufeinandergetroffen sind.

Das macht ihn zu einer erstaunlich ehrlichen Form der Prozessdokumentation.

Bevor die nächste Software beschafft, ein weiterer Workflow eingerichtet oder der nächste Prozess „digitalisiert“ wird, helfen drei einfache Fragen:

Gerade die dritte Frage ist häufig ergiebiger als eine weitere Diskussion über Funktionslisten.

Denn der Nutzer kennt möglicherweise nicht die Systemarchitektur.

Aber er weiß sehr genau, welcher Weg ihn ans Ziel bringt.

Technical Governance beginnt für mich nicht bei der Frage, welche Software eingesetzt werden sollte.

Sie beginnt bei der Frage, wie Technik, Prozesse, Verantwortlichkeiten und Regeln gemeinsam wirken.

Ein System kann technisch hervorragend sein und trotzdem keinen Nutzen erzeugen, wenn es in einen schlechten Prozess eingebettet wird.

Ein guter Prozess kann scheitern, wenn Informationen an Systemgrenzen verloren gehen.

Eine sinnvolle technische Lösung kann wirkungslos bleiben, wenn Verantwortlichkeiten ungeklärt sind.

Und Governance kann zum Hindernis werden, wenn sie Anforderungen definiert, ohne deren praktische Umsetzung mitzudenken.

Deshalb reicht es nicht, Anwendungen isoliert zu betrachten.

Entscheidend ist der Weg vom Anfang bis zum Ende:

Wer benötigt welche Information, zu welchem Zeitpunkt, für welche Entscheidung – und was geschieht danach?

Erst wenn diese Kette funktioniert, entsteht Wirkung.

Das verändert auch die Reihenfolge, in der Organisationen über Digitalisierung nachdenken sollten.

Nicht zuerst:

Welche Software brauchen wir?

Sondern:

Welches Problem wollen wir lösen?

Dann:

Wie funktioniert der Prozess heute tatsächlich?

Und unbedingt:

Wo haben sich bereits Trampelpfade gebildet?

Denn genau dort findet man häufig die interessantesten Hinweise.

Der sauber gepflasterte Weg zeigt, wie der Prozess geplant wurde.

Der Trampelpfad zeigt, wie Menschen ihn wirklich benutzen.

Für gute Digitalisierung braucht man beides.

Aber im Zweifel würde ich mir zuerst den Trampelpfad ansehen.

Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Über Digitale Souveränität haben wir in diesem Format bereits gesprochen. Aber es ist notwendig, dies erneut zu tun, denn die Debatte um Digitale Souveränität hat neuen Schwung bekommen.

Die EU-Kommission hat dazu am 3. Juni 2026 ein Paket vorgestellt. Es umfasst den Chips Act 2.0, ein Gesetz zur Entwicklung von Cloud und KI, eine Open-Source-Strategie und einen Fahrplan für Digitalisierung und KI im Energiesektor.

Der politische Satz dahinter ist einfach.
Europa soll bei kritischen Technologien nicht dauerhaft abhängig sein.

Die Kommission nennt dafür sensible Bereiche.
Krankenhäuser. Energienetze. Sicherheitsdienste.
Das sind keine Komfortdienste. Das ist Grundbetrieb.

Die EU ist mit dieser Sicht nicht allein.
Auch andere Länder und Institutionen schauen auf digitale Abhängigkeiten.

In Japan prüft die Wettbewerbsbehörde JFTC Vorwürfe gegen Microsoft. Laut Cyber Intelligence Institute geht es um den Verdacht, Lizenzbedingungen könnten den Betrieb bestimmter Microsoft-Produkte auf konkurrierender Cloud-Infrastruktur erschweren oder verteuern. Das ist eine berichtete Einordnung. Es ist kein abgeschlossenes Urteil.

Auch ein Bericht des Internetportals Golem über die Software Microsoft Scout gehört in diese Debatte. Dort werden interne Formulierungen beschrieben, nach denen Nutzer abhängig gemacht werden sollten. Microsoft-Chef Satya Nadella wies diese Zielrichtung laut Bericht zurück.

Solche Fälle beweisen nicht jede große These.
Aber sie zeigen ein Muster.

Digitale Abhängigkeit entsteht selten auf einmal.
Sie wächst durch Verträge.
Sie wächst durch Gewohnheit.
Sie wächst durch Integration.
Sie wächst durch fehlende Alternativen.

Auch die USA rahmen KI inzwischen stark als Sicherheits- und Infrastrukturthema. Eine Executive Order vom 2. Juni 2026 verbindet fortgeschrittene KI mit Cybersicherheit, kritischer Infrastruktur und nationaler Sicherheit.

Hinzu kommt die physische Ebene.
KI und Cloud hängen an Kabeln, Strom und Rechenzentren.
Das renommierte Magazin WIRED beschreibt Unterseekabel für KI-Standorte am Golf als strategische Verwundbarkeit. Der Artikel verweist auch auf Berichte über mögliche Kontrolle von Kabeln in der Straße von Hormus.

Das zeigt: Digitale Infrastruktur ist nicht schwerelos.
Sie liegt in Rechenzentren.
Sie hängt an Stromnetzen.
Sie läuft durch Glasfaserkabel.
Sie passiert Seewege und Grenzräume.

Europa steht also nicht allein vor dieser Frage.
Aber Europa muss eine eigene Antwort finden.

Das klingt groß.
Aber es ist im Kern sehr konkret.

Wenn ein Dienst ausfällt, steht nicht nur eine App still.
Dann kann eine Verwaltung nicht arbeiten.
Dann kann ein Krankenhaus Prozesse verlieren.
Dann kann ein Unternehmen keine Daten mehr erreichen.
Dann kann ein KI-System nicht mehr rechnen.

Die Debatte verschiebt sich also.
Digitale Souveränität ist nicht mehr nur Privatsphäre.
Sie ist Infrastrukturpolitik.

Was ist neu?

Neu ist nicht die Erkenntnis, dass Europa abhängig ist.
Neu ist die Breite der Antwort.
Chips, Cloud, KI, Open Source und Energie werden endlich gemeinsam gedacht.
Denn diese Bereiche hängen zusammen.

KI braucht Rechenzentren.
Rechenzentren brauchen Chips.
Chips brauchen Lieferketten.
Cloud-Dienste brauchen Strom, Netz und Betrieb.
Open Source braucht Wartung, Sicherheit und Menschen.

Wer nur einen Teil betrachtet, übersieht den Rest.

Der Chips Act 2.0 soll europäische Halbleiter stärken. Er soll Genehmigungen beschleunigen und strategische Projekte unterstützen. Die Kommission stellt dabei auch den Bezug zu KI-Anwendungen und Rechenzentren her.

Das ist nachvollziehbar.

Der Cloud and AI Development Act soll mehr europäische Cloud- und KI-Kapazität ermöglichen. Die Kommission will auch einen Rahmen zur Bewertung von Cloud- und KI-Souveränität schaffen.

Das klingt technisch. Es ist aber politisch.

Denn eine Souveränitätsbewertung fragt nicht nur: Ist ein Dienst schnell?
Sie fragt auch: Wer kontrolliert ihn?
Wo liegen Daten?
Welches Recht gilt?
Welche Ausweichmöglichkeit gibt es?

Der dritte Baustein ist Open Source.
Die EU will offene Alternativen stärken.
Genannt werden Cloud, KI, Internet-Technologien, Cybersicherheit und Halbleiter.

Das ist absolut sinnvoll.
Aber Open Source ist kein Zauberwort.

Offener Code schafft Einblick.
Er kann Wechsel erleichtern.
Er kann Abhängigkeiten senken.
Er kann lokale Anbieter stärken.

Aber er betreibt sich nicht selbst.
Er patcht sich nicht selbst.
Er schult keine Mitarbeitenden.
Er bezahlt keine Sicherheitsprüfungen.
Er organisiert keine Haftung.
Er garantiert keine Verfügbarkeit.

Genau hier liegt die Lücke.

Politik spricht gern über strategische Autonomie.
In der Praxis braucht sie Betrieb.
Sie braucht Wartung.
Sie braucht Personal.
Sie braucht Beschaffung.
Sie braucht Budgets.
Sie braucht Governance.

Ohne das bleibt Open Source ein gutes Argument.
Aber kein belastbares System.

Das betrifft auch die Verwaltung.
Eine Kommune kann nicht einfach sagen: Wir nutzen freie Software.
Sie braucht Administratoren.
Sie braucht Support.
Sie braucht Migrationspläne.
Sie braucht Schulungen.
Sie braucht klare Zuständigkeiten.

Bisherige Versuche sind mehr oder minder (kläglich) gescheitert.
Dann entsteht Frust.
Und dann kehrt man zum alten Anbieter zurück.

Die wirtschaftliche Mechanik ist ähnlich wie bei KI-Kosten.

Wer KI nutzt, zahlt nicht nur für Antworten.
Eine frühere netkiosk.digital-Folge über KI-Kosten hat diesen Punkt auf der Nutzungsebene ausführlich beschrieben.

Nun geht es um dieselbe Logik auf politischer Ebene.
Natürlich kostet KI Geld.
Ein Anbieter darf diese Kosten abrechnen.
Das ist nicht automatisch problematisch.

Problematisch wird es, wenn Nutzer keine Kontrolle haben.
Wenn Preise, Limits und Modellpolitik von außen kommen.
Wenn Daten nicht sauber getrennt sind.
Wenn keine Exit-Strategie geplant ist.

Dann wird aus einem Werkzeug Infrastruktur.
Und aus Infrastruktur wird Macht.

Aber muss Europa jede Infrastruktur selbst entwickeln oder betreiben ?

Die tagesschau zitiert die Einordnung, technologische Souveränität bedeute nicht „Europe First“. Es gehe darum, eigene Fähigkeiten in kritischen Bereichen aufzubauen und offen für Handel zu bleiben.

Das ist der wichtige Punkt.

Souveränität heißt nicht Abschottung.
Sie heißt Handlungsfähigkeit.

Europa muss nicht jede Cloud ersetzen.
Aber Europa braucht Wahlfreiheit.

Europa muss nicht jeden Chip selbst bauen.
Aber Europa darf kritische Lieferketten nicht ignorieren.

Europa muss nicht jedes KI-Modell allein trainieren.
Aber Europa braucht eigene Infrastruktur für sensible Bereiche.

Europa muss also entscheiden, wo eigene Fähigkeiten nötig sind.
Nicht jedes Produkt muss aus Europa kommen.
Nicht jeder Anbieter muss europäisch sein.
Nicht jede internationale Partnerschaft ist ein Risiko.

Der AI Act macht die Lage zusätzlich konkreter.
Die Transparenzregeln treten im August 2026 in Kraft.

Auch das ist Souveränität.
Nicht als Hardware.
Sondern als Regelsetzung.

Die eigene These lautet deshalb:

Digitale Souveränität entsteht nicht durch ein einzelnes Gesetz.
Sie entsteht durch belastbare Alternativen.
Und durch die Fähigkeit, sie wirklich zu betreiben.

Der EU-Plan ist darum wichtig.
Er benennt mit Chips, Cloud, KI, Open Source und Energie die richtigen Ebenen.

Aber der Erfolg entscheidet sich an den harten Fragen.

Wer finanziert den Betrieb?
Wer bildet Fachleute aus?
Wer trägt Verantwortung?
Wer beschafft klug?
Wer hält Systeme sicher?
Wer beendet nutzlose Projekte?

Ohne diese Antworten bleibt Souveränität ein schönes Wort.

Mit diesen Antworten wird sie praktisch.
Dann geht es nicht um Abschottung.
Dann geht es um Auswahl.
Um Resilienz.
Um Kostenkontrolle.
Und um den einfachen Satz: Wer abhängig ist, braucht einen Exit-Plan.

Digitale Souveränität ist keine romantische Rückkehr zur Technik von gestern.
Sie ist auch kein pauschales Misstrauen gegen ausländische Anbieter.

Sie ist die nüchterne Frage, wo Europa, Unternehmen und Verwaltungen handlungsfähig bleiben müssen.

Der EU-Plan zeigt, dass diese Frage politisch geworden ist.
Jetzt muss sie praktisch werden.

Wer heute seine Abhängigkeiten kennt, muss morgen nicht hektisch wechseln.
Wer heute Alternativen prüft, gewinnt Zeit.
Wer heute Kosten misst, behält Kontrolle.

Diesen Text und diese Folge finden Sie auf netkiosk.digital.
Folgen Sie netkiosk.digital kostenlos in Apple Podcasts.
Kommentare zur Folge schicken Sie am einfachsten über die netkiosk.digital-App. Diese finden Sie im Apple App Store.

Verwandte Episoden mit vollständiger URL:

KI-Kosten: Wenn der Zähler weiterläuft
https://www.netkiosk.digital/podcast/ki-kosten-wenn-der-zaehler-weiterlaeuft/
Ist heute Ihr Digital Independence Day?
https://www.netkiosk.digital/podcast/ist-heute-ihr-digital-independence-day/
Hacker, Hersteller und der Moment der Wahrheit
https://www.netkiosk.digital/podcast/hacker-hersteller-und-der-moment-der-wahrheit/

Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Microsoft hat Scout vorgestellt. Nicht als weiteren Chatbot. Nicht als kleines Fenster für schnelle Antworten. Scout soll ein Arbeitsagent sein. Er soll im Hintergrund laufen. Er soll Termine vorbereiten, Dateien bearbeiten, E-Mails auswerten und Risiken erkennen.

Damit verschiebt Microsoft die Debatte. Bisher ging es oft um die Frage, ob KI gute Antworten liefert. Bei Scout geht es um eine andere Frage. Darf ein KI-System im Namen des Nutzers handeln?

Microsoft nennt solche Systeme Autopilots. Sie sollen dauerhaft aktiv sein. Sie besitzen eine eigene Identität. Sie arbeiten im Rahmen gesetzter Berechtigungen. Sie greifen auf Microsoft 365 zu. Dazu zählen Teams, Outlook, OneDrive, SharePoint, E-Mail, Kalender, Chats und Kontakte.

Die Microsoft-Learn-Dokumentation geht noch weiter. Scout kann Dateien lesen und schreiben. Scout kann Shell-Kommandos ausführen. Scout kann einen Browser steuern. Scout kann Microsoft-365-Daten abfragen. Scout kann im Hintergrund arbeiten.

Das ist der zentrale Unterschied:
Ein Chatbot macht Vorschläge.
Ein Agent greift in Abläufe ein.
Er kann eine Datei verändern.
Er kann eine Nachricht vorbereiten.
Er kann einen Termin setzen.
Er kann eine Recherche anstoßen.
Er kann Befehle ausführen.
Damit wird er Teil der Arbeitsinfrastruktur.

Genau deshalb ist der technische Unterbau so wichtig. Microsoft sagt selbst, Scout werde durch OpenClaw-Open-Source-Technologie angetrieben.
Nun… Im Februar hatte Microsofts eigenes Security-Team OpenClaw aber sehr vorsichtig beschrieben. Die Runtime könne fremden Text aufnehmen. Sie könne externe Skills ausführen. Sie könne mit zugewiesenen Zugangsdaten handeln.

Microsoft schrieb damals sinngemäß: OpenClaw gehört nicht auf normale Arbeitsrechner. Wer es testet, soll es isolieren. Es soll mit dedizierten Konten laufen. Diese Konten sollen niedrige Rechte haben. Die Umgebung soll keine sensiblen Daten enthalten.

Im Juni heißt es nun: Scout kommt als Enterprise-Agent. Er soll in Microsoft 365 eingebettet werden. Nun ja. Ich würde das freundlich als „Sicherheitsparadox“ beschreiben. Dieselbe technische Linie, die vorher wie ein Risiko behandelt wurde, wird jetzt als Arbeitsprodukt verpackt.

Das bedeutet nicht, dass Scout automatisch unsicher ist. Microsoft nennt Gegenmaßnahmen. Agenten sollen eigene Entra-Identitäten haben. Purview-Regeln und DLP sollen greifen. Sensitivity Labels sollen berücksichtigt werden. Für sensible Aktionen kann eine Freigabe nötig sein.

Diese Kontrollen sind wichtig. Sie sind aber keine Antwort auf alle Fragen. Denn der Kern des Risikos liegt in der Kombination. Autonomie trifft auf Dauerbetrieb. Memory trifft auf Zugangsdaten. Browserzugriff trifft auf fremde Inhalte. Shell-Zugriff trifft auf lokale Dateien. Aus einzelnen Funktionen wird eine neue Angriffsfläche.

Microsoft beschreibt selbst, welche Risiken bei OpenClaw entstehen können. Zugangsdaten und erreichbare Daten können abfließen. Der Zustand oder die Erinnerung eines Agenten kann manipuliert werden. Das Host-System kann kompromittiert werden, wenn der Agent Code nachlädt und ausführt.

Hinzu kommt der Zeitpunkt. Diverse Portale verweisen auf Berichte über fünf OpenClaw-Zero-Days im Umfeld der Scout-Vorstellung. Diese Meldungen ersetzen keine eigene technische Analyse. Sie liefern aber einen aktuellen Anlass. Sie zeigen, warum die alte Sicherheitsfrage nicht erledigt ist.

Ein zweiter Punkt betrifft Bindungsdesign. 404 Media berichtet unter Berufung auf interne Microsoft-Unterlagen, dass die erste Phase der Scout- beziehungsweise ClawPilot-Strategie Nutzer abhängig machen sollte. Das Internetportal Golem griff diesen Punkt auf. Microsoft-Mitarbeiter sollen die Formulierung intern kritisch gesehen haben.

Man sollte diese Formulierung nicht überdehnen. Ein internes Planungswort ist noch kein fertiges Produktverhalten. Aber es ist ein Warnsignal. Ein Agent, der im Hintergrund immer mehr Aufgaben übernimmt, kann nützlich sein. Er kann aber auch Gewohnheiten bauen. Erst hilft er. Dann übernimmt er. Danach fehlt die Alternative.

Das betrifft besonders Unternehmen. Microsoft 365 ist oft kein einzelnes Werkzeug. Es ist ein Betriebssystem für Arbeit. Identität, E-Mail, Dateien, Chat, Kalender, Office, Rechteverwaltung und Geräteverwaltung hängen zusammen. Wenn dort ein permanenter Agent hinzukommt, wächst die Bindung an das Ökosystem.

Auch das Kostenrisiko gehört in diese Debatte. Für Scout liegen in den uns zugängigen Quellen keine belastbaren Preisdetails vor. Trotzdem ist die Mechanik erkennbar. Agenten verbrauchen Rechenleistung. Sie lesen Kontext. Sie schreiben Ausgaben. Sie starten Werkzeuge. Sie können Teilaufgaben delegieren. Sie laufen auf Zeitplänen oder Auslösern.

Ein kurzer Auftrag kann klein wirken. Der Prozess dahinter kann groß sein. Ein Agent durchsucht E-Mails. Er prüft Kalender. Er liest Dateien. Er startet eine Webrecherche. Er nutzt ein Modell. Er schreibt Zusammenfassungen. Er hält Ergebnisse im Speicher. All das kostet Infrastruktur.

Riskant wird es, wenn KI-Nutzung selbst zur Kennzahl wird. Unlängst hat der NVIDIA-CEO in einer Keynote genau davon gesprochen. Aber: Dann arbeiten Menschen mit Agenten, weil es modern wirkt. Sie erzeugen Aktivität. Sie verschieben Verantwortung an ein System, dessen Fehler später schwer zuzuordnen sind. Sie verbrauchen Budget. Gut für NVIDA oder Microsft. Doof für Nutzer und deren Geschäftsführungen.

Die falsche Antwort lautet daher: erst ausrollen, später regeln. Diese Reihenfolge ist bequem. Sie ist aber gefährlich. Bei einem normalen Tool kann man vieles nachziehen. Bei einem Agenten entstehen schon im Test Datenflüsse, gespeicherte Entscheidungen und Freigabemuster.

Human in the loop klingt beruhigend. Es reicht aber nicht immer. Wenn Auto-Approve-Regeln gesetzt werden, wirken Entscheidungen weiter. Wenn ein Agent im Heartbeat-Modus periodisch läuft, ist niemand ständig daneben. Wenn Automationen Bedingungen prüfen, entsteht Schattenarbeit. Sie kann produktiv sein. Sie kann aber auch unübersichtlich werden.

Für Verwaltung, Bildung und Gesundheitswesen ist das besonders heikel. Dort geht es nicht nur um Effizienz. Es geht um Akten, Patientendaten, Schülerdaten, Personalvorgänge und öffentliche Verantwortung. Ein Agent darf dort nicht nur technisch funktionieren. Er muss erklärbar, auditierbar und begrenzbar sein.

Auch Betriebsräte, Informationssicherheitsbeauftrage, Datenschutzbeauftragte und die Compliance sollten früh eingebunden werden. Scout kann Arbeitskontexte beobachten. WorkIQ, Memory, Automationen und Hintergrundläufe erzeugen eine neue Nähe zum Verhalten von Beschäftigten. Daraus muss nicht automatisch Überwachung werden. Aber die Infrastruktur dafür entsteht.

Digitale Souveränität heißt hier nicht, Microsoft sofort zu verlassen. Das wäre für viele Unternehmen unrealistisch. Es heißt, Abhängigkeiten zu kennen. Es heißt, Grenzen zu setzen. Es heißt, Exit-Szenarien zu planen. Es heißt auch, lokale KI als Teil der Antwort zu prüfen.

Scout zeigt, wohin Enterprise-KI gerade kippt. Weg vom optionalen Assistenten. Hin zum delegierten Mitarbeiter aus Software. Dieser Schritt kann nützlich sein. Er kann Koordination erleichtern. Er kann Routinearbeit senken. Aber er braucht mehr als Produktvertrauen.

Die entscheidenden Fragen sind einfach. Welche Daten darf Scout sehen? Welche Aktionen darf Scout ohne Freigabe ausführen? Welche Aktionen sind verboten? Wer prüft die Protokolle? Wer haftet bei Fehlern? Wer misst Kosten und Nutzen? Und wie lässt sich der Agent wieder abschalten?

Unternehmen sollten Scout nicht wie ein einfaches neues Office-Feature behandeln. Sie sollten Scout wie eine neue operative Rolle behandeln. Diese Rolle braucht ein Profil. Sie braucht Rechte. Sie braucht Grenzen. Sie braucht Aufsicht. Und sie braucht einen klaren Zweck.

Die Lehre aus OpenClaw ist nicht, dass Agenten unmöglich sind. Die Lehre ist, dass Agenten eine andere Sicherheitsklasse bilden. Sie verbinden Text, Code, Daten, Identität und Handlung. Wer das unterschätzt, baut nicht Produktivität auf. Er baut Abhängigkeit auf.

Microsoft Scout ist deshalb kein Randthema für Technikfans. Es ist ein Testfall für Arbeit, Sicherheit und Souveränität. Der richtige Beginn ist nicht die Frage, wie viel der Agent übernehmen kann. Der richtige Beginn ist die Frage, was er niemals dürfen soll.

Scout ist kein Grund für Panik. Aber Scout ist ein Grund für klare Regeln. Wer Microsoft 365 nutzt, sollte jetzt nicht nur auf Funktionen schauen. Entscheidend sind Rechte, Protokolle, Kosten und Datenflüsse. Ein Agent, der im Hintergrund arbeitet, braucht engere Grenzen als ein Chatfenster. Er braucht weniger Vertrauen und mehr Nachvollziehbarkeit. Unternehmen sollten Tests nicht dem Zufall überlassen. Verwaltung, Bildung und Gesundheitswesen brauchen besonders strenge Vorgaben. Lokale KI kann an manchen Stellen helfen. Sie ersetzt aber keine saubere Strategie. Die einfache Regel lautet: Erst klären, dann freischalten. Erst Grenzen setzen, dann automatisieren.

Diesen Text und die gesprochene Episode finden Sie auf netkiosk.digital. Kommentare zur Folge schicken Sie am einfachsten über die netkiosk.digital-App. Diese finden Sie im Apple AppStore.

Verwandte Episoden mit vollständiger URL: