Enterprise AI that runs where your data already lives.
Data.co Control deploys model serving, retrieval, a policy-enforced gateway, and agent tooling inside your data center, private cloud, or air-gapped network. Your teams get the AI capabilities they are asking for; your security team keeps the boundary it is accountable for.
Not a private endpoint at someone else's provider.
Many products described as private AI are a dedicated tenant at a hosted model provider. The prompts and documents still travel to infrastructure you do not operate, under terms you negotiate rather than enforce. For regulated records, privileged material, or controlled technical data, that is often the conversation the risk committee cannot get past.
In a Data.co deployment, inference, retrieval, embeddings, and logs run on hardware inside your boundary. app.data.co handles accounts, licensing, and billing, and never receives prompts, documents, embeddings, or records. External commercial model APIs are off by default; if a policy enables one for a specific use, that decision is explicit, scoped, and logged.
Five parts that work together, each usable on its own.
Private LLMs
Open-weight models served with vLLM on GPU servers, or Ollama for smaller deployments, on hardware you control.
Private RAG
Retrieval that checks each user's source-system permissions before a chunk can reach a prompt.
Model management
A registry of model versions, serving configurations, and approval status, so production only runs what was reviewed.
AI gateway
One OpenAI-compatible endpoint with identity, quotas, routing, and policy enforcement on every call.
Private agents
Agents with their own scoped identities, reaching tools only through a governed MCP gateway.
Shared governance
All five use the same policy engine and audit log, so one rule set covers chat, retrieval, and automation.
Where the trade-offs actually sit.
Hosted model APIs are a reasonable choice for many workloads. Private deployment makes sense when the data, not the model, sets the constraints.
| Consideration | Hosted model API | Private AI with Data.co |
|---|---|---|
| Where prompts and documents go | Provider infrastructure, under contract terms | Stays on hardware inside your boundary |
| Model choice | Provider's catalog and release schedule | Open-weight models you select, version, and approve |
| Behavior changes | Provider may update or retire models | A model changes only when you promote a new version |
| Cost shape | Per-token, scales with usage | Mostly capacity: hardware, power, and operations |
| Disconnected operation | Not possible | Supported, including air-gapped networks |
| Frontier capability | Usually the largest models available | Bounded by open-weight models and your hardware |
From first conversation to a governed rollout.
- 1
Scope the workloads
Identify the use cases, data sources, user counts, and classifications that will drive model and hardware choices.
- 2
Size and deploy
An infrastructure assessment turns those workloads into a hardware and deployment plan; Control is installed on it.
- 3
Connect and govern
Connect sources, apply classification, write policies, and register approved models before users arrive.
- 4
Roll out in stages
Start with a pilot group, review audit logs and usage, then widen access policy by policy.
Data.co can operate the environment for you.
Managed Private AI covers model updates, monitoring, patching, and capacity planning under contract, using access you grant and can revoke.
What happens to a single request, end to end.
A user asks a question in an internal chat tool. The tool calls the AI gateway with a token issued to that application, and names the user it is acting for. The gateway resolves the caller to an identity with its groups, roles, and scope, then builds a policy request: this subject wants to invoke this model endpoint, with these datasets in play, for this purpose. Each referenced dataset is evaluated as its own read, with the classification labels from your catalog attached.
The policy engine evaluates those requests locally against the active compiled policy set. Any deny wins; otherwise any approval requirement wins; only a clean allow is forwarded to the model. Every evaluation is appended to a hash-chained audit log that records who, what, which policy, and why, but not the prompt text itself. If the policy set fails to compile, the license has expired, or the audit log cannot be written, the request is denied. The design is fail closed: an enforcement point that cannot prove a request is allowed does not forward it.
Match the first component to the problem in front of you.
Most programs begin with one component and add the others once identity and policy are in place.
| If the pressing problem is | Start with | Because |
|---|---|---|
| Staff pasting sensitive data into public chatbots | AI gateway + private LLMs | It gives people a sanctioned endpoint and gives security one place to see usage |
| Search across documents with mixed permissions | Private RAG | Permission-aware retrieval is the hard part; the model is comparatively easy |
| Several teams running models with no review | Model management | A registry turns ad hoc containers into approved, versioned aliases |
| Pilots of agents with broad service accounts | Private agents + MCP gateway | Tool calls need least privilege before any write access is granted |
Questions to answer before the first production user.
- Which identity provider groups map to which use cases
- Which data classifications each use case may touch
- Which open-weight models are approved, and by whom
- Where audit logs are retained and who reviews them
- Who is on call for the GPU nodes and the gateway
- How model and policy changes move through change control
Questions buyers ask
Are open-weight models good enough for enterprise work?
For many common workloads, including summarization, extraction, classification, drafting, and grounded question answering over your documents, current open-weight models perform well, especially with good retrieval. The largest hosted models still lead on some open-ended reasoning tasks. We help you test candidate models on your own examples before you commit to hardware.
Can we still use a commercial model API for some use cases?
Yes, if you choose to. External APIs are disabled by default. A policy can enable a specific provider for specific identities, data classifications, or purposes, and the gateway enforces and logs that decision on every call.
Does Data.co ever see our prompts or documents?
No. Inference, retrieval, and logging run inside your environment. app.data.co handles accounts, licensing, billing, and opt-in fleet administration only. If you engage managed services, our engineers work through access you grant, scope, and can revoke.
What hardware do we need?
It depends on the models, concurrency, and context lengths your workloads need. Small pilots can run on a single workstation; production chat and RAG for a department typically needs one or more GPU servers. An infrastructure assessment sizes this before you buy anything.
Can we start with one component, such as RAG, and add the rest later?
Yes. Each component is usable on its own, and they share the same identity, policy, and audit layers, so adding agents or more models later does not mean rebuilding governance.
What happens if the license or policy set is invalid?
Enforcement fails closed. An expired license (after its grace period), a policy set that fails to compile or fails its own tests, an unknown model, or an audit log that cannot be written all result in a deny rather than an unchecked request.
Do access decisions depend on reaching app.data.co?
No. Policies are evaluated locally by the runtime inside your network, and the license is verified offline with a public key. An outage of app.data.co, or no connection to it at all, does not change what is allowed.
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.