Qualitätsmanagementsystem nach Art. 17 AI Act – So bauen Sie es für Ihre Hochrisiko-KI auf

Ein QMS, das niemand lebt, ist im Audit wertlos – und teuer

Stellen Sie sich vor, Sie haben Monate in Ihre technische Dokumentation, Ihr Risikomanagement und Ihre Datenqualität investiert – und die benannte Stelle stellt trotzdem fest: Es fehlt die organisatorische Klammer, die all das nachweisbar zusammenhält. Genau diese Klammer verlangt Artikel 17 des AI Act: ein dokumentiertes Qualitätsmanagementsystem (QMS). Das Qualitätsmanagementsystem im AI Act ist keine Kür, sondern eine der zentralsten Anbieterpflichten für Hochrisiko-KI – und zugleich diejenige, die am häufigsten unterschätzt wird. Dieser Artikel zeigt Ihnen, wie Sie das QMS aus Bausteinen aufbauen, die Sie größtenteils schon besitzen.

Qualitätsmanagementsystem im AI Act: Was Art. 17 verlangt

QMS als organisatorische Klammer für alle Anbieterpflichten

Der AI Act verteilt die Pflichten für Hochrisiko-KI über zahlreiche Artikel: Risikomanagement (Art. 9), Datenqualität (Art. 10), technische Dokumentation (Art. 11), Aufzeichnungspflichten (Art. 12), menschliche Aufsicht (Art. 14) und viele mehr. Das Problem: Diese Pflichten stehen nicht isoliert nebeneinander. Sie müssen systematisch, dokumentiert und reproduzierbar ineinandergreifen.

Genau das leistet das QMS nach Art. 17. Es ist die organisatorische Klammer, die festlegt, wer was wann wie tut – und wie das belegt wird. Das Gesetz verlangt ausdrücklich, dass das QMS „systematisch und ordnungsgemäß in Form schriftlicher Leitlinien, Verfahren und Anweisungen” dokumentiert wird. Ein QMS ist damit nicht ein einzelnes Dokument, sondern das Betriebssystem Ihrer AI-Act-Compliance.

Abgrenzung zu ISO 9001 und bestehenden QM-Systemen

Wenn Sie bereits nach ISO 9001 oder einem branchenspezifischen Managementsystem arbeiten, ist das ein enormer Vorteil – aber kein Freifahrtschein. ISO 9001 regelt Qualitätsmanagement generisch und prozessorientiert; Art. 17 verlangt jedoch KI-spezifische Elemente, die ISO 9001 nicht kennt: etwa das Risikomanagement nach Art. 9, das Datenmanagement nach Art. 10 oder das Meldeverfahren für schwerwiegende Vorfälle nach Art. 73.

Die Norm ISO/IEC 42001 (KI-Managementsystem) liegt inhaltlich deutlich näher, deckt aber ebenfalls nicht alle rechtlichen Detailanforderungen des Art. 17 ab. Die richtige Strategie lautet daher: integrieren statt duplizieren. Ein vorhandenes ISO-9001- oder 42001-System bildet das Gerüst; die AI-Act-spezifischen Elemente docken Sie daran an. Ein zweites, paralleles QMS ist weder gefordert noch sinnvoll.

Für wen die Pflicht gilt: Anbieter von Hochrisiko-KI

Ein häufiges Missverständnis vorweg: Die QMS-Pflicht nach Art. 17 trifft ausschließlich Anbieter von Hochrisiko-KI-Systemen – also diejenigen, die ein solches System entwickeln oder entwickeln lassen und unter eigenem Namen in Verkehr bringen. Betreiber (Deployer), die ein System lediglich einsetzen, müssen kein QMS nach Art. 17 vorhalten; sie treffen andere Pflichten.

Die Unterscheidung ist folgenreich, weil sich Rollen verschieben können – etwa wenn ein Betreiber ein System wesentlich verändert oder unter eigenem Namen anbietet. Wer genau wann als Anbieter gilt, klären wir ausführlich in unserem Beitrag zur Abgrenzung von Anbieter- und Betreiberpflichten. Prüfen Sie diese Einordnung, bevor Sie in den QMS-Aufbau investieren.

Die 13 Pflichtelemente des QMS nach Art. 17 im Überblick

Art. 17 Abs. 1 listet in den Buchstaben a bis m dreizehn Pflichtelemente auf, die Ihr QMS zwingend abdecken muss:

#	Element (Art. 17 Abs. 1)	Kern
a	Strategie zur Einhaltung der Regulierungsvorschriften	inkl. Konformitätsbewertung und Verfahren zum Management von Änderungen
b	Techniken und Verfahren für Design, Entwurfskontrolle und -verifizierung	wie Sie das System konzipieren und prüfen
c	Techniken und Verfahren für Entwicklung, Qualitätskontrolle und -sicherung	wie Sie entwickeln und die Qualität sichern
d	Untersuchungs-, Test- und Validierungsverfahren	vor, während und nach der Entwicklung
e	Technische Spezifikationen einschließlich Normen	welche Standards Sie anwenden
f	Systeme und Verfahren für das Datenmanagement	Erhebung, Analyse, Kennzeichnung, Speicherung, Filterung usw.
g	Risikomanagementsystem nach Art. 9	fortlaufend über den gesamten Lebenszyklus
h	Beobachtung nach dem Inverkehrbringen (Post-Market-Monitoring) nach Art. 72
i	Verfahren zur Meldung schwerwiegender Vorfälle nach Art. 73
j	Handhabung der Kommunikation mit Behörden, benannten Stellen, anderen Akteuren, Kunden
k	Systeme und Verfahren zur Aufzeichnung aller relevanten Dokumentation und Informationen
l	Ressourcenmanagement einschließlich Maßnahmen zur Versorgungssicherheit
m	Rechenschaftsrahmen (Verantwortlichkeiten der Leitung und des Personals)

Diese dreizehn Punkte machen deutlich: Das QMS ist kein zusätzlicher Pflichtenkatalog, sondern die Struktur, in die Ihre übrigen AI-Act-Pflichten eingehängt werden. Risikomanagement, Datenmanagement und Meldeverfahren sind hier nicht neu erfunden, sondern als Bestandteile des QMS organisiert. Element m – der Rechenschaftsrahmen – verlangt zudem explizit, dass Sie Verantwortlichkeiten der Leitungsebene definieren. Compliance wird damit zur Chefsache, nicht zur Aufgabe eines einzelnen Entwicklers.

Schritt für Schritt: So bauen Sie Ihr QMS auf

Schritt 1 – Ist-Analyse: Welche Prozesse existieren schon

Beginnen Sie nicht auf der grünen Wiese. Die meisten Organisationen erfüllen einen erheblichen Teil der dreizehn Elemente bereits – nur nicht dokumentiert oder nicht AI-Act-konform benannt. Erstellen Sie eine Gap-Analyse entlang der Buchstaben a bis m:

Welche Prozesse existieren (z. B. Test- und Validierungsverfahren, Änderungsmanagement)?
Wo sind sie dokumentiert – und wo nur „im Kopf” einzelner Personen?
Welche Elemente fehlen vollständig (häufig: Post-Market-Monitoring, Meldeverfahren, formaler Rechenschaftsrahmen)?

Ein Softwareunternehmen mit bestehendem DevOps-Prozess hat Element b, c und d oft weitgehend abgedeckt – es fehlt nur die Verknüpfung zur AI-Act-Terminologie und der Nachweis.

Schritt 2 – Verantwortlichkeiten und Rollen festlegen

Element m verlangt einen klaren Rechenschaftsrahmen. Legen Sie fest, wer für jedes der dreizehn Elemente verantwortlich ist. Bewährt hat sich eine RACI-Logik (Responsible, Accountable, Consulted, Informed). Benennen Sie mindestens:

eine verantwortliche Person auf Leitungsebene (Accountable für die Gesamt-Compliance),
Prozessverantwortliche je Element,
eine Schnittstelle zur benannten Stelle und zu Behörden (Element j).

Diese Struktur ist zugleich das Herzstück Ihrer KI-Governance. Wie Sie Rollen, Gremien und Eskalationswege systematisch aufsetzen, vertieft unser Beitrag zum KI-Governance-Framework.

Schritt 3 – Prozesse dokumentieren statt neu erfinden

Der häufigste Fehler ist der Versuch, alles neu zu bauen. Nutzen Sie stattdessen vorhandene Prozesse und übersetzen Sie sie in die geforderte Form: schriftliche Leitlinien, Verfahren und Anweisungen. Ein bestehender Freigabeprozess vor einem Release wird zum dokumentierten Verfahren nach Element d; Ihr Code-Review-Prozess deckt Teile von Element c ab.

