The Build, Buy, or Kill Decision Tree for Every AI Request

An AI request is not a buying brief. It is a sentence asking for a budget line. Before a vendor demo, write down the recurring workflow, the person who owns its outcome, how many cases it handles, and how the work happens now.

The current process is the baseline. If the team cannot describe it, nobody can tell whether a tool changed the work or added another tab. Use the unit the owner already sees: invoices per month, quote requests per week, hours spent checking documents, or errors caught before a customer sees them.

Use 12 months to judge cost and dependency. Use 30 days to establish the baseline and 90 days for the first review. A shorter view hides renewal pressure. A longer one turns guesses about future volume into fake precision. Keep the first pass boring. Boring is checkable.

The GOV.UK AI procurement guidance says buyers should define the problem, assess available data, consider risks, and plan for future suppliers. The GSA Buy AI guidance starts in the same place for federal buyers: the agency's needs, not a named product. Those pages speak to public procurement, not a private company's legal duties. The operating lesson still transfers. Define the work before a seller defines it for you.

The first gate is practical. The request needs enough shape to judge. Write down six fields: workflow volume, baseline, accountable owner, data classes, risk consequence, and review rule. If one is blank, validate first or defer. A vague request does not earn a vague pilot.

Volume shows whether a subscription or build has enough work to touch. The baseline says what improvement would mean. The owner can accept a bad output, change the process, and stop the system. Data classes show what may leave the company and under which agreement. Risk consequence tells you whether a wrong output creates rework, a lost sale, a privacy problem, or a safety problem. The review rule says what a human checks, how often, and what sends the request back to manual handling.

The NIST AI Risk Management Framework is voluntary, and its generative AI profile describes a cross-sector way to govern, map, measure, and manage AI risks. It does not pick a vendor for you. It gives the packet a sensible spine.

Use this decision record. Copy it into the request, fill every field, and reject a blank. The thresholds are proposed operating rules, not law or a promise of performance.

AI REQUEST DECISION RECORD

Request: [one recurring workflow, written as an input and an output]
Owner: [one person accountable for the workflow outcome]
Volume: [cases per week or month, plus source of the count]
Baseline: [current minutes, cost proxy, error rate, backlog, or service level]
Data: [classes, systems, jurisdictions, retention, and what must not leave]
Risk: [what a wrong output could cause and who accepts that risk]
Review rule: [human reviewer, sample or trigger, and stop condition]
Decision horizon: 30-day baseline, 90-day review, 12-month cost and exit view

Branch gates
1. Missing owner, volume, baseline, data, risk, or review rule: kill or defer.
2. Hard privacy, safety, legal, or data-access block: kill or defer until resolved.
3. Current tool fits the workflow and controls without custom logic: buy and pilot.
4. Specific integration or decision rules justify a bounded external scope: commission a build.
5. Anything else: validate the workflow before spending.

Exit test
[what data, prompts, logs, configuration, and credentials must be returned or deleted]
[notice period, export format, migration owner, and date the test will run]

Review trigger
[date, volume change, accuracy breach, incident, vendor change, or cost threshold]

Rejecting a request is a budget decision, not an anti-AI position. Kill it when the work is occasional, nobody owns the outcome, no baseline exists, the source data cannot be accessed lawfully, or a wrong output would be unacceptable without a credible review path.

A request to "make customer service smarter" fails. It has no recurring unit, owner, baseline, or stop rule. By contrast, a request to classify 800 supplier invoices each month, show the three fields that triggered an exception, and route every exception to the accounts-payable manager is testable.

Defer is for a request that might be worthwhile but has a missing dependency. The data owner may not have approved the fields. The source system may not export records. Legal review may not have decided whether personal data can be processed. Put a date and owner on that dependency. Otherwise defer becomes a polite way to lose the request.

The ICO statistical accuracy guidance says teams should set accuracy targets and error tolerances before go-live, test new data, use human review, and document the decision. The rule applies to low-risk operations too. If nobody can say what counts as a bad result, nobody can say whether the system is ready.

Buy when a current product handles the core job, the team can use its controls, and the configuration is smaller than what you would operate yourself. Common candidates draft, summarize, classify, extract, or route information while a person reviews the result. The GSA Buy AI guidance starts with needs, security, compliance, and risk. The GAO acquisition review explains why the product and service tradeoff needs evidence.

The buy branch needs a proof, not a demo. Ask the vendor to run a fixed sample from your workflow with the same input set and acceptance rule you will use later. Record false accepts, false rejects, review minutes, data exposure, integration steps, and the output a human actually receives. A flawless demo on vendor-selected examples is not evidence. It is theatre with better lighting.

