Dieser Kurs behandelt Entscheidungen zur Entwicklung verantwortungsvoller KI für Ingenieure, die KI-Systeme bereitstellen; Grundlage hierfür ist der EU AI Act (Verordnung (EU) 2024/1689). Der Schwerpunkt liegt auf der Arbeit des Anbieters – also auf jenen Entscheidungen, die ein Modell oder eine Pipeline in ein vertretbares Produkt verwandeln. „Verantwortungsvolle KI“ bedeutet in diesem Kurs: Entwicklung, Dokumentation, Governance und Bereitstellung so zu gestalten, dass die Grenzen des Systems klar und sein Verhalten kontrollierbar sind. Teams machen oft den Fehler, die Pflichten des Anbieters als bloßen Papierkram zu betrachten, der erst bei der Markteinführung erledigt wird. Zwar wirkt die Arbeit wie eine nachträgliche Dokumentation, doch die Weichen werden bereits viel früher durch Entscheidungen zu Design und Daten gestellt. Deshalb kehrt der Kurs immer wieder zu konkreten, benennbaren und versionierbaren Artefakten zurück. Wir erstellen zunächst den Gesamtüberblick, bevor wir ins Detail gehen, damit Sie jede Pflicht an der richtigen Stelle einordnen können.
Anbieter-Teams erledigen einen Großteil dieser Arbeit bereits, allerdings oft an verschiedenen Stellen: in Architektur-Dokumenten, Model Cards, Evaluierungs-Notebooks, Release-Checklisten und Monitoring-Dashboards. Das Problem dabei ist, dass diese Artefakte nicht immer auf einen einheitlichen Verwendungszweck abgestimmt sind, wodurch Lücken zwischen den Teams entstehen. Sobald solche Lücken bestehen, können nachgelagerte Anwender (Deployer) das System nicht sicher betreiben, da sie nicht wissen, wofür es entwickelt wurde oder wie es sich unter Belastung verhält. Der Kurs strukturiert die Anbieterpflichten als Prozessmodell für Entwicklung und Bereitstellung mit drei Phasen: Design und Daten, Release-Meilensteine und Nachweise sowie Marktüberwachung und Umgang mit Vorfällen. Genau diese Struktur macht die späteren Lektionen praxisnah und umsetzbar. Hier ist dieses Modell im Überblick:
In diesem Kurs wird ein KI-System als maschinengestütztes System definiert, das mit unterschiedlichem Grad an Autonomie arbeitet und aus den empfangenen Eingaben ableitet, wie Ausgaben – etwa Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen – zu generieren sind. Ein Anbieter ist die Person oder Organisation, die ein KI-System entwickelt (oder entwickeln lässt) und es unter eigenem Namen oder eigener Marke auf den Markt bringt oder in Betrieb nimmt – sei es entgeltlich oder unentgeltlich. Diese Definition ist für Ingenieure von Bedeutung, da man auch ohne das Training von Basisgewichten zum Anbieter werden kann – allein dadurch, dass man für das ausgelieferte System und dessen Zweckbestimmung verantwortlich ist. Diese Schwelle wird überschritten, sobald Nutzer das System als das eigentliche Produkt wahrnehmen und das eigene Team dessen Funktionsweise steuert.
Die Verwendung eines Modells eines Drittanbieters macht diesen nicht automatisch zum Anbieter für das gesamte von Ihnen ausgelieferte Produkt. Ihr Team entscheidet weiterhin darüber, welche Daten einfließen, was die Ausgaben bedeuten und welche Schutzmechanismen (Guardrails) in der Schnittstelle implementiert sind. Diese Entscheidungen legen in der Praxis die Zweckbestimmung fest, selbst wenn der Begriff im Marketing nie explizit verwendet wird. Wenn ein Partner fragt: „Wer ist hier der Anbieter?“, geht es darum, wer den Nachweis erbringen kann – nicht darum, wer die erste Zeile des Modellcodes geschrieben hat.
Ingenieure verantworten jene Aspekte der Anbieterrolle, die erst durch die technische Umsetzung (den „Build“) realisiert werden. Abteilungen für Compliance und Recht können zwar bei der Auslegung des AI Act helfen, sind jedoch nicht in der Lage, nachträglich Logging-Funktionen, Überwachungsmechanismen oder eine umfassende Evaluierungsabdeckung zu implementieren. Die ständige Herausforderung besteht darin, eine rechtliche Verpflichtung in etwas Konkretes zu übersetzen – etwa ein Element im Repository, einen Testlauf oder ein Release-Gate. Genau an diesem Punkt geraten Projekte oft aus der Spur, da der Prozess verschiedene Teams und Zeitpläne übergreift. Läuft alles gut, ist das technische Ergebnis unspektakulär und überprüfbar.
Erfolgreiche Teams gehen dabei stets nach demselben Muster vor: Sie legen die Zweckbestimmung frühzeitig fest und verknüpfen Designentscheidungen sowie Dokumentation direkt damit. Sie betrachten die Dokumentation als Spiegelbild der technischen Umsetzung – und nicht als nachträglich verfassten Bericht –, sodass sie gemeinsam mit dem System versioniert wird. Zudem unterscheiden sie zwischen Anforderungen, die vor der Markteinführung erfüllt sein müssen, und solchen, die auch nach dem Start Bestand haben müssen; denn die Auslieferung verändert den Spielraum für kostengünstige Korrekturen. Kann man einer Verpflichtung ein konkretes Artefakt zuordnen, lassen sich auch Verantwortliche und Termine festlegen.
[Quellen][/Quellen]