KI-Copilot im Produkt (eingebetteter Assistent in SaaS und Apps)

Nutzer von Software finden Funktionen nicht, tun sich mit komplexen Einstellungen schwer und kämpfen mit Berichtsgeneratoren, und Support-Teams beantworten immer wieder dieselben Bedienfragen. Ein Copilot im Produkt lebt innerhalb der Anwendung, weiß, auf welchem Bildschirm und bei welchem Objekt die Nutzer gerade sind, antwortet mit deren eigenen Daten und erledigt Aufgaben, indem er die Schnittstelle des Produkts mit den Berechtigungen der Nutzer aufruft. Ziel: schnelleres Onboarding, höhere Nutzung von Funktionen und weniger Support-Tickets. Das ist eine Kernarchitektur für Softwarehersteller (ISVs), kein allgemeiner Chatbot.

Problem & Nutzen

• Heute: Nutzer lesen Hilfecenter, eröffnen Tickets oder klicken sich durch Menüs. Ausgereifte SaaS-Produkte haben Hunderte Einstellungen, Filter und Berichtsgeneratoren; die meisten Nutzer verwenden nur einen kleinen Teil davon. Support- und Customer-Success-Teams tragen die Last der Bedienfragen.
• Warum eigenständig: Ein externer FAQ-Bot (CONV-001) und Dokumenten-Q&A (KNOW-002) kennen den Zustand der App nicht. Der Copilot braucht Kontext (Seite, Auswahl, Rolle), Tool-Aufrufe ins Produkt und die Darstellung der Oberfläche innerhalb des Produkts.
• KI-Nutzen: Zugriff auf Funktionen in natürlicher Sprache („zeige überfällige Rechnungen nach Region als Diagramm und versende es wöchentlich“), kontextbezogenes Onboarding, weniger Tickets und ein Alleinstellungsmerkmal des Produkts. Hersteller berichten von Entlastung beim Support und höherer Nutzung, doch die Zahlen stammen von ihnen selbst und hängen stark vom Umfang ab; messen Sie Ihre eigene Ausgangslage, statt eine Zahl zu unterstellen.
• Markt: Fast jeder große Anbieter von Unternehmenssoftware liefert inzwischen einen eingebetteten Assistenten aus (z. B. Microsoft Copilot in 365/Dynamics, Salesforce Agentforce, ServiceNow, SAP Joule [EU], Atlassian Rovo, Notion AI, Intercom Fin, HubSpot Breeze), und Entwickler-Toolkits zum Einbetten von Copilots haben 2026 erhebliche Finanzierung erhalten [3].

Varianten

• Reiner Anleitungs-Copilot: Antworten und Anleitungen, kein Schreibzugriff. Geringstes Risiko; typische erste Ausbaustufe.
• Aktions-Copilot: führt Anlegen- und Ändern-Vorgänge nach Bestätigung durch die Nutzer aus.
• Agentischer Copilot: mehrstufige Aufgaben (Projekt einrichten, Daten migrieren) mit Planvorschau.
• Generative Oberfläche: Der Assistent stellt Formulare, Tabellen und Diagramme im Designsystem des Produkts dar.
• Branchenspezifisch: ERP/HR/Finanzen (SAP Joule, DATEV, Assistenten im Stil von Personio), CRM, Analytik/BI (Abfragen in natürlicher Sprache), Low-Code-Plattformen, Entwicklerwerkzeuge und Admin-Konsolen.
• Plattform/MCP nach außen: Dieselbe API-Fläche wird als MCP-Server bereitgestellt, damit externe Assistenten sie nutzen können [2].

So funktioniert es

