EU-KI-Verordnung

Menschliche Aufsicht, die sich tatsächlich bauen lässt.

Die KI-Verordnung verlangt, dass eine Person ein Hochrisikosystem wirksam beaufsichtigen kann und dass festgehalten wird, was passiert ist. Das meiste davon ist eine Produktfrage: Wie erreiche ich die richtige Person und wie bewahre ich den Nachweis auf. Diese Seite trennt, was Sie bauen können, von dem, wofür Sie Rechtsberatung brauchen.

Was verlangt die EU-KI-Verordnung zur menschlichen Aufsicht?

Artikel 14 der Verordnung (EU) 2024/1689 verlangt, dass Hochrisiko-KI-Systeme so gestaltet sind, dass natürliche Personen sie wirksam beaufsichtigen und eingreifen oder den Betrieb unterbrechen können. Artikel 12 verlangt die automatische Aufzeichnung von Ereignissen über die Lebensdauer des Systems. Pushary übernimmt den operativen Teil: Es erreicht eine benannte Person, hält den Agenten an, bis sie entscheidet, wertet Schweigen als Ablehnung und schreibt jede Entscheidung in ein dauerhaftes Ledger.

Die Verordnung im Original: Verordnung (EU) 2024/1689 auf EUR-Lex.

Artikel für Artikel

Was der Text verlangt und welcher Teil sich bauen lässt

Artikel 14

Menschliche Aufsicht

Hochrisikosysteme müssen so entwickelt werden, dass natürliche Personen sie während der Nutzung wirksam beaufsichtigen können. Dazu gehört, die Fähigkeiten und Grenzen des Systems zu verstehen, den Automatisierungs-Bias im Blick zu behalten, die Ausgabe richtig zu deuten und entscheiden zu können, die Ausgabe nicht zu verwenden oder den Betrieb zu unterbrechen.

Das Unterbrechen ist ein Aufruf, auf den Ihr Agent wartet. Pushary hält den Lauf an, legt einer benannten Person eine einzige zugespitzte Frage auf das Gerät, das sie bei sich trägt, und gibt deren Entscheidung zurück. Das Übersteuern der Ausgabe ist eine reguläre Antwort und kein Sonderfall.

Artikel 12

Aufzeichnungspflichten

Hochrisikosysteme müssen die automatische Aufzeichnung von Ereignissen über ihre Lebensdauer technisch ermöglichen, in einem Umfang, der dem Zweck des Systems angemessen ist.

Jede Entscheidung wird in ein dauerhaftes Ledger geschrieben: die Frage in der Form, in der die Person sie gesehen hat, die gewählte Option, ihre Identität und der Zeitstempel. Das ist abfragbar und exportierbar, und aufgelöste Entscheidungen gehen als signierter Webhook in Ihren eigenen Nachweisspeicher.

Artikel 26

Pflichten der Betreiber

Betreiber von Hochrisikosystemen müssen die menschliche Aufsicht natürlichen Personen übertragen, die die erforderliche Kompetenz, Schulung und Befugnis haben, und dafür sorgen, dass diese Personen die nötige Unterstützung erhalten.

Die Aufsicht richtet sich über die ID, die Sie ohnehin für diese Person führen, an einen konkreten Menschen und nicht an einen gemeinsamen Kanal. Zwei Freigebende für dieselbe Handlung sind zwei unabhängige Aufrufe mit zwei separat zurechenbaren Ledger-Einträgen.

Artikel 50

Transparenz

Anbieter müssen dafür sorgen, dass Menschen erfahren, wenn sie mit einem KI-System interagieren, sofern das nicht ohnehin offensichtlich ist, und dass synthetische Audio-, Bild-, Video- und Textausgaben maschinenlesbar gekennzeichnet werden. Betreiber müssen Deepfakes offenlegen sowie KI-erzeugten Text, der zur Information der Öffentlichkeit über Angelegenheiten von öffentlichem Interesse veröffentlicht wird, sofern nicht eine Person die redaktionelle Verantwortung dafür trägt. Diese Pflichten gelten seit August 2026 und stehen neben dem Hochrisiko-Regime.

