Was prüft 2026 IaaS KYC? Compliance für Übersee-GPU-Konten

Zahlung erfolgreich, Konto trotzdem in der Nachprüfung?
Schnellste Lösung: Endnutzer, Kontrollverhältnis, Login-Orte und Verwendungszweck vorab dokumentieren, persönliche Konten trennen und gemeinsame Zugangsdaten abschaffen.

Dieser Beitrag ist für Plattformadministratoren, die eine belastbare Konten- und Rechtearchitektur brauchen.
Internationale Entwicklungsteams finden hier eine Vorgehensweise für Anmeldungen aus mehreren Regionen. Compliance-Verantwortliche erhalten Kriterien, mit denen sich Nachforderungen eines IaaS-Anbieters sachlich prüfen und beantworten lassen.

Stand der Prüfung: Zuletzt aktualisiert am 07.09.2026. Die Aussagen wurden gegen Teil 748 der EAR, die BIS-Leitlinie zur Verhinderung von Umgehung und Weiterleitung sowie veröffentlichte Identitäts- und Protokollierungsleitlinien abgeglichen. Eine einheitliche, für alle Cloud-Anbieter geltende KYC-Regel für die Zukunft ist bislang nicht offiziell veröffentlicht.

Warum reicht eine erfolgreiche Zahlung für die Freigabe nicht aus?

Eine Zahlung beantwortet nur einen Teil der Prüfungsfrage: Wer bezahlt? Für eine IaaS-KYC-Prüfung ist zusätzlich entscheidend, wer die GPU-Ressource tatsächlich nutzt, wer den Vertrag kontrolliert, von welchem Ort aus zugegriffen wird und wofür die Rechenleistung eingesetzt wird.

Ein typischer Ablauf sieht so aus: Die europäische Muttergesellschaft eröffnet ein Konto, die amerikanische Tochter bezahlt die Rechnung, ein externes Entwicklerteam meldet sich aus Asien an und ein Kunde liefert das Trainingsprojekt. Die Zahlungsdaten können dabei korrekt sein. Trotzdem entsteht ein Erklärungsbedarf, weil Zahlungspartei, Vertragspartner, Endnutzer und tatsächliche Bediener nicht identisch sind.

Die Prüfung ist deshalb nicht automatisch ein Beweis für einen Gesetzesverstoß. Sie kann aus einer internen Risikobewertung des Plattformbetreibers, aus Vertragsbedingungen, aus Anforderungen an die Exportkontrolle oder aus einer Kombination dieser Faktoren entstehen. Die Plattformpolitik darf nicht pauschal als unmittelbare Vorgabe des US-Rechts dargestellt werden. Maßgeblich sind jeweils die anwendbaren Regeln und die eigenen Nutzungsbedingungen des Anbieters.

Die BIS-Hinweise zu „Know Your Customer“ und Warnsignalen zeigen jedoch, warum Anbieter auf widersprüchliche Angaben, ungewöhnliche Nutzerstrukturen und unklare Endverwendung achten. Für Sie bedeutet das: Eine Rechnung, ein Handelsregisterauszug oder eine Kreditkartenprüfung ersetzt keine nachvollziehbare Nutzungserklärung.

Die vier Prüfobjekte im Überblick

• Zahlungspartei: Welche juristische Person bezahlt und aus welchem Land stammt die Zahlung?
• Vertragspartner: Welche Gesellschaft hat das Konto eröffnet und die Nutzungsbedingungen akzeptiert?
• Endnutzer: Wer verwendet die GPU-Ressourcen für Training, Inferenz, Forschung oder einen Kundendienst?
• Tatsächliche Bediener: Welche individuellen Personen oder technischen Identitäten greifen auf Instanzen, Speicher und APIs zu?

Je weiter diese vier Angaben auseinanderfallen, desto wichtiger wird eine kurze, konsistente Erklärung. Sie sollte keine vertraulichen Kundendaten enthalten, die für den Prüfzweck nicht erforderlich sind. Eine anonymisierte Projektbeschreibung kann genügen, wenn sie Eigentum, Zweck, Verantwortlichkeit und Servicebeziehung verständlich macht.

Warum verlangen ausländische GPU-Plattformen Angaben zum Endnutzer?
Weil der Endnutzer die tatsächliche Verwendung der Rechenressource erklärt. Besonders relevant ist, ob Sie selbst trainieren, im Auftrag eines Kunden arbeiten, Rechenkapazität weiterverkaufen oder eine verwaltete Infrastruktur für Dritte betreiben. Der Anbieter möchte außerdem erkennen, ob der angegebene Geschäftszweck zu den bestellten Ressourcen und zum Zugriffsmuster passt.

