Governance: wer darf was, und was kostet es

Warum eine KI-Plattform eine eigene Rechteverwaltung braucht

Eine KI-Plattform braucht eine eigene Rechteverwaltung, weil ein Chatfenster ohne Regeln jede Frage an jedes angebundene System weiterreicht. Sobald die KI an ein Firmensystem angeschlossen ist, lautet die Frage nicht mehr, ob jemand chatten darf, sondern welche Datensätze die KI im Auftrag dieser Person lesen darf.

Ein Verbot verlagert die Nutzung nur, es beendet sie nicht

Wer keinen freigegebenen Weg hat, nimmt den nächstbesten. Ein Verbot verlagert die Nutzung in private Konten bei öffentlichen Anbietern, wo weder Vertrag noch Protokoll noch Löschanspruch greift. Firmendaten landen dann in einem Dienst, den niemand in eurer Organisation administriert und dessen Verarbeitung ihr nicht belegen könnt.

Die Gegenmassnahme, die funktioniert, ist ein freigegebener Weg, der besser ist als der private. Er muss aber vier Dinge kontrollierbar machen, sonst verlagert ihr das Risiko nur nach innen:

• Welche Personen die Plattform überhaupt nutzen dürfen, und über welche Anmeldung.
• Welche angebundenen Systeme und welche einzelnen Werkzeuge einer Person offenstehen.
• Was tatsächlich passiert ist, nachweisbar und exportierbar.
• Was der Betrieb kostet, aufgeschlüsselt und begrenzbar, bevor die Rechnung kommt.

Genau diese vier Kontrollpunkte bilden die Bereiche des Admin-Panels von EU-Cowork: Benutzerverwaltung, Zugriffsregeln, Audit und Verbrauch.

Woher Nutzer, Rollen und Gruppen kommen

Nutzer, Rollen und Gruppen pflegt ihr im Admin-Panel oder übernehmt sie aus Entra ID. Eine Rolle bündelt Funktionsrechte, also was jemand in der Oberfläche darf. Eine Gruppe bündelt Personen für Zugriffs- und Budgetregeln. Beides ist unabhängig voneinander kombinierbar.

Lokale Benutzer und Anbindung an Entra ID

Ohne Identitätsanbieter arbeitet EU-Cowork mit lokalen Konten: Einladung per Link, Passwort setzt die eingeladene Person selbst. Die Anmeldung über Entra ID oder einen anderen OIDC-Anbieter wird von der Plattform unterstützt und für eure Instanz eingerichtet. Ist sie eingerichtet, meldet sich jede Person über OIDC an, das Konto entsteht bei der ersten Anmeldung, und die Gruppen- und Rollenangaben aus dem Anmelde-Token werden auf eure Gruppen in EU-Cowork abgebildet.

Der Entzug läuft damit an der Haustür: Wer in Entra ID deaktiviert ist, kommt nicht mehr hinein und verliert damit jeden Zugriff, auch auf die angebundenen Systeme. Automatisches Vorbereitstellen und Abschalten von Konten über SCIM ist geplant, heute noch nicht verfügbar.

Was eine Rolle festlegt, was eine Gruppe

Eine Rolle steuert Funktionsrechte in der Plattform, etwa ob jemand Agenten bauen, die Websuche nutzen oder das Admin-Panel öffnen darf. Eine Gruppe steuert, an welche Daten und Werkzeuge jemand kommt und auf welches Budget der Verbrauch läuft.

Einladung, Zuweisung, Deaktivierung

Eine Einladung geht per Mail oder Link hinaus und kann die Zielgruppe bereits mitgeben. Die Mitgliedschaft wird gesetzt, sobald die eingeladene Person die Registrierung abgeschlossen hat. Damit startet niemand in einem rechtelosen Zwischenzustand, und ihr müsst nach jeder Registrierung nichts nachtragen.

Zum Beenden gibt es zwei Wege. Sperren lässt das Konto bestehen, verweigert aber die Anmeldung. Löschen entfernt Konto, Unterhaltungen und Suchindex-Einträge; ein Datenexport für die betroffene Person ist vorher möglich, damit Auskunfts- und Löschbegehren beide bedient sind.

Rechte bis auf Werkzeugebene

Tool-Aufrufe laufen über das MCP-Gateway, ein Bauteil zwischen Chat und angebundenem System. Das Gateway prüft für die anfragende Person, ob der Server und das konkrete Werkzeug erlaubt sind, hält die Entscheidung fest und reicht den Aufruf nur bei einer Freigabe weiter. Gesperrte Werkzeuge erscheinen nicht in der Werkzeugliste des Nutzers; nach einer Rechteänderung wirkt das mit kurzer Verzögerung. Der eigentliche Riegel ist die Prüfung bei jedem Aufruf.

