Die Architektur entscheidet, was KI darf

Viele Unternehmen experimentieren derzeit mit KI. Wo siehst du aktuell die grössten blinden Flecken, wenn es um Sicherheit und Kontrolle geht?

Michael Kloos: Grundsätzlich sehen wir eine sehr grosse Bandbreite. Manche Unternehmen sind schon sehr weit und arbeiten bereits selbstverständlich mit Konzepten wie MCP. Andere stehen noch am Anfang und stellen sich grundlegende Fragen: Wie sichere ich mein LLM ab? Was ist eine sichere Architektur? Was bedeutet Datensouveränität überhaupt? Wo liegen meine Daten? Wer verarbeitet sie? Diese Fragen sind bei vielen noch unklar und manchmal wurden sie noch gar nicht gestellt.

Wo verlieren Unternehmen in der Praxis besonders häufig die Übersicht?

Oft treffen zwei Perspektiven aufeinander. Die Projektabteilungen wollen möglichst schnell Ergebnisse erzielen, während die IT vorsichtiger ist – aus technischen Gründen, aber auch wegen Datensouveränität, ethischer Fragen und regulatorischer Anforderungen. Hinzu kommt, dass die Kosten häufig nicht vollständig transparent sind. Bei KI sind nicht nur Spracherkennung und LLM-Nutzung Kostentreiber, sondern zunehmend auch Sprachsynthese. Gerade bei generativer KI entstehen ständig neue Texte, die synthetisiert werden müssen. Solche Kosten fallen im Probebetrieb oft kaum auf, können im Betrieb aber relevant werden.

Wir bewegen uns vom sprechenden Bot hin zur handelnden KI. Was verändert sich dadurch fundamental?

Früher war Automatisierung häufig eine Art Formularausfüllen. Der Nutzer gab Informationen ein, der Bot las sie vielleicht noch einmal vor und bestätigte sie. Aber der Bot löste nicht wirklich selbst Aktionen aus. Bei agentischer KI ist das anders. Die KI initiiert und führt selbstständig Aktionen aus. Es geht also nicht mehr nur darum, etwas abzuarbeiten. Es geht um komplexe, teilweise schreibende Zugriffe. Die KI entscheidet, wann was gemacht wird. Genau deshalb braucht es klare Leitplanken, Governance und Kontrolle.

Was bedeutet Datensouveränität in diesem Zusammenhang konkret?

Viele sprechen zuerst über Modelle:

• Welches neue LLM ist verfügbar?
• Welches ist besser?
• Welches ist veraltet?

Aus meiner Sicht ist das heute aber nicht mehr die entscheidende Diskussion. Die eigentliche Frage lautet: Welche Architektur wähle ich, um eine KI-Lösung zu realisieren?

Die Architektur bestimmt, wie die Lösung insgesamt aufgebaut ist. Sie sichert die Lösung ab, orchestriert die verschiedenen Agenten und legt fest, wer worauf zugreifen darf. Das LLM wird dabei vor allem für die Kommunikation mit dem Nutzer eingesetzt. Es hat eine enorme Sprachfähigkeit und kann auch einzelne Aufgaben übernehmen. Aber die Kontrolle liegt in der Architektur. Mit einer klaren Architektur kann ich auch erreichen, dass ich ein LLM, eine Spracherkennung oder eine Sprachsynthese austauschen kann. Die Architektur bleibt. Und genau dort integriere ich Themen wie Verschlüsselung, Anonymisierung und Schnittstellenabsicherung.

Das heisst, Unternehmen sollten nicht zuerst nach dem besten Modell fragen, sondern nach der richtigen Architektur?

Genau. Man muss sich grundsätzlich für einen Standard entscheiden. Einer der wichtigen Standards, den grosse Unternehmen heute einführen, ist das Model Context Protocol, kurz MCP. MCP strukturiert grundsätzlich nach Prompts, also Handlungsanweisungen, Tools, also Werkzeugen, und Ressourcen wie Datenquellen oder Formularen.

Der zentrale Gedanke dahinter ist: Das LLM soll austauschbar sein und klar von den Unternehmensdaten getrennt werden. Früher hat man oft versucht, möglichst viel Wissen in einen riesigen Prompt zu packen. Solche Bots wurden immer grösser, langsamer und unbeweglicher. Mit MCP verfolgt man eine andere Strategie: Das LLM bekommt nicht alles von Anfang an, sondern muss Daten gezielt anfragen. Es erhält also nur das, was es für eine konkrete Aufgabe braucht.

Warum ist es so wichtig, dass ein LLM Daten anfragen muss, statt direkt darauf zuzugreifen?

