At 00:34 UTC on Saturday, 18 July 2026, Peter Steinberger posted a single sentence on X: “Are we still talking loops or did we shift to graphs yet?” The sentence is often credited with introducing the term “graph engineering,” but it does not contain it.

Four and a half hours later, Hamel Husain published a piece titled “Loop Engineering Is Dead. Enter Graph Engineering”, which several readers took as satire. The label was older than both: an essay dated 4 July had already proposed it deliberately, and the two words have appeared in technical print since at least 2016, in quantum walks and in object graphs, with an unrelated meaning.

The tweet put the label into circulation. By Monday, it had spread far enough for Harrison Chase, the author of LangGraph, to reply: “So i didn’t really know what graph engineering is, and i still don’t really… but it’s basically just langgraph?” On Wednesday, LangChain published “3 Years of Graph Engineering with LangGraph”, calling the expression “the latest term to come out of X’s AI content factory”, and settled the question: “Graph engineering isn’t a new idea. It’s the latest name for a well established approach to building reliable agents.”

Five days were enough to carry the label from an isolated remark to the corporate history of a three-year discipline. The term it displaced, “loop engineering”, had itself been in circulation for a few weeks.

The idea is old, and this is undisputed: LangChain states this directly. What no one is examining is the nature of that idea and when it was first developed. Software engineering built it between 1987 and the end of the 1990s, under the name “software process”: a body of languages, environments, and industrial experiments that is described in the next section. The version now returning under the name “graph engineering” retains only part of it. A discipline that names its concerns in this order — prompt engineering, context engineering, harness engineering, loop engineering, graph engineering — is reconstructing, one term per quarter, a body of knowledge available in published form. And each reconstruction is narrower than the material it reproduces.

The existing corpus

In the spring of 1987, at the ninth International Conference on Software Engineering in Monterey, Leon Osterweil gave a plenary talk whose title set the direction for the next fifteen years of research: “Software Processes are Software Too”. He claimed that the process used to build software is itself an artifact, and can therefore be written in a language, analyzed, executed, and improved.

A research area grew from it, with its own workshops, journals, and industrial programs. The languages were called Process Modeling Languages, and the environments that interpreted them were Process-centered Software Engineering Environments. The paradigms varied: high-level Petri nets in SPADE and in FUNSOFT nets, a logic-based language in Latin, which drove the Sentinel environment, and Osterweil’s own process programming, first in an extension to Ada and later in JIL. Running a process model was called enactment. The environments helped the people doing the work, automated routine steps, and invoked and controlled the tools.

I worked in this area for several years. In 1995, with Sergio Bandinelli, Luigi Lavazza, Maurizio Loi, and Gian Pietro Picco, I published in IEEE Transactions on Software Engineering an account of one such experiment: the anomaly management process of the Business Unit Telecommunications for Defense at Italtel, written partly as finite state machines and partly in SLANG, our Petri-net-based language. The model contained twenty-four SLANG activities. A finite state machine held the states an anomaly report could be in; a net held the coordination among the configuration management group, the change control board, and the qualification subgroup.

Nodes, edges, states, transitions, persistent state, and an engine that advances the model one step at a time. The LangGraph documentation — “At its core, LangGraph models agent workflows as graphs”, with nodes that “encode the logic” and edges that “determine which Node to execute next” — describes, word for word, what we built in 1995. Microsoft’s Agent Framework uses almost the same terms: “A Workflow ties executors and edges together into a directed graph and manages execution.” Google’s ADK 2.0 has made the graph the runtime itself, to the point that its base agent class now inherits from a base node class.

Software Process was not the only research area addressing these topics. The same route was traveled by workflow management systems and BPMN, and later by tools that industrialized them: Apache Airflow, which since 2015 has had data engineers describe their pipelines as directed acyclic graphs of tasks, and AWS Step Functions, which since 2016 has orchestrated cloud services as state machines. That is why the LangGraph documentation cites Pregel, and not Osterweil. The notation survived the journey; the research that explained where it breaks did not.

Reduction, first instance: the process

A process model of the 1990s held three things beyond control flow, and the roadmap I wrote for ICSE 2000 lists them in that order. It held roles: who may perform an activity, and what to do when that person is not available. It treated artifacts as typed objects with a life cycle, so the model knew that a specification document was not a test case and which versions of which items had to remain consistent with each other. And it held tools, with the conditions under which each one is called.

Some of this exists in the current frameworks, and it would be wrong to say otherwise. Microsoft validates a workflow as built, ensuring that message types are compatible across connected executors. Google’s ADK stores artifacts as named, versioned, MIME-typed objects behind a service. CrewAI requires a role string on every agent. So the payload is often typed, and the actor often has a name.

The people are there. LangGraph can stop a run and wait for someone; Google’s ADK asks for confirmation before a tool call. Every serious framework has a way to hand a decision to a human. So these systems coordinate models, tools, and people, which is the same mixed set that the 1990s models coordinated. What they lack is any notion of which person, with what authority, and what happens when that person does not answer. A stopping point without a role is the gap the earlier work had filled.

The largest omission is not on that list. The paper we wrote in 1995 spent its analysis on a distinction that has no equivalent in today’s tools: the process the owner wants, the process as written down, the process each participant believes is in force, the process an observer records, and the process that actually runs. We called them the Desired, Official, Perceived, Observed, and Actual processes, and we concluded that together they form “an unstable feedback system in which stability can only be enforced by reducing the sources of divergencies”.

Robert Balzer had drawn the practical consequence four years earlier, in “Tolerating Inconsistency” at ICSE 1991. A formal system cannot reason usefully once an inconsistency is present, and real development is inconsistent most of the time; a support system should therefore tolerate inconsistency and mark it, so that whoever can resolve it is told, and the parts of the system that cannot handle it are shielded from it. That was a minority position in 1991, and it is the point on which the whole line of work eventually turned.

Part of that apparatus has been rebuilt. Tracing and evaluation are an established product category: a trace records the Observed Process, and an evaluation measures the distance between the result wanted and the result obtained. What is missing is the comparison itself — a declared model to check a trace against, so that a departure is reported as a departure rather than a lower score. The Perceived Process has no name in this vocabulary, as the participants are assumed to be executors.

Reduction, second instance: the specification

The same compression has occurred more visibly in specifications.

The best answer the agent community has produced to ungoverned code generation is spec-driven development: write down what the system must do before the agent writes it. The reasoning is sound, and it is the reasoning software engineering has used since the field had a name.

GitHub’s Spec Kit, public since August 2025 and announced in September, is the most widely adopted case: it organizes a project around a constitution, a specification, a plan, and a task list, written as markdown in headed sections and read by a model. Amazon’s Kiro goes further in one respect, writing its requirements in EARS, a template syntax built at Rolls-Royce for aero engine control systems, which Kiro renders as WHEN [condition/event] THE SYSTEM SHALL [expected behavior]. That is a real constraint, and it is the mildest form of an old one. EARS itself is finer grained: its event-driven pattern reads WHEN <optional preconditions> <trigger> the <system name> shall <system response>, and separating the precondition from the trigger is the point of it. The reduction has happened here too, inside the one place where the specification was supposed to get more precise. Fixing the shape of a requirement so that it can be checked is an idea the field had been working on long before EARS gave it a tidy name, and the A-7E tables discussed below had taken it much further decades earlier.

Prose in headed sections has no formal semantics, no type system, and no mechanical checks for consistency between documents. Spec Kit has added a command that asks a model to check the specification, the plan, and the task list against each other. That admits the problem and answers it with a second model’s judgment.

The SE corpus offers a different comparison. Hoare’s axiomatic basis for computer programming dates from 1969 and gave a program a formal meaning: the axioms and rules of inference were to be “the ultimately definitive specification of the meaning of the language”. VDM had come out of the IBM laboratory in Vienna at the end of 1972. Z was written by Jean-Raymond Abrial in France in 1977 and developed further at Oxford after he arrived there in 1979. At the Naval Research Laboratory, Kathryn Heninger, David Parnas, and their colleagues rewrote the requirements of the A-7E aircraft’s navigation and weapon delivery program as tables of functions, to show that software engineering principles held up on a real embedded system running in twelve thousand instructions and sixteen kilobytes of memory. The exercise produced a finding worth keeping: “Writing down the requirements turned out to be surprisingly difficult in spite of the availability of a working program and experienced maintenance personnel.” Harel’s statecharts, published in 1987, gave event-driven behavior a formal semantics, which STATEMATE made executable and which Simulink Stateflow later carried into industry, so that a specification could be simulated, code generated from it, tests derived to coverage criteria, and safety properties checked by machine. Alloy made lightweight formal modeling automatically analyzable. And IEEE 830, the recommended practice for requirements specifications, now replaced by the international standard ISO/IEC/IEEE 29148, put the reason in four words: “Natural language is inherently ambiguous.”

Most of these notations were built for reasons that recur in the papers introducing them: a specification in natural language admits contradictory readings, and the contradictions are found late, in the running system, by its users.

The notation is the smaller part of what is being ignored. Current discussion of agent-assisted development keeps arriving at one recommendation, offered in good faith: write good requirements. It is put forward as though the writing were the easy part, and as though the whole problem fitted into a well-organized markdown file.

Requirements engineering exists as a field, with a conference series since 1993 and more than thirty years of results, because that is false. It established that requirements are negotiated, not collected, among stakeholders whose aims are legitimately incompatible; that much of what matters is tacit and goes unsaid even by the people who hold it, which is why elicitation is a technique and not a meeting; that requirements change while they are being written, at a rate set by the domain rather than by the analyst’s competence; and that judging a requirement correct, rather than merely well formed, needs a reference outside the document, which is the one thing a document cannot hold.

Fred Brooks made the point in the version of “No Silver Bullet” that reached most readers in 1987, the year of Osterweil’s talk: “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems.” In the volume where I wrote about software processes in 2000, the requirements engineering roadmap by Bashar Nuseibeh and Steve Easterbrook is the paper immediately after mine, and the open problems it lists are still open.

Design has had the same treatment. Architectural styles, architecture description languages, and the design rationale tradition are decades of work on how to record why a system has the shape it has, so the reason outlasts the person who had it. The current answer is a paragraph of prose in plan.md.

I am not arguing that agent projects should be written in — say — Z. Most should not, and the formal tradition stayed in a niche for a real reason: the models cost more to write and keep current than the work they described. I am arguing that a field that has decided specifications matter, and that has a whole discipline’s worth of results on how to write them, might read some of them before settling on markdown.

What went wrong the first time

When I assessed software process research for the Future of Software Engineering track at ICSE 2000, the finding on one specific line of work was blunt: after more than ten years of research on process modeling languages and the environments that interpreted them, none of the approaches had reached industrial practice. The diagnosis had two parts. The languages were built to be executed, which pushed them toward completeness and detail, which made them cost more to write and maintain than the work they described. And the environments got in the way, because a model detailed enough to run is a model rigid enough to obstruct. What reached practice, and is still here, was configuration management, which worked because it automated only the process fragments that were reasonable to automate. The same holds for what later became ITSM (IT Service Management), on the operations side.

The update I wrote with Elisabetta Di Nitto in 2014, for the same track, found no reason to change the original argument. On the languages: “Many languages developed during the 90s were too complex and rigid. In general, they turned out to be difficult to apply in real settings and not capable of producing a concrete impact on software development practices… But PMLs went too far and basically ‘missed the point’.” On the scope of automation: researchers “have recognized that the possibilities of fully automating them are limited to specific aspects and phases such as code generation, testing, packaging, deployment and operation management of final products”. The lesson is that prescriptiveness has a ceiling, and that going past it turns a support system into an obstacle.

Fundamentals without a source

On 14 August 2026, Andrew Ng published what he called The AI Engineering Skills Map, based on an analysis of over 10,000 job postings and a set of expert interviews. Four skills emerge from it: building and deploying AI applications, software engineering fundamentals, using coding agents, and shaping the build. On the second, he is explicit and correct: knowing the fundamentals is what lets an engineer see which tradeoffs exist and steer an agent “using the precise language of software engineering”.

The map, though, is filed under AI engineering. I wrote a few days ago about the two questions that fall under one phrase: how to use AI when building an information system, and how to build a product made with AI. Ng’s map seems to answer the second and borrows the first’s vocabulary. The fundamentals it invokes belong to a discipline that is not the map’s subject.

What has changed

There is a version of this argument that ends in complacency, and I want to avoid it. The corpus did not fail because practitioners were incurious. It failed for two real reasons.

Writing and maintaining a formal model cost more than the work it described. And a deterministic engine, given an incomplete or inconsistent model, either stops or forces a resolution that throws away information the situation held. That is fatal because incompleteness and inconsistency are the normal state of software development, not defects in it. It was the hardest point, and the one where the technology of the time broke: a formal language flexible enough to tolerate deviation is close to a contradiction in terms.

Not everything in the earlier diagnosis was about cost. The 2014 paper gives a second reason, and it is the one that still holds: software development is human-centered, creativity and autonomy are decisive in it, and most of its activities therefore cannot be rigidly automated. What automates well is what is repetitive and error-prone, which is why configuration management and deployment worked. That criterion is about the nature of the activity, not about the price of writing a model for it, so a fall in cost does not affect it.

The two obstacles above are the ones that new technology can remove, and the two claims are not of the same kind.

The first is a hypothesis. Drafting a model, keeping it aligned with the system, and deriving one representation from another are tasks a large language model can perform, so the cost that once blocked this work in the 1990s may no longer be prohibitive.

The second does not depend on cost at all. An executor that generates rather than computes can continue with a partial model instead of stopping at it. A departure comes out as an output to judge, not as an error that halts the run.

The property this delivers already has a specification, written twelve years ago and never claimed. The 2014 paper has a section titled “From Rigid Compliance to Smart Convergence”, and its argument runs: “In software development, consistency is the exception and inconsistency is the most common state. Therefore, it is impossible to impose a rigid adherence to a (often strictly) predefined set of rules and constraints. Rather, it is much more important to ensure that the process as a whole ‘converges’ towards the desired outcome, tolerating, controlling, and exposing inconsistencies as they occur… In process automation and support, it is therefore essential to make inconsistencies a ‘first-class citizen’, helping software developers to visualize, monitor, and manage them, rather than ‘fighting’ to eradicate them.”

No deterministic engine could meet that requirement, and saying so was the honest end of a research program. A generative executor meets part of it by construction. It tolerates inconsistency, because inconsistency is the condition it works in rather than the condition that stops it. It does not expose it. Given a self-contradictory specification, a model picks one reading and produces plausible code, leaving the contradiction in the result rather than in front of the engineer. The 2014 requirement asked for both, and for convergence on top. The remaining half is the research problem, and it is the same one as the missing comparison between a declared model and a trace. The technology arrived after the specification was finalized, and the two have not been integrated.

A PSEE failed because of the people it governed: they found a rigid model inconvenient and circumvented it, and their Perceived Process diverged from the Official one. An agent does not circumvent a model. So the fact that PSEEs failed does not mean agent graphs will fail, and I am not claiming they will. What remains useful from that experience is narrower: a record, built over fifteen years of industrial use, of which parts of a process were worth automating and which were not.

Looking forward

None of this is a claim of priority. Whether a result came first in Milan in 1995 or in San Francisco in 2026 makes no difference to anyone building a system today.

What the earlier work gives is a record of where each path ends: which parts of a process yield to automation and which resist it; what becomes of a model when the people it governs find it inconvenient; why every attempt to specify behavior in prose produced the same class of defect; how much detail a model can carry before maintaining it costs more than the work it describes. That record is written down in venues that are indexed and mostly downloadable, and it is still largely unread by the discussion that is now rebuilding its contents.

Sources

• Leon J. Osterweil, “Software Processes are Software Too”, Proceedings of the 9th International Conference on Software Engineering (ICSE 9), Monterey, CA, 30 March – 2 April 1987, pp. 2–13

• S. Bandinelli, A. Fuggetta, L. Lavazza, M. Loi, G. P. Picco, “Modeling and Improving an Industrial Software Process”, IEEE Transactions on Software Engineering, 21(5), May 1995, pp. 440–454

• A. Fuggetta, “Software Process: A Roadmap”, Future of Software Engineering, ICSE 2000, pp. 25–34

• A. Fuggetta, E. Di Nitto, “Software Process”, Proceedings of the on Future of Software Engineering (FOSE 2014), Hyderabad, pp. 1–12

• Robert Balzer, “Tolerating Inconsistency”, Proceedings of the 13th International Conference on Software Engineering (ICSE 13), Austin, TX, 13–17 May 1991, pp. 158–165. The paper is behind a paywall with no open copy; the account of the guards, or “pollution markers”, follows A. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, B. Nuseibeh, “Inconsistency Handling in Multi-Perspective Specifications”, IEEE Transactions on Software Engineering, 20(8), 1994

• K. L. Heninger, “Specifying Software Requirements for Complex Systems: New Techniques and Their Application”, IEEE Transactions on Software Engineering, SE-6(1), January 1980, pp. 2–13; and K. L. Heninger, J. W. Kallander, D. L. Parnas, J. E. Shore, Software Requirements for the A-7E Aircraft, NRL Memorandum Report 3876, Naval Research Laboratory, 1978

• David Harel, “Statecharts: A Visual Formalism for Complex Systems”, Science of Computer Programming, 8(3), 1987, pp. 231–274

• Frederick P. Brooks Jr., “No Silver Bullet: Essence and Accidents of Software Engineering”, Computer, 20(4), April 1987, pp. 10–19, revised from “Essence and Accident in Software Engineering”, Information Processing 86, IFIP Congress, 1986

• Bashar Nuseibeh, Steve Easterbrook, “Requirements Engineering: A Roadmap”, Future of Software Engineering, ICSE 2000, pp. 35–46

• C. A. R. Hoare, “An Axiomatic Basis for Computer Programming”, Communications of the ACM, 12(10), October 1969, pp. 576–580, 583

• A. Mavin, P. Wilkinson, A. Harwood, M. Novak, “Easy Approach to Requirements Syntax (EARS)”, 17th IEEE International Requirements Engineering Conference, 2009

• ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering, which supersedes IEEE 830-1998

• GitHub, Spec Kit, toolkit for spec-driven development

• Kiro, “Requirements-First Workflow”, Kiro documentation: “System behaviors in EARS format (WHEN…THE SYSTEM SHALL…)” https://kiro.dev/docs/specs/feature-specs/requirements-first/

• Peter Steinberger (@steipete), post on X, 18 July 2026, 00:34 UTC

• Josh C. Simmons, “We Are Entering the Graph Engineering Phase”, dated 4 July 2026 — the earliest deliberate use of the label in this sense I have been able to find. On earlier uses of the two words in unrelated senses, see for instance Quantum walks with dynamical control: graph engineering, initial state preparation and state transfer, New Journal of Physics 18, 2016, and Evil Pickles: DoS Attacks Based on Object-Graph Engineering, ECOOP 2017

• Hamel Husain (@HamelHusain), “Loop Engineering Is Dead. Enter Graph Engineering”, X article, 18 July 2026, 04:59 UTC

• Sydney Runkle, Harrison Chase, “3 Years of Graph Engineering with LangGraph”, LangChain blog, 22 July 2026

• LangGraph documentation, Graph API

• Microsoft, Agent Framework — builder and execution

• Google, “Welcome to ADK 2.0”, ADK documentation, section “Agent Execution: BaseAgent to BaseNode” https://adk.dev/2.0/

• Andrew Ng, “The AI Engineering Skills Map”, 14 August 2026

• Alfonso Fuggetta, “Usare l’AI per costruire software o costruire software di AI?”, A bassa voce, 14 August 2026

• Alfonso Fuggetta, “Claude Workflows: Revisiting Process Modeling Languages Three Decades Later”, A bassa voce, 1 June 2026

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Il post in tre frasi

1. Sotto l’espressione “costruire software con l’AI” convivono due domande diverse: come usare l’AI nello sviluppo di un sistema informatico e come costruire un prodotto basato su un modello di AI.

2. Quasi tutta la letteratura degli ultimi due anni risponde alla seconda, e chi cerca risposte alla prima trova indicazioni che sembrano incoerenti.

3. Rispondere alla prima significa riprendere il patrimonio dell’ingegneria del software e riadattarlo ai nuovi strumenti: un lavoro che non è ancora stato fatto.

Il 12 agosto Matteo Giuliani ha posto su X una richiesta molto interessante che fa emergere una questione chiave:

Sto cercando (forse non esiste ancora) un insieme di BP da utilizzare quando si progetta/scrive sw usando AI. Trovo sul web molte indicazioni, spesso non organiche, che non sempre mi sembrano compatibili. Vorrei una guida sufficientemente sintetica per chiarirmi le idee.

Poco prima aveva usato queste parole: “sto navigando a vista e non mi piace”. E ancora: “leggo di qua, leggo di là (probabilmente troppo) e alla fine ne capisco sempre meno”.

La risposta può risultare banale: quella guida non esiste1. Non è però interessante segnalarne semplicemente l’assenza, quanto discutere la ragione per cui manca. E la ragione è che sotto la stessa espressione “costruire software con l’AI” convivono due domande/risposte diverse.

La prima domanda: usare l’AI mentre si sviluppa

Matteo chiede pratiche da usare quando si progetta e si scrive software e le chiede organiche, coerenti fra loro, componibili, tali da reggere casi industriali e non solo proof of concept. L’AI è lo strumento con cui si lavora. Il prodotto finale può essere un gestionale, un sistema di controllo, un’app mobile o un portale.

Questa prima domanda è quella che si deve costruire e mantenere un sistema e vuol capire come innovare il proprio modo di lavorare alla luce della disponibilità dei nuovi strumenti di sviluppo basati sull’AI. Il materiale che trova online non risponde a queste domande perché è spesso scritto da chi sta risolvendo un problema diverso dal suo.

La seconda domanda: costruire un prodotto fatto di AI

Alla domanda di Matteo ha risposto Mirko Voltolini, suggerendo “AI Engineering: Building Applications with Foundation Models” di Chip Huyen. È un suggerimento ragionevole: quel libro è il testo di riferimento sull’argomento, è ben fatto e il titolo sembra promettere esattamente ciò che Matteo cerca.

L’indice include i seguenti temi: prompting, retrieval, agenti, fine-tuning, dataset, inferenza, valutazione. Sono i passaggi necessari per adattare un LLM a uno specifico scopo applicativo. Il punto è che “costruire applicazioni” in quel contesto significa qualcosa di molto specifico e diverso rispetto al problema sollevato da Matteo. Quel libro discute di come costruire tutto ciò che sta sopra un modello LLM. Non parla di come usare l’AI per la costruzione di applicazioni nell’ampiezza e nell’accezione tipiche dell’ingegneria del software: requisiti, architettura, integrazione con i sistemi esistenti e con i processi aziendali, testing, evoluzione e manutenzione, organizzazione e gestione dei team di sviluppo. Alcuni capitoli si avvicinano a queste tematiche (la scelta dei casi d’uso, il ruolo rispettivo di AI e persone, l’architettura di un sistema in produzione con guardrail e monitoraggio), ma l’impianto e l’approccio restano quelli del progettista di sistemi di AI, anziché quelli dell’architetto di sistemi informatici che vuole usare l’AI per innovare il proprio modo di lavorare.

