Data confidentiality in collections
On this page
Your documents remain yours
This is the first question any serious stakeholder asks in a RAG project, whether legal counsel or CISO: if we send our contracts to xAI, do they train Grok on them? The answer is no. xAI guarantees that data stored in collections is not used to train models. This guarantee covers three distinct aspects worth separating, because they address different concerns.
First, no training: files uploaded to collections do not feed Grok or any other xAI model. Second, isolation: your collections are accessible only through your own API keys. Finally, deletion: when you delete a file or collection, the data and corresponding indexes are indeed deleted, which is the technical condition for honoring an erasure request.
In practice, this opens collections to documents you wouldn’t entrust to a consumer service: contracts and legal documents, internal financial reports, proprietary technical documentation, HR data and internal policies, confidential correspondence.
Security relies on your keys
Each pair of keys—API Key and Management API Key—defines an access scope. A third party who knew the identifier col_rh_policies could do nothing with it without your keys: there is no public path to a collection. The consequence is direct and unambiguous: the confidentiality of your documents is worth exactly what the protection of your keys is worth.
Store them in environment variables, never hard-coded in your code, where they would end up in your Git history.
import os
client = Client(
api_key=os.getenv("XAI_API_KEY"),
management_api_key=os.getenv("XAI_MANAGEMENT_API_KEY")
)
The rest is standard hygiene, yet neglected just as often. Rotate your keys periodically, and immediately after any team member with access leaves—a key left on a returned device grants permanent access to your document repository. Grant each key only the permissions it needs: a service that only reads has no business holding a key capable of deleting a collection. Finally, monitor key usage in the xAI console, where an unexplained spike in calls is the easiest warning sign to spot.
What regulated enterprises require
Before uploading data subject to regulation—GDPR, HDS (French health data hosting), SOC 2—verification focuses less on technique than on the contract. You need to know xAI’s terms of use regarding data location, the status of the platform’s security certifications, and available contractual guarantees, notably the DPA or BAA depending on your sector. Do this work once, ahead of time, with your legal team; redoing it after production costs far more.
Establish an internal classification policy in parallel that clearly states what can enter a collection. Four levels are generally enough, each associated with an unambiguous storage rule:
| Level | Examples | Collection storage |
|---|---|---|
| Public | Product documentation, FAQ | Allowed |
| Internal | Procedures, guides | Allowed with precautions |
| Confidential | Financial data, contracts | Case-by-case evaluation |
| Secret | Critical intellectual property | Evaluate with legal counsel |
The value of such a table isn’t bureaucratic: it prevents a rushed developer from uploading the negotiated price list into the same collection as the public FAQ, simply because no one had ever addressed the question.
Personal data deserves separate treatment. As soon as your documents contain names, email addresses, or phone numbers, you must have the necessary legal basis for this processing, record it in your GDPR registry, and be able to delete the relevant documents if an individual exercises their right to erasure. This last point requires knowing which file and which collection contains the data: keep this mapping up to date from indexing onward; reconstructing it after the fact across several thousand documents is a tedious exercise.
A layered architecture for high requirements
A non-training guarantee doesn’t settle which employee can read which document. Your application bears this responsibility, through four successive layers. It authenticates the user, then determines which collections are open to them based on their role, queries the API only on those collections, and finally filters results before display. A sales rep asks a question about price lists: their request goes only to col_docs_produit, never to col_rh_policies, even if both collections exist under the same keys. This discipline on the application side, not storage at xAI, determines what everyone ends up seeing.
Key takeaways
- xAI guarantees that collection data is not used to train models
- Access isolation relies on API keys: each account has its own scope
- Store keys in environment variables and rotate them regularly
- Classify your documents before storing them in collections
- For personal data, comply with GDPR obligations (consent, registry, right to erasure)