MCP, Function Calling, Code Execution: KI mit Unternehmenstools verbinden

So leistungsfähig moderne Modelle sind, auf CRM, Wissensdatenbanken, Übersetzungssysteme, Data Warehouses oder E-Mail-Plattformen haben sie keinen direkten Zugriff. Damit KI echten Mehrwert schafft, muss sie zuerst mit diesen Systemen verbunden werden.

Die richtige Frage kommt zuerst

In den vergangenen Monaten haben wir viele Gespräche mit Unternehmen geführt, die KI-Anwendungen planen oder erste Projekte bewerten. Fast immer drehten sich die ersten Fragen um Technik: Welche Technologien kommen infrage, wie werden bestehende Systeme angebunden, welche Architektur ist die richtige? Das sind wichtige Fragen. Am Anfang steht aber eine andere Überlegung, die mit Frameworks und Standards wenig zu tun hat: Wer nutzt das System, welche Aufgaben soll es übernehmen, wie oft und unter welchen organisatorischen und sicherheitsrelevanten Bedingungen?

Was KI-Tool-Integration eigentlich bedeutet

Ein KI-Modell wie GPT, Claude oder Gemini hat von Haus aus keinen Zugriff auf die Daten, Systeme oder Prozesse eines Unternehmens. Es verfügt über viel allgemeines Wissen, kennt aber weder Ihre Kunden noch Ihre Produkte oder internen Abläufe.

Man kann es mit einer neuen Kollegin am ersten Arbeitstag vergleichen: fachlich hervorragend, aber noch ohne Zugang zu den Werkzeugen und Informationen für die tägliche Arbeit. Erst mit Zugriff auf CRM, Wissensdatenbank und andere Anwendungen wird dieses Potenzial nutzbar. Genau das leistet KI-Integration. Sie verbindet Modelle mit den Datenquellen, Anwendungen und Prozessen eines Unternehmens und macht sie handlungsfähig. Dafür gibt es mehrere Wege, jeder mit eigenen Stärken, Grenzen und Sicherheitsanforderungen.

Die Ansätze im Detail

In der Praxis haben sich fünf Ansätze etabliert. Drei davon bilden die Grundlage der meisten produktiven Architekturen, zwei weitere kommen seltener zum Einsatz, können aber in bestimmten Situationen entscheidend sein.

Function Calling

Beim Function Calling legt das Entwicklungsteam fest, welche Aktionen die KI ausführen darf, etwa einen Bestellstatus abrufen, Kundendaten suchen oder einen Bericht versenden. Für jede Funktion werden Eingaben, Ausgaben, Berechtigungen und Geschäftsregeln definiert. Das Modell erhält die Liste der verfügbaren Funktionen und entscheidet im Gespräch, welche zur Anfrage passt. Die Ausführung bleibt vollständig unter der Kontrolle der Anwendung.

Der größte Vorteil ist die Vorhersehbarkeit: Alles, was die KI tun kann, wurde vorher definiert, geprüft und implementiert. Deshalb wählen Unternehmen Function Calling oft als ersten Ansatz. Solange die Zahl der Funktionen überschaubar bleibt, ist er schnell umgesetzt und einfach zu betreiben. Er bewährt sich besonders bei Chatbots, internen Assistenten und geschlossenen Anwendungen, in denen Sicherheit, Nachvollziehbarkeit und Geschäftsregeln wichtiger sind als maximale Flexibilität.

• Stärken: volle Kontrolle über jedes Detail, leicht zu auditieren, weil alle Tools im Anwendungscode liegen und den normalen Code-Review durchlaufen, geringe Latenz, nachvollziehbare Entscheidungen.
• Grenzen: Jede neue Integration ist ein eigenes Entwicklungsprojekt. Vorhandene Integrationen etwa für Slack, Notion oder GitHub lassen sich nicht wiederverwenden, und Integrationscode für einen Modellanbieter lässt sich nicht immer auf einen anderen übertragen.

