Warum KI-übersetztes COBOL Ihre Datenbank zum Absturz bringt

Das Problem

Eine Großbank bat eine KI, dreißig Jahre COBOL nach Java umzuschreiben. Die KI übersetzte die Syntax perfekt. Der Code kompilierte. Die Unit-Tests liefen durch. Dann ließ die erste Transaktion die Datenbank abstürzen.

Der Fehler hatte nichts mit schlechttem Code zu tun. Das Java war grammatikalisch einwandfrei. Das Problem war eine versteckte Abhängigkeit — eine Variable namens TRN-LIMIT, definiert in einer gemeinsamen Header-Datei, tausende Zeilen entfernt von dem Code, den die KI tatsächlich übersetzte. Diese Header-Datei enthielt eine REDEFINES-Klausel, ein COBOL-Feature, das erlaubt, dass eine Speicheradresse je nach Flag, das in einem völlig anderen Modul gesetzt wird, zwei verschiedene Datentypen enthält. Die KI sah nichts davon. Sie behandelte TRN-LIMIT als einfache Zahl. In Wirklichkeit war sie ein gepacktes Dezimalformat (packed decimal). Diese Diskrepanz veranlasste die Java-Anwendung, korrupte Binärdaten in die Datenbank zu schreiben, was einen Fehler der referentiellen Integrität auslöste.

Das ist kein Randfall. Forschungsergebnisse zeigen, dass 70 % bis 80 % der Legacy-Modernisierungsprojekte ihre Ziele verfehlen. Ihre Organisation betreibt höchstwahrscheinlich kritische Systeme auf Code, der älter ist als die meisten Ihrer Mitarbeiter. Wenn Sie eine Migration planen — oder bereits mitten in einer stecken — sollte dieses Fehlermuster Sie zutiefst beunruhigen. Die KI hat sich nicht vertippt. Sie hat eine Beziehung übersehen, die sie nicht sehen konnte. Das ist eine grundlegend andere Art von Risiko, und die meisten aktuellen Werkzeuge haben darauf keine Antwort.

Warum das für Ihr Unternehmen wichtig ist

Die finanzielle Exposition ist hier enorm, und sie berührt jede Position Ihrer Bilanz.

Allein die technische Altlastenschuld (Technical Debt) in den USA wird auf 1,52 Billionen US-Dollar geschätzt. Wenn Ihre Organisation Legacy-Systeme betreibt, tragen Sie genau jetzt einen Teil dieser Last. Rund 80 % der IT-Budgets der Bundesregierung fließen in Betrieb und Wartung — sodass nur noch 20 % für alles Neue übrig bleiben. Der Bankensektor ist besonders exponiert: 43 % der Bankensysteme laufen noch auf COBOL, und diese Systeme verarbeiten 95 % aller Geldautomaten-Transaktionen.

Das bedeutet im Einzelnen für Ihr Risikoprofil:

• Das Sicherheitsrisiko verdreifacht sich. Systeme, die älter als zehn Jahre sind, erleiden statistisch drei Mal so häufig einen Datenverstoß wie moderne Anwendungen. Mit jedem Quartal, das Sie die Modernisierung aufschieben, wächst Ihre Angriffsfläche.
• Compliance-Anforderungen werden strenger. Regulierungen wie DSGVO und DORA verlangen Echtzeit-Berichterstattung und Kontrollen zum Datenschutz. Legacy-Systeme wurden nicht für diese Anforderungen entworfen. Ihre Unfähigkeit zur Anpassung wird zu einem Compliance-Risiko, das Ihren Regulatoren auffallen wird.
• Ihre Experten gehen. Die Entwickler, die diese Systeme geschrieben haben, gehen in Rente. Achtundfünfzig Prozent der Entwickler sagen, dass sie wegen veralteter Technologie-Stacks über eine Kündigung nachdenken. Wenn institutionelles Wissen das Unternehmen verlässt, steigen Ihre Wartungskosten weiter.
• Gescheiterte Migrationen kosten Millionen. Bei einer Misserfolgsquote von 70–80 % sprechen die Chancen gegen Sie. Eine misslungene Migration kostet nicht nur das Projektbudget — sie beschädigt das Vertrauen in Ihre Technologieführung und verzögert die Geschäftsfähigkeiten, auf die Ihre Teams warten.

