Ein Pilotbetrieb ist noch kein kontrollierter Realtest

Sobald echte Menschen, echte Entscheidungen oder echte Folgen beteiligt sind, reicht die Bezeichnung „Pilot" nicht mehr als Sicherheitskonzept.

Organisationen lieben Pilotprojekte. Der Begriff klingt klein, reversibel und lernorientiert. Eine begrenzte Nutzergruppe, ein kurzer Zeitraum, ein Dashboard und einige Feedbackgespräche – schon scheint ein KI-System unter realistischen Bedingungen getestet zu sein. Doch ein Pilot kann faktisch bereits produktiv wirken: Menschen ändern ihr Verhalten, Beschäftigte verlassen sich auf Empfehlungen, Daten fließen in weitere Systeme und Fehlentscheidungen erzeugen reale Nachteile.

Kontrolliertes Real-World Testing beginnt deshalb nicht mit dem Etikett, sondern mit einer überprüfbaren Testarchitektur. Sie definiert Zweck, Population, Dauer, Rollen, Schutzmaßnahmen, Stop-Regeln, Rücknahme, Datenverwendung und Evidenz. Erst wenn diese Grenzen technisch und organisatorisch wirksam sind, wird aus „Wir probieren es einmal aus" ein verantwortbarer Realtest.

Vier Betriebsformen müssen getrennt werden

Viele Missverständnisse entstehen, weil sehr unterschiedliche Versuche alle Pilot heißen.

1 · Simulation: Das System arbeitet mit synthetischen oder historischen Fällen, ohne aktuelle Prozesse oder Personen zu beeinflussen.

2 · Shadow Mode: Es verarbeitet reale Eingaben parallel zum bestehenden Prozess, seine Ausgabe steuert aber keine reale Entscheidung.

3 · Kontrollierter Realtest: Die Ausgabe kann im begrenzten Testkontext reale Handlungen beeinflussen; besondere Aufsicht, Einwilligung und Rücknahme greifen.

4 · Regulärer Betrieb: Das System ist in den vorgesehenen Prozess überführt und unterliegt dem vollständigen Betriebs- und Monitoringregime.

Diese Stufen sind keine reine Reifegradskala. Schon Shadow Mode kann sensible Daten verarbeiten oder Beschäftigte indirekt beeinflussen. Ein vermeintlicher Test wird zum Betrieb, wenn Ergebnisse außerhalb des Plans verwendet, gespeichert oder für Entscheidungen übernommen werden.

Artikel 60 setzt einen engen Rahmen

Artikel 60 des EU AI Act regelt Real-World Testing außerhalb von KI-Reallaboren für bestimmte Hochrisiko-Systeme aus Anhang III. Anbieter oder künftige Anbieter dürfen solche Tests vor Inverkehrbringen oder Inbetriebnahme allein oder mit künftigen Betreibern durchführen, wenn die genannten Bedingungen erfüllt sind. Verbote aus Artikel 5 und andere anwendbare Rechtsvorschriften bleiben unberührt.

Zu den Voraussetzungen gehören ein eingereichter Realtestplan, die Einbindung beziehungsweise Genehmigung der Marktüberwachungsbehörde, erforderliche Registrierung, eine Niederlassung oder Vertretung in der Union, Schutz bei Drittlandtransfers, Zeitgrenzen, Schutz vulnerabler Gruppen, klare Rollenvereinbarungen, informierte Einwilligung, qualifizierte Aufsicht sowie wirksame Rücknehmbarkeit der Systemausgaben.

Das ist mehr als Projektmanagement. Jede Bedingung muss in einen technischen oder organisatorischen Kontrollpunkt übersetzt werden.

Der Testplan ist ein ausführbarer Vertrag mit der Realität

Ein guter Testplan beschreibt nicht nur, was geprüft werden soll. Er legt fest, welche Systemversion, Datenquellen, Nutzergruppen, Standorte, Prozesse und Entscheidungstypen einbezogen sind. Er definiert Hypothesen, Metriken, Schwellenwerte und Abbruchkriterien. Außerdem beschreibt er Normalfall, Fehlermodi und Extremfälle.

Ein Beispiel: „Wir testen die Genauigkeit eines Priorisierungssystems" ist zu unscharf. Belastbarer ist: „Für 500 freiwillige Testfälle im Zeitraum X vergleichen wir die priorisierte Reihenfolge mit einer unabhängigen fachlichen Referenz; keine Empfehlung wird ohne Bestätigung übernommen; bei einer Differenz von mehr als Y Punkten oder einem Gruppenunterschied über Z wird der Test automatisch pausiert."

Der Plan enthält auch die Nicht-Ziele. Daten dürfen nicht für Personalbewertung, Modelltraining oder Marketinganalyse weiterverwendet werden, wenn dies nicht ausdrücklich vorgesehen und rechtlich zulässig ist. Diese Negativgrenzen verhindern Scope Creep.

