KI-Gesetz-Compliance-Tool-Vergleich: 5 Kategorien, 6 Achsen

Ein Vergleich von KI-Gesetz-Compliance-Tools wird erst dann nützlich, wenn man aufhört, Marken zu vergleichen, und stattdessen Kategorien vergleicht – denn die fünf Kategorien dieses Marktes erzeugen fünf unterschiedliche Artefakte, und vier davon berühren in der Regel nicht unmittelbar den Satz, den Ihr Nutzer tatsächlich auf dem Bildschirm liest.

Viele Ranking-Listen verwischen das. Sie stecken einen kostenlosen Risikoklassifikator, eine GRC-Automatisierungssuite, eine KI-Governance-Plattform, eine Laufzeit-Beobachtungsschicht und eine Offenlegungsschicht in eine Tabelle und bewerten sie anhand gemeinsamer Checkboxen wie „Audit-Trail“ und „Richtlinienvorlagen“. Ein Team kann das Top-Produkt aus einer dieser Listen kaufen, jeden Onboarding-Schritt abschließen – und trotzdem ein Support-Chat-Widget ausliefern, in dessen Oberfläche nichts darauf hinweist, dass es sich um einen Chat mit einem KI-System handelt.

Die Transparenzvorschriften von Artikel 50 gelten seit dem 2. August 2026. Nur für die maschinenlesbare Kennzeichnung nach Absatz 2 gibt es eine Übergangsfrist: Anbieter von KI-Systemen (einschließlich KI-Systemen mit allgemeinem Verwendungszweck), die synthetische Audio-, Bild-, Video- oder Textinhalte erzeugen und vor dem 2. August 2026 in Verkehr gebracht wurden, haben dafür bis zum 2. Dezember 2026 Zeit (Art. 111 Abs. 4, eingefügt durch die Digital-Omnibus-Verordnung zur KI, Verordnung (EU) 2026/1744). Für die Absätze 1, 3 und 4 und für Betreiber gilt diese Übergangsfrist nicht. Prüfen Sie beide Daten und ihren Geltungsbereich anhand der Zeitleiste des AI Act Service Desk der Europäischen Kommission und nicht anhand der Marketingseite eines Anbieters. Für die Einordnung Ihres Systems hilft der offizielle AI Act Compliance Checker der Kommission; ob Ihr konkretes System in eine bestimmte Spur fällt, bleibt eine Frage für qualifizierte Rechtsberatung. Dieser Artikel ist keine Rechtsberatung; er ist eine Beschaffungsmethode.

Fünf Kategorien, fünf unterschiedliche Artefakte

DiscloseKit, das diesen Leitfaden veröffentlicht, steht in der fünften Zeile: Ein deterministischer Prüfmechanismus ohne Sprachmodell im Compliance-Kern, ein Offenlegungs-Widget, ein Verifizierungsschritt und ein hash-verkettetes Nachweisprotokoll, gehostet in der EU (Frankfurt). Das ist Compliance-Tooling, keine Rechtsberatung und keine Zertifizierung. Behandeln Sie die Beschreibung dieser Zeile als eigeninteressiert und bewerten Sie sie anhand derselben sechs Achsen wie alles andere weiter unten. Ein Anbieter, der zurückschreckt, bei den Ausstiegskosten bewertet zu werden, sagt Ihnen damit etwas.

Zwei kostenlose Klassifikatoren lohnt es sich auszuprobieren, bevor Sie mit jemandem sprechen: Der oben verlinkte Checker der Kommission, den sie derzeit als Beta-Version bezeichnet, und der EU AI Act Compliance Checker, den das Future of Life Institute – nach eigener Angabe in keiner Weise mit der EU verbunden – zusammen mit einem durchsuchbaren Gesetzestext (AI Act Explorer) pflegt (Angaben der Betreiber, Stand: September 2026). Beide sind kostenlos und grenzen das Gespräch von „KI-Compliance“ auf einen konkreten Satz von Spuren ein. Sie enden auch dort, wo jeder kostenlose Klassifikator endet: Beim Urteil.

Die Frage, die Anbieter schneller sortiert als eine Feature-Matrix

Stellen Sie beim ersten Gespräch eine einzige Frage: *Welches Artefakt existiert, nachdem Ihr Tool seine Arbeit an unserem Checkout-Assistenten erledigt hat, das vorher nicht existierte, und wo liegt es?*