Das ist nicht unser Teil, und das sagen wir lieber deutlich, statt etwas anderes anzudeuten. Die Kennzeichnung Ihrer eigenen Modellausgaben gehört zu dem System, das sie erzeugt. Pushary sitzt am Freigabeschritt, und das ist eine andere Pflicht. Die Unterscheidung lohnt sich, denn die Transparenzpflichten gelten bereits, während ein großer Teil des Hochrisiko-Zeitplans das noch nicht tut.

Anhang III

Hochrisiko-Anwendungsfälle

Der Anhang listet die als hochriskant eingestuften Anwendungsfälle auf, darunter Beschäftigung, wesentliche private und öffentliche Dienstleistungen, Kreditwürdigkeit sowie Risikobewertung und Preisbildung in der Lebens- und Krankenversicherung.

Ob Ihr Produkt in den Anwendungsbereich fällt, ist eine rechtliche Frage zu Ihrem Anwendungsfall und keine technische. Sie sollte geklärt sein, bevor irgendetwas auf dieser Seite für Sie relevant wird.

Was diese Seite nicht ist

  • Das ist keine Rechtsberatung, und Pushary macht niemanden konform. Menschliche Aufsicht ist eine Eigenschaft davon, wie Ihr System gestaltet und betrieben wird. Ein Werkzeug kann einen Teil des Mechanismus liefern, nicht die Pflicht.
  • Der Zeitplan hat sich verschoben. 2026 wurden die Pflichten für eigenständige Hochrisikosysteme nach Anhang III auf Dezember 2027 verschoben und die für KI in regulierten Produkten auf August 2028, während die Transparenzpflichten nach Artikel 50 wie ursprünglich geplant im August 2026 wirksam wurden. Fristen haben sich einmal verschoben und können sich wieder verschieben. Prüfen Sie den aktuellen Stand daher auf EUR-Lex oder mit Ihrer Rechtsberatung und nicht anhand eines Datums auf einer Anbieterseite. Einen Countdown zeigen wir weiterhin nicht.
  • Pushary ist DSGVO-orientiert und selbst bewertet. Es gibt keine ISO-Zertifizierung, keinen SOC-2-Bericht und keine Konformitätsbewertung nach KI-Verordnung, und wir behaupten das auch nicht.
  • Ob Ihr Produkt überhaupt unter Anhang III fällt, ist die erste Frage, und sie gehört Ihrer eigenen Rechtsberatung. Nichts hier ist eine Einschätzung zu Ihrer Einstufung.

Der Aufsichtsschritt im Code

Das Übersteuern ist eine Antwort und kein Notausgang. Wer nicht reagiert, erzeugt eine Ablehnung und keine stillschweigende Ausführung.

import { createPusharyServer } from "@pushary/server"

const px = createPusharyServer({ apiKey: process.env.PUSHARY_API_KEY! })

// Der Aufsichtsschritt: eine benannte natürliche Person, keine Rolle, keine Warteschlange.
const decision = await px.decisions.ask({
  externalId: reviewer.id,
  type: "select",
  question: `Fall ${caseRef}: System schlägt ${proposal} vor. ${topReason}`,
  options: ["Annehmen", "Übersteuern", "Weitergeben"],
})

// Ohne Entscheidung einer Person passiert nichts. Ein Timeout gilt als Ablehnung.
if (decision.answer === "Übersteuern") return recordOverride(caseRef, decision)
if (!decision.approved) return holdForReview(caseRef)

// Der Eintrag im Ledger ist der Nachweis: wer hat was gesehen, was gewählt, wann.
return applyProposal(caseRef, proposal)

Häufige Fragen

