Eine regulatorische Sandbox ist kein Gütesiegel

Ein Reallabor ist ein beaufsichtigter Lernraum. Wer es als Zertifikatsautomat versteht, verwechselt den Prozess der Erkenntnis mit dem Ergebnis einer Konformitätsbewertung.

Der Begriff „regulatorische Sandbox" weckt starke Bilder: Ein geschützter Raum, in dem ein KI-System getestet wird, bis eine Behörde grünes Licht gibt. Danach, so die verkürzte Vorstellung, sei das Produkt vertrauenswürdig, rechtssicher und marktreif. Genau diese Vorstellung ist gefährlich.

Ein KI-Reallabor schafft eine zeitlich begrenzte, kontrollierte Umgebung, in der Anbieter oder künftige Anbieter gemeinsam mit zuständigen Behörden ein innovatives System entwickeln, trainieren, testen und validieren können. Es soll rechtliche Unsicherheit reduzieren, Risiken sichtbar machen, regulatorisches Lernen fördern und den Weg zur Compliance erleichtern. Es ersetzt aber weder alle anwendbaren Gesetze noch die erforderliche Konformitätsbewertung, Marktaufsicht oder Verantwortung des Anbieters.

Die Pflicht trifft den Mitgliedstaat, nicht jedes Projekt

Artikel 57 des EU AI Act verpflichtet die Mitgliedstaaten, sicherzustellen, dass bis zum 2. August 2026 mindestens ein nationales KI-Reallabor betriebsbereit ist. Diese Pflicht wird gelegentlich falsch in eine Teilnahmeverpflichtung für höher riskante KI-Systeme umgedeutet. Der Normtext sagt etwas anderes: Der Staat muss Infrastruktur und Verfahren bereitstellen. Daraus folgt nicht, dass jedes Unternehmen oder jedes Hochrisiko-System zwingend eine Sandbox durchlaufen muss.

Teilnahme kann dennoch strategisch sinnvoll sein, besonders wenn ein innovatives System offene regulatorische Fragen berührt, mehrere Aufsichtsbereiche verbindet oder der Nachweis geeigneter Kontrollen noch nicht belastbar ist. Die richtige Frage lautet nicht „Müssen wir hinein?", sondern „Welche ungeklärte Anforderung können wir dort mit Behörden, Evidenz und kontrollierten Tests besser beantworten?"

Ein Reallabor ist ein gemeinsamer Untersuchungsprozess

Die Grundlage ist ein spezifischer Sandbox-Plan zwischen Teilnehmer und zuständiger Behörde. Er begrenzt Zeit, Umfang, Systemversion, Ziele, Testfälle, Daten, Verantwortlichkeiten und Abbruchbedingungen. Die Behörde bietet angemessene Anleitung, Aufsicht und Unterstützung, insbesondere bei Risiken für Grundrechte, Gesundheit und Sicherheit sowie bei der Wirksamkeit von Minderungsmaßnahmen.

Das ist keine ausgelagerte Produktentwicklung. Der Anbieter bleibt Eigentümer seiner Architektur, Dokumentation, Tests und Entscheidungen. Die Behörde gibt regulatorische Orientierung, nimmt aber nicht die Rolle eines Implementierungsteams ein. Eine gute Sandbox trennt deshalb drei Ebenen:

1 · Produktlernen: Funktioniert das System unter definierten Bedingungen?

2 · Risikolernen: Welche Schäden, Fehlermodi und Kontrollgrenzen werden sichtbar?

3 · Regulierungslernen: Welche Anforderungen greifen, wie können sie belegt werden und wo besteht Auslegungsbedarf?

Reife vor Eintritt spart Sandbox-Zeit

Ein unreifes Projekt ohne klaren Zweck, Verantwortliche, Datenkarte oder stabile Version verbraucht den beaufsichtigten Zeitraum mit Grundlagenarbeit. Die deutsche Pilotierung hebt deshalb ein strukturiertes Reifegradmodell hervor. Nicht maximale technische Fertigstellung ist erforderlich, wohl aber ein prüfbarer Ausgangspunkt.

