V
Victor Horlenko
Guest
Enterprise AI adoption is close to universal now, but confidence in the data underneath it is not. IBM asked over 1,700 chief data officers whether their data capabilities were ready to support new AI-enabled revenue streams. Only 26% said yes.
It is tempting to read that gap as a data quality problem: silos, stale records, half-documented schemas. Those things matter, but they also sit on top of a problem that gets far less attention.
Take a team with AI in production and ask one question. Pick an answer the internal assistant gave someone last Tuesday. Which record keys did it read? Who was it acting for? What authorized that use? Where are the copies of that data now?
Answering all four gets difficult fast. Not because the team was careless, but because AI readiness usually focuses on different questions: Does the model perform? Will the infrastructure hold? Has security signed off? While all these are fair questions, they only tell you whether the system works, not whether you can account for what it did with the data.
That missing accountability is the database compliance gap. It shows up across the data lifecycle: in access, retrieval, lineage, copies, and eventually deletion.
Traditional applications usually give the database a fairly explicit request. Take a simple query:
The database does not know why the application wants that information, but the scope is clear: return the vacation balance for one active employee. You can see exactly what was requested.
Now look at a basic vector search in a retrieval pipeline:
The database sees something very different: find the twenty chunks closest to this embedding. It may have no idea what the user actually asked. That context lives higher up the stack, in the prompt and application logic. Unless the retrieval layer carries it into its filters and logs, the database sees what was retrieved but very little about why.
That matters in practice. Say an employee asks an internal HR assistant how parental leave accrues. The retriever finds the leave policy, but it also pulls a paragraph from a grievance file because that document discusses leave entitlement too.
The retrieval worked. The problem is that relevance and purpose are not the same thing. A document can be a good semantic match and still be the wrong data to use for the request.
That is the gap AI retrieval exposes: the database can tell you what matched without necessarily knowing why it was appropriate.
The compliance gap does not stop at retrieval. It shows up again as data moves through the rest of the AI stack.
An AI assistant may serve thousands of users, but the database often sees the same service account for all of them. The logs might show that hr-ai-service read a record at 10:42 a.m. They may not show which employee asked the question that triggered it.
This gap between agent access and user-level permissions becomes a problem when something goes wrong. Knowing which service accessed a record is not enough if you cannot trace the request back to the person it was acting for.
Healthcare is a good example. HIPAA's minimum necessary standard generally requires limiting protected health information to what is needed for the purpose. If an assistant pulls patient data, the service account tells you what accessed it. It does not necessarily tell you who needed it, or why.
AI logs usually capture the prompt and the answer. Database logs capture database activity. What is often missing is the connection between them.
If an answer is challenged later, you need to know which query ran, which records came back, and which version of the data the model saw. A query log alone cannot tell you how those records influenced a particular answer.
Here article 12 of the EU AI Act offers a useful reference point. It applies to some high-risk biometric systems but the basic questions around logging make sense more generally: which database, what records, when, and who looked at them?
Sensitive data does not become harmless because it has been turned into an embedding. Morris and colleagues reconstructed 92% of 32-token inputs exactly from text embeddings and recovered full names from clinical-note embeddings. Later research demonstrated effective attacks against black-box encoders with roughly 1,000 samples.
The engineering point is pretty simple: sensitive data is sensitive no matter where it ends up. Vector embeddings are derived data, not a clean break from the source records that produced them. What is often missed is that the same controls do not necessarily conform to it. If the data is stored in a vector store, cache, prompt log, or evaluation dataset, then each of those requires its own access control, retention rules, and way to delete it.
Deleting a customer from the main database is easy. It gets a bit more complicated in an AI stack. The same data could also be present as chunks, embeddings, old index snapshots, prompt logs, evaluation sets or a fine-tuning dataset.
So “delete customer 4471 everywhere” is no longer one operation. It is closer to distributed garbage collection. Can you find every copy, remove it, and prove it is gone?
There is a similar problem with reproducibility. Re-embedding a corpus or rebuilding an index can change what gets retrieved. If an AI-assisted decision is questioned later, especially something like a financial-services adverse action, the source records may not be enough. You may also need the index version and the records retrieved at the time.
Deleting the row is no longer the same as deleting the data.
A schema change can now change what an AI agent is able to reach. Add a column to a table the agent can already query, for example, and that new data may become visible to the agent without anyone changing its configuration.
That makes schema changes part of the AI permission boundary. If an agent can inspect the schema and generate its own SQL, a schema diff is no longer just about what changed between staging and production. It can also tell you whether the agent's reachable data changed with the release.
Most of the controls here will already be familiar to database teams: review AI-generated SQL before running it, limit what tables and columns an agent can access, compare schemas across environments, check dependencies and make sure there is a way to roll changes back.
Database teams already have tools for most of this. GitHub can track schema changes, while GitHub Actions or Azure DevOps can run checks before those changes are deployed. Schema comparison and dependency checks add another layer when a release changes what an agent can reach. Tools such as dbForge AI Assistant are context-aware, meaning they can take relevant database context into account to generate more accurate and relevant SQL, as well as explain, troubleshoot, and optimize it. However, the final decision about what an agent should be allowed to access still belongs to the team.
The tooling is not the governance policy. It gives teams a practical way to enforce one.
Before scaling an AI system that touches enterprise data, ask five questions:
Database tooling can help with query review, schema changes, permissions, and tracing what happened. But it only covers part of the problem. You still need policy, monitoring, security controls, and clear ownership.
If these questions are hard to answer, switching models will not solve much. The problem sits lower in the stack.
Models will change. The data layer underneath them is much harder to swap out. That is why AI readiness has to go deeper than whether the current model works. Google's 2025 DORA research found that AI tends to amplify the engineering strengths and weaknesses already there. If data accountability is weak today, adding AI is more likely to expose that weakness than fix it.
And someone still has to own what happens. An agent can retrieve the data and generate the SQL, but it cannot decide who should be accountable for that access. Someone has to set the boundaries, review what matters, and decide whether the data is being used for the right reason.
That is really what AI readiness comes down to.
It is tempting to read that gap as a data quality problem: silos, stale records, half-documented schemas. Those things matter, but they also sit on top of a problem that gets far less attention.
Take a team with AI in production and ask one question. Pick an answer the internal assistant gave someone last Tuesday. Which record keys did it read? Who was it acting for? What authorized that use? Where are the copies of that data now?
Answering all four gets difficult fast. Not because the team was careless, but because AI readiness usually focuses on different questions: Does the model perform? Will the infrastructure hold? Has security signed off? While all these are fair questions, they only tell you whether the system works, not whether you can account for what it did with the data.
That missing accountability is the database compliance gap. It shows up across the data lifecycle: in access, retrieval, lineage, copies, and eventually deletion.
The growing gap between access and intent
Traditional applications usually give the database a fairly explicit request. Take a simple query:
Code:
SELECT vacation_balance FROM employees
WHERE employee_id = 4471 AND status = 'active';The database does not know why the application wants that information, but the scope is clear: return the vacation balance for one active employee. You can see exactly what was requested.
Now look at a basic vector search in a retrieval pipeline:
Code:
SELECT chunk_text FROM documents
ORDER BY embedding <=> $1
LIMIT 20;The database sees something very different: find the twenty chunks closest to this embedding. It may have no idea what the user actually asked. That context lives higher up the stack, in the prompt and application logic. Unless the retrieval layer carries it into its filters and logs, the database sees what was retrieved but very little about why.
That matters in practice. Say an employee asks an internal HR assistant how parental leave accrues. The retriever finds the leave policy, but it also pulls a paragraph from a grievance file because that document discusses leave entitlement too.
The retrieval worked. The problem is that relevance and purpose are not the same thing. A document can be a good semantic match and still be the wrong data to use for the request.
That is the gap AI retrieval exposes: the database can tell you what matched without necessarily knowing why it was appropriate.
Five places the gap opens
The compliance gap does not stop at retrieval. It shows up again as data moves through the rest of the AI stack.
Identity collapses into a service account
An AI assistant may serve thousands of users, but the database often sees the same service account for all of them. The logs might show that hr-ai-service read a record at 10:42 a.m. They may not show which employee asked the question that triggered it.
This gap between agent access and user-level permissions becomes a problem when something goes wrong. Knowing which service accessed a record is not enough if you cannot trace the request back to the person it was acting for.
Healthcare is a good example. HIPAA's minimum necessary standard generally requires limiting protected health information to what is needed for the purpose. If an assistant pulls patient data, the service account tells you what accessed it. It does not necessarily tell you who needed it, or why.
Lineage gets logged at the wrong layer
AI logs usually capture the prompt and the answer. Database logs capture database activity. What is often missing is the connection between them.
If an answer is challenged later, you need to know which query ran, which records came back, and which version of the data the model saw. A query log alone cannot tell you how those records influenced a particular answer.
Here article 12 of the EU AI Act offers a useful reference point. It applies to some high-risk biometric systems but the basic questions around logging make sense more generally: which database, what records, when, and who looked at them?
Derived data gets treated as a safe abstraction
Sensitive data does not become harmless because it has been turned into an embedding. Morris and colleagues reconstructed 92% of 32-token inputs exactly from text embeddings and recovered full names from clinical-note embeddings. Later research demonstrated effective attacks against black-box encoders with roughly 1,000 samples.
The engineering point is pretty simple: sensitive data is sensitive no matter where it ends up. Vector embeddings are derived data, not a clean break from the source records that produced them. What is often missed is that the same controls do not necessarily conform to it. If the data is stored in a vector store, cache, prompt log, or evaluation dataset, then each of those requires its own access control, retention rules, and way to delete it.
Deletion stops being a transaction
Deleting a customer from the main database is easy. It gets a bit more complicated in an AI stack. The same data could also be present as chunks, embeddings, old index snapshots, prompt logs, evaluation sets or a fine-tuning dataset.
So “delete customer 4471 everywhere” is no longer one operation. It is closer to distributed garbage collection. Can you find every copy, remove it, and prove it is gone?
There is a similar problem with reproducibility. Re-embedding a corpus or rebuilding an index can change what gets retrieved. If an AI-assisted decision is questioned later, especially something like a financial-services adverse action, the source records may not be enough. You may also need the index version and the records retrieved at the time.
Deleting the row is no longer the same as deleting the data.
Schema change is now a permission change
A schema change can now change what an AI agent is able to reach. Add a column to a table the agent can already query, for example, and that new data may become visible to the agent without anyone changing its configuration.
That makes schema changes part of the AI permission boundary. If an agent can inspect the schema and generate its own SQL, a schema diff is no longer just about what changed between staging and production. It can also tell you whether the agent's reachable data changed with the release.
Most of the controls here will already be familiar to database teams: review AI-generated SQL before running it, limit what tables and columns an agent can access, compare schemas across environments, check dependencies and make sure there is a way to roll changes back.
Database teams already have tools for most of this. GitHub can track schema changes, while GitHub Actions or Azure DevOps can run checks before those changes are deployed. Schema comparison and dependency checks add another layer when a release changes what an agent can reach. Tools such as dbForge AI Assistant are context-aware, meaning they can take relevant database context into account to generate more accurate and relevant SQL, as well as explain, troubleshoot, and optimize it. However, the final decision about what an agent should be allowed to access still belongs to the team.
The tooling is not the governance policy. It gives teams a practical way to enforce one.
Five questions to answer before scaling
Before scaling an AI system that touches enterprise data, ask five questions:
- Can we trace an AI answer back to the queries and records it used, including the version of the data at the time?
- Does each agent or retrieval service have its own least-privilege identity? Can we trace that activity back to the person it was acting for?
- Are AI-generated queries and schema changes reviewed before they reach production?
- Do our retention and deletion rules cover embeddings, caches, prompt logs, evaluation sets, and replicas? Can we tell when deletion is actually complete?
- If something goes wrong, can security trace the database activity back to the AI request that caused it?
Database tooling can help with query review, schema changes, permissions, and tracing what happened. But it only covers part of the problem. You still need policy, monitoring, security controls, and clear ownership.
If these questions are hard to answer, switching models will not solve much. The problem sits lower in the stack.
Takeaway: Readiness begins below the model
Models will change. The data layer underneath them is much harder to swap out. That is why AI readiness has to go deeper than whether the current model works. Google's 2025 DORA research found that AI tends to amplify the engineering strengths and weaknesses already there. If data accountability is weak today, adding AI is more likely to expose that weakness than fix it.
And someone still has to own what happens. An agent can retrieve the data and generate the SQL, but it cannot decide who should be accountable for that access. Someone has to set the boundaries, review what matters, and decide whether the data is being used for the right reason.
That is really what AI readiness comes down to.