Skills vs. Agents: Der Governance-Guide für AI Agents
Jeder Agent, der eigentlich ein Skill wäre, ist Governance-Schuld von morgen. Und Agents schaffen kein neues Risiko. Sie erben die Berechtigungslage, die eine Organisation über Jahre hat schleifen lassen, und machen sie mit Maschinengeschwindigkeit auffindbar. Deshalb ist Governance nicht die Bremse vor dem Agent-Rollout. Sie ist das, was den Rollout überhaupt tragfähig macht: erst der Spielzug, dann der Spieler.
Der 40-Agenten-Friedhof
Diese Szene spielt sich gerade in vielen Organisationen ab. Sechs Monate nach der Öffnung von Copilot Studio gibt es vierzig Agenten. Niemand kann sagen, wer die Hälfte davon gebaut hat, auf welche Daten sie zugreifen, welche noch funktionieren und wer sie abschaltet. Jeder einzelne ist ein Governance-Objekt, das niemand pflegt.
Ich habe diese Liste gesehen. Mehr als einmal. Und der unbequeme Teil ist immer derselbe: Die meisten dieser vierzig Agenten sollten gar keine Agenten sein. Es sind Anleitungen, Vorgehen, Know-how. Dinge, die aufgeschrieben gehört hätten, nicht mit einer Identität ausgestattet. Die Teams, die sie gebaut haben, haben keine falsche Entscheidung getroffen. Sie haben keine getroffen. So beginnt Governance-Schuld. Nicht mit einer falschen Wahl, mit einer nicht getroffenen.
Skill oder Agent: die Unterscheidung, die alles entscheidet
Zuerst das Begriffschaos, denn “Skill” bedeutet in der Microsoft-Welt gerade zwei verschiedene Dinge: den neuen offenen SKILL.md-Standard (portable Anleitungs-Dateien) und die Legacy-Bot-Framework-Skills in Copilot Studio. Dieser Guide meint das Erste. Wenn ich Skill sage, meine ich eine geschriebene, portable Fähigkeit.
Damit ist die Unterscheidung sauber.
Ein Skill ist das Wie. Er beschreibt, wie etwas getan wird. Keine eigene Identität, keine Lizenz, kein eigener Datenzugriff. Er lebt als Datei, ist in Minuten gebaut und wandert mit, wohin du ihn nimmst.
Ein Agent ist das Wer. Er ist ein Akteur, mit eigener Identität, eigenem Datenzugriff, Tools, einem Grad an Autonomie und damit einer Governance-Pflicht: Lifecycle, Kosten, Monitoring, Ownership.
Oder in der Sprache, der ich am meisten vertraue: Der Skill ist der Spielzug im Playbook, der Agent ist der Spieler auf dem Eis. Denselben Spielzug kannst du jedem Spieler im Kader beibringen. Aber nur der Spieler braucht einen Vertrag, einen Platz im Kader und einen Coach, der ihn überwacht.
Das ist die ganze Entscheidung, verdichtet. Braucht diese Aufgabe einen Spielzug, oder einen Spieler? Die meisten Aufgaben brauchen einen Spielzug. Daraus folgt die Faustregel: Skill first. Agent nur, wenn die Aufgabe einen Akteur braucht, keinen Spielzug.
Die Erbschaft: warum deine Agents alte Schuld industrialisieren
Jetzt der Teil, der das Ganze dringlich macht statt akademisch.
Viele Organisationen haben ihre M365-Grundlagen über Jahre schleifen lassen. Oversharing, tote Permissions, keine Sensitivity-Label-Strategie, SharePoint-Wildwuchs. Diese Schuld war überlebbar, weil sie latent blieb. Die übergeteilte Datei existierte, aber niemand hat aktiv nach ihr gefragt.
Ein Agent ändert das. Ein Agent schafft kein neues Risiko. Er erbt die Berechtigungslage, die du bereits hast, und macht sie mit Maschinengeschwindigkeit auffindbar. Was früher eine Person brauchte, die zufällig über das falsche Dokument stolpert, braucht heute eine gut formulierte Frage an einen Agenten mit breitem Zugriff. Security-Schuld verzinst sich zu Agent-Schuld. Mit Zinseszins.
Deshalb kann das Governance-Gespräch nicht warten, bis Probleme auftreten. Die Frage wird in dem Moment entschieden, in dem das erste Team seinen ersten Agenten baut. Auf dem Datenfundament, das an diesem Tag existiert.
Und deshalb ist auch der Rahmen wichtig. Governance ist hier kein Angstmaterial. Das Fundament aufzuräumen ist das, was dir erlaubt, Agents schnell auszurollen, ohne dass der Rollout unter seiner eigenen Erbschaft zusammenbricht. Governance ist nicht die Bremse. Sie ist die Strasse.
Die Entscheidungsmatrix: vier Fragen vor jedem Agenten-Build
Häng das neben Copilot Studio an die Wand. Bevor irgendetwas ein Agent wird, brauchen vier Fragen eine Antwort.
-
Braucht die Aufgabe eine eigene Identität und eigenen Datenzugriff? Wenn die Fähigkeit in einem bestehenden, kontrollierten Kontext laufen kann (im Copilot einer Person, in einem bestehenden System), ist es ein Skill. Identität ist die teuerste Eigenschaft, die ein Agent hat.
-
Muss sie autonom handeln, oder leitet sie jemanden an, der handelt? Anleitungen, Checklisten, Methoden und Prompts, die ein Mensch ausführt, sind Spielzüge. Autonomie ist das, was einen Spieler ausmacht.
-
Ist der Governance-Aufwand tragbar? Jeder Agent braucht einen Owner, einen Lifecycle, Monitoring und einen Abschaltweg. Wenn ihn in zwölf Monaten niemand besitzen wird, gib ihm heute keine Identität.
-
Wer pflegt es, und ist es über Kontexte wiederverwendbar? Ein Skill wandert: derselbe Spielzug, viele Spieler, praktisch keine Zusatzkosten. Ein Agent multipliziert Pflichten mit jeder Kopie.
Frage 1 oder 2 nicht bestanden: Bau einen Skill. Beide bestanden, aber 3 oder 4 nicht: Kläre zuerst die Ownership, bevor du irgendetwas baust. Alle vier bestanden: Bau den Agenten. Bewusst, registriert, mit Owner.
Der Bauplan: was vor dem ersten Agenten stehen muss
Die gute Nachricht: Die Plattform-Seite ist gereift. Microsoft hat die Kontrollebenen-Bausteine geliefert, die dieser Guide voraussetzt. Entra Agent ID gibt jedem Agenten eine kontrollierte Identität nach Zero-Trust-Regeln. Agent 365, seit 1. Mai 2026 generell verfügbar, ist das zentrale Register und die Kontrollebene für Agenten über Entra, Defender, Purview und Intune hinweg. Auf der Datenfundament-Seite läuft Purviews DSPM for AI mit einem wöchentlichen Default-Assessment über die meistgenutzten SharePoint-Sites und unterstützt Bulk-Remediation übergeteilter Links, flankiert von Restricted Content Discovery und DLP für Copilot.
Was ist also das ehrliche Minimum vor der Agenten-Skalierung? Weniger, als du befürchtest. Und nichts davon verhindert einen schnellen Start.
Ab Tag 1 brauchst du drei Dinge: ein Agenten-Register (jeder Agent sichtbar, jeder Agent mit Owner), eine Identität pro Agent, und die Datenhygiene-Basics am Laufen, also das wöchentliche Assessment an und das schlimmste Oversharing bereinigt.
Bewusst warten darf: feingranulare Monitoring-Tiefe, Kostenoptimierung pro Agent und die volle Lifecycle-Automatisierung. Das verbessert einen kontrollierten Bestand. Es rettet keinen unkontrollierten.
Das ist Minimal-Governance, die Innovation nicht erstickt. Sichtbarkeit, Identität, Ownership, Hygiene. Alles andere darf dem Wert folgen.
Wo die Plattform noch Grenzen hat
Zwei ehrliche Beobachtungen, datiert Juli 2026 und beim Lesen gegen den aktuellen Stand zu prüfen.
Erstens: Das Tooling ist der Praxis davongelaufen. Die Kontrollebene existiert. Der organisatorische Muskel (wer reviewt das Register, wer pensioniert Agenten, wer besitzt die Entscheidungsmatrix) baut sich nicht von selbst, und keine Lizenz enthält ihn.
Zweitens: Das Register sieht, was im Microsoft-Bestand lebt. Agenten, die deine Teams auf anderen Plattformen bauen, inventarisieren sich nicht selbst. Wenn deine Organisation multi-plattform arbeitet, ist dein Governance-Umfang grösser als jede einzelne Kontrollebene.
Keiner der beiden Punkte ist ein Grund zu warten. Beide sind Gründe, mit der Entscheidungsmatrix zu starten statt mit dem Tooling-Katalog.
Dein nächster Schritt: der Agenten-Inventar-Selbst-Check
- Kannst du eine vollständige Liste der Agenten liefern, die heute in deiner Organisation laufen, mit Owner pro Agent?
- Bei wie vielen davon kannst du beantworten: Auf welche Daten kann dieser Agent zugreifen?
- Wie viele deiner Agenten würden an der Vier-Fragen-Matrix scheitern? Wie viele sind Spielzüge im Trikot?
- Ist dein Datenfundament assessed? Kennst du deine Oversharing-Hotspots, bevor ein Agent sie findet?
- Wer entscheidet formal, ob die nächste Fähigkeit ein Skill oder ein Agent wird?
Wenn schon Frage 1 scheitert, fang dort an. Du kannst nicht kontrollieren, was du nicht siehst.
Der Guide gibt dir das Denkmodell. Trainiert wird anders.
- Wöchentlicher Trainingsrhythmus: Copilot Your Day, jeden Montag um 7:30Newsletter abonnieren
- Live: die "Become a Frontier Firm"-Keynote oder ein Executive Briefing mit euren Zahlen auf dem TischSpeaking →
- In deiner Organisation: Ganze Transformations-Programme sind die Arbeit, die ich mit meinem Team bei Campana & Schott mache. Die Kontaktseite zeigt den Weg.
FAQ
Skill oder Agent: Wann brauchen wir was?
Frag, was die Aufgabe verlangt: einen Spielzug oder einen Spieler. Wenn die Fähigkeit beschreibt, wie etwas getan wird, und ein Mensch oder ein bestehendes, kontrolliertes System sie ausführt, bau einen Skill. Keine Identität, keine Lizenz, portabel, in Minuten gebaut. Wenn die Aufgabe wirklich einen Akteur mit eigener Identität, eigenem Datenzugriff und Autonomie braucht, bau einen Agenten. Bewusst, mit Owner und Lifecycle. Pascal Brunner-Nikolla, Microsoft MVP für M365 Copilot & Agents, fasst die Regel so: Skill first, Agents bewusst.
Wie verhindern wir Agenten-Wildwuchs und Governance-Schuld?
Installiere die Entscheidung vor dem Tooling: vier Fragen (eigene Identität nötig? Autonomie nötig? Governance-Aufwand tragbar? Ownership und Wiederverwendung geklärt?), die jede Fähigkeit besteht, bevor sie ein Agent wird. Kombiniere das mit einem Agenten-Register ab Tag 1, jeder Agent sichtbar und mit Owner, und das Wildwuchs-Problem schrumpft auf die Fälle, die den Aufwand verdienen.
Wer sollte im Unternehmen Agenten bauen dürfen?
Mehr Leute, als dein Instinkt sagt, unter klareren Regeln, als du vermutlich hast. Breite Bau-Rechte mit Pflicht-Register, Identität pro Agent und der Vier-Fragen-Matrix schlagen ein zentrales Bottleneck-Team. Denn das Bottleneck stoppt das Bauen nicht. Es verschiebt es in den Schatten. Shadow AI folgt derselben Logik wie Shadow IT.
Welche vier Fragen gehören vor jeden Agenten-Build?
Braucht die Aufgabe eine eigene Identität und eigenen Datenzugriff? Muss sie autonom handeln statt einen Menschen anzuleiten? Ist der Governance-Aufwand (Owner, Lifecycle, Monitoring, Abschaltung) tragbar? Wer pflegt es, und ist es wiederverwendbar? Scheitern die ersten beiden: Es ist ein Skill. Scheitern die letzten beiden: Kläre zuerst die Ownership.
Wie inventarisieren wir bestehende Agenten?
Starte mit der Kontrollebene. Agent 365 liefert die Register-Sicht über den Microsoft-Bestand, mit Identität via Entra Agent ID. Dann schliesse die Lücke, die das Tooling nicht sieht (Agenten auf anderen Plattformen), mit einer einfachen Deklarationsregel: Jeder Agent, egal wo er läuft, bekommt einen Eintrag und einen Owner. Ein Inventar, das zu 90% automatisiert und zu 10% deklariert ist, schlägt eines, das zu 100% theoretisch ist.
Bremst Governance nicht die Innovation?
Das Gegenteil, wenn du sie richtig dimensionierst. Unkontrollierte Agenten-Bestände bremsen im schlechtesten Moment: wenn etwas bricht, wenn das Audit fragt, wenn niemand sagen kann, worauf ein Agent zugreift. Minimal-Governance (Sichtbarkeit, Identität, Ownership, Datenhygiene) ist das, was einer Organisation erlaubt, zum nächsten Fünfziger-Paket an Agenten schnell Ja zu sagen. Governance ist nicht die Bremse. Sie ist die Strasse.
Zum Vertiefen
- Episode 111 — Agent 365 is GA. All You Need to KnowDie Kontrollebene für Agenten, im Detail.
- Episode 101 — From Shadow IT to Shadow AIWarum die Bottleneck-Strategie zweimal scheitert.
- Geführtes Training: Sicher mit Copilot umgehenDie Datenhygiene-Hausaufgabe als geführter LinkedIn-Learning-Kurs.