Vier Konsolen, eine Person

Tiina Rytkönen 25. September 2026 8 Min. Lesezeit

Die meisten Unternehmen nutzen KI inzwischen an mehreren Stellen zugleich. Schwierig ist nicht, sich mit jedem Anbieter zu verbinden. Schwierig ist zu erkennen, dass hinter allen vier Konten dieselbe Person steht, und das wird teurer, je länger man es aufschiebt.

Eine KI zu regeln ist ein gelöstes Problem. Mehrere gleichzeitig zu regeln ist es nicht, und der Grund hat mit keiner von ihnen einzeln viel zu tun.

Eine Zahl bestimmt die Form dieser Arbeit, und sie entscheidet, was wir bauen und in welcher Reihenfolge.

Menlo Ventures hat im November 2025 495 Entscheider für Enterprise-KI gefragt, welche Anbieter sie nutzen. Kein einzelner Anbieter kommt auf mehr als 40%.¹

Diese Grafik ist das ganze Engineering-Problem in einem Bild. Es gibt keinen Anbieter, an den man sich anbindet und dann fertig ist, denn selbst der größte lässt 60% der Unternehmensnutzung woanders. Welche KI Sie heute auch regeln, Sie regeln eine Minderheit Ihres eigenen Bestands.

Die Arbeit ist also nie eine einzelne Integration. Es ist dieselbe Aufgabe, immer wieder, für jeden Anbieter, auf Dauer.

Das klingt nach einem Skalierungsproblem. Ist es nicht. Es ist ein Formproblem, und erst beim zweiten Anbieter haben wir es gesehen.

Wie das aus Sicht des Engineerings aussieht

Als wir mit dem zweiten Anbieter begonnen haben, war der Konnektor nicht der schwierige Teil. Konnektoren sind Arbeit, keine Schwierigkeit.

Schwierig ist, dass jeder Anbieter ein eigenes Governance-System ist. Eine eigene Admin-Konsole. Ein eigenes Audit-Log. Eine eigene Art, Dinge zu benennen, eine eigene Liste von Ereignissen und eine eigene Vorstellung davon, wer oder was als handelnd gilt. Als wir bei einem Anbieter gezählt haben, kamen wir auf 46 Einstellungen auf Organisationsebene, 464 verschiedene Ereignistypen und sechs Arten von Akteuren, also der verschiedenen Dinge, die eine Aktion ausführen können: Personen, Dienstkonten, Agenten und weitere. Sehr wenig davon passt zum nächsten Anbieter. Und alles bewegt sich, wenn der Anbieter seine API ändert.

Ein Team kann das einmal bauen. Die Kosten kommen im zweiten Jahr, und im Jahr danach, für jeden Anbieter, auf Dauer.

Darunter liegt das, was Governance tatsächlich bricht. Derselbe Mitarbeiter ist in jedem System ein eigenes Konto.

So sieht das in der Praxis aus. Jemand fängt im Finanzteam an und bekommt ein Microsoft-365-Konto. Im Laufe des nächsten Jahres taucht diese Person als Nutzerin eines zweiten KI-Werkzeugs aus einem Abteilungspilot auf, als Besitzerin zweier Projekte in einem dritten und als Mitglied eines Arbeitsbereichs, den jemand anderes in einem vierten angelegt hat. Vier Systeme halten nun einen Teil dieser Person. Jedes benennt sie anders. Jedes zeichnet ihr Handeln in einem eigenen Format auf, unter einer eigenen ID, mit einer eigenen Vorstellung davon, was aufzeichnenswert ist. Nichts davon ist ungewöhnlich, und nichts davon ist verbunden.

Vier Konten, vier IDs, vier Audit-Trails, und nichts verbindet sie. Fragen Sie, worauf eine Person über alle KI Ihres Unternehmens zugreifen kann, und kein System kann antworten, weil kein System die ganze Person hält.

Diese Lücke wollen wir schließen. Nicht in die KI hineinsehen. Den Bestand sehen, in dem die KI sitzt.

Der Teil, der jeden Monat teurer wird

Die naheliegende Antwort an dieser Stelle lautet, das sei ein Problem fürs nächste Jahr. Drei Gründe sprechen dagegen, und alle drei sind praktisch, nicht kommerziell.