Ihr Vorstand will digitale Transformation. Ihre Regulatoren wollen moderne Kontrollen. Ihr Budget ist bereits knapp, nur um den Betrieb am Laufen zu halten. Eine Migration, die still scheitert, können Sie sich nicht leisten.

Was tatsächlich unter der Haube geschieht

Um zu verstehen, warum Standard-KI daran scheitert, betrachten Sie Ihre Codebasis als eine Stadt. Jede Funktion, jede Variable und jede Datenbanktabelle ist ein Gebäude. Die Verbindungen zwischen ihnen — welche Funktion welche aufruft, welche Variable welche Berechnung speist — sind die Straßen.

Stellen Sie sich nun vor, Sie geben jemandem ein Telefonbuch mit jedem Gebäude der Stadt und bitten ihn, das Verkehrssystem neu zu entwerfen. Er hat Namen und Adressen, aber keine Karte. Er kann nicht sehen, welche Straßen welche Gebäude verbinden. Genau das macht ein Standard-KI-Codierungswerkzeug mit Ihrem Code. Es liest den Text, kann aber die Struktur nicht sehen.

Dieser spezifische technische Fehler ist als der sogenannte „Lost in the Middle“-Effekt bekannt. Große Sprachmodelle — die KI-Engine hinter Werkzeugen wie Coding-Assistenten — verarbeiten Text mithilfe eines Attention-Mechanismus. Forschungsergebnisse belegen, dass diese Modelle Informationen am Anfang und Ende einer langen Eingabe gut abrufen können, ihre Leistung bei Informationen jedoch abrupt abfällt, die in der Mitte verborgen liegen. In einem COBOL-Programm, das sich über tausende Zeilen erstreckt und externe Dateien referenziert, sitzen kritische Variablendefinitionen oft genau in diesem blinden Fleck.

Wenn die KI eine Definition übersieht, hält sie nicht an und fragt. Sie rät. Sie füllt die Lücke mit etwas, das statistisch plausibel, aber sachlich falsch ist. In der KI-Terminologie heißt das Halluzination. In Ihrem Bankensystem bedeutet das, dass die KI annehmen könnte, eine Variable sei eine Ganzzahl, obwohl sie tatsächlich ein gepacktes Dezimalformat ist. Diese eine falsche Annahme kann Finanzdaten korrumpieren, die Datenbankintegrität brechen und ein Transaktionssystem lahmlegen. Ihr Code kompiliert. Ihre Tests bestehen. Ihre Produktionsumgebung fällt aus.

Was funktioniert (und was nicht)

Beginnen wir mit dem, was Ihre Teams wahrscheinlich schon versucht oder erwogen haben — und warum jeder dieser Ansätze zu kurz greift.

Lift and Shift (Rehosting): Sie verschieben die kompilierte Anwendung in einen Cloud-Emulator. Das ändert Ihre Hosting-Rechnung, bewahrt aber jede Zeile verworrenen Legacy-Codes. Sie schleppen die gesamte technische Altlastenschuld in eine neue Umgebung und gewinnen keinerlei Flexibilität der Cloud.

Manuelle Neuentwicklung: Sie stellen Entwickler ein, um alles von Hand in Java neu zu schreiben. Das ist schmerzhaft langsam, astronomisch teuer und hängt davon ab, Menschen zu finden, die sowohl COBOL als auch moderne Architektur verstehen. Da Ihre COBOL-Experten in Rente gehen, wird das von Jahr zu Jahr schwieriger.

