Pflichten aus der EU-KI-Verordnung, die in die Entwicklungsphase fallen, werden schon lange vor der Erstellung juristischer Gutachten zu konkreten technischen Aufgaben. Der Kurs konzentriert sich auf die Pflichten von Anbietern – also jene Verpflichtungen, die das Team treffen, welches ein KI-System bereitstellt –, da Ingenieure und Data Scientists den Großteil der Nachweise erbringen, auf denen diese Pflichten beruhen. Teams übersehen dies oft, weil sich die Arbeit wie die reine Entwicklung von Funktionen anfühlt, während die spätere Zulassung oder Ablehnung davon abhängt, was dokumentiert und getestet wurde und ob über verschiedene Versionen hinweg Konsistenz gewahrt blieb. Häufige Fehler sind nicht auf böse Absichten zurückzuführen. Sie entstehen vielmehr durch eine Diskrepanz zwischen dem, was das System tatsächlich leistet, und dem, was das Team nachweislich belegen kann.
Ein Anbieter kann die Freigabe eines Systems nur dann rechtfertigen, wenn dessen Entwicklung von Anfang an klar strukturiert ist. Diese Struktur beginnt bei der Frage, welches System entwickelt wird, welchem Zweck es dient und was es in der realen Einsatzumgebung leisten kann – oder eben nicht. Zudem umfasst sie die verwendeten Eingangsdaten, die implementierten Kontrollmechanismen, die vorhandenen Protokolle sowie die Handlungsmöglichkeiten für Menschen, falls die Ausgabe fehlerhaft erscheint. Es ist entscheidend, diese Aspekte im Zusammenhang zu betrachten, da fehlende Elemente meist erst entdeckt werden, wenn das Team das System bereits trainiert, integriert und bereitgestellt hat. Die nachstehende Übersicht veranschaulicht das gesamte Themenfeld, bevor die einzelnen Bereiche im Detail behandelt werden.
In diesem Kurs verstehen wir unter einem KI-System nicht bloß eine Modelldatei oder einen ausgeklügelten Prompt. Es handelt sich um das gesamte Systemgefüge: Es verarbeitet Eingaben aus einem Arbeitsprozess, liefert Ergebnisse, auf die sich Menschen verlassen, und verhält sich auf eine Weise, die durch Code, Daten, Konfiguration und die umgebende Benutzeroberfläche (UI) geprägt ist. Deshalb kann schon eine kleine Änderung in der Pipeline die Auswirkungen des Systems in der Praxis verändern – selbst wenn die Modellgewichte unverändert bleiben.
Ein Team mag glauben, es gehe „nur um die Integration eines Modells“, doch der regulierte Gegenstand ist das fertige Gesamtsystem, sobald es Entscheidungen, Empfehlungen oder generierte Inhalte in einen Arbeitsablauf einbindet. Trainingsauftrag, Feature Store, Retrieval-Index, Leitplanken (Guardrails), Überwachungsregeln und UI-Texte bestimmen gemeinsam, was der Nutzer sieht und welche Schritte als Nächstes möglich sind. Sind diese Komponenten nicht fest an eine bestimmte Version und einen Zweck gebunden, stimmen spätere Tests und Dokumentationen nicht mit dem tatsächlich ausgelieferten System überein.
Ingenieure und Data Scientists treffen in der Regel die Entscheidungen, die den Verwendungszweck, die Eingaben und die Grenzen des Systems festlegen; diese Entscheidungen fallen im Rahmen von Tickets, Datensätzen, Evaluierungsplänen und Code-Reviews. Rechts- und Compliance-Abteilungen können zwar das Gesetz auslegen, aber sie können nicht rekonstruieren, welche Daten das Modell während des Trainings gesehen hat oder welche Aktionen die Benutzeroberfläche zum Zeitpunkt der Entscheidung zuließ. Produktverantwortliche können Ziele vorgeben, aber sie können keine fehlenden Protokolle (Logs) ersetzen oder ein nicht protokolliertes Experiment wiederholen.
Auch die Übergabe an die für den Rollout (Deployment) zuständigen Teams beginnt bereits in der Entwicklungsphase. Diese Teams benötigen klare Anweisungen, eine nutzerfreundliche Transparenz der Benutzeroberfläche sowie Kontrollmechanismen, die auch unter Zeitdruck funktionieren; denn ein PDF mit Richtlinien kann kein System ausgleichen, das seine eigene Unsicherheit verschleiert oder Eingriffe verhindert. Betrachten Entwickler diese Aspekte lediglich als „später zu erledigenden Papierkram“, müssen sie am Ende meist die Benutzeroberfläche nachbessern und die Dokumentation an die Realität anpassen – ein Prozess, der mehr Zeit in Anspruch nimmt als eine durchdachte Planung von Anfang an.
Bevor wir fortfahren, ist es hilfreich zu prüfen, welche Fehlerarten Ihnen bereits bekannt sind.