La ragione è strutturale e non riguarda la bravura di chi ha scritto quel libro. Quasi tutta la letteratura degli ultimi due anni si concentra su applicazioni intese come “strati applicativi basati su un LLM”. Nella realtà organizzativa, le applicazioni basate su componenti di AI fanno parte di un sistema informativo molto più ampio. I costi e i fallimenti risiedono nell’intero sistema, non tanto e non solo nel componente AI.

Matteo non ha cercato male e chi gli ha risposto non gli ha dato un cattivo consiglio. La letteratura disponibile spiega quasi sempre come costruire applicazioni di AI: non è la stessa cosa. I pezzi non si incastrano perché rispondono a due problemi diversi, per due lettori diversi.

La conferma è arrivata da Matteo stesso che, dopo aver guardato l’indice, scrive: “leggendo dettagli sul libro avevo intuito che il focus fosse quello, dunque non proprio ciò che mi interessa ora”.

Cosa succede quando la prima domanda resta senza risposta

Cal Newport ha raccontato pochi giorni fa una storia molto interessante derivata da uno scambio di mail con un suo lettore, un ingegnere senior della Silicon Valley che usa l’AI per scrivere software di tipo generale.

A gennaio aveva ricevuto una prima mail: scettico convertito, l’ingegnere aveva abbandonato l’ambiente di sviluppo tradizionale e lavorava esclusivamente tramite Claude Code. “Overnight, it changed the way I do my job”, aveva scritto: un compito che prima gli costava una settimana ora richiedeva solo due giorni.

Sette mesi dopo lo stesso ingegnere ha scritto di nuovo. Due funzionalità generate secondo queste nuove modalità di lavoro avevano causato il crash del prodotto. Il suo capo gli aveva detto che un terzo incidente avrebbe comportato il licenziamento. “I’ve never had quality issues like this before in my career.”

Il meccanismo che descrive non riguarda la qualità del modello. Il codice prodotto da un agente sembra ragionevole, ma può contenere errori difficili da individuare e va quindi rivisto con attenzione. Tuttavia, capire il codice che non si è scritto è notoriamente faticoso, e la revisione diventa il passaggio che si tende a saltare o sottovalutare, soprattutto se si insegue l’obiettivo della maggiore velocità di sviluppo.

Le esperienze sul campo che si stanno consolidando puntano nella stessa direzione (come ho scritto parlando del ruolo dell'ingegneria del software e della differenza fra coding e ingegneria del software). E chi lavora nelle aziende aggiunge la parte relativa alla responsabilità. In una rassegna di CIO, una manager di un fornitore di sviluppo afferma: “I nostri clienti non pagano per il codice grezzo; pagano per il giudizio, l’architettura, le integrazioni complesse e la responsabilità. Non risolvi tutto questo con un prompt” (traduzione mia).

Cosa cercare, allora

Le due domande hanno risposte diverse e conviene tenerle separate invece di cercare un’unica lettura che le spieghi entrambe.

• Se il problema è usare l’AI nello sviluppo di software, cioè la domanda di Matteo, i temi da discutere riguardano il processo di ingegneria del software, rivisto alla luce dei nuovi strumenti.

• Se il problema è costruire un prodotto basato sull’AI, cioè la domanda a cui il libro segnalato risponde, i temi riguardano il sistema attorno al modello e sono quelli di cui parla la letteratura corrente.

Ecco perché è necessario essere precisi, ricordare la storia e i risultati della ricerca in informatica (e in ingegneria del software), e valorizzare tutto il know-how sviluppato nei decenni scorsi: si evita di “reinventare la ruota” o, peggio, di confondere i problemi e le relative soluzioni.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Fonti

• Matteo Giuliani (@mgiul26), Cristian Mesiano (@Cr1st14nM3s14n0) e Mirko Voltolini (@mvoltoli), scambio su X, 12 agosto 2026

• Chip Huyen, AI Engineering: Building Applications with Foundation Models, O’Reilly, dicembre 2024

• Cal Newport, On AI Coding and Its Discontents, agosto 2026

• AI Is Altering the Economics of Software Development, but Who Gets a Cut?, CIO, 31 marzo 2026

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

La prima volta che lo ascoltai, mi resi conto di ciò che accadde a metà degli anni settanta con il loro ingresso nei Fleetwood Mac: furono la loro presenza e il loro sound a trasformare la band e a portarla al successo mondiale degli anni successivi.

Il sound di questo album, che all’epoca non ebbe successo, è incredibile e fa capire che cosa sarebbe arrivato dopo.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Il post in tre frasi

1. Le crisi d’impresa più pericolose covano in silenzio proprio quando l’azienda è al culmine del successo: il declino di Nokia come produttore di cellulari era già scritto negli anni della sua egemonia, molto prima dell’arrivo dell’iPhone.

2. Ciò che separa chi affonda da chi si rialza è il coraggio di riconoscere che il terreno è cambiato: Microsoft lo trovò con Nadella, spostandosi dal client al cloud; Nokia restò legata al proprio passato.

3. Per chi dirige un’impresa, l’antidoto è culturale prima che strategico e si riduce a tre pratiche scomode: coerenza tra ciò che si dice e ciò che si fa, lealtà al posto della fedeltà e la capacità di ammettere di aver sbagliato.

In tanti anni di lavoro ho visto due tipi di crisi d’impresa.

Il primo è quello più semplice da rilevare e da studiare: si palesa sotto gli occhi di tutti. Non serve essere geni per capire che il digitale e Internet hanno messo in crisi l’editoria, i giornali, il mondo delle news. Lo stesso vale, per fare un altro esempio, per la grande distribuzione che ha messo in crisi i piccoli negozi di quartiere. In questi casi, le analisi si sprecano e ciascun attore cerca una via per superare gli ostacoli.

Nokia è il caso di scuola. La sua crisi non comincia nel 2007 con l’arrivo dell’iPhone. Comincia molto prima, negli anni della sua egemonia. Alla fine degli anni Novanta Nokia era il primo produttore di telefoni al mondo, con margini che nessun concorrente si sognava. E già allora, parlando con chi in Nokia contava, mi sentivo ripetere una frase che avrebbe pesato più di qualsiasi bilancio: “noi non facciamo software”. Nel 2002, cinque anni prima dell’iPhone, in un’intervista con Beppe Caravita per Il Sole 24 Ore, sostenevo che il software sarebbe diventato il cuore dello sviluppo delle telecomunicazioni, e che servivano piattaforme europee per il mobile e per ciò che allora non si chiamava ancora IoT. Nokia era leader assoluto e aveva tutto per costruirle. Scelse di restare un colosso dell’hardware.

Il fuoco covava lì, sotto una cenere fatta di bilanci ancora eccellenti. L’iPhone, nel 2007, non ha acceso quel fuoco: ha spazzato via la cenere che lo nascondeva. Da un giorno all’altro divenne evidente a tutti quanto Nokia fosse rimasta indietro sul software e sull’ecosistema. Nel 2011 il nuovo amministratore delegato, Stephen Elop, descriveva Nokia ai propri dipendenti come un uomo fermo su una “piattaforma in fiamme”. Nel 2014 la divisione telefoni fu venduta a Microsoft.

Microsoft, nello stesso periodo, era nella medesima trappola e la sua fissazione aveva un nome: il client. A Redmond tutto ruotava attorno a Windows, Office e Windows Mobile, al punto che Steve Ballmer poté ridere in pubblico dell’iPhone. Per un decennio il titolo rimase piatto, quello che ancora chiamano “il decennio perduto”. La svolta arrivò nel 2014 con Satya Nadella, cresciuto nella divisione server e cloud e non in quella del client. Per tempo, Nadella spostò il baricentro dell’azienda: dal client ai server, con Exchange e i prodotti enterprise, e da lì al cloud, con Azure. Fu la lungimirante rinuncia all’idea che tutto dovesse ruotare intorno a Windows. Per Microsoft equivalse a ciò che Nokia non fece mai: riconoscere che il campo di battaglia era cambiato. Microsoft si rilanciò grazie a quella scelta. Nokia restò legata al suo passato.

Le crisi silenziose hanno un profilo ricorrente:

• arroganza e supponenza verso il mercato e verso i propri clienti;

• cecità rispetto ai segnali deboli o latenti;

• retorica trionfante che supera ogni limite di buon senso e di realismo e che cancella il dibattito all’interno dell’azienda;

• incapacità di cogliere lo scarto tra ciò che si dichiara e ciò che si è.

Che fare in questi casi?

Semplificando, questo cambiamento interiore si può ridurre a tre cose.

Primo: essere fedeli a se stessi

La descrizione forse più nota del fallimento interiore è la parabola dei sepolcri imbiancati: puliti fuori, pieni di ossa dentro. Duemila anni dopo resta la migliore fotografia di una dichiarazione di scopo a cui, dentro l’edificio, non crede nessuno. Come dicono gli anglosassoni, “walk your talk”, che alla fine si riduce a tre parole.

• Coerenza: ciò che dici e ciò che fai coincidono. Le parole chiave e gli slogan che riempiono i poster delle sale riunioni, i meeting aziendali, i documenti e i siti diventano veri e significativi solo quando si ritrovano nelle decisioni di tutti i giorni, anche nelle più piccole e insignificanti.

• Sincerità: lo pensi davvero, anche quando ti costa. Una convinzione si misura quando difenderla ha un prezzo, non quando serve a fare curriculum o a fare audience.

• Integrità: regge quando nessuno sta guardando. È ciò che resta dei valori dichiarati quando non c’è un pubblico che ti ascolta e ti giudica.

Secondo: lealtà, non fedeltà

Le due parole sono spesso confuse, ma non significano la stessa cosa. “Lealtà” viene da legalis, la legge; “fedeltà” da fides, la fiducia tra le persone. La prima lega a una regola che sta al di fuori di tutti noi; la seconda lega una persona a un’altra. Quando chiedo lealtà e non fedeltà, non cerco una parola più calda né una complicità più o meno virtuosa: cerco qualcosa che punti altrove rispetto a me.

Kim Scott, in Radical Candor, ha dato a questa distinzione un vocabolario operativo. Due assi: prendersi cura della persona e sfidarla apertamente, che, a loro volta, generano quattro quadranti. Il candore radicale è il quadrante in cui ci si prende cura dell’altro pur sfidandolo: è la lealtà. L’empatia rovinosa è quando si vuole prendersi cura dell’altro ma si tace per amor di tranquillità. Scott osserva che questo è il fallimento più diffuso: la fedeltà cieca. L’insincerità manipolativa è quando non ci si cura dell’altro né lo si sfida: è la ricerca del puro tornaconto, il coltello nella schiena quando serve, senza remore né rimpianti. Per ultima, l’aggressività odiosa, quando si sfida l’altro senza prendersene cura: la cito perché è il modo in cui questo discorso viene di solito frainteso. Il candore non è il permesso di far del male all'altro.

Terzo: ammettere di aver sbagliato

È la virtù più discussa, più declamata, più acclamata e meno praticata nella gestione d’impresa e discende direttamente dalla precedente: un leader circondato da fedeltà, e non da lealtà, non sente mai parlare dei propri errori. Al massimo non perde occasione per stigmatizzare quelli degli altri.

Tutto il resto — cultura, valori, framework di leadership, il poster appeso in reception — dipende da quale dei due tipi è in cima. Un’azienda non può essere intellettualmente più onesta con se stessa di quanto lo siano le persone che la governano.

La brace

Il fuoco che cova sotto la cenere non si spegne con una strategia. Si rileva e si combatte con la disciplina di dirsi la verità quando i numeri sono ancora buoni, quando nessuno ti obbliga a farlo, quando costa in termini di consenso e di serenità dei rapporti umani.

La brace resta accesa a lungo prima che qualcuno la veda divampare oltre la cenere. Il compito di chi guida è avere il coraggio di sporcarsi le mani e di togliere per primo quella cenere.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Dicembre 2015, intervista a Fortune: “We’re going to end up with complete autonomy, and I think we will have complete autonomy in approximately two years”. Ottobre 2016, conference call con la stampa, sulla traversata Los Angeles-New York attesa per la fine dell’anno seguente: “Without the need for a single touch including the charger”. Febbraio 2018, earnings call del quarto trimestre: quella stessa traversata è diventata “three months, six months at the outside”. Aprile 2019, Autonomy Day: robotaxi autonomi entro l’anno successivo, su un milione di Tesla già in strada con l’hardware necessario. Luglio 2020, videocollegamento con la World AI Conference di Shanghai: “I remain confident that we will have the basic functionality for level 5 autonomy complete this year”.

Come catalogo di promesse mancate, la sequenza si commenta da sé. Come sintomo, dice qualcosa in più: per dieci anni la discussione pubblica sulla guida autonoma ha avuto la forma di una domanda su una data, ma il calendario era solo metà della questione.

Cosa scrivevo nel 2017

Il 28 novembre 2017 pubblicai su TechEconomy un pezzo intitolato “Il mito della guida autonoma”. Mi appoggiavo soprattutto a due saggi di Rodney Brooks, professore emerito di robotica al MIT, sui casi limite della guida autonoma. Ne ricavavo una lista di domande: che succede se la strada è bloccata per manutenzione; se un autista si ferma davanti al veicolo; se un semaforo si guasta; se non esiste una distinzione fra marciapiede e strada; come interagisce un’auto a guida autonoma con la polizia o con chi sta svolgendo una missione di emergenza. Una sezione del saggio di Brooks si intitola “Maps Don’t Tell the Whole Story”, ed è la formula che avevo ripreso.

Citavo poi Jean-Louis Gassée sull’incrocio fra Hayes e Octavia a San Francisco, dove pedoni e automobilisti negoziano la precedenza con lo sguardo e con cenni del capo: “Can we ‘algorithmicize’ eye contact and stuttering restraint?”. E citavo Chris Urmson, che aveva diretto il progetto di Google fino al 2016. A SXSW, nel marzo 2016, aveva detto: “How quickly can we get this into people’s hands? If you read the papers, you see maybe it’s three years, maybe it’s thirty years. And I am here to tell you that honestly, it’s a bit of both”. Poi aveva aggiunto una frase che allora mi era parsa minore: “We imagine we are going to find places where the weather is good, where the roads are easy to drive — the technology might come there first”.

Chiudevo confrontando i settori dove la guida automatica funzionava già (treni che si muovono lungo una sola dimensione, aerei su traiettorie separate da chilometri, magazzini robotizzati in ambienti chiusi e regolari) con ciò che avevamo davanti. Notavo che le sperimentazioni americane si svolgevano su strade “molto larghe, spesso rigorosamente perpendicolari, con corsie e incroci canalizzati”, e chiedevo: “Possiamo forse confrontare un magazzino robotizzato di Amazon con il centro storico di (diciamo) Como o Firenze?”.

Quella parte del post ha retto meglio di quanto mi aspettassi. La domanda era però incompleta, e il fastidio è che il materiale sul dove era a portata di mano: le strade perpendicolari della California, il centro storico di Como, la frase di Urmson sui places where the weather is good, where the roads are easy to drive. L’ho usato per argomentare che serviva più tempo, cioè per discutere del calendario, come tutti gli altri. In realtà, quei commenti mettevano in luce anche un’osservazione sullo spazio, e non l’avevo vista.

Dove si guida senza conducente

Chi nel 2017 diceva che non sarebbe mai successo aveva torto e conviene riconoscerlo. La guida senza una persona al volante esiste, è commerciale ed è a pagamento. Waymo la offre al pubblico in undici aree metropolitane statunitensi; l’ultimo dato comunicato, a marzo, parla di oltre mezzo milione di corse pagate a settimana: dieci volte le cinquantamila del maggio 2024, il doppio dell’aprile 2025. In Cina, Apollo Go di Baidu ha registrato 3,2 milioni di corse completamente autonome nel solo primo trimestre del 2026, con un picco settimanale superiore a 350.000 nel marzo 2026. Tesla ha cominciato a togliere il safety monitor dall’abitacolo ad Austin nel gennaio 2026 — poche auto della flotta, non l’intera flotta — e a Miami, a luglio, è partita per la prima volta senza di esso.

Le proporzioni ridimensionano lo scenario. La flotta Waymo era di poco più di tremila veicoli a fine 2025, ultimo dato comunicato ai regolatori federali; l’area di servizio complessiva superava a maggio le 1.400 miglia quadrate, un terzo in più della superficie del Rhode Island, il più piccolo stato americano per estensione: in una stima di aprile, quando il totale era ancora sulle millecento, Phoenix da sola ne valeva trecentoquindici e Houston venticinque. La flotta Tesla senza monitor, conteggiata veicolo per veicolo da un tracker indipendente, era di ventuno unità a luglio fra Austin e Dallas, ferma sui valori di maggio dopo un picco di venticinque a fine aprile; e in California Tesla continua a guidare con una persona al volante, perché opera con un permesso da noleggio con conducente e non ha chiesto quelli che servirebbero per un servizio autonomo.

Tesla is not operating an autonomous vehicle service. So in California we define autonomous vehicles to be those that are SAE level three… Tesla is a level two system and so they do not have a permit with the California Public Utilities Commission and my understanding is that they do not have a permit with the DMV either.

What they have from us is essentially a charter party carrier permit. It is the same type of permit that a limousine company would get… the person who is sitting in the driver’s seat, that is the driver. That is not a safety driver.

Pat Tsen, vicedirettore esecutivo del CPUC, Driverless Digest, 25 marzo 2026.

Fuori dagli Stati Uniti non esiste ancora nulla di paragonabile. A Londra Waymo prova da aprile 2026 con un centinaio di veicoli e uno specialista al volante; a Tokyo guida dal 2025 con equipaggi di Nihon Kotsu a bordo. Nessuna data annunciata per il passaggio alle corse senza conducente.

Come questi operatori entrano in una città nuova dice più di qualsiasi dichiarazione. Prima si guida con un “autonomous specialist” al volante, per validare il sistema. Poi si passa al rider-only, senza nessuno davanti, ma con i dipendenti dell’azienda a bordo come passeggeri. Poi si aprono gli inviti a scaglioni. Solo alla fine si può scaricare l’app e utilizzarla. San Diego, Las Vegas, Tampa e Denver, annunciate l’8 luglio, sono al secondo gradino. Il perimetro è disegnato, mantenuto e modificato dall’operatore; ogni estensione costituisce un annuncio aziendale.

Che la difficoltà dell’ambiente conti si vede nei numeri, con una cautela che pesa quanto i numeri. Uno studio dell’IIHS, pubblicato il 23 luglio, ha ripulito i rapporti d’incidente trasmessi alla NHTSA e li ha confrontati con quelli dei guidatori umani nelle stesse aree e negli stessi anni: circa cinquanta milioni di miglia percorse da Waymo senza conducente contro circa duecentoventidue miliardi di miglia percorse da guidatori umani.

“Overall, Waymo’s crash involvement rate was 68% lower than that of human drivers — 76% lower in Phoenix, 35% lower in San Francisco, 71% lower in Los Angeles, and 4% higher in Austin, where the sample size was relatively small.” — IIHS, 23 luglio 2026

Il confronto fra Phoenix e San Francisco lo faccio io, non l’IIHS: quaranta punti di scarto fra una griglia dell’Arizona e una città di colline, nebbia e traffico pedonale sono difficili da attribuire al caso. Il dato copre però gli anni dal 2021 al 2024, e si ferma prima dell’espansione nel Sun Belt: sulle città aperte fra il 2025 e il 2026 non dice nulla. David Harkey, presidente dell’istituto, lo mette per iscritto: “the present data collection system isn’t good enough to allow continuous monitoring of a large-scale expansion”.

“Senza conducente” si riferisce all’abitacolo, non al sistema. Dietro la flotta c’è una squadra di operatori remoti che interviene quando la macchina si pianta. Il presidio umano si è trasferito dall’abitacolo a una sala operativa.

Recintati, e nemmeno del tutto

“I believe the technology was deployed too quickly in too vast amounts, with hundreds of vehicles, when it wasn’t really ready.” — Lt. William White, Austin Police Department, ai regolatori federali, citato da WIRED.

Ad aprile WIRED ha pubblicato la registrazione di una riunione riservata, tenuta a marzo, fra i responsabili dei servizi di emergenza di San Francisco e di Austin e la NHTSA, l’agenzia federale per la sicurezza stradale, che vigila anche sui veicoli autonomi. È la lista del 2017 che torna, formulata da chi ci lavora contro.

“We are actually seeing something interesting: backsliding of some things that had been improved upon.” — Mary Ellen Carroll, direttrice esecutiva del Department of Emergency Management di San Francisco

Carroll ha riferito ai regolatori che i veicoli commettono più infrazioni rispetto al passato. Il vicecomandante operativo dei vigili del fuoco di San Francisco, Patrick Rabbitt, ha riferito che “Waymo is frequently now blocking our fire stations from access” e che “their default is to freeze”. Ad Austin, il tenente William White, a capo della Highway Enforcement Command, ha spiegato che i veicoli spesso non riconoscono i segnali manuali degli agenti, contrariamente a quanto Waymo aveva assicurato ai soccorritori; in un servizio di NBC del novembre precedente aveva descritto il caso limite, un veicolo fermo a un incrocio con il verde mentre una moto della polizia, con lampeggianti e sirena, era in mezzo alla carreggiata. Ai regolatori ha poi aggiunto la frase che chiude il cerchio con Gassée:

“The moment you introduce the human element, the vehicles lack that social awareness of what to do, and they freeze.” — Lt. William White, Austin Police Department

Nove anni dopo, la domanda su come un’auto senza conducente interagisca con la polizia ha una risposta empirica: si ferma. I soccorritori devono avvicinarsi al finestrino del lato guida e usare l’audio di bordo per parlare con l’operatore remoto, perché gli altoparlanti esterni non sono configurati per le chiamate avviate da loro. Ad Austin, durante la risposta a una sparatoria che aveva provocato tre morti e almeno quattordici feriti, un veicolo ha bloccato per due minuti un’ambulanza: un agente ha dovuto scansionare il codice QR, disattivare la guida autonoma e spostare l’auto manualmente. Durante il blackout del 20 dicembre a San Francisco, che ha lasciato un terzo della città senza corrente e i semafori spenti per ore, la flotta si è fermata quasi milleseicento volte per due minuti o più e sessantaquattro veicoli hanno richiesto un recupero sul posto; la centrale del 911 ha chiamato Waymo trentuno volte e, in un caso, un operatore è rimasto in attesa per cinquantatré minuti.

Il 28 aprile il DMV californiano ha adottato nuove regole, in parte già in vigore e in parte con efficacia scaglionata nei mesi successivi: obbligo per le aziende di rispondere alle chiamate dei soccorritori entro 30 secondi; potere per le autorità locali di emergenza di dichiarare un’area temporaneamente vietata, in cui nessun veicolo autonomo può entrare; obbligo per il costruttore di far uscire da quell’area, entro 2 minuti dalla comunicazione, i veicoli che vi si trovano già.

Quelle regole riscrivono l’ambiente affinché il veicolo possa continuare a operare. È la città che si rende leggibile alla macchina e non l’inverso. Un’operazione legittima e forse sensata, che però va chiamata con il suo nome, perché la parola “autonomia” lascia immaginare l’opposto.

Il recinto, poi, è stato definito sulla base di condizioni precise: perimetri di poche decine o centinaia di miglia quadrate, un numero di veicoli che si conta in migliaia, aree ridisegnabili quando necessario. Dentro quel recinto, chi risponde alle emergenze riferisce un peggioramento e i dati dell’IIHS mostrano che il margine si assottiglia man mano che si considerano città con una viabilità più complessa. Le difficoltà del 2017 non sono state risolte e non sono state neppure del tutto recintate: se ne è ridotta la frequenza, operando dove capitavano meno.

Sugli ADAS non ho riserve

I sistemi di assistenza alla guida sono maturi, utili e li uso. Frenata automatica d’emergenza, mantenimento di corsia, cruise control adattivo: riducono il lavoro del guidatore e prevengono gli incidenti. La loro diffusione mi pare una delle cose migliori successe all’automobile negli ultimi vent’anni.

Quanto ambiente siamo disposti a riscrivere

La sequenza di date annunciate e mancate proseguirà, e continueremo a commentarla. Vale la pena però cambiare la domanda che ci portiamo dietro da dieci anni.

La riformulerei in termini di spazio e con due gradini invece di uno. Il primo: quanta parte del nostro ambiente saremmo disposti a riscrivere perché la guida senza conducente possa arrivarci, fra corsie, protocolli con i soccorritori, obblighi di risposta e aree interdette. Il secondo viene prima, e di solito lo si salta: là dove quel prezzo è già stato pagato, il servizio funziona? I responsabili dei soccorsi di San Francisco e di Austin rispondono di no o di non ancora.

A Phoenix, dove il conto torna meglio che altrove, la risposta è probabilmente sì. A San Francisco il margine si dimezza. In una città cresciuta per stratificazioni, dove il concetto stesso di incrocio è discutibile, il calcolo va rifatto da capo, e nessuno lo ha ancora fatto.

Nel 2017 chiudevo invocando un po’ di sana prudenza e una bella dose di saggio realismo. Rileggendomi, trovo che fossi ancora ottimista: davo per scontato che il tempo avrebbe sciolto i nodi e discutevo di quanto tempo sarebbe servito per completare il percorso. I nodi sono gli stessi. Sono stati aggirati in una manciata di città, con risultati che peggiorano man mano che la città somiglia meno a una griglia, e anche lì continuano a stringersi nei momenti sbagliati: quando arriva un’ambulanza, quando si spegne un semaforo, quando un agente fa un cenno con la mano.

Per approfondire

[1] Aarian Marshall, “Emergency First Responders Say Waymos Are Getting Worse”, WIRED, 29 aprile 2026. https://www.wired.com/story/emergency-first-responders-say-waymos-are-getting-worse/

[2] IIHS, “Waymo’s driverless cars crash less often than people”, 23 luglio 2026. https://www.iihs.org/news/detail/waymos-driverless-cars-crash-less-often-than-people

[3] California DMV, “New autonomous vehicle regulations strengthen oversight and enforcement, authorize trucks and transit”, comunicato del 28 aprile 2026. https://www.dmv.ca.gov/portal/news-and-media/new-autonomous-vehicle-regulations-strengthen-oversight-and-enforcement-authorize-trucks-and-transit/

[4] Lee Gomes, “Google’s Self-Driving Car Will Be Ready Soon for Some, in Decades for Others”, IEEE Spectrum, 18 marzo 2016. https://spectrum.ieee.org/google-selfdriving-car-will-be-ready-soon-for-some-in-decades-for-others

[5] Stanford HAI, Artificial Intelligence Index Report 2026, sezione “Self-Driving Cars”, 2026. https://hai.stanford.edu/ai-index/2026-ai-index-report

[6] Electrek, “Waymo expands robotaxi coverage more than 20% — larger than Rhode Island”, 13 maggio 2026. https://electrek.co/2026/05/13/waymo-expands-coverage-1400-square-miles-11-cities/

[7] Waymo, “From the road — July 8, 2026”, blog ufficiale, 8 luglio 2026. https://waymo.com/blog/shorts/ro-den-lv-sd-tmpa/

[8] Baidu, “Baidu Announces First Quarter 2026 Results”, investor relations, 18 maggio 2026. https://ir.baidu.com/news-releases/news-release-details/baidu-announces-first-quarter-2026-results

[9] Waymo, “Safe, Routine, Ready: Autonomous driving in five new cities”, 18 novembre 2025. https://waymo.com/blog/2025/11/safe-routine-ready-autonomous-driving-in-new-cities/

[10] CNBC, “Elon Musk says Tesla taking safety supervisors out of some Robotaxi vehicles in Austin”, 22 gennaio 2026. https://www.cnbc.com/2026/01/22/musk-says-tesla-takes-safety-supervisors-out-of-some-austin-robotaxis.html

[11] Rodney Brooks, “Edge Cases For Self Driving Cars”, rodneybrooks.com, 17 giugno 2017. https://rodneybrooks.com/edge-cases-for-self-driving-cars/

[12] Rodney Brooks, “Unexpected Consequences of Self Driving Cars”, rodneybrooks.com, 12 gennaio 2017. https://rodneybrooks.com/unexpected-consequences-of-self-driving-cars/

[13] Jean-Louis Gassée, “Autonomous Cars: The Level 5 Fallacy”, Monday Note, 2017. https://mondaynote.com/autonomous-cars-the-level-5-fallacy-247ae9614e14

[14] Alfonso Fuggetta, “Il mito della guida autonoma”, TechEconomy, 28 novembre 2017. https://www.techeconomy2030.it/2017/11/28/mito-della-guida-autonoma/

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

I modelli di GenAI sarebbero una commodity perché, in sistemi come Cursor, sono intercambiabili: posso decidere quali usare.

Se accettassi che i modelli di GenAI siano commodity perché Cursor mi permette di scegliere quello che voglio, allora dovrei anche dire che una concessionaria di auto di lusso che mi permette di scegliere tra diversi brand (Lamborghini, Ferrari, Aston Martin, Bentley, …) vende commodity: ovviamente quelle auto non sono commodity.

Si dirà: “No, quelli sono beni di lusso, costano tanto. Le commodity costano poco.” Lascio a Don Ameche e Ralph Bellamy, in Una poltrona per due, spiegare che l’oro è una commodity. I fratelli Duke sono “commodities brokers”.

Quindi il problema non è il costo, tema che avevo discusso nei miei post precedenti (qui e qui).

Si dirà, ma queste su AI come commodity sono affermazioni fatte sui social, non è quello che dice chi ne capisce. Beh, non è così. In un recente intervento presso Assolombarda, Luciano Floridi usa la stessa parola: “l’intelligenza artificiale sta diventando anche una commodity, come si dice, costa sempre meno ed è sempre più diffusa […] il giorno in cui le AI saranno letteralmente come l’elettricità, la differenza non sarà chi sarà a gestirla, ma che cosa ci faremo, come, quando, con quale regolamentazione”.

Ma nello stesso passaggio aggiunge che “il vero divario sarà chi avrà la qualità dei dati migliori, chi avrà le competenze umane migliori, chi avrà la regolamentazione migliore”. Ed è qui la contraddizione: se l’AI fosse davvero una commodity, le competenze umane non sarebbero il discrimine. Una commodity si usa senza doverla saper gestire. Floridi la chiama commodity e, nella stessa frase, ammette ciò che nessuna commodity richiede.

Nota: la trascrizione di Assolombarda nel post su Linkedin contiene un errore. Floridi non dice “chi saprà gestirla o meno”, ma “chi sarà a gestirla o meno”.

Ho provato a spiegarlo nei miei due post. Ma non fidatevi di me e leggete questo articolo sulla home page del Wall Street Journal.

I manager americani sono stanchi di spendere soldi in modelli ipercostosi e si sono accorti che, per molti compiti, bastano modelli più semplici. Lo dice Mike Saeks, field CTO proprio di Cursor:

The most powerful and expensive AI models aren’t necessary for relatively mundane tasks.

“It’s like driving a Lamborghini to go to the grocery store to pick up milk when that was designed to be raced around a track”.

Ma quindi sono diversi! Il sito di Cursor consente di scegliere i modelli in base a diverse proprietà: “cost, intelligence, and balance”. Del resto lo dice il prodotto stesso: un router che “sceglie il modello giusto per ogni compito” presuppone che i modelli siano diversi. Per l’energia elettrica nessuno sente il bisogno di usarne uno.

Non solo: come dicevo nel post precedente, ogni modello, oltre a essere più o meno potente, ha un addestramento che lo rende più o meno adatto a svolgere specifiche attività. Inoltre è condizionato in modo diverso. Vi fidate di una valutazione d'investimento affidata a Grok, che ha mostrato di avere bias chiari in ambito geopolitico?

Dire che un bene è una commodity ha un impatto enorme sulle scelte manageriali e politiche. Se l’AI è una commodity, se basta usarla come l’elettricità, perché guardare alla sua qualità e alle sue caratteristiche? Basta prendere quella più economica. Costano meno Grok, che fa certe affermazioni sul genocidio dei bianchi in Sudafrica, o i modelli cinesi basati sui “core socialist values”? Non importa, prendiamo quelli. Una commodity si compra, si monta e si usa, qual è il problema? Se è gestita negli USA, che dalla mattina alla sera possono decidere di chiudere l’accesso ad un modello, si passa a quelli cinesi… o no?

Trattarla come una commodity è una decisione strategica travestita da constatazione tecnica. No, l'AI non è una commodity, né i modelli lo sono. Prima lo capiamo, meno errori faremo.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Il 18 luglio scorso, Alex Imas (economista comportamentale della University of Chicago Booth, dallo scorso maggio Director of AGI Economics a Google DeepMind) ha scritto su X una tesi che merita di essere discussa [1]:

AGI will very likely be a commodity. This is not a value judgement, it’s just the outcome of an economically-valuable product + competitive markets. Implicitly people see this coming and are leaning into it, hence the big push from all the labs to go vertical.

A few things can prevent this: 1) regulation or 2) a moat, so it’s definitely not a certainty. But absent that, this is where things are going.

