Kontrolle in einer KI-gestützten Organisation

Der erste ist, KI weitreichenden Zugriff zu geben. Ein Agent erhält Zugang zu Ihren Systemen und findet selbst heraus, wie er sein Ziel erreicht. Das beseitigt die Starrheit alter Software, ersetzt aber die Abhängigkeit von Software durch eine Abhängigkeit von KI: Niemand kann mehr sagen, was sie tun durfte oder warum sie getan hat, was sie getan hat.

Der zweite ist, vor alles einen Menschen zu setzen. Jedes Ergebnis wartet darauf, dass jemand auf „Genehmigen“ klickt. Das fühlt sich sicher an, aber wenn ein Agent tausend Routineschritte am Tag erledigt, ist der Mensch nur noch auf dem Papier Teil des Ablaufs. Niemand kann für tausend Klicks wirklich einstehen.

Keiner der beiden Wege gibt Ihnen Kontrolle. Kontrolle entsteht dadurch, dass Sie im Voraus und ausdrücklich festlegen, was KI tun darf, und im Nachhinein sehen können, was sie getan hat.

In CaseFlows ist die Arbeit um Cases herum organisiert, und alle wirken über eine Case-Rolle mit: eine definierte Verantwortung mit den Informationen und Aktionen, die in der Phase, in der sich der Case befindet, dazugehören. Ein KI-Agent in einem Caseflow arbeitet genauso. Er bekommt keinen Zugang zu Ihrer Organisation; er bekommt eine Rolle, in einem Case, zu einem Zeitpunkt.

Es geht hier um Agenten, die in Ihren laufenden Cases Arbeit erledigen. Der Code-Assistent, der Ihre Plattform baut, arbeitet in der Entwicklungsumgebung, nach anderen Regeln; wie es darum steht, lesen Sie unten auf dieser Seite.

Was der Agent außerhalb dieser Rolle anfragt, wird abgelehnt, und die Ablehnung wird festgehalten. Die Grenze ist keine Richtlinie, die der Agent beachten soll. Sie wird von der Plattform durchgesetzt, auf der der Agent läuft.

Harte Grenzen bleiben hart. Was Sie als Regel festlegen, etwa ein Feld, das für eine Rolle verborgen bleibt, oder einen Betrag, ab dem jemand anderes genehmigen muss, wird für Menschen und Agenten gleichermaßen durchgesetzt. Gesetze, Datenschutzvorschriften und Ihre eigenen Befugnisse in diese Regeln zu übersetzen, bleibt Aufgabe Ihrer Organisation; CaseFlows setzt durch, was Sie spezifizieren. Innerhalb dieser Grenzen gibt es Handlungsspielraum, und dieser Spielraum ist sichtbar.

Wir gehen deshalb nicht von „einem Menschen im Ablauf“ aus, sondern von Rechenschaft. Ein Agent darf eigenständig handeln, wenn drei Dinge ausdrücklich festgelegt sind: welche Verantwortung ihm übertragen wurde, innerhalb welcher Grenzen, und wer in Ihrer Organisation dafür einsteht, ihn dort einzusetzen.

Manchmal sollte ein Mensch jedes Ergebnis prüfen: bei einer Entscheidung mit schwerwiegenden Folgen für jemanden oder bei einem Schritt, bei dem sich der Agent oft als falsch erweist. Dann legen Sie diese Prüfung als eigenen Schritt im Caseflow an. An anderer Stelle erledigt der Agent seine Arbeit, und Sie sehen sich an, was er getan hat, nicht jeden Klick.

Für Menschen gilt dasselbe. Eine Fachkraft, die in einer Ausnahmesituation vom üblichen Weg abweicht, tut das besser sichtbar, innerhalb des Systems, als unbemerkt außerhalb davon. Raum für Urteilsvermögen und Rechenschaft gehören zusammen.

Ein Protokoll, das „Benutzer X hat Feld Y geändert“ sagt, erzählt nur einen Teil der Geschichte. Um eine Entscheidung ein Jahr später zu verstehen, müssen Sie wissen, aus welcher Verantwortung heraus sie getroffen wurde. Für jede Aktion hält CaseFlows fest:

• wer gehandelt hat, und aus welcher Case-Rolle, ein Mensch oder ein Agent;
• in welchem Case, und in welcher Phase er sich in diesem Moment befand;
• was sich geändert hat, nicht nur, dass sich etwas geändert hat;
• unter welcher Version des Caseflows der Case lief, sodass Sie ihn nach den damaligen Regeln beurteilen, nicht nach den heutigen;
• was abgelehnt wurde: was jemand versucht hat, das seine Rolle nicht erlaubte.

Bei KI-Aufrufen hält CaseFlows zudem fest, welches Modell geantwortet hat und über wessen Schlüssel der Aufruf lief. Die Spur ist nur ergänzbar: Die Datenbank verweigert Änderungen und Löschungen, und jeder Eintrag ist mit dem vorherigen verkettet, sodass Manipulationen sichtbar würden. Die Ausführung zeigt Ihnen, was geschehen ist; die Spezifikation zeigt Ihnen, innerhalb welcher Vereinbarungen es geschehen ist.