Wenn die Antwort ein Bericht, ein Eintrag im Risikoregister oder eine Dashboard-Kachel ist, kaufen Sie Analyse. Wenn die Antwort eine gerenderte Zeichenkette im Produkt plus ein datierter Nachweis dafür ist, dass diese Zeichenkette an einer URL live war, kaufen Sie Ausführung. Beide sind legitime Käufe. Analyse zu kaufen, während man glaubt, Ausführung gekauft zu haben, ist der Fehlermodus, den dieser gesamte Markt hervorbringt, und er tritt in der Regel zutage, wenn zum ersten Mal jemand außerhalb des Teams fragt, was ein Nutzer an einem bestimmten Datum gesehen hat.

Die Anschlussfrage ist schärfer: *Welche Teile dieser Antwort stehen im Vertrag, und welche in der Dokumentation?* Dokumentation ändert sich mit jedem Deploy. Verträge nicht.

Eine 30-Zellen-Abdeckungsmatrix, die Sie aus Anbieterdokumentation ausfüllen können

Sechs Pflichtenzellen, fünf Kategorien. Die vier Spuren unten folgen der Struktur von Artikel 50 – ein Interaktionshinweis, maschinenlesbare Kennzeichnung synthetischer Ausgaben, ein Hinweis für Emotionserkennung und biometrische Kategorisierung sowie Offenlegung bei Deepfakes und bei KI-generiertem Text, der zur Information der Öffentlichkeit über Angelegenheiten von öffentlichem Interesse veröffentlicht wird. Laut Artikel 50 der KI-Verordnung richten sich die Absätze 1 und 2 an Anbieter, die Absätze 3 und 4 an Betreiber; welche Rolle Sie für ein konkretes Feature einnehmen, sollten Sie für Ihre eigenen Sachverhalte anhand des Verordnungstextes bestätigen. Die letzten beiden Zeilen – Nachweisaufbewahrung und Änderungserkennung – sind keine ausdrücklichen Pflichten aus Artikel 50, sondern praktische Nachweisfragen.

Diese Matrix ist eine Skizze auf Kategorieebene, keine Anbieter-Scorecard. Zwei Produkte in derselben Spalte können sich stark unterscheiden, und mehrere Anbieter verkaufen über zwei Spalten hinweg. Drucken Sie sie aus und füllen Sie dann eine Kopie pro Anbieter der engeren Wahl ausschließlich anhand von dessen eigener öffentlicher Dokumentation aus, und lassen Sie jede Zelle leer, die Sie nicht belegen können. Eine leere Zelle ist ein Befund. Eine Zelle, die aus einem Verkaufsgespräch ausgefüllt wurde, ist kein Nachweis für irgendetwas.

Ein Muster, auf das Sie achten sollten: Die Papierkram-Zeilen sind gut bedient, und die oberen vier Zeilen sind dünn. Eine solche Asymmetrie entsteht, weil Inventar- und Richtlinien-Tooling über Regelwerke hinweg verallgemeinerbar ist, während ein Hinweis in einer bestimmten React-Komponente das nicht ist.

Sechs Achsen von je vier Punkten bewerten, mit zwei harten Untergrenzen

Vierundzwanzig Punkte, sechs Dimensionen, keine Gewichtungsspielchen. Ankerpunkte bei 0, 2 und 4, damit zwei Personen, die getrennt bewerten, zum selben Ergebnis kommen.

1. Reichweite auf der Oberfläche. 0 — erzeugt nur Dokumente. 2 — liefert Text und Snippets, die Sie selbst einfügen. 4 — rendert im Produkt und kann von außerhalb verifiziert werden.

2. Rollenhandhabung. 0 — fragt Sie einmal global, ob Sie Anbieter oder Betreiber sind. 2 — pro System. 4 — pro Oberfläche, und kann beide Rollen auf demselben Feature abbilden, wenn Sie auf einer Drittanbieter-Modell-API aufbauen und das Ergebnis auch selbst einsetzen.

3. Determinismus des Urteils. 0 — eine undurchsichtige Punktzahl. 2 — eine Regel-Engine, die Sie nicht einsehen können. 4 — gleiche Eingaben ergeben dasselbe Urteil, das Urteil benennt den Absatz, auf dem es beruht, und der Regelsatz trägt eine Versionsnummer.

