ChatGPT & Copilot im Unternehmen: Wann Standardprodukte reichen

ChatGPT oder Copilot ist nicht die erste Architekturentscheidung

ChatGPT und Microsoft Copilot sind im Unternehmen nicht pauschal verboten. Ob ihr Einsatz passt, hängt vom konkreten Use Case, Vertrag, Konfiguration, Datenzugriff und Berechtigungsmodell ab. Consumer-Nutzung ist dabei etwas anderes als ein zentral verwalteter Business- oder Enterprise-Einsatz.

Ein generelles Verbot löst das Produktivitätsproblem der Mitarbeitenden nicht. Es verlagert es oft in private Accounts und damit in Schatten-KI, die weder sichtbar noch steuerbar ist. Sinnvoller ist ein offizieller Weg mit klaren Grenzen.

Danach beginnt aber die wichtigere Frage: Reicht für diese Aufgabe ein Standardprodukt, braucht sie eine kontrollierte Erweiterung oder eine eigene AI-Anwendung? Nicht jedes Unternehmen braucht eine eigene Plattform. Ein Standardprodukt bleibt dann eine gute Entscheidung, wenn Daten, Identity, Berechtigungen und Integrationen innerhalb seiner vorgesehenen Grenzen liegen.

Für die rechtliche Einordnung von Datenflüssen, Hosting und Transfers ist DSGVO-konforme KI für Unternehmen der passende Deep Dive. Dieser Beitrag behandelt die vorgelagerte Architektur- und Adoptionsentscheidung.

Wann ein Standardprodukt tatsächlich reicht

Standardprodukte sind stark bei allgemeiner Wissensarbeit: Texte entwerfen, Inhalte zusammenfassen, recherchieren, Meetings vorbereiten oder Office-Arbeit unterstützen. Sie passen besonders gut, wenn der Arbeitskontext bereits in einer Produktumgebung liegt, die zentral verwaltet wird.

Das gilt etwa für einen Schreibassistenten, eine Zusammenfassung vorhandener Dokumente oder Unterstützung in Teams, Outlook und Office. Die Aufgabe bleibt dabei eine Assistenz: Die KI schlägt vor, ein Mensch entscheidet und die Unternehmenssysteme werden nicht über einen eigenen Ausführungspfad verändert.

Die entscheidende Frage lautet nicht, ob ein Produkt theoretisch einen Connector oder eine Agentenfunktion anbietet. Sie lautet: Kann der konkrete Use Case mit den vorhandenen Daten-, Identity- und Integrationsgrenzen zuverlässig erledigt werden? Wenn ja, wäre eine eigene Anwendung oft unnötige Komplexität.

Die vier Entscheidungsblöcke vor der Produktentscheidung

A. Use Case und Daten

Zuerst muss klar sein, welche Aufgabe die KI tatsächlich erledigen soll und welche Daten sie dafür sehen muss. Ein allgemeiner Schreibassistent verarbeitet andere Informationen als ein System, das internes Wissen, Kundenakten oder operative Daten zusammenführen soll.

Diese Unterscheidung verhindert zwei typische Fehlentscheidungen: eine überbaute Eigenentwicklung für eine einfache Assistenz – oder ein Standardprodukt für einen Use Case, dessen entscheidende Daten gar nicht kontrolliert erreichbar sind.

B. Integrationen und Berechtigungen

Wo liegen die relevanten Daten: in Microsoft 365 und SharePoint, in einem DMS, CRM oder mehreren internen APIs? Und muss ein Nutzer in jedem dieser Systeme weiterhin genau nur das sehen, wozu er berechtigt ist?

Ein einzelner Datenraum mit vorhandener Identity kann eine Standardintegration plausibel machen. Mehrere Quellen mit unterschiedlichen Rollen, Mandanten oder ACLs verändern die Aufgabe. Dann reicht es nicht, Inhalte nur technisch erreichbar zu machen; die Berechtigungen müssen im tatsächlichen Abfragepfad erhalten bleiben. Wie das bei Retrieval-Systemen funktioniert, vertieft RAG Permissions & Security Trimming.

C. Assistenz oder Systemaktion

Eine KI, die eine Antwort entwirft oder Informationen recherchiert, hat eine andere Risikogrenze als eine KI, die ein Ticket anlegt, einen Datensatz ändert oder einen Workflow auslöst. Bei Vorschlägen kann ein Mensch die letzte Entscheidung treffen. Bei Aktionen muss klar sein, mit welcher Identität, welchen Rechten und unter welchen Bedingungen ein System verändert werden darf.

Sobald AI Systeme verändert, steigt der Architekturbedarf deutlich. Dann sind begrenzte Tool-Rechte, nachvollziehbare Übergaben und ein kontrollierter Execution Path wichtiger als eine überzeugende Chat-Oberfläche.

