Learning in AI: What Changes With Experience?

The word “learning” is used casually. Any system that changes attracts it. A useful definition must separate updates to a rulebook, additions to a database, and changes to a model's parameters — and that boundary is not a teaching convention invented for this course. Two lawmaking bodies have written it into their own text.

The EU's AI Act defines the thing it regulates by what it does with an input, not by what it is made of. Article 3(1) of Regulation (EU) 2024/1689, adopted in 2024: “‘AI system’ means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments;”. Recital 12 of the same Regulation then rules out the first column of this comparison by name. The definition should not cover “systems that are based on the rules defined solely by natural persons to automatically execute operations”, because “A key characteristic of AI systems is their capability to infer.” The OECD Council had adopted materially the same wording a year earlier, in 2023 — a system that “infers, from the input it receives, how to generate outputs” — revising an instrument it first adopted in 2019. The two texts do not carry the same weight. The AI Act is binding law, the OECD Recommendation is expressly not, and only the AI Act excludes the rulebook.

The third column has a founding case, and it is old. A checkers program was given the rules of the game, a sense of direction, and a redundant and incomplete list of parameters whose correct signs and relative weights were unknown and unspecified. The rulebook never moved. The parameters did, and they moved from the games themselves. After what the abstract calls a remarkably short period of time — 8 or 10 hours of machine-playing time — Arthur L. Samuel could write, in the abstract of his 1959 paper in the IBM Journal of Research and Development: “Enough work has been done to verify the fact that a computer can be programmed so that it will learn to play a better game of checkers than can be played by the person who wrote the program.” IBM's own account of the program puts the mechanism in six words: “the program got better the more games it played”.

That single sentence of Samuel's contains the whole comparison. The rules were hand-written and stayed hand-written. The improvement came from experience, the experience was self-play games, and the evidence was a game the author lost.

A machine-learning system uses experience—usually data—to adjust a model so that its performance on a specified task improves according to a chosen measure. Each part matters. Without a task, “better” is undefined; without a measure, improvement is only a feeling. The AI Act turns on the same hinge. What separates an AI system from ordinary software there is inference from input, not execution of authored rules.

The model does not need to imitate a person or become generally intelligent. A system that becomes better at ranking support tickets can be learning even if it cannot explain a joke, plan a trip, or recognize an object. Samuel's 1959 program could not do any of those things either. It could beat the man who wrote it at checkers, which was the task it was measured on and the only task it was measured on.

Before discussing algorithms, write down the experience, the task, and the performance measure. It is a simple contract. It prevents impressive training activity from being mistaken for useful learning.

The contract is old enough to have a 1959 example. In Samuel's checkers work the experience is the games the program played, the task is checkers, and the measure is whether the resulting play beats the person who wrote the program. All three are stated in the abstract, in one sentence. That is why the claim can still be checked sixty-seven years later. Most modern claims are harder to audit only because one of the three has been left unwritten.

A phishing detector becomes concrete when each part of the learning contract is named, in the way Samuel's abstract named his.

Use this sequence whenever a report, vendor, or teammate says that a system has learned: name the behavior, name the experience, name the update, name the evidence, name the boundary. It reads like bureaucracy until you count what happens when the last two steps are skipped across an entire literature.

One review covered every paper and preprint published between 1 January and 3 October 2020 that proposed a machine-learning model to diagnose or prognosticate COVID-19 from chest radiographs or CT. 2,212 studies were identified. 415 survived initial screening. 62 were reviewed in full. Roberts and colleagues state the outcome in their abstract in Nature Machine Intelligence, without hedging: “Our review finds that none of the models identified are of potential clinical use due to methodological flaws and/or underlying biases.” A separate team running a separate search landed in the same place. Wynants and colleagues screened 4,909 titles, included 51 studies describing 66 prediction models, rated every one of them at high or unclear risk of bias, and concluded in BMJ in 2020: “Hence, we do not recommend any of these reported prediction models to be used in current practice.” Two reviews, two samples, 66 models and 62 papers, and no survivors.

The fifth step — name the boundary — has a case of its own, and it is the case where the sentence “our AI learned from customers” was literally true. Microsoft released the chat bot Tay on Twitter on 23 March 2016. It learned from its interactions with users and produced more than 93,000 tweets. Gina Neff and Peter Nagy record the ending in the International Journal of Communication: “Sixteen hours after Tay started interacting with and learning from Twitter users, Microsoft took Tay offline.” The same peer-reviewed account notes the reactivation seven days later. On 25 March 2016 Microsoft published its own post-mortem, written by corporate vice president Peter Lee. He attributed the failure to “a coordinated attack by a subset of people” who, he wrote, “exploited a vulnerability in Tay”. The behavior was named, the experience was named, the update happened. Nobody had written down the evidence that would show it going wrong, or the conditions under which the experience stops being trustworthy, and sixteen hours was how long that took to matter.

This path explains the logic of learning projects: framing, data, feedback, training, evaluation, generalization, debugging, and improvement. It stays conceptual enough for beginners. It is still precise enough to prevent the mistakes the cases above are made of.

Later paths will examine supervised, unsupervised, and reinforcement learning separately. They will also cover optimization mathematics, detailed metrics, and production data systems. Here, the goal is to understand how those pieces fit into an honest learning process — one in which the experience, the task, the measure and the boundary are all written down before anyone says the word learned.