KI in regulierter Softwareentwicklung: Geschwindigkeit ohne Kontrollverlust

„Reguliert“ ist kein Zustand, den Software besitzt, sondern eine Anforderung an den Prozess, der sie hervorbringt. Der Unterschied zu einem gewöhnlichen Projekt liegt selten in der Technik. Er liegt in einem zusätzlichen Satz Fragen, die jederzeit beantwortbar sein müssen: Wer hat was auf welcher Grundlage entschieden, wer hat es geprüft, und woran lässt sich das später belegen?

1. Was „reguliert“ in Softwareprojekten bedeuten kann

Der Begriff wird in Ausschreibungen oft pauschal verwendet, meint aber sehr unterschiedliche Regelwerke mit unterschiedlichen Adressaten. Eine grobe Sortierung hilft, den eigenen Fall einzuordnen:

Zwei Klarstellungen, die in der Praxis viel Verwirrung ersparen. Erstens: Managementsystem-Normen zertifizieren Organisationen und Prozesse, nicht ein einzelnes Softwareprodukt. „ISO-zertifizierte Software“ ist deshalb in den meisten Fällen eine unpräzise Formulierung. Zweitens: Validierung ist an einen konkreten Verwendungszweck gebunden. Ein Werkzeug oder eine Plattform kann Voraussetzungen dafür schaffen; validiert wird immer das System in seinem Einsatzkontext.

2. Welche Fragen der KI-Einsatz zusätzlich aufwirft

Regulatorische Anforderungen sind gegenüber der Frage, wie Code entsteht, weitgehend neutral. Sie fordern beherrschte Prozesse, definierte Verantwortung und belastbare Nachweise – ob eine Zeile getippt oder generiert wurde, ist zunächst nachrangig. Praktisch entstehen durch KI dennoch vier neue Fragen:

1. Reproduzierbarkeit. Ein Modell liefert nicht garantiert zweimal dasselbe Ergebnis. Reproduzierbar sein muss deshalb nicht der Generierungsvorgang, sondern das Artefakt: Aus derselben versionierten Definition muss derselbe Build entstehen.
2. Verantwortungszuordnung. Wer den Code beauftragt und freigegeben hat, trägt die Verantwortung. Das muss aus den Aufzeichnungen hervorgehen und nicht aus der Annahme, ein Commit-Autor habe alles selbst geschrieben.
3. Prüftiefe. Wenn Änderungsvolumen steigt, sinkt die faktische Prüftiefe pro Zeile – es sei denn, das Team steuert bewusst dagegen.
4. Datenfluss und Vertraulichkeit. Welche Inhalte gelangen in welches System? Diese Frage betrifft Informationssicherheit und Vertragsrecht, nicht die Codequalität.

3. Requirements: der Anker der gesamten Kette

Jede Nachweiskette beginnt bei der Anforderung. Ist sie unpräzise, hilft keine spätere Werkzeugkette. Für den KI-Einsatz gilt das doppelt: Ein Agent füllt Lücken plausibel auf – und plausibel ist nicht dasselbe wie vereinbart.

Praktische Mindestanforderungen:

• Eindeutige Kennung je Anforderung, stabil über den gesamten Lebenszyklus.
• Prüfbare Formulierung. „Das System muss performant sein“ ist keine Anforderung, sondern eine Absichtserklärung.
• Akzeptanzkriterien, aus denen sich Testfälle ableiten lassen – idealerweise vor der Implementierung notiert.
• Risikobezug, wo das Regelwerk risikobasiertes Vorgehen vorsieht: Was passiert im Fehlerfall, wen betrifft es, wie wird es entdeckt?
• Versionierung mit Historie – auch geänderte oder verworfene Anforderungen bleiben Teil der Geschichte.

Der wichtigste Effekt ist nicht regulatorisch, sondern praktisch: Präzise Anforderungen sind exakt der Kontext, den ein Coding Agent braucht, um brauchbare Ergebnisse zu liefern. Die Arbeit, die Regulierung erzwingt, zahlt hier direkt auf die Ergebnisqualität ein.

4. Architektur: explizit statt implizit

