AI in the Business Analyst Workflow: Where It Helps, Where It Breaks

It's 9:14 on a Monday. A VP forwards a Slack screenshot. Their CSM tool's new AI assistant says active customers grew 38% last quarter. The exec wants to put that number in a board deck by lunch.

You open the warehouse. The actual figure is closer to 12%. The chatbot counted every row in customers regardless of status, ignored the is_test flag your data engineer added in February, and quietly summed a metric that resets monthly as if it were cumulative. You now have forty minutes to explain what went wrong without sounding like a person who is afraid of being automated away.

This is the BA's life now. Every BI tool ships an "ask in plain English" feature. Every IDE has an autocomplete that writes joins. Most of the output is wrong-but-confident SQL: queries that run, return numbers, and miscount in ways that don't trip any guardrails. Someone has to be the last line of defense. That someone is still you, and the tools have not made the job easier so much as they have shifted where the hard parts live.

Here is the working BA's view, written for people who have shipped real dashboards and gotten real things wrong.

Where AI Genuinely Helps the BA

There is real leverage here. Refusing it on principle is the same energy as the analysts who insisted on writing every join by hand in 2014 because IDEs were "for juniors." The work has changed. Five places where AI earns its keep:

SQL drafts to refactor. Skeleton joins, window function syntax, regex for that one log field nobody documented. You give Claude the column names and a one-line description of what you want, and it returns a query that is 70% correct and 100% better than starting from a blank file. You then refactor it. The model is faster than your fingers; your fingers were never the bottleneck anyway.

Dashboard schema documentation. Forty-three columns in fact_orders, three of them named things like flag_2 and legacy_amt_v3. Paste the schema and the recent commit history into a model and ask it to draft column descriptions. You'll fix half of them. You will also have written documentation that did not previously exist, which beats the version where it never gets written at all.

Requirements interview prep. Before a stakeholder kickoff, ask the model to generate the awkward questions you tend to forget, like "what does 'churned' mean here, calendar month or rolling 30 days?" or "how do we handle accounts that downgrade and then upgrade in the same period?" The model does not know your business. It is good at reminding you of the categories of question you have to ask anyway.

Anomaly detection on known datasets. Point a model at a time series and ask "where would a careful person look first?" It will flag the right things: sudden null surges, point-in-time spikes, days where the row count drops to a rounded number that suggests a partial load. You still have to investigate. The model just compresses the scanning.

Data dictionary maintenance. Turning Jira tickets into glossary entries is a real chore. Feeding a closed ticket into a model and asking for a one-paragraph definition is the kind of mechanical writing that AI does adequately and you would otherwise never get around to.

Notice the pattern: AI is useful where the input is bounded and you remain the editor. The moment the model is the final author, things start to slip.

Where AI Quietly Breaks

This is the section that matters. The failures are not loud. The query runs. The chart renders. The number is wrong in a way that takes thirty minutes of warehouse archaeology to prove.

Data semantics. Your orders table has a status column with values like pending, processing, shipped, delivered, returned, void, chargeback, and legacy_v2. Which of those means "actually a sale"? Your Finance team has an opinion. Your Ops team has a different opinion. The model does not know either of them and will pick the most plausible-sounding option, usually delivered, which is wrong about 8% of the time because of returns posted in a separate batch.

Null handling. The model defaults to WHERE column IS NULL checks. Your warehouse uses empty strings, sentinel dates like 1900-01-01, the literal string "NULL", and one column where missing values are encoded as -999. The model will not catch any of these unless you tell it. Most BAs forget to tell it because they have internalised the quirks and no longer see them.

Business logic. "Active customer" has at least six definitions in any warehouse older than two years. Logged in this month. Has a paid subscription. Has a paid subscription and is not in dunning. Has a paid subscription, is not in dunning, and is not flagged as a test account. Has used the product in the last 14 days. Was active per Finance's snapshot at month-end. The model will pick one. It will not tell you it picked one. The CRO will quote the resulting number in a board meeting.

Governance. Pasting customer rows into a chat window is a data exfiltration event. Pasting the schema is borderline. Pasting query plans that include real PII is a real incident. Most BAs do not think of "ask Claude" as a data movement, but Legal absolutely does, and so does the next auditor.

I have seen each of these break a real analysis in the last twelve months. None of them announce themselves. The query runs. That's the point.

The Cursor + Claude Loop for SQL

The way this actually works in practice, for me and the BAs I trust:

Step 1: Force assumptions before code. First prompt is never "write the query." It's "before you write SQL, list every assumption you'd have to make to answer this question against this schema." Paste the relevant table definitions. The model returns a list. You edit it. About a third of the assumptions will be wrong, and you'd rather argue with a list than with a finished query.

A real example. The question: "monthly active accounts by plan tier for Q1." The model's assumptions, lightly edited:

1. "Active" means last_activity_at within the calendar month.
2. Plan tier is accounts.plan_id joined to plans.tier_name.
3. Test accounts (is_test = true) are excluded.
4. Free trial accounts count as active.
5. Accounts with multiple plan changes in a month are attributed to their plan at month-end.
6. Time zone is UTC.

