5 Enterprise Use Cases für MCP: CRM, ERP, ITSM, Finance und HR im produktiven Einsatz

Im Vertrieb liegt das Problem selten im Mangel an Daten, sondern in deren operativer Nutzbarkeit. Relevante Informationen zu Accounts, Opportunities, Aktivitäten, offenen Aufgaben und letzten Kundeninteraktionen sind in Salesforce grundsätzlich vorhanden und über die REST API zugänglich, aber sie liegen oft verteilt über mehrere Objekte, Views und Berechtigungsmodelle. Salesforce positioniert seine REST API explizit als skalierbare Schnittstelle für programmgesteuerten Datenzugriff; für einen AI-Host ist sie jedoch ohne zusätzliche Abstraktion zu technisch und zu granular.

In der Praxis bedeutet das: Ein Vertriebsmitarbeiter will keine API-Objekte lesen, sondern Antworten auf Fragen wie:

• Welche Opportunities in meiner Pipeline sind in den nächsten 14 Tagen kritisch?

• Was ist der aktuelle Stand beim Account?

• Welche Follow-up-Aktion ist nach dem letzten Kundentermin sinnvoll?

• Welche offenen Tasks gibt es zu diesem Deal?

Ohne MCP wird diese Lücke häufig mit host-spezifischen Integrationen geschlossen: ein Chatbot bekommt einen eigenen Salesforce-Connector, ein Copilot einen anderen, ein Agent-Framework wieder einen dritten. Das erzeugt genau die Art von Integrationsfragmentierung, die MCP vermeiden soll: ein standardisierter Host-Client-Server-Ansatz mit wiederverwendbaren Capabilities statt mehrfach gebauter Punkt-zu-Punkt-Wrapper. MCP beschreibt dafür eine Architektur mit Hosts, Clients und Servern, in der Server spezialisierte Context- und Capability-Schnittstellen bereitstellen.

Ein sinnvoller Zuschnitt ist ein dedizierter MCP-Server „Sales-CRM“, der Salesforce nicht 1:1 durchreicht, sondern in vertriebsnahe Capabilities übersetzt. MCP-Server können standardisiert Resources, Tools und optional Prompts bereitstellen; genau diese Trennung ist für einen produktiven Sales-Use-Case entscheidend. Resources liefern lesbaren Kontext, Tools führen gezielte Aktionen aus, und Prompts können wiederverwendbare Vorlagen für typische Vertriebsaufgaben bereitstellen.

Resources könnten zum Beispiel sein:

• account://{accountId}/summary

• opportunity://{opportunityId}/snapshot

• pipeline://open-opportunities?owner={user}

Diese Resources liefern verdichteten, AI-tauglichen Kontext statt roher CRM-Daten. Der MCP-Server ruft dazu intern Salesforce-REST-Endpunkte auf, normalisiert die Antwort und stellt sie in einer Form bereit, die ein AI-Host direkt für Zusammenfassungen, Priorisierung oder Vorbereitung auf Kundentermine verwenden kann. Salesforce unterstützt diesen API-Zugriff über OAuth-geschützte REST-Schnittstellen und Connected Apps beziehungsweise External Client Apps.

Tools sollten enger und kontrollierter geschnitten sein, zum Beispiel:

• create_followup_task

• draft_opportunity_brief

• suggest_next_sales_action

• optional später: update_opportunity_stage

Hier ist wichtig: MCP-Tools sind bewusst so konzipiert, dass sie vom Modell entdeckt und aufgerufen werden können. Genau deshalb sollten produktive Sales-Tools nicht generisch formuliert sein wie „execute_salesforce_action“, sondern fachlich eng, mit klaren Input-Schemas, begrenzten Feldern und möglichst wenig Freitext. Die MCP-Spezifikation betont, dass Tools model-controlled sein können, empfiehlt aus Trust-&-Safety-Gründen aber ausdrücklich Human-in-the-loop mit der Möglichkeit, Tool-Aufrufe abzulehnen.

Ein typischer Ablauf sähe dann so aus:

1. Der Nutzer fragt im AI-Host nach einer Deal-Einschätzung für einen bestimmten Account.

2. Der Host ruft über den MCP-Client passende Resources vom Sales-CRM-Server ab.

3. Der MCP-Server aggregiert intern Salesforce-Daten, zum Beispiel Opportunity-Status, letzte Aktivitäten und offene Tasks.

4. Der Host erzeugt daraus eine Zusammenfassung oder Handlungsempfehlung.

