ROI doesn't live in the model

A stalled AI project has an obvious-looking fix: swap the model for a better one. It rarely works. Gartner's own research points somewhere else entirely — return tracks how well the system is integrated, governed, and fitted to the work, not the sophistication of the model. If that is right, most of the money spent chasing a smarter model is being spent on the wrong link in the chain.

This essay makes one argument, and it is narrow. The value from an AI system is a property of the whole chain around the model, not of the model in isolation. A chain's throughput is set by its weakest link, and the weakest link is almost never the model. Drop a better model into an unchanged process and you have upgraded a part that was not the bottleneck.

The number does not move, and people are surprised that it does not.

The rule from the factory floor

The cleanest way to see this is a model built for a physical factory, decades before anyone shipped a language model into production. Eliyahu Goldratt and Jeff Cox laid it out in The Goal (North River Press, 1984): the Theory of Constraints. A system's throughput is set by a single constraint — the bottleneck — and improving anything that is not the bottleneck does nothing for output.

Goldratt's own line is worth keeping literal. "An hour lost at a bottleneck is an hour lost for the entire system. An hour saved at a non-bottleneck is a mirage." The mirage is the trap. Speed up a station that was never the limiting one and the local metric improves, the team feels productive, and the plant ships exactly as much as before.

Picture the plant he was describing. Machines feed one another in sequence, and one of them is slower than the rest. Speed up any machine except the slow one, and inventory just piles up in front of the bottleneck, which still releases work at its own unchanged pace. The plant's output is the bottleneck's output, full stop. Every improvement not aimed at it is motion without gain, busywork that shows on a local dashboard and nowhere on the shipping dock.

Now map it onto an AI system. The chain runs roughly: source data, access and permissions, integration into the systems where work happens, the model, its output, a path to action, and the people who have to adopt it. The model is one station on that line. If the constraint sits at integration or data or adoption, a stronger model is an hour saved at a non-bottleneck. It is real work, and it is a mirage.

There is a first-principles version of the same idea, and it comes from computing. Gene Amdahl gave it in 1967: the maximum speedup from improving one component is capped by the fraction of the system you did not improve. Even an infinite improvement to one part leaves the untouched fraction as a hard ceiling. The frame is from performance engineering, not from AI, so treat it as an analogy rather than a measurement.

The analogy is exact where it counts. Suppose the model accounts for a third of the value an AI system delivers. The figure is illustrative, not measured, and nobody has a credible number for it. Then a flawless model, perfect and free, lifts you by at most that third. The other two-thirds — integration, data, adoption — set the ceiling, and you cannot buy your way past them with weights.

The chain is worse than additive. Treat each stage as a yield. Say integration passes only 60% of the model's good outputs into a usable action, and people then act on only half of those. A perfect model now delivers 0.6 × 0.5 — thirty cents on the dollar of its own quality. The fractions are illustrative, and the exact numbers do not matter. The shape matters: non-model stages multiply, so two mediocre links downstream can swallow almost all of a great model's value. Upgrading the model raises the first term in a product whose later terms sit near zero. You sharpened the one number that was never the problem.

A third frame widens the lens from the chain to the whole system. Donella Meadows, in Thinking in Systems: A Primer (Chelsea Green, 2008), argues that a system's behaviour comes from its structure and its relationships, not from any single element. Swapping one component is, in her language, a low-leverage intervention. The high-leverage places to intervene are the flows of information, the rules, and the goals — the structure the model sits inside.

Meadows is careful, and honesty requires the caveat she insisted on. She presents her leverage points as a heuristic, and warns explicitly against treating them as a formula or a validated ranking. So take the direction, not a ladder to climb. The direction is enough: the model is a component, and components are where the leverage is lowest.

Why a better model doesn't move the number

Set the models aside and reason it out. Where, concretely, does an AI system create value? Not at the moment the model produces a good answer. At the moment that answer reaches a system, triggers an action, and someone trusts it enough to let it run. Everything before that is a demo.

That is the last-mile problem, borrowed from logistics and adapted to machine learning: the distance between a working prototype and a system that delivers value in production. The last mile is the most expensive stretch and the one where most projects break. MLOps exists as a discipline precisely to close it: integration, monitoring, retraining, and the path from output to action. The value is manufactured in that mile, which sits entirely downstream of the model.

So the chain has a structural feature that decides everything. Value accrues at the end, and the constraint usually sits before the model gets its say. ROI is a function of the whole pipeline, and a function dominated by its weakest term. The model is rarely that term.

This is not only a deduction. The survey evidence points the same way, from more than one direction.

Start with the anchor. Gartner surveyed 782 infrastructure and operations leaders across November and December 2025 and published on 7 April 2026. Melanie Freeze, a Director of Research at Gartner, framed the headline result directly: "ROI from AI is not driven by the sophistication of the model, but by how well the technology is integrated, governed, and aligned with real operational needs." One honesty note. Gartner's newsroom blocks automated access, so this wording comes from outlets that quoted the release — CIO and The Register among them — not from the primary page.

