Agentic AI, KI-Agenten & MCP-Server

Agentic AI bezeichnet KI-Systeme, die ein Ziel in einzelne Schritte zerlegen, passende Werkzeuge aufrufen und deren Resultate für den nächsten Schritt verwenden. Ein KI-Agent ist die konkrete Anwendung dieses Prinzips. MCP (Model Context Protocol) standardisiert, wie ein KI-Client solche Werkzeuge entdeckt und aufruft. MCP gibt Zugriff — Berechtigungen, Datenschutz und Freigaben müssen zusätzliche Schichten durchsetzen.

Das klingt abstrakt, bis eine reale Aufgabe dahintersteht: «Finde den Kunden Meier AG, suche Artikel SB-630 und bereite eine Offerte über 20 Stück vor.» Ein Chatbot kann den Satz formulieren. Ein Agent kann Kontakte und Artikel in Bexio suchen und einen Offertenentwurf anlegen. Genau an diesem Übergang vom Antworten zum Handeln entstehen Nutzen und Risiko.

Was unterscheidet Chatbot, Assistent und KI-Agent?#

Die Begriffe werden oft vermischt. Für eine technische und geschäftliche Entscheidung hilft diese Trennung:

Nicht jede Automatisierung braucht einen Agenten. Wenn Eingabe, Regel und Ergebnis eindeutig sind, ist normaler Code meist günstiger, testbarer und einfacher zu betreiben. Ein Agent ist sinnvoll, wenn Sprache, Dokumente oder mehrdeutige Entscheidungen vorkommen, aber die erlaubten Aktionen trotzdem schmal begrenzt werden können.

Wie sieht die Architektur eines produktiven KI-Agenten aus?#

Ein belastbarer Agent besteht nicht nur aus einem Sprachmodell. Der Datenfluss braucht mindestens sechs Schichten:

1. Nutzer und Identität. Eine konkrete, eingeloggte Person stellt die Anfrage. Ein geteilter «KI-Account» ohne Zuordnung reicht für produktive Schreibzugriffe nicht.
2. Agent oder KI-Client. Claude, ChatGPT oder eine eigene Oberfläche interpretiert die Aufgabe und schlägt Werkzeugaufrufe vor.
3. Werkzeug-Adapter. Ein MCP-Server oder eine direkte Tool-Calling-Schicht übersetzt den Vorschlag in eine klar definierte Funktion wie search_contacts oder create_offer.
4. Policy- und Privacy-Schicht. Rollen, erlaubte Felder, Datenminimierung, Tokenisierung und notwendige Freigaben werden geprüft, bevor ein Drittsystem angesprochen wird.
5. Fachsystem. Bexio, Abacus, ein CRM oder eine eigene API führt die erlaubte Lese- oder Schreibaktion aus.
6. Resultat und Audit-Spur. Die Antwort geht zurück zum Agenten; Werkzeug, Nutzer, Zeitpunkt, Freigabe und Ergebnis werden nachvollziehbar protokolliert.

Der zentrale Grundsatz lautet: Das Modell schlägt vor, die Anwendung setzt die Regeln durch. Eine Anweisung im Prompt ist hilfreich, aber keine technische Zugriffskontrolle. Kritische Regeln gehören serverseitig vor den Werkzeugaufruf.

Unsere Architekturseite zu MCP, Privacy-Gateway und Datenfluss zeigt diese Schichten als zusammenhängendes System. Die Privacy-Gateway-Demo macht zusätzlich sichtbar, welche Felder das Modell nach Tokenisierung tatsächlich erhält. Die Demo arbeitet ausdrücklich mit fiktiven Testdaten.

MCP versus direkte API und Tool Calling#

MCP und eine direkte API-Integration lösen verwandte, aber nicht identische Aufgaben.

MCP ist also kein Ersatz für die Bexio-API. Der MCP-Server sitzt davor und übersetzt standardisierte Werkzeugaufrufe in die konkreten Bexio-Endpunkte. Ebenso ist MCP kein Datenschutz-Gateway: Wenn ein Werkzeug zu viele Felder zurückgibt, reicht das Protokoll diese Daten zuverlässig weiter. Die Filterung muss vor oder nach dem Fachsystem-Aufruf bewusst implementiert sein.

