Datenqualität für KI-Agenten: Warum Nutzen vor dem Modell beginnt

KI-Agenten versprechen, Arbeit nicht nur zu unterstützen, sondern Aufgabenketten eigenständig zu planen und auszuführen. In der Praxis entscheidet jedoch selten allein das Modell über den Nutzen. Entscheidend ist, ob Daten auffindbar, verständlich, aktuell, berechtigt nutzbar und technisch erreichbar sind. Die zentrale These: Wer KI-Agenten produktiv einsetzen will, muss Datenqualität als Architektur- und Betriebsaufgabe behandeln, nicht als nachgelagertes Aufräumprojekt.

Datenqualität für KI-Agenten verstehen

Datenqualität beschreibt mehr als fehlerfreie Tabellen. Für KI-Agenten zählt, ob Informationen in einem konkreten Arbeitskontext belastbar genug sind, damit ein System daraus sinnvolle Schritte ableiten kann. Dazu gehören Korrektheit, Aktualität, Vollständigkeit, Konsistenz, Nachvollziehbarkeit, Berechtigungsstatus und maschinenlesbare Semantik.

Ein typisches Missverständnis ist die Annahme, ein leistungsfähiges Sprachmodell könne schlechte Daten einfach ausgleichen. Ein Modell kann Lücken sprachlich überbrücken, Muster erkennen und Informationen zusammenfassen. Es kann aber nicht zuverlässig wissen, ob ein veralteter Kundendatensatz, eine unklare Produktbezeichnung oder eine widersprüchliche Prozessregel im Unternehmen noch gültig ist. Gerade Agenten, die Tools aufrufen, Tickets verändern, Bestellungen vorbereiten oder Codeänderungen anstoßen, verstärken die Wirkung schlechter Daten.

Ein zweites Missverständnis betrifft den Begriff "Daten". Für KI-Agenten sind nicht nur Datenbanken relevant, sondern auch Dokumente, Wikis, Tickets, E-Mails, API-Antworten, Logdaten, Berechtigungssysteme und Prozessmetadaten. Datenqualität entsteht deshalb nicht in einem einzelnen Data-Team, sondern an vielen Stellen der IT-Organisation.

Warum jetzt? Treiber und Kontext

Viele Organisationen bewegen sich von KI-Experimenten zu konkreteren Automatisierungsszenarien. Statt nur Texte zu generieren, sollen KI-Agenten recherchieren, klassifizieren, priorisieren, Systeme abfragen und Arbeitsschritte vorbereiten. Dadurch verschiebt sich die Frage von "Kann das Modell antworten?" zu "Kann der Agent im richtigen Kontext handeln?".

Technisch treiben bessere Modellfähigkeiten, Tool-Integrationen, Retrieval-Ansätze und Workflow-Orchestrierung diese Entwicklung. Organisatorisch steigt der Druck, wiederkehrende Wissensarbeit effizienter zu gestalten, ohne Kontrolle und Qualität zu verlieren. Ökonomisch geht es häufig um kürzere Durchlaufzeiten, weniger manuelle Übergaben und bessere Skalierbarkeit in Support, IT-Betrieb, Engineering und Backoffice-Prozessen.

Gleichzeitig werden Grenzen sichtbarer. Wenn interne Wissensquellen ungepflegt sind, API-Verträge uneinheitlich wirken oder Berechtigungen historisch gewachsen sind, erzeugen KI-Agenten keine robuste Automatisierung. Sie machen bestehende Unklarheiten nur schneller sichtbar. Das ist unbequem, aber nützlich: Datenqualität wird messbar, weil fehlerhafte Daten unmittelbar zu schlechten Handlungsvorschlägen, unnötigen Rückfragen oder riskanten Aktionen führen.

Wie KI-Agenten mit Daten arbeiten

Ein KI-Agent ist kein einzelnes Modell, sondern typischerweise ein Zusammenspiel aus Modell, Kontextquellen, Werkzeugen, Regeln und Kontrollpunkten. Das Modell interpretiert das Ziel und plant Zwischenschritte. Retrieval-Komponenten liefern relevante Informationen aus Dokumenten oder Datenbeständen. Tool-Integrationen ermöglichen Aktionen in Systemen wie Ticketing, Monitoring, CRM, Repositorys oder internen APIs. Guardrails begrenzen, was der Agent sehen, vorschlagen oder ausführen darf.