Was verlangt die EU-KI-Verordnung zur menschlichen Aufsicht?
Artikel 14 der Verordnung (EU) 2024/1689 verlangt, dass Hochrisiko-KI-Systeme so gestaltet sind, dass natürliche Personen sie wirksam beaufsichtigen und eingreifen oder den Betrieb unterbrechen können. Artikel 12 verlangt die automatische Aufzeichnung von Ereignissen über die Lebensdauer des Systems. Pushary übernimmt den operativen Teil: Es erreicht eine benannte Person, hält den Agenten an, bis sie entscheidet, wertet Schweigen als Ablehnung und schreibt jede Entscheidung in ein dauerhaftes Ledger.
Welche Teile der KI-Verordnung gelten aktuell?
Die meisten Verbote nach Artikel 5 und die Pflicht zur KI-Kompetenz nach Artikel 4 gelten seit Februar 2025, die Transparenzpflichten nach Artikel 50 seit August 2026. Die Pflichten für eigenständige Hochrisikosysteme nach Anhang III wurden auf Dezember 2027 verschoben, die für KI in regulierten Produkten auf August 2028. Die auf dieser Seite beschriebenen Pflichten zu Aufsicht und Protokollierung sind für die meisten Anhang-III-Systeme also noch nicht anwendbar. Das spricht dafür, den Mechanismus zu bauen, bevor er verlangt wird, und nicht danach. Es ist kein Grund, ein Datum als Stichtag zu behandeln, auf den man zusprintet.
Sind wir mit Pushary konform?
Nein, und wer Ihnen das verspricht, verkauft Ihnen etwas. Konformität hängt von Ihrer Einstufung, Ihrem Risikomanagement, Ihrer Dokumentation, Ihrer Konformitätsbewertung und dem tatsächlichen Betrieb des Systems ab. Pushary liefert einen Mechanismus für das Eingreifen und den Ereignisnachweis. Die Pflicht bleibt bei Ihnen.
Reicht eine Nachricht in Slack als Aufsichtsschritt?
Das ist eine Frage für Ihre Rechtsberatung. Das praktische Problem lässt sich leichter beschreiben: Eine Chat-Nachricht wird zugestellt, ob die richtige Person sie liest oder nicht, es gibt keinen Rückgabewert, auf den das System warten kann, und nichts daran ist ausfallsicher abweisend. Wenn der Sinn der Aufsicht darin besteht, dass eine Person wirksam eingreifen kann, ist ein Aufsichtsschritt, den niemand erhalten hat, im Nachhinein schwer nachzuweisen.
Was wird gespeichert, und wo?
Standardmäßig das Entscheidungs- und Policy-Ereignis: der Fragetext, den Sie zusammengestellt haben, die Antwort, die Person und der Zeitstempel. Es ist kein Protokoll der internen Abläufe Ihres Systems und keine Kopie Ihrer Daten. Halten Sie sensible Inhalte in Ihrer eigenen Umgebung und übergeben Sie in der Frage eine Referenz und eine kurze Zusammenfassung.
Kann die freigebende Person das System übersteuern?
Ja, und für einen Aufsichtsschritt ist das meist die nützlichere Form. Verwenden Sie den Typ select mit einer Option zum Übersteuern. Die Wahl kommt als Antwort zurück und wird im Ledger als Übersteuerung und nicht als Ablehnung festgehalten. Artikel 14 spricht davon, die Ausgabe nicht zu verwenden, und genau das ist dieser Unterschied.
Funktioniert das auch für ein Produkt, das von außerhalb der EU verkauft wird?
Der Mechanismus schon, denn er adressiert über Ihre eigene Nutzer-ID und erreicht das Gerät, das diese Person bei sich trägt. Ob die Verordnung auf Sie als Anbieter oder Betreiber anwendbar ist, der ein System auf dem EU-Markt bereitstellt, ist eine rechtliche Frage. Sie lohnt sich früh und nicht spät.

Den Aufsichtsschritt bauen, den Nachweis behalten.

Ein Aufruf erreicht eine benannte Person und wartet auf sie. Bei Schweigen passiert nichts, und jede Entscheidung wird festgehalten. Was das für Ihre Pflichten bedeutet, klären Sie mit Ihrer Rechtsberatung. Das hier ist der Teil, den Sie ausliefern können.