4. Qualität der Nachweise. 0 — ein PDF-Export, den man beliebig neu erzeugen kann. 2 — zeitgestempelte Einträge, die ein Administrator bearbeiten kann. 4 — Append-only-Einträge, die das wortgetreue gerenderte Artefakt, die Verifizierungsmethode und einen Supersedes-Verweis enthalten.

5. Widerstandsfähigkeit gegen Änderungen. 0 — Regelaktualisierungen des Anbieters reklassifizieren Ihre vergangenen Datensätze stillschweigend. 2 — Aktualisierungen werden angekündigt. 4 — alte Urteile bleiben an die Regelversion gebunden, die sie hervorgebracht hat, und neue Urteile erscheinen als neue Datensätze.

6. Ausstiegskosten. 0 — Screenshots eines Dashboards. 2 — CSV mit Metadaten. 4 — ein vollständiger Export, den man ohne die Software des Anbieters lesen und erneut verifizieren kann.

Zwei harte Untergrenzen: Eine Null bei der Nachweisqualität oder bei den Ausstiegskosten disqualifiziert das Tool als System of Record für diese Spur, unabhängig von der Gesamtpunktzahl. Unter 14 von 24 in diesem Rahmenwerk sollten Sie planen, es zu ergänzen. Zwischen 14 und 19 kann es ein bis zwei Spuren tragen. Ab 20 kann es der Nachweis für die von ihm abgedeckten Spuren sein – für die von ihm abgedeckten Spuren, und nicht weiter. Wenn Sie ein einzelnes Produkt statt eines ganzen Feldes bewerten, führt unser Leitfaden zu einem EU-KI-Gesetz-Artikel-50-Compliance-Tool ausführlicher durch einen Intake mit zwölf Feldern pro Feature und eine 24-Zellen-Betriebsmatrix.

Der zweistündige Bake-off: Sechs Fälle, je zwanzig Minuten

Machen Sie dies mit einer Stichprobe von zwölf echten Oberflächen aus Ihrem Produkt, nicht mit den Demodaten des Anbieters. Zwölf reichen in der Regel aus, um Drift aufzudecken, und sind klein genug, um an einem Vormittag fertig zu werden. Wenn Sie die Liste der Oberflächen noch nicht erstellt haben, beginnen Sie mit dem ersten Durchgang (Inventur nach Oberfläche) in unserer EU-KI-Gesetz-Compliance-Checkliste – der Bake-off ist ohne sie wertlos.

Fall 1 — der offensichtliche Chatbot. Ein Support-Widget, beschriftet mit „AI Assistant“ in 24px-Schrift, mit Avatar und einem Disclaimer über dem Eingabefeld. Artikel 50 Absatz 1 verlangt den Interaktionshinweis nicht, wenn die Interaktion mit einem KI-System aus Sicht einer angemessen informierten, aufmerksamen und verständigen Person aufgrund der Umstände und des Nutzungskontexts offensichtlich ist – ob das zutrifft, ist eine Einzelfallbewertung. Lässt das Tool einen Menschen eine Ausnahme aufzeichnen und begründen, oder erzwingt es einen Hinweis und erklärt die Aufgabe für erledigt? Das richtige Verhalten ist ein aufgezeichnetes Urteil mit einem Begründungsfeld, kein stiller Durchlauf in die eine oder andere Richtung.

Fall 2 — das Modell von jemand anderem. Ihr Zusammenfasser ruft eine Drittanbieter-API auf. Welche Rolle weist das Tool Ihnen zu, und erklärt es die Begründung? Achten Sie auf Tools, die dem gesamten Konto eine einzige Rolle zuweisen. Wenn das Tool nicht ausdrücken kann „Anbieter des KI-Systems, das wir auf einem fremden Modell gebaut haben, und zugleich Betreiber, wo wir es selbst einsetzen“, wird es viele Konstellationen eines modernen SaaS-Produkts nicht sauber abbilden.

Fall 3 — das retuschierte Marketingbild. Ein Produktfoto mit KI-erweitertem Hintergrund, veröffentlicht auf Ihrer Preisseite. Ordnet das Tool es der Deepfake-Spur zu, ordnet es es davon aus, oder stellt es es in eine Warteschlange „menschliches Urteil erforderlich“? Alle drei Antworten können vertretbar sein. Eine Antwort ohne beigefügte Begründung ist es nicht.

