For the CDO
Sovereign intelligence for the CDO
Turn enterprise data into organisational intelligence.
The CDO is accountable for data quality, access and value, and AI makes every weakness in those three visible. A model is only as useful as the context it is given, and only as safe as the permissions on that context. This page covers the data worries that matter most and the vendor questions that test them.
What a CDO worries about
Retrieval that ignores permissions
Indexing documents into one shared store can let an assistant answer from files the asker could never open. The control has to travel with the data, not be bolted on after.
Data nobody can trace
When an answer is wrong, you need to know which source, which version and which transformation produced it. Without lineage, data quality problems turn into AI trust problems.
Stale, duplicated and conflicting sources
AI surfaces contradictions that people had learned to work around. Cleaning and reconciling sources becomes the real project behind the assistant.
Classification that does not reach the model
A data classification policy is only useful if it decides which model may see which class. Otherwise the policy exists on paper and the data flows anyway.
Derived knowledge held by someone else
Embeddings, memory, summaries and evaluation sets are valuable assets. If they sit in a vendor system in a format you cannot export, your accumulated knowledge is not really yours.
What a Sovereign Intelligence Platform gives you
Data and context as a defined layer
The data and context layer is designed to give AI the context to understand the organisation, with retrieval, memory and lineage treated as first-class parts.
Data controls that decide what AI can read and write
Classification, residency and boundaries are applied to AI access as part of the trust fabric, not as a separate project.
Knowledge as an owned asset
Intelligence sovereignty covers proprietary knowledge, memory and derived insight, so what the organisation learns stays portable. See intelligence sovereignty.
A feedback loop for data quality
Outcomes and their evidence flow back into data and context in the closed intelligence loop, which surfaces which sources help and which mislead.
Entry through your own files
Cortex is an entry point that answers from company files and meetings and runs on the laptop by default, which gives a bounded place to prove value on real content.
Capabilities are described as what the platform is designed to let you do. For what is true today and what is not claimed, see the trust centre.
Questions to ask any vendor
Use this as a checklist in any evaluation, ours included. Each question comes with what a good answer looks like.
01Does retrieval enforce the asker's permissions on the source system at query time?
A good answer: Yes, with permissions synced or checked live, and a demonstration using two accounts. Document-level and row-level controls are both addressed.
02Can I trace any answer back to the exact source passages, versions and retrieval steps?
A good answer: Every answer carries citations and a retrieval trace, stored for audit. Source version identifiers are kept so a result can be reproduced.
03How do you handle data classification, and can it restrict which model sees which data?
A good answer: Classification labels are read from our catalogue or applied on ingest, and routing policy uses them to allow or deny a model.
04Where are embeddings, indexes and memory stored, and can we export them?
A good answer: Storage location is stated and the formats are documented. Export includes vectors, metadata and the embedding model identifier, since vectors are not portable across models without re-embedding.
05How are deletions and retention applied to indexes, caches and memory?
A good answer: Deleting a source removes its chunks, vectors and cached answers within a stated period, and retention rules apply to memory too.
06What data quality signals does the platform give back to us?
A good answer: Reports on stale sources, conflicting answers, low-confidence retrievals and unanswered questions, per source and owner.
07Who owns a data source inside the platform, and how are owners notified of problems?
A good answer: Each connected source has a named data owner who receives alerts about failed syncs, stale content and permission changes, and can pause or remove the source without vendor help.
08Do you support structured data, unstructured documents and a knowledge graph, or only text chunks?
A good answer: A clear description of supported source types and when a graph or structured query is used instead of vector search.
09How do you prevent sensitive fields from entering prompts and logs?
A good answer: Masking and filtering policies that apply before the model call and before logging, configurable by field and class.
10Can we run evaluations of retrieval quality on our own questions?
A good answer: A harness for question sets with expected sources, reporting recall and answer quality over time. See the RAG architecture guide for what to measure.
11Does any of our content or derived data leave our chosen region or boundary?
A good answer: A data-flow diagram that includes model providers, logging and support access, and a contractual statement of residency.
12Is our data used to train or improve your models or anyone else's?
A good answer: A clear answer in the contract, covering prompts, files, embeddings and feedback signals.
Recommended reading
- Guide: prepare data and context
- Data sovereignty
- Intelligence sovereignty
- RAG architecture and implementation guide
- Platform: data and context layer
Not sure where to start? Take the readiness assessment or read the build guide.
Frequently asked questions
What is the difference between data and context?
Data is what you store. Context is the subset, structure and history an AI system is given for a specific task, with permissions and provenance attached.
Do we need a knowledge graph?
Not to begin. Many use cases work with permission-aware retrieval. A graph helps when relationships between entities matter more than passage similarity.
How does data sovereignty differ from data residency?
Residency is where data sits. Sovereignty also covers access, processing, transfer and retention, and whose legal reach applies. See data sovereignty.
Build with control: for the CDO
Start with one entry point. Add intelligence, agents, workflows and infrastructure as you prove value. Or read the step-by-step build guide and take the readiness assessment.