Finding the right starting point for AI
Almost every company has reached the point where AI is part of the conversation. Sometimes a team has already identified a use case but doesn't know how to move from an idea to implementation. Other times, it's leadership that wants to understand where some sort of AI use would fit in the business. In both cases, though, the same question comes up: where do we start?
Rushing into the first promising use case rarely works. That’s because AI projects depend on more than choosing the right model or tool – you also need the right data, technical foundations, and internal ownership. Not to mention, a realistic understanding of what AI can and can't do. Without that, even a good idea can turn into an expensive experiment.
Start with organizational AI readiness
The first thing I always want to understand is the organization itself, and not just the use case we're considering. I look at how familiar the team is with AI. This means:
- whether people already use these tools in their daily work,
- who owns AI adoption,
- if anyone has defined a strategy instead of relying on isolated experiments.
Those answers tell me far more than a backlog of ideas.
That's what an AI readiness assessment can do. Instead of jumping straight into implementation, it evaluates your technical foundations, governance, business priorities, and organizational maturity. That makes it much easier to identify the workflows worth automating first, estimate their ROI, and build an adoption plan that the organization can actually support.
Why AI readiness assessment isn't a maturity score
People love talking about "AI maturity models." They map out strategy, data, infrastructure, talent, and culture, aggregate a five-pillar diagnostic score, and call it a day. At a recent meetup I attended with around 30 managers, this exact topic came up, with models like DORA floating around in the background. Everyone was trying to figure out how to measure readiness, and almost everyone was lost.
A high-level maturity score gives a generic report card. It might point out general organizational weaknesses, but it fails at the most critical moment. It won't tell which specific workflow to greenlight this quarter.
Real readiness isn't an abstract score. It’s evaluated at the workflow layer, against practical ROI, on technical foundations that can survive constant change.
The view from the Scrum team
The biggest mistake is evaluating readiness at the corporate level instead of looking at granular workflows. Ask a product manager in a classic Scrum setup how they measure strategy adoption or culture, and the honest answer is usually a blank stare.
Readiness varies entirely by team and task:
- Identify the actual unit of work. Don't ask if the engineering is "AI-ready." Ask if a specific team can deliver a two-week sprint faster with an assistant tool.
- Focus on daily mechanics. Look at direct inputs, handoffs, and friction points rather than high-level strategy slides.
- Build awareness before tools. If developers don't understand how a tool fits their immediate daily work, giving them access changes nothing.
Readiness is about what happens on the ground, day by day, sprint by sprint.
Be careful with standard ROI calculators
Every standard AI ROI calculator relies on static variables like employee hourly rates, token costs, projected volume, and a neat estimate of when the project pays off. That works for traditional software. For AI, it’s mostly guesswork because nobody really knows what numbers to plug in yet.
Real value often shows up qualitatively first. In one internal trial with developers, sentiment was tracked before and three months after giving them an AI coding assistant. The goal was to find out if they actually feel more effective, and have they crossed over from non-users to daily users.
When managers overcomplicate ROI, there are three disruptive questions that could cut through the noise:
- How fast would the team deliver software today if all their AI tools were suddenly taken away?
- How quick can the team (and, thus, software) adapt?
- How resilient can the system be with the use of AI tools?
When a team realizes that taking away the tool breaks their momentum, that's real adoption, and real ROI.
Technical foundations: models shift, systems break
An organization can pass a maturity audit, claim high data quality, and still fail in production. That usually happens when teams treat AI like static software instead of a moving target.
Working with AI models requires preparing for constant, unpredictable shifts:
- Unrepresentative data creates systematic bias. A model trained mostly on data from one production line, machine type, or region can produce unreliable recommendations when used elsewhere. And even with a well-designed workflow, training on skewed historical decisions or narrow operating conditions can carry existing biases into the automated system and reinforce them.
- Prompt paradigms change. Prompting approaches change as models improve. Detailed persona prompts such as “You are an expert chef...” were more useful with earlier models. Newer reasoning models often need less instruction, and overly elaborate prompts can get in the way. In some cases, a short prompt, or even very little guidance, produces better results than a long set of rules.
- API behavior drifts. A model hosted in the cloud today won't perform identically tomorrow. Output consistency can drift by overnight without warning, or the API might simply go down.
- Security keeps changing. As models get more capable and gain access to more tools and data, testing continues to uncover ways they can behave outside intended limits. Prompt instructions aren’t enough on their own, so access should be controlled through permissions, sandboxing, network and filesystem restrictions, and secure tool interfaces such as MCP gateways.
True readiness is about having the procedural discipline, security harness, and technical flexibility to adapt when the underlying models inevitably shift.
Layer one: workflow readiness
This is the first layer of any AI readiness assessment. Before you think about models, infrastructure, or implementation, you ask yourself: Is this process worth automating in the first place?
The strongest candidates for AI aren't selected by matching a generic checklist - they are workflows where the business logic is clear, process repeatable, but manual execution creates an operational bottleneck.
Don't evaluate the technology before you evaluate the process
One challenge I see across organizations is that they try to measure AI's impact before they define what success looks like. Everyone talks about ROI, but very few teams know how to calculate it. Traditional ROI calculators focus on implementation costs, token usage, or infrastructure. Those numbers matter, but they don't tell you whether your teams actually work more effectively after AI adoption.
That's why I also look at qualitative signals. I want to know whether employees feel they complete work faster, make fewer mistakes, or spend more time on higher-value tasks. One question I like to ask is: What would happen if I took your AI tools away tomorrow?
If productivity drops immediately, AI has already become part of the team's workflow.
Automating a broken process – the biggest possible mistake
When it comes to AI use case prioritization, the most common mistake is trying to automate a workflow that nobody has optimized yet. Technology doesn't fix unclear business processes.
That's why, during discovery workshops, I spend a lot of time asking uncomfortable questions. What happens if the usual person isn't available? Who makes the decision when information is missing? What happens when an exception occurs?
Teams often realize they don't have consistent answers to these questions because people rely on tribal knowledge instead of documented processes. AI simply exposes those gaps.
Personally, I prefer breaking complex workflows into smaller, well-defined pieces before introducing automation. If information is missing, maybe the first step isn't an AI model at all?
It could be an automated email asking a customer to complete a form or an SMS requesting additional details. Once your workflow is structured, AI could support it much more reliably.
As you can see, workflow readiness has very little to do with how exciting an idea sounds. The strongest AI candidates usually solve repetitive, clearly defined business problems.
Layer two: ROI readiness
Technical feasibility alone doesn't justify an AI project. I see plenty of workflows that look like elegant candidates for automation on paper, yet yield zero actual business impact. ROI readiness means defining measurable outcomes, like saved hours, reduced overhead, faster decision loops, or a shorter time-to-value before writing code, rather than reverse-engineering success metrics after an expensive PoC fails.
At the end of the day, when I sit down with business leaders, they care about one core question: What is this going to cost, and what do I actually get back?
Calculating an accurate AI use case ROI requires cutting through high-level promises and looking closely at real-world implementation costs.
The hidden costs of the 5% edge case
Standard financial models fail because they only calculate best-case scenarios, for example, token pricing today, basic API usage, and predicted time saved on straightforward tasks. They completely ignore edge cases and ongoing system maintenance.
LLMs hallucinate and drift. Moving data from point A to point B sounds simple, but maintaining confidence in system outputs demands constant oversight. I often remind teams that when a model processes 95% of routine cases smoothly, the remaining 5% of unpredictable edge cases can drain all initial efficiency gains:
- Endless debugging. If an operator spends two hours digging into backend reasoning traces to figure out why a model misclassified a critical data point, they'll inevitably scrap the output and rewrite it from scratch.
- Costly technical oversight. An architect’s role goes beyond system maintenance. Reliable AI systems need ongoing engineering to monitor prompt injection risks, refine guardrails, and adapt the infrastructure as APIs and model behavior change.
- Escalation routines. Systems require clear failure procedures for when edge cases hit. Just as Richard Branson famously trained Virgin staff for high-stress crises, I build operational frameworks with explicit human handoffs for when outputs drift or models fail.
Ignoring edge cases turns a theoretical 10x ROI gain into a net loss.
Regulatory and political infrastructure overhead
Pure software ROI calculators assume static operating environments. Generative AI deployment operates within shifting geopolitical and legal boundaries that I have to factor into every build:
- Data residency. Meeting strict data residency rules (such as localized European cloud setups) alters baseline infrastructure costs.
- Geopolitical risk. A financial institution might technically optimize credit scoring using an open-source foreign model, but the compliance and reputational fallout makes that deployment far too costly.
True AI ROI accounts for legal exposure, compliance requirements, and regional hosting constraints.
How I de-risk implementation: start small or fix literacy first
When a client presents a workflow with high technical potential but unclear returns, I don't discard the project – I scope it down or address foundational blockers first.
1. Micro-automations over full system overhauls
Replacing an entire operational department with AI carries massive risk and runaway costs. I prefer isolating high-friction touchpoints within the workflow:
Instead of spending a massive budget attempting to automate a multi-step operational pipeline end-to-end, isolate a single bottleneck, such as auto-categorizing incoming customer requests or drafting initial response summaries for human sign-off.
Targeting high-friction steps delivers immediate efficiency without creating runaway maintenance costs.
For a clearer picture of how a well-executed process translates into actual speed gains, see AI-Augmented Software Development: What 3-5x Faster Delivery Really Requires.
2. Accounting for digital literacy
System adoption breaks down when employees lack basic computer skills. I've conducted training sessions where participants struggled with basic concepts like network drives or SharePoint. Rolling out advanced LLM interfaces to a workforce in that situation guarantees failure, regardless of model capability.
If executive leadership misses onboarding sessions or employees lack foundational IT literacy, adoption stalls immediately.
In these situations, I don't rush to deploy complex AI agents. I recommend building basic digital skills across the team first, ensuring the organization can actually use the tools long after I finish the rollout.
Calculating ROI readiness isn't about guessing abstract financial returns. It means factoring in edge-case handling, compliance overhead, and team capability to make sure the math actually holds up in production.
Layer three: technical readiness for production AI
By the time you've identified a promising workflow and ROI, there's one more question to answer: can your organization actually deploy it?
You need accessible data, systems that can communicate with each other, clear ownership, appropriate permissions, and an AI infrastructure capable of supporting the solution long after the proof of concept ends.
Business discovery tells you “what.” Technical discovery tells you “whether.”
While business discovery helps you understand the problem you're trying to solve, technical discovery determines whether you can solve it with the technology you already have.
This is the stage where we ask for access to the codebase, architecture, infrastructure, and the people who know the environment best. Documentation rarely tells the whole story. The real insights usually come from engineers and system owners who know where the workarounds, legacy dependencies, and hidden constraints live.
Once you have that level of visibility, the real blockers start to emerge.
What might they be? Sometimes the data you need exists, but nobody can access it. Sometimes the systems don't expose the APIs or integrations the project depends on. In other cases, it's the security policies, permissions, or architectural decisions that will make the original implementation approach impossible.
Why a successful PoC doesn't prove production readiness
Here, I'd like to point to one of the biggest misconceptions I see. It's treating a successful proof of concept as proof that the organization is ready for production.
A PoC only shows that an idea can work under specific conditions. Production introduces a completely different set of questions.
You need to know whether:
- your data readiness for AI is sufficient
- the solution can integrate with existing systems
- it can satisfy security and compliance requirements
We cover these checks step by step in how STX Next validates AI automation opportunities before implementation, from data sovereignty and pipeline quality to permission boundaries and working prototypes.
You also need to ask yourself whether they've involved everyone who understands the process in the conversation. So, it's not just leadership, but the people who use these systems every day.
I've seen some projects brought to a halt because stakeholders weren't part of the discovery process, or because critical technical constraints only became visible after implementation had already started.
That's why I treat business and technical discovery as two sides of the same assessment. One explains where AI can create value. The other determines whether your organization has the technical foundations to deliver that value in production.
This is where organizations benefit from working with a partner that combines AI consulting with software engineering and data expertise. Identifying a promising use case is only the beginning. Getting it into production requires people who can validate the architecture, assess the infrastructure, understand the data landscape, and solve the engineering challenges that discovery uncovers.
Bringing the three layers together: how to score and compare use cases
When evaluating potential projects, everything looks great on paper. But that is where skeletons in the closet start appearing. A project might have incredible ROI potential, yet collapse due to unpredictable model hallucinations, poor data infrastructure, or straightforward human resistance.
My job during an assessment is catching those mismatches before money is spent.
I run an AI use case selection process that plots candidate workflows across three core axes, i.e., workflow fit, practical ROI, and technical feasibility.
I use a straightforward AI prioritization framework to map out candidate workflows alongside leadership:
- T-shirt sizing over rigid numbers. I don't force teams to estimate exact dollar figures right away. Mapping effort and return as High/Low or Small/Medium/Large reveals relative value fast.
- Finding the golden intersection: Prioritization belongs at the intersection of all three layers. A loud, highly visible idea from C-level executives gets dropped if technical feasibility or user adoption falls short.
- Targeting high-volume friction first. Production-ready quick wins often sit in repetitive tasks, like inbox filtering, data aggregation, or cross-system integrations. Clearing these operational bottlenecks frees up immediate capacity across the entire organization.
The human reality check
Even when the technical setup is sound, automation still needs human ownership. Teams need to understand when to trust the system, when to review its output, and how it fits into their day-to-day work. If people avoid the tool or keep falling back on the old process, the implementation has not really succeeded.
Good prioritization therefore means choosing workflows where the value is clear, the risks are manageable, and adoption is realistic. Proving that value on a smaller scale also gives the organization a better basis for deciding where AI should be introduced next.
What comes out of the AI readiness assessment: The practical roadmap
An AI readiness assessment should let you prioritize initiatives based on business value, technical feasibility, and implementation effort.
From the projects I've participated in, I can tell you that some use cases are ready to move forward immediately. Others require additional work first, whether that's improving data quality, integrating systems, or refining the business process before AI.
Here's where I also need to underline the fact that not every promising idea will be a quick win.
That's because, during discovery, we identify the areas that already have the right technical foundations and enough clarity to move forward with confidence. Those projects usually become good candidates for an AI PoC or MVP because both sides understand the problem, and we know how to approach the implementation.
Experiences turn discovery into an implementation plan
There's no universal checklist that would tell you which projects belong in each category. Like elsewhere, a lot of it comes down to lived experience.
When we've solved similar challenges in the past, we can quickly recognize proven implementation patterns and technical accelerators that reduce delivery time. For example, at STX Next, while we validate every assumption with the client, previous projects help us distinguish between problems we've already solved and challenges that require a custom approach.
Conclusion
Ideas are easy. The hard part is to know which specific workflow deserves actual budget and attention first. A practical AI readiness assessment cuts through generic scores and hype to find the exact spot where technical feasibility, real business ROI, and daily team workflows meet.
Where we go next depends on how your team prefers to work:
- Build your internal skills. If your team wants to learn how to evaluate workflows, pick the right tools, and map out a roadmap together, explore our AI & Automation Workshops and Trainings. In these discovery sessions, we work side-by-side, test ideas hands-on, and adapt to your team's current stack instead of forcing rigid top-down specs.
- Let us handle the assessment. If you want STX Next to audit your architecture, pinpoint high-ROI use cases, and hand over a prioritized roadmap directly, reach out to us.
At the end of the day, people still build software for people. Whether we run a workshop together or map out the assessment for you, the goal doesn’t change – to put real, reliable value into production without wasted effort.
