„KI halluziniert doch. So etwas kann ich in sicherheitsrelevanter Entwicklung nicht brauchen.” Diesen Satz hören wir in fast jedem Erstgespräch mit Entwicklungsleitern — und er ist kein Vorurteil, sondern gesunder Ingenieursverstand. Wer Produkte baut, bei denen Fehler teuer oder gefährlich sind, darf einem System misstrauen, das überzeugend klingende Fehler produzieren kann.
Trotzdem wäre der Umkehrschluss falsch, KI ganz aus der Entwicklung herauszuhalten. Die richtige Frage ist nicht ob, sondern wo: An welchen Stellen des V-Modells trägt KI zuverlässig — und an welchen richtet sie mehr Schaden an, als sie nützt? Dieser Artikel ist unsere ehrliche Landkarte. Sie stammt nicht aus Anbieterfolien, sondern aus 15 Jahren Test-Ingenieursarbeit im Embedded-Bereich und dem täglichen KI-Einsatz in unserer eigenen Organisation.
Die Grundregel: Prüfen ist leichter als Erzeugen
Fast alle sinnvollen KI-Einsätze im Engineering folgen einem Muster: KI erzeugt einen Vorschlag, ein Mensch mit Fachurteil prüft und entscheidet. Das funktioniert überall dort gut, wo das Prüfen eines Ergebnisses deutlich schneller geht als sein Erzeugen — ein Ingenieur bewertet zwanzig vorgeschlagene Testfälle in einem Bruchteil der Zeit, die er zum eigenständigen Ausdenken gebraucht hätte.
Umgekehrt gilt: Wo das Prüfen genauso aufwendig ist wie das Selbermachen — oder wo niemand mehr prüft, weil das Ergebnis so überzeugend aussieht — kippt der Nutzen. Genau dort entstehen die Geschichten, die das Misstrauen der Ingenieure nähren.
Wo KI heute zuverlässig trägt
Requirements-Reviews: der stärkste Hebel
Anforderungen auf Eindeutigkeit, Widersprüche, Vollständigkeit und Testbarkeit zu prüfen ist klassische Fleißarbeit: wichtig, ermüdend, und in der Praxis immer zu knapp bemessen. KI ist hier in ihrer Paradedisziplin — sie liest tausend Anforderungen ohne Ermüdung, findet die Formulierung, die zwei Interpretationen zulässt, und den Widerspruch zwischen Anforderung 47 und 812.
Entscheidend: Das Ergebnis ist eine Befundliste, kein Urteil. Jeder Befund lässt sich in Sekunden gegen die Quelle prüfen. Ein falscher Befund kostet einen Klick, ein gefundener Widerspruch spart Wochen. Das Risiko-Nutzen-Verhältnis ist kaum zu schlagen — deshalb empfehlen wir Requirements-Reviews fast immer als Pilotprojekt.
Testfall-Ableitung: Vorschlag statt Freigabe
Aus einer sauberen Anforderung Testfälle abzuleiten — Normalfälle, Grenzwerte, Fehlerfälle — ist strukturierte Arbeit mit klaren Regeln. KI schlägt vollständigere Testfallmengen vor, als unter Zeitdruck von Hand entstehen, und vergisst die unbequemen Randfälle nicht.
Aber: Die KI schlägt vor, der Testingenieur entscheidet, was in die Testspezifikation übernommen wird. Die Verantwortung für die Testabdeckung bleibt beim Menschen — die KI sorgt dafür, dass er sie mit besserem Material wahrnimmt.
Dokumentation und Traceability-Pflege
Verknüpfungen zwischen Anforderung, Implementierung und Testergebnis aktuell zu halten ist die Arbeit, die in jedem Audit gebraucht und in jedem Projekt aufgeschoben wird. KI kann Verknüpfungsvorschläge machen, verwaiste Anforderungen melden, veraltete Dokumentationsabschnitte markieren und Änderungsbeschreibungen vorformulieren. Der Charme: All das passiert in der bestehenden ALM-Umgebung — Polarion, Codebeamer, Jira — und stärkt die Auditierbarkeit, statt sie zu gefährden.
Code-Review als zusätzliche Instanz
Ein KI-Review ersetzt keinen menschlichen Reviewer — es ist eine zusätzliche Instanz davor. Es findet die vergessene Null-Prüfung, die Abweichung von der Coding-Richtlinie und den Copy-Paste-Fehler, bevor ein Kollege seine Zeit darauf verwendet. Menschliche Reviews werden dadurch nicht überflüssig, sondern besser: Sie können sich auf Architektur und Logik konzentrieren statt auf Formalien.
Befundbewertung in der Pipeline
Wenn der Nightly Build rot ist, beginnt Detektivarbeit: Welcher Commit, welches Modul, echter Fehler oder flakiger Test? KI kann Build-Logs vorauswerten, Befunde clustern, Verdächtige benennen und die Zusammenfassung schreiben, die morgens im Stand-up gebraucht wird. Falsch liegen darf sie dabei — es ist eine Priorisierungshilfe, keine Entscheidung.
Wissenssuche im Projektbestand
„Haben wir dieses Problem nicht 2019 schon einmal gelöst?” KI-gestützte Suche über Confluence, Altprojekte und Ticket-Historie beantwortet solche Fragen in Sekunden, mit Quellenangabe. Gerade in Teams, in denen erfahrene Kollegen das Projektgedächtnis sind, ist das Gold wert — mehr dazu in unserem Artikel über Wissensverlust.
Wo KI nicht trägt — und wo sie täuscht
Genauso wichtig ist die andere Hälfte der Landkarte. Diese Einsätze raten wir ab — teilweise grundsätzlich, teilweise beim heutigen Stand der Technik:
Finale Freigaben und Sicherheitsentscheidungen. Kein KI-System gibt bei uns etwas frei. Freigaben brauchen Verantwortung, und Verantwortung braucht einen Menschen mit Namen. Das ist keine technische Grenze, sondern eine organisatorische Grundsatzentscheidung — und nach EU AI Act für viele Anwendungen schlicht Pflicht.
Anforderungen erfinden. KI kann Anforderungen prüfen, strukturieren und umformulieren. Aber sie darf keine fachlichen Anforderungen erzeugen, die kein Fachexperte diktiert hat — sonst steht am Anfang der Traceability-Kette eine plausibel klingende Vermutung. Das ist der klassische Halluzinations-Unfall im Engineering-Kontext.
Berechnungs- und Sicherheitsnachweise. Auslegungsrechnungen, Worst-Case-Analysen, Sicherheitsnachweise: Hier zählt nicht Plausibilität, sondern Korrektheit. Sprachmodelle rechnen nicht — sie formulieren. Für Nachweise gehören verifizierte Werkzeuge und Vier-Augen-Prinzip an den Tisch, keine KI-Prosa.
„Die KI sagt, der Test ist grün.” Testergebnisse müssen reproduzierbar und nachvollziehbar sein. KI darf Ergebnisse zusammenfassen und auffällige Muster melden — aber die Aussage „bestanden” muss aus dem Testsystem kommen, nicht aus einer Interpretation.
Bereiche ohne Datengrundlage. Wo Prozesse undokumentiert und Daten unstrukturiert sind, hat KI nichts, worauf sie arbeiten kann. Wer sie trotzdem einführt, automatisiert das Chaos. Erst die Prozesse für KI optimieren, dann KI einführen — in dieser Reihenfolge, nie umgekehrt.
Die vier Prüffragen für jeden Einsatzfall
Ob ein konkreter Einsatz in die linke oder rechte Spalte gehört, lässt sich mit vier Fragen entscheiden:
- Prüfbarkeit: Kann ein Fachmensch das KI-Ergebnis schnell und sicher gegen die Quelle prüfen? Wenn nein — Finger weg.
- Fehlerkosten: Was kostet es, wenn das Ergebnis falsch ist und durchrutscht? Je höher, desto enger die menschliche Kontrolle.
- Reversibilität: Lässt sich die Wirkung rückgängig machen? Ein verworfener Vorschlag ist harmlos, eine ausgelieferte Firmware nicht.
- Datenlage: Gibt es strukturierte, gepflegte Daten, auf denen die KI arbeiten kann? Ohne Fundament kein Aufbau.
Wer diese vier Fragen konsequent stellt, braucht keinen Glauben an KI — und keine Angst vor ihr. Er braucht ein Vorgehen. Genau dafür gibt es unser Stufenmodell: Governance und Datenreife zuerst, dann der Prozess, dann — wer will — das Produkt.