1. Nutzernachricht + App-Kontext (Route, ausgewählte Entität, Rolle, Sprache)
2. Kontextaufbau (was die Nutzer sehen dürfen; mandantenbezogen)
3. Retrieval (Doku, Hilfecenter, Release Notes; hybride Suche + Reranker)
4. LLM mit Tool-Definitionen (Produkt-API / MCP-Tools, lesend vs. schreibend)
5. Richtlinienebene (Token der Nutzer, RBAC, Ratenbegrenzung, Injection-Filter)
6. Tool-Ausführung unter der Identität der NUTZER
7. Bestätigungsdialog bei Schreibvorgängen
8. Ergebnis in der App-Oberfläche dargestellt
9. Audit-Log + Feedback (Daumen, Eskalation an den Support)

• Weitergabe der Identität: Der Copilot ruft dieselben Dienste, Validierungen und Berechtigungsprüfungen auf wie die Oberfläche, mit dem Token der Endnutzer und nie mit einem breit berechtigten Dienstkonto. MCP selbst löst die Autorisierung nicht; die Host-Anwendung muss das leisten [2].
• Tools: kleine, gut beschriebene, idempotente Funktionen; getrennte Lese- und Schreib-Tools; Probelauf oder Vorschau bei zerstörerischen Aktionen.
• Hygiene des Kontextfensters: nur die Daten übergeben, die der aktuelle Bildschirm braucht; lange Verläufe zusammenfassen; Mandantendaten strikt getrennt halten.
• Mensch-in-der-Schleife (Human-in-the-Loop): ausdrückliche Bestätigung bei Schreibvorgängen, Löschungen, Zahlungen, dem Versand von Nachrichten und Änderungen von Berechtigungen; einfaches Rückgängigmachen; Übergabe an einen menschlichen Mitarbeiter mit angehängtem Gespräch.
• UI-Protokoll: Frameworks wie CopilotKit mit dem Ereignisprotokoll AG-UI übertragen Agentenzustand und Tool-Aufrufe an das Frontend [3][4].

Datenaufbereitung

Der Copilot braucht drei Arten von Inhalten: Hilfecenter-Artikel, Release Notes und Handbücher (meist in einem CMS, Wiki, Confluence oder als PDF), die API-Schemas des Produkts (OpenAPI, MCP-Tool-Definitionen) und die Mandantendaten, die er zur Laufzeit über die API liest. Typische Lücken: veraltete oder widersprüchliche Artikel, Funktionen, die nur in Support-Tickets oder in den Köpfen der Entwickler dokumentiert sind, fehlende Angaben zu Tarif und Version, doppelte Seiten in mehreren Sprachen und API-Beschreibungen, die für ein Modell zu knapp sind, um das richtige Tool zu wählen.

Schritte der Aufbereitung: eine maßgebliche Wissensbasis kuratieren und veraltete Seiten außer Betrieb nehmen (PREP-013, PREP-017), Metadaten zu Produktversion, Tarif und Sprache ergänzen (PREP-010), Tool-Beschreibungen mit Beispielen und klarer Trennung von Lesen und Schreiben verfassen und aus Support-Tickets ein Referenzset („Golden Set“) echter Bedienfragen mit erwarteten Antworten und API-Aufrufen zusammenstellen (PREP-018, PREP-020). Prüfen Sie, dass die Berechtigungen der Nutzer in der API durchgesetzt werden und nicht nur in der Oberfläche (PREP-023), und pseudonymisieren Sie Ticketdaten, bevor Sie sie für die Evaluation verwenden (PREP-022). Werkzeuge: ein Dokumenten-Crawler oder CMS-Export, pgvector/Qdrant und ein Staging-Mandant mit synthetischen Daten.

Grober Anteil am Aufwand: etwa 25-35 Prozent, überwiegend Bereinigung der Dokumentation und Evaluationssets. Ohne diese Arbeit antwortet der Copilot selbstsicher aus veraltetem Text. Eine Bereitschaftsprüfung finden Sie in GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• smb: B, weil der Wert in Aktionen über die eigene Produkt-API und das eigene Berechtigungsmodell liegt, die Standard-FAQ-Bots nicht leisten können; A nur für einen reinen Anleitungs-Copilot auf Basis der Dokumentation.
• enterprise: B, weil der Copilot Teil eines strategischen Produkts ist und Mandantentrennung, eigene Evaluation und Kontrolle über die Kosten pro Gespräch braucht.
• developer: B, weil Tool Calling, MCP und UI-Frameworks auf APIs in EU-Regionen den schnellsten Weg bieten; zu C erst für Kunden mit On-Premises-Betrieb wechseln.