Numbers 4 and 5 are wrong for our reporting standard. Free trial accounts do not count, and we attribute by start-of-month plan because that's how Finance does it. Catching that here saves you from a query that reports the right shape with the wrong numbers.

Step 2: Draft in Cursor. With assumptions corrected, ask for the query. Cursor's editor lets you see the schema in the sidebar, which means the model is less likely to hallucinate column names. It will still hallucinate one or two. That's why you read it.

Step 3: Refactor like a dbt PR. Treat the AI-generated query the way you'd treat a junior's PR. Comments at the top noting purpose, assumptions, and "AI-assisted draft, refactored by [you]." Inline notes on any non-obvious join. Test counts at the end (SELECT COUNT(*) FROM final against a known reference) before sending the result to anyone.

Step 4: Run it against the warehouse, twice. Once on a small date range to sanity-check the shape. Once on the real range to get the answer. If both numbers feel implausible, they are. The model has zero opinion on plausibility. You do.

This loop is not slower than writing SQL from scratch for most non-trivial queries. It is materially faster. It is also materially safer than the version where you accept the first draft.

The "AI Generated This Query" Trap

There's a new excuse going around. Someone ships a wrong number. The post-mortem lands. The phrase appears: "the AI generated this query."

The phrase is doing two jobs. The honest one: "I was using a tool, the tool was wrong, I didn't catch it." Fine, that happens, log it, move on. The dishonest one: "the responsibility for this number lives with the model, not with me." That's the modern equivalent of citing Wikipedia in a court filing and shrugging when the citation turns out to have been someone's joke edit from 2009.

If you sent the number, you own the number. If you ran the query, you own the query. The model is a writing tool. You are the analyst. Stakeholders do not care about the chain of custody beyond your name on the ticket, and they shouldn't have to.

The practical version of this rule: never paste a model's output into a stakeholder ticket without first running it through the warehouse. Not "looking at it." Running it. With a row count. Against the actual schema, with the actual filters, on the actual date range. If you find yourself about to skip that step because the deadline is tight, the deadline was always going to be tight, and skipping is how the wrong number gets quoted in a board deck.

Governance and Versioning

Treat AI-assisted analysis like any other code, because it is code. A working checklist:

• PR review. Every AI-assisted query that ships to a dashboard or a recurring report goes through the same review as a hand-written one. No exceptions for "it's just a quick number."
• Comments noting assistance. A header line: -- AI-assisted draft (Claude, 2026-04-28); refactored and validated by [your name]. This is for the next analyst, not for the model.
• No PII in prompts. The schema is fine. The first three rows are usually fine if they're test data. Real customer rows, email addresses, payment details, employee records: never. Use synthetic samples or column descriptions only.
• Prompt logs for audit. Cursor and Claude both have history. Don't clear it. When something breaks six months from now, you'll want to find the original prompt.
• Kill-switch list of datasets. Some tables never get sent to a third-party API. HR records, customer financials, anything under a regional data residency rule. Write the list down. Pin it in the BA Slack channel. New hires read it before they're given warehouse access.

The governance work is unglamorous. It is also the difference between AI being a productivity multiplier and AI being the named cause in next year's data incident report.

Optional: Where This Sits in the ACE Framework

For teams using the ACE Framework to map AI capabilities across the business, AI-assisted BA work sits squarely in Analyze at the Capabilities level (level 2 of 5). You're using AI to interpret existing data and produce decisions, not to ingest new sources (Ingest), forecast (Predict), draft documents (Generate), or take downstream action (Execute).

Useful framing because it tells you what AI is not doing for the BA: it is not building data pipelines, it is not running models against future data, it is not auto-emailing stakeholders. Those live in other ACE rows and have their own failure modes. Keeping the lanes clean keeps the conversations clean.

The 30-Day Plan

If you've read this far and want a way to start without rewriting your whole workflow, here it is. Pick one recurring SQL task and run the experiment.

The goal of the 30 days is not to "adopt AI." It is to learn, in your specific warehouse, where the model lies. Every warehouse lies in different ways. Generic AI advice ignores this; that's why most of it is useless.

After 30 days you will have a calibrated sense of the leverage. You will know which tasks are 3x faster with AI and which ones are slower because verification eats the savings. You will have written down the things your team has been carrying in heads, which is a separate gift to your future self.

Closing

AI in the BA workflow is a fast junior on day one. Useful, eager, and confidently wrong. The leverage is real, and so is the failure mode. The job has not changed: understand the question, understand the warehouse, ship the right number. The tools have changed where the hard parts live.

The BA who knows where the model lies is more valuable, not less. The BA who treats the model as the final author is the one whose name appears in next year's incident report next to "the AI generated this query."

Pick the first one.

Learn More

• Business Analyst Job Description Template
• SQL and Dashboard Design That Earns Trust
• Requirements Gathering That Doesn't Morph
• Common Business Analyst Pitfalls