Ein CE-Zeichen ist kein Qualitätsversprechen

Kaum ein Symbol wird im europäischen Produktumfeld so oft überinterpretiert wie das CE-Zeichen. In Präsentationen wird daraus schnell ein Qualitätssiegel, ein Sicherheitszertifikat oder sogar eine behördliche Freigabe. Für KI-Systeme wäre diese Verkürzung besonders gefährlich. Denn ein rechtlich relevanter Marktzugang, technische Leistungsfähigkeit und verantwortbarer Betrieb sind drei verschiedene Fragen.

Die Konformitätslogik des EU AI Act verbindet Klassifikation, Anforderungen, Nachweise, Bewertung, Erklärung, Kennzeichnung, Registrierung und Überwachung. Das CE-Zeichen ist darin ein sichtbarer Endpunkt eines Verfahrens – kein Ersatz für das Verfahren selbst. Wer es verstehen will, muss die unsichtbare Beweiskette dahinter lesen können.

Zuerst wird der Anwendungsfall klassifiziert

Vor jeder Diskussion über ein Zeichen steht die Frage, welche Rolle, welches System und welcher vorgesehene Zweck überhaupt betrachtet werden. Nicht jede KI-Anwendung ist ein Hochrisiko-KI-System. Nicht jedes Unternehmen ist automatisch Anbieter. Und nicht jede technische Änderung bleibt ohne Einfluss auf die rechtliche Rollenverteilung.

Eine belastbare Klassifikation hält Systemgrenze, vorgesehenen Zweck, Nutzer, betroffene Personen, Entscheidungseinfluss, Einbettung in Produkte und Prozesse sowie die Rolle jedes Akteurs fest. Sie dokumentiert auch Annahmen und offene Punkte. Ein bloßer Modellname reicht nicht: Dasselbe Basismodell kann in einer unverbindlichen Schreibhilfe oder in einem System mit erheblichem Entscheidungseinfluss eingesetzt werden.

Klassifikation ist kein einmaliger Etikettierakt. Wird der Zweck erweitert, das System unter eigenem Namen vermarktet oder wesentlich verändert, kann eine neue Bewertung erforderlich werden. Deshalb gehört die Klassifikationsentscheidung in ein versioniertes Register mit Auslösern für erneute Prüfung.

Anbieter ist eine Verantwortungsrolle

Der Begriff Anbieter beschreibt nicht einfach den Hersteller eines Basismodells. Entscheidend ist, wer ein KI-System entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke in Verkehr bringt oder in Betrieb nimmt. Entlang einer Wertschöpfungskette können Integratoren, Produktanbieter oder andere Akteure unter bestimmten Voraussetzungen selbst in diese Rolle rücken.

Artikel 25 erfasst insbesondere Konstellationen, in denen ein Akteur ein System unter eigenem Namen oder eigener Marke bereitstellt, eine wesentliche Änderung vornimmt oder den vorgesehenen Zweck so verändert, dass das System zum Hochrisiko-System wird. Dann genügt es nicht, auf einen vorgelagerten Anbieter zu zeigen. Verträge müssen Informationen, technische Zugänge, Pflichten und Schutz von geistigem Eigentum oder Geschäftsgeheimnissen so ordnen, dass die neue Verantwortung tatsächlich erfüllbar ist.

Eine RACI-Matrix allein löst das Problem nicht. Rollen brauchen Entscheidungsrechte, Zugriff auf Nachweise, Budget für Tests und die Fähigkeit, Vertrieb oder Betrieb zu stoppen.

Konformitätsbewertung ist ein Verfahren, kein einzelnes Zertifikat

Artikel 43 beschreibt unterschiedliche Wege der Konformitätsbewertung. Welcher Weg gilt, hängt unter anderem von der Systemkategorie und den anwendbaren Regelungen ab. Eine notifizierte Stelle ist deshalb weder immer beteiligt noch grundsätzlich ausgeschlossen. Die pauschalen Sätze „CE ist nur Selbsterklärung" und „CE bedeutet externe Zertifizierung" sind beide unzuverlässig.