KI-Wrapper-Werkzeuge: Sie richten ein kommerzielles KI-Codierungsassistenzwerkzeug auf Ihre Codebasis. Es übersetzt Syntax schnell. Aber wie das Scheitern der Bank zeigt, übersieht es dateiübergreifende Abhängigkeiten, halluziniert Variablendefinitionen und produziert Code, der richtig aussieht, sich aber falsch verhält.

Das funktioniert tatsächlich — ein grafikbasierter Ansatz, der Ihren Code als verbundenes System behandelt und nicht als Stapel von Textdateien:

1. Analysieren Sie die Struktur, nicht nur den Text. Statt Ihren Code in beliebige Textblöcke zu zerschneiden, parsen Sie jede Datei in einen Baum, der ihre logische Struktur repräsentiert — jede Variable, jede Funktion, jeden Kontrollfluss-Zweig. Dies stellt sicher, dass die KI die Grenzen Ihres Codes respektiert. Eine Funktion wird als vollständige logische Einheit behandelt, nicht als zufälliger Textschnipsel.

2. Bauen Sie eine Karte jeder Beziehung auf. Sie extrahieren jede Verbindung in Ihrer Codebasis — welche Module welche Unterprogramme aufrufen, welche Dateien welche Variablen definieren, welche Funktionen welche Datenbanktabellen aktualisieren — und speichern sie in einem Wissensgraphen. Wenn die KI eine Zahlungsfunktion übersetzen muss, greift sie nicht einfach nach Text, der „Zahlung“ erwähnt. Sie folgt der tatsächlichen Abhängigkeitskette, um jede Variablendefinition, jede gemeinsame Header-Datei und jede Downstream-Auswirkung einzubeziehen. Das ist, was Veriprajna einen Repository-Aware Knowledge Graph, nennt — und er löst damit direkt das „Lost in the Middle“-Problem.

3. Prüfen Sie jede Ausgabe gegen die Karte. Die KI generiert Java-Code und kompiliert ihn anschließend in einer Sandbox. Wirft der Compiler einen Fehler — etwa eine fehlende Variable — fragt das System den Graphen ab, findet die Abhängigkeit und generiert den Code neu. Diese Compile-Fix-Schleife läuft automatisch. Ihre Entwickler prüfen verifizierte Ausgaben, keine rohen KI-Vermutungen.

Der Vorteil, der für Ihre Compliance- und Audit-Teams am meisten zählt: Jede Entscheidung der KI ist nachvollziehbar. Der Wissensgraph zeichnet exakt auf, warum die KI eine bestimmte Bibliothek importiert oder eine Variable auf eine bestimmte Weise definiert hat. Statt einer Blackbox erhalten Sie eine Zitationskette. Ihre Prüfer können die Logikkette für jede Zeile generierten Codes nachvollziehen.

Dieser Ansatz beseitigt auch Verschwendung, bevor die Migration überhaupt beginnt. Der Wissensgraph identifiziert toten Code — Funktionen, die nichts in Ihrem System tatsächlich aufruft. Das Entfernen toten Codes reduziert die Codebasis typischerweise um 20–30 %, was niedrigere Migrationskosten und ein saubereres Endergebnis bedeutet.

Für Organisationen im Finanzdienstleistungssektor , die regulatorischer Prüfung ausgesetzt sind, ist diese Art von Transparenz nicht optional. Und wenn Ihre Modernisierung die Rückverfolgung der Datenherkunft über Systeme hinweg erfordert, übertragen Veriprajas Funktionen für Datenherkunft und Rückverfolgbarkeit denselben grafikbasierten Ansatz auf Ihre gesamte Datenpipeline.

Sie können die vollständige technische Analyse lesen , um die technischen Details für das Engineering zu erhalten, oder die interaktive Version erkunden , um in einem visuellen Durchlauf zu sehen, wie der Wissensgraph in der Praxis funktioniert.