How to Pick Your First AI Project

To pick your first AI project, choose one bounded internal workflow where better output matters, real examples are available, success can be measured, mistakes can be caught, and a person who knows the work will own the test.

Do not begin with the most impressive demo or the broadest transformation plan. Begin with a specific operating problem. RAND's interviews with 65 experienced AI practitioners found that misunderstood business problems, inadequate data, technology-first choices, missing infrastructure, and tasks beyond AI's practical capability were recurring causes of failure (RAND report). The lesson is not that every first project must be tiny. It is that its purpose, boundaries, evidence, owner, and evaluation have to be concrete.

Start with a workflow, not an AI feature

Name the candidate in one sentence:

> When this input arrives, these decisions or checks happen, producing this output for this user.

"Use AI in sales" is not a project. "Read an incoming request-for-quote email and its attachments, extract the requested part and due-date fields, flag missing information, and prepare an internal review packet for the estimator" is a project.

That sentence exposes whether the team understands the work. It also makes a non-AI answer possible. If ordinary rules, a form, a database constraint, or a conventional automation can solve the problem reliably, use that. OpenAI's agent-building guide recommends agents for workflows involving contextual decisions, brittle rule sets, or unstructured information, while explicitly noting that deterministic software may be enough when those conditions are absent (OpenAI agent guide). AI is a means, not the project.

Score six factors before choosing

Use a 0–2 score for each factor: 0 means absent or unknown, 1 means plausible but unproved, and 2 means directly evidenced. This is a decision aid, not a scientific formula.

A practical threshold is 9 out of 12 with no zero in evidence readiness, measurability, risk containment, or ownership. A high total does not erase a critical zero. If the work has no reliable examples, no way to judge output, no safe failure mode, or nobody accountable for it, it is not ready to be the first project.

Evaluate the output that matters

Model accuracy is not the same as business success. A system can extract fields correctly and still make the workflow worse if reviewers cannot understand its output, exceptions disappear, or the handoff adds more work than it removes.

Before building, capture a modest but representative test set from the real workflow. For each case, record the expected output, acceptable variation, unacceptable error, and required escalation. Then measure at two levels:

1. Output quality: completeness, factual accuracy, policy compliance, error rate, and whether exceptions are surfaced. 2. Operating outcome: turnaround, capacity, rework, decision quality, or another result the organization actually values.

NIST's voluntary AI Risk Management Framework says organizations should document intended purpose, business value, targeted scope, expected benefits and costs, knowledge limits, and human oversight. It also calls for performance criteria to be demonstrated under conditions similar to the real deployment setting (NIST AI RMF Core). That is a useful first-project discipline even when the system is small.

OpenAI similarly recommends establishing a performance baseline and evals before optimizing cost or complexity. The baseline does not need to become a research program. It needs to be honest enough to answer: Is the new workflow producing better work, consistently, on the cases we actually face?

Treat data readiness as a project question

"We must clean all our data first" is too broad. So is "AI can handle messy data."

The right question is: What evidence does this workflow require, and is it usable for this purpose?

An agent that reads differently formatted PDFs may tolerate layout variation if the required facts are present and the system can flag uncertainty. A forecasting model cannot compensate for measurements that were never captured. NIST's industrial AI guidance says data should match real-world conditions and represent the intended use-case scope; incomplete data, inadequate variation, and large gaps are common pitfalls (NIST data guidance).

A NIST Manufacturing Extension Partnership case makes the distinction concrete. A food manufacturer found that its manual moisture-data collection was not fast or consistent enough to support a predictive model, so the measurement process had to be improved first (NIST MEP case). That does not justify a company-wide data program. It shows why the chosen workflow's actual inputs have to be inspected before promising an AI result.

Prefer a safe first version

The first version should prove the hardest useful part of the workflow while limiting authority.

• Read and summarize before writing back to a system.
• Draft before sending.
• Recommend before approving.
• Compare and flag before changing records.
• Run on a sample before running on the full queue.

This is not timidity. It creates observable evidence. The team can see the system's reasoning artifacts, catch edge cases, and decide which controls are needed before an error becomes a customer, compliance, financial, or operational event.

High-consequence or irreversible actions are poor first moves unless the control environment already exists. NIST calls for the way humans use and oversee AI output to be documented, not assumed. The person who performs the workflow today should help define those checkpoints. OpenAI's use-case guidance also recommends sourcing opportunities from employees and breaking workflows into individual tasks rather than treating adoption as a leadership-only idea (OpenAI use-case guide).

Three illustrative candidates

These examples are fictional and illustrate the filter; they are not RAI client results.

Manufacturer: RFQ review packet

The system reads an RFQ email, drawings, and specifications; extracts requested parts and dates; checks the package against a known checklist; and drafts an internal review packet. An estimator validates every field before quoting. Measure completeness, extraction errors, missing-requirement detection, and estimator cycle time.

Why it can work: the input and output repeat, documents carry much of the context, skilled judgment stays with the estimator, and mistakes are contained before the customer receives a quote.

Nonprofit: program-report evidence assembly

The system gathers approved program notes and outcome records, maps them to a funder's reporting questions, identifies missing evidence, and drafts a source-linked internal outline. A program owner verifies every claim. Measure unsupported statements, missing evidence caught, revision cycles, and time to an accurate draft.

Why it can work: the job depends on scattered knowledge and documents, while the review boundary protects the organization from submitting an invented or misattributed claim.

Service business: client-onboarding readiness check

The system compares a signed scope, intake form, and supplied files; produces a readiness checklist; and flags contradictions or missing access. A project owner resolves the exceptions and starts the work. Measure missed prerequisites, avoidable back-and-forth, and time from authorization to a ready kickoff.

Why it can work: the deliverable is concrete, the system remains advisory, and the baseline is visible in past onboarding records.

Refuse these first-project shapes

The everything platform. A plan to transform sales, operations, finance, and HR at once hides which workflow works, which evidence is missing, and who owns failure.

A showcase with no operating owner. A demo can look convincing without surviving real inputs, access constraints, edge cases, or handoffs.

A high-consequence autonomous action. Customer promises, payments, personnel decisions, safety decisions, and irreversible system changes need stronger controls than a first project is likely to have.

A problem ordinary software solves better. If the job is stable rules over structured data, conventional automation may be cheaper, faster, and easier to audit.

A use case with no representative evidence. Do not build an evaluation around invented examples and then call the result proven.

Turn the winner into an implementation brief

The selected project should leave the scorecard and become a buildable brief. Record:

• the workflow sentence and current baseline;
• representative inputs, expected outputs, and edge cases;
• the AI's exact authority and prohibited actions;
• human review, escalation, retry, and shutdown points;
• evaluation cases and acceptance criteria;
• data and system access, with owners;
• the operator who will receive feedback and maintain the process; and
• a go, revise, or stop decision after the pilot.

If candidate selection is still contested, an AI opportunity assessment should compare the alternatives, preserve a no-build list, and produce that brief. When the workflow is selected, the production AI agent checklist covers the controls required to move beyond a promising prototype. And if the organization's instructions and operating knowledge are scattered, build the Operating Standard and first workflow together so the project has durable context instead of another isolated prompt.

The best first AI project is not the one that proves AI can do something. It is the one that proves the organization can define a valuable workflow, test it honestly, keep people in control, and turn better output into an operating result.