Was der Bau eines eigenen KI-Systems über Governance lehrt

Vier Erkenntnisse aus einem persönlichen Projekt für die Beurteilung von KI-Strategien auf Aufsichtsstufe.

Im Rahmen meines Ratgebers für Verwaltungsräte zu KI-Governance, Cybersecurity, Datenschutz und Datenmanagement arbeite ich an einem eigenen lokalen Wissenssystem. Mein technischer Hintergrund erlaubt es mir, das selbst zu bauen und zu entwickeln. Mein Anliegen war pragmatisch: Ich wollte selbst verstehen und erleben, welche praktischen Probleme sich in einem solchen Projekt stellen, damit ich diese auf Stufe Verwaltungsrat und Geschäftsleitung besser einordnen kann. Erfahrung aus digitaler Transformation und technischen Projekten bringe ich mit, doch auf Code-Stufe war ich seit längerem nicht mehr so aktiv. Das eigenhändige Bauen ist gleichzeitig eine Reaktivierung dieses Wissens.

Das KI-System soll folgende Funktionen leisten:

• Wissenschaftliche Quellen automatisiert importieren und grob kategorisieren (Peer-Reviewed ja/nein, Management Summary, Kernaussagen).
• Meine gesamte Knowledge-Base aus Fachbüchern, Reports und Artikeln indexieren und verwalten.
• Gesetze, Normen, Standards und Meldungen von Aufsichtsbehörden für schnellen Zugriff und Querverweise bereitstellen.
• Relevante Informationen von bekannten Autoren und Verlagen gezielt verfügbar machen, damit die Recherche effizienter wird.

Diese lokalen Datenquellen werden über eine RAG-Architektur (Retrieval-Augmented Generation) für die KI nutzbar gemacht. Ein späterer Ausbau zu einem KI-Board-System ist geplant bzw. bereits in Arbeit: Erarbeitung von Governance-Frameworks, Compliance-Prüfungen, Auswertung von Finanzdaten und Bearbeitung mandantenspezifischer Fragestellungen auf lokaler Infrastruktur ohne Cloud-Exposure.

Was sich in diesem Aufbauprozess gezeigt hat, ersetzt keine Theorie, ergänzt sie aber operativ und substanziell. Vier Erkenntnisse nehme ich für die Beurteilung von KI-Strategien auf Aufsichtsstufe mit.

Wenn die Ausgangsvision an Grenzen stösst: Empirie ist unverzichtbar

Mein ursprünglicher Plan war eine vollständig lokale Architektur, motiviert durch Datenhoheit. Empirische Tests zeigten schnell: Das lokale System war bei Synthese-Aufgaben um den Faktor 17 bis 20 langsamer als Cloud-Systeme und lieferte epistemisch schwächere Antworten, dies obwohl die eingesetzte Hardware auf Basis eines NVIDIA-GB10-Superchips mit 128 GB Memory durchaus leistungsfähig ist. Leistungsfähigere Hardware könnte die Performance zwar verbessern, doch ein substanzieller Unterschied bliebe bei deutlich höheren Investitionen. Eine nächtliche Batch-Verarbeitung als Ausweg für die Performance-Probleme schied aus, weil der Anwendungsfall interaktiv ist. Überraschender als die Latenz war die Bandbreite der Resultate zwischen verschiedenen Modellen, selbst bei einfachen Fragestellungen. Die Ausgangsvision stiess damit an Grenzen, die Architektur wurde umgebaut und der realen Situation angepasst.

Diese Art der Anpassung funktioniert in einer kleinen und übersichtlichen Umgebung. Bei grösseren Projekten ist sie deutlich schwieriger, was die Wichtigkeit realistischer Pilotprojekte einmal mehr unterstreicht.

Hinzu kam ein zweiter Aspekt, den ich aus der Theorie kannte und aus anderen Projekten antizipieren konnte, der im Bereich der KI-Projekte aber noch grösseres Gewicht bekommt: Datenmenge, Datenstruktur und Datenart beeinflussen das Verhalten der KI-Systeme und der zugrundeliegenden Modelle substanziell. Juristische Texte und Texte in verschiedenen Sprachen lieferten je nach Modell und Training deutlich unterschiedliche Resultate, sowohl im Inhalt als auch in der Qualität. Modell-Updates und durch Upgrades getriggerte Drifts haben Resultate zwischen zwei Läufen signifikant verändert. Beides ist grundsätzlich bekannt. Wer es aber selbst beobachtet und feststellt, dass Erwartung und Ergebnis nicht mehr übereinstimmen, ist trotzdem überrascht, denn die Diskrepanzen können signifikant sein.