Einwilligung ist ein Prozess, kein Kästchen

Artikel 61 verlangt für die erfassten Fälle freiwillige, spezifische, informierte und unmissverständliche Einwilligung. Testpersonen müssen unter anderem Art und Ziele des Tests, erwarteten Nutzen, Risiken, Dauer, Bedingungen, Rechte und Rücktrittsmöglichkeiten verstehen. Sie können grundsätzlich ohne Nachteil und ohne Begründung widerrufen und die Löschung ihrer personenbezogenen Daten verlangen.

Eine lange Datenschutzerklärung kurz vor dem Klick erzeugt noch keine informierte Entscheidung. Einwilligung wird in verständlicher Sprache, zugänglichem Format und ohne unzulässigen Druck eingeholt. Bei Abhängigkeitsverhältnissen – etwa im Beschäftigungskontext – muss besonders geprüft werden, ob Freiwilligkeit realistisch ist.

Das Consent-System braucht Versionierung. Es dokumentiert, welcher Information eine Person wann zugestimmt hat, wie ein Widerruf den Datenfluss stoppt und welche bereits ausgeführten Aktivitäten davon unberührt bleiben. Der Widerruf muss operativ genauso gut funktionieren wie der Eintritt.

Rücknehmbarkeit muss technisch bewiesen werden

Artikel 60 verlangt, dass Vorhersagen, Empfehlungen oder Entscheidungen wirksam rückgängig gemacht und ignoriert werden können. Ein menschlicher Prüfer auf dem Organigramm genügt nicht.

Der Test muss zeigen, dass die zuständige Person die Ausgabe rechtzeitig sieht, ihre Bedeutung versteht, Zugang zu Gegeninformationen hat, ohne Sanktion abweichen kann und die nachgelagerte Aktion tatsächlich stoppt. Bei automatisierten Tool-Aufrufen braucht es Transaktionsgrenzen, Freigabegates, Rücksetzpunkte oder kompensierende Aktionen.

Reversal wird mit Störfällen geprüft: falsche Identität, verspätete Daten, widersprüchliche Quelle, Ausfall eines Kontrollsystems, unerlaubter Tool-Aufruf und Widerruf während einer laufenden Verarbeitung. Ein Stop-Knopf, der nur die Benutzeroberfläche anhält, aber Hintergrundaktionen fortsetzt, ist kein wirksamer Stop.

Qualifizierte Aufsicht braucht Kapazität und Autorität

Aufsichtspersonen müssen fachlich geeignet sein und Zeit, Training sowie Befugnis besitzen. Eine Person, die gleichzeitig hunderte Fälle betreut oder negative Abweichungen nicht durchsetzen darf, ist nur dekorative Kontrolle.

Der Aufsichtsplan definiert Schichtabdeckung, maximale Fallzahl, Eskalationsbereitschaft, Vertretung, Interessenkonflikte und Entscheidungsrechte. Er misst nicht nur, wie oft Menschen überstimmen, sondern ob sie relevante Fehler erkennen und welche Konsequenzen folgen.

Automation Bias wird gezielt getestet. Manche Fälle werden mit plausibel klingenden, aber kontrolliert falschen Empfehlungen versehen. So zeigt sich, ob Aufsicht tatsächlich prüft oder lediglich bestätigt.

Vulnerable Gruppen brauchen mehr als einen Ausschlussvermerk

Personen können aufgrund von Alter oder Behinderung besonders schutzbedürftig sein; weitere Vulnerabilitäten können aus Kontext, Abhängigkeit, Sprache oder digitaler Zugänglichkeit entstehen. Schutz beginnt mit der Frage, ob ihre Einbeziehung notwendig und vertretbar ist.

Wenn sie beteiligt werden, braucht der Plan angepasste Information, barrierefreie Interaktion, engere Schwellenwerte, zusätzliche menschliche Unterstützung und schnelle Beschwerdewege. Durchschnittsmetriken dürfen keine systematischen Nachteile kleiner Gruppen verdecken.

Zeitbegrenzung verhindert schleichenden Dauerbetrieb

Der Realtest darf nicht länger dauern als für seine Ziele nötig und grundsätzlich höchstens sechs Monate; eine weitere Periode von bis zu sechs Monaten setzt vorherige Mitteilung und Begründung voraus. Diese Grenze ist kein Zielbudget, sondern eine Obergrenze.

Jeder Test besitzt ein Enddatum und einen Exit-Zustand. Nach Ablauf wird das System deaktiviert, in eine neue genehmigte Phase überführt oder nach Abschluss der erforderlichen Verfahren regulär betrieben. „Der Pilot läuft einfach weiter" ist eine unkontrollierte Inbetriebnahme.