Entscheidend ist an dieser Stelle die Frage, womit Sie all das dauerhaft und prüfungssicher erfassen – denn verstreute Word-Dateien, Wikis und E-Mails halten einem Audit selten stand. Wer Prozessbeschreibungen, Nachweise, Versionsstände und die Verknüpfung zu den einzelnen Art.-17-Elementen zentral pflegen will, nutzt dafür eine Software für die AI-Act-Dokumentation, die die QMS-Struktur und die zugehörigen Belege an einem Ort zusammenführt. So bleibt jederzeit nachvollziehbar, welches Verfahren welchen Pflichtpunkt abdeckt und wann es zuletzt aktualisiert wurde.

Schritt 4 – Verzahnung mit Risikomanagement und technischer Dokumentation

Das QMS steuert die Erstellung und Pflege Ihrer übrigen Nachweise. Das Risikomanagement nach Art. 9 ist als Element g direkter Bestandteil des QMS – wie Sie diesen fortlaufenden Prozess aufsetzen, zeigt unser Beitrag zum Risikomanagementsystem nach dem AI Act.

Ebenso legt das QMS fest, wie die technische Dokumentation entsteht, aktualisiert und mit den Entwicklungsergebnissen verknüpft wird. Behandeln Sie diese nicht als Einzelaufgabe, sondern als vom QMS gesteuerten Prozess – Details dazu in unserem Beitrag zur technischen Dokumentation nach dem AI Act.

QMS in die bestehende Compliance-Landschaft integrieren

Verknüpfung zu Data Governance, Logging und menschlicher Aufsicht

Ein wirksames QMS verweist auf die operativen Prozesse der Einzelpflichten, statt sie zu duplizieren:

Datenmanagement (Element f) verzahnt sich mit den Data-Governance-Anforderungen des Art. 10. Ihre Verfahren zu Datenerhebung, -kennzeichnung und -qualität gehören hier hinein – vertieft im Beitrag zu Datenqualität und Data Governance nach Art. 10.
Aufzeichnung (Element k) greift auf die Logging-Pflichten nach Art. 12 zurück. Das automatische Führen von Protokollen ist ein technisches Feature; das QMS legt fest, wie Logs aufbewahrt und ausgewertet werden.
Die menschliche Aufsicht nach Art. 14 ist zwar kein eigenes QMS-Element, muss aber über das Design- und Entwicklungselement (b, c) organisatorisch verankert werden.

Nutzung vorhandener ISO- oder Managementsysteme

Wer bereits ein zertifiziertes Managementsystem betreibt, kann viele Formalanforderungen – Dokumentenlenkung, interne Audits, Managementbewertung, korrektive Maßnahmen – direkt übernehmen. Ergänzen Sie diese Struktur um die KI-spezifischen Elemente g bis i (Risikomanagement, Post-Market-Monitoring, Vorfallmeldung). Das spart Aufwand und vermeidet widersprüchliche Parallelsysteme.

Proportionalität für KMU

Der AI Act erkennt an, dass ein Start-up nicht die Ressourcen eines Konzerns hat. Nach dem Digital Omnibus (in Kraft seit 27. Juli 2026) gilt: Art. 17 Abs. 2 verlangt eine Umsetzung, die der Größe des Anbieters angemessen ist – insbesondere bei KMUs, Start-ups und kleinen Midcap-Unternehmen (SMC). Art. 63 erlaubt zudem KMUs einschließlich Start-ups (ohne Partner- oder verbundene Unternehmen), bestimmte Elemente des QMS in vereinfachter Weise umzusetzen. Wichtig ist die richtige Lesart: Vereinfachung betrifft die Art und Weise der Umsetzung, nicht den Wegfall von Pflichten. Alle dreizehn Elemente müssen adressiert werden – ein kleineres Unternehmen darf sie aber schlanker, weniger formalisiert und mit angemessenem Aufwand dokumentieren. Welche Elemente vereinfacht werden dürfen, legt die Kommission in Leitlinien fest. Die inhaltliche Substanz – nachweisbares Risikomanagement, dokumentierte Datenqualität – bleibt jedoch unverzichtbar.

Nachweis und Prüfung: Wie das QMS im Audit standhält

Rolle des QMS bei der Konformitätsbewertung

Das QMS ist nicht nur eine interne Organisationshilfe – es ist prüfungsrelevant. Bei bestimmten Hochrisiko-KI-Systemen ist das QMS unmittelbarer Gegenstand der Konformitätsbewertung. Für Systeme, die dem Bewertungsverfahren nach Anhang VII unterliegen, prüft die benannte Stelle das QMS als eigenständigen Bewertungsgegenstand. Ein solides, gelebtes QMS ist damit die Grundlage dafür, dass Sie die Konformität überhaupt nachweisen können. Wie das Verfahren insgesamt abläuft, erläutert unser Beitrag zur Konformitätsbewertung nach dem AI Act.