Die erforderlichen Unternehmensangaben müssen zusammenpassen

IaaS KYC prüft häufig nicht nur den Namen der Gesellschaft, sondern die Verbindung zwischen Gesellschaft, Mutterunternehmen, verbundenen Unternehmen und tatsächlicher Entscheidungshoheit. Dabei sollten Sie keine eigene rechtliche Einstufung vorwegnehmen. Ihre Aufgabe besteht zunächst darin, die überprüfbaren Tatsachen sauber zu ordnen.

Für die Dokumentation gehören typischerweise folgende Informationen zusammen:

• vollständiger Name und Sitz des Vertragspartners,
• zuständige Gesellschaft für Zahlung und Rechnung,
• Muttergesellschaft oder verbundene Unternehmen, sofern sie die Nutzung oder Finanzierung steuern,
• zeichnungsberechtigte Person oder interne Genehmigungsstelle,
• verantwortlicher Projektleiter,
• Beschreibung der eigenen Nutzung oder der Kundendienstleistung,
• Länder, aus denen berechtigte Personen und technische Systeme zugreifen.

Als Nachweise kommen – abhängig von Plattform und Rechtsraum – Unternehmensregisterauszug, interne Vollmacht, Organisationsdiagramm, Projektfreigabe und eine schriftliche Endnutzererklärung infrage. Eine Plattform kann zusätzliche Dokumente verlangen; daraus folgt nicht, dass jedes verlangte Dokument in jedem Fall rechtlich zwingend ist. Prüfen Sie deshalb Zweck, Umfang, Aufbewahrung und Zugriff auf die angeforderten Daten.

Wie erkennt eine IaaS-Plattform den tatsächlichen Kontoinhaber?
Sie kombiniert normalerweise die Angaben aus Kontoeröffnung, Vertragsunterlagen, Zahlungsprofil, Identitätsprüfung, Login-Mustern, API-Nutzung und Supportkommunikation. Ein einzelnes Merkmal entscheidet nicht zwingend. Widersprüche zwischen diesen Quellen können jedoch eine manuelle Nachprüfung auslösen.

Ein Unternehmen sollte daher eine interne „Kontenakte“ führen. Darin stehen die aktuelle Vertragsgesellschaft, die genehmigten Nutzergruppen, die zulässigen Regionen, der technische Zweck und die zuständige verantwortliche Person. Ändert sich die Konzernstruktur oder der Auftraggeber, wird diese Akte aktualisiert, bevor neue Ressourcen bestellt oder Schlüssel an ein anderes Team übergeben werden.

Vorteile und Grenzen einer zentralen Kontenakte

Vorteile

• Widersprüchliche Angaben lassen sich vor einer Plattformprüfung erkennen.
• Neue Administratoren erhalten eine nachvollziehbare Übergabe.
• Support- und Compliance-Anfragen können mit konsistenten Dokumenten beantwortet werden.
• Der Umfang personenbezogener Daten bleibt auf den konkreten Zweck begrenzt.

Grenzen

• Eine interne Akte ersetzt keine Prüfung der geltenden Exportkontroll- oder Datenschutzpflichten.
• Konzernverhältnisse können sich schneller ändern als die Dokumente.
• Kundendaten dürfen nicht pauschal an einen Anbieter weitergereicht werden.
• Eine Erklärung zum Endnutzer darf keine ungesicherten Behauptungen enthalten.

Für die europäische Perspektive ist außerdem die DSGVO relevant. Sammeln Sie nur Angaben, die für Identitäts-, Sicherheits- oder Vertragszwecke erforderlich sind, legen Sie Verantwortlichkeiten fest und beschränken Sie den internen Zugriff. Die NIST-Leitlinien zur digitalen Identität bieten hierfür ein technisches Referenzmodell, ersetzen aber keine Datenschutzprüfung nach dem für Sie geltenden Recht.

Was lösen geteilte Konten und wechselnde Login-Orte aus?

Ein gemeinsames Administratorkonto verhindert eine klare Zuordnung: Nach einer Änderung an Firewall, Speicher, API-Schlüssel oder GPU-Instanz lässt sich nicht zuverlässig feststellen, welche Person gehandelt hat. Für den Plattformbetreiber sieht ein solches Konto außerdem wie eine technische Identität mit mehreren menschlichen Bedienern aus.

