Agenten-Taxonomie entscheidet mehr als die Architektur

Im Dezember 2025 hat Microsoft dem Cloud Adoption Framework ein eigenes Einführungsframework für KI-Agenten hinzugefügt. Es definiert, was ein Agent ist, führt durch die Phasen Planen, Steuern, Bauen und Betreiben und sortiert Agenten nach ihrem Autonomiegrad in drei Kategorien. Die Anleitung ist gut. Sie ist aber für ein globales Publikum geschrieben und erwähnt an keiner Stelle die Verordnung, die in der EU darüber entscheidet, wie viel Governance jede Kategorie trägt.

Diese Zuordnung lohnt sich, denn die Hochrisiko-Pflichten der KI-Verordnung gelten ab dem 2. Dezember 2027, einem Termin, den die Omnibus-Novelle vom Juni 2026 bereits einmal nach hinten verschoben hat. Wer jetzt Agenten pilotiert, muss die Systeme, die er in diesem Quartal klassifiziert, bis dahin dokumentiert haben. Diese Einstufung richtig zu treffen, ist der erste Schritt jedes KI-Projekts auf Azure, das wir übernehmen.

Die drei Agententypen

Microsofts Taxonomie verläuft entlang eines Autonomie-Spektrums:

• Produktivitätsagenten suchen und verdichten Informationen. Der Anwender fragt, der Agent durchsucht angebundene Quellen und antwortet, der Anwender entscheidet, was er damit tut.
• Aktionsagenten erledigen definierte Aufgaben in festen Abläufen: einen Datensatz aktualisieren, ein Ticket anlegen, einen Prozess anstoßen.
• Automatisierungsagenten steuern mehrstufige Prozesse mit minimaler Aufsicht. Sie entscheiden, wann sie laufen, wann sie stoppen und wann sie eskalieren.

Microsoft merkt selbst an, dass die dritte Kategorie strenge Governance verlangt, ohne zu sagen, was diese Governance erfüllen muss. In der EU hat ein großer Teil der Antwort eine Fundstelle.

Was die KI-Verordnung tatsächlich klassifiziert

Die KI-Verordnung klassifiziert keine Technologie. Sie klassifiziert die Zweckbestimmung. Anhang III listet die Bereiche, in denen ein System als hochriskant gilt: Beschäftigung und Personalmanagement, Zugang zu grundlegenden Diensten, Kreditwürdigkeitsprüfung, Bildung, Strafverfolgung und einige weitere. Ob hinter diesem Zweck ein Chat, ein Workflow oder ein Agent steht, ist für die Einstufung unerheblich.

Deshalb können zwei Agenten auf derselben Plattform in verschiedenen Rechtswelten leben. Ein Suchagent, der Fragen zu Ihren HR-Richtlinien beantwortet, ist in den meisten Konfigurationen nicht hochriskant. Ein Automatisierungsagent, der Bewerbungen vorsortiert und eine Auswahlliste erstellt, steht mitten in Anhang III. Derselbe Foundry-Tenant, dieselbe Modellfamilie, ein anderes Pflichtenpaket: Risikomanagement, Daten-Governance, Protokollierung, Dokumentation, menschliche Aufsicht.

Wo die Taxonomie zum Governance-Indikator wird

Autonomie ist in der Verordnung kein Einstufungskriterium. Mit den Pflichten korreliert sie trotzdem, auf drei Wegen.

Erstens über die Wahrscheinlichkeit. Je weiter rechts ein Agent auf Microsofts Spektrum steht, desto mehr handelt er an Menschen und Prozessen, statt Informationen für sie zu beschaffen. Und das Handeln an Menschen ist genau das, worum es in Anhang III überwiegend geht. Automatisierungsagenten landen häufiger im Hochrisiko-Bereich, weil sie dafür gebaut sind.

Zweitens über Artikel 14. Die menschliche Aufsicht über einen Suchagenten ist fast schon eingebaut: Ein Mensch liest die Antwort und trifft die Entscheidung. Bei einem Automatisierungsagenten muss Aufsicht entworfen, besetzt und nachgewiesen werden. Jemand muss nachvollziehen können, was der Agent getan hat, eingreifen können und ihn stoppen können. Wenn Ihr Agent nachts einen mehrstufigen Prozess abarbeitet, ist "ein Mensch prüft das Ergebnis" eine Behauptung, die Sie verteidigen können müssen, kein Satz auf einer Folie.

Drittens über die Protokollierung. Artikel 12 verlangt für Hochrisiko-Systeme eine automatische Protokollierung über die gesamte Lebensdauer, Artikel 19 setzt sechs Monate als Mindestaufbewahrung. Ein Suchagent mit einer Frage und einer Antwort erzeugt nebenbei ein sauberes Protokoll. Eine Multi-Agent-Orchestrierung, die Werkzeuge aufruft, Teilaufgaben startet und ihren eigenen Plan revidiert, erzeugt eine Spur, deren Erfassung Sie bewusst architektonisch vorsehen müssen. Sonst können Sie hinterher nicht rekonstruieren, was passiert ist.

Die Anbieterfrage

Noch eine Stelle, an der sich Agentenplattformen und die Verordnung unbequem kreuzen. Die Betreiberpflichten aus Artikel 26 sind beherrschbar. Die Anbieterpflichten ab Artikel 16 sind eine andere Größenordnung. Artikel 25 regelt, wann ein Betreiber zum Anbieter wird: wer seinen Namen auf ein Hochrisiko-System setzt, es wesentlich verändert oder ein System so verändert, dass es hochriskant wird.

Agentenplattformen machen alle drei Fälle per Konfiguration erreichbar. Ein in Copilot Studio oder Foundry gebauter Agent mit Ihren Anweisungen, Ihren Werkzeugen und Ihrem Branding ist nicht offensichtlich "ein Microsoft-System, das Sie betreiben". Ob Ihre Konfiguration die Linie aus Artikel 25 überschreitet, ist eine Einzelfallprüfung. Sie ist deutlich billiger, bevor der Agent existiert, als danach.

Was in diesem Quartal zu tun ist

Inventarisieren Sie die Agenten, die bereits existieren, einschließlich derer, die einzelne Teams in Copilot Studio gebaut haben, ohne jemandem Bescheid zu sagen. Klassifizieren Sie jeden nach Zweckbestimmung gegen Anhang III, beim Entwurf, nicht erst in der Rechtsprüfung. Nutzen Sie Microsofts Taxonomie dann als Triage: Suchagenten bekommen eine leichte Prüfung, Aktions- und Automatisierungsagenten die vollständige Prüfung nach Artikel 9, 12 und 14, bevor sie live gehen. Die Taxonomie wurde als Einführungshilfe veröffentlicht. Neben Anhang III gelesen, ist sie ein brauchbares Werkzeug zur Risikotriage. Wo diese Triage einen Automatisierungsagenten zutage fördert, den Sie dennoch bauen müssen, sortiert ein AI Discovery Sprint die Kandidaten nach Machbarkeit und EU-AI-Act-Risiko, bevor einer davon in Produktion geht.