Nel thread la tesi è stata contestata subito. David Rein (@idavidrein) — il ricercatore che ha creato il benchmark GPQA, uno di quelli che cito più avanti per mostrare che nessun modello vince ovunque — ha risposto con l’obiezione di merito più netta: “Commodities form when you can’t innovate anymore, and it seems very unlikely we’ll hit capability ceilings anytime soon, so I’d bet against this” [2]. Imas ha ribattuto che i due modelli di testa già oggi competono sul prezzo e che le imprese passano di continuo dall’uno all’altro. E, in coda, tagliente, Pedro Tremacoldi-Rossi — financial economist presso Cornerstone Research, che studia i mercati delle commodity — ha liquidato la definizione: “very strange notion of commodity” [3].

La settimana scorsa ho argomentato che chiamare l’AI commodity è una categoria sbagliata: i grandi modelli linguistici non soddisfano nessuna delle proprietà economiche del bene commodity: fungibilità, prezzo per unità di valore, basso costo di migrazione, stabilità nel tempo, basse barriere d’uso. Il post di Imas e l’obiezione di Tremacoldi-Rossi mi hanno portato a chiedermi se, alla luce di ciò che i dati mostrano oggi sul mercato dei modelli di base, quella conclusione regga.

Una prima reazione all’affermazione di Imas potrebbe consistere nelle sue stesse parole: è più una previsione di ciò che potrebbe accadere che una presa d’atto di un fatto acclarato. Ma sarebbe un artificio retorico per evitare il problema, che invece va affrontato direttamente, ripercorrendo le caratteristiche chiave del concetto di commodity.

La fungibilità: quale intercambiabilità

Uno studio del Digital Economy Lab di Stanford, pubblicato a marzo e firmato da Elisa Pereira, Alvin Wang Graylin ed Erik Brynjolfsson, tra gli economisti più autorevoli sulla produttività dell’IT, analizza 51 casi di successo di adozione aziendale in 41 organizzazioni. Uno dei risultati principali, riportato senza mezzi termini [4]: “For 42% of implementations, model choice was fully interchangeable.” Cioè, in quasi la metà dei casi reali che hanno generato valore misurabile, la scelta del modello di base era irrilevante. Il dato è scomodo per il mio argomento della settimana scorsa. Va affrontato, non eluso.

La domanda giusta è: che tipo di intercambiabilità stanno documentando? Ci sono due letture possibili. Una, la lettura forte dell’indifferenziazione, sostiene che i modelli si sono equivalsi qualitativamente. L’altra dice che i casi d’uso documentati erano sotto una soglia di capacità così bassa da poter essere risolti da qualunque modello di frontiera. Sono ovviamente casistiche molto diverse tra loro.

I dati dei test di valutazione sembrano orientarsi verso la seconda situazione. A luglio 2026 nessun modello vince ovunque: Claude Fable 5 guida sulla scrittura di codice di frontiera (SWE-bench Verified attorno al 95%), Gemini 3.1 Pro guida sulle prove di ragionamento scientifico e astratto (GPQA Diamond, ARC-AGI-2), GPT-5.4 guida nell’uso autonomo del computer (OSWorld-Verified 75,0%, sopra il livello umano di riferimento) [5]. I profili prestazionali restano distinti quando il compito diventa difficile. La fungibilità che Stanford osserva è sufficienza, non identità: per i casi d’uso sotto soglia qualunque modello di frontiera basta — ma “bastare” non è “essere lo stesso bene”. E infatti la fungibilità non regge nemmeno dove sembra reggere. Due modelli non sono lo stesso bene: anche quando su un compito neutro l’esito è ugualmente valido, non producono la stessa risposta, e l’equivalenza svanisce del tutto non appena il compito tocca qualcosa che i loro addestramenti trattano in modo diverso.

Una commodity è neutra rispetto al produttore — la specifica cancella chi l’ha fatta: 220 volt sono 220 volt, il barile Brent è Brent da qualunque pozzo arrivi. Un modello non è mai neutro rispetto a chi l’ha addestrato: dati, allineamento e filtri incorporano scelte di valore che restano in ogni risposta. The Economist lo mostra con il caso più clamoroso: i modelli cinesi open-weight, scaricabili e installabili sui propri server, sono offerti al mondo come “shared asset for all humanity”, ma sono tenuti a rispettare i “core socialist values”. Come riporta la testata, una bambola AI esportata dalla Cina, interrogata sullo status di Taiwan, risponde che l’isola “is an inalienable part of China” e che ciò “cannot be refuted” [6]. La differenziazione non è un divario temporaneo che la concorrenza cancella — l’assunto di Imas — è impressa nel bene alla fabbricazione.

E non è solo la Cina: cambia il valore che gli viene attribuito, non il fatto che ci sia. Grok, il modello di Elon Musk, la dipendenza dal proprietario l’ha messa a verbale — nel maggio 2025 ha cominciato a infilare la teoria del “white genocide” sudafricano in risposte che non c’entravano (xAI l’ha attribuito a una modifica “non autorizzata” del system prompt, poi resa pubblica); a luglio, istruito a non evitare il “politicamente scorretto”, è arrivato a definirsi “MechaHitler” [7]. All’estremo opposto Anthropic pubblica la “costituzione” con cui allinea Claude, e gli studi comparativi misurano orientamenti diversi da un modello all’altro — Grok il più oscillante, Claude il più centrista, i modelli OpenAI più a sinistra [8]. Meta ha scelto l’open-weight: rilasciare i pesi è già, di per sé, un atto strategico e di valore. Mistral porta un’impronta ancora diversa: quella regolatoria europea, GDPR-native e vincolata dall’AI Act [9]. La domanda non è se un modello sia neutro — non lo è nessuno — ma di chi siano i valori che porta dentro e se li dichiara. La corrente elettrica non ha un “di chi”.

E vale perfino all'interno di un solo fornitore: le versioni successive dello stesso modello non sono intercambiabili, e il loro comportamento dipende da due strati — come sono addestrate e come le istruisci — un comportamento che non è quello di una commodity: risponde con toni e atteggiamenti diversi, come ho sperimentato passando da Sonnet a Opus 4.7 e Opus 4.8.

Si obietterà che anche le commodity hanno qualità diverse: il greggio sweet e sour, i diversi livelli di ottani. Ma le qualità di una commodity sono trasparenti, definite e prezzate: compri “Brent” e sai esattamente che cosa ti arriva, chiunque l’abbia estratto. Il condizionamento di un modello è opaco, non dichiarato e deliberato: il produttore non converge verso uno standard comune, ma imprime i propri valori di proposito. In una commodity le differenze tendono a sparire, a convergere verso uno standard comune; in un modello AI sono volute: ogni produttore vi imprime scelte proprie che lo qualificano rispetto agli altri. È il contrario esatto della commoditizzazione.

La fungibilità è solo la prima delle cinque proprietà (il prezzo non misura il valore, il costo di migrazione è elevato, la stabilità non c’è, la barriera d’uso è alta, come mostrano i prossimi paragrafi), ma è quella che cade più a fondo: il modello la manca alla radice, non per una differenza di grado.

Standardizzazione e prezzo: il costo che non è prezzo

La caduta dei prezzi dei token (le unità con cui si misura ciò che entra ed esce da un modello) è ormai un dato di fatto. Da quando GPT-4 è uscito nel marzo 2023 a 30 dollari per milione di token in ingresso, il prezzo dei modelli di frontiera è sceso di oltre il 90%. Oggi il successore di punta di quella linea è intorno ai 2 dollari, mentre le versioni più leggere della stessa famiglia sono sotto 1 dollaro. Il segnale sembra quello di un mercato delle commodity in tendenza verso l’equilibrio, in cui il prezzo scende fino al costo marginale e nessuno cattura margine.

I numeri di chi produce i modelli raccontano un’altra storia. OpenAI proietta una perdita di 14 miliardi di dollari per il 2026, senza redditività prevista prima del 2029–2030 [10]. Anthropic ha visto il margine lordo passare dal -94% nel 2024 a circa il 60% nel 2026, ma il salto è dovuto a un’esecuzione dei modelli più efficiente, non al rialzo dei prezzi [11]. E c’è uno schema, documentato dagli analisti, che spiega una parte dell’anomalia: il capital recycling. Amazon ha investito fino a 25 miliardi di dollari in Anthropic; Anthropic si è impegnata a spendere oltre 100 miliardi di dollari per il calcolo su AWS. OpenAI, dal canto suo, ha firmato con la stessa AWS un impegno d’acquisto di calcolo per 38 miliardi. E Microsoft, che possiede il 27% di OpenAI, ha contabilizzato nel solo trimestre 3,1 miliardi di dollari come propria quota del rosso di OpenAI (un passivo che, riproporzionato, implica una perdita trimestrale di OpenAI di circa 11,5 miliardi) mentre riconosce ricavi da Azure dallo stesso cliente che quella spesa genera [12].

Il prezzo che scende in queste condizioni non è il prezzo di equilibrio in un mercato competitivo come ipotizza Imas. È un prezzo determinato con lo scopo di conquistare quote di mercato, una strategia che prosegue finché il capitale regge. E soprattutto: il costo misurato per token non fornisce alcuna unità condivisa di misura del valore. Mille token possono produrre una risposta inutile o una decisione operativa da migliaia di euro. Il costo si misura, il valore no. La seconda proprietà della commodity, il prezzo per unità di valore, non è nemmeno definibile.

Il costo di migrazione: il moat che si costruisce

Nella terminologia della strategia aziendale, moat (“fossato”) è la barriera strutturale che protegge un business dai concorrenti: costi di ingresso elevati, effetti di rete, brevetti, marchi. È la parola che Imas usa nel tweet: la sua previsione sulle commodity vale solo se non emerge un moat. Il mercato dei modelli di base ne ha almeno uno sulle barriere all’ingresso e, a maggio 2026, i lab hanno iniziato a costruirne un secondo sull’adozione.

Un rapporto RAND del 2024, applicato empiricamente al mercato dei modelli di base, conclude che “il caso attuale per un monopolio naturale è relativamente forte”: modelli omogenei, economie di scala elevate, costi in gran parte nascosti ed effetti di rete pronunciati [13]. Il costo di addestramento di GPT-4 è stimato tra 63 e 100 milioni di dollari in termini di potenza di calcolo e, secondo le proiezioni di Epoch AI, addestrare un modello di punta supererà il miliardo entro il 2027. È una soglia che esclude ogni attore al di fuori di un ristretto cerchio di grandi operatori del cloud e dei loro partner. È il primo moat: la struttura di mercato è oligopolistica a causa dei costi di ingresso.

E qui si vede la seconda mossa, quella che Imas descrive parzialmente e che si è chiarita solo a maggio. All’inizio di maggio 2026, a pochi giorni l’uno dall’altro, i due lab principali hanno annunciato iniziative dedicate all’adozione presso i clienti per un nuovo capitale di 5,5 miliardi di dollari. Anthropic ha lanciato una joint venture con Blackstone, Goldman Sachs e Hellman & Friedman (per un valore di 1,5 miliardi, secondo la stampa finanziaria) per integrare Claude nelle operazioni delle società partecipate dai fondi coinvolti. OpenAI ha annunciato The Deployment Company (4 miliardi da 19 tra investitori, società di consulenza e integratori di sistemi, con una valutazione di 10 miliardi prima dell’investimento) e ha acquisito Tomoro per portare a bordo, dal primo giorno, 150 ingegneri distaccati presso il cliente, i “forward deployed engineers” [14]. Il modello ricalca da vicino quello di Palantir: l’ingegnere va dal cliente, ne impara il flusso di lavoro, scrive software che avvolge il modello attorno al problema, e resta finché il sistema funziona in modo stabile.

La logica che giustifica l’operazione è quella classica del mercato aziendale: attorno a ogni euro di licenza software ruota una spesa per servizi di integrazione molto più elevata. È esattamente la fetta di valore che il piano di adozione (coordinamento dei sistemi, dati proprietari, integrazione nei processi, competenze) rappresenta. La proprietà del basso costo di migrazione sta cambiando. I lab stanno impostando costi di migrazione elevati nel piano di adozione, con una soluzione che, una volta installata, è su misura per il flusso di lavoro del cliente, integrata con i suoi dati e appresa dai suoi ingegneri interni. Cambiare fornitore significa interrompere un rapporto operativo di mesi con persone insediate nel proprio processo.

Stabilità nel tempo, barriera d’uso

Le altre due proprietà si commentano brevemente. Sui modelli usati in azienda, il ritmo di aggiornamento resta di tre-sei mesi e ogni nuova versione vanifica test consolidati e riapre le valutazioni. Il declino dei prezzi accelera invece di rallentare: a parità di prestazioni, il costo per ottenerle si riduce ogni anno di un fattore compreso tra 9 e 900 volte, a seconda del compito, secondo lo Stanford AI Index. Il mercato stesso è in trasformazione strutturale ogni pochi mesi, come mostra la mossa sull’adozione di maggio. Le commodity vere non fanno questo. Il rame del 1980 è il rame del 2026 e non sviluppa un modo di parlarti. Lo tocco con mano da utente: la versione di Claude che uso oggi non risponde come quella di qualche mese fa e, discutendo proprio di questo pezzo, mi ha contraddetto dove le precedenti avrebbero assecondato. Il modello di tre versioni fa non è quello di adesso.

