The Enterprise Learning Loop

Why Owning Learning May Matter More Than Owning Models

For several years enterprise AI strategy has been a debate about models. Build or buy. Open or proprietary. Whether advantage required owning the weights. Those questions have not gone away, but they have stopped being decisive, because frontier capability is broadly available and the gap between the best model and the good-enough model closes faster than a procurement cycle.

A different source of advantage is surfacing, and it is quieter. Every interaction between people and AI inside an enterprise produces information. Prompts get refined. Outputs get corrected. Recommendations get accepted or overruled. Experts intervene, and the intervention contains their reasoning. Any one of these is trivial. Collectively they are a body of institutional knowledge that is specific to one enterprise and cannot be bought.

The strategic question changes accordingly. It is not how to get a better model. It is how to build a better learning system, and then how to make sure it belongs to the enterprise rather than to a vendor.

What follows are five observations on what that requires. They lead to one conclusion: models are rented, learning is owned, and most enterprises are investing heavily in the rented part.

1. The Model Layer Is Rented. The Learning Layer Is Owned.

• "We are not trying to automate the process. We are trying to teach the agents to learn the process."
• "The model is the part we rent. Everything around it is the part we should own."
• "If we switched providers tomorrow, we would start over. That is the whole problem."

The distinction between automating a process and teaching a system the process sounds like a nuance. It is the entire argument. Automation encodes the current state of the work into a system that executes it faithfully until someone changes it. Teaching produces something that improves through use, absorbs exceptions, and gets better at the work than the specification it started from.

The economics of the two layers run in opposite directions. Model capability improves through external investment on a curve the enterprise does not control and does not pay for directly. It arrives whether the enterprise participates or not, and it arrives for competitors on the same schedule. Enterprise learning improves only through operational experience, only inside the organization generating it, and only if someone deliberately captures it. That asymmetry is the basis of durable advantage in this phase. Anything that improves because a vendor improved it is not differentiation. It is a subscription.

There is a single question that establishes whether an enterprise has built a learning asset or accumulated vendor dependency. If the model provider changed tomorrow, what would remain. For most the honest answer is uncomfortable. The prompts live inside a vendor platform, the evaluation logic is expressed in a vendor's tooling, the tuning is bound to one model family, and the context layer is configured against a single interface. What was described internally as institutional learning turns out to be configuration, and configuration does not travel.

Questions:

• Are we automating our processes or teaching systems to perform them, and would our engineers and our business owners give the same answer?
• If we changed model providers tomorrow, what learning would remain, and can we point at where it physically lives?
• Which parts of what we call our AI capability are actually vendor configuration?

2. Trained on a Simulation of You

• "A model trained on a simulation of your industry will fail on your simplest tasks."
• "It failed, then told me it should have tried the simpler approach first. That answer was not cheap."

Frontier models are increasingly trained not just on the open internet but on constructed environments designed to teach them how professional work is done. Practitioners from an industry are hired, given realistic tasks, and everything they produce is captured: the work, the reasoning, and critically the judgments about what counts as good. That material is packaged and sold, and it is what makes a general model competent at underwriting, or legal review, or financial analysis.

This is genuinely useful and it has a specific limitation that most enterprises have not priced. Post-training on a constructed environment does not generalize cleanly to a real one. A model taught to be an investment banker in a simulation will still fail on the simple, particular tasks inside an actual bank, because the simulation was a reasonable approximation of the industry and not of that institution. The failure is often not a wrong answer. It is an expensive one, where the system tries several approaches, burns tokens working around what it does not understand, and arrives somewhere acceptable at several times the necessary cost.

The consequence is that the gap between a frontier model's general competence and an enterprise's specific requirement is not closed by waiting for a better model. Better models raise the general ceiling. They do not learn your exceptions, your escalation paths, or your definition of an acceptable answer, because none of that was in the environment they were trained on. Something has to supply it, and the only source is the enterprise itself.

Questions:

• Where are our systems producing acceptable answers expensively, and has anyone measured the difference between a first-try result and a worked-around one?
• What do we assume the next model release will fix, and is any of it actually specific to us?
• Which of our processes would a well-informed outsider get wrong, and what does that tell us about what we would have to teach?

3. What Counts as Good Is the Scarce Input

• "It is not just how we do the work. It is what we consider good. That is what differentiates us."
• "Every correction our experts make is a training signal. We throw almost all of them away."
• "Our people teach the system every day and none of it survives the session."

Teaching a system to do the work requires telling it what finished looks like, and that turns out to be the part no enterprise has written down. How the organization decides whether a piece of work is good is the input the whole exercise depends on, and it exists almost nowhere in retrievable form.

It is also the thing that genuinely separates one enterprise from another. Two firms in the same sector hold similar data and follow similar processes. What differs is what they consider an acceptable answer, which risks they tolerate, which exceptions warrant escalation, and what distinguishes competent work from excellent work. That judgment was never documented, because it lived in people who applied it without articulating it.

It does, however, already exist as artefacts, and this is the practical opening. Every comment on a document. Every reply saying this is not right. Every annotation, every review score, every correction an expert makes to a draft. These are not administrative residue. They are the enterprise stating its standards, continuously, in a form nobody collects. Capturing them is the single highest-leverage data exercise available right now, and it is almost entirely uninstrumented. The capture cannot be a technology project done to the business, because the people who hold the criteria are the subject-matter experts rather than the technology function. The approaches that work involve suggesting captured criteria back to the expert for confirmation rather than harvesting silently, which preserves both accuracy and consent.