Es geht um Kontrolle, Datenhoheit und Datensouveränität. Am Anfang hat man oft sehr viel Wissen in das LLM hineingesteckt – Unternehmenswissen, Informationen über Kunden, Kontextdaten. Man ging davon aus, das LLM werde schon damit umgehen können. Aus Sicherheitsgründen ist das aber problematisch.

Heute geht es darum, den Datenzugriff zu begrenzen. Das LLM muss den Zugriff bei Bedarf anfordern. Dadurch kann ich gezielt Anonymisierung einsetzen und kontrollieren, welche Daten überhaupt freigegeben werden. Das Prinzip lautet: Man muss nicht alles wissen, sondern wissen, wo es steht und wer es weiss. So sollte auch ein LLM agieren. Es hat Tools, es hat Handlungsanweisungen, aber es muss nicht das ganze Unternehmen kennen. Wenn es etwas braucht, fragt es an – und dieser Zugriff wird kontrolliert.

Kannst du das an einem konkreten Beispiel erklären?

Nehmen wir einen Versicherungsfall: Einem Kunden wurde das E-Bike gestohlen, und er möchte den Schaden melden. Wenn er bei seiner Versicherung anruft und einen Bot erreicht, muss dieser Bot zuerst herausfinden, wie er die Aufgabe lösen kann. Vielleicht gibt es mehrere MCP-Server: einen für Gesundheit, einen für Kfz, einen für Hausrat. Der Bot kann abfragen, was diese Server jeweils können. Da es um ein Fahrrad geht, wird er den Hausrat-MCP-Server nutzen.

Dort findet er ein Tool zur Schadensmeldung und die dazugehörigen Handlungsanweisungen im Prompt. Zum Beispiel: Zuerst den Anrufer legitimieren, dann das Tool zur Schadensmeldung aufrufen. Das Tool gibt vor, welche Informationen benötigt werden: Wann ist der Schaden aufgetreten? Was ist konkret passiert? Gibt es eine Seriennummer? Erst wenn der Bot alle nötigen Daten gesammelt hat, ruft er das MCP-Tool auf. Dieses trägt den Schaden über das Backend der Versicherung ein und gibt anschliessend eine Bestätigung zurück.

Wo liegt dabei der Moment der Kontrolle?

In der klaren Trennung. Auf der einen Seite steht das Tool, das die Aktion ausführt. Es ist verantwortlich für gesicherte Datenzugriffe – ohne KI. Auf der anderen Seite steht das LLM, das den Dialog mit dem Anrufer führt und die benötigten Daten einsammelt. Damit gibt es eine Trennung zwischen LLM und ausführendem MCP-Tool – und letztlich eine klassische Trennung zwischen Daten und Anwendungen, die Datensicherheit und Datensouveränität gewährleistet.

Auch Freigaben, technische Prüfungen oder Vier-Augen-Prinzipien gehören in diese Logik. Solche Mechanismen liegen im MCP-Server. Der Anrufer muss legitimiert sein, es muss geprüft werden, ob er eine entsprechende Versicherung hat, und die fachlichen Regeln bleiben im Tool verankert. Das LLM übernimmt das Interaktive und Intuitive, aber die klassischen Logiken werden über den MCP-Server ausgeführt.

Das klingt stark nach IT-Projekt. Wie verhindert man, dass Fachbereich und IT auseinanderlaufen?

Genau das ist heute eine der grossen Herausforderungen. Wir sehen viele verschiedene Initiativen in Unternehmen. Jede Abteilung arbeitet für sich, möchte schnell Projekterfolge erzielen und setzt unterschiedliche Tools ein. Mitarbeitende bringen zudem oft «privates» Vorwissen über KI mit, das eher zufällig entstanden und nicht orchestriert ist. Gleichzeitig gibt es sehr unterschiedliche Aufgaben: Chatbots, Dokumentensuche, Prozessautomatisierung bis hin zu agentischen Systemen.

All das muss unter einen Hut gebracht werden. Genau hier setzt eine standardisierte KI-Architektur an. Eine MCP-Architektur sagt im Grunde: Baut verschiedene MCP-Server auf und orchestriert damit verschiedene Bots.

Braucht jeder Use Case bereits eine agentische KI-Lösung?

Nein. Wenn im Unternehmen keine Daten verändert werden, würde ich nicht von agentischer KI sprechen. Ein einfaches FAQ-System oder eine klassische Retrieval-Augmented-Generation (RAG)-Lösung kann für reine Informationswiedergabe ausreichend sein. Sobald aber ein schreibender Datenzugriff erfolgt, empfehle ich, direkt mit einer MCP-Lösung zu arbeiten und gegebenenfalls hier bestehende RAG-Lösungen in den MCP-Server einzubinden. Bei diesen Datenzugriffen braucht es eine klare IT-Strategie, um KI sicher und souverän einsetzen zu können.

