Dein erster Role Contract. Acht Bestandteile, ein Nachmittag.

Kurz gesagt: In der Frage nach den Daten stecken zwei Fragen. Wo verarbeitet wird, beantwortet dein Anbieter. Was das System anfassen darf, entscheidest du selbst, pro Tool und getrennt nach Lesen und Schreiben.

Ein Role Contract klingt nach einem Dokument, für das man ein Projekt aufsetzt. Das ist es nicht, und der erste ist in einem Nachmittag geschrieben, vorausgesetzt du fängst an der richtigen Stelle an.

Was ein Role Contract ist und warum er etwas anderes ist als ein guter Prompt, habe ich an anderer Stelle beschrieben. Hier geht es nur darum, wie du deinen ersten schreibst.

Fang nicht bei der KI an

Der häufigste Fehler passiert vor dem ersten Satz. Die meisten setzen sich hin und überlegen, was die KI alles könnte. Damit entsteht eine Wunschliste, kein Contract.

Fang stattdessen bei einer Arbeit an, die es bei dir schon gibt, die regelmäßig anfällt, und bei der du sagen kannst, wie ein gutes Ergebnis aussieht. Wenn du das dritte Kriterium nicht erfüllst, nimm eine andere Arbeit. Eine Aufgabe, für die niemand einen Standard formulieren kann, ist die falsche erste Rolle, egal wie viel Zeit sie frisst.

Der erste Role Contract ist kein Stellenprofil. Er beschreibt eine wiederkehrende Arbeit, für die du "fertig" definieren kannst.

Halte ihn außerdem klein. Eine Routine, nicht ein Bereich. "Wöchentlicher Vertriebsbericht" ist eine erste Rolle. "Vertrieb" ist keine.

Die acht Bestandteile

Ein vollständiger Role Contract hat acht Pflichtbestandteile. Ich gehe sie der Reihe nach durch, mit dem Fehler, der bei jedem am häufigsten passiert.

1. Zweck und Grenzen des Scope. Ein Satz, wofür die Rolle da ist, und dann der wichtigere Teil: wofür ausdrücklich nicht. Der übliche Fehler ist, nur den Zweck zu schreiben. Die Grenze ist die Hälfte, die später Streit vermeidet.

2. Outcomes und Metriken. Wofür steht die Rolle gerade, und woran misst man das. Wenn dir keine Kennzahl einfällt, ist das ein Signal über die Aufgabe, nicht über deine Fantasie.

3. Routinen-Ownership und Standard-Outputs. Welche wiederkehrenden Abläufe gehören dazu, in welchem Takt, und was kommt am Ende konkret heraus. "Ein Bericht" reicht nicht. "Ein Bericht in dieser Struktur, freitags, mit diesen fünf Zahlen" reicht.

4. Entscheidungsrechte, Freigaben, Eskalations-Trigger. Was darf die Rolle allein entscheiden, was braucht eine Freigabe, und was muss zwingend nach oben. Der Fehler ist, das erst im Ernstfall zu klären. Ordne die wiederkehrenden Entscheidungen vorher nach Wirkung ein und schreib mindestens einen konkreten Schwellenwert auf, bei dem der Fall dich erreicht.

5. Tool-Access-Policy. Lese- und Schreibgrenzen, pro Tool, nach dem Least-Privilege-Prinzip. Nicht "Zugriff auf unsere Systeme", sondern pro System und pro Richtung. Schreibzugriff ist die Ausnahme, die du begründest.

6. Pflichten zur Qualitätsbestätigung. Woran wird geprüft, ob das Ergebnis den Standard erfüllt, und welchen Nachweis liefert die Rolle mit. Hier gehört die FTT (First Time Through) hinein, also der Anteil der Ergebnisse, der die Prüfung im ersten Anlauf besteht. Ohne diesen Punkt hast du eine Beschreibung, keine Steuerung.

7. Schnittstellen. Was die Rolle von anderen bekommt und was sie an andere liefert. Der Fehler ist, die Rolle isoliert zu denken. Die meisten Reibungen entstehen an den Übergaben, nicht in der Arbeit selbst.

8. Upgrade-Regeln. Wie der Contract sich ändert, wenn etwas gelernt wurde. Das ist der Bestandteil, den fast alle weglassen, und er entscheidet, ob die Rolle über die Zeit besser wird oder gleich bleibt. Ein Learning zählt erst, wenn es ein Artefakt ändert, und dieser Punkt sagt, welches.

Der erste Entwurf darf kurz sein