Read the failure side of that same survey and the pattern holds. Of the leaders reporting a failure, 57% blamed "expected too much, too fast" — an expectation problem, not a capability one. Roughly 38% named weak data quality and availability. On adoption, integration difficulty (48%) and lack of budget (50%) were the top barriers. Not one leading cause is "the model was not good enough."

The success side agrees by omission. Among leaders with a working use case, the credited factors were wiring AI into existing workflows and systems, full backing from business leadership, and cross-functional collaboration. No top success factor concerns the class, size, or vintage of the model. The people closest to the work locate their wins and losses in the process, and the model is not on either list.

A second, independent population reaches the same verdict. MIT's NANDA initiative, in The GenAI Divide: State of AI in Business 2025, names the main barrier a "learning gap" — the inability of firms to fold models into their own workflows, structures, and culture. As reported, the report is blunt: workflow integration, not model quality, is the real barrier. Different unit, different sample, same finding. (The often-quoted "95% of pilots" line from that report is a separate argument about denominators, dismantled in the 28% teardown.)

The model is the part everyone can see. That is exactly why it gets the blame it has not earned.

There is an incentive layer under the reflex, too. The model is the thing with a vendor, a price list, and a sales team, so it is the thing with someone paid to sell you the upgrade. Integration, data hygiene, and change management have no equivalent salesperson. Nobody cold-calls you about your permissions model or your onboarding flow. So the market pushes attention toward the one link in the chain that has a storefront, and away from the links that usually bind. The reflex is not only cognitive. Someone is paid to sustain it.

There is an economic foundation under all of this, and it predates the AI debate. Erik Brynjolfsson and Lorin Hitt spent the 2000s on the same point about information technology. Its value comes mostly from complementary organisational capital: redesigned processes, changed work practices, retraining. That capital is often worth far more than the technology itself, and much harder to measure. Their later work with Chad Syverson named the consequence: a productivity J-curve, where a general-purpose technology first depresses measured productivity while the complementary investments are built, and only later raises it.

Two cautions keep that honest. The data is about computers and IT from the 1990s and 2000s, so its transfer to language models is an analogy, strong but still an analogy. And "general-purpose technology" here is an economic category, not a product — do not read GPT as the model. With those flagged, the lesson is durable. The return on a general-purpose tool is a return on the reorganisation around it, and "no ROI yet" is sometimes the bottom of the J rather than a failure. Swapping the model does not dig you out of that trough.

Reading the constraint before you spend

None of this tells you where your constraint is. It tells you where to look first, and it warns you off the reflex. The reflex — buy a better model — is a bet that the model is the bottleneck, made without checking. Goldratt's whole method is the checking: find the constraint before you spend a cent improving anything.

Here is a diagnostic to find it. It is my own synthesis, not a Gartner finding or a Goldratt theorem, and it should be read as a framework rather than a measurement. Each question separates a model problem from a process problem before the budget moves.

The first four questions point away from the model far more often than toward it. That is the whole claim, restated as a procedure. If the model already performs on a clean, curated set and the system still fails, the model is not your problem, and a better one will fail the same way at the same station.

The order of investment follows from the same logic. Spend first on integration and the path to action. Then on data quality and availability. Then on adoption and the change management that makes people trust the output. Then on the governance of the budget itself — funding that reaches across business units instead of fragmenting inside them. The next model upgrade comes after all of that, unless the diagnostic's last row is the one that lit up.

Governance earns its place on that list for a reason that is easy to miss. Freeze points at how AI actually gets funded: "Today, many AI initiatives are still funded by individual business units. However, as AI infrastructure spending continues to rise, CEOs and CFOs need to play a more active role." Per-unit funding fragments the very things the whole chain shares: common data, common integration, common standards. The weak link there is an org chart, not an architecture, and no model upgrade touches it.

That ordering is not only my inference. Gartner published a second study on 16 April 2026, surveying 353 data-and-analytics and AI leaders. That is a different sample and a different construct from the 782 above, so the two should not be summed or conflated. Its finding: organisations with successful AI initiatives invest up to four times more, as a share of revenue, in data quality, governance, AI-ready people, and change management than those that fail. "Up to four times" is a ceiling, not an average. And only 39% of technology leaders were confident their current AI spend would improve the financials at all.

Read those two Gartner surveys together and the shape is clear. The winners are not the ones who bought the smartest model. They are the ones who spent, heavily, on everything the smart model needs to be useful.

Spending on the model is visible and fast. Spending on the process is slow and looks like overhead. The reflex favours the visible one, which is exactly why it is usually wrong.

A stalled project, walked through the chain

Abstract levers are cheap, so here is the diagnostic run once, concretely. A mid-size company builds an assistant to triage inbound support tickets. It reads each ticket, classifies it, drafts a reply, and routes it to the right queue. In the demo it is excellent. Six months later, deflection is flat and the team is quietly back to triaging by hand. The instinct in the room is to blame the model and ask for the next one.

Run the diagnostic instead of the purchase order. First question: does the model clear a curated gold set offline? Someone pulls two hundred historical tickets and runs them through, and the classifications come back 94% correct. The model can do the task. So the constraint is downstream, and a better model would be an hour saved at a non-bottleneck.

