Artificial Intelligence
AI consulting: How to choose your first pilot project
Your first AI pilot should address a bounded, testable task. Good starting conditions include a known process, usable data, an accountable owner and a clear comparison with the current workflow. AI consulting helps establish these conditions before a company invests in tools or development.
Translate the ambition into a specific task
“We want to become more efficient” is not yet a pilot brief. Describe a real working situation instead: a team regularly creates drafts from approved product information and reviews them afterwards. Which steps take time? Where do mistakes occur? What output would genuinely help the team?
Define what the pilot will not do. An assistant summarising internal documents does not also need to advise customers or make binding decisions. Narrow scope makes errors easier to see and outcomes easier to compare. If simple rules or conventional automation solve the task more reliably, that is a useful conclusion too.
Three questions for choosing a pilot
- Value: Is there a recurring task with a clearly understood problem?
- Feasibility: Are suitable data, access rights and expert reviewers available?
- Risk: What happens if an output is wrong or information reaches the wrong person?
A high-value use case with unclear data rights is not automatically the best starting point. Prefer a controlled environment where people can review every output and return to the previous workflow. This is a pilot-design recommendation, not a legal classification of an AI system.
An example of a bounded pilot brief
This example is fictional: a communications team tests an assistant that creates an initial draft from approved product sheets. Editors retain responsibility. The assistant must not add prices absent from its sources or publish anything by itself.
Before testing, the team prepares both typical and difficult cases: complete information, conflicting documents and missing details. It assesses factual accuracy, omissions and correction effort. A quick draft is not a success if reviewing it takes longer than writing it previously did.
What belongs in the pilot brief?
- The process, intended users and explicitly excluded tasks.
- Approved data sources, access rules and handling of confidential information.
- Ownership of operations, expert review and decisions when errors occur.
- Test cases and predefined criteria for continuing, changing or stopping the pilot.
- Records of the tool, version, configuration and observed failures.
Compare the whole workflow: preparation, processing, review, corrections and operation. Record costs and limitations without projecting a guaranteed annual return from a handful of tests. Changes to the tool or data may require another evaluation.
Risk work continues beyond the first test
The voluntary NIST AI Risk Management Framework describes four functions: Govern, Map, Measure and Manage. They address ownership, context, evaluation and risk treatment. NIST treats them as ongoing activities throughout the lifecycle, not a one-off sequence of completed steps. This structure can help document pilot decisions clearly; it does not replace an assessment of applicable legal requirements.
Frequently asked questions
Do we need to develop our own model first?
No. First establish the task you need to solve. Whether an existing tool, an integration or custom development is appropriate depends on your data, requirements and operating conditions.
When should a pilot stop?
When agreed quality criteria cannot be met, risks cannot be adequately controlled or total effort outweighs the value. A documented decision to stop can be a good outcome.
From pilot brief to consultation
Bring a specific process and some approved examples to your initial discussion. Explore our AI consulting service and broader AI Consulting area. For team development, see the AI Works Academy.
Reference: NIST: AI RMF Core.
