Copilot‑Agenten für Banken: Aufbau und Governance

Eine Bank erweitert Microsoft 365 Copilot auf vier Wegen mit eigenen Agenten: deklarative Agenten, Copilot-Connectors, MCP- und API-Plug-ins sowie benutzerdefinierte Engine-Agenten. Entscheidend für den produktiven Einsatz ist weniger der Bau als der Rahmen um Copilot herum: wer welche Daten sieht, welche Daten den Mandanten verlassen, wer einen Agenten freigibt und wie sich jede Aktion später nachvollziehen lässt.

Dieser Leitfaden richtet sich an CIOs, Leiter IT und COOs in Schweizer und deutschen Banken. Wir zeigen, welcher Erweiterungsweg zu welchem Bankprozess passt, was Sie vor dem ersten Agenten regeln sollten und welche Beobachtungen die FINMA zum Einsatz von KI festgehalten hat.

Kurz gesagt

• Microsoft unterscheidet deklarative Agenten und benutzerdefinierte Engine-Agenten: Die ersten nutzen Orchestrator und Modelle von Copilot, die zweiten bringen eigene mit.
• Connectors und MCP-Plug-ins bestimmen, welche Bankdaten ein Agent lesen und welche Systeme er verändern kann. Hier liegt der grösste Governance-Hebel.
• Vier Themen gehören vor jeden Rollout: Berechtigungen, Datengrenzen, Admin-Freigabe und Nachvollziehbarkeit.
• Die FINMA hat in der Aufsichtsmitteilung 08/2024 vom 18. Dezember 2024 Beobachtungen zu Governance, Inventar, Tests und Dokumentation von KI-Anwendungen festgehalten.
• Eine nummerierte Checkliste weiter unten hilft Ihnen, jeden Agenten vor dem Go-live durch dieselben Prüfpunkte zu führen.

Inhaltsverzeichnis

• Was Copilot-Agenten von Copilot selbst unterscheiden
• Vier Wege, Copilot mit eigenen Agenten zu erweitern
• Was um Copilot herum geregelt sein muss
• Governance-Checkliste für Copilot-Agenten
• So bringen Sie den ersten Agenten in den Betrieb
• Was die FINMA zum Einsatz von KI beobachtet
• Unsere Sicht auf Copilot-Agenten in Banken
• Wie S-PRO Banken bei Copilot-Agenten unterstützt
• Häufige Fragen
• Quellen

Was Copilot-Agenten von Copilot selbst unterscheiden

Copilot ist die Oberfläche, über die Mitarbeitende mit KI arbeiten. Ein Agent ist eine spezialisierte Konfiguration darin: mit eigenen Anweisungen, eigenem Wissen und eigenen Aktionen für einen bestimmten Prozess.

Für eine Bank ist dieser Unterschied wichtig. Der Standard-Copilot beantwortet Fragen auf Basis dessen, was eine Person ohnehin sehen darf. Ein Agent kann zusätzlich auf Kernbanken-, CRM- oder Dokumentensysteme zugreifen und dort, je nach Bauweise, Daten abrufen, anlegen oder ändern. Laut Microsoft ermöglichen deklarative Agenten, Geschäftsprozesse mit Anweisungen, Wissen und Aktionen zu automatisieren. Damit wird aus einem Assistenten ein Werkzeug, das in Prozesse eingreift.

Typische Einsatzfelder in Banken sind:

• Fragen zu internen Weisungen, Produktblättern und Prozesshandbüchern beantworten
• Kundendossiers für Beratungsgespräche oder Kreditanträge vorbereiten
• Unterlagen im Onboarding vorprüfen und fehlende Dokumente markieren
• Tickets, E-Mails und Anfragen aus dem Backoffice vorsortieren
• Reports aus mehreren Quellen zusammenführen und als Entwurf bereitstellen

Je näher ein Agent an Kundendaten, Entscheidungen und Buchungen rückt, desto strenger muss der Rahmen sein. Genau darum geht es in den folgenden Abschnitten.

