Start with the problem you have this quarter.
Most teams do not buy an AI governance platform in the abstract. They need to approve one assistant, connect one agent to one system, or answer one auditor's question. These are the problems Data.co is built to solve, each one a starting point that grows into the rest.
If this is your situation, start here.
| Situation | Use case | First capability deployed |
|---|---|---|
| Leadership wants AI, security wants a plan | Secure enterprise AI | AI gateway with policy and audit |
| Regulated data is spread across systems | Sensitive data governance | Classification and labeling |
| Nobody can find anything across drives and wikis | Private knowledge search | Permission-aware retrieval |
| Agents are about to get credentials | AI agent access control | Agent identities and scoped policies |
| Data must stay in a country or a building | Data sovereignty | Local inference and local audit |
| Critical data lives in decades-old systems | Legacy data modernization | Connectors and normalization |
| Answers must cite sources and respect access | Enterprise RAG | Governed retrieval pipeline |
| Teams are wiring MCP servers to production | Secure MCP integration | MCP gateway |
Every use case shares the same foundation.
Each use case relies on the same four pieces: identities for every actor including agents and models, classification labels on data, a deterministic policy engine that decides each request, and an append-only audit log in your environment. Start with one and the next reuses what you already configured.
A team that begins with private knowledge search has already labeled its data and mapped its groups. Adding an agent later means giving that agent an identity and a policy, not starting a new governance project.
Common to every deployment.
Inside your infrastructure
On-prem, private cloud, hybrid, or air-gapped. Prompts, documents, and embeddings never reach app.data.co.
No LLM in the decision path
Access decisions are deterministic, testable, and explainable.
Evidence by default
Every request, decision, and approval is logged locally and exportable.
Open model choice
Run open-weight models on vLLM or Ollama, or route approved data classes to endpoints you choose.
What the first use case looks like in practice.
Whatever the starting point, first deployments tend to follow the same arc. The scope is deliberately narrow so the foundation is right before it is reused.
- 1
Pick one boundary
One team, one or two data sources, one model or one agent. Write down what must never happen, such as PHI reaching an external endpoint.
- 2
Install Control locally
Run the Control runtime in your environment with an offline-verified license, connect your identity provider, and register the models or MCP servers in scope.
- 3
Write policies with tests
Express the boundary as policies and test cases. A failing test blocks activation, so the rules you rely on are the rules that run.
- 4
Observe, then enforce
Review real decisions in the audit log before tightening. Most surprises are about what people actually do, not what was planned.
- 5
Reuse for the next one
The next use case adds identities and policies to the same deployment instead of starting a new project.
Questions to ask any vendor in this space, including us.
- Does any prompt, document, embedding, or tool argument leave our network to reach the vendor?
- Is the access decision made by a model, or by deterministic rules we can test?
- What happens when the policy service is down: allow or deny?
- Can an agent's effective access exceed the access of the user it acts for?
- Is the audit log tamper-evident, and can we verify it ourselves?
- Can we run fully disconnected, including licensing?
An assessment maps your first use case.
We review your data sources, regulatory constraints, and infrastructure, and recommend a first deployment with a defined scope.
Questions buyers ask
Do we need to deploy everything at once?
No. Each use case is a valid first deployment. Later use cases reuse the identities, labels, and policies you already set up.
Which use case is fastest to put in place?
It depends on how clean your identity groups and data sources are. Private knowledge search over a well-permissioned document system is often a straightforward start; agent access control depends on how many systems the agents touch.
Are use cases priced separately?
Pricing is described on the pricing page and discussed during scoping. Use cases are configurations of one platform, not separate products.
How do use cases relate to the industry solutions?
Industry pages describe where the regulatory boundary sits for a sector. Use cases describe the technical problem being solved. Most deployments are one of each, such as enterprise RAG for a law firm.
Who should own the first use case internally?
Usually a pairing: a platform or infrastructure lead who owns the deployment, and a security or data governance lead who owns the policies. Business owners define what success means for their team.
Can someone else run it for us?
Yes. Managed services can operate the deployment inside your environment through access you grant, scope, and revoke, while your team keeps ownership of policies and data.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.