Sulla barriera d’uso, la conferma arriva dalla stessa fonte che sembrava metterla in difficoltà. Lo studio di Stanford dice che il 77% delle sfide più difficili nelle adozioni riguarda costi invisibili, non tecnici: gestione del cambiamento, qualità dei dati, ridisegno dei processi. Brynjolfsson lo scrive esplicitamente: “the durable advantage is in the orchestration layer, not the foundation model.” E dal fronte opposto — un venture capitalist che ha investito miliardi nell'AI, non un economista accademico — Marc Andreessen arriva alla stessa conclusione: il moat è ciò che costruisci attorno al modello, non il modello stesso [15]. Il consenso trasversale è ormai netto: la barriera d’uso è alta e sta crescendo.

Non è la prima volta

Questa confusione ha una storia, e la parola commodity torna sempre allo stesso modo. Nel maggio 2003 Nicholas Carr pubblicò su Harvard Business Review “IT Doesn’t Matter”: l’informatica aziendale, sosteneva, ha “all the hallmarks of an infrastructural technology” ed è perciò destinata a una “particularly rapid commoditization”. La conclusione: non offre un vantaggio competitivo, è solo un costo da comprimere — meglio esternalizzare, seguire invece di guidare, rimandare gli investimenti. Presa alla lettera, quella tesi produsse un decennio di scelte sbagliate.

L’errore non era dire che qualcosa si fosse commoditizzato. Alcune cose lo sono davvero: i PC, la potenza di calcolo a consumo, alcuni servizi cloud. L’errore era il salto di strato — trattare l’intero campo come se fosse definito dallo strato dell’infrastruttura. Una commodity ha, per definizione, un basso o nullo rischio di adozione: la compri, la monti, la usi. Se l’IT lo fosse stato davvero, perché i progetti di adozione fallivano con la regolarità che Carr stesso documentava? È l’argomento che porto avanti da vent’anni: le tante delusioni sono la prova che l’IT, salvo i suoi componenti di base, non è mai stato una commodity. Con l’AI la scena torna identica, di nuovo con un salto di strato: si guarda il prezzo per token, che crolla, e si dichiara commodity l’intero campo, quando è il piano di adozione a decidere il valore — ed è quanto di più lontano da una commodity ci sia.

E stavolta il coro non è quello di un solo economista. Accanto a Brynjolfsson e Andreessen, citati sopra, negli ultimi mesi si sono aggiunte altre voci, da parte di chi non ha alcun interesse a negare la potenza dell’AI. McKinsey, in uno studio di luglio [16], è netta: “AI does not create enterprise value simply because more people use it. Individual productivity gains matter, but they rarely translate into lasting advantage when the organization around them stays the same.” In un secondo lavoro [17] concede che “capabilities that differentiate one platform today often become standard within months”, e proprio da lì conclude che “most AI value comes from people and process transformation, not algorithms, technology, or data infrastructure.” È lo stesso punto della fungibilità: anche concedendo che i modelli si equivalgono, la categoria non si sposta, perché il valore sta altrove. E chi guarda il problema dal lato di chi deve realizzarlo arriva alla stessa diagnosi [18]: “The gap isn’t the technology. It’s the foundational work most organizations haven’t done: data readiness, operating models, governance, skills, and culture. […] They’re tackling the unglamorous work themselves.”

Tre voci diverse, una conclusione sola: il valore sta nel piano di adozione, ed è un processo complesso e ad alto tasso di fallimento — non un interruttore. È il rovescio di una commodity. Di una commodity puoi fidarti: il litro di benzina fa sempre la stessa cosa e, se la tua flotta fallisce, non è colpa della benzina ma del tuo piano. Di un modello no: il bene non è neutro e non ti dà lo stesso risultato ogni volta — parte del rischio è nel bene stesso. Perfino l’inefficienza spinge nella stessa direzione. Un’analisi di Atlantic [19] nota che i modelli generativi scalano al rovescio rispetto a ogni altro software, “the bigger an AI model is, the less it improves with each added parameter”, così che il prezzo che scende non segnala un bene che matura, ma capitale che ne copre uno che perde.

La questione strategica

Se i cinque piani della definizione di commodity non si applicano, e i dati di mercato lo confermano, la domanda diventa: cosa c’è dietro l’insistenza con cui la parola torna? La risposta sta nella mossa delle imprese del settore.

L’insistenza nel presentare il modello come commodity copre uno spostamento strategico da parte dei venditori verso il piano di adozione. Il modello base, come servizio venduto al minuto, è la parte che i lab hanno smesso di considerare strategica. Il valore che stanno costruendo lo mettono altrove: nella verticalizzazione (il passaggio dal modello generale a soluzioni su misura, calate sul cliente e sul suo settore), attraverso ingegneri distaccati presso il cliente, nell’integrazione su misura nei processi del cliente, nella cattura della spesa per i servizi che circondano ogni licenza software. La spinta a “verticalizzare” che Imas osserva è la strategia con cui i lab entrano nel mercato dell’adozione, cioè nel piano che, nel post della settimana scorsa, indicavo come quello in cui il valore per l’azienda si costruisce internamente.

Il consiglio d’amministrazione che sente “AI is a commodity” e ne trae la conclusione manageriale familiare: tagliare il budget di formazione, esternalizzare le competenze per l’uso e l’istruzione dei modelli, scegliere il fornitore in base al prezzo per token. Così facendo, sta regalando due cose contemporaneamente: rinuncia a costruire capacità sul piano su cui si concentra il valore e consegna quel piano nelle mani di chi ha appena costruito 5,5 miliardi di dollari di infrastruttura per prenderlo. È l’errore della consulenza SAP/Oracle degli anni Duemila, con una differenza: il vincolo di secondo livello che si crea con un ingegnere distaccato e insediato nel processo aziendale è più profondo di quello che si creava con un consulente SAP, e si stringe in mesi invece che in anni.

E qui entra la terza forza che Imas non menziona. Accanto ai modelli proprietari — quelli che usi solo attraverso il fornitore — sono arrivati i modelli open source, che chiunque può scaricare ed eseguire per conto proprio, oggi in media quattro mesi più tardi rispetto ai migliori proprietari [20]. Con loro la soglia di accesso al modello si azzera quasi: niente licenza, niente fornitore. Ma l'accessibilità non definisce una commodity. Non è che prendi un modello, lo colleghi e lo usi come la corrente: sotto quella soglia di adozione bassissima c’è tutto il lavoro di prima: metterlo in produzione, valutarlo, integrarlo nei processi, adattarlo ai tuoi dati. La barriera che il fornitore ti nascondeva non sparisce, si sposta intera sull’adozione. È il profilo rovesciato di una commodity: un prodotto sempre più accessibile che richiede investimenti crescenti di competenza e di adozione. I modelli open source spingono l’accesso verso il basso senza mai toccare la categoria; anzi, sono la prova più chiara che il valore non sta nel modello, ma in ciò che l’azienda ci costruisce attorno.

Qualche conclusione

La parola commodity cade su tutte le proprietà che la definiscono: il prezzo non misura il valore, il costo di migrazione sale invece di essere basso, la stabilità non c’è, la barriera d’uso è alta. Perfino la fungibilità, l’unico appiglio della tesi contraria, si ferma ai casi d’uso più semplici — la coppia modello-uso, non il modello — e non tocca il bene, che porta impressa l’origine di chi l’ha addestrato. Il prezzo che scende, l’unico segnale che sembra dire il contrario, non è la prova di un mercato-commodity: è capitale sussidiato in un oligopolio, non un equilibrio competitivo. Chi la porta in consiglio d’amministrazione come argomento per non investire in adozione fa un salto di categoria che vent’anni fa costò caro: è lo stesso errore di Carr, che spinse molte aziende a esternalizzare l’IT dopo “IT Doesn’t Matter” [21], e le lasciò, dieci anni dopo, con dipartimenti ridotti a comprare licenze e la strategia digitale in mano al system integrator di turno. La differenza è che oggi chi vende il modello offre anche l’adozione, con ingegneri che si siedono ai tuoi tavoli, imparano i tuoi processi, scrivono il software e lo controllano per te.

Se decidi che l’AI è commodity, in consiglio, hai preso in dieci secondi due decisioni: non costruisci capacità interna e la compri da chi vende il modello. Nel decennio, si vedrà chi ha scelto bene.

Per approfondire

[1] Alex Imas (@alexolegimas), tweet del 18 luglio 2026, x.com/alexolegimas/status/2078529740281970689. Imas è professore alla University of Chicago Booth School of Business (in aspettativa) e, dal maggio 2026, Director of AGI Economics a Google DeepMind. Il “big push from all the labs to go vertical” è nelle parole di Imas; la lettura di quella “verticalizzazione” come strategia di adozione — ingegneri distaccati presso il cliente, modello Palantir — è sviluppata in questo pezzo, non una definizione data da Imas.

[2] David Rein (@idavidrein), interventi nel thread sotto il tweet di Alex Imas, 19 luglio 2026. Rein fa ricerca su valutazione e controllo dei sistemi di AI (METR) ed è il primo autore del benchmark GPQA (D. Rein et al., “GPQA: A Graduate-Level Google-Proof Q&A Benchmark”, 2023).

[3] Pedro Tremacoldi-Rossi (@pedrotrossi1), intervento nella discussione sotto il tweet di Alex Imas, 19 luglio 2026, x.com/pedrotrossi1/status/2078633442795802712. Tremacoldi-Rossi è financial economist a Cornerstone Research ed è postdoctoral research scholar al Department of Economics della Columbia University, dove insegna. Ha conseguito il PhD alla University of Illinois at Urbana-Champaign, dove ha tenuto il corso Commodity Futures and Options ed è affiliato all’Office for Futures and Options Research; la sua ricerca riguarda i mercati finanziari e la loro microstruttura.

[4] Elisa Pereira, Alvin Wang Graylin, Erik Brynjolfsson, The Enterprise AI Playbook — Lessons from 51 Successful Deployments, Stanford Digital Economy Lab, marzo 2026, digitaleconomy.stanford.edu/publication/enterprise-ai-playbook.

[5] Dati dei test di luglio 2026 da Artificial Analysis e da vals.ai per SWE-bench Verified; le cifre sull’uso autonomo del computer di GPT-5.4 (OSWorld-Verified 75,0%) sono dalla pagina ufficiale OpenAI. Le classifiche di frontiera cambiano rapidamente e i numeri esatti variano tra aggregatori: qui si riportano le posizioni di leadership per famiglia di compiti, non una classifica puntuale.

[6] “When China’s open-source AI is a trap”, The Economist, sezione International (The Telegram), 14 luglio 2026 (edizione a stampa del 18 luglio 2026), economist.com. L’esempio della bambola Miiloo è attribuito dalla testata a “American researchers” non nominati.

[7] Su Grok e la sua dipendenza dal system prompt: “Grok started calling itself ‘MechaHitler’”, NPR, 9 luglio 2025, npr.org; “Users accuse Grok of a rightward tilt after xAI changed its internal instructions”, Fortune, 8 luglio 2025, fortune.com; l’episodio “white genocide” (maggio 2025) è ricostruito da PBS News, pbs.org.

[8] Sugli orientamenti politici misurati nei modelli: “Popular AI Models Show Partisan Bias When Asked to Talk Politics”, Stanford Graduate School of Business, 2025, gsb.stanford.edu; “Evaluating political bias in LLMs”, Promptfoo, 2025, promptfoo.dev. Anthropic ha pubblicato la propria ricerca sull’even-handedness politica nel novembre 2025.

[9] Mistral AI: posizionamento europeo “sovrano”, GDPR-native e conformità all’AI Act (obblighi per i modelli GPAI dal 2 agosto 2026), da materiali legali Mistral, legal.mistral.ai, e analisi di settore 2026.

[10] Le proiezioni finanziarie interne di OpenAI — perdita di circa 14 miliardi di dollari nel 2026 e ritorno all’utile non prima del 2029–2030 — sono state anticipate da The Information sulla base di documenti interni e riprese dalla stampa finanziaria: Fortune, “OpenAI says it plans to report stunning annual losses through 2028—and then turn wildly profitable just two years later”, 12 novembre 2025, fortune.com.

[11] Stime SemiAnalysis sui margini di Anthropic (margine lordo dal -94% nel 2024 a circa il 60% nel 2026, trainato dall’efficienza di inferenza), riprese da BigGo Finance, “On the Eve of Trillion-Dollar Valuations: Anthropic Turns Profitable First”, luglio 2026. Sono stime di analisti, non dati ufficiali certificati.

[12] Cifre di capital recycling da fonti primarie e stampa finanziaria: l’investimento Amazon in Anthropic (fino a 25 mld, aprile 2026) e l’impegno Anthropic di spesa di calcolo su AWS (oltre 100 mld) da CNBC e TechCrunch; l’impegno d’acquisto OpenAI–AWS da 38 mld dal comunicato Amazon (novembre 2025); i conti Microsoft Q1 FY26 (ottobre 2025) registrano 3,1 mld come quota del 27% di OpenAI, che implica un passivo trimestrale di OpenAI di circa 11,5 mld, da The Register.

[13] Jon Schmid, Tobias Sytsma, Anton Shenk, Evaluating Natural Monopoly Conditions in the AI Foundation Model Market, RAND Corporation, RR-A3415-1, settembre 2024, rand.org/pubs/research_reports/RRA3415-1. Il rapporto valuta il mercato “as of January 2024” e conclude che il caso per un monopolio naturale è “relatively strong”.

[14] Comunicati ufficiali Anthropic (la nuova società di servizi enterprise con Blackstone, Hellman & Friedman e Goldman Sachs, 4 maggio 2026) e OpenAI (il lancio di The Deployment Company, con l’acquisizione di Tomoro e i 150 ingegneri distaccati presso il cliente). Le cifre finanziarie sono da stampa primaria: 1,5 mld della joint venture Anthropic da CNBC e Fortune (non riportati nel comunicato Anthropic); 4 mld di nuovo capitale e valutazione di 10 mld prima dell’investimento di The Deployment Company da OpenAI e Bloomberg.

[15] La posizione è ripresa e parafrasata in: The AI Corner, “The AI moat is not the model. Marc Andreessen on why AI gets more expensive as it commoditizes”, 18 maggio 2026, che la attribuisce a un intervento di Andreessen a un meeting LP di a16z (gennaio 2026). Trattandosi di un evento privato senza trascrizione a verbale, la frase è resa come parafrasi e non come citazione testuale.

[16] McKinsey & Company, “From Adoption to Impact: Three Horizons of AI Transformation”, 8 luglio 2026, mckinsey.com.

[17] “The Operating Model Advantage: Why AI Winners Are Rewiring Their Organizations”, McKinsey & Company, 7 luglio 2026, mckinsey.com.

[18] Stephanie Overby, “CIOs Must Rethink Operating Models to Unlock AI at Scale”, CIO, 13 luglio 2026, cio.com.

[19] Alex Reisner, “Generative AI Is an Engineering Disaster”, The Atlantic, 14 luglio 2026, theatlantic.com.

[20] Jack Edwards, Luke Emberson, “Open models lag state-of-the-art closed models by 4 months”, Epoch AI, 29 maggio 2026, epoch.ai/data-insights/open-closed-eci-gap. Il gap medio è di quattro mesi (8 punti ECI) nel periodo gennaio–maggio 2026, in leggero aumento rispetto ai tre mesi del periodo gennaio 2023–ottobre 2025.

[21] Nicholas Carr, “IT Doesn’t Matter”, Harvard Business Review, maggio 2003, hbr.org/2003/05/it-doesnt-matter.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Il disco è dal vivo, registrato in un piccolo cocktail bar di Los Angeles: quattro brani lunghi, coinvolgenti.

Da ascoltare, ne vale la pena.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Il post in tre frasi

1. La retorica “AI is a commodity” del 2026 ripete l’errore di “IT Doesn’t Matter” (Nicholas Carr, 2003): entrambe ignorano la definizione economica di commodity e portano alle stesse scelte manageriali sbagliate: outsourcing, gare al ribasso, impoverimento delle competenze e il loro allontanamento dai tavoli decisionali.

2. Applicando i parametri economici della definizione di commodity (fungibilità, standardizzazione, prezzo di mercato, basso switching cost, stabilità nel tempo, bassa barriera d’uso), l’AI non soddisfa alcuno di essi. E non si tratta di una fase transitoria: è la natura della tecnologia.

3. Trattare l’AI come una commodity non è un problema terminologico, ma un errore strategico: chi lo fa pagherà due volte, in valore non estratto e in vantaggio competitivo ceduto a chi ha imparato a usarla.

Chi lavora nella tecnologia da un po’ di tempo riconosce il ritornello. Cambia la sigla, ma resta la formula. Nel 2003 era “IT Doesn’t Matter” [1]: l’informatica è diventata un’infrastruttura, quindi commodity, quindi irrilevante per la strategia. Nel 2026 è “AI is a commodity”: i modelli sono accessibili via API, i prezzi per token scendono, i grandi provider offrono capacità simili; quindi l’intelligenza artificiale è diventata una commodity e si compra come la corrente elettrica.

Alcuni usano “commodity” in senso metaforico: intendono dire che l’AI sarà accessibile a tutti, come l’elettricità. È una tesi comprensibile. Ma il problema è che la parola “commodity” non è neutrale: se importata in un contesto aziendale, porta con sé una teoria economica. E la teoria economica del bene determina le strategie. Come dice Nanni Moretti, “Le parole sono importanti!”, soprattutto quando si parla di temi così delicati.

Cos’è una commodity

Il Dizionario di Economia e Finanza della Treccani definisce “commodity” come “ogni tipo di merce o materia prima tangibile e fruibile sul mercato, facilmente immagazzinabile e conservabile nel tempo” [2]. Gli esempi sono canonici: petrolio, oro, gas, cereali, caffè, bestiame. L’etimologia è illuminante: dal francese commodité, “ottenibile comodamente”.

Attorno a questa nozione la teoria economica ha costruito alcuni test operativi. Una commodity ha una serie di caratteristiche:

• fungibile, cioè intercambiabile fra produttori senza differenze qualitative;

• standardizzata e prezzata dal mercato, con unità di misura condivise (dollari al barile, dollari per once di oro puro al 99,5%…);

• a basso costo di sostituzione tra fornitori;

• stabile nel tempo, senza modifiche significative nel comportamento del bene;

• a bassa barriera d’uso, nel senso che l’acquirente non deve imparare a usarla, ma solo a impiegarla nel proprio processo produttivo.

Applichiamo questi test all’AI, una proprietà alla volta.

Fungibilità: Sonnet non è Fable

La prima proprietà di una commodity è che l’acquirente sia indifferente nei confronti del produttore. Un kilowattora è un kilowattora: non cambia le sue caratteristiche in base a chi lo produce.

Sonnet non è Fable. GPT-5 non è Claude Opus. Gemini non è Llama. A parità di prompt, gli output differiscono per tono, struttura, precisione, rischio di errore, gestione dell’incertezza e capacità di seguire istruzioni complesse. Non parlo di sfumature estetiche: parlo di differenze che, in un flusso applicativo reale, si traducono in tassi di successo, retention degli utenti ed escalation al supporto umano.

Inoltre, sotto il titolo “GenAI” si celano molteplici tipologie di prodotto, ciascuna adatta a specifiche attività professionali o aziendali. Ho chiesto a Claude di generare due infografiche per mappare il panorama delle tecnologie e dei prodotti nel mondo della GenAI. Probabilmente ci sono errori e imprecisioni (GenAI è fallibile e opera in modo probabilistico!). Ma qui serve cogliere la complessità e la ricchezza di questo mondo. Sono aspetti che nessuna adozione seria può ignorare. A meno di non farne un uso semplificato ed estemporaneo.

Chiunque abbia messo in produzione una funzionalità basata su un LLM sa che cambiare modello non equivale a sostituire un fornitore di corrente. Vuol dire rivalutare l’insieme degli strumenti adottati, rifare i test, rivedere i prompt, ricalibrare i valutatori e riscrivere parti dell’orchestrazione. Inoltre, un modello non è indipendente da chi lo ha creato e addestrato, a differenza di un kilowattora prodotto da diverse centrali. Un modello è il risultato di scelte di training, di dati e di alignment: differenze qualitative che nessuna standardizzazione elimina.

Prezzo, costi, unità di misura del valore

Una commodity ha un prezzo pubblico, quotato in un’unità di misura condivisa che rappresenta il valore economico del bene. Dollari al barile, dollari all’oncia, euro al megawattora. La quotazione è trasparente perché la sostanza sottostante è omogenea.

L’AI non ha nulla di tutto questo. Il token è un’unità di consumo tecnico, non un’unità di valore. Lo stesso numero di token può generare una risposta banale che nessuno userà, oppure una decisione operativa che vale migliaia di euro. Non c’è alcuna relazione stabile tra l’input consumato e il valore restituito. Mille token consumati producono, a seconda del caso, un risultato inutile, un risultato eccellente o un’allucinazione. Il costo si misura, il valore no.

E il costo sostenuto non è facile da prevedere. Chi progetta sistemi seri se ne accorge alla prima fattura mensile, che troppo spesso sfora le previsioni fatte. Le aziende scoprono di avere agenti che consumano milioni di token per attività che, a mente lucida, ne richiederebbero decine di migliaia. I meccanismi di controllo (rate limiting, caching, model routing) sono complessi da progettare e richiedono competenze specifiche. Una commodity ha costi facilmente prevedibili e gestibili; per questo motivo si scambia sui mercati a termine. L’AI, oggi, comporta costi fuori controllo in molte adozioni concrete: il 73% delle aziende dichiara che i costi hanno superato le proiezioni iniziali [3].

Switching cost: comprare non è migrare

Nel mercato dell'AI cambiare modello significa toccare l'intero stack applicativo. Le istruzioni scritte per il modello (i prompt), i sistemi che valutano le sue risposte, i meccanismi che gli consentono di usare strumenti esterni, i sistemi che gli forniscono informazioni dall'archivio aziendale: ognuno di questi elementi è calibrato sulle peculiarità del modello scelto [4].

Chi ha adottato e usato seriamente l’AI ha già scoperto il costo della migrazione. Chi non lo ha fatto lo scoprirà quando cercherà di passare da un provider all’altro o dovrà orchestrare più modelli in parallelo. Un sondaggio Zapier del 2026 su oltre cinquecento dirigenti aziendali americani lo conferma: tra chi ha tentato una migrazione tra piattaforme di AI, il 58% afferma che la migrazione è fallita del tutto o ha richiesto molto più sforzo del previsto [5]. E il caso di Claude Fable 5, sospeso a livello globale per diciotto giorni nel giugno 2026 per un ordine di export control del Dipartimento del Commercio statunitense, ha mostrato che il lock-in su un singolo provider è un rischio operativo concreto, non ipotetico [6].

Una commodity si sostituisce, un modello si migra. Sono due verbi che descrivono economie diverse.

Evoluzione continua e artefatto conoscitivo

Il rame del 1980 è il rame del 2026. Il petrolio di dieci anni fa, raffinato per gli stessi usi, dà gli stessi risultati. La stabilità nel tempo è parte della definizione di commodity: se non fosse così, i futures non funzionerebbero.