Erkenntnis: Strategische KI-Entscheidungen ohne realistische empirische Validierung sind keine Governance. Sie sind Glaube an Anbieter-Folien. In vielen KI-Projekten, die ich sehe, fehlen realistische Pilotdaten in vergleichbarer Datenmenge. Stattdessen Marktstudien, gut aufbereitete Präsentationen, theoretische Analysen und Roadmaps. Das reicht bei weitem nicht, denn ein KI-Projekt ist kein Sprint. Es ist ein Marathon. Auf Aufsichtsstufe würde ich für jedes Projekt oder Teilprojekt belastbare Pilotergebnisse unter realistischen Datenbedingungen verlangen, bevor das Greenlight für die produktive Entwicklung folgt. Wenn Pilotmessungen nicht unter realistischen Bedingungen abgeschlossen wurden, ist der Reifegrad für die Entwicklungsfreigabe nicht erreicht.

Kleine Details entscheiden über Erfolg

Eines der Phänomene in meinem System war ein einziger Konfigurationsschalter, der beim Kommandoaufruf zwar aktiv war, im Code durch eine Änderung plötzlich nirgends mehr richtig ausgewertet wurde. Dass mir das passiert ist, hat teils mit der eingangs erwähnten Wissens-Reaktivierung zu tun. Letztlich kann ein solcher Fehler jedem unterlaufen. Faktisch indexierte das System bei jedem Lauf alle Inhalte neu. Nach drei Durchläufen war die Datenbasis um den Faktor drei aufgebläht. Beim Code-Review ist der Fehler schlicht untergegangen. Erst empirische Tests haben ihn offengelegt: Die Qualität der Antworten auf einem Testfragenkatalog nahm sichtbar ab. Andere Phänomene, etwa Dokumente mit identischen Dateinamen, hatten Effekte auf die Datenqualität, die ich nicht ausreichend antizipiert hatte. Lösbar mit Filtern, zusätzlichen Abfragen und Indexierungslogik, aber Fehler, die Zeit und Qualität kosten, und die in einer Produktion Geld und gegebenenfalls ein Reputationsrisiko bedeuten können.

Daraus folgen zwei Erkenntnisse:

• Wer einem Anbieter die Aussage abnimmt, KI-Agenten und Systeme seien «in wenigen Wochen einsatzbereit», hat keinen realistischen Blick auf die Detailtiefe, die solche Projekte verlangen. Selbst für einen einzigen Anwendungsfall brauchte es mehrere Iterationen. Ein Unternehmen, das mehrere produktive Agenten verantwortet, braucht ein Vielfaches an Empirie. Das gilt für die Verarbeitung der Daten im Prozess ebenso wie für die Sicherheit der Daten und Prozesse. Wenn ein Anbieter oder ein Projekt zu diesen Aspekten keine belastbaren Aussagen macht, ist Vorsicht angezeigt.

• Die Anzeige eines Schalters in einem Dashboard oder eine Option beim Aufruf ist keine Evidenz, dass die Funktion wirkt. In Compliance-Dashboards, in KI-Sicherheitsfiltern, in Audit-Modi. Überall, wo eine Anzeige Sicherheit suggeriert, lohnt sich die Frage, wann diese Funktion zuletzt durch einen Differenztest verifiziert wurde. Der «Human in the Loop» muss sich darauf verlassen können, dass System, Reports und Dashboards zuverlässig sind.

Diese Detailtiefe gehört in jede Projektplanung. Eine KI-Strategie, die Detailrisiken nicht benennt, ist eher eine Marketing-Folie als eine Entscheidungsgrundlage.

Tests sind Daueraufgabe, keine Projektphase

