In 30 Sekunden
- Unternehmen haften für ihre Endnutzer: Wer Grok über die API in ein eigenes Produkt einbaut, bleibt laut Unternehmensbedingungen vollständig verantwortlich für das Verhalten seiner Endnutzer und muss mit ihnen eigene Nutzungsregeln vereinbaren.
- Kennung erleichtert die Zuordnung: Mit dem Feld
safety_identifierkann SpaceXSI einen Richtlinienverstoß einer pseudonymen Endnutzerkennung zuordnen statt dem ganzen API-Schlüssel. Ein Schutz vor einer Sperre des gesamten Zugangs ist damit nicht garantiert. - Eigene Moderationsregeln sind schmal: Über
guidelineslassen sich nur drei Kategorien verschärfen: sexuelle Inhalte, Gewalt und Kraftausdrücke. - Sicherheitstests vorher abstimmen: Die Nutzungsrichtlinie verbietet Prompt-Injection und das Umgehen von Schutzmaßnahmen, außer mit schriftlicher Zustimmung von SpaceXSI. Nach unserer Lesart betrifft das auch Tests gegen die eigene Anwendung.
Executive Summary
Eine Kundenanwendung auf Grok-Basis verlagert Missbrauchsrisiken nicht zum Modellanbieter, sie bündelt sie beim Unternehmen. Die Leitung muss entscheiden, wer Endnutzer sperren kann, welche pseudonyme Kennung je Endnutzer an SpaceXSI geht und ob die Datenschutzlage das zulässt. Da die Nutzungsrichtlinie nach unserer Lesart auch Angriffstests gegen die eigene Anwendung erfasst, gehört die schriftliche Zustimmung von SpaceXSI vor dem ersten Test in die Projektplanung.
Was Unternehmen jetzt tun sollten
- Produkt und Recht, vor dem StartEigene Nutzungsbedingungen für Endnutzer erstellen, die mindestens so streng sind wie die Regeln von SpaceXSI, und einen Weg zum Sperren einzelner Endnutzer festlegen.
- Entwicklung, im PilotJe Endnutzer eine pseudonyme, gehashte Kennung als
safety_identifiermitsenden und intern dokumentieren, wie sie sich zurückverfolgen lässt. - Sicherheit, vor AngriffstestsSchriftliche Zustimmung von SpaceXSI für Prompt-Injection- und Umgehungstests einholen oder Tests auf eine abgestimmte Umgebung beschränken.
Der Beitrag richtet sich an Produktverantwortliche, Entwicklungsleitung und Rechtsabteilungen, die Grok über die API in ein Kundenportal, eine App oder ein Partnerangebot einbauen. Er beantwortet die Frage, was passiert, wenn nicht das eigene Team, sondern Kunden oder Partner mit Grok sprechen, und wie sich das Risiko begrenzen lässt. Sinnvoll ist es, mit den Vertragspflichten zu beginnen, weil sie bestimmen, welche technischen Kontrollen nötig sind.
Wo das Thema im Angebot von xAI steht
Die Grok-API ist eines der drei Angebote auf der Seite xAI für Unternehmen. Bisher hat AI-Fabrik vor allem untersucht, was mit Firmendaten geschieht: Verarbeitungsort und Personendaten im EU-Check, Dokumente in Files und Collections, Werkzeuge im Beitrag zur Grok-API mit Werkzeugen. Kontrollen für Nutzer im eigenen Haus behandelt der Beitrag zu Grok Business und Enterprise.
Hier geht es um den anderen Fall: Externe Endnutzer schreiben über eine Anwendung des Unternehmens an Grok. Nicht behandelt werden die Chat-Produkte von SpaceXSI selbst und Plattformen, die Grok weiterverkaufen. Für diese gelten eigene Bedingungen.
Was der Vertrag über Endnutzer sagt
Die Unternehmensbedingungen (Stand 27. Oktober 2026) erlauben ausdrücklich, Grok über die API in eigene Produkte einzubauen und diese Endnutzern bereitzustellen. Zwischen SpaceXSI und den Endnutzern entsteht dabei kein Vertrag. Das Unternehmen bleibt für alle Handlungen und Unterlassungen seiner Endnutzer voll verantwortlich.
Drei Pflichten folgen daraus. Erstens muss das Unternehmen mit seinen Endnutzern durchsetzbare Nutzungsbedingungen und eine Nutzungsrichtlinie haben, die SpaceXSI nicht schlechter schützen als die eigenen Regeln. Zweitens darf SpaceXSI die Nutzung überwachen und bei einem vermuteten Verstoß ohne Vorankündigung einzelne Eingaben oder Ausgaben drosseln oder blockieren. Drittens müssen beide Seiten bei einem Verdacht zusammenarbeiten, Protokolle bereitstellen, und das Unternehmen muss einen auffälligen Endnutzer auf Anforderung sperren.
Für den ganzen Zugang gilt eine eigene Regel: SpaceXSI kann ihn aussetzen, wenn die Nutzung den Vertrag wesentlich verletzt oder Missbrauch und illegale Aktivität einschließt. Dafür gibt es eine Frist zur Abhilfe von mindestens zwei Werktagen, die bei akuten Sicherheitsrisiken, illegaler Aktivität oder wiederholten Verstößen entfällt. Für ein Kundenportal heißt das: Ein einzelner Endnutzer, der wiederholt gegen die Regeln verstößt, kann im ungünstigen Fall den Dienst für alle anderen gefährden.
Verbotene Einsatzzwecke gelten auch für Endnutzer: Die Nutzungsrichtlinie (Stand 14. August 2026) untersagt unter anderem automatisierte Entscheidungen mit hoher Tragweite über Personen, etwa zu Kredit, Beschäftigung, Versicherung, Wohnen oder medizinischen Fragen. Eine Anwendung, die Grok solche Entscheidungen treffen lässt, verstößt damit gegen die Richtlinie, unabhängig davon, wer die Anfrage stellt. Für die EU kommt Artikel 22 DSGVO hinzu.
Wie Verstöße dem richtigen Endnutzer zugeordnet werden
Seit September 2026 nimmt die API das Feld safety_identifier an. Laut Sicherheits-FAQ ist es eine stabile, für SpaceXSI nicht aussagekräftige Kennung („opaque“), die die Anwendung jedem Endnutzer zuweist. Verstößt eine Anfrage gegen die Nutzungsregeln, kann SpaceXSI den Verstoß dieser Kennung zuordnen statt dem ganzen API-Schlüssel und sich bei Rückfragen auf sie beziehen. SpaceXSI empfiehlt ausdrücklich, einen Hash der internen Nutzerkennung zu senden und keine E-Mail-Adresse, Telefonnummer oder Anzeigenamen. Das Feld funktioniert mit Chat Completions, der Responses API, verzögerten Anfragen und der Batch API.
Die Animation zeigt schematisch, wie derselbe Verstoß mit und ohne Kennung ankommt.
Redaktionelle, schematische Darstellung von AI-Fabrik nach der Sicherheits-FAQ von SpaceXSI, abgerufen am 15. November 2026. SpaceXSI sagt nicht zu, dass bei einer Zuordnung zur Kennung der API-Schlüssel unangetastet bleibt; die Bedingungen erlauben weiterhin Drosselung und Sperren.
Die Kennung hilft, sie entlastet aber nicht vollständig. Sie macht einen Verstoß zuordenbar, die Pflicht zum Sperren des Endnutzers bleibt beim Unternehmen. Dafür braucht es intern einen Weg von der gehashten Kennung zurück zum Konto und einen Ablauf, wer eine Rückfrage von SpaceXSI annimmt und wie schnell gesperrt wird.
Datenschutzrechtlich ist die Kennung kein Freibrief. Ein Hash, den das Unternehmen selbst einem Konto zuordnen kann, ist für das Unternehmen ein pseudonymes und damit personenbezogenes Datum (Erwägungsgrund 26 DSGVO). Die Unternehmensbedingungen verlangen, Personendaten ausschließlich über die API mit Null-Speicherung zu senden. Ob SpaceXSI das Feld als Personendatum behandelt und ob es bei aktiver Null-Speicherung gespeichert wird, sagt die Dokumentation nicht. Das ist eine Frage an SpaceXSI, bevor die Kennung in einen Dienst mit Personenbezug geht.
Was eigene Moderationsregeln leisten
Seit Oktober 2026 lassen sich mit dem Feld guidelines laut Dokumentation drei Kategorien verschärfen: nsfw, violence und profanity. Die einzige Einstellung ist „ablehnen“ (decline). Grok vermeidet dann etwa sexuelle Anspielungen oder grafische Gewaltdarstellungen, beantwortet aber weiter sachliche Fragen zu diesen Themen. SpaceXSI behält sich vor, die Details zu verfeinern.
| Eigenschaft | Laut Dokumentation | Folge für eine Kundenanwendung |
|---|---|---|
| Kategorien | Nur sexuelle Inhalte, Gewalt, Kraftausdrücke | Themen wie Rechtsrat, Wettbewerber oder vertrauliche Daten brauchen eigene Prüfungen |
| Geltung | Nur für die Anfrage, die das Feld trägt | In jedem Aufruf mitsenden, am besten zentral im eigenen Gateway |
| Ausnahmen | Nicht mit Multi-Agent-Modellen und verzögerten Anfragen; Fehler 400 | Modellwahl mit der Moderationsanforderung abstimmen |
| Verhalten | Grok formuliert die Ablehnung selbst, Antwortformat unverändert | Ablehnungen tragen kein eigenes Kennzeichen, Tests müssen den Text prüfen |
Quelle: SpaceXSI, Custom Moderation Controls, abgerufen am 15. November 2026. Spalte drei ist eine Einordnung von AI-Fabrik.
Die Moderationsregeln sind damit ein Baustein für den Ton der Antworten, keine Schutzschicht gegen Missbrauch. Was Endnutzer eingeben dürfen und was die Anwendung ausgibt, muss das Unternehmen weiter selbst prüfen, etwa mit einer eigenen Eingangsprüfung vor dem Aufruf und Regeln für die Ausgabe.
Sicherheitstests: Erst die Zustimmung, dann der Angriff
Die Nutzungsrichtlinie nennt unter den verbotenen Handlungen ausdrücklich „Jailbreaking, adversarial prompting, or prompt injection“ sowie das Umgehen von Schutzmaßnahmen. Erlaubt ist das nur für ein offizielles Red Team oder mit schriftlicher Zustimmung von SpaceXSI. Genau diese Tests gehören aber zu jeder seriösen Abnahme einer Kundenanwendung, wie der Sicherheitstestplan am Beispiel DeepSeek zeigt.
Nach unserer Lesart deckt die Richtlinie dem Wortlaut nach auch Tests ab, die ein Unternehmen gegen die eigene Anwendung fährt, solange dabei Angriffseingaben an Grok gehen. Ob SpaceXSI das so durchsetzt, ist offen. Wer auf Nummer sicher gehen will, holt die schriftliche Zustimmung ein, bevor das Testteam startet, und hält Umfang, Zeitraum und verwendeten Schlüssel fest. Ein eigener Schlüssel oder ein eigenes Team für Tests erleichtert die Zuordnung.
Ein hypothetisches Beispiel: Ein Onlinehändler baut einen Grok-Assistenten für Produktfragen. Das Sicherheitsteam testet 200 Varianten eingeschleuster Anweisungen über den Produktionsschlüssel, ohne SpaceXSI zu informieren. Die automatische Missbrauchserkennung meldet den Schlüssel. Nach den Bedingungen kann SpaceXSI einzelne Anfragen drosseln oder blockieren und bei wiederholten Verstößen den Zugang ohne Abhilfefrist aussetzen. Mit Zustimmung, eigenem Testschlüssel und Kennung je Testfall wäre der Test nachvollziehbar und vom Kundenbetrieb getrennt.
Pilotfragen vor dem Start einer Kundenanwendung
- Sind unsere Nutzungsbedingungen für Endnutzer mindestens so streng wie die Nutzungsrichtlinie von SpaceXSI, und schließen sie verbotene Einsatzzwecke wie automatisierte Entscheidungen über Personen aus?
- Senden wir je Endnutzer eine gehashte Kennung als
safety_identifier, und wer kann sie im Ernstfall einem Konto zuordnen und das Konto sperren? - Hat SpaceXSI schriftlich bestätigt, wie die Kennung datenschutzrechtlich behandelt wird und ob sie bei Null-Speicherung gespeichert wird?
- Welche Inhalte prüfen wir selbst vor und nach dem Aufruf, weil die drei Kategorien von
guidelinessie nicht abdecken? - Liegt die schriftliche Zustimmung von SpaceXSI für Prompt-Injection- und Umgehungstests vor, und laufen diese Tests über einen eigenen Schlüssel?
Fazit: Die Kundenanwendung braucht ein eigenes Missbrauchsmanagement
Die Werkzeuge von SpaceXSI nehmen dem Unternehmen das Missbrauchsmanagement nicht ab, sie machen es nur besser zuordenbar. Sperrprozess, Eingangsprüfung und abgestimmte Sicherheitstests muss die Kundenanwendung selbst mitbringen. Bei Personendaten bleibt vor dem Start zu klären, ob die Kennung selbst unter die Null-Speicherung fällt.
Die nächste Entscheidung: Wer im Unternehmen nimmt Rückfragen von SpaceXSI zu Verstößen an, sperrt Endnutzer und beantragt vor dem ersten Angriffstest die schriftliche Zustimmung?
Quellen
SpaceXSI / xAI (abgerufen am 15. November 2026)
- SpaceXSI: Terms of Service – Enterprise, Stand 27. Oktober 2026
- SpaceXSI: Acceptable Use Policy, gültig ab 14. August 2026
- xAI Docs: Security FAQ (safety_identifier, Speicherung, Null-Speicherung)
- xAI Docs: Custom Moderation Controls
- xAI Docs: Release Notes (September und Oktober 2026)
Recht
- EU: Verordnung (EU) 2016/679 (DSGVO), Erwägungsgrund 26 und Art. 22
Weiterführende Artikel auf AI-Fabrik
Jeden Freitag die neuen AI-Fabrik-Analysen kompakt per E-Mail: Modelle, Tools, DSGVO und EU AI Act mit Blick auf Unternehmen im DACH-Raum. Kostenlos, jederzeit abbestellbar.