5. Wenn eine Aktion wie ein Follow-up-Task sinnvoll erscheint, kann das Tool create_followup_task vorgeschlagen werden.

6. Vor dem tatsächlichen Ausführen wird die Aktion bestätigt.

Architektonisch ist das der eigentliche Vorteil: Salesforce wird einmal über einen fachlich geschnittenen MCP-Server integriert und kann dann von mehreren AI-Hosts wiederverwendet werden — etwa von einem internen Sales-Chat, einem Meeting-Assistant oder einer Agent-Runtime für Opportunity-Reviews. Das reduziert nicht die Existenz der Backend-Integration selbst, aber es standardisiert die AI-seitige Integrationsoberfläche.

Gerade im CRM-Kontext entscheidet nicht die Demo, sondern die Sicherheitsarchitektur über die Produktivtauglichkeit. Salesforce verlangt für API-Zugriffe eine OAuth-basierte Autorisierung über Connected Apps oder External Client Apps. Das ist für Enterprise-Szenarien hilfreich, weil sich darüber nicht nur Tokens beziehen, sondern auch Sicherheitsrichtlinien und Nutzungsgrenzen administrativ steuern lassen.

Für einen Sales-MCP-Server bedeutet das konkret:

1. Read-first statt Action-first
Der erste produktive Scope sollte fast immer read-only sein: Account-Zusammenfassungen, Opportunity-Snapshots, offene Aktivitäten, nächste Schritte. Schreibende Tools wie update_opportunity_stage oder create_followup_task sollten erst dann ergänzt werden, wenn Logging, Approval und Ownership sauber definiert sind. MCP erlaubt sowohl Context Retrieval über Resources als auch Action Paths über Tools; gerade deshalb ist die bewusste Trennung wichtig.

2. Least Privilege auf mehreren Ebenen
Nicht nur der Salesforce-Zugriff selbst, sondern auch der MCP-Server muss minimal privilegiert sein. Ein häufiger Fehler ist, dem Server breite Rechte zu geben und darauf zu vertrauen, dass der Host schon „vernünftig“ fragt. Das öffnet die Tür für Overprivileged Server und Confused-Deputy-Szenarien: Das Modell löst eine Aktion aus, die formal erlaubt ist, aber nicht im Interesse oder Berechtigungsrahmen des anfragenden Nutzers liegt. Die MCP-Architektur legt Sicherheitsverantwortung bewusst stark in Host und Server, nicht in das Protokoll selbst.

3. Kein Token Passthrough
MCP nennt Token Passthrough ausdrücklich ein Anti-Pattern. Ein MCP-Server soll keine Tokens blind vom Client annehmen und an Downstream-APIs wie Salesforce weiterreichen, sondern nur Tokens akzeptieren, die explizit für ihn ausgestellt und von ihm validiert wurden. Das ist besonders wichtig, wenn der Server im Namen des Nutzers mit CRM-Daten arbeitet.

4. Saubere Authorization-Integration
Für HTTP-basierte MCP-Server definiert die Spezifikation einen OAuth-basierten Autorisierungsansatz mit Discovery-Mechanismen über Protected Resource Metadata sowie Discovery nach RFC 8414 beziehungsweise OIDC Discovery. Das ist für Enterprise-Plattformen relevant, weil dadurch ein konsistenter, standardisierter Anbindungsweg an zentrale Identitäts- und Autorisierungssysteme möglich wird.

5. Human-in-the-loop für sensible Vertriebsaktionen
Auch wenn ein Modell Tools automatisch entdecken und anstoßen kann, sollten sensible Aktionen wie Task-Erstellung, Stage-Wechsel oder das Anlegen neuer CRM-Objekte bestätigt werden. MCP empfiehlt genau das: Der Nutzer soll Tool-Aufrufe sehen und ablehnen können. Für Sales ist das nicht nur Security-, sondern auch Prozessschutz, weil falsche oder verfrühte CRM-Aktionen direkt die Pipelinequalität beeinträchtigen.

Konkretes Risiko:
Das zentrale Risiko in diesem Use Case ist Confused Deputy. Wenn der Sales-MCP-Server mit privilegierten Rechten auf Salesforce arbeitet, kann ein unpassender Prompt, eine indirekte Prompt Injection oder eine fehlerhafte Tool-Entscheidung dazu führen, dass im CRM Aktionen im falschen Berechtigungsrahmen ausgeführt werden. Das Risiko steigt nochmals, wenn Tool-Beschreibungen zu offen sind oder der Server sowohl Lese- als auch Schreibrechte zu breit bündelt. Die wirksamsten Gegenmaßnahmen sind enge Tool-Schnittschnitte, Read-first, Human-Approval und strikt validierte OAuth-Grenzen.