Auch eine interne Bewertung ist keine Selbstbefreiung. Sie verlangt, dass Anforderungen systematisch in Kontrollen übersetzt, Tests durchgeführt, Abweichungen behandelt und die Ergebnisse dokumentiert werden. Wo eine externe Stelle beteiligt ist, ersetzt deren Prüfung nicht die Verantwortung des Anbieters. Sie prüft innerhalb eines bestimmten Mandats und auf Basis eines definierten Systems und Dokumentenstands.

Die erste operative Aufgabe lautet daher: den korrekten Bewertungsweg und seine Eingangsvoraussetzungen bestimmen. Ein Conformity Route Record nennt Rechtsgrundlage, Systemkategorie, verwendete Standards oder Spezifikationen, beteiligte Stellen, erforderliche Artefakte und Freigabekriterien.

Self-assessment bedeutet nicht self-approval ohne Beweise

Der Kern einer guten Bewertung ist eine Traceability Matrix. Jede anwendbare Anforderung erhält eine eindeutige Kennung. Diese wird mit einer technischen oder organisatorischen Kontrolle, einem Prüfverfahren, einem beobachteten Ergebnis, einem verantwortlichen Owner und einer Abweichungsentscheidung verbunden.

Die Kette lautet: Anforderung → Systembehauptung → Kontrolle → Test → Ergebnis → Entscheidung. Fehlt ein Glied, entsteht nur Dokumentationstheater. Ein Testbericht ohne Anforderung beweist nicht, warum der Test relevant ist. Eine Richtlinie ohne Betriebssignal beweist nicht, dass sie angewendet wird. Ein Modellbenchmark ohne vorgesehenen Zweck sagt wenig über die Eignung des Gesamtsystems.

Negative Ergebnisse gehören in dieselbe Kette. Sie werden nicht aus dem Dossier entfernt, sondern mit Begrenzung, Korrektur, akzeptiertem Restrisiko oder Stop-Entscheidung verbunden. Gerade der Umgang mit Gegenbelegen zeigt, ob die Bewertung ernst gemeint ist.

Technische Dokumentation muss das reale System beschreiben

Eine Konformitätsakte kann formal vollständig und dennoch praktisch wertlos sein, wenn sie eine idealisierte Architektur beschreibt. Die Dokumentation muss zu der Konfiguration passen, die tatsächlich in Verkehr gebracht oder in Betrieb genommen wird: Modell- und Promptversion, Datenquellen, Retrievalbestand, Tools, Schwellenwerte, Schnittstellen, Aufsicht, Logging, Sicherheitsmaßnahmen und Abhängigkeiten.

Dabei ist Versionierung entscheidend. Jede Bewertung braucht einen eingefrorenen Evidence Snapshot. Hashes, Artefaktkennungen und Gültigkeitszeiträume verbinden die Aussage mit einem reproduzierbaren Zustand. Dynamische Komponenten werden nicht durch einen Screenshot „stabilisiert"; für sie braucht es Änderungsregeln, zulässige Bereiche und erneute Testauslöser.

Ein Dossier ist somit kein Ordner voller PDFs, sondern ein navigierbarer Graph. Von der Systemversion muss man zu Zweck, Anforderung, Test, Ergebnis, Freigabe und späterer Änderung gelangen können.

Die EU-Konformitätserklärung ordnet Verantwortung zu

Nach Artikel 47 wird für das jeweilige System eine EU-Konformitätserklärung erstellt und aktuell gehalten. Mit ihr übernimmt der Anbieter Verantwortung dafür, dass das System die einschlägigen Anforderungen erfüllt. Das ist mehr als ein Marketingtext: Die Erklärung identifiziert System, Anbieter, anwendbare Rechtsakte und weitere vorgeschriebene Angaben.

Die Erklärung fasst eine vorherige Beweisarbeit zusammen. Sie kann fehlende Tests, widersprüchliche Versionen oder ungeklärte Abweichungen nicht heilen. Vor der Unterzeichnung braucht es deshalb ein formales Readiness Review: Sind System und Scope eindeutig? Ist jede Pflicht abgedeckt? Stimmen technische Dokumentation, Teststand und ausgelieferte Version überein? Sind offene Abweichungen entscheidungsreif? Ist die unterzeichnende Rolle befugt und informiert?

