Say yes to AI without losing track of your data.
Employees are already pasting company data into public chatbots. Blocking them does not work for long. Data.co gives you a sanctioned path: private models behind one gateway, with policy on every request and an audit log your security team controls.
Shadow AI is a symptom of having no approved path.
When the only AI tools available are consumer services, people use them with whatever data is on their screen. Acceptable-use memos do not tell you what was shared, and network blocks push usage to personal devices.
A sanctioned alternative has to be good enough that people choose it. Data.co provides an OpenAI-compatible gateway so existing tools and SDKs work by changing a base URL, backed by private models that run on your hardware. Every request carries the user's identity, is evaluated against policy, and is logged locally.
A realistic sequence.
- 1
Inventory
Identify which teams use AI today, for what, and with which data. This sets the first policies.
- 2
Deploy the gateway
Stand up Data.co Control with one or two local models sized to your hardware and connect your identity provider.
- 3
Set baseline policy
Allow general use, keep labeled data on local models, and deny export of restricted classes.
- 4
Open access
Point internal tools and a chat interface at the gateway. Retire unsanctioned paths once the alternative is in place.
- 5
Review and expand
Use the audit log to see actual usage, then add retrieval, agents, and connectors where demand is real.
Change one line in existing code.
The gateway speaks the OpenAI-compatible chat completions API. Identity comes from your SSO token or a scoped service key, so policy applies to every call.
from openai import OpenAI
client = OpenAI(
base_url="https://ai.internal.example.com/v1", # your Data.co gateway
api_key=os.environ["DATACO_GATEWAY_TOKEN"],
)
resp = client.chat.completions.create(
model="llama-local",
messages=[{"role": "user", "content": "Summarize the Q3 vendor review."}],
)Illustrative example · final API surface documented in /docs
One request, traced through the gateway.
An analyst asks the internal assistant to summarize a vendor file that includes payment terms. The assistant names the dataset it is using, so the gateway can apply that dataset's labels.
| Step | What happens | Recorded in the audit log |
|---|---|---|
| Authenticate | The analyst's SSO token identifies the user and their groups | Subject and organization |
| Resolve the model | The requested model must be a registered endpoint; unknown names are refused | Endpoint key and its approval status |
| Attach labels | The referenced dataset carries a financial label from the catalog | Dataset name and classification |
| Evaluate | One decision for invoking the model, one for reading the dataset at that destination | Decision, policy IDs, explanation |
| Route or refuse | Local model: allowed and forwarded. External endpoint: denied with the policy ID | Outcome, latency, policy set version |
Where rollouts usually stall.
The most common problem is identity, not models. Tools that call the gateway with one shared key make every request look like the same user, which defeats per-user policy and turns the audit log into noise. Budget time to pass real user identity from each tool, or issue a separate identity per application with a narrow scope.
The second is starting with policies that are too strict to be useful. If the sanctioned path refuses ordinary drafting work, people go back to consumer tools. A better first policy allows general use on local models, restricts only the labeled classes that matter, and is tightened as the audit log shows real usage. The third is skipping success criteria: agree up front what the security team needs to see, and what the business needs to be able to do, so the review after the first month has something to measure against.
Answers to the questions they will ask.
- A list of every model endpoint in use and its approval status
- Per-user and per-team usage records
- Confirmation of which data classes reached which models
- Blocked requests with policy ID and reason
- No prompt or document data sent to app.data.co
- Audit export to your SIEM
Questions buyers ask
Will existing AI tools work with the gateway?
Tools that let you set an OpenAI-compatible base URL generally work. Some tools need configuration to pass user identity; we cover this during deployment.
Can we still use a hosted frontier model?
Yes, if your policy allows it. You can route specific non-sensitive data classes to an approved external endpoint and keep labeled data on local models.
Are local models good enough for daily use?
Current open-weight models handle drafting, summarization, and question answering well for many tasks. Fit depends on the workload and hardware, which we size during assessment.
How do we see what people are actually doing?
The audit log records each request's identity, model, data classes, decision, and outcome. Decision records are content-free by design; if you want prompt text retained for review, that is a separate choice your team makes and stores in your environment.
What happens if the policy engine cannot decide?
The gateway denies. An invalid policy set, an unknown model, or an audit log that cannot be written all result in a refusal rather than an unchecked request.
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.