This article was originally published on NOVA-MBA.
This editorial draws on and connects two pieces published in MIT Technology Review Italia: The engineered enterprise in the age of AI (May 2026), which introduces the shift from technology adoption to enterprise design, and The first choices of the engineered enterprise in the age of AI (September 2026), which looks at how the AI supply market is separating and recombining new strategic control points.
From adoption to enterprise design
We are used to approaching the relationship between businesses and artificial intelligence by focusing mainly on one question: which model or platform should we choose? It is an understandable question. But it risks starting from the wrong object, because it treats AI as a new tool to add to the company’s digital toolbox. When it becomes a stable part of processes, AI can change how knowledge is produced and verified, how work is coordinated, how decisions are prepared and where human judgment must remain.
This is where the concept of the engineered enterprise comes from. It is not a company run by engineers, nor an organization where everything is automated. It is a company that treats its own organizational operating system as a design object: people, models, data, workflows, interfaces, controls, incentives, escalation paths and judgment are designed as parts of a single socio-technical system. The managerial company of the twentieth century coordinated mainly through hierarchies, budgets, reporting and procedures. The engineered enterprise increasingly coordinates through architectures as well: what systems can see, which actions they can perform, where verification is needed, what information crosses an interface and how a component is changed when external conditions change.
In this sense the CEO becomes, in part, the company’s Chief Engineer. Model design and code remain specialist responsibilities. The CEO is responsible for the architecture within which technology and organization combine. Governance must move down from policies and committees into the workflows themselves, in the form of permissions, audit trails, evaluation routines, human checkpoints, fallbacks and escalation rules. At the same time, modularity becomes a strategic choice: separating what may need to change without forcing the company to rebuild the entire system each time.
The control points of the AI supply
Modularity becomes particularly important because the AI supply market is also breaking apart. Functions that can be purchased together from a single vendor are becoming separable control points and, in some cases, separately contractable. As the market takes shape, these control points separate and recombine.
We are still in the first moments after the “Big Bang” of generative artificial intelligence: the supply ecosystem, regulation, geopolitics and competitive structure are evolving together. The fundamental components and control points of the market have not yet settled into lasting combinations. For the engineered enterprise, predicting which technological configuration will prevail matters less than preserving enough granularity to distinguish the decisions that matter and enough modularity to recombine them when technologies, vendors and market conditions change.
Behind the choice of an AI lie at least six decisions
What seems like a single choice, which model or platform to place at the center of the AI architecture, contains at least six different and partly interdependent decisions. The first concerns which models and capabilities to use: proprietary APIs, open-weight models, specialized models or a portfolio of different models. The second concerns who retains control of the model once it has been adapted to the company’s needs, and whether the weights and checkpoints resulting from fine-tuning or post-training remain tied to the provider or can be controlled and transferred by the customer. The third concerns who provides the post-training infrastructure. The fourth concerns where inference is run: at the provider, through a hyperscaler, via a specialized operator, in a private cloud or on-premises.
Even the first decision does not necessarily mean choosing a single model destined to become the company standard. Models differ in capability, cost, latency and failure modes. A model may be very effective at one task and less suited to another. For this reason, one possible evolution is the mixture of models: instead of electing one model as the universal default, different tasks are routed to different backends.
The fifth decision concerns routing: who decides which model should receive a given request? Routing can be controlled by the company, entrusted to a third-party service or left to the provider. Whoever manages routing also holds a particular informational position, because they can observe which models work best on different tasks, where they fail and when an alternative is needed.
The sixth decision, perhaps less obvious but fundamental, concerns who can observe, store and use the information and meta-information generated during AI operations, and for what purpose. This decision is different from the others because it goes beyond what the company buys today and concerns who can accumulate knowledge through the way those systems are used.
The boundary between use, observation and reuse of information
Every interaction with an artificial intelligence system produces an output, but it can also generate information about what happens afterwards, when the workflow makes these outcomes observable. A response can be accepted, modified, rejected or repeated. An error can be corrected by a person; a result can be escalated or turned into an action; the professional can make a different decision from the one suggested by the system. In generative workflows and, even more so, in agentic systems, this trace can show where the system failed, how the result was corrected and which subsequent behavior produced a better outcome.
The point is not that the model automatically “learns” from every prompt. During normal inference, mere use does not in itself change the model’s weights. The strategic question is who can observe the information generated during use, who can store it, who can reuse it and to improve what. Observation, storage and subsequent use to improve a model, a router, a service or a workflow are different rights and possibilities.
Agentic systems add further complexity because they can generate an intermediate state carried from one call to the next. If that state remains opaque or tied to the provider, the ability to route the next call to another model may also be reduced. Freedom of routing therefore also depends on who controls the intermediate state. A model can be replaced, inference can be moved, routing can be redesigned and a post-training infrastructure can, at a cost, be recreated elsewhere. Information already absorbed by another organization, however, cannot be called back in the same way.
The engineered enterprise must be designed to change
Separating these control points does not mean that every company must break down its AI architecture to the maximum. Integration has value. Especially for smaller companies, choosing a provider able to absorb technological and operational complexity can be a perfectly rational decision. But it is necessary to know which decisions are being bundled in the hands of a single vendor, which control points are being given up and what freedom may be lost in the future.
A practical test is to ask what would happen tomorrow if it were necessary to change model. Would it be enough to replace one component, or would it be necessary to renegotiate the rights over the use of information, repeat the post-training, rebuild parts of the workflow, lose the state of a process in progress or give up accumulated knowledge? A system can be technically made of modules and still fail this test. Modularity becomes strategic when decisions are separated at the level at which the company may actually need to change them.
One clarification concerns orchestration, which is not a seventh decision on the supply side. Routing chooses the model or endpoint to which a call is entrusted. Orchestration carries out the work across models, tools, systems and people; state management determines what passes from one call to the next. For the engineered enterprise, this complexity must be governed within the architecture, but made as invisible as possible to the people and workflows that do not need to manage it directly.
The value of information depends on architecture
Finally, we are used to thinking of data as an asset with a relatively stable value. But the value of information also depends on the technological architecture able to use it. Current LLM-centered systems place great value on text, code, preference signals and corrections. Other technological trajectories could place greater value on state, actions, trajectories, physical interaction and simulation.
An information stock can therefore remain accurate, proprietary and legally usable, but become more or less valuable if the architecture able to exploit it changes. The same applies to the knowledge a company accumulates about its vendors: benchmarks, evaluations, routing rules and error profiles can quickly become obsolete when models and interfaces change. This knowledge, too, must be treated as an asset that requires maintenance.
For this reason the engineered enterprise is designed so that it can adapt to changes in the AI ecosystem and other external conditions without having to rethink the entire organization each time. The question is not to choose today the “right” vendor once and for all. It is to know which control points matter, which are worth integrating, which to keep separable and which information must remain under the company’s control to preserve future options. At a time when the supply market is still taking shape, this ability to reconfigure is part of the strategy.
Q&A
Is the engineered enterprise a model only for large companies?
No. Size matters less than the nature of the business. If value and coordination depend mainly on information, language and knowledge, even a small company can be radically exposed. The comparison will increasingly be with new AI-native companies, often small, able to replicate the same value proposition with structurally different costs, margins and flexibility.
How much modularity is really needed?
As much as is needed to preserve sovereignty and freedom of choice, avoiding technological vassalage to one or two players, even when open-source solutions are used. What matters is the granularity of modularization: it is necessary to separate above all what the company might need to change and what is essential to keep under its own control. A simple test is to ask: does changing model or provider force us to redo post-training, workflows, state or rights over information? If so, the modularity is largely apparent. Autonomy can still be preserved on specific control points that the company has chosen to keep separable.
Do rights over operational information matter even if a company has little bargaining power?
Yes. Bargaining power and control are not the same thing. Even when it cannot dictate the terms, the company must know who can observe, store and reuse the information generated during use, and choose architecture and vendors on this basis as well.
How should one act while the market is still unstable?
One must act without waiting for the market to stabilize and without building the company around a prediction about the winner. Investments must preserve the ability to change. In knowledge-intensive businesses, Jeff Bezos’s formula applies: “Your margin is my opportunity”. If a new AI-native operator can capture the margins of the legacy model by offering the same value with a better structure, sooner or later it will. It is better to build your own AI twin of the business — and cannibalize yourself — than to leave someone else the opportunity to do so by winning over your customers.
References and further reading
- Vena, Marcello. “L’intelligenza artificiale non vi renderà più competitivi (se non cambiate l’azienda).” Wired Italia, 7 April 2026. Frames AI as an enterprise design problem, with attention to modularity, governance and strategic autonomy.
- Vena, Marcello. “L’impresa ingegnerizzata nell’era dell’AI.” MIT Technology Review Italia, May 2026. Introduces the concept of the engineered enterprise and the shift from technology adoption to the design of the enterprise system.
- Vena, Marcello. “Le prime scelte dell’impresa ingegnerizzata nell’era dell’AI.” MIT Technology Review Italia, September 2026. Explores the six strategic decisions, routing, rights over operational information and the modularity of the AI architecture.