Häufige Auslöser für Rückfragen sind:

• mehrere Personen verwenden denselben Administratornamen,
• Anmeldungen erfolgen in kurzer Folge aus weit entfernten Regionen,
• API-Schlüssel werden per Chat oder Ticket weitergereicht,
• ein Konto wechselt ohne dokumentierten Anlass zwischen Entwicklungs-, Kunden- und Trainingsprojekten,
• ein ausgeschiedener Mitarbeiter bleibt technisch berechtigt,
• ein Dienstkonto besitzt weitreichende Rechte, obwohl es nur eine einzelne Aufgabe ausführt.

Ein Wechsel des Login-Ortes ist nicht automatisch verdächtig. Internationale Teams arbeiten legitim über verschiedene Standorte, Reisen und Homeoffice-Verbindungen. Entscheidend ist, ob die Abweichung erklärbar, autorisiert und im Protokoll nachvollziehbar ist.

Was muss ein internationales Team für Zugriffe aus mehreren Regionen vorbereiten?
Legen Sie vor dem ersten Zugriff eine genehmigte Nutzer- und Länderübersicht an. Ordnen Sie jeder Person eine eigene Identität zu, dokumentieren Sie Rolle und Projekt und definieren Sie, welche Regionen für welche Arbeitsaufgaben vorgesehen sind. Bei Reisen oder Notfallzugriffen sollte ein befristeter Freigabeprozess existieren, statt dauerhaft weitreichende Rechte zu vergeben.

Die technische Basis besteht aus individuellen Konten, Mehrfaktor-Authentifizierung, rollenbasierten Berechtigungen und getrennten Dienstidentitäten. Die IAM-Empfehlungen für sichere Kontenverwaltung nennen unter anderem die Vermeidung gemeinsamer Zugangsdaten, die Nutzung individueller Identitäten und die Begrenzung von Berechtigungen. Für technische Dienstkonten beschreibt die Anleitung zur Absicherung von Servicekonten ähnliche Grundsätze.

Schrittfolge für eine belastbare Zugriffsumgebung

1. Bestandsaufnahme: Erfassen Sie alle menschlichen Benutzer, Dienstkonten, API-Schlüssel, Administratorrollen und automatisierten Jobs.
2. Identitäten trennen: Ersetzen Sie gemeinsam genutzte Konten durch persönliche Identitäten mit nachvollziehbarer Zuordnung.
3. Rollen definieren: Trennen Sie beispielsweise Abrechnung, Plattformadministration, Projektbetrieb, Monitoring und Support.
4. Mehrfaktor-Authentifizierung aktivieren: Setzen Sie diese mindestens für privilegierte Rollen und Konten mit Zugriff auf Schlüssel oder Kundendaten voraus.
5. Berechtigungen reduzieren: Geben Sie nur die Ressourcen, Aktionen und Projekte frei, die für die jeweilige Aufgabe nötig sind.
6. Schlüssel kontrollieren: Hinterlegen Sie technische Geheimnisse in einem geeigneten Geheimnisspeicher, begrenzen Sie ihre Reichweite und wechseln Sie sie nach einem dokumentierten Anlass.
7. Regionen erklären: Halten Sie geplante Länder, Reisezugriffe und externe Dienstleister in einer genehmigten Liste fest.
8. Austritte bearbeiten: Sperren Sie persönliche Zugänge, widerrufen Sie Sitzungen und rotieren Sie gemeinsam genutzte technische Geheimnisse unmittelbar nach dem Ausscheiden.

Die genaue Aufbewahrungsdauer und der Inhalt der Protokolle richten sich nach Plattformvertrag, Sicherheitskonzept und anwendbarem Recht. Der NIST-Leitfaden zur Log-Verwaltung SP 800-92 beschreibt die organisatorischen und technischen Grundlagen, aber keine pauschal für jedes Unternehmen geltende Frist.

Wie belegen Sie Nutzungszweck und Modellverantwortung?

Eine Nachforderung zum Verwendungszweck wird schwierig, wenn das Team nur „KI-Training“ als Antwort liefern kann. Dieser Begriff ist zu breit. Sie sollten intern unterscheiden, ob GPU-Ressourcen für eigene Forschung, für einen konkreten Kundenauftrag, für eine Plattformleistung oder für die Weitervermietung eingesetzt werden.

