Actor Registry: Menschen, AI-Operatoren, Knowledge Personas

Frage einen Geschäftsführer, wer in seinem Unternehmen welche Entscheidung trifft, und du bekommst meistens eine Aufzählung von Personen und ein paar Tools dazu. Frage konkreter, wer eine bestimmte wiederkehrende Entscheidung gestern getroffen hat, und es wird vage. Wer hat den Preis für das letzte Angebot freigegeben? Wer hat den Forecast korrigiert? Wer hat entschieden, dass dieses Lead keines ist? In den meisten Unternehmen ist das nicht sauber dokumentiert. Es ist gefühlt geregelt.

Sobald AI ins Spiel kommt, wird die Frage noch unklarer. Ein AI-Operator hat einen Output produziert, ein Mensch hat freigegeben, eine geteilte Annahme im Hintergrund hat den ganzen Ablauf geprägt. Wer war wirklich verantwortlich?

Ein Unternehmen, das nicht weiß, wer in ihm arbeitet, weiß auch nicht, wo seine Qualität herkommt.

In Rocket Routine OS gibt es dafür einen klaren Mechanismus: das Actor Registry. Es kennt genau drei Arten von Akteuren, und jede hat eine andere Rolle im System.

Die drei Arten von Akteuren

1. Human Actors. Menschen mit Entscheidungsbefugnis, Verantwortung und Urteilsvermögen. Sie tragen alle Entscheidungen, die nicht ausdrücklich an einen AI-Operator delegiert wurden. Sie sind die einzigen Akteure, die im Sinne der Constitution souverän sind.

1. AI Operators. AI-Akteure, die durch einen Role Contract geregelt sind. Sie führen Routinen aus, produzieren standardisierte Outputs, halten sich an explizite Decision Rights, Tool-Access-Policies und Eskalations-Trigger. Sie tragen die Ausführungslast für definierte Routinen, nicht die Entscheidungsverantwortung dahinter.

1. Knowledge Personas. Spezialisierte AI-Akteure mit einem rein beratenden Role Contract. Sie haben Lesezugriff auf zugewiesene Wissensquellen, keinen Schreibzugriff, keine Entscheidungsbefugnis und keine Routinen-Verantwortung. Sie werden ausschließlich vom Decision Moderator angerufen, wenn eine Entscheidung oder strategische Überlegung eine domänenspezifische Perspektive von außen braucht.

Diese drei Kategorien werden in der Actor Registry definiert. Jeder Akteur hat einen Eintrag mit seiner Kategorie, seinem Role Contract und den Domänen, in denen er aktiv ist. Wer nicht in der Registry steht, arbeitet auch nicht im System.

Warum die Unterscheidung den Unterschied macht

Die drei Kategorien sind nicht nur eine Aufzählung, sie sind drei verschiedene Verteilungen von Verantwortung.

Ein Human Actor trägt Entscheidung. Ein AI-Operator trägt Ausführung. Eine Knowledge Persona trägt eine Perspektive, die in eine Entscheidung einfließen kann, aber niemals die Entscheidung selbst ist. Wer diese drei Verantwortungs-Typen nicht trennt, vermischt Beratung mit Ausführung und Ausführung mit Entscheidung. Genau dort entstehen die meisten Verwechslungen, in denen ein AI-Output als "die Entscheidung" behandelt wird, weil niemand mehr nachvollziehen kann, wer eigentlich was beigetragen hat.

Die saubere Trennung in der Registry macht zwei Dinge möglich.

1. Lückenlose Zurückführbarkeit jeder Entscheidung auf einen verantwortlichen Akteur.

1. Klare Stellschrauben für Verbesserung. Ein schlechter Output gehört einem AI-Operator zugeordnet, dessen Role Contract dann nachgeschärft wird. Eine schlechte Entscheidung gehört einem Human Actor zugeordnet, dessen Decision Rights oder Entscheidungsmethode überprüft werden.

Knowledge Personas genauer

Eine Knowledge Persona ist kein zweiter Chatbot und kein "AI-Experte", den man neben dem AI-Operator zu Rate zieht. Sie ist eine architektonisch klar abgegrenzte Konstruktion.

