Wissen

Verifizierte KI-Entwicklung: Kann man KI-Code vertrauen?

Nur, wenn jemand ihn unabhängig prüft. KI schreibt Software schnell — und irrt sich dabei überzeugend. Vertrauen entsteht durch eine nachvollziehbare Prüfung jedes Schritts.

Zuletzt aktualisiert: 18. August 2026 · Baldux GmbH

Was ist verifizierte KI-Entwicklung?

Verifizierte KI-Entwicklung ist Softwareentwicklung, bei der eine KI baut und ein vom bauenden Modell unabhängiger Prüfapparat jeden Schritt gegen feste Regeln kontrolliert, das Ergebnis nachvollziehbar belegt und den geprüften Stand kryptografisch überprüfbar kennzeichnet. Sie unterscheidet sich von Vibe Coding und KI-Baukästen dadurch, dass nicht die KI behauptet, fertig zu sein, sondern eine getrennte Prüfung es nachweist. Vier Kennzeichen: unabhängige Prüfung, Belegkette, Prüfsiegel, kundenspezifischer Code beim Kunden.

Der Begriff bezeichnet eine Kategorie, kein Produkt. Jeder Anbieter kann sie erfüllen oder verfehlen, und die Kriterien dafür lassen sich abfragen (Abschnitt 5). Das Werkzeug, mit dem MCP Baldux sie umsetzt, ist die KI-Engine mit vier Prüfrollen — ein Ablauf, der die Prüfung erzwingt, statt sie zu empfehlen. Eine kompakte Fassung dieser Definition steht im Lexikon.

Warum KI-Code Prüfung braucht — die Zahlen

KI-generierter Code muss wie Fremdcode geprüft werden: Ein Modell erkennt seine eigenen Fehler schlecht, erst die vom bauenden Modell unabhängige Prüfung jedes Schritts macht das Ergebnis belastbar.

Moderne KI erzeugt lauffähigen Code oft in Minuten. Das eigentliche Risiko ist nicht der offensichtliche Fehler, sondern der überzeugende: Code, der übersetzt und vernünftig aussieht, im Betrieb aber falsch handelt — eine KI-Halluzination in Software. Wie groß dieses Risiko ist, muss man nicht schätzen; es ist gemessen worden.

Sicherheit. Veracode testete 2025 über 100 KI-Sprachmodelle: 45 % der generierten Code-Beispiele enthielten Schwachstellen aus den OWASP Top 10, bei Java lag die Quote bei 72 %. Bemerkenswert ist die zweite Feststellung desselben Berichts: Neuere und größere Modelle schrieben zwar funktionaleren, aber keinen sichereren Code — die Sicherheitsleistung blieb unabhängig von der Modellgröße flach (Veracode (Anbieter für Anwendungssicherheit), GenAI Code Security Report, 2025). Wer auf das nächste Modell wartet, bekommt damit nicht automatisch sichereren Code.

Selbsteinschätzung. Eine Stanford-Studie (Perry et al., ACM CCS 2023) zeigte, dass Entwickler mit KI-Assistent signifikant unsichereren Code schrieben — und ihn zugleich häufiger für sicher hielten (Perry et al., Stanford, ACM CCS 2023). Das ist der eigentlich unangenehme Befund: Wer den unsichereren Code schrieb, hielt ihn eher für sicher. Genau deshalb hilft es nicht, dieselbe Person oder dasselbe Modell noch einmal draufschauen zu lassen.

Vertrauen in der Praxis. Im Stack Overflow Developer Survey 2025 misstrauten mehr Entwickler der Genauigkeit von KI-Tools (46 %) als ihr vertrauten (33 %). Als größte Frustration nannten 66 % Lösungen, die „fast richtig, aber nicht ganz“ sind; 45 % gaben an, dass das Debuggen von KI-Code zeitaufwendiger ist (Stack Overflow Developer Survey 2025). Diese Zahl hat sich verschoben: 2024 fühlten sich noch 43 % mit der Genauigkeit von KI-Ausgaben wohl. Mit der Verbreitung ist also die Erfahrung gewachsen, nicht das Vertrauen.