Now find the actual station. The tickets live in a helpdesk tool the assistant cannot write back into, so a human copies every draft by hand — and stops bothering by week three. That is an integration constraint, not a model one. The output has no action path, so it lands in a queue nobody works. Adoption dies for a reason that has nothing to do with answer quality.

The fix costs an engineer a fortnight, not a model licence. Wire the assistant's output into the helpdesk API so routing happens automatically. Log every action for the audit trail governance will ask for. Let the humans approve rather than retype. Deflection moves the following month, and the model that was "not good enough" is the same model, untouched.

Swap the constraint and the lesson holds. Suppose the assistant instead classified badly in production despite a clean demo. You check the input and find the live tickets arrive with attachments stripped and customer history missing — the model sees less than it saw in testing. That is a data-availability constraint. A stronger model reasons better over the same impoverished input and still misses, because you cannot reason your way to information that was never in the prompt.

The pattern generalises past this one case. When a working demo fails in production, the break is almost always at the seam between the model and the system, not inside the model. The demo runs in a clean room. Production runs in your real stack, with its permissions, its latency, its formats, and its people — and that is where throughput is actually decided.

When the model really is the constraint

A rule sold as universal is being sold dishonestly. Three limits matter enough that ignoring any one of them turns this argument against you.

One: sometimes the model genuinely is the bottleneck. If a task exceeds what the current generation can do, the model is the binding constraint. Goldratt's own logic then says to strengthen that link. Improving the actual constraint is the one move that raises throughput. Capability jumps are real. Reasoning models have unlocked tasks that were previously unsolvable; on ARC-AGI-2, a benchmark built to resist surface pattern-matching, scores have moved sharply upward in a single generation. Treat that as evidence a threshold exists, not as a conversion rate from model quality to ROI — capability benchmarks are sometimes marketing. The thesis was never "the model doesn't matter." It is "identify the real constraint," and occasionally the real constraint is the model.

How do you know you are in that row rather than fooling yourself? There is a clean test. Look for public evidence that some model of the current class already does your task — a paper, a benchmark, a shipped product. If it exists, the ceiling is not the model, and your work is downstream. If nothing of the kind exists anywhere, you may genuinely be early, and a stronger model is the honest lever.

Two: you can over-invest in process on a foundation that cannot hold it. Building integrations, data pipelines, and change programmes around a model that simply cannot do the task is the same error in reverse. You polish a non-bottleneck until the process is thicker and the throughput is still zero. It is the symmetric mistake to the endless model upgrade, and it wastes more money because process work is slower to unwind. The stop condition is a single test: before you build the scaffolding, prove that some model of this class can do the task on your gold set. If none can, you are not looking at a process problem yet.

Three: "it's the process, not the model" is a comfortable alibi. The same sentence that correctly redirects a team away from a pointless upgrade also excuses a department that does not want to change its process. If it is "not a model question," then it is "not our fault," and one can skip both the model evaluation and the workflow redesign. The thesis can justify inaction in either direction. You can watch it happen. One team whose assistant fails in production says "Gartner is right, it's a process problem," and uses the line to avoid ever testing whether a newer model would clear the task. Another team, handed the same sentence, keeps the broken workflow and blames the model forever. Same words, opposite excuse, identical result: nothing changes. The antidote is the diagnostic above, which refuses the general answer and forces you to name a specific constraint — this data feed, that missing action path, this team's refusal to adopt.

Hold the three limits together and a discipline falls out. The model is the constraint when no model of its class can do the task. The process is the constraint the rest of the time. And the way to tell them apart is a test on a gold set, not a preference for whichever answer lets you avoid work. The thesis here is a default, not a law. Defaults are for the common case, and the common case is a process problem — but the whole job is to check, because the expensive mistakes live in the exceptions.

One more limit belongs to the evidence itself, and it is the same discipline applied to the 28%. The Gartner anchor is a self-assessment survey of one corner of IT. The unit is the use case, success is declared rather than audited, and the population is I&O leaders, not the whole enterprise. Freeze's "not driven by the sophistication of the model" is the data author's interpretation of that survey, reported at second hand. It is a considered position from Gartner, not a controlled experiment that pitted model against process and measured the winner. It converges with MIT's independent finding and with the economics, which is worth something. It is not proof, and it should not be quoted as one.

Closing

A better model is the right answer to exactly one question: is the model the constraint? Ask it honestly, on a gold set, before the purchase order — and most of the time the answer is no. That "no" is not a dead end. It is a map to where the return has been sitting the whole time, one station downstream, unglamorous and unbought.

Sources

