KI-Coding-Tools im Entwicklungsprozess nach IEC 62304

Wir legen in Ihrem Entwicklungsplan und Ihren Arbeitsanweisungen fest, wofür Sie die Werkzeuge einsetzen dürfen und wofür nicht. Außerdem dokumentieren wir Werkzeugversionen und Einstellungen. Ändern sich das Modell oder die Nutzungsbedingungen, bewerten wir das Werkzeug erneut.

Jede generierte Änderung geht mit einem benannten Reviewer ins Review und wird einer Anforderung, einer Risikobeherrschungsmaßnahme oder einem Problembericht zugeordnet. Die Verifizierung folgt der Software-Sicherheitsklasse (A, B oder C, je nach Schaden, den ein Softwarefehler verursachen könnte) und der Risikoanalyse.

Wir dokumentieren die Funktionen des Codes und sichern sein Verhalten durch Tests ab. Aus der Zweckbestimmung und der Risikoanalyse leiten wir Anforderungen ab und prüfen den Code auf deren Erfüllung. Nachträglich erstellte Dokumente kennzeichnen wir als retrospektiv. Sicherheitsrelevante Teile entwickeln wir neu, wenn sich ihre Korrektheit nicht nachweisen lässt.

Unsere Entwickler prüfen den Code Modul für Modul, überarbeiten seine Struktur und dokumentieren ihn.

Reviewer prüfen generierten Code auf kopierten Code von Drittanbietern. Komponenten von Drittanbietern und ihre Lizenzen werden in der SBOM (Software Bill of Materials, die Liste aller Softwarekomponenten im Build) festgehalten, und Komponenten, die der Definition von SOUP nach IEC 62304 entsprechen, stehen zusätzlich mit ihrer Risikobewertung in der SOUP-Liste (Software unbekannter Herkunft, also Code von Drittanbietern, der im Gerät verwendet wird).

Statische Analyse und Abhängigkeitsprüfungen bei jedem Build, Regeln für sicheres Programmieren im Review geprüft, und das Threat Model (eine strukturierte Analyse, wie das Gerät angegriffen werden könnte) wird aktualisiert, wenn generierte Änderungen die Architektur oder die Schnittstellen verändern.

Wir vereinbaren schriftlich, auf welche Repositories und Daten die Werkzeuge zugreifen dürfen. Patientendaten bleiben davon ausgeschlossen.

Claude Code, OpenAI Codex und der Agent-Modus von Cursor ändern anhand einer Aufgabenbeschreibung den Code in mehreren Dateien. Jede Änderung durchläuft dieselben Reviews und Tests wie manuell geschriebener Code. Auch für die Rückverfolgbarkeit gelten dieselben Anforderungen.

GitHub Copilot, ChatGPT und JetBrains AI Assistant schlagen direkt im Editor Code vor. Der Entwickler bleibt Autor jeder Zeile, die er übernimmt.

Offene Modelle lassen sich mit Ollama auf lokaler Hardware betreiben. So bleiben Code, Anforderungen und Testdaten in Ihrem Netzwerk.

Die KI schlägt Unit-Tests und Review-Kommentare vor. Ein Entwickler entscheidet, welche Vorschläge er übernimmt oder ablehnt. Die Entscheidung wird im Review-Protokoll dokumentiert. Die erwarteten Testergebnisse leiten wir aus den Anforderungen ab, niemals aus dem generierten Code.

KI-Tools wie GitHub Copilot Autofix schlagen Korrekturen für Befunde aus der statischen Analyse vor. Auch bei der Bewertung neuer CVEs anhand der SBOM können sie unterstützen. Jeder Korrekturvorschlag durchläuft das reguläre Review. Betrifft er eine Schwachstelle, bearbeiten wir ihn zusätzlich nach dem Schwachstellenprozess gemäß IEC 81001-5-1. Dieser umfasst Bewertung, Korrektur, Verifizierung und Release. Erst nach dem Review wird die Änderung gemergt.