Eine Seite reicht. Wenn dein erster Contract länger wird als zwei, hast du fast sicher einen Bereich beschrieben statt einer Routine, und dann geh zurück zum Anfang und schneide ihn kleiner.

Ein häufiger Einwand an dieser Stelle: Woher soll ich wissen, was in Punkt 4 und Punkt 6 realistisch ist, bevor ich es probiert habe? Gar nicht, und das musst du auch nicht. Deshalb startet eine neue Rolle auf der Stufe Shadow: Sie entwirft, Menschen führen aus, und du siehst über ein paar Durchläufe, wo dein Standard zu vage war. Der erste Contract ist eine Hypothese mit Grenzen, kein fertiges Regelwerk.

Schreib ihn so, dass der erste Durchlauf ihn widerlegen kann. Genau dafür sind die Upgrade-Regeln da.

Company 0

Der Role Contract des Content-Marketing-Operators bei uns passt auf eine Seite, und er ist ein brauchbares Beispiel, weil ich alle acht Punkte konkret benennen kann.

Zweck ist die wöchentliche Content-Produktion, ausdrücklich nicht Strategie und nicht Preisaussagen. Die Outcomes hängen an veröffentlichten Artikeln in zwei Sprachen. Die Routinen sind der Wochenablauf mit definierten Outputs, Artikel, LinkedIn-Beiträge, Bildprompt. Entscheidungsrechte enden auf Leaf-Ebene, alles darüber erreicht mich, und ein konkreter Trigger ist jede Aussage, die eine Zusage über Preise, Termine oder Rechtliches enthält. Der Tool-Access ist lesend auf Wissensbasis und Kalender, schreibend auf Entwürfe, und nicht schreibend auf das CMS. Die Qualitätsbestätigung ist eine feste Prüfliste, aktuell dreizehn Edit-Patterns, plus die FTT darüber. Die Schnittstellen sind der SEO-Input rein und die fertigen Assets raus. Und die Upgrade-Regel ist die, die diesen Blog interessant macht: Was im Review auffällt, wird eine neue Regel in der Prüfliste, nicht eine Korrektur an einem einzelnen Text.

Diese letzte Zeile ist der Grund, warum die Liste in vier Monaten von null auf dreizehn gewachsen ist, und warum keine dieser dreizehn Regeln vorsorglich geschrieben wurde.

Was das für dich heißt

Nimm dir einen Nachmittag und eine einzige wiederkehrende Arbeit. Schreib die acht Punkte untereinander und fülle sie in dieser Reihenfolge aus. Wenn du bei Punkt 2 keine Kennzahl findest oder bei Punkt 6 keine Prüfung formulieren kannst, hast du nicht das falsche Format erwischt, sondern die falsche erste Rolle. Nimm eine andere und der Rest geht schnell.

Und lass Punkt 8 nicht weg, auch wenn er sich beim ersten Mal überflüssig anfühlt. Ohne ihn hast du eine Rolle, die genau so gut bleibt, wie du sie an einem Nachmittag hinbekommen hast.

Häufige Fragen

Was ist eine Tool-Access-Policy?

Ein Pflichtbestandteil des Role Contracts: Lese- und Schreibgrenzen, pro Tool definiert, nach dem Least-Privilege-Prinzip. Nicht "hat Zugriff auf unsere Systeme", sondern pro System und pro Richtung festgelegt.

Warum ist der Unterschied zwischen Lese- und Schreibzugriff so wichtig?

Ein Operator mit Lesezugriff kann etwas Falsches ableiten, und das fällt in der Qualitätsprüfung auf. Ein Operator mit Schreibzugriff verändert den Zustand deines Unternehmens. Deshalb ist Schreibzugriff die begründete Ausnahme und nicht die Voreinstellung.

Wo werden meine Daten bei einem AI-Operator verarbeitet?

Das beantwortet der Anbieter, nicht das Betriebssystem. Rocket Routine OS ist bewusst provider-agnostisch gebaut: Welches Sprachmodell darunter arbeitet, entscheidet der Mandant, und die Entscheidung lässt sich wechseln, ohne dass sich die Steuerung darüber ändert.

Wie fange ich mit einer Zugriffsregelung an?

Mit einer Tabelle aus vier Spalten: welches System, lesen oder schreiben, welcher Ausschnitt, und wer es merkt, wenn etwas Falsches geschrieben wurde. Wer sie für die erste Rolle ausfüllen kann, hat eine Tool-Access-Policy.