Vier Wege, Copilot mit eigenen Agenten zu erweitern

Microsoft Learn beschreibt vier Bausteine, die sich kombinieren lassen: deklarative Agenten, Copilot-Connectors, MCP- und API-Plug-ins sowie benutzerdefinierte Engine-Agenten. Die Wahl bestimmt, wie viel Kontrolle Sie über Modell, Orchestrierung und Datenflüsse haben.

Deklarative Agenten

Ein deklarativer Agent ist eine Konfiguration auf Copilot: benutzerdefinierte Anweisungen, zusätzliches Wissen und Aktionen. Er nutzt die KI-Infrastruktur, das Modell und den Orchestrator von Copilot, es braucht kein zusätzliches Hosting. Microsoft hält dazu fest, dass solche Agenten deshalb die Sicherheits-, Compliance- und RAI-Anforderungen für Microsoft 365 erfüllen. Erstellt werden sie mit Low-Code-Werkzeugen oder mit Visual Studio Code und dem Microsoft 365 Agents Toolkit.

Für Banken ist das der naheliegende Einstieg: ein Agent für Weisungsfragen, ein Agent für die Vorbereitung von Kundengesprächen, ein Agent für interne IT-Anfragen.

Copilot-Connectors

Connectors bringen Daten aus Drittsystemen in die Reichweite von Copilot. Microsoft unterscheidet zwei Modelle: synchronisierte Connectors, die externe Inhalte in Microsoft Graph indizieren, und Verbundconnectors, die Inhalte zur Abfragezeit über das Model Context Protocol (MCP) abrufen, ohne sie in Microsoft Graph zu indizieren. Für Verbundconnectors nennt Microsoft ausdrücklich dynamische Daten oder regulierte Inhalte, die in der Quelle verbleiben müssen.

Diese Unterscheidung ist für eine Bank eine Architekturentscheidung mit Compliance-Folgen. Ein synchronisierter Connector kopiert Inhalte in den Microsoft-365-Index. Ein Verbundconnector lässt sie im Quellsystem, dort gelten weiterhin dessen Berechtigungen.

MCP- und API-Plug-ins

Plug-ins sind Aktionen innerhalb deklarativer Agenten. Sie verbinden einen Agenten mit einem MCP-Server oder einer REST-API mit OpenAPI-Beschreibung und erlauben es, Daten abzufragen und, sofern unterstützt, Objekte zu erstellen, zu aktualisieren und zu löschen.

Ein Detail verdient Aufmerksamkeit: Bei MCP-basierten Plug-ins löst Copilot die Werkzeuge standardmässig dynamisch zur Laufzeit vom MCP-Server auf. Neue Werkzeuge stehen damit sofort zur Verfügung, ohne dass der Agent neu veröffentlicht wird. Entwickler können stattdessen einen festen Satz an Werkzeugen im Plug-in-Manifest anheften. Für eine Bank ist das Anheften in der Regel die richtige Wahl, weil jede neue Fähigkeit dann durch die Freigabe läuft.

Für die Anmeldung ruft Microsoft 365 Copilot die Anmeldeinformationen im Namen des angemeldeten Benutzers ab. API-Schlüssel unterstützen MCP-Plug-ins als deklarative Agentaktionen nicht. Das hält den Zugriff an die Identität der Person gebunden.

Benutzerdefinierte Engine-Agenten

Benutzerdefinierte Engine-Agenten bringen eigene Orchestrierung und eigene Modelle mit. Microsoft beschreibt volle Kontrolle über Workflows, KI-Modelle und Integrationen, gebaut mit Copilot Studio, dem Microsoft 365 Agents SDK, dem Teams SDK oder Microsoft Foundry. Solche Agenten können Workflows programmatisch anstossen, selbständig arbeiten, Aufgaben eskalieren und mit anderen Agenten zusammenarbeiten.

