Warum KI-Implementierung eine saubere Architektur auf drei Ebenen braucht
Wie jeden Morgen komme ich die Treppe runter, ein Blick auf das Smartphone zeigt mir die Mitteilung: „Robi hat die Aufgabe erledigt, bis er feststeckte.“ Robi, unser Staubsaugerroboter, sollte eigentlich unbemerkt und gründlich in der Nacht das Krümel-Chaos entfernen, gleich einer fleißigen Hauselfe. Doch wie erwartet finde ich ihn wie fast jeden Morgen irgendwo feststecken, heute in den Fängen der Sportschuh-Schnürsenkel, wo er still leidend darauf wartet gerettet zu werden. Ich seufze innerlich. „Hat die Aufgabe erledigt“ ist eher ein Euphemismus, denn er ist nicht einmal aus dem Flur rausgekommen.
Es ist Zeit, sich dem Thema zu widmen, das ein Nerd-Herz höher schlagen lässt: Architektur.
Das Pilotprojekt funktioniert, aber im „echten Leben“?
In einer eingekapselten Umgebung mit wenigen Anwendungen, Schnittstellen, fein kuratierten Daten und wenig Sonderfällen läuft eine KI Projekt Demo beeindruckend. So wie im Präsentationsraum: Hier navigiert der Roboter wie aus dem Lehrbuch. Doch in einem 3-Kinder-plus-Hund-und-Hamster-Haushalt des echten Lebens ist alles anders: Kabelsalat, liegengebliebene Sportschuhe, angemalte Papierfetzen und Stifte, Hundespielzeug, mal eine Einkaufstüte oder eine getragene Socke. Oder ein kleiner, aber doch unüberwindbarer Sockel.
Genau das passiert, wenn KI-Projekte vom Pilot in die echte Geschäftsumgebung gehen.
Der Unterschied liegt nicht am Roboter selbst. Der Unterschied liegt in der Architektur der Umgebung, in der er agieren soll. Und hier gibt es drei kritische Dimensionen zu beachten.
1. IT-Architektur: Unüberwindbare Sockel vermeiden
Soll ein Pilotprojekt raus aus der Sandbox und rein in die Unternehmens-Architektur, so ist vorab zu prüfen: Funktioniert das alles? Greifen die Systeme ineinander? Sind die Anwendungen strategisch sinnvoll ausgewählt? Was ist aus Kosten-Nutzen-Sicht sinnvoll?
Welche Systeme müssen miteinander sprechen? Kann das System in der bestehenden Umgebung integriert werden? Sind alle Bedarfsanforderungen erfüllt oder muss eine neue Lösung gekauft, oder gar entwickelt werden? Gibt es veraltete Systeme, oder solche, die nicht mehr genutzt werden sollen? Gibt es Lösungen, die mehrere Anwendungen ersetzen könnten? Denken Sie auch für die Zukunft mit. Was macht kosten-technisch und strategisch Sinn?
Wo liegen die Schnittstellen? Braucht die Lösung Daten aus anderen Systemen? Wo liegen die Quelldaten, wie laufen die Datenströme? Wann werden diese aktualisiert? Es bringt nichts, wenn Sie einmal pro Tag das DWH befüllen, aber Ihre Anwendung Echtzeit-Daten benötigt.
IT-Architektur ist ein evolutionärer Prozess. Sie erfordert, dass Ihre IT und die Fachabteilungen zusammen verstehen, wie die Anwendungen funktionieren. Ist die Kapazität und Kompetenz sichergestellt? Wer pflegt diese und stimmt sie aufeinander ab, wenn das Projekt einmal läuft und übergeben ist?
2. Daten-Architektur: Liegt irgendwo eine stinkende Socke?
Pilotprojekte laufen meist auf einem ausgewählten und bereinigten Datensatz.
Alle Felder sind gefüllt. Keine Duplikate. Keine Einträge, die sich widersprechen. Keine Sonderfälle.
Dann geben Sie das Projekt frei, und es landet in Ihrer echten Datenbasis. Und plötzlich treffen Sie auf Jahrzehnte von Datenverwilderung. Manchmal buchstäblich: Irgendwo in Ihrer Datenbank liegt eine „Socke“, ein Datensatz so alt und verdreht, dass Sie nicht mehr wissen, ob er noch aktuell ist oder längst hätte gelöscht werden sollen.
Was müssen Sie konkret tun?
Data Audit durchführen: Bevor Sie KI implementieren, müssen Sie verstehen, wie gut Ihre Daten tatsächlich sind. Welche Daten sind verfügbar. Welche Daten sind bereinigt. Welche Daten sind veraltet? Wo ist die Ursprungs-Datenquelle (Single Source of Truth) und wie ist die Qualität des Master Data Management?
Datenpflege ist Kernaufgabe: Wer ist dafür verantwortlich, dass Daten in ausreichender Qualität vorhanden sind und regelmäßig bereinigt werden? Wer orchestriert die Datenflüsse? Wer hat das Domänenwissen, um die Qualität zu prüfen, wer hat den technischen Zugang und die Fähigkeiten, die Datenbereinigung durchzuführen? Diese Verantwortung und die Prozesse müssen klar verankert sein, sonst verrottet die Datenqualität wieder, sobald das KI-Projekt live geht.
Sonderfälle: Denken Sie auch darüber nach, wie Sie mit Ausnahmen, Outliern und anderen Sonderfällen umgehen. Kunde nicht in der Datenbank vorhanden und muss neu angelegt werden? Eine vom üblichen Muster abweichende Bestellung? Eine verdächtige E-Mail? Überlegen Sie, an welcher Stelle die Automatisierung abgebrochen und doch wieder an den Menschen übergeben werden soll.
3. Governance-Architektur: Kabelsalat vermeiden
Governance für Rechte und Rollen bedeutet: Was darf die KI-Lösung tun? Welche Daten dürfen nur anonymisiert verarbeitet werden? Wer darf Ergebnisse sehen? Welche Aktionen darf die Automatisierung durchführen?
Wenn das nicht klar ist, entsteht ein Kabelsalat aus Berechtigungen. Die KI verfängt sich, weil sie versucht, Daten zu verarbeiten, auf die sie keinen Zugriff hat. Oder die Lösung funktioniert, aber plötzlich werden Daten an einen falschen Personenkreis weitergeleitet. Oder, im schlimmsten Fall, der Agent löscht einfach die Datenbank. Nichts ist sauberer als eine leere Tabelle, oder?
Auch hier wieder ein Konzept für Rollen und Berechtigungen notwendig: Nicht jeder im Unternehmen darf jeden Output der KI-Lösung sehen. Dokumentieren Sie, wer welche Ergebnisse nutzen darf und wer nicht. Nicht alles sollte durch die KI verarbeitet werden. Überlegen Sie, welche Aktionen Sinn machen (Lese oder Schreibrechte?), nach dem Motto: nur so viel wie nötig.
Datenschutz und Anonymisierung: Wenn Ihre KI mit sensiblen Kundendaten arbeitet, wie stellen Sie sicher, dass diese in der Lösung geschützt sind? PII-Anonymisierung (Anonymisierung von personenbezogenen Daten), oder geschwärzte Dokumente können Lösungen sein. Die KI kann sehr gut auch mit anonymisierten Daten arbeiten. Aber achten Sie auch auf den Kontext: Herrn Max Mustermann durch [NAME IT-TEAMLEITER] zu ersetzen ist keine hilfreiche Anonymisierung wenn es nur einen IT-Teamleiter gibt.
Audit Trails: Wer hat wann was gemacht mit dieser Lösung? Sichern und Loggen Sie Daten und Protokolle. Sollte es zu Problemen kommen, können Sie nachvollziehen, was passiert ist. Und: Mit den Daten wachsen auch die Risiken. Lassen Sie diese Lösungen regelmäßig überprüfen.
Security: Auch dieser Punkt darf nicht unterschätzt werden. Anders als klassische Code-Anwendungen sind KI-Anwendungen anfällig für Angriffe. Jeder, der die Sprache beherrscht könnte (auch unbewusst) zum Hacker werden. Etablieren Sie Guardrails und testen Sie die KI-Systeme regelmäßig.
Was Sie diese Woche tun können
Fragen Sie sich ehrlich: Wo könnte Ihre aktuelle KI-Lösung feststecken? Wo haben Sie saubere Grundlagen geschaffen und wo gibt es noch Aufholungsbedarf? Ist es die IT-Integration? Die Datenqualität? Oder die Governance?
Bauen Sie einen Workshop: Laden Sie Ihre IT, Ihre Fachabteilungen und Ihre Sicherheitsverantwortlichen an einen Tisch. Nicht um zu klären, welche KI Sie kaufen. Sondern um zu klären, wie Ihre KI-Lösungen architektonisch in Ihr Unternehmen passen. Identifizieren Sie vor allem, welche Anwendungen strategisch wichtig, und welche obligatorisch oder veraltet sind und Probleme machen könnten.
Stellen Sie Ihre Daten auf die Waage: Single-Source of Truth, Master Data Management, Governance. Können Sie überall ein Häkchen machen? Sind die Rollen klar definiert? Wo ist das Domänenwissen? Wo der Zugriff? Wie kommunizieren die Systeme miteinander und wer kümmert sich darum? Suchen Sie nach den alten Socken, die findet man schnell am Geruch.
Ich bin gespannt: Welche Architektur-Herausforderung ist aktuell die kritischste für Ihr Unternehmen? Schreiben Sie mir gern. Ich freue mich auf Ihre Rückmeldung.
Was mache ich jetzt? Erst einmal den Robi aus den Schnürsenkel befreien. Und hoffen, dass es irgendwann mit der Ordnung doch mal klappt. Vielleicht brauche ich ja noch einen Aufräum-Roboter?
Olga Sawall