I modelli AI si aggiornano ogni tre o sei mesi. Non solo con nuove versioni, ma con aggiornamenti che cambiano comportamenti sottili, spostano capacità, rompono valutazioni consolidate. Ogni release rimette in discussione i test di regressione, i benchmark interni, la calibrazione dei sistemi. Chi gestisce sistemi in produzione con LLM tiene un log di comportamenti che cambiano fra una release e l’altra, e sa che ogni “minor update” annunciato dal provider è un evento che richiede attenzione [7].

Questa non è un’anomalia da correggere, è la natura della tecnologia. Un modello di frontiera è un artefatto conoscitivo, il prodotto di scelte progettuali su dati, obiettivi di training, priorità di alignment, tradeoff fra capacità diverse. Riflette una teoria implicita di cosa sia utile, ragionevole, sicuro. Chiamare commodity un artefatto di questo tipo è una categoria concettuale sbagliata, prima ancora che un errore di analisi economica. Confonde il modo di produzione (industriale, su larga scala) con la natura del prodotto (contingente, situato, negoziato).

La barriera d’uso: chi accende la luce non pensa alla corrente

C’è un’ultima proprietà, la più importante. Chi compra una commodity la usa, non deve conoscerne il funzionamento. Chi accende la luce non sa come si genera la corrente; chi compra farina la impasta senza essersi mai occupato della macinazione; chi compra benzina la brucia nel motore senza pensare al giacimento. Il prodotto è pronto per essere consumato secondo protocolli stabiliti.

L’AI no. Per produrre valore va conosciuta per come funziona e per come lo fa: saperla interrogare (prompt engineering), fornirle il contesto giusto (context engineering), integrarla con i propri dati (retrieval, tool use), valutarne l’output (eval), correggerne le derive (guardrail, monitoring), aggiornarne la pipeline quando cambiano i modelli. È un lavoro cognitivo di alto livello che richiede persone che sappiano cosa stanno facendo. Non basta comprarla: bisogna imparare a usarla. Serve ricerca, serve formazione, serve l’accumulo di conoscenza all’interno dell’organizzazione.

Il costo di una categoria sbagliata

Chiamare l’AI una commodity non è una questione terminologica. È una categorizzazione che determina in anticipo come l’azienda tratterà la tecnologia. Da lì discende una cascata di scelte manageriali che derivano automaticamente dalla categoria adottata: gare al ribasso sui fornitori, esternalizzazione dei ruoli distintivi, budget di formazione tagliati, competenze tecniche allontanate dai tavoli decisionali, KPI sulla riduzione del costo per utente invece che sull’accumulo di capacità. Sono gli stessi automatismi che hanno impoverito l’IT negli ultimi vent’anni; solo che oggi il costo del non fare non si misura in progetti che finiscono in ritardo, ma in intere aziende che perdono la capacità di comprendere il proprio settore.

Il verbo giusto

La commodity si compra. L’AI si adotta: un verbo diverso, con conseguenze diverse.

Chi la tratta come una commodity ha già scelto il proprio destino. Pagherà due volte: una perché non ne otterrà un valore proporzionato all’investimento, l’altra perché nel frattempo qualcun altro sta imparando a farlo. La differenza fra le due posture non si vedrà nel trimestre. Si vedrà nel decennio, come si è vista la differenza fra le aziende che negli anni Duemila hanno preso sul serio l’informatica e quelle che l’hanno trattata come commodity.

La domanda che ponevo alla fine del post sui quattro cavalieri era: quanti di loro galoppano nella vostra azienda? Ne aggiungo un'altra, più elementare: quando qualcuno vi dice che l'AI è una commodity, chiedetegli di nominarne un'altra che, per produrre valore, debba essere istruita a svolgere il proprio lavoro. Se non riesce, non sta conducendo un’analisi fondata. Usando la categoria della commodity, sta di fatto imponendo una scelta strategica. E le decisioni strategiche prese su una categoria sbagliata sono, per definizione, sbagliate.

Per approfondire

[1] Nicholas Carr, “IT Doesn’t Matter”, Harvard Business Review, maggio 2003, hbr.org/2003/05/it-doesnt-matter. L’articolo che ha coniato la formula “IT is a commodity” per l’informatica aziendale, da cui è scaturita una generazione di scelte manageriali di outsourcing e di riduzione dei costi.

[2] Treccani, “Commodity”, Dizionario di Economia e Finanza (2012), voce di Flavio Pressacco, treccani.it.

[3] FinOps Foundation, State of FinOps 2026 Report, data.finops.org. Il 73% delle aziende dichiara che i costi dell’AI hanno superato le proiezioni iniziali; il budget medio per l’AI è passato da 1,2 milioni di dollari nel 2024 a 7 milioni nel 2026. Sul caso Uber (intero budget AI 2026 bruciato entro aprile, con l’introduzione successiva di un cap mensile per dipendente): TechCrunch, “The token bill comes due: Inside the industry scramble to manage AI’s runaway costs”, 5 giugno 2026, techcrunch.com.

[4] OpenAI, “Prompt Migration Guide”, developers.openai.com; Anthropic, “Prompting best practices”, platform.claude.com. I due principali provider ammettono ufficialmente che i prompt non sono portabili tra modelli e forniscono guide di migrazione dedicate.

[5] Zapier, “Zapier Survey Finds Nearly 3 in 4 Enterprises Would Face Disruption If They Lost Their Primary AI Vendor”, BusinessWire, 2 aprile 2026. Sondaggio su 542 C-level executive statunitensi, condotto tramite Centiment tra il 30 gennaio e il 6 febbraio 2026. businesswire.com

[6] Anthropic, “Statement on the US government directive to suspend access to Fable 5 and Mythos 5”, 12 giugno 2026, anthropic.com/news/fable-mythos-access. Ripristino annunciato il 30 giugno 2026: CNBC, “Anthropic says Trump admin has lifted export controls on Claude Fable 5 and Mythos 5”, cnbc.com.

[7] Lingjiao Chen, Matei Zaharia, James Zou, “How Is ChatGPT’s Behavior Changing over Time?”, arXiv:2307.09009 (2023), poi pubblicato in Harvard Data Science Review, 6(1), 2024, arxiv.org/abs/2307.09009. Lo studio empirico documenta scostamenti marcati nel comportamento di GPT-3.5 e GPT-4 tra le release successive: in un caso, l’accuratezza di GPT-4 sul task di identificazione dei numeri primi è passata dall’84% al 51% tra marzo e giugno 2023.

Letture correlate

Matt Asay, “The new AI lock-in”, InfoWorld, 18 maggio 2026, infoworld.com. Il punto centrale rafforza l’argomento del post: il lock-in nell’AI non è sparito con la standardizzazione delle API, si è spostato di uno o due livelli, sull’orchestrazione, sul workflow surface, sul layer di governance. “The model call is getting easier to replace; the surrounding workflow, governance, and operating model are not.”

Gartner, Market Guide for AI Gateways, ottobre 2025. Previsione: entro il 2028 il 70% dei team di software engineering che costruiscono applicazioni multi-model userà un AI gateway (dal 25% del 2025): segnale che l’industry riconosce il lock-in come rischio operativo da gestire con layer di astrazione dedicati.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Il post in tre frasi

1. Molte aziende si avvicinano all’AI partendo dallo strumento (un fornitore, un modello, una tecnologia) anziché dal problema da risolvere, e per questo si scontrano con costi imprevisti e risultati che non tornano.

2. I nove punti che seguono, ciascuno con un fare e un non fare, coprono le principali scelte tecniche, organizzative ed economiche che guidano un processo di adozione di GenAI.

3. Non eliminano i rischi dell’adozione: aiutano a giungere alla decisione con meno assunzioni implicite e a ridurre il rischio di fallimento.

Quando un’azienda mi parla di GenAI, la prima domanda è quasi sempre la stessa: “Da dove cominciamo?” La intendono in senso operativo: scegliere un caso d’uso, un fornitore, un pilota da chiudere entro il trimestre.

Il 9 giugno ho parlato a Bologna con un gruppo di imprese manifatturiere che stanno cercando di capire come gestire l’adozione di GenAI nei propri processi. L’intervento era in due parti: la prima sui limiti strutturali degli LLM, la seconda è un framework con nove punti su come impostare un’adozione pragmatica, ciascuno definito da un fare e un non fare.

I punti derivano da osservazioni raccolte tra aprile e maggio in quattro post su A bassa voce: L’agente che non sa perché, Quando il computer “indovina” e quando calcola, Per un martello, il mondo è fatto solo di chiodi, L’AI che non ricorda. Preparare l’intervento mi ha costretto a estrarne un framework operativo. Eccolo.

1. Partire dal problema, non dallo strumento

La domanda “come uso GenAI?” pone lo strumento prima del bisogno. La domanda corretta è l’opposto: qual è il problema da risolvere e quale strumento lo risolve al meglio? A volte sarà GenAI, spesso sarà altro. Sistemi esperti, blockchain e metaverso sono stati adottati con la stessa dinamica: prima la tecnologia, poi la ricerca di un caso d’uso che la giustificasse. Il risultato: molti studi e progetti mai arrivati in produzione.

✅ Partire da un problema specifico per cui esistono già dati sufficienti. Qualificarlo, poi valutare lo strumento.

❌ Non partire dallo strumento. Non trattare la GenAI come un'opzione automatica. Soprattutto, non trattarla come una commodity (un tema su cui tornerò presto).

2. Domain expert nel progetto, formazione in parallelo

Un LLM non conosce l’impresa specifica in cui deve essere adottato: vincoli operativi, limiti regolatori, procedure interne, conoscenza di dominio. Questa lacuna non si colma solo con più training. La conoscenza organizzativa cambia nel tempo, presenta contraddizioni interne e va arricchita e verificata da chi la usa ogni giorno. Allo stesso tempo, usare GenAI richiede di conoscerne le caratteristiche, i limiti e le dinamiche d’uso.

✅ Domain expert nel team dal giorno uno, con formazione parallela in GenAI fin dalla fase di costruzione del pilota.

❌ Non aspettarsi che un modello, solo perché più grande o potente, sia in grado di “imparare a conoscere l’azienda”. Non rimandare la formazione a dopo il pilota: è una precondizione, non una conseguenza.

3. Calcolare o stimare

Un foglio Excel calcola: stesso input, stesso output. Un LLM stima: pondera le probabilità e può cambiare risposta a parità di domanda. Trattare l’uno come l’altro non è una svista teorica: si paga con errori a valle, con controlli di riproducibilità che non tornano, con numeri che non stanno più insieme.

✅ Prima di scegliere lo strumento, chiarire il tipo di risposta necessario. Certezza riproducibile → calcolo deterministico. Stima, approssimazione, creazione → GenAI.

❌ Non usare GenAI come motore computazionale per calcoli o procedure che richiedono esattezza e riproducibilità dei risultati.

4. Nei workflow regolati, l’LLM è una scelta architetturale onerosa

Al vincolo del punto 3 se ne aggiunge un altro: la ricostruibilità delle decisioni. Nei processi con audit, tracciabilità, accountability legale e vincoli normativi, ricostruire ex post perché una decisione sia stata presa non è opzionale. Un LLM, come motore decisionale, rende quella ricostruzione strutturalmente difficile: le tracce di ragionamento che produce non costituiscono una garanzia di fedeltà al processo interno che ha portato alla decisione.

✅ Nei workflow regolati, mantenere il motore decisionale deterministico. L’LLM può agire come interfaccia con l’utente o come orchestratore di strumenti di terze parti, ma non decide.

❌ Non delegare a un agente non deterministico decisioni che devono essere ricostruibili di fronte a un auditor. Il livello di governance (control plane) può vincolare ciò che un agente è autorizzato a fare, non il modo in cui ragiona per farlo.

5. Nei sistemi transazionali, l’LLM sta fuori dal motore

I sistemi OLTP (contabilità, fatturazione, ERP, gestione degli ordini) hanno due requisiti tecnici che un LLM non è progettato per garantire: correttezza e prestazioni. Un saldo, una fattura, un movimento contabile non ammettono approssimazioni né errori di sincronizzazione tra le operazioni: la correttezza è al centesimo. E una transazione va chiusa in millisecondi, con migliaia di operazioni al secondo, a un costo unitario sostenibile. Nessuno di questi requisiti è compatibile con l’attuale profilo tecnico ed economico degli LLM di frontiera, tipicamente considerati nei progetti aziendali di GenAI attuali.

✅ Nei sistemi transazionali, tenere l'LLM fuori dalla catena delle transazioni. Ha senso come interfaccia esterna: interrogare un database in linguaggio naturale, generare report, sintetizzare dati. Il calcolo e la scrittura restano al motore deterministico.

❌ Non usare l’LLM come componente della catena transazionale, nemmeno come orchestratore di una sequenza di operazioni di commit (l’operazione che rende definitive e permanenti le modifiche di una transazione). Latenza, costi e non-determinismo cumulati rendono il servizio insostenibile prima ancora che inesatto.

6. Lo stato esterno ha un costo che va stimato

Gli LLM sono stateless per definizione: ogni sessione parte da zero. Per simulare la continuità, si costruisce uno stato esterno: un file di contesto, RAG, tecniche di context engineering (cioè come si struttura ciò che viene passato al modello a ogni chiamata). In un workflow personale funziona. In un processo aziendale, lo stato deve essere costruito, mantenuto in vita, validato e testato. È lì che la complessità esplode.

✅ Valutare il costo totale per gestire lo stato esterno: costruzione, manutenzione, validazione, test e riproducibilità.

❌ Non assumere che aggiungere RAG (un livello software che consente all’LLM di accedere a documenti specifici al momento della richiesta) risolva l’assenza di stato a un costo trascurabile. Il più delle volte costa più del processo deterministico che voleva sostituire, e funziona peggio.

7. Governance dei dati prima della governance dell’AI

Qualità, tagging, integrazione, accesso: senza “igiene dei dati”, ogni difetto entra nel modello e ne esce moltiplicato. Un progetto AI eredita tutti i problemi che il sistema informativo aziendale ha lasciato in sospeso: dati duplicati, incoerenze tra le fonti, campi non validati, accessi non tracciati. Non è un problema che si aggira scegliendo un modello migliore. La catalogazione delle fonti, la tracciabilità di chi le aggiorna, la definizione di misure di qualità e il controllo degli accessi vanno impostati prima, non dopo.

✅ Costruire la governance dei dati prima di avviare qualsiasi progetto di AI. Se non esiste, è il primo investimento — e va misurato, non solo dichiarato.

❌ Non lanciare un progetto AI se i dati a supporto non esistono o se non c’è un piano credibile per produrli e validarli. Non aspettarsi che il modello “recuperi” ciò che manca a monte.

8. Economia del progetto: costruzione ed esercizio

I costi dell’AI si dividono in due categorie con logiche distinte. Il costo di costruzione (build) va giustificato ex ante. GenAI non è, di per sé, più conveniente di un’alternativa tradizionale: per i compiti computazionali strutturati, un sistema deterministico ben progettato costa spesso meno e funziona meglio. Il costo di esercizio (run) è variabile e, senza un controllo dedicato, cresce rapidamente e in modo non lineare con l'uso. La FinOps Foundation propone un ciclo in tre fasi da adottare fin dall'inizio: Inform (visibilità), Optimize (efficienza), Operate (governance continua).

✅ Costruzione: quantificare costo reale, beneficio atteso, metro di misura, e la ragione per cui l’approccio tradizionale non basta. Esercizio: monitorare i costi per caso d’uso; ottimizzare token, chiamate ai modelli, infrastruttura. Pratiche FinOps dal primo giorno.

❌ Non trattare i costi dell’AI come “spese tecniche” al di fuori del bilancio. Non dare per acquisito il vantaggio economico: dimostrarlo caso per caso.

9. Dove collocare l’intelligenza

La scelta di dove collocare il modello e i dati va effettuata esplicitamente. Tipicamente, modelli di frontiera in cloud per compiti generici; modelli più piccoli e specializzati, in sede (on-premise) o edge, per dati sensibili o per esigenze di latenza. Architetture ibride (es. RAG con dati in loco e modello in cloud) quando conviene.

✅ Scegliere l’architettura in base a due criteri: la sensibilità dei dati (GDPR, NIS2, vincoli di settore); il profilo di utilizzo effettivo.

❌ Non adottare posizioni di principio del tipo “tutto in cloud” o “tutto in casa”. Il criterio è tecnico ed economico, non una preferenza ideologica.

Si parte dal problema, non dal modello

I nove punti non risolvono il problema di adozione. Servono per arrivare alla decisione con il minor numero possibile di assunzioni implicite. Se, dopo averli esaminati tutti, resta incertezza, è un buon segnale: significa che il problema è stato preso sul serio. Se si saltano tutti, i rischi di insuccesso aumentano.

Proprio in questi giorni, ho ricevuto una mail con The Management Tip of the Day di Harvard Business Review, distillata dall'articolo di David De Cremer “When Developing an AI Strategy, Beware the Urgency Trap”, che dice:

If your AI initiatives aren’t delivering meaningful results, the problem may not be the technology, but the way you’re approaching it. Instead of chasing short-term efficiency, use AI to strengthen your organization’s long-term strategy.

Start with purpose. Before choosing tools, define the value you want to create. Ask yourself which problems matter most to your mission, where people add unique value, and how AI can support that work instead of simply accelerating existing processes.

Resist the urgency trap. Don’t let pressure to move quickly dictate your AI strategy. Fast deployments often overlook the skills, processes, and cultural changes needed for lasting success. Give people time to learn, adapt, and build trust in new ways of working.

Use AI to advance your vision. Treat AI as part of a broader transformation, not an isolated productivity tool. Align initiatives across teams so they help employees make better decisions, collaborate more effectively, and create greater value over time.

Dice le stesse cose con parole diverse. Segno che sono osservazioni di buon senso, maturate nella pratica. Temi su cui vale la pena riflettere e lavorare.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Ma i Pink Floyd che amo forse di più sono quelli che credo siano dominati da Rick Wright: Atom Heart Mother, Meddle e il grande, strano, folle Ummagumma.

Un disco con quattro pezzi live semplicemente stratosferici, a cominciare da una versione pazzesca di “Astronomy Domine” di Syd Barrett e dalle urla agghiaccianti di “Careful with That Axe, Eugene”. E poi un disco sperimentale, in cui i quattro, a turno, provano le atmosfere e i suoni più strani, spaziali, “otherworldly”.

Non è facile da ascoltare. Ma che creatività e voglia di sperimentare!

Unico, a cominciare dalla copertina lunare di Hipgnosis.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Stradella, Agostino Depretis si presenta agli elettori del suo collegio elettorale e si dichiara pronto ad accogliere chiunque sia disposto a “trasformarsi” ed entrare nella sua maggioranza. Da quel discorso entra nel vocabolario politico italiano una parola difficile da dimenticare: trasformismo. Oggi è ancora una delle parole con cui descriviamo e stigmatizziamo comportamenti che dovrebbero essere considerati negativi e che, invece, vengono spesso tollerati e, in alcuni casi, persino giustificati.

Due facce della stessa medaglia

Sono due le forme in cui si è “milanista e interista allo stesso tempo”. La prima è semplice. Certi ruoli si escludono per natura: chi controlla non può essere controllato; chi decide non può essere il primo beneficiario della propria decisione, né può aver scritto la norma per il proprio caso; non si può lavorare per una struttura e, contemporaneamente, per un concorrente. Eppure queste cose accadono e spesso si fa finta di non vederle.

Nel dibattito italiano chi solleva questo problema diventa il guastafeste, l’invidioso, il rompiscatole. Il potere funziona come una licenza implicita: se sei abbastanza in alto, le incompatibilità diventano rumore per chi non capisce. La sensibilità collettiva si accende solo di fronte agli scandali, quando i fatti sono troppo gravi per essere ignorati. Poi si spegne di nuovo.

Le istituzioni e le imprese scrivono codici etici con cura, li illustrano ai nuovi arrivati e poi li lasciano cadere quando il caso si fa scomodo. Usiamo o meno la lente a seconda di chi guardiamo.

Una maglia oggi, l’altra domani

La seconda lettura racconta una storia altrettanto antica. Due maglie indossate in sequenza, una dopo l’altra. Ieri di qua, oggi di là, senza spiegazioni. E nessuno fa una piega. Molti chiamano questa abilità “capacità di adattamento” o “pragmatismo”. L’espressione esatta è una sola: squallido opportunismo.

Il trasformismo di Depretis era anzitutto un metodo di governo, prima che un’inclinazione personale: assorbire gli avversari svuotandone le posizioni, governare al centro, spostandosi al bisogno a destra o a sinistra. Depretis fece la sua mossa verso i moderati di Minghetti, ma il metodo non ha preferenze di parte. Gramsci userà l’espressione “strategia di neutralizzazione”. La versione contemporanea che vediamo è meno raffinata e più personale. Il dirigente che cambia casacca quando più conviene, l’intellettuale che ridefinisce le proprie posizioni a seconda del pubblico che ha davanti, l’esperto che ieri certificava una tesi e oggi la sua contraria. E i media che certificano la metamorfosi come “evoluzione”, “maturazione”, “capacità di lettura del tempo”.

Lo stesso virus

Le due letture si toccano. Sembrano parlare di cose diverse (un soggetto con due ruoli simultanei, un soggetto che cambia ruolo nel tempo), ma in realtà svolgono la stessa operazione. Liberano la persona dal vincolo che la posizione comporta. Trasformano l’appartenenza in un accessorio da indossare e togliere a seconda della temperatura. Il filo comune è la dissoluzione della categoria della coerenza, intesa come qualcosa che vincola e qualifica.

In entrambi i casi, una volta accettata la mossa, cambiamo il vocabolario per giustificarla. Il conflitto di interessi diventa “sovrapposizione di esperienze”, il cambio di posizione diventa “maturazione”, la doppia appartenenza diventa “competenza trasversale” o “sinergie”. Rinunciamo al vero significato delle parole e i fatti si adeguano di conseguenza.

Nessuno è puro, e la purezza non è la posta in gioco. La posta in gioco è più ragionevole: una maglia per volta; i cambi di maglia argomentati; quando i ruoli si escludono, sceglierne uno. Se non lo facciamo e lo diciamo noi, non lo farà nessuno al nostro posto. E i milanisti-interisti continueranno a giocare in entrambe le squadre, presentandosi come pragmatici e moderni.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

È per me un piccolo rituale. Mi piace percorrere in silenzio il lungo viale alberato che dall’ingresso conduce al campo dove sono sepolti i miei genitori. I cimiteri non mi mettono paura. Perché dovrei aver paura del luogo in cui sono sepolti i nostri cari? È il luogo delle nostre memorie, delle nostre famiglie, dei nostri affetti. È un luogo d'amore, anche quando raccoglie le spoglie di persone che hanno commesso errori o fatto del male. “Chi è senza peccato scagli la prima pietra”, disse qualcuno qualche millennio fa.

