I have always had a problem with how loosely we use the term AI. As a customer, it tells me very little about what I am buying, what the system bases its output on, or how much control the supplier actually has over it.
Artificial Intelligence (AI) provides capabilities such as prediction, classification and generation. Intelligent Automation (IA) is already used more broadly to describe the combination of AI with software, rules, workflows and automation. I am proposing a more deliberate use of that distinction. If the intelligence is developed and controlled as part of the system itself, I think AI is an appropriate description. If the system instead relies on intelligence provided by somebody else, particularly a shared foundation model, I think IA is a more useful and transparent description.
This is not about diminishing the value of the application. The distinction is about where the intelligence actually sits. One supplier may own and operate the model producing the intelligence. Another may specialize, constrain and automate around intelligence supplied by OpenAI, Anthropic, Google or somebody else. Those are materially different systems, and I think customers should be able to tell which one they are buying.
That distinction carries an ethical responsibility. Customers should have enough information to evaluate what they are being asked to trust, and end users should understand the capabilities and limitations of a system affecting them. This does not require disclosure of source code or trade secrets. It requires an explanation of what the system does and what supports its conclusions.
What the intelligence is based on
When a supplier has trained a model, my evaluation starts with what it learned from and how relevant that learning is to my organization. The training data, operating conditions and intended purpose matter. A model that performs well elsewhere still needs to demonstrate that its predictions are useful in my environment, with my data and the consequences of getting something wrong. Performance on the supplier's test data is only part of that assessment.
I also need clarity about how that model will be personalized and maintained. That includes whether it is exclusive to my organization or shared across customers, whether my data contributes to further training, and who benefits from the resulting improvements. The supplier should explain when updates happen, how they are validated and what control I have over their adoption. Saying the system “learns from us” leaves quite a lot unexplained.
With IA built on a shared model, the supplier starts with intelligence that has already been trained. My attention then shifts to how it has been adapted to our purpose. Organizational information can be retrieved and supplied to a model without retraining it, but the usefulness of that approach depends on the information selected and how it is used. Connecting our documents is a starting point; handling outdated policies, conflicting sources and different access permissions is part of making the system suitable for us.
Improvement also needs a clearer meaning. Better information and retrieval can improve an application without changing the underlying model, while fine-tuning changes the model through additional training. These are different mechanisms. A supplier should explain what happens to our corrections, what persists and how improvement is measured. I would not assume that correcting an answer today means the system has learned to avoid the same mistake tomorrow.
What bounds it, and who supports it
For either approach, I expect defined limits on what the system can access, conclude and do. A recommendation and an automatically executed decision carry different consequences. There should be enough traceability to investigate an outcome through the relevant inputs, sources, system version and actions taken. An employee or customer affected by the result also needs a practical way to challenge it and obtain review. These expectations should reflect the significance of the decision, rather than assume every application requires the same controls.
The operational difference becomes substantial when the intelligence runs on someone else's infrastructure. Having the rights and infrastructure to operate a model gives an organization a different degree of control from consuming a hosted service. With the latter, the application supplier may not control the underlying model's continued availability. Model retirement can require migration, and the replacement needs testing against the application's actual tasks. A functioning application can therefore require changes because of a decision made further up the supply chain.
That dependency belongs in the support and maintenance agreement. I expect the supplier to explain who investigates failures, coordinates with the intelligence provider, tests replacements and maintains our organizational information. The agreement should also address where our data is processed, what happens during an outage and which costs are included. I should not discover after deployment that maintaining the application's usefulness is a separate service nobody discussed.
This affects what we are paying for. With a supplier-developed model, part of the value may sit in its trained capability and continued development. With IA using shared intelligence, much of the value may sit in specialization, integration, controls and the work required to keep the complete system reliable. I would evaluate the price against those contributions and responsibilities.
Using somebody else's intelligence is a reasonable engineering choice. In many cases it is probably the sensible one. But I do not think we should describe every application built around somebody else's model as though the application supplier created the intelligence itself.
That is why I think IA is a useful distinction.
If you developed and control the intelligence, tell me about the AI.
If you are using shared intelligence supplied by somebody else, tell me how your Intelligent Automation makes that intelligence useful, specific and reliable for me.
Either way, I should know where the intelligence sits, what it is based on, how it becomes useful to my organization, and who is responsible for keeping it that way.
That is part of the product I am buying.