Build vs Buy vs Embed: The AI Decision Matrix

The AI decision you keep making without noticing

Call it what it is: "AI strategy" is the phrase leaders reach for to put off a decision they're already making. It implies there's one big moment coming, some strategic juncture you'll schedule once the timing's right.

There isn't. The decision that truly shapes your AI posture is smaller, quieter, and you're making it repeatedly. Usually without a framework — sometimes without noticing you've made it at all.

It's this: when a new AI capability shows up, do you build it, buy it, or turn on the version already sitting inside software you own?

Build, buy, or embed. Every one of those paths can get you to a working AI tool. What most people miss is that they don't fail the same way. Each breaks at a different point, and I don't mean the technology. I mean the decision breaks at a different point, for different reasons, and drops the consequences on a different desk. If you're evaluating all three against the same mental checklist (cost, features, whether it works) you're going to get surprised. And in our world, the surprises tend to involve a GLBA gap, a CMMC finding, or an accreditation review.

Build breaks on the org chart

Building sounds like the responsible choice. You control the data, you control the model behavior, and nothing leaves your environment without your say-so. In theory, it's the path with the most governance.

In practice, build fails because of who's doing the building, and whether anyone with governance authority knows it's happening.

I've watched this play out the most clearly in higher ed. A faculty member spins up a custom AI tool for their research. It's clever work. It's also quietly generating institutional data governance obligations that IT won't hear about until something surfaces: a sponsored research review, a CUI question, a data flow nobody documented. The build didn't fail technically. It failed because the person building it and the person accountable for governance were never in the same conversation. Local government has its own version: the internal build that becomes one person's undocumented side project, carrying maintenance and vendor-dependency risks once that person leaves.

Buy breaks at the signature

Buying feels like the safe path because it runs through procurement, where your controls are supposed to hold. But buy has a failure mode the other two don't: it's the only path where you actively sign away your position — and you sign when you have the most leverage and tend to use the least.

Before the contract, you have everything: competing vendors, an unspent budget, the ability to walk away. That's the window to settle the questions that matter. Does our data train their model? Who owns what the tool produces? Can we get our data back — and on what terms? Buy fails when those questions get deferred until after signing, because functionality and price are what the evaluation committee knew how to score.

I've seen how that plays out. A year in, someone in legal or IT finally reads the terms closely and realizes the vendor retains a license to use institutional inputs, or that "your" data lives somewhere you'd never have agreed to. And the answer from the account rep is some version of "that's standard, it's in the agreement you signed." Now the leverage is gone. What would have been a redline before signing is a favor after it. Same request, no leverage, and nothing on your side of the table to trade for it.

Build's problem is that the wrong person decided. Buy's problem is that the right process reached a binding decision based on the wrong questions, and a signature is very hard to walk back.

Embed breaks a decision you already made

This is the one I'd push you to worry about most, because it doesn't announce itself as a decision at all. It quietly changes one you already made.

When you approved your LMS, SIS, help desk, productivity suite, or ERP, you authorized a named vendor to handle defined data under agreed terms. That agreement is still on the books, but the products it covers have fundamentally changed. In the last 18 months, most of your technology vendors have rolled out AI features, usually switched on by default.

Nothing on your end flagged it: no contract amendment, no renewal review, just an update.

Embed doesn't fail because a new tool slipped past you. It fails because an old approval still looks valid, even though the thing it approved has quietly turned into something else. Your contract, risk register, and data map still describe the product you vetted, not the one you now have. Your FERPA, CJIS, HIPAA, and PCI obligations may be riding on features you never enabled and can't fully see. Build eventually fails loudly. Buy fails the moment you read the contract closely. Embed fails silently — while your paperwork insists everything's fine.

Why one checklist can't catch all three

Build, buy, and embed don't just carry different risks; they route around different controls. Build routes around procurement because it never goes there. Buy goes through procurement and gets a binding signature on the wrong questions. Embed changes what an approved tool does without going through procurement, security review, or anyone with the authority to say no.

If you only have one lens, at least two of these three paths will slip by it. That's not a discipline or staffing problem. It's structural. You need criteria that adapt to how the decision is being made, not a single gate that assumes every AI-related decision walks through the same door.

It doesn't have to be elaborate. A one-page matrix naming the criteria that matter (data sensitivity, degree of customization, maintenance commitment, vendor stability, and requirements for procurement and legal reviews) is enough to start. Perfection isn’t the point. It's having a consistent way to ask "which path is this, and how does this one tend to go wrong?" before the decision instead of after. And someone has to own the answer.

The decision is already being made

Build, buy, and embed aren't hard choices. Your organization is already making all three, constantly, mostly by default. The faculty member already built something. The department already bought something. The vendor already embedded something and turned it on.

You don't get to decide whether to make this decision. You only get to decide whether you're making it on purpose.

Build vs. Buy vs. Embed is Domain 6 of the Securance 11, Securance’s AI governance standard for the public sector and higher education.

Where does your organization sit on The Securance 11? Take the 6-minute Index: 12 questions, a real score across all 11 domains, and the three things to fix first. It’s free, and you’ll get the full Securance 11 framework along with your score.

→ Take the Securance 11 Index → securanceconsulting.com/securance-11-index