Angebunden werden Systeme über MCP, den offenen Standard für Werkzeugzugriffe von KI-Modellen. Das Gateway sitzt davor, damit die Freigabe zentral pro Person, Rolle und Gruppe entschieden wird und nicht im angebundenen System verstreut liegt. Welche Systeme sich anbinden lassen und welche vorbereitet sind, steht auf der Seite Integrationen; Rechte ohne Werkzeuge sind gegenstandslos.

Das Beispiel: Rechnungen lesen ja, Löhne lesen nein

Ein angebundenes ERP bietet der KI nicht einen einzigen Zugang, sondern viele einzelne Werkzeuge: Rechnungen suchen, Kundendaten lesen, Lohndaten lesen, Datensätze schreiben. Die Gruppe Buchhaltung bekommt die Rechnungs-Werkzeuge freigegeben, die Lohn-Werkzeuge bleiben der Personalabteilung vorbehalten. Gleicher Server, unterschiedliche Werkzeuge, getrennt entschieden.

Darunter liegt eine zweite Grenze. Meldet sich EU-Cowork mit der Identität der jeweiligen Person an eurem ERP an, bleiben dessen eigene Zugriffsregeln massgeblich: Wer dort nur bestimmte Datensätze sehen darf, sieht auch über die KI nicht mehr. Läuft die Anbindung über ein gemeinsames Dienstkonto, ist das Gateway die einzige Durchsetzungsstelle, und dann gehört die Werkzeugauswahl entsprechend eng geschnitten.

Rechte innerhalb eines Werkzeugs, also auf einzelne Felder oder Zeilen, setzt EU-Cowork nicht selbst durch. Dafür ist die Rechteverwaltung des angebundenen Systems zuständig. Ein Werkzeug mit weit gefasstem Funktionsumfang gebt ihr deshalb entweder gar nicht frei oder nur an eine Gruppe, die die Daten ohnehin sehen darf.

Die Regelkette: Nutzer vor Rolle vor Gruppe vor Standard

Rechte werden in einer festen Reihenfolge ausgewertet: einzelner Nutzer, dann Rolle, dann Gruppe, dann Voreinstellung des Servers. Die erste passende Regel entscheidet, danach wird nicht weitergesucht. Damit ist jede Entscheidung erklärbar, und eine Einzelfreigabe braucht keine Sonderrolle. Dass Rechte pro einzelnem Werkzeug gelten, ist im Vergleich mit anderen Plattformen das Unterscheidungsmerkmal.

Was passiert, wenn keine Regel greift

Greift keine Nutzer-, Rollen- oder Gruppenregel, entscheidet die Voreinstellung des jeweiligen Servers. Setzt diese Voreinstellung direkt nach dem Anbinden eines Systems auf verweigern und gebt danach gezielt einzelne Gruppen frei. So kann ein frisch angebundenes System niemanden versehentlich mehr sehen lassen, als vorgesehen war.

Fällt die Rechteprüfung selbst aus, etwa weil die Regeldatenbank nicht erreichbar ist, verweigert das Gateway den Aufruf, statt ihn durchzulassen. Eine Störung führt also zu einer Fehlermeldung im Chat, nicht zu einem offenen Zugriff. Ein Nur-Lesen-Schalter pro Server, der schreibende Werkzeuge pauschal sperrt, ist geplant.

Audit: jeder Zugriff nachvollziehbar

Jeder Tool-Aufruf über das Gateway wird mit Zeitpunkt, Person, Zielsystem, Werkzeug und Entscheidung festgehalten, auch der verweigerte. Zusätzlich führt die Plattform ein fortlaufend verkettetes Protokoll über Admin-Aktionen, Anmeldungen und Rechteänderungen. Beide Protokolle liegen in eurer eigenen Instanz und lassen sich als CSV exportieren.

Was protokolliert wird

• Tool-Aufrufe an angebundene Systeme, mit der getroffenen Entscheidung, erlaubt oder verweigert.
• Anmeldungen an der Plattform und am Admin-Panel.
• Änderungen an Rollen, Gruppen, Rechten und Zugriffsregeln.
• Änderungen an der Konfiguration der Instanz.
• Anlegen, Einladen, Sperren und Löschen von Konten.

Das Audit-Log ist ein Zugriffsnachweis, kein Gesprächsmitschnitt. Es beantwortet, wer wann welches Werkzeug an welchem System aufgerufen hat. Die Unterhaltungen selbst liegen getrennt davon in der Datenbank eurer Instanz und unterliegen der eingestellten Aufbewahrungsdauer.

Wie lange und wohin exportierbar

Die Protokolle bleiben in eurer Instanz, in eurer Datenbank. Beim Selbstbetrieb verlassen sie eure Infrastruktur nicht. Der Export läuft als CSV, gefiltert nach Zeitraum und Person, und ist damit direkt an eine Revision, an die Rechtsabteilung oder an ein Auditwerkzeug übergebbar.