Das Durcheinander wächst, und niemand räumt es für Sie auf. Wir haben das schon einmal erlebt. Zwischen 2015 und 2020 wuchs die Zusammenarbeit in Microsoft 365 schneller, als irgendeine Governance mithalten konnte. Die Unternehmen, die erst nach dem Wildwuchs mit Governance begonnen haben, haben Jahre damit verbracht, aufzuräumen, was die Unternehmen, die vorher begonnen hatten, nie aufräumen mussten. KI hat dieselbe Form. Sie bewegt sich nur schneller. Jeder Monat ohne Governance bedeutet mehr Konten, mehr Projekte, mehr geteilte Dateien und mehr Berechtigungen, die später von Hand zu sortieren sind.

Audit-Logs sind keine Archive. Dieser Punkt ist spezifisch für KI, und die meisten übersehen ihn. Die Aufbewahrung ist begrenzt, und wie lange sie reicht, hängt vom Anbieter und oft vom Tarif ab. Es lohnt sich also zu prüfen, was Ihre Anbieter tatsächlich aufbewahren. Wie lang das Fenster auch ist, das Prinzip gilt. Schalten Sie Governance in achtzehn Monaten ein, sehen Sie Ihren Bestand so, wie er an diesem Tag ist. Wie er so geworden ist, sehen Sie nicht.

Jede Frage, die ein Security-Team nach einem Vorfall stellt, betrifft die Vergangenheit. Die Vergangenheit, die Sie nicht aufgezeichnet haben, ist weg.

Agenten verändern, wofür Governance da ist. Bis vor Kurzem hat KI Fragen beantwortet. Jetzt handelt sie. Ein Agent hat eine eigene Identität, eigene Berechtigungen und läuft, ohne dass jemand zusieht. Gartner erwartet, dass bis Ende 2026 40% der Business-Anwendungen aufgabenspezifische Agenten integriert haben, gegenüber unter 5% im Jahr 2025.² Sobald KI handelt statt antwortet, ist die Kontrolle darüber, worauf sie zugreifen kann, keine Hausarbeit mehr. Sie entscheidet darüber, was ein unbeaufsichtigtes System tun darf.

Warum sich das nicht innerhalb der Werkzeuge lösen lässt

Jeder Anbieter regelt sich selbst, und die meisten tun das gut. Jeder liefert eine Admin-Konsole, ein Audit-Log, ein Berechtigungsmodell und sinnvolle Kontrollen für das, was er abdeckt.

Keiner regelt übergreifend. Das ist keine Kritik, und es ist keine Lücke, die einer von ihnen schließen wird. Kein Anbieter kann in einen anderen hineinsehen. Keiner hat einen Grund, die Sicht zu bauen, mit der Sie sein eigenes Risiko mit dem eines Wettbewerbers vergleichen könnten. Die Informationen liegen nicht an einem Ort, und nichts im Markt wird sie dorthin bringen.

Die Frage, worauf eine Person über all Ihre KI zugreifen kann, hat also keinen Besitzer. Die Antwort ist nicht schwer zu finden. Es ist nur kein System dafür zuständig, sie zu halten.

Damit bleibt ein Ort, an dem die Antwort leben kann. Eine Schicht über den Werkzeugen, die aus allen liest und keinem gehört.

Die nächste Frage ist, worum diese Schicht gebaut wird, und das entscheidet, ob sie in drei Jahren noch funktioniert.

Abdeckung ist die naheliegende Antwort. So viele Anbieter anbinden wie möglich und für jeden eine Liste zeigen. Das macht sich gut in der Demo. Es löst sehr wenig, denn vier Listen muss immer noch jemand von Hand zusammenführen, und der fünfte Anbieter bringt eine fünfte Liste.

Wir bauen stattdessen um die Person herum. Jedes KI-Konto wird derselben Person in Entra ID zugeordnet, dem Verzeichnis, das die Organisation bereits betreibt. KI-Nutzer, Projekte, Sitzungen, Einstellungen und Kosten liegen dann im selben Inventar, aus dem unsere Kunden bereits Microsoft 365 regeln. Dieselben Richtlinien, dieselbe Automatisierung, dieselben Zugriffsprüfungen.

Identität ist aus einem einfachen Grund die richtige Grundlage. Sie ist der einzige Teil, der sich nicht ändert. Anbieter kommen und gehen. Pilotprojekte enden, Abteilungen wechseln Werkzeuge, Software wird ersetzt. Die Person bleibt, ihre Aufgabe bleibt, und worauf sie zugreifen darf, ist das, wonach das Security-Team fragt. Governance rund um den Anbieter muss jedes Mal neu gebaut werden, wenn sich die Liste der Anbieter ändert. Governance rund um die Person nicht.