D. Prozesslogik und Betriebsgrenze

Manche Prozesse benötigen deterministische Regeln, explizite Freigaben oder einen nachvollziehbaren Audit-Pfad. Andere müssen mehrere Modelle oder Provider austauschbar halten, eigene Qualitätskriterien prüfen oder innerhalb einer bestimmten Hosting- und Betriebsgrenze laufen.

Das sind keine Argumente für Custom um seiner selbst willen. Sie zeigen nur, dass die Verantwortung nicht mehr vollständig in einer Produktkonfiguration verschwinden darf. Welche Betriebsmodelle zu Schutzbedarf und Kontrollgrenze passen, behandelt Private AI vs. Public Cloud. Wenn bereits eine eigene oder integrierte Lösung entstehen soll, kommen zusätzlich Evaluation, Observability und Betrieb hinzu.

Die Wahl folgt dem Use Case, nicht einer Reifeleiter

1. 01

   Allgemeine Assistenz

   Schreiben, Zusammenfassen und Recherche innerhalb eines klaren Arbeitskontexts.

2. 02

   Unternehmensdaten & Integrationen

   Relevante Quellen liegen in M365, DMS, CRM oder internen APIs.

3. 03

   Rechte & Prozesslogik

   Identity, ACLs, Regeln und Systemgrenzen müssen durchgängig gelten.

4. 04

   Operative Aktionen

   Die KI darf Tickets, Daten oder Workflows nur über einen kontrollierten Pfad verändern.

5. 05

   Passendes Zielmodell

   Standardprodukt, kontrollierte Erweiterung oder eigene Anwendung – abhängig von den Antworten davor.

Drei Zielmodelle

Modell A: Standardprodukt

Ein Standardprodukt reicht, wenn allgemeine Assistenz im Vordergrund steht, die vorhandene Produktumgebung die notwendigen Daten bereits sinnvoll umfasst und die bestehende Identity- und Admin-Struktur passt. Komplexe Multi-System-Integration, kritische Systemaktionen und eigene Prozesslogik sind dann nicht nötig.

ChatGPT Business oder Enterprise und Microsoft 365 Copilot können in diesem Rahmen sinnvolle Optionen sein. Die Entscheidung ist bewusst klein: ein zentral bereitgestelltes Werkzeug für klar abgegrenzte Arbeit – keine unsichtbare neue Fachanwendung.

Modell B: Standardprodukt + kontrollierte Erweiterung

Dieses Modell passt, wenn die vorhandene Produktumgebung weiterhin sinnvoll ist, aber zusätzliche Datenquellen, definierte Connectoren oder begrenztes Retrieval benötigt werden. Die Erweiterung bleibt bewusst an einer klaren Grenze: Sie verbindet ausgewählte Quellen oder einen eng umrissenen Prozess, ohne eine vollständige eigene Anwendungsplattform vorzutäuschen.

Das Standardprodukt bleibt die primäre Benutzeroberfläche und Arbeitsumgebung. Identity und Berechtigungen bleiben möglichst im bestehenden Produktkontext; ein klarer Integrationspfad begrenzt, welche zusätzliche Quelle oder Funktion hinzukommt. Es entsteht keine vollwertige Fachanwendung mit eigenem Execution-, Evaluation- und Betriebsmodell. Wenn Retrieval oder Datenanbindung zum Kern der Aufgabe wird, hilft die RAG-Implementierung & KI-Integration bei der konkreten Architektur.

Modell C: Eigene AI-Anwendung

Eine eigene Anwendung wird relevant, wenn mehrere interne Systeme zusammenspielen, eigene Prozesslogik nötig ist oder Berechtigungen feiner sind als das Standardprodukt sie für den Use Case abbilden kann. Dasselbe gilt für kontrollierte Tool- und API-Aktionen, deterministische Workflows, spezifische Audit-Anforderungen oder eine bewusst eigene Betriebsgrenze.

Custom ist keine höhere Reifestufe und kein Qualitätsmerkmal. Es ist eine andere Antwort auf Anforderungen, die nicht mehr sauber in den Grenzen eines Standardprodukts liegen.

ChatGPT und Copilot im natürlichen Produktumfeld einordnen

Microsoft 365 Copilot liegt besonders nahe, wenn Microsoft 365 mit Entra ID, Teams, Outlook, OneDrive und SharePoint bereits der zentrale Arbeits- und Identity-Kontext ist. Er kann Work Data entsprechend den bestehenden Nutzerberechtigungen verwenden. Das ersetzt aber keine Datenqualität und bereinigt keine Fehlberechtigungen: KI macht vorhandene Zugriffsgrenzen nutzbar, nicht automatisch richtig.