Für jedes größere Projekt sollte der verantwortliche Leiter mindestens folgende Punkte erklären können:

• Wer ist Eigentümer oder Auftraggeber des Modells?
• Wird das Modell intern trainiert, angepasst, evaluiert oder nur betrieben?
• Welche Gesellschaft trägt die technische und vertragliche Verantwortung?
• Werden Ressourcen an Dritte weitergegeben oder nur im eigenen Auftrag genutzt?
• Welche Datenkategorien werden verarbeitet?
• Welche Personen dürfen Aufgaben starten, stoppen oder Ergebnisse abrufen?
• Welche Regionen sind für Daten, Verwaltung und Zugriff vorgesehen?

Sammeln Sie dabei keine unnötigen sensiblen Informationen. Ein Anbieter braucht nicht automatisch Rohdaten, vollständige Kundendateien oder interne Quelltexte, wenn eine abstrahierte Zweckbeschreibung für die Prüfung ausreicht. Formulieren Sie den Nachweis so, dass die Nutzung verständlich, aber nicht unnötig offen ist.

Ein besonders riskanter Widerspruch entsteht, wenn ein Konto als interne Forschungsumgebung beschrieben wird, die Ressourcen aber nachweislich von mehreren unabhängigen Kunden verwendet werden. Das kann eine andere Vertrags- und Kontrollstruktur erfordern. Umgekehrt ist ein regulärer Managed-Service-Betrieb nicht automatisch unzulässig; er muss nur korrekt beschrieben und vertraglich abgedeckt sein.

Dokumente für eine Nachprüfung vorbereiten

Erstellen Sie eine kurze, freigabefähige Antwortvorlage mit folgenden Abschnitten:

• juristische und wirtschaftliche Zuordnung des Kontos,
• verantwortliche Kontaktperson,
• Endnutzer und Art der Nutzung,
• berechtigte Bediener und technische Dienstidentitäten,
• vorgesehene Zugriffsregionen,
• Umgang mit Kundendaten,
• Bestätigung, dass keine Zugangsdaten gemeinsam genutzt werden,
• Verweis auf interne Genehmigungs- und Protokollierungsprozesse.

Vermeiden Sie absolute Aussagen wie „alle Nutzer sitzen in einem Land“, wenn Bereitschaftsdienste, Dienstleister oder Reisen das nicht gewährleisten. Besser ist eine überprüfbare Formulierung mit Ausnahmeprozess und Verantwortlichkeit.

Protokolle für eine erfolgreiche Erklärung

Eine Antwort ohne Logs bleibt oft eine Behauptung. Sie sollten mindestens nachvollziehen können, wer sich wann anmeldete, welche Rolle verwendet wurde, welche Berechtigung geändert wurde, welcher Auftrag gestartet oder beendet wurde und ob Daten oder Schlüssel bewegt wurden.

Sinnvolle Protokollkategorien sind:

• erfolgreiche und abgelehnte Anmeldungen,
• verwendete Identität und Rolle,
• Quellregion oder technische Herkunft des Zugriffs, soweit rechtlich und vertraglich zulässig,
• Änderungen an Rollen, Firewall-Regeln, Speichern und Schlüsseln,
• Start, Stopp und Änderung von GPU-Aufträgen,
• API-Aufrufe mit privilegierter Wirkung,
• Datenübertragungen und relevante Export- oder Download-Ereignisse,
• Freigaben, Ausnahmen und Ticketverweise.

Protokolle müssen gegen nachträgliche Manipulation geschützt werden. Zugleich dürfen sie nicht für alle Beschäftigten offenliegen. Trennen Sie operative Einsicht, Sicherheitsanalyse und administrative Löschung. Legen Sie eine dokumentierte Aufbewahrungsregel fest, die Plattformbedingungen, gesetzliche Anforderungen, Datenschutz und tatsächlichen Untersuchungsbedarf berücksichtigt.

Abhakbare Prüfung vor der Kontoeröffnung

