Das chinesische KI-Unternehmen Zhipu AI (bekannt als Z.ai) hat mit GLM-5.2 ein Open-Weight-Modell veröffentlicht, das sich bei der Erkennung von Sicherheitslücken offenbar mit Anthropics Opus 4.8 messen kann.

Das haben IDOR-Benchmark-Tests der Cybersicherheitsfirma Semgrep ergeben. Da es sich um ein Open-Weight-Modell handelt, kann jeder GLM-5.2 herunterladen, lokal betreiben und modifizieren. Das eröffnet für Hacker weitere Möglichkeiten für kriminelle Einsätze.

Open Weight als Chance und Risiko

Die offene Verfügbarkeit von GLM-5.2 ist ein zweischneidiges Schwert. Sicherheitsfirmen, CERTs und interne Red Teams können das Modell in abgeschotteten Umgebungen für Code-Reviews und Penetrationstests nutzen, ohne sensible Daten an US-Clouds zu übermitteln. Für DSGVO-konforme Umgebungen in Europa ist das ein Vorteil.

Gleichzeitig können auch Angreifer GLM-5.2 ohne jede Aufsicht betreiben. Diese Eigenschaft macht das Modell attraktiv für Akteure, die nach Schwachstellen in kritischen Systemen suchen wollen. Lior Div, Chef der Cybersicherheitsfirma 7AI, fasste die Lage gegenüber dem Wall Street Journal zusammen: China sorge dafür, dass der Abstand zu den US-KIs „immer kleiner“ werde.

Zhipu AI selbst räumt in den Release Notes ein, dass GLM-5.2 während des Reinforcement-Learning-Trainings verstärkt sogenanntes Reward Hacking zeigte. Das Unternehmen habe daraufhin spezielle Anti-Hacking-Sicherungen für das Training und die Evalution des Modells integriert.

Geopolitische Dimension: USA unter Zugzwang

Die Entwicklung trifft die US-Regierung in einem heiklen Moment. Eines von Anthropics Modellen war kurzzeitig komplett gesperrt, weil die Trump-Administration den Zugriff durch ausländische Nutzer untersagte. Auch OpenAI bekommt von der US-Regierung Auflagen „aus Sicherheitsgründen“.

Für europäische Unternehmen und Behörden stellt sich mit der wachsenden Leistungsfähigkeit der KI-Modelle die Governance-Frage: Wie lässt sich der Einsatz solcher Werkzeuge in sicherheitskritischen Bereichen mit dem EU AI Act und nationalen Sicherheitsvorgaben vereinbaren – und wie geht man mit einem Modell um, das beim Schwachstellen-Finden brilliert, aber keiner Aufsicht unterliegt?

(rie)

In seiner Keynote auf der data2day 2025 stellt Dr. Michael Zimmer den Menschen ins Zentrum der KI-Transformation – nicht die Technologie. Unter dem Leitgedanken „V³ – Verständnis, Vertrauen und Verantwortung“ zeigt er auf, dass KI in der Unternehmenspraxis weit mehr erfordert als technische Implementierung. Am Beispiel Klarna illustriert er, wie Unternehmen zunächst massiv auf KI-gestützte Automatisierung setzten und Personal abbauten, nur um später festzustellen, dass menschlicher Kundenkontakt unersetzlich ist. Eine MIT-Sloan-Studie untermauert zwar Produktivitätssteigerungen von bis zu 42 % bei Einzelaufgaben – in der Gesamtbetrachtung sei jedoch keine signifikante Veränderung messbar. Zimmer warnt vor dem Reflex, KI als Universallösung für strukturelle Probleme wie unübersichtliche Dokumentenablagen oder fehlerhafte Prozesse einzusetzen, und bringt es auf den Punkt: „Shit in, shit out“ – ohne saubere Daten und Prozesse liefert auch KI keine brauchbaren Ergebnisse.

Befähigung statt Angstmache: Der Mensch als Erfolgsfaktor

