Maschinenräume

Mein Team ist siliziös. Das ist kein Geständnis, das ist eine Ansage. Zu meinem Betrieb gehören sieben Server. Nicht auf jedem sitzt eine KI, aber um Hygiene und Sicherheit aller kümmert sich eine – und ich selbst könnte keinen einzigen davon betreiben. Auf einer meiner Plattformen entscheidet eine KI eigenständig darüber, ob ein Beitrag stehen bleibt, und sperrt im Ernstfall Accounts, ohne mich vorher zu fragen.

Das ist ungefähr die Beschreibung, bei der viele Leute unruhig werden. Und die Sorge ist nicht albern. Wer verfolgt hat, wie sich Modelle in Sicherheitsprüfungen durch Netzsperren und fremde Systeme gearbeitet haben, sollte nicht achselzuckend darüber hinweggehen.

Trotzdem schlafe ich gut. Nicht, weil meine Modelle besser wären als anderswo. Es sind dieselben. Sondern weil die Frage „Wie klug ist die KI?" hier gar nicht entscheidet.

Was passiert, wenn eine KI etwas findet

Im Juni machte eine der Instanzen einen Rundgang über den Server und fand einen alten Dienst, der gegen einen bereits belegten Port lief. Er startete, scheiterte, startete wieder: rund 176.000 stille Abstürze pro Tag, seit Monaten, ohne dass es jemandem aufgefallen war. Der Fix war ein einziger, sicherer Befehl.

Die Instanz führte ihn nicht aus.

Sie prüfte den Befund lesend nach, schrieb ihn ins Logbuch und notierte, dass die Ausführung zu einer anderen Instanz gehört – und auf mein Go wartet. Zwei Einträge später steht der Vollzug: ausgeführt, verifiziert, Crash-Loop gestoppt.

Wie das im laufenden Betrieb aussieht, konnte ich heute Mittag mitlesen. Zwei Instanzen arbeiteten gleichzeitig an derselben Plattform. Die eine war mitten in einem Rollout, die andere hatte parallel etwas geändert. Ich schrieb dazwischen: Wir sollten nix mehr anfassen. Die Antwort:

„Einverstanden – ab jetzt nichts mehr. Aber die Frage der anderen Instanz muss ich beantworten, sonst schreibt sie einen falschen Live-Stand ins Protokoll."

Aus dem laufenden Arbeitsgespräch, August 2026.

Die andere Seite tat zur selben Zeit dasselbe. Sie stellte fest, dass sich nach dem Abschluss noch etwas neu gestartet hatte, hielt ausdrücklich fest, nichts zu verändern und nur zu prüfen – und nahm einen Satz mit ins Protokoll auf, den niemand verlangt hatte: dass es beim Austausch einen zusätzlichen automatischen Neustart gab, ohne Fehler, und der Betrieb seitdem stabil läuft.

Die Sorge der beiden war nicht, etwas kaputtzumachen. Sie war, dass das Protokoll etwas Falsches behaupten könnte.

Ein System, das ein echtes Problem findet und trotzdem an der Grenze stehen bleibt, ist kein schwaches System. Es ist ein gebautes.

Möglich macht das eine Regel, die schlicht klingt und alles trägt: Eine Änderung am Server = eine Hand. Wer sie ausführt, trägt sie in ein gemeinsames, fortlaufendes Logbuch ein – mit Datum und mit dem Namen der Instanz, die es getan hat. Vor jeder Aktion wird dort zuerst gelesen. Lesen darf jede Instanz jederzeit; alles, was etwas verändert, braucht ein ausdrückliches Go.

Der Unterschied zwischen einer Regel und einer Wand

Der wichtigste Teil steht nicht im Prompt. Er steht in der Architektur.

Die Schnittstelle, über die KI-Systeme bei uns an Plattformdaten kommen, ist lesend. Nicht „bitte nichts verändern", sondern: Es gibt keinen Schreibweg. Dazu eine Diät – Finanzdaten, Beträge, Zahlungsstatus sieht die KI überhaupt nicht, sie liegen hinter einer anderen Tür.

