Wie mietet man 2026 eine ausländische GPU-Cloud regelkonform? Abnahme-Checkliste für Remote-Rechenleistung

Diese Anleitung richtet sich an AI-Start-ups, Einkauf, Rechtsabteilung und Plattformengineering vor der Anmietung ausländischer GPU-Cloud-Kapazität. Sie erhalten fünf Prüfbereiche, konkrete Abnahmeschritte, Bedingungen für Freigabe oder Ablehnung sowie Anforderungen an Protokolle, Verträge und Migration.

Entscheidungsrahmen: Eine ausländische GPU-Cloud ist für ein langfristiges Training oder ein Kernmodell geeignet, wenn Betreiber, Hardwarestandort, Endnutzer, Fernzugriff, Protokolle und Exit-Mechanismus nachweisbar sind. Sie ist nicht geeignet, wenn der Anbieter nur GPU-Modell und Preis nennt, aber Eigentum, Standort oder Migrationsfähigkeit offenlässt.

Diese Prüfung gilt für AI-Start-ups, die vor der Beschaffung die Nutzbarkeit ausländischer Rechenleistung absichern müssen. Sie hilft auch Einkaufs- und Rechtsabteilungen, regulatorische Unsicherheit in Vertragsklauseln zu übersetzen, sowie Plattformteams bei Konten, Berechtigungen, Protokollen und Wiederanlauf.

Zuletzt aktualisiert am 07.09.2026. Die regulatorischen Aussagen wurden gegen die verlinkten BIS-Dokumente, die einschlägigen EAR-Abschnitte und das angegebene Federal Register-Dokument geprüft. Medienberichte über mögliche künftige Regeln für Remote-Server gelten hier ausdrücklich nicht als geltendes Recht.

Die fünf Abnahmekriterien

Wir beginnen nicht mit dem GPU-Typ. Wir vergeben zunächst je einen Prüfstatus für fünf Kriterien:

• Betreibertransparenz: Ist klar, wer Vertragspartner, Plattformbetreiber, Hardwareeigentümer und Rechenzentrumsbetreiber ist?
• Nachweisbarer Standort: Lässt sich der physische Standort der Server auf Staat- oder Regionsebene belegen?
• Endnutzerkontrolle: Sind Unternehmen, tatsächliche Bediener, Arbeitszweck und Kontostruktur bekannt?
• Protokollierung und Auditierbarkeit: Können Anmeldung, Jobs, Images, Datenübertragungen und Administratoreingriffe exportiert werden?
• Übertragbarkeit: Lassen sich Daten, Snapshots, Container, Schlüssel und Workloads bei einer Unterbrechung auf einen Ersatzstandort bewegen?

Für jedes Kriterium vergeben wir intern grün, gelb oder rot. Das ist keine Rechtsentscheidung. Es ist eine Beschaffungsentscheidung mit dokumentierter Begründung.

Grün bedeutet: schriftlicher Nachweis vorhanden, technisch prüfbar und im Vertrag verankert. Gelb bedeutet: Erklärung vorhanden, aber Nachweis unvollständig oder nur über den Support erhältlich. Rot bedeutet: Der Anbieter verweigert die Information, widerspricht sich oder macht den Nachweis von einer späteren Einzelfallentscheidung abhängig.

Eine Plattform mit fünf grünen Kriterien kann in die technische Abnahme. Bei zwei gelben Kriterien sollte der Vertrag nur mit einer Nachbesserungsfrist unterschrieben werden. Ein rotes Kriterium bei Standort, Endnutzer oder Export ist ein Grund, die Beschaffung zu pausieren. Diese interne Schwelle ersetzt keine Rechtsberatung, verhindert aber, dass ein niedriger Mietpreis die eigentliche Risikoprüfung verdrängt.

Die BIS-Regelungen zu den EAR und ihren Begriffsbestimmungen sind dabei die maßgebliche Ausgangsbasis für die Sachverhaltsprüfung. Wir lesen daraus keine pauschale Aussage „Remote-Zugriff ist erlaubt“ oder „Remote-Zugriff ist immer verboten“. Die konkrete Einordnung hängt vom Produkt, den Parteien, dem Ziel, dem Standort und dem Zugriffspfad ab.

Entscheidungshilfe für die Erstfreigabe

Die folgende Liste können Einkauf und Plattformteam gemeinsam abarbeiten:

• [ ] Vertragspartner und Betreiberrollen sind schriftlich benannt.
• [ ] Der tatsächliche GPU-Standort ist mindestens auf Staat- oder Regionsebene verifiziert.
• [ ] Endnutzer, tatsächliche Bediener und Arbeitszweck sind dokumentiert.
• [ ] Persönliche Konten, Mehrfaktor-Authentifizierung und minimale Berechtigungen sind eingerichtet.
• [ ] Login-, Job-, Image-, Daten- und Administratorprotokolle wurden testweise exportiert.
• [ ] Container, Snapshots, Daten und Schlüssel können außerhalb der Plattform gesichert werden.
• [ ] Ein Wiederanlauf auf einem Ersatzsystem wurde durchgeführt.
• [ ] Unterbrechung, Datenexport, Schlüsselwiderruf und Löschung sind vertraglich geregelt.

Wenn alle Punkte belegt sind, dann kann die Plattform für den vorgesehenen Workload freigegeben werden. Wenn nur die Aufbewahrungsdauer von Protokollen oder eine Komfortfunktion offen ist, dann ist eine befristete Freigabe mit Nachbesserungsfrist möglich. Wenn Standort, Endnutzer oder Exportfähigkeit nicht nachgewiesen werden, dann wird die Beschaffung vor der Unterschrift angehalten. Wenn der Workload nicht migriert werden kann, dann darf die Umgebung höchstens für entbehrliche Entwicklung und nicht für ein Kernmodell eingesetzt werden.

Betreiber- und Standortnachweise

Vertragspartner und Hardwareeigentum

Fordern Sie vor der Bestellung ein Dokument mit vier getrennten Rollen:

1. Vertragspartner, der Rechnung stellt.
2. Plattformbetreiber, der Konten und API verwaltet.
3. Eigentümer oder Betreiber der GPU-Server.
4. Rechenzentrum, in dem die Hardware physisch steht.

Diese Rollen dürfen identisch sein. Sie müssen es aber nicht. Ein Reseller kann eine GPU-Cloud verkaufen, während die Server von einem anderen Unternehmen betrieben werden. Für die Risikoanalyse ist dieser Unterschied wesentlich: Ein Reseller kann möglicherweise keine verbindliche Aussage über Zutritt, Hardwaretausch, Administratoren oder Standortwechsel treffen.

Wir akzeptieren keine Formulierungen wie „globale Infrastruktur“, „asiatischer Knoten“ oder „US-Zugang“ als Standortnachweis. Verlangt werden Staat, Region, Betreiberrolle und Verfahren für Hardwareverlagerungen. Wenn der Anbieter aus Sicherheitsgründen keine genaue Adresse nennen darf, kann eine belastbare Region mit einer schriftlichen Zusicherung genügen. Nicht ausreichend ist eine reine Marketingkarte.

Standort und Lieferkette

Der GPU-Standort ist nicht automatisch der Standort der Weboberfläche. Ein Dienst kann eine Kontrollplattform in einer Region betreiben und Rechenkapazität in einer anderen Region vermitteln. Ebenso können Objektspeicher, Backup, Monitoring und Support eigene Datenflüsse erzeugen.

Wir prüfen daher getrennt:

• Wo steht der Server?
• Wo liegen Images, Snapshots und Trainingsdaten?
• Wo werden Support- und Auditdaten verarbeitet?
• Welche Administratoren können auf Instanzen oder Metadaten zugreifen?
• Was passiert bei Hardwareaustausch oder Kapazitätsmangel?

Für Datenschutz und Auftragsverarbeitung sollte die regionale Zuordnung zusätzlich mit den eigenen Anforderungen der DSGVO abgeglichen werden. Die Datenschutzhinweise von ZekVPS zeigen, welche Punkte Leser bei einer eigenen Anbieterprüfung zumindest als Dokumentationskategorie berücksichtigen sollten; sie ersetzen keine individuelle Datenschutzvereinbarung.

Die BIS-Übersicht zum EAR-Teil 732 ist eine weitere offizielle Referenz für die Einordnung des Regelwerks. Für die Abnahme bedeutet das praktisch: Wir dokumentieren nicht nur „GPU in Land X“, sondern die gesamte Zugriffskette und die für den jeweiligen Workload relevanten Parteien.