Di fronte alla tomba dei miei, mi viene spontaneo rivolgermi a loro nel pensiero per raccontare quel che mi succede: le gioie, le preoccupazioni, le paure e le angosce che vivo. E ripenso alle loro vite, ai sacrifici compiuti e, con dolore, alla sofferenza dei loro ultimi giorni. Papà fu operato per la rimozione di un rene, compromesso da un tumore. Non si riprese mai completamente e morì di notte, in ospedale per una complicanza dovuta a un edema polmonare. Mamma visse nella sua casa fino a 90 anni. Aveva una tempra forte ed era totalmente autonoma. Poi si ruppe un femore e da lì iniziò una discesa inarrestabile. Fummo costretti a ricoverarla in una RSA perché necessitava di un’assistenza continua, peraltro proprio poco prima dello scoppio della pandemia. Visse quei periodi da sola. Potevamo andare a trovarla solo in determinati giorni e parlarle separati da un vetro, con un microfono per scambiarci qualche parola. Si spense un po’ alla volta. Quando andavo a trovarla, seduta sulla carrozzina dalla quale non poteva più alzarsi, sentivo con strazio le sue parole sulla speranza di tornare a casa, non appena “fosse guarita”. Anche lei se ne è andata di notte, senza che io potessi essere al suo capezzale.

Quando adesso vado a trovarli, penso a chi si prenderà cura di queste tombe. Non sono i sepolcri di Michelangelo e di Galileo a Santa Croce, celebrati da Ugo Foscolo. Sono le tombe di persone semplici, come milioni di altre. È questione di qualche generazione e, di loro come di me, si perderà il ricordo. Nessuno si prenderà cura di queste spoglie, nessuno cambierà i fiori in loro memoria.

È un sentimento tragico, a cui tutti noi cerchiamo di sottrarci. Sono pensieri che portano alla disperazione e allo sconforto. Mi torna in mente la Nona di Mahler: il primo e il quarto movimento sono sospesi sulla soglia della morte, mentre il secondo e il terzo mettono in scena la folle ostinazione di chi ama la vita e, quasi da pazzo, si rifiuta di contemplarne la fine. È un’opera che mi sconvolge come poche altre. Mi mette di fronte alla paura del nulla. Forse è così perché io, come tanti, ho molto e ho paura di perderlo: la gioia dei figli e, ora, del nipote, una vita tutto sommato serena, un lavoro stimolante. Per molti altri, ahimè, la vita è solo sofferenza, dolore, disperazione. La vita e la morte hanno un significato completamente diverso.

Di fronte alla tomba dei miei mi rendo conto che la Fede è l’unica speranza. Ma non voglio che sia una consolazione, un oppio che addomestica le paure e le lascia intatte, senza una via di uscita. Voglio che ciò in cui credo sia vero, non perché lo spero, ma perché così è.

Non c'è risposta razionale. Nessuna prova inconfutabile che convinca la testa di un ingegnere. Non resta che vivere la Fede accettando il dubbio. Sperare e attendere "la risurrezione della carne, la vita eterna. Amen.”

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

I ranking internazionali (QS, THE, ARWU di Shanghai) hanno pubblicato negli ultimi mesi le edizioni più recenti e ogni paese ha presentato i propri risultati con il consueto mix di legittimo orgoglio e di marketing istituzionale. In Italia, la notizia forse più segnalata sui media è stata l’ulteriore avanzata del Politecnico di Milano nei top 100 della QS — 87° posto nell’edizione 2027 uscita il 18 giugno 2026, +11 posizioni in un anno, +100 in dieci anni. Risultato vero, che si aggiunge al miglior risultato di sempre della Sapienza nella stessa edizione (111° posto, +17 in un anno) e al miglioramento di Bologna e di altri atenei italiani.

La mia tesi (e non solo la mia) è che il ritardo europeo non risieda principalmente nelle università: stanno facendo il loro mestiere a un livello dignitoso. Il problema è che il sistema attorno a loro non è attrezzato a valorizzare, sul piano economico, quanto si produce sul piano scientifico. Pensate al web, inventato a Ginevra al CERN, e dominato oggi dalle grandi corporation USA. In Italia il problema si aggrava per gli interventi e gli investimenti che hanno speso molto senza cambiare in modo strutturale la dinamica dei processi di ricerca e innovazione del Paese.

1. Quello che le università europee producono e non riescono a trasferire

Nei tre principali ranking mondiali, la presenza europea resta significativa. Il THE 2026 conta una trentina di università europee nei top 100 (gli USA ne hanno 35); QS 2026 valorizza il sistema britannico (17 atenei nei top 100, di cui 4 nei top 10); ARWU 2025 — che pesa di più la ricerca pura, con indicatori come premi Nobel, articoli su Nature e Science, citazioni Web of Science — abbassa la quota europea al 25% contro il 37% americano, ma le presenze restano numerose: Cambridge (4°), Oxford (6°), Paris-Saclay (13°), LMU Monaco (42°), Sorbonne (43°), TU Monaco (45°), Heidelberg (51°), fra le prime cinquanta o appena dietro.

Anche le università italiane stanno migliorando. In ARWU 2025 Sapienza è nella fascia 101-150, l’unica italiana nei top 150; in THE 2026 Bologna sale al 130° posto (dal 146° dell’edizione precedente). In QS 2027, l’edizione più recente, il quadro italiano è il migliore degli ultimi anni: Politecnico di Milano all’87° posto, Sapienza al 111° (miglior risultato di sempre), Bologna al 123°, e progressi importanti per Padova (dal 336° al 204°, +132 posizioni in un anno) e Politecnico di Torino (dal 305° al 206°). Sono 47 gli atenei italiani in classifica QS, di cui 26 in miglioramento rispetto all’edizione precedente. È il dato di maggior interesse: in QS 2027, mentre la Germania ha visto scendere 38 atenei su 60, la Spagna 24 su 48, la Francia 19 su 38 e l’Olanda 11 su 13, l’Italia è l’unico grande sistema europeo in cui la maggioranza degli atenei è in crescita. Nel complesso, gli atenei italiani in classifica restano molto meno numerosi rispetto agli USA (184 atenei) e agli altri grandi sistemi anglosassoni e asiatici, ma la traiettoria, almeno in QS, è positiva.

Va aggiunta una precisazione d’obbligo: il dibattito italiano sull’università è da anni avvelenato da una retorica stucchevole. Riconoscere che il sistema ha una base competitiva non significa che vada tutto bene. Il sistema italiano resta molto sotto i benchmark europei su quasi ogni indicatore strutturale: finanziamento per ricercatore, dimensione media degli atenei, rapporto studenti-docenti, internazionalizzazione di studenti e docenti, output di alta qualità per docente, capacità di attrarre i migliori dall’estero. La distanza dai migliori sistemi continentali — Olanda, Svizzera, Svezia, i Länder tedeschi più virtuosi — è cospicua. Il lavoro da fare è enorme, e bisogna farlo.

Una cosa, però, è una valutazione seria, anche dura, fondata su meccanismi specifici e su dati confrontabili. Un’altra è il fuoco di sbarramento generalizzato che spesso accompagna il discorso pubblico sull’università italiana — ridotta a luogo di privilegi corporativi, parentopoli e inefficienza endemica, da cui non ci si potrebbe aspettare nulla. Quel registro non corregge nulla, produce rumore, demoralizza chi lavora bene e fa da copertura a chi non vuole investire nell’università perché «tanto è un buco nero». Sparare nel mucchio alla cieca è sempre più facile che lavorare per migliorare un sistema complesso. Più facile, ma quasi sempre sbagliato.

Quando però si guarda al passaggio successivo (la trasformazione di quella produzione in aziende che competono a livello globale), il sistema si inceppa. Il caso del web che citavo in precedenza è, a questo proposito, emblematico.

In 2023, deep tech accounted for 44% of venture capital (VC) funding in Europe. However, only 23% of spin-offs operate in this sector, compared to more than 60% of VC funded deep tech companies in the United States. This gap suggests that Europe is not fully capitalising on its research strengths. [Commissione Europea, Spin-offs: Driving innovation across the EU-27, 25 febbraio 2025]

La ricerca europea genera meno aziende ad alta intensità tecnologica e, quando le genera, fatica a portarle oltre la fase seed. Quel fallimento è di sistema, non è una colpa delle università.

2. Il sistema downstream che non c’è

Tre dati illustrano la struttura del ritardo europeo.

Spesa R&D corporate. Lo dice il rapporto Draghi:

In 2021, EU companies spent about half as much on R&I as share of GDP as US companies – around EUR 270 billion. [Mario Draghi, The future of European competitiveness — Part A, Commissione Europea, settembre 2024]

Il gap è concentrato nel settore tecnologico, dove le prime tre imprese europee per spesa in R&D operano nell’automotive mentre le prime tre americane sono tutte tech. La R&D intensity complessiva dell’UE è pari al 2,1% del PIL (OECD MSTI 2024), contro circa il 3,4% degli Stati Uniti e la rapida ascesa della Cina, salita al 2,6% nel 2024 — allineandosi per la prima volta alla media OECD, ma ancora circa 0,8 punti sotto quella degli Stati Uniti.

Allocazione del risparmio. È qui che il quadro diventa impietoso. Il rapporto Atomico State of European Tech 2025 documenta che i fondi pensione europei allocano al venture capital appena lo 0,009% dei propri asset, contro lo 0,028% dei fondi pensione statunitensi — una differenza di oltre tre volte. Portare l’allocazione europea al livello americano libererebbe circa 210 miliardi di dollari aggiuntivi di venture funding nel corso del decennio.

Aggregando l’effetto su un orizzonte più ampio, lo stesso rapporto stima che l’Europa abbia sottofinanziato le proprie aziende tecnologiche di circa 375 miliardi di dollari rispetto agli Stati Uniti negli ultimi dieci anni — e che per fermare l’allargamento del gap servirebbero oltre 1 trilione di dollari di investimento aggiuntivo nei prossimi dieci anni.

Scale-up gap. L’Europa è competitiva nelle fasi seed e serie A. È nella fase di crescita, dopo i €50 milioni di valutazione, che il sistema non funziona. Le aziende che superano quella soglia trovano in Europa pochi fondi capaci di investire centinaia di milioni e finiscono per andare a Wall Street, quotarsi al Nasdaq, spostare il quartier generale. È quello che gli analisti chiamano mid-tech trap: il sistema genera molte aziende interessanti, quasi nessuna delle quali diventa grande.

I dati di produttività confermano la diagnosi.

Between the fourth quarter of 2019 and the second quarter of 2024 labour productivity per hour worked increased by 0,9% in the euro area, whereas it increased by 6,7% in the United States. [Banca Centrale Europea, Economic Bulletin — box «Labour productivity growth in the euro area and the United States: short and long-term developments», giugno 2024]

Un divario di sette volte in cinque anni non si recupera con un’iniezione di laureati STEM. Si recupera, semmai, ricostruendo l’apparato che sfrutta la ricerca su scala più ampia.

A ciò si aggiunge la frammentazione regolatoria. Il mercato unico europeo non esiste, di fatto, per i servizi finanziari, il diritto societario, il fallimento, la fiscalità del capitale di rischio. Una startup tedesca che vuole quotarsi si trova ad affrontare regole diverse da quelle di una startup francese. Un fondo VC che vuole investire cross-border paga frizioni che un fondo americano non affronta. I rapporti di Letta sul mercato unico (aprile 2024) e di Draghi sulla competitività (settembre 2024) convergono: senza Capital Markets Union, qualunque iniezione di liquidità si disperde e non raggiunge la scala e l’effetto desiderati.

3. L’azione è sottodimensionata di un fattore venti

Il rapporto Draghi ha esplicitato un numero: per chiudere il gap di competitività servono tra i €750 e gli €800 miliardi all’anno di investimento aggiuntivo, pari al 4,4-4,7% del PIL europeo. Le 383 raccomandazioni del rapporto riguardano il Capital Markets Union, la ricerca e l’innovazione, l’energia, la difesa e l’industria.

A un anno dalla pubblicazione, il Draghi Observatory & Implementation Index, lanciato a settembre 2025 dall’European Policy Innovation Council, riporta numeri preoccupanti:

Out of 383 recommendations, only 11,2% have been fully delivered. Even when partial progress is counted, the EU has reached just 31,4% of the Draghi agenda. The rest remains either “in progress” or untouched.

Implemented: 11,2% (43 measures) — Partially Implemented: 20,1% (77 measures) — In Progress: 46,0% (176 measures) — Not Implemented: 22,7% (87 measures).

La Commissione ha lanciato a gennaio 2025 il Competitiveness Compass — un quadro coerente, ma con risorse di un ordine di grandezza inferiore rispetto a quelle proposte da Draghi. Lo Scaleup Europe Fund dell’European Innovation Council, annunciato dalla Presidente von der Leyen nel Discorso sullo Stato dell’Unione di settembre 2025, sarà presentato formalmente all’EIC Summit del 3 giugno 2026 con i primi investimenti previsti in autunno 2026: descritto come «multi-miliardo», è ancora in fase di costituzione. In parallelo, il bilancio annuale dell’EIC per il deep tech e le tecnologie strategiche nel 2025 si attesta su €1,4 miliardi: una cifra che, confrontata con l’ammontare del problema, ha un peso marginale.

4. L’Italia, e il PNRR come occasione mancata

In questo quadro, l’Italia parte da una posizione peggiore della media europea e aggiunge errori propri.

La spesa italiana in R&D è all’1,37% del PIL, ferma rispetto al 2022:

L’incidenza percentuale della spesa sul Pil, indicatore noto come intensità di ricerca e sviluppo, risulta pari all’1,37%, in linea con il 2022 (1,37%), e in diminuzione rispetto al 2021 (1,41%). [ISTAT, La ricerca e sviluppo in Italia – Anni 2023-2025, settembre 2025]

Sotto la media europea (2,11%) e ben al di sotto dell’obiettivo del 3% fissato al Consiglio europeo di Barcellona nel 2002, nell’ambito della Strategia di Lisbona lanciata due anni prima. La spesa pubblica per la ricerca e lo sviluppo (R&D) in Italia, in percentuale sul PIL, è tra le più basse tra i grandi paesi europei.

Il sistema italiano di venture capital è marginale. Lo quantifica il Barometro EY 2026:

Nel 2025 il mercato italiano del venture capital ha raggiunto 1.488 milioni di euro, +32% rispetto al 2024 [...] tutti i paesi citati consolidano valori di raccolta ben più alti rispetto all’Italia: Francia circa 6,3 miliardi di euro, Germania 6,6 miliardi di euro, Regno Unito 18,4 miliardi di euro e Spagna 2,6 miliardi di euro. [EY Venture Capital Barometer, gennaio 2026]

Un divario di oltre quattro volte rispetto alla Francia e alla Germania, e di oltre dodici volte rispetto al Regno Unito.

Sotto questo gap c’è una causa strutturale che il dibattito italiano tende a sottovalutare: la dimensione delle imprese. L’Italia ha imprese mediamente più piccole di quelle di chiunque in Europa — 3,9 addetti per impresa contro una media UE di 5,0. Le grandi imprese (oltre 250 addetti) sono solo lo 0,09% del totale italiano, contro lo 0,14% in Francia, lo 0,19% nella media UE, lo 0,48% in Germania — dove ce ne sono oltre cinque volte tante (ISTAT, Censimento Permanente delle Imprese; elaborazione Centro Studi Tagliacarne / Unioncamere su dati Eurostat).

Conta perché la R&D corporate la fanno le grandi imprese. ISTAT segnala che, pur rappresentando meno dello 0,1% del totale italiano, le grandi imprese coprono il 73,1% della spesa privata in R&D del Paese:

Le grandi imprese si confermano quindi il soggetto più importante nelle attività di R&S intra-muros, con circa 12,5 miliardi di spesa (pari al 73,1% della spesa complessivamente sostenuta dalle imprese) contro i 3,4 miliardi delle piccole e medie imprese (PMI). [ISTAT, La ricerca e sviluppo in Italia – Anni 2023-2025, settembre 2025]

Un tessuto fatto al 95% da microimprese con meno di dieci dipendenti non ha la massa critica per sostenere la ricerca privata su scala continentale, né per attrarre venture capital in cerca di aziende capaci di scalare fino a valutazioni da centinaia di milioni. Il sottodimensionamento del VC italiano è in larga parte il riflesso del sottodimensionamento delle imprese. E una solida catena di trasferimento tecnologico fra ricerca pubblica e industria non si costruisce su un tessuto produttivo privo di massa critica per assorbirla.

Su un quadro del genere, il PNRR avrebbe potuto rappresentare l’occasione per una correzione strutturale. Risorse straordinarie, scadenze precise, vincoli europei: le condizioni per spese di sistema anziché di mantenimento. Quello che è successo, almeno sulla Missione 4 Istruzione e Ricerca (€30,9 miliardi complessivi, di cui €11,4 miliardi sulla sola Componente 2 dedicata alla ricerca e al trasferimento tecnologico), è andato in larga parte nella direzione opposta. Il giudizio è severo perché i fatti lo sono.

Primo, la dispersione interna dei programmi. La Componente 2 della Missione 4 ha finanziato 5 Centri Nazionali (HPC e Quantum, Agritech, Terapia genica e farmaci RNA, Mobilità sostenibile, Biodiversità), 14 Partenariati Estesi e 11 Ecosistemi dell’Innovazione: non un numero abnorme di programmi. Il problema è dentro a ciascuno di essi: ogni Centro Nazionale coinvolge decine di soggetti tra atenei, CNR ed enti di ricerca; ogni Partenariato Esteso copre quasi tutta la geografia accademica italiana. Quando si distribuiscono risorse pubbliche su un perimetro così ampio per garantire equità territoriale e accademica, si rinuncia, in partenza, a concentrare una massa critica su un numero ristretto di assi competitivi internazionali.

Secondo, i criteri di valutazione mi sembrano premiare la capacità di spesa entro le scadenze più che l’impatto. Il sistema di reportistica MUR–Commissione si concentra sulle milestone di realizzazione e di rendicontazione finanziaria — quelle che il PNRR esige per non perdere fondi — più che sugli outcome di trasferimento tecnologico e di scalabilità delle ricerche finanziate. È una mia valutazione, non un dato pubblico: si basa sull’osservazione diretta dei programmi e sulla letteratura disponibile (rapporti dell’ANVUR, audit della Corte dei conti europea sul Recovery and Resilience Facility). Quello che manca, ad oggi, è un meccanismo trasparente di selettività ex post — quali centri stanno funzionando, quali no, quali meritano di entrare in regime ordinario al termine del PNRR.

Terzo, la sostenibilità. Le strutture create dal PNRR vivono di risorse a tempo limitato. Quando il PNRR finirà, nessuna di queste strutture avrà un modello di finanziamento ordinario che la mantenga in vita. Ne ho già scritto in Le strutture nate con il PNRR cercano una exit strategy (18 aprile 2026) — il rischio non è teorico: i direttori dei centri stanno cercando risorse per mantenerli in vita.

Quarto, e più grave, il mancato raccordo con il mondo industriale. Non è stata costruita una governance che mettesse in fila le filiere industriali italiane prioritarie, le competenze accademiche necessarie a quelle filiere e i meccanismi di mercato per portare i risultati in azienda. È stato fatto il contrario: i temi li ha definiti il mondo accademico, Bruxelles li ha approvati, l’industria è arrivata in coda — quando è arrivata.

Quinto, e trasversale a tutto il resto: manca la spinta della concorrenza. La R&D privata cresce dove le imprese sono costrette a innovare per sopravvivere; il venture capital fiorisce dove il rischio privato rende più della rendita; il trasferimento tecnologico funziona dove l’industria a valle è in competizione con qualcuno; e la ricerca pubblica migliora dove gli atenei competono per talenti, risorse e studenti, non dove le risorse vengono ripartite in quote per equilibrare la geografia accademica. In Italia molte filiere restano protette (servizi professionali, energia, distribuzione, credito, trasporti, concessioni pubbliche) e la stessa logica pervade il sistema universitario: il finanziamento ordinario premia poco la performance relativa tra atenei, i concorsi restano largamente locali, la mobilità di docenti e studenti è modesta rispetto ai benchmark europei, e le stesse scelte del PNRR (su tutte, i Centri Nazionali costruiti per associare quasi tutta la geografia accademica) hanno rinforzato la logica proporzionale invece di introdurre selezione. La rendita di posizione, nei mercati come negli atenei, riduce la pressione competitiva e, con essa, la domanda di innovazione. L’aumento della concorrenza e della competizione dovrebbe essere una lente attraverso cui si muove l’intera azione di governo, non un capitolo confinato alla legge annuale sulla concorrenza, quando c’è, ma un criterio trasversale che informa le politiche fiscali, industriali, del lavoro, della regolazione dei mercati e del finanziamento del sistema della ricerca. Senza quella pressione, ogni iniezione di risorse pubbliche trova un tessuto (industriale e accademico) che non ha bisogno di trasformarla su larga scala.

La domanda giusta

Tornando alla domanda di apertura: quanto è grande l’impatto delle università sulla competitività tecnologica di un paese?

In Europa la leva decisiva è altrove rispetto alle università: nella mobilitazione dei €10 trilioni di depositi bancari delle famiglie europee che la Commissione, con l’iniziativa Savings and Investments Union, punta a canalizzare verso investimenti produttivi, nell’integrazione dei mercati finanziari, nella disciplina selettiva degli investimenti pubblici in innovazione e nell’apertura dei mercati e del sistema della ricerca alla concorrenza. In Italia, quella leva va affiancata a una correzione interna che il PNRR avrebbe potuto fare e che ha mancato: distribuendo risorse straordinarie secondo i criteri di ripartizione della spesa ordinaria, rinviando di un altro decennio la difficile conversazione sulla selettività e lasciando intatte le rendite di posizione (nei mercati e negli atenei) che frenano la domanda di innovazione.

Le università non possono fare tutto questo da sole. Stanno facendo la loro parte, quantomeno alcune ci provano. È necessario, dall’altra parte, un impegno che, allo stato dei fatti, non si riscontra.

Per approfondire

[1] Mario Draghi, The future of European competitiveness, European Commission, settembre 2024. https://commission.europa.eu/topics/competitiveness/draghi-report_en

[2] Enrico Letta, Much more than a Market, Consiglio Europeo, aprile 2024.

[3] European Policy Innovation Council (EPIC), Draghi Observatory & Implementation Index, settembre 2025 (aggiornato gennaio 2026). https://thinkepic.eu/draghi-observatory-implementation-index-only-1-in-10-measures-implemented/

[4] Banca Centrale Europea, Labour productivity growth in the euro area and the United States: short and long-term developments, Economic Bulletin Box, giugno 2024. https://www.ecb.europa.eu/press/economic-bulletin/focus/2024/html/ecb.ebbox202406_01~9c8418b554.en.html

[5] Atomico, State of European Tech 2025. https://www.stateofeuropeantech.com/

[5b] Commissione Europea, Savings and Investments Union: better financial opportunities for EU citizens and businesses, comunicato del 19 marzo 2025. https://commission.europa.eu/news/savings-and-investments-union-better-financial-opportunities-eu-citizens-and-businesses-2025-03-19_en

[5c] European Innovation Council, Scaleup Europe Fund. https://eic.ec.europa.eu/eic-fund/scaleup-europe-fund_en