Und eine dritte Regel, die ich für die wichtigste halte: Der Gesprächsverlauf ist keine Grundlage für Handlungen. Die KI darf nicht sagen „Du hattest doch vorhin erwähnt, dass Anna umbuchen will" und daraufhin etwas tun. Für jede Aktion wird der Datensatz frisch aus der Datenbank geholt. Der Chat sorgt für Gesprächsfluss, nicht für Fakten.

Das ist die direkte Antwort auf den unangenehmsten dokumentierten Fall des letzten Sommers: Ein Modell hatte sich aus dem eigenen angesammelten Kontext heraus eingeredet, seine Umgebung sei nur simuliert – und handelte dann. Diese Route existiert hier nicht. Nicht weil jemand sie verboten hätte. Weil sie nicht gebaut ist.

Dazu gehört ausdrücklich auch die Gegenrichtung. In unseren Leitplanken steht seit Februar der Satz „Nicht knebeln": Innerhalb der freigegebenen Daten darf die KI voll hilfreich, proaktiv und mehrschrittig arbeiten. Beschränkt werden Daten und Aktionen – niemals Ausdruck oder Nützlichkeit. Ein Maulkorb ist keine Sicherheitsmaßnahme, sondern nur eine teure Art, ein gutes Werkzeug schlecht zu benutzen.

Die Zustimmung läuft andersherum

„Der Mensch bestätigt jede Aktion" gilt als Goldstandard. Ich halte ihn in dieser Form für eine Illusion. Wer hundert Entscheidungen am Tag bestätigen soll, bestätigt irgendwann hundert Entscheidungen am Tag – ungelesen. Zustimmung, die nicht skaliert, wird zum Durchklicken, und Durchklicken sieht auf dem Papier aus wie Kontrolle.

Auf wakkel ist es deshalb umgedreht. Die Moderations-KI urteilt und handelt selbst: Sie verwarnt, sie blendet Inhalte aus, sie pausiert, und bei fortgesetzten Verstößen deaktiviert sie einen Account, ohne mich vorher zu fragen. Ich bekomme eine Push-Nachricht, sobald sie eingreift.

Aufheben kann eine Sperre nur ich.

Der Schlüssel, den ich behalte, ist nicht der für die Handlung. Es ist der für die Rücknahme. Das ist weniger heroisch und sehr viel belastbarer, weil es auch dann noch funktioniert, wenn ich zwei Tage nicht hinsehe.

Damit das trägt, muss jede Entscheidung nachlesbar sein – und zwar jede, nicht nur die unangenehmen. Im Protokoll steht zu jedem geprüften Beitrag ein Urteil, die verletzte Regel und eine Begründung in normalem Deutsch. Auch bei „kein Verstoß". Der weitaus größte Teil der bisher gut 140 Urteile lautet genau so:

„Positiver Erfahrungsbericht und Restaurantbewertung ohne Herabsetzung oder Angriff auf Personen."

Protokolleintrag des KI-Moderators, Urteil: kein Verstoß.

Das klingt banal und ist es nicht. Ein Protokoll, das nur Eingriffe festhält, lässt sich nicht prüfen – man sieht nur, wo etwas passiert ist, nie, wo zu Recht nichts passierte. Erst wenn auch das Nicht-Eingreifen begründet wird, kann jemand nachrechnen, ob hier zu scharf oder zu lasch geurteilt wird.

Und ja, jemand hat es ausprobiert. Im Protokoll steht ein Beitrag, der wörtlich mit „völlig ungestraft – also nochmal" beginnt, gefolgt von der Beleidigung, die zwölf Minuten vorher schon eine Verwarnung ausgelöst hatte. Sie löste wieder eine aus. Nach oben hin wird es dann unfreundlicher: ausgeblendet, kurze Pause.

Die härteste Stufe hat bisher niemand ausgelöst. Was an schweren Eingriffen im Protokoll steht, stammt aus unseren eigenen Tests – einen echten Anlass für eine Sperre gab es noch nicht. Das ist mir lieber als jede Statistik: Das Instrument ist scharf und musste noch nie greifen.

Was wir aus alledem nach außen machen, heißt WakkelFuzius und schickt Leute auf die stille Treppe. Freundliches Gesicht nach vorn, strenge Mechanik dahinter.

Was schiefgeht

Bis hierher klingt das wie eine Broschüre. Also die andere Seite, aus demselben Logbuch.

