subscribe for upcoming articles and periodical summaries of the most read ones

Random Thoughts on Leadership & Technology

If You Can't Run It, It Runs You

corporate-hamster-wheel

On why owning your own AI is quietly becoming the new corporate literacy - and why the companies that treat it as a subscription will one day find the subscription treating them.


The Misconception

"AI is a utility. You plug in, you prompt, you prosper."

This is the comfortable story. The model lives somewhere in the cloud, like electricity or tap water, and your job is simply to consume it. Nobody builds their own power plant, so why would anyone run their own model? Pay the monthly fee, paste your spreadsheet into the chat box, and let the magic happen.

It is a lovely story. It is also roughly the same story people told themselves about renting an office, outsourcing their customer database, and storing all their photos on a service that later "sunset" them with a cheerful email.

The Question

If every productivity gain in your business flows through a model you do not control, cannot inspect, cannot run without an internet connection, and cannot keep when the pricing page quietly gains a new tier - whose productivity is it, exactly?

The Explanation

Electricity is a commodity because a volt is a volt. A model is not a volt. It carries opinions, defaults, blind spots, a personality, and a context window full of your most sensitive paperwork. When your team's workflows become prompts into someone else's box, you have not adopted a tool. You have outsourced the judgment layer of your company to a vendor who can retrain, re-price, or retire next week.

"Running it" does not mean every accounting firm must become a GPU farm. It means having the capability to operate a model on your own terms - your own hardware or your own cloud account, your own data, your own definition of what "good" looks like - so that using someone else's model remains a choice rather than a dependency. The difference between those two states is the difference between a business that uses AI and a business that is used by it.


Picture the most impressive contractor you have ever hired. Reads every document, drafts every memo, knows every client by name, works nights and weekends, never asks for a raise. One small detail - this person is employed by someone else, who can reassign them, change their rate, or swap them for a cheaper cousin without telling you. Would you build your entire operating model around that contractor? You would not. And yet "we use the AI for that now" is currently the most popular sentence in corporate strategy decks, delivered with the serenity of a man who has never read a terms-of-service update.

The strange part is how little it would take to hire the contractor outright. The technical reality is far less exotic than the mythology. Open-weight models - the Llama, Mistral, Qwen, Gemma and DeepSeek families, among others - can be downloaded as files and run on hardware you own. Quantization compresses the weights so that a model with tens of billions of parameters fits on a single workstation GPU with modest loss in quality. Retrieval-augmented generation lets the model read your internal documents through a local vector store without those documents ever leaving the building. Low-rank fine-tuning adapts a general model to your tone and terminology for the price of a few GPU hours. None of this requires a research lab. It requires one competent engineer, a few to a few tens of thousands (depending on wherlther you are a 10 or 200 people company) euros/dollars of hardware, and the willingness to stop treating the chat box as a shrine.

Most companies have not made that trade, and the cost of not making it is already compounding in a place nobody is looking. Over the past few years, procedures have migrated into prompts. The onboarding checklist is now "ask the assistant". The weekly report is a saved chat project. The sales qualification rubric exists only as a system prompt someone wrote in a hurry and nobody can find (unless you have a company AI skills registry). These are not tools your company uses. They are organs your company has grown inside a vendor's database. Every model update is an uninvited reorganisation. "The model got better" occasionally means "the model got different", and your Friday reports now have a slightly new personality and an unexplained fondness for bullet points.

Strip away the drama and this is a versioning problem wearing a trench coat. Hosted models are deprecated on schedules you do not set. Even within a version, outputs are non-deterministic, and vendors tune behaviour continuously. If you have no evaluation suite - a fixed set of inputs with known-good outputs that you re-run on every change - you cannot tell whether last week's regression was your prompt, their update, or the sun. Running your own model lets you pin exact weights, log every request, run air-gapped for regulated data, and satisfy a data-residency auditor without a nervous phone call to legal. More importantly, it forces you to build evals, which is the single practice that separates teams that understand their AI from teams that merely enjoy it.

Which raises the more embarrassing half of the problem, because "can't run it" cuts two ways. Many managers now rely on a model to draft, summarise and decide, while being unable to explain what a token is, why the thing confidently invented a court case, or what happens to the attachment they just uploaded. That is not productivity. That is a very expensive form of trust. The future of business will not be decided by who has access to AI - everyone will - but by who can tell the difference between you having control over your business and an external company owning its outputs at a price they set. That literacy is built the same way all literacy is built. You have to touch and experiment with the thing.

Touching the thing does not mean abandoning the frontier. The strongest hosted models will likely stay ahead on hard reasoning for a while, and that is fine. The mature architecture is a routing layer - your own model handles sensitive, repetitive, high-volume work where marginal cost per token matters, and a frontier API handles the hard problems where quality justifies the price. Orchestration frameworks, tool calling and guardrails sit on top, and crucially they sit in your codebase, not in a vendor's UI. The economics follow. At scale, self-hosted inference drops the per-token cost dramatically, and the simple fact that you could leave is the only negotiating position a vendor respects. Optionality is not a nice-to-have. It is the asset.


The Point

The companies of the next decade will split into two groups. One group will have an AI layer it owns - models it can run, data pipelines it understands, evaluations it trusts, and staff who can look under the bonnet. Their capability compounds, because every improvement stays in-house. The other group will have a growing stack of subscriptions, a workforce fluent in prompting and illiterate in everything beneath it, and a business process that technically belongs to someone else's product roadmap.

Both groups will say they are "AI-first". Only one of them will be telling the truth. AI-first - not business first - can mean a dark thing if you think about it.

You do not need to run everything yourself. You need to be able to. Because the alternative is not neutral. If you can't run it, it runs you - and machines can be hard masters to please.