CaseFlows läuft mit den eigenen KI-Schlüsseln Ihrer Organisation, nicht mit unseren. Die Modellnutzung läuft über Ihren Vertrag und zu Ihren Bedingungen, und Sie sehen, was sie kostet.

Sie wählen auch, woher die Intelligenz kommt: von einer großen KI-Plattform, von einem Anbieter, der Modelle in Europa betreibt, oder von einem Modell auf Ihrer eigenen Infrastruktur. CaseFlows verbindet sich mit allen dreien. Das Modell steht hinter einer Verbindung Ihrer Plattform, nicht in Ihren Caseflows, sodass Sie eine Arbeitslast zu einem anderen Anbieter verlagern können, ohne die Arbeit neu zu gestalten.

Sie wählen KI nicht ein einziges Mal. Sie behalten die Möglichkeit, immer wieder neu zu wählen.

KI ist dort am stärksten, wo Ausprobieren wenig kostet: einen Prozess beschreiben, eine erste Version bauen, sie mit Testcases testen. Dort setzt CaseFlows sie so weit wie möglich ein. Eine Fachexpertin oder ein Fachexperte beschreibt die Arbeit einem Coach, und ein Code-Assistent baut sie.

Was in die Produktion geht, ist keine improvisierende KI, sondern eine Spezifikation, die Ihre Prozessverantwortlichen freigegeben haben, ausgeführt so, wie sie geschrieben ist. KI erledigt dort nur dann einen Schritt, wenn Sie ihr einen gegeben haben, in einer Rolle, mit Grenzen. KI in der Entwicklung maximieren. KI in der Produktion minimieren.

Das heißt nicht, dass KI in der Produktion wenig tut. Ein Agent kann dort einen großen Teil der Arbeit übernehmen, solange er das in einer Rolle tut, die Sie definiert haben. Was wir minimieren, ist nicht KI, sondern KI, die improvisiert, wo niemand entschieden hat, dass sie das darf.

Die Spur ist nicht nur für den Fall da, dass etwas schiefgeht. Wenn ein Agent in einer bestimmten Phase oft nicht weiterkommt oder immer wieder um Hilfe bittet, können Sie das sehen. Vielleicht fehlt ihm Kontext, vielleicht ist seine Rolle zu eng gefasst, oder vielleicht ist dies eine Entscheidung, die zu einem Menschen gehört.

Menschen, die mit dem Agenten arbeiten, können das aus dem Case heraus melden, mit ihrem Kontext. Daraus wird ein Vorschlag zur Änderung des Caseflows, der in der Entwicklungsumgebung erprobt wird, bevor sich in der Produktion etwas ändert. So wird Rechenschaft zu einer Quelle der Verbesserung, nicht nur der Kontrolle.

KI wirkt immer häufiger an Entscheidungen mit echten Folgen für Menschen mit: ein abgelehnter Antrag, ein Angebot, eine Auswahl. Zu erklären, was das System getan hat, reicht dann nicht immer aus. Jemand muss das Ergebnis anfechten können.

Dafür muss bekannt sein, wer für die Entscheidung verantwortlich ist, und die Umstände, unter denen sie getroffen wurde, müssen sich rekonstruieren lassen. „Die KI hat entschieden“ ist keine Antwort. Ein Modell kann beraten, ein Agent kann handeln, ein Dienst kann rechnen, aber in CaseFlows bleibt sichtbar, welche Rolle, und damit welche Organisation, dafür einsteht, sie einzusetzen.

Läuft heute

• Agenten und Skills, die einen Schritt in einem Caseflow erledigen, mit dem eigenen KI-Schlüssel Ihrer Organisation.
• Case-Rollen, deren Grenzen der Server pro Phase durchsetzt, wobei Ablehnungen festgehalten werden, auch für Agenten.
• Eine Spur pro Aktion mit der Rolle, dem Case, dem, was sich geändert hat, und der Caseflow-Version, nur ergänzbar und verkettet, sodass Änderungen sichtbar würden.
• Bei KI-Aufrufen: welches Modell geantwortet hat, und über wessen Schlüssel.
• Ihre eigenen Schlüssel und eine Wahl des Anbieters: eine große Plattform, ein Anbieter, der die gängige API spricht, oder ein Modell, das Sie selbst betreiben.

Wohin wir gehen

• Pro Case-Rolle wählen, welches Modell verwendet werden darf, etwa „nur ein Modell auf unserer eigenen Infrastruktur“ für die sensibelste Rolle. Heute wird diese Wahl pro Plattform getroffen.
• Der Code-Assistent, der Ihre Plattform baut, arbeitet unter denselben Rollengrenzen wie Agenten in Ihren Caseflows. Heute arbeitet er noch mit plattformweiten Rechten, in der Entwicklungsumgebung.