Grok Files und Collections: Wo Firmendokumente landen und warum Personendaten draußen bleiben müssen

Der Beitrag richtet sich an IT-Leitungen, Plattform-Teams und Datenschutzverantwortliche, die Grok mit eigenen Dokumenten nutzen wollen, etwa für einen internen Assistenten oder einen Kundenservice, der aus Produktunterlagen antwortet. Wer schon den Grok-4.7-Unternehmenscheck kennt, weiß, dass die API Anfragen standardmäßig 30 Tage speichert. Bei Dokumenten geht es um mehr: um Dateien, die dauerhaft beim Anbieter liegen. Sinnvoll beginnt man deshalb nicht mit dem Upload, sondern mit der Frage, welche Dokumente überhaupt hinaus dürfen.

Wo Files und Collections im xAI-Angebot stehen

Files und Collections sind Teil der Grok API, also des Angebots für eigene Anwendungen. Die Seite xAI für Unternehmen ordnet die API neben Grok Voice und den Tarifen Grok Business und Enterprise ein. Mit den Konnektoren im Chat-Tarif, die wir im Beitrag zu Grok Business und Enterprise beschrieben haben, haben sie nichts zu tun: Dort verbinden Nutzer ihre eigenen Ablagen, hier baut ein Entwicklerteam eine Anwendung.

Laut Dokumentation unterscheiden sich die beiden Bausteine so:

Eigene Zusammenfassung nach der xAI-Dokumentation zu Files, Collections und Preisen, abgerufen am 12. November 2026. Hinzu kommen jeweils die Tokenkosten des Modells und 0,20 US-Dollar je GiB für Downloads aus dem Speicher.

Für eine Wissensbasis spricht einiges. Collections erlaubt Metadatenfelder, nach denen sich die Suche filtern lässt, etwa nach Abteilung oder Gültigkeit. Antworten tragen Quellenangaben, die auf Collection und Datei zeigen, sodass sich nachprüfen lässt, aus welchem Dokument eine Aussage stammt. Laut SpaceXSI werden in Collections gespeicherte Daten nicht zum Training genutzt. Was die Dokumentation nicht sagt: in welchem Land die Dateien liegen und wo die Suche läuft.

Warum Null-Speicherung und Collections sich ausschließen

Die Sicherheits-FAQ beschreibt die Null-Speicherung als Einstellung für das ganze Team, nicht für einzelne Schlüssel. Ist sie aktiv, speichert SpaceXSI Anfragen und Antworten nicht. Alles, was auf gespeicherte Daten angewiesen ist, fällt weg: neue Uploads und Verweise auf Files, Collections, die Batch API und gespeicherte Unterhaltungen. Bestehende Files und Collections lassen sich dann nur noch ansehen und löschen. Um die Null-Speicherung einzuschalten, muss ein Admin vorher alle Files und Collections des Teams löschen, sonst sperrt die Konsole den Schalter.

SpaceXSI rät den meisten Kunden ausdrücklich von der Null-Speicherung ab, weil sie diese Funktionen kostet. Für DACH-Unternehmen reicht diese Betriebsempfehlung aber nicht, denn der Auftragsverarbeitungsvertrag in der Fassung vom 22. September 2026 stellt eine harte Regel auf: Der Kunde muss sicherstellen, dass personenbezogene Daten über die API mit Null-Speicherung verarbeitet werden, und darf keine Personendaten an die übrigen Dienste senden. Ein Verstoß gilt als wesentliche Vertragsverletzung. Wie wir diese Regel lesen und warum sie den Enterprise-Bedingungen vorgeht, steht im Grok-EU-Check.

Zusammengenommen heißt das nach unserer Lesart: Files und Collections stehen nur in einem Team ohne Null-Speicherung zur Verfügung, und dort dürfen keine Personendaten hinein. Eine Wissensbasis mit Personendaten lässt sich in der Grok API vertragskonform nicht bei SpaceXSI ablegen.

Redaktionelle, schematische Darstellung von AI-Fabrik nach xAI-Dokumentation und Auftragsverarbeitungsvertrag, kein Produkt-Screenshot. Die Einstufung „nur ohne Personendaten“ ist unsere Lesart des Vertrags. Weg 2 setzt voraus, dass die Anfragen über ein Team mit Null-Speicherung laufen; die Übermittlung der Auszüge muss trotzdem datenschutzrechtlich geprüft werden.

Was das für den Dokumentenbestand bedeutet