Erfahrung aus der Beschaffung: Ein Anbieter, der den Hardwarestandort erst nach Zahlung oder erst nach der Bereitstellung nennt, sollte nicht als „gelb“ behandelt werden, wenn der Standort für die Freigabeentscheidung zwingend ist. Ohne prüfbare Grundlage kann das Kriterium nicht bewertet werden.

Endnutzer und Fernzugriff

Konten, Personen und Unternehmen

Ein Firmenkonto mit persönlicher Zuordnung ist die Mindestanforderung. Gemeinsame Administratorpasswörter erschweren die Zuordnung von Aktionen und erhöhen das Risiko, dass ein Dienstleister den tatsächlichen Bediener nicht erklären kann.

Vor der Freigabe dokumentieren wir:

• juristische Person und wirtschaftlich verantwortliches Team,
• Zweck der Nutzung und Modellkategorie,
• tatsächliche Nutzer und deren Regionen,
• Rollen für Betrieb, Entwicklung und Abrechnung,
• Anbieter- und Supportzugriffe,
• Verfahren bei ungewöhnlichen Anmeldungen.

Ein ausländisches AI-Team sollte nicht versuchen, regionale Unklarheit durch VPNs, wechselnde Konten oder fremde Zahlungsprofile zu verdecken. Das verschlechtert die Nachweisbarkeit. Es kann außerdem zu einer Kontosperre führen, gerade dann, wenn ein Modelltraining bereits läuft und große Datenmengen gebunden sind.

Minimale Rechte und regionale Regeln

Wir legen Rollen getrennt an:

• Entwickler dürfen Jobs starten und Logs lesen.
• Plattformadministratoren dürfen Infrastruktur ändern.
• Abrechnung darf Kosten und Limits verwalten.
• Externer Support erhält nur zeitlich begrenzten Zugriff.
• Kein Konto darf von mehreren Personen gleichzeitig als dauerhafte Identität verwendet werden.

Für Fernzugriff werden Herkunftsregionen, Mehrfaktor-Authentifizierung, IP-Beschränkungen und Alarmierung bei Anomalien geprüft. Eine starre Länderfreigabe ist nicht immer technisch möglich; dann braucht es wenigstens eine dokumentierte Ausnahmeprozedur. Wichtig ist, dass der Anbieter erklären kann, welche Daten er beim Login erfasst und wie ein verdächtiger Zugriff behandelt wird.

Die offizielle BIS-Anleitung vom 31.05.2026 sollte bei der internen Prüfung gemeinsam mit dem konkreten Sachverhalt gelesen werden. Sie ist kein Freibrief für jede Remote-Arbeitsweise. Sie liefert aber eine belastbare Grundlage, um Endnutzer, Zugriff und mögliche Umgehungssachverhalte nicht nur nach dem Verkaufsgespräch zu beurteilen.

Für produktive Systeme trennen wir außerdem Entwicklungs- und Trainingsdaten. Ein temporärer Entwicklerzugang darf nicht automatisch auf die vollständige Trainingsdatenbank, Produktionsschlüssel oder alle Snapshots zugreifen. Das reduziert nicht nur regulatorische Unsicherheit, sondern auch den Schaden bei kompromittierten Zugangsdaten.

Protokolle und Verwendungsnachweise

Was exportierbar sein muss

Ein Anbieter darf „vollständige Logs“ nicht nur als Produktversprechen nennen. Wir verlangen eine Liste der Felder und einen Testexport. Mindestens diese Ereignisse müssen nachvollziehbar sein:

• erfolgreiche und abgelehnte Anmeldungen,
• Konto- und Rollenänderungen,
• Start, Ende und Abbruch eines Jobs,
• verwendetes Image oder Container-Tag,
• Uploads, Downloads und Kopiervorgänge,
• Neustarts, Snapshot-Erstellung und Snapshot-Löschung,
• Support- und Administratoreingriffe,
• Änderungen an Netzwerkregeln und SSH-Schlüsseln.

Für jeden Datensatz prüfen wir Zeitstempel, Zeitzone, Konto-ID, Quelladresse und Ereignistyp. Fehlt die Zuordnung zum konkreten Nutzer, ist der Log für eine interne Untersuchung nur eingeschränkt brauchbar.

Aufbewahrung und Beweiswert

Eine gesetzte Aufbewahrungsdauer darf nicht frei erfunden werden. Sie muss aus dem Vertrag, einer verbindlichen Plattformdokumentation oder einem gekennzeichneten eigenen Test stammen. Wenn keine belastbare Angabe existiert, schreiben wir im Abnahmeprotokoll „nicht nachgewiesen“ und behandeln das Kriterium als gelb oder rot.

