Modern Workplace hiess gut zehn Jahre lang: verwaltetes Gerät, saubere Identität, Daten in der Cloud. Genau darüber habe ich die meisten meiner Beiträge geschrieben. Jetzt kommt eine vierte Schicht dazu, und sie verändert die anderen drei. Jetzt gehen wir darauf ein, wie ein Arbeitsplatz mit AI-Agenten aussieht, was das für die IT bedeutet und in welcher Reihenfolge ich dorthin laufen würde.
Wichtig zu verstehen: die Reihenfolge. Die Agenten-Schicht steht nicht neben dem Modern Workplace, sie steht darüber. Ohne Entra ID, Conditional Access und Geräte-Compliance kannst du Agenten nicht kontrolliert betreiben. Du musst vorher die Frage «Wer darf was?» beantworten haben. Die gute Nachricht ist, wer seinen Endpoint-Stack im Griff hat, hat die halbe Vorarbeit erledigt.
Damit das nicht abstrakt bleibt, ein Tag, wie ich ihn bei Kunden bereits in Teilen sehe:
07.30 Uhr | Über Nacht hat ein Workflow-Agent die neuen Tickets vorsortiert, Dubletten zusammengeführt und bei sechs Fällen eine Antwort vorbereitet. Vier davon wurden automatisch geschlossen, zwei liegen zur Freigabe.
08.15 Uhr | Ein Recherche-Agent hat zu einer Ausschreibung die Unterlagen gezogen, gegen frühere Angebote geprüft und eine Lücke markiert: eine Zertifizierung fehlt. Diese Ausnahme ist eskaliert, weil sie eskalieren sollte.
10.00 Uhr | Ein neuer Kollege fängt an. Der Onboarding-Agent hat Gerät, Gruppen, Lizenzen und die ersten Aufgaben vorbereitet. Die IT prüft eine Zusammenfassung statt sieben Portale.
14.00 Uhr | Im Kundengespräch fragt jemand nach Zahlen aus drei Systemen. Der Agent in Microsoft Teams-Fenster beantwortet es mit Quellenangabe – nicht, weil er alles weiss, sondern weil er Zugriff auf die richtigen Werkzeuge hat.
17.00 Uhr | Der Report-Agent legt den Wochenbericht ab. Niemand baut ihn noch von Hand.
Nichts davon ist Science-Fiction, und nichts davon ist ohne Aufsicht. Genau so sieht mein Arbeitsalltag heute aus.
Für Endpoint- und Identity-Teams ist das eine gute Nachricht, weil die Denkmodelle dieselben bleiben. Ein Agent ist aus IT-Sicht ein neuer Typ von Konto mit sehr merkwürdigen Eigenschaften: Er arbeitet nachts, hat kein Gerät und kann in Sekunden sehr viel tun.
Lebenszyklus: Agenten brauchen Anlegen, Ändern und Löschen wie Nutzerkonten. Ein Agent, dessen Fachbereich das Projekt beendet hat, muss abgeschaltet werden, sonst hast du in einem Jahr Karteileichen mit Rechten.
Least Privilege: Ein Werkzeug pro Aufgabe, nicht ein Sammel-Set «für alle Fälle».
Werkzeug-Freigaben: Welche Integrationen, Kommandos und Browser-Ziele sind überhaupt erlaubt? Das ist die neue Variante von «Welche Apps dürfen ins Firmennetz».
Nachweis: Jeder Werkzeugaufruf protokolliert, jede Freigabe nachvollziehbar. Ohne das wird die erste Datenschutzfrage unangenehm.
Kosten: Verbrauch pro Agent sichtbar machen und begrenzen. Agenten haben keine Kostenstelle im Kopf.
Hinweis: Die praktische Reihenfolge ist fast immer gleich, erst Inventar, dann Identität, dann Rechte und letztlich Use Cases. Ich habe noch kein Projekt gesehen, in dem sich die umgekehrte Reihenfolge nicht später gerächt hat.
Weil das mein Kernthema ist, ein eigener Abschnitt dazu: Das Gerät verschwindet nicht, es verliert nur seine Sonderstellung. Zehn Jahre lang war der Endpoint der Ort, an dem Arbeit passiert. Künftig ist er einer von mehreren Orten neben Agenten, die ohne Gerät und ohne angemeldeten Nutzer arbeiten. Praktisch ändert das drei Dinge im Endpoint-Management:
Compliance wird zur Eintrittskarte, nicht zum Ziel: Ein AI-Agent, der im Namen eines Nutzers auf Unternehmensdaten zugreift, muss an dieselben Bedingungen gebunden sein, wie das Gerät dieses Nutzers. Wer Conditional Access sauber hat, kann das ausdehnen. Wer nicht, hat jetzt zwei Baustellen.
Troubleshooting verschiebt sich: Ein Teil der Fehler ist künftig kein Gerätefehler, sondern ein Werkzeugfehler: fehlende Berechtigung, eine Integration, die nicht antwortet. Dafür brauchst du Logs auf Agenten-Ebene, nicht nur auf Geräteebene.
Das Inventar wird grösser: Zum Gerätebestand kommt ein Agentenbestand. Beide brauchen Besitzer, Lebenszyklus und Nachweise. Die Denkweise ist identisch, und genau deshalb sind Endpoint-Leute für diese Aufgabe gut vorbereitet.
Hinweis: Behandle AI-Agenten in der Betriebsführung wie Dienstkonten mit Sprachverständnis: Besitzer, Zweck, Ablaufdatum, Rechteumfang, Protokoll. Diese fünf Felder pro Agent lösen die meisten Diskussionen, bevor sie entstehen.
Der Ort, an dem Agenten heute am produktivsten sind, ist kein Chatfenster. Es ist das Terminal. Das klingt nach einem Rückschritt, ist aber das Gegenteil: In der Kommandozeile hat ein AI-Agent Zugriff auf das Repository, auf Skripte, auf Logs, auf Tests – auf all das, was eine Aufgabe wirklich ausmacht. Dass das nicht nur ein Entwickler-Hobby ist, zeigt eine Untersuchung von Microsoft selbst. Microsoft hat Anfang 2026 zwei Kommandozeilen-Agenten für die eigene Entwicklungsmannschaft freigegeben und die Einführung über zehntausende Ingenieure hinweg ausgewertet. Drei Befunde daraus finde ich für die Planung relevant:
Etwa 24% mehr gemergte Pull Requests bei den Nutzern gegenüber dem, was ohne das Werkzeug zu erwarten gewesen wäre.
Die Verbreitung lief über soziale Netze im Unternehmen, nicht über Anordnungen. Und ob jemand dabeiblieb, hing an der eigenen Arbeitsweise, nicht an Rolle oder Erfahrung.
Für die Einführung heisst das etwas Unbequemes: Ein Rollout per Anweisung funktioniert schlechter als ein Rollout über die Leute, die es freiwillig benutzen und weitererzählen. Suche also die vier oder fünf Kollegen, die es ohnehin ausprobieren, gib ihnen Zeit und mache es dem Rest leicht, mitzumachen.
Wichtig ist der zweite Teil des Bildes. Ein Kommandozeilen-Agent kann auch ohne Menschen laufen – gestartet von einem Zeitplan, einem Ticket oder einem Commit, ohne Prompt, mit einem festen Auftrag. Das ist die Betriebsart, in der aus einem Werkzeug ein Kollege wird: Der nächtliche Lauf, der Abhängigkeiten aktualisiert und einen Pull Request hinterlässt. Der Agent, der jeden Montag die Compliance-Abweichungen zusammenstellt.
Und genau hier kippt die Frage von Produktivität zu Sicherheit. Interaktiv schaut ein Mensch zu und greift ein. Headless nicht. Deshalb gehört zu jedem headless laufenden Agenten dasselbe Paket: eigene Identität, engstes Rechteset, Protokoll, Zeit- und Kostenlimit und eine Sandbox.
Ein AI-Agent, der Code ausführt, Dateien schreibt oder Kommandos startet, ist aus Sicherheitssicht etwas grundsätzlich Neues: ein Prozess, dessen nächste Aktion niemand vorher kennt – auch der Hersteller nicht. Der Grundfehler, den ich am häufigsten sehe, ist, ihn einfach mit den Rechten des angemeldeten Nutzers laufen zu lassen. Damit erbt er alles, was diese Person darf: Netzlaufwerke, gespeicherte Zugangsdaten, Datenbankverbindungen. Der Fachbegriff dafür ist «ambient authority», und sie ist die eigentliche Ursache der meisten Agentenvorfälle.
Die Stufen im Bild sind eine Entscheidung nach Vertrauen, nicht nach Budget:
Container: schnell und für die meisten Fälle ausreichend, solange der Agent nur euren eigenen Code ausführt. Der Kernel wird mit dem Host geteilt. Dieser Kompromiss ist bewusst zu treffen, nicht zu übersehen.
Syscall-Filterung (etwa gVisor): Container-Geschwindigkeit, aber die Systemaufrufe laufen durch eine Zwischenschicht. Für mich der pragmatische Mittelweg.
MicroVM: eigener Kernel pro Lauf, minimal langsamer im Start. Die richtige Wahl, sobald der Agent Code ausführt, den weder du noch der Nutzer geschrieben hat. Also bei allem, was aus dem Internet, aus Kundendaten oder aus einem Ticket kommt.
Zur Isolation gehören vier Dinge, die man gern vergisst: eine Allowlist statt offener Netzwerkzugriff, explizit freigegebene Werkzeuge statt «alles was da ist», Secrets ausserhalb der Box (die Umgebung des Agenten sieht nur einen Platzhalter, der echte Schlüssel wird erst beim ausgehenden Aufruf eingesetzt) und ein Protokoll jedes Werkzeugaufrufs.
Wichtig: Eine Sandbox verhindert keine Prompt Injection. Sie verhindert, dass eine erfolgreiche Injection grossen Schaden anrichtet. Wer die Sandbox als Schutz vor Manipulation verkauft, wird enttäuscht. Wer sie als Schadensbegrenzung einsetzt, liegt richtig. Beides braucht zusätzlich Prüfung der Eingaben, Werkzeug-Allowlists und Auswertung der Ausgaben.
Und ein Satz, den ich mir angewöhnt habe: Wenn du nicht erklären kannst, was der AI-Agent im schlimmsten Fall anrichten könnte, ist er noch nicht produktionsreif. Nicht weil ein Fehler wahrscheinlich ist, sondern weil die Antwort auf diese Frage die Sandbox-Stufe bestimmt.
Der Service Desk ist bei mir fast immer der erste Bereich, in dem AI-Agenten wirklich etwas bewegen und der ehrlichste Prüfstein. Was ich dort beobachte:
Die spannendste Kennzahl aus dem Work Trend Index ist für mich die Human-Agent-Ratio: das Verhältnis von menschlicher Aufsicht zu Agenten-Effizienz. Sie ist nicht global festlegbar, sie ist aufgabenabhängig. Bei Recherche darf sie hoch sein, bei allem mit Aussenwirkung oder Geldfluss muss sie niedrig bleiben. Meine Faustregel: Je grösser der Schaden bei einem Fehler, desto engmaschiger die Aufsicht. Unabhängig davon, wie gut das Modell gerade ist. Für die Menschen bedeutet das drei neue Fähigkeiten, und keine davon ist Prompt-Engineering:
Aufträge schreiben: ein Ziel so formulieren, dass Erfolg prüfbar ist. Wer gute Tickets schreiben kann, kann das schon.
Ergebnisse prüfen: stichprobenartig, systematisch und mit dem Wissen, wo dieser Agent typischerweise falsch liegt.
Eskalation definieren: vorher festlegen, was der Agent nie allein entscheidet. Das ist Führungsarbeit, nicht Technik.
Interessant fand ich einen Nebenbefund des Berichts: Die fortgeschrittensten Nutzergruppen halten bewusst inne und entscheiden, ob eine Aufgabe mit oder ohne KI besser läuft. Und erledigen aufgrunddessen manche Aufgaben absichtlich ohne KI, um die eigene Fähigkeit zu erhalten. Das halte ich für eine sehr erwachsene Haltung.
Schatten-Agenten: Fachbereiche bauen sich AI-Agenten im Store zusammen, niemand hat den Überblick. Deshalb steht Inventar an Position eins.
Agent-Sprawl: vierzig AI-Agenten, von denen sechs genutzt werden. Ohne Nutzungsdaten fällt das monatelang nicht auf.
Nichts gemessen: «Die Leute finden es gut.» überlebt keine Budgetrunde. Zeit pro Fall, Fehlerquote und Durchlaufzeit vorher festlegen.
Schlechte Prozesse automatisiert: wenn der Ablauf schon vorher unklar war, macht ein Agent ihn schneller unklar.
Kosten aus dem Ruder: der teuerste AI-Agent ist der, der stündlich läuft und dessen Ergebnis niemand liest.
In Monat 1–2 baust du zunächst ein vollständiges Agenten-Inventar auf, schaltest die Kontrollschicht ein und legst Datenklassen sowie Verbotszonen fest. Erfolg bedeutet hier, dass du jederzeit sagen kannst, welche AI-Agenten existieren und wer für sie verantwortlich ist.
In Monat 3–4 gehen genau zwei Anwendungsfälle produktiv. Jeder erhält eine eigene Agenten-Identität und definierte Messpunkte. Du erkennst den Erfolg an einem messbaren Zeitgewinn und daran, dass keine Sicherheitsfunde auftreten.
In Monat 5–8 wird aus dem Pilot eine Plattform. Dafür etablierst du Freigabewege und Zeitpläne, machst die Kosten pro Agent sichtbar und regelst die Betriebsübergabe. Das Ziel: Die AI-Agenten laufen zuverlässig ohne dein ständiges Zutun und du kannst jederzeit nachvollziehen, was jeder Agent kostet.
In Monat 9–12 geht es schliesslich um die Organisation selbst. Verantwortlichkeiten werden neu verteilt und eine klare Agent-Boss-Verantwortung wird benannt. Mitarbeitende werden geschult und Prozesse neu geschnitten. Der eigentliche Erfolg zeigt sich daran, dass Prozesse am Ende schneller und anders aussehen als vorher.
Weiss ich, welche AI-Agenten in meinem Tenant laufen? → Inventar aufbauen, bevor du irgendetwas baust.
Hat jeder AI-Agent eine eigene Identität? → Rechtemodell korrigieren, dann weiter.
Ist Gerätecompliance und Conditional Access sauber? → Erst den Modern-Workplace-Unterbau fertigmachen.
Gibt es für jeden AI-Agenten einen fachlichen Verantwortlichen? → Keinen Agenten ohne Besitzer produktiv setzen.
Kann ich Nutzung und Kosten pro Agent sehen? → Messung nachrüsten, sonst fliegt dir das Budget weg.
Weiss der Fachbereich, was der AI-Agent nie allein tun darf? → Eskalationsregeln schriftlich festhalten.
Ich schreibe sonst nicht viel darüber, was ich für übertrieben halte, aber bei diesem Thema gehört es dazu:
Ich glaube nicht, dass AI-Agenten in den nächsten Jahren komplexe Entscheidungen mit Aussenwirkung allein treffen. Nicht, weil sie es technisch nicht könnten, sondern weil niemand die Haftung übernehmen will und das ist vernünftig.
Ich glaube nicht an die Zahl «X% Produktivitätsgewinn» aus Herstellerfolien. In den Projekten, die ich messe, kommt gemessener Nutzen heraus, aber selten der Wert aus der Folie.
Ich glaube nicht, dass Prompt-Schulungen der Hebel sind. Der Hebel ist, Arbeit anders zu schneiden. Dafür sprechen auch die Zahlen aus dem Microsoft Work Trend Index 2026, wo organisatorische Faktoren die Wirkung deutlich stärker erklären als individuelle.
Und ich glaube nicht, dass es reicht, das Thema in der IT zu halten. Ein AI-Agent, der einen Fachprozess übernimmt, braucht einen Besitzer im Fachbereich. Sonst wird die IT für Ergebnisse verantwortlich, die sie fachlich nicht beurteilen kann.
Es kommt eine vierte Schicht dazu. Identität, Gerät und Daten bleiben die Grundlage. Darüber sitzt künftig eine Agenten-Schicht, und darunter braucht es eine Kontroll- und Nachweisebene. Wer seinen Endpoint-Stack im Griff hat, hat die halbe Vorarbeit erledigt.
Ja. Ein Agent, der handelt, darf nicht mit dem Konto der Person laufen, die ihn gestartet hat, sonst kannst du hinterher nicht sagen, wer etwas getan hat, und er erbt alle Rechte dieser Person. Microsoft hat dafür Entra Agent ID eingeführt, Agent 365 nutzt genau das als Grundlage.
Eine Sandbox ist eine abgeschottete Umgebung, in der AI-Agenten arbeiten. Sie verhindert keine Manipulation durch Prompt Injection, aber sie begrenzt den Schaden. Für eigenen Code reicht meist ein Container, für fremden Code gehört eine stärkere Isolation dazu.
In vier Phasen: erst Inventar und Regeln, dann genau zwei gemessene Anwendungsfälle, dann der Schritt von Pilot zu Plattform mit Freigabewegen und Kostentransparenz, und im letzten Drittel der Umbau der Rollen. Die häufigste Ursache für gescheiterte Projekte ist die umgekehrte Reihenfolge.
Nach unserer Erfahrung nicht. Was schrumpft, ist der Anteil an Suchen, Übertragen, Zusammenstellen und Nachfragen. Was bleibt, ist mehr Entscheiden und mehr Verantwortung pro Person. Und eine neue Rolle, die diese AI-Agenten führt.