Data and AI

Everything on that list has one property in common: the task is genuinely hard to write down as fixed logic, but easy for a person to evaluate once done. That combination is what makes AI worth using. Where the logic is simple to state, a rule is better. It is cheaper and faster, and it fails in ways you can predict.

We say this early because the most common way an AI analytics project disappoints is by being applied to a problem a query would have solved.

Generating a short written explanation of what moved and why, attached to a regular report, reaches the people who will never open a BI tool. The model works from the numbers and their history, not from general knowledge, and it says what changed relative to the previous period and to the same period last year. It does not speculate about causes it cannot see in the data.

Anomaly detection covers the opposite case: something changed and nobody was looking. Fixed thresholds handle this badly, because normal ranges vary by weekday, by season and by growth stage. A model that learns the shape of a metric can flag a Tuesday that is unusual for a Tuesday. The hard part is not detection, it is sensitivity. An alert stream that includes ordinary variation gets muted within two weeks, so we tune against history before anything goes live.

A forecast is an extrapolation of patterns that held in the past. It handles seasonality, trend and known effects such as promotions. It does not handle a competitor entering the market, a supply disruption, or a change in your own pricing that has no precedent in the history it learned from. Any model that claims otherwise is overfitting.

What makes a forecast usable is the confidence range around it. Knowing that next month's demand is likely to fall between two values, with a stated probability, supports a stock or staffing decision. A single number without a range invites false precision and gets blamed when reality differs. We report backtested accuracy on periods you already know, so you can judge the model on evidence rather than on our description of it.

Language models are good at turning a written question into SQL, which removes that queue for straightforward questions. The failure mode is specific and worth knowing: the system answers with equal confidence when it has misunderstood the question, joined the wrong tables, or silently ignored a filter. It rarely says it is unsure.

We handle that by constraining it. The model queries a curated, documented data model rather than raw production tables, the generated query is shown alongside the answer so it can be checked, and we keep these interfaces away from figures that go into external reporting without review. Within those limits it works well for exploration and for the many questions that currently go unasked.

Report summaries and anomaly alerts are usually the best first step: quick to build, easy to evaluate, and immediately visible to people outside the data team. Forecasting is worth doing once the history supports it. Everything else is easier to judge after you have one AI component running that people actually trust.