Tempo. Eine METR-Studie vom Juli 2025 ließ erfahrene Open-Source-Entwickler mit und ohne KI-Werkzeuge an ihren eigenen Projekten arbeiten. Mit KI brauchten sie 19 % länger — obwohl sie vorher eine Beschleunigung um 24 % erwartet hatten (METR, 2025). Das widerlegt nicht, dass KI schnell schreibt. Es zeigt, wohin die eingesparte Zeit wandert: ins Nachvollziehen und Korrigieren.

Lieferfähigkeit. Der DORA-Bericht 2024 von Google fand einen Zusammenhang zwischen KI-Nutzung und Auslieferung: Je 25 % mehr KI-Einsatz gingen mit 1,5 % weniger Liefer-Durchsatz und 7,2 % geringerer Liefer-Stabilität einher. 39,2 % der Befragten hatten wenig (27,3 %) oder gar kein Vertrauen (11,9 %) in die Qualität KI-generierten Codes (Google DORA, 2024). Das sind Zusammenhänge, keine bewiesenen Ursachen — aber sie zeigen in dieselbe Richtung wie alles andere.

Die einzelnen Befunde stehen samt Jahr und Quelle noch einmal als Tafel auf Softwareentwicklung mit KI — dort geht es um das Feld insgesamt, hier um das Verfahren dagegen.

Zusammengenommen ergibt sich kein Argument gegen KI in der Entwicklung, sondern eines gegen ungeprüfte KI in der Entwicklung. Eine einzelne KI ist der falsche Prüfer für sich selbst: Ein Modell, das seine eigene Arbeit bewertet, prüft mit denselben blinden Flecken, mit denen es gebaut hat. Geschwindigkeit allein schafft kein Vertrauen — sie verschiebt die Arbeit nur nach hinten, dorthin, wo sie teurer ist.

Abgrenzung: Vibe Coding, KI-Code-Review, Zertifizierung, Agentur

Vier benachbarte Begriffe werden regelmäßig mit verifizierter KI-Entwicklung verwechselt. Alle vier haben ihren Platz; keiner davon leistet dasselbe.

Vibe Coding ist die Arbeitsweise, bei der man einer KI in normaler Sprache beschreibt, was entstehen soll, und den erzeugten Code weitgehend ungeprüft übernimmt. Der Unterschied liegt in genau einem Punkt: Dort entscheidet die bauende KI selbst, wann etwas fertig ist. Für einen Prototyp ist das die richtige Wahl — schnell, billig, ohne Ballast. Für ein System, auf das sich ein Betrieb verlässt, fehlen Prüfung, Nachweis und Übergabe. Mehr dazu im Lexikon und im Vergleich.

KI-Code-Review ist ein einzelner Prüfschritt: Ein Modell liest fertigen Code und meldet Auffälligkeiten. Das ist nützlich und ersetzt nichts. Der Unterschied ist die Stellung im Ablauf — ein Review steht meist am Ende, ist optional und lässt sich unter Termindruck überspringen. Verifizierte KI-Entwicklung prüft jeden Schritt statt nur das Ergebnis, und der Ablauf lässt die Prüfung nicht aus. Außerdem prüfen vier Rollen mit unterschiedlichen Fragen statt eines einzelnen Modells. Was Sie als Auftraggeber davon verlangen können, steht als Liste im Ratgeber KI-generierten Code prüfen; die typischen Fehlerformen einzeln stehen im Ratgeber zur KI-Halluzination im Code.

Zertifizierung bescheinigt einer Organisation, dass sie ein Verfahren einhält — geprüft wird das Managementsystem, nicht Ihr Vorhaben. Verifizierte KI-Entwicklung erzeugt den Nachweis am einzelnen Arbeitsergebnis: Diese Version, diese Prüfungen, dieses Siegel. Beides schließt sich nicht aus. Nur ersetzt ein Zertifikat an der Wand keine Belegkette zu Ihrer Anwendung, und umgekehrt.

Die klassische Agentur unterscheidet sich nicht in der Sorgfalt, sondern in der Bauweise. Dort bauen Menschen nach Stunden, und die Qualitätssicherung hängt an Prozess und Team; hier baut eine KI, und die Prüfung ist als Ablauf erzwungen. Der anspruchsvolle Teil ist in beiden Fällen menschlich — die Architektur. Ausführlich im Vergleich Agentur.

Wie verifizierte KI-Entwicklung abläuft

