Ohne saubere CMDB keine brauchbaren AI Agents

Ein Erlebnis aus dem Dezember, das ich seitdem in jedem Kundengespräch erzähle, weil es das Problem besser illustriert als jede Folie.

Bei einem Kunden sollte ein AI Agent die Incident-Triage unterstützen, unter anderem mit einer Einschätzung, welche Services von einer Störung betroffen sind. Im Test lieferte der Agent eine wunderbar formulierte, in sich vollkommen schlüssige Impact-Analyse: betroffene Anwendungen, abhängige Services, Empfehlung zur Priorität, alles sauber begründet. Sie war nur leider falsch. Die Beziehungen in der CMDB waren seit dem letzten Rechenzentrumsumzug nicht nachgezogen worden, und der Agent argumentierte auf dem Stand von vor anderthalb Jahren.

Der Agent hat fehlerfrei gearbeitet. Die Daten haben gelogen.

Warum Agenten das Problem verschärfen

Das Tückische an dieser Geschichte ist nicht der Fehler selbst, veraltete CMDB-Daten gab es schon immer. Das Tückische ist, wie sich der Fehler verhält, sobald ein Agent im Spiel ist.

Eine veraltete CMDB war früher ein stilles Problem. Ein Mensch, der die Daten abfragte, brachte meist genug Kontextwissen mit, um Unstimmigkeiten zu erkennen. Der Kollege wusste eben, dass der Server letztes Jahr migriert wurde, stutzte beim Blick auf die Abhängigkeiten und fragte nach. Diese menschliche Plausibilitätsprüfung war nie Teil des Designs, aber sie war immer da, als unsichtbares Sicherheitsnetz.

Ein Agent hat dieses Kontextwissen nicht. Er nimmt die Daten als Wahrheit und handelt entsprechend: schnell, skaliert, rund um die Uhr und mit einer Begründungsqualität, die Vertrauen erweckt. Genau diese Überzeugungskraft macht es schlimmer, denn eine flüssig formulierte, falsche Impact-Analyse wird seltener hinterfragt als eine lückenhafte richtige. Der Fehler wandert ungebremst in Prioritäten, Eskalationen und im nächsten Schritt in automatisierte Aktionen.

Kurz gesagt: Agenten erben die Qualität ihrer Datengrundlage, und sie erben sie mit Zins.

Die Datenprüfung vor jedem Agenten-Use-Case

Deshalb gehört für mich vor jeden Agenten-Use-Case eine ehrliche Datenprüfung, und zwar eine eng zugeschnittene. Niemand muss die gesamte CMDB perfektionieren, das wäre der gleiche Fehler wie beim klassischen CMDB-Großprojekt, nur in neuem Gewand. Drei Fragen reichen.

Welche Tabellen und Attribute wird der Agent tatsächlich lesen? Diese Liste ist erstaunlich kurz, wenn der Use Case sauber geschnitten ist: beim Triage-Beispiel etwa CI-Stammdaten, Service-Beziehungen und die Incident-Historie. Genau dort muss die Qualität stimmen. Nicht überall, dort. Diese Eingrenzung macht aus einem unbezahlbaren Daten-Sanierungsprogramm eine machbare Aufgabe von Wochen.

Wie aktuell sind diese Daten, und woher kommen sie? Die Faustregel aus der Praxis: Automatisch befüllte Daten aus Discovery oder Integrationen sind in der Regel verlässlich, sie haben einen Mechanismus, der sie aktuell hält. Manuell gepflegte Felder und Beziehungen sind die Kandidaten für böse Überraschungen, sie veralten genau dann, wenn niemand hinschaut. Beim Dezember-Vorfall war es exakt diese Sorte: handgepflegte Service-Zuordnungen, die der Umzug überholt hatte.

Wer merkt es, wenn die Daten kippen? Datenqualität ist kein Zustand, sondern ein Prozess. Ein einfacher Gesundheitscheck, der wöchentlich läuft und ein paar Kennzahlen prüft, also Anteil verwaister CIs, Alter der letzten Aktualisierung je Quelle, Beziehungen ohne Gegenstück, reicht oft schon. Entscheidend ist, dass ihn jemand anschaut und dass Auffälligkeiten einen definierten Weg zur Korrektur haben.

Der doppelte Ertrag

Die gute Nachricht zum Schluss: Dieser Aufwand zahlt doppelt ein. Dieselbe Datenqualität, die den Agenten trägt, verbessert auch alles andere, was auf der CMDB aufsetzt: Change-Planung, Impact-Analysen im Incident-Prozess, Audits, Lizenzbilanzen. Der Agent ist nur der Anlass, der das Thema endlich auf die Tagesordnung bringt, und ehrlich gesagt ein willkommener.

Ich formuliere es in Kundengesprächen inzwischen so: Datenarbeit ist die am meisten unterschätzte KI-Investition. Sie taucht in keiner Produktpräsentation auf, sie gewinnt keinen Innovationspreis, und sie entscheidet trotzdem darüber, ob der Agent ein Werkzeug wird oder ein Risiko. Der Dezember-Kunde hat das verstanden, die Service-Beziehungen sind inzwischen saniert, der Agent läuft. Die Reihenfolge war nur eben andersherum, als es die Roadmap vorgesehen hatte.