Der Nutzen dieses Use Cases liegt nicht darin, dass „KI Vertrieb macht“, sondern darin, dass ein AI-Host kontextfähig und handlungsnah auf CRM-Daten zugreifen kann, ohne pro Oberfläche eine neue Integrationslogik zu benötigen.

Konkret entstehen vier Hebel:

1. Schnellere Vorbereitung auf Kundentermine
Statt mehrere Salesforce-Views manuell zu durchsuchen, bekommt der Nutzer eine verdichtete Sicht auf Account, Opportunity, letzte Aktivitäten und offene Risiken.

2. Bessere Wiederverwendung über mehrere AI-Hosts
Ein sauber geschnittener Sales-CRM-MCP-Server kann von Chat-Oberflächen, Assistants, IDE-nahen Tools oder Agent-Systemen genutzt werden. Genau diese Composability gehört zur Grundidee von MCP.

3. Höhere Konsistenz in Sales-Workflows
Wenn Summary-, Retrieval- und Action-Logik zentral im MCP-Server modelliert sind, werden Follow-up-Prozesse, Deal-Reviews und Account-Briefings standardisierter als bei verteilten Einzelintegrationen.

4. Bessere Kontrollierbarkeit als bei generischen Agent-Setups
Der AI-Host bekommt nicht „freien Salesforce-Zugriff“, sondern klar definierte Resources und Tools. Das reduziert Komplexität und verbessert Auditierbarkeit.

Der realistische Reifegrad für den Einstieg ist daher:

• Phase 1: reine Read-Use-Cases

• Phase 2: vorgeschlagene Aktionen mit Bestätigung

• Phase 3: selektive, streng kontrollierte Action-Tools

Genau in dieser Reihenfolge wird aus einem CRM-Connector kein Demo-Gimmick, sondern ein belastbarer Enterprise-Use-Case für MCP.

In vielen IT-Organisationen ist nicht der Ticketzugang das eigentliche Problem, sondern die operative Reibung rund um den Ticketprozess. Es gibt zu viele eingehende Anfragen, uneinheitliche Beschreibungen, unvollständige Pflichtfelder und wiederkehrende Standardprobleme, die trotzdem immer wieder manuell eingeordnet werden müssen.

Typische Symptome in der Praxis sind:

• Tickets werden mit zu wenig Kontext erstellt

• ähnliche Incidents werden unterschiedlich klassifiziert

• Service Desk Agents verbringen Zeit mit Copy-and-Paste-Arbeit statt mit Problemlösung

• vorhandene Knowledge-Artikel werden nicht konsistent genutzt

• Eskalationen erfolgen zu früh, zu spät oder an die falschen Teams

Das führt zu längeren Bearbeitungszeiten, höherem Abstimmungsaufwand und sinkender Datenqualität im ITSM-System. Ein klassischer Chatbot hilft hier nur begrenzt, weil er ohne saubere Systemanbindung weder belastbare Kontexte abrufen noch kontrolliert Aktionen ausführen kann.

Ein MCP-Server „ITSM“ kapselt die ServiceNow Table API und stellt dem AI-Host eine klar definierte Menge an Resources und Tools zur Verfügung. Wichtig ist dabei: Der MCP-Server exponiert nicht pauschal das gesamte ITSM-System, sondern nur die für den Use Case relevanten Fähigkeiten.

Resources:

• bestehende Tickets mit begrenztem Feldumfang

• Knowledge-Artikel

• Service-Katalogeinträge

• Statusinformationen zu Incidents, Requests oder Changes

Tools:

• create_incident

• draft_incident_from_chat

• classify_ticket

• suggest_assignment_group

• update_ticket

• link_related_knowledge_article

Ein typischer Ablauf sieht so aus:

1. Ein Nutzer schildert ein Problem im AI-Host, etwa: „Mein Laptop verbindet sich seit heute nicht mehr mit dem VPN.“

2. Der Host ruft über den MCP-Server passende Knowledge-Artikel, ähnliche historische Tickets und relevante Servicedaten ab.

3. Das Modell erzeugt auf dieser Basis einen strukturierten Ticket-Entwurf mit Kategorie, Priorität, Kurzbeschreibung und technischer Zusammenfassung.

4. Der Nutzer prüft den Entwurf.

5. Erst nach Bestätigung wird über ein Tool wie create_incident ein Incident in ServiceNow angelegt.

