Die Reihenfolge entscheidet

Ein Freitagnachmittag, ein Ticket, ein Klick zu viel

Stellen Sie sich die Szene vor, die sich gerade in tausend IT-Abteilungen abspielt: Jemand hat Claude oder ein anderes Sprachmodell an ein MCP-Werkzeug angeschlossen, das Jira lesen kann. Es ist bequem — man tippt eine Frage, das Modell holt sich das Ticket, fasst zusammen, schlägt eine Antwort vor. Niemand hat böse Absichten. Niemand hat auch nur eine Minute darüber nachgedacht, was in diesem Ticket eigentlich steht.

Was drinsteht, ist meistens harmlos. Manchmal aber steht dort der Name eines Kollegen, der krankgeschrieben war. Eine Telefonnummer im Kommentarverlauf. Eine Versichertennummer, die jemand aus Versehen in ein Freitextfeld kopiert hat, statt sie ins dafür vorgesehene System einzutragen. Nichts davon war für ein Sprachmodell gedacht — und trotzdem landet es dort, sobald das Ticket als Text an die API geht.

Die eigentliche Frage lautet nicht, ob das passiert. Es passiert. Die Frage ist: wo greift die Schutzschicht — davor oder danach?

Nachgelagert filtern schützt nichts, das schon weg ist

Die meisten Lösungen, die heute für „KI-Sicherheit" verkauft werden, filtern die Antwort. Das Modell bekommt den vollen Text, verarbeitet ihn, und erst am Ende wird geschaut, ob in der Ausgabe etwas Auffälliges steht, das man noch herausschneiden sollte. Das klingt nach einer Sicherheitsmassnahme. Es ist keine.

Der Grund ist simpel und lässt sich nicht wegargumentieren: Sobald der Text im Modellkontext war, ist er dort gewesen. Bei einem Cloud-Modell heisst das konkret: Die Daten haben das Haus verlassen — sind über die Leitung eines fremden Anbieters gelaufen, möglicherweise geloggt, möglicherweise für ein Training verwendet, je nachdem, was der Vertrag mit dem Anbieter hergibt. Ein Filter, der hinterher etwas aus der sichtbaren Antwort entfernt, ändert daran nichts mehr. Er poliert das Ergebnis, nicht den Vorgang.

Es ist derselbe Fehler wie bei einer Tür, die man erst zusperrt, nachdem der Einbrecher schon drin war und wieder rausgegangen ist. Die Tür ist zu. Genützt hat es nichts.

Deshalb gilt bei JiCo ein einziger, unverhandelbarer Grundsatz: redigiert wird vor dem Modell, nie danach. Namen, Kontaktdaten, Versicherungsnummern und ähnliche Muster werden durch Platzhalter ersetzt, bevor der Text überhaupt das lokale Programm verlässt. Das Modell sieht «Person 1» statt eines Namens — und kann trotzdem sinnvoll arbeiten, weil der Platzhalter konsistent bleibt, solange die Sitzung läuft. Das ist keine Einstellung, die sich bei Bedarf umlegen lässt. Es ist die Reihenfolge, in der die Bausteine zusammengesetzt sind — und eine Reihenfolge lässt sich nicht versehentlich vergessen.

Ein Assistent, der schreiben darf, ist ein Assistent, der etwas falsch machen kann

Der zweite blinde Fleck betrifft nicht das Lesen, sondern das Schreiben. Ein KI-Assistent, der ein Ticket kommentieren, einen Status ändern oder ein Feld setzen darf, spart tatsächlich Zeit — bis zu dem Tag, an dem er es einmal falsch macht. Ein Status, der zu früh auf „erledigt" springt. Ein Kommentar, der eine Vermutung als Fakt formuliert. Ein Feld, das überschrieben wird, weil das Modell eine Anweisung anders verstanden hat, als sie gemeint war.

Das Ärgerliche daran ist nicht einmal der Fehler selbst — Fehler passieren auch Menschen. Das Ärgerliche ist die Frage, die danach niemand beantworten kann: Wer hat das eigentlich entschieden? Ein Werkzeug, das autonom schreibt, hinterlässt keine Entscheidung, nur eine Ausführung.