Für einen einzelnen, stabilen Prozess ist eine direkte Integration häufig der kleinere Weg. MCP lohnt sich, wenn ein wiederverwendbarer Werkzeugkatalog mehreren KI-Clients oder Agenten dienen soll. Unsere Leistung KI-Agents & MCP-Server deckt beide Varianten ab; ERP- & API-Integration ist der passende Einstieg für deterministische Systemverbindungen. Die breitere KI-Agentur für Schweizer KMU beginnt eine Stufe früher bei der Frage, ob überhaupt gebaut werden soll.

Ein konkreter Bexio-Ablauf#

Ein sicherer Offertenablauf kann so aussehen:

1. Der Mitarbeiter nennt Kunden, Artikel und Menge.
2. Der Agent ruft zuerst search_contacts auf. Bei mehreren Treffern muss der Mensch wählen; bei keinem Treffer darf kein Kunde erfunden werden.
3. search_articles sucht nach Artikelname und SKU. Mehrdeutige Treffer werden angezeigt, ein fehlender Preis wird nicht geschätzt.
4. Der Agent fasst Kontakt, Positionen, Mengen und Preise zusammen.
5. Erst nach Bestätigung darf create_offer laufen.
6. Bexio legt die Offerte als Entwurf an. Der Mitarbeiter öffnet sie über den zurückgegebenen Bexio-Link, prüft und versendet selbst.

Der gleiche Werkzeugansatz unterstützt auch das Nachschlagen von Kontakten, Artikeln, Offerten und Rechnungen sowie das Vorbereiten von Aufträgen und Rechnungsentwürfen. Der Bexio-Sachbearbeiter-Copilot zeigt die bestehende direkte Tool-Calling-Schicht mit einem bewusst kuratierten Ausschnitt für den Innendienst. Die Bexio-MCP-Seite dokumentiert dagegen transparent die künftige Adapterarchitektur; ein produktiver MCP-Server ist dort noch nicht live. Vorführungen verwenden fiktive Testdaten, nicht Kundendaten.

Diese Begrenzung ist ein Vorteil. Ein Agent braucht nicht «Zugriff auf Bexio», sondern genau die Funktionen, die für seine Aufgabe notwendig sind. Freier Datenbankzugriff, beliebige API-Pfade oder ein universelles «execute»-Werkzeug vergrössern die Angriffs- und Fehlerfläche ohne fachlichen Mehrwert.

OAuth, Berechtigungen und Zugriffsmodell#

Für Bexio verwenden wir im vorgesehenen Produktionspfad OAuth 2.0 mit Authorization Code und Refresh Token. Der Nutzer verbindet Bexio über den Einwilligungsdialog; Access- und Refresh-Token bleiben serverseitig. In der bestehenden Demo werden gespeicherte Tokens mit AES-256-GCM verschlüsselt. Ein Personal Access Token dient nur als Übergangs-Fallback, nicht als bevorzugtes Mehrbenutzer-Modell.

OAuth allein löst jedoch nicht alle Berechtigungsfragen. Ein robustes Zugriffsmodell prüft auf drei Ebenen:

Die aktuelle Demo speichert eine aktive Bexio-Verbindung und ist bewusst kein fertiges Multi-Tenant-Produkt. Für mehrere Firmen muss der Token-Store nach Mandant und Nutzer getrennt werden. Genau solche Grenzen gehören in ein Pilotprotokoll: Was beweist die Demo bereits, und welche Kontrollen werden vor dem Produktivbetrieb ergänzt?

Human Approval: mehr als «Bitte zuerst fragen»#

Eine menschliche Freigabe kann auf drei Arten umgesetzt werden:

1. Konversationell: Der Agent fragt im Chat nach Bestätigung. Das ist in einer Demo verständlich, aber allein nicht manipulationssicher.
2. Serverseitige Freigabe: Ein schreibendes Werkzeug erhält erst nach einem separaten, kurzlebigen Freigabe-Token Zugriff. Das Modell kann diesen Schritt nicht überspringen.
3. Entwurfsprinzip: Der Agent erstellt nur einen Entwurf; Veröffentlichung, Versand, Zahlung oder Löschung bleibt im Fachsystem beim Menschen.

Für Offerten und Rechnungen ist das Entwurfsprinzip besonders praktisch: Die Automatisierung spart Erfassungsarbeit, ohne die fachliche Verantwortung zu verschieben. Für irreversible oder finanzielle Aktionen — etwa Gutschriften, Zahlungen, Vertragsänderungen, Löschungen oder Massenexporte — reicht eine Chat-Bestätigung nicht. Hier braucht es eine technisch erzwungene Freigabe oder gar kein Agenten-Werkzeug.

