Rixoffice was built so that your documents stay yours. Editing is local-first and the AI follows the same principle: processing happens on your machine wherever technically possible, and when a cloud model is involved, only the minimum text needed for your request makes the trip. This page states the model plainly, provider by provider, so you can decide exactly how much leaves your machine.
What stays on your device by default
Regardless of which AI provider you choose, these never leave your machine as part of AI:
- Your documents, workbooks, decks and PDFs as files.
- Your API keys for OpenRouter, Anthropic, OpenAI, Gemini, DeepSeek or custom endpoints, stored locally in the app.
- The agent tooling — skills, block indexing, attachment reading — which runs locally.
The agents read your real file structure on your device. What they optionally send onward is the narrow slice a cloud model needs to reason about your request, and nothing beyond it.
Your Rixcart account — used for cloud projects, plan management and credits — comes with device session management, so you can see and revoke signed-in devices, and GDPR data controls for accessing or deleting your account data. Cloud project sync covers only the documents you explicitly keep there; local files remain local unless you sync them yourself.
It is worth separating those two layers in your head, because they are governed differently. AI is a processing question — what happens to text while you work — and the answer is that processing stays local by default. Storage is a custody question — where files live — and the answer is that custody stays with you unless you deliberately place a file in a synced cloud project. Neither layer quietly expands into the other.
What cloud AI receives
When you use a cloud provider, the text you ask about is what crosses the network:
- The block, range, slide or page involved in your request.
- Your instruction, plus whatever context the agent includes to fulfill it — for example, a heading when you ask to rewrite a paragraph under it.
Not sent: your other files, your file tree, unrelated document sections, or your keys. If you ask the agent to rewrite one paragraph, the model sees that paragraph and its instruction, not the surrounding report. The block-level architecture is what makes this scoping possible — the AI addresses small targets by design, not by effort.
The same scoping applies to chat questions about a file. Ask Oracle what a workbook claims and the agent reads the relevant ranges locally; what reaches the cloud model is the question and the material it needs, not the whole workbook with every sheet attached.
Provider by provider
| Provider | Where processing happens | What crosses the network |
|---|---|---|
| Ollama (local) | Entirely on your device | Nothing — no internet needed |
| BYO API keys | Your device; model runs at your provider | The request text, directly to your chosen provider |
| Built-in Rix AI | Your device; model runs via the Rixcart proxy | The request text, through the proxy to the model |
The Ollama row is the strictest option available in any office suite configuration: with a local model selected, documents, prompts, agent reasoning and responses all stay on your machine, and the AI works with the network completely disconnected. BYO keys sit in the middle — the request goes straight from your machine to a provider you chose, under your own account and your own terms.
Web search and attachments
Two features involve outside services, and both are scoped narrowly:
- Web search sends only the search query to the search provider — Google results via Serper, with DuckDuckGo fallback. Your document content is not uploaded to any search engine.
- Attachments are read locally by the agent. If you use cloud AI, the attachment itself is not shipped off; the model works from the text the agent extracts for your request.
Choosing your own comfort level
The design intent is that privacy is a setting, not a slogan:
- Maximum: select Ollama. Nothing leaves the device, ever. Works offline.
- Direct: use your own API keys. Requests go from your machine straight to a provider you chose and trust, under your own account.
- Convenient: use built-in Rix AI. Requests pass through the Rixcart proxy, with only request text involved.
You can switch between these per task, per day or per machine in Settings — the editors, agents and skills behave identically in all three, so tightening privacy never costs you functionality.
A practical example
Suppose you edit a contract in RixDocs. With Ollama, the rewrite request never touches a network. With a BYO key, the paragraph and your instruction go from your machine to your provider endpoint. On built-in Rix AI, the same text passes through the proxy. In every case, the contract file itself remains on your disk, unchanged and unuploaded, and every other section of the document stays home.
Questions worth asking any office suite
If you are evaluating tools against each other, these are the questions that separate real local-first designs from marketing:
- Does editing work with no connection at all? In Rixoffice, yes.
- Is the whole file uploaded for AI, or only the requested text? Only the requested text here.
- Can the AI run on-device with zero network? Yes, through Ollama.
- Where do API keys live? On your device, in the app's local storage.
- Can you review and revoke signed-in devices and delete your data? Yes — session management and GDPR controls come with the account.
What to explore next
- Ollama local models — the fully on-device setup, step by step.
- BYO API keys — direct-to-provider requests under your own account.
- AI web search — what a search query sends and what it does not.