Artificial Intelligence vs Machine Learning

Artificial intelligence names a group of methods; machine learning names one of them, the one where behaviour is derived from past examples rather than written down. Everything that learns is covered by both terms. The wider term adds written procedures that decide things and learn nothing. A policy scoped to one term and a policy scoped to the other cover different systems, and the gap is where accountability goes missing.

Two terms only need separating when something turns on the separation. Here two things do. One is what a policy covers. The other is what a register has to list. Both are settled by a wording choice somebody makes early, usually in a first draft, usually by reaching for whichever of the two words sounded more current that year. Nobody in that room thinks they are deciding which systems will need an approval, a review and a written record, and that is exactly what they are deciding.

What is the actual difference between the two terms?

Start in a pharmacy. The shape is the same there and already familiar. Every antibiotic is a medicine. Not every medicine is an antibiotic. Insulin, an inhaler, a painkiller, a saline drip: all of them medicine, none of them antibiotics. Now a hospital writes a stock control policy that applies to antibiotics. The policy can be a perfectly good one. In conversation everybody calls the whole cupboard medicine and only the document says antibiotics, so the insulin sits outside the policy and nobody notices for a year.

Machine learningThe method where a system derives its behaviour from past examples instead of following steps a person wrote out. is the narrower of the two terms, and it names a method. A component covered by it derived its behaviour from past examples rather than from steps a person typed out. Nobody wrote the rule down; the rule was fitted to what had already happened. Fitting behaviour to what already happened is the whole of the boundary. How the fitting is done is covered separately.

Artificial intelligenceA collecting label for a group of methods that produce an output without a person working the answer out each time. is the wider of the two terms, and it names a group of methods rather than one. It collects together the ways a system can produce an output without a person working the answer out each time. Learning from past examples is one of those ways. A written procedure that decides something is another. A component that follows thirty-four lines somebody typed, and reaches a decision on the strength of them, is inside the wider term and outside the narrower one.

So the two terms are not two things standing beside each other, waiting to be chosen between. One sits inside the other. The interesting part of the picture is neither box but the ring between them. Almost every argument about these two words is really an argument about what is in the ring, conducted by people who have not drawn it.

What sits in the ring, and why is it so easy to walk past?

Sumeru Bank Limited, an invented mid-sized Indian bank, runs one retail personal loan intake chain made of nine components. Five of the nine derived their behaviour from past examples. Four are procedures somebody wrote out: the identity match step, an income corroboration rule of thirty-four lines, the fraud rules that run on the servicing book, and the workflow router that decides where every file goes next. The four written procedures are the ring. Each of them decides something. None of them learned anything.

Here is the everyday version, and it is worth recognising before the bank version. A household keeps a rule: if the electricity bill comes in above Rs 3,000/-, read the meter before paying it. Nobody fitted that rule to anything. Somebody wrote the rule after one bad month, and the rule still decides what happens to a bill every time one arrives. Now somebody asks for a list of everything in the house that makes a decision on the household's behalf. The household's rule feels like the person rather than like a system. The standing instruction at the bank gets named and the household's own rule does not.

The ring is not an edge case; it is where the components nobody puts in front of a reviewer live. A written procedure is invisible in precisely this way. A written procedure is so obviously readable that nobody thinks of it as needing explanation, and nobody opens what needs no explanation. In Sumeru Bank Limited's chain the component that touched every single file in the month is one of the four in the ring, and it was the last one anybody looked at.

What does the difference look like as decisions in one month?

Stated as a definition, the difference between the two terms sounds like something for a seminar. Stated as decisions in a month, it becomes something a reviewer has to care about. In month six, its first steady month, Sumeru Bank Limited's intake chain reached a decision on 8,600 applications. A component that learns from data determined the outcome of 7,245 of them, or 84.2 per cent. One of the four written rule sets determined the other 1,355, or 15.8 per cent.

One file in six is decided by a component the narrower term does not reach. All four figures belong to one invented bank and one month, and they add back exactly: 602 plus 452 plus 189 plus 112 is 1,355, and 1,355 plus the 7,245 determined by a learned component is the full 8,600.

What is a scoping test, and why does the wording decide the work?

A scoping testThe wording that decides which systems a policy or a register applies to, and therefore which ones need approvals and records. is the sentence at the top of a policy that says which systems the policy applies to. The scope sentence is usually one line long, and usually written before anybody has counted the systems it will catch. Everything downstream follows from that one line. The line decides which components need an approval before they change; which carry a named person; which appear on a register; and which get reviewed at all. A component that is in scopeCovered by the policy, so its approvals, controls and records apply to it. carries work. A component outside it carries none.

Sumeru Bank Limited ran three scoping tests over the same nine components, and got three different answers. No system changed between the three runs. Nothing was rebuilt, nothing was retired, no new component appeared. Only the sentence at the top of the policy changed, and the number of things the bank had to govern moved by more than a factor of two.

What happens when a policy is scoped to machine learning?

Sumeru Bank Limited's first policy was worded that way, and on the face of it the wording is the careful one. The policy applies to any system whose behaviour is derived from data. Run over the intake chain it catches five components: the liveness check on the selfie image, the document classifier, the field reading step, the scoring model and the drafting assistant. All five get an approval route, a named person and a place on the register.

The four in the ring get none of it. None of the four derived anything from data, so the identity match step, the income corroboration rule, the fraud rules and the workflow routerThe written rule that decides where each file goes next and how long it waits before it escalates. all sit outside the policy. The workflow router touched all 8,600 files in the month, and a policy scoped to machine learning does not see it at all. That is not a drafting slip. The wording did exactly what it said, on the systems it named, and the result is that the single most widely used component in the chain sat outside every control the policy created.