Weg A — Kaufen (Standardsoftware)

• Einbettbare Assistenten-Plattformen: Intercom Fin, Zendesk AI Agents, Ada, Kapa.ai (an der Doku verankerte Assistenten), Suche mit Chat im Stil von Algolia/Glean, Pendo und Anleitungen mit KI im Stil von Appcues. EU-Optionen: Mistral Le Chat Enterprise/Agents, Angebote auf Basis von Aleph Alpha, SAP Joule (für SAP-Kunden), Parloa und Cognigy (NICE) für Service-Szenarien.
• A wählen, wenn: Sie schnell Bedienantworten auf Basis der Doku brauchen und keine tiefen Aktionen in der App. Prüfen Sie EU-Hosting, Auftragsverarbeitungsvertrag, kein Training mit Ihren Daten, SSO und Mandantentrennung.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlen für Softwarehersteller)

• Modelle: Spitzenmodelle mit Tool Calling und strukturierten Ausgaben (Claude, GPT, Gemini, Mistral Large/Medium) über EU-Regionen (Azure OpenAI EU Data Zone, Google Vertex EU, AWS Bedrock Frankfurt/ Paris, Mistral La Plateforme als EU-Anbieter). Ein kleines, schnelles Modell für das Routing und ein stärkeres für die Planung verwenden.
• Orchestrierung: Vercel AI SDK, LangGraph, Mastra, Pydantic AI oder die Agenten-SDKs der Anbieter; Frontend mit CopilotKit, assistant-ui oder eigenen React-Komponenten [3][4].
• Integration: Tools, die aus Ihrer OpenAPI-Spezifikation erzeugt werden; optional ein MCP-Server für externe Clients [2]; Retrieval mit pgvector/OpenSearch/Qdrant über die Doku.
• Sicherheit: Filter gegen Prompt Injection, Validierung der Ausgaben gegen Schemas, Positivlisten pro Tool [5].

Weg C — Selbst betreiben (Open Source)

• Modelle: offene Modelle mit Tool Calling wie Qwen3, offene Veröffentlichungen von Mistral Small/Medium, Llama 3.x, gpt-oss, betrieben mit vLLM oder Ollama; Embeddings wie BGE-M3 oder multilingual-e5.
• Stack: LangGraph oder Mastra, Qdrant/pgvector, Langfuse für das Tracing, Guardrails/LLM Guard für Filter.
• Hardware: HW3 für ein gemeinsam genutztes Tool-Calling-Modell mit 30-120 Mrd. Parametern unter Last; HW2 für ein quantisiertes Modell mit rund 30 Mrd. im Pilotmaßstab. Nötig für Kunden mit On-Premises-Betrieb oder Souveränitätsanforderungen (öffentlicher Sektor, Banken).

Weg D — Eigenes Training

Ein kleines Modell für die Tool-Auswahl und Ihr Fachvokabular erst dann feintunen, wenn Logs aus Weg B/C systematische Fehler beim Tool Calling oder Kostendruck zeigen. Trainingsdaten: echte, mit Einwilligung erhobene und anonymisierte Gesprächsprotokolle mit korrekten Tool-Aufrufen; Evaluationssets sind wichtiger als Menge.

Stand der Technik (2026)

