What an AI Opportunity Assessment Should Actually Produce

An AI opportunity assessment should produce a decision, not a catalog of tools. Its useful outputs are a map of the real work, measured baselines, opportunities ranked by value and buildability, an honest no-build list, and an implementation brief for the best first project. That brief should make a yes, no, or not-yet decision possible without another round of vague discovery.

Most businesses already have enough AI ideas. Someone wants a chatbot. Someone else wants to automate quoting. A manager saw an AI meeting tool at a conference. The owner has heard that agents can run entire workflows. All of those ideas may be technically possible. That does not make all of them useful, safe, or sensible as a first project.

The assessment exists to close that gap between possibility and an operating decision. If it ends with a slide deck full of use cases but no measured workflow, accountable owner, or testable first build, it has not done its job.

That discipline also addresses several of the recurring causes covered in why AI programs fail: unclear problems, weak workflow fit, and measures that do not match the result the business actually needs.

The assessment deliverable at a glance

The sections below explain why each output matters. They are a practical synthesis, not a verbatim checklist from any one framework. NIST's voluntary AI Risk Management Framework, for example, organizes work around Govern, Map, Measure, and Manage and treats context, measurement, oversight, and monitoring as connected responsibilities rather than a one-time compliance exercise. (NIST AI RMF 1.0, NIST AI RMF Core)

Start with the work, not the software

The first question is not which model or platform to buy. It is where work is currently expensive, slow, inconsistent, difficult to hand off, or trapped in one person's head.

That requires sitting with the people who actually do the work. A process often looks clean on an organizational chart and completely different at the operator's desk. The official procedure may say that a quote starts when a request arrives and ends when the customer receives a price. The real process may involve an email, a PDF, a spreadsheet, three supplier lookups, a question to engineering, a folder on a shared drive, and a final check that only one person knows how to perform.

That messy version is not an inconvenience around the process. It is the process the system has to understand.

A useful assessment maps:

• what triggers the work and what a correct completion looks like;
• which information, documents, systems, and informal workarounds are used;
• who makes decisions and who owns exceptions;
• where work waits, fails, gets re-keyed, or returns for correction;
• which steps depend on undocumented judgment; and
• what the business consequence is when the result is wrong or late.

This workflow-first approach is consistent with the NIST Core's direction to document intended purpose, context, application scope, affected actors, and human oversight before treating an AI system as ready to operate. It also prevents a tool purchase from silently defining the problem.

Establish a baseline before promising an improvement

You cannot honestly claim that a system saved time or money if nobody measured the work before changing it.

The baseline does not need to be a six-month study. It does need to be specific enough to support a decision. Depending on the workflow, that may include:

• cases per week or month;
• active human time per case;
• elapsed time from trigger to completion;
• rework, exception, or correction rate;
• cost of delays or missed handoffs;
• number of systems a person has to touch;
• time spent finding or reconciling information; and
• the business consequence of a wrong or late result.

The important word is net. Saving five minutes in one step means nothing if the resulting system adds ten minutes of review, breaks twice a week, or requires someone to repair its context constantly.

The assessment should also keep three columns separate: observed baseline, forecast change, and realized result. The baseline is evidence about work today. A forecast is an estimate built from explicit assumptions. Realized value exists only after implementation and repeated use. Blending those categories turns an assessment into a sales claim instead of a decision tool.

Rank opportunities by value, buildability, and proof

The most valuable problem is not automatically the best first project. A workflow can be expensive and still be a poor opening move because it is too ambiguous, too consequential, too dependent on inaccessible systems, or too hard to evaluate.

Likewise, the easiest automation is not necessarily worth doing. A clever tool that saves a few minutes each month is a demonstration, not an operating priority.

A useful ranking considers at least six factors together:

• Business value: Would a better result save meaningful time, reduce real cost, improve capacity, or create a useful capability?
• Frequency: Does the workflow happen often enough for an improvement to compound?
• Clarity: Can the trigger, inputs, output, exclusions, and definition of done be described precisely?
• Data and access readiness: Are representative examples and authoritative sources available, and is there a safe path to the required systems?
• Risk and reversibility: What happens when the system is wrong, and can its action be reviewed, corrected, or reversed?
• Proof: Can the company test the result against real cases and compare it with the baseline?