1. primaryEliyahu M. Goldratt & Jeff Cox, The Goal (North River Press, 1984) — the Theory of Constraints; throughput is set by the bottleneck, and improving a non-bottleneck is a mirage.
2. primaryGene M. Amdahl, "Validity of the Single Processor Approach to Achieving Large-Scale Computing Capabilities," AFIPS Conference Proceedings (1967) — the un-improved fraction caps the achievable speedup.
3. primaryDonella H. Meadows, Thinking in Systems: A Primer (Chelsea Green, 2008), and "Leverage Points: Places to Intervene in a System" (1999) — behaviour follows structure; leverage points offered as heuristic, not formula.
4. primaryErik Brynjolfsson & Lorin Hitt, "Beyond Computation: Information Technology, Organizational Transformation and Business Performance," Journal of Economic Perspectives 14(4):23–48 (2000) — IT value comes largely from complementary organisational capital.
5. primaryErik Brynjolfsson, Daniel Rock & Chad Syverson, "The Productivity J-Curve: How Intangibles Complement General Purpose Technologies," NBER Working Paper 25148 (2018) — measured productivity dips before it rises while complementary intangibles are built.
6. primaryGartner, AI Projects in I&O Stall Ahead of Meaningful ROI Returns (press release, 7 April 2026) — 782 I&O leaders; 28% of use cases fully succeed; the Freeze framing on integration, governance, and fit. (newsroom returned 403 to automated access; quotes and figures verified via the secondary outlets below)
7. primaryGartner, Organizations with Successful AI Initiatives Invest Up to Four Times More in Data and Analytics Foundations (press release, 16 April 2026) — 353 D&A/AI leaders; "up to four times" more in foundations; 39% confident of financial upside.
8. primaryMIT NANDA, The GenAI Divide: State of AI in Business 2025 — the "learning gap"; workflow integration, not model quality, as the real barrier.
9. secondaryCIO, AI often doesn't deliver ROI for IT departments either — verbatim Freeze quotes on model sophistication and per-business-unit funding.
10. secondaryThe Register, Only 28% of AI infrastructure projects fully pay off (7 April 2026) — sample, analyst, and headline figures.
11. secondaryBuilt In, Artificial Intelligence Has a "Last Mile" Problem — framing of MLOps and the last-mile gap between prototype and production.
12. secondaryRCR Wireless, 7 takeaways from the GenAI Divide (MIT NANDA) — secondary framing of the "learning gap" and workflow-integration finding.

ROI nie mieszka w modelu

Zablokowany projekt AI ma poprawkę, która wygląda na oczywistą: podmienić model na lepszy. Rzadko pomaga. Z badań samego Gartnera wynika co innego: zwrot zależy od tego, jak system jest wpięty w firmę, kto nad nim panuje i czy pasuje do pracy, a nie od wyrafinowania modelu. Jeśli tak jest, większość pieniędzy wydanych w pogoni za mądrzejszym modelem trafia w niewłaściwe ogniwo łańcucha.

Teza tego eseju jest jedna i wąska. Wartość systemu AI powstaje w całym łańcuchu wokół modelu, a nie w samym modelu. Przepustowość łańcucha wyznacza najsłabsze ogniwo i tym ogniwem prawie nigdy nie jest model. Wstawiasz lepszy model w niezmieniony proces i ulepszasz część, która nie była wąskim gardłem.

Liczba nie drgnie, a ludzi to szczerze zaskakuje.

Goldratt: o wyniku systemu decyduje jedno stanowisko

Najlepiej widać to na modelu zbudowanym dla zwykłej fabryki, dekady przed pierwszym modelem językowym na produkcji. Eliyahu Goldratt i Jeff Cox wyłożyli go w The Goal (North River Press, 1984) jako Teorię Ograniczeń: przepustowość systemu wyznacza jedno ograniczenie, czyli wąskie gardło, a poprawianie czegokolwiek innego nie zmienia wyniku.

Zdanie Goldratta warto zostawić dosłownie. „Godzina stracona w wąskim gardle to godzina stracona dla całego systemu. Godzina zaoszczędzona poza wąskim gardłem to miraż". Przyśpiesz maszynę, która nigdy nie ograniczała linii, a materiał zacznie się piętrzyć przed wolną maszyną, bo ta wypuszcza pracę w swoim niezmienionym tempie. Lokalny wskaźnik pójdzie w górę, zespół poczuje się produktywny, a hala wyśle tyle samo co przedtem.

Przełóż to na system AI. Łańcuch wygląda mniej więcej tak: dane źródłowe, dostęp i uprawnienia, integracja z systemami, w których toczy się praca, model, jego wyjście, ścieżka do działania, wreszcie ludzie, którzy mają z tego korzystać. Model jest jednym stanowiskiem na tej linii. Kiedy ograniczenie leży w integracji, w danych albo w przyjęciu przez ludzi, mocniejszy model daje godzinę zaoszczędzoną poza wąskim gardłem. Praca jest prawdziwa, zysku z niej nie ma.

Tę samą myśl wyprowadził od pierwszych zasad Gene Amdahl w 1967 roku, tyle że dla komputerów: maksymalne przyśpieszenie z poprawy jednego elementu ogranicza ta część systemu, której nie ruszyłeś. Nawet nieskończona poprawa jednej części zostawia resztę jako twardy sufit. Amdahl liczył wydajność maszyn, nie zwrot z AI, więc bierz to jako analogię.

