EU AI Act: Banken-KI scheitert nicht am Modell, sondern am prüfbaren Betrieb

. KI Projekte scheitern selten an Modellen, sondern an der Architektur. Viele Systeme lassen sich nicht produktiv betreiben, weil zentrale Anforderungen wie Auditierbarkeit, Reproduzierbarkeit und kontrollierbare Datenverarbeitung technisch nicht erfüllt sind. Mit dem EU AI Act verschärft sich diese Situation und für viele Institute entsteht unmittelbarer Handlungsbedarf. Ohne Cloud Souveränität sind diese Kontrollmechanismen häufig nur eingeschränkt umsetzbar und schwer unabhängig überprüfbar. Entscheidend ist daher nicht die Modellqualität, sondern die Architektur, auf der sie betrieben wird. von Selcuk Ugur, Jonathan Gros, beide GFT Technologies.. [ -]. . Regulatorische Anforderungen wirken direkt auf die Systemarchitektur. Ka I Modelle müssen nicht nur funktionieren, sondern über ihren gesamten Lebenszyklus hinweg kontrollierbar bleiben. Vorgaben wie der EU AI Act definieren hierfür konkrete Anforderungen, etwa an Logging, Nachvollziehbarkeit und Risikomanagement für Hochrisiko Ka I. Daraus ergeben sich klare Designvorgaben: Trainings- und Inferenzdaten müssen eindeutig einem Rechtsraum zugeordnet werden, was eine Trennung von Datenhaltungs- und Verarbeitungszonen erfordert. Für international tätige Institute führt dies in der Praxis häufig zu verteilten Architekturen, beispielsweise im Sinne eines Data Mesh Ansatzes. Zugriffe auf Daten und Modelle sind revisionssicher zu protokollieren. Erfolgreiche Architekturen setzen hier auf manipulationssichere Logging Strukturen, etwa über WORM konforme Speicherung und kryptografisch abgesicherte Audit Logs, in denen Inferenzanfragen, Modellversionen und Eingabedaten korreliert werden. Auch die Nachvollziehbarkeit von Modellentscheidungen erfordert versionierte Artefakte entlang der gesamten Pipeline. Fehlt diese Reproduzierbarkeit, sind Audit und Incident Analysen nicht möglich. Darüber hinaus muss auch die Entscheidung erklärbar sein, entweder durch inhärent erklärbare Modelle oder Explainable AI Ansätze.Viele post hoc Verfahren liefern nur Näherungen. Erst die Kombination aus reproduzierbarer Pipeline und erklärbarer Entscheidung ermöglicht belastbare Nachvollziehbarkeit.“. Cloud Souveränität ist eine Systemeigenschaft!. . Cloud Souveränität bezeichnet die Fähigkeit, Daten, Verarbeitung und Betriebsumgebungen jederzeit technisch zu kontrollieren und unabhängig von einzelnen Anbietern betreiben zu können. Dazu zählen insbesondere die Kontrolle über Datenflüsse, Zugriffsmechanismen und Schlüsselmaterial sowie die Begrenzung von Abhängigkeiten. Was häufig unterschätzt wird: Cloud Souveränität ist nicht nur eine regulatorische Anforderung, sondern ein operativer Hebel. Architekturen, die diese Kontrolle systematisch umsetzen, ermöglichen schnellere Freigaben, stabileren Betrieb und eine deutlich höhere Anpassungsfähigkeit bei sich ändernden Anforderungen. Beim Schlüsselmanagement reichen anbieterverwaltete Modelle oft nicht aus. Regulatorische Szenarien erfordern kundenseitig kontrollierte Schlüssel. Die Wahl des Schlüsselmodells ist dabei eine zentrale Architekturentscheidung mit direkten Auswirkungen auf Anbieterauswahl, Kosten und Auditierbarkeit. Ein zentraler Schwachpunkt klassischer Architekturen ist die Verarbeitung sensibler Daten. Während Verschlüsselung im Ruhezustand und bei der Übertragung Standard ist, bleibt die Verarbeitung häufig ungeschützt. Confidential Computing Ansätze adressieren dieses Problem, sind jedoch insbesondere bei großen Modellen durch Performance- und Speicheranforderungen eingeschränkt. In der Praxis entstehen daher hybride Lösungsansätze: etwa die Kombination aus der Pseudonymisierung sensibler Daten und geschützten Ausführungsumgebungen. Mechanismen wie Remote Attestation ermöglichen dabei die technische Überprüfung der Verarbeitung, ein Aspekt, der insbesondere für externe Audits zunehmend relevant wird. Ergänzend ist durchgängige Transparenz erforderlich: Nur wenn Logs, Metriken und Abhängigkeiten durchgängig nachvollziehbar sind, lassen sich Anforderungen effizient erfüllen. Abhängigkeiten von Modellanbietern als Betriebsrisiko!. . Ein oft unterschätzter Aspekt von Cloud Souveränität ist die Abhängigkeit von externen Modellanbietern. Viele Ka I Anwendungen basieren auf leistungsfähigen Modellen, die jedoch eine strukturelle Abhängigkeit in kritischen Teilen der Wertschöpfung erzeugen. Diese Abhängigkeit ist operativ relevant: Änderungen bei Verfügbarkeit, Zugriff oder Preisstrukturen wirken sich unmittelbar auf bestehende Anwendungen aus, im Extremfall bis hin zum Ausfall geschäftskritischer Prozesse. Steigende Tokenpreise verschieben zudem die Wirtschaftlichkeit von Ka I Lösungen teilweise innerhalb weniger Monate. Cloud Souveränität bedeutet daher, diese Abhängigkeiten aktiv zu begrenzen, etwa durch abstrahierte Zugriffe, Modellwechsel und den Einsatz alternativer Modelle. . Zusätzlich entsteht eine weitere Abhängigkeit: die Verfügbarkeit physischer Infrastruktur. Engpässe bei GPUs, spezialisierten Ka I Beschleunigern und Speicherressourcen führen bereits heute zu steigenden Kosten und limitieren die Skalierbarkeit von Ka I Anwendungen. Neben Modell- und Cloud Abhängigkeiten wird damit auch die Kontrolle über Infrastrukturkapazitäten und Kostenentwicklung zu einem entscheidenden Faktor für den langfristig stabilen Betrieb. Der kritische Punkt: Betrieb, nicht nur Training!. . Während das Training von Modellen technisch und regulatorisch anspruchsvoll ist, wird der kontrollierte Betrieb häufig unterschätzt. Erforderlich sind MLOps Ansätze über den gesamten Lebenszyklus. Zentrale Voraussetzung ist die Versionierung aller Artefakte: Trainingsdaten, Feature Definitionen und Modellparameter müssen reproduzierbar sein. Ebenso entscheidend ist das kontinuierliche Testen im Betrieb: Modelle müssen auf Verzerrungen sowie auf Veränderungen in Daten und Modellverhalten (Drift) überprüft werden. Diese Kontrollen müssen integraler Bestandteil der Pipeline sein. Erst durch die Kombination aus Versionierung, Testing und Monitoring lassen sich Modelle kontrolliert und regulatorisch belastbar betreiben.Die Umsetzung ist auch eine organisatorische Entscheidung: Ob zentral gesteuerte MLOps Strukturen oder föderierte Modelle mit domänenspezifischen Teams, beide Ansätze beeinflussen Governance, Audit Fähigkeit und Skalierbarkeit.“. Architektur entscheidet über Geschwindigkeit!. . Cloud Souveränität ist eine Architekturentscheidung mit direkten Auswirkungen auf Betrieb und Time to Market. Regulatorische Anforderungen müssen in Plattformen, Schnittstellen und Betriebsmodelle integriert werden, Architektur wird damit zur Compliance Entscheidung. In der Umsetzung bewähren sich standardisierte Plattformen für Daten- und Ka I Workloads, ergänzt durch Policy as Code und automatisierte Compliance Prüfungen entlang der gesamten Pipeline. Der Effekt ist messbar: Freigabeprozesse verkürzen sich, weil Modellversionen, Trainingsdaten und Inferenzpfade systemseitig dokumentiert sind. Manuelle Prüfungen werden durch technische ersetzt. Gleichzeitig sinken Reibungsverluste zwischen Ai Tieh, Fachbereich und Compliance, und Komponenten lassen sich wiederverwenden. Cloud Souveränität schafft hierfür die technische Grundlage, indem sie Kontrolle über Datenflüsse, Zugriffe und Nachweise ermöglicht. Fazit EU AI Act!. . Viele Ka I Initiativen scheitern nicht an Daten oder Modellen, sondern daran, dass ihre Architektur nie für einen auditierbaren Betrieb ausgelegt war. Der produktive Einsatz von Ka I in regulierten Umgebungen ist deshalb primär eine Architekturfrage. Cloud Souveränität schafft die Grundlage für technische Kontrolle, reduziert Abhängigkeiten und ermöglicht einen stabilen Betrieb. Wer in Ka I investiert, ohne die Infrastruktur entsprechend auszurichten, wird Systeme bauen, die funktionieren, aber nicht betrieben werden können. Mit dem EU AI Act steigt der Handlungsdruck weiter: Für viele Finanzinstitute werden ab 2026 umfassende Anforderungen an Hochrisiko Ka I verbindlich. Architektur, Betrieb und Nachweisfähigkeit müssen daher frühzeitig überprüft und entsprechend ausgerichtet werden. Sie hörten einen Beitrag von “ Selcuk Ugur, Jonathan Gross, beide GFT Technologies/dk“

 
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/244422

• teilen 
• teilen 
• teilen 
• teilen 
• teilen 
• RSS-feed 
• E-Mail 
• drucken