GAO's accountability framework uses the complementary lenses of governance, data, performance, and monitoring. It was developed for federal agencies and other entities, not as a private-company purchasing rule, but its structure is a useful check against rankings based only on excitement or projected savings. (U.S. GAO, AI Accountability Framework)

The best first project usually sits in the overlap: meaningful enough to matter, bounded enough to build, safe enough to test, and measurable enough to prove. For a shorter selection filter, see how to pick your first AI project.

Produce an honest no-build list

One of the most valuable outputs is the list of things that should not be automated yet.

That may include work with no accountable owner, a process that changes every week, a decision that depends on undocumented judgment, a system with no safe access path, a use with consequences that the organization is not prepared to govern, or an idea whose maintenance would cost more than the time it saves.

The no-build list is not pessimism. It protects attention and creates a record of what would have to change before an idea becomes viable.

For example, the correct recommendation may be to standardize an intake form, name the source of truth, collect representative examples, resolve a data-rights question, or clarify who can approve an exception before building an agent. GAO's 2026 review of selected federal AI acquisitions found that agencies were not systematically collecting lessons learned and specifically identified data rights and testing requirements as examples of knowledge worth retaining for later procurements. The federal setting is different, but the practical lesson transfers: unresolved ownership of data and proof is a project condition, not paperwork to discover after buying. (GAO-26-107859)

If the assessment cannot produce a defensible no, it is probably functioning as a sales funnel rather than an assessment.

Turn the winning candidate into an implementation brief

Naming the first project is not enough. The primary deliverable should include a brief that another competent builder could inspect, challenge, and scope.

At minimum, that brief should define:

• the exact trigger, inputs, output, definition of done, and explicit exclusions;
• the current workflow owner and the future system owner;
• authoritative data sources, known quality limits, access requirements, and prohibited data;
• the systems and tools involved, including what may be read, drafted, changed, or sent;
• representative test cases, edge cases, expected results, and acceptance criteria;
• the human-review and escalation points for ambiguous or consequential cases;
• logging, retry, rollback, recovery, and shutdown expectations;
• the implementation sequence, dependencies, and major cost or effort drivers; and
• the baseline metrics and observation window that will determine whether the build worked.

This is where the assessment becomes an implementation plan rather than a recommendation. The brief does not need to pre-design every line of software. It needs to make the operating contract concrete enough to price, build, and test without reopening the fundamental question of what the project is.

The UK Government AI Playbook recommends clear roles, inventories, maintenance plans, escalation paths, data-flow reporting, and risk prioritization across delivery and post-delivery. ISO/IEC 42001 similarly treats AI as a management system that must be established, maintained, and continually improved. Those sources are reference points, not claims that their requirements apply to every private company. They reinforce the same practical point: the useful unit is a managed operating system, not a one-time model demo. (UK Government AI Playbook, ISO/IEC 42001)

Before an agent touches real work, the implementation brief should also be tested against the production AI agent checklist.

Define the human and recovery boundary for the actual workflow

There is no universal rule that says a human must approve every AI-assisted action, and there is no responsible rule that says a human should approve none of them.

The boundary has to be discovered for the work in front of you. Early in a deployment, people should usually see more. The system is still earning trust, the exception set is incomplete, and the team is learning what it does well. As evidence accumulates, routine and reversible work can move with less supervision.

The most durable human gates tend to sit around actions that are difficult to recover: sending a consequential external commitment, moving money, deleting unique information, changing production, making a regulated or high-impact decision, or resolving an ambiguous exception with a real relationship attached to it.

The OECD AI Principles call for human agency and oversight appropriate to context, traceability across datasets, processes, and decisions, and systematic risk management throughout the lifecycle. The same principles say systems should be capable of being overridden, repaired, or decommissioned when needed. (OECD AI Principles)

An assessment should therefore identify not just who reviews an output, but who can pause the system, how a bad action is detected, what can be reversed, where an incident is recorded, and what evidence is needed before the automation boundary expands.

Seed the operating foundation while the first workflow is concrete

If the company expects AI to grow beyond one isolated task, the first project should begin organizing reusable operating context at the same time.

That foundation is a company brain: explicit, owned information about how the business works, what its terms mean, where authoritative data lives, which rules govern a process, how decisions are made, and where human review belongs.

