KI-gestützte Softwareentwicklung im GxP-Umfeld

Dieser Artikel zeigt anhand eines konkreten Beispiels — der Entwicklung von Data Products im GxP-Umfeld — wie KI-gestützte Softwareentwicklung mit regulatorischen Anforderungen vereinbar ist. Die beschriebenen Prinzipien und Mechanismen gelten generell für jede Art von Softwareentwicklung in regulierten Umgebungen.

Die Revolution ist da — aber darf sie bei Ihnen rein?

Ein KI-Agent analysiert ein Ticket, erstellt einen Feature Branch, implementiert die Änderung, schreibt Tests und öffnet einen Merge Request — vollautomatisch, in Minuten.

Für Entwicklungsteams in der Pharma-, Medizintechnik- und Life-Sciences-Branche klingt das nach einem Traum. Und nach einem Albtraum.

Denn im GxP-Umfeld gilt: Jede Softwareänderung muss nachvollziehbar sein. Jede Entscheidung braucht einen menschlichen Verantwortlichen. Jeder Schritt muss auditierbar sein. Wie passt das zusammen mit einem Werkzeug, das Code generiert, ohne zu erklären warum?

Die Antwort ist nicht, KI zu verbieten. Die Antwort ist Struktur.

Grundlagen: Was ist ein Code-Repository?

Ein Code-Repository ist ein versioniertes Archiv für Softwarecode — vergleichbar mit einem Dokumentenmanagementsystem, das jede Änderung mit Zeitstempel, Autor und Begründung speichert. Nichts geht verloren, jede Version ist wiederherstellbar.

Innerhalb eines Repositorys arbeiten Entwickler auf Branches (Entwicklungszweigen) — isolierten Arbeitskopien, in denen Änderungen entwickelt und getestet werden, ohne den stabilen Hauptzweig zu beeinflussen. Eine fertige Änderung wird über einen Merge Request (Zusammenführungsanfrage) zur Prüfung eingereicht. Erst nach Freigabe durch mindestens eine weitere Person wird sie in den Hauptzweig übernommen.

Jede gespeicherte Änderung heisst Commit — sie enthält den geänderten Code, den Autor, den Zeitstempel und eine Beschreibung. Diese lückenlose Historie ist im GxP-Umfeld der eingebaute Audit Trail.

Was KI heute in der Softwareentwicklung kann

• Autonome Merge Requests: Ein KI-Agent liest ein Ticket, implementiert die Änderung, schreibt Unit Tests und öffnet einen Merge Request — ohne menschliches Zutun bis zu diesem Punkt.
• AI Code Review: Jede Codeänderung wird automatisch auf Fehler, Sicherheitslücken und Stilkonformität geprüft — bevor ein Mensch sie sieht.
• Automatische Versionierung: Semantic Release generiert Versionsnummern und Changelogs direkt aus standardisierten Commit Messages.
• Data Contract Synchronisation: Fachliche Anforderungen werden als Code versioniert und automatisch zwischen Repository und Plattform synchronisiert.

Das Tempo steigt. Die Frage ist: Hält Ihre Qualitätssicherung mit?

Die spezifischen Risiken im regulierten Umfeld

GxP-Regularien — 21 CFR Part 11, EU GMP Annex 11, GAMP 5 — verlangen Nachvollziehbarkeit, Prüfbarkeit und benannte Verantwortliche. LLMs bringen fünf Herausforderungen mit.

1. Halluzinationen

LLMs erzeugen Ausgaben, die plausibel klingen, aber faktisch falsch sind: syntaktisch korrekter Code, der logisch falsch ist. Tests, die bestehen, aber nichts prüfen.

Konsequenz: KI-generierte Ausgaben sind immer ein erster Entwurf. Niemals das Endergebnis.

2. Datenschutz und IP-Schutz

Wenn proprietärer Code oder interne Systemarchitektur in ein öffentliches LLM eingegeben werden, verlieren Sie die Kontrolle über diese Daten.

Konsequenz: Öffentliche KI-Tools nur mit öffentlichen Informationen. Für alles andere: interne, freigegebene Umgebungen.

3. Fehlende Erklärbarkeit

