Most organizations ask the wrong question first. They ask whether to buy or build before they have written down what the workflow is supposed to do, who it serves, and what risk they can tolerate. That sequence guarantees a tooling decision dressed up as a strategy decision.

This memo argues for a different order: document the context, define the value, state the tolerance, and only then treat buy, build or redesign as a go/no-go choice informed by that record. The NIST AI RMF Core is voluntary guidance, not a legal obligation, and a revised version of the framework is in progress. Its vocabulary is still useful for structuring the decision.

The decision in one page

Buy, build and redesign are not three equal options. They are three answers to a narrower question: what is the smallest change that gives you a workflow you can oversee, evaluate and switch off?

The NIST–ISO crosswalk describes the map function plainly: context is recognized and risks related to context are identified. The AI RMF Core itself says map "establishes the context to frame risks related to an AI system." The framework also states that an initial go/no-go decision about whether to design, develop or deploy an AI system is informed by the map function, and that its outcomes are the basis for measure and manage. That is the spine of this memo. The acquisition question is a go/no-go question, and it should arrive after mapping, not before.

Start with context, not tooling

Before anyone demos a product, write one page describing the workflow as it runs today. Who does it, in what sequence, with what inputs, and what happens when it goes wrong. The map function's subcategories ask for the intended purpose, beneficial uses, and the context-specific laws, norms and expectations that apply. They also ask you to document how system output may be used and overseen by humans, and the system's knowledge limits.

This page does more work than a specification document. It tells you where the actual risk sits. A customer-service drafting workflow and an underwriting workflow can look similar on a slide and have almost nothing in common once you write down the human oversight and the consequences of a wrong output.

If the context shows that the weak point is handoffs, data entry or review queues, buying a model may not touch the problem at all. Redesigning the workflow may resolve it with no AI system to govern. That outcome is a success, not a failure to innovate.

Business value and risk tolerance as inputs

Two inputs decide the shape of the answer. The map subcategories call for defining the business value or context of use, and for documenting organizational risk tolerances. Without both, "buy" tends to win by default, because a vendor has already priced the value and implied the tolerance on your behalf.

Write the value down as an operational change you can observe, not as an aspiration. Then write the tolerance down as limits: which decisions may be made without human review, what error rate would force a rollback, who is allowed to widen the scope. These are not engineering details. They are the constraints that make later measurement meaningful.

Worked hypothetical example, not a real case: a mid-sized insurer considers an AI-assisted claims triage tool. The team is tempted to buy, because a vendor offers a configuration that fits an existing system. The mapping exercise reveals that a majority of the delay comes from incomplete intake forms, and that the triage decision itself is a regulated one requiring documented human oversight. The business value is faster cycle time; the tolerance is zero unattended denials. Those two lines rule out the purchased configuration, because it routes some claims without a human step. The conclusion is not "build instead" — it is a workflow redesign of intake plus a narrower buy for summarization, with human review retained. The point of the example is the sequence, not the specific answer.

The go/no-go moment

Once context, value and tolerance are documented, the buy-or-build choice becomes a comparison against fixed criteria rather than a preference.

Buy is plausible when

The workflow is well understood, the oversight you need is available off the shelf, the vendor's terms allow the data use you intend, and you have a credible way to test the output before trusting it. NIST's governance categories ask for policies addressing third-party risks, including infringement of intellectual property or other rights, and for contingency processes when third-party data or systems fail. Those are now questions for the contract, not surprises after signature.

Build is plausible when

The workflow is specific to you, the context changes quickly, and you have the capacity to monitor it continuously. The framework describes risk management as continuous and timely across the system lifecycle, performed with diverse and multidisciplinary perspectives. Building without a monitoring plan simply converts a vendor's maintenance problem into your own.

Redesign is plausible when

The workflow's losses come from process rather than from missing intelligence. This is the most frequently skipped option and often the cheapest.

The framework's core actions are explicitly not a checklist and not necessarily an ordered set of steps. Use them as prompts, then make one decision and record it.

What to record for the board

A board does not need a product comparison. It needs the decision and its conditions. One page, five lines:

  • The workflow, its intended purpose, and who is affected.
  • The business value, stated as an observable operational change.
  • The documented risk tolerance and the limits it imposes.
  • The option chosen — buy, build, redesign or stop — and the alternatives rejected, with reasons.
  • The monitoring cadence, the owner, and the condition that triggers reversal.

That final line is what makes the decision governable. It connects the choice to ongoing monitoring and periodic review with defined roles, and to the possibility of safe decommissioning later.

The next step

Do not convene a tooling committee this week. Instead, take the workflow currently under the most pressure and write the one-page context record: purpose, users, human oversight, knowledge limits, value, tolerance. Then bring that page to the next decision meeting in place of a vendor shortlist. If the page cannot be written, that is the finding — the organization is not yet ready to choose between buying and building, and no purchase will resolve it.

The AI RMF was developed over roughly eighteen months with more than 240 contributing organizations across industry, academia, civil society and government, according to the AI RMF resources page. For organizations that work to ISO/IEC 23894:2023, the NIST–ISO crosswalk maps the framework's functions to that standard's clauses, which helps where the two vocabularies already coexist. Test the context record against your own decision before committing budget — or talk to NovCog about running that exercise with your leadership team.