Why You Cannot Trust an AI Formula or Query on Sight
Every AI tool I have tested is confident even when it is wrong. I have had it hand me a =SUMIFS formula that looked perfect and summed the wrong column because I described the range loosely, and a SQL query that ran fine but returned 40,000 rows where 8,000 should have been — the JOIN was duplicating records. None of that is obvious by reading the output. The mistake only surfaces when you check the number against the source data. So the workflow is not a nice-to-have; it is the thing that separates a useful AI assistant from a trap.
The good news is that verification does not have to be fancy. You do not need a second tool or a certification. You need a repeatable habit: after AI gives you anything, you run it on a small controlled sample, compare the result to a number you can compute by hand, and then scale it up. That is the whole method, and the rest of this guide is the concrete version of it.
Set a rule for yourself: nothing generated by AI goes into a report, a dashboard, or a query that a colleague will run, until you have verified it against real numbers at least once. I keep a scratch sheet for exactly this — a tab in the workbook or a sandbox schema in the database where AI output gets tested before it is promoted anywhere.
The Five-Step Workflow: Ask, Generate, Test, Verify, Adopt
Here is the workflow I use and that I teach in every training session I run. It has five steps, and the middle three are where most people skip ahead and get burned. Commit the names to memory — ask, generate, test, verify, adopt — and the habit is half the battle.
Before you prompt, write down what the result is supposed to do. 'Give me a SUMIFS' is a useless prompt. 'Sum column D for rows where column A equals the value in F2 and column B is greater than 100' gives the AI everything it needs to generate something close. The time you spend tightening the question is time you save on debugging.
Ask for the formula or query and paste it somewhere isolated — a blank tab in the workbook or a sandbox schema in the database. Do not paste it into the production report yet. You want a place where a wrong answer cannot do damage and where you can run the next two steps freely.
Feed the AI output the smallest real slice of data you have. For Excel, that might be ten rows you can audit by eye. For SQL, a WHERE clause that limits to a single week or a single region. The point is that you know the expected answer, so any deviation is visible. A sample you cannot inspect proves nothing.
Now check the result independently. For a SUMIFS, total the same rows by hand in a column next to it, or write a COUNTIF that confirms the row count. For SQL, run a COUNT(*) on the join before you trust any SUM column, and compare it to the count on the base table. Two methods agreeing is your green light.
If the number matches, promote the AI output to the real report or query. If it does not, debug the difference — do not tweak the output to force it to match. Finding out why it is off teaches you more than the AI ever will. Then move on to the next task and repeat the loop.
In my experience the biggest time saver is not better prompts — it is keeping a short list of 'known-good' AI outputs you have already verified. If you verified a SUMIFS pattern for one workbook, reuse that exact pattern instead of asking the AI again. Every verified formula becomes a template, and over a few weeks you stop asking for the basics entirely.
Worked Example in Excel: A SUMIFS You Cannot Trust Yet
Let me show the loop with a real case. Say you manage a small orders sheet with columns: A is Order ID, B is Region, C is Product, D is Quantity, and E is Revenue. You want the total revenue for the 'West' region where quantity is over 20. Ask the AI precisely, and it will hand you something like =SUMIFS(E2:E100, B2:B100, "West", D2:D100, ">20"). Looks right. Do not paste it into your monthly report yet.
Say exactly which column is summed (E, Revenue) and which columns hold the criteria (B for Region, D for Quantity). The more specific you are, the less room the AI has to guess a range. A prompt like 'sum E where B equals West and D is over 20' gets you to a workable start with less back-and-forth.
Filter the sheet down to ten rows, or copy ten rows to a scratch tab, and apply the AI formula. Count the matching rows by eye: which rows have Region = West and Quantity > 20? Add their revenue values by hand. If the AI's SUMIFS equals your hand total, the structure is right for that sample.
The classic trap with SUMIFS is a wrong range that still sums something. Before you trust it, run =COUNTIFS(B2:B100, "West", D2:D100, ">20"). If that count matches the number of rows you identified by hand, and the SUMIFS total matches your hand total, the formula is almost certainly correct. Two independent checks beat one.
Now apply the formula to the full 100-row range. The structure is proven, but re-check the final total one more way — a pivot table on the same columns is the fastest second opinion. If the pivot agrees, promote the formula to your report. If they disagree, one of the two is wrong, and you have caught it before anyone else saw the number.
Worked Example in SQL: When a JOIN Quietly Duplicates Rows
SQL is where AI mistakes get expensive, because a query can run fine and still be wrong. My most common encounter is a LEFT JOIN that inflates numbers. Say you want the total sales per customer, and the AI generates something like SELECT c.customer_id, c.name, SUM(o.amount) FROM customers c LEFT JOIN orders o ON c.customer_id = o.customer_id GROUP BY c.customer_id, c.name. Reads clean. But if a customer placed three orders, that customer shows up three times in the join, and any other table you join onto it multiplies again.
The number one habit in my workflow is to run a COUNT(*) on the joined result before trusting any SUM. SELECT COUNT(*) FROM customers; tells you how many rows the base table has. Then SELECT COUNT(*) FROM (your join) tells you how many the join produced. If they are not equal, the join is duplicating rows and every SUM on top of it is wrong. You will hit this with almost every multi-table query.
Pick a single customer who placed a known number of orders, and run the query filtered to just them. If they placed three orders, the joined row count for them should be three. Sum the amounts on those three rows by hand and compare to the GROUP BY result. A mismatch here pinpoints the duplicate before you scale the query up.
Add a helper count to expose duplication: SELECT c.customer_id, COUNT(o.order_id) AS order_count, SUM(o.amount) AS total FROM customers c LEFT JOIN orders o ON c.customer_id = o.customer_id GROUP BY c.customer_id ORDER BY order_count DESC. A customer with order_count of 5 is not necessarily wrong — it means five orders. What you are looking for is an order_count that makes no sense, which is the signal your join is too loose.
When the numbers are off, feed the discrepancy back to the AI: 'This join returns 40,000 rows but the base customer table has 8,000 — why?' In my experience the AI will explain the fan-out and suggest a fix, usually a tighter join condition or a subquery that dedupes first. Let it propose, but verify the fix the same way you verified the original. The loop does not end because the second answer looks better.
How to Phrase Prompts So the Output Is Checkable
A lot of the verification burden disappears if the prompt sets up the check from the start. When I write a prompt now, I ask for three things in one shot: the formula or query, a short explanation of what it does, and a note on what could break it. The explanation gives me a map to check against, and the risk note tells me where to look first. You can copy that habit directly.
Write the column names exactly as they appear in your sheet or schema. Vague labels like 'the total' or 'the amount' invite the AI to guess the wrong field. In my experience, prompts that name the exact columns cut the debugging loop in half. 'Sum the Revenue column (E) where Region (B) equals West' gets you much closer to a correct formula the first time.
Add one line: 'what could go wrong with this, and how would I check it?' For Excel that surfaces the empty-cell and duplicate pitfalls. For SQL it often surfaces the JOIN fan-out and the NULL-handling issues. When the AI flags its own risk, you know exactly which check to run, and you look like you wrote the query yourself.
Ask for a companion check as part of the output. For Excel, that might be 'and give me a COUNTIFS to sanity-check the row count.' For SQL, 'and give me a COUNT(*) query that tells me how many rows this join should produce.' You get the work and the check in one prompt, and you do not have to invent the verification step from scratch.
Save the prompts that work. I keep a short file with a template for 'ask for formula + explanation + risk + verification query,' and I paste it in and fill in the specifics each time. It makes the whole workflow a copy-paste operation and guarantees I never skip the verification step out of laziness.
Where AI Actually Saves You Time (and Where It Does Not)
Used well, AI does not replace the thinking — it removes the typing. I lean on it hardest for syntax I do not use every week: a tricky array formula, a window function in SQL I have not written in months, or converting a formula from one dialect to another. Those are exactly where a human is slow and where the AI output is easy to verify against a small sample. The verified example above is the model for that.
Ask it to rewrite a SQL query from MySQL to Postgres, or to convert a VLOOKUP to an INDEX/MATCH. These conversions are mechanical, the AI is fast, and you can verify the output on a sample. It is a low-risk, high-speed use case and it keeps your skill level relevant when you switch tools. Just run the verification loop before you commit the result.
When you inherit a spreadsheet or a query you did not write, paste a slice and ask what it does. The explanation is usually good enough to orient you, and you can then verify your understanding by running the step yourself. This is one of my favorite uses because it turns a confusing file into a learning opportunity instead of a mystery.
The one place the workflow breaks is when you ask AI to cover for the fact that you have not looked at your own data. If you do not know whether your orders table has duplicates or whether your Region column has trailing spaces, no AI output can be trusted. Spend the time understanding the source first; AI is a multiplier on top of that, not a replacement for it.
For business-critical calculations — the revenue number your boss reads in a meeting — write the logic yourself and use AI only as a second opinion. When you are responsible for a number, you want to be able to defend it, and you can only do that if you wrote or fully verified the logic. This is the boundary I recommend every analyst draw.
In my experience the fastest way to get good at verification is to break things on purpose. Take a correct formula or query and introduce a known bug — a wrong range, a loose JOIN — then see if your check catches it. Do this a few times a week and the patterns become automatic. You will hit this habit paying off the first time you catch an AI error a coworker already shipped.
Your Verification Checklist (Print It or Paste It in Your Notes)
Here is the workflow as a checklist you can reuse on every AI-assisted task. It is the same loop from the top of this guide, condensed into actions you can actually do today. If you want to go deeper on the Excel and SQL fundamentals this depends on, start with the guides I linked below — the more solid your basics, the faster your verification gets.
Before you prompt, define the expected result in a sentence you could explain to a colleague. 'Total revenue for West, quantity over 20' beats 'sum it up.' This sentence becomes your test oracle for every later step.
One prompt: the formula or query, a one-line explanation, and a verification query you can run. If the AI will not give you a check, ask for it explicitly. A tool that refuses to provide its own test is a tool you should verify twice.
Do the small-sample run first, always. For Excel, ten auditable rows. For SQL, one customer or one week. Compare the AI total to your hand total. If they match on the small sample, the structure is sound.
COUNTIFS in Excel, COUNT(*) in SQL. The row count is your early warning system for duplicates and wrong ranges. If the count does not match, stop and debug before you touch any SUM.
Run on the full data and confirm the final number with a different method — a pivot table, a second query, or a known total. Two agreeing methods are your green light to promote the output to the real report.
Only after it passes do you move the output into the report or the production query. Note the date and the verification method in a comment or a cell note, so that in three months you (or a colleague) can see that this number was actually checked.
For the Excel and SQL basics that make this workflow fast, work through Excel for Data Analysis and SQL for Data Analysis. If you want to see how this fits into the broader shift toward tool-assisted analysis, read AI Tools for Data Analysis and the career angle in AI Skill Transformation for Data Analysts. Then take one of the examples in this guide, run the loop on it, and you will have the habit before the week is out.