Eine belastbare Bewerbung enthält Problem und Innovationsgehalt, vorgesehenen Markt- oder Einsatzkontext, Anbieter- und Betreiberrollen, Systemgrenzen, Datenflüsse, vorläufige Risikoklassifizierung, offene Rechtsfragen, vorhandene Tests und konkrete Lernziele. „Bitte prüfen Sie unser Produkt" ist kein Testplan.

Geeignet sind Fragen wie: Kann die menschliche Aufsicht die Entscheidung tatsächlich stoppen? Bleibt die Genauigkeit für relevante Untergruppen innerhalb definierter Grenzen? Welche Protokolle belegen eine Rücknahme? Wie interagieren AI Act, Datenschutzrecht und Medizinprodukterecht in diesem Workflow?

Der Abschlussbericht ist wertvoll – aber kein Siegel

Aktivitäten, Ergebnisse und Erkenntnisse werden in einem Abschlussbericht dokumentiert. Hinzu kann ein schriftlicher Nachweis der erfolgreich durchgeführten Aktivitäten kommen. Diese Artefakte können technische Dokumentation verbessern und die spätere Konformitätsbewertung erheblich beschleunigen.

Sie sind trotzdem kein universelles Gütesiegel. Sie gelten für den geprüften Scope, die damalige Version, die verwendeten Daten und die dokumentierten Annahmen. Ein späterer Modellwechsel, neue Autonomie, ein anderer Markt oder veränderte Zielgruppen können die Aussagekraft begrenzen. Auch eine erfolgreiche Teilnahme beweist nicht, dass jede spätere Nutzung konform ist.

Die sauberste Sprache lautet daher: „Das System wurde im vereinbarten Umfang beaufsichtigt erprobt; folgende Aktivitäten und Ergebnisse sind dokumentiert." Nicht: „Die Behörde hat das System zertifiziert", sofern tatsächlich keine solche Zertifizierung vorliegt.

Aufsicht und Haftung verschwinden nicht

Artikel 57 stellt klar, dass Reallabore Aufsichts- und Korrekturbefugnisse der zuständigen Behörden nicht beeinträchtigen. Bedeutende Risiken müssen angemessen gemindert werden; gelingt dies nicht, kann die Entwicklung oder Erprobung ausgesetzt werden. Die kontrollierte Umgebung ist kein rechtsfreier Raum.

Auch andere Rechtsgebiete bleiben relevant. Sobald personenbezogene Daten, Medizinprodukte, Finanzdienstleistungen, Beschäftigung, Produktsicherheit oder Cybersecurity betroffen sind, müssen die jeweils zuständigen Stellen und Anforderungen einbezogen werden. Behördenkooperation ist daher kein Verwaltungsdetail, sondern Teil der Systemarchitektur.

Datenschutz wird nicht automatisch gelockert

Artikel 59 erlaubt unter engen, kumulativen Bedingungen die Weiterverarbeitung bestimmter rechtmäßig erhobener personenbezogener Daten für ausgewählte KI-Systeme im erheblichen öffentlichen Interesse. Das ist keine allgemeine Sandbox-Ausnahme von der DSGVO.

Vorausgesetzt werden unter anderem Notwendigkeit, ein geschützter und funktional getrennter Verarbeitungsraum, autorisierter Zugriff, wirksames Risikomonitoring, Löschung, Logs und detaillierte technische Dokumentation. Die Verarbeitung darf nicht zu Maßnahmen oder Entscheidungen führen, die betroffene Personen beeinträchtigen. Wo anonymisierte, synthetische oder andere nicht personenbezogene Daten ausreichen, trägt die Sonderregel nicht.

Sandbox und Real-World Testing sind nicht dasselbe

Ein Reallabor kann beaufsichtigte Tests unter Realbedingungen enthalten. Der AI Act regelt daneben Real-World Testing von bestimmten Hochrisiko-Systemen außerhalb eines Reallabors. Dafür gelten eigene Voraussetzungen, darunter Testplan, behördliche Einbindung, Zeitgrenzen, Schutz vulnerabler Gruppen, qualifizierte Aufsicht, gegebenenfalls Einwilligung und die Möglichkeit, Systementscheidungen wirksam zurückzunehmen oder zu ignorieren.