Ein Forschungs- und Entwicklungsprojekt wird nicht wie ein Integrations- oder Implementierungsprojekt geleitet. Die technische Unsicherheit ist strukturell, nicht zufällig. Jede Designentscheidung bindet Ressourcen an Annahmen, die im Verlauf invalidiert werden können. Um ein F&E-Projekt erfolgreich zu gestalten, ist daher ein methodologischer Rahmen erforderlich, der dieser Realität gerecht wird, nicht eine Übertragung klassischer Projektmanagementmethoden.
KI-Governance und AI Act: die regulatorische Anforderung, die den F&E-Rahmen neu definiert
Ein F&E-Projekt, das KI-Modelle einsetzt, fällt nicht mehr ausschließlich in den Bereich der technischen Leitung. Seit dem 2. Februar 2025 verlangt der AI Act von den Organisationen, die KI-Systeme entwickeln oder implementieren, Governance-Verpflichtungen. Konkret muss der ursprüngliche Rahmen des Projekts die Identifizierung der Rolle des Unternehmens (Anbieter oder Implementierer), die Schulung der beteiligten Teams und die Nachverfolgbarkeit der Anwendungen beinhalten.
Wenn das Projekt ein als hochriskant eingestuftes System zum Ziel hat, muss die Konformität bereits in der Entwurfsphase berücksichtigt werden. Die Anforderungen beziehen sich auf die Qualität der Datensätze, die technische Dokumentation, die menschliche Aufsicht und die Sicherheit. Wir empfehlen, diese Anforderungen im ursprünglichen F&E-Brief zu formalisierten und nicht am Ende des Zyklus, wenn die technischen Entscheidungen bereits festgelegt sind.
Diese Logik der Compliance by Design, die auf KI-Projekte angewendet wird, verändert auch die Auswahl der Modelle und die Bedingungen für die Wiederverwendung der während der explorativen Phase erzeugten Daten. Parallel dazu beschreibt die Präsentation von L’Essentiel Pro die Meilensteine, die gesetzt werden müssen, um ein F&E-Projekt bereits in den ersten Phasen zu strukturieren.
Hypothesen vor dem experimentellen Protokoll strukturieren
Wir beobachten regelmäßig Teams, die mit dem Aufbau eines Protokolls beginnen, ohne ihre Hypothesen stabilisiert zu haben. Das Ergebnis: kostspielige Iterationen, unbrauchbare Daten und Schwierigkeiten, die Kohärenz der Arbeiten im Falle einer Steuerprüfung (CIR) nachzuweisen.
Die einzuhaltende Reihenfolge ist strikt. Zuerst validiert oder invalidiert die Literaturrecherche die Existenz früherer Arbeiten. Dann wird das Problem festgelegt und die Hypothesen in testbarer Form formuliert. Erst zu diesem Zeitpunkt nimmt das experimentelle Design Gestalt an.
Was die CIR-Dokumentation tatsächlich erwartet
Jedes Projekt muss mit einer dokumentierten wissenschaftlichen oder technischen Unsicherheit verbunden sein. Die Verwaltung sucht keinen nachträglich verfassten zusammenfassenden Bericht. Sie überprüft die Existenz zeitgenössischer Nachweise: datierte Hypothesen, Testergebnisse, Pivot-Entscheidungen, beteiligte Personen. Eine granulare Zeitverfolgung, die mit jeder Forschungsaufgabe verbunden ist, stärkt erheblich die Solidität der Dokumentation.
Die F&E-Dokumentation wird nicht am Ende des Jahres an einen externen Redakteur delegiert. Sie entsteht im Verlauf des Projekts durch die Forscher und Ingenieure selbst. Wir empfehlen, bereits beim Kick-off einen Dokumentationsverantwortlichen zu benennen, der direkten Zugang zu den Laborprotokollen oder Code-Deposits hat.
F&E-Projektmethodologie: Wahl zwischen iterativ und Phase-Gate
Die methodologische Wahl hängt vom Grad der Unsicherheit und der Größe des Teams ab. Zwei Ansätze dominieren das F&E-Projektmanagement, und sie sind nicht austauschbar.
- Iterativer Ansatz (Agil/spiral): geeignet für Projekte mit vielen technischen Unbekannten. Jede Iteration produziert ein Lernen, das das Ziel der nächsten definiert. Kleine, co-lokalisierte Teams profitieren am meisten davon.
- Phase-Gate-Ansatz (Stage-Gate): relevant, wenn das Projekt einem identifizierbaren linearen Fortschritt folgt, mit Validierungspunkten vor jedem zusätzlichen Ressourceneinsatz. Verteilte Teams oder Projekte, die strengen regulatorischen Anforderungen unterliegen, finden darin einen klareren Rahmen.
- Hybridisierung: Einige Projekte kombinieren beide Ansätze, mit explorativen Phasen im iterativen Modus und formellen Gate-Übergängen vor den Phasen der Industrialisierung oder Konformität.
Die häufige Falle besteht darin, eine Agile-Methode auf ein Projekt anzuwenden, dessen regulatorische Meilensteine sequenzielle Ergebnisse erfordern. Die Methodologie muss der Natur des Projekts dienen, nicht umgekehrt.
Nachverfolgbarkeit der F&E-Arbeiten und Antizipation der Steuerprüfung
Die Vorbereitung eines CIR-Dossiers wird zunehmend granularer. Die geforderten Nachweise beschränken sich nicht mehr auf eine allgemeine Beschreibung der Arbeiten. Die Verwaltung verlangt, dass jedes Projekt mit einem dokumentierten Stand der Technik, einem nachverfolgbaren experimentellen Ansatz und Ergebnissen, einschließlich negativer, verknüpft werden kann.
Die kontinuierlich zu produzierenden Elemente
- Datierte Hypothesenblätter mit im Voraus definierten Validierungs- oder Invalidierungskriterien
- Zeitstempel-Testprotokolle (Laborprotokolle, Git-Commits, Berichte über automatisierte Tests)
- Zeiterfassungen pro Mitarbeiter und Aufgabe, idealerweise mit wöchentlicher Granularität
- Entscheidungsprotokolle während der Meilensteine, die die Pivots und deren technische Begründungen erwähnen
Ein gut nachverfolgtes Projekt verteidigt sich selbst bei einer Prüfung. Teams, die kontinuierlich dokumentieren, verbringen weniger Zeit mit der Rekonstruktion ihrer Dokumentation und reduzieren erheblich das Risiko einer Nachprüfung.
Der häufigste Fehler besteht darin, die CIR-Dokumentation als eine administrative Aufgabe zu betrachten, die vom Projekt getrennt ist. In Wirklichkeit produziert ein korrekt geführtes F&E-Projekt von selbst die meisten erforderlichen Nachweise. Projektmanagement und steuerliche Konformität konvergieren, wenn die Forschungsziele, Testergebnisse und Entscheidungen bereits bei ihrem Eintreten formalisiert werden.
Der letzte Punkt, den man nicht vernachlässigen sollte, betrifft die Aufbewahrung der Rohdaten. Die Quelldateien, Datensätze und Zwischenversionen müssen mit einem klaren Versionskontrollsystem archiviert werden. Im Falle einer Prüfung mehrere Jahre nach der Erklärung haben nur zeitgenössische und nicht rekonstruierte Nachweise Beweiskraft.