Building the brain without a real workflow can become abstract documentation. Building workflows without durable context can become a pile of disconnected automations that do not understand one another. The useful approach is to build both in parallel. The live project reveals which context matters, and the brain lets the next project reuse what the first one learned.

The UK Data and AI Ethics Framework likewise emphasizes documenting data provenance and limitations, clear roles, auditability, feedback, ongoing evaluation, and decommissioning. Again, that public-sector framework is not a blanket private-sector obligation. It is strong evidence that reusable context includes ownership and lifecycle decisions, not merely a folder of prompts. (UK Data and AI Ethics Framework)

The deliverable should support a yes, a no, or a not-yet

A complete assessment should leave the owner with:

• a map of the workflows examined;
• baseline measurements for the strongest candidates;
• opportunities ranked by value, feasibility, risk, and proof;
• an honest no-build or not-yet list;
• the recommended first project and why it won;
• an implementation brief covering scope, access, evaluation, ownership, review, recovery, sequence, and measurement;
• an evidence and assumption register that keeps observed facts separate from forecasts;
• the information and systems the project would require; and
• reusable, client-owned operating context that remains useful whether or not the company continues into implementation.

That is enough information to decide intelligently. Sometimes the answer will be yes. Sometimes the most valuable answer will be not yet. Occasionally the answer should be no.

Richardson Applied AI's Opportunity Assessment is $2,500 flat. It is a half-to-full day on site with the owner and two or three operators at their desks, followed by a written deliverable. It is designed to produce the decision and operating foundation described here, not a generic list of AI possibilities. If the company proceeds into a scoped Install, the assessment is fully credited toward that work.

The point is not to create urgency around AI. The point is to replace vague interest with a project that has a real owner, a measurable result, and a reason to exist.

What the assessment does not prove

An assessment is decision evidence, not production evidence.

It cannot guarantee savings, ROI, safety, compliance, adoption, or model performance. It can measure current work, make assumptions visible, identify risks, and define how a first build would be tested. Realized results require a deployed system observed over repeated cycles.

It also does not replace legal, privacy, cybersecurity, financial, labor, or sector-specific review. Risk depends on the actual use and jurisdiction. The European Commission's current AI Act summary, for example, describes a risk-based regime with additional requirements for certain high-risk uses, including documentation, traceability, human oversight, cybersecurity, accuracy, and monitoring. That does not make every small-business automation a high-risk system; it makes use-case classification part of responsible scoping. (European Commission, AI Act overview)

Finally, the recommended model or vendor may change before implementation. The workflow, evidence, ownership, evaluation, and recovery requirements should survive that change. If the assessment is useful only while one product remains fashionable, it did not capture the durable part of the opportunity.

Frequently asked questions

What should an AI opportunity assessment include?

It should include an evidence-based workflow inventory, current-state baselines, ranked opportunities, a no-build or not-yet list, and an actionable implementation brief for the recommended first project. The brief should cover scope, systems, access, ownership, human review, evaluation, recovery, and success measures.

Does an AI opportunity assessment guarantee ROI?

No. It can forecast value from observed frequency, time, cost, delay, and error data, but realized ROI can be measured only after a system is built and used. A responsible assessment labels assumptions and keeps forecast value separate from observed results.

Should an assessment recommend AI for every inefficient process?

No. Some work is too infrequent, unstable, risky, inaccessible, or hard to evaluate. The no-build list should explain whether the answer is no or not yet and what would have to change before reconsideration.

Is an AI opportunity assessment the same as an AI audit?

Not necessarily. An opportunity assessment is a business and implementation decision tool. It can identify the need for qualified legal, privacy, cybersecurity, financial, or regulatory review, but it does not replace those disciplines.

Sources and further reading

• NIST, AI Risk Management Framework 1.0
• NIST AI RMF Core
• NIST, Generative AI Profile
• U.S. GAO, AI Accountability Framework
• U.S. GAO, AI acquisition lessons learned
• OECD AI Principles
• OECD, Advancing accountability in AI
• UK Government AI Playbook
• UK Data and AI Ethics Framework
• UK NCSC and CISA, Guidelines for Secure AI System Development
• ISO/IEC 42001, AI management systems
• ISO/IEC 23894, AI risk management guidance
• European Commission, AI Act overview