Fall 4 — das KI-verfasste Vorfallsupdate. Text, generiert für Ihre öffentliche Statusseite über einen Serviceausfall. Dieser Fall ist leicht falsch einzuordnen: Er gehört nicht in die Chatbot-Spur, sondern ist an Artikel 50 Absatz 4 Unterabsatz 2 zu messen. Diese Betreiberpflicht erfasst nur Text, der veröffentlicht wird, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren, und sie gilt nicht, wenn die KI-erzeugten Inhalte einem Verfahren der menschlichen Überprüfung oder redaktionellen Kontrolle unterzogen wurden und eine natürliche oder juristische Person die redaktionelle Verantwortung für die Veröffentlichung trägt. Ob eine Störungsmeldung darunter fällt, ist eine Frage des Einzelfalls – zumal solche Meldungen oft von Marketing oder SRE veröffentlicht werden statt vom Produktteam. Das richtige Verhalten ist ein begründetes Urteil, keine stille Zuordnung.

Fall 5 — die Umbenennung. Ändern Sie „Smart Reply“ in „Compose“ und deployen Sie erneut. Versioniert der Datensatz, oder wird er überschrieben? Überschreiben zerstört Ihre Fähigkeit, Fragen über die Vergangenheit zu beantworten, was der einzige Zweck des Datensatzes ist.

Fall 6 — die Frage des Prüfers. „Zeigen Sie mir, dass der Hinweis am 3. März um 14:00 Uhr live war.“ Stoppen Sie die Zeit. Unter zwei Minuten mit einem einzigen Export ist ein funktionierendes System. Zwanzig Minuten Slack-Archäologie bedeuten, dass die Nachweise in Menschen leben, nicht im Tool.

Bewerten Sie jeden Fall mit bestanden, teilweise oder nicht bestanden, bevor Sie weitermachen. Ein Anbieter, der die Fälle 1 bis 4 besteht und bei 5 und 6 versagt, hat einen guten Klassifikator und kein Gedächtnis gebaut.

Wo Behauptungen zu maschinenlesbarer Kennzeichnung leise zusammenbrechen

Kennzeichnung ist der Punkt, an dem Vergleichsartikel am unpräzisesten werden, weil „maschinenlesbare Kennzeichnung“ nach Beweis klingt und sich wie ein Hinweis verhält. HTML-Attribute, JSON-LD-Blöcke und HTTP-Response-Header sind reine Hinweis-Metadaten. Sie sind keine signierte Provenienz, sie sind keine C2PA-Content-Credentials, und sie überleben nicht, wenn ein Nutzer Cmd+Umschalt+4 drückt.

Testen Sie die Kennzeichnungskanäle jedes Anbieters der engeren Wahl anhand von fünf Transformationen und lassen Sie sich schriftlich sagen, welche Zellen sie beanspruchen:

Fünfundzwanzig Zellen, und nur eine Zeile hält fast durchweg stand – die, die für einen Menschen sichtbar ist, und selbst sie geht beim Kopieren von Text verloren. Das ist kein Argument gegen die maschinenlesbaren Kanäle; Artikel 50 Absatz 2 verpflichtet Anbieter generativer KI-Systeme, die Ausgaben in einem maschinenlesbaren Format zu kennzeichnen, und ein sichtbares Label allein liefert das nicht. Es ist ein Argument dafür, beides zu betreiben, und in der eigenen Dokumentation präzise zu sein, was jeder Kanal tatsächlich belegt. Beschreibt ein Anbieter ein HTML-Attribut als „manipulationssicher“ oder „Provenienz“, fragen Sie nach, worauf sich das stützt – ein solches Attribut ist keine signierte Herkunftsangabe. Unsere Scorecard für KI-Kennzeichnungstools vertieft, wie man sichtbare Kennzeichnung, Metadaten und Provenienz getrennt bewertet und Fehler bei Export und erneutem Upload testet.

Die 11 Felder, die aus einer Notiz einen Nachweis machen

Unabhängig davon, wie das Tool seine Datensätze nennt, sollte die Akte pro Oberfläche Folgendes enthalten:

1. Oberflächenkennung und der menschliche Name, den Ihr Team tatsächlich dafür verwendet 2. Die für diese Oberfläche beanspruchte Rolle, mit einer kurzen Begründung 3. Erfasste Spuren und ausdrücklich ausgeschlossene Spuren 4. Regelsatzversion und Datum, an dem das Urteil erstellt wurde 5. Der gerenderte Hinweistext, wortgetreu, nicht als Vorlagenverweis 6. Platzierung: Route, Auslöser und Position im Ablauf 7. Zeitstempel der Live-Verifizierung plus verwendete Methode (HTTP-Abruf, DOM-Prüfung, Screenshot-Hash) 8. Genehmiger — eine namentlich benannte Person, kein Team-Alias 9. Verknüpfter Release oder Commit 10. Nächstes geplantes Datum der Wiederverifizierung 11. Supersedes- und Superseded-by-Verweise

Feld 11 ist dasjenige, das man am ehesten auslässt, und dasjenige, das zählt, wenn jemand nach dem letzten März fragt. Und der Test für den ganzen Satz ist unumwunden: Wenn ein Feld später spurlos bearbeitet werden kann, ist es kein Nachweis – es ist eine Notiz.

Bauen oder kaufen: Nachweisereignisse zählen, nicht Nutzerlizenzen

Die Frage nach der Anzahl der Nutzerlizenzen verdeckt den eigentlichen Treiber, nämlich wie oft ein Datensatz erstellt oder aktualisiert werden muss. Zählen Sie es direkt:

> Nachweisereignisse pro Jahr = Oberflächen × betroffene Spuren pro Oberfläche × (geplante Wiederverifizierungen pro Jahr + Releases pro Jahr, die die Oberfläche betreffen)

Ein durchgerechnetes Beispiel, für diesen Artikel erfunden: Northbay Analytics, ein fiktives 40-Personen-SaaS-Unternehmen mit neun KI-Oberflächen. Sieben Oberflächen liegen in einer Spur, zwei liegen in zwei Spuren, was 11 Oberflächen-Spuren-Paare ergibt (7 × 1 + 2 × 2) – und 14, sobald man die drei Oberflächen hinzurechnet, die zusätzlich Texte zu Angelegenheiten von öffentlichem Interesse veröffentlichen und damit je eine weitere Spur berühren. Vierteljährliche Wiederverifizierung ergibt vier Ereignisse; jede Oberfläche wird von ungefähr drei Releases pro Jahr berührt. Das ergibt 14 × (4 + 3) = 98 Nachweisereignisse pro Jahr, oder ungefähr zwei pro Woche.

Schwellenwerte, über die es sich zu streiten lohnt, in diesem Rahmenwerk und anpassbar an Ihren Release-Rhythmus:

• Unter 40 Ereignissen pro Jahr. Eine Tabelle, ein Ordner mit datierten Screenshots und eine Kalendererinnerung genügen. Dafür eine Plattform zu kaufen, kauft Prozess, nicht Fähigkeit.
• 40 bis 150. Manuelle Pflege gerät gegenüber Releases in Rückstand. Der minimal tragfähige Kauf ist etwas, das die Live-Oberfläche automatisch verifiziert und einen datierten Datensatz schreibt, ohne dass sich jemand daran erinnern muss.
• Über 150. Der Engpass verschiebt sich von der Verifizierung zum Abgleich – zu wissen, welche von 300 Datensätzen aktuell sind. Hier fangen inventarzentrierte Plattformen an, ihren Preis zu rechtfertigen, und hier hört eine Offenlegungsschicht allein auf, ausreichend zu sein.

Beachten Sie, was in dieser Formel nicht auftaucht: Unternehmensgröße, Finanzierungsphase oder ob jemand in einer Vorstandssitzung das Wort „Governance“ verwendet hat.

Was Teams bei der Wahl falsch machen

Den Klassifikator nutzen und die Oberfläche für abgedeckt erklären. Die kostenlosen Checker sind nützlich und weisen selbst auf ihre Grenzen hin – der Checker der Kommission als Beta-Version, der Checker des Future of Life Institute mit dem Rat, professionelle Rechtsberatung einzuholen (Stand: September 2026). Das Urteil ist der Anfang der Arbeit. Zu oft wird das Ergebnis abgelegt, und die Arbeit endet dort.

Die falsche Funktion das Inventar besitzen lassen. Wenn die Liste der KI-Oberflächen bei Compliance liegt, veraltet sie schnell, weil Compliance nicht in den Pull-Requests steckt. Wenn sie bei Product liegt und Compliance mitliest, bleibt sie einigermaßen aktuell. Das Tool kann das nicht beheben – es ist eine Frage Ihres Organigramms, nicht der Software.

