How Does AI Written SQL Reach Production?

A developer describes the production schema to an assistant and says "fix last month's bad records". The SQL that comes back looks reasonable. Nobody asks where the text came from, because code review looks at the text and not its author. This article is about which control is missing on the road that AI generated SQL takes into production.

No Decision Was Taken; It Already Happened

Most organisations have not yet formed a policy on this, but the situation did not wait for one. A 2026 industry survey found that almost all organisations report at least one AI interaction with their production databases: analytics and reporting, training pipelines, internal copilots and directly generated SQL. Meanwhile the share that consistently automates security and compliance checks before deployment sits a little above one third.

That gap is not a new technology debate but a familiar governance gap: a new road into the production database opened and no gate was defined for it. In the same survey, close to half of respondents flag ungoverned generated SQL as a concern. Many are aware of the problem; few have built the control.

The Difference From a Developer: No Hesitation

The objection that SQL is SQL and it does not matter who wrote it sounds reasonable and is partly right. Once the text exists, its origin does not change the risk assessment. The difference is in how the text came to exist.

A developer writing an unqualified delete hesitates while writing that line. They know what will happen, they know they will answer for it, and they usually check once more. Even if they do not, a colleague catches it in review.

None of that applies to an assistant producing the same statement. It has no awareness of the consequence, no stake in the outcome and therefore no hesitation. It produces SQL that looks plausible given the prompt and the context it received, not given what the production database can survive.

The distinction matters because most existing controls rest on human behaviour. The assumption that nobody would do that is a silent control nobody thought about, and it quietly disappears when a producer for whom the assumption does not hold enters the picture.

Three Typical Failure Modes

1. Objects and columns that do not exist. A model can produce a column name that is not in the schema. That is the most harmless failure, because it errors on execution and gets noticed. The dangerous version is picking a column whose name is right but whose meaning is different: both tables have a status column and the model uses the wrong one. The statement runs cleanly and updates the wrong rows.

2. Statements with too wide a scope. The instruction "fix last month's bad records" leaves the definitions of last month and bad to the model. The model makes a plausible interpretation, and that interpretation is usually broader than intended. The result is a statement that looks right and touches far more rows than expected.

3. Context that never travels. The model does not know the organisation's critical object list, its maintenance window, why that table is special or a decision taken years ago. None of that is written in a schema definition. A technically flawless statement can still violate the organisation's own rules.

Why Natural Language Guardrails Are Not Enough

The common answer is to instruct the model: only produce read queries, never write a delete. This is a request rather than a security control.

Limits set through a system prompt can be crossed two ways. First, a carefully crafted input can override the instruction. Second, and more insidiously, the model's own structural error can break through without noticing the limit: a model told to read only can produce a statement that modifies data, because it does not evaluate what its output means, it predicts a likely continuation.

The valid security rule is this: a boundary is not enforced by asking the party that would cross it. The control belongs where the text reaches the database, not where the text is produced. That is not a new principle; it is the same one that says input validation cannot be left to the client.

The Scale Problem: Manual Review Does Not Keep Up

The most common plan here is that a database administrator should review every piece of AI generated SQL. The intent is right and the plan is unworkable.

The reason is simple: the rate of production changed while review capacity did not. There is an order of magnitude between how many scripts a developer writes in a day and how many an assistant can produce in the same time. Manual review cannot match that volume or velocity. Forced to try, it produces the familiar outcome: review degrades into a formal approval and the real control disappears.

That does not mean human review is unnecessary. It means human review cannot be the first filter. The first filter has to be a machine, with people looking at the minority the machine flags. This is not a model invented for AI; setting approval depth by risk band is a known approach and it works here unchanged.

A Model That Works: Judge the Text, Not the Author

The core principle of the right design is that the rule applies identically regardless of who produced the text. A person and an assistant pass through the same gate and are measured by the same standard. That principle removes the need for a separate governance regime for AI.

The text is parsed, not searched. Keyword matching misleads: whether a statement is unqualified, which object it touches and what type it is can only be established reliably by analysing it according to the grammar of the language. Once the text is parsed, who wrote it becomes irrelevant.

Risk comes from content. An unqualified update, touching a table on the critical object list, an irreversible operation: these are written rules, and the same script always lands in the same band. Taking the assessment out of human judgement is the one property whose value grows as volume grows.

Approval is tied to the execution gate. Approval is a condition rather than a field; execution does not open until approval completes. Text produced by an assistant, however plausible it looks, cannot pass that gate on its own.

The origin is recorded. Origin does not set the risk, but it should be recorded. Six months later, the answer to who wrote this script should be able to read as: an assistant produced it, this person submitted it, this person approved it. That information is useful less when something breaks and more when you want to understand the pattern.

SQL Change Guard applies this model without distinguishing origin: every script is parsed, the risk band comes from content, execution does not open until approval completes, and the rollback is prepared from the current definition on the server. No separate regime is needed for AI, because the gate already looks at the text itself.

Frequently Asked Questions

Would banning AI tools not be simpler?

It looks simple but it is not enforceable, and it usually inverts the outcome. A ban does not remove the usage, it makes it invisible. The developer still uses the assistant, submits the output as their own work, and the organisation now has no idea of the origin. Usage that cannot be measured cannot be managed. The approach that works better is to accept the usage and harden the gate the text passes through.

Is giving the model our schema a security risk?

There are two separate questions here and they should not be merged. Sending schema information, table and column names, to an external service leaks knowledge about the organisation's internal structure; that is different from a data breach but it is a real risk, and it can be reduced with models running inside the organisation. The much larger risk is not the schema but supplying real data as input: pasting production rows to explain a bug moves that data outside the organisation, and that is a transfer. The two need to be assessed separately.

Would giving the assistant read only access not be enough?

It is the most effective step in the right direction and far stronger than a natural language instruction, because the boundary is set by the connection itself. Two points need attention though. First, read only access prevents modification but not seeing data; sensitive columns remain readable and that is a separate data protection question. Second, a badly written read query can still slow production down. Read only closes the modification risk; it does not close the access or performance risks.

Should AI generated scripts go through a separate process?

No, and a separate process weakens things for two reasons. First, the distinction depends on the origin being declared honestly, and the whole thing collapses when it is not. Second, applying rules by origin means measuring risk in the wrong place: an unqualified delete is equally dangerous whoever wrote it. The right design is one process with content based assessment, where origin is kept only as a record.

What is the first step to take today?

Start with an inventory: which teams, using which tools, connect to which environments? Building that list takes a few days and usually comes out longer than expected. Then set one rule: no SQL reaching the production database, whatever its origin, runs without being parsed, assessed and approved. Those two steps close most of the risk without writing an AI specific policy at all.