What happens when a policy is scoped to artificial intelligence?

The obvious repair is to widen the wording, and Sumeru Bank Limited tried it. A policy applying to any system using artificial intelligence catches all nine components of the intake chain, the four in the ring included. Widening the wording looks like the problem solved. Then somebody ran the same wording across the rest of the bank, and it caught 38 further routing and calculation rules that nobody had thought of as being in the subject at all: the interest accrual calculation, the statement generation rule, the branch allocation rule, the standing instruction scheduler, the limit refresh rule, the dormancy flag, the fee waiver check and thirty-one more.

The wide wording produced 47 items to govern, nine components plus thirty-eight rules, and nobody had meant to bring in more than nine. This is where a widely held instinct turns out to be wrong. Scoping by the widest available term does not produce caution. The widest term produces a backlog nobody can service, and then it produces a carve-outWording added later to push something back out of a scope that caught it by accident.: a scope wording admitting it caught the wrong set. Neither of those outcomes leaves the bank better governed than it was.

What does a consequence test ask instead?

Sumeru Bank Limited's third attempt stopped asking how a component was built. A consequence testScoping by what an output does to somebody rather than by how the component that produced it was built. asks two questions about the output instead. Does the output reach a customer or a reported figure? And does it get there without a person deciding? If both answers are yes, the component is in scope. Neither question needs anybody to agree on terminology. The argument stops there.

Run over the intake chain, the consequence test brought in seven of the nine components and 19 items in all across the bank. Two components were dropped, and each reason is a judgement rather than a fact. The document classifier was dropped because its output is consumed by the field reading step and never leaves the system, so nothing it produces reaches anybody on its own. The drafting assistant was dropped on the ground that a person signs every output it produces, so nothing reaches a customer without somebody deciding. The signing reason holds only for as long as the signing actually happens every time, and a test resting on a control is only as good as the control.

One invented bank chose these three tests, and the reasoning above is the bank's own. None of the three is the correct approach and none is required by any supervisor. The three tests show something narrower and more useful: the choice of wording, not the choice of technology, is what determines how much a firm has to govern.

Do the three tests actually disagree, or is this a word game?

The three tests disagree, and the counts are what make the disagreement concrete rather than semantic. Set all three over the same nine components and read the columns. Machine learning catches 5 components and nothing else in the bank. Artificial intelligence catches all 9 and drags in 38 further rules, giving 47 items. The consequence test catches 7 of the 9 and 12 of those other 38, giving 19 items. The gap between the first two tests is exactly the four written rule sets, and those four determine 1,355 decisions a month. That is not a debate about words. The difference is 42 items on somebody's workload and 1,355 files a month on somebody's accountability.

What does a carve-out indicate about the scope above it?

When Sumeru Bank Limited's wide wording pulled in 38 rules nobody meant to govern, the repair somebody reached for was a carve-out: a paragraph added underneath the scope, listing the 38 by name, in order to push them back out again. The carve-out runs longer than the scope it qualifies. The carve-out is also evidence about that scope, and it can be read that way.

A long carve-out list is a scope wording admitting that it caught the wrong set. A scope that asked the right question would have excluded them at the outset, so it would not need to name 38 exceptions. Reading a carve-out this way takes ten seconds and is worth doing on sight. In any policy, the exclusions are worth turning to before anything else. If the exclusions are longer than the scope, the scope is not doing the work; the list is. And a list has to be maintained by hand for ever, so the list starts going stale the day it is signed.

Which term belongs in a register entry, in a policy and in a letter to a customer?

The two terms are not interchangeable across documents, and the quickest way to see why is to notice that each document is answering a different question. A register entry names the component, a policy names the consequence that brings something into scope, and a letter to a customer names neither term and describes what happened instead. Using the same word in all three is what makes a scope and a register disagree with each other. The register lists whatever the word suggested to the person filling it in, the scope catches whatever the word suggested to the person drafting it, and those two sets are never the same.

Sumeru Bank Limited found this the expensive way. Its register held 9 entries on the day it was signed off, and a sweep in month 10 found 14 systems in use, so the register was 64.3 per cent complete on its first day. Nobody had been careless. The register was filled in by people reading a word, and the word did not tell them what counts.

Where does using the two words interchangeably actually cost something?

Most of the time it costs nothing at all, and it is worth saying so plainly rather than pretending otherwise. In a budget conversation, a strategy paper, a board update or a job title, the two words are close enough that swapping them changes nothing anybody will act on. There are exactly three places where the swap costs money or accountability, and all three have the same shape: somebody has to decide how much work a thing carries.

The first is sizing a review before agreeing to it. In Sumeru Bank Limited, Neelima Rao read all 34 lines of the income corroboration rule in 25 minutes. The review of the scoring model took eleven working days. Both reviews are in scope under the wide wording and both would appear as one line each on a plan, and a reviewer who agrees to review a list of items without knowing which kind each one is has agreed to an unknown quantity of work.

The second is deciding whether a change needs an approval. The workflow router above is that failure. The third is answering a customer. In one steady month, 1,290 of Sumeru Bank Limited's applicants reached an outcome they would call a refusal: 602 routed by the written income rule, with a printed procedure behind each one, and 688 declined by the scoring model, with no procedure and only an attributed reason. Answering all 1,290 by quoting the written procedure is wrong for 688 of them, or 53.3 per cent. That is what the two words cost when they are treated as one.

Why the difference is definitional rather than a matter of degree