Wo landen deine Daten und was darf die KI anfassen? Tool-Access als Grenze.

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.

Sobald es konkret wird und ein AI-Operator echte Arbeit übernehmen soll, kommt zuverlässig diese Frage. Sie ist die letzte Hürde vor einer Entscheidung, und sie ist berechtigt.

Sie enthält allerdings zwei sehr verschiedene Fragen, die fast immer vermischt werden. Die erste lautet: Wo werden meine Daten verarbeitet, und von wem? Die zweite lautet: Was darf dieses System in meinem Unternehmen eigentlich anfassen? Die erste ist eine Anbieterfrage. Die zweite ist eine Konstruktionsfrage, und sie gehört dir.

Die Frage, wo deine Daten liegen, beantwortet dein Anbieter. Die Frage, wie viel Schaden möglich ist, beantwortet deine eigene Architektur.

Die Anbieterfrage: wichtig, aber nicht dein einziger Hebel

Zur ersten Frage gehört Sorgfalt: Wer verarbeitet, auf welcher Rechtsgrundlage, wie lange, und was passiert mit dem, was du hineingibst. Das ist eine Prüfung, die jedes Unternehmen für jeden Dienstleister macht, und für KI-Dienste gelten dieselben Maßstäbe wie sonst auch.

Rocket Routine OS ist an dieser Stelle bewusst provider-agnostisch gebaut. Das Sprachmodell ist die Ausführungsmaschine im System, nicht das Produkt. Welcher Anbieter darunter arbeitet, entscheidet der Mandant, und diese Entscheidung lässt sich wechseln, ohne dass sich die Steuerung darüber ändert. Das ist deshalb relevant, weil es dich unabhängig hält: Deine Governance hängt nicht an den Bedingungen eines einzelnen Anbieters.

Was ich hier bewusst nicht tue, ist dir eine Compliance-Auskunft zu geben. Hosting, Auftragsverarbeitung und die konkrete rechtliche Bewertung sind Fragen, die in einen Vertrag gehören und nicht in einen Blogartikel.

Die eigentliche Frage: was darf das System anfassen?

Die zweite Frage wird seltener gestellt und entscheidet mehr. Denn selbst bei einwandfreier Verarbeitung bleibt das Risiko dasselbe, wenn ein Operator im Unternehmen überall hinkommt.

Genau dafür ist der Role Contract da. Einer seiner acht Pflichtbestandteile ist die Tool-Access-Policy: Lese- und Schreibgrenzen, pro Tool definiert, nach dem Least-Privilege-Prinzip. Nicht "hat Zugriff auf unsere Systeme", sondern pro System und pro Richtung.

Der Unterschied zwischen Lesen und Schreiben ist dabei der wichtigste Schnitt im ganzen Thema. Ein Operator, der eine Quelle lesen darf, kann daraus etwas Falsches ableiten, und das fällt in der Qualitätsprüfung auf. Ein Operator, der schreiben darf, verändert den Zustand deines Unternehmens. Deshalb ist Schreibzugriff die Ausnahme, die begründet wird, und nicht die Voreinstellung.

Lesezugriff erzeugt schlechte Entwürfe. Schreibzugriff erzeugt Tatsachen. Nur eines davon musst du zurückholen können.

Dieses Prinzip ist im System bis in die Rollen hinein durchgezogen. Eine Knowledge Persona etwa hat Lesezugriff auf genau eine zugewiesene Wissensquelle, keinen Schreibzugriff, keine Entscheidungsrechte. Sie spricht, sie entscheidet nicht.

Der häufigste Fehler in der Praxis ist dabei nicht Leichtsinn, sondern Bequemlichkeit. Zugriff auf Kontoebene zu vergeben ist in fünf Minuten erledigt, einen Ausschnitt sauber zuzuschneiden dauert eine halbe Stunde. Also bekommt der Operator das ganze Postfach statt eines Ordners, das ganze Laufwerk statt eines Projekts. Diese halbe Stunde ist die günstigste Versicherung im gesamten Vorhaben, weil sie den Schaden begrenzt, bevor es einen gibt. Und sie muss nur einmal pro Rolle investiert werden.

Zugriff ist eine Stufe, kein Schalter

Auch hier gilt, was für Verantwortung insgesamt gilt: Zugriff wird nicht am ersten Tag vergeben, sondern verdient. Über die Adoption Levels wächst mit der gemessenen Qualität auch der Handlungsraum, und er schrumpft wieder, wenn die Evidenz nachlässt.

Das macht die Zugriffsfrage beantwortbar, ohne dass du sie einmalig und für immer entscheiden musst. Du fängst mit Lesen und Entwerfen an, siehst über mehrere Durchläufe, ob die Qualität den Standard trifft, und erweiterst erst dann. Wer das umgekehrt macht und mit vollem Zugriff startet, hat keine Governance, sondern Glück.

Company 0: der konkrete Zuschnitt

Bei unserem Content-Operator sieht das so aus. Er darf die Wissensbasis und den Redaktionskalender lesen. Er darf Entwürfe schreiben, in zwei Sprachen, jede Woche ein komplettes Set. Er darf nicht veröffentlichen.

Der Schreibzugriff auf das CMS ist technisch erst offen, wenn ein Mensch den Text geprüft und freigegeben hat. Das ist keine Vertrauensfrage, das ist die Konstruktion, und sie ist der Grund, warum ein Fehler in diesem Betrieb einen Absatz kostet und nicht eine öffentlich sichtbare Falschaussage.

Der Zuschnitt ist deshalb interessant, weil er zeigt, wie eng man Zugriff fassen kann, ohne die Rolle nutzlos zu machen. Der Operator produziert eine komplette Wochenproduktion. Er kann trotzdem nichts davon in die Welt bringen.

Was das für dich heißt

Wenn du die Zugriffsfrage für dein Unternehmen klären willst, reicht eine Tabelle mit vier Spalten, und du brauchst dafür niemanden von außen:

• Welches System? Pro Tool eine Zeile, nicht "unsere IT".
• Lesen oder schreiben? Und wenn schreiben, warum reicht lesen nicht?
• Welcher Ausschnitt? Ein Ordner, ein Projekt, ein Kalender, nicht der ganze Account.
• Wer merkt es, wenn etwas Falsches geschrieben wurde, und wie schnell?

Diese vier Spalten sind eine Tool-Access-Policy. Wenn du sie für deine erste Rolle ausfüllen kannst, ist die Frage nach den Daten plötzlich viel kleiner, weil der mögliche Schaden vorher begrenzt wurde. Und wenn du sie nicht ausfüllen kannst, ist das die eigentliche Antwort auf die Frage, ob ihr bereit seid.

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.

Willst du das in deinem Unternehmen aufbauen?

Rocket Routine OS ist das Betriebssystem hinter diesen Artikeln: Rollen, Entscheidungen und Routinen, die auch dann tragen, wenn KI einen Teil der Arbeit übernimmt. Es ist noch nicht öffentlich. Auf der Warteliste bekommst du den Zugang zuerst — und alle zwei Wochen einen ehrlichen Bericht darüber, was funktioniert und was nicht. Auf die Warteliste eintragen