Procurement Doesn’t Settle Your Architecture

Buy-or-build is a fake choice in AI. You'll be doing both.

When a packaged AI product doesn't fit the workflow you actually run, the instinct is to assume the alternative is bespoke — your team, your stack, your maintenance burden forever. So you sign the contract instead and take the vendor's version of the process.

That's a false equivalence. Rejecting a vendor's workflow does not commit you to rebuilding the infrastructure underneath it.

The line worth drawing sits inside the system, not around it. Buy the undifferentiated plumbing: identity, data platform, security, observability, policy enforcement. Nobody wins by owning that. Then compose a thin, task-specific layer around your own data and processes — and keep model access behind open adapters, so the layer isn't welded to one provider.

That's not drag-and-drop. The thin layer still needs real engineering, an evaluation harness, and a named owner. Swappability only exists if you design the interface and test it.

But it changes what the decision is about. Choosing a supplier never settled which parts of the workflow you need to control. Procurement leaves an architecture question sitting on the table, and most teams walk past it.

Which parts of your process do you actually need to be able to change?

Originally posted on LinkedIn