2026 US-Regeln für Remote-AI-Server: Woche 1

Am 07.09.2026 sollten Sie bestehende Remote-AI-Server nicht allein wegen der aktuellen Berichte abschalten oder sofort umziehen: Eine neue, allgemein geltende Regel ist noch nicht bestätigt. Planen Sie stattdessen in der ersten Woche eine belastbare Bestandsaufnahme von Konten, Endnutzern, Serverknoten, Aufgaben und Migrationsfähigkeit.

Dieser Beitrag richtet sich an:

• Entwickler, die ausländische GPU-Server oder andere AI-Server nutzen und eine voreilige Migration vermeiden wollen.
• Plattformverantwortliche, die Konten, Zugriffsrechte und Workloads für eine mögliche Prüfung dokumentieren müssen.
• Management-Teams, die zwischen geltendem BIS-Recht und Medienberichten unterscheiden müssen.

Last updated: 07.09.2026. Der Status wurde anhand der veröffentlichten BIS-Seiten, der EAR-Dokumentation, des Congressional Record und der verfügbaren Medienberichte geprüft. Eine Medienmeldung ersetzt keine Veröffentlichung im Federal Register oder eine verbindliche BIS-Mitteilung.

Status zuerst prüfen: Was ist bestätigt und was nur berichtet?

Die wichtigste Trennung betrifft drei Ebenen. Erstens gelten die veröffentlichten Regeln der Export Administration Regulations, kurz EAR. Die aktuelle EAR-Übersicht des BIS ist deshalb die erste Referenz für bestehende Pflichten, nicht ein Nachrichtenartikel.

Zweitens hat das BIS die frühere AI Diffusion Rule aus der Biden-Zeit aufgehoben. Das wurde in einer offiziellen BIS-Mitteilung zur Aufhebung der AI Diffusion Rule bekanntgegeben. Daraus folgt aber nicht automatisch, dass jede Nutzung ausländischer GPU-Infrastruktur frei von Exportkontrollrisiken ist. Andere EAR-Regeln und Anti-Umgehungsanforderungen können weiterhin relevant sein.

Drittens berichten Medien im Jahr 2026 über mögliche neue Maßnahmen für den Fernzugriff auf leistungsfähige AI-Server. Der Bericht beschreibt eine mögliche politische Richtung, aber keine bereits wirksame Regel. Die Zusammenfassung der berichteten Pläne ist daher ein Hinweis zur Beobachtung, nicht die Grundlage für eine sofortige Abschaltung.

Auch der Begriff „Remote Access“ allein entscheidet nichts. Entscheidend wären später unter anderem die betroffenen Personen, Unternehmen, Server, Verwendungszwecke und Zugriffswege. Eine Diskussion im Congressional Record zu Remote Access zeigt, warum dieser Bereich politisch beobachtet wird. Sie ist jedoch nicht mit einer neuen, bereits anwendbaren Endnutzerregel gleichzusetzen.

Achtung: Wenn ein Anbieter behauptet, eine neue Regel sei bereits in Kraft, verlangen Sie die genaue BIS-Veröffentlichung, das Veröffentlichungsdatum, das Inkrafttreten und die betroffene EAR-Bestimmung. Ohne diese Angaben bleibt die Aussage unvollständig.

Für eine neutrale Einordnung des Dienstleistungsmodells sollten Sie außerdem Vertragspartner, Supportweg und technische Zuständigkeiten getrennt dokumentieren. Die Unternehmensübersicht von VPSSpark kann dabei als interne Referenz für die Anbieterprüfung dienen; sie ersetzt weder eine Rechtsprüfung noch die Kontrolle Ihrer eigenen Nutzer- und Zugriffsdaten.

Tag eins: Keine Panikentscheidung auslösen

Am ersten Tag geht es nicht um einen neuen Standort. Es geht darum, die Ausgangslage unveränderbar festzuhalten. Wer sofort Server löscht, Accounts schließt oder langfristige Ressourcen kauft, verliert den Vergleich zwischen dem bisherigen und dem später geforderten Zustand.

Legen Sie deshalb ein internes Prüfprotokoll an. Erfassen Sie für jeden AI-Server:

• Vertragspartner und Rechnungsempfänger.
• Rechtliche Einheit, Muttergesellschaft und wirtschaftlich verantwortliche Stelle.
• Serverstandort und logische Zuordnung des Knotens.
• Administratoren, Entwickler, Dienstkonten und externe Nutzer.
• Login-Regionen und verwendete VPN-, Bastion- oder Remote-Desktop-Wege.
• Modelle, Datensätze, Container-Images und aktive Trainingsaufgaben.
• Ablaufdatum von API-Schlüsseln, SSH-Schlüsseln, Tokens und Zertifikaten.
• Exportierbare Artefakte sowie Abhängigkeiten von lokalen Volumes.

Speichern Sie die Unterlagen mit Zeitstempel und beschränktem Zugriff. Die Dokumentation selbst kann personenbezogene Daten enthalten. Nach DSGVO sollten Sie daher Zweck, Aufbewahrung, Zugriff und Löschung definieren. Ein vollständiges Login-Protokoll darf nicht unkontrolliert in ein gemeinsames Tabellenblatt kopiert werden.

Vermeiden Sie am ersten Tag drei typische Fehlentscheidungen:

1. Nicht sofort alles migrieren: Eine Migration ohne Zielkriterien kann Kosten, Downtime und neue Compliance-Fragen erzeugen.
2. Nicht langfristig buchen, um Unsicherheit zu kompensieren: Ein langer Vertrag löst kein unklar dokumentiertes Nutzer- oder Zugriffsmodell.
3. Nicht Beweise vernichten: Gelöschte Accounts, Jobs und Schlüssel erschweren später die Erklärung, wer wann worauf zugegriffen hat.

Die ersten drei Tage: Konten und tatsächliche Nutzer offenlegen

Eine Kontenliste reicht nicht aus. Sie müssen zwischen dem Vertragspartner, dem tatsächlichen Bediener und dem Endkunden unterscheiden. Genau diese Ebenen werden in einem strengeren Remote-Access-Modell voraussichtlich wichtiger als die reine IP-Adresse.

Erstellen Sie je Konto einen Datensatz mit folgenden Feldern:

• Wer hat den Vertrag abgeschlossen?
• Welche Gesellschaft bezahlt?
• Welche Muttergesellschaft oder verbundene Gesellschaft ist beteiligt?
• Wer bedient den AI-Server tatsächlich?
• In welcher Region erfolgt der Login normalerweise?
• Für wen wird der Workload ausgeführt?
• Welche Rolle besitzt der Nutzer: Administrator, Entwickler, Operator oder nur Leseberechtigung?
• Gibt es gemeinsame Konten?
• Gibt es Dienstkonten ohne dokumentierten Eigentümer?
• Sind externe Auftragnehmer oder Kunden indirekt eingebunden?

Markieren Sie unbekannte Verbindungen, statt sie zu erraten. Ein „unklar“ mit Verantwortlichem und Frist ist besser als eine scheinbar vollständige, aber falsche Zuordnung. Besonders kritisch sind gemeinsam genutzte Konten, wechselnde Login-Regionen und Benutzer, die gleichzeitig mehrere rechtliche Einheiten bedienen.

Prüfen Sie außerdem die Rechtekette. Ein Entwickler sollte nicht automatisch Rechnungs-, Netzwerk- und Schlüsselrechte besitzen. Trennen Sie mindestens die Verwaltung des Accounts, die Bereitstellung von Servern, den Zugriff auf Trainingsdaten und die Rotation von Secrets. Der BIS-Leitfaden zur Vermeidung von AI-Umgehung und Fehlleitung ist dafür eine relevante offizielle Orientierung, auch wenn er keine individuelle Rechtsprüfung ersetzt.

Für Plattformteams ist die Frage nach dem Dienstleister allein zu eng. Dokumentieren Sie auch, welche Kunden oder internen Projekte den Server nutzen. Ein Anbieter kann den Vertrag mit Ihrer Firma halten, während ein anderer Endkunde die Berechnung steuert. Diese Beziehung muss im internen Inventar nachvollziehbar sein.

Die erste Woche: Workloads nach Rückfalloption sortieren

Nach der Kontenprüfung folgt die technische Entscheidung. Teilen Sie jeden Workload in drei Gruppen ein. Diese Einteilung ist kein Urteil über die Rechtmäßigkeit. Sie zeigt, wie schnell Sie bei einer offiziellen Änderung reagieren könnten.

