KI-Verordnung (AI Act): Compliance ohne Abstraktion.

Klassifizieren Sie das System, bevor Sie irgendetwas anderes tun

Jede Entscheidung im Rahmen der KI-Verordnung beginnt mit einer Frage: In welche Stufe fällt dieses System. Klassifizieren Sie falsch, so überkonstruieren Sie entweder einen Chatbot oder unterschützen ein Tool zum Lebenslauf-Screening, das eine Aufsichtsbehörde als hochriskant einstufen wird. Die vier Stufen sind kein Spektrum, auf dem Sie sich bewegen; es sind diskrete Kategorien mit unterschiedlichen rechtlichen Folgen, und ein einzelnes Produkt kann in mehr als einer liegen, wenn es mehrere Funktionen bündelt.

Die Klassifizierung ist eine Funktion des Zweckbestimmung, nicht der technischen Raffinesse. Eine einfache logistische Regression, die entscheidet, wer einen Kredit erhält, ist hochriskant. Ein großes multimodales Modell, das Rezepte empfiehlt, ist es nicht. Die Verordnung betrachtet, wofür das System verwendet wird und wen es betrifft, weshalb die Klassifizierungsarbeit Produkt und Compliance gemeinsam zukommt, nicht dem Data-Science-Team allein.

Die meisten Streitfragen im Audit-Raum drehen sich nicht um minimal gegen hoch; sie drehen sich an der Grenze um hoch gegen begrenzt. Wenn Sie die Klassifizierung nicht schriftlich verteidigen können, behandeln Sie sie als die höhere Stufe, bis Sie es können. Der Kurs AI Risk Manager geht die Klassifizierungslogik durch und den Nachweis, den Sie benötigen, um hinter einer Entscheidung zu stehen.

Was "hochriskant" im Betrieb tatsächlich bedeutet

Das TL;DR listet die sieben Pflichtenbereiche auf. Die betriebliche Realität ist, dass jeder davon ein wiederkehrender Prozess ist, kein Dokument, das Sie einmal schreiben. Hochrisiko-Compliance ist ein System, das Sie über die gesamte Lebensdauer des Produkts betreiben, und die Verordnung erwartet, dass Sie nachweisen, dass das System aktiv ist, nicht dass es am Tag der Markteinführung existierte.

1. Risikomanagement ist fortlaufend. Sie identifizieren vorhersehbaren Missbrauch und Schäden, mindern sie, prüfen das Restrisiko und wiederholen dies bei jeder wesentlichen Änderung. Ein eingefrorenes Risikoregister von der Markteinführung ist eine Feststellung, kein Control.
2. Daten-Governance erfasst die Trainings-, Validierungs- und Testdatensätze: Repräsentativität, Prüfung auf Verzerrungen, Lücken und die Herkunft der Daten. Sie müssen zeigen, was Sie geprüft und was Sie gefunden haben, nicht nur behaupten, die Daten seien "gut" gewesen.
3. Die technische Dokumentation ist das Rückgrat der Akte. Sie beschreibt das System, seinen Zweck, seine Designentscheidungen, seine Leistungskennzahlen und seine Grenzen so detailliert, dass eine Drittstelle daraus die Konformität bewerten könnte.
4. Aufzeichnungen bedeuten automatische Protokollierung über die Lebensdauer des Systems, damit Ereignisse nachvollziehbar sind. Wenn etwas schiefläuft, müssen Sie rekonstruieren können, was das System getan hat.
5. Menschliche Aufsicht muss von Anfang an eingebaut sein, nicht nachträglich angesetzt: Die das System beaufsichtigenden Personen brauchen die Fähigkeit, zu verstehen, einzugreifen und zu übersteuern, und die Schnittstelle muss dies ermöglichen.
6. Genauigkeit, Robustheit und Cybersicherheit müssen gemessen und erklärt und dann unter realen Bedingungen, einschließlich gegnerischer, gehalten werden. "Es funktioniert in der Demo" ist keine Robustheitsaussage.

Diese Pflichten lassen sich sauber auf ein Managementsystem abbilden, weshalb Teams die Verordnung mit ISO/IEC 42001 kombinieren. Der Kurs ISO 42001 Lead Implementer baut das Betriebsmodell auf, das diese sieben Bereiche in wiederholbare Prozesse mit Verantwortlichen, Nachweisen und Überprüfungszyklen verwandelt.

Der Ablauf der Konformitätsbewertung

Die Konformitätsbewertung ist die Hürde, die ein Hochrisikosystem nimmt, bevor es auf dem EU-Markt in Verkehr gebracht wird. Für die meisten Hochrisikokategorien ist dies eine vom Anbieter durchgeführte Bewertung auf Grundlage einer internen Kontrolle gegen die Anforderungen der Verordnung; bestimmte Kategorien, insbesondere einige biometrische, laufen über eine notifizierte Stelle. So oder so ist die Abfolge dieselbe, und es lohnt sich, sie eher als Projektplan denn als Checkliste zu behandeln.

1. Bestätigen Sie die Klassifizierung und die geltenden Anforderungen für Ihren konkreten Anwendungsfall und Ihre Kategorie.
2. Richten Sie die Prozesse für Risikomanagement und Daten-Governance ein und betreiben Sie sie, sodass echte Nachweise statt Platzhalter entstehen.
3. Stellen Sie die technische Dokumentation so zusammen, dass sie vollständig und intern konsistent mit den Protokollen, Testergebnissen und dem Risikoregister ist.
4. Führen Sie die Konformitätsbewertung durch (intern oder, wo erforderlich, über eine notifizierte Stelle) und schließen Sie die dabei aufgedeckten Lücken.
5. Erstellen Sie die EU-Konformitätserklärung, bringen Sie die CE-Kennzeichnung an und registrieren Sie das System vor der Markteinführung in der EU-Datenbank.
6. Gehen Sie ab dem ersten Tag in die Beobachtung nach dem Inverkehrbringen über, denn die Pflicht endet nicht mit der Markteinführung.