Im Audit reicht «die KI hat das so gemacht» nicht als Begründung. Jede Architekturentscheidung braucht einen Menschen, der sie versteht und vertreten kann.

Konsequenz: Der Mensch dokumentiert seine Prüfung und Freigabe — nicht die KI.

4. Sicherheit

Unautorisierte Browser-Extensions und Apps, die Zugriff auf Entwicklungstools versprechen, sind ein reales Risiko.

Konsequenz: Nur freigegebene und geprüfte Tools. Keine Ausnahmen.

5. Verantwortlichkeit

Die Regularien verlangen eine benannte Person für jede Änderung. Die KI ist ein Werkzeug — die Verantwortung bleibt beim Menschen.

Das Konzept: Qualitätssicherung durch Struktur

Wir bei Advans IT Solutions haben dieses Konzept in der Praxis entwickelt und implementiert — in Umgebungen, in denen Compliance keine Option ist, sondern Voraussetzung. Es basiert auf vier Säulen.

Säule 1: Klare Rollenverteilung — Human in the Loop

Jede Änderung hat einen menschlichen Verantwortlichen. Keine Ausnahme.

KI-Tools sind Hilfsmittel. Sie beschleunigen, sie prüfen, sie schlagen vor. Aber sie entscheiden nicht, und sie tragen keine Verantwortung. Der Entwickler ist verantwortlich für jeden Commit — unabhängig davon, ob der Code von ihm selbst, von einem Kollegen oder von einer KI stammt. Der Business Analyst ist verantwortlich für die fachliche Korrektheit der Anforderungen und des Data Contracts.

Der «Human in the Loop» ist kein optionaler Schritt — er ist die Grundvoraussetzung für GxP-Compliance. Kein automatisiertes System ersetzt das menschliche Urteil. Es ergänzt es.

Innerhalb des Data Product Teams:

Ausserhalb des Teams:

Option A: CODEOWNERS
Eine CODEOWNERS-Datei im Repository definiert, wer Änderungen an bestimmten Dateipfaden genehmigen muss. Das Versionsverwaltungssystem weist den richtigen Reviewer automatisch zu. CODEOWNERS dokumentiert zudem explizit, wer für welchen Teil des Codes verantwortlich ist — ein eigenständiger Wert im GxP-Umfeld.

/contracts/     @product-owner
/src/           @developer-team
/.github/       @technology-lead
/governance/    @product-owner @technology-lead

Option B: Merge-Request-Vorlage mit manueller Reviewer-Zuweisung
Der Entwickler weist Reviewer manuell zu — gesteuert durch die Merge-Request-Vorlage, die explizit vorschreibt, welche Rolle zugewiesen werden muss.

Wir empfehlen an dieser Stelle, beide Ansätze zu kombinieren. CODEOWNERS als automatisches Sicherheitsnetz und Dokumentation der Verantwortlichkeiten. Merge-Request-Vorlage für die strukturierte Checkliste.

Säule 2: Dokumentierter Entwicklungsprozess im Repository

Ein Qualitätskonzept, das nur in einem separaten Wiki beschrieben ist, wird im Alltag nicht eingehalten. Die Lösung: Der gesamte Entwicklungsprozess wird direkt im Repository in der Haupt-README dokumentiert — verbindlich, versioniert, auditierbar.

1. Prozess und Code leben am selben Ort. Der Entwickler sieht sofort, was als nächstes zu tun ist.
2. Prozessänderungen durchlaufen denselben Review-Prozess wie Code. Niemand kann den Prozess still und heimlich anpassen.
3. Der Prozess ist auditierbar. Die Git-Historie zeigt, wer wann welche Prozessänderung vorgenommen hat.

Säule 3: Automatisierte Qualitätssicherung

Alles, was automatisiert geprüft werden kann, wird automatisiert geprüft. KI-generierter Code durchläuft dieselben Prüfungen wie menschlich geschriebener Code.

Pre-Commit Hooks — lokal, vor jedem Commit:

Pre-Commit Hooks sind Skripte, die automatisch vor jedem Commit ausgeführt werden. Sie verhindern, dass fehlerhafte Änderungen überhaupt ins Repository gelangen. Implementiert werden sie mit Husky (JavaScript/TypeScript) oder dem pre-commit Framework (Python). Die Konfiguration liegt als Datei im Repository — selbst versioniert und reviewed.