Das CE-Zeichen ist eine präzise, aber begrenzte Aussage

Artikel 48 verknüpft die CE-Kennzeichnung mit der Konformität des Hochrisiko-KI-Systems. Bei digitalen Systemen kann eine digitale Kennzeichnung verwendet werden; die vorgeschriebenen Regeln zu Sichtbarkeit und Zuordnung bleiben relevant. Das Zeichen kommuniziert eine rechtliche Konformitätsbehauptung für ein konkretes Produkt oder System.

Es behauptet nicht automatisch:

• dass eine Behörde das System empfohlen oder jeden Test selbst durchgeführt hat;

• dass eine unabhängige Stelle stets beteiligt war;

• dass das System fehlerfrei, für jeden Zweck geeignet oder risikofrei ist;

• dass sein Anbieter besonders innovativ, ethisch oder wirtschaftlich stabil ist;

• dass spätere Änderungen und jede reale Verwendung von der ursprünglichen Bewertung gedeckt sind.

Diese Grenzen sind keine Schwäche des Zeichens. Sie schützen seine Bedeutung. Problematisch wird es erst, wenn Vertrieb oder Beratung aus einer begrenzten Konformitätsaussage ein allgemeines Vertrauensversprechen machen.

Registrierung ist ein eigener Kontrollpunkt

Für relevante Hochrisiko-KI-Systeme sieht Artikel 49 Registrierungen in der EU-Datenbank vor. Registrierung und CE-Kennzeichnung sind miteinander verbunden, aber nicht identisch. Ein Zeichen ersetzt keinen Datenbankeintrag; ein Eintrag ersetzt keine Bewertung.

Das Registration Record enthält Verantwortlichen, Systemidentität, Status, erforderliche Angaben, Datum, Referenz und Aktualisierungsregeln. Vor Veröffentlichung werden Konsistenz und Vertraulichkeit geprüft. Die Angaben müssen zur technischen Dokumentation und zur tatsächlich bereitgestellten Version passen.

In komplexen Produkten können zusätzlich andere europäische Produktregime greifen. Mehrere Kennzeichnungen oder Verfahren dürfen nicht zu einer einzigen unscharfen Aussage vermischt werden. Das Compliance Mapping zeigt für jede Regelung Gegenstand, Verantwortlichen, Bewertungsweg und Nachweis.

Änderungen können die Aussage entwerten

Nach Marktzugang bleibt das System nicht stehen. Modelle werden ersetzt, Tools erhalten neue Rechte, Datenquellen wechseln und Kunden nutzen Funktionen in anderen Prozessen. Eine Änderung kann die geprüfte Baseline verlassen, ohne dass sich die Benutzeroberfläche sichtbar verändert.

Ein Change Gate bewertet deshalb Zweck, Rolle, Risikoklassifikation, Anforderungen, Tests, Dokumentation, Erklärung, Kennzeichnung und Registrierung gemeinsam. Besonders aufmerksam werden Teams bei wesentlichen Änderungen und Zweckänderungen. Auch ein Rebranding oder die Übernahme eines fremden Systems unter eigenem Namen kann Verantwortung verschieben.

Die Frage ist nicht nur „Funktioniert der Build?", sondern „Ist die bisherige Konformitätsbehauptung für diesen Build noch tragfähig?" Bis diese Frage geklärt ist, bleibt die Änderung begrenzt oder blockiert.

Marktzugang beendet die Evidenzarbeit nicht

Artikel 72 verlangt für Hochrisiko-KI-Systeme aktives und systematisches Post-Market-Monitoring während der Lebensdauer. Damit ist das CE-Zeichen kein Abschlussstempel. Reale Betriebsdaten, Beschwerden, Vorfälle, Drift und Änderungen können die ursprünglichen Annahmen bestätigen oder widerlegen.