Das Protokoll über Admin-Aktionen ist verkettet: Jeder Eintrag trägt eine Prüfsumme über den vorhergehenden, und eine eingebaute Prüfung meldet, wenn die Kette nicht mehr aufgeht. Nachträgliches Herausschneiden einzelner Einträge fällt damit auf. Für Unterhaltungen ist die Aufbewahrungsdauer einstellbar; abgelaufene Inhalte werden samt Suchindex entfernt.

Kosten sichtbar machen und begrenzen

Der Verbrauch wird pro Person, Gruppe, Modell und Tag erfasst und sowohl in Token als auch in Euro ausgewiesen. Ein gemeinsames Monatsbudget begrenzt die Summe für die ganze Organisation, ein optionales Monatslimit pro Person begrenzt einzelne Konten. Ist ein Budget erschöpft, greift eine weiche Sperre (Soft-Block).

Verbrauch pro Person, Gruppe und Modell

Das Admin-Panel zeigt den Verbrauch in Euro, aufgeschlüsselt nach Person, nach Modell und nach Tag, dazu die einzelnen Anfragen mit Modell und Zeitpunkt. Beträge und Aufschlüsselung sieht die Administration; Endnutzer bekommen im Chat nur einen Hinweis, wenn das Budget erschöpft ist. Das nimmt den Kostendruck aus dem Arbeitsalltag und lässt die Zahlen trotzdem dort sichtbar sein, wo sie hingehören.

Die Preise werden pro Modell hinterlegt, damit die Auswertung nicht auf einem Näherungswert beruht. Das ist wichtiger, als es klingt: Zwischen einem sparsamen und einem sehr grossen Modell liegt beim gleichen Gesprächsverlauf ein Vielfaches an Kosten. Eine kuratierte Modellauswahl ist deshalb Teil der Kostenkontrolle, nicht nur eine Frage der Bedienbarkeit.

Gemeinsames Monatsbudget statt Einzellimits

Das Monatsbudget gilt für die Organisation als Ganzes, nicht pro Kopf. Der Grund ist praktisch: Verbrauch verteilt sich nie gleichmässig. Wer die Plattform intensiv nutzt, würde an einem starren Einzellimit hängen bleiben, während bei anderen Kontingent verfällt. Ein gemeinsamer Topf gleicht das aus, ohne dass jemand Limits nachjustieren muss.

Für Ausreisser gibt es zusätzlich ein optionales Monatslimit pro Person. Es ist ausgeschaltet, solange ihr es nicht setzt, und wird im selben Abgleich hart durchgesetzt wie das Gesamtbudget. Typischer Einsatz: ein einzelnes Konto, das automatisiert Anfragen stellt, soll den gemeinsamen Topf nicht allein leeren.

Weiche Sperre statt stiller Überschreitung

Ist das Budget aufgebraucht, greift die weiche Sperre: Die nächste Anfrage wird abgelehnt, mit einem Hinweis im Chat statt einer stillen Weiterbuchung. Eine laufende Antwort wird noch zu Ende geführt. Der Admin kann das Budget jederzeit anheben, danach läuft der Betrieb sofort weiter. Ohne diese Anhebung entsteht keine Nachzahlung.

Der Abgleich zwischen erfasstem Verbrauch und Budget läuft im Minutentakt, und die Vorabschätzung einer Anfrage kennt deren Länge nicht exakt. Eine einzelne Antwort kann deshalb noch knapp über die Grenze laufen. Es handelt sich um eine weiche Sperre, die eine Kostenexplosion verhindert, nicht um eine sekundengenaue Vorabreservierung.

Agenten freigeben statt verbieten

Agenten und Skills werden kuratiert freigegeben, nicht pauschal erlaubt und nicht pauschal verboten. Normale Konten nutzen die ihnen zugewiesenen Agenten und sehen den Agenten-Baukasten gar nicht. Eine privilegierte Rolle erstellt und teilt Agenten, und Skills gibt der Admin pro Person frei.

Der Grund liegt in den Rechten: Ein Agent bringt eine feste Anleitung und einen Satz Werkzeuge mit. Dürfte jeder eigene Agenten bauen und teilen, entstünde neben eurer Rechtekette eine zweite, unkontrollierte Verteilungsschiene. Die Rechteprüfung am Gateway greift zwar weiterhin bei jedem Aufruf, aber die Übersicht, wer womit arbeitet, ginge verloren.

In der Praxis ergibt das wenige, gepflegte Agenten pro Gruppe statt vieler halbfertiger: einen für die Angebotserstellung, einen für Auswertungen aus dem ERP, einen für die interne Wissenssuche.

Häufige Fragen