Questions:

• When one of our experts rejects a piece of work, where does the reasoning go?
• Could we produce a written statement of what good looks like for our three most valuable processes, and who would have to write it?
• Are our subject-matter experts participating in this, or are we running it as a technology programme?

4. What You Actually Build

• "Start with evals. Own the evals. Never hand them to a model provider."
• "Do not start by tuning the model. Start with the harness."
• "If your tuned model does not beat the frontier model on your work, you do not have IP."

Fine-tuning has moved from exotic to worth evaluating, and the practical path is more approachable than most enterprises assume. It has a sequence, and the sequence matters more than the technology.

It starts with evaluations. Identify the high-value tasks where a better result would matter, in accuracy, cost, or speed, and build a way to measure how well current models and current tooling actually perform them, scored against the success criteria described above. This is the foundational asset and everything else depends on it. Two disciplines belong here from the beginning. Evaluations should run continuously rather than once, because model updates, safety filter changes, and governance layer changes all alter behaviour without warning, and every production incident should become a new test. And evaluations should never be handed to a model provider to improve their model, because the evaluation set encodes the enterprise's standards more concentratedly than almost anything else it owns. Start with read-only access so that testing cannot modify production systems.

Then tune in order of cost. First the skills, meaning the reusable descriptions of how a particular job is done well, which improve automatically when a successful approach is fed back into them. Then the harness, meaning the logic that decides which model to call at each step and how to arrive at a final answer, where using several models rather than one reliably improves results and allows cheaper models to handle what does not need an expensive one. Only then the weights, which has moved from out of reach to worth evaluating.

There is a diagnostic worth running before any of it. If a tuned version of a model does not outperform the frontier model on your work, the enterprise does not have proprietary knowledge in that domain, and should buy rather than build. If it does outperform, the enterprise has found something real, and the lift will persist and grow. That single test answers the build-versus-buy question more honestly than any strategy exercise.

Questions:

• Do we have an evaluation set for our highest-value work, and who owns it?
• Has any of our evaluation data been shared with a model provider, under what terms, and did anyone read them?
• Have we run the test of whether tuning beats the frontier model on our own work, and are we willing to accept the answer?

5. The Individual Loop Is Moving Faster Than the Enterprise One

• "I went from enabling others to use AI to actually using AI. I can now do the work of an entire quant team."
• "The biggest disappointment of my time running IT was how few of my direct reports used AI in any serious way. Polishing emails is not using AI."
• "The gap between our best user and our average user is wider than the gap between the models."

The enterprise learning loop is the slower of the two loops now running. The faster one is individual, and it is producing effects the organization has no framework for.

The transition it describes is becoming common and remains unmanaged. A senior leader whose role was to enable others to use the technology becomes a direct producer of work at a scale that previously required a team. That is not a productivity improvement. It is a change in what one person is, and it happens without a job architecture change or any adjustment to how the contribution is measured. The people making the transition tend to describe the same practices: a substantial personal library of standing instructions that loads automatically and encodes their standards, and a working style that gives the system latitude rather than narrow direction, because over-specifying suppresses exactly the capability being paid for.

The organizational consequence is a widening variance between people in the same role with the same tools. Some are running a tight personal learning loop and accumulating technique and judgment about where the system fails. Others have access and use it as a better search box. Both look identical in adoption metrics. The uncomfortable observation from leaders who have looked closely is that access and encouragement do not close this gap, and that the strongest lever is removing the alternative rather than adding training.

Two problems follow, and the second is the more urgent. Measurement is unsolved outside software engineering, where efficiency can be expressed as work produced per token consumed and published back to the individual, which changes the status signal from volume to efficiency. No equivalent metric exists for other knowledge work, and it is needed. And capture is unsolved, because the individual loop produces the most valuable learning in the enterprise and holds it privately. When that person leaves, it leaves with them.

Questions:

• Who in our organization has moved from enabling AI to producing with it, and do we know their names?
• What is the gap between our most and least effective users of the same tools, and is it wider than the gap between the models we are choosing between?
• When our most capable user resigns, what stays behind?

What This Adds Up To

For decades enterprise software captured transactions. Transactions record what happened. Learning changes what happens next.

The enterprises that build durable advantage in this phase will not be the ones with privileged access to the best models, because that access is temporary and available to competitors on the same terms. They will be the ones that treated learning as an asset with an owner, a location, and an architecture, and built the capture mechanisms while the work was already generating the signal for free.

The most valuable thing an enterprise owns in this domain is not its data. It is its standards: what it considers good, which exceptions matter, and where judgment overrides the rule. That is what a general model cannot learn from a simulation of your industry, and it is what most organizations are discarding at the point of creation.

Models are rented. Learning is owned. The strategic error of this phase will be how much was invested in the rented part.

© 2026 Executive Technology Board. All rights reserved. This document is the proprietary work product of the Executive Technology Board and is intended for the use of board members and authorized recipients. No part of this document may be reproduced, distributed, quoted, or republished, in whole or in part, without the prior written consent of the Executive Technology Board.

Executive Technology Board (c)