ChatGPT liegt nahe für Wissens-, Analyse-, Schreib- und Recherchearbeit, ist aber nicht auf einen allgemeinen Assistenten ohne Unternehmenskontext beschränkt. ChatGPT Business kann verbundene Arbeitsquellen – auch aus Microsoft 365 – in den Unternehmenskontext einbeziehen und berücksichtigt dabei die bestehenden Berechtigungen der verbundenen Apps. Für Unternehmensnutzung ist dieser Kontext getrennt von Consumer-Nutzung zu betrachten.

Das Produktökosystem ist damit ein Faktor, aber nicht die Architekturentscheidung selbst. Mehrere Systeme mit eigener Integrationslogik, explizit kontrollierte Rechte über Produktgrenzen hinweg, eigene Prozesslogik, deterministische Workflows, Tool- oder API-Aktionen sowie eigene Audit-, Evaluation-, Observability- oder Betriebsanforderungen müssen separat bewertet werden. Damit gibt es keinen Gewinner. Beide können im richtigen Kontext eine gute Entscheidung sein.

Typische Mismatch-Situationen

• Ein Unternehmen kauft Copilot, obwohl das relevante Wissen überwiegend in DMS, CRM und Fachsystemen außerhalb von M365 liegt. Die Oberfläche passt, der eigentliche Datenpfad nicht.
• ChatGPT wird zum Frontend für einen Fachprozess, obwohl die benötigten Rechte, Freigaben und Prozessregeln nur in internen Systemen existieren.
• Ein Standardprodukt soll mehrere Systeme orchestrieren, aber es gibt keinen kontrollierten Execution Path für API-Aufrufe, Fehlerfälle und Berechtigungen.
• Ein Team baut sofort eine Custom-App, obwohl ein zentral verwalteter Assistenz-Use-Case innerhalb der vorhandenen Produktumgebung vollständig abgedeckt wäre.
• RAG wird ergänzt, obwohl das eigentliche Problem fehlende Datenqualität oder ungeklärte Berechtigungen ist. Ein Index ersetzt keine fachliche Source of Truth und keine Rechteentscheidung.

Diese Fälle scheitern selten daran, dass ein Modell zu schwach ist. Sie scheitern daran, dass Produktgrenze und tatsächlicher Use Case nicht zusammenpassen.

Was eine eigene Anwendung bewusst zusätzlich übernimmt

Eine eigene Anwendung schafft Kontrolle, weil sie die Grenzen selbst gestaltet. Sie übernimmt damit aber auch Verantwortung: für Identity Mapping, Daten- und Integrationslogik, Prozess- und Workflow-Regeln, Tool-Ausführung, Security Boundaries sowie die Ownership im Betrieb.

Auch Qualität wird dann zur eigenen Aufgabe. Das Unternehmen braucht eine nachvollziehbare Evaluation, ausreichende Observability und einen Weg, Änderungen, Fehler oder Ausfälle verantwortbar zu behandeln. Das ist nicht gegen Standardprodukte gerichtet – es ist der Preis dafür, dass eine AI-Anwendung einen eigenen Fachprozess trägt. Für diese Fragen nach der Architekturentscheidung ist die KI-Architektur-Checkliste für Unternehmen der passende nächste Deep Dive.

Die pragmatische Entscheidung: klein starten, Grenzen explizit halten

Wenn ein Standardprodukt den Use Case innerhalb seiner Daten-, Identity- und Integrationsgrenzen erfüllt, sollte es genutzt werden. Wenn eine klar begrenzte Erweiterung genügt, sollte sie nicht zur verdeckten Plattform werden. Erst wenn echte Integrations-, Berechtigungs-, Prozess- oder Betriebsanforderungen darüber hinausgehen, ist eine eigene Architektur die kleinere und sicherere Entscheidung.

Die wertvolle Entscheidung ist nicht „Buy oder Build" im Allgemeinen. Sie lautet: Welche Verantwortung muss dieses Unternehmen für diesen Prozess selbst kontrollieren – und welche darf bewusst im Produkt bleiben?

Hinweis: Dieser Beitrag bietet eine technische und organisatorische Orientierung, ersetzt aber keine Rechtsberatung. Die rechtliche Bewertung hängt vom konkreten Einsatz, den Datenflüssen und dem gewählten Betriebsmodell ab.

---

Sie müssen zwischen Standardprodukt, Erweiterung und eigener AI-Anwendung entscheiden? In der KI-Beratung & AI Solution Architecture werden Use Case, Daten, Integrationen, Berechtigungen und Betriebsgrenzen in eine belastbare Zielentscheidung übersetzt. → Erstgespräch anfragen