Es bedeutet auch, dass sich niemand in eine fünfte Konsole einloggen muss, um das Problem mit vier Konsolen zu lösen. KI wird zu einer weiteren Menge von Objekten in einem Governance-Modell, das das Unternehmen bereits betreibt.

Dieser Ansatz kostet uns Tempo. Er ist langsamer auszuliefern als ein Konnektor, und er funktioniert nur dort, wo es ein Verzeichnis zum Abgleich gibt. Er zahlt sich beim zweiten Anbieter aus und bei jedem weiteren, weil sich das Modell nicht ändert, wenn sich der Anbieter ändert.

Was wir nicht tun werden

Wir werden nicht behaupten, dass wir jede KI regeln können. Es gibt eine Reihenfolge, sie folgt dem, wo die Unternehmensnutzung tatsächlich liegt, und nicht dem, wo wir am liebsten anfangen würden, und wir stellen sie am 1. Oktober vollständig vor.

Das sage ich lieber als etwas Beeindruckenderes. Eine Roadmap, die man prüfen kann, ist mehr wert als eine Behauptung, die bei der ersten technischen Frage zerfällt, und dieses Publikum stellt sie früh.

Was ich schon jetzt sagen kann, ist die Form. Drei Anbieter stehen für rund 80% der Unternehmensnutzung,¹ der größte Teil des Problems ist also erreichbar, ohne den Ozean zum Kochen zu bringen. Und der lange Rest danach braucht nicht jedes Mal einen Neubau, weil Governance rund um Menschen nicht für jeden Anbieter neu erfunden werden muss.

Was wir uns ansehen und was nicht

Noch ein Punkt, weil er die erste Frage in jeder Sicherheitsprüfung ist, die wir durchlaufen.

Rencore regelt, worauf KI zugreifen kann. Wir arbeiten mit Besitz, Berechtigungen, Freigaben und Bezeichnungen: wem etwas gehört, wer darauf zugreifen kann, wo es außerhalb des Unternehmens geteilt wurde und wie es klassifiziert ist. Die Inhalte von Unterhaltungen, Dateien oder Prompts lesen wir dafür nicht.

Das ist eine Designentscheidung, keine Einschränkung, um die wir herumarbeiten. Im Zugriff liegt das Risiko. Ein Agent ist nur so sicher wie die Daten, die er erreichen kann, und um den Zugriff zu steuern, muss man den Inhalt nicht lesen.

Die Multi-KI-Ära: Vision und Roadmap

Webinar, 1. Oktober 2026, 16:00 Uhr MEZ. Matt Einig spricht darüber, wohin Rencore geht und warum. Ich zeige, was heute mehr als eine KI von einem Ort aus regelt, was als Nächstes gebaut wird und in welcher Reihenfolge.

Zum Webinar anmelden

Quellen

Menlo Ventures, “The State of Generative AI in the Enterprise”. Veröffentlicht im November 2025. 495 US-Entscheider für Enterprise-KI, befragt vom 7. bis 25. November 2025. Hier verwendet für: welche KI-Anbieter Unternehmen nutzen. Anthropic 40%, OpenAI 27%, Google 21%, alle anderen 12%.
Gartner-Pressemitteilung, 26. August 2025. “Gartner Predicts 40% of Enterprise Applications Will Feature Task-Specific AI Agents by End of 2026.” Hier verwendet für: 40% der Business-Anwendungen mit integrierten aufgabenspezifischen KI-Agenten bis Ende 2026, gegenüber unter 5% im Jahr 2025.

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organisation and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Häufige Fragen dazu

Warum reicht nicht die Admin-Konsole, die jeder KI-Anbieter mitliefert?

Sie reicht für den Anbieter, den sie abdeckt, und meist ist sie dort gut. Die Grenze liegt darin, dass jede Konsole nur sich selbst sieht. Sie listet ihre eigenen Nutzer, ihre eigenen Projekte und ihre eigenen Audit-Ereignisse unter ihren eigenen IDs, und sie kann nicht wissen, dass das Konto, das sie so nennt, derselbe Mitarbeiter ist, den ein anderer Anbieter anders nennt. Vier Konsolen liefern vier Teilantworten, und jemand muss sie von Hand zusammenführen. Die Frage, die ein Security-Team tatsächlich stellt, nämlich worauf eine Person über alle KI im Unternehmen zugreifen kann, liegt zwischen den Konsolen.