Damit entsteht eine saubere Trennung zwischen:

• Kontextbeschaffung über Resources

• Entscheidungsunterstützung durch das Modell

• Systemaktion über kontrollierte Tools

Architektonisch ist das deutlich belastbarer als ein freies Agentensystem, das direkt mit weitreichenden Rechten auf das ITSM-System zugreift.

Gerade im ITSM-Kontext ist Governance entscheidend, weil Tickets nicht nur Dokumentation sind, sondern operative Prozesse auslösen können. Falsch erzeugte oder falsch priorisierte Tickets verursachen reale Folgekosten: Fehlzuweisungen, unnötige Eskalationen, SLA-Verletzungen oder fehlerhafte Changes.

Deshalb sollte ein MCP-basierter ITSM-Co-Pilot mindestens folgende Leitplanken haben:

• Aktionen immer im Namen des berechtigten Users oder einer klar eingeschränkten Service-Identität

• Least Privilege für alle Tool-Aufrufe

• Read-only als erste Ausbaustufe

• Pflicht zur User-Bestätigung vor create– oder update-Aktionen

• vollständiges Audit-Logging für alle tools/call-Operationen

• serverseitige Validierung aller Eingaben gegen feste Schemas

• klare Begrenzung, welche Felder automatisch gesetzt werden dürfen

Besonders relevant ist hier das Risiko des Confused Deputy. Das entsteht, wenn der MCP-Server mit breiteren Rechten arbeitet als die anfragende Person selbst. Dann könnte ein Nutzer indirekt Aktionen auslösen, die er im nativen ServiceNow-Frontend gar nicht durchführen dürfte. Genau dieses Muster muss architektonisch verhindert werden, etwa durch sauberes Identity Mapping, Scope-Begrenzung und explizite Policy-Prüfungen vor jedem Action-Tool-Call.

Ein zweites Risiko liegt in Tool Poisoning oder fehlerhaften Klassifikationen. Wenn Tool-Beschreibungen, Eingabefelder oder externe Ticketinhalte manipulativ wirken, kann das Modell falsche Prioritäten oder Assignment Groups vorschlagen. Deshalb müssen sowohl Tool-Schemas als auch Rückgabewerte serverseitig validiert und sensible Felder restriktiv behandelt werden.

Der Nutzen eines MCP-basierten ITSM-Co-Piloten liegt nicht darin, den Service Desk vollständig zu automatisieren. Der eigentliche Mehrwert entsteht durch bessere Vorstrukturierung, konsistentere Dateneingabe und schnellere operative Bearbeitung.

Konkret ergeben sich typischerweise diese Effekte:

• Tickets werden vollständiger und konsistenter erfasst

• ähnliche Probleme werden einheitlicher klassifiziert

• Knowledge-Artikel werden systematischer eingebunden

• First-Level-Teams werden bei Standardfällen spürbar entlastet

• Routing und Priorisierung werden belastbarer vorbereitet

• mehrere AI-Hosts können dieselbe ITSM-Fähigkeit wiederverwenden, ohne jeweils eigene Integrationen zu bauen

Der Use Case ist deshalb strategisch interessant, weil er einen guten Einstiegspunkt für MCP im Enterprise bietet: hoher operativer Nutzen, klar abgegrenzte Prozesse, vorhandene Rollenmodelle und eine gute Möglichkeit, mit read-orientierten oder assistiven Szenarien zu starten, bevor echte Schreib- und Automatisierungsrechte freigegeben werden.

Beschaffungs- und ERP-Prozesse gehören zu den Bereichen, in denen Unternehmen besonders stark unter Systemkomplexität leiden. Informationen zu Lieferanten, Bestellungen, Materialverfügbarkeiten, Freigaben oder Rechnungsstatus liegen zwar im ERP vor, sind aber für Fachbereiche oft nur mit erheblichem Aufwand nutzbar.

Typische Probleme in der Praxis:

• Einkäufer müssen Informationen aus mehreren SAP-Transaktionen, Fiori-Apps oder angebundenen Systemen zusammensuchen

• Rückfragen wie „Ist dieser Lieferant freigegeben?“, „Wie ist der Status der Bestellung?“ oder „Welche Bestellanforderungen warten auf Genehmigung?“ sind operativ häufig, aber manuell aufwendig

• ERP-Oberflächen sind für strukturierte Prozessbearbeitung optimiert, nicht für schnelle, kontextbezogene Exploration

• Fachanwender benötigen oft nur einen klar abgegrenzten Ausschnitt der ERP-Realität, erhalten aber Zugriff über generische, komplexe Oberflächen