Die Regel klingt eng, trifft in der Praxis aber viele Dokumente. Personenbezogen sind nicht nur Kundendaten. Auch ein Handbuch mit Ansprechpartnern, ein Protokoll mit Teilnehmerliste oder eine Präsentation mit Autorennamen enthält Personendaten. Wer Collections nutzen will, braucht deshalb eine Prüfung jedes Dokuments vor dem Upload oder einen Bestand, der von vornherein frei davon ist, etwa veröffentlichte Produktunterlagen, technische Datenblätter oder freigegebene Richtlinien ohne Namen.

Ein hypothetisches Beispiel zeigt die Abwägung. Ein Maschinenbauer will einen Assistenten für den Außendienst, der aus Bedienungsanleitungen und Ersatzteillisten antwortet. Diese Dokumente lassen sich bereinigen, Collections kommt infrage. Will derselbe Assistent auch Wartungsberichte mit Kundennamen und Technikerkürzeln durchsuchen, passt Collections nicht mehr. Dann bleibt die Suche im Unternehmen, und nur die gefundenen Abschnitte gehen als Teil der Anfrage an Grok, über ein Team mit Null-Speicherung. Eine fertige Datenschutzlösung ist das nicht: Die Null-Speicherung verhindert, dass SpaceXSI die Auszüge speichert, nicht dass sie übermittelt und an einem nicht zugesagten Ort verarbeitet werden. Ob Auszüge mit Personendaten überhaupt an Grok gehen dürfen, bleibt eine eigene Prüfung von Rechtsgrundlage, Zweck und Drittlandübermittlung.

Weil die Null-Speicherung immer für ein ganzes Team gilt, lassen sich beide Fälle nur mit getrennten Teams verbinden: eines ohne Null-Speicherung für bereinigte Dokumente in Collections, eines mit Null-Speicherung für alles mit Personenbezug. Die Konsole sieht mehrere Teams vor. Ob diese Aufteilung dem Vertrag genügt, sollte SpaceXSI schriftlich bestätigen, denn das Risiko liegt beim Kunden: Landet versehentlich ein Dokument mit Personendaten im falschen Team, ist das nach dem Vertrag ein Verstoß.

Wie man Collections kontrolliert einsetzt

Wer sich für Collections entscheidet, kann die Risiken mit den vorhandenen Mitteln begrenzen. Der wichtigste Hebel ist der Upload. Er verlangt einen Verwaltungsschlüssel mit dem Recht AddFileToCollection, getrennt von den normalen API-Schlüsseln der Anwendung. Diesen Schlüssel sollte nur ein freigegebener Prozess halten, etwa eine Pipeline, die Dokumente vor dem Upload auf Namen, E-Mail-Adressen und Telefonnummern prüft. Eine automatische Prüfung findet nicht alles, sie senkt aber die Fehlerquote gegenüber manuellem Hochladen.

Zweitens das Löschen. Files lassen sich mit einer Ablauffrist zwischen einer Stunde und 30 Tagen hochladen, danach löscht die Plattform sie. Für Collections nennt die Dokumentation keine solche Frist. Hier braucht das Unternehmen einen eigenen Löschprozess: Welche Dokumente sind veraltet, wer entfernt sie, und wer prüft das? Die Audit-Logs der Management API helfen, Änderungen nachzuvollziehen. Ob sie jeden Upload und jede Löschung in Collections erfassen, haben wir in der Dokumentation nicht belegt gefunden; das sollte vor dem Produktivgang geprüft werden.

Drittens die Abnahme. Die Quellenangaben machen jede Antwort nachprüfbar. Ein Pilot sollte das nutzen: eine feste Liste von Fachfragen mit bekannten richtigen Antworten, und für jede Antwort die Prüfung, ob die zitierte Datei die Aussage trägt. Die Wahl zwischen Stichwort-, Bedeutungs- und kombinierter Suche beeinflusst die Treffer. Laut xAI ist die kombinierte Suche voreingestellt; für Artikelnummern oder Paragraphen kann die Stichwortsuche genauer sein.

Pilotfragen vor dem ersten Upload

1. Enthält irgendein Dokument des geplanten Bestands Personendaten, auch Namen von Mitarbeitenden, und wie stellen wir sicher, dass solche Dokumente nicht hochgeladen werden?
2. Hat SpaceXSI die Aufteilung in Teams mit und ohne Null-Speicherung sowie den Speicher- und Suchort von Files und Collections schriftlich bestätigt?
3. Welche Dokumente ohne Personendaten sind trotzdem vertraulich, und wer gibt ihre Ablage bei SpaceXSI frei?
4. Wer hält den Verwaltungsschlüssel für Uploads, und wer löscht veraltete Dokumente in welchem Takt?
5. Mit welchen Fachfragen und richtigen Antworten nehmen wir die Suche ab, und wer prüft die Quellenangaben?

Fazit: Collections nur für freigegebene Bestände ohne Personenbezug

Quellen

Weiterführende Artikel auf AI-Fabrik