AI Solution Design & Delivery
One of the easiest things to demonstrate in AI is that something can work. A dataset can be assembled, a model trained, and an improvement demonstrated against historical data. A large language model can extract information from a document, a graph can expose relationships that were difficult to see previously, and a proof of concept can establish technical possibility in a matter of weeks. The harder question is whether that capability can improve a real business outcome repeatedly, safely, and economically inside the operating environment of the enterprise.
This is why I do not consider an AI opportunity fully qualified until there is a credible path to production. Production planning does not begin with infrastructure; it begins with the decision or outcome the organisation is trying to improve. What happens today, what is unacceptable about the current result, which decision contributes to that outcome, what additional intelligence might improve it, and what action would change as a result all determine what the AI solution actually needs to do.
If a model identifies fraud after a transaction has completed, it may support investigation. If the objective is to prevent the transaction, the model, data, and intervention must operate within a completely different time window. If an underwriting model produces a recommendation but policy prevents the organisation from acting on it, deployment alone will create little value. The production architecture is therefore a consequence of the business intervention rather than a decision that should be made independently of it.
One of the most important questions in applied AI is whether the information used to train the model will actually be available when the decision is made. Historical datasets often contain information that became known after the event, features may have been calculated through batch processes that cannot run within the production decision window, and data scientists may join information across systems that the operational application cannot access with sufficient reliability or speed. A model can therefore perform extremely well in development while depending on information that does not exist at the moment it is needed.
Feature engineering needs to account for this from the beginning. The relevant question is not only whether a feature is predictive, but whether it can be calculated using information available at that point in time, reproduced consistently in production, and delivered within the constraints of the business process. This is where model development and architecture stop being separate conversations.
Labels can create a similar problem. Fraud labels may reflect only detected fraud, a mule account may remain unknown until an investigation occurs months later, and a customer classified as churned may have left for reasons unrelated to the intervention being considered. Human decisions embedded in historical data may also reproduce policies or assumptions the organisation is trying to improve. Poor labels do not make AI impossible, but they change the problem and may require supervised learning to be combined with anomaly detection, graph relationships, behavioural signals, or human review. They may also require a feedback process so that production outcomes improve the quality of future training data.
Enterprise AI discussions can become disproportionately focused on selecting the model, when in practice the surrounding system frequently determines whether the model creates value. Features need to be available, inference must complete within the required decision window, the application must know what to do with the result, thresholds need to reflect the economics of false positives and false negatives, exceptions need somewhere to go, and outcomes need to return as feedback. A model producing a score is not a production solution. The complete system connects data, features, intelligence, decision, intervention, and outcome.
There is also no universal answer to where AI should run. Some intelligence can be calculated in batch and delivered hours before it is needed, while some models can operate through a remote service without affecting the business process. Other decisions occur at high frequency, depend on current transactional context, and have only milliseconds in which an intervention remains possible. The business decision should establish the required latency, data access, availability, security, and cost profile, and those requirements should guide architecture and placement rather than the other way around.
Human intervention is part of that architecture. Human-in-the-loop is frequently presented as a safe fallback for AI, but it is only useful if people can absorb the workload. If a model creates ten thousand alerts and investigators can review one thousand, the organisation has created a prioritisation problem rather than solved one. Production design therefore needs to consider which decisions can be automated, which require review, which cases deserve scarce specialist attention, and how quickly that review must occur before the opportunity to intervene disappears.
Finally, production should create evidence about the decisions AI influences. What information was available, what prediction was made, what action followed, who or what authorised it, what eventually happened, and what economic consequence resulted all matter. Without that feedback, an organisation can monitor model performance without knowing whether business performance improved. The objective is not to preserve a model indefinitely; it is to improve the outcome as behaviour, policy, data, and operating conditions change.
The divide between strategy and implementation is therefore often artificial. A credible AI strategy needs enough understanding of data, models, operations, and architecture to know whether the proposed opportunity can survive contact with production. A credible technical solution needs enough understanding of the business to know what outcome it is supposed to improve. Connecting those disciplines early reduces the distance between an interesting AI idea and a useful enterprise capability, which is why the path to production should begin when the opportunity is first identified rather than after the proof of concept.