• Tool-Nutzung ist ausgereift: Starke Modelle rufen Dutzende Tools zuverlässig mit strukturierten Ausgaben auf; MCP hat sich als gängiger Weg etabliert, Produktfunktionen für Assistenten bereitzustellen [2].
• Agent-UI-Protokolle (AG-UI) und generative Oberflächen lassen Assistenten nativ wirken statt wie ein Chat-Popup [4].
• Evaluation: Aufgabentests auf einem skriptgesteuerten Staging-Mandanten (Referenzgespräche mit erwarteten API-Aufrufen) sind der praktische Standard; Genauigkeit der Tool-Aufrufe und Rate falscher Aktionen verfolgen.
• Grenzen und Fehlerbilder: falsche Wahl von Tool oder Parameter, erfundene Funktionen, die es im Tarif der Nutzer nicht gibt, veraltete Doku, Abdriften bei langen mehrstufigen Aufgaben, Latenz (mehrere Sekunden durch Tool-Schleifen) und Kosten pro Gespräch. Prompt Injection über nutzergenerierte Inhalte in der App (Tickets, Kommentare, importierte Dateien) ist das wichtigste Sicherheitsrisiko: Ein Copilot mit Schreibzugriff kann zu Datenabfluss oder unerwünschten Aktionen verleitet werden [5].

Gemeinsame Bausteine & Kombinationen

• Retrieval-Stack (embedding-text, vector-db, reranker) gemeinsam mit KNOW-002, KNOW-004 und CONV-001.
• Agenten-/Tool-Ebene gemeinsam mit AGENT-002 (Workflow-Automatisierung) und AGENT-003 (Computernutzung, ein Ausweg, wenn es keine API gibt).
• Agentenunterstützung und Eskalation: CONV-007 für die menschliche Support-Seite; CONV-004 für die interne IT-Variante.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen, Preis pro gelöster Anfrage oder pro Lizenz.
• Weg B: typischerweise 2-6 Monate für einen ersten Aktions-Copilot (Tool-Design, Berechtigungsmodell, Evaluationsumgebung, Oberfläche); laufende Token-Kosten wachsen mit Gesprächen und Kontextgröße.
• Weg C: 4-9 Monate inkl. GPU-Betrieb.
• Kennzahlen: Aufgabenerfolgsquote, Genauigkeit der Tool-Aufrufe, Rate falscher Aktionen/Rückgängigmachungen, Ticket-Entlastung bei Bedienthemen, Nutzung der gezielt adressierten Funktionen, Zeit bis zum ersten Nutzen für neue Nutzer, CSAT, Kosten pro Gespräch, Eskalationsquote, Bestehensquote der Injection-Tests.

Menschen & Veränderung

Beziehen Sie die Geschäftsführung früh für Umfang, Budget und KI-Richtlinie ein; die Abteilungsleitung (Produkt oder Support) verantwortet den Anwendungsfall und die Erfolgskennzahlen. IT und Informationssicherheit entwerfen vor dem Pilot die Weitergabe der Identität, die Mandantentrennung und die Injection-Tests (GUIDE-013). Die oder der Datenschutzbeauftragte prüft Rechtsgrundlage, Auftragsverarbeitungsverträge und Aufbewahrung der Chat-Protokolle und entscheidet über eine Datenschutz-Folgenabschätzung (DSFA), wenn der Copilot breite Mandantendaten liest (GUIDE-005). Kunden sollten klar darüber informiert werden, dass sie mit einer KI sprechen (Art. 50 KI-Verordnung).

Betriebsrat: kommt darauf an. Wenn der Copilot nur kundenseitig genutzt wird, ist die Mitbestimmung in der Regel nicht berührt; sobald Beschäftigte ihn nutzen (Support-Mitarbeitende, interner Admin-Copilot) und die Nutzung protokolliert wird, greift § 87 Abs. 1 Nr. 6 BetrVG, weil die objektive Eignung zur Überwachung genügt, und § 90 Abs. 1 Nr. 3 verlangt die frühzeitige Information über KI-gestützte Arbeitsprozesse (GUIDE-004).