Załóżmy, że model odpowiada za jedną trzecią wartości, którą dowozi system AI; ta jedna trzecia jest poglądowa, bo nikt nie ma tu wiarygodnego pomiaru. Nawet doskonały i darmowy model podnosi wtedy wynik najwyżej o tyle. W praktyce jest gorzej, bo etapy poza modelem się mnożą, zamiast dodawać. Jeśli integracja zamienia w użyteczne działanie 60% dobrych odpowiedzi, a ludzie korzystają z połowy tego, co zostanie, doskonały model dowozi 0,6 × 0,5, czyli trzydzieści groszy z każdej złotówki własnej jakości. Ułamki są poglądowe, znaczenie ma kształt: dwa mierne ogniwa dalej w łańcuchu połkną niemal całą wartość świetnego modelu, bo wymiana modelu podnosi pierwszy czynnik w iloczynie, którego dalsze czynniki leżą przy zerze.

Trzecie ujęcie wychodzi poza łańcuch, na cały system. Donella Meadows w Thinking in Systems: A Primer (Chelsea Green, 2008) dowodzi, że zachowanie systemu wynika z jego struktury i z relacji między częściami. Podmiana komponentu ma w jej języku słabą dźwignię; mocna leży w przepływach informacji, w regułach i w celach. Meadows jest przy tym ostrożna: punkty dźwigni podaje jako heurystykę i wprost odradza traktowanie ich jak wzoru albo rankingu. Zostaje kierunek, bez obietnicy, że któryś punkt zadziała akurat u ciebie.

Wartość powstaje na ostatniej mili

Odłóż na chwilę modele i wyprowadź to sam. Gdzie system AI tworzy wartość? Nie w chwili, w której model produkuje dobrą odpowiedź, tylko wtedy, gdy ta odpowiedź trafia do systemu, uruchamia działanie i ktoś ufa jej na tyle, żeby pozwolić temu działaniu pójść dalej. Wszystko wcześniej to demo.

Tak wygląda problem ostatniej mili, pożyczony z logistyki i przeniesiony na uczenie maszynowe: odległość między działającym prototypem a systemem, który dowozi wartość na produkcji. To najdroższy odcinek i na nim łamie się większość projektów. MLOps powstał właśnie po to, żeby ten odcinek domknąć: integracja, monitoring, dotrenowywanie, ścieżka od wyjścia do działania. Wartość wykuwa się na tym odcinku, a odcinek zaczyna się za modelem. Zwrot jest więc funkcją całego łańcucha, w której dominuje najsłabszy człon, a model bywa nim rzadko.

Ten wniosek nie stoi na samym rozumowaniu. Dane ankietowe prowadzą w tę samą stronę i pochodzą z kilku niezależnych źródeł.

Gartner przepytał 782 liderów infrastruktury i operacji w listopadzie i grudniu 2025 roku, a wyniki ogłosił 7 kwietnia 2026. Melanie Freeze, Director of Research w Gartnerze, ujęła główny wniosek wprost: „ROI z AI nie napędza wyrafinowanie modelu, lecz to, jak dobrze technologia jest zintegrowana, objęta governance i dopasowana do realnych potrzeb operacyjnych". Newsroom Gartnera blokuje dostęp automatyczny, więc to sformułowanie mam z serwisów, które cytowały komunikat, m.in. z CIO i The Register, a nie ze strony pierwotnej.

Strona porażek trzyma ten sam wzorzec. Wśród liderów zgłaszających porażkę 57% wskazało „oczekiwaliśmy za dużo, za szybko", czyli problem oczekiwań, nie zdolności technologii. Około 38% wymieniło słabą jakość i dostępność danych. Przy wdrażaniu największymi barierami okazały się trudność integracji (48%) i brak budżetu (50%). Na liście głównych przyczyn nie ma zdania „model był za słaby".

Strona sukcesów mówi to samo przez przemilczenie. Liderzy, u których zastosowanie AI zadziałało, przypisali zasługę wpięciu AI w istniejące procesy i systemy, pełnemu poparciu kierownictwa biznesu oraz współpracy między działami. Żaden z czołowych czynników sukcesu nie dotyczy klasy, rozmiaru ani rocznika modelu.

Druga, niezależna próba dochodzi do tego samego. Inicjatywa NANDA z MIT w raporcie The GenAI Divide: State of AI in Business 2025 nazywa główną barierę „luką w uczeniu się", czyli niezdolnością firm do wpięcia modeli we własne procesy, struktury i kulturę. Serwisy referujące raport, m.in. RCR Wireless, streszczają to bez ogródek: prawdziwą barierą jest integracja z procesem pracy, a nie jakość modelu. Cytowane co chwilę zdanie o „95% pilotaży" z tego samego raportu to osobny spór o mianowniki, rozebrany w rozbiórce 28%.

Model widzą wszyscy i dlatego zbiera winę, na którą nie zasłużył. Pod tym odruchem pracują jeszcze bodźce: model ma dostawcę, cennik i zespół sprzedaży, więc ma kogoś opłacanego za sprzedanie ci nowszej wersji. Integracja, higiena danych i zarządzanie zmianą nie mają swojego handlowca; nikt nie dzwoni na zimno w sprawie modelu uprawnień. Rynek kieruje uwagę na jedyne ogniwo, które ma witrynę sklepową.