Wir exportieren Protokolle in ein eigenes System und verlassen uns nicht auf die Konsole des Anbieters. Ein Export muss auch funktionieren, wenn das Konto eingeschränkt ist oder ein Vertrag endet. Zusätzlich speichern wir Hashwerte, Exportzeitpunkt und verantwortliche Person, damit später erkennbar ist, ob ein Protokoll verändert wurde.

Die BIS-Seite zur offiziellen Guidance und zugehörigen Veröffentlichungen sollte bei Änderungen erneut geprüft werden. Für ein internes Audit ist nicht entscheidend, dass ein Anbieter „compliant“ sagt. Entscheidend ist, ob die konkrete Nutzung, die Konten und die Freigaben in einer nachvollziehbaren Akte belegt werden können.

Vertragsrisiken und Migrationsfähigkeit

Abhängigkeiten sichtbar machen

Ein GPU-Job ist selten nur eine VM. Er hängt oft an Container-Images, Basismodellen, Objektspeicher, Netzwerkregeln, Secrets, Lizenzschlüsseln und einer bestimmten CUDA- oder Treiberversion. Bei einer kurzfristigen Sperre kann daher ein Snapshot allein unbrauchbar sein.

Vor Vertragsabschluss inventarisieren wir:

• Image und Containerformat,
• Treiber- und Laufzeitabhängigkeiten,
• Datenvolumen und Übertragungsweg,
• Schlüssel und Zertifikate,
• externe Paket- und Modellquellen,
• benötigte Netzwerkports,
• Wiederherstellungsreihenfolge,
• Zielplattform für den Ersatzbetrieb.

Wir testen nicht nur, ob eine Datei heruntergeladen werden kann. Wir starten den Workload auf einem unabhängigen Ziel, prüfen Abhängigkeiten und dokumentieren, welche Schritte manuell erforderlich sind.

Klauseln für Unterbrechung und Exit

Der Vertrag sollte mindestens diese Punkte regeln:

• Auslöser und Verfahren einer Dienstunterbrechung,
• Benachrichtigung bei Kapazitätsentzug oder Kontosperre,
• Frist und Format für Datenexport,
• Zugriff auf Snapshots und Container,
• Rückgabe oder Löschung von Kundendaten,
• Widerruf von API-Schlüsseln und SSH-Zugängen,
• Verantwortlichkeit für Übertragungsfehler,
• Unterstützung bei einem Ersatzstandort,
• Kosten und Fristen für den Export,
• Nachweis über die endgültige Löschung.

Eine zugesagte Verfügbarkeit beantwortet nicht die Frage, ob ein Anbieter Kapazität aus regulatorischen, wirtschaftlichen oder technischen Gründen entziehen darf. Wir unterscheiden deshalb zwischen „Dienst ist erreichbar“ und „Workload ist tragfähig migrierbar“.

Die BIS-Veröffentlichung im Federal Register gehört in die Quellenmappe für die Rechtsprüfung. Sie ist keine individuelle Freigabe für einen konkreten Mietvertrag. Sie hilft jedoch, formale Regeländerungen und deren Geltungsbereich von Medienmeldungen über mögliche künftige Fernzugriffsregeln zu trennen.

Warnsignal: Wenn ein Anbieter Snapshots zwar erstellt, den Export aber ausschließt, ist das kein vollständiger Backup-Mechanismus. Für ein Kernmodell muss die Wiederherstellbarkeit außerhalb der Anbieterplattform nachgewiesen werden.

Durchlauf vor der Unterschrift

Wir führen die Abnahme in dieser Reihenfolge durch:

1. Anbieterakte anlegen: Vertragspartner, Betreiber, Hardwareeigentümer, Rechenzentrum und Supportrollen schriftlich erfassen.
2. Standortnachweis prüfen: Region, Datenflüsse, Speicher, Backups und mögliche Hardwareverlagerung getrennt dokumentieren.
3. Endnutzer freigeben: Firmenidentität, tatsächliche Bediener, Arbeitszweck, Regionen und Administratoren bestätigen.
4. Zugriff konfigurieren: Persönliche Konten, Mehrfaktor-Authentifizierung, Rollen, IP-Regeln und Notfallzugang einrichten.
5. Protokollexport testen: Login-, Job-, Image-, Daten- und Administratorereignisse exportieren und auf Vollständigkeit prüfen.
6. Migrationspaket bauen: Container, Snapshots, Daten, Schlüssel, Konfiguration und Wiederherstellungsanleitung außerhalb der Plattform speichern.
7. Unterbrechung simulieren: Einen Workload stoppen, Export durchführen, Schlüssel widerrufen und auf einem Ersatzsystem wieder anlaufen lassen.
8. Abweichungen entscheiden: Jedes gelbe Kriterium mit Frist und Verantwortlichem versehen; jedes rote Kriterium vor der Bestellung eskalieren.
9. Rechtsprüfung auslösen: Bei unklarer Endnutzerregel, möglicher Weitergabe, widersprüchlichem Standort oder ungewöhnlicher Zugriffskonstellation eine spezialisierte Rechtsberatung einbeziehen.

Verbindliche Entscheidungsbedingungen

• Wenn alle fünf Kriterien grün sind und der Migrationstest erfolgreich war, dann kann die Plattform für den vorgesehenen Workload freigegeben werden.
• Wenn nur Nachweise zur Protokollaufbewahrung oder zu Komfortfunktionen fehlen, dann ist eine befristete Freigabe mit schriftlicher Nachbesserung möglich.
• Wenn der physische GPU-Standort nicht genannt wird, dann wird die Beschaffung pausiert.
• Wenn der tatsächliche Endnutzer oder Arbeitszweck nicht sauber erfasst werden kann, dann erfolgt keine Nutzung für ein Kernmodell.
• Wenn Daten, Images oder Schlüssel nicht exportierbar sind, dann wird die Plattform höchstens für entbehrliche Entwicklung verwendet.
• Wenn der Anbieter die Prüfung als unnötig bezeichnet oder Antworten nur mündlich gibt, dann wird auf einen transparenten Anbieter zurückgefallen.
• Wenn eine geplante neue Remote-Server-Regel nur aus Medienberichten bekannt ist, dann wird sie als Zukunftsrisiko dokumentiert, aber nicht als bereits geltende Pflicht dargestellt.

Die EAR-Referenz zu den relevanten Regelungsbereichen bleibt dabei der Prüfanker. Die Bewertung muss zum Zeitpunkt der Nutzung erneut erfolgen, wenn BIS eine Regel, Guidance oder Vorgabe zu Endnutzern, Standorten oder Remote-Zugriff ändert.

FAQ zur Beschaffung

Die häufigste Fehlentscheidung besteht darin, eine Plattform wegen niedriger Mietkosten oder schneller Bereitstellung freizugeben. Das eigentliche Risiko liegt oft in nicht dokumentierten Rollen, fehlenden Protokollen und einem Exit, der nur auf dem Papier existiert. Deshalb sollte die Freigabeakte neben der technischen Konfiguration auch Quellen, Verantwortliche und offene Punkte enthalten.

Für macOS-Entwicklung ist die Prüfung anders gelagert als für GPU-Training. Wer eine reproduzierbare Entwicklerumgebung mit klaren Benutzerrechten benötigt, kann zusätzlich einen Mac-mini-Standort in den USA für die Fernentwicklung betrachten. Das ersetzt keine GPU-Plattform, kann aber die Workloads trennen, die keine GPU benötigen.

Einordnung gegenüber der aktuellen Lösung

Eine bestehende Lösung mit selbst verwalteten Servern, wechselnden Cloud-Konten oder informellen Fernzugängen hat meist drei konkrete Nachteile: Der physische Standort bleibt unklar, Benutzer- und Administratoraktionen sind nicht konsistent nachvollziehbar, und ein Anbieterwechsel scheitert an fehlenden Exportformaten oder fest eingebauten Zugangsschlüsseln. Eine transparente Anmietung über ZekVPS ist für temporäre Entwicklungs- und Testumgebungen deshalb oft besser prüfbar, sofern Standort, Nutzerzugriff, Protokolle und Migration vorab anhand dieser Liste bestätigt werden.

Wenn Sie eine zeitlich begrenzte Rechenumgebung benötigen, senden Sie ZekVPS am besten zuerst die geplante Laufzeit, die Zugriffsregionen und die Workload-Art. Damit lässt sich die passende Cloud- oder Remote-Umgebung gegen die hier genannten Abnahmekriterien prüfen, bevor ein langfristiger Vertrag oder ein schwer migrierbares Training beginnt.