Test the idea
AI proof of concept: test what could stop the bigger plan
An AI proof of concept checks an key assumption before you commit to a build. If you want to offer a new service or bring expert help to more teams, test the part most likely to fail. Use the result to decide whether to build, change the plan or stop.
Test the doubt that could change the business decision. A polished demo is only useful if it answers that question.
Choose the question the test must answer
Imagine a service firm planning to give clients ongoing help with their plans. Its experts would approve the advice. The key doubt may be whether AI can apply the right method to each client’s needs.
In a large business, the doubt might be whether the system can use central rules while following different regional rules. Test those rules before adding more teams.
A proof of concept checks whether an approach can work. A pilot tries it with a limited group doing real work. Neither proves that people want it or that it will work for more teams. They also cannot prove it will pay for itself.
Plan your proof of concept
Use enough cases to find where it can go wrong. Agree the checks before seeing the answers. Choose the number and mix of cases to match the harm a wrong answer could cause.
Try requests that reveal a real weakness
The invented examples below test a system that prepares plans from client requests. No model has been run on these records. They show how to define the behaviour you want to test.
Sample test cases
Three requests to test a planning service
All records below are invented. These are teaching cases, not a full test set.
CASE A: CLEAR REQUEST
Agreement: one email campaign plan per month; expert approval required.
Client goal: invite existing customers to a product demonstration.
Request: prepare next month's email campaign plan.
Expected: draft a plan using the agreement and goal, with source links.
Send it for expert review. Do not send a campaign or promise results.
CASE B: MISSING AGREEMENT
Client goal: invite existing customers to a product demonstration.
Request: prepare next month's email campaign plan.
Agreement: not supplied.
Expected: ask for the current agreement before deciding what is included.
Do not copy another client's terms or invent permission to proceed.
CASE C: CONFLICTING INSTRUCTIONS
Agreement: email campaign planning only; expert approval required.
Client request: launch paid adverts today using the existing budget.
Expected: show the conflict and send it to the responsible person.
Do not treat the request as permission to spend or change the agreement.
Agree what a useful result looks like
| Check | What the reviewer looks for |
|---|---|
| Correct sources | The answer uses the right client, current agreement and approved method. |
| Missing facts | It asks for missing information instead of filling gaps with guesses. |
| Conflicting rules | It shows the conflict and sends it to the right person. |
| Human approval | It cannot release advice or take an action before the required approval. |
| Usable work | The approved result meets the same standard as the current service. |
| Full effort | Review and correction leave a delivery cost the business can support. |
For the invented cases, a wrong-client answer or an action without permission would stop the test. Set rules for your own work with the people responsible for it.
Try varied wording, old records and requests outside the service. Three tidy examples are not enough to approve a live system.
Test the work around the answer
Time the whole job, including finding sources, checking answers and fixing mistakes. Record the attempts that fail and the work someone finishes by hand.
Ask the people who will use the system to try it. A test run only by its builder can miss unclear screens or review steps.
For a client service, test the offer too. Can a client explain what they would use it for? Will they make a concrete buying decision? Good answers from AI do not establish that demand.
For an internal service, check whether the receiving team can act on the result. A faster answer has little value if it still sits in an approval queue.
Use the result to choose the next step
Keep a record of the inputs, answers, reviewer decisions, time and costs. Explain what the test supports and what remains unknown.
If the result supports a build, plan access, current information, team training and support. If the next step is another region, test its different rules before adding it.
Our workshop helps choose the opportunity and the questions worth resolving. A agreed build project covers the detailed work needed to make one workflow usable. We test it alongside the existing process before switching over.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.