Der entscheidende Punkt: Copilot Studio verbindet die Freiheit generativer KI mit der Kontrolle eines Baukastens. Ein reiner Chatbot ohne Leitplanken kann alles und nichts – er halluziniert, gibt inkonsistente Auskünfte und ist schwer zu verantworten. Copilot Studio erlaubt es dagegen, präzise festzulegen, aus welchen Quellen ein Agent antwortet, welche Aktionen er ausführen darf und wo die harten Grenzen liegen. Diese Mischung aus generativer Flexibilität und deklarativer Steuerung ist das, was die Umgebung für Unternehmen interessant macht – und was sie von einem freien Prompt an ein Sprachmodell unterscheidet.
Copilot Studio ist Teil der Microsoft Power Platform und teilt sich mit Power Apps, Power Automate und Power Pages die gemeinsame Basis aus Umgebungen, Connectoren und der Datenplattform Dataverse. Wer diese Nähe zum Bestand nutzt, kann einen Agenten in kurzer Zeit an SharePoint-Dokumente andocken, ihn in Microsoft Teams veröffentlichen und über einen Flow konkrete Vorgänge auslösen lassen – ohne eine Zeile klassischen Code zu schreiben. Genau diese Verzahnung ist Copilot Studios größter Vorteil und zugleich die Quelle der häufigsten Missverständnisse, weil „in der Power Platform“ eben nicht automatisch „ohne zusätzliche Lizenz“ bedeutet.
Copilot Studio hat sich mit dem Markt gewandelt. In seinen Anfängen – noch unter dem Namen Power Virtual Agents – ging es vor allem um klassische, regelbasierte Chatbots: vordefinierte Themen, Frage-Antwort-Bäume, festgelegte Dialogpfade. Heute steht der Begriff Agent im Zentrum. Ein Agent kann nicht nur auf Fragen antworten, sondern auf Basis von Wissensquellen generativ formulieren, über Actions in andere Systeme greifen und – in der weiterentwickelten Form – Aufgaben eigenständig anstoßen, statt nur auf jede einzelne Nutzereingabe zu warten. Diese Entwicklung vom reaktiven Chatbot zum handelnden Agenten ist der rote Faden, der sich durch das gesamte Produkt zieht.
Für die Praxis heißt das: Copilot Studio deckt heute ein breites Spektrum ab. Am einen Ende steht der einfache FAQ-Bot, der Standardfragen aus einer Dokumentensammlung beantwortet. Am anderen Ende steht ein autonomer Agent, der auf ein Ereignis reagiert, eine Reihe von Schritten durchläuft und dabei mehrere Systeme koordiniert. Zwischen diesen Polen liegt der weitaus größte Teil sinnvoller Anwendungsfälle im Mittelstand.
Copilot Studio ist aus Power Virtual Agents hervorgegangen und hat dessen Rolle übernommen. Power Virtual Agents war Microsofts Low-Code-Werkzeug für klassische Chatbots: Man definierte Themen und Dialogpfade, ohne zu programmieren. Mit dem Aufkommen generativer KI hat Microsoft das Produkt umgebaut und neu positioniert – aus dem regelbasierten Chatbot-Baukasten wurde eine Umgebung für generative Copilots und Agenten. Die bekannten Bausteine wie Themen und Trigger sind erhalten geblieben, wurden aber um generative Antworten aus Wissensquellen, Actions und agentische Fähigkeiten erweitert. Wer Power Virtual Agents kannte, findet sich in Copilot Studio wieder – trifft aber auf ein deutlich mächtigeres Werkzeug.
Diese Kontinuität ist praktisch relevant: Bestehende Power-Virtual-Agents-Projekte wurden in die neue Welt überführt, und das Denkmodell aus vordefinierten Themen bleibt eine tragende Säule. Die Neuerung liegt darin, dass ein Agent heute nicht mehr nur den vorgezeichneten Pfaden folgen muss, sondern generativ und – zunehmend – eigenständig agieren kann.
Der Microsoft-365-Copilot ist der fertige KI-Assistent, der in Word, Excel, Outlook, Teams und den übrigen Office-Anwendungen wohnt. Copilot Studio verhält sich dazu komplementär: Es ist das Werkzeug, mit dem Unternehmen diesen fertigen Copilot erweitern und anpassen. Über Copilot Studio lassen sich eigene Agenten bauen, die im Microsoft-365-Copilot als zusätzliche Fähigkeiten erscheinen – etwa ein Agent, der Auskunft aus einer firmeneigenen Wissenssammlung gibt oder einen internen Prozess anstößt. Damit wird aus dem generischen Assistenten ein auf das Unternehmen zugeschnittenes Werkzeug.
Gleichzeitig kann Copilot Studio auch eigenständige Copilots erzeugen, die unabhängig vom Microsoft-365-Copilot laufen – etwa ein Kundenservice-Bot auf der Website oder ein interner Assistent in einem Teams-Kanal. Die Grenze ist fließend: Derselbe Maker baut mal eine Erweiterung des großen Copilot, mal einen völlig eigenständigen Agenten. Für die Planung ist wichtig, diese beiden Betriebsarten früh zu unterscheiden, weil sie unterschiedliche Lizenz- und Veröffentlichungswege haben.
Copilot Studio ist der vierte große Baustein der Power Platform – neben Power Apps für Oberflächen, Power Automate für Workflows und Power Pages für externe Portale. Es teilt sich mit ihnen die gemeinsame Infrastruktur: Umgebungen als organisatorische Einheiten, die Connector-Bibliothek für Anbindungen und Dataverse als Datenplattform. Diese Verzahnung ist konkret spürbar. Ein Agent in Copilot Studio ruft für konkrete Aktionen einen Power-Automate-Flow auf, der wiederum Daten in Dataverse schreibt oder ein Drittsystem anspricht. So entsteht aus mehreren Bausteinen eine durchgängige Lösung, ohne dass man die Werkzeugwelt verlässt.
Für Microsoft-Häuser ist das der wirtschaftliche Kern der Positionierung: Man kauft keinen isolierten Chatbot-Dienst, sondern erweitert eine Plattform, die ohnehin vorhanden ist. Wer hingegen keinen Microsoft-Stack betreibt, kauft sich mit Copilot Studio auch ein Stück Power-Platform- und Dataverse-Gravitation ein – ein Aspekt, der in die strategische Entscheidung gehört und in Kapitel 05 bei der Abgrenzung wieder aufgegriffen wird.
Das Denkmodell von Copilot Studio ruht auf zwei Säulen, die sich ergänzen. Die eine sind die Themen: strukturierte Dialogpfade, die festlegen, wie der Agent auf eine erkannte Absicht reagiert. Ein Thema startet mit Auslöser-Phrasen – Formulierungen, an denen der Agent erkennt, worum es geht – und führt dann durch Nachfragen, Bedingungen und Antworten. Themen sind die deklarative, gut kontrollierbare Seite eines Agenten und eignen sich überall dort, wo ein Ablauf präzise vorgezeichnet sein soll.
Die andere Säule sind die generativen Antworten aus Wissensquellen. Hier hinterlegt man dem Agenten Quellen – etwa eine SharePoint-Bibliothek, ausgewählte Websites, hochgeladene Dateien oder Dataverse-Tabellen – und lässt ihn Antworten daraus generativ formulieren. Der entscheidende Unterschied zu einem freien Chatbot: Der Agent antwortet nicht aus dem allgemeinen Weltwissen eines Sprachmodells, sondern gebunden an die bereitgestellten Quellen. Das ist im Kern eine unternehmenstaugliche Umsetzung des Prinzips, Antworten aus dem eigenen Wissensbestand zu erzeugen und mit Belegen zu versehen. In der Praxis kombiniert man beide Säulen: klare Themen für definierte Abläufe, generative Antworten für die breite Masse der offenen Fragen.
Ein Agent, der nur antwortet, ist nützlich – ein Agent, der handelt, ist wertvoll. Genau das leisten Actions. Über sie kann ein Agent konkrete Aktionen ausführen: einen Power-Automate-Flow starten, einen Connector zu einem Drittsystem nutzen oder eine eigene Schnittstelle ansprechen. So beantwortet ein Support-Agent nicht nur die Frage nach dem Bestellstatus, sondern kann auf Wunsch auch eine Adressänderung anstoßen oder ein Ticket eröffnen. Die Bandbreite der anbindbaren Systeme entspricht dabei weitgehend dem, was die Power Platform über ihre Connectoren ohnehin erreicht.
Die jüngste Entwicklungsstufe sind autonome Agenten. Während ein klassischer Chatbot rein reaktiv arbeitet – er wartet auf eine Eingabe und antwortet –, kann ein autonomer Agent durch ein Ereignis ausgelöst werden, selbstständig mehrere Schritte planen und ausführen und dabei verschiedene Systeme koordinieren. Ein solcher Agent könnte etwa auf eingehende Anfragen reagieren, relevante Informationen zusammentragen und einen Vorgang vorbereiten, bevor ein Mensch ihn freigibt. Diese Autonomie ist mächtig, verlangt aber besondere Sorgfalt: Je eigenständiger ein Agent handelt, desto wichtiger werden klare Berechtigungen, Freigabestufen und eine belastbare Nachvollziehbarkeit. Wir raten dazu, Autonomie schrittweise und mit menschlicher Kontrolle im entscheidenden Moment einzuführen.
Ein fertiger Agent muss dorthin, wo die Nutzer sind. Copilot Studio veröffentlicht Agenten über verschiedene Kanäle. Der naheliegendste im Mittelstand ist Microsoft Teams: Ein interner Wissensassistent lebt dort, wo die Mitarbeitenden ohnehin arbeiten. Ebenso verbreitet ist der Web-Kanal – ein Chat-Widget auf der Unternehmenswebsite für Kundenanfragen. Darüber hinaus lassen sich Agenten als Fähigkeiten in den Microsoft-365-Copilot einbinden oder über weitere Kanäle verfügbar machen. Die Kanalwahl ist keine Nebensache: Sie bestimmt mit, wer den Agenten nutzt, welche Authentifizierung greift und welche Datenschutz-Anforderungen gelten – ein interner Teams-Bot unterliegt anderen Bedingungen als ein öffentlich erreichbarer Web-Bot.
Die erste und wichtigste Weichenstellung ist die zwischen einer eigenständigen Lizenzierung und der Nutzung im Kontext des Microsoft-365-Copilot. Eigenständig lizenziert baut und betreibt man Agenten unabhängig – etwa einen Kundenservice-Bot auf der Website oder einen internen Assistenten in Teams, ohne dass der große M365-Copilot vorhanden sein muss. Im Copilot-Kontext dagegen dient Copilot Studio dazu, den bereits lizenzierten Microsoft-365-Copilot mit eigenen Agenten zu erweitern; die Lizenzierung ist dann mit diesem Umfeld verwoben. Welcher Weg passt, hängt davon ab, ob ein Agent innerhalb des M365-Copilot erlebt werden soll oder als eigenständige Anwendung.
Für die Praxis heißt das: Wer ohnehin den Microsoft-365-Copilot einführt oder betreibt, betrachtet Copilot Studio meist als dessen Erweiterung. Wer gezielt einen abgegrenzten Bot bauen will – etwa für die Website oder einen einzelnen Prozess –, fährt oft mit der eigenständigen Lizenzierung besser. Diese Entscheidung sollte früh fallen, weil sie Architektur, Kosten und Governance prägt.
Unabhängig vom Lizenzweg wird der laufende Betrieb im Kern über verbrauchte Nachrichten beziehungsweise Kapazität abgerechnet. Vereinfacht gilt: Jede Interaktion eines Nutzers mit einem Agenten verbraucht Kapazität, und generative Antworten aus Wissensquellen wiegen dabei in der Regel schwerer als einfache, deklarativ beantwortete Anfragen. Kapazität lässt sich als Abonnement oder als zusätzlicher Kapazitätsbaustein beziehen. Der praktische Effekt: Die Kosten skalieren nicht mit der Zahl der Agenten, sondern mit ihrer Nutzung – ein wenig genutzter Bot kostet wenig, ein stark frequentierter Kundenservice-Agent kann erheblichen Verbrauch erzeugen.
Genau deshalb ist die Volumenschätzung der Schlüssel jeder Kostenplanung. Wie viele Interaktionen sind pro Monat realistisch? Wie hoch ist der Anteil generativer Antworten? Diese Fragen gehören an den Anfang, nicht ans Ende. Ohne sie wird aus einem günstigen Pilot schnell ein teurer Dauerbetrieb – die klassische Überraschung bei verbrauchsbasierten Modellen. Konkrete Preise und Paketgrenzen ändern sich häufig und sollten vor dem Ausbau aktuell geprüft werden.
Google Dialogflow und Amazon Lex sind die naheliegenden Alternativen im Cloud-Umfeld – jeweils tief in ihr eigenes Ökosystem eingebettet. Dialogflow punktet mit einer sehr ausgereiften Absichtserkennung und starken Sprachkanälen, was es besonders für Telefonie- und Voice-Szenarien attraktiv macht. Amazon Lex spielt seine Stärken dort aus, wo die restliche Landschaft ohnehin auf AWS liegt und Entwickler-Teams die Bots eng in AWS-Dienste einbetten. Beide sind technisch mächtig, verlangen aber tendenziell mehr Entwickler-Nähe und sind weniger auf den Low-Code-Fachanwender zugeschnitten als Copilot Studio.
Der entscheidende Unterschied ist die Ökosystem-Schwerkraft. Copilot Studio gewinnt fast automatisch, wenn Microsoft 365 die Arbeitsumgebung ist – die Anbindung an SharePoint, Teams und die vorhandenen Prozesse ist mit den Cloud-Baukästen der Wettbewerber nicht in gleicher Selbstverständlichkeit zu erreichen. Umgekehrt ist Copilot Studio selten die erste Wahl, wenn ein Haus konsequent auf Google Cloud oder AWS setzt und dort seine Datenwelt hat. Die Baukasten-Entscheidung folgt damit meist der bereits getroffenen Cloud-Entscheidung, nicht umgekehrt.
Am anderen Ende des Spektrums stehen eigenständige RAG-Frameworks – Ansätze, bei denen ein Team den Abruf aus eigenen Wissensbeständen und die Anbindung eines Sprachmodells selbst orchestriert, häufig anbieterunabhängig und mit voller Kontrolle über Modellwahl, Abruflogik und Architektur. Das ist der Weg für Häuser, die maximale Anpassbarkeit, bewusste Modellwahl oder besondere Souveränitätsanforderungen haben und über die nötigen Entwickler-Ressourcen verfügen. Der Preis dieser Freiheit ist Aufwand: Was Copilot Studio als Baukasten fertig mitbringt, muss hier selbst gebaut, betrieben und gewartet werden.
Unsere Faustregel: Copilot Studio ist die richtige Wahl für die breite Masse mittelständischer Anwendungsfälle im Microsoft-Umfeld, bei denen Geschwindigkeit, Governance und Office-Nähe zählen. Ein eigenständiges RAG-Framework rechtfertigt sich erst, wenn die Anforderungen an Kontrolle, Modellwahl oder Souveränität so speziell werden, dass der Baukasten zu eng wird – und wenn das Haus die technische Tiefe mitbringt, diesen Weg dauerhaft zu tragen. Für die meisten Mittelständler ist das nicht der Fall.
Copilot Studio ist bewusst so gebaut, dass auch Nicht-Entwickler Agenten erstellen können. Diese Demokratisierung ist ein Segen für die Verbreitung – und zugleich der Ursprung des zentralen Governance-Risikos. Weil fast jeder mit Zugang einen Agenten bauen kann, entstehen ohne Rahmen schnell viele halb-offizielle Bots: gebaut von Einzelpersonen, dokumentiert nirgends, mit unklaren Wissensquellen und Berechtigungen. Verlässt die bauende Person das Unternehmen, weiß niemand mehr, was der Agent tut und woher er seine Auskünfte zieht. Die Antwort ist keine Verbotskultur, sondern strukturierte Befähigung: klare Zuständigkeiten, getrennte Umgebungen, zentrale Richtlinien und eine Prüfinstanz für Agenten, die auf sensible Daten zugreifen oder handelnd in Systeme eingreifen.
Zwei Governance-Werkzeuge sind besonders wichtig. Das erste sind die Data-Loss-Prevention-Richtlinien, die – wie in der übrigen Power Platform – festlegen, welche Connectoren ein Agent nutzen darf und welche nicht miteinander kombiniert werden dürfen. So lässt sich verhindern, dass ein Agent Geschäftsdaten aus einer geschützten Quelle zieht und über einen unkontrollierten Kanal weitergibt. Das zweite ist die konsequente Beachtung der Zugriffsrechte der Nutzer: Ein interner Wissensassistent darf einem Mitarbeiter nur das zugänglich machen, was dieser ohnehin sehen dürfte. Wird das nicht sauber umgesetzt, wird der Agent zur Umgehung bestehender Berechtigungen – eines der unterschätzten Risiken beim Andocken an breite Wissensquellen. Beide Themen greifen in die Datenschutz-Betrachtung von Kapitel 09 über.
Der pragmatischste erste Anwendungsfall ist fast immer der FAQ- oder Support-Bot. Er hat einen klar umrissenen Zweck, ein überschaubares Risiko und einen unmittelbar sichtbaren Nutzen: Wiederkehrende Fragen – zu Öffnungszeiten, Produkten, Rückgabebedingungen, internen Abläufen – werden vom Agenten aus einer gepflegten Wissenssammlung beantwortet, konsistent und rund um die Uhr. Für den Kundenservice bedeutet das eine spürbare Entlastung des First-Level-Supports; für interne Anfragen sinkt die Zahl der Standardtickets. Der Charme liegt in der Begrenztheit: Ein FAQ-Bot muss nicht handeln, nur zuverlässig auskunftsfähig sein – das senkt die Anforderungen an Governance und Autonomie und macht ihn zum idealen Lernfeld.
Entscheidend für den Erfolg ist die Qualität der Wissensquelle. Ein Agent ist immer nur so gut wie das, woraus er antwortet. Veraltete, widersprüchliche oder lückenhafte Dokumente führen zu schlechten Antworten – und ein schlechter Bot verspielt schneller Vertrauen, als ein guter es aufbaut. Deshalb gehört die Pflege der zugrundeliegenden Inhalte zum Projekt, nicht als Nebensache dazu.
Der zweite Anwendungsfall, der interne Wissensassistent, hebt die FAQ-Idee auf die Ebene des ganzen Unternehmenswissens. In Teams eingebettet gibt der Agent Auskunft aus Handbüchern, Richtlinien, Prozessbeschreibungen und Projektunterlagen. Der Nutzen ist groß – Wissen wird auffindbar, ohne Ordnerstrukturen zu durchsuchen –, aber genau hier lauert das größte Datenschutz- und Berechtigungsrisiko: Der Assistent darf einem Mitarbeiter nur zugänglich machen, was dieser ohnehin sehen dürfte. Wird dieses Prinzip nicht sauber umgesetzt, wird der Assistent zur Umgehung bestehender Zugriffsrechte. Deshalb gehört gerade dieser Anwendungsfall eng an die Governance aus Kapitel 06 gekoppelt.
Der dritte Anwendungsfall, der Prozess-Agent, ist der anspruchsvollste und wertvollste. Hier antwortet der Agent nicht nur, er handelt: Über Actions und Power-Automate-Flows erfasst er eine Urlaubsanfrage, eröffnet ein Ticket, bereitet eine Bestellung vor oder stößt eine Genehmigung an. Aus dem Gespräch wird ein Vorgang. Das ist der Punkt, an dem Copilot Studio seinen vollen Mehrwert entfaltet – und zugleich die höchste Sorgfalt verlangt, weil ein handelnder Agent Berechtigungen, Fehlerbehandlung und Nachvollziehbarkeit ernst nehmen muss. Wir empfehlen, Prozess-Agenten schrittweise einzuführen: erst mit menschlicher Freigabe im entscheidenden Moment, dann bei bewährten, risikoarmen Abläufen zunehmend eigenständig.
Die wichtigste Erwartung, die es zu steuern gilt: Bei Copilot Studio kostet nicht der Bau eines Agenten das meiste, sondern sein laufender Betrieb. Das Nachrichten- und Kapazitätsmodell aus Kapitel 04 bedeutet, dass jede Interaktion Kapazität verbraucht und generative Antworten dabei stärker zu Buche schlagen als einfache. Ein wenig genutzter interner Bot verursacht geringe laufende Kosten; ein stark frequentierter, öffentlich erreichbarer Kundenservice-Agent kann erheblichen Verbrauch erzeugen. Wer nur die Einstiegshürde betrachtet und den Betrieb ausblendet, unterschätzt die Gesamtkosten systematisch.
Hinzu kommen die oft übersehenen Plattform-Kosten: Nutzt ein Agent Premium-Connectoren oder speichert er Daten in Dataverse, können dafür eigene Lizenz- oder Kapazitätsanforderungen entstehen. Und schließlich verursacht die Pflege laufenden Aufwand – Wissensquellen müssen aktuell gehalten, Antwortqualität überwacht und Themen erweitert werden. In einer ehrlichen Gesamtkostenbetrachtung gehören diese drei Posten – Betriebsverbrauch, Plattform-Bestandteile und Pflege – neben den einmaligen Aufbauaufwand.
Wir nennen bewusst keine konkreten Preise: Die Konditionen ändern sich häufig, unterscheiden sich zwischen eigenständiger und Copilot-gebundener Lizenzierung und hängen stark vom Nutzungsvolumen ab. Was stabil bleibt, ist die Logik. Deshalb empfehlen wir, vor jedem produktiven Agenten drei Fragen zu beantworten: Wie viele Interaktionen sind realistisch zu erwarten? Wie hoch ist der Anteil generativer Antworten? Welche Plattform-Bestandteile – Premium-Connectoren, Dataverse – werden gebraucht? Aus diesen Antworten wird eine belastbare Schätzung, die weit mehr wert ist als ein aus dem Internet gegriffener Listenpreis. Die aktuellen Konditionen sind dann beim Anbieter oder Partner zu verifizieren, bevor eine Investitionsentscheidung fällt.
Für die DSGVO ist die Datenresidenz zentral. Copilot Studio lässt sich über die zugrundeliegende Power-Platform-Umgebung in einer EU-Region betreiben, sodass die verarbeiteten Daten in europäischen Microsoft-Rechenzentren verbleiben. Die Region wird beim Aufsetzen der Umgebung festgelegt und sollte bewusst gewählt werden, da eine spätere Änderung aufwendig ist. Zu beachten bleibt: Microsoft ist ein US-Konzern und unterliegt dem US Cloud Act. Die Wahl einer EU-Region reduziert das Restrisiko deutlich, hebt es aber nicht vollständig auf. Für die meisten Mittelständler ist dieses Restrisiko bei bewusster Konfiguration akzeptabel; für besonders sensible Daten, Berufsgeheimnisträger oder KRITIS-nahe Bereiche gehört die Frage in eine sorgfältige, fallbezogene Bewertung.
Für die Rolle als Auftragsverarbeiter stellt Microsoft einen Auftragsverarbeitungsvertrag (AVV) bereit, der als Vertragsbasis für die Verarbeitung personenbezogener Daten dient. Für Häuser, die bereits Microsoft 365 nutzen, gilt dieser Rahmen in der Regel ohnehin – eine völlig neue Vertragsbasis ist meist nicht nötig, wohl aber die Prüfung, ob der bestehende AVV den konkreten Copilot-Studio-Einsatz abdeckt.
Das Copilot-Studio-spezifische Datenschutzthema sind die Wissensquellen. Ein Agent, der aus SharePoint-Bibliotheken, Dateien oder Dataverse-Tabellen antwortet, greift auf Inhalte zu, die personenbezogene Daten enthalten können – Personaldokumente, Kundenkorrespondenz, interne Vermerke. Daraus folgen zwei Pflichten. Erstens muss klar sein, welche Quellen ein Agent nutzen darf und ob deren Inhalte für den vorgesehenen Zweck überhaupt verwendet werden dürfen. Zweitens – und das ist der kritische Punkt – muss der Agent die Zugriffsrechte der Nutzer respektieren: Er darf einem Fragenden nur Auskünfte geben, die dieser ohnehin sehen dürfte. Ein Agent, der diese Grenze verwischt, wird zur Umgehung bestehender Berechtigungen und damit selbst zum Datenschutzrisiko. Governance rund um Wissensquellen und Berechtigungen ist deshalb kein Nice-to-have, sondern Voraussetzung für einen datenschutzkonformen Betrieb.
Zum Umgang mit den Daten gibt Microsoft eine wichtige Zusage: Nach Angabe von Microsoft werden Copilot-Daten nicht zum Training der zugrundeliegenden Modelle verwendet. Das ist ein relevanter Baustein für die datenschutzrechtliche Bewertung – wir kennzeichnen es bewusst als Zusage des Anbieters, die im Rahmen der eigenen Prüfung und der vertraglichen Grundlagen nachzuvollziehen ist, nicht als unabhängig verifizierte Tatsache.
