Integrate for AI, not for another copy of everything.
Classic integration projects move data into one place and then work out access. AI needs the opposite order: keep data close to its source, carry its permissions and labels, and choose per source whether to index it for retrieval or query it in place.
Three ways to make a source available to AI.
Most deployments use all three. The right choice depends on the shape of the data and how fresh it must be.
| Pattern | Best for | How permissions apply | Trade-off |
|---|---|---|---|
| Index for retrieval | Documents, notes, tickets, knowledge bases | Source ACLs stored with each chunk and re-checked at query time | Needs sync to stay current; uses local storage for indexes |
| Query in place | Structured data that changes often or is too large to index | Executed with the requesting identity's effective permission | Bounded by source performance and query constraints |
| Governed tool | Actions and lookups in business applications | Each call evaluated by policy at the MCP gateway | Requires tool definitions and argument constraints |
Permissions and labels are part of the integration.
An integration that drops access control on the way in creates a new, flatter copy of your most sensitive data. Every pattern in Data.co Control keeps two things attached to the data: the source system's permissions and the classification labels applied at ingest. They are what let the policy engine make a decision later.
Integration runs in the connector runtime inside your network. Nothing is staged through a hosted service, which also means integration works the same way in private cloud, on-premises, and air-gapped deployments.
One source, two patterns.
A single connection can index document content for retrieval and expose structured tables for bounded queries, each with its own policy surface.
source: claims
connector: postgres
connection:
host: claims-db.internal
database: claims
credentials: secret://connectors/claims-readonly
patterns:
query_in_place:
schemas: [public]
max_rows: 10000
index:
tables: [claim_notes]
text_columns: [note_body]
acl_from: row_owner_group
classification: { on_ingest: true, review_owner: group:claims-data-owners }Illustrative example · final API surface documented in /docs
From connection to governed use.
- 1
Register
Add the source with credentials stored as secrets in the runtime, and an owning team.
- 2
Profile
The catalog inventories tables, fields, and collections; classifiers propose labels.
- 3
Confirm
Data owners confirm labels and choose patterns: index, query in place, or tool.
- 4
Enable
Policies reference the new source, are tested in the simulator, and then go live.
Questions that decide the pattern for each source.
Ask these per source, not per project. The same system often ends up with different patterns for different tables or collections.
Is the value in prose or in numbers?
Contracts, notes, and tickets answer questions through their text and suit retrieval. Balances, counts, and statuses are better queried in place, where the answer is exact rather than paraphrased.
How stale can an answer be?
If minutes matter and the source supports change capture, an index can keep up. If seconds matter, query in place so the answer reflects the system of record.
How are permissions modeled?
Document ACLs travel well with chunks. Row-level rules embedded in application logic are often safer to enforce by querying through the source or a governed tool.
Does the AI need to act?
Creating a ticket or updating a record is an action, not a retrieval. Expose it as a governed tool so each call is evaluated and can require approval.
What can the source tolerate?
Fragile or heavily loaded systems may favor an index refreshed off-hours over frequent live queries.
How sensitive is it?
Highly regulated sources may warrant query-in-place with tight row limits, so less of their content is ever stored in a second location.
Central copy versus integrating in place.
| Concern | Copy everything into one store first | Integrate per source for governed AI |
|---|---|---|
| Permissions | Rebuilt or flattened in the new store | Carried from the source and re-checked at query time |
| Sensitivity labels | Added later, if at all | Applied at ingest before anything is retrievable |
| Freshness | Bounded by the bulk load schedule | Chosen per source: change capture, events, or schedule |
| Footprint of regulated data | A full second copy | Only what is indexed; the rest is queried where it lives |
| Traceability | Hard to tie an answer to a source version | Lineage from answer to source version and sync job |
Questions buyers ask
Do we need to centralize data in a warehouse first?
No. Control connects to sources where they are. If you already have a warehouse, it can be one of the sources, but it is not a prerequisite.
How do you handle documents with complex permissions?
Document permissions are read from the source and stored with each indexed chunk, then checked again at query time, so a user only retrieves content they can open in the source system.
Where are indexes and embeddings stored?
Inside your environment, on storage you provide. Embeddings are generated by models running in your deployment and are never sent to Data.co.
How long does it take to integrate a source?
It depends on the system, network access, and how much classification review the data needs. We estimate per source during scoping rather than quote a standard timeline.
Can one source use more than one pattern?
Yes, and it is common. A claims database might expose structured tables for bounded queries while indexing free-text note columns for retrieval, each with its own policies.
What about our existing ETL and pipelines?
They keep doing their jobs. Control does not replace analytics pipelines; it prepares sources for governed AI use, and a warehouse or lake those pipelines feed can be connected as a source.
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.