How to Validate AI-Generated SQL Before Running It

AI can draft SQL quickly, but a query that looks plausible may use the wrong table, join unrelated rows, expose more information than intended, or change data. Treat generated SQL as an untrusted draft. Review it against your schema and the database’s documentation before execution.

This checklist is for people who already have authorized database access. It is not a substitute for a DBA or security review for production, regulated, or high-impact systems.

1. Confirm the task and the data source

Write down the expected result in plain language: which records, what date range, what aggregation, and what should be excluded. Confirm the database, schema, and table names against an approved schema reference. AI may invent a column or assume a relationship that does not exist.

Check each join key and cardinality. A many-to-many join or missing join condition can multiply rows and distort totals. Compare a small, known example or independently calculate a sample before trusting an aggregate.

2. Identify whether the query changes anything

Read the full statement, including common table expressions, nested queries, functions, and any statements after a semicolon. Determine whether it only reads data or can insert, update, delete, create, alter, execute a procedure, or change permissions. Never rely only on the AI’s description of its query.

For a read-only report, reject unexpected write operations. For an authorized change, get an independent review, confirm the exact target set, and use the organization’s approved change process and recovery plan.

3. Review filters, scope, and sensitive fields

Check that date boundaries and time zones match the request.
Verify that filters do not omit an important condition or accidentally include all records.
Ask whether the output needs names, emails, account numbers, or other sensitive columns. Remove fields that are not needed.
Watch for broad wildcards, unbounded result sets, and expensive functions on large tables.
Check that user-supplied values are passed as parameters by the application rather than concatenated into SQL text.

4. Use a safe validation environment

Do not start on production. Use a disposable or approved development environment with representative, non-sensitive data.
Use least privilege. A read-only account should not be able to modify records, schemas, or permissions. Separate accounts and approvals for authorized write operations.
Check syntax for your database. SQL dialects differ. Validate against the specific engine and version instead of assuming that syntax accepted elsewhere will work.
Inspect the plan and cost. Where supported, examine the execution plan and estimated work. Plan inspection is not a guarantee of safety or low impact; behavior varies by database.
Limit the test. Use a small, controlled sample where it preserves the logic. A row limit alone does not necessarily prevent an expensive scan.
Compare results. Check row counts, duplicates, null behavior, and totals against an independent expectation or known sample.

5. Treat transactions and parameters as controls, not magic

Parameterized queries help keep values separate from SQL instructions in application code; they do not validate business logic or make an overbroad query correct. Follow your database and framework’s parameterization guidance.

A transaction can help group supported changes, but not every command or side effect is reversible, and transaction behavior differs across systems. Do not assume that “I can roll it back” makes an unreviewed production query safe.

A quick review checklist

Does the query match the requested outcome and use real schema objects?
Are joins and filters correct, specific, and tested?
Does it return only the data needed?
Is it read-only, or has the intended change been independently approved?
Has it been tested with least privilege in a non-production environment?
Have syntax, plan, row counts, and representative results been checked?
For application use, are values parameterized and errors handled safely?

Bottom line

Generated SQL can accelerate drafting, but correctness depends on the schema, task, database engine, and permissions. Review the statement yourself, test with non-sensitive data and least privilege, and get an appropriate human review before any production change. If you cannot explain what each part does, do not run it.