AI can speed up ordinary data work: cleaning a messy spreadsheet, summarizing a survey, drafting a chart, or writing a formula. It is fast at the setup and works from aggregate, de-identified numbers you paste. It is not a calculator you can trust, so the numbers and what they mean stay with you.
The workflow
Set up fast, then verify
PrepareClean and reshape the data
AnalyzeSummarize, group, draft a formula
VisualizeDraft a chart and its caption
VerifyRecompute the key numbers yourself
Every number a decision rests on gets recomputed against the source.
AI is quickest at preparing and drafting. The last step, checking the math and the meaning, is yours.
Good for the setup: cleaning and reshaping a spreadsheet, suggesting a chart type, writing a spreadsheet or code formula, and drafting the plain-language story of a result.
Ask it to write and run code for any calculation, and still recompute the numbers a decision rests on against the source.
It is weakest at choosing the method and at cause. It will confidently run a statistic that does not fit your data, and it is least reliable when asked whether one thing caused another.
A chart can mislead. An AI-drafted chart can use a cut-off axis, a wrong encoding, or colors that fail for colorblind readers, and models are poor at noticing when a chart misleads.
Only aggregate, de-identified data. Never paste a client roster or anything that identifies a person into a general tool.
You own the interpretation. What a number means for your program and your clients is a judgment a person makes.
How it works, and where it breaks
1Doing the math in its head is unreliable; running code is better
When you paste numbers into a plain chat and ask for an average or a total, the model does not compute. It predicts what a written-out answer should look like, which is where silent arithmetic and rounding errors come from. Having the model instead write code that a real interpreter runs on the data raised accuracy by about twelve points over written-out reasoning across a set of math and finance tests, because the computer does the arithmetic (Chen and colleagues, 2023). Code fixes the arithmetic; it does not fix the choice of method. On a large statistics benchmark the best model reached only about sixty-five percent, and its mistakes were mostly applying a method that did not fit the data, an error a busy person is unlikely to catch (Zhu and colleagues, 2024).
2Even when the code runs, about one number in five can still be wrong
On a benchmark that let models use a code interpreter on real data-analysis tasks, the code executed almost every time, yet only about seventy-eight percent of the computed answers were correct and only about sixty-four percent of the charts were right (Zhang and colleagues, 2024). The code running is not the same as the answer being right, because the model can write code that reads the wrong column, filters the wrong rows, or picks the wrong method. The trouble grows with the size of the table: accuracy on simple calculations over a pasted table fell sharply as the table got longer, and duplicate rows alone cut a model's totals badly (Wolff and Hulsebos, 2025). Cause is the weakest area of all; on one data-reasoning benchmark models handled statistical questions far better than causal ones, which sat below half (Liu and colleagues, 2024).
3A clean-looking chart can still be wrong, and color is the blind spot
A chart can render without error and still encode the data incorrectly. On a visualization benchmark the best model produced a valid, correct chart about three quarters of the time, and roughly one chart in five ran but broke the data in some way, such as a wrong axis, a wrong mapping, or a missing legend (Chen and colleagues, 2024). Asking the model to catch a misleading chart helps only moderately and depends heavily on the prompt, and models are weakest at spotting color problems (Lo and Qu, 2024). The fix you have to ask for by name is a colorblind-safe palette; the widely used Okabe and Ito set stays distinguishable for the roughly one in twelve men with a color-vision deficiency (Wong, 2011).
Get a number you can trust
How to run a data task you can check
Strip names, dates of birth, addresses, and case numbers before you upload anything.
Ask it to write and run code for every calculation, and to show you the code.
For a chart, ask for an axis that starts at zero, direct labels, and the Okabe-Ito colorblind-safe palette.
Recompute the key numbers yourself, or check them in a spreadsheet, before they go in a report.
Keep the interpretation, and any claim that one thing caused another, with a person.
A messy intake spreadsheetA cleaned table you can check
Clean and standardize a de-identified spreadsheet
Write and run Python to standardize the columns in this de-identified spreadsheet: make the category labels consistent, put the dates in one format, and flag blank or duplicate rows. Show me the code, the row count before and after, and the value counts for each column so I can confirm nothing was dropped. [upload a de-identified export, no names or case numbers]
Guardrail. Confirm the row count is unchanged and the categories are right, since cleaning can silently drop or merge rows. See Module 4.
A de-identified survey exportA summary with the counts shown
Summarize a client-satisfaction survey
Using code, compute the count and percentage for each response option on every item in this de-identified survey, and the mean for the rating items. Show the full distribution, not only the average, and print the code. Do not run any significance test unless I ask. [upload the de-identified responses, drop any open-text column first]
Guardrail. Re-add one item's counts by hand to check the total, and be wary of any test the tool proposes, since models often pick a method that does not fit. See Module 2.
A small aggregate tableA board-ready chart and caption
Draft a chart and a plain caption for a report
Make a bar chart from this aggregate table using code. Start the y-axis at zero, label the bars directly, and use the Okabe-Ito colorblind-safe palette. Then write a two-sentence caption that states only what the chart shows, with no claim about cause. [paste the aggregate counts, no client-level rows]
Guardrail. Check that the axis is not cut off and the labels match the numbers, and read the caption so it does not overstate a trend. See Module 2.
Worked example
A total that does not add up
You paste a column of monthly intake counts and ask, in a plain chat, for the yearly total and the percent change.
The reply gives a clean total and a percentage, formatted and confident.
You add the column yourself and find the total is off by a month the model dropped, and the percentage used the wrong base.
You ask it again to write and run the code, check the result against your own sum, and only then put the number in the report. The format looked finished; the arithmetic was not.
Guardrail. Use only aggregate, de-identified data, and treat every number as a draft. Recompute the ones that matter against the source. See Module 2 and Module 4. To turn a result into a chart and caption for a report, see Storytelling.
Sources
Chen, W., Ma, X., Wang, X., & Cohen, W. W. (2023). Program of thoughts prompting: Disentangling computation from reasoning for numerical reasoning tasks. Transactions on Machine Learning Research. https://arxiv.org/abs/2211.12588
Zhu, Y., Du, S., Li, B., Luo, Y., & Tang, N. (2024). Are large language models good statisticians? In Advances in Neural Information Processing Systems 37 (Datasets and Benchmarks Track). https://arxiv.org/abs/2406.07815
Liu, X., Wu, Z., Wu, X., Lu, P., Chang, K.-W., & Feng, Y. (2024). Are LLMs capable of data-based statistical and causal reasoning? Benchmarking advanced quantitative reasoning with data. In Findings of the Association for Computational Linguistics: ACL 2024. https://arxiv.org/abs/2402.17644
Zhang, S., Zhang, C., Hu, Y., Shen, H., Liu, K., Ma, Z., et al. (2024). CIBench: Evaluating your LLMs with a code interpreter plugin. arXiv. https://arxiv.org/abs/2407.10499
Chen, N., Zhang, Y., Xu, J., Ren, K., & Yang, Y. (2024). VisEval: A benchmark for data visualization in the era of large language models. IEEE Transactions on Visualization and Computer Graphics. https://arxiv.org/abs/2407.00981
Lo, L. Y.-H., & Qu, H. (2024). How good (or bad) are LLMs at detecting misleading visualizations? IEEE Transactions on Visualization and Computer Graphics. https://arxiv.org/abs/2407.17291