Build vs. Buy bei KI-Workflow-Automatisierung: Wann eine Plattform reicht und wann nicht

Build vs Buy for AI Workflow Automation Is the Wrong First Question

Every vendor evaluation for AI workflow automation eventually arrives at the same fork: buy a platform licence and configure it, or build something on top of the systems you already run. Both camps have a convincing deck. The platform vendor shows a demo that automates a clean, well-formed version of your process in an afternoon. The build camp shows a diagram of your actual stack with arrows into a new box. Neither deck answers the question that decides whether the money comes back, which is: how much of this workflow needs a model at all?

That question has a measurable answer, and the answer is usually a small number. In one European manufacturer's order-handling workflow that SUPALABS mapped step by step, three of eleven steps genuinely needed a model. The other eight were parsing, lookups, validation and routing, work that ordinary software does more cheaply, faster, and with an answer you can reproduce tomorrow (SUPALABS engagement data, 2024–2026). Once you know that number for your own process, the build-versus-buy decision mostly makes itself, because a platform is priced as if every step were the hard kind.

Why the Platform Demo Works and the Rollout Does Not

The platform demo works because it is run on the documented process. Ask a company what step one of order handling is and you will be told "an email arrives." That is true and useless. The real step one is forty senders, no two alike, some with the order in the body, some in an attached PDF, some in a spreadsheet that changes columns every quarter, and one large customer who phones and expects the rep to type it. The demo automates the first version. The rollout meets the second.

This is the pattern behind the MIT figure. The NANDA study interviewed 52 executives, surveyed 153 leaders and analysed 300 public deployments, and concluded that the divide between the 5% that create value and the 95% that do not is not talent, infrastructure or regulation. It is the absence of learning, integration and contextual adaptation: the system does not retain feedback, does not fit the workflow it was dropped into, and does not know the exceptions that make the workflow real. A platform licence does not fix any of that on its own, because the vendor never saw your exceptions. Neither does an in-house build, if the build starts from the same documented process the demo did.

The practical consequence is that the choice between buying and building matters less than what precedes it: a written account of how the workflow actually runs, exception by exception, before any money is committed. We have written separately about why the documented process is never the real process; the build-versus-buy decision is where that gap becomes expensive.

When Buying a Platform Is the Right Answer

Platforms earn their licence in a specific set of conditions, and it is worth stating them plainly rather than pretending a build is always better. Buy when:

• The workflow is regular and the inputs are already structured. Invoices arriving through Italy's SDI exchange system, tickets from a helpdesk with mandatory fields, orders from a B2B portal with a fixed schema. When the data is clean on arrival, a platform's connector and rules engine can carry the work, and the model-shaped parts are small enough to configure.
• The platform's native connectors cover the systems you actually run. Not "has an API" but "has a maintained connector for this ERP version, this CRM, this document store." The gap between those two is where most rollouts stall.
• Volume is high and variance is low. Ten thousand identical transactions a month reward a licence; two hundred transactions with two hundred shapes do not.
• You need to find out cheaply whether the idea is real. A month of licence fees to discover that the process is not what anyone thought is a good trade. The trap is staying on the licence after that month has answered the question.

A platform used this way is a measurement tool as much as a product. The mistake is treating the licence as the destination rather than the experiment.

When Building Is the Right Answer

Build when the exceptions are the process. That sounds like a slogan, so here is the test. Sit beside the person who runs the workflow for a day and write down every time the documented path is not the path taken: the customer who sends orders as a photo of a handwritten note, the supplier invoice that references a purchase order number that does not exist, the approval that goes to a different manager on Fridays because the usual one is on site. Count them. If the count is a handful, a platform's exception handling will absorb them. If the count is dozens, and each one has a rule that lives in somebody's head, you are looking at a build, because the work is not automating the process, it is writing down the process for the first time.

