Das große Namens-Wirrwarr der KI-Branche
Wer dieser Tage Fachartikel über KI-Integration liest, braucht starke Nerven und ein gutes Gedächtnis. Ein Microsoft-Beitrag erklärt, warum Connectors der Schlüssel zur Unternehmens-KI sind. Ein Anthropic-Blogpost wirbt für Skills. Ein OpenAI-Entwickler-Tutorial dreht sich um Actions. Und ein Google-Whitepaper handelt von Function Calling. Auf den ersten Blick klingt das nach demselben Konzept in vier verschiedenen Verpackungen. Auf den zweiten Blick zeigt sich: Die Begriffe liegen auf grundlegend unterschiedlichen Ebenen. Anthropic-Skills sind wiederverwendbare Fähigkeitsbausteine, die schon durch eine einzige Datei entstehen können. OpenAI Actions und Googles Function Calling beschreiben ausführbare Schnittstellen zu externen Systemen. Microsoft Connectors stehen für Daten- und Inhaltsanbindung. Der Witz bleibt, aber die Unterschiede sind real.
Willkommen in der Nomenklatur-Hölle der KI-Plattformen 2026.
Wer eine informierte Entscheidung darüber treffen will, wie er KI in seine Arbeitsprozesse einbettet, steht vor einem Problem, das gar nichts mit Technik zu tun hat: Er muss erst einmal herausfinden, ob das, was Anbieter A „Plugin“ nennt, dasselbe ist wie das, was Anbieter B „Extension“ nennt. Meistens ist es das nicht. Manchmal aber schon.
Dieser Artikel verteilt keine Gesamtnoten, dafür sind die Unterschiede zwischen den Anbietern zu kontextabhängig. Was er stattdessen tut: die einzelnen Dimensionen auseinandernehmen, in denen sich die Plattformen wirklich unterscheiden. Wer zunächst verstehen möchte, warum KI-Systeme überhaupt den Schritt vom Textgenerator zur handelnden Automatisierung gemacht haben, dem empfehlen wir als Einstieg unseren Hintergrundartikel „Vom Textgenerator zum digitalen Mitarbeiter“. Hier gehen wir einen Schritt weiter: Was konkret bieten die Plattformen an und wo liegen die echten Unterschiede?
Fünf Kategorien, die wirklich zählen
Bevor wir die Anbieter unter die Lupe nehmen, brauchen wir eine gemeinsame Sprache. Denn ohne Grunddefinitionen vergleicht man Äpfel mit Werkzeugkästen. Die folgende Ordnung orientiert sich nicht an Marketing-Broschüren, sondern an der tatsächlichen Architektur der Systeme, weniger als strenge Hierarchie, eher als Orientierungsrahmen:
Konfigurierte Assistenten sind vorkonfigurierte Schichten über einem bestehenden Basismodell. Keine eigene KI, kein eigenes Training, sondern ein angepasster Auftritt mit eigenem Namen, Ton, Wissensbasis und Verhalten. OpenAI nennt sie Custom GPTs, Google Gems, Microsoft Declarative Agents.
Skills sind wiederverwendbare Fähigkeits- oder Workflow-Bausteine kondensierte Arbeitslogik, die immer wieder abrufbar ist. Anthropic hat diesen Begriff am klarsten definiert und produktnah ausgearbeitet. Bei anderen Anbietern taucht „Skill“ eher als unschärferer Sammelbegriff auf.
Tools, Actions und Plugins bezeichnen ausführbare Schnittstellen: Das Modell ruft eine externe Funktion auf, eine API (eine Schnittstelle zu einem anderen System), eine Datenbank, einen Service. OpenAI spricht von Actions, Anthropic von Tool Use, Google von Function Calling, Microsoft von Plugins.
Connectors, Extensions und Apps sind Anbindungen an Datenquellen und externe Dienste, sie geben dem System Zugang zu Informationen. Tools und Connectors liegen dabei konzeptionell eher nebeneinander als übereinander: Tools handeln aktiv, Connectors stellen Kontext bereit. Hier herrscht die größte Namensverwirrung: Was OpenAI früher Connector nannte, heißt heute App; Anthropic setzt auf Desktop Extensions; Microsoft hat Connectors als eigenständige Produktkategorie.
Agenten orchestrieren all das, aber mit einem entscheidenden Unterschied zu allem bisher Genannten: Ein konfigurierter Assistent antwortet einmal auf eine Eingabe. Ein Agent plant, führt aus, prüft das Ergebnis und korrigiert sich selbst iterativ, über mehrere Schritte, bis das Ziel erreicht ist. Das ist keine Marketing-Umschreibung für „Chatbot mit besserer Beschriftung“, sondern ein fundamentaler Architektursprung.
Die Anbieter im Vergleich: Was wirklich dahintersteckt
OpenAI: Produktdynamik auf Kosten der Konsistenz
OpenAI hat den Markt für konfigurierte Assistenten mit Custom GPTs definiert und ist damit bis heute die meistgenutzte Plattform für schnelle, leichtgewichtige KI-Anpassungen. Die Integration in ChatGPT bedeutet eine riesige Nutzerbasis, eine niedrige Einstiegshürde und eine lebendige Entwickler-Community.
Was gut funktioniert: Custom GPTs lassen sich ohne Programmierkenntnisse in wenigen Minuten konfigurieren. Für interne Styleguide-Bots, FAQ-Assistenten oder Onboarding-Helfer ist das unschlagbar. Die Actions-Funktion ermöglicht echte API-Integrationen, Tickets erstellen, externe Dienste abfragen, Kalendereinträge schreiben.
Wo OpenAI Schwächen hat: Die Begrifflichkeiten ändern sich schnell. Was gestern Connector hieß, heißt heute App. Wer eine mittel- bis langfristige Systemarchitektur plant, muss damit rechnen, dass sich Produktnamen, Featuregrenzen und Plan-Zugehörigkeiten regelmäßig verschieben. Und diese Produktdynamik hat reale Konsequenzen: Ein GPT kann laut OpenAI-Dokumentation entweder Apps oder Actions nutzen, aber nicht beides gleichzeitig. Das ist kein Redaktionsfehler, sondern eine echte Produktgrenze, die Architekturentscheidungen beeinflusst. Wer das nicht weiß, plant an der Realität vorbei. Hinzu kommt: OpenAI hat Plugins einst als zentrales Zukunftskonzept positioniert und sie dann still beerdigt, was für alle, die damals entsprechende Integrationen gebaut haben, schlicht Mehraufwand bedeutete.
Anthropic / Claude: Der klarste Stack, die steilste Lernkurve
Wer Anthropic-Dokumentation liest, staunt zunächst über die begriffliche Sorgfalt. Während andere Anbieter Termini lose verwenden, hat Anthropic eine klare Architektur ausgearbeitet, in der jede Ebene eine eigene Funktion hat.
Skills sind bei Anthropic kein Schlagwort, sondern ein konkretes Artefakt. Anthropic beschreibt sie ausdrücklich als „simple folder“, ein Verzeichnis mit einer SKILL.md-Datei im Kern, die einer KI erklärt, wie sie eine bestimmte Aufgabe strukturiert angehen soll. Skills können dabei entweder automatisch vom System genutzt oder direkt aufgerufen werden. Das ist fundamental anders als klassische Plugin-Mechaniken, die zwingend externe API-Aufrufe erfordern: Ein Skill kann rein textbasiert sein, ohne eine einzige Schnittstelle anzusprechen. Das senkt die Einstiegshürde für Arbeitslogik drastisch.
Tool Use – Anthropics Bezeichnung für Function Calling – unterstützt sowohl client- als auch serverseitige Tools und ist sauber dokumentiert. Der Agent SDK, verfügbar für Python und TypeScript, ist Anthropics Antwort auf die Frage, wie man vollständige agentische Systeme baut: mit Agent-Loop, Kontextmanagement und Tool-Integration. Das Verbindungsstück nach außen ist zunehmend das MCP (Model Context Protocol), dazu mehr im nächsten Abschnitt.
Was gut funktioniert: Die Architektur ist modular, konsistent und gut dokumentiert. Wer ernsthaft agentische Systeme bauen will, hat bei Anthropic das klarste konzeptionelle Fundament.
Wo Anthropic Schwächen hat: Die Nutzeroberfläche für Nicht-Entwickler ist deutlich schwächer als bei OpenAI oder Microsoft. Wer keinen Code schreiben will, hat wenig Spielraum. Und der Begriff „Skills“ ist so Anthropic-spezifisch definiert, dass er in plattformübergreifenden Gesprächen regelmäßig zu Missverständnissen führt.
Google / Gemini: Sauberste Trennung, stärkste Built-in-Tools
Google hat etwas, das andere Anbieter so nicht bieten: eine klare organisatorische Trennung zwischen dem, was Endnutzer konfigurieren, und dem, was Entwickler bauen.
Gems, Googles konfigurierte Assistenten, sind das Äquivalent zu Custom GPTs. Sie sind einfach einzurichten, in Google Workspace integrierbar und für viele Unternehmensanwender ein natürlicher Einstiegspunkt. Wichtig: Ein Gem ist kein Entwickler-Tool. Wer Gems mit der Gemini API gleichsetzt, vergleicht Produkte aus grundlegend verschiedenen Schichten.
Auf Entwicklerebene bietet Google Function Calling als zentrales Integrationswerkzeug, die Brücke zwischen natürlicher Sprache und realen Systemaktionen. Besonders stark: Built-in Tools, darunter Code Execution, File Search und Grounding with Google Search. Was technisch bemerkenswert ist: Google dokumentiert inzwischen explizit, dass bestimmte Gemini-Modelle Built-in Tools und Custom Function Calling kombinieren können, also nativ und extern gleichzeitig. Das rückt Google stärker in Richtung Agent-Plattform, als es auf den ersten Blick wirkt, und zeigt, dass Google in dieser Dimension technisch sichtbar aufholt. Grounding with Google Search bleibt dabei ein echter Differenzierungsfaktor: Gemini-Modelle können nativ auf aktuelle Webinhalte zugreifen, ohne dass dafür ein separater Connector konfiguriert werden muss.
Was gut funktioniert: Die Integration in Google Workspace ist für Teams, die ohnehin auf Drive, Docs und Gmail setzen, nahezu reibungslos. Die Built-in-Tools für Websuche und Dateiverarbeitung sind direkt nutzbar, ohne externe API-Konfiguration.
Wo Google Schwächen hat: Die Tool-Verfügbarkeit ist modellabhängig. Was auf einem Gemini-Modell funktioniert, ist auf einem anderen unter Umständen nicht verfügbar. Das macht systematische Architekturentscheidungen komplizierter als es sein müsste. Und beim Agent SDK ist Anthropic derzeit noch die ausgereiftere Wahl, auch wenn der Abstand kleiner wird.
Microsoft: Sauberste Taxonomie, aber ein Ökosystem als Labyrinth
Microsoft ist in dieser Runde der Musterschüler, zumindest was begriffliche Sorgfalt betrifft. Die offizielle Dokumentation von Microsoft 365 Copilot trennt zwischen Declarative Agents, Custom Engine Agents, Plugins und Connectors so klar, dass man sie als Referenz für jeden Anbieter-Vergleich nutzen kann.
Was Microsoft anbietet
Declarative Agents sind das Microsoft-Äquivalent zu Custom GPTs: konfigurierte Assistenten über dem Copilot-Basismodell, mit eigenem Instruktionsset und Wissensbasis. Custom Engine Agents gehen einen Schritt weiter: Hier wird das zugrundeliegende Modell selbst ausgetauscht oder ergänzt, was für spezifische Anforderungen mehr Kontrolle, aber auch erheblich mehr Aufwand bedeutet.
Plugins, ja, Microsoft verwendet den Begriff weiterhin aktiv, können mit MCP oder OpenAPI/REST arbeiten und ermöglichen echte Aktionen in externen Systemen. Connectors decken Wissens- und Dateneinbindung ab, mit sowohl synchronisierten als auch föderativen Mustern, also: Daten bleiben wo sie sind, werden aber on-demand abgerufen.
Was die Dokumentation nicht zeigt
Und hier beginnt das eigentliche Problem: Die Klarheit der Dokumentation wird durch die schiere Masse an Portalen und Entwicklungsumgebungen wieder relativiert. Wer mit Microsoft KI-Systeme baut, navigiert zwischen Azure AI Studio, Copilot Studio und der Power Platform, drei Oberflächen, die sich teilweise überschneiden, teilweise exklusiv sind und unterschiedliche Zielgruppen ansprechen. Was in der Dokumentation sauber getrennt ist, ist in der Praxis oft eine Frage von: „In welchem Portal war das noch mal?“ Das ist kein Angriff auf die Technologie – aber ein ehrlicher Hinweis für alle, die vor dem Einstieg stehen.
Was gut funktioniert: Wer in einer Microsoft-365-Umgebung arbeitet, hat ein nahezu fertig integriertes Ökosystem. Teams, SharePoint, Outlook, Word alles ist angebunden, ohne dass man Integrationen von Grund auf neu bauen muss. Die Governance-Tools für Admins sind ausgereifter als bei den meisten Konkurrenten.
Wo Microsoft Schwächen hat: Wer außerhalb des Microsoft-Ökosystems arbeitet, hat wenig Grund, hier einzusteigen. Und die Komplexität des Gesamtsystems kann für kleinere Teams erschlagend sein, die Dokumentation ist gut, aber die Landschaft dahinter ist es manchmal nicht.
Vergleichstabelle: Wer bietet was?
| OpenAI / ChatGPT | Anthropic / Claude | Google / Gemini | Microsoft Copilot | |
|---|---|---|---|---|
| Konfigurierter Assistent | Custom GPTs | Claude-Projekte | Gems | Declarative Agents |
| Skills / Workflow-Bausteine | Nicht klar definiert | Skills (SKILL.md) | Nicht klar definiert | Nicht klar definiert |
| Tool-Integration | Actions (OpenAPI) | Tool Use (client/server) | Function Calling | Plugins (MCP/REST) |
| Datenanbindung | Apps (ehem. Connectors) | Desktop Extensions, MCP | File Search, Grounding | Connectors (sync/federated) |
| Agenten-Plattform | Agents API | Agent SDK (Python/TS) | Agents (Gemini API) | Custom Engine Agents |
| MCP-Unterstützung | Ja (wachsend) | Ja (Ursprung) | Eingeschränkt | Ja (in Plugins) |
| Einstieg ohne Code | ★★★★★ | ★★☆☆☆ | ★★★★☆ | ★★★☆☆ |
| Architektur-Klarheit | ★★★☆☆ | ★★★★★ | ★★★★☆ | ★★★★★ |
| Ökosystem-Integration | Breit, aber fragmentiert | Entwickler-fokussiert | Google Workspace | Microsoft 365 |
| Begriffsstabilität | ★★☆☆☆ | ★★★★☆ | ★★★☆☆ | ★★★★☆ |
MCP: Das Verbindungsstück, das alle brauchen
Hinter der Produktvielfalt zeichnet sich 2026 ein Konsolidierungstrend ab, den viele unterschätzen: das Model Context Protocol (MCP). Ursprünglich von Anthropic entwickelt und als offener Standard veröffentlicht, legt MCP fest, wie KI-Modelle mit externen Tools und Datenquellen kommunizieren – anbieterübergreifend, maschinenlesbar, standardisiert.
Was das in der Praxis bedeutet: Statt für jeden Anbieter eigene Integrationen zu bauen, kann ein MCP-kompatibler Konnektor theoretisch von Claude, Copilot und anderen genutzt werden. Microsoft hat MCP in seine Plugin-Architektur integriert. OpenAI setzt es zunehmend in Business-Integrationen ein. Anthropic baut seinen gesamten Erweiterungsstack darauf auf.
Wichtiger Vorbehalt: MCP standardisiert die Verbindung, nicht die Sicherheit. Wer MCP-Server betreibt, muss Berechtigungen, Datengrenzen und Zugriffsrechte eigenständig klären. Das Protokoll ist eine gemeinsame Sprache – kein Sicherheitskonzept.
Sicherheit und Wirtschaftlichkeit: Was Entscheider wissen müssen
Wenn KI-Systeme nicht mehr nur antworten, sondern handeln, verändert sich die Risikolandschaft fundamental. Die alte Debatte „Trainiert das Modell auf meinen Daten?“ ist inzwischen zweitrangig gegenüber den eigentlichen Fragen:
Was darf das System ausführen? Schreibende Aktionen, Tickets erstellen, Kalendereinträge anlegen, E-Mails versenden, sind nicht rückgängig zu machen. Wer hier keine klaren Berechtigungskonzepte definiert, baut systemische Risiken ein.
Welche Daten fließen wohin? Connectors und Extensions geben Modellen Zugriff auf interne Datenquellen. Das bedeutet, dass Zugriffsrechte des KI-Systems und die des anfragenden Nutzers klar getrennt sein müssen.
Sind System-Prompts geschützt? Konfigurierte Assistenten enthalten oft Instruktionen mit vertraulichen Informationen über interne Prozesse. Instruction Leakage, das ungewollte Durchscheinen dieser Instruktionen in Modellantworten, ist ein reales, dokumentiertes Problem, das mit Produktwahl allein nicht gelöst wird.
Dazu kommt eine wirtschaftliche Dimension, die 2026 zunehmend auf den Tischen von CTOs landet: Agenten-Effizienz als Kostenfaktor. Ein konfigurierter Assistent verursacht kaum Mehrkosten gegenüber einem Standard-Abo. Ein vollständiger Agent mit iterativen Planungsschleifen hingegen, der plant, ausführt, prüft und korrigiert, verbraucht bei jedem Durchlauf ein Vielfaches an Token (die Recheneinheit, nach der KI-APIs abgerechnet werden). Wer agentische Systeme im Unternehmensmaßstab plant, muss die Total Cost of Ownership (TCO) dieser Schleifen einrechnen. „Wie viel kostet ein Agent pro Aufgabe?“ ist 2026 keine akademische Frage mehr, sondern eine betriebswirtschaftliche.
Wer braucht was? Ein ehrlicher Leitfaden
Der folgende Überblick ignoriert Marketing und orientiert sich am tatsächlichen Anwendungsfall:
Schneller interner Assistent (Styleguide-Bot, FAQ, Onboarding): Custom GPT (OpenAI) oder Gem (Google). Kein Code notwendig, in einer Stunde einsatzbereit. Wer in der Google-Workspace-Welt lebt, fährt mit Gems besonders reibungslos.
Wiederverwendbare Arbeitslogik (Code-Review-Standards, Triage-Schemata, Release-Checklisten): Anthropic Claude Code mit Skills, wenn man bereit ist, eine SKILL.md zu pflegen. Alternativ: Microsoft Declarative Agents mit Wissensbasis, für Nicht-Entwickler zugänglicher.
Echte API-Aktionen (Tickets erstellen, CRM abfragen, Daten synchronisieren): OpenAI Actions oder Anthropic Tool Use für Entwickler-Teams. Microsoft Plugins für Teams im 365-Ökosystem. Hier ist technisches Know-how zwingend.
Wissensanbindung und Datenzugriff (interne Dokumente, Confluence, SharePoint): Microsoft Connectors für 365-Umgebungen, klar führend in Reife und Governance. Google File Search und Grounding für Google-Workspace-Teams.
Vollständige agentische Automatisierung (mehrstufige Workflows, autonome Prozesse mit Selbstkorrektur): Anthropic Agent SDK oder OpenAI Agents API für Entwickler-Teams. Microsoft Custom Engine Agents für Enterprise-Umgebungen mit Compliance-Anforderungen. Und hier gilt besonders: den TCO-Faktor nicht vergessen.
Was die nächsten zwei Jahre bringen werden und was nicht
Es gibt eine Prognose, die man 2026 mit einiger Zuversicht treffen kann: Der Wettbewerb zwischen KI-Plattformen wird sich weniger um Modellqualität drehen als um Integrations-Ökosysteme, Governance-Tools und Standardisierung. Die Modelle werden besser, das ist fast sicher. Aber der eigentliche Engpass liegt woanders: in der Frage, wie verlässlich, sicher und wartbar Integrationen in reale Arbeitsprozesse sind.
MCP wird in dieser Entwicklung eine zentrale Rolle spielen. Nicht weil es perfekt ist, sondern weil es das erste ernstzunehmende Angebot für anbieterübergreifende Interoperabilität ist. Ob es sich als Standard durchsetzt oder von einem Hyperscaler verdrängt wird, ist offen, aber die Richtung ist klar.
Was sich hingegen nicht auflösen wird: die Komplexität. Wer ernsthaft KI-Systeme baut, die mehr tun als antworten, wird nicht darum herumkommen, Governance-Konzepte, Berechtigungsmodelle, Monitoring-Infrastruktur und Kostenmodelle mitzudenken. Die eigentliche Frage ist nicht mehr „Welches KI-Modell ist am klügsten?“ sondern: Welchem System gebe ich wie viel Handlungsspielraum, unter welchen Bedingungen, und zu welchem Preis?
Das ist eine Frage, die über Produktdokumentationen weit hinausgeht. Und eine, auf die bisher kein Anbieter eine vollständige Antwort hat.
📥 Tipp: Lerne Prompt-Engineering in unserer kostenlosen KI-Schulung