# Die Architektur hinter verantwortbarer Autonomie > KI einzusetzen kann mittlerweile jeder. Was zwischen „Claude Code installiert“ und Agenten, die sicher betrieben werden, liegt, ist Inhalt dieses Essays. - **Autor:** Dominic Asche - **Datum:** 09 / 2026 - **Lesezeit:** 13 min - **URL:** https://fse-group.de/thinktank/die-architektur-hinter-verantwortbarer-autonomie Wer Claude Code installiert, hat nach zehn Minuten einen Assistenten, der Code schreibt und Kommandos ausführt. Das ist der einfache Teil. Der schwierige beginnt, sobald das Modell nicht mehr nur antwortet, sondern handelt. KI einzusetzen kann mittlerweile jeder, aber wir glauben, die Verantwortung, die daraus resultiert, ist vielen nicht klar. Was für uns zwischen „Claude Code installiert“ und Agenten, die sicher betrieben werden, liegt, ist Inhalt dieses Essays. Wer Claude Code installiert, hat nach zehn Minuten einen Assistenten, der Code schreibt, Dateien liest und Kommandos ausführt. bypassPermissions an, Zugriff auf Computer und Browser, und schon erledigt „Claude“ erste Aufgaben allein. Das ist beeindruckend und der einfache Teil. Der schwierige Teil beginnt, sobald das Modell nicht mehr nur antwortet, sondern handelt: ein Ticket anlegt, eine Bestellung freigibt, eine Kundenantwort vorbereitet. Datenschutz, Auditfähigkeit und mehr. Jetzt muss man als Unternehmen sagen können, auf welcher Grundlage gehandelt wurde, welche Befugnis galt, welche Daten dabei geflossen sind, auf welcher Rechtsgrundlage sie verarbeitet wurden und wer eine Entscheidung getroffen hat. Wir haben Agenten als vollwertige Kollegen ins Team integriert: in der Ticketbearbeitung und -umsetzung, in der Überwachung unserer Systeme, in Kundenprozessen. Was nötig ist, um das sicher herzustellen, welche Fehler wir auf dem Weg gemacht haben und welches Investment wir erschaffen haben, wollen wir nachfolgend teilen. Wir glauben, dass vielen die Folgen, die aus der Benutzung von Programmen wie Claude entstehen, nicht bewusst sind. Uns waren sie es zumindest vorher nicht. ### Was ein installiertes Werkzeug kann, und was es nicht wissen kann Claude Code bringt viel mit: Berechtigungen pro Werkzeug, Regeln für Erlauben, Nachfragen und Verbieten, Hooks für eigene Prüfungen, zentral verwaltete Einstellungen für Unternehmen. Anthropic hat damit die technischen Voraussetzungen für einen kontrollierten Betrieb geschaffen, und wir nutzen jede davon. Jeder muss alles benutzen und aus unserer Sicht darüber hinaus noch viel mehr selbst sicherstellen. Ist Ihnen bewusst beziehungsweise transparent, welche Aktionen Claude oder Codex durchgeführt hat? Könnte es sein, dass in einem internen Reasoning-Vorgang etwas stand, das nicht öffentlich werden durfte? Also ist verhindert, dass Claude jemals ein Bash-Command auf eine .env oder auf ein Secret ausgeführt hat? Oder eine E-Mail eines Geschäftspartners ohne geeignete Rechtsgrundlage oder die erforderlichen Datenschutzmaßnahmen an die Anthropic-API geschickt hat? Wie wurde sichergestellt, dass im Ordner kein Dokument enthalten war, dessen Verarbeitung in diesem Kontext nicht zulässig war? bypassPermissions lässt grüßen mit „hallo IT-Securityvorfall“, möglicherweise „hallo Datenschutzvorfall“. Der Unterschied lässt sich in einer Tabelle zeigen. Links das, was die Installation mitbringt. Rechts das, was fehlt, wenn ein Agent Verantwortung übernehmen soll, und wie wir es gelöst haben. ### Woher weiß der Agent, was gilt? **Claude Code nach der Installation** Aus dem, was im Prompt und in den geöffneten Dateien und Ordnern steht, claude.md, Anweisungen im Skill- und/oder Rules-Ordner **Enterprise Grade bei FSE** Standardisiertes Startprompt mit festen Skills, Guardrails enforced über eigenen Harness Ein notwendiges LLM Wiki als Wissensbasis mit Quelle, Stand und einem Governanceprozess, der Lücken und Widersprüche auflöst ### Was darf er technisch tun? **Claude Code nach der Installation** Was die lokale Berechtigungsliste erlaubt **Enterprise Grade bei FSE** Jede Nachricht, jeder Call an Claude geht über ein zentrales FSE-Policy-Gateway, das auf PII, unerlaubte Befehle und Einhaltung von festen Werkzeugen prüft ### Was darf fachlich passieren? **Claude Code nach der Installation** Technische Berechtigungsmechanismen existieren. Unternehmensspezifische fachliche Grenzen kennt das Werkzeug nach der Installation jedoch nicht, sofern wir sie nicht selbst definieren und technisch durchsetzen. **Enterprise Grade bei FSE** Guardrails sind technisch durchgesetzt, also deterministisch über das Policy-Gateway, und prozessual über strikte Anweisungen. Aufgaben sind nach dieser Logik mit eigenem Regelset aufgebaut: - braucht die Aufgabe einen eigenen Auslöser, wird sie ein Agent - braucht sie einen eigenen großen Lesekontext, wird sie Subagent - sonst wird sie Skill Agenten und Skills haben über zentral kontrollierte MCP-Server, Authentifizierung, Autorisierung und Gateway-Policies beschränkte Rechte, analysiert nach einem Risk-Threat-Model, Zonenbewertung und eigener Zugangslogik nach CRUD, Vier-Augen-Prinzip und generellem Pentesting. Sämtliche Unterhaltungen und Aktionen, also Agent-Logs, werden gespeichert, untersucht und bei Fehlverhalten oder unerlaubten Aktionen sofort gemeldet, samt Folgemaßnahmen-Policies ### Was passiert mit personenbezogenen Daten? **Claude Code nach der Installation** Sie stehen im Kontext, sobald sie gelesen werden **Enterprise Grade bei FSE** Maskierung und Prüfung. Direkte Identifikatoren und definierte sensible Datenklassen werden, wo sie für den Verarbeitungszweck nicht erforderlich sind, vor dem Modellaufruf entfernt, maskiert oder tokenisiert. Dies geschieht durch das Zwischensetzen von lokaler Claude App, Policy Gateway und Anthropic-API bei den dafür definierten Übergängen, vor dem Modellaufruf, vor dem Schreiben, vor dem Speichern. Grundsätzlich sollte organisatorisch verhindert sein, dass personenbezogene Daten überhaupt in Prompts beziehungsweise POSTs existieren, wenn sie dort für den jeweiligen Zweck nicht erforderlich sind ### Wer entscheidet, wenn es unklar ist? **Claude Code nach der Installation** Der Mensch, der die Unterhaltung mit Claude oder Codex führt **Enterprise Grade bei FSE** Standardisierter, auditfähiger Entscheidungsprozess mit festen Regeln, dokumentiert in einem Ticket, Eskalationspfade und nur innerhalb vordefinierter Regeln ### Wie kommt eine Änderung am Agenten in Betrieb? **Claude Code nach der Installation** Datei, beispielsweise claude.md, ändern und speichern **Enterprise Grade bei FSE** Merge Request, menschliche Freigabe, Regressionstests, Evals gegen bekannte Fehlerfälle, Testfälle und Bewertung ### Was lernt das System aus einem Fehler? **Claude Code nach der Installation** Nicht organisatorisch. Claude Code kann Erkenntnisse über Auto Memory oder CLAUDE.md über Sessions hinweg persistieren. Ein organisatorisches Learning entsteht daraus aber nicht. **Enterprise Grade bei FSE** Ständige Analyse von Agentenläufen nach Evals und KPIs, die zu einer Regel oder einer technischen Grenze werden oder Prozesse verändern Agenten oder Prompts erhalten ein Ziel. Der Harness versucht, je nach Einstellung dieses Ziel zu erreichen, und mit dem Command /goal arbeitet das Tool so lange und versucht so lange, bis ein separater Evaluator die gesetzte Completion Condition als erfüllt bewertet. Je länger und autonomer ein solcher Lauf arbeitet und je mehr Werkzeuge und Datenquellen dafür zugänglich sind, desto größer wird die Angriffsfläche. Sensible Daten können in den Modellkontext und damit zum externen Harnessanbieter gelangen, wenn Datei-Inhalte, Tool-Outputs oder andere lokale Informationen ungefiltert zurückgeführt werden. Nur wer einen Harnessanbieter wie OpenAI oder Anthropic als sichere Zone einstuft und den konkreten Datenfluss entsprechend absichert, kann jetzt weiterhin von einem seriösen Betrieb sprechen. ### Wissen mit Herkunft Agenten, im seriösen Unternehmenskontext, arbeiten nicht mit dem, was zufällig in einem Prompt steht oder angewiesen wurde, sondern mit einer eigenen, versionierten Wissensbasis. Darin liegen Unternehmensregeln, Prozessbeschreibungen und Systemwissen, verdichtet aus Dokumentationsseiten. Jede Seite kennt ihre Quelle und deren Stand. Ein Agent liest also nicht nur eine Antwort. Er sieht, woher sie stammt und wie alt sie ist. Aufbauend auf dem von [Andrej Karpathy](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) beschriebenen Konzept eines „LLM Wiki“ bilden wir Autorität, Werthaltigkeit und Hierarchie des Wissens ab. Einem Harness einfach ungefiltertes Wissen aus beispielsweise einem Confluence oder einem Drive zu geben, ist, an folgendem Beispiel anschaulich erklärt, absoluter Unsinn: Dokumentation ist in agilen Zeiten fast per Definition n-1. Beispiel: Zwei Dokumente beschreiben dieselbe Regel unterschiedlich. Das System wählt nicht die plausibler klingende Variante aus, was ein Modell ohne diese Vorkehrung womöglich täte. Es markiert den Konflikt auf beiden Seiten, und ein eigener Prozess legt solche Fälle täglich vor. Die Klärung läuft als geführter Prozess, Antwort gibt ein Mensch, und sie wird in die Quelle zurückgeschrieben, nicht nur in die Wissensbasis. ![Bildschirmfoto aus unserer Betriebsplattform: eine Zeile der Widerspruchsliste der Wissensbasis, gekennzeichnet mit der Kennung C-2c5e39 und dem Vermerk Regelseite. Der Befund lautet, dass Regel 25 der Quelle verlangt, die technische Roadmap im hybriden Lauf vor der ersten Zeile Code zu lesen und freizugeben, während der Befehl zum Umsetzen nur das Lesen verlangt und keinen Freigabeschritt kennt. Daneben steht die betroffene Quelle Regeln für Ticket Umsetzung mit einem Link, der Hinweis Widerspruch innerhalb einer Quelle, kein Gegenstück, und rechts eine Schaltfläche, um den Fall in Claude zu klären.](https://fse-group.de/media/think-pieces/20260915_thinktank-harness-brain-conflict.png) Dahinter steht eine wichtige Unterscheidung: Ein Fehler beim Verdichten lässt sich anhand der Quelle korrigieren. Die Frage, welche von zwei Unternehmensregeln künftig gilt, ist keine Korrektur. Sie ist eine Entscheidung der Organisation. Ein System, dessen Quellen sich widersprechen, ist als Grundlage für autonome Prozesse gefährlich. ### Anweisung ist nicht Durchsetzung Eine Regel im Kontextfenster erklärt dem Modell, was es tun soll. Ob eine konkrete Aktion dann aber auch wirklich deterministisch stattfindet, muss an anderer Stelle abgesichert sein. Das Kontextfenster ist kein Garant für die Durchsetzung einer Regel. Dieses LLM-immanente Verhalten muss bei jeder Erwartungshaltung verinnerlicht sein. Ob etwas stattfinden darf, wird an anderer Stelle definiert: Jeder Werkzeugaufruf eines Agenten geht vor der Ausführung über einen Hook an ein zentrales Gateway in unserer Betriebsplattform, der Anwendung, in der wir alle Agentenläufe steuern, beobachten und auswerten. Dort wird geprüft: Ist das Werkzeug für diesen Agenten zugelassen? Bleibt der Aufruf innerhalb des Mandanten, für den er arbeitet? Stimmt die Empfängerkonstellation, etwa bei einer Nachricht an einen Kunden? Ist der verwendete Skill unverändert und wird der erwartete StructuredOutput eingehalten? Häuft sich der Aufruf ungewöhnlich? Fällt eine solche Prüfung durch, findet die Aktion per technischer Garantie niemals statt, sofern sämtliche möglichen Ausführungspfade und Egress-Wege technisch über diese Kontrollschicht erzwungen werden. Der Agent erhält die Regel, gegen die er verstoßen hätte, samt Korrekturvorschlag, und formuliert neu. ![Ablaufgrafik mit dem Titel Zwei Kontrollpfade zwischen Absicht und Wirkung, beschriftet als Grafik 1, die Kette einer autonomen Geschäftsaktion. Von links nach rechts: ein Geschäftsereignis wie E-Mail, Ticket oder Bestellung, dann die Wissensbasis mit Regeln samt Quelle und Stand, dann der Agent, bei dem das Modell entscheidet wie. Darauf folgt der mit Harness überschriebene Bereich mit zwei übereinanderliegenden Prüfungen: das technische Gateway, das Werkzeug, Mandant, Empfänger und personenbezogene Daten prüft, und die fachliche Prüfung in der Anwendung, die Auftrag, Einstufung und Vorbereitung prüft. Danach die menschliche Freigabe dort, wo sie zusätzliche Sicherheit bringt, und zuletzt die protokollierte und auswertbare Ausführung. Aus dem Harness führt ein Pfeil nach unten zu einem Kasten: Blockiert führt zum sichtbaren Bearbeitungspfad mit Regel-Kennung, Begründung und Korrekturvorschlag, der Agent formuliert neu und ein Mensch entscheidet Unklares. Zwei senkrechte gestrichelte Linien markieren die Datenschutzgrenze mit Maskierung vor dem Modellaufruf und Prüfung vor dem Schreiben.](https://fse-group.de/media/think-pieces/20260915_thinktank-harness-controlpaths.png) Ein Beispiel aus dem Alltag: Ein Ticket, in dessen Text personenbezogene Daten geraten würden, weil ein Agent versucht, ein solches anzulegen, beispielsweise auf Briefing eines Kunden hin, der Kundendaten an eine E-Mail angehängt hat, wird nicht geschrieben. Der Agent versucht, mit seinem Ticketsystem-MCP-Werkzeug die Create-Funktion aufzurufen. Das Modell erzeugt dafür einen Tool Call. Bevor unsere Anwendung diesen gegen das Ticketsystem ausführt, prüft das Gateway Payload und Berechtigung, beispielsweise auf PII. Die Prüfung kennt die Regel und weist den POST ab, nennt die Regel und die Stelle. Dieselbe Mechanik sorgt dafür, dass kein Agent eine Kundennachricht an eine Adresse außerhalb des zugehörigen Mandanten schickt, und so weiter. Doch das reicht noch immer nicht. Ein generisches Gateway weiß, dass ein Werkzeug erlaubt ist. Es weiß nicht, was die konkrete Aktion fachlich bedeutet. Diese Prüfung liegt deshalb in der Fachanwendung selbst. Bei einer Auftragsfreigabe prüft die Anwendung, ob die Bestellung zum gesetzten Auftrag gehört, ob die hinterlegte Einstufung eine Freigabe zulässt, ob die Vorbereitungsschritte erfolgt sind und ob dieselbe Freigabe in diesem Lauf schon einmal eingeplant wurde. Damit steht die Trennung, die für uns den Begriff Enterprise Grade ausmacht: Das Modell entscheidet, wie es ein Ziel erreicht. Die Architektur entscheidet, innerhalb welcher Grenzen daraus Wirkung werden darf. ### Autonomie wird pro Prozess gestaltet Autonomie ist keine Einstellung, die man einmal setzt und überall verwendet. Die eine Aufgabe endet mit einem Vorschlag. Andere brauchen eine Freigabe. Wieder andere laufen innerhalb definierter Bedingungen selbstständig ans Ziel. Ein Beispiel aus unserer Ticketbearbeitung: Ein Agent nimmt eine eingehende E-Mail an das Ticket-Postfach, baut daraus User Story, Akzeptanzkriterien und einen Umsetzungsplan und legt das Ticket an. Ein zweiter Agent setzt das Ticket um. Er liest den Plan, schreibt Code, führt Tests aus und stellt das Ergebnis zur Qualitätssicherung dem menschlichen Dev-Team vor. Stößt er auf eine offene Frage, schreibt unser Agent sie als markierten Punkt in den Plan, weist das Ticket dem zuständigen Menschen zu und wartet. Antwort, Frage, Entscheidung sind transparent, können in direktem Gespräch oder in Gruppenchats, sogar mündlich in Teams-Meetings, entschieden werden. Sämtliche Kommunikation, alle Transkripte werden nach Abschluss analysiert und bewertet auf die betriebswirtschaftlich wertvollste Frage überhaupt: Wie kann die Rückfrage künftig verhindert werden, was muss unternommen werden, damit der Harness im nächsten Durchlauf ohne Rückfrage auskommt (siehe hierzu: [Was bleibt nach dem Token?](/thinktank/was-bleibt-nach-dem-token)) ![Bildschirmfoto eines Fahrplans im Ticketsystem. Unter der Überschrift Schritte zur Zielerreichung stehen zwei mit einem Fragezeichen markierte Punkte, die einer Person zugewiesen sind. Der Agent hält darin fest, dass ein Akzeptanzkriterium ohne Messgröße nicht prüfbar ist und fragt, anhand welchen konkreten Merkmals geprüft werden soll, und dass ein zweites Kriterium ein konkretes Szenario braucht. Unter jeder Frage steht die Anweisung, die Antwort an die Stelle des Unterpunkts zu schreiben und das Ticket danach dem Jira-Benutzer FSE KI zuzuweisen, worauf es erneut geprüft wird. Darunter folgen die übrigen Punkte des Fahrplans und eine Legende, die erklärt, dass ein Fragezeichen einen offenen Punkt zur Klärung markiert, der nur während der Ticketbearbeitung erlaubt ist.](https://fse-group.de/media/think-pieces/20260915_thinktank-harness-plan-question.png) Geht etwas schief, greift eine Eskalation, die für Agenten genauso verbindlich ist wie für Menschen. Dauert eine Aufgabe länger als geplant, fehlt eine Voraussetzung oder ist der Betrieb beeinträchtigt, zieht ein Agent, ein Prozess oder ein Mensch die „rote Reißleine“ (siehe „Reißleine“, [Toyota Produktionssystem](https://de.wikipedia.org/wiki/Toyota-Produktionssystem)): Alles stopp, wir versammeln uns in einer Teams-Session, Mensch-Maschine, und lösen das Hindernis auf. Wie weit Autonomie gehen kann, hängt für uns von drei Dingen ab: von der möglichen Wirkung einer Handlung, von der Qualität der Kontrollen und davon, wie zuverlässig Fehler erkannt werden. Die klassische Frage nach dem Menschen in der Schleife verschiebt sich damit. Sie lautet nicht mehr pauschal, ob ein Mensch nötig ist. Sie lautet, an welcher Stelle eine menschliche Entscheidung zusätzliche Sicherheit bringt, und wo eine technisch prüfbare Grenze sie ersetzen kann. ### Datenschutz liegt im Datenfluss, nicht im Prompt Ein Hinweis im System Prompt, personenbezogene Daten vertraulich zu behandeln, ist, wie bereits erwähnt, eine Bitte. Datenschutz muss stattdessen an den Übergängen, an denen Daten den Ort wechseln, behandelt und sichergestellt sein. Der Mailzugriff unserer Agenten liefert logischerweise Absender und Empfänger. Bei uns gilt: Wo diese Informationen für den Zweck des Modellaufrufs nicht erforderlich sind, erreichen sie den Harness nicht im Klartext, sondern werden maskiert oder tokenisiert: der erste Buchstabe bleibt, der Rest wird gest*****. Im Kundenprozess werden E-Mail-Inhalte vor dem Modellaufruf auf Muster wie Zugangsdaten oder Kontonummern geprüft. Erzeugte Kundenantworten werden vor der Weitergabe auf interne oder sensible Informationen kontrolliert. Wird etwas gefunden, wechselt der Vorgang in einen internen Bearbeitungspfad. Datenschutz muss technisch sichergestellt werden. Sobald ein Harness, wie Codex oder Claude, ohne vorherige Prüfung Zugriff auf eine Inbox erhält, besteht das Risiko einer unzulässigen Verarbeitung oder, bei unbefugter Offenlegung, eines Datenschutzvorfalls. Das klingt womöglich sehr deutsch. Dass ich meine Beschwerde, mein Projektbriefing, meinen HR-Bewertungsreport oder mein wöchentliches, persönliches Review einem Anbieter wie OpenAI gegenüber offenlegen wollte, erzeugt hingegen ein Unwohlsein und setzt ein Transparenzvertrauen voraus, über das man sich womöglich zu wenig Gedanken macht und sonst nur bereitwillig Meta mit persönlichsten Einblicken via WhatsApp oder Apple mit teils intimsten Bildern und Nachrichten anvertraut. Deswegen müssen aus unserer Sicht die für Sicherheit und Audit relevanten Agent-Traces risikobasiert geprüft und überwacht werden. Damit sind nicht nur die Interaktionen zwischen Agent und Mensch gemeint, sondern insbesondere Prompts, Tool Calls, Tool Outputs, Datei- und Systemzugriffe, Antworten sowie, soweit vom verwendeten Modell bereitgestellt, Reasoning-Summaries. Auch für diese Logs müssen Zweck, Zugriff und Aufbewahrungsdauer definiert sein. Und wir gehen noch weiter: Wenn irgendwo ein Zugang, ein Geheimnis oder eine eingeschleuste Anweisung offenliegt, muss das eingedämmt werden. Ein Zugang, der in einem solchen Trace auftaucht, gilt sofort als kompromittiert, egal wie er dort hingekommen ist, und wird ausgetauscht, automatisiert. Jetzt denkt man womöglich: Ok, wer ist so leichtsinnig und lässt Secrets offenlegen? Beispiel: Claude, mit entsprechend weitreichend freigegebenen Werkzeugen, Analyse eines Bestellstatus. Anthropics Harness legt los, hat keinen direkten DB-Zugriff, es wurde eine .env mit einem lesenden Datenbankzugriff bereitgestellt, nur über VPN erreichbar und nur über einen Jumphost und SSH-Tunnel. Klingt nach solider Architektur. Der Agent überlegt, wie er an die Bestelldetails kommen kann, und greift beispielsweise per Bash auf die .env zu. Wird der Dateiinhalt dabei durch einen Read- oder Command-Output in den Modellkontext aufgenommen, wird dieser Inhalt an den verwendeten Modellanbieter übertragen. Folglich: kompromittiert. ![Bildschirmfoto der wöchentlichen Auswertung der Gateway-Befunde für die Kalenderwoche 38 des Jahres 2026. Fünf Zeilen mit Fallart, Prüfklasse und Empfehlung: ein Löschversuch eines Remote-Branches wurde korrekt geblockt, echte Ansible-Läufe ohne Prüf-Flag ebenfalls, beide als Verstoß eingestuft mit dem Hinweis, dass kein Handeln nötig ist. Drei weitere Zeilen sind als unklar eingestuft, weil bei abgeschnittenem Kommando die Serverzugriffsprüfung, die Force-Push-Erkennung und eine Cross-Tenant-Erkennung nicht abschließend verifizierbar waren. Jede Zeile trägt eine Empfehlung und eine Schaltfläche, um den Fall in Claude zu bearbeiten oder zu schließen.](https://fse-group.de/media/think-pieces/20260915_thinktank-harness-policy-findings.png) Beim Gedächtnis der Agenten muss übrigens dasselbe Prinzip gelten. Der Europäische Datenschutzausschuss beschreibt Privacy by Design als fortlaufende Aufgabe: von Beginn an integriert, regelmäßig auf Wirksamkeit geprüft, mit Datenminimierung vor der Verarbeitung. [1] Für uns heißt das: Datenschutz verändert das Verhalten des Systems, nicht nur seinen Wortlaut. Und für jeden Anwendungsfall ist geklärt, welcher Anbieter die Daten verarbeitet, in welcher Region, wie lange und auf welcher vertraglichen Grundlage. ### Behauptungen, Disclaimer und die Forderung nach einem Security Mindset Der Wert liegt zwischen Modell, Prozess und Harness, nicht im Konzept. Der angeschnittene FSE-Ansatz verpflichtet uns, unsere Bestrebung nach einem wirtschaftlichen, sicheren und nachhaltigen Betrieb immer im Hinblick auf die Folgen der Aktion zu beleuchten. Ein Gateway beweist keine vollständige Absicherung aller Ausführungspfade. Ein Audit-Log beweist keinen fachlich erfolgreichen Vorgang. Eine Prüfung nach einer Aktion kann deren Wirkung nicht rückgängig machen. All unsere Prozesse beweisen ihre Wirksamkeit erst, wenn die gesamte Organisation die weitreichenden Konsequenzen einer Abweichung von der stoischen Absicherungsmaxime per default mitdenkt. Diese Genauigkeit ist kein Vorbehalt gegen Autonomie. Sie ist die Bedingung, um sie Schritt für Schritt zu erweitern. Modelle werden besser, Werkzeuge auch. Der Zugang zu einem leistungsfähigen Modell unterscheidet bald niemanden mehr. Wenn sich Modellfähigkeiten weiter annähern, verschiebt sich die Differenzierung zunehmend auf die Schicht, die ein Unternehmen um das Modell baut: sein Wissen und dessen Herkunft, seine Rollen und Skills, seine Geschäftsregeln, seine Datenschutzgrenzen, seine technischen Befugnisse, seine Governance und die Fähigkeit, Betriebserfahrung in das System zurückzuführen. Kurzum, der eigene Harness. Unser Anspruch ist eine Organisation, die KI zunehmend eigenständig handeln lässt und trotzdem jederzeit sechs Fragen beantworten kann: - Auf welcher Grundlage wurde gehandelt? - Welche Befugnis galt? - Welche Daten durften diese Grenze überschreiten? - Welche Kontrolle hat die Handlung zugelassen? - Was haben wir aus dem Ergebnis gelernt? - Und wer trägt die Verantwortung für das, was das System nicht entscheiden darf? Wer diese Fragen beantworten kann, betreibt eine Infrastruktur und ist nicht mehr Konsument einer Commodity-Intelligenz der großen, datenhungrigen Frontier-Labs. Sicherlich mit Opt-out vertraglich zugesichert, doch vor dem Hintergrund von [Der Vorfall bei Hugging Face und der weitere Weg](https://openai.com/de-DE/index/hugging-face-incident-and-the-road-ahead/) oder [An alignment assessment of recent cybersecurity incidents](https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents) darf Zarathustra nicht unerwähnt bleiben: Vielleicht ist KI genau deshalb weniger die Frage, was Maschinen künftig können, sondern was der Mensch und seine Organisation daraus machen. KI ist vielleicht nicht Zarathustras Übermensch. Sie zwingt uns womöglich, neu zu beantworten, was der Mensch nicht an Maschinen delegieren sollte. Unternehmerisches Handeln heißt, die Dinge in die Hand zu nehmen und autonom mit allen Konsequenzen zu agieren. Wir möchten nachdrücklich dazu auffordern, dass diese neuen, mächtigen Tools, die alsbald omnipräsente Intelligenz in einer unvorstellbaren Geschwindigkeit liefern werden, als solche verstanden werden und wir alle sie so einsetzen, dass wir unserer Commodisierbarkeit bewusst sind. ![Infografik mit dem Titel Das Modell entscheidet, wie. Der Harness entscheidet, wie weit, überschrieben mit Der sichere KI-Harness. Oben eine Kette in vier Schritten: Geschäftsereignis, Wissensbasis und Agent, Gateway und fachliche Prüfung, Freigabe oder Ausführung. Darunter eine Tabelle mit dem Titel Was die Installation mitbringt, und was fehlt, mit den Spalten Nach der Installation und Enterprise Grade bei FSE. Vier Zeilen: Woher weiß der Agent was gilt, aus Prompt und geöffneten Dateien gegenüber einer versionierten Wissensbasis mit Quelle, Stand und Governance. Was darf technisch passieren, die lokale Berechtigungsliste gegenüber einem zentralen Policy-Gateway, das vor der Wirkung prüft. Was passiert mit personenbezogenen Daten, sie stehen im Kontext sobald sie gelesen werden, gegenüber Maskierung und Tokenisierung an den Übergängen. Wie kommt eine Änderung in Betrieb, Datei ändern und speichern gegenüber Merge Request, menschlicher Freigabe, Regressionstests und Evals. Als Fazit darunter: Eine Regel im Kontextfenster ist eine Bitte, ob eine Aktion stattfindet entscheidet die Kontrollschicht, die jeden Ausführungspfad erzwingt. Am Fuß drei Karten unter der Überschrift Sechs Fragen, jederzeit beantwortbar: auf welcher Grundlage wurde gehandelt und welche Befugnis galt, welche Daten durften die Grenze überschreiten und welche Kontrolle hat es zugelassen, was haben wir daraus gelernt und wer trägt die Verantwortung für das, was das System nicht entscheiden darf.](https://fse-group.de/media/think-pieces/20260915_thinktank-harness-overview.png) #### Quellenverzeichnis - [1] Europäischer Datenschutzausschuss: *Guidelines 4/2019 on Article 25, Data Protection by Design and by Default*, Version 2.0, 20. Oktober 2020. - [2] Anthropic: *Claude Code Dokumentation*, Abschnitte Permissions, Hooks und Managed Settings, abgerufen im September 2026. - [3] Europäische Union: *Datenschutz-Grundverordnung*, insbesondere Art. 5, Art. 6, Art. 25, Art. 28 und Art. 32. - [4] Anthropic: *Dokumentation zu Claude Code Permissions sowie Extended Thinking und Thinking Summaries*, abgerufen im September 2026. - [5] Andrej Karpathy: *Veröffentlichungen zum Konzept LLM Wiki*, 2026.