Screenshots ohne Kette. Ein Ordner mit PNGs beweist, dass jemand Screenshots gemacht hat. Ohne einen Hash, einen Zeitstempel außerhalb der eigenen Metadaten der Datei und einen Link zum Release beweist er sehr wenig darüber, was ein Nutzer gesehen hat.

Stille Reklassifizierung. Ein Anbieter aktualisiert seinen Regelsatz, Ihr Dashboard wird grün, und niemand kann rekonstruieren, wie das Urteil im April lautete. Fragen Sie konkret, wie historische Urteile fixiert werden. Das ist Achse fünf, und es ist eine Achse, die in Demos leicht untergeht.

Den DSGVO-Datensatz wiederverwenden. Verzeichnisse von Verarbeitungstätigkeiten (Art. 30 DSGVO) und interne Nachweise zu Artikel 50 beantworten unterschiedliche Fragen und haben meist unterschiedliche Verantwortliche. Das eine in das andere zu kopieren erzeugt ein Dokument, das keinen der beiden Leser zufriedenstellt.

Drei fiktive Tool-Stacks, bewertet

Alle drei sind erfundene Profile, keine Kunden.

Kestrel (Seed-Phase, drei KI-Oberflächen, eine Rolle). Ein Chat-Assistent, ein KI-gestützter E-Mail-Helfer, ein Zusammenfasser auf der API eines anderen. Ungefähr 3 × 1 × (4 + 2) = 18 Nachweisereignisse pro Jahr, bei vierteljährlicher Wiederverifizierung und etwa zwei Releases pro Oberfläche. Ein kostenloser Klassifikator plus eine Offenlegungsschicht mit 21/24 Punkten deckt in diesem Modell den Tooling-Bedarf; eine Governance-Plattform würde gut abschneiden und ein Problem lösen, das Kestrel noch nicht hat. Die Gesamtausgaben für Prozesse sollten unter einem Ingenieurtag pro Quartal bleiben.

Meridian (Series B, 14 Oberflächen, beide Rollen, keine Hochrisikoklassifizierung). Etwa 14 × 1 × 7 = 98 Ereignisse pro Jahr, das Northbay-Muster. Die interessante Entscheidung ist nicht, welche Kategorie man kauft, sondern welche zwei Bausteine man kombiniert: Die Zeilen der Abdeckungsmatrix, die ihr bestehendes Tooling nicht ausfüllt, sind Spur 1, 2 und 4 sowie die Änderungserkennung – und für Letztere hat das Team bereits eigene Prüfungen in der CI-Pipeline. Eine Offenlegungsschicht mit 20+ Punkten auf der Scorecard, kombiniert mit diesen CI-Prüfungen, schneidet in diesem Modell besser ab als eine einzelne Plattform, die über alles hinweg 17 Punkte erreicht.

Halden (Enterprise, 60+ Oberflächen, einige laut einer Ersteinschätzung mit dem offiziellen Checker möglicherweise hochriskant). Über 400 Ereignisse pro Jahr (60 × 7 = 420 schon bei einer Spur je Oberfläche), plus Pflichten weit jenseits der Transparenz – für Hochrisiko-Systeme nach Anhang III ab dem 2. Dezember 2027. Hier leistet eine inventarzentrierte Governance-Plattform die tragende Arbeit, und die Frage wird, ob sie die gerenderte UI erreicht – Achse eins – oder ob dies eine separate Schicht bleibt. In den von uns modellierten Profilen bleibt es separat.

Neun Dinge, die Sie sich vom Anbieter schriftlich geben lassen sollten

1. Für welche der sechs Pflichtenzellen erzeugt Ihr Produkt ein Artefakt, und für welche dokumentiert es nur? 2. Wie weisen Sie Anbieter- und Betreiberrollen zu, wenn beide auf ein Feature zutreffen? 3. Wie sieht Ihr Versionierungsmodell für den Regelsatz aus, und werden historische Urteile an die Version gebunden, die sie hervorgebracht hat? 4. Welche Kennzeichnungskanäle geben Sie aus, und welche der fünf oben genannten Transformationen übersteht jeder davon? 5. Kann ein Administrator einen Nachweiseintrag bearbeiten oder löschen, und hinterlässt das eine Spur? 6. Was genau ist in einem vollständigen Export enthalten, und können wir ihn ohne Ihre Software erneut verifizieren? 7. Wo werden die Daten gehostet, und wer ist der Auftragsverarbeiter? 8. Wie erfährt das Tool, dass sich eine Oberfläche geändert hat – Polling, Webhook, CI-Hook oder ein Mensch? 9. Welche der obigen Antworten sind vertraglich bindend, und welche sind Dokumentation, die sich ändern kann?