Gerade im Procurement entsteht dadurch ein Produktivitätsproblem: Nicht die Daten fehlen, sondern ein kontrollierter, domänengerechter Zugang zu genau den Informationen und Aktionen, die im jeweiligen Arbeitsschritt benötigt werden.

Ein MCP-Server kapselt SAP S/4HANA OData APIs und stellt daraus klar definierte Tools und Resources für AI-Hosts bereit. Der zentrale Gedanke ist: Das LLM spricht nicht direkt mit SAP, sondern über eine kontrollierte Integrationsschicht, die Fachlogik, Validierung und Sicherheitsregeln durchsetzt.

Resources können zum Beispiel bereitstellen:

• Lieferantenstammdaten in reduziertem, fachlich sinnvollem Umfang

• Statusinformationen zu Bestellungen oder Bestellanforderungen

• Freigaberelevante Metadaten

• referenzierbare ERP-Dokumente oder Objektzusammenfassungen

Tools können z. B. sein:

• check_supplier_status

• get_purchase_order_summary

• list_pending_approvals

• create_purchase_request

• draft_supplier_inquiry

Wichtig ist die Trennung zwischen lesenden und schreibenden Fähigkeiten. Ein sinnvoller Einstieg ist ein read-first-Modell: Der MCP-Server liefert zunächst nur lesende Funktionen, etwa für Lieferantenstatus, Bestellhistorie oder offene Freigaben. Erst in einem zweiten Reifegrad werden action-fähige Tools ergänzt, beispielsweise zum Anlegen einer Bestellanforderung oder zum Starten eines Freigabeprozesses.

Für längere oder systemübergreifende Prozesse eignet sich ein asynchrones Modell über MCP Tasks. Ein Beispiel:

• User stößt per Assistent eine Bestellanforderung an

• der MCP-Server validiert Parameter und erstellt einen Draft

• die eigentliche Genehmigung läuft in SAP oder einer Workflow-Engine

• der Status wird später über Task-Mechanismen oder nachgelagerte Abfragen zurückgegeben

So bleibt MCP die AI-seitige Interaktionsschicht, während das ERP weiterhin System of Record und Prozessautorität bleibt.

Im Procurement ist MCP nur dann sinnvoll, wenn Sicherheits- und Governance-Fragen von Anfang an mitgedacht werden. Einkauf, Lieferantenmanagement und ERP-Stammdaten sind hochsensibel: Schon lesende Zugriffe können kritisch sein, schreibende Zugriffe erst recht.

Deshalb sollten folgende Kontrollen gesetzt werden:

• strikt definierte Tool-Schemas: keine freien Eingabefelder für kritische Aktionen, sondern klar begrenzte Parameter, Enums und Pflichtvalidierungen

• Elicitation für sensible Aktionen: bevor eine Bestellanforderung angelegt oder ein Prozess gestartet wird, muss der Nutzer aktiv bestätigen

• Freigabelogik außerhalb des LLM: Genehmigungen dürfen nicht vom Modell „entschieden“ werden, sondern müssen in SAP oder in einer dedizierten Workflow-Engine abgebildet sein

• Least Privilege: der MCP-Server darf nur genau die SAP-Berechtigungen besitzen, die für seinen Scope erforderlich sind

• vollständiges Audit-Logging: nachvollziehbar muss sein, welcher Nutzer welche Anfrage gestellt hat, welches Tool aufgerufen wurde und welche SAP-Aktion daraus entstanden ist

Ein zentrales Risiko in diesem Use Case sind falsche oder unerwünschte Aktionen. Das kann durch Prompt Injection, fehlerhafte Parametrisierung, zu breite Berechtigungen oder unzureichend validierte Eingaben entstehen. Kritisch wird es vor allem dann, wenn ein MCP-Server mit generischen ERP-Rechten arbeitet und damit faktisch zum überprivilegierten Gateway wird. Genau deshalb sollte Procurement nicht mit „freien ERP-Aktionen“ starten, sondern mit eng begrenzten, fachlich spezifischen Tools.

Der Nutzen dieses Use Cases liegt nicht darin, SAP zu ersetzen, sondern SAP gezielt besser nutzbar zu machen.

Konkret entsteht Mehrwert durch:

• schnelleren Zugriff auf operative Beschaffungsinformationen

• weniger Reibung bei Standardanfragen zu Lieferanten, Bestellungen und Freigaben

• konsistente Bereitstellung derselben Procurement-Fähigkeiten über mehrere AI-Hosts hinweg

• geringere Abhängigkeit von einzelnen SAP-Oberflächen für Routinefragen

• kontrollierte Automatisierung bei klar abgegrenzten Aktionen

Strategisch ist dieser Use Case besonders relevant, weil er gut zeigt, was MCP im Enterprise-Kontext leisten kann: nicht „KI direkt auf ERP“, sondern eine standardisierte, auditierbare und domänenspezifische Zugangsschicht zu einem der sensibelsten Kernsysteme im Unternehmen.

Finance- und Controlling-Teams arbeiten typischerweise mit einer Mischung aus BI-Reports, Data Warehouses, Data Lakes und operativen Quellsystemen. Die eigentliche Herausforderung ist dabei selten nur der Datenzugriff, sondern die Frage, wie Analysen reproduzierbar, belastbar und governance-konform in KI-gestützte Workflows eingebunden werden.

Typische Probleme in der Praxis:

• Kennzahlen liegen in verschiedenen Systemen und Formaten vor

• Fachbereiche stellen Ad-hoc-Fragen, die nicht direkt in Standardreports beantwortet werden

• Analysten verbringen viel Zeit mit wiederkehrenden Datenabfragen

• KI-Antworten wirken plausibel, sind aber ohne Datenherkunft kaum prüfbar

• Freie Datenbankabfragen erhöhen das Risiko von Fehlinterpretationen, Performance-Problemen und Datenabfluss

Gerade im Finance-Kontext ist das kritisch: Eine sprachlich gute Antwort reicht nicht aus. Es muss nachvollziehbar bleiben, welche Datenbasis verwendet wurde, welche Logik angewendet wurde und ob die Antwort regulatorisch und fachlich belastbar ist.

Ein MCP-Server „Finance-Data“ kapselt den Zugriff auf die relevanten Datenplattformen und stellt klar definierte Analysefähigkeiten zur Verfügung. Typische Backend-Systeme sind:

• Snowflake für strukturierte Analyse- und Reporting-Daten

• S3 oder ADLS für Reports, Exporte, Forecast-Dateien oder Monatsabschlüsse

• optional weitere Quellen wie semantische Layer, KPI-Views oder BI-nahe Datenmodelle

Der entscheidende Punkt: Der MCP-Server stellt keinen generischen SQL-Zugang für das Modell bereit, sondern eine kontrollierte Menge an Tools und Resources.

Beispiel für Resources:

• Monatsreport als Datei oder referenzierte Ressource

• Definitionen von KPIs und Kennzahlen

• Forecast- oder Budget-Dokumente

• Datenkatalogeinträge zu freigegebenen Finance-Datasets

Beispiel für Tools:

• get_revenue_by_region

• get_budget_vs_actual

• get_margin_deviation

• get_top_cost_drivers

• fetch_latest_finance_report

Statt freier Abfragen nutzt der Host damit klar definierte Analysepfade. Das reduziert Interpretationsspielraum und erleichtert die Wiederverwendung über mehrere AI-Hosts hinweg, etwa in Chat-Interfaces, Analysten-Assistants oder Management-Copilots.

Ein robustes Zielbild sieht so aus:

• Das LLM formuliert die Nutzerfrage semantisch

• der MCP-Server mappt die Anfrage auf freigegebene Analysefunktionen oder vordefinierte Views

• die Ergebnisse werden als structured content zurückgegeben, etwa als JSON mit Kennzahlen, Dimensionen, Zeitraum und Quelle

• zusätzlich werden Referenzen auf Reports, Tabellen oder Dokumente geliefert, damit Aussagen überprüfbar bleiben

So entsteht ein Setup, in dem die KI nicht „frei über Daten fantasiert“, sondern auf einen kontrollierten analytischen Pfad geführt wird.

Gerade in Finance ist dieser Use Case nur dann sinnvoll, wenn Governance von Anfang an mitgedacht wird. Finanzdaten sind oft sensitiv, interpretationsabhängig und in vielen Unternehmen regulatorisch relevant. Deshalb sollte der MCP-Server strikt auf kontrollierte Query-Policies ausgerichtet sein.

Wichtige Kontrollmechanismen:

• nur freigegebene Views, keine freien SQL-Statements

• rollenbasierter Zugriff auf Kennzahlen, Regionen, Gesellschaften oder Kostenstellen

• Ausgaben nur in definierten Formaten

• Limits für Zeilenmengen, Zeiträume und Abfragekomplexität

• Trennung zwischen Analyse-Use-Cases und administrativen Datenoperationen

Auch Logging spielt hier eine zentrale Rolle. Nicht nur der Tool-Call selbst sollte nachvollziehbar sein, sondern auch:

• wer die Anfrage ausgelöst hat

• welche freigegebene Analysefunktion genutzt wurde

• auf welchen Datenstand sich die Antwort bezieht

• welche Ressource oder welcher Report referenziert wurde

Risiko:
Das größte Risiko ist nicht nur Halluzination, sondern Sensitive Data Exposure durch unkontrollierte oder zu breit definierte Queries. Ein zweites Risiko liegt in der Scheingenauigkeit: Wenn das Modell Ergebnisse sprachlich überzeugend zusammenfasst, aber die zugrunde liegende Datenlogik nicht sauber begrenzt wurde, entsteht schnell fachlich falsche Sicherheit.

Deshalb gilt im Finance-Kontext besonders:
Nicht das Modell darf definieren, wie gerechnet wird, sondern die Plattform und das Fachmodell müssen den zulässigen Rechen- und Datenraum vorgeben.

Richtig umgesetzt, ist dieser Use Case einer der wertvollsten MCP-Anwendungsfälle im Enterprise-Umfeld, weil er einen echten Schmerzpunkt adressiert: den Spagat zwischen Self-Service, Kontrolle und Nachvollziehbarkeit.

Konkreter Nutzen:

• schnellere Beantwortung typischer Finance-Fragen

• weniger manuelle Standardanalysen durch Analysten

• konsistente Nutzung freigegebener KPI-Definitionen

• bessere Nachvollziehbarkeit durch strukturierte Ergebnisse und Quellenbezug

• geringeres Halluzinationsrisiko als bei rein promptbasierten Auswertungen

Besonders stark wird der Use Case dort, wo Fachbereiche regelmäßig Fragen stellen wie:

• „Wie entwickelt sich die Marge im Vergleich zum Vorquartal?“

• „Welche Regionen weichen aktuell am stärksten vom Budget ab?“

• „Welche Kostenblöcke treiben die Abweichung im Monatsabschluss?“

Mit MCP lässt sich daraus ein kontrollierter Analysepfad machen, bei dem die KI nicht das Controlling ersetzt, sondern den Zugang zu verlässlichen Finance-Informationen beschleunigt. Genau darin liegt der eigentliche Mehrwert: nicht in maximaler Autonomie, sondern in schnellerer, sicherer und besser prüfbarer Analyse.

HR-Teams bearbeiten in vielen Unternehmen eine große Zahl wiederkehrender Anfragen, die fachlich oft nicht komplex, operativ aber zeitintensiv sind. Typische Beispiele sind Fragen zu Urlaubsregelungen, Krankmeldungen, Elternzeit, Reisekosten, Arbeitszeitmodellen, Onboarding-Dokumenten oder internen Richtlinien. Die Informationen liegen meist bereits vor, aber verteilt über SharePoint, Intranets, PDF-Dokumente, Wissensdatenbanken oder Workflow-Systeme.

Das eigentliche Problem ist deshalb selten fehlendes Wissen, sondern fehlender kontrollierter Zugriff auf genau die Informationen, die im jeweiligen Kontext relevant sind. Ohne saubere Architektur entstehen schnell zwei Extreme: Entweder bleibt HR-Self-Service zu statisch und unflexibel, oder eine KI erhält zu breiten Zugriff auf personenbezogene Inhalte und erzeugt neue Datenschutz- und Governance-Risiken.

Ein MCP-Server kann im HR-Kontext als gezielte Vermittlungsschicht zwischen AI-Host und den relevanten Unternehmenssystemen fungieren. Typischerweise bindet ein „HR-Docs“-Server SharePoint oder OneDrive über Microsoft Graph an und stellt freigegebene Richtlinien, Handbücher, FAQ-Dokumente und Prozessbeschreibungen als Resources bereit.

Beispiele für Resources sind:

• Urlaubsrichtlinien

• Onboarding-Handbücher

• Benefits-Übersichten

• Reisekostenrichtlinien

• interne Formulare und Prozessdokumentationen

Darüber hinaus können ausgewählte Tools bereitgestellt werden, allerdings sehr kontrolliert und mit engem Scope. Statt direkt operative HR-Transaktionen auszulösen, sind zunächst eher vorbereitende oder assistierende Funktionen sinnvoll, etwa:

• draft_leave_request

• prepare_hr_case

• collect_required_documents

• start_workflow_intent

Die eigentliche Aktion, zum Beispiel ein Urlaubsantrag, eine Bescheinigungsanforderung oder ein HR-Ticket, wird dann nicht direkt im MCP-Server „fertig entschieden“, sondern an eine Workflow-Engine wie Camunda, ServiceNow oder ein internes HR-System übergeben. Das MCP-Modell eignet sich hier besonders gut, weil es Read-Pfade und Action-Pfade sauber trennt: Dokumente und Richtlinien werden als Resources eingebunden, während kontrollierte Prozessschritte über Tools angestoßen werden.

Ein realistisches Zielbild ist daher:

• SharePoint/OneDrive liefern Richtlinien und Dokumentenkontext

• der MCP-Server macht diesen Kontext AI-nutzbar

• der AI-Host formuliert Antworten oder bereitet Anträge vor

• eine Workflow-Engine übernimmt Genehmigung, Statuslogik und Nachverfolgung

So bleibt die KI in einer assistierenden Rolle, während verbindliche Entscheidungen und Transaktionen in den dafür vorgesehenen Fachsystemen verbleiben.

Im HR-Bereich ist Governance kein Zusatz, sondern Kern des Use Cases. Schon scheinbar harmlose Fragen können in personenbezogene oder vertrauliche Kontexte kippen. Deshalb muss die Architektur konsequent nach dem Prinzip der Datenminimierung gestaltet werden.

Das bedeutet konkret:

• Der MCP-Server sollte standardmäßig nur freigegebene HR-Dokumente und allgemeine Policies exponieren.

• Personenbezogene Daten dürfen nur in eng definierten Fällen und mit klarer Berechtigungsprüfung eingebunden werden.

• Logs dürfen keine sensiblen Mitarbeiterdaten, Gesundheitsinformationen oder vertraulichen Inhalte enthalten.

• Consent und Rollenprüfung müssen klar regeln, wann der Host welchen Kontext an den MCP-Server weitergeben darf.

Gerade im HR-Self-Service ist der Unterschied zwischen Dokumentenwissen und Personaldatenzugriff entscheidend. Eine KI darf etwa die Urlaubsrichtlinie erklären, ohne Zugriff auf die gesamte Personalakte zu benötigen. Sobald jedoch individuelle Anfragen betroffen sind, etwa Resturlaub, Vertragsinformationen oder Krankheitsdaten, müssen Berechtigungen, User-Kontext und Freigaben wesentlich strenger behandelt werden.

Ein weiteres Risiko liegt in der Vermischung von Policy-Auskunft und Prozessauslösung. Wenn ein Assistent nicht nur Regeln erklärt, sondern auch Anträge vorbereitet oder Workflows anstößt, braucht es klare Kontrollpunkte:

• Human-in-the-loop bei sensiblen Aktionen

• strikte Tool-Schemas ohne Freitext-Exzesse

• saubere Trennung von Draft und verbindlicher Einreichung

• revisionsfähige Audit-Events für gestartete Prozesse

Risiko:
Der zentrale Risikofaktor ist unkontrollierter Zugriff auf personenbezogene Daten oder sensible HR-Kontexte. Schon ein technisch funktionierender, aber zu breit privilegierter HR-MCP-Server wäre aus Datenschutz- und Compliance-Sicht problematisch.

Richtig umgesetzt, ist dieser Use Case einer der pragmatischsten MCP-Anwendungsfälle im Enterprise-Umfeld. Der Nutzen entsteht vor allem dort, wo viele wiederkehrende Anfragen mit klarem Regelwerk beantwortet werden können, ohne dass jedes Mal ein HR-Mitarbeiter manuell eingreifen muss.

Der Mehrwert liegt in mehreren Ebenen:

• Mitarbeiter erhalten schneller verlässliche Antworten auf standardisierte HR-Fragen.

• HR-Teams werden von wiederkehrenden Informationsanfragen entlastet.

• Dokumentierte Richtlinien werden konsistenter genutzt, weil der Zugriff kontextbezogen und nicht nur über manuelle Suche erfolgt.

• Prozesse wie Urlaubsanträge oder Dokumentenanforderungen können vorbereitet werden, ohne sofort eine Vollautomatisierung zu erzwingen.

Besonders wichtig ist: Dieser Use Case ist realistisch, weil er nicht mit „autonomer HR-KI“ beginnt, sondern mit einem kontrollierten Self-Service-Modell. Genau deshalb eignet er sich gut für eine MCP-Einführung: hoher operativer Nutzen, klarer Dokumentenbezug und die Möglichkeit, Governance von Anfang an sauber mitzudenken.