Bei MCP Baldux läuft das Verfahren in fünf Stationen. Es ist so gebaut, dass der Ablauf keine Station auslässt — auch nicht, wenn es eilt.

  1. Einreichen. Sie schildern Ihr Vorhaben, gesprochen oder getippt, ohne Konto — daraus entsteht sofort ein strukturierter Plan.
  2. Council-Prüfung. Vier unabhängige Prüfrollen gehen denselben Plan mit unterschiedlichen Fragen durch; kein Modell gibt seine eigene Arbeit frei.
  3. Nachbesserung. Was durchfällt, geht zurück — die Sicherheitsrolle hat ein Veto und kann allein blockieren.
  4. Bau durch die Engine. Erst der freigegebene Plan wird gebaut, bei jedem Schritt erneut geprüft.
  5. Versiegelte Übergabe. Der geprüfte Stand landet in Ihrem GitHub, die Anwendung auf Ihrem Hosting, mit Prüfsiegel und Belegkette.

Vier Bausteine tragen das Verfahren — jeder hat eine eigene, zitierbare Definition:

  • Council — vier unabhängige Prüfrollen prüfen jeden Plan aus vier Richtungen. Architektur fragt, ob der Aufbau in zwei Jahren noch trägt. Sicherheit fragt, ob jemand an Daten kommt, der nicht darf — und hat ein Veto. Vollständigkeit fragt, ob wirklich alles drinsteht, was vereinbart war. Integration fragt, was passiert, wenn das andere System schweigt.
  • Belegkette — jeder Schritt und jede Prüfung bleibt nachträglich einsehbar, mit Rolle, Ergebnis und Zeitpunkt. Auch der Fehlversuch bleibt stehen; Nachbesserungen werden angehängt, nicht überschrieben.
  • Freigabe — eine Arbeitseinheit gilt erst als fertig, wenn sie den Council vollständig durchlaufen hat. Sie ist zugleich die Abrechnungseinheit: bezahlt wird ein geprüftes Ergebnis, nicht der Weg dorthin.
  • Prüfsiegel — bindet den geprüften Stand an eine konkrete Version. Es ist kryptografisch überprüfbar: Es verhindert keine Änderung, aber es macht jede Änderung erkennbar.

Technisch steht darunter das Model Context Protocol, ein offener Standard für die Verbindung von KI-Modellen mit Werkzeugen und Daten. Dessen Spezifikation verlangt, dass Hosts vor jedem Werkzeugaufruf die ausdrückliche Zustimmung des Nutzers einholen (MCP-Spezifikation, Stand 2025-06-18). Genau dieser Moment vor dem Zugriff ist die Stelle, an der sich Regeln überhaupt durchsetzen lassen — mehr dazu unter MCP.

ArchitekturSicherheitVeto · offenVollständigkeitIntegrationPlan #218
Eine Zustimmung fehltDas Siegel schließt nicht — der Plan geht zurück in die Nachbesserung.
ArchitekturSicherheitVetoVollständigkeitIntegrationPlan #218
Alle vier zugestimmtDer Kreis schließt sich: aus vier Prüfungen wird eine Freigabe.

Der Council besteht aus vier unabhängigen Prüfrollen — Architektur, Sicherheit, Vollständigkeit, Integration. Jede prüft jeden Plan; kein Modell gibt seine eigene Arbeit frei, die Sicherheitsrolle hat ein Veto.

Woran Sie verifizierte KI-Entwicklung erkennen

Eine belastbare Lösung erfüllt vier Bedingungen. Sie taugen als Checkliste für jeden Anbieter — auch für uns:

  • Unabhängigkeit. Die Prüfung ist unabhängig vom bauenden Modell, nicht dasselbe System, das sich selbst bewertet. Fragen Sie nach, wer prüft und ob die Prüfung ein fester Teil des Ablaufs ist.
  • Nachvollziehbarkeit. Es gibt eine Belegkette, kein bloßes Endergebnis. Fragen Sie nach einem Beispiel: Schritt, geprüfter Gegenstand, Rolle, Ergebnis, Zeitpunkt.
  • Überprüfbarkeit. Der geprüfte Stand ist kryptografisch überprüfbar. Fragen Sie, wie Sie selbst feststellen, ob der laufende Stand noch der geprüfte ist.
  • Rechte ohne Abhängigkeit. Ihre Anwendung gehört zu Ihrem Unternehmen. Kundenspezifischer Code wird übergeben; das Baldux-Framework bleibt geschützt und ist für Ihre Anwendung dauerhaft lizenziert — ohne Weiterverkauf, Unterlizenz oder Nutzung in anderen Projekten. Fragen Sie, was passiert, wenn Sie kündigen — und lassen Sie sich die Antwort im Vertrag zeigen.