Pod całą sprawą leży fundament ekonomiczny starszy niż spór o AI. Erik Brynjolfsson i Lorin Hitt przez lata dwutysięczne dowodzili tego samego o technologii informacyjnej: jej wartość bierze się głównie z komplementarnego kapitału organizacyjnego, czyli z przeprojektowanych procesów, zmienionych praktyk pracy i przeszkolenia ludzi. Ten kapitał bywa wart więcej niż sama technologia i jest znacznie trudniejszy do zmierzenia. Późniejsza praca Brynjolfssona z Danielem Rockiem i Chadem Syversonem nazwała skutek krzywą J produktywności: technologia ogólnego przeznaczenia najpierw obniża mierzoną produktywność, bo firma dopiero buduje inwestycje komplementarne, a podnosi ją potem.

Dwa zastrzeżenia trzymają to w ryzach. Dane dotyczą komputerów i IT z lat 90. i dwutysięcznych, więc przeniesienie ich na modele językowe pozostaje analogią, mocną, ale wciąż analogią. Osobno: „technologia ogólnego przeznaczenia" jest tu kategorią ekonomiczną, a nie produktem, i skrótu GPT nie czytaj jako nazwy modelu. Lekcja trzyma się mimo to. Zwrot z narzędzia ogólnego przeznaczenia jest zwrotem z reorganizacji wokół niego, a „na razie brak ROI" bywa dnem krzywej J, z którego podmiana modelu nie wyciąga.

Znajdź ograniczenie, zanim ruszy budżet

Nic z tego nie mówi, gdzie leży twoje ograniczenie. Mówi, gdzie szukać najpierw, i odciąga od odruchu. Odruch — zakup lepszego modelu — jest zakładem, że wąskim gardłem jest model, postawionym bez sprawdzenia. Cała metoda Goldratta polega na sprawdzeniu: najpierw znajdujesz ograniczenie, potem wydajesz pierwszy grosz.

Poniższa diagnostyka to moja synteza, nie ustalenie Gartnera ani twierdzenie Goldratta; czytaj ją jako ramę, a nie pomiar. Każdy wiersz oddziela problem modelu od problemu procesu, zanim ruszy budżet.

Pierwsze cztery wiersze kierują cię od modelu znacznie częściej niż ku niemu. Jeśli model radzi sobie na czystym, wyselekcjonowanym zestawie, a system i tak zawodzi, mocniejszy polegnie na tym samym stanowisku.

Kolejność wydatków wynika z tej samej logiki. Najpierw integracja i ścieżka do działania. Potem jakość i dostępność danych. Potem przyjęcie i zarządzanie zmianą, dzięki któremu ludzie zaczynają ufać wyjściu. Potem governance samego budżetu, czyli finansowanie, które sięga w poprzek jednostek biznesowych, zamiast rozdrabniać się w każdej z osobna. Wymiana modelu przychodzi po tym wszystkim, chyba że zapalił się ostatni wiersz diagnostyki.

Governance trafia na tę listę z powodu, który łatwo przeoczyć. Freeze wskazuje, kto dziś płaci za AI: „Dziś wiele inicjatyw AI wciąż finansują pojedyncze jednostki biznesowe. Ale gdy wydatki na infrastrukturę AI rosną, CEO i CFO muszą odegrać aktywniejszą rolę". Finansowanie osobno w każdej jednostce rozdrabnia to, co cały łańcuch ma wspólne: dane z integracją i wspólne standardy. Słabym ogniwem jest wtedy schemat organizacyjny, a nie architektura, i żadna wymiana modelu tego nie tknie.

Tę kolejność potwierdza drugie badanie. Gartner ogłosił je 16 kwietnia 2026 i przepytał w nim 353 liderów: z obszaru danych i analityki oraz z AI. To inna próba i inny konstrukt niż tamte 782 osoby, więc obu badań nie należy sumować. Organizacje z udanymi inicjatywami AI inwestują w jakość danych, governance, ludzi gotowych na AI i zarządzanie zmianą do czterech razy więcej — licząc jako udział w przychodzie — niż organizacje, którym nie wychodzi. „Do czterech razy" jest sufitem, nie średnią. Tylko 39% liderów technologii było przy tym przekonanych, że ich obecne wydatki na AI w ogóle poprawią wyniki finansowe.

Obie ankiety razem układają się w jeden obraz: wygrywają organizacje, które wydały dużo na wszystko, czego mądry model potrzebuje, żeby był użyteczny. Zakup najmądrzejszego modelu w tym opisie się nie pojawia. Wydatek na model widać od razu, wydatek na proces schodzi wolno i w księgach wygląda na koszt ogólny, a odruch faworyzuje ten pierwszy.

Jeden przypadek: asystent do zgłoszeń

Abstrakcyjne dźwignie są tanie, więc puśćmy tę diagnostykę raz, na konkrecie. Średniej wielkości firma buduje asystenta do segregowania napływających zgłoszeń wsparcia: czyta zgłoszenie, klasyfikuje je, szkicuje odpowiedź i kieruje do właściwej kolejki. W demie wypada znakomicie. Pół roku później odsetek zgłoszeń zamykanych bez człowieka stoi w miejscu, a zespół po cichu wrócił do ręcznej segregacji. Odruch na sali brzmi: obwinić model i poprosić o następny.

