Provisa / Governed data for AI
The model is ready. Is your data?
The hard problems in AI have moved from the models to the data: what an agent may see, what the data means, and how to serve it at agent volume without flattening a source or the bill. Provisa answers all three in one governed model, over the systems you already run.
What Provisa solves, and what it improves
Putting AI to work raises several problems: governing the models themselves, AI governance more broadly, fitting AI into workflows, reshaping business processes around it, and showing a return on it. Provisa is not a model governance or AI governance platform. It solves the data underneath all of them, and that improves most of the rest:
- AI governance. Every agent acts as a role, under the same rules as people, and every query it runs is in the request record. Much of what an AI governance program has to prove about data access is already recorded.
- Workflow integration. Agents reach data over MCP, and the same governed data is open to the tools around them over SQL, GraphQL, Cypher and nine protocols. Triggers run a command when data changes, so a workflow can react without polling.
- Business processes. A process reshaped around AI still runs on your systems of record. Provisa lets it read and write them in place, governed, instead of building a new pipeline per process.
- Return on investment. The cost of AI is often the cost of the queries it runs. Caching, materialized views and engine choice keep that bill in your hands, and the request record shows what each agent used.
Context tells an agent what it should do. Governance decides what it can do.
A description of your data in a prompt or a catalog helps an agent ask better questions. It doesn't stop the agent reading a column it shouldn't, joining two tables in a way nobody agreed, or running a query that scans a production database at noon. Those have to be enforced where the query runs. In Provisa they are: compiled into the plan of every query, from a person or an agent alike.
The same five questions, under heavier load
Governance answers five questions about every piece of processing: what it means, who it runs for, how it's asked, when it runs and where. Agents raise the stakes on each one.
What it means
An agent is only as good as the meaning it's given. The glossary, declared metrics and registered relationships travel with the data, so the agent works from your definition of "active customer" rather than a guess, and can join only along relationships the domains agreed. The same model is readable over MCP: schemas, tables, glossary terms, data products and metrics.
Who it runs for
An agent connecting over MCP carries an OAuth token that maps to a role. It gets exactly that role's rows and columns, with row-level security, column masking and pre-execution approval applied. There is no separate access path for AI and no second policy to keep in sync: the agent and the analyst sitting next to it are governed by the same rules.
How it's asked
Agents call governed tables as MCP tools, over stdio or remote Streamable HTTP. Natural language compiles to SQL, Cypher or GraphQL with a validation loop before anything runs. Every path, MCP, natural language, SQL, GraphQL or Cypher, compiles to the same governed plan.
Already have a favorite data agent? Connect it to Provisa over a plain Postgres connection. Provisa speaks the Postgres wire protocol, so any agent or MCP server built for Postgres works unchanged, signing in as a Provisa user and governed by that user's role. You get much of the value that way. Provisa's own MCP server adds the extras: the glossary and ontology, data products and metrics, as tools.
When it runs
Agents query far more often, and far less predictably, than people do. Freshness is declared per table, so a busy source can be replicated on a schedule instead of read live. A load management window keeps heavy work off a source in its busy hours. A response can be cached when the request asks for it, and queries rewrite onto a materialized view while it's fresh.
Where it runs
Put agent workloads on the engine that suits them: a region with its own engine, storage and size, on-premises or in the cloud, so a burst of agent traffic lands on capacity sized and paid for it, not on the system of record. Where data must stay in a country or a business unit, the region keeps it there, for agents as for everyone else.
Accountable by default
Every agent query goes through the same request record as a person's: which role asked, what ran, and what governance applied. When someone asks what the AI saw, the answer is a query away.
What it looks like
| An agent on the database | An agent on Provisa | |
|---|---|---|
| What it can read | Whatever the connection can read | Exactly what its role can read, rows and columns |
| What the data means | Column names and a prompt | The glossary, metrics and registered relationships |
| How it joins | Any way it guesses | Only along registered relationships |
| Load on the source | Every question hits the system of record | Replicas, caching and materialized views where declared |
| Policy | A second copy to keep in sync | The same rules as every other consumer |
| Audit | Database logs, if any | The request record: role, query and governance applied |
Start with one agent
- Register the sources the agent needs, where they already live.
- Give it a role. Grant the tables, rows and columns it should see, and nothing else.
- Point the agent at Provisa instead of the database: Provisa's MCP server, or your own agent over a Postgres connection.
- Read the request record to see what it asked and what it got.