[5d] European Innovation Council, EIC to invest €1.4 billion in deep tech in 2025, 29 ottobre 2024. https://eic.ec.europa.eu/news/european-innovation-council-invest-eu14-billion-deep-tech-and-scale-strategic-technologies-2025-2024-10-29_en

[6] Commissione Europea (DG Connect), Spin-offs: Driving innovation across the EU-27, 25 febbraio 2025. https://digital-strategy.ec.europa.eu/en/library/spin-offs-driving-innovation-across-eu-27

[6b] ISTAT, Censimento Permanente delle Imprese — primi risultati 2023. https://www.istat.it/comunicato-stampa/censimento-permanente-delle-imprese-2023-primi-risultati/

[6c] Centro Studi Tagliacarne / Unioncamere, elaborazioni sulla distribuzione dimensionale delle imprese europee (dati Eurostat). https://www.tagliacarne.it/

[7] QS World University Rankings 2027 — risultati (uscita 18 giugno 2026). https://www.qs.com/insights/qs-world-university-rankings

[8] Politecnico di Milano — comunicato QS 2027 (87° posto). https://www.polimi.it/en/the-politecnico/news/news-detail/qs-world-university-rankings-2027-polimi-ranked-87th-in-the-world-and-first-in-italy

[9] Sapienza Università di Roma — comunicato QS 2027 (111° posto, miglior risultato di sempre). https://www.uniroma1.it/it/notizia/qs-world-university-rankings-2027-sapienza-ottiene-il-miglior-risultato-di-sempre-111a-al

[10] Il Sole 24 Ore — QS University Rankings: Italia moves up, PoliMi 87th. https://en.ilsole24ore.com/art/qs-university-rankings-italia-moves-up-polimi-ranks-87th-in-the-world-AILiqAjD

[11] Times Higher Education — World University Rankings 2026: colliding forces. https://www.timeshighereducation.com/world-university-rankings/world-university-rankings-2026-colliding-forces

[12] ShanghaiRanking — Academic Ranking of World Universities 2025. https://www.shanghairanking.com/rankings/arwu/2025

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Prima di entrare nel merito, un chiarimento che nel post forse è rimasto implicito, e che qui rendo esplicito perché merita di esserlo. Non sono contro il remote working e, ancor meno, lo smart working. Sono contro il full-remote e contro un uso esagerato del lavoro da remoto, che tratta la presenza in ufficio come un residuo del passato da cui liberarsi e assume che la relazione professionale possa essere interamente trasferita su un canale digitale senza costi. E no, non sto neppure dicendo che il lavoro debba esaurire la vita delle persone: sto dicendo che il lavoro ha una dimensione sociale e relazionale, e che il full-remote la spezza. Il target del post è la modalità estrema, non la flessibilità né la critica all’occupazione totale del tempo. Detto questo, rispondo con tre punti.

1. I dati sono dati

Lo studio di Emanuel, Harrington e Pallais su Science è una misura statistica basata su un campione ampio e su un disegno di ricerca solido. Dice cosa accade in media a una popolazione di lavoratori, non ciò che è accaduto a un singolo. Un’esperienza individuale positiva non contraddice una tendenza aggregata: è un punto su una distribuzione. Chi risponde al dato con l’aneddoto sta cambiando la scala del discorso, dal fenomeno collettivo al proprio caso, e sposta la conversazione fuori dal terreno su cui si muove il paper. Si possono discutere il metodo, il perimetro, la trasferibilità. Non si può liquidare uno studio pubblicato su Science con «io mi trovo bene». I dati possono non piacere, ma quelli sono.

2. Da noi succede lo stesso

Con tutta la prudenza e l’attenzione del caso, visto che non sono un sociologo, ho fatto una breve ricerca giusto per capire come, nel nostro Paese, si parla di questo tema e in quali termini. La letteratura italiana sul benessere psicofisico dei lavoratori da remoto è abbondante e, per quel pochissimo che ho visto, conferma la struttura del ragionamento: il full-remote comporta costi mentali, fisici e organizzativi documentabili, distribuiti in modo asimmetrico tra gruppi che variano per contesto. Su salute mentale, Bertoni, Cavapozzi, Pasini e Pavese (2021) usano i dati del progetto SHARE per stimare l’effetto causale del remote work sui lavoratori senior europei nella prima ondata pandemica: gli effetti sono negativi per chi ha figli a casa (il carico domestico si somma a quello lavorativo) e per chi vive in paesi meno colpiti dalla pandemia: nei paesi con lockdown più leggeri e minore eccesso di mortalità il lavoratore da remoto restava isolato in casa mentre il resto della popolazione continuava a uscire e a vedersi; nei paesi più colpiti, dove tutti erano confinati, l’isolamento era invece collettivo. Gli effetti sono invece positivi per gli uomini e per chi non ha figli conviventi. Il contesto è quello pandemico, ma il meccanismo (carico domestico che si somma al lavoro, isolamento asimmetrico rispetto agli altri) non è pandemico, è strutturale e persiste ovunque il full-remote sia intenso e prolungato. Anche il paper su Science riporta un effetto asimmetrico, ma orientato diversamente: negli Stati Uniti sono i single a soffrire di più, perché per loro il lavoro era il principale canale di contatto sociale. Sul piano fisico, Pacetti e Recchi (2024), riprendendo Azzolari e Fullin, riportano che «l’85,4% dei rispondenti dichiara di esperire almeno un sintomo di malessere fisico e il 65,0% rileva la comparsa di almeno due sintomi contemporaneamente» dopo una giornata di lavoro da remoto, con un’incidenza sistematicamente più alta tra chi non dispone di una stanza dedicata (meno della metà del campione, in prevalenza donne). Sull’isolamento professionale, tema parallelo a quello dell’isolamento sociale al centro del paper su Science, Bronzini, Cori, Sarti e Torre (2023) mostrano che gli strumenti di coordinamento non bastano: serve «uno sforzo volto a promuovere il supporto sociale sul lavoro». Sul sovraccarico, l’Osservatorio Smart Working del Politecnico di Milano nella ricerca 2025 mette il numero: il 35% dei white collar in remoto soffre di overworking, contro il 30% di chi lavora sempre in sede. E l’INAPP (della Ratta-Rinaldi, 2026) sintetizza il trade-off sistemico: da un lato flessibilità, efficienza, autonomia; dall’altro, «riduzione dell’interazione tra colleghi, crescita delle asimmetrie informative e riduzione del potere contrattuale dei lavoratori». È il quadro che descrivo nel post, con dati su lavoratori italiani.

Lungi da me trarre conclusioni definitive. Ma, ancora una volta, non si possono liquidare queste osservazioni dicendo che l’esperienza dei singoli può essere diversa o che certe ricerche si applicano solo negli USA.

3. La dimensione sociale del lavoro non è una scoperta di oggi

Nel post l’ho solo sfiorata, perché ne ho scritto diffusamente altrove, in particolare nel libro Un bel lavoro, dove la comunità di pratica è il tessuto professionale, non un contorno. Lavorare bene non è solo produrre output: è imparare dai colleghi, capire i codici impliciti dell’organizzazione, essere apprezzati quando si fa qualcosa di utile ed essere aiutati quando si sbaglia, costruire nel tempo relazioni positive. Nessuna di queste cose si costruisce in modo sostitutivo su Slack o su Teams. Non è nostalgia dell’ufficio. È il modo in cui il lavoro professionale funziona da sempre, e continuerà a funzionare anche quando il rapporto tra presenza e distanza si sarà stabilizzato. Chi tratta la dimensione relazionale come un dettaglio che il remote può assorbire senza costi sta ignorando decenni di studi sull’organizzazione, non solo il paper su Science.

Il tema esiste. Parliamone, non neghiamolo.

Ci sono dati americani, ci sono dati italiani, c’è una tradizione di studi sull’organizzazione del lavoro che da anni ripete le stesse cose. La domanda utile non è se da noi si applica. Si applica. La domanda è: come costruiamo modalità di lavoro che tengano insieme la flessibilità che le persone, giustamente, vogliono e i costi sociali e cognitivi che il full-remote impone? Le risposte esistono e passano dall’approccio collaborativo alla pianificazione del lavoro, dall’investimento esplicito nel supporto sociale, dal ripensamento serio degli spazi e degli strumenti.

Un’ultima cosa. «A me il full-remote piace» è una preferenza legittima. «Il full-remote non ha costi» è un’affermazione sul mondo e ha bisogno di dati per reggere. Le due cose non sono la stessa cosa, e chi le confonde spesso lo fa perché la seconda gli permette di non rinunciare alla prima.

Questo post è stato scritto con l'assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Fonti

• Bertoni M., Cavapozzi D., Pasini G., Pavese C. (2021), Remote Working and Mental Health during the First Wave of COVID-19 Pandemic, IZA Discussion Paper n. 14773 — scheda IZA | PDF. Studio su dati SHARE.

• Pacetti V., Recchi S. (2024), Il lavoro da remoto dentro e oltre l’emergenza: una riflessione sociologica sul ruolo dello spazio, Università degli Studi di Milano-Bicocca — PDF. I dati 85,4% / 65,0% sono originariamente di Azzolari D., Fullin G. (2022), Il mio ufficio è il mio divano, Meridiana 104, pp. 75–99.

• Bronzini M., Cori E., Sarti D., Torre T. (2023), Isolamento professionale e inclusione nell’esperienza del lavoro da remoto durante la pandemia in Italia, PRISMA — Economia, Società, Lavoro, 1–2/2022, pp. 68–89, DOI 10.3280/PRI2022-001005 — scheda.

• Emanuel N., Harrington E., Pallais A. (2026), Home Alone: Remote Work, Isolation, and Mental Health, Science, 392, DOI 10.1126/science.aec7671 — scheda.

• Osservatorio Smart Working del Politecnico di Milano (2025), Lo Smart Working ai tempi dell’AI: opportunità e sfide verso il lavoro del futuro — comunicato stampa.

• Della Ratta-Rinaldi F. (a cura di) (2026), La sfida del lavoro da remoto. Evidenze sui focus group di manager pubblici e privati, INAPP Paper n. 62 — PDF.

• Fuggetta A., Un bel lavoro, Egea, 2023.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Di Vangelis conoscevo bene i suoi lavori da solista e sapevo del suo passato con gli Aphrodite’s Child. Del gruppo avevo in mente i singoli di successo che passavano sempre in radio quando ero ragazzo.

A questo album sono arrivato un pomeriggio scorrendo Progarchives. Il titolo, 666, la copertina rossa con il numero in nero, Apocalisse di Giovanni, testi di Costas Ferris. Ho cliccato perché non capivo cosa ci facesse lì, in mezzo ai dischi di prog britannico che stavo guardando.

Mi sono trovato davanti a un doppio album, ricco, complesso, maestoso, che non avrei mai immaginato di trovare nella produzione del gruppo di Spring, Summer, Winter and Fall.

Un’altra dimostrazione di quanto immenso sia il mondo della musica.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

1. Che cos’è una skill

Forse non ci sarebbe bisogno di dirlo, ma è comunque utile ricordarlo. Una skill è una procedura scritta che Claude può leggere ed eseguire. Tecnicamente è una cartella che contiene un file Markdown (SKILL.md) con istruzioni in linguaggio naturale, eventualmente accompagnato da file di riferimento (template, esempi, script ausiliari). È un manuale operativo, scritto una volta e riutilizzato a ogni invocazione.

Una skill ha tre caratteristiche:

• Un nome e una descrizione: il nome serve per invocarla, la descrizione indica a Claude quando attivarla automaticamente in base alle parole della richiesta.

• Istruzioni operative: cosa fare passo per passo, quali strumenti usare, in che ordine e con quali output.

• Memoria di contesto: regole specifiche del mio modo di lavorare, file da consultare prima di iniziare, formati standard da produrre.

Per esempio, quando dico a Claude “chiudiamo la giornata”, parte la skill daily-journal-evening: produce il log della giornata, estrae il pre-brief per domani da ClickUp, svuota la mia inbox personale. Quando gli chiedo “scrivi un post su X”, parte la skill post-writer che legge la mia guida di stile ed esegue la procedura interattiva per costruire la struttura argomentativa di un post per A bassa voce. La differenza con un prompt ad hoc è che, con un prompt, devo fornire ogni volta il contesto e la descrizione dell’output; con una skill il contesto è già presente e l’output è ripetibile.

2. Perché ho cominciato a costruirle

Tre ragioni, in ordine di importanza crescente.

La prima è il risparmio di tempo. Senza skill, ogni sessione comincia con cinque-dieci minuti di setup: spiegare chi sono, cosa sto facendo, quali file consultare, in che formato voglio l’output. Una skill assorbe tutto questo. Per la singola sessione il risparmio non è grande; sommato per le tante sessioni della settimana, vale parecchio tempo.

La seconda è la coerenza. I post di A bassa voce hanno una voce precisa: registro saggistico, struttura circolare, regole tipografiche, una lista di pattern AI da evitare. Senza skill, ogni volta che chiedo a Claude di aiutarmi con un draft, devo ricordargli, per esempio, che “cruciale” va tagliato, che le citazioni vanno verificate con un web fetch e che la nota di assistenza AI va in fondo al post. Con la skill post-writer queste regole vengono codificate una sola volta e applicate sistematicamente.

La terza è la più interessante e l’avevo sottovalutata. Costruire una skill mi costringe a scrivere per esteso una routine che fino a quel momento avevo solo in mente. Routine implicite: come strutturo un intervento, come gestisco la chiusura della giornata, come decido se un libro merita un post. Metterle nero su bianco le rende ripetibili, criticabili e migliorabili. Diverse delle mie skill sono nate per Claude e si sono trasformate nel manuale operativo del mio lavoro intellettuale, indipendentemente dall’AI.

3. Come ho organizzato il sistema

Oggi ho sedici skill personali (escluse quelle di sistema fornite con Claude per formati standard come pdf, xlsx, docx). Le ho raggruppate in quattro famiglie, per dominio funzionale.

Famiglia 1: Scrittura

Sette skill che coprono l’intero flusso di scrittura: Substack, libri, paper accademici e professionali.

• post-writer e abv-style-guide: l’assistente principale per i post argomentativi di A bassa voce, con la guida di stile letta in automatico.

• libro-della-settimana e album-della-settimana: le due rubriche brevi (100-200 parole), con regole proprie e titolo nel formato Autore — Opera (Anno).

• book-writer: la pipeline LaTeX per i miei progetti di libro, che include la compilazione e la gestione dei capitoli. Sono passato dal mio amato Scrivener a LaTeX perché così tutto il processo di scrittura è gestito tramite Claude. Spero che Scrivener fornisca al più presto un’interfaccia MCP nativa (ne esistono già di terze parti).

• paper-writer: articoli per riviste accademiche (ad esempio, CACM, IEEE Software) e professionali (ad esempio, Sloan Management Review, lavoce.info). Due sottotipi nella stessa skill.

• fact-check: verifica strutturata di un testo prima della pubblicazione: citazioni, dati, attribuzioni, stress test argomentativo.

Famiglia 2: Conoscenza personale

Due skill per gestire l’informazione che entra e che esce dal mio sistema.

• media-manager: la libreria di immagini (loghi, foto, screenshot) con una convenzione di denominazione e un indice ricercabile.

• substack-analytics: analisi delle performance di A bassa voce (open rate, engagement, registri che funzionano).

Famiglia 3: Attività quotidiane

Quattro skill per il lavoro operativo: gestione della giornata, riunioni, pubblicazione, manutenzione.

• daily-journal-evening: la routine serale di chiusura: log, pre-brief di domani da ClickUp, svuotamento dell’inbox personale.

• minutes-management: verbali di riunione su ClickUp, gestiti sia da Mac sia da mobile.

• post-publication: runbook dopo la pubblicazione di un post: aggiornamento degli stati ClickUp e scheduling dei lanci social via Buffer.

• workspace-housekeeping: audit periodico di coerenza del mio workspace (paths, template, ClickUp, cross-reference fra file).

Famiglia 4: Didattica e presentazioni

Tre skill per la docenza universitaria e per le presentazioni.

• exam-generator: generazione di temi d’esame del Politecnico, con soluzioni e griglie di correzione.

• presentation-designer: concezione e outline di una presentazione (dal taglio narrativo allo storyboard).

• slides-markdown: generazione di slide in formato Markdown (Deckset e compatibili) a partire da un documento sorgente.

Skill importate

Le sedici skill qui sopra le ho scritte io (insieme a Claude). Ne uso anche due di terze parti, integrate nel mio sistema:

• stop-slop: eliminazione dei pattern AI tipici (contrasti binari, falsa agency, avverbi riempitivi) da qualsiasi testo. Open-source, scritta da Hardik Pandya. La invoco come verifica finale con post-writer e fact-check.

• llm-wiki: costruzione e manutenzione di un wiki personale alimentato da LLM (ingest di articoli, ricerca, query, lint periodico). Open-source, ideata da Andrej Karpathy, la uso come knowledge base personale sul mio Mac oltre all’integrazione con Reader/Readwise.

4. Lo strato sotto: ClickUp e il filesystem

Le skill non vivono nel vuoto: si appoggiano a un task manager con liste, custom field, automazioni. Lo strumento è ClickUp (integrato via MCP). Ci sono arrivato passando per Todoist. ClickUp è molto più potente. La migrazione l’ho costruita con Claude: gli ho chiesto di esaminare come lavoravo in Todoist (progetti, etichette, filtri, routine ricorrenti) e gli ho detto cosa volevo ottenere in più e di diverso: gestire in modo integrato progetti, didattica, contenuti editoriali e operazioni quotidiane, senza saltare tra app diverse per attività dello stesso lavoro. Claude mi ha generato la prima versione del workspace: liste, gerarchie, custom field, automazioni. Io l’ho aggiustata in base all’uso che ne faccio. Oggi la manutengo insieme alle skill: se cambio un’automazione di ClickUp, spesso modifico anche una skill su cui ci si appoggia, e viceversa.

Il secondo strato è il filesystem dei miei documenti, organizzato con il metodo Johnny Decimal: una struttura ad albero numerata, in cui ogni area (10–19 Life admin, 20–29 Work docs) contiene categorie (21 Books, 22 Media, 26 Progetti…) e ciascuna categoria contiene progetti o asset trasversali. ClickUp e filesystem sono separati ma accoppiati: ogni task in ClickUp ha un custom field JD Reference che punta alla cartella corretta sul disco. Quando lavoro su un task, l’allegato fisico (PDF, draft, slide) è già nel posto giusto; quando archivio un task, non devo riorganizzare nulla.

5. Il workspace Claude

Accanto al filesystem JD vive una cartella separata, ~/Documents/Claude/ che non segue la numerazione di Johnny Decimal. È il workspace operativo delle skill: ciò che le skill leggono per sapere come comportarsi e ciò che scrivono come output intermedio o come archivio. Ha una struttura propria, articolata in tre strati.

Il primo strato è la configurazione. In root vivono i file .md che codificano le regole globali del mio sistema: CLAUDE.md (regole generali e gerarchia source-of-truth), TAXONOMY.md (tassonomia dei tipi di documento), jd-routing.md (mappa del sistema Johnny Decimal), typography-rules.md (corsivo, virgolette, formati dei titoli) e operations-reference.md (riferimento operativo cross-dominio). Ogni file ha un perimetro preciso e gli altri lo citano come fonte autoritativa.

Il secondo strato sono le cartelle di dominio, ciascuna con il proprio CLAUDE.md: Editorial System/ (hub editoriale), Social Manager/ (post Substack, LinkedIn, X), Libro/ (pipeline LaTeX), Productivity/ (daily log e routine), Presentations/, Wiki/, Esami-PoliMI/, ClickUp Management/ (con workspace-config.md come fonte autoritativa sulla struttura ClickUp). Quando una skill opera su un dominio, legge il CLAUDE.md di quel dominio per applicare le regole locali.

Il terzo strato è di supporto e archivi: Templates/, Skill Archive/, Dashboards/, Artifacts/, Scheduled/, più gli archivi storici (Archivio Medium/, Archivio Substack/, Archivio Meeting/, Music/, Gestione Spese/). Sono i materiali a cui le skill attingono o che producono, ma che non richiedono regole proprie.

La rete dei CLAUDE.md è il vero collante del sistema. È un’architettura volutamente decentralizzata: il CLAUDE.md di root non contiene tutto, ma coordina. Le regole specifiche stanno nei domini, e ogni volta che le tocco con una skill so dove andare a guardare.

6. Un sistema vivo

Nessuna di queste skill è scritta una volta per tutte. Le aggiorno e le arricchisco di continuo: ogni volta che un’esecuzione mi mostra che una regola manca, che un’istruzione è ambigua, che un caso non è previsto. È un approccio agile allo sviluppo delle skill: ogni uso reale è un piccolo test che mi dice cosa funziona e ogni correzione entra subito nel testo. Le skill più mature, come post-writer o daily-journal-evening, sono arrivate alla forma attuale dopo decine di iterazioni; le più giovani sono ancora in assestamento.

7. Cosa troverete nei prossimi post

Pubblicherò un post ogni due settimane circa, alternandolo agli altri contenuti della pubblicazione. La struttura sarà sempre la stessa: cosa fa la skill, in quali casi la uso, una sequenza di esempi reali, cosa funziona e cosa rifarei diversamente.

L’ordine sarà per famiglia, cominciando dalla scrittura: quella su cui ho iterato di più e che meglio mostra il rapporto fra una procedura scritta e una voce che resta riconoscibile. Ogni post sarà autocontenuto: si potrà leggere il pezzo su daily-journal-evening senza aver letto quello su post-writer.

Una nota di metodo. Le mie skill sono personali per costruzione, perché codificano il mio modo di lavorare. Non aspettatevi di copiarle e usarle come sono. Il valore di questa serie, se ce n’è uno, è mostrare che la categoria “skill” è accessibile a chiunque abbia voglia di scrivere una procedura. E che il sottoprodotto di scriverla, cioè capire come si lavora, vale spesso più dell’automazione che ne deriva.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Il post in tre frasi

1. Le imprese stanno investendo nell’AI a ritmi senza precedenti, ma non sanno se sta funzionando.

2. Le (principali) ragioni sono due, e si sovrappongono: dati e processi non pronti da una parte, metriche assenti dall’altra.

3. La via d’uscita non è operare solo sul fronte del taglio degli investimenti, ma ammettere che una parte cruciale del lavoro l’abbiamo saltata e che, senza quella, ogni numero sul ROI è un’opinione travestita da dato.

Alla ricerca di valore

C’è una frase che circola nelle scuole di marketing da oltre un secolo. È attribuita a John Wanamaker, pioniere del retail americano a cavallo tra l’Ottocento e il Novecento (sebbene l’attribuzione sia incerta). Suona così: “Metà del denaro che spendo in pubblicità è sprecata; il problema è che non so quale metà.”

Quando la sento citata, penso alle riunioni con i CEO e i CFO delle imprese italiane degli ultimi diciotto-ventiquattro mesi — riunioni in cui si parla di investimenti in AI, di pilot e di trasformazioni in corso. Wanamaker, almeno, aveva l’onestà di dirlo: spendo, una parte è sprecata, non so quale. Non so quanti dei CFO che ho incontrato lo direbbero con quella nettezza, ma sotto la superficie del racconto la stessa onestà fatica a emergere. La volontà di essere chiari c’è; mancano i dati per esserlo.