Logging: Was muss nachvollziehbar sein?#

Ein brauchbarer Audit-Eintrag beantwortet mindestens diese Fragen:

• Wer hat die Aufgabe ausgelöst?
• Welches Werkzeug wurde wann und für welchen Mandanten aufgerufen?
• Welche Freigabe lag vor?
• War der Aufruf erfolgreich, abgelehnt oder fehlerhaft?
• Welche Datenklassen wurden gefiltert oder tokenisiert?
• Welche Fachsystem-ID entstand, ohne den gesamten Personendatensatz ins Log zu kopieren?

Die Demo-Oberflächen zeigen Werkzeugaufrufe und Resultate, und das Privacy-Gateway erzeugt pro Transformation einen Audit-Eintrag. Das ist gute technische Transparenz, aber noch kein automatischer Compliance-Nachweis. Produktiv braucht es eine persistente, zugriffsgeschützte Aufbewahrung mit Löschfrist, Mandantentrennung und einer klaren Entscheidung, welche Werte gerade nicht ins Log gehören.

Fehlerfälle, die vor dem Pilot definiert werden müssen#

Agenten scheitern selten am perfekten Normalfall. Entscheidend sind die Ränder:

In unserem Copilot begrenzt eine harte Rundenzahl endlose Tool-Schleifen. Schreibvorgänge werden nicht blind parallelisiert, weil Bexio Anfragen begrenzen kann. Bei Mehrdeutigkeit soll der Agent nachfragen statt raten. Solche Regeln sind weniger spektakulär als die Demo-Antwort, machen aber den Unterschied zwischen einem Prototyp und einem betreibbaren System.

nDSG: Datenminimierung statt pauschaler «KI-Konformität»#

Ein KI-Agent ist nicht automatisch nDSG-konform, nur weil die Anwendung in der Schweiz läuft. Relevant ist der gesamte Datenfluss: Welche Personendaten verlassen Bexio, welcher Modellanbieter erhält sie, zu welchem Zweck, wie lange werden sie gespeichert und wer kann die Aufrufe sehen?

Unser technischer Ansatz reduziert diesen Umfang:

• nur die für das Werkzeug benötigten Felder abrufen;
• sensible Werte vor dem Modell tokenisieren oder entfernen;
• Lese- und Schreibrechte getrennt behandeln;
• Modelle und Infrastruktur nach Schutzbedarf wählen;
• Logs ohne unnötige Klartext-Personendaten führen;
• Freigaben und Löschfristen dokumentieren.

Tokenisierung ist dabei Pseudonymisierung, nicht Anonymisierung. Solange eine Zuordnung zurück zur Person möglich ist, bleiben Schutzpflichten bestehen. Der Beitrag KI nutzen, ohne Kundendaten preiszugeben erklärt die technische Schutzschicht im Detail; unsere Datenschutzerklärung legt die eingesetzten Anbieter und Verarbeitungen offen. Die konkrete rechtliche Beurteilung hängt trotzdem vom Prozess und den Datenkategorien des Unternehmens ab.

Wann MCP die richtige Wahl ist — und wann nicht#

MCP passt, wenn mehrere kompatible KI-Clients denselben kontrollierten Werkzeugkatalog verwenden sollen, wenn Systemfunktionen sauber als kleine Werkzeuge beschrieben werden können und wenn Authentifizierung, Policies und Betrieb verantwortet werden.

Eine direkte Integration passt besser, wenn ein einzelner Ablauf automatisiert wird, wenn eine eigene Oberfläche genügt oder wenn sehr strikte, deterministische Prozessschritte wichtiger sind als Client-Portabilität.

Gar kein Agent passt, wenn eine feste Regel, ein normaler API-Job oder ein Dashboard die Aufgabe zuverlässig löst. Ein Agent sollte Unsicherheit bearbeiten, nicht unnötig in eindeutige Abläufe eingebaut werden. Die ausführliche Auswahl zwischen SaaS, Custom GPT, RAG, Integration, Agent und Eigenbau steht im Leitfaden KI-Tools für KMU.

Wer diese Entscheidung nicht nur auf Folien, sondern an einem konkreten Ausschnitt prüfen will, kann mit dem kostenlosen 10-Tage-Prototyp starten. Die Bexio-MCP-Architekturvorschau grenzt den aktuellen direkten Werkzeugzugriff vom künftigen Adapter ab; für produktive technische Umsetzung ist der Bereich KI-Agents & MCP-Server der richtige Einstieg.