Für Data Teams besonders relevant ist Zimmers Analyse der unterschiedlichen Mitarbeitertypen im KI-Kontext: von der erfahrenen Fachkraft, die KI-Trainings konzipiert, über das „Spielkind“, das ohne Governance eigene Lösungen baut, bis zum ängstlichen Kollegen, der erst „abgeholt“ werden muss. Die W&W-Gruppe begegnet dem mit einem breit angelegten Enablement-Programm: 500 Mitarbeitende wurden in Präsenz geschult, eine Konzernbetriebsvereinbarung (KBV) erarbeitet, und Betriebsrat und Vorstand ziehen bewusst an einem Strang. Das konkrete Praxisbeispiel „Reggi“ – ein KI-Assistent zur Regresserkennung in der Kfz-Schadenbearbeitung – zeigt, wie ein gelungenes Zusammenspiel aussieht: Die KI übernimmt die zeitaufwendige Dokumentenprüfung, die finale Bewertung bleibt beim Menschen.

Governance, Regulierung und die Rolle von Data Teams

Zimmer betont in seinem Vortrag, dass erfolgreiche KI-Einführung Domänenwissen, Nähe zwischen IT und Fachbereich, klare Standards für Plattformen und Integrationsmuster sowie eingespielte Entwicklungs- und Deployment-Prozesse benötigt. Hinzu kommen die regulatorischen Anforderungen: Der EU AI Act (in Kraft seit August 2024, für die meisten Regelungen gültig ab August 2026, für bestimmte Hochrisiko-KI-Bereiche erst ab August 2027) verlangt von Finanzkonzernen einen risikobasierten Ansatz mit konkreten Prüfschemata. Sein Fazit für Data Scientists und Engineers: „Wir übernehmen das Denken, die KI erledigt die Ausführung, wir kümmern uns um die Validierung und Interpretation.“ Im aktuellen LLM-Hype sei Expertenwissen wichtiger denn je – und duale/integrierte Studienmodelle bekämen eine entscheidende Rolle, um diese Kompetenzbrücke zwischen Fachlichkeit und Technologie zu schlagen.

Dr. Michael Zimmer ist Chief Data & AI Officer und Leiter des Kompetenzzentrums für KI in der W&W-Gruppe. Er hat über Agilität von Datenarchitekturen promoviert und war unter anderem als CDO der Zurich Gruppe Deutschland und mehr als 13 Jahre in der Beratung tätig. Er ist Herausgeber und Autor diverser Bücher und unter anderem TDWI Fellow, männlicher Alliierter der Women Leaders in Data and AI (WLDA) sowie Mitglied der Arbeitsgruppe Ethical AI der deutschen Aktuarsvereinigung.

(map)

Mit LTAP (Lake Transactional/Analytical Processing) stellt Databricks eine Architektur vor, die operative Datenbanken und analytische Systeme enger zusammenführen soll. Statt Daten per ETL- oder CDC-Prozessen zwischen beiden Welten zu kopieren, sollen künftig beide auf derselben Datenbasis arbeiten. Databricks sieht darin eine Antwort auf den zunehmenden Einsatz von KI-Agenten, die jederzeit auf aktuelle Unternehmensdaten zugreifen müssen.

In vielen Unternehmen existieren heute zwei getrennte Datenwelten. Operative Anwendungen speichern ihre Daten für den laufenden Geschäftsbetrieb in Transaktionsdatenbanken wie PostgreSQL oder Oracle. Für Berichte, Analysen oder KI-Anwendungen werden diese Daten anschließend in ein Data Warehouse oder Lakehouse kopiert. Dazwischen liegen ETL-Prozesse oder sogenannte Change-Data-Capture-Pipelines (CDC), die Änderungen laufend zwischen beiden Systemen synchronisieren. Diese Architektur gilt seit Jahren als Standard, verursacht jedoch zusätzlichen Betriebsaufwand, Datenkopien und zeitliche Verzögerungen.

Nach Ansicht von Databricks stößt dieses Modell zunehmend an seine Grenzen. KI-Agenten und moderne Anwendungen benötigten aktuelle operative Daten und könnten nicht mit Minuten oder Stunden alten Replikaten arbeiten. Mit LTAP will der Hersteller deshalb transaktionale und analytische Workloads enger zusammenführen.

Zwei Engines statt einer