Aus Architekturperspektive entsteht ein Datenfluss mit mehreren Qualitätsprüfungen:

• Der Agent erhält ein Ziel, etwa die Analyse eines Incidents oder die Vorbereitung einer Lieferantenbewertung.
• Er fragt strukturierte und unstrukturierte Quellen ab, zum Beispiel Tickets, Runbooks, Vertragsdaten oder Metriken.
• Er bewertet den Kontext anhand von Regeln, Berechtigungen und Plausibilität.
• Er erzeugt einen Vorschlag, eine Zusammenfassung oder einen geplanten Aktionspfad.
• Ein Mensch, ein Freigabeprozess oder eine technische Policy entscheidet, ob daraus eine Aktion wird.
• Logs, Feedback und Ergebnisdaten fließen in Monitoring und Verbesserung zurück.

In diesem Ablauf ist Datenqualität kein statischer Zustand. Sie muss an Schnittstellen, in Metadaten, in Suchindizes, in Zugriffskontrollen und im Betrieb überwacht werden. Wichtig sind klare Datenowner, verständliche Schemas, dokumentierte Begriffe, stabile APIs, Versionierung und ein Audit-Trail für agentische Entscheidungen.

Praxis: Anwendungsfälle und Entscheidungslogik

Ein naheliegender Use Case ist der IT-Support. Ein Agent kann Tickets zusammenfassen, ähnliche Vorfälle suchen, betroffene Services identifizieren und Lösungsvorschläge aus Runbooks ableiten. Das funktioniert gut, wenn Ticketkategorien konsistent gepflegt sind, Service-Ownership klar ist und Runbooks aktuell gehalten werden. Wenn Ticketdaten uneinheitlich sind, sollte der Agent zunächst nur klassifizieren und Rückfragen vorschlagen, statt automatische Änderungen anzustoßen.

Im Incident Management kann ein Agent Logauszüge, Monitoring-Hinweise und Deployment-Informationen zusammenführen. Der Nutzen entsteht durch schnellere Kontextbildung, nicht durch blinde Ursachenbehauptungen. Wenn Telemetriedaten nachvollziehbar, zeitlich sauber korreliert und mit Service-Metadaten verbunden sind, kann ein Agent Priorisierung und Hypothesenbildung unterstützen. Wenn diese Voraussetzungen fehlen, ist ein Dashboard mit besserer Datenmodellierung oft wertvoller als ein autonomer Agent.

In der Softwareentwicklung können KI-Agenten Anforderungen prüfen, Codebereiche finden, Tests vorschlagen und Pull Requests vorbereiten. Voraussetzung sind klare Repository-Strukturen, verständliche Build- und Testsignale sowie gepflegte Architekturentscheidungen. Wenn Dokumentation und Tests veraltet sind, sollte der erste Schritt nicht mehr Autonomie sein, sondern eine Daten- und Wissensbasis, die Engineering-Realität abbildet.

Auch im IT-Management kann ein Agent bei Portfolio-, Risiko- oder Kostenanalysen helfen. Dafür braucht er belastbare Systeminventare, Kostenstellen, Vertragsdaten und Verantwortlichkeiten. Wenn diese Daten verstreut oder widersprüchlich sind, eignet sich der Agent eher als Assistent für Recherche und Datenbereinigung. Wenn Datenmodell und Governance stabil sind, kann er Entscheidungsunterlagen schneller vorbereiten.

Die Entscheidungslogik ist einfach: Wenn der Agent nur lesen, zusammenfassen oder sortieren soll, reichen oft moderate Qualitätsanforderungen und klare Quellenhinweise. Wenn er Empfehlungen mit operativer Wirkung gibt, braucht es geprüfte Daten, nachvollziehbare Regeln und menschliche Freigabe. Wenn er Aktionen selbst ausführt, sind strenge Berechtigungen, Tests, Monitoring, Rollback-Fähigkeit und Auditierbarkeit Pflicht.

Risiken, Grenzen, Kontrollmechanismen

Das größte Qualitätsrisiko ist Scheingenauigkeit. Ein Agent kann eine gut formulierte Antwort liefern, obwohl die zugrunde liegenden Daten unvollständig oder veraltet sind. Gegenmaßnahmen sind Quellenanzeige im internen System, Aktualitätsmarker, Konfidenzregeln, verpflichtende Rückfragen bei Lücken und klare Kennzeichnung von Annahmen.

