Make enterprise data usable by AI without losing track of it.
Before a model can answer anything useful, someone has to connect the systems, know what is in them, label what is sensitive, and keep it current. The platform layer of Data.co Control does that work inside your network and hands governed, labeled, traceable data to the policy engine and AI gateway.
Governance is only as good as what it knows about the data.
A policy that says "no PHI to external models" is only enforceable if the system knows which fields and documents contain PHI. A permission-aware answer is only possible if source permissions travel with the content. An audit is only useful if an answer can be traced back to the record that produced it.
That is why Data.co Control starts with data infrastructure rather than a chat interface. Connectors, the catalog, classification, lineage, and synchronization produce the metadata the governance layer runs on: what exists, how sensitive it is, who may see it, and where it came from.
Six parts of the Connect layer.
Each has its own page. Together they turn source systems into labeled, permissioned, traceable inputs for AI.
Enterprise Data Integration
Choose per source whether to index for retrieval, query in place, or expose as a governed tool, without building a central copy.
02Data Connectors
Connectors run in your network, read with credentials Control holds, and carry source permissions forward with every record.
03Data Catalog
An inventory of every source, dataset, field, and document collection AI can reach, with owners, labels, and usage.
04Data Classification
PHI, PII, financial, privileged, and custom labels applied at ingest and confirmed by data owners before retrieval.
05Data Lineage
Trace any answer back to the document version, sync job, model, and policy set that produced it.
06Data Synchronization
Scheduled sync or change data capture per source, with deletes propagated and every change classified first.
How a record becomes something an agent can safely use.
- 1
Connect
A connector in your network authenticates to the source with credentials held by Control and reads data with its permissions.
- 2
Catalog + classify
Datasets and fields are registered in the catalog and labeled at ingest, with data owners confirming labels.
- 3
Index + sync
Content is indexed for retrieval inside your environment and kept current by scheduled sync or change data capture.
- 4
Serve with lineage
At query time, source ACLs and policy decide what is returned, and lineage ties each answer to its sources.
What the data layer will not do.
- Copy your data to Data.co-hosted systems
- Flatten source permissions into one service account
- Send content to a model before it is classified
- Lose track of which version an answer used
- Require internet access to sync or index
- Hide which sources are connected and by whom
What each part of the data layer hands to governance.
The policy engine does not read your data to make a decision. It reads metadata about the data, and this is where that metadata comes from.
| Producer | Metadata produced | Consumed by |
|---|---|---|
| Connectors | Source identity, source permissions per record or chunk, source version or change marker | Permission-aware retrieval, lineage |
| Catalog | Stable asset identifiers, owners, schemas, sync state, AI usage | Policies, access reviews, approval routing to owners |
| Classification | Labels with proposed or confirmed status at field, record, and document level | Policy conditions, egress rules, monitoring by label |
| Synchronization | Job IDs, timestamps, change mode, propagated deletes | Freshness checks, lineage, deletion requests |
| Lineage | Links from answer to chunk, document version, sync job, model, and policy set | Audit, disputes, impact analysis |
How AI data pipelines usually go wrong.
Most retrieval projects that run into trouble do so for data reasons rather than model reasons. The index is built once by a script with an administrator's credentials, so every user can retrieve everything. Permissions are copied at ingest and never refreshed, so revoked access lingers. Content arrives unlabeled, so the only egress control left is pattern matching on outbound text. Deleted records leave orphaned chunks behind. And when an answer is challenged, nobody can say which version of which document it came from.
Each part of the Connect layer is aimed at one of those problems: connectors that carry permissions, query-time permission checks, classification before indexing, deletes as first-class changes, and lineage written as the pipeline runs. None of it is novel on its own. The value is that it is consistent across sources and feeds a single policy engine and audit log instead of a different set of scripts per project.
Questions buyers ask
Is this a data warehouse or a data lake?
No. The platform layer prepares data for governed AI use. It can index content for retrieval and query some sources in place, but it does not replace your warehouse, lakehouse, or operational databases.
Does data leave our network?
No. Connectors, the catalog, indexes, and lineage all run inside your environment. The hosted account plane at app.data.co never receives records, documents, or embeddings.
Can we use the data layer without Data.co's AI gateway?
The data layer is built to feed the policy engine and AI gateway, and that is where its value is clearest. We scope other integration patterns per deployment.
Which source systems are supported?
The connector framework targets databases, document stores, business applications, storage, and APIs. The product is early, so we confirm specific connectors against your systems during scoping rather than publishing a blanket list.
Where should we start if we have dozens of sources?
With the sources behind one or two concrete AI use cases. Connect, classify, and confirm owners for those first, then expand. A smaller, well-labeled set is more useful to policy than a large, unreviewed one.
Does the data layer need GPUs?
Connectors, the catalog, classification, and sync are ordinary compute. Embedding generation for retrieval uses models in your deployment, so its hardware needs depend on volume and the model you choose.
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.