A retailer wants to improve its stock planning. Its existing software records sales and applies reorder rules, but demand varies with promotions, weather, and local events. A machine learning model could estimate future demand from relevant historical data. A separate language model could help staff summarise supplier messages. Both applications use AI, although they perform different tasks and require different checks.
Artificial intelligence is a broad field concerned with building systems that perform tasks associated with capabilities such as perception, language, prediction, planning, and problem-solving. It includes several approaches, from systems built around explicit rules and search to models whose behaviour is learned from data. Robotics can use AI, but an AI application does not need a physical machine.
For someone evaluating adoption, the useful starting point is the work the system would perform. Knowing whether the organisation needs a forecast, a classification, a generated draft, or an action-taking assistant makes the technical options and their limitations easier to assess.
How Machine Learning Differs From Written Rules
In conventional software, developers specify much of the logic directly. A stock rule might trigger an order when inventory falls below a fixed quantity. Machine learning provides another approach: a training process uses data to fit a model, which is then applied to new inputs. The forecast may combine sales history, seasonality, price, and other available information to estimate demand.
This does not make rules obsolete. A retailer might use a learned forecast alongside explicit restrictions on order size, approved suppliers, and spending authority. Each part serves a different purpose. The model estimates what may happen; the surrounding application determines what the organisation is permitted to do about it.
The distinction also helps explain why AI performance needs evaluation. A rule can be checked against its written requirement, though that requirement may itself be mistaken. A learned forecast needs evidence about how well it predicts outcomes on cases outside its training examples. Neither approach removes the need to examine whether the resulting process serves the business.
Learning Takes Several Forms
Machine learning does not always require people to label every example. Google’s introduction to machine learning describes several forms of learning. In supervised learning, examples include a target: a sales quantity, an observed equipment failure, or an agreed document category. Training aims to learn a relationship between the inputs and that target.
Unsupervised learning looks for structure without those target labels, such as groups of customers with similar purchasing patterns. Self-supervised learning derives training signals from the data itself; predicting parts of a text from other parts is an important example. Reinforcement learning uses feedback expressed through rewards as a system interacts with an environment. These approaches can be combined within a development process.
The method affects the work adoption requires. A document classifier may need consistently categorised examples. A business using a pretrained language model may need no initial model training, but it still needs suitable instructions, permitted data access, and an evaluation set. Buying access to a model moves some development work to a supplier; it leaves the organisation responsible for checking its own application.
What Training and Everyday Use Mean
Training changes a model’s learned parameters. Inference is the use of a trained model to produce an output, such as tomorrow’s demand estimate or a draft email. These are separate activities, with different infrastructure, cost, and change-control implications.
An employee correcting a forecast does not necessarily cause the model to learn from that correction. The application may save it for a later training cycle, use it only to amend the current order, or discard it after the session. Similarly, a chatbot can use information supplied in a conversation without that information becoming a permanent change to its model parameters.
This matters when suppliers describe a product as continuously learning. Ask what actually changes, when changes occur, who approves them, and whether customer data is retained or used for training. Those answers should come from the product’s technical and contractual arrangements. The conversational appearance of the interface provides no reliable answer.
Prediction and Generation Need Different Checks
A demand forecast estimates a quantity. A classifier assigns a category or score. Generative AI produces content, including text, images, audio, or code. A business may combine these capabilities, but their outputs need different forms of verification.
A language model processes sequences of tokens, which can represent words, parts of words, or other units. Google’s explanation of large language models describes how language modelling estimates probabilities over token sequences. Systems built on these models can perform useful tasks such as translation, summarisation, and answering questions, although fluent output is not a guarantee of factual accuracy.
For the retailer, a generated supplier summary should preserve delivery dates, qualifications, and unresolved issues. A readable paragraph that omits a delayed shipment can be operationally worse than a less polished summary that retains it. Evaluation therefore needs to ask whether the content is supported by the source and suitable for the intended decision.
Generated output can also contain unsupported details or fabricated references. A review process should give staff access to the underlying messages and identify which information must be checked before they act. Where a task requires a verified fact, the application should make the source available rather than rely on the model’s confidence of expression.
Generalisation Is Useful, but It Has Limits
A model is intended to handle inputs it has not seen before. It would have little forecasting value if it could only repeat its training records. Generalisation is the ability to perform usefully on new examples; Google’s generalisation guidance explains why performance on training data alone is insufficient evidence of that ability.
An unseen case is not automatically beyond a model’s capabilities. Equally, a familiar-looking case can become difficult when its meaning changes. The retailer’s usual seasonal pattern may be disrupted by a new competitor or a prolonged supply shortage. Historical relationships can then become less useful for the decision at hand.
Testing should include realistic variation and clearly state what remains untested. A strong average result across established stores may tell the retailer little about a newly opened location. The answer is to investigate that uncertainty, perhaps keeping more manual review during the opening period, rather than assume either universal capability or universal failure.
Confidence, Understanding, and Authority
Words such as thinking and understanding can be convenient descriptions of observed behaviour, but they do not specify a dependable capability. Whether a system can solve a particular problem is an empirical question. Whether it has human-like understanding is a separate question that a business demonstration cannot settle.
A confidence score also needs interpretation. A classifier’s score may help rank cases, but it should not automatically be read as the probability that any individual output is correct. Its usefulness depends on how it was produced and evaluated. A language model saying it is certain is a different signal again and should not be treated as calibrated evidence.
Authority comes from the application design. An AI agent can be configured to choose tools and carry out several steps towards an assigned objective. That gives it operational capabilities beyond returning a single answer, without making it an accountable employee. Access restrictions, approval requirements, and stop conditions need to follow the actions it can perform.
The retailer could allow an assistant to prepare an order proposal while requiring a purchasing manager to approve it. Permitting it to submit orders automatically would be a separate decision about delegated authority. The controls should reflect the financial exposure, reversibility, and reliability of that complete workflow.
Evaluating a First Application
A useful assessment starts with the current process and a specific outcome. For stock planning, the retailer could examine stockouts, excess stock, planner effort, and the cost of incorrect orders. It should compare the proposed model with the existing method, including a simpler forecasting approach where appropriate.
The evaluation needs to include the people using the result. Does the forecast arrive before purchasing closes? Can planners see relevant assumptions and amend an order? Can the business continue if the model service is unavailable? These questions connect technical performance to a process the organisation can operate.
Scope should remain visible after launch. A forecast evaluated for weekly purchasing should not automatically be used to set individual staff targets or decide which stores deserve investment. Those decisions involve different consequences and may need additional information. Reusing a convenient score can create a new application without the evaluation that would normally accompany one.
The retailer should also name who investigates recurring errors and who can change the process. A planner correcting an order needs a route to report a broader forecasting problem. That feedback is useful only if someone examines it, distinguishes local exceptions from recurring defects, and decides whether a change needs testing.
The guide to AI system components explains the architecture behind these checks. A bounded pilot can then test the most important assumptions without committing the entire operation to the new approach.
AI can help organisations work with information, recognise patterns, and produce useful outputs at scale. Its value becomes clearer when the task, evidence, and authority are explicit. An organisation adopting AI needs to know what the system can demonstrate in its setting, what remains uncertain, and how people will make and correct the decisions that follow.