Sofort migrierbar

Ein Workload gehört in diese Gruppe, wenn Sie ihn mit dokumentierter Konfiguration reproduzieren können. Typische Merkmale sind:

• Container-Image ist versioniert und exportierbar.
• Modellgewichte und Checkpoints liegen in einem kontrollierten Speicher.
• Abhängigkeiten sind in einer Lock-Datei oder einem reproduzierbaren Build beschrieben.
• Trainingsdaten dürfen an den vorgesehenen Zielort übertragen werden.
• Secrets lassen sich ohne manuellen Eingriff widerrufen und neu ausstellen.
• Der Job benötigt keine dauerhafte lokale Hardwarebindung.

Hier sollte Ihr Ziel nicht lauten, sofort umzuziehen. Das Ziel ist ein geprüfter Wiederanlauf. Starten Sie einen kleinen, repräsentativen Test und vergleichen Sie Logs, Checkpoint-Lesen, Datenzugriff und Ergebnisdateien.

Nur mit geplanter Unterbrechung migrierbar

Diese Kategorie umfasst Jobs mit großen Datenbeständen, langen Trainingsphasen oder schwer reproduzierbaren Umgebungen. Prüfen Sie:

• Wie wird ein Checkpoint konsistent erstellt?
• Welche Dateien ändern sich während des Exports?
• Wie wird die Integrität nach der Übertragung geprüft?
• Wie lange darf der Dienst unterbrochen sein?
• Welche Netzwerkbandbreite und welcher temporäre Speicher werden benötigt?
• Gibt es Lizenz- oder Datenschutzgrenzen für die Übertragung?

Sichern Sie nicht nur das Modell. Ein verwendbarer Wiederanlauf braucht auch Konfiguration, Tokenizer, Preprocessing, Scheduler, Versionsstand und Auswertungsprotokoll. Ohne diese Bestandteile kann ein vorhandener Checkpoint technisch vorhanden, aber praktisch wertlos sein.

Nicht kurzfristig migrierbar

Dazu zählen Workloads mit physischer Gerätebindung, proprietären Treibern, nicht exportierbaren Daten oder nicht reproduzierbaren manuellen Änderungen. Auch Jobs mit sehr großen lokalen Datenbeständen können in diese Gruppe fallen.

Für diese Aufgaben brauchen Sie keine voreilige Standortentscheidung, sondern eine Abhängigkeitenliste. Halten Sie fest, welche Komponente die Migration blockiert und ob eine Übergangslösung möglich ist. Wenn die Aufgabe geschäftskritisch ist, definieren Sie eine zweite Ausführungsumgebung, bevor eine formelle Frist veröffentlicht wird.

Erfahrungshinweis: Der häufigste Engpass ist nicht der Server selbst, sondern der fehlende Wiederanlaufnachweis. Ein Team, das Images, Checkpoints und Schlüssel getrennt kontrolliert, kann auf eine neue Regel schneller reagieren als ein Team mit mehreren Standorten, aber ohne Inventar.

Entscheidungstest: Was muss vor Freitag abgehakt sein?

Verwenden Sie die folgende Prüfliste als operative Entscheidungshilfe. Markieren Sie einen Punkt erst dann als erledigt, wenn eine verantwortliche Person den Nachweis verlinkt oder den Speicherort dokumentiert hat.

• [ ] Für jeden AI-Server sind Vertragspartner, Rechnungsempfänger und rechtliche Einheit erfasst.
• [ ] Muttergesellschaften, verbundene Unternehmen und tatsächliche Endkunden sind zugeordnet.
• [ ] Alle Administratoren, Entwickler, Dienstkonten und externen Auftragnehmer sind bekannt.
• [ ] Gemeinsame Konten wurden beendet oder mit einer begründeten Ausnahme dokumentiert.
• [ ] Login-Regionen und ungewöhnliche Zugriffswege sind nachvollziehbar.
• [ ] Serverstandort, Knotenkennung und technische Abhängigkeiten sind festgehalten.
• [ ] Container-Images, Modellgewichte und Checkpoints sind versioniert und auffindbar.
• [ ] Der Export von Trainingsdaten wurde hinsichtlich Datenschutz, Lizenz und Integrität geprüft.
• [ ] SSH-Schlüssel, API-Tokens, Zertifikate und Secrets können widerrufen werden.
• [ ] Mindestens ein repräsentativer Workload wurde in einer zweiten Umgebung gestartet oder die Blockade wurde dokumentiert.
• [ ] Für jeden Workload ist eine Kategorie festgelegt: sofort migrierbar, nur mit Unterbrechung migrierbar oder nicht kurzfristig migrierbar.
• [ ] Eine zuständige Person prüft täglich BIS-Pressemitteilungen, EAR-Änderungen und relevante Veröffentlichungen.
• [ ] Management und Technik verwenden dieselbe Version des Konten- und Workload-Inventars.