Das Monitoring verbindet jede ausgelieferte Version mit Signalen und Schwellen. Wenn ein Signal eine Systembehauptung berührt, folgen Triage, Korrektur und Wirksamkeitsprüfung. Erhebliche Probleme können Einschränkung, Deaktivierung, Rücknahme oder weitere Meldewege auslösen. Eine Konformitätsakte, die nach dem Launch nicht mehr aktualisiert wird, verliert den Bezug zum lebenden System.

Qualität geht darüber hinaus. Auch ein konformes System kann gegenüber einer Alternative ungenauer, schwerer bedienbar oder teurer sein. Qualitätsmanagement misst Nutzen, Robustheit, Fairness, Wartbarkeit und Nutzererfahrung nach dem vorgesehenen Zweck. Compliance setzt Grenzen; Produktqualität entscheidet innerhalb dieser Grenzen über Eignung und Wert.

Der Versprechens-Test für Produktkommunikation

Jede Aussage mit „zertifiziert", „behördlich geprüft", „sicher", „vertrauenswürdig" oder „vollständig konform" wird vor Veröffentlichung zerlegt. Welches konkrete System? Welche Version? Welche Anforderung? Welches Verfahren? Welche Stelle? Welcher Gültigkeitsbereich? Welches Datum? Welche Ausnahmen?

Ist eine Antwort nicht belegbar, wird die Formulierung eingegrenzt. Präzise Kommunikation kann sagen, dass für ein bestimmtes System eine Konformitätsbewertung durchgeführt, eine Erklärung ausgestellt und die CE-Kennzeichnung angebracht wurde. Sie sollte nicht daraus ableiten, dass jede Ausgabe korrekt oder jede zukünftige Verwendung zulässig ist.

Diese Disziplin schützt Käufer, Anbieter und Beratende. Sie verhindert, dass ein rechtlich definiertes Zeichen zu einer frei erfundenen Qualitätsmarke wird.

Methode: CLASSIFY → EVIDENCE → ASSESS → DECLARE → REGISTER → MONITOR

CLASSIFY bestimmt System, Zweck, Risiko und Rollen. EVIDENCE verbindet Anforderungen mit Kontrollen, Tests und Ergebnissen. ASSESS führt den passenden Bewertungsweg durch und entscheidet über Abweichungen. DECLARE fasst die verantwortete Konformitätsaussage zusammen. REGISTER stellt die vorgeschriebene Markttransparenz her. MONITOR prüft fortlaufend, ob die Aussage unter realen Bedingungen und Änderungen weiter trägt.

Die Reihenfolge ist wichtig. Wer mit dem Zeichen beginnt, produziert Symbolpolitik. Wer mit Klassifikation und Evidenz beginnt, baut einen belastbaren Marktzugang.

Übungsblatt: Baue eine Market-Access Evidence Map

1. Definiere Systemgrenze, vorgesehenen Zweck, Version und alle beteiligten Rollen.

2. Begründe Risikoklasse und gewählten Konformitätsweg; markiere Unsicherheiten.

3. Wähle acht anwendbare Anforderungen und verbinde jede mit Kontrolle, Test, Ergebnis und Owner.

4. Prüfe, ob technische Dokumentation und reale Produktkonfiguration übereinstimmen.

5. Entwirf ein Readiness Review für Erklärung, Kennzeichnung und Registrierung.

6. Simuliere eine Modell-, Zweck- oder Markenänderung und entscheide, welche Schritte erneut nötig werden.

7. Formuliere eine zulässige Produktbeschreibung und streiche jede unbelegte Qualitätsbehauptung.

Reflexion: Welche Aussage über das CE-Zeichen würdest du nach dieser Prüfung nicht mehr verwenden? Welche Änderung könnte deine heutige Konformitätsbehauptung morgen ungültig machen?

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Der Beitrag erläutert ein fachliches Konformitäts- und Evidenzmodell, keine Rechtsberatung. Ob ein System als Hochrisiko-KI gilt, welches Verfahren greift und welche weiteren Produkt-, Sektor-, Datenschutz-, Arbeits- oder nationalen Regeln gelten, ist für den konkreten Fall zu prüfen. Stand der redaktionellen Prüfung: 17. Juli 2026.