commitlint prüft, ob die Commit Message dem Conventional-Commits-Standard entspricht (fix:, feat:, chore: etc.). Ohne korrektes Format wird der Commit lokal abgelehnt. Zusätzlich läuft commitlint in der CI/CD-Pipeline — damit werden auch Commits abgefangen, die mit --no-verify ohne Hook gemacht wurden.

Die Secret Detection ist im KI-Kontext besonders relevant: Wenn ein LLM Code generiert, der versehentlich API-Keys oder Tokens enthält, wird der Commit automatisch blockiert. Datenschutz by Design, nicht by Hoffnung.

Merge Request Settings — serverseitig, vor jedem Merge:

GitLab Duo als zweite KI-Prüfschicht:
GitLab Duo analysiert automatisch jeden Merge Request auf semantische und logische Fehler — als zusätzliche Schicht vor dem menschlichen Review. Es erkennt falsche Logik, fehlende Fehlerbehandlung, inkonsistente Datenverarbeitung. Das entlastet den menschlichen Reviewer — er konzentriert sich auf fachliche Korrektheit und regulatorische Konformität. GitLab Duo ist ein Hilfsmittel. Es ersetzt das menschliche Urteil nicht.

CI/CD Pipelines:
Jede Änderung durchläuft spezialisierte Pipelines: Datenmodell-Tests, Governance-Checks, Dokumentationsgenerierung, Verifikationstests. Die Pipeline-Matrix definiert exakt, welche Pipeline bei welcher Änderung läuft.

Bei Data Products kommt ein zusätzlicher Pflichtschritt hinzu: datacontract-cli test validiert automatisch, ob die Implementierung dem definierten Data Contract entspricht — Schema, Datenqualität und SLAs werden gegen die tatsächlichen Daten geprüft. Ein Data Product, das seinen eigenen Contract nicht erfüllt, kann nicht gemergt werden.

datacontract-cli ist ein Open-Source-Kommandozeilenwerkzeug des Data Contract Specification Projekts. Es liest den Data Contract (eine YAML-Datei im Repository) und führt automatisierte Tests gegen die tatsächliche Datenquelle aus. Installation: pip install datacontract-cli. Der Befehl datacontract-cli test datacontract.yaml wird als Pipeline-Schritt konfiguriert.

Semantic Release — automatische Versionierung als Qualitätsmechanismus:
Semantic Release ist ein Open-Source-Tool, das Versionsnummern, Changelogs und Releases automatisch aus standardisierten Commit Messages generiert. fix: erzeugt eine Patch-Version (1.0.1), feat: eine Minor-Version (1.1.0), feat!: eine Major-Version (2.0.0). Es läuft als letzter Schritt in der CI/CD-Pipeline. Konfiguration in einer .releaserc-Datei im Repository.

Das Zusammenspiel der drei Tools ist entscheidend: commitlint erzwingt das Format, Conventional Commits definiert den Standard, Semantic Release wertet ihn aus. Alle drei müssen konfiguriert sein — keines funktioniert sinnvoll ohne die anderen.

Säule 4: Lückenlose Nachvollziehbarkeit

Merge-Request-Vorlage mit Rollenlabels:

* [ ] [BA]         Data Contract definiert, reviewed und freigegeben
* [ ] [BA]         Testdaten und Akzeptanzkriterien geprüft
* [ ] [Entwickler] Lokale Tests bestanden (inkl. datacontract-cli test)
* [ ] [Entwickler] Code reviewed und verstanden — unabhängig von der Entstehung
* [ ] [TL / DL]    Technologie- und Datenmodell-Standards geprüft

Der Entwickler bestätigt, dass er den Code versteht und für ihn einsteht — unabhängig davon, ob er ihn selbst geschrieben, von einem Kollegen übernommen oder von einer KI generiert hat. Es gibt keine separate Kategorie «KI-generierter Code» — es gibt nur Code, für den ein Mensch die Verantwortung trägt.