Zwei Warnzeichen dazu. Wenn ein Anbieter die Prüfung als Produktmerkmal beschreibt, das man „aktivieren“ kann, ist sie kein Ablauf, sondern eine Einstellung. Und wenn niemand sagen kann, wo Ihr Code am Ende liegt, dann klären Sie die Eigentumsfrage vor der Unterschrift.

Was das für Unternehmen bedeutet

Kosten. Geprüfte Arbeit ist nicht teurer als ungeprüfte — sie ist nur früher teuer. Weil bei MCP Baldux nach geprüften Freigaben abgerechnet wird, kosten Prüfrunden, Fehlversuche und Nachbesserungen den Kunden nichts: Auf das Kontingent zählen nur geprüfte Freigaben. Was ein Vorhaben ungefähr braucht, lässt sich in Größenordnungen angeben — ein kleines Vorhaben liegt bei 25 bis 40 Freigaben, ein großes bei 150 bis 300. Die Stufen und Beträge stehen offen auf der Preisseite.

Tempo. Die Prüfung kostet Durchläufe, nicht Wochen: Die Engine baut auch außerhalb Ihrer Bürozeiten, und eine Nachbesserung läuft im selben Kontingent weiter — ohne neuen Termin, ohne neues Angebot. Was wirklich Zeit spart, ist der Wegfall der Vorstufen — kein Lastenheft, keine Ausschreibungsrunde, kein Angebot je Änderungswunsch. Was belastbar zugesagt ist: Den Plan sehen Sie sofort, eine Rückmeldung von einem Menschen kommt innerhalb von zwei Arbeitstagen.

Rechte. Die Trennung ist schriftlich geregelt und lässt sich nachlesen. Ihre Anwendung gehört Ihnen: Sie nutzen sie, betreiben sie, lassen sie weiterentwickeln, hosten sie selbst oder lassen hosten. Das Baldux-Framework darunter bleibt unser Eigentum und ist für genau diese Anwendung unbefristet lizenziert — kein Weiterverkauf, keine Unterlizenz, kein Herauskopieren, keine Nutzung in anderen Projekten, auch nicht durch andere Agenturen oder Ihre Mitarbeitenden. Änderungen am Framework fallen an Baldux; die Entwicklungsplattform und die Engine werden nie ausgeliefert. Einzelheiten: AGB Ziffer 12–17 und Lizenz.

Der Hosting-Vertrag läuft auf Ihren Namen. Wenn Sie aufhören, läuft Ihre Anwendung weiter — nur der Zugang zur Entwicklungsplattform endet.

Verantwortung. Menschen entscheiden die Architektur, die KI baut sie. Was in dieser Vorarbeit passiert — Prozesslandkarte, Datenmodell, Rollen, Schnittstellen, Nicht-Ziele, Abnahmekriterien —, steht auf der Seite zur KI-Beratung für Unternehmen. Wie das Ganze als laufende Entwickler-Position funktioniert, zeigt Managed.

Häufige Fragen: KI-generierter Code und Code Review mit KI

Kann man KI-generiertem Code vertrauen?

Nur, wenn ihn jemand unabhängig prüft. Ein Modell erkennt seine eigenen Fehler schlecht; erst die getrennte Prüfung jedes Schritts macht das Ergebnis belastbar. Im Stack Overflow Developer Survey 2025 misstrauten mehr Entwickler der Genauigkeit von KI-Tools (46 %) als ihr vertrauten (33 %).

Was ist verifizierte KI-Entwicklung?

Verifizierte KI-Entwicklung ist Softwareentwicklung, bei der eine KI baut und ein vom bauenden Modell unabhängiger Prüfapparat jeden Schritt gegen feste Regeln kontrolliert, das Ergebnis nachvollziehbar belegt und den geprüften Stand kryptografisch überprüfbar kennzeichnet. Vier Kennzeichen: unabhängige Prüfung, Belegkette, Prüfsiegel, kundenspezifischer Code beim Kunden.