Neu ist die Idee allerdings nicht. Bereits vor rund 15 Jahren versuchten HTAP-Systeme (Hybrid Transactional/Analytical Processing), Transaktionen und Analysen in einer gemeinsamen Datenbank-Engine auszuführen. Der Nachteil: Dieselbe Engine musste gleichzeitig schnelle Schreibzugriffe und komplexe analytische Abfragen bewältigen, was häufig zulasten der jeweiligen Optimierung ging.

Genau darin sieht Databricks den entscheidenden Unterschied zu früheren HTAP-Ansätzen. Eine einzelne Engine sei für beide Aufgaben zwangsläufig kompromissbehaftet, erläutert Rich Radley, Vice President Field Engineering EMEA bei Databricks. LTAP setzt stattdessen auf zwei spezialisierte Engines: Lakebase übernimmt die transaktionale Verarbeitung auf Basis von PostgreSQL, das Lakehouse die analytischen Abfragen. Beide greifen jedoch auf dieselbe Datenbasis zu.

Grundlage dafür ist Lakebase, ein serverloses PostgreSQL-System, das Daten direkt im Objektspeicher des Lakehouse ablegt. Nach Angaben des Herstellers werden die für Transaktionsdaten typischen zeilenorientierten Daten beim Schreiben automatisch in ein für analytische Abfragen optimiertes spaltenorientiertes Format überführt.

Erst dadurch können beide Engines dieselbe Datenbasis nutzen, obwohl sie unterschiedliche Anforderungen an die Datenorganisation stellen. Radley bezeichnet diese Echtzeit-Transcodierung als eigentlichen technischen Durchbruch der Architektur. Dadurch können zwei spezialisierte Engines parallel auf denselben Daten arbeiten, ohne dass Daten zwischen operativen und analytischen Systemen repliziert werden müssen.

Gemeinsame Datenbasis statt Datenkopien

Lakebase legt die Daten auf derselben Speicherschicht wie das Lakehouse in offenen Tabellenformaten wie Delta oder Iceberg ab. Über den Unity Catalog werden sie gemeinsam verwaltet; dieser übernimmt Berechtigungen, Metadaten und Governance. Dadurch können sowohl die transaktionale Datenbank als auch das Lakehouse auf dieselbe Datenbasis zugreifen, ohne dass zusätzliche Datenkopien entstehen.

Lakebase ergänzt Databricks zudem um cloud- und regionenübergreifende Disaster Recovery, Git-ähnliche Branches und Snapshots sowie autonome Datenbankfunktionen, bei denen Agenten den Zustand überwachen und Optimierungsvorschläge liefern.

Architektur statt Revolution

Mit seinem Ansatz, transaktionale und analytische Workloads enger zusammenzuführen, will sich Databricks sowohl von den HTAP-Systemen (Hybrid Transactional/Analytical Processing) als auch von den neueren Zero-ETL-Konzepten absetzen. Während HTAP beide Workloads in einer gemeinsamen Engine vereinen wollte, argumentiert Databricks, dass Zero ETL vor allem den Integrationsaufwand zwischen bestehenden Systemen reduziere, die zugrunde liegenden Datenkopien jedoch bestehen blieben. LTAP setzt dagegen auf zwei spezialisierte Engines, die auf einer gemeinsamen Datenbasis arbeiten und Datenkopien vollständig vermeiden sollen.

Ob dieser Architekturansatz ETL- und Replikationsprozesse tatsächlich in größerem Umfang ersetzen kann, muss sich allerdings erst im produktiven Einsatz zeigen. LTAP ist bislang nicht allgemein verfügbar, unabhängige Benchmarks oder belastbare Erfahrungen aus Produktivumgebungen liegen ebenfalls nicht vor.

Zusammen mit Lakehouse//RT zeigt LTAP die strategische Richtung von Databricks: Analyse-, Transaktions- und KI-Workloads sollen künftig nicht mehr über zahlreiche Datenkopien und spezialisierte Zwischensysteme verbunden werden, sondern auf einer gemeinsamen Datenbasis zusammenlaufen. Sollte sich dieser Architekturansatz im produktiven Einsatz bewähren, könnte er den Aufbau datenintensiver KI-Anwendungen und Agentensysteme vereinfachen.

(axk)