• [ ] Vertragspartner, Zahlungspartei und Endnutzer sind schriftlich zugeordnet.
• [ ] Muttergesellschaften und relevante Kontrollbeziehungen sind intern dokumentiert.
• [ ] Für jedes Projekt gibt es eine verantwortliche Person und einen klaren Nutzungszweck.
• [ ] Persönliche Benutzerkonten ersetzen gemeinsame Administratorzugänge.
• [ ] Mehrfaktor-Authentifizierung ist für privilegierte Identitäten aktiviert.
• [ ] Rollen und Dienstkonten besitzen nur die erforderlichen Berechtigungen.
• [ ] Zugriffsregionen und zulässige Reise- oder Notfallzugriffe sind festgelegt.
• [ ] API-Schlüssel werden nicht per E-Mail oder Chat weitergegeben.
• [ ] Login-, Berechtigungs-, Auftrags- und Datenübertragungsereignisse werden erfasst.
• [ ] Es gibt einen Prozess für Mitarbeiteraustritt, Schlüsselrotation und Sitzungswiderruf.
• [ ] Eine datensparsame Antwort auf Endnutzer- und Verwendungsfragen ist freigegeben.
• [ ] Unklare Exportkontroll-, Datenschutz- oder Konzernfragen werden an qualifizierte Berater eskaliert.

Mit dieser Liste können Sie vorab feststellen, ob eine Nachforderung mit vorhandenen Fakten beantwortbar ist. Sie verhindert nicht jede manuelle Prüfung. Sie reduziert aber die Wahrscheinlichkeit, dass Ihr Team wegen widersprüchlicher Kontoinformationen, fehlender Zuständigkeiten oder nicht erklärbarer Zugriffe ins Stocken gerät.

Wann reicht interne Administration nicht mehr aus?

Nicht jede Frage sollte der Plattformadministrator allein entscheiden. Professionelle Beratung ist sinnvoll, wenn die tatsächliche Kontrolle über mehrere Gesellschaften verteilt ist, wenn ein Kunde in einer sensiblen Branche arbeitet, wenn Daten grenzüberschreitend übertragen werden oder wenn der Anbieter eine Erklärung zu Exportkontrolle und Endverwendung verlangt.

Auch bei der Bewertung eines Weiterverkaufsmodells ist Vorsicht angebracht. Eigene GPU-Nutzung, Training im Kundenauftrag, Managed Hosting und reine Kapazitätsweitergabe können technisch ähnlich aussehen, aber vertraglich und regulatorisch unterschiedlich behandelt werden. Lassen Sie die Einordnung prüfen, statt aus einer technischen Architektur automatisch eine rechtliche Schlussfolgerung abzuleiten.

Bis zum 07.09.2026 ist bestätigt, dass die einschlägigen BIS-Unterlagen Anforderungen rund um Endnutzer, IaaS-Fernnutzer und die Vermeidung unbefugten Zugriffs berücksichtigen. Welche Felder ein konkreter Anbieter erhebt, hängt weiterhin von den anwendbaren Regeln und seiner eigenen Risikopolitik ab. Berichte über eine künftig einheitliche Cloud-KYC-Regel sind daher als nicht offiziell bestätigte Entwicklung zu behandeln.

Für Ihr Team lautet die operative Konsequenz: Bauen Sie nicht auf eine einzelne Rechnung oder auf die Annahme, dass ein ausländisches Rechenzentrum jede Nutzung automatisch abdeckt. Halten Sie Identität, Kontrollbeziehung, Zugriffsort, Zweck und Protokoll in einer gemeinsamen, datensparsamen Struktur zusammen.

Wenn Sie heute mit gemeinsam genutzten Konten, wechselnden Standorten oder unklaren Projektgrenzen arbeiten, hat die bestehende Lösung drei konkrete Nachteile: Verantwortlichkeiten bleiben im Vorfall unklar, eine Nachprüfung kann den GPU-Betrieb unterbrechen, und sensible Schlüssel lassen sich nach einem Personalwechsel schwer vollständig kontrollieren. Eine gemietete Mac-Umgebung von Kvmjet kann für zeitlich begrenzte Entwicklungs- und Testaufgaben übersichtlicher sein, wenn persönliche Zugänge, klar getrennte Rollen und ein dokumentierter Zugriff benötigt werden. Prüfen Sie vorab dennoch Ihre Plattformbedingungen, Ihre Datenflüsse und die Frage, ob Sie physische Schnittstellen oder dauerhaft hohe Last benötigen.

Für eine konkrete Einordnung Ihrer geplanten Kontenstruktur können Sie Kvmjet direkt kontaktieren. Ergänzend sollten Sie die Hinweise zum Datenschutz prüfen und Ihre Teamgröße, Login-Regionen sowie Aufgabentypen mit der gewünschten Remote-Entwicklungsumgebung abgleichen.