Welche Rolle spielt MCP im Hinblick auf Anbieterabhängigkeit?

Eine Standardarchitektur hat gerade das Ziel, unabhängiger zu werden. Wenn ich im Unternehmen eine MCP-Serverlandschaft habe, kann ich verschiedene Bots unterschiedlicher Hersteller darauf laufen lassen. Auch der Einsatz des LLMs sollte möglichst unabhängig gestaltet sein. Natürlich haben einzelne Modelle spezifische Stärken. Aber die grundsätzliche Plattformstrategie sollte sein, nicht von einem LLM-Anbieter abhängig zu werden.

Wir sehen, dass Kunden zunehmend darüber nachdenken, von grossen Anbietern unabhängiger zu werden. Lokale LLMs, lokale GPUs und kleinere Modelle werden attraktiver und leistungsfähiger. Gleichzeitig wächst der Wunsch nach Datensouveränität und On-Premises-Einsatz. Deshalb ist es wichtig, dass Plattformanbieter den Unternehmen Freiheit lassen – bei Spracherkennung, Sprachsynthese und LLM.

Wie entwickelt sich das Thema aus deiner Sicht weiter?

Datensouveränität ist bei allen Unternehmen präsent. Manche grossen Technologieanbieter sind etwas in Ungnade gefallen, und Unternehmen werden vorsichtiger, sich vollständig auf deren Plattformen einzulassen. Solche Plattformen sind sehr mächtig, erzeugen aber auch starke Abhängigkeiten (Vendor-Lock-In). Viele Unternehmen wollen das nicht mehr und verfolgen zumindest eine zweigleisige Strategie.

MCP ist zwar noch nicht überall in den Fachabteilungen angekommen, aber in vielen IT-Abteilungen ist sehr wohl bewusst, wie wichtig dieser Ansatz werden kann. Die Aufgabe wird sich zunehmend dahin verschieben, MCP-Server zu entwickeln und damit eine kontrollierte, standardisierte KI-Architektur aufzubauen.

Was bedeutet das für Omnichannel-Lösungen im Customer Service?

Die MCP-Architektur selbst ist kanalunabhängig. Für das Frontend kann man dann entscheiden, ob man verschiedene Chatkanäle einheitlich löst oder differenziert. Sprache hat andere Anforderungen als Webchat. Ein Anrufer muss vielleicht stärker geführt werden, während ein Webchat mehr Informationen auf einmal anzeigen kann. WhatsApp wiederum lebt stärker von Bildern, Videos oder Links. MCP hilft, die Architektur der Daten- und Backendzugriffe im Hintergrund einheitlich zu halten, während die Ausgestaltung der Kanäle unterschiedlich sein kann.

Was ist aus deiner Sicht der grösste Denkfehler beim KI-Einsatz im Kundenservice?

Viele Unternehmen beginnen mit dem grössten und wichtigsten Geschäftsfall, den sie schon lange automatisieren wollten. Genau dieser Fall ist aber oft besonders komplex und tückisch. Häufig gibt es einfachere Quick Wins, mit denen man schnell eine Lösung aufbauen kann – mit weniger Risiko, aber sichtbarem Erfolg. Dabei lernt das Unternehmen, kann intern Akzeptanz schaffen und sich Schritt für Schritt zu grösseren Lösungen vorarbeiten.

Wer sollte im Unternehmen am Tisch sitzen, wenn es um KI-Architektur geht?

Heute sitzen Fachabteilungen und IT oft noch an getrennten Tischen. Die einen wollen schnell Projekterfolge, die anderen sehen Risiken und regulatorische Anforderungen. Wichtig wäre, dass beide an einen gemeinsamen Tisch kommen. Die Technik und die Architektur sind vorhanden. KI wird den Kundenservice verändern. Entscheidend ist jetzt, dass Unternehmen gemeinsam klären, wie sie anfangen.

Was würdest du Customer Service-Verantwortlichen konkret raten?

Sie sollten sich zunächst klar machen, was ihre Kunden tatsächlich erwarten – Privatkunden wie Geschäftskunden. Dann geht es darum, die eigenen Hausaufgaben zu machen: Welche Geschäftsfälle lassen sich gut definieren? Was eignet sich als Quick Win? Wo lässt sich mit überschaubarem Risiko ein kommerziell sinnvoller Use Case umsetzen? Mit einer einfachen Umsetzbarkeit und einem begrenzten Risiko kommt man am ehesten auch im Management durch.