Model Context Protocol (MCP)

MCP ist am besten als universeller Verbindungsstandard für KI-Anwendungen zu verstehen. So wie USB Geräte mit Computern verbindet, bindet MCP Software einheitlich an KI-Assistenten an. Anthropic hat den Standard 2024 vorgestellt, inzwischen unterstützen ihn auch OpenAI, Google und Microsoft. Anbieter wie Slack, Notion, GitHub, SAP oder Atlassian veröffentlichen zunehmend offizielle MCP-Server, die unterschiedliche KI-Clients nutzen können. MCP wird damit zum gemeinsamen Integrationsstandard der KI-Welt, ähnlich wie REST-APIs es lange für klassische Software waren.

MCP funktioniert in beide Richtungen:

• Fertige MCP-Server: Der häufigste Fall. Existiert die benötigte Integration schon, lässt sie sich oft in wenigen Stunden einbinden.
• Eigene MCP-Server: Strategisch interessanter. Ein Unternehmen stellt CRM, ERP oder Data Warehouse einmal als MCP-Server bereit, und verschiedene KI-Anwendungen wie Claude, Copilot oder Cursor nutzen ihn gemeinsam. Gerade in großen Organisationen spart das doppelte Entwicklungsarbeit, weil dieselbe ERP-Integration nicht für jedes KI-Projekt neu gebaut wird.

MCP eignet sich, wenn mehrere KI-Anwendungen auf dieselben Systeme zugreifen oder mehrere Teams parallel KI-Lösungen bauen, und wenn es für eine SaaS-Anwendung bereits einen offiziellen Server gibt. Wer Integrationen einmal bauen und lange wiederverwenden will, schafft mit einer gemeinsamen Integrationsschicht die zukunftssicherste Grundlage.

• Stärken: Interoperabilität, ein wachsendes Angebot fertiger Integrationen, eine Integration für mehrere KI-Clients, langfristige architektonische Flexibilität.
• Grenzen: höhere betriebliche Komplexität, eine größere Angriffsfläche, die bewusste Sicherheitsarbeit verlangt, und schwankende Qualität: Offizielle Server großer Anbieter sind meist solide, viele Community-Projekte wirken noch wie Prototypen.

Code Execution

Bei Code Execution erhält die KI keine vordefinierte Funktionsliste, sondern eine sichere, isolierte Ausführungsumgebung, in der sie selbst Code schreibt und ausführt. Das passt zu datenintensiven, analytischen Aufgaben: große CSV-Dateien auswerten, umfangreiche Dokumentensammlungen verarbeiten, Daten aus verschiedenen Quellen extrahieren und bereinigen oder komplexe Tabellen umformen. Statt für jeden Schritt ein eigenes Tool aufzurufen, erzeugt das Modell den nötigen Code selbst. Seine Stärken spielt der Ansatz aus, wenn die Arbeitsschritte zu vielfältig oder zu dynamisch für eine feste Funktionsliste sind.

• Stärken: hohe Flexibilität, die Daten müssen nicht durch den Kontext des Modells fließen, was Kosten und Latenz im Rahmen hält, und der Code kann seinerseits Funktionen oder MCP-Server aufrufen.
• Grenzen: braucht eine sichere Sandbox, ist schwerer zu debuggen und setzt ein Modell voraus, das gut programmiert. Die besten heutigen Modelle können das, es verlangt aber sorgfältiges Prompt Engineering.

Anbindung über API-Dokumentation

Die KI erhält die Beschreibung einer Schnittstelle, etwa als OpenAPI-Spezifikation, und erzeugt die API-Aufrufe selbst. Das eignet sich für schnelle Integrationen in einer einzelnen Anwendung mit sauberer API-Beschreibung. Der Ansatz verliert allerdings an Bedeutung, weil viele Unternehmen aus denselben Spezifikationen heute direkt MCP-Server erzeugen.

Computer Use

Hier bedient die KI die Benutzeroberfläche direkt wie ein Mensch: Sie klickt Schaltflächen, füllt Formulare aus und navigiert durch Anwendungen. Das ist langsamer und weniger zuverlässig als eine Integration über Schnittstellen, für ältere Systeme ohne moderne API aber manchmal die einzige Option. In den meisten Unternehmen ist Computer Use deshalb eine Brücke bis zur Modernisierung.

Wie Sie entscheiden, was am besten passt

Jede belastbare Architekturentscheidung lässt sich an fünf Kriterien festmachen. Keines davon ist rein technisch, sie betreffen Nutzung, Organisation und Governance.

Selten führt diese Analyse zu einer einzigen richtigen Architektur. Meist ergibt sich eine Kombination, und genau so sehen moderne KI-Systeme aus.

Hybrid ist die Norm

Reife Enterprise-KI-Architekturen kombinieren 2026 MCP und Function Calling bewusst und ergänzen Code Execution für große Datenmengen. Ein einzelner KI-Agent nutzt oft mehrere Integrationsschichten gleichzeitig, je nach Aufgabe und Kontext.

Daraus lassen sich einige Leitlinien ableiten:

• Mit der einfachsten Lösung beginnen, die das Problem zuverlässig löst, und Komplexität erst bei konkretem Bedarf erhöhen.
• Die Architektur von Anfang an so anlegen, dass sie wachsen kann, ohne bestehende Integrationen neu zu schreiben.
• Klar festlegen, wie der Agent Tools aufruft, wie diese autorisiert werden und wie Daten durch das System fließen.
• Jede Aktion beobachtbar machen: was ausgeführt wurde, wann, im Auftrag welcher Nutzeridentität und mit welchem Ergebnis. Das erleichtert das Debugging und schafft Vertrauen im Betrieb.

Was ist mit der Sicherheit?

Im Unternehmen entscheidet Sicherheit oft darüber, ob ein KI-Projekt überhaupt umgesetzt wird. Dabei ist Sicherheit eine Eigenschaft der gesamten Architektur um den Integrationsansatz herum. MCP ist nicht per se unsicherer als Function Calling, es braucht andere Schutzmechanismen. Jeder Ansatz hat sein eigenes Risikoprofil und verlangt passende Kontrollen: klare Zuständigkeiten, nachvollziehbare Berechtigungen, kontrollierte Tool-Aufrufe und volle Transparenz darüber, welche Aktionen die KI auf welcher Grundlage ausführt.

Risiken gibt es immer. Entscheidend ist, ob sie sich klar benennen, realistisch einschätzen und dem Sicherheitsteam mit einem belastbaren Maßnahmenplan vorlegen lassen. Wie Berechtigungen, Menschen im Ablauf und Betriebsmodelle zusammenspielen, beschreibt unser Artikel KI integrieren in SAP, Microsoft 365 und Jira.

Die richtige Frage zuerst

KI mit Unternehmenssystemen zu verbinden, bedeutet heute, mehrere Ansätze bewusst zu kombinieren. Function Calling, MCP und Code Execution bilden unterschiedliche Schichten einer Architektur und beantworten jeweils andere Anforderungen. Die besten Umsetzungen, die wir in den vergangenen Monaten gesehen haben, kombinieren alle drei gezielt, abhängig von der Situation der Organisation.

Am Anfang stehen die geschäftlichen Fragen: Wer nutzt das System, welche Aufgaben soll es übernehmen, wie oft wird es eingesetzt, und unter welchen organisatorischen und sicherheitsrelevanten Bedingungen? Daraus ergibt sich die technische Architektur. Die Technologie ist verfügbar, die eigentliche Arbeit liegt darin, diese Fragen vor der Umsetzung zu stellen. Wie wir Agenten mit Unternehmenssystemen bauen, zeigt unsere Seite zur KI-Agenten-Entwicklung.

Häufige Fragen