In regulierten Projekten muss die Struktur eines Systems beschreibbar sein – Komponenten, Schnittstellen, Datenflüsse, Rollen- und Rechtekonzept, Datenhaltung, Schutzbedarf. Diese Beschreibung existiert ohnehin; die Frage ist nur, ob sie vor der Implementierung entsteht oder danach mühsam rekonstruiert wird.

Der belastbarste Ansatz ist, die fachliche Struktur als Modell zu führen und nicht als Nebenwirkung von Code: Entitäten, Relationen, Pflichtfelder, Validierungsregeln, Rollen, Berechtigungen und Mandantenkontext explizit definiert. Ein Modell lässt sich prüfen, versionieren, vergleichen und gegen eine Anforderung stellen. Eine über zwanzig Klassen verteilte Konvention lässt sich das nicht.

Genau an dieser Stelle setzt CodamAI an: Backend-Modelle, Rollen und Validierungen bleiben explizit und im Hub visuell prüfbar, auch wenn sie über AI-Werkzeuge entstanden sind.

5. Review: dokumentierte Prüfung statt gefühlter Qualität

Reviews sind in regulierten Kontexten kein Qualitätsritual, sondern ein Nachweis. Drei Punkte entscheiden über ihre Belastbarkeit:

• Unabhängigkeit. Prüfer und Autor sind verschiedene Personen. Bei generiertem Code heißt „Autor“: die Person, die den Code beauftragt und übernommen hat.
• Nachvollziehbarer Umfang. Ein Review-Vermerk zu einem Änderungssatz mit mehreren tausend Zeilen ist im Zweifel wertlos. Kleinere, thematisch geschlossene Änderungen sind hier eine regulatorische Tugend, nicht nur eine Entwicklerpräferenz.
• Dokumentiertes Ergebnis. Was wurde geprüft, was beanstandet, was daraufhin geändert? Ein „LGTM“ beantwortet keine dieser Fragen.

Sinnvoll ist außerdem eine explizite Kennzeichnung, wenn KI wesentlich beteiligt war. Nicht als Misstrauensvotum, sondern damit Prüfumfang und Prüftiefe später bewertbar bleiben.

6. Tests: vom Anforderungsnachweis zum Regressionsschutz

In regulierten Projekten haben Tests zwei getrennte Aufgaben, die häufig vermischt werden. Die erste: nachweisen, dass eine Anforderung erfüllt ist. Die zweite: verhindern, dass eine spätere Änderung sie wieder bricht. Für den Nachweis zählt die Verknüpfung zur Anforderung, für den Schutz die Ausführung bei jeder Änderung.

Daraus folgen drei Regeln, die sich in der Praxis bewährt haben:

1. Jeder Testfall trägt die Kennung der Anforderung, die er belegt.
2. Testfälle werden aus der Anforderung abgeleitet – nicht aus dem Implementierungsstand und schon gar nicht aus demselben Prompt.
3. Testergebnisse werden versioniert aufbewahrt und dem geprüften Stand zugeordnet, nicht nur in der Pipeline-Oberfläche angezeigt.

Der letzte Punkt wird oft übersehen: Ein grüner Build ohne aufbewahrtes Protokoll ist ein Zustand, kein Nachweis.

7. Traceability: die Kette muss halten

Traceability bedeutet, dass sich der Weg von der Anforderung bis zum ausgelieferten Stand in beide Richtungen verfolgen lässt. Die Kette sieht im Kern immer gleich aus:

Damit die Kette hält, braucht es stabile Kennungen und automatische Verknüpfung. Ein pragmatisches Muster: Die Anforderungskennung wandert vom Ticket in den Branch-Namen, von dort in den Commit-Trailer, in den Testfall und schließlich in die Release Notes. Was maschinell verknüpft wird, muss später niemand aus dem Gedächtnis rekonstruieren. Die konkrete Umsetzung – Kennungen, Commit-Trailer, Testannotationen und eine generierte Matrix – zeigt der Deep Dive Traceability: Requirement bis Release.

8. Change Control: Änderungen als bewertete Ereignisse

Change Control ist kein Genehmigungshindernis, sondern die Zusicherung, dass Änderungen bewertet werden, bevor sie wirksam werden. Vier Fragen genügen meistens:

• Was ändert sich fachlich – und welche Anforderung ist betroffen?
• Welches Risiko entsteht daraus, und welche Prüftiefe folgt daraus?
• Welche Nachweise müssen erneuert werden (Tests, Dokumentation, gegebenenfalls Validierungsartefakte)?
• Wer gibt frei, und wann wird es wirksam?

Mit KI verschiebt sich hier vor allem die Frequenz. Wenn Änderungen leichter entstehen, muss die Bewertung schlank und automatisierbar sein – sonst wird sie umgangen. Ein risikobasiertes Vorgehen mit klar definierten Kategorien („dokumentationsrelevant“, „validierungsrelevant“, „nur intern“) ist deutlich belastbarer als ein Gremium, das jede Änderung gleich behandelt.

9. Release Evidence: Nachweise entstehen unterwegs

Der teuerste Fehler in regulierten Projekten ist, Nachweise am Projektende zusammenzusuchen. Zu diesem Zeitpunkt sind Beteiligte gewechselt, Werkzeuge aktualisiert, Zwischenstände überschrieben. Evidence by Design bedeutet, dass jedes Release die zugehörigen Belege bereits mitbringt:

• welcher Stand der Projektdefinition gebaut wurde (Version, Prüfsumme),
• welche Anforderungen im Release enthalten sind,
• welche Tests mit welchem Ergebnis gelaufen sind,
• welche Reviews und Freigaben vorliegen,
• welche Abhängigkeiten enthalten sind (SBOM),
• wohin, wann und von wem ausgeliefert wurde.

Technisch ist das keine große Aufgabe – es ist eine Frage der Pipeline, nicht der Disziplin. Genau deshalb gehört Nachweisführung in die Automatisierung: Was die Pipeline erzeugt, kann niemand vergessen.

10. Organisatorische Verantwortung bleibt

Kein Werkzeug und keine Plattform übernimmt die regulatorische Verantwortung. Was extern nicht delegierbar ist:

• die Festlegung des Verwendungszwecks und der daraus folgenden Anforderungen,
• die Risikobewertung,
• die Validierungsplanung und deren Freigabe,
• die Definition von Rollen und Verantwortlichkeiten,
• die Freigabeentscheidung für den produktiven Einsatz,
• der Betrieb der zugehörigen Prozesse (Schulung, Abweichungen, CAPA, Audits).

Was eine Plattform leisten kann, ist etwas anderes und trotzdem viel: technische Voraussetzungen schaffen, damit diese Prozesse belegbar durchführbar sind – explizite Modelle, Historie, Rollen und Rechte, reproduzierbare Builds, auswertbare Protokolle. Die Unterscheidung ist wichtig genug, um sie deutlich zu sagen: CodamAI unterstützt validierungsorientierte Entwicklung. CodamAI erzeugt keine automatisch validierte oder automatisch konforme Software.

Typische Fehler

• Regulierung als Werkzeugfrage behandeln. Ein Traceability-Werkzeug erzeugt keine Traceability, wenn niemand die Kennungen pflegt.
• KI verbieten statt regeln. Der Einsatz verschwindet dadurch nicht aus dem Projekt, nur aus der Dokumentation.
• Nachweise am Ende erzeugen. Kostet ein Vielfaches und ist inhaltlich schwächer.
• Alles gleich streng behandeln. Ohne Risikoabstufung wird der Prozess entweder unbezahlbar oder er wird umgangen.
• Compliance-Aussagen von Anbietern ungeprüft übernehmen. Zulässig ist die Aussage, dass ein Produkt bestimmte Anforderungen unterstützt – nicht, dass es sie automatisch erfüllt.

Checkliste: KI in regulierten Projekten

Fazit

Regulierte Entwicklung und KI-Geschwindigkeit schließen sich nicht aus. Sie vertragen sich aber nur, wenn Nachvollziehbarkeit nicht als nachgelagerte Dokumentationsaufgabe verstanden wird, sondern als Eigenschaft des Prozesses: explizite Anforderungen, explizite Modelle, dokumentierte Prüfungen, reproduzierbare Builds, Nachweise, die unterwegs entstehen.

Wer diese Basis hat, kann KI aggressiv einsetzen und trotzdem jederzeit Auskunft geben. Wer sie nicht hat, verliert genau die Zeit wieder, die er vorne gewonnen hat – nur später und unter Druck.