Die Verifikationslücke

Fast nie am Modell. Die MIT-Studie The GenAI Divide (Project NANDA, 2025) kommt zu einem ernüchternden Befund: Rund 95 Prozent der Organisationen erzielen keinen messbaren Return auf ihre GenAI-Investitionen. Nur etwa 5 Prozent der integrierten Pilotprojekte liefern einen klaren Wertbeitrag.

Gartner erwartet, dass mindestens 30 Prozent der generativen KI-Projekte bis Ende 2025 nach dem Proof of Concept aufgegeben werden, und beobachtet inzwischen sogar höhere Abbruchquoten. Bei autonomen KI-Agenten rechnet Gartner damit, dass mehr als 40 Prozent der Projekte bis Ende 2027 eingestellt werden. Die wiederkehrenden Gründe sind dieselben: schlechte Datenqualität, fehlende Prozesse, steigende Kosten und ein unklarer Geschäftsnutzen.

Anders gesagt: Die Projekte scheitern an Organisation und Verantwortung, nicht an der Technik. Wer mit der Technologie statt mit dem Problem startet, baut teure Demos statt tragfähiger Systeme.

Der Begriff Verification Debt stammt von Werner Vogels, dem CTO von Amazon. Er beschreibt die Differenz zwischen Code, der erzeugt wird, und Code, der tatsächlich geprüft wird. Die Zahlen dahinter sind eindeutig.

Laut dem State of Code Developer Survey von Sonar (2026, über 1.100 Entwickler weltweit) vertrauen 96 Prozent der Befragten KI-generiertem Code nicht voll. Aber nur 48 Prozent prüfen ihn vor jedem Commit konsequent nach. Diese 48-Punkte-Differenz ist die Lücke. KI macht laut derselben Erhebung bereits rund 42 Prozent des eingecheckten Codes aus, und 38 Prozent der Entwickler sagen, das Prüfen von KI-Code sei aufwendiger als das Prüfen von Code aus dem eigenen Team.

Was passiert, wenn diese Lücke offenbleibt? Der CodeRabbit-Report (2025, 470 untersuchte Pull-Requests) misst rund 1,7-mal mehr Probleme pro Pull-Request in KI-generiertem Code, 10,83 gegenüber 6,45. Eine peer-reviewte Studie von CodeScene (Borg und Tornhill, 2026) zeigt, dass KI-Assistenten das Defektrisiko um mindestens 30 Prozent erhöhen, sobald sie auf ohnehin schwachem Code arbeiten, in stark verschachteltem Code sogar um rund 60 Prozent. Eine seriös belegbare Pauschalzahl zu Wartungskosten gibt es nicht, die Richtung aber ist klar: Ungeprüfter KI-Code wird später teuer.

Die Lücke schließt man nicht, indem man weniger KI nutzt, sondern indem man jeden KI-Beitrag durch dieselben Kontrollen schickt wie menschlichen Code, nur strenger und automatisierter. Bei InitFrame durchläuft jeder Beitrag eine feste Reihe von Stufen, bevor er live geht.

Was sich technisch lohnt, wird ab 2026 auch regulatorisch eingefordert. Die KI-Verordnung der EU (Verordnung 2024/1689) verpflichtet seit dem 2. Februar 2025 alle Unternehmen, die KI einsetzen, zu KI-Kompetenz (Artikel 4), ohne Ausnahme für kleine und mittlere Unternehmen. Bei verbotenen Praktiken drohen Bußgelder bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes, bei sonstigen Pflichtverstößen bis zu 15 Millionen Euro oder 3 Prozent.

Beim Stichtag lohnt Genauigkeit: Der 2. August 2026 markiert das Ende der ursprünglichen Übergangsfrist. Die zentralen Hochrisiko-Pflichten werden mit dem sogenannten Digital Omnibus voraussichtlich verschoben, für eigenständige Systeme auf Dezember 2027, für in Produkte eingebettete Systeme auf August 2028. Stand Juni 2026 ist diese Verschiebung politisch beschlossen, aber noch nicht endgültig in Kraft.

Parallel greift der Cyber Resilience Act (Verordnung 2024/2847). Hersteller von Produkten mit digitalen Elementen müssen ab dem 11. Dezember 2027 unter anderem eine technische Dokumentation führen, Schwachstellen über den Supportzeitraum behandeln und ein Konformitätsverfahren durchlaufen. Die Meldepflichten für aktiv ausgenutzte Schwachstellen gelten schon ab dem 11. September 2026.

All das verlangt im Kern dasselbe: Nachvollziehbarkeit. Wer KI-Code von Anfang an prüfbar, protokolliert und dokumentiert baut, erfüllt diese Pflichten als Nebenprodukt. Wer die Verifikation auslässt, muss sie später teuer nachrüsten. Dieser Abschnitt ist eine technische Einordnung, kein Rechtsrat.

Diese Ehrlichkeit gehört dazu: Nicht jedes Vorhaben profitiert von KI-gestützter Entwicklung. Wenn das Problem unklar ist, die Datenbasis schlecht oder niemand bereit ist, den Output zu verantworten, ist AI-first der falsche Hebel. Bei kleinen, stabilen, selten geänderten Aufgaben übersteigt der Aufwand für Spezifikation, Evals und Gates schnell den Nutzen.

AI-first lohnt sich dort, wo viel ähnlicher Code entsteht, wo Qualität messbar ist und wo ein Verantwortlicher das Ergebnis tragen kann. Als Selbstzweck, weil gerade alle KI machen, lohnt es sich nie.