Draft: docs(security): clarify Orbit is deterministic and GitLab does not train on Orbit data

What does this MR do and why?

Adds a "Data handling and AI" section to the Orbit Remote security page (docs/source/remote/security.md), covering three questions that come up repeatedly from customers evaluating Orbit:

  1. Is Orbit deterministic? Yes. Orbit is a data API that compiles JSON DSL to ClickHouse SQL. There is no LLM or model inference behind queries.
  2. Does GitLab train models on Orbit data? No. GitLab does not train generative AI models on the indexed graph, source code, SDLC objects, or query inputs/outputs. AI vendors are contractually barred from training on customer data.
  3. Where does the data live? ClickHouse on GitLab-managed infrastructure in us-east1 (South Carolina). Same compliance posture as other SaaS ClickHouse features (Advanced Search, CI/CD analytics). Contractual residency guarantees are a GitLab Dedicated feature.

This came up in a customer evaluation conversation where the Orbit team confirmed these points verbally. Putting them in the docs gives customers and sales a citable, public reference.

Raised from a customer evaluation conversation (Slack thread, internal).

Testing

Documentation-only change. No code changes.

Performance Analysis

  • This merge request does not introduce any performance regression. If a performance regression is expected, explain why.
Agent context — long-form analysis, file-by-file walkthroughs, profiler output, alternatives considered

File changed: docs/source/remote/security.md

New section added: ## Data handling and AI with three subsections:

  • ### Deterministic query engine — explains no LLM/inference, JSON DSL → ClickHouse SQL pipeline
  • ### No model training on your data — states no training on graph, code, SDLC, or query I/O; vendor contractual commitment; same posture as rest of GitLab SaaS AI
  • ### Data residency — us-east1, same ClickHouse compliance as Advanced Search and CI/CD analytics; Dedicated for contractual guarantees

Placement: Between ## Security architecture and ## Programmatic access — logical flow from "how access is controlled" → "what happens to the data" → "how to connect programmatically".

Front matter description updated to include "data handling and AI".

Alternatives considered: Adding to how-it-works.md instead. Chose security.md because customers asking "do you train on my data?" are asking a security/compliance question, not an architecture question.

%{all_commits}

Merge request reports

Loading
Loading