Frage 9 ist diejenige, die das Gespräch verändert. Stellen Sie sie zuletzt.

Fragen, die Menschen vor dem Kauf stellen

Reicht der offizielle Compliance Checker allein aus?

Der Compliance Checker der Kommission beantwortet die Routing-Frage – welche Regeln auf Ihr System zutreffen könnten – und er ist genau deshalb der richtige erste Anlaufpunkt, weil er frei zugänglich ist und von der Kommission auf ihrem AI Act Service Desk bereitgestellt wird (nach Angabe der Kommission derzeit eine Beta-Version; Stand: September 2026). Er rendert keinen Hinweis in Ihrem Produkt, kennzeichnet keinen Output, verifiziert nicht, dass irgendetwas live ist, und führt keinen datierten Datensatz. Ob Sie über das Urteil hinaus etwas brauchen, hängt vollständig davon ab, was das Urteil für Ihre Oberflächen sagt.

Wir betreiben bereits eine GRC-Plattform. Brauchen wir ein zweites Tool?

Füllen Sie zunächst die 30-Zellen-Matrix für Ihre bestehende Plattform aus. Wenn die unteren zwei Zeilen stark sind und die oberen vier leer, haben Sie eine Abdeckungslücke in der Produktoberfläche statt einer Tooling-Lücke in der Compliance, und die günstigste Lösung ist oft Ingenieursarbeit plus ein Verifizierungsschritt, kein zweites Abonnement. Wenn die oberen vier Zeilen teilweise gefüllt sind, führen Sie die sechs Bake-off-Fälle gegen die Plattform durch, die Sie bereits bezahlen, bevor Sie irgendetwas Neues auf die Shortlist setzen.

Bedeutet der Kauf eines Tools, dass wir abgedeckt sind?

Kein Tool klärt das. Ein Checker erzeugt aus den von Ihnen gemachten Angaben ein Routing-Urteil. Ein Widget rendert eine Zeichenkette. Ein Protokoll verzeichnet, dass die Zeichenkette zu einem Zeitpunkt live war. Ob diese Artefakte zusammen die Pflichten erfüllen, die für Ihr konkretes System in Ihrer konkreten Rolle gelten, ist eine rechtliche Beurteilung Ihrer Sachverhalte – und die gehört zu qualifizierter Rechtsberatung, informiert durch die vom Tooling erzeugten Nachweise.

Der Fall, den dieses Rahmenwerk nicht klärt

Jede oben beschriebene Bewertungsmethode setzt voraus, dass Sie eine Oberfläche benennen und ihr eine Rolle zuweisen können. Der unangenehme Fall ist das Feature, bei dem Sie eindeutig beides sind: Sie haben die Oberfläche gebaut und nutzen ein Foundation-Modell über eine API, sodass die eine Hälfte des Satzes, den ein Nutzer liest, Ihre Gestaltungsaufgabe ist und die andere Hälfte von einer Kennzeichnung abhängt, die vorgelagert von einer Partei ausgegeben wird, die Sie nicht prüfen können. Rechtlich verschiebt das die Pflicht nicht nach oben: Wer ein fremdes Modell in ein eigenes KI-System einbaut und dieses unter eigenem Namen anbietet, ist Anbieter dieses Systems (Art. 3 Nr. 3 der KI-Verordnung) und damit selbst Adressat von Artikel 50 Absatz 2 – auch wenn die technische Kennzeichnung beim Modell ansetzt. Kein Tool in irgendeiner der fünf Kategorien löst diese Aufteilung für Sie. Was ein Tool leisten kann, ist festzuhalten, welche Hälfte Sie beansprucht haben, mit welcher Begründung und an welchem Datum – und das ist es, was Sie zur Hand haben möchten, wenn jemand danach fragt.

Beginnen Sie damit, die sechs Bake-off-Fälle gegen das durchzuführen, was Sie bereits besitzen. Womöglich ist Ihre Lücke nur drei Zeilen breit, nicht fünf – und das verändert die Shortlist noch vor dem ersten Verkaufsgespräch.