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.

Ein isolierter digitaler Test und ein Einsatz mit realen Personen besitzen unterschiedliche Risikoprofile. Deshalb muss jeder Testfall markieren, ob er synthetisch, simuliert, shadow-mode oder realweltlich ist und welche zusätzlichen Schutzmaßnahmen gelten.

Zugang soll fair sein, Kapazität bleibt knapp

Artikel 58 verlangt transparente und faire Auswahlkriterien, breite und gleiche Zugänglichkeit sowie eine Entscheidung grundsätzlich innerhalb von drei Monaten. Für KMU einschließlich Start-ups soll der Zugang kostenfrei sein; außergewöhnliche Kosten können fair und verhältnismäßig zurückgefordert werden.

Das bedeutet weder automatische Aufnahme noch unbegrenzte Kapazität. Ein überzeugender Antrag zeigt Innovationspotenzial, regulatorische Lernfrage, angemessenen Reifegrad und realistischen Plan. Er macht deutlich, warum die Unsicherheit nicht allein durch gewöhnliche Beratung, interne Tests oder bestehende Leitlinien gelöst werden kann.

Aus dem Reallabor muss ein übertragbares Evidenzpaket entstehen

Der größte Wert liegt nicht im Aufenthalt, sondern in verwertbarer Evidenz. Ein gutes Paket enthält System- und Datenkarte mit Versionen, Sandbox-Plan und Änderungsprotokoll, Anforderungen und zugeordnete Nachweise, Testfälle mit Metriken, Ergebnissen und Restunsicherheit, ein Risiko-, Incident- und Stop-Log, die Entscheidungen der menschlichen Aufsicht, offene Rechts- oder Standardisierungsfragen sowie den Abschlussbericht und die Übergabe an Konformitäts- und Betriebsprozesse.

Damit wird die Sandbox zum Beschleuniger. Ohne diese Überführung endet sie als interessante Demonstration, deren Erkenntnisse beim nächsten Release verschwinden.

Der richtige Ausgang ist ein begründeter nächster Schritt

Eine Sandbox muss nicht mit „bestanden" oder „durchgefallen" enden. Mögliche Ergebnisse sind: Anforderungen ausreichend belegt; zusätzliche Tests notwendig; Scope muss reduziert werden; Architektur braucht eine Kontrolle; ein anderer Rechtsrahmen ist einzubeziehen; Real-World Testing ist noch nicht vertretbar; das Vorhaben wird gestoppt.

Gerade ein früher Stop kann ein Erfolg sein, wenn er Schaden und Fehlinvestition verhindert. Regulatorisches Lernen ist dann produktiv, wenn es eine belastbare Entscheidung ermöglicht – nicht wenn es nur ein positives Label erzeugt.

Nicht jedes Problem gehört in ein Reallabor

Vor der Bewerbung lohnt eine Alternativenprüfung. Eindeutige Anforderungen werden durch Rechts- und Fachberatung, Standards, interne Evaluation oder eine Prüfstelle effizienter bearbeitet. Technische Leistungsfragen gehören zunächst in reproduzierbare Tests. Eine Sandbox ist besonders wertvoll, wenn Innovation und regulatorische Unsicherheit tatsächlich gekoppelt sind und die zuständige Behörde aus dem Fall ebenfalls verallgemeinerbares Wissen gewinnen kann.

Ein Portfolio-Gate bewertet daher Innovationsgrad, offene Regulierungsfrage, Wirkung, Reife, Behördenbedarf, Datenrisiko und erwarteten Erkenntnistransfer. Projekte ohne stabile Eigentümerschaft oder Ressourcen werden zuerst intern vorbereitet. So konkurrieren nicht die lautesten Ideen um knappe Sandbox-Kapazität, sondern die Fälle mit dem höchsten gemeinsamen Lernwert.

Änderungen müssen den Geltungsbereich aktualisieren

Während der Erprobung wird sich das System verändern. Jede relevante Änderung erhält eine Kennung, Begründung und Auswirkungsanalyse. Modell, Datenquelle, Toolberechtigung, Zielgruppe, Autonomie oder Entscheidungsschwelle können frühere Ergebnisse entwerten. Der Plan legt fest, welche Änderung innerhalb des vereinbarten Scope liegt und welche eine erneute Abstimmung verlangt.

Diese Disziplin setzt sich nach dem Exit fort. Ein Release-Register verbindet Sandbox-Evidenz mit der tatsächlich ausgelieferten Version. Nur gültige Nachweise werden in Konformitätsunterlagen übernommen. Veraltete Ergebnisse bleiben historisch erhalten, werden aber nicht als aktuelle Bestätigung präsentiert.

Beratung bereitet die Lernfähigkeit vor

Eine verantwortungsvolle Beratung verspricht keinen Behördenstempel. Sie hilft, System und Datenflüsse zu erfassen, die offene Frage zu präzisieren, zuständige Fachgebiete zu erkennen, Evidenzlücken zu markieren und einen realistischen Plan zu schreiben. Verbindliche Rechtsbeurteilung und behördliche Entscheidung bleiben bei den zuständigen Stellen.

Der beste Vorbereitungstest ist einfach: Kann das Team erklären, welche Entscheidung es nach jedem möglichen Testergebnis treffen wird? Wenn nur ein positives Ergebnis vorgesehen ist, handelt es sich um eine Marketingdemonstration. Ein echtes Reallabor braucht auch Pfade für Änderung, Einschränkung und Stop.

Übungsblatt: Entwirf einen Sandbox-Plan

1. Beschreibe System, Innovation, Rolle und geplanten Markt.

2. Benenne drei konkrete regulatorische Lernfragen.

3. Definiere Scope, Version, Dauer und Exit-Kriterien.

4. Ordne Testfälle, Daten, Metriken und Schutzmaßnahmen zu.

5. Trenne Simulation, Shadow Mode und Real-World Testing.

6. Definiere Behörden-, Anbieter-, Betreiber- und Datenschutzrollen.

7. Lege Stop-, Incident- und Änderungsprozess fest.

8. Plane das Evidenzpaket für Konformitätsbewertung und Betrieb.

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

Einordnung: Der Beitrag ist eine fachliche Umsetzungshilfe und keine Rechtsberatung. Die konkrete Rechtswirkung hängt von System, Rolle, Sektor, anwendbarem Recht und dem finalen Sandbox-Verfahren ab. Ein Reallabor ist weder pauschal verpflichtend noch eine Zertifizierung oder Haftungsfreistellung. Stand der redaktionellen Prüfung: 17. Juli 2026.