Proof of concept AI: what it is for and how long it lasts
What an AI proof of concept is, when it helps and when it wastes time. Differences from prototypes and pilots, typical duration and exit criteria.
Reading time: 9 min
The proof of concept responds to a single question, technical and circumscribed: is this specific thing feasible with our data? It doesn't respond to "serve?", it doesn't respond to "is it appropriate?", and it doesn't prove that AI works — we already know that.
In the practice of SMEs the PoC is required to reassure, and in that role it is time spent badly. It only makes sense when there is a real unknown, and real unknowns are almost always about data, not technology.
In summary
- Reply to "Can it be done?", not “is it useful?”.
- It only makes sense if there's a Royal unknown, usually on data.
- Dura days: if it stretches it has become something else.
- It must be done on the true data, not on examples.
- A successful PoC doesn't say the project is worth it.
- If the feasibility is not in doubt, skip it.
When it's really needed
Makes sense
- The documents have an unusual structure
- The quality of the scans is doubtful
- Language is very technical or sectoral
- Management software Exposes Data Strangely
- The volume of data is unusual for excess or defect
It's lost time
- Demonstrate that AI reads an invoice
- Show that a chatbot responds
- Reassure someone who has no technical doubts
- Check things already seen in other similar projects
The left column has a common trait: the unknown lies in your data or constraints, not in technology in general. It is the only case where a preliminary verification produces information that you would not have otherwise.
How to set
- Write the question in one line: "Can we extract the data from our transport documents?"
- Define what an answer would be positive, with a number.
- Prepare a Real Champion, including bad exceptions.
- Give a time limit: a few days.
- In the end, you decide: you proceed, you change your approach, you let it go.
Point 3 is what determines the value. One PoC out of twenty of the cleanest papers will say that everything works, and will have measured nothing. The sample must contain the difficult cases, because they are the ones that will decide the outcome of the real project.
The PoC risk succeeded
There is a side effect that deserves attention: a well-functioning PoC generates enthusiasm, and enthusiasm leads to jumping the pilot.
The reasoning seems logical — it works, so let's do it — but skips the most important question. The PoC has shown that technically you can; it has not shown that in the real process, with the true exceptions, with the people who work there, it produces a benefit that is worth the cost.
These are the two questions that lead to different failures. A project that fails on feasibility is discovered in days; one that fails on utility is discovered after months and after spending everything. The second is the one that is prevented with the pilot project.
Practical examples
Technical documents with internal nomenclature. A mechanical company wanted to extract data from drawings with its own encodings. Real unknown: no one knew if the model would interpret that encoding. PoC of three days out of fifty real drawings, including the oldest. Clear response, project sized correctly.
Chatbot on product catalog. No technical unknowns: it is known that it works. The PoC requested by the customer only served to reassure, and delayed the start of useful work by three weeks.
Transcript in noisy environment. A workshop wanted a voice assistant. Real and specific unknown: the quality of transcription with that background noise. Half-day verification with true recordings, negative outcome, reoriented project. Minimum cost, saved decision.
How do you read the result
A PoC produces three possible outcomes, and only one is what everyone expects.
It works. You can proceed, but towards the pilot, not towards the full project. The technical feasibility is demonstrated; the utility is not.
It works in part. It is the most frequent and the most informative outcome: the system succeeds on standard cases and fatigue on a specific category. This tells you exactly where the real work is and allows you to size the project accurately, or to reduce the perimeter by excluding that category.
It's not working. It is worth the cost of the PoC and that is exactly what it was made for. It avoided a project that would fail after months and many more resources.
The PoC as a negotiation tool
There is a use of proof of concept that companies do not consider: It also serves to evaluate the supplier, not just technology.
The way he deals with the PoC says a lot about how he will deal with the project. Do you ask for real data or are you content with examples? Does it include difficult cases or choose the cleanest ones? Do you honestly tell the limits you have encountered or only present the successes?
A provider that tells you ‘about this category of documents doesn't work well, and you'd better rule it out' at the PoC stage is the same one that will tell you uncomfortable things during the project. It's information that's worth as much as the technical result, and you only get it by observing how he works — by not asking for references.
PoC, prototype and pilot in comparison
| Question | Data used | Duration | Useful Outcome | |
|---|---|---|---|---|
| Proof of concept | Can it be done? | Yours, tough champion | Days | Yes / Partly / No |
| Prototype | What do you mean? | Examples | Days-weeks | Interface Idea |
| Pilot | Do you really need it? | Real Work | Months | Extend / Reduce / Close |
Confusing the three categories is the most frequent cause of wrong expectations: you show a prototype, you conclude that the project is ready, and the first contact with the real work disproves everything.
Mistakes to Avoid
- Do it when there is no unknown. Delays and does not inform.
- Using sample data. The unknown is almost always in your data.
- Choosing the best sample. We need the worst.
- Let it stretch. It becomes a project without being one.
- Moving from PoC to the full project. Utility verification is missing.
- Not writing the success criterion. In the end, there is debate.
How to apply it in the company
Before asking for a PoC, ask yourself: What do I not know, exactly? If you can write it in a line as a technical question, the PoC makes sense. If the answer is "I want to see how it works," you're asking for a commercial demonstration, which is something else and doesn't require your data.
When you do, prepare the difficult sample and set a duration in days. And above all, keep in mind that a successful outcome opens the door to the pilot, not the full project.
The overall picture is in AI project: how to get startedcauses of failure in Why AI Projects Fail.
What to deliver at the end
A PoC should produce a short document, not a presentation. Three pages with four things: the question you asked yourself, the sample used, the result with numbers, and the recommendation.
The recommendation is the part that matters and must be explicit: we proceed to the pilot, we proceed excluding a category of cases, we change our approach, we let it go. A PoC that concludes with ‘the results are encouraging’ did not produce a decision, and the decision was its purpose.
It is worth keeping that document even after a long time: if in a year someone will propose the same idea again, you will already have the answer and the cost of the verification will not be paid twice.
The next step is described in AI Pilot Project and the overall picture in AI project: how to get started.
It should be added that the value of a proof of concept depends a lot on how specific the starting demand is. "Does AI work on our documents?" is a question that will produce a vague answer; "can we extract number, date and taxable from the transport documents of our three main suppliers, including scans?" produces a usable answer. The precision of the question determines the accuracy of the answer more than any technical choice, and it is the part of the work that is up to you and not the supplier.
Conclusion
Proof of concept is a tight tool: it answers a technical question when there is a real doubt, in a few days, about the real data. Outside that perimeter it is time that delays useful work.
And above all: a successful PoC does not say that the project is convenient. It just says you can ask. The question that matters comes next, and you answer it by putting the system in the hands of those who work.
If you want to understand what processes in your company can be automated with AI, Giallo Studio can help you turn the problem into a real workflow.
A final caution concerns the data used for verification: even a PoC involves sending real documents to an external provider, so the same verifications described in GDPR and AI in the company. It is a passage that is often skipped because «it is only a test», and instead the data are the real ones.
Giallo Studio guides: methodology and sources
How we apply it in the company
Related resources
FAQ
What is a proof of concept for?
To answer a precise technical question: is this specific thing feasible with our data? It serves when there is a real doubt about feasibility, not as a generic demonstration that AI works. If there is no doubt, the PoC is time spent to reassure someone.
How long should the training last?
Days, rather than weeks. A PoC that drags on is becoming a prototype or a project in disguise. Its purpose is to answer a narrowly defined question quickly; if it requires more time, the question was probably not narrow enough.
What's the difference with a pilot?
A PoC answers “can it be done?”, while a pilot answers “is it useful?”. The former is technical and does not enter the real workflow; the latter is organisational and is used by the people doing the work, on real cases, for a defined period. Confusing them leads from a PoC to a full project without ever checking usefulness.
When is it a waste of time?
When feasibility is not in doubt. Proving that a model can read an invoice or answer a question does not add information: you already know. The PoC only makes sense if there is a specific unknown about your data or your constraints.
Who should do that?
The people who will implement the project, using your actual data. A PoC using sample data, carried out by someone who will not oversee the work, tells you nothing useful: the uncertainty almost always concerns the quality and particular characteristics of the real data.
Does it have to be paid?
It depends on its scope. A check taking a few hours is often included in the sales phase; a PoC requiring data access, cleaning and days of work is real work. Be wary of substantial free PoCs: someone is paying for them, usually through an inflated quote afterwards.