The second condition for a build is a system you intend to keep. Platforms tend to arrive with an implicit migration: move the data here, route the workflow through us, let us become the system of record for this part of the business. For a company whose ERP or gestionale has run invoicing, production and payroll for fifteen years, that is not a feature. It is the largest career risk an operations or IT leader can take on, and it is almost never what the problem requires. A build on top of the existing systems, through their interfaces, leaves the system of record where it is and adds the missing steps beside it. We put that commitment in writing at the start of every engagement, because the question "does this mean replacing our software" is the first one a CIO asks and the one vendors most often dodge.

The Number That Settles It: The Determinism Ratio

Here is the figure that vendors on both sides prefer not to compute, because it undercuts both decks. Take the workflow, list its steps, and classify each one as deterministic code, model judgement, or a decision that stays with a person. The share of steps that are deterministic is the determinism ratio, and it is usually high. In the manufacturer's order handling mentioned above it was eight of eleven. In a quote-to-cash process with five handoffs it was higher. In research-heavy consulting work it is lower, because the raw material is text and the model does most of the drafting; there, SUPALABS has measured a 30–50% acceleration in deliverable turnaround, concentrated in research and first draft (SUPALABS engagement data, 2024–2026).

Why does the ratio decide build versus buy? Because a platform is priced for the hard steps. The licence, the per-seat fee, the usage tier: all of it assumes the model is doing the work. When the model is doing three steps of eleven, you are paying model prices for the other eight, which are lookups and validation that a well-built integration does for the cost of running a server. Conversely, when the ratio is low and most steps genuinely need judgement, a platform with mature evaluation and monitoring tooling may be the cheaper way to get there, provided its connectors reach your systems.

The ratio is also a governance number. Every step kept out of the model is a step that can be shown to an auditor as a rule rather than argued for as a sample. For a company that will one day have to explain an automated decision to a regulator, a works director or an acquirer's diligence team, that is not an engineering preference. It is the difference between a decision log and a shrug.

What a Build Should Hand You, So You Are Not Locked In Either Way

The honest objection to building is lock-in of a different kind: dependence on the people who built it. That objection is fair when the build is delivered as a black box. It is not fair when the build is delivered with the documents that make it inspectable. A build that is worth buying comes with an Exception Ledger (every real deviation from the documented process, how often it happens, who absorbs it), an AI Boundary Map (the step-by-step classification that produced the determinism ratio), an evaluation suite with a golden dataset and a monthly accuracy report, and a decision log that a compliance officer can open without asking an engineer. Those four, plus a written commitment not to replace the systems you run, are the five artifacts the SUPALABS method produces on every engagement, and they are the reason a build can be stopped without being lost: the system runs in your accounts, the golden dataset stays with you, and the only thing that stops when the service stops is the monthly report.

Ask any build partner for those documents by name before you sign. Ask any platform vendor how you would produce them from inside their product. The answers tell you more than either deck.

A Sequencing Rule for the Evaluation

If the choice is genuinely open, the cheapest order of operations is this. First, map the workflow with the people who run it, for long enough to produce the Exception Ledger and the Boundary Map. Five days is enough for one workflow; a quarter of discovery is not necessary and usually a sign the partner is billing time rather than finding answers. Second, read the determinism ratio off the map. Third, if the ratio is high and the systems are ones you will keep, build on top of them, fixed-price, scoped from the map rather than from a guess. If the ratio is low, the inputs are structured and a platform's connectors reach your stack, buy the licence for a month and let the same map tell you whether the platform survived the exceptions. Either way, the map is the asset, and it is the one thing neither deck offered.

BCG's July 2026 survey of 152 CEOs at companies with at least $500M in revenue found two-thirds pursuing AI pilots and only 26% with AI embedded in a broader transformation. That is the end of the market with the budget to buy any platform it likes and the headcount to build anything it wants, and it is still stuck. The constraint is not the purchasing decision. It is that nobody wrote down how the work actually runs before making it.

Sources & References