Dieser Weg passt, wenn ein Prozess mehrere Systeme, eigene Prüfregeln oder ein bestimmtes Modell braucht. Er verlangt aber auch den umfassendsten Betriebs- und Kontrollrahmen, weil Hosting, Modellwahl und Protokollierung bei Ihnen liegen.

Die vier Wege im Vergleich

Was um Copilot herum geregelt sein muss

Vier Themen entscheiden, ob ein Copilot-Agent in einer Bank produktiv gehen kann: Berechtigungen, Datengrenzen, Admin-Freigabe und Nachvollziehbarkeit. Sie sollten geklärt sein, bevor der erste Agent mehr als eine Testgruppe erreicht.

Berechtigungen

Ein Agent sieht, was das Konto sieht, unter dem er arbeitet. Bei Plug-ins ist das die angemeldete Person. Damit werden alte Berechtigungsprobleme sichtbar: Teams-Kanäle mit zu breitem Zugriff, SharePoint-Sites, die für alle Mitarbeitenden offenstehen, oder Ablagen ohne Eigentümer. Bereinigen Sie diese vor dem Rollout, nicht danach.

Achten Sie besonders auf Connectors. In einem Beispiel von Microsoft ist der erfasste Inhalt so eingestellt, dass er für jeden in der Organisation sichtbar ist. Für Weisungen mag das passen, für Kundendaten nie. Jeder Connector braucht eine dokumentierte Zugriffslogik, die jener des Quellsystems entspricht.

Datengrenzen

Legen Sie pro Agent fest, welche Datenklassen er verarbeiten darf und wohin sie fliessen. Drei Fragen helfen:

1. Werden Inhalte in Microsoft Graph indiziert, oder bleiben sie in der Quelle?
2. Ruft der Agent externe Dienste, MCP-Server oder Modelle ausserhalb von Microsoft 365 auf?
3. Welche Kundendaten, insbesondere solche unter Bankkundengeheimnis, sind ausgeschlossen?

Bei benutzerdefinierten Engine-Agenten liegt die Antwort vollständig in Ihrer Architektur. Klären Sie Datenstandorte und Unterauftragnehmer mit Ihrem Datenschutzbeauftragten und, wo ein Drittanbieter beteiligt ist, im Rahmen Ihrer Outsourcing-Prüfung.

Admin-Freigabe

Kein Agent sollte ohne definierten Freigabeprozess in den Mandanten gelangen. Bestimmen Sie, wer Agenten erstellen darf, wer sie veröffentlichen darf und wer sie für welche Gruppen bereitstellt. Die Freigabe prüft nicht nur Technik, sondern auch Zweck, Risikoklasse, Eigentümer und Datenquellen.

Bei MCP-Plug-ins gehört der Werkzeugumfang zur Freigabe. Ist er angeheftet, ändert sich der Agent nur über einen neuen Freigabezyklus. Bei dynamischer Werkzeugermittlung muss der MCP-Server selbst unter Change-Management stehen.

Nachvollziehbarkeit

Eine Bank muss erklären können, welcher Agent wann auf welche Daten zugegriffen und welche Aktion ausgelöst hat. Definieren Sie, welche Ereignisse protokolliert werden: Erstellen, Veröffentlichen, Berechtigungsänderungen, Aufrufe von Plug-ins und schreibende Aktionen. Bestimmen Sie, wie lange die Protokolle aufbewahrt werden und wer sie auswertet.

Bei schreibenden Aktionen mit Kundenwirkung empfehlen wir, eine Person jede Aktion bestätigen zu lassen. Der Agent bereitet vor, der Mensch entscheidet.

Governance-Checkliste für Copilot-Agenten

Diese zehn Punkte sollte jeder Agent durchlaufen, bevor er über eine Testgruppe hinaus freigegeben wird. Die Liste eignet sich als Vorlage für Ihr Freigabeformular.