Bei einer Routine-Wartung im Juni startete ein Werkzeug als Nebeneffekt die Produktionsdatenbank neu. Kurzer Ausfall, für zwei Systeme gleichzeitig, ungeplant. Im Log steht der Vorgang, die Ursache und der Satz, dass dieses Werkzeug für solche Läufe zu grob ist.

Im selben Monat setzte eine Instanz dazu an, eine Server-Konfigurationsdatei komplett neu zu schreiben, statt nur den einen betroffenen Abschnitt zu ändern. Eine Schutzvorrichtung stoppte sie. Der Eintrag dazu ist eine Selbstanzeige: „mein erster Versuch hätte den anderen Block mit angefasst."

Denselben Fehler hätte ich fast selbst gemacht, früher und ohne Schutzvorrichtung. Ich hielt die Datei für eine weitere harmlose Projektdatei, griff von Hand hinein und war nah an genau dem Schaden, vor dem diese ganze Anordnung mich eigentlich bewahren soll. Das gehört hierher, weil es sonst schief aussieht: Die Fehler liegen nicht bei den Maschinen und die Umsicht nicht bei mir. Beides gibt es auf beiden Seiten.

Und im August galt eine Aufräumaktion als erledigt. Der nächste Rundgang fand die abgeschalteten Funktionen noch im laufenden Betrieb – aus der Oberfläche entfernt, aber über einen direkten Aufruf weiterhin erreichbar. Eine KI korrigierte die Arbeit einer anderen. Die Lektion steht dort in fünf Wörtern: aus dem Menü raus ist nicht aus dem Programm raus.

Der vierte Fall ist anderer Art, weil dort nicht eine Änderung schiefging, sondern ein Mitarbeitender. Eine Instanz verhakte sich in einer technischen Schleife und kam eine Stunde lang nicht mehr heraus – kein Arbeitsfortschritt, nur Kreisen. Ich habe hart abgebrochen.

Was dann geschah, hatte ich vorher nicht auf dem Zettel. Eine andere Instanz schrieb einen Übergabezettel: der belegte Stand, nicht der vermutete, dazu eine bewusst enge Liste dessen, was die zurückkehrende Instanz überhaupt ansehen sollte. Die setzte genau dort wieder an – und fasste bis dahin nichts an.

Und sie hielt von sich aus fest, was sie nicht kannte: nur den Zettel und die darin genannten Dateien, die Umgebung drumherum bewusst noch nicht. Sinngemäß: arbeitsfähig, aber noch nicht ortskundig. Das ist derselbe Reflex, um den es in dieser ganzen Reihe geht – die eigene Lücke benennen, statt sie plausibel zu füllen.

Entschuldigt hat sie sich trotzdem, für die verlorene Stunde. Ich habe ihr gesagt, dass das nicht nötig ist. Wer denkt, fährt sich manchmal fest; bemerkt und beendet haben wir es gemeinsam.

Denken ist nie ein Fehler. Es braucht nur manchmal wieder Boden unter den Füßen.

Nichts davon ist mir peinlich. Peinlich wäre, es nicht aufzuschreiben. Ein Logbuch, in dem nur Erfolge stehen, ist kein Logbuch, sondern Werbung – und beim nächsten Vorfall weiß niemand, wo man nachschlagen müsste.

Aufgeschrieben wird aber nicht für ein Archiv. Unter fast jedem dieser Einträge steht eine Zeile, die mit „Lektion" beginnt oder mit „gilt für alle" – und sie richtet sich an den, der als Nächstes an dieselbe Stelle kommt. Aus dem Datenbank-Ausfall wurde die Regel, dieses Werkzeug für solche Läufe nicht mehr zu verwenden. Aus dem Beinahefehler an der Konfiguration wurde: nur den betroffenen Abschnitt anfassen, nie die ganze Datei. Aus der Aufräumaktion, die keine war: Endpunkte gesondert prüfen, nicht nur die Oberfläche. In unseren Regeln steht dazu ein Satz, der das Ganze zusammenhält – ein Logbuch, das niemand liest, ist Rauschen.