Prüfung durch benannte Stelle

Unterliegt Ihr System einer Bewertung durch eine benannte Stelle, bewertet diese, ob das QMS die Anforderungen des Art. 17 erfüllt. Konkret prüft sie:

ob die dreizehn Elemente dokumentiert sind,
ob die dokumentierten Prozesse tatsächlich angewendet werden,
ob Nachweise (Records, Testberichte, Meldeprotokolle) vorliegen und konsistent sind.

Eine strukturierte Vorbereitung entscheidet hier über Erfolg oder teure Nachforderungen – konkrete Hinweise dazu finden Sie im Beitrag zur Audit-Vorbereitung.

Typische Lücken und wie Sie sie vermeiden

Im Audit fallen regelmäßig dieselben Schwachstellen auf:

Dokumentation ohne Nachweis der Anwendung: Ein Verfahren ist beschrieben, aber es fehlen Records, die belegen, dass es gelebt wird.
Fehlende Aktualität: Prozesse wurden einmal erstellt und nie an Produktänderungen angepasst – das Änderungsmanagement (Element a) versagt.
Brüche zwischen Elementen: Das Risikomanagement identifiziert ein Risiko, das aber nirgends in Test- oder Monitoring-Prozessen wiederauftaucht.

Vermeiden lassen sich diese Lücken durch eine durchgängige Rückverfolgbarkeit von der Risikoanalyse über die Entwicklung bis zum Post-Market-Monitoring.

Häufige Fehler beim Aufbau des QMS

Papier-QMS ohne gelebte Prozesse

Der Klassiker: ein umfangreiches Handbuch, das nach der Erstellung im Ordner verschwindet. Die benannte Stelle prüft nicht, ob Sie schöne Dokumente haben, sondern ob Ihre Organisation nach diesen Dokumenten tatsächlich arbeitet. Ein QMS, dessen Verfahren im Alltag ignoriert werden, ist im Prüfungsfall wertlos – und erzeugt zusätzlich das Risiko, dass dokumentierte Abweichungen als Verstoß gewertet werden.

Fehlende Verantwortlichkeiten

Wenn niemand konkret zuständig ist, verwaisen Prozesse. Ohne einen klaren Rechenschaftsrahmen (Element m) bleibt unklar, wer das Monitoring auswertet, wer Vorfälle meldet, wer die Dokumentation aktualisiert. Definierte, benannte und mit Ressourcen ausgestattete Rollen sind kein bürokratischer Luxus, sondern Voraussetzung dafür, dass das System funktioniert.

QMS als isoliertes Dokument statt lebendiges System

Ein QMS ist kein Projekt mit Enddatum, sondern ein kontinuierlicher Kreislauf. Es muss regelmäßig überprüft, an neue Erkenntnisse aus dem Post-Market-Monitoring angepasst und bei Produktänderungen aktualisiert werden. Wer das QMS als einmalige Pflichtübung behandelt, verliert genau die organisatorische Klammer, für die Art. 17 überhaupt existiert.

Fazit

Das Qualitätsmanagementsystem nach Art. 17 AI Act ist die organisatorische Klammer, die alle Anbieterpflichten für Hochrisiko-KI zusammenhält. Es betrifft ausschließlich Anbieter von Hochrisiko-KI und verlangt die dokumentierte Umsetzung von dreizehn Pflichtelementen – von der Regulierungs-Compliance-Strategie über Design-, Entwicklungs- und Testverfahren, Datenmanagement, Risikomanagement und Post-Market-Monitoring bis zu Vorfallmeldung, Behördenkommunikation, Aufzeichnung, Ressourcenmanagement und Rechenschaftsrahmen. Der Schlüssel liegt nicht im Neuerfinden, sondern im strukturierten Aufbau aus vorhandenen Bausteinen: Ist-Analyse, klare Verantwortlichkeiten, dokumentierte Prozesse und die konsequente Verzahnung mit Data Governance, technischer Dokumentation und Risikomanagement. Bestehende ISO-9001- oder ISO/IEC-42001-Systeme liefern das Gerüst, ersetzen die KI-spezifischen Elemente aber nicht. Für KMUs erlauben Art. 17 Abs. 2 und Art. 63 eine verhältnismäßige, schlankere Umsetzung – ohne dass Pflichten entfallen. Entscheidend bleibt am Ende, dass das QMS gelebt wird: Nur ein System mit realen Prozessen, Nachweisen und benannten Verantwortlichen hält der Prüfung durch die benannte Stelle stand und trägt die Konformitätsbewertung Ihres Hochrisiko-Systems.