Beobachtung nach dem Inverkehrbringen und der gestufte Zeitplan

Das Inverkehrbringen eines Systems ist der Mittelpunkt der Pflicht, nicht das Ende. Anbieter müssen einen Plan zur Beobachtung nach dem Inverkehrbringen betreiben, der aktiv Leistungs- und Vorfalldaten über die eingesetzte Lebensdauer des Systems erhebt, und schwerwiegende Vorfälle müssen den Behörden innerhalb festgelegter Fristen gemeldet werden. Wesentliche Änderungen können eine erneute Konformitätsbewertung auslösen, weshalb Ihr Änderungsmanagementprozess und Ihr KI-Verordnungsprozess miteinander verzahnt sein müssen.

Der Zeitplan ist gestuft, was Teams zu Fall bringt, die "August 2027" lesen und annehmen, sie hätten für alles bis dahin Zeit. Die Verbote inakzeptabler Praktiken gelten bereits. GPAI-Pflichten und mehrere Governance-Bestimmungen greifen früher im Zeitplan, und die Hochrisikopflichten greifen je nach Kategorie über den Zeitraum bis August 2027 gestaffelt. Die richtige Haltung besteht darin, jedes Ihrer Systeme seinem eigenen geltenden Datum zuzuordnen, statt auf eine einzige Klippe hin zu planen.

Den Beobachtungs- und Vorfallkreislauf zu betreiben, ist der Punkt, an dem sich die KI-Auditoren- und Risikorollen bezahlt machen. Der Kurs AI Auditor (AAIA) behandelt, wie man ein KI-Managementsystem gegen diese Nachweise auditiert, und der Kurs Advanced AI Auditor (AAIR) geht tiefer auf die Test- und Assurance-Arbeit ein, die hinter einer belastbaren Akte zur Beobachtung nach dem Inverkehrbringen steht.

KI mit allgemeinem Verwendungszweck: eine separate Pflicht, die Sie erben können

Die GPAI-Modellregeln stehen neben den Risikostufen, nicht in ihnen. Wenn Sie ein Modell mit allgemeinem Verwendungszweck erstellen oder feinabstimmen, tragen Sie Anbieterpflichten: technische Dokumentation für das Modell, Informationen für nachgelagerte Betreiber, eine Urheberrechtsstrategie und eine öffentliche Zusammenfassung der Trainingsinhalte. Modelle, die als systemisch risikobehaftet eingestuft werden, übernehmen strengere Pflichten, darunter Modellbewertung, gegnerische Tests und Vorfallmeldung.

Die Falle für die meisten Teams liegt auf der anderen Seite dieser Beziehung. Wenn Sie ein Basismodell eines Drittanbieters in Ihr eigenes Hochrisikosystem integrieren, entkommen Sie der Verordnung nicht, indem Sie auf den Modellanbieter verweisen. Sie erben das Integrationsrisiko und bleiben dafür verantwortlich, dass Ihr System die Konformität erreicht. Behandeln Sie die Dokumentation des Modellanbieters als Eingabe in Ihre Akte, nicht als Ersatz dafür, und richten Sie die vertraglichen Weitergabepflichten ein, bevor Sie ausliefern.

Häufige Fehler und die Entscheidung, die vor Ihnen liegt

• Die Klassifizierung als einmaligen Vorgang behandeln. Eine Funktion, die als Empfehlungssystem begann, wird in dem Moment hochriskant, in dem sie eine Einstellungs- oder Kreditentscheidung steuert. Klassifizieren Sie bei jeder wesentlichen Zweckänderung neu.
• Dokumentation als Artefakt der Markteinführung schreiben. Die Akte muss mit dem laufenden System synchronisiert bleiben; eine veraltete Akte ist schlimmer als eine unvollständige, weil sie aktiv in die Irre führt.
• Das Managementsystem mit der Regulierung verwechseln. ISO 42001 organisiert Ihren Nachweis, macht aber für sich genommen kein System KI-Verordnungs-konform. Sie klassifizieren, bewerten und registrieren weiterhin gegen die Verordnung.
• Annehmen, dass die GPAI-Anbieterpflichten Ihre Integration abdecken. Tun sie nicht. Ihr Hochrisikosystem braucht seine eigene Konformitätsgeschichte.
• Auf eine einzige Frist hin planen. Die gestuften Daten bedeuten, dass einige Pflichten bereits aktiv sind, während andere Jahre entfernt liegen; planen Sie pro System, pro Kategorie.

Die Entscheidung, die vor den meisten Teams liegt, ist nicht, ob sie Compliance herstellen, sondern wie sie die Fähigkeit aufbauen, sie wiederholt herzustellen. Wenn Sie bei null beginnen, gibt der Kurs ISO 42001 Foundation dem Team ein gemeinsames Vokabular, und der Kurs AI Security Management (AAISM) verbindet die Cybersicherheits- und Robustheitspflichten der Verordnung mit dem Sicherheitsprogramm, das Sie bereits betreiben. Wählen Sie die Rolle, die Ihrer Lücke am nächsten liegt, und bauen Sie von dort aus weiter.