# KI-Agenten scheitern am Datenzugriff: So werden KMU agentenbereit

> Autor: Chris Jon Graf (KI-Stratege & CEO)
> Aktualisiert: 2026-09-14
> URL: https://ki-outsourcing.ch/ratgeber/ki-agenten-scheitern-am-datenzugriff-so-werden-kmu-agentenbereit

## Zusammenfassung

KI-Agenten scheitern selten am Modell, sondern am Zugriff auf die richtigen Daten. Der MCP-Standard reduziert Integrationsaufwand von O(N×M) auf O(N+M). Schweizer KMU brauchen drei Schichten: MCP-Server pro System, eine föderierte Abfragschicht und identity-basierte Berechtigungen – sonst bleiben Agenten Chatbots.

## Das eigentliche Problem: Nicht das Modell, sondern der Zugriff

Die meisten KMU-Projekte scheitern nicht an der Intelligenz des Modells. Sie scheitern daran, dass ein Agent zur richtigen Zeit auf die richtigen Daten zugreifen darf – über ERP, CRM, DMS, HR und Ticketing hinweg. Typischerweise betreiben Schweizer KMU 3 bis 8 Kernsysteme, jedes mit eigener API, eigenem Berechtigungsmodell und eigenen Datenformaten. Genau hier entsteht Agent Sprawl: Viele halb fertige Agenten, die nur einen Ausschnitt sehen. Warum viele KI-Agenten-Piloten nie produktiv gehen

- Agenten greifen nur auf ein System zu und geben unvollständige Antworten
- Berechtigungen werden pro Tool manuell konfiguriert und laufen auseinander
- Jede neue Integration kostet O(N×M) Aufwand statt O(N+M)

## MCP: Der gemeinsame Standard für Agentenzugriffe

Das Model Context Protocol (MCP) hat sich zum Quasi-Standard entwickelt. Es verbindet KI-Agenten über ein einheitliches Protokoll mit Tools und Datenquellen – vergleichbar mit einem "USB-C-Port für KI", wie es SAS ausdrückt. Im Dezember 2025 wurde MCP an die Agentic AI Foundation unter dem Dach der Linux Foundation übergeben. Das Protokoll verzeichnet 97 Millionen monatliche SDK-Downloads.

> Das Model Context Protocol ist der USB-C-Port für KI.
>
> — SAS Model Context Protocol

Für KMU bedeutet das: Statt N×M Punkt-zu-Punkt-Integrationen zwischen Agenten und Systemen zu bauen, genügt eine MCP-Schicht pro System. Ein MCP-Server kapselt die Zugriffe, gibt Tools und Ressourcen kontrolliert frei und sorgt für ein einheitliches Berechtigungsmodell. Wer heute Systeme anbindet, sollte auf MCP-Kompatibilität achten.

**97 Mio.** — monatliche MCP SDK-Downloads

**3–8** — typische Kernsysteme in Schweizer KMU

## Schicht 1: MCP-Server für jedes Kernsystem

Jedes Kernsystem bekommt einen eigenen MCP-Server. Bei Microsoft SQL Server ist das bereits eingebaut: Der SQL MCP Server ab DAB 1.7 stellt SQL-Operationen als MCP-Tools bereit und nutzt integrierte RBAC. Monarch geht noch weiter: Der Product Graph erfasst nicht nur dokumentierte APIs, sondern auch undocumented Endpoints, UI-Pfade, Berechtigungen und Workflow-Regeln. So können Agenten zuverlässig auf Systeme zugreifen, die nie für KI gebaut wurden.

> **Governance nicht vergessen**
>
> Roher SQL-Zugriff ist ein Governance-Problem. Wer Agenten direkten Datenbankzugriff gibt, riskiert unkontrollierte Abfragen. MCP-Tools mit klaren Berechtigungen sind der sicherere Weg.

## Schicht 2: Föderierte Datenschicht oder AI Gateway

Die zweite Schicht verbindet die MCP-Server und sorgt dafür, dass Agenten nicht in Datensilos hängen bleiben. Zwei Muster haben sich bewährt: catalog-first governance und direct access. Databricks setzt mit Agent Bricks auf Unity Catalog und AI Gateway, ibl.ai verbindet SIS, LMS, CRM, HRIS und ERP über einen Integration Bus – Echtzeitabfragen ohne Daten-Duplikation. Oracle positioniert seine AI Database für sicheren Zugriff auf operative Daten.

1. Catalog-first: Der Agent bekommt nur Zugriff auf Daten, die im Katalog freigegeben sind
2. Direct access: Der Agent fragt über kontrollierte MCP-Tools direkt im Quellsystem an

## Schicht 3: Identity-basierte Zugriffskontrolle

