Most failures are not model failures. They are data, process and integration failures — decided long before anyone chooses a platform.
By the time an organisation is comparing models, the outcome of the project has usually already been determined. The decisions that matter — which process is being changed, what data that process runs on, and which systems the result has to land in — were made earlier, often informally.
That is why so many pilots demonstrate well and then stall. The demonstration runs on curated data in a controlled setting. Production runs on the operational reality.
The process was never specified
A model cannot improve a process nobody has described. Before anything is built, the current path of the work needs to be written down: who touches it, what they decide, where it waits and what a good outcome looks like.
Where that specification is missing, AI is applied to a vague intention. The result is impressive output with no measurable effect on the operation.
The data was not ready
Retrieval quality is a data engineering result, not a model capability. If the underlying records are inconsistent, undocumented or unreachable behind an application boundary, no amount of prompt engineering compensates.
A governed data layer — modelled, documented, access-controlled and refreshed on a known cadence — is the prerequisite, not a later phase.
There was nowhere for the result to go
An answer that a person then re-keys into the ERP has moved the work, not removed it. The value appears when the system can act: create the task, post the entry, route the approval, update the record.
That requires integration and permission design up front, which is engineering work rather than model selection.
What to do instead
Start with a process that is expensive, repetitive and well understood. Define the measure before building. Engineer the data and the integration path. Then choose the model — which, at that point, is the easiest decision in the programme.