Zamiast zamówienia puszczamy diagnostykę. Czy model przechodzi wyselekcjonowany zestaw wzorcowy offline? Ktoś bierze dwieście historycznych zgłoszeń i przepuszcza je przez asystenta. Wynik: 94% poprawnych klasyfikacji. Model potrafi wykonać zadanie, więc ograniczenie leży dalej.

System obsługi zgłoszeń nie przyjmuje zapisu od asystenta, więc człowiek przekleja każdy szkic ręcznie i przestaje się z tym męczyć w trzecim tygodniu. To ograniczenie integracji. Wyjście nie ma ścieżki działania, ląduje w kolejce, której nikt nie obsługuje, a przyjęcie umiera z powodu niemającego nic wspólnego z jakością odpowiedzi.

Naprawa kosztuje dwa tygodnie pracy inżyniera, nie licencję na model. Wpinasz wyjście asystenta w API systemu obsługi zgłoszeń, żeby kierowanie działo się samo. Logujesz każde działanie na potrzeby śladu audytowego, o który upomni się governance. Pozwalasz ludziom zatwierdzać, zamiast przepisywać. Odsetek zgłoszeń zamykanych bez człowieka rusza w następnym miesiącu, przy modelu, którego nikt nie tknął.

Zmień ograniczenie, a lekcja zostaje ta sama. Załóżmy, że asystent klasyfikuje źle na produkcji mimo czystego demo. Sprawdzasz wejście i widzisz, że zgłoszenia na żywo przychodzą bez załączników i bez historii klienta, więc model widzi mniej, niż widział w testach. To ograniczenie dostępności danych: mocniejszy model rozumuje lepiej nad tym samym zubożonym wejściem i wciąż chybia, bo z rozumowania nie da się wydobyć informacji, której nigdy nie dostał.

Kiedy działające demo zawodzi na produkcji, pęknięcie leży niemal zawsze na szwie między modelem a systemem. Demo pracuje w czystym pokoju, produkcja w twojej realnej infrastrukturze, z jej uprawnieniami, opóźnieniami, formatami i ludźmi, i to tam rozstrzyga się przepustowość.

Granice tej reguły

Reguła sprzedawana jako uniwersalna jest sprzedawana nieuczciwie. Moja pęka w kilku miejscach i wypada je nazwać.

Czasem model naprawdę jest wąskim gardłem. Kiedy zadanie przekracza możliwości obecnej generacji, model staje się ograniczeniem wiążącym, a logika samego Goldratta każe wzmocnić właśnie to ogniwo. Skoki zdolności zdarzają się naprawdę: modele rozumujące otworzyły zadania wcześniej nierozwiązywalne, a na ARC-AGI-2, benchmarku zbudowanym tak, żeby opierał się powierzchownemu dopasowaniu wzorców, wyniki poszły ostro w górę w ciągu jednej generacji. Bierz to jako dowód, że próg istnieje, a nie jako kurs wymiany jakości modelu na zwrot, bo benchmarki zdolności bywają marketingiem. Teza tego eseju każe zidentyfikować prawdziwe ograniczenie, którym czasem jest model.

Skąd wiadomo, że jesteś w tym wierszu, a nie oszukujesz sam siebie? Poszukaj publicznego dowodu, że jakiś model obecnej klasy już wykonuje twoje zadanie: pracy naukowej, benchmarku, wdrożonego produktu. Jeśli taki dowód istnieje, sufitem nie jest model. Jeśli nie istnieje nigdzie, możesz być naprawdę wcześnie i mocniejszy model jest wtedy uczciwą dźwignią.

Da się też przeinwestować w proces na fundamencie, który tego nie udźwignie. Rozbudowywanie integracji i przepływów danych wokół modelu, który nie umie wykonać zadania, jest tym samym błędem, tylko odwróconym — a doklejanie do tego programów zmiany niczego nie ratuje. Polerujesz stanowisko, które nie ogranicza linii; proces robi się grubszy, a przepustowość zostaje przy zerze. Kosztuje to więcej niż niekończąca się wymiana modelu, bo pracę nad procesem trudniej odkręcić. Zanim postawisz rusztowanie, udowodnij, że jakiś model tej klasy wykonuje zadanie na twoim zestawie wzorcowym.

Najgroźniejsze jest to, że zdanie „to proces, a nie model" bywa wygodnym alibi. Słusznie odciąga zespół od bezsensownej wymiany modelu, ale równie dobrze usprawiedliwia dział, który nie chce ruszyć własnego procesu. Skoro „to nie kwestia modelu", to „nie nasza wina", i można pominąć zarówno ewaluację modelu, jak i przeprojektowanie pracy. Jeden zespół powie „Gartner ma rację, to problem procesu" i nigdy nie sprawdzi nowszego modelu; drugi zostawi zepsuty proces i będzie obwiniał model. Te same słowa, przeciwne alibi, skutek identyczny. Antidotum jest diagnostyka wyżej, bo każe nazwać konkretne ograniczenie: ten strumień danych, tę brakującą ścieżkę działania, opór tego zespołu.