KI-Kompetenz: Support-Mitarbeitende und Produktteams brauchen Schulung zu Grenzen und Fehlerbildern; die Verordnung verlangt Maßnahmen zur Förderung der Kompetenz, kein garantiertes Niveau (GUIDE-006). Beginnen Sie mit einer Beta-Gruppe und KI-Botschaftern aus dem Support, veröffentlichen Sie, was der Copilot darf und was nicht, und begegnen Sie der Sorge um den Arbeitsplatz, indem Sie ihn als Entlastung bei wiederkehrenden Bedienfragen darstellen (GUIDE-008). Schreibvorgänge brauchen immer die Bestätigung der Nutzer, und die Übergabe an einen Menschen bleibt einen Klick entfernt.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel begrenztes Risiko: Nutzer müssen darüber informiert werden, dass sie mit einem KI-System interagieren (Art. 50 Abs. 1), und KI-generierte Inhalte sind wie vorgeschrieben zu kennzeichnen. Wird nur dann zu hohem Risiko, wenn der Copilot in Anwendungsfällen nach Anhang III (z. B. Personalentscheidungen, Bonitätsbewertung) eingesetzt wird, die im Produkt angeboten werden; dann gelten die Pflichten des Anbieters. Art. 4 (KI-Kompetenz) gilt für Anbieter und Betreiber. Verbotene Praktiken (Art. 5), etwa manipulative Techniken oder Emotionserkennung am Arbeitsplatz, dürfen nicht in Funktionen zur Steigerung der Nutzung eingebaut werden [1].
• DSGVO: Der Copilot verarbeitet personenbezogene Daten der Nutzer und der betroffenen Personen im Mandanten. Nötig sind eine klare Rollenverteilung (der Kunde ist Verantwortlicher, der Hersteller Auftragsverarbeiter), ein AVV mit dem Modellanbieter, EU-Region oder Standardvertragsklauseln, standardmäßig kein Training mit Kundendaten, Aufbewahrungsfristen für Chat-Protokolle, eine DSFA bei breitem Datenzugriff und Sorgfalt nach Art. 22, wenn Aktionen rechtliche oder ähnlich erhebliche Wirkung haben.
• Sicherheit: Risiken der OWASP LLM Top 10: Prompt Injection, übermäßige Handlungsfreiheit (Excessive Agency), Offenlegung sensibler Informationen, unsichere Verarbeitung von Ausgaben [5]. Gegenmaßnahmen: minimale Rechte, Ausführung mit dem Token der Nutzer, Bestätigungen, Kodierung der Ausgaben, Tests der Mandantentrennung und Red Teaming.

Erste Schritte

1. 10-20 häufigste Bedienthemen aus Tickets und 5 besonders wertvolle Aufgaben in der App auswählen; Erfolgskennzahlen festlegen.
2. Zuerst einen rein lesenden, an der Doku verankerten Copilot ausliefern; jede Frage protokollieren, um Lücken zu finden.
3. Die Tool-Ebene aus Ihrer OpenAPI-Spezifikation ableiten; Ausführung mit dem Token der Nutzer und RBAC durchsetzen; Bestätigungen ergänzen.
4. Eine Evaluationsumgebung mit skriptgesteuerten Gesprächen auf einem Staging-Mandanten aufbauen, dazu Injection-Tests.
5. Mit einer Beta-Gruppe mit Feedback-Schaltflächen und Eskalation an Menschen ausrollen; Logs wöchentlich auswerten.

Quellen

1. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. Model Context Protocol specification (incl. authorization) — https://modelcontextprotocol.io/specification
3. TechCrunch — CopilotKit raises $27M to help devs deploy app-native AI agents (2026-05-05) — https://techcrunch.com/2026/05/05/copilotkit-raises-27m-to-help-devs-deploy-app-native-ai-agents/
4. AG-UI protocol documentation — https://docs.ag-ui.com
5. OWASP Top 10 for LLM Applications — https://genai.owasp.org/llm-top-10/
6. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj