Best AI Use Cases for Data Analytics in 2026

Required

Warehouse

Reads schemas, sampled rows, and the approved datasets through read-only access.

Writes saved queries or a result table in a review workspace.

Recommended

Data catalog

Reads metric definitions, model descriptions, owners, lineage, and trusted query examples.

Optional

Notebook

Writes the analysis, validation cells, and explanation for reuse.

Export the relevant schemas, metric definitions, and small representative samples if direct warehouse access is unavailable. The agent can draft SQL, but an analyst must run and validate it in the real environment.

Have a read-only warehouse role, catalog or schema documentation, three known-good queries, query-cost limits, and real questions with answers you can independently check.

Help me build a business-question-to-SQL workflow.

For each approved analysis question, return read-only SQL, a validated result,
and a concise explanation. Never modify warehouse data.

1. Ask for the business decision, metric, population, dimensions, time window,
   comparison, and desired output grain.
2. Find the governed metric definition, relevant models, keys, freshness, and
   one trusted query pattern before writing SQL.
3. State the grain and join plan, then write the smallest read-only query that
   answers the question.
4. Run it with limits first. Check row counts, nulls, duplicates, join
   multiplication, date boundaries, and totals against a known control.
5. If definitions conflict or required fields are missing, stop and name the
   decision needed rather than choosing silently.
6. Return the formatted SQL, result table, assumptions, checks, and source models.
7. Test on a trend, a segmented comparison, and a funnel question.

What good looks like

The query should use the governed definition, preserve the requested grain, avoid accidental join multiplication, reconcile with a known total, and make every filter and assumption visible to another analyst.

Choose your trigger

Run manually from a structured analysis request or a selected backlog item. Require the metric, population, period, and decision; return incomplete requests with a short clarification checklist.

What runs without you

Queries that feed decisions stay analyst-reviewed. After ten requests that reconciled cleanly, let the agent execute automatically - but only in a read-only, cost-limited workspace where the worst case is a wasted query. Audit catalog freshness monthly; this workflow is only as honest as the metric definitions it retrieves.

Pairs well with explore datasets and investigate metric anomalies - all three run on the same governed definitions and read-only access.

Required

Spreadsheets

Reads the source workbook or CSV, schema notes, and allowed cleaning rules.

Writes a separate cleaned copy and exception tab.

Recommended

Warehouse

Reads reference tables and accepted values.

Writes a staging table only after review.

Optional

Data catalog

Reads column meanings, owners, quality expectations, and canonical aliases.

Upload the file directly to the agent and require a new output file. Never let the workflow overwrite the original; preserving a source row ID makes every change traceable.

Have a representative messy file, target schema, canonical formats, alias tables, duplicate rule, required fields, and examples of rows that must be preserved despite missing values.

Help me build a dataset-cleaning workflow.

For each new file, create a cleaned copy and a data-quality report while
leaving the original unchanged.

1. Ask for the target schema, canonical date, currency, category, and null
   rules; the duplicate key; and fields that must never be inferred.
2. Profile every column for type, range, missingness, aliases, duplicates,
   summary rows, and suspicious values before changing anything.
3. Preserve the source file and source row ID. Apply only the approved
   normalization and deduplication rules to a new copy.
4. Keep blank values blank unless a documented rule supports the fill. Put
   uncertain rows in an exceptions output instead of guessing.
5. Recalculate row counts and key totals before and after cleaning.
6. Return the cleaned file, exceptions, rule summary, and counts of every change.
7. Test it on a clean file, a messy export, and a file with ambiguous duplicates.

What good looks like

The original should remain untouched, row and total changes should reconcile, every normalization should follow a named rule, uncertain rows should be visible, and another analyst should be able to reproduce the result.

Choose your trigger

Run when a new file lands in the agreed intake folder or staging location. Restrict it to known file patterns and schemas; quarantine unexpected columns or row-count shifts rather than continuing.

What runs without you

After five runs where the totals reconciled, let it produce the cleaned copy and quality report on its own as files land. Loading anything into the warehouse stays behind review - a bad load is expensive to unwind, a bad file is not. Revisit the cleaning rules whenever the source system changes; new export formats break silently otherwise.

Pairs well with analyze spreadsheets - a reconciled cleaned copy is exactly the input the analysis expects.

Required

Spreadsheets

Reads all relevant tabs, formulas, named ranges, filters, and workbook notes.

Writes new analysis and checks tabs without replacing source data.

Optional

Docs

Writes a short decision summary with links to the supporting ranges.

Files

Reads supporting CSVs, lookup tables, and prior versions of the workbook.

Upload the workbook or CSV and ask for a new spreadsheet output. Use the original file only as input, especially when it contains operational formulas or manually maintained fields.

Have the real decision question, a data dictionary or owner, the expected period and population, and two totals you already know so the workflow has controls.

Help me build a spreadsheet-analysis workflow.

Given a workbook and a business question, create a transparent analysis in a
new tab and preserve all source tabs.

1. Ask for the decision, population, period, dimensions, expected output, and
   known control totals.
2. Inventory tabs, tables, formulas, filters, hidden rows, date coverage, and
   key fields before analyzing.
3. Identify data-quality issues and state which rows or columns will be excluded.
4. Build the analysis with formulas, pivots, or clearly labeled steps that a
   spreadsheet user can inspect; do not replace source values with hard-coded results.
5. Add control totals and reconcile the analysis population to the source.
6. Create a concise summary with supporting ranges, important drivers, and caveats.
7. Test it on a clean workbook, a multi-tab workbook, and one with missing data.

What good looks like

The source must remain intact, formulas and filters must be inspectable, the analysis population must reconcile to control totals, and each conclusion should link back to a specific table or range.

Choose your trigger

Run manually when a workbook and question are attached or from a controlled intake form. Do not auto-run on every spreadsheet in a drive; require an owner and a decision question.

What runs without you

One-off analyses stay reviewed before anyone acts on them. A recurring analysis earns automation after three cycles that reconciled to control totals - then it can refresh on schedule while you spot-check the checks tab. Re-verify the formulas whenever the workbook template changes; a moved column defeats every control quietly.

Pairs well with clean datasets and draft performance reports - clean inputs in, reconciled narrative out.

Required

Notebook

Reads the analysis environment, approved packages, and prior work.

Writes reproducible queries, code, charts, and notes.

Recommended

Warehouse

Reads the bounded dataset through read-only queries.

Optional

Data catalog

Reads field definitions, lineage, known limitations, and data owner.

Use a local notebook with a representative extract if warehouse access is not available. Preserve the query that created the extract so findings can later be checked on the full data.

Have the decision context, dataset scope, field definitions, allowed population, known limitations, and resource limits. Decide which outcomes would change the next action.

Help me build a dataset-exploration workflow.

For a new dataset, create a reproducible first-pass exploration that helps
decide what to analyze next.

1. Ask for the decision context, dataset grain, population, time coverage,
   important fields, known limitations, and resource limits.
2. Profile schema, row counts, uniqueness, missingness, ranges, distributions,
   category cardinality, and obvious integrity problems.
3. Propose a small set of hypotheses tied to the decision, including what result
   would support or weaken each one.
4. Run bounded queries and plots with code visible; avoid searching every
   possible correlation.
5. Check whether outliers, missing data, selection, or time boundaries explain
   apparent patterns.
6. Return the notebook, profile, supported findings, dead ends, and next questions.
7. Test it on a tidy dataset, a sparse dataset, and one with mixed grain.

What good looks like

Every chart should have visible code and labeled units, the population and grain should be explicit, quality problems should be separated from findings, and the next questions should follow from the decision rather than random correlations.

Choose your trigger

Run manually when a dataset and decision context are approved for exploration. Exclude unrestricted access to sensitive or extremely large tables; use a defined view, sample, or query budget.

What runs without you

Findings always pass through an analyst - exploration produces questions, not conclusions. Scheduled profiling of known datasets can run unattended after three stable runs, so new data arrives already characterized. Review the resource and privacy limits quarterly, especially when new sensitive tables enter scope.

Pairs well with write SQL queries and investigate metric anomalies - exploration generates the hypotheses the other two test.

Required

BI

Reads existing semantic models, visual standards, filters, permissions, and dashboard templates.

Writes a draft dashboard in a review workspace.

Warehouse

Reads governed measures and dimensions through approved models.

Recommended

Data catalog

Reads metric definitions, owners, lineage, and freshness expectations.

Optional

Docs

Reads the dashboard brief and stakeholder decisions.

Writes the glossary and usage notes.

Have the agent produce the metric-to-visual specification and validation queries if it cannot write to your BI tool. An analyst can build the approved specification manually.

Have an approved audience and decision brief, metric definitions, semantic model, dashboard style guide, access rules, control totals, and one strong existing dashboard.

Help me build a governed dashboard-creation workflow.

From an approved dashboard brief, create a reviewable BI draft using only our
governed metrics. Never publish it to a broad audience.

1. Ask who uses the dashboard, which decisions it supports, the required
   metrics, dimensions, period, refresh cadence, filters, and access rules.
2. Map every requested measure to the catalog and semantic model. Flag any
   metric without an approved definition or owner.
3. Propose the minimum set of views in reading order and explain what question
   each answers; avoid decorative or duplicate charts.
4. Build the draft with consistent filters, units, date logic, labels, and
   documented metric definitions.
5. Reconcile each key measure with a trusted control query and test filter interactions.
6. Add freshness, owner, and usage notes plus a QA checklist.
7. Test it with an executive, operator, and analyst question.