Zeigt Microsoft Entra ID nicht schon, welche KI-Werkzeuge jeder Mitarbeiter nutzt?

Nur für die Werkzeuge, die daran angebunden sind. Meldet sich jemand per Single Sign-on mit dem Arbeitskonto bei einem KI-Dienst an, verzeichnet Entra ID die Anmeldung und die Anwendung, und das lohnt sich zu prüfen. Was Entra ID nicht enthält, ist das, was im Werkzeug passiert: die Projekte dieser Person, die Arbeitsbereiche, in denen sie Mitglied ist, die Einstellungen, die Kosten und die Dateien, die sie dort geteilt hat. Ein Werkzeug, das privat bezahlt oder mit eigenem Login genutzt wird, taucht gar nicht auf. Entra ID ist der richtige Anker für Identität, aber kein Inventar des KI-Bestands.

Wie lange bewahren KI-Anbieter ihre Audit-Logs auf?

Das hängt vom Anbieter und oft vom Tarif ab, deshalb lohnt es sich zu prüfen, was Ihre Anbieter tatsächlich aufbewahren, statt es anzunehmen. Entscheidend ist, dass die Aufbewahrung begrenzt ist. Ein Audit-Log ist ein rollierendes Zeitfenster, kein Archiv, und alles, was älter ist, ist endgültig weg. Wer diese Logs ab heute in einem eigenen Speicher sammelt, behält die Historie ab heute. Wer in achtzehn Monaten beginnt, sieht den KI-Bestand so, wie er an diesem Tag aussieht, und nichts darüber, wie er so geworden ist.

Was bedeutet es, KI rund um die Person statt rund um den Anbieter zu regeln?

Jedes KI-Konto wird einer Identität im Verzeichnis zugeordnet, das die Organisation bereits betreibt. Derselbe Mitarbeiter erscheint dann einmal, mit allem, worauf er zugreifen kann, statt einmal pro Werkzeug. Rencore ordnet die Konten Entra ID zu und führt KI-Nutzer, Projekte, Sitzungen, Einstellungen und Kosten in dasselbe Inventar, aus dem Kunden bereits Microsoft 365 regeln, mit denselben Richtlinien, derselben Automatisierung und denselben Zugriffsprüfungen. Ein neuer Anbieter fügt damit Daten zu einem bestehenden Modell hinzu statt einer fünften Konsole mit eigenen Regeln.

Liest Rencore unsere Prompts, Chats oder Dateien, um KI zu regeln?

Nein. Rencore arbeitet mit Besitz, Berechtigungen, Freigaben und Vertraulichkeitsbezeichnungen: wem etwas gehört, wer darauf zugreifen kann, wo es außerhalb des Unternehmens geteilt wurde und wie es klassifiziert ist. Die Inhalte von Unterhaltungen, Dateien oder Prompts liest Rencore dafür nicht. Das ist eine bewusste Designentscheidung und keine Lücke, denn das Risiko liegt im Zugriff. Ein Agent ist nur so sicher wie die Daten, die er erreichen kann, und um diesen Zugriff zu steuern, muss man den Inhalt nicht lesen.

Zuletzt aktualisiert am 25. September 2026

Über den Autor

Tiina Rytkönen

Tiina ist eine technische Führungskraft, die in dem Raum zwischen dem, „was ist“ und dem, „was sein könnte“, gedeiht. Seit mehr als 20 Jahren führt sie Organisationen durch kritische Transformationen - von der Skalierung von Unternehmensprogrammen in der Telekommunikation über den Aufbau preisgekrönter digitaler Teams bis hin zu ihrer aktuellen Tätigkeit als VP of Product & Engineering bei Rencore Governance. Tiina liebt es, komplexe technische oder organisatorische Herausforderungen anzunehmen und in umsetzbare Strategien zu verwandeln. Ihr Ansatz: Die Kluft zwischen der technischen Realität und der geschäftlichen Vision überbrücken. Die besten Lösungen entstehen aus dem Verständnis sowohl des Codes als auch des Kunden, sowohl des Sprints als auch der Strategie.