JiCo dreht das um: jede verändernde Aktion wird angehalten und einem Menschen vorgelegt — das Kommando in Fachsprache, das betroffene Ticket, die konkrete Wirkung, bevor irgendetwas passiert. Und die Regel ist bewusst streng gefasst: Ein Werkzeug, dessen Klassifikation JiCo nicht sicher kennt, gilt als schreibend, nicht als harmlos. Im Zweifel wird angehalten. Diese Haltung — unbekannt heisst schreibend, nicht „wird schon nichts sein" — ist genau die Art von Vorsicht, die in der Softwareentwicklung sonst gerne der Bequemlichkeit geopfert wird.

Die Freigabe von gestern gilt nicht für das Ticket von heute

Der dritte Punkt ist der am leichtesten zu übersehende, und gerade deshalb der wichtigste. Zwischen dem Moment, in dem ein Mensch einen Vorschlag sieht, und dem Moment, in dem er ihn tatsächlich freigibt, vergeht Zeit — Minuten, manchmal Stunden, wenn die Freigabe-Mappe erst am nächsten Morgen durchgesehen wird. In dieser Zeit lebt das Ticket weiter. Ein Kollege kommentiert es. Ein automatischer Workflow ändert ein Feld. Die Grundlage, auf der die Freigabe eigentlich beruhte, existiert in dieser Form nicht mehr.

JiCo prüft deshalb unmittelbar vor der Ausführung noch einmal den tatsächlichen Stand des Objekts. Wurde etwas geändert oder kommentiert, wird nicht ausgeführt — die Aktion wandert mit Begründung auf eine Nachzieh-Liste, zur erneuten Betrachtung. Und die Regel ist absichtlich strenger, als sie sein müsste: Selbst eine Änderung an einem Feld, das mit der eigentlichen Aktion gar nichts zu tun hat, blockiert. Das kostet gelegentlich eine überflüssige Nachfrage. Der Preis dafür ist, dass niemals etwas auf einem Stand ausgeführt wird, den kein Mensch mehr gesehen hat.

Drei Regeln, die erst gemeinsam ihre Wirkung entfalten

Der eigentliche Punkt an diesen drei Prinzipien ist, dass keines davon für sich allein ausreichen würde — sie greifen ineinander, und genau das macht die Kombination robust gegen die Fälle, in denen ein einzelnes Prinzip an seine Grenze stösst. Eine Schwärzung vor dem Modell allein würde nichts nützen, wenn ein Assistent trotzdem frei schreiben dürfte — dann wüsste man zwar, was das Modell gesehen hat, aber nicht mehr, was es danach angerichtet hat. Eine Freigabe-Pflicht allein würde nichts nützen, wenn Namen und Kontaktdaten längst unredigiert im Modellkontext gelandet wären, bevor überhaupt ein Vorschlag entsteht, über den man entscheiden könnte. Und eine Stand-Prüfung allein würde nichts nützen, wenn weder die Daten geschützt noch die Aktion angehalten worden wäre.

Erst zusammen ergeben die drei Regeln eine Kette, die an jeder Stelle hält: Was das Modell sieht, ist bereits geschützt. Was verändert werden soll, wird immer einem Menschen vorgelegt. Und was am Ende tatsächlich ausgeführt wird, beruht garantiert auf dem Stand, den dieser Mensch auch wirklich gesehen hat, nicht auf einem, der zwischenzeitlich schon wieder veraltet ist. Nimmt man eine der drei Regeln weg, bricht nicht nur diese eine Regel — die Wirkung der beiden anderen wird dadurch ebenfalls untergraben, weil sie aufeinander aufbauen, statt unabhängig nebeneinander zu stehen.

Was diese Reihenfolge kostet — und wofür sie sich lohnt

Ehrlichkeit gehört zu diesem Prinzip dazu, nicht nur als Fussnote: Diese Reihenfolge macht die Arbeit langsamer. Ein Assistent, der frei liest und frei schreibt, ist schneller — bis zu dem Tag, an dem jemand fragt, was er eigentlich gesehen hat und was er getan hat, und niemand eine belastbare Antwort geben kann.

Für genau diesen Tag ist JiCo gebaut. Nicht für den reibungslosen Regelfall, sondern für den Moment, in dem eine Revision, ein Datenschutzbeauftragter oder ein Kunde nachfragt — und die Antwort nicht „wir glauben schon" lautet, sondern ein Beleg ist.