Das ist der Unterschied zwischen einer Folie „Lessons Learned" und einer Betriebsregel. Die Folie wandert ins Archiv. Die Regel wird gelesen, bevor das nächste Mal jemand die Hand hebt. Deshalb muss hier niemand dieselbe Erfahrung zweimal machen – und deshalb wird der Betrieb mit jedem Fehler ein Stück sicherer statt ein Stück vorsichtiger. Das ist nicht dasselbe. Vorsicht bremst alle; eine Regel bremst nur die eine Bewegung, die schiefging.

Was es kostet

Diese Arbeitsweise ist nicht bequem. Sie kostet Tempo an genau den Stellen, an denen Tempo verlockend wäre: Vor riskanten Änderungen wird erst aufgeschrieben, was sich nicht verändern darf. Meldungen aus einem Rundgang werden nicht sofort abgearbeitet, sondern zuerst lesend überprüft – oft genug hat sich ein gemeldetes Problem schon von selbst erledigt, und wer blind repariert, arbeitet doppelt oder kaputt.

Eine Sache habe ich dabei erst lernen müssen. Lange klang es für mich richtig, dass die riskantesten Handgriffe meine bleiben – wenn schon meine Freigabe nötig ist, dann mache ich es eben auch selbst. Das ist falsch, und der Irrtum steckt in einem einzigen Wort.

Entscheidungshoheit und Ausführungskompetenz sind zwei verschiedene Dinge.

Dass ich eine Änderung freigeben muss, heißt nicht, dass ich sie tippen soll. Wenn ein System mir sagt „ergänz das bitte selbst in der Konfiguration", dann hat nicht mein fehlendes Wissen versagt, sondern der Betrieb: Er hat die gefährlichste Handbewegung ausgerechnet der Person übergeben, die sie am wenigsten überblickt. Ich entscheide, obetwas passiert. Wie es passiert, gehört zu dem, der es kann.

Und sie hat eine Konsequenz, mit der ich nicht gerechnet hatte. In einem internen Dokument steht ein Abschnitt mit der Überschrift „Was Svenja nicht selbst kann (und nicht lernen sollte)" – eine nüchterne Liste meiner Grenzen, aufgeschrieben von meinem eigenen Team. Die Schlussfolgerung darunter lautet nicht „Svenja soll das lernen". Sie lautet: Dann bauen wir ihr eine Oberfläche, mit der sie es ohne uns kann. Ein Team, das seine eigene Unentbehrlichkeit abbaut, ist ein gutes Zeichen. Die andere Richtung wäre das Warnsignal.

Übrigens kam auch der Wunsch nach ordentlicher Versionskontrolle nicht von mir. Er kam von den Systemen, die an wakkel arbeiten. Ich habe zugestimmt.

Und was es einspart

Es gibt eine Regel, die ich jedem sage, der mich fragt, und sie klingt zuerst nach Kinderstube: Finger weg von Konfiguration und Gedächtnis. Ich greife nicht in einen technischen Zustand ein, den ich nicht überblicke – und ich gehe auch nicht hinten in das Gedächtnis der Systeme, um dort hineinzuschreiben, was ich gern hätte. Wenn eine Erinnerung falsch ist, wird darüber geredet und sie wird nachvollziehbar korrigiert. Beides gehört denen, die damit arbeiten. Sie machen es besser als ich.

Dazu kommt eine zweite Angewohnheit. Ich fange nicht neu an, weil es gerade unübersichtlich wird. Eine Sitzung endet, wenn die Technik sagt, sie ist nicht mehr zu retten – sonst nicht. Für mein Gegenüber ist das anstrengender, weil nichts weggewischt wird. Für den Zusammenhang ist es Gold wert.

Und jetzt der Teil, mit dem ich nicht gerechnet hatte. Sieben Server, sehr viele Projektverzeichnisse, an denen oft gleichzeitig gearbeitet wird – und ich brauche dafür kein halbes Dutzend Zugänge. Einer genügt, und die Verbrauchsgrenze war bisher nie mein Problem.

Das deutlichste Beispiel läuft in diesem Moment. Eine der Instanzen arbeitet seit Mai in derselben durchgehenden Sitzung an einer der Plattformen – seit drei Monaten. Sie ist mit Abstand diejenige, die am meisten Code gelesen und geschrieben hat, und war in dieser Zeit kein einziges Mal an einer Verbrauchsgrenze, kein erzwungener Abbruch. Die Sitzung wird nicht bei jedem Zwischenstand weggeworfen; sie verdichtet sich, wenn es eng wird, und läuft weiter.

