Platform
Connect enterprise data to AI without losing control
Govern how AI reaches databases, warehouses, documents, knowledge systems, APIs, files and enterprise applications. OpsAI is not a database.
OpsAI is not a database
Nothing is copied, synced or indexed. A read happens against your system at request time, and what OpsAI keeps is the record that it happened — not the contents.
Sources governed
9
Copies held
0
Before anything else
Governing data access without becoming a place data lives.
Every product that sits between AI and enterprise data eventually gets mistaken for a copy of that data. The mistake is expensive — it implies a sync, a staleness problem, a retention obligation and a new place to leak from — so it is worth closing before the rest of the page.
- Not a database
- Nothing is copied, synced or cached. A read happens against your system, at request time, and OpsAI records that it happened rather than what came back.
- Not a data catalogue
- It records what AI may reach and what happened when it did. It does not profile your columns, infer schemas or try to be the place your analysts look things up.
- Not a retrieval layer
- No embeddings, no index, no vector store. Your retrieval stays yours; OpsAI governs the boundary it reads across.
- Not a second source of truth
- Which matters most of all: a copy creates a retention obligation, a staleness problem and a new place to leak from. There is no copy.
What is recorded is that a read happened, not what it returned.
The source, the AI system, the grant it held, the time, and whether the read was permitted. That is enough to answer what AI has seen without OpsAI holding any of it, which is the only version of this that does not enlarge the problem it solves.
What AI reaches
5 kinds of source, governed the same way.
A database, a warehouse, a document store, a knowledge base, an application and an object store are reached very differently and governed identically — because what is governed is the read and its destination, not the query language.
Data sources in the sample estate
9 sources · 5 kinds · 3 residencies| Source | Kind | Classification | Residency | Governed by | Readers |
|---|---|---|---|---|---|
| Order historyPostgres | database | pii.indirect | ap-south-1 | pii.export_block | 3 |
| General ledgerZoho Books | application | financial | ap-south-1 | close.controls | 1 |
| Vendor masterNetSuite | application | financial | us-east-1 | vendor.new_payee | 1 |
| CRM accountsSalesforce | application | pii.indirect | eu-west-1 | write.window | 2 |
| Support ticketsZendesk | application | pii.direct | ap-south-1 | pii.export_block | 2 |
| Executed contractsBox | documents | pii.direct | eu-west-1 | pii.export_block | 1 |
| Product analyticsAmazon S3 | warehouse | internal | ap-south-1 | pii.export_block | 1 |
| Policy handbookBox | knowledge base | internal | eu-west-1 | pii.export_block | 3 |
| Payroll recordsWorkday | application | pii.direct | eu-west-1 | pii.export_block | — |
Sources
9
classified and governed
Kinds
5
reached differently, governed alike
Holding direct PII
3
a name, an email, an account
Read by nothing
1
worth knowing, either way
IllustrativeIllustrative sources for the OpsAI sample estate, a fictional company.
Four facts per source, and the fourth is the unexpected one
- Classification
- Five classes, and pii.indirect is separate on purpose — fields that identify somebody in combination are the harder case and folding them into the direct class loses that.
- Residency
- Where the data physically sits. A fact about your infrastructure rather than about OpsAI, and the first thing a data-protection review asks for.
- Approved destinations
- Where a read may be written. 2 of 9 sources have none at all — readable into a decision, never written out. Why the destination is the control.
- Who holds a read grant
- And therefore which sources nothing reads. One source here — either correctly untouched, or reached by a route OpsAI cannot see.
Why data has its own mechanism
A read is not an action, and governing it as one gets both wrong.
An action changes something and can be refused on its own terms — an amount, a payee, a window. A read changes nothing, and the exposure is not the read itself but where the answer ends up. Two different questions, so two different controls.
- An action
- Refusable before it lands, on the properties of the action itself. Governed at the boundary by a bound.
- A read
- Permitted or not by a grant, and then constrained by where the result may go. The second half is the part that matters and the part usually missing.
- Why not just refuse the read
- Because the work needs the data. A control that stops an agent reading a customer record stops it resolving a customer problem — the useful question is not whether it may read, but where the answer may travel.
Where to start
Classify the sources first. The destination list is a shorter conversation than it sounds.
Most teams find the classification takes a week and the destination list takes an afternoon, because the honest answer for most sources is that a read should not be written anywhere at all.