Ein zweites Risiko liegt in Berechtigungen. Agenten dürfen nicht zum Umweg um etablierte Zugriffskontrollen werden. Technisch sollten sie mit eigenen Identitäten, minimalen Rechten, rollenbasierten Policies und getrennten Umgebungen arbeiten. Prozessual braucht es Freigaben für neue Datenquellen und regelmäßige Rezertifizierung der Zugriffe.

Compliance-Risiken entstehen, wenn personenbezogene, vertrauliche oder regulierte Daten in ungeeignete Workflows gelangen. Dagegen helfen Datenklassifizierung, Zweckbindung, Protokollierung, Maskierung, Aufbewahrungsregeln und klare Vorgaben, welche Daten in welchen KI-Diensten verarbeitet werden dürfen.

Qualitätsrisiken zeigen sich auch in unklaren Begriffen. Wenn "aktiver Kunde", "kritischer Service" oder "abgeschlossener Incident" je nach System anders definiert ist, plant ein Agent auf unsicherer Grundlage. Ein gemeinsames Glossar, zentrale Stammdaten, Datenverträge und fachliche Owner reduzieren diese Ambiguität.

Betriebsrisiken entstehen durch instabile Schnittstellen, fehlende Rate-Limits, lange Antwortzeiten oder nicht getestete Tool-Aufrufe. Kontrollmechanismen sind synthetische Tests, Sandbox-Ausführung, Monitoring pro Agenten-Workflow, klare Fehlerpfade und ein Stoppschalter für automatisierte Aktionen. Besonders wichtig ist die Trennung zwischen Vorschlag, Freigabe und Ausführung.

Umsetzung: 30-60-90-Tage-Plan

In den ersten 30 Tagen sollte das Ziel nicht maximale Automatisierung sein, sondern Transparenz. IT-Management und Architektur sollten ein kleines, relevantes Agenten-Szenario auswählen, etwa Ticket-Triage oder Incident-Zusammenfassung. Dazu gehören eine Liste der benötigten Datenquellen, klare Owner, eine erste Risikoklassifizierung und ein einfacher Qualitätscheck für Aktualität, Vollständigkeit und Berechtigungen.

Nach 60 Tagen sollte ein kontrollierter Pilot laufen. Der Agent liest definierte Quellen, nutzt begrenzte Tools und erzeugt nachvollziehbare Vorschläge. In dieser Phase sind Messpunkte wichtig: Wie oft fehlen Daten? Welche Quellen widersprechen sich? Wo sind Berechtigungen unklar? Welche Vorschläge werden von Menschen verworfen und warum? Diese Erkenntnisse fließen in Datenverträge, Runbook-Pflege, API-Korrekturen und Guardrails ein.

Nach 90 Tagen sollte die Organisation entscheiden, ob der Use Case skaliert, begrenzt oder neu zugeschnitten wird. Skalierung ist sinnvoll, wenn Datenqualität, Akzeptanz, Betriebsstabilität und Kontrollmechanismen belastbar sind. Andernfalls ist es professioneller, die Datenbasis zu verbessern, bevor zusätzliche Agenten-Workflows entstehen.

Ein pragmatischer Plan kann so aussehen:

• 30 Tage: Use Case auswählen, Datenquellen inventarisieren, Owner benennen, Risiken klassifizieren.
• 60 Tage: Pilot mit Leserechten, Guardrails, Logging und menschlicher Freigabe betreiben.
• 90 Tage: Qualitätsmetriken auswerten, Datenverträge stabilisieren, Automatisierungsgrad bewusst erhöhen oder begrenzen.

Fazit

KI-Agenten erzeugen ihren Nutzen nicht im luftleeren Raum. Sie sind nur so belastbar wie der Kontext, auf den sie zugreifen, und nur so sicher wie die Regeln, die ihre Aktionen begrenzen. Datenqualität wird damit zu einer Kernaufgabe für IT-Management, Architektur und Betrieb. Der beste Einstieg ist ein begrenzter Use Case, der echte Arbeit erleichtert und zugleich sichtbar macht, wo Daten, Schnittstellen und Verantwortlichkeiten verbessert werden müssen.

Wenn Sie KI-Agenten in Ihrer Organisation einsetzen oder planen, diskutieren Sie früh mit IT, Fachbereichen und Compliance, welche Datenqualität für welchen Automatisierungsgrad erforderlich ist.