Eine Knowledge Persona besteht aus einem rein lesenden Role Contract, der genau eine Sache definiert, nämlich welche publizierte Wissensquelle die Basis ihrer Perspektive bildet. Das kann das Werk eines spezifischen Autors sein, eine Methode, ein Standard, ein spezielles Wissensdokument. Wichtig ist die Abgrenzung: Eine Knowledge Persona spricht nur aus dem ihr zugewiesenen Korpus. Sie improvisiert nicht. Sie hat keinen Zugang zu operativen Daten des Unternehmens, sie kann nichts schreiben, sie kann nichts auslösen.

Sie wird vom Decision Moderator angerufen, dem Mechanismus, der formal die Entscheidungsmethode für einen offenen Punkt auswählt. Wenn der Decision Moderator feststellt, dass eine Entscheidung eine externe Perspektive braucht, ruft er eine oder mehrere Knowledge Personas auf und bekommt eine synthetisierte Stellungnahme zurück.

Auch ein Human Actor kann jederzeit eine solche Konsultation aktivieren und so zu jedem Thema eine oder mehrere externe Perspektiven bekommen (das können auch durchaus spezifische Rollen wie CFO, CSO, CIO, ... sein).

Eine Knowledge Persona spricht. Sie entscheidet nicht.

Dieses Aufruf-Gate ist nicht bürokratisch, es ist hygienisch. Es verhindert, dass ein Human Actor in einer wichtigen Entscheidung eine beliebige AI-Meinung einholt und sich dann auf "die AI" beruft, obwohl der eigentliche Wissens-Korpus nie geprüft, nie zugewiesen, nie methodisch eingebettet wurde.

Domain Advisory Boards

Mehrere Knowledge Personas in der gleichen Domäne bilden ein Domain Advisory Board. Für die Domäne Produkt kann das ein Board aus drei Personas sein, die jeweils das Werk eines anderen Vordenkers tragen. Für die Domäne Vertrieb kann es ein anderes Board sein.

Wenn der Decision Moderator eine domänenspezifische Frage stellt, bekommt er nicht eine Stimme zurück, sondern eine synthetisierte Sicht aus dem Board. Die Differenzen zwischen den Personas werden explizit gemacht, nicht weggeglättet. Das ist der Punkt: Ein Board zeigt Spannungen zwischen Schulen des Denkens, statt sie zu verstecken.

Company 0

Bei Rocket Routine haben wir mehrere Knowledge Personas in der Registry. Einmal einige bekannte Namen und zum zweiten aber auch verschiedene C-Level-Rollen, die wir in erster Linie bei wichtigen strategischen Entscheidungen verwenden. Sie liefern jeweils eine Stellungnahme aus dem Korpus, der Decision Moderator vermerkt sie als Eingabe, die Entscheidung trifft am Ende ein Human Actor mit Verantwortung für diese Domäne.

Die Knowledge Persona hat keinen Output produziert. Sie hat eine bessere Frage produziert.

Genau das ist ihre Funktion. Nicht entscheiden. Nicht ausführen. Eine Perspektive einbringen, die ein Human Actor sonst übersehen würde.

Was als Nächstes kommt

Das Actor Registry ist die Antwort auf eine simple, oft übersehene Frage, nämlich wer eigentlich in deinem Unternehmen arbeitet. In Rocket Routine OS ist diese Frage nicht mehr gefühlt geregelt. Sie ist explizit beantwortet, pro Akteur, pro Rolle, pro Domäne.

In den kommenden Wochen schaue ich mir an, wie die FTT, Verification und Poka Yoke zusammen den Qualitätsmechanismus bilden, der diese Akteure überhaupt steuerbar macht. Quality Confirmation ist keine Ermessensfrage, sie ist eine strukturelle Voraussetzung.

Wenn du ein gründergeführtes B2B-Unternehmen mit 15 bis 50 Mitarbeitern führst und klare Verantwortlichkeiten zwischen Menschen, AI-Operatoren und externem Wissen willst: rocket-routine.com