An official product page can confirm price and included controls. It cannot tell you whether your data, owners, and process fit. OpenAI's ChatGPT Business overview lists standard and premium seats, usage limits, admin features, and no training on workspace data. That is useful product evidence. Your buyer packet still needs its own data classification, review rule, and sample test.

Buy only when the contract preserves the controls you need. If the product stores outputs longer than your policy allows, cannot provide records for an investigation, or requires a permission path your owner cannot manage, feature fit is irrelevant. A cheap tool that cannot be governed is an expensive second workflow.

A build is a bounded external delivery project. For this ICP, that does not mean asking an operations manager to become a software engineer on nights and weekends. Commission one when the workflow has a specific integration, decision rule, or human handoff that current products cannot express without brittle workarounds. The GOV.UK procurement guidance supports defining requirements, data, governance, portability, and end of life before supplier commitment.

Keep the scope tight: one workflow, one source system, one output, and one owner. Name the input schema, allowed actions, human approval step, failure route, log, acceptance sample, and exit package. The contract should say who owns the prompts, code, configuration, evaluation set, run history, and credentials. It should also say what happens when the underlying model, connector, or vendor changes.

The GAO review of federal AI acquisitions covers agency-directed and vendor-driven approaches, product and service acquisitions, and the difficulty of understanding AI-related costs. Its recommendations emphasize market research, portability, clear licensing, pricing transparency, performance terms, and post-award oversight. The report concerns federal agencies, but those contract questions help a private buyer commissioning a workflow.

Maintenance still belongs to someone. That person reviews the workflow, handles exceptions, approves changes, watches cost, and rehearses recovery. If the company cannot name them, a custom build is a stranded asset with a launch party.

Use one formula for every branch. First-year cost is acquisition or build cost, usage, integration and configuration, owner time, review time, maintenance, and the reserve needed to leave. The GAO acquisition review shows why product and service costs need to be visible. The GOV.UK procurement guidance supports defining requirements and future supplier terms. A kill decision has no license line, but it still carries the cost of continuing the baseline work.

To make the math concrete, use 800 supplier invoices per month, six minutes of manual checking per invoice, and a $35 per hour internal cost proxy. These are illustrative inputs, not a market benchmark or a client result. The baseline is 80 hours per month, or 960 hours per year. At the proxy rate, keeping the manual process costs $33,600 per year. The arithmetic is 800 x 6 / 60 x 12 x $35.

The buy path uses two OpenAI ChatGPT Business standard seats at the annual list price of $20 per seat per month, plus Zapier Professional at the current starting price of $19.99 per month. Annual software is $719.88. That is 12 x ((2 x $20) + $19.99). The Zapier Professional pricing page is the source for the $19.99 input, and the OpenAI Business overview is the source for the $20 seats. Add the workflow owner's review time, configuration, and an exit exercise. The tool price is not the answer.

The commissioned build path uses a $5,000 fixed-scope assumption for this example, not a quoted market rate. Its scope is one invoice intake, one extraction output, one exception queue, one human approval, logs, and a tested rollback. Add the same owner review and the cost of the external model or connector it actually uses. A proposal that cannot state these boundaries is not comparable to the buy price.

The kill path keeps the manual baseline and spends nothing on software. It still costs the $33,600 annual labor proxy. Automation is not automatically justified. If the request is infrequent, risky, or ownerless, compare no project with a project nobody can safely run.

The BLS software developer profile reports occupational wage data and explains that the figures are from the Occupational Employment and Wage Statistics survey. Do not turn that wage data into a fake commissioned-build quote. Use your own signed scope and internal labor assumptions. The point is to show every cost input, not borrow an official number that was never meant to price your project.

Use requests that actually occur in the business, not abstract capability labels. These examples are operational request shapes, not client case studies or reported results. Run the evidence packet against each one.

Supplier invoice exception triage. Accounts payable owns it. The volume is 800 invoices each month, with six minutes of checking per invoice as the baseline. The data includes supplier names, amounts, tax fields, purchase-order references, and bank details. The accounts-payable manager reviews exceptions, and the system must never approve a payment. Buy and pilot an existing document tool if it can extract fields, show confidence, and send exceptions to the reviewer without exposing prohibited data. Commission a bounded integration when the current stack cannot connect to the accounting system or enforce the no-payment rule. If the company cannot name the data owner or exception reviewer, defer.

Quote drafting from a rate sheet. Sales operations owns this workflow. The volume is 120 quote requests each month, with 18 minutes per quote as the baseline. A human checks the product, terms, and discount authority. A tool that reads the approved rate sheet, drafts a quote, and leaves the final send to a person is a buy candidate. Consider a custom build only when the quote must combine several internal systems and apply rules the current product cannot represent. Without an approved rate sheet, kill the AI request and fix the source of truth first. An AI system cannot make an undocumented price list true.