Vorfälle führen zu Mitigation, Pause oder Abbruch

Schwerwiegende Vorfälle sind der Marktüberwachungsbehörde zu melden. Anbieter müssen unverzüglich mindern; gelingt dies nicht, wird der Test ausgesetzt oder beendet. Für die Beendigung braucht es einen schnellen Rückrufprozess.

Incident Readiness wird vor dem Start geprobt. Wer erkennt das Signal? Wer friert Logs und Versionen ein? Wer stoppt das System? Wer informiert Testpersonen, Betreiber und Behörde? Wie werden falsche Folgeaktionen korrigiert? Ein Kontaktpostfach ohne Bereitschaft ist kein Vorfallprozess.

Haftung verschwindet im Test nicht. Anbieter bleiben nach anwendbarem Unions- und nationalem Haftungsrecht für verursachte Schäden verantwortlich. Das Kostenmodell des Piloten muss daher Schutz, Rücknahme und Schadensbearbeitung berücksichtigen.

Evidenz muss Unterschiede erklären, nicht nur Mittelwerte zeigen

Ein Dashboard mit durchschnittlicher Genauigkeit reicht nicht. Der Evidenzplan verbindet Testfall, Systemversion, Inputzustand, Ausgabe, menschliche Entscheidung, Aktion, Ergebnis und Abweichung. Er segmentiert nach relevanten Gruppen und Szenarien, ohne unnötige personenbezogene Daten anzuhäufen.

Vorab festgelegte Metriken verhindern nachträgliches Schönrechnen. Negative Ergebnisse und Beinahe-Vorfälle bleiben erhalten. Änderungen am Modell oder an Schwellenwerten erzeugen neue Vergleichsgruppen; sonst vermischt das Team verschiedene Systeme zu einer scheinbar stabilen Kennzahl.

Der Übergang in den Markt ist ein eigenes Gate

Ein erfolgreicher Realtest ist kein automatischer Produktivfreigabebeschluss. Vor dem Markt- oder Betriebsübergang werden Konformitätsanforderungen, technische Dokumentation, Risikomanagement, Qualitätssystem, Registrierung, Anweisungen, menschliche Aufsicht und gegebenenfalls weitere sektorspezifische Pflichten abgeschlossen.

Testmonitoring wird anschließend nicht abgeschaltet, sondern in Post-Market-Monitoring überführt. Dabei ändern sich Population, Volumen und Fehlermuster. Der Betriebsplan definiert Drift, Beschwerden, Vorfälle, Korrekturmaßnahmen und Re-Evaluation. Der Realtest liefert den Startpunkt, nicht das Ende des Lernens.

Auch ein technisch möglicher Test kann organisatorisch unvertretbar sein

Vor dem Start prüft ein Readiness-Gate nicht nur das Modell, sondern die gesamte Schutzkapazität. Sind genügend qualifizierte Aufsichtspersonen verfügbar? Kann das Team Widerrufe und Löschungen innerhalb der zugesagten Zeit ausführen? Reichen Budget und Bereitschaft für Vorfälle, Rücknahme und mögliche Entschädigung? Ist die unabhängige Referenz belastbar?

Fehlt eine dieser Fähigkeiten, wird der Test verkleinert, in Simulation zurückgeführt oder verschoben. Technische Funktionsfähigkeit ist keine Erlaubnis, Menschen einem schlecht kontrollierten Lernprozess auszusetzen. Diese Entscheidung und ihre Gründe gehören ebenfalls in die Evidenzakte.

Übungsblatt: Entwirf einen kontrollierten Realtest

1. Ordne den Versuch Simulation, Shadow Mode, Realtest oder Betrieb zu.

2. Definiere Population, Version, Ort, Dauer und Nicht-Ziele.

3. Formuliere Hypothesen, Metriken, Schwellen und Exit-Kriterien.

4. Entwirf Einwilligung, Widerruf und Datenlöschung.

5. Beweise Aufsicht, Stop, Rücknahme und Incident Response.

6. Schütze vulnerable Gruppen und prüfe Gruppenunterschiede.

7. Plane Registrierung, Behördenkontakt und Abschlussmeldung.

8. Definiere das Gate zu Konformität und Post-Market-Monitoring.

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

Einordnung: Der Beitrag beschreibt ein fachliches Kontrollmuster und keine Rechtsberatung. Artikel 60 betrifft bestimmte Hochrisiko-KI-Systeme nach Anhang III außerhalb eines KI-Reallabors; produktspezifisches, nationales, ethisches, datenschutz- und haftungsrechtliches Recht bleibt zusätzlich zu prüfen. Nicht jeder betriebliche Pilot ist ein Realtest im Sinne dieses Artikels. Stand der redaktionellen Prüfung: 17. Juli 2026.