1. Inventar: Der Agent ist mit Zweck, Eigentümer, Erweiterungsweg und Version im zentralen KI-Inventar erfasst.
2. Risikoklasse: Der Agent ist nach Kundenwirkung, Datensensitivität und Autonomie klassifiziert.
3. Wissensquellen: Alle Datenquellen sind benannt, ihre Berechtigungen sind geprüft und bereinigt.
4. Datenfluss: Es ist dokumentiert, ob Inhalte indiziert oder zur Laufzeit abgerufen werden und ob Daten Microsoft 365 verlassen.
5. Aktionen: Lesende und schreibende Aktionen sind getrennt aufgeführt; bei MCP-Plug-ins ist der Werkzeugumfang festgelegt.
6. Authentifizierung: Der Zugriff auf Backend-Systeme läuft über die Identität der Person, nicht über geteilte Schlüssel.
7. Menschliche Kontrolle: Für Aktionen mit Kundenwirkung ist eine Bestätigung durch eine Person vorgesehen.
8. Tests: Der Agent ist an realen, bereits von Menschen bearbeiteten Fällen geprüft, mit festgelegten Kennzahlen und Schwellenwerten.
9. Protokollierung: Zugriffe, Aktionen und Änderungen am Agenten werden aufgezeichnet und regelmässig ausgewertet.
10. Lebenszyklus: Es gibt Regeln für Überprüfung, Änderung und Ausserbetriebnahme, inklusive Notabschaltung.

So bringen Sie den ersten Agenten in den Betrieb

Der sichere Weg führt über einen eng geschnittenen Anwendungsfall, einen klaren Rahmen und einen beaufsichtigten Start. So gewinnen Sie belastbare Erfahrungen, bevor Sie skalieren.

1. Anwendungsfall eingrenzen: Wählen Sie einen Prozess mit hohem Volumen, klaren Regeln und messbarem Ergebnis, etwa die Beantwortung von Weisungsfragen oder die Vorbereitung von Kundendossiers.
2. Erweiterungsweg wählen: Starten Sie, wo möglich, deklarativ. Wechseln Sie zu einem benutzerdefinierten Engine-Agenten, wenn Orchestrierung, Modell oder Systemzugriffe es verlangen. Microsoft beschreibt auch, wie sich ein deklarativer Agent in einen benutzerdefinierten Engine-Agenten konvertieren lässt.
3. Rahmen festlegen: Arbeiten Sie die Checkliste oben durch, bevor Sie Code schreiben.
4. Lizenzen und Kosten klären: Laut Microsoft brauchen Sie für die Verankerung in Organisationsdaten über Copilot Studio eine Lizenz oder eine Verbrauchsmessung im Mandanten.
5. Isoliert testen: Prüfen Sie den Agenten an historischen Fällen und vergleichen Sie seine Ergebnisse mit der Arbeit Ihrer Mitarbeitenden.
6. Beaufsichtigt starten: Geben Sie den Agenten zunächst einer kleinen Gruppe frei, mit Bestätigung jeder schreibenden Aktion.
7. Überwachen und erweitern: Werten Sie Protokolle und Kennzahlen aus und erweitern Sie den Nutzerkreis erst, wenn die Ergebnisse stabil sind.

Steht bei Ihnen ein Copilot-Agent kurz vor dem Rollout, aber Berechtigungen, Datenflüsse oder die Freigabe sind noch nicht geklärt? Besprechen Sie Ihren Anwendungsfall mit unseren Engineers.

Was die FINMA zum Einsatz von KI beobachtet

Die FINMA hat mit der Aufsichtsmitteilung 08/2024 “Governance und Risikomanagement beim Einsatz künstlicher Intelligenz” vom 18. Dezember 2024 ihre Beobachtungen aus der laufenden Aufsicht veröffentlicht. Sie betreffen direkt die Themen, die bei Copilot-Agenten zu regeln sind.

Die Aufsichtsmitteilung beschreibt Beobachtungen in diesen Bereichen:

• Governance: Viele Institute konzentrierten sich auf Datenschutzrisiken, weniger auf Modellrisiken wie fehlende Robustheit, Korrektheit, Verzerrungen oder Erklärbarkeit. Zuständigkeiten seien bei dezentraler Entwicklung nicht immer klar.
• Inventar und Risikoklassifizierung: Die Abgrenzung, was als KI gilt, und die Vollständigkeit der Inventare waren Thema.
• Datenqualität: Ergebnisse hängen von Qualität und Eignung der verwendeten Daten ab.
• Tests und laufende Überwachung: Kennzahlen, Schwellenwerte und Rückfallebenen spielen eine Rolle.
• Dokumentation und Erklärbarkeit: Zweck, Daten, Modellwahl und Ergebnisse sollten nachvollziehbar sein.
• Unabhängige Überprüfung: Wesentliche Anwendungen sollten unabhängig geprüft werden.
• Drittanbieter: KI wird oft von externen Anbietern bezogen, was die Steuerung der Auslagerung berührt.

Die Checkliste oben bildet diese Themen auf Copilot-Agenten ab. Für Institute mit Tätigkeit in der EU ist bei der Beurteilung der KI-Systeme selbst zusätzlich der EU AI Act massgeblich; für deutsche Institute kommen DORA und die Anforderungen der BaFin hinzu. Dieser Leitfaden ersetzt keine Rechtsberatung; die Einordnung Ihres Agenten nehmen Sie mit Compliance und Rechtsabteilung vor.

Unsere Sicht auf Copilot-Agenten in Banken

Copilot ist für viele Banken der schnellste Weg, KI in den Arbeitsalltag zu bringen, weil Mitarbeitende die Oberfläche bereits kennen. Den eigentlichen Nutzen schaffen aber Agenten, die Bankprozesse verstehen und mit den Systemen der Bank arbeiten.

Aus unseren Projekten wissen wir: Der Engpass ist selten das Modell. Es sind die Schnittstellen zu Kernbankensystem, CRM und Dokumentenablage, die Berechtigungslogik dahinter und die Frage, wer einen Agenten freigibt und überwacht. Wer das früh klärt, kommt schneller in die Produktion.

Wir empfehlen deshalb, Copilot nicht mit einzelnen, isoliert gebauten Agenten zu erweitern, sondern mit einem gemeinsamen Fundament: einer Plattform, auf der Agenten nach denselben Regeln entstehen, protokolliert werden und sich mit Copilot verbinden. So bleibt die Governance einheitlich, auch wenn aus einem Agenten zehn werden.

Das S-PRO-Team

Wie S-PRO Banken bei Copilot-Agenten unterstützt

Wir entwickeln KI-Agenten für Banken, Vermögensverwalter und Fintechs und verbinden sie mit Microsoft Copilot. Microsoft Copilot Booster ist unser Agenten-Hub, der sich mit Microsoft Copilot verbindet, gebaut auf unserer eigenen agentischen Plattform S-PRO Agents. Mehr dazu finden Sie bei unseren Agenten für Prozessautomatisierung.

Wir bauen die Lösung des Kunden auf S-PRO Agents auf und betreiben sie als Service. Dazu gehören je nach Ausgangslage:

• Technologieberatung: Auswahl des Erweiterungswegs, Architektur, Datenflüsse und Governance-Rahmen
• Agenten für Prozessautomatisierung: Agenten für Backoffice-, Beratungs- und Operations-Prozesse, verbunden mit Copilot
• KI-Pilot in die Produktion: vom eng geschnittenen Anwendungsfall bis zum überwachten Betrieb

S-PRO ist ein internationales schweizerisch-amerikanisches Unternehmen mit Büros in Zürich (Löwenstrasse 45, 8001 Zürich) und Salt Lake City und globaler Delivery, und R&D-Zentren in Zürich und Łódź. Gegründet 2014, arbeiten bei uns mehr als 250 Ingenieure. Wir sind nach ISO 27001 und ISO 27701 zertifiziert.

Möchten Sie Copilot mit eigenen Agenten erweitern und den Rahmen dafür von Anfang an sauber aufsetzen? Vereinbaren Sie ein Erstgespräch mit S-PRO.

