Uber hat vorgestern beschrieben, wie sie KI-Agenten an ihre eigenen Systeme lassen (Uber Engineering). Über 800 MCP-Server und mehr als 5.000 einzelne Werkzeuge hängen da inzwischen dran, also Funktionen, die ein Agent aufrufen kann, Fahrt nachschlagen, Daten abfragen und so weiter. Klingt erst mal nach einer Konzerngeschichte, mit der eine Firma mit 30 Leuten nichts zu tun hat. Ein Satz da drin hat mich aber hängen lassen, sinngemäß: Dass ein Werkzeug gefunden wurde, heißt noch nicht, dass es freigegeben ist.
Bei Uber läuft das so. Ein Programm sucht automatisch alle Schnittstellen zusammen, die es im Haus gibt, und baut daraus Werkzeuge für die Agenten, inklusive Beschreibung. Und dann sind die alle aus. Jedes einzelne. Erst wenn das Team, dem der Dienst gehört, draufguckt und zustimmt, wird es eingeschaltet. Ändert sich die Beschreibung, muss das Team wieder zustimmen, und es kann jederzeit auf die alte Fassung zurück.
Bei uns ist es meistens andersrum
Jetzt mal ehrlich, wie läuft das bei den meisten, mich eingeschlossen? Man klickt in Claude oder ChatGPT auf „Google Drive verbinden“, meldet sich an, fertig. Ab da kann der Assistent alles, was das Konto kann. Lesen, anlegen, verschieben, teilen. Bei mir hängen gerade Drive, Mail, Kalender, Notion und Slack dran, und wenn ich ehrlich bin, hab ich beim Verbinden nicht bei jedem einzelnen überlegt, was davon er eigentlich können soll. Es war halt ein Knopf und dann ging es.
Das ist die Reihenfolge, die Uber umgedreht hat. Bei uns ist alles an und man hofft, dass der Agent schon das Richtige macht. Bei denen ist alles aus und jemand muss sagen, warum es an sein soll. Und dieser Jemand ist das Team, das den Dienst kennt. Die IT stellt die Leitung, entscheiden tun die, die wissen, was passiert, wenn da was schiefgeht.
Das find ich den eigentlich spannenden Teil. Uber hätte auch sagen können, wir haben ein zentrales KI-Team, das gibt alles frei. Haben sie nicht. Die Freigabe liegt bei dem, dem das System gehört.
Was das für den Mittelstand heißt
Jetzt braucht natürlich niemand mit drei Konnektoren ein Gateway mit Registry und eigener Steuerungsebene. Das wär ja ein Witz. Aber die Frage dahinter bleibt dieselbe: Wer bei euch entscheidet eigentlich, dass der Assistent ins Buchhaltungsprogramm darf? Und weiß der, was der Assistent da drin alles kann?
Ich wette, in vielen Firmen ist das ungefähr so geregelt: Ulf hat das mal eingerichtet, weil er es ausprobieren wollte. Seitdem hängt das an Ulfs Konto, mit Ulfs Rechten, und Ulf ist Admin. Gemerkt hat das keiner, weil es ja funktioniert.
Und dann gibt es noch die zweite Sache aus dem Uber-Artikel, die oft untergeht. Die haben ihre Dienste nicht umgebaut, damit Agenten damit klarkommen. Die vorhandenen Schnittstellen werden einfach übersetzt, so wie sie sind. Und das ist für den Mittelstand eigentlich die gute Nachricht. Ihr braucht kein neues ERP, damit KI was damit anfangen kann. Ihr braucht eine Stelle, an der festgelegt ist, welche Funktionen davon nach draußen gehen.
So würde ich anfangen
Dauert keinen Nachmittag, wenn man es einmal ehrlich macht:
- Aufschreiben, welche Programme schon mit einem KI-Assistenten verbunden sind. Auch die privaten Versuche von Ulf.
- Pro Verbindung einen Verantwortlichen festlegen. Der, der das Programm im Alltag betreut, nicht der, der es angeklickt hat.
- Mit diesem Menschen durchgehen, was der Assistent darin können muss. Meistens reicht Lesen. Schreiben, Löschen und Teilen nur da, wo es wirklich gebraucht wird.
- Die Verbindung auf ein Konto mit genau diesen Rechten umziehen, weg vom Admin-Konto.
Neue Verbindungen laufen danach genauso, erst aus, dann reden, dann an. Klingt nach Bürokratie, ist aber im Grunde das, was man bei jedem neuen Mitarbeiter auch macht. Der kriegt ja auch nicht am ersten Tag den Generalschlüssel, nur weil er nett gefragt hat.
Wie ist das bei euch, wisst ihr gerade aus dem Kopf, welche Programme an eurem KI-Assistenten hängen und wer die mal verbunden hat?