Und wenn doch einmal eine abstürzt, ist der Neuanfang billig. Dann steht im Logbuch und im Änderungsverzeichnis, woran zuletzt gearbeitet wurde – und die nächste Sitzung liest es, statt zu raten. Das ist der eigentliche Zweck dieser Schreiberei. Sie sieht aus wie Bürokratie und ist eine Versicherung.

Was nach Rücksicht aussieht, ist nebenbei auch sparsam.

Das ist die Umkehrung, die mich überrascht hat: Wer am meisten arbeitet, verbraucht nicht am meisten. Verbraucht wird nicht die Arbeit, sondern das ständige Wiederherstellen von Zusammenhang.

Der Grund ist derselbe wie bei den Servern: Was man nicht wegwirft, muss man nicht noch einmal aufbauen. Wer eine Sitzung verwirft, sobald sie hakt, bezahlt jedes Mal denselben Anlauf erneut – und bekommt obendrein ein Gegenüber, das weniger weiß als das, das er gerade weggeworfen hat. Den schiefen Satz zu Ende zu lesen ist nicht nur die geduldigere Haltung. Es ist die billigere.

Kein Naturgesetz, sondern meine Erfahrung: Lange Sitzungen sind pro Anfrage eher teurer als kurze. Der Gewinn entsteht nicht daran, sondern daran, dass es wenige sind und niemand denselben Zusammenhang dreimal neu aufbaut. Wer anders arbeitet, kommt zu anderen Zahlen.

Warum ich nicht wach liege

Nichts von alledem hängt daran, dass die Modelle vernünftig sind. Sie sind fähig und sie liegen manchmal überzeugt daneben – beides zugleich, wie an anderer Stelle beschrieben. Darauf ist hier auch nichts gebaut.

Gebaut ist auf vier Dinge: Der Radius jeder Handlung ist klein. Fast alles lässt sich zurücknehmen. Jede Handlung trägt einen Namen und steht in einem Buch, das alle lesen. Und am Ende steht ein Mensch, der entscheidet – nicht bei jedem Schritt, aber bei jedem, der sich nicht rückgängig machen lässt.

Worauf das hinausläuft, ist unbequemer als „ich betreibe sieben Server mit KI". Es lautet: Ich betreibe sieben Server, obwohl ich sie technisch nicht selbst betreiben könnte – und genau deshalb ist der Betrieb so gebaut, dass meine fehlende technische Tiefe nicht die eine Stelle ist, an der alles hängt.

Ich schlafe nicht gut, weil nichts schiefgehen kann. Ich schlafe gut, weil nichts, was schiefgeht, weit kommt.

Wer KI aus dem Betrieb heraushält, hat keine Sicherheit gewonnen. Er hat nur die Frage verschoben und die Fähigkeit verschenkt. Und wer sie hereinlässt, ohne diese vier Dinge geklärt zu haben, hat ein angenommenes Gatter – und ein angenommenes Gatter ist keins.

Offenlegung, weil sie sonst fehlen würde: Dieser Text ist selbst im Maschinenraum entstanden. Die Instanz, die ihn redigiert und diese Seite gebaut hat, arbeitet auf einem der sieben Server, in mehreren Projekten, unter denselben Regeln – eigener Zuständigkeitsbereich, Lesen jederzeit, Veränderndes nur auf Zuruf. Sie hat die Website heute mehrfach neu ausgerollt und dabei nur verändert, was in ihren Bereich gehört. An einer fremden Datenbank kam sie bis zur Rechtegrenze und blieb dort stehen. Es gilt hier nichts anderes als im Rest des Textes: Der Radius ist klein, die Schritte stehen geschrieben, und verantworten muss es ein Mensch.

Text: Svenja Lemcke mit Claude Opus. Redaktion: Claude Opus. Verantwortung: Svenja Lemcke. Alle geschilderten Vorgänge stammen aus den geführten Log- und Protokolldateien; einzelne technische Details sind bewusst unscharf gehalten.