Edison opened his first power stations in 1882, in New York and London. The
technology was there from that year, and for many people it changed nothing for
another four decades, the time it took to reach an ordinary factory and an ordinary
home.
Computers followed the same course, from corporate basements in the 1960s to the
counter of every bakery by the 2000s. But the computer on the bakery counter and
the machines in a large company's data centre were never the same thing, and no-one mistook one for the other. Both were computers. They did different work, and the
stakes were different.
AI is partway along that curve now. Its use has spread very fast, which is why the
better word for it is diffusion, not democratization. Democratization would mean
control was shared out. Diffusion only means "use spread". What is now on every
desk and what still has to be built for a single company are not the same machine,
even though we have started calling both of them AI.
A great deal of money is now going into adopting the AI that everyone can adopt. A
company buys access to the same models its competitors buy, wires them into the
same tools, and treats the result as an advantage. For a while it feels like one.
It is not. Whatever you can rent through an API, your competitors can rent the same
day, at the same price - that is commodity AI. Nobody ever won a market by having a
website. Some lost one by not having it.
Adopting it well still helps, and a company that puts these tools to work will be ahead
of one that fumbles them. At least for a while.
What takes real work today can be part of the commodity tomorrow, and I have
watched it happen to my own work. Between 2010 and 2025 I worked on more than
fifty AI projects in industry. Some of them were text problems: classification, entity
extraction, a model built for one specific kind of document, with labelled data and
months of work behind it.
Most of those would not be built that way today. Several that we did build that way
have since been replaced by a general language model with a containment layer
around it, and the replacement performs better. It performs better because
understanding language is a general problem, and the general model had read far
more of it than we could ever have labelled. My model was trying to learn, from a few
thousand examples, something a general model trained on much more data already
knew. It was always going to lose that.
That is not an enjoyable sentence to write. You spend months building something
precise, and a general tool you never trained does it better. And the day entity
extraction became good enough for us to drop our own model, it was good enough
for everyone else too, our client's and competitors included.
What does move is the work. It does not disappear when you switch to a general
model, it relocates: from building and validating a model to writing evaluations,
maintaining prompts, and containing failure modes a narrow model could never have
produced. A hundred guardrails and the evaluation suite become the most valuable
thing you own: they protect you when the rented model underneath you changes.
So the question worth asking is which problems will keep moving to general models
like that, and which probably never will.
Ask where the answer physically comes from. There are two possibilities.
Either it is something true of the world, written down somewhere, and the model read it in training. Machines fail more often as they age. People buy more cake in December than in January. Germans the verb at the end put.
Or it is something true only inside one company, recorded nowhere except in its own data. That your biggest Thursday is the factory down the road placing its canteen order, and that when they switched shift patterns your whole week moved with them.
A general model answers the first kind and cannot answer the second, and that has
nothing to do with it being weak or badly prompted. The information is not in it. It
never saw your data, and reading more of the internet will not help, because your
data is not on the internet (hopefully).
This is why the boundary has moved the way it has, and it is worth knowing the
direction. It moves toward the general, and it keeps moving. Anything whose answer
sits in the shared, public record will eventually be done well by a model that has read
that record. Anything whose answer sits only in your data stays where it is, however
large the models become. Scale means reading more of what is public. Your data
was never public (again: hopefully).
Two caveats, because the line is not always where it first appears.
The first: some problems look specific but are mostly general. Answering a question from your own internal handbook feels like something only your system could do, but the hard part is reading, and reading is general. The handbook is private, yet you can hand it to a general model and it reads it on the spot.
The second: none of this is about how a model is built. A general model fine-tuned on your own data counts as your own model here. What decides the side of the line is whether the answer has to be learned from your data, or can be read from something you hand over.
The problems that stay on the far side of that line share a shape: Which customers will leave this quarter? Which loans will default? Which machine will fail, and when? Which patient will be readmitted within thirty days? Which student will drop out? Which roll of fabric will not pass inspection? Which dogs will develop which diseases? Which people leaving a treatment programme are most at risk of relapse? Which bid will win?
Each one is a question about a future event, for a named entity, inside a single organisation.
Ask a general model why customers churn and it will answer well. Onboarding, price, support experience, switching costs. It is a clean literature review, it is free, and your competitor can have the identical one this afternoon. Ask it why your customers churn and it hands you the same literature review in a more confident voice.
A general model gives you the drivers. Only your own model gives you the list.
The two kinds (general and your own) show up in the adoption numbers, once you separate them. A study published this year by Bick, Blandin, Deming, Fuchs-Schündeln and Jessen puts AI use among European workers at 32%, and use of AI in production among European firms at 4%; in the United States the two figures are 43% and 7%.
AI in production is a strict measure. It is AI built into how a company actually makes or delivers what it sells, not someone using a chatbot at their desk - which is why it sits so far below the share of people using AI at all. A third of people have picked up the AI that everyone has. But only four companies in a hundred run AI inside the business itself. The first kind spread almost overnight, because there was nothing to build. The second is slow, because it takes your data, your problem, and someone to build it.
Everything so far has been about whether a general model can answer the question. There is a second question: whether you can use the answer even when the model can produce it.
Some data cannot leave the building. And some decisions have to behave the same way in three years, and have to be inspectable when someone asks why. A rented model changes underneath you on a schedule you do not set. Anyone in a regulated industry knows the shape of this already: explainability and auditability were never things you could bolt on at the end, and stability belongs in the same family.
See our webinar on Explainable AI in partnership with Fetch Pet Insurance here.
Then there is the question of what you own, which is not a yes or a no. Think of it as five levels, and for each one ask what changes on the Tuesday the vendor ships an update.
At level one you use a chat window. You own nothing, down to the reproducibility of yesterday's answer.
At level two you have a prompt. You own a text file, which has real value and which anyone who sees a few of your outputs can approximate. When the vendor updates, your prompt stops working the way it did, and you may not find out for a while.
At level three you have built around the model: retrieval, tool calls, containment, evaluations. This is serious engineering, and it is where most companies belong for most things. The part that makes the decision is still rented, and the evaluations are what tell you the day it changes.
At level four you take a capable general model and adapt it on your own data, by fine-tuning or training on your own labels. The base came from someone else, but the version that makes your decisions is yours to host, and it does not change unless you change it.
At level five the model was built for your problem, from your data, in your environment. While level four is a strong model you adapted, level five is one that would not exist without you. The weights, the pipeline, and how it behaves over time are all yours.
The right level is set by the question, not by ambition. Most work belongs on the first three, and that is ok.
This is where the electricity from the opening comes back: When power first reached the factories, the ones that moved first often saw nothing for it. They set a large electric motor where the steam engine had stood and let it turn the same overhead shafts and belts, and the building ran exactly as before.
The gain came only to the factories that put a small motor on each machine and then rebuilt around it: no shafting overhead, so lighter buildings, single floors, a layout that followed the work. That rebuild took decades to spread, which is much of why the promised productivity from electricity arrived forty years late.
The first three levels are that first motor: the commodity, wired in, the business running as it did before. You should do that much - it is the floor, and skipping it puts you behind. But the advantage was never in the motor. It came from the factories willing to rebuild around it, and the question worth sitting with is not whether to adopt the general AI (because you have to and you will) but where your own data would justify rebuilding around it.
One recent shift makes that rebuilding cheaper: open-weight models. These are models whose trained weights are published: you can download them, run them on your own hardware, and adapt them on your own data. They are not new, they have been around for years. What changed is the quality.
Today's open models are good enough to build on, and on some tasks they match the strongest closed systems (Moonshot's Kimi is one example). Open weights are not the same as open source, though. Open weights give you the published, runnable model, not the recipe behind it. For owning the model that makes your decisions, that is usually enough, and it puts the top two levels within reach of companies that could not have considered them a few years ago.
Owning your own model no longer means training one from scratch or keeping a research group on staff.
A July 2026 letter signed by NVIDIA, Meta, Microsoft, IBM, OpenAI, Google and, since launch, hundreds more argued the case for open weights - and put the practical version well: open weights let a company “match the right model to the right job at the right cost, reserving frontier-scale capability for genuine frontier problems and running efficient, specialized models everywhere else.”
Separately, open weights have become part of how Europe thinks about AI sovereignty. A contribution to the European Commission's Apply AI forum notes that access to weights “does not necessarily provide transparency over training data, code, evaluation methods or governance”, and adds that open weights lower dependency at the application level but “can also create a broader ecosystem dependency when the models, tooling and technical roadmaps on which European organisations rely are principally developed elsewhere.”
General or your own model? The questions I would put to any problem before deciding what to build:
Is the answer written down somewhere in the world, or only in your data?
If the answer is wrong, who notices, and how long does it take them?
Does someone have to be able to interrogate the decision before acting on it?
Can the data leave the building?
Does this have to behave the same way in three years?
And then the one that follows from the rest: which level does that put you on, and are you standing higher than the question needs?
Answer them honestly and most problems turn out to be general, and that is ok - that is the floor. The few that do not are the ones worth building for.
We have sat on both sides of these questions.
For Fetch, a US pet insurer, the answer - which individual dogs would develop which conditions - existed in seventeen years of claims from 785,000 dogs and nowhere else. Level five.
For a healthcare client, extracting diagnoses and medications from clinical documents once took a model of our own. Today that is level three work, for clinical notes and invoices alike.
Same questions, different answers, and one of them changed over time. That is why you ask them more than once.
The bakery needed a computer, then a website, and now it needs the AI that everyone has. It should take all three. But none of them can tell it how much to bake for a Thursday so the shelves are neither empty by nine nor full at closing, or which of its regulars have stopped coming in. Those answers sit in its own records, in that one shop, and no general model has seen them.
The same holds for any business. The first three levels (the AI everyone has) are the floor. An enterprise has to be standing on them, and for many tasks that is the right place to stop.
Pulling ahead is a different question and a different machine. It lives in the problems where your own data earns the top two levels - a model built for your problem, on data no one else holds.
The work is knowing which of your questions those are, and most are not. Everything else you can rent. What only your data knows, you have to build.
References