Dyscyplina jest z tego prosta. Model jest ograniczeniem, kiedy żaden model jego klasy nie wykonuje zadania; przez resztę czasu ograniczeniem jest proces. Rozróżnia je test na zestawie wzorcowym, a nie upodobanie do odpowiedzi, która pozwala uniknąć pracy. Teza jest tu regułą domyślną, nie prawem, a kosztowne pomyłki mieszkają w wyjątkach.

Jedno zastrzeżenie należy jeszcze do samego dowodu, czyli ta sama dyscyplina przyłożona do 28%. Badanie Gartnera, na którym się opieram, jest ankietą samooceny z jednego zakątka IT: jednostką pomiaru jest zastosowanie, sukces bywa deklarowany, nie audytowany, a populacją są liderzy infrastruktury i operacji, nie całe przedsiębiorstwo. Zdanie Freeze o wyrafinowaniu modelu jest interpretacją autorki danych, w dodatku podaną z drugiej ręki. To przemyślane stanowisko Gartnera, a nie eksperyment, który zderzył model z procesem i zmierzył zwycięzcę. Zbieżność z niezależnym wynikiem MIT i z ekonomią ma jakąś wartość, ale dowodem to nie jest i jako dowód cytowane być nie powinno.

Jedno pytanie przed zamówieniem

Lepszy model jest właściwą odpowiedzią na jedno pytanie: czy to model jest ograniczeniem? Pytanie zadaje się uczciwie, na zestawie wzorcowym, przed złożeniem zamówienia, i przez większość czasu odpowiedź brzmi „nie". Wtedy warto wrócić do asystenta od zgłoszeń. Zwrot leżał tam przez cały czas, w API systemu obsługi zgłoszeń, do którego nikt nie wpiął wyjścia. Dwa tygodnie pracy inżyniera, żadnej faktury od dostawcy, i nikt tego nie sprzeda, bo nie ma tam czego sprzedawać.

Bibliografia

1. primaryEliyahu M. Goldratt & Jeff Cox, The Goal (North River Press, 1984) — Teoria Ograniczeń; przepustowość wyznacza wąskie gardło, a poprawa poza nim to miraż.
2. primaryGene M. Amdahl, „Validity of the Single Processor Approach to Achieving Large-Scale Computing Capabilities", AFIPS Conference Proceedings (1967) — niepoprawiona część systemu ogranicza osiągalne przyśpieszenie.
3. primaryDonella H. Meadows, Thinking in Systems: A Primer (Chelsea Green, 2008) oraz „Leverage Points: Places to Intervene in a System" (1999) — zachowanie wynika ze struktury; punkty dźwigni podane jako heurystyka, nie wzór.
4. primaryErik Brynjolfsson & Lorin Hitt, „Beyond Computation: Information Technology, Organizational Transformation and Business Performance", Journal of Economic Perspectives 14(4):23–48 (2000) — wartość IT bierze się głównie z komplementarnego kapitału organizacyjnego.
5. primaryErik Brynjolfsson, Daniel Rock & Chad Syverson, „The Productivity J-Curve: How Intangibles Complement General Purpose Technologies", NBER Working Paper 25148 (2018) — mierzona produktywność najpierw spada, potem rośnie, gdy budują się komplementarne wartości niematerialne.
6. primaryGartner, AI Projects in I&O Stall Ahead of Meaningful ROI Returns (komunikat prasowy, 7 kwietnia 2026) — 782 liderów I&O; 28% zastosowań w pełni się udaje; ujęcie Freeze o integracji, governance i dopasowaniu. (newsroom zwrócił 403 przy dostępie automatycznym; cytaty i liczby zweryfikowane przez źródła wtórne poniżej)
7. primaryGartner, Organizations with Successful AI Initiatives Invest Up to Four Times More in Data and Analytics Foundations (komunikat prasowy, 16 kwietnia 2026) — 353 liderów D&A/AI; „do czterech razy" więcej w fundamenty; 39% przekonanych o korzyści finansowej.
8. primaryMIT NANDA, The GenAI Divide: State of AI in Business 2025 — „luka w uczeniu się"; prawdziwą barierą jest integracja z procesem pracy, nie jakość modelu.
9. secondaryCIO, AI often doesn't deliver ROI for IT departments either — dosłowne cytaty Freeze o wyrafinowaniu modelu i finansowaniu per jednostka biznesowa.
10. secondaryThe Register, Only 28% of AI infrastructure projects fully pay off (7 kwietnia 2026) — próba, analityczka i liczby z nagłówka.
11. secondaryBuilt In, Artificial Intelligence Has a "Last Mile" Problem — ujęcie MLOps i luki ostatniej mili między prototypem a produkcją.
12. secondaryRCR Wireless, 7 takeaways from the GenAI Divide (MIT NANDA) — wtórne ujęcie „luki w uczeniu się" i wniosku o integracji z procesem.