Die Entscheidung lässt sich danach mit drei Bedingungen vereinfachen:

• Wenn alle Identitäten klar sind und ein Wiederanlauf getestet wurde, können Sie den bestehenden Betrieb zunächst fortführen und die offiziellen Quellen weiter überwachen.
• Wenn Identitäten klar sind, der Wiederanlauf aber nicht getestet wurde, richten Sie einen begrenzten Doppelbetrieb ein, bevor Sie kritische Jobs verschieben.
• Wenn Vertragspartner, Endnutzer oder Zugriffswege nicht erklärbar sind, priorisieren Sie Kontenbereinigung und eine kontrollierte Migration statt einer langfristigen Verlängerung.
• Wenn Daten, Modelle oder Schlüssel nicht exportierbar sind, behandeln Sie den Workload als nicht kurzfristig migrierbar und erstellen Sie zuerst einen technischen Rückfallplan.

Drei Regelszenarien als Entscheidungstest

Planen Sie keine bestimmte politische Entwicklung als sicher ein. Testen Sie stattdessen, welche interne Reaktion zu verschiedenen möglichen Regeltypen passen würde.

Szenario A: Strengere Identitäts- und KYC-Prüfung

Wenn vor allem Vertragspartner, wirtschaftlich Berechtigte, tatsächliche Nutzer und Login-Regionen genauer geprüft würden, könnte der Weiterbetrieb möglich bleiben. Voraussetzung wäre, dass Ihre Angaben vollständig, konsistent und aktuell sind.

Weiterbetrieb: Konten sind eindeutig, gemeinsame Logins wurden abgeschafft und Nutzerbeziehungen sind dokumentiert.

Doppelbetrieb: Einzelne Nutzer oder verbundene Gesellschaften sind noch nicht abschließend geprüft, aber die Workloads können parallel in einer bereinigten Struktur getestet werden.

Migration: Der Anbieter kann die erforderlichen Informationen nicht erfassen oder akzeptiert keine kontrollierte Bereinigung der Konten.

Szenario B: Einschränkung bestimmter Endnutzer

Wenn bestimmte Organisationen, Länderbeziehungen oder Endkunden betroffen wären, wäre die technische Umgebung allein keine ausreichende Lösung. Sie müssten den tatsächlichen Leistungsempfänger und die wirtschaftliche Nutzung prüfen.

Weiterbetrieb: Das Projekt hat einen eindeutig zulässigen Endnutzer und eine nachvollziehbare Vertragskette.

Doppelbetrieb: Die Endnutzerprüfung ist offen, aber Modelle, Daten und Jobs können getrennt auf einer neutral dokumentierten Umgebung getestet werden.

Migration: Eine verbundene Partei bleibt nicht erklärbar oder die Nutzung lässt sich organisatorisch nicht sauber trennen.

Szenario C: Erweiterte Prüfung bestimmter Trainingszwecke

Eine Regel könnte stärker auf den Verwendungszweck, Modelle oder Trainingsarten zielen. Dann wäre eine einfache Umbenennung des Projekts keine Lösung. Dokumentieren Sie den Zweck, die Modelle, Datensätze, Evaluationsziele und beteiligten Teams.

Weiterbetrieb: Der Zweck ist dokumentiert und die verantwortliche Organisation kann ihn erklären.

Doppelbetrieb: Ein Teil der Forschung ist eindeutig, während einzelne Trainingsläufe eine zusätzliche Prüfung benötigen.

Migration: Sie können weder Zweck noch Endnutzer nachvollziehbar belegen oder die erforderlichen Daten nicht kontrollieren.