Macht KI Fehler beim Programmieren?

Ja, und zwar überzeugende: Code, der plausibel aussieht und im Betrieb falsch handelt. Veracode fand 2025 in 45 % der von über 100 Modellen erzeugten Code-Beispiele OWASP-Top-10-Schwachstellen. Deshalb prüft bei uns nicht das bauende Modell, sondern vier unabhängige Rollen — jeden Schritt, nicht nur das Ergebnis.

Ist KI-generierter Code sicher?

Nicht von allein. Laut Veracode 2025 schreiben neuere und größere Modelle funktionaleren, aber keinen sichereren Code. Sicherer wird KI-Code durch eine Prüfung, die vom bauenden Modell unabhängig und fester Teil des Ablaufs ist — bei MCP Baldux hat die Sicherheitsrolle ein Veto und kann allein blockieren.

Wer haftet, wenn KI-generierter Code Fehler hat?

Der Anbieter, der die Leistung schuldet — im vertraglich vereinbarten Rahmen. Bei MCP Baldux regeln das die AGB: Ziffer 21 Mängel und Gewährleistung, Ziffer 23 Haftung. Geschuldet sind Entwicklung und Prüfung, nicht absolute Fehlerfreiheit. Maßgeblich ist der Vertragstext, nicht diese Zusammenfassung.

Wem gehört der mit KI gebaute Code?

Ihre Anwendung gehört Ihnen: Sie nutzen sie, betreiben sie, lassen sie weiterentwickeln, hosten sie selbst oder lassen hosten. Das Baldux-Framework darunter bleibt unser Eigentum und ist für genau diese Anwendung unbefristet lizenziert — kein Weiterverkauf, keine Unterlizenz, kein Herauskopieren, keine Nutzung in anderen Projekten, auch nicht durch andere Agenturen oder Ihre Mitarbeitenden. Änderungen am Framework fallen an Baldux; die Entwicklungsplattform und die Engine werden nie ausgeliefert. Einzelheiten: AGB Ziffer 12–17 und /lizenz.

Wie funktioniert Code Review durch KI — reicht das?

Ein Modell liest die Änderung und meldet, was ihm auffällt: Fehler, Sicherheitslücken, Stilbrüche. Das ist nützlich, reicht aber nur, wenn mehrere unabhängige Rollen prüfen und das Ergebnis dokumentiert wird. Eine KI, die ihren eigenen Code prüft, ist keine Prüfung — sie hat beim Prüfen dieselben blinden Flecken wie beim Bauen.

Ist verifizierte KI-Entwicklung eine Zertifizierung?

Nein. Ein Zertifikat bescheinigt einer Organisation, dass sie ein Verfahren betreibt; verifizierte KI-Entwicklung erzeugt den Nachweis am einzelnen Arbeitsergebnis — je Änderung, mit Prüfrolle, Ergebnis und Zeitpunkt. Beides schließt sich nicht aus und ersetzt sich auch nicht.

Welche rechtlichen Risiken hat Code Review mit KI?

Zwei werden regelmäßig genannt: Der zu prüfende Code verlässt das Haus, und die Verantwortung für die Freigabe bleibt trotzdem beim Auftraggeber. Beides ist regelbar — wer welche Inhalte verarbeitet, steht bei uns in der Datenschutzerklärung und im Auftragsverarbeitungsvertrag; wer freigibt, steht in der Belegkette. Rechtsberatung ist das nicht.

Wie lange dauert es bis zur ersten lauffähigen Version?

Das hängt vom Umfang ab; jede pauschale Wochenzahl wäre geraten. Belastbar: Den strukturierten Plan sehen Sie sofort beim Einreichen, ein Mensch meldet sich innerhalb von zwei Arbeitstagen, und nach der kostenlosen Analyse sagen wir, wie viele Freigaben Ihr Vorhaben braucht — daraus ergibt sich die Laufzeit bei Ihrer Stufe.

Quellen

← Zur Startseite

Unverbindlich · kostenlos

Ihr Vorhaben — geprüft gebaut.

Schildern Sie in fünf Minuten, was Ihr Betrieb braucht. Die Engine macht daraus einen Plan, ein Mensch prüft ihn und meldet sich.

Managed ansehen

Kostenlos bis zur BeauftragungAntwort innerhalb von zwei Arbeitstagenservice@baldux.com