Ohne klare Berechtigungen hilft die beste Infrastruktur nichts. MCP-Plugins wie Kaman.ai setzen auf OAuth 2.0-Felder, damit jeder Zugriff an eine Identität gebunden ist. Unity Catalog und AI Gateway sorgen für end-to-end Permissions. Das ist auch rechtlich relevant: Das revDSG verlangt klare Datenflüsse und Nachvollziehbarkeit – eine föderierte Architektur mit Identity-basierten Zugriffen erfüllt das besser als ein zentraler Datenlake. Mehr dazu in unserem Leitfaden zur [Governance-Lücke bei KI-Agenten](/ratgeber/ki-agenten-als-standard-feature-warum-die-governance-lucke-jetzt-schliesst-werde).

## Der Schweizer Weg: Datensouveränität als Architekturprinzip

Schweizer KMU haben besondere Anforderungen: revDSG, Datensouveränität, oft keine eigene grosse Datenplattform. Eine föderierte Datenschicht, die Daten dort lässt, wo sie liegen, passt besser als ein zentraler Datenlake. Projekte wie [Apertus LLM von der ETH Zürich](https://www.ki-podcast.ch/apertus-llm-eth-zuerich-digitale-souveraenitaet) zeigen, wie Confidential Computing dabei helfen kann, sensible Daten auch bei externer Verarbeitung zu schützen.

> **Datenschutz als Architekturprinzip**
>
> Wer Datenzugriffe für Agenten plant, sollte Datenschutz nicht nachrüsten, sondern von Anfang an in die Architektur integrieren.

## Erster Schritt: Bestandsaufnahme statt Big Bang

Agentenbereite Infrastruktur entsteht nicht über Nacht. Der klügste erste Schritt ist eine ehrliche Bestandsaufnahme: Welche Kernsysteme gibt es? Welche APIs sind vorhanden? Wo liegen Berechtigungen heute? Danach lohnt sich ein Pilot mit einem einzigen MCP-Server und einem überschaubaren Use Case. Wer diese Basis legt, kann später Schritt für Schritt weitere Systeme anbinden – ohne die Gesamtarchitektur neu zu bauen.

1. Inventar aller Kernsysteme und APIs erstellen
2. Ein Pilot-System mit MCP-Server anbinden
3. Identity-Provider und Berechtigungskonzept koppeln
4. Mit einem klar abgegrenzten Use Case starten

## Häufige Fragen

### Was ist das Model Context Protocol (MCP)?

MCP ist ein offener Standard, der KI-Agenten über ein einheitliches Protokoll mit Tools und Datenquellen verbindet. Er reduziert Integrationsaufwand von O(N×M) auf O(N+M) und wird von der Linux Foundation gepflegt.

### Warum scheitern KI-Agenten in KMU oft am Datenzugriff?

Weil Kernsysteme wie ERP, CRM und DMS unterschiedliche APIs, Berechtigungen und Datenformate haben. Ohne MCP-Server oder föderierte Datenschicht sehen Agenten nur Ausschnitte und liefern unvollständige Ergebnisse.

### Braucht jedes System einen eigenen MCP-Server?

Ja, idealerweise. Ein MCP-Server pro System kapselt die Zugriffe, stellt Tools und Ressourcen kontrolliert bereit und vereinheitlicht Berechtigungen. Das ist die Basis für agentenbereite Infrastruktur.

### Wie passt das zum revDSG?

Das revDSG verlangt klare Datenflüsse und Nachvollziehbarkeit. Eine föderierte Architektur mit identity-basierten Zugriffen erfüllt das besser als ein zentraler Datenlake, weil Daten dort bleiben, wo sie hingehören.

### Was ist der Unterschied zwischen Datenlake und föderierter Datenschicht?

Ein Datenlake kopiert Daten zentral, was Datenschutz- und Aktualitätsprobleme schafft. Eine föderierte Schicht fragt Daten in Echtzeit an der Quelle ab, ohne Duplikate – das passt besser zu den Anforderungen von Schweizer KMU.

## Quellen

- [From silos to insights: Federated data access patterns for AI agents](https://aws.amazon.com/blogs/big-data/from-silos-to-insights-federated-data-access-patterns-for-ai-agents/)
- [Agent Bricks: The Governed Enterprise Agent Platform](https://www.databricks.com/blog/agent-bricks-governed-enterprise-agent-platform)
- [Federated AI Data Layer](https://ibl.ai/resources/capabilities/federated-ai-data-layer)
- [Monarch: AI agents that operate your systems](https://www.monarchagents.ai/)
- [Oracle Unveils AI Database Agentic Innovations for Business Data](https://www.oracle.com/news/announcement/oracle-unveils-ai-database-agentic-innovations-for-business-data-2026-03-24/)
- [SQL MCP Server overview](https://learn.microsoft.com/en-us/azure/data-api-builder/mcp/overview)
- [Model Context Protocol: What it is and why it matters](https://www.sas.com/en_nz/insights/analytics/model-context-protocol.html)
- [The Model Context Protocol and Enterprise Tool Orchestration](https://ijcesen.com/index.php/ijcesen/article/view/5402)