Die BIS-Regelungen in Teil 748 der EAR sollten Sie bei einer späteren Prüfung gemeinsam mit Ihrer Rechts- oder Exportkontrollabteilung lesen. Verlassen Sie sich nicht auf eine einzelne Zusammenfassung. Für Rechenzentren können außerdem Programme für validierte Endnutzer relevant sein; dazu gibt es eine offizielle Aktualisierung zum Validated-End-User-Programm.

Nach einer offiziellen Veröffentlichung: Sechs Prüfpunkte

Sobald eine Behörde eine neue Maßnahme veröffentlicht, lesen Sie nicht zuerst die Überschrift. Prüfen Sie in dieser Reihenfolge:

1. Ausstellende Stelle: Stammt der Text tatsächlich vom BIS oder einer anderen zuständigen US-Behörde?
2. Rechtsinstrument: Handelt es sich um eine endgültige Regel, eine vorgeschlagene Regel, eine FAQ, eine Leitlinie oder eine politische Erklärung?
3. Betroffene Subjekte: Werden Anbieter, Eigentümer, Betreiber, Nutzer, Endkunden oder bestimmte Länderbeziehungen genannt?
4. Anwendungsbereich: Geht es um Hardware, Remote Access, Software, Daten, Trainingszwecke oder eine Kombination?
5. Inkrafttreten: Gibt es ein konkretes Datum, eine Übergangsfrist oder eine sofortige Anwendung?
6. Ausnahmen und Nachweise: Welche Lizenzen, Endnutzererklärungen, Programme oder Dokumente können eine Ausnahme ermöglichen?

Prüfen Sie anschließend die Originalquelle erneut. Das BIS-Kommuniqué zum früheren Diffusionsrahmen zeigt, warum Veröffentlichung, Regeltext und Umsetzung getrennt betrachtet werden müssen.

Für die tägliche Überwachung genügt ein klarer interner Ablauf: Eine Person prüft BIS-Pressemitteilungen, eine zweite die EAR-Aktualisierungen und eine dritte dokumentiert relevante Veröffentlichungen und Fristen. Medienberichte dienen als Frühwarnung. Als Nachweis für das Inkrafttreten verwenden Sie nur die offizielle Quelle.

Was diese Lage für Ihre Infrastrukturentscheidung bedeutet

Ihre aktuelle Lösung kann kurzfristig sinnvoll bleiben, wenn die Kontenstruktur nachvollziehbar ist, der Anbieter auf Prüfungsanfragen reagiert und die wichtigen Workloads reproduzierbar gesichert sind. Ein sofortiger Umzug auf eine andere Plattform beseitigt keine unklaren Endnutzerbeziehungen und keine fehlende Schlüsselverwaltung.

Problematisch wird das bestehende Modell, wenn mehrere Personen ein gemeinsames Konto verwenden, Login-Regionen nicht erklärbar sind, der Vertragspartner vom tatsächlichen Nutzer abweicht oder Trainingsdaten und Checkpoints nicht kontrolliert exportiert werden können. Bei klassischen öffentlichen Cloud-Strukturen kommen zusätzlich wechselnde Zuständigkeiten, schwer nachvollziehbare Unterauftragnehmer und uneinheitliche KYC-Prozesse hinzu.

Für ein temporäres Prüf-, Entwicklungs- oder Migrationsfenster kann das Mieten einer klar abgegrenzten Umgebung über VPSSpark daher praktischer sein als ein langfristiger Kauf: Sie vermeiden eine sofortige Kapitalbindung, können die Konten- und Zugriffskette neu dokumentieren und testen einen Workload, ohne die bisherige Umgebung direkt zu zerstören. Das ist kein Ersatz für Exportkontrollberatung und nicht automatisch die beste Wahl für dauerhaft hohe Auslastung, spezielle physische Schnittstellen oder langfristig kalkulierbare Dauerlast.

Wenn Sie nach der internen Bestandsaufnahme eine getrennte Testumgebung benötigen, können Sie eine passende Serveroption von VPSSpark als begrenztes Prüf- oder Migrationsfenster bewerten. Entscheiden Sie über eine Anmietung erst dann, wenn feststeht, welcher Workload tatsächlich verschoben werden soll, welche Nachweise Ihr Team benötigt und wie der Zugang nach dem Test wieder entzogen wird.