Your AI PoC will fail (unless…)
Don’t launch an AI project you can’t handle.
This is “Effective Delivery” — a bi-weekly newsletter from The Software House about improving software delivery through smarter IT team organization.
It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.
TL;DR
95% of AI PoCs fail because executives are too ambitious,
A PoC must reflect the company’s AI readiness to succeed,
Companies that lack quality data should target PoCs based on incoming data,
Only a high AI readiness lets companies build multi-agent AI PoCs.
Contents
Hey there, Aleksander again.
As a Solution Architect at TSH, I’ve helped 11 clients launch their AI PoCs through workshops and consulting.
95% of AI pilots fail to turn into products, according to a 2025 MIT report.
My experience tells me that it is because companies often attempt PoCs that are simply too hard for their organizations to handle.
Today, I’ll show you how to prevent that with a set of AI PoC guidelines tailored to three AI readiness levels.
The ambition trap
The standard AI proof-of-concept process follows 4 steps.
Gather information,
Build the PoC,
Report the findings,
Make the decision,
This process is correct, but it doesn’t protect you from attempting a PoC that is too hard for your company.
It won’t stop you from trying to enhance a process with AI when you don’t have the right historical data.
It won’t flag a PoC that will take too long to validate.
This standardized process leaves room for excessive ambition to become the biggest obstacle for a PoC.
The goal is to match that ambition to what your organization can afford to carry to development.
A beginner’s AI PoC
Who is this for
These guidelines are for organizations that:
do not have structured AI-ready data,
have not built AI-enhanced features before,
and do not have machine learning experts on board.
Your PoC guidelines
Focus on generating the right ideas first
If you struggle with data, ideas that rely on it are off the table.
Create AI PoC ideas that focus on handling incoming rather than historical data, such as document processing.
Brainstorm with the internal team and ask end users or employees where they lose time.
Consult legal before building anything with AI, because the legal department can block your idea for many reasons.
An IT team can spend months building a feature only to discover that it is a legal dead end.
The reasons can include violations of contracts, data regulations, or industry-specific policies.
Find an experienced partner
A technological partner who has deployed AI before can flag other risks the IT team might not consider, such as data handling, error handling, and compliance.
A partnership like this can take the form of workshops to develop a viable AI PoC.
If the IT team lacks AI expertise, this kind of partnership is also a way to build some, regardless of which direction the PoC goes.
Don’t insist on AI
Perhaps AI isn’t for you now. If there is no process to speed things up and no strong data to support more complex actions, try a different direction.
One client insisted on adding AI to a feature even after we showed that a traditional solution would be cheaper and faster.
The client wanted AI because it was trendy, not because it solved a problem.
Forcing AI into a process that does not require it can make the workflow worse, not better.
An intermediate AI PoC
Who is this for
Let’s now focus on organizations that:
attempted 1 or 2 AI PoCs before,
have some AI expertise on board,
maintain at least some structured process data.
Your PoC guidelines
Pick a non-critical, boring process
You may feel confident with your AI expertise.
Still, don’t be more ambitious than you need to be.
Try automating time-consuming tasks, such as document processing, data extraction, or content summarization.
Choosing a non-critical process is important because the IT team wants to improve work without risking a break in a larger system.
Stay within 2 weeks
If the PoC takes longer than 2 weeks, it’s a sign that you’re going too deep.
Those 2 weeks should answer 2 questions:
is this idea possible to build?
should the IT team build it?'
Estimate production costs during the PoC
At this level, you should build AI PoCs with a high likelihood of going to production, not just for education.
Consider this right from the beginning.
Testing costs little, but running the same feature in production can cost much more.
If the estimated cost is too high, reduce the scope.
Work asynchronously
If you have an ambitious idea that you really don’t want to abandon, there may be a way.
Start with the most basic PoC possible.
While it’s in development, generate the data you’ll need to broaden the PoC’s scope.
A client lacked the structured data for a complex PoC.
They started smaller while the organization collected and organized data in parallel.
In 2 months, that data became historical and usable for the next iteration.
An advanced AI PoC
Who is this for
This is dedicated to organizations with:
clean, up-to-date data,
a strong technical organization,
at least some actual AI experience.
Quality data is the true differentiator.
As long as you have it, you may qualify for this bracket, even if your IT team has not done much AI product development yet.
Your PoC guidelines
Follow the same steps, but extend the scope
At this point, you may feel that you have the means to skip the PoC process and go straight to development.
Hear me out.
The more ambitious your idea is, the more it will cost you if it fails.
A complex chatbot, when implemented incorrectly, can cost you tons of money in tokens wasted on user queries that should have been blocked.
Having more money does not mean the IT team can skip the validation.
However, what you can do is:
extend the PoC to 3-4 weeks,
use internal data to train models and fine-tune the solution,
go for complex projects, like chatbots,
try a multi-agent solution.
The main difference between mid-level and advanced IT teams is how many things they can automate with AI using their data.
Use milestones
If you want to validate a complex project, but still have something to release early, reverse the typical process of extending a basic idea.
Think of the whole complex solution first.
Then, figure out if you can validate just a part of it and make that your first milestone.
For example, if your idea is a chatbot that answers any business question, make one only for a single product from your suite.
Next time
In Effective Delivery #20, Adam Polak will explain the ups and downs of doing 100% AI-powered development for the first time in a commercial project.
That’s it for today ✌️
Read our most popular issue next.
Published with a smirk by The Software House
Twarda 18, Warsaw, Poland
tsh.io →
 | A guest post by
|