KI-generierten Code prüfen: Checkliste für Geschäftsführer ohne IT-Abteilung

Warum KI-Code eine eigene Prüfung braucht

Der Reflex ist verständlich: Wenn der Code läuft und die Seite lädt, scheint die Sache erledigt. Genau darauf ist das Problem gebaut. Ungeprüfter KI-Code fällt nicht im Test auf, sondern im Betrieb — weil der Normalfall funktioniert und der Sonderfall nie ausprobiert wurde.

Veracode testete 2025 über 100 KI-Sprachmodelle. In 45 % der erzeugten Code-Beispiele fanden sich Schwachstellen aus den OWASP Top 10; bei Java lag der Anteil bei 72 %. Bemerkenswert ist der Nebenbefund: Größere und neuere Modelle schrieben funktionaleren Code, aber keinen sichereren. Mehr Rechenleistung löst das Problem also nicht.

Dass die Selbsteinschätzung dabei in die falsche Richtung zeigt, ist ebenfalls belegt. In einer Untersuchung von Perry und Kollegen (ACM CCS 2023) schrieben Entwickler mit KI-Assistent messbar unsichereren Code — und hielten ihn zugleich häufiger für sicher. Mehr Fehler und zugleich mehr Sicherheitsgefühl — das ist der unangenehme Befund.

Die Berufsgruppe selbst ist entsprechend skeptisch: Im Stack Overflow Developer Survey 2025 lag der Anteil derer, die der Genauigkeit von KI-Werkzeugen misstrauen, bei 46 % — höher als der Anteil derer, die ihr vertrauen (33 %). Als größte Frustration nannten 66 % Lösungen, die „fast richtig, aber nicht ganz“ sind; 45 % gaben an, das Debuggen von KI-Code sei zeitaufwendiger. Wer bezahlt, sollte diese Zahlen kennen — sie erklären, warum ein Angebot ohne Prüfschritt zu billig aussieht.

Die vier Fragen, die eine Prüfung beantworten muss

Prüfen heißt nicht „noch einmal draufschauen“. Es heißt, vier verschiedene Fragen an dieselbe Stelle zu stellen — Fragen, die einander widersprechen dürfen. Bei MCP Baldux tut das der Council: vier unabhängige Prüfrollen, von denen keine ihre eigene Arbeit freigibt.

Der Unterschied zu einer einzelnen Kontrollrunde liegt im Blickwinkel. Ein Modell, das gerade eine Abfrage geschrieben hat, prüft sie darauf, ob sie das Gewünschte liefert. Die Sicherheitsrolle prüft dieselbe Abfrage darauf, was passiert, wenn jemand die Nummer in der Adresszeile verändert. Das ist nicht mehr Aufwand vom Gleichen, sondern eine andere Frage — und nur die zweite Frage findet die Lücke.

Übertragen auf ein Angebot heißt das: Ein Anbieter, der „Code-Review mit KI“ anbietet, sagt damit noch nichts. Entscheidend ist, ob die prüfende Instanz von der bauenden getrennt ist und ob eine der Rollen tatsächlich blockieren kann. Ohne Blockaderecht ist eine Prüfung eine Empfehlung.

Belegkette und Prüfsiegel: der Nachweis, den Sie verlangen können

Eine Prüfung, die niemand nachlesen kann, ist eine Behauptung. Deshalb gehört zu jeder Freigabe ein Protokoll: was geändert wurde, welche Rolle es geprüft hat, mit welchem Ergebnis, und was nach einer Beanstandung nachgebessert wurde. Diese Kette heißt bei uns Belegkette; in der Fachsprache ist es ein Audit-Trail.

Der geprüfte Stand bekommt zusätzlich eine maschinell erzeugte Kennzeichnung — ein Prüfsiegel. Es beweist nicht, dass der Code fehlerfrei ist. Es macht sichtbar, ob der Stand, der bei Ihnen liegt, derselbe ist, der die Prüfung durchlaufen hat. Beides sind Werkzeuge gegen dieselbe Sorge: dass zwischen Freigabe und Auslieferung noch etwas passiert ist, von dem niemand weiß.

Ein Prüfsiegel ist ein Erkennungsmerkmal, kein Schutzschild. Es zeigt Abweichungen an — es verhindert sie nicht. Wer Ihnen mehr verspricht, verspricht zu viel.

Acht Punkte, die Sie von jedem Anbieter verlangen sollten

Diese Liste ist so geschrieben, dass Sie sie in ein Gespräch mitnehmen können. Jeder Punkt ist eine Frage, auf die es eine belegbare Antwort gibt — oder ein Ausweichen, das für sich spricht.

1. Wer prüft? Verlangen Sie die Aussage, dass die prüfende Instanz nicht dieselbe ist wie die bauende — und lassen Sie sich erklären, wie das technisch sichergestellt wird.
2. Kann eine Prüfung blockieren? Wenn jede Beanstandung überstimmbar ist, ist die Prüfung Kosmetik.
3. Was wird protokolliert? Fragen Sie nach einem Beispielprotokoll einer Änderung — anonymisiert, aber vollständig.
4. Wie erkennen Sie den geprüften Stand wieder? Es muss ein Merkmal geben, das eine spätere Abweichung sichtbar macht.
5. Wer sieht welche Daten? Rollen und Rechte gehören in den Plan, nicht in die Nacharbeit.
6. Was passiert, wenn eine Schnittstelle ausfällt? Für jede Anbindung muss ein definiertes Verhalten im Fehlerfall vereinbart sein.
7. Wem gehört das Ergebnis? Lassen Sie sich schriftlich geben, was übergeht und was lizenziert bleibt — samt der Frage, ob eine andere Agentur damit weiterarbeiten darf.
8. Wo liegen die Daten? Betriebsdaten, Entwicklungsdaten und KI-Verarbeitung sind drei verschiedene Orte. Alle drei müssen benannt sein.

Punkt sieben ist der, an dem die meisten Angebote unscharf werden. Wie die Aufteilung bei MCP Baldux aussieht, steht wörtlich in der Antwort auf die Frage nach den Rechten weiter unten — und im Vertrag an derselben Stelle.

Was Sie selbst prüfen können, ohne Code zu lesen

Vier Dinge lassen sich ohne Programmierkenntnisse überprüfen, und sie decken erstaunlich viel ab. Erstens die Rechte: Melden Sie sich mit einem Konto an, das wenig darf, und versuchen Sie, an etwas heranzukommen, das Sie nichts angeht — etwa indem Sie in der Adresszeile eine Nummer verändern. Zweitens die Sonderfälle: Reichen Sie einen Vorgang ein, der die Ausnahme darstellt, über die im Betrieb immer geredet wird.

Drittens der Ausfall: Lassen Sie sich zeigen, was passiert, wenn das angebundene System nicht antwortet — hängt die Maske, oder gibt es eine verständliche Meldung? Viertens die Übergabe: Lassen Sie sich einmal vorführen, wie Sie an den Quellstand und an den Server kommen, ohne den Anbieter zu fragen. Wenn das im laufenden Betrieb funktioniert, funktioniert es auch nach einer Trennung.