Answers from safety manuals. The operations lead owns the workflow. The volume is 60 questions each month, with 12 minutes per answer as the baseline. A second person checks anything that could change a work instruction. A controlled retrieval tool may be worth a pilot when the source documents are current and the answer cites the page. Defer if the tool cannot show its source or the business cannot approve who may change the manuals. Kill the use case if an answer would directly authorize a safety action without human review.

These examples give each branch a test. Buy needs fit and controls. Build needs a specific gap and bounded scope. Kill or defer follows when a prerequisite is missing or the consequence is unacceptable. A lower price does not rescue a hard risk failure. The GAO review of federal AI acquisitions treats market research, portability, and performance evidence as part of the acquisition decision. The ICO statistical accuracy guidance supplies the accuracy and human-review test that makes each example falsifiable.

A decision memo should let someone outside the pilot reconstruct why the branch was chosen. Use this comparison once the evidence packet is complete.

Branch	Choose it when	Required proof	Exit or stop rule
Kill	The workflow is occasional, ownerless, unmeasured, or blocked by data or risk	A written reason and the missing prerequisite	Close the request, or name a dated dependency for defer
Buy	A current product covers the common workflow and the controls fit	Fixed-sample test, price, data terms, reviewer rule, and export check	Cancel or switch when the review trigger fires; export before deletion
Commission a build	A specific integration, rule set, or handoff justifies external delivery	Signed scope, acceptance sample, owner, maintenance plan, and asset list	Stop at the scope boundary or if acceptance fails
Validate first	The request might be useful but the baseline or data is not ready	Time-boxed discovery with no production commitment	End after 30 days with a buy, build, defer, or kill decision

Use the table as a decision aid, not a score that can hide a hard stop. A cheap buy still fails when the contract does not cover the data it processes. An impressive prototype still fails when the owner cannot run the exception queue. Killing the request can be the most disciplined outcome when a slogan is looking for a budget. The ICO contract guidance makes the same point about accuracy, roles, monitoring, and deletion.

An exit clause is not an exit plan. Write down the export file, migration owner, notice period, deletion evidence, credentials to revoke, and manual fallback. Then run the smallest rehearsal that proves the plan works.

The UK Contract Management Playbook says exit should be considered before contract award, kept in the risk register, and developed with the supplier from the start. The GOV.UK AI procurement guidance points buyers toward open standards, portability, governance, and end-of-life planning.

OpenAI's Services Agreement says a customer may terminate for certain material security-measure changes and says customer content is deleted within 30 days after termination, subject to legal retention and the agreement's other terms. Its Data Processing Addendum says that following expiry or termination, OpenAI will, at the customer's instruction, return or delete customer data, subject to legal retention. These terms apply to the services and agreement described there. They do not prove that every workspace feature, connected system, log, prompt, or downstream copy will export in the format your workflow needs. Ask directly.

Zapier's Terms of Service say customers retain ownership of Customer Content and may access, export, and delete it before deleting the account. They also say a deleted account cannot be restored and the customer loses access to export. That is a plain exit dependency. Export before deletion is the sequence.

Your exit test should leave behind the approved data, configuration, evaluation sample, decision log, and evidence needed to explain what ran. If you cannot do that, shorten the contract, narrow the data, or reject the vendor.

The final record should name Buy, Commission, Validate first, Defer, or Kill. It should also name who made the call, which evidence was current on that date, what the decision excludes, and when the branch will reopen. Without a review trigger, the decision is a permanent guess.

Set triggers a person can observe: volume doubles, the error tolerance is breached, the model or vendor changes, a new data class enters the workflow, the cost exceeds the approved envelope, an incident occurs, or the workflow owner leaves. Review sooner when one of those events happens. Otherwise use the 90-day first review and the 12-month cost and exit review.

The ICO contracts and third-party guidance asks buyers to set acceptable accuracy before procurement, document controller and processor roles, include audit checks, monitor the relationship, and include deletion or return terms. The NIST generative AI profile describes risks that can change across the AI lifecycle. The record lets the owner see that change before the invoice does.

A fractional AI officer can own this sequence across departments while the delivery scope stays explicit. That split matters. Leadership decides what deserves attention. A bounded build earns its place by proving the work. Our fractional AI officer ownership model keeps the commercial decision attached to the work. The fractional AI officer pillar explains the ownership model, and our strategy capability covers prioritization and roadmap decisions.