How to use AI in data analytics

TL;DR

Hand over translation work: question to SQL, messy column to clean one, unknown file to description. Keep the judgment calls, which number is right and what caused a change.

Fix the shape of the file first. One table, one header row, column names that say what they hold.

For cleaning, ask for a script rather than a cleaned file. A script is reviewable, repeatable and honest about what it dropped.

For SQL, paste your schema and dialect, then read the query for join fan-out and date boundaries before you trust the number.

Verify cheaply: ask something you already know the answer to, ask the same thing two ways, and tie one total to a system of record.

Keep it away from sensitive data in uncleared tools, audited reporting, and anything going out unchecked.

Most advice about AI in analytics arrives in one of two flavours. Either it replaces the analyst, or it is autocomplete with a good marketing budget. Neither is much help when you have a dataset open and a question to answer by lunchtime.

The truth sits somewhere narrower, and this guide follows an ordinary workflow through it, from raw file to write-up. What to hand over at each stage, what to keep, and how to check the output without doing the whole job twice.

Where AI fits in the analytics workflow

The rule we keep coming back to: hand over the work you could check in a minute but would take an hour to write.

A window function you half remember. A regex for parsing inconsistent product codes. A description of what is actually inside the 40-column export somebody dropped in your inbox on a Friday afternoon.

Turn that rule around and you get the work to keep. Where the answer is quick to produce but slow to check, AI stops helping and starts costing you. "Why did signups drop last week" takes the model three seconds, and you cannot verify it without context that lives in your head, your team's Slack, and last month's release notes.

So: cheap to verify, hand it over freely. Expensive to verify, use AI to generate candidates and do the deciding yourself.

One more thing before the steps. The model has no idea whether it is right. Its most fluent, most confident output often arrives at the exact moment it has misread your data, because in these systems fluency and accuracy have nothing to do with each other. Every verification habit below exists because of that one fact.

How to prepare your data for AI analysis

Most bad output traces back to bad input, and most bad input is structural rather than dirty. Ten minutes on the shape of the file removes an entire class of failure.

Use one table with a single header row

AI tools read tabular data much the way a script does. One rectangle, one row per record, one header row at the top.

Which means the things that make a spreadsheet pleasant for humans are exactly the things that break it:

merged cells across the top
a title in row 1 and the real headers down in row 4
subtotal rows sitting inside the data
blank spacer rows between sections
two tables side by side on one sheet
colour used to mean something, which the model cannot see at all

If your file does any of that, export a clean copy first. One sheet, headers in row 1, no totals inside the body, no formatting carrying meaning. A CSV beats a workbook with twelve sheets and cross-references, mostly because you know exactly what the model is looking at.

Wide data causes its own trouble. If you have twelve columns running jan_revenue through dec_revenue, ask for it in long format first: one row per month per entity, with a month column and a revenue column. Every aggregation afterwards gets simpler, and simpler questions produce fewer wrong answers.

Rename columns to describe what they contain

Column names are the only clue the model has about meaning. Col_F, metric_2 and value tell it nothing, so it guesses, and it guesses quietly.

Rename them to whatever you would say out loud:

rev becomes revenue_usd
date2 becomes trial_start_date
amt becomes order_total_cents, if that is what it holds

That last one matters more than it looks. A model that assumes dollars when the column holds cents will be wrong by a factor of a hundred and will never mention it.

Then watch for names that actively lie. A column called users that really contains sessions will produce confidently wrong answers all afternoon, and none of them will look wrong.

Describe the dataset before asking questions about it

Before your first question, write two or three sentences about what the data is. This is not only for the model's benefit. Writing it down has a way of surfacing your own assumptions.

Something like:

One row per completed order from our store, January to August 2026. total is USD and includes tax but not shipping. Refunded orders are still in here with status = refunded. Each customer_id can appear many times.

That last detail is what prevents the most common error of all. Without it, a question as innocent as "what was our average order value" gets answered across refunded orders too, and nothing in the output will tell you it happened.

Say what the grain of the table is, too, meaning what one row represents. Most bad aggregations trace back to the model assuming one row per customer when it is really one row per order line.

How to clean messy data with AI

Cleaning is where AI pays for itself fastest. The tasks are tedious, well defined, and cheap to check:

standardising a country column that holds USA, U.S., United States and us
parsing dates stored in four different formats
splitting a full name field
bucketing free-text job titles into categories
finding duplicate records where the email matches but the spelling of the name does not

The single most useful habit here is this: ask for a script, not a cleaned file.

Paste 5,000 rows in and get 5,000 rows back and you have no idea what happened in between. Rows may have been dropped. Values may have been reformatted. The model may have hit an output limit and truncated without saying so. A script is reviewable before you run it, repeatable next month when the same export lands again, and honest about what it does.

So the request looks more like this:

Write a Python script using pandas that standardises the country column to ISO two-letter codes. Print the distinct values before and after, and the row count at each step. Do not drop any rows. Flag anything you cannot map instead of guessing.

That final instruction does a lot of work. Told to standardise, a model maps ambiguous values to whatever seems plausible. Told to flag what it cannot map, you get a short list to handle yourself, which is the right outcome.

Then check four things before you accept the result:

Row count, before and after. It should not have moved unless you asked it to.
Null counts per column. Silent type coercion shows up here first.
The sum of your main numeric column. Unchanged, unless changing it was the point.
Distinct values of whatever you cleaned. The fastest way to catch two categories that got merged when they should not have been.

How to explore an unfamiliar dataset with AI

Somebody sends you an export with 40 columns and no documentation. Of everything in this guide, this is where you will save the most time.

Ask for a summary of the data before asking for answers

Do not open with your real question. Open by asking the tool to describe what it has: every column with its type, ranges for the numeric ones, missing value counts, distinct value counts, and a handful of example rows.

You are reading that output for surprises, and there are usually one or two:

a date column that turns out to be text
a revenue column with negative values nobody warned you about
an ID column with 60% duplication when you expected it to be unique
a country column with 190 distinct values, several of them blank variants

Ten minutes here saves you from building an afternoon of analysis on a misunderstanding.

Break one large question into several small ones

"What are the insights in this data" produces the same generic paragraph no matter what you uploaded. It is not really a question, so what comes back is not really an answer.

Specific comparative questions work far better, and each is easy to check:

Which five product categories had the highest revenue in Q2, with revenue and order count for each?
How many customers ordered more than once, and what share of total revenue came from them?
What is the daily order count for August, and which days sit more than 20% below the monthly median?

Small questions have a second advantage. When one answer is wrong, you notice, because the numbers stop agreeing with each other. Ask one enormous question and a single bad assumption gets baked invisibly into all of it.

How to write SQL and spreadsheet formulas with AI

This is the most dependable use of AI in analytics and the one most analysts keep permanently. Window functions, gnarly date logic, pivot formulas, regex, the syntax differences between BigQuery and Postgres. Real time saved, low risk, provided you read what comes back.

Give the model your schema, not just your question

A question on its own produces a query against imagined tables. Paste the actual CREATE TABLE statements, or a compact description of each table with its columns, types and grain.

Four things people routinely leave out:

the SQL dialect, because date functions differ everywhere and generic SQL often will not run
the grain of each table, which determines whether your join fans out
the join keys, and whether they are actually unique
the filters that always apply, like excluding test accounts or internal orders

For spreadsheets, name the application and version, since Excel and Google Sheets have drifted apart on newer functions, and say whether your data sits in a named range or a table.

Read the query before you trust the number

The query will usually run. Running is not the same as correct, and a query that returns a plausible number while quietly double counting is worse than one that throws an error.

Five things to check, roughly in the order they go wrong:

Join fan-out. Join orders to order items, then sum order_total, and every order gets counted once per item. The total comes out too high and looks entirely reasonable.
Date boundaries. BETWEEN '2026-01-01' AND '2026-08-31' quietly drops most of the last day when the column is a timestamp. Check whether the range is inclusive, and whether timezones are in play.
Counting. COUNT(*) counts rows. COUNT(DISTINCT customer_id) counts customers. Models mix these up, especially after a join.
Inner joins doing filtering you never asked for. An inner join to a dimension table drops every fact row with no match. If 3% of your orders have a null region_id, they have just vanished from the analysis and nothing announced it.
Averages of averages. Averaging a column that is itself an average is wrong unless every group is the same size. Easy to miss, because the output looks fine.

If you only ever run one of these checks, make it the first. Take the aggregation off the query and look at the row count against what you expected.

How to use AI to explain a change in your metrics

Conversions fell 14% last week and somebody wants to know why. This is where AI is least reliable and most confident, which is an unfortunate combination.

It genuinely helps with the first half of the job. Ask it to list plausible explanations given what the data contains, and to propose a specific check for each. In seconds you get a decent hypothesis list:

mix shift between channels
one large customer churning
a change in the denominator rather than the numerator
ordinary seasonality
a data collection problem
a single segment dragging the average down

What it cannot know is that pricing changed on the 14th, that a tracking tag broke on mobile Safari, that a competitor ran a promotion, or that marketing paused a campaign to move budget around. None of that is in your table. The model will still produce a confident causal story built entirely from what it can see, and the story will be plausible enough that somebody repeats it in a meeting.

Use it to generate the list, then to write the queries that test each item. Keep the conclusion for yourself, and say why you believe it. "Enterprise fell 40% while everything else was flat, and it lines up with the two accounts that churned on the 8th" is an analysis. "Conversions declined due to a combination of seasonal factors and market conditions" is what you get when you let the model decide.

How to use AI to write up your analysis

Once the numbers are verified, drafting the commentary around them is a fair handover. Turning rough notes into a summary for people who will never read the appendix is real work, and models are good at it.

Two rules keep it safe:

Give it your verified numbers as text and tell it not to recalculate anything. A model asked to write a summary from raw data will helpfully compute fresh figures that do not match your output.
Say who is reading and what they have to decide. "For the finance team deciding next quarter's budget" produces something usable. "Write a summary" produces filler.

Then read it as an editor. Models default to hedged, agreeable prose and will soften a finding until it says nothing at all. If your analysis says the channel is not working, the write-up needs to say the channel is not working.

How to verify AI output without redoing the analysis

If verification means recomputing everything by hand, nobody will bother. These three habits are cheap enough that people actually keep them.

Test it on a question you already know the answer to

Before you ask a new tool anything real, ask it something you can already answer. Total revenue for last month. Headcount at the end of Q1. Any number you have in a dashboard.

Get a wrong answer and you have learned something important in thirty seconds. Get a right one and you have learned a little about how it reads your columns. Worth doing with every new tool, and again whenever you upload a differently shaped file.

Ask the same question two different ways

Ask for average order value. Then, separately, ask for total revenue and total order count, and divide them yourself. Two routes to the same number should agree.

When they disagree, the gap itself tells you where the problem is, usually a filter applied in one calculation and not the other. This catches more real errors than any amount of staring at a single output.

Reconcile totals against a source you trust

Whatever the analysis, one number in it should be checkable against a system of record: billing, the CRM, the finance close, a dashboard somebody else already validated.

Tie one total to that source. Within a rounding error, and your foundation is probably sound. Off by 8%, and you stop and find out why before building anything on top of it.

The underlying rule: never let the model be the only place a number exists. If the sole evidence for a figure is that a chat window produced it, it is not a finding yet.

When not to use AI in data analytics

Some situations are not worth the risk, or simply not worth the effort:

Sensitive data in tools you have not cleared. Customer records, health data, payroll, anything under contract or regulation. This is a legal and procurement question before it is a technical one, and pasting a customer export into a personal account is the sort of mistake that outlives the analysis.
Regulated or audited reporting. Financial closes and statutory reporting need provenance for every figure. If you cannot show where a number came from and reproduce it exactly, the shortcut creates work rather than saving it.
Small, familiar data. If a pivot table answers it in two minutes, use the pivot table. Writing a decent prompt and checking the result takes longer than the thing you were avoiding.
Anything going out unchecked. The failure mode that hurts is not a broken query. It is a beautifully formatted wrong answer in a board deck. If nobody has time to verify it, do not use AI to produce it.
Causal claims. Worth saying twice, because it is the most common way these projects burn trust. Correlation from a model with no knowledge of your business is a hypothesis, not a cause.

Building an AI analytics workflow you can trust

Put together, the workflow is unglamorous, and it holds up:

Get the data into one clean rectangle with honest column names.
Write two sentences on what it is and what one row represents.
Ask for a profile before you ask a question.
Hand over cleaning as a reviewable script, not a pile of output.
Give the model your schema when you want SQL, then read the query for fan-out and date boundaries.
Use it to generate hypotheses about changes, never conclusions.
Tie one number to a source you trust before you believe any of it.

What you get out of that is a faster version of the job you already do, with more of your time on the parts that need judgment and less on remembering window function syntax. That is a real gain, and we would not go back.

It is also a good deal less than what usually gets promised, which is exactly why the verification habits matter more than the prompting tricks.