Article & News

Data quality is where AI projects quietly fail, and the usual response is disproportionate: a general data programme that takes two years and blocks everything behind it. The useful question is narrower. Is this data good enough for this specific question? Answering that lets most businesses ship something useful while the wider cleanup happens in the background, if it happens at all. The problems that genuinely break systems These break things because they change what the system concludes rather than merely making it untidy. The problems you can usually live with Inconsistent formatting, minor typos, free-text fields with varied phrasing

Readiness is not about technical sophistication. Plenty of unglamorous businesses adopt automation successfully, and plenty of technically capable ones stall. What separates them is whether their processes are written down, their data is trustworthy, and somebody owns the outcome. These are the conditions worth checking before committing a budget. Are your processes written down? This is the first and heaviest condition. If the process exists only in people’s heads, any system built against it will encounter exceptions nobody enumerated and will produce confident output that is quietly wrong. The test is whether a competent new starter could perform the task

Most large model bills grow for structural reasons rather than because usage grew. The prompt got longer, retrieval started passing more context, and a capable expensive model is handling work a smaller one could do. None of that is visible from a monthly total. The first step is finding out where the tokens go, which is usually surprising. Measure per request, not per month Log input and output tokens per request type. Almost every system has a small number of request shapes doing most of the spending, and they are frequently not the ones anybody expected. A background summarisation job