Häufige Fragen

Brauchen wir für Copilot-Agenten eine zusätzliche Lizenz?

Das hängt vom Erweiterungsweg ab. Mit einer Microsoft-365-Copilot-Lizenz brauchen Sie laut Microsoft keine weitere Lizenz für deklarative Agenten mit Connectors und Plug-ins. Für Copilot-Studio-Agenten, die auf Organisationsdaten zugreifen, ist eine Lizenz oder eine Verbrauchsmessung im Mandanten nötig. Benutzerdefinierte Engine-Agenten mit dem Teams SDK verursachen Kosten über die genutzten Azure-Dienste.

Sollen wir mit einem deklarativen oder einem benutzerdefinierten Engine-Agenten starten?

Für die meisten Banken ist ein deklarativer Agent der bessere Einstieg. Er nutzt Modell und Orchestrator von Copilot und braucht kein eigenes Hosting. Ein benutzerdefinierter Engine-Agent lohnt sich, wenn ein Prozess eigene Modelle, mehrere Systeme oder autonome Abläufe verlangt. Ein deklarativer Agent lässt sich später in einen benutzerdefinierten Engine-Agenten überführen.

Kann ein Copilot-Agent mehr Daten sehen als die Person, die ihn nutzt?

Bei MCP- und API-Plug-ins arbeitet der Agent mit den Anmeldeinformationen der angemeldeten Person und sieht damit, was diese sehen darf. Risiken entstehen bei zu breit freigegebenen Ablagen oder bei Connectors, deren Inhalte für die ganze Organisation sichtbar sind. Prüfen Sie deshalb Berechtigungen und Zugriffslisten jedes Connectors vor dem Rollout.

Was verlangt die FINMA konkret für Copilot-Agenten?

Die Aufsichtsmitteilung 08/2024 behandelt KI allgemein, nicht Copilot-Agenten im Besonderen. Die FINMA beschreibt darin Beobachtungen zu Governance, Inventar, Risikoklassifizierung, Datenqualität, Tests, Dokumentation, Erklärbarkeit und unabhängiger Überprüfung. Diese Themen lassen sich direkt auf Agenten übertragen. Die rechtliche Einordnung Ihres Anwendungsfalls klären Sie mit Compliance und Rechtsabteilung.

Wie starten wir mit S-PRO und was kostet der Einstieg?

Der Einstieg ist ein Design-Thinking-Pilot ab CHF 20k, 2-4 Wochen. Darin klären wir gemeinsam Anwendungsfall, Erweiterungsweg, Datenflüsse und den Governance-Rahmen für Ihren ersten Copilot-Agenten. Das Ergebnis ist eine belastbare Grundlage für die Entscheidung, ob und wie Sie den Agenten in die Produktion bringen.

Quellen

• Microsoft Learn: Vergleich von deklarativen und benutzerdefinierten Engine-Agents
• Microsoft Learn: Übersicht über Microsoft 365 Copilot-Connectors
• Microsoft Learn: MCP- und API-Plug-Ins für deklarative Agents
• Microsoft Learn: Konfigurieren der Authentifizierung für MCP- und API-Plug-Ins
• Microsoft Learn: Benutzerdefinierte Engine-Agents für Microsoft 365
• Microsoft Learn: Konvertieren eines deklarativen Agents in einen benutzerdefinierten Engine-Agent
• Microsoft Learn: Häufig gestellte Fragen zur Microsoft 365 Copilot-Erweiterbarkeit
• FINMA: Aufsichtsmitteilung 08/2024, Governance und Risikomanagement beim Einsatz künstlicher Intelligenz (18. Dezember 2024)

Zuletzt aktualisiert: 7. November 2026

Empfehlungen

• KI-Agent erstellen: Leitfaden für Banken und Finanzinstitute
• 6 Produktionsgates für KI-Agenten in Banken (2026)
• KI-Agenten für Banken: in fünf Phasen zur Produktion
• AMINA: Bibliothek von KI-Agenten und KI-Governance