Daten und Systeme verändern sich in der Produktion durch unterschiedliche Einflüsse. Datenbasen wachsen, verändern sich, verlieren an Integrität oder erodieren, Modelle erhalten Updates, Schnittstellen ändern sich. Deshalb müssen systematische und regelmässige Tests Teil der produktiven Maintenance werden. In regelbasierten Systemen waren vorhersagbare Resultate die Norm. Mit KI-Systemen werden Tests anspruchsvoller und wichtiger als zuvor. Durch verschiedene Verarbeitungsschichten lassen sich Bias-Effekte vermeiden oder zumindest reduzieren. Doch ohne wiederkehrende Tests und Verifikation der Resultate ist keine belastbare Aussage zur Qualität möglich. Es bleibt nur eine Vermutung.

Für diesen Anwendungsfall: Hybrid ist die professionelle Antwort

Das lokale System taugt für datenschutzpflichtige Inhalte und strukturierte Aufgaben. Das Cloud-System taugt für interaktive Wissensarbeit und Synthese. Beide einzeln genommen sind ungenügend für die Bandbreite produktiver Anwendungsfälle. Die Architektur, die heute produktiv läuft, nutzt beide bewusst nach Anwendungskontext. Vertrauliche Mandanteninhalte gehen ausschliesslich lokal, bei Bedarf im Batchmodus aufgrund der Performance. Allgemeine Recherche geht in die Cloud, soweit datenschutzrechtlich unbedenklich.

Eine pauschale und «einfache» Universallösung, die jeden Anwendungsfall abdecken soll, ist zu Projektbeginn selten realistisch. Wer einem Anbieter dennoch eine solche abnimmt, kauft entweder Performance-Probleme oder Datenschutzrisiken und ganz am Schluss, mit einer gewissen Wahrscheinlichkeit, eine Erwartungsenttäuschung. Eine tragfähige Architektur verlangt Zeit für genaue Analyse und empirische Tests. Sie wird in vielen Fällen hybrid sein, mit einer klaren Klassifikationsregel, welche Daten durch welches System und welche Benutzer zugreifbar gemacht werden dürfen. Diese Regel ist nicht rein technisch. Sie ist eine Governance-Entscheidung. Wer sie nicht trifft, hat seine Aufsichtsfunktion an den Anbieter delegiert. Auch diese Regel muss systematisch überprüft werden.

Was ich aus diesem Projekt weitergeben kann

Vier Beobachtungen nehme ich mit, die auf jede KI-Strategie auf Aufsichtsstufe übertragbar sind.

• Ohne Pilotdaten aus dem eigenen Haus, in vergleichbarer Datenmenge und unter realistischen Bedingungen, ist eine KI-Strategie nicht entscheidungsreif. Präsentationen und Anbieter-Versprechen sind kein Ersatz für eigene Messungen.

• Detailtiefe gehört in die Planung, nicht einfach in den Schlussbericht. Ein einziger übersehener Konfigurationsfehler kann ein System für strategische Zwecke unbrauchbar machen, ohne dass es unbedingt gleich auffällt.

• Bei komplexeren Anwendungsfällen, und eine ernsthafte Literaturrecherche gehört bereits dazu, sind rein lokale Modelle nur bedingt realistisch. Entweder braucht es erhebliche Investitionen in eigene Infrastruktur, oder es drohen Performance-Probleme. Cloud-only erzeugt seinerseits erhebliche Datenschutzrisiken. Es braucht beides, aufeinander abgestimmt.

• Testen und Verifikation sind die unterschätzte Kerndisziplin. Schon Veränderungen der Daten allein, ohne weitere Anpassungen, können das Systemverhalten verändern. Ohne wiederkehrende Tests und Verifikation gibt es keine Aussage über die Qualität. Es gibt nur eine Vermutung. Vieles davon lässt sich automatisieren. Für mein Projekt habe ich beispielsweise ein automatisches Testsystem mit mehreren Modellen als Bewertern aufgebaut, das einen grossen Fragekatalog abarbeitet. Doch die menschliche Überprüfung am Schluss bleibt unersetzlich.

KI-Governance auf Aufsichtsstufe ist Pflicht. Sie verlangt aber, dass sich das Aufsichtsorgan in Grundzügen mit der Technik beschäftigt und Technologiekompetenz aufgebaut hat, sodass es Faktoren wie die oben genannten einordnen kann. Nicht als Entwickler, aber als verantwortungsvolle Aufsicht.

Technologie lässt sich delegieren. Die Aufsicht und die damit verbundene Verantwortung nicht.