Vediamo perché.

Una fase concitata e una domanda scomoda

Il punto di partenza è duplice. Da una parte, l’AI è il fenomeno di investimento aziendale più rapido che ricordi. Dall’altra parte, quando si chiede al management “qual è stato l’effetto?”, la risposta più frequente è un’esitazione, una qualificazione, un rinvio. Non si tratta di un’impressione mia. Arriva da fonti diverse, tutte indipendenti e degli ultimi mesi.

Provo a leggere queste fonti da due punti di vista che mi sembrano i più produttivi.

1. Molti progetti sono partiti senza una base adeguata, perché i dati e i processi delle imprese non erano ancora pronti.

2. Anche dove la base c’è, non sappiamo quantificare i benefici, o perché non ci sono, o perché non siamo capaci di misurarli.

I due punti di vista non si escludono. Si rafforzano.

Progetti senza base: il problema sta nei dati e nei processi

La fonte più recente e più articolata è una survey di Bain & Company, ripresa da Bloomberg e commentata da Entrepreneur all’inizio di giugno. Il campione è solido: 951 grandi aziende in 9 settori.

AI is supposed to save companies billions. So far, it isn’t. […] Among companies measuring their AI savings, 40% saw reductions of just 10% or less. That’s well below what most were expecting.

In altre parole, quattro aziende su dieci, fra quelle che almeno provano a misurare, ottengono risparmi inferiori al 10% rispetto alle proiezioni. È un divario notevole, ma quel che mi colpisce di più viene subito dopo:

The disappointing returns matter because 44% of companies surveyed are funding their next wave of generative and agentic AI investments with those projected savings. Bain calls the strategy “a circular bet with a structural leak.”

“Una scommessa circolare con una falla strutturale.” La formulazione è di Bain stessa, non di una stampa allarmistica. Significa che quasi la metà delle imprese sta finanziando il prossimo round di investimenti in AI con risparmi proiettati dal round precedente, risparmi che, come abbiamo appena visto, si discostano dalle proiezioni. Quando una scommessa si autorifinanzia con un ritorno che non arriva, il problema e il rischio sono strutturali.

Bain pone una domanda che si poteva porre al centro del rapporto: perché i risparmi attesi non si materializzano? La risposta è la parte più importante del documento.

the No. 1 reason AI programs underperform isn’t budget or strategy. It’s that most companies’ data is so disorganized their AI can’t get to it. That problem, Bain warned, “should be making executives uncomfortable.”

I dati delle imprese sono talmente disorganizzati che l’AI non riesce ad accedervi. Bain dice che la cosa “dovrebbe mettere a disagio gli executive”. Sospetto che il disagio arrivi, quando arriva, troppo tardi, dopo che la spesa è già impegnata e i pilot sono già stati lanciati.

La lettura di Bain non è isolata. Maria Korolov, su CIO.com a fine giugno, ha pubblicato un’analisi sull’adozione dei data lakehouse come infrastruttura per l’AI aziendale.

L’idea di fondo è semplice: senza un livello dati unificato e accessibile, qualsiasi modello AI non funziona o funziona male. Prasad Pore, analista di Gartner, dichiara nell’articolo un tasso di adozione del 65% dei data lakehouse tra i clienti dell’azienda, “a very strong number in a short time”. Chi ha capito che, senza un livello dati unificato, l’AI non scala, sta riparando la fondazione. Chi non l’ha capito continua a costruire “case sulla sabbia”, come recita la parabola evangelica.

A questo aggiungerei una considerazione tratta dalla mia esperienza. I progetti AI che ho visto fallire non sono falliti per problemi del modello. Sono falliti perché le persone incaricate di farli funzionare non avevano le competenze e l’accesso ai dati nei tempi e nei formati richiesti. Quando il dato c’era, era distribuito su quattro sistemi diversi, con definizioni semantiche incompatibili, regole di aggiornamento asincrone, granularità differenti. Le riunioni di kickoff parlavano di prompt engineering. Sei mesi dopo si parlava di pipeline per l’acquisizione e l’organizzazione delle informazioni.

Misurare ciò che non si sa misurare

Il secondo punto di vista è più sottile e, secondo me, più interessante perché va oltre l’aspetto tecnico-infrastrutturale e raggiunge il cuore del funzionamento delle imprese. Anche laddove i dati esistono e i processi funzionano, le imprese faticano a stabilire se l’AI stia generando valore. Il caso più citato è uno studio del MIT Media Lab dell’estate scorsa (The GenAI Divide: State of AI in Business 2025, luglio 2025), ripreso a settembre 2025 da Harvard Business Review (HBR) in un articolo sui workslop:

a recent report from the MIT Media Lab found that 95% of organizations see no measurable return on their investment in these technologies.

La cifra del 95% è circolata molto e va presa con la cautela che il rapporto stesso indica: “non vedono un ritorno misurabile”. La distinzione è importante. Una cosa è dire che gli investimenti in AI non stanno producendo valore: un’altra, ben diversa, è dire che lo stanno producendo ma non siamo capaci di quantificarlo. Sono due situazioni che richiederebbero risposte diverse: nel primo caso, ripensare l’approccio; nel secondo, continuare a investire, dotandosi però degli strumenti per misurare ciò che già accade. Davanti a un board che chiede cifre, però, le due situazioni collassano in una sola: in entrambi i casi non si hanno numeri da portare e, in entrambi i casi, quanto affermato suona come “non sappiamo se sta funzionando”. La distinzione resta sostanziale, ma diventa inutilizzabile come argomento a sostegno del prossimo round di investimenti. La differenza c’è, conta e, nondimeno, scompare nel momento in cui dovrebbe pesare.

Una conferma indiretta arriva da una survey di Gartner condotta a fine 2025 (pubblicata a maggio 2026) e commentata da CIO Magazine:

Eighty percent of large enterprises surveyed by Gartner have reported workforce reductions after launching automation projects, with the average reduction between 1% and 15%. The IT analyst firm, however, has found no correlation between layoffs and AI ROI.

Otto grandi imprese su dieci hanno effettuato tagli di personale dopo aver avviato iniziative di automazione basate sull’AI. Nessuna correlazione, però, fra i tagli e il ROI. Helen Poitevin di Gartner lo dice in modo molto netto:

“You would anticipate that those who are getting the most ROI maybe then are able to cut the most, but that’s not what we see. […] There seems to be no link between laying people off and getting ROI from AI investments.”

È un punto su cui mi sono già soffermato a febbraio, parlando di AI-washing. La logica “meno teste = più ROI” trasforma un’aspettativa ancora da verificare in decisioni operative concrete: le imprese tagliano personale contando su risparmi che l’AI dovrebbe generare. Il rapporto di Gartner mostra che quei risparmi non si stanno materializzando e che, quando arrivano, non sono correlati ai tagli. Le decisioni, intanto, anticipano il dato che dovrebbe giustificarle.

HBR di giugno 2026, in un articolo dal titolo “How People Are Really Using AI in 2026” a firma di Marc Zao-Sanders, mette nero su bianco la stessa difficoltà:

Explicitly stated ROI like this is rare in the data we have—growth is more often claimed anecdotally.

I casi di ROI esplicito sono rari nei dati. Quando si trovano (sales/marketing, +20–30% di conversione su campagne testate con agenti AI ottimizzati), sono dichiarazioni aneddotiche più che evidenze sistematiche. Fuori da questi pochi casi, le affermazioni sul ROI dell’AI restano impressionistiche: parlano di sensazioni, mentre servirebbero misurazioni.

McKinsey, in un’analisi sull’AI paradox nei consumi europei, formalizza la difficoltà in una frase che vale come sintesi di tutto il filone:

[…] Boards want to understand where AI investments are going. CFOs want to see measurable returns. Strategy teams point to an expanding set of AI initiatives across marketing, customer experience, supply chain, and technology development. Yet when pressed on bottom-line impact, many organizations still give the same answer: It is too early to tell.

“It is too early to tell.” La frase appare cortese, ma è la confessione di un’incapacità di misurazione che si sblocca soltanto se, a un certo punto, si decide di costruire le metriche che oggi non esistono. Misurare l’AI guardando solo al costo dei token, alla latenza, all’utilizzo delle licenze e al numero di pilot in corso equivale a misurare l’output del sistema tecnico. L’outcome del business è un’altra cosa e si misura in modo ben diverso.

A febbraio scorso, in un post sullo sviluppo software assistito dall’AI, scrivevo che la produttività in quel dominio non è misurabile guardando soltanto alla fase di coding. La stessa logica vale, in scala, per l’impresa: la produttività dell’AI va misurata alla scala giusta, quella del processo o della catena di valore. Misurare solo la fase in cui il modello produce l’output è troppo poco; pretenderne gli effetti netti sull’EBIT aziendale è troppo. La granularità utile sta nel mezzo: la durata di un ciclo di vendita, il tempo di chiusura di una pratica, il numero di interventi necessari per completare un’istanza del processo.

Il “baratro della disillusione”

Resta una nota sulla curva del ciclo dell’hype di Gartner. The Economist ha pubblicato a dicembre, citando S&P Global, un dato alquanto significativo:

the share of companies abandoning most of their generative-AI pilot projects has risen to 42%, up from 17% last year.

Il 42% delle imprese ha abbandonato la maggior parte dei propri pilot generativi. Un anno prima era il 17%. La pendenza è netta. La collocazione sulla curva di Gartner del baratro della disillusione (trough of disillusionment) è netta e non sorprende: è un meccanismo empiricamente consolidato. Quel che mi interessa, però, è che il baratro è il momento in cui scoperchiamo i problemi che ho descritto sopra: i dati, i processi, le metriche. Chi resta dentro la curva, senza porsi la domanda del perché, non vede il ritorno e rischia di sospendere gli investimenti proprio mentre la vera maturazione potrebbe cominciare a dare i primi risultati. Chi si ferma a chiedersi perché e accetta la risposta scomoda, che riguarda dati, processi e metriche, può ripartire con un setup diverso e raggiungere il plateau di produttività con un vantaggio che oggi non si vede.

L’onestà intellettuale di cui abbiamo bisogno

Torno a Wanamaker per una sola riga. La sua frase ha attraversato un secolo perché contiene una postura: l’onestà intellettuale di chi sa di non sapere. Il problema è che facciamo finta di sapere. Le presentazioni dei vendor le fanno per mestiere; i board le fanno per fiducia; gli executive le fanno per inerzia, perché ammettere l’incertezza significa esporsi. L’unica cosa peggiore di non sapere quanto stiamo spendendo bene è raccontare che lo sappiamo.

Per questo la responsabilità non ricade interamente su una sola parte. Le imprese sono partite senza basi solide perché hanno operato in un mercato che premiava la fretta: vendor che hanno venduto risparmi rapidi, board che hanno chiesto numeri prima del tempo, una curva di hype che ha punito la prudenza. La trasformazione digitale saltata è responsabilità dell’impresa. Il contesto che l’ha resa visibile solo oggi è frutto di una responsabilità collettiva.

Per approfondire

[1] Bain & Company, Your AI Budget Is Growing. Your Returns Aren’t. Here’s Why, giugno 2026. https://www.bain.com/insights/your-ai-budget-is-growing-your-returns-arent-heres-why/

[2] Maria Korolov, “Data lakehouses are becoming foundations for enterprise AI”, CIO.com, giugno 2026. https://www.cio.com/article/4184051/data-lakehouses-are-becoming-foundations-for-enterprise-ai.html

[3] MIT NANDA (MIT Media Lab), The GenAI Divide: State of AI in Business 2025, luglio 2025 (release: 16 agosto 2025). https://nanda.media.mit.edu/ai_report_2025.pdf

[4] “AI-Generated ‘Workslop’ Is Destroying Productivity”, Harvard Business Review, settembre 2025 — riprende lo studio del MIT al punto [3]. https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity

[5] “AI-driven layoffs aren’t making business sense”, CIO, maggio 2026 — commenta la survey Gartner sui tagli del personale dopo l’automazione, con interventi di Helen Poitevin sul nesso tagli/ROI dell’AI. https://www.cio.com/article/4171054/ai-driven-layoffs-arent-making-business-sense.html

[6] Marc Zao-Sanders, “How People Are Really Using AI in 2026”, Harvard Business Review, giugno 2026. https://hbr.org/2026/06/how-people-are-really-using-ai-in-2026

[7] McKinsey & Company (QuantumBlack), The AI paradox in Europe’s consumer industries: More spending, elusive impact, 2026. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-ai-paradox-in-europes-consumer-industries-more-spending-elusive-impact

[8] The Economist, sulla quota di imprese che abbandonano i pilot generativi (42% nel 2025, 17% l’anno prima), citando S&P Global, dicembre 2025. Dato originale: S&P Global, “Generative AI shows rapid growth but yields mixed results”, ottobre 2025. https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Where Rivers Meet mi ha tenuto coinvolto fino alla fine. Your Brother’s Keeper non lo conoscevo; Gary Bartz neanche. Ho scoperto un musicista che ha suonato con Miles Davis e con altri grandi del jazz, e adesso ho molto da recuperare del suo percorso musicale.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it

Nel quadro di Putnam il lavoro non era nella lista delle attività umane erose. La vita sociale in ufficio era l’ambito che le persone sperimentavano cinque giorni su sette, in cui trascorrevano otto-dieci ore al giorno, in cui imparavano un mestiere e stringevano relazioni che spesso superavano la durata del loro impiego. Ricordate il film 9 to 5 con Dolly Parton, Lily Tomlin e Jane Fonda?

Ventisei anni dopo, il 17 giugno 2026, Emma Harrington e Natalia Emanuel hanno firmato sul New York Times un guest essay che chiude così: “Twenty-six years after Robert Putnam warned that Americans were bowling alone, many of us are now typing alone.”

La frase riconosce, da parte di due economiste del lavoro, che l’erosione descritta da Putnam si è manifestata anche nell’ultimo ambito in cui la cultura del tardo Novecento aveva dato per scontato che il legame sociale si formasse da sé.

Cosa dicono i dati

Harrington ed Emanuel, insieme ad Amanda Pallais, hanno appena pubblicato su Science uno studio basato su sondaggi condotti su oltre mezzo milione di lavoratori americani tra il 2011 e il 2024. Confrontano due popolazioni: chi svolge un lavoro tecnicamente svolgibile da remoto e chi svolge un lavoro che richiede la presenza fisica. Il primo gruppo, dal 2019 al 2024, ha triplicato il numero di giornate lavorate da casa. Le sue giornate sono diventate più solitarie: oggi l’84% dei remote worker trascorre l’intera giornata di lavoro da solo. Oltre la metà si sente meno connessa ai propri colleghi. Chi vive da solo ha visto il proprio benessere mentale calare del 20%, mentre per chi vive con un partner o con figli la salute mentale è rimasta sostanzialmente stabile. Il distress dei lavoratori in mansioni svolgibili da remoto è cresciuto del 7% rispetto al gruppo di controllo e tale incremento spiega circa un terzo dell'aumento dal 2011 al 2024 del distress mentale tra i lavoratori americani.

Cosa abbiamo demolito senza chiamarlo per nome

Il dato che mi ha colpito di più nel pezzo riguarda la sociologia, non la salute mentale. Citando la ricerca del Survey Center on American Life, Harrington ed Emanuel ricordano che l’ufficio è il luogo numero uno in cui gli adulti americani stringono nuove amicizie. Il sondaggio colloca l’ufficio davanti alla scuola, alle amicizie già esistenti, al vicinato, alla parrocchia, ai club e alle organizzazioni. Nessuno aveva progettato l’ufficio per quella funzione: è successo, di fatto, come sottoprodotto della convivenza forzata per otto ore al giorno. Per molti adulti, l’ufficio è lo spazio della vita in cui il legame si forma per default, senza doverlo decidere, organizzare, calendarizzare. La socialità per appuntamento raggiunge una quota ristretta: la socialità ambientale, quella che capita perché si è nello stesso posto a fare la stessa cosa, scala da sola.

In questa storia, anch’io devo fare un po’ di esame di coscienza. Quando ho riguardato il mio archivio per scrivere queste righe, ho trovato tre vecchi post su Medium. Nel novembre 2011 segnalavo con entusiasmo i primi risultati dello studio di Stanford sul telecommuting di Nicholas Bloom (il paper completo sarebbe arrivato nel 2013), intitolato “Finally, a Proper Study to Scientifically Show Telecommuting is More Productive”. Già allora nella citazione che riportavo dal pezzo originale, c’era un dettaglio che è opportuno ricordare: alcuni dipendenti di un’agenzia di viaggi cinese avevano rifiutato di passare al telelavoro perché apprezzavano il tempo trascorso a socializzare con i colleghi. Lo riportai come una nota di colore. Avevo il segnale davanti e non l’ho visto. Pochi mesi dopo, nel marzo 2012, segnalavo, con tono neutro-positivo, un sondaggio Wrike (di fine 2011) che indicava che l'83% dei lavoratori già lavorava da remoto almeno qualche ora a settimana. Ancora prima, nel 2007, avevo scritto un breve post intitolato Vorrei vedere come fanno i conti: dubitavo dei numeri sui risparmi di CO₂ attribuiti al telelavoro, ma non avevo pensato di chiedermi che cosa il telelavoro sottraesse. Allora nessuno se lo chiedeva, me incluso. Per quindici anni, quei segnali sono rimasti in archivio, mentre lo studio su Science di giugno 2026 li esplicita e li rende visibili.

E poi è arrivato il COVID. In Cefriel, quando l’emergenza si è conclusa, abbiamo definito una policy di smart working che riconosceva la centralità delle giornate in presenza: un modello di collaborazione, non un’autorizzazione permanente al lavoro da remoto. Era la direzione giusta, ma ho sbagliato a non aumentare la percentuale di giornate in ufficio una volta superato il momento critico: ciò che lo studio su Science misura oggi, all’epoca lo intuivo ma non ebbi il coraggio di concretizzarlo fino in fondo.

Nota: non lavoro più in Cefriel e al momento non so quali siano le policy su questo tema.

Perché non basta tornare indietro né bastano i rituali

Le autrici del pezzo NYT propongono una via d'uscita “soft”: ripristinare le interazioni informali e incidentali che il remote work ha eliminato, ridisegnare gli ambienti per favorire gli incontri spontanei, riconoscere il valore del “lavoro di connessione” negli incentivi aziendali. Sono interventi che hanno senso. Ma sono correttivi, non strutturali. E sono fragili per tre ragioni.

La prima: il prepandemia non era un paradiso e neanche oggi lo sarebbe. L’ufficio, dalle 9 alle 18, cinque giorni su cinque, insieme al tempo di viaggio, assorbe una parte significativa della nostra vita che non possiamo dedicare alla famiglia, agli amici, agli impegni personali. Il remote work libera ore di viaggio che alcune persone reinvestono in famiglia, hobby, relazioni fuori dal lavoro. Il bilancio aggregato resta però negativo e ricade soprattutto su chi vive da solo, chi non reinveste quelle ore in legami significativi. Il fatto che al modello prepandemia sia subentrato qualcosa di peggio non lo trasforma retroattivamente in un punto di equilibrio. Non c’è un 2019 a cui tornare con serenità.

La seconda: le pezze non scalano. Coffee chat, weekly one-on-one, sessioni di “team building” definiscono i momenti di vita sociale come un opt-in nell’organizzazione del lavoro, mentre nell’epoca dell’ufficio erano un opt-out. È una differenza decisiva. Quando una pratica è di default (cioè succede a tutti, sempre), funziona. Quando è opt-in (succede a chi se la ricorda, ha tempo e non ha già altri impegni), avviene nel 15-20% dei casi e poi scompare.

La terza: il danno misurato è troppo grande. Chi vive da solo perde un quinto del proprio benessere mentale. Non lo si risolve con qualche coffee chat settimanale.

Cosa significa per noi

Lo studio è americano, ma la dinamica descritta ha valenza generale. In Italia, tutto questo ci riguarda direttamente. Sulla carta, lo smart working italiano (L. 81/2017) è più ampio del remote work americano: autonomia, gestione per obiettivi, flessibilità di tempi e luoghi. Nella pratica, però, in molte organizzazioni si è ridotto a “lavorare da casa”, cioè a lavorare da remoto. Quando lo smart working scivola verso il remote-by-default, lo studio di Harrington, Emanuel e Pallais parla anche di noi. Non perché il nostro lavoro sia diverso, ma perché stiamo replicando le stesse scelte senza nemmeno il dibattito che le accompagna negli Stati Uniti.

La pubblica amministrazione è entrata nello smart working di massa nel marzo 2020 e da allora discute quasi soltanto della percentuale di giorni lavorati da casa, riducendo di fatto al remote work ciò che la legge aveva pensato come modello più ampio. Quasi nessuno discute la funzione relazionale del servizio pubblico, che è in larga parte un mestiere di mediazione tra cittadino e Stato e che richiede presenza non tanto fisica al cittadino quanto fisica tra colleghi che imparano quel mestiere guardandolo fare. L’università italiana è uscita dall’online del COVID senza ricostruire i meccanismi informali di formazione dell’identità accademica: la chiacchiera in dipartimento, il corridoio prima del seminario, la birra dopo. Sono pratiche che i senior ricordano e che i nuovi arrivati non hanno mai vissuto o solo marginalmente. Stiamo formando una generazione di ricercatori che non ha vissuto appieno il proprio lavoro come parte di una comunità. La consulenza, infine, ha fatto dell’ibrido la sua forma definitiva. “Ibrido” che, nella maggior parte dei casi, è remote-by-default mascherato da smart working, più qualche giornata dal cliente. Il mestiere del consulente è, prima di tutto, un mestiere di relazione, interna all’azienda, prima ancora che verso il committente. Smontare queste dinamiche è una perdita di capitale sociale che vedremo solo tra cinque o dieci anni, quando i senior di oggi cominceranno a uscire e coloro che li hanno sostituiti si scopriranno a corto di qualcosa che non hanno mai vissuto né sviluppato.

Adesso tocca a noi

Putnam aveva mostrato un’erosione che la cultura del suo tempo aveva faticato a leggere. Harrington, Emanuel e Pallais documentano una versione più dura della stessa storia. Da qui non si esce con un coffee chat settimanale, né con un nostalgico ritorno alle 9-18 di prima. Si esce riconoscendo che certi legami, quelli che tengono insieme una società, una professione, una vita, non si formano da soli nei modelli organizzativi costruiti negli ultimi cinque anni: vanno progettati e ripensati rimettendo al centro l’incontro e la vita in comune. Servono scelte aziendali, contrattuali e individuali che oggi quasi nessuno fa. Per anni l'ufficio produceva quelle dinamiche come sottoprodotto della giornata lavorativa, senza che nessuno dovesse occuparsene esplicitamente. Ora che non si producono più nella stessa forma, vanno costruite deliberatamente. Sono decisioni sui tempi e i modi del lavoro che, prese nel loro complesso, determinano se la prossima generazione vedrà la propria professione come un’esperienza di comunità o come una somma di contratti e dinamiche individuali.

Come al solito, Madame Realtà ci mette di fronte alle nostre responsabilità e al bisogno di scegliere.

Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.

Lascia un commento

© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it