Qualitätssicherung in der Softwareentwicklung beruht bislang überwiegend auf Stichproben: Tests prüfen einzelne Fälle, Code-Reviews prüfen das Verständnis einzelner Menschen. Eine Meldung aus dem Umfeld von Google DeepMind deutet darauf hin, dass sich dieses Verhältnis verschieben könnte. Mit einem System namens AlphaProof Code wurde der kryptografische Kerncode des Messengers Signal nach Angaben des Unternehmens erstmals mathematisch verifiziert – und zwar in rund vier Wochen statt der sonst üblichen Jahre.

Was formale Verifikation von Tests unterscheidet

Formale Verifikation ist ein Verfahren, bei dem mit mathematischen Mitteln bewiesen wird, dass ein Programm eine festgelegte Spezifikation unter allen möglichen Eingaben erfüllt. Der Unterschied zum klassischen Test ist grundlegend: Ein Test zeigt, dass ein Fehler in einem konkreten Fall nicht auftritt. Ein Beweis zeigt, dass eine bestimmte Klasse von Fehlern überhaupt nicht auftreten kann.

Der Preis dafür war bisher hoch. Beweise müssen in spezialisierten Sprachen formuliert und maschinell überprüft werden, und der Aufwand übersteigt den eigentlichen Programmieraufwand oft um ein Vielfaches. Deshalb beschränkt sich formale Verifikation traditionell auf sehr kleine, sehr kritische Codebestandteile – etwa in Luftfahrt, Chipdesign oder eben Kryptografie.

Was im Fall Signal passiert ist

Laut der Meldung schrieben KI-Agenten auf Basis des Modells Gemini Carbon über sechs Millionen Zeilen Beweiscode. Nur etwa ein Prozent davon wurde für eine menschliche Nachkontrolle markiert. Die Arbeit konzentrierte sich auf den kryptografischen Kern von Signal, also jenen Teil, der die Verschlüsselung der Kommunikation trägt.

Bemerkenswert ist dabei weniger die Codemenge als das Verhältnis: Die Maschine übernimmt den mühsamen, formal strengen Teil, der Mensch konzentriert sich auf die Stellen, an denen der Beweis unsicher oder die Spezifikation fragwürdig ist. Genau dieses Verhältnis entscheidet darüber, ob ein Verfahren aus der Nische in die Breite kommt.

Als nächste Anwendungsfelder werden kritische Infrastrukturen genannt, etwa Stromnetze oder Medizingeräte. Das sind Bereiche, in denen Fehlverhalten unmittelbare physische Folgen hat und in denen Zulassungsverfahren ohnehin nach belastbaren Nachweisen verlangen.

Was das Ergebnis nicht zeigt

Ein Beweis gilt immer nur gegenüber einer Spezifikation. Wenn die Spezifikation falsch oder unvollständig formuliert ist, ist der Beweis korrekt und das Ergebnis trotzdem nicht das, was gewollt war. Die Frage, was ein System eigentlich tun soll, bleibt eine menschliche und fachliche Aufgabe – und sie wird durch leistungsfähige Beweiswerkzeuge eher wichtiger als unwichtiger.

Ebenso wenig lässt sich aus einem Kryptografie-Kern auf beliebige Anwendungssoftware schließen. Kryptografischer Code ist mathematisch klar beschreibbar, überschaubar im Umfang und stabil in seinen Anforderungen. Eine Fachanwendung mit Schnittstellen, Benutzeroberfläche, Rechtelogik und ständig wechselnden fachlichen Regeln ist ein ganz anderer Gegenstand. Die Übertragbarkeit ist eine offene Frage, kein bereits eingelöstes Versprechen.

Die Richtung ist dennoch relevant

Für die Praxis ist die eigentliche Botschaft eine andere: KI-Systeme werden zunehmend nicht nur zum Erzeugen von Code eingesetzt, sondern zum Prüfen von Code. Das ist aus Sicht der Qualitätssicherung die interessantere Entwicklung. Generierter Code vergrößert zunächst die Menge dessen, was geprüft werden muss. Werkzeuge, die Prüfaufwand übernehmen, wirken in die Gegenrichtung.

Absehbar ist, dass sich dieser Ansatz zuerst dort niederschlägt, wo klar umrissene Eigenschaften geprüft werden können:

  • Sicherheitsrelevante Bausteine wie Authentifizierung, Signatur- und Verschlüsselungsroutinen oder Zugriffsprüfungen
  • Datenverarbeitende Kernlogik, etwa Berechnungen in Abrechnung, Tarifierung oder Dokumentenprüfung
  • Schnittstellenverträge, bei denen Ein- und Ausgabeformate eindeutig beschreibbar sind
  • Migrationslogik, bei der nachgewiesen werden soll, dass alter und neuer Stand gleich rechnen

Was sich in Projekten jetzt schon vorbereiten lässt

Unabhängig davon, wann solche Verfahren allgemein verfügbar werden, profitieren Projekte von Vorarbeiten, die ohnehin sinnvoll sind:

  1. Anforderungen präzise formulieren. Je klarer beschrieben ist, welche Eigenschaft gelten soll, desto eher lässt sie sich später maschinell prüfen – und desto weniger Interpretationsspielraum bleibt im Alltag.
  2. Kritische Logik isolieren. Wenn sicherheits- oder geschäftskritische Berechnungen in klar abgegrenzten Modulen liegen, lassen sie sich gezielt härter prüfen als die Oberfläche darum herum.
  3. Prüfbarkeit als Architekturkriterium behandeln. Verwobene Zuständigkeiten und versteckte Seiteneffekte erschweren jede Form der Verifikation, ob durch Menschen, Tests oder Werkzeuge.
  4. Review-Kapazität umschichten. Wenn Routineprüfungen zunehmend automatisiert ablaufen, sollte die verbleibende menschliche Aufmerksamkeit dorthin gehen, wo fachliche Entscheidungen getroffen werden.

Vertrauen wird nachweisbar

Mittelfristig verschiebt sich damit auch die Argumentation gegenüber Auftraggebern, Auditoren und Aufsichtsstellen. Heute lautet die Aussage meist: Es wurde sorgfältig entwickelt, getestet und reviewt. Künftig könnte in Teilbereichen die Aussage möglich sein, dass eine bestimmte Eigenschaft nachweislich gilt. Das ist ein qualitativer Unterschied, insbesondere in regulierten Branchen.

Für Web- und Softwareprojekte heißt das konkret: Qualitätssicherung bleibt notwendig, aber ihr Schwerpunkt verlagert sich von der Fehlersuche hin zur sauberen Beschreibung dessen, was richtig ist. Wer heute in präzise Anforderungen, klar geschnittene Architektur und nachvollziehbare Abnahmekriterien investiert, schafft die Grundlage dafür, solche Prüfverfahren später überhaupt nutzen zu können. Und bis dahin zahlen sich dieselben Maßnahmen schon dadurch aus, dass sie Reviews, Tests und Wartung spürbar entlasten.

Quellen