Artificial intelligence will not become an organizational capability because everybody got a chatbot. It will happen when computation, data, models, infrastructure and the ability to shape them become available at every level of the operation.
There is a peculiar moment in every technological revolution when the thing that initially looked like a product begins to reveal itself as infrastructure.
Electricity did it.
Computers did it.
Networks did it.
The internet did it.
And artificial intelligence is doing it now.
For the first years of the generative AI boom, much of the corporate conversation was understandably centered on access. Who has ChatGPT? Which model is better? Can we buy Copilot? Which vendor has the best enterprise agreement? Should employees be allowed to use this new tool?
Those were reasonable questions when AI still felt like an application.
They are increasingly the wrong questions now.
The strategic question is becoming something much larger:
How much intelligence can your organization actually produce, direct, adapt and operate for itself?
This is not simply a question about owning GPUs. Nor is it an argument that every company must train a frontier model in a basement.
It is a question of capacity.
Can a person inside the organization identify a task that could be improved with AI and do something about it?
Can a team assemble its own workflow without waiting six months for an enterprise software implementation?
Can a department connect models to the data and systems that actually define its work?
Can the organization evaluate whether an AI system is improving or merely sounding impressive?
Can it change models when the economics change?
Can it run sensitive workloads where they belong?
Can it capture what it learns from thousands of daily interactions and turn that knowledge into better systems?
Can it decide where computation happens, what it costs, what information reaches it and who controls the resulting capability?
If the answer to most of those questions is no, the organization may have access to artificial intelligence.
But it does not yet have AI capacity.
And the difference is enormous.
The new means of production
The title of this post is deliberately borrowed from a much older argument.
For most of industrial history, productive power depended on access to physical capital: land, factories, machinery, transportation, energy. Whoever controlled those assets controlled a meaningful part of what could be produced, at what scale and under which conditions.
Knowledge work changed the machinery, but not the underlying logic.
A spreadsheet is a machine.
A database is a machine.
A CRM is a machine.
A compiler is a machine.
A search engine is a machine.
Artificial intelligence adds something qualitatively different: a machine that can increasingly participate in the transformation of information itself.
It reads.
Classifies.
Translates.
Writes.
Searches.
Compares.
Predicts.
Extracts.
Codes.
Plans.
Evaluates.
Transforms images.
Operates software.
Coordinates other machines.
What used to be an application layer is beginning to behave like a general-purpose computational labor layer.
That makes access to computation much more consequential.
When an employee cannot run a spreadsheet, we do not say the company lacks access to Microsoft Excel. We say that person lacks a basic operational capability.
A similar transition is underway with AI.
Soon, saying that a team has no practical way to deploy models against its own data may sound as strange as saying that the finance department must call an external vendor every time it wants to calculate a pivot table.
The means of computation are becoming part of the means of operation.
Renting intelligence is not the same as building capacity
There is nothing inherently wrong with APIs.
In fact, external model APIs are one of the most extraordinary infrastructure abstractions ever offered to software developers. For a few cents or dollars, an organization can temporarily access a computational system that cost billions to create.
That is an astonishing bargain.
The mistake is confusing cheap access to someone else’s capability with the creation of your own.
Imagine a company where every employee receives access to a powerful AI assistant.
Productivity goes up.
Documents are written faster.
Research gets summarized.
Emails improve.
Presentations appear almost magically.
Everyone is impressed.
Then look beneath the surface.
The organization may still have no shared model infrastructure.
No internal inference endpoint.
No systematic retrieval layer.
No common evaluation framework.
No process for building datasets from operational knowledge.
No model gateway.
No reusable agent tools.
No secure environment for experimentation.
No way to move a successful prototype into production.
No cost accounting beyond a monthly SaaS invoice.
No systematic record of which tasks are actually benefiting.
No internal team capable of replacing the provider.
The individuals have become more capable.
The organization has not necessarily become much more intelligent.
This distinction matters because individual productivity gains are only the first layer of AI adoption.
The larger gains come when intelligence becomes embedded in the structure of the operation itself.
From AI users to computational operators
The first wave of enterprise AI adoption has produced millions of AI users.
The next wave must produce computational operators.
Not machine-learning researchers.
Not necessarily programmers.
Operators.
People who understand enough about models, data, context, tools and evaluation to reshape the computational environment around their own work.
Consider the difference.
An AI user asks a chatbot to summarize a weekly report.
A computational operator notices that the same report is generated every Friday, identifies its data sources, defines what matters in the summary, connects the relevant systems, establishes an evaluation criterion and turns the activity into a repeatable workflow.
The first saves twenty minutes.
The second changes the process.
This distinction should exist throughout the organization.
At the individual level, people need access to flexible models and the literacy to use them critically.
At the team level, people need shared tools, reusable prompts, agents, datasets and workflows.
At the process level, AI needs programmatic access to systems and clear operational boundaries.
At the departmental level, teams need the ability to allocate compute, deploy applications, manage data and evaluate results.
At the enterprise level, the organization needs common infrastructure, governance, observability, security and an architecture that prevents every successful experiment from becoming another isolated island.
AI capacity therefore cannot live exclusively in an “AI team.”
The AI team can build roads.
It cannot be the only organization allowed to drive.
Every operational layer needs a computational surface
One of the mistakes we repeatedly see in technology adoption is the creation of a massive gap between consumer access and centralized infrastructure.
Employees receive a chatbot.
Somewhere else, a specialized engineering team receives a GPU cluster.
Between the two lies almost nothing.
That middle is precisely where much of the economic value of AI will be created.
A marketing analyst should be able to turn a useful experiment into a small internal application.
A customer-service team should be able to connect a model to approved knowledge sources and evaluate answer quality.
An operations manager should be able to automate document classification without creating a procurement project.
A developer should be able to request an internal model endpoint as easily as a database.
A data team should be able to expose a governed dataset to models without copying it into a mysterious third-party interface.
A creative team should be able to assemble image, video, text and retrieval models into a workflow rather than being imprisoned inside whichever product happened to bundle those functions first.
A factory, clinic, agency, publisher or logistics company should be able to decide that a particular inference workload belongs locally, close to its data or devices, and deploy it there.
This is what building AI capacity at every operational level means.
Not giving everybody root access to a server.
Giving every level of the organization an appropriate degree of computational agency.
Infrastructure is much more than GPUs
The hardware receives disproportionate attention because it is visible.
A rack of GPUs looks like infrastructure.
A well-designed evaluation pipeline does not.
But AI infrastructure is an ecosystem.
Compute is one component.
Data is another.
Storage.
Networking.
Model serving.
Identity.
Permissions.
Observability.
Vector retrieval.
Queues.
Caches.
Model registries.
Tool interfaces.
Application runtimes.
Evaluation systems.
Feedback collection.
Dataset versioning.
Monitoring.
Security boundaries.
And, increasingly, orchestration between models with very different capabilities and costs.
A company with eight powerful GPUs but no operational architecture may have less useful AI capacity than a company with modest hardware and an extremely good internal platform.
This is important because the goal is not to maximize computational ownership.
The goal is to maximize useful computational optionality.
Some workloads should run through frontier APIs.
Some should use smaller inexpensive hosted models.
Some should run in a private cloud.
Some should run on-premise.
Some should run on a laptop.
Some should run directly on a machine at the edge.
Some tasks deserve a giant reasoning model.
Others deserve a 500-million-parameter classifier that answers in six milliseconds and costs almost nothing.
A mature AI operation can make those choices.
An immature one sends everything through whichever interface procurement approved last year.
The model should be replaceable
One of the strongest indicators of AI maturity is how painful it would be for an organization to change models.
If changing from Model A to Model B requires rebuilding the whole application, the organization does not really own the application architecture.
The model owns it.
This is especially dangerous in a field moving as quickly as AI.
Today’s best model may be mediocre twelve months from now.
Today’s cheap model may become expensive.
Today’s proprietary feature may become an open-source commodity.
Today’s API may disappear.
Today’s enormous model may be replaced by a specialized smaller one.
Today’s cloud workload may become economically sensible to run locally.
Infrastructure should assume this change rather than resist it.
Applications should talk to model abstractions.
Workflows should define capabilities rather than brand names.
Evaluation datasets should allow models to compete against one another.
Retrieval should be separable from generation.
Business logic should not disappear into prompts.
Tools should have explicit interfaces.
Data should remain portable.
Models should enter and leave the architecture without bringing the organization down with them.
This is not merely good software engineering.
It is strategic leverage.
The cheapest token is the one you do not have to buy twice
AI economics are often discussed as price per million tokens.
Useful metric.
Incomplete picture.
The real cost of organizational AI also includes duplicated context, repeated reasoning, unnecessary calls, poor routing, oversized models, idle hardware, forgotten subscriptions, fragmented workflows and people repeatedly solving the same problem in isolation.
Infrastructure creates opportunities to recover those losses.
Shared retrieval systems prevent every application from rebuilding the same knowledge layer.
Prompt and context caching prevent repeated computation.
Model routing sends simple work to inexpensive models and difficult work to stronger ones.
Batch inference uses hardware efficiently.
Small models handle narrow repetitive tasks.
Reusable tools allow many agents to interact with the same business systems.
Internal services let one successful piece of engineering benefit dozens of teams.
And local compute can turn some high-volume workloads from a variable external expense into a predictable internal resource.
This is where AI moves from experimentation to industrialization.
Not because experimentation stops.
Because the organization becomes better at turning experiments into reusable machinery.
Data is accumulated operational intelligence
The debate about AI ownership often becomes obsessed with model weights.
But for most organizations, the truly irreplaceable asset is not the model.
It is the growing corpus of knowledge produced by the operation.
Customer interactions.
Corrections.
Successful outputs.
Rejected outputs.
Documents.
Internal terminology.
Decision histories.
Product information.
Workflow states.
Expert annotations.
Visual assets.
Measurements.
Exceptions.
Edge cases.
Feedback.
This is the material from which increasingly specialized intelligence can be built.
Every time someone corrects an AI answer, a potentially valuable training example has been created.
Every time a human chooses one generated option over another, preference data has appeared.
Every repeated question exposes a retrieval requirement.
Every failure reveals an evaluation case.
Every manual intervention in an automated process identifies a boundary.
Organizations that treat these events as disposable interactions will continuously rent intelligence from the outside.
Organizations that capture them systematically will accumulate operational intelligence.
The latter is much harder to copy.
You cannot outsource the learning loop
This may be the most important part.
The real competitive advantage is rarely the first AI system you deploy.
It is the speed at which the organization learns how to improve it.
Deploy.
Observe.
Measure.
Correct.
Capture.
Evaluate.
Change.
Deploy again.
That loop is where AI capability compounds.
A vendor can sell you software.
A consultant can accelerate implementation.
A cloud provider can rent you enormous amounts of compute.
A model company can give you extraordinary reasoning capabilities through an API.
None of them can fully own the learning loop of your operation without also absorbing some of the knowledge that makes your operation distinct.
This is why internal capacity matters even when most of the technology remains external.
You need enough understanding inside the organization to know what should be outsourced and what should not.
Enough infrastructure to preserve options.
Enough talent to evaluate claims.
Enough data discipline to accumulate learning.
Enough computational capacity to experiment without asking permission every time curiosity appears.
Centralize the boring things. Decentralize invention.
There is an understandable temptation to respond to AI chaos with total centralization.
One approved model.
One platform.
One team.
One process.
One gateway.
One committee.
It looks governable.
It can also become a beautifully organized way to prevent anything interesting from happening.
The opposite extreme is equally dysfunctional: hundreds of employees purchasing unrelated AI products, copying corporate information into unknown systems and building workflows that disappear when their creator leaves.
The useful architecture sits between those extremes.
Centralize identity.
Security.
Logging.
Model access.
Cost controls.
Core data connectors.
Deployment standards.
Evaluation infrastructure.
Reusable tools.
Approved storage.
Centralize the things that are expensive, risky or pointless to rebuild fifty times.
Then decentralize experimentation.
Let teams compose.
Let departments prototype.
Let domain experts define evaluation criteria.
Let operators discover use cases.
Let people close to the work reshape the work.
The platform should make the safe path the easiest path.
That is much more powerful than trying to predict every possible AI application from a central office.
AI literacy must reach the boardroom and the loading dock
“AI training” is often reduced to prompt-writing workshops.
That is not enough.
Different parts of an organization need different forms of literacy.
Executives need to understand capability, economics, risk, dependency and strategic options.
Managers need to understand workflow redesign, evaluation and the limits of automation.
Domain experts need to understand how their knowledge becomes context, data, rules and evaluation criteria.
Developers need to understand model behavior, inference architecture, orchestration and observability.
Data teams need to understand how AI changes the consumption and production of organizational information.
Security teams need to understand an entirely new attack surface.
Procurement teams need to understand switching costs that are not obvious from subscription pricing.
Front-line workers need to understand when AI is useful, when it is uncertain and how to correct it.
The objective is not to transform every employee into an AI engineer.
It is to prevent AI from becoming a magical layer that nobody outside a specialist group can interrogate.
Organizations should know what their machines are doing.
We have made this argument before in the context of opaque AI systems: if all you can see are the shadows on the wall, sophisticated output can create the illusion of sophisticated understanding.
Capacity means turning around and looking at the machinery.
The infrastructure has cultural consequences
There is another reason to place computational capability close to the operation.
People invent differently when experimentation is cheap.
If every AI idea requires a business case, procurement approval, a vendor call and a quarterly roadmap meeting, employees quickly learn not to have AI ideas.
If a prototype can be assembled safely in an afternoon, the organization develops a different relationship with the technology.
Questions become experiments.
Complaints become workflows.
Repetitive tasks become candidates.
Unexpected datasets become useful.
People begin discovering possibilities that no centralized transformation plan could have predicted.
This is how general-purpose technologies actually spread.
Not through one enormous use case.
Through thousands of small appropriations.
The spreadsheet did not transform business because a CEO announced a Spreadsheet Strategy.
It transformed business because computation suddenly appeared on desks.
The web did not become organizational infrastructure because every useful website was designed by the CIO.
The capability became ubiquitous, and people built on top of it.
AI will follow a similar pattern.
The difference is that this time the new computational surface can manipulate language, images, code, decisions and software itself.
The surface is much larger.
Build the refinery, not just the pipeline
Many organizations currently treat AI strategy as a procurement pipeline.
Acquire models.
Acquire licenses.
Acquire applications.
Acquire compute.
But raw access is not enough.
Oil is not an economy until there are refineries, distribution systems, engines, standards, skills and industries built around it.
Compute is similar.
The valuable organizational layer is everything that converts raw model capability into useful work.
Adapters.
Data pipelines.
Evaluation.
Interfaces.
Agents.
Workflows.
Monitoring.
Human review.
Domain models.
Feedback loops.
Deployment systems.
Governance.
That middle layer is where generic intelligence becomes specific organizational capability.
And unlike access to a frontier model, it cannot simply be purchased once and considered finished.
It must be cultivated.
Do not build a miniature hyperscaler
There is a predictable misreading of this argument.
If owning computational capacity is good, more owned hardware must be better.
No.
An organization does not seize the means of computation by purchasing a mountain of accelerators it cannot keep busy.
Owning idle infrastructure is not sovereignty.
It is depreciation.
The objective is not technological autarky.
It is the ability to choose.
A good AI architecture may aggressively use commercial APIs while keeping its data architecture internal.
It may run stable high-volume workloads on-premise while bursting into cloud capacity for peaks.
It may use open models for privacy-sensitive processes and frontier models for complex reasoning.
It may deploy tiny local models on edge devices and giant remote models for planning.
It may rent nearly all its compute while owning the orchestration, evaluation, datasets and interfaces.
It may eventually discover that local inference is dramatically cheaper for a particular workload and move it in-house.
Capability is measured by the number of viable choices available to you, not the number of servers you own.
The company that can compute can adapt
The AI market will continue changing at a speed that makes long-term vendor predictions nearly useless.
Models will become smaller.
And larger.
Cheaper.
More specialized.
More multimodal.
More agentic.
New hardware architectures will appear.
Old hardware will become unexpectedly useful.
Inference will move between device, edge, datacenter and cloud.
Some tasks currently requiring generative models will collapse into tiny deterministic systems.
Other tasks we currently consider impossible will become routine.
In that environment, the durable advantage is not betting correctly on one model.
It is building an organization capable of absorbing whatever comes next.
That requires technical architecture.
But also organizational architecture.
People who can experiment.
Systems that can be changed.
Data that can be reached.
Infrastructure that can be composed.
Processes that can be measured.
Leadership that understands the difference between a demo and a capability.
Seize the means of computation
So yes: seize them.
Not from anyone.
For yourselves.
Give the analyst a way to compute.
Give the designer a way to compute.
Give the researcher a way to compute.
Give the warehouse, the studio, the call center, the engineering team and the executive office computational surfaces appropriate to their work.
Give teams enough autonomy to discover what intelligence means inside their own processes.
Give developers infrastructure instead of a pile of API keys.
Give models access to governed data instead of copying knowledge manually into chat windows.
Give the organization evaluation systems so it can distinguish progress from theater.
Build shared services.
Build datasets.
Build feedback loops.
Build deployment paths.
Build internal talent.
Own enough infrastructure to preserve your options.
Rent what makes sense.
Run locally what makes sense.
Replace models freely.
Measure everything that matters.
And above all, do not mistake consuming artificial intelligence for developing artificial intelligence capability.
The organizations that prosper in the next phase will not necessarily be those with the largest models, the biggest GPU clusters or the most expensive enterprise subscriptions.
They will be the ones in which useful computation can appear wherever a useful idea appears.
That is when AI stops being a tool someone sells you.
It becomes part of what the organization is capable of doing.
And that is the means of computation worth seizing.
EN 
ES