What good looks like

Every measure should map to a governed definition, filters should behave consistently, totals should reconcile, each view should answer a named question, and a new reader should understand freshness, owner, and scope.

Choose your trigger

Run only from an approved dashboard brief with named metric owners. Exclude exploratory requests and undefined KPIs; route those to dataset exploration or metric-definition work first.

What runs without you

Publication is permanently human - a dashboard becomes a source of truth the moment it is shared. After three builds that reconciled, let the agent assemble drafts in a private workspace so review starts from something concrete. Rerun the control reconciliation after every semantic-model change; that is where silent breakage enters.

Pairs well with draft performance reports - the report reads from the same governed metrics the dashboard displays.

Required

BI

Reads approved metrics, targets, segments, comparisons, and dashboard source links.

Docs

Reads the report template, prior reports, and writing rules.

Writes the new draft and open-question list.

Optional

Chat

Writes specific questions to metric owners and the approved summary.

Spreadsheets

Reads supplemental plans or control tables not available in BI.

Export the governed metric table and provide the report template. Keep calculations in the table so the narrative can be checked against the exact numbers.

Have a stable report template, metric dictionary, targets, materiality thresholds, data-completeness delay, owner map, and three prior periods.

Help me build a recurring performance-report workflow.

After each reporting period closes, prepare a reviewable report from approved
metrics and clearly separate facts from explanations.

1. Ask for the audience, template, metrics, targets, comparison periods,
   segments, materiality threshold, data delay, and owner map.
2. Confirm freshness and metric definitions, then calculate target variance and
   period-over-period change using the same population and units.
3. Reconcile headline totals with the source dashboard or control table.
4. Identify the few material changes and supporting segment or driver evidence.
5. Label owner explanations, analyst hypotheses, and unanswered questions distinctly.
6. Draft the executive summary, metric table, drivers, risks, decisions, and
   owner questions with source links.
7. Test on a stable, unusually strong, and unusually weak period.

What good looks like

Numbers should reconcile exactly, the narrative should focus on material movement, explanations should have owners or be labeled as hypotheses, and every claim should link to the supporting metric or source.

Choose your trigger

Run after the reporting data-completeness window, not at midnight on period close. Exclude metrics still marked provisional and flag missing targets or owner inputs.

What runs without you

After four reports whose numbers reconciled exactly, let the draft and the owner questions go out automatically when the period closes - the review conversation starts earlier that way. Final commentary and anything leaving the team stay reviewed. Audit the template and metric list quarterly so the report keeps answering questions people still ask.

Pairs well with build dashboards and investigate metric anomalies - the dashboard supplies the numbers and the anomaly workflow explains the surprises.

Required

BI

Reads the alert, metric definition, baseline, threshold, filters, and related dashboard views.

Warehouse

Reads the underlying governed models, raw-enough detail, and pipeline freshness through read-only queries.

Recommended

Data catalog

Reads lineage, owners, known incidents, and recent model changes.

Optional

Observability

Reads pipeline failures, deploys, and service events around the anomaly window.

Provide the metric export, definition, baseline, and a few relevant segment cuts if direct data access is unavailable. The result should be an investigation plan, not a confident cause without supporting rows.

Have the metric definition, normal range, alert threshold, data delay, segment dimensions, model lineage, recent deploys, and examples of one real anomaly and one data-quality false alarm.

Help me build a metric-anomaly investigation workflow.

When a governed metric crosses its threshold, determine whether the movement is
real and return ranked explanations with evidence.

1. Read the metric definition, population, grain, baseline, threshold, expected
   data delay, and recent model or product changes.
2. Confirm freshness, completeness, duplicate rates, schema changes, and whether
   the dashboard reproduces in a direct control query.
3. If the movement is real, decompose it by time, segment, geography, channel,
   product, and other approved dimensions until the main contribution is clear.
4. Compare with related leading and lagging metrics and relevant releases or events.
5. Rank possible explanations with supporting and contradicting evidence; do not
   label correlation as cause.
6. Return a triage summary, queries, driver table, and specific next checks or owners.
7. Test on a data failure, a real business change, and a threshold false alarm.

What good looks like

The workflow should first prove the anomaly exists, identify the segments that account for the movement, show the exact queries and controls, and keep the confirmed evidence distinct from plausible explanations.

Choose your trigger

Run when an approved metric crosses a materiality threshold for the required duration, or manually from an analyst flag. Exclude known maintenance windows, incomplete periods, and metrics without a documented baseline.

What runs without you

The triage draft can fire automatically once five replayed cases came back accurate - speed is the value when a metric moves. Deciding the cause, and what to do about it, stays with analysts. Review the thresholds monthly; alert fatigue kills this workflow faster than any wrong answer.

Pairs well with write SQL queries and draft performance reports - both depend on knowing whether a movement is real before anyone writes it down.