Draft/Ready-Workflow:
Der Entwickler erstellt den Merge Request als Draft nach dem ersten Push. Erst wenn alle Checkboxen erledigt und alle Pipelines grün sind, wird er auf Ready gesetzt und Reviewer zugewiesen. Kein Reviewer wird mit halbfertiger Arbeit konfrontiert.

Source-of-Truth-Prinzip:
Jede Information existiert genau einmal. Dokumentation wird aus den Quelldateien generiert — nicht manuell gepflegt. Wenn sich der Data Contract ändert, aktualisiert sich die Dokumentation automatisch. Keine veralteten PDFs. Keine Inkonsistenzen.

Governance im regulierten Umfeld

Für GxP-relevante Systeme kommen zusätzliche Governance-Artefakte hinzu — alle als Code im Repository verwaltet, alle demselben Review-Prozess unterworfen wie jede andere Codeänderung:

Nichts wird manuell auf einem Server konfiguriert. Jede Konfigurationsänderung durchläuft denselben Review-Prozess wie Code — mit Rollenzuordnung, Vier-Augen-Prinzip und Pipeline-Validierung.

Skalierung: Von einem Repository auf das gesamte Unternehmen

Plattform-Settings:
Merge-Request-Einstellungen — Vier-Augen-Prinzip, Pipeline-Pflicht, AI Code Review — werden auf Organisationsebene konfiguriert und gelten automatisch für alle Repositories. Einmal eingerichtet, kein manueller Aufwand pro Projekt.

Templating — Qualität von Anfang an:
Jedes neue Repository wird aus einer Vorlage erstellt, die alle Qualitätsartefakte bereits enthält: Merge-Request-Vorlage, CODEOWNERS, README mit dokumentiertem Entwicklungsprozess, CI/CD-Konfiguration, Pre-Commit Hooks.

In unserem Referenzprojekt wird dafür Copier eingesetzt — ein Open-Source-Template-Tool, das neue Repositories aus einer zentralen Vorlage generiert. Der Entwickler führt copier copy <template-url> <zielverzeichnis> aus und erhält ein vollständig konfiguriertes Repository. Copier unterstützt zudem Updates: Wenn die zentrale Vorlage weiterentwickelt wird, können bestehende Repositories mit copier update auf den neuesten Stand gebracht werden. Qualität ist eingebaut — nicht nachträglich hinzugefügt.

Für bestehende Repositories kann der Rollout über die Plattform-API automatisiert werden: Ein Script erstellt pro Repository einen Branch, fügt die fehlenden Artefakte hinzu und öffnet einen Merge Request zur Prüfung.

Fazit: KI ist nicht das Risiko — fehlende Struktur ist es

KI-gestützte Entwicklung im GxP-Umfeld ist kein Widerspruch. Sie erfordert einen Prozess, der die bekannten Risiken von Anfang an adressiert:

• Human in the Loop — Entwickler und Business Analyst tragen die volle Verantwortung. KI ist Hilfsmittel, kein Entscheidungsträger.
• Dokumentierter Entwicklungsprozess — im Repository, versioniert, auditierbar. Prozess und Code leben am selben Ort.
• Klare Verantwortlichkeiten — CODEOWNERS und Merge-Request-Vorlage verankern, wer für welchen Code verantwortlich ist — technisch erzwungen, nicht nur dokumentiert.
• Automatisierte Prüfungen — Secret Detection, Linting, datacontract-cli test, GitLab Duo und Pipeline-Checks fangen Fehler ab, bevor ein Mensch sie sehen muss.
• Rollenbasierte Checklisten — eingebaute Compliance statt nachträglicher Dokumentation.
• Lückenlose Nachvollziehbarkeit — Commit-Historie, Merge-Request-Checklisten und generierte Dokumentation als eingebauter Audit Trail.
• Templating — Qualität von Anfang an in jedem neuen Repository eingebaut.
• Kontrollierte Umgebungen — Datenschutz und IP-Schutz durch freigegebene, interne Tools.

Das Ergebnis: Schnellere Entwicklung, höhere Qualität, volle Compliance.

Glossar

Verwandte Themen: Was ist Computer System Validation? | GxP validierte ETL Verarbeitung | Quality Risk Management Approach | CSV Dienstleistungen | Life Science IT