AI proposals are landing on executive desks faster than ever. Pilots get pitched as transformative, vendors promise miracles in slide decks, and internal teams arrive eager to prove value. Yet many of these projects stall, quietly drain budget, or graduate from pilot to production only to underperform. The pattern has become so common it has a name in our work: AI pilot purgatory.
The fix isn’t more enthusiasm. It’s better questions. Executives who approve AI initiatives without a disciplined diligence process tend to fund the loudest pitch rather than the best opportunity. Those who slow down for ten minutes of structured inquiry routinely cut waste, sharpen scope, and dramatically improve the odds of measurable results inside 90 days.
This article gives you that structure. It’s a pre-approval question framework built for senior leaders who don’t need to write the code, but do need to make sure the investment is sound, the risks are understood, and the outcome will move the business. Use it as a checklist, a meeting agenda, or a gating document before any AI initiative crosses your desk for sign-off.
Why a Formal Question Framework Matters
Most failed AI projects don’t fail because the technology was wrong. They fail because nobody pressure-tested the business case, the data foundation, or the change management plan before approval. A structured set of questions does three things at once. It surfaces hidden assumptions, it forces alignment between sponsors and implementers, and it creates a defensible audit trail for governance and board reporting.
Think of this framework the way you’d think of diligence before any other major capital decision. You wouldn’t approve a new product line, an acquisition, or a major hire without asking hard questions. AI deserves the same rigor, and arguably more, because the technology evolves faster than the policies around it.
The framework below is organized into seven domains. Work through them in order. If a proposal can’t answer the questions in domain one, there’s no point arguing about domain seven.
Domain 1: Strategic Fit and Problem Definition
Before anything else, you need to know whether the proposal solves a problem worth solving. Many AI projects begin with a technology in search of a use case, and that’s a structural weakness no amount of clever engineering can fix.
Questions to Ask
- What specific business problem does this project solve, and who owns that problem today? If nobody currently owns the pain, the solution will lack a champion when momentum dips.
- Why does this problem require AI rather than a simpler approach? Some problems are better solved with a rules engine, a process redesign, or a well-trained team. AI should be the answer because it’s the right tool, not because it’s the trendy one.
- How does this initiative connect to a published strategic priority? If you can’t link it to a board-level objective or a stated operational goal, it’s an orphan project.
- What happens if we don’t approve this? The answer reveals whether this is a “must-do” or a “nice-to-have.” Both can be worth funding, but they shouldn’t be confused.
- What does success look like in concrete, measurable terms? Vague aspirations like “improve efficiency” are red flags. Push for numbers, timeframes, and the named metric owner.
A useful test: if the answer to “what problem does this solve” takes more than two sentences, the team hasn’t defined the problem tightly enough yet. Send them back to sharpen it before you approve a dollar of spend.
Domain 2: Data Readiness and Foundations
AI is only as good as the data that feeds it. This is the single most common point of failure in real-world implementations, and it’s also the easiest one to glide past in a polished pitch deck. Executives should treat data readiness as a gating question, not a footnote.
Questions to Ask
- What data sources will this model rely on, and who owns each of them? Multiple owners with no clear authority almost guarantees delays.
- Is the data accessible, structured, and clean enough to use today? If the honest answer is “we’ll need a six-month cleanup first,” that’s not an AI project. It’s a data engineering project with an AI epilogue.
- What’s our data quality baseline, and how will we monitor drift over time? Models degrade when inputs shift. The team should have a plan for ongoing quality, not just a snapshot today.
- Are there data privacy, residency, or consent issues we need to address before training or inference? Regulatory exposure here can stop a project cold after launch, which is the worst time to discover it.
- If we’re using third-party data or pretrained models, what are the licensing terms and downstream usage restrictions? Some “free” models carry surprisingly restrictive commercial terms.
- How will sensitive information be handled, masked, or excluded? Particularly relevant for HR, financial, customer, and health-adjacent data.
If a project team can’t answer these crisply, the right response is usually to fund a short data-readiness assessment first, then revisit the full proposal. That’s not a delay. It’s risk reduction.
Domain 3: Technical Approach and Architecture
You don’t need to evaluate the math, but you do need to understand the shape of the solution. The goal here is to confirm that the technical approach is appropriate, scalable, and supportable, not just impressive on a whiteboard.
Questions to Ask
- Are we building custom, fine-tuning an existing model, or using an off-the-shelf service? Each path has different cost, risk, and lock-in profiles. The team should be able to defend the choice.
- How will this integrate with our existing systems, and what changes are required in the surrounding stack? A model that can’t talk to your CRM, ERP, or data warehouse isn’t going to deliver value at scale.
- What’s the inference cost per transaction, and how does that scale with adoption? Many pilots look cheap and become expensive when usage grows. Get the unit economics on the table early.
- What’s the latency profile, and is it acceptable for the use case? A model that takes eight seconds to respond may be fine for a back-office report and unacceptable for a customer-facing chat.
- What’s our fallback plan if the model fails or the vendor changes terms? Resilience matters. So does optionality.
- Who will operate this in production, and do they have the runbooks, monitoring, and on-call coverage to do it well? A model is software. It needs the same operational discipline as any other production system.
Domain 4: Risk, Ethics, and Compliance
Ethical and responsible AI isn’t a box to check at the end. It’s a design constraint that shapes the entire project. Executives carry personal and organizational risk if these questions go unasked, and regulators around the world are sharpening their expectations.
Questions to Ask
- What are the foreseeable harms if this model produces a wrong, biased, or unexpected output? If the worst-case scenario includes regulatory fines, customer harm, or reputational damage, the controls need to match.
- How will we test for bias, fairness, and disparate impact across the populations this affects? “We’ll figure it out later” isn’t an answer. Testing methodology should be defined before launch.
- Is a human in the loop, and at what point? For consequential decisions, especially those affecting employees, customers, or applicants, human review usually shouldn’t be optional.
- How explainable does the output need to be, and can this approach deliver that? Some industries demand traceability. A black-box recommendation isn’t acceptable in lending, hiring, or clinical contexts.
- Which regulations apply, and have we engaged legal and compliance early? GDPR, sector-specific rules, emerging AI acts in multiple jurisdictions, and contractual obligations to customers can all be in scope.
- What’s our incident response plan if the model behaves badly in production? Speed of response matters. So does communication with affected parties.
- How will we document model decisions, training data lineage, and version history for audit? Good governance demands a paper trail.
A useful framing question for the room: “If this story showed up on the front page of a major publication tomorrow, would we be proud of how we built it?” If the team hesitates, the controls aren’t strong enough yet.
Domain 5: Talent, Change Management, and Adoption
The most overlooked failure mode in AI projects isn’t technical. It’s human. A brilliant model that nobody trusts, uses, or knows how to interpret will deliver zero value, no matter how elegant the underlying engineering.
Questions to Ask
- Who is the named end user, and have they been involved in defining the requirements? If users hear about the tool for the first time at launch, adoption will be brutal.
- What workflow changes are required, and who’s responsible for managing them? Process redesign usually delivers more value than the model itself, and it needs an owner.
- What training and enablement does the user base need? Including prompting skills, interpretation of outputs, and knowing when to override the system.
- How will we measure adoption, and what’s our intervention plan if it lags? Adoption curves are predictable. Plan for the dip.
- Do we have the internal skills to operate, improve, and extend this over time, or are we creating a vendor dependency we can’t unwind? Both paths are valid. Both should be explicit.
- What’s the communication plan for employees whose roles will change? Trust erodes fast when staff feel surprised. Transparency early protects culture and reduces resistance.
This is where marketing fluency genuinely helps. AI rollouts succeed when they’re treated like product launches with internal customers, complete with messaging, training, feedback loops, and visible champions. Skip this work, and even a technically perfect model will underperform.
Domain 6: Vendor and Partner Diligence
Most AI projects involve at least one outside partner, whether that’s a model provider, an integrator, or a SaaS vendor with embedded AI features. Diligence on these relationships deserves more attention than it typically gets, because vendor decisions made today shape your options for years.
Questions to Ask
- What’s the vendor’s track record with organizations similar to ours in size, industry, and complexity? Logos on a slide don’t equal outcomes. Ask for references and talk to them.
- Where does our data go, and what does the vendor’s data-handling policy actually say? Read the contract, not the marketing page. Pay particular attention to training rights, retention, and sub-processors.
- What are the realistic exit costs if we need to switch providers in two years? Lock-in can be financial, technical, or operational. Get all three on the table.
- What’s the vendor’s security posture, and do they hold the certifications we require? SOC 2, ISO 27001, and sector-specific frameworks should be table stakes for serious vendors.
- How will pricing scale, and what happens at renewal? Many AI vendors price aggressively at entry and reset sharply once you’re committed.
- What’s the vendor’s roadmap, and how does it align with ours? A partner whose direction diverges from yours becomes a problem quickly.
- What service levels, support response times, and indemnities are contractually committed? Promises in conversation don’t survive an incident. Written terms do.
Domain 7: Economics, ROI, and Measurement
Finally, the money. By the time you reach this domain, you should already know the problem is worth solving, the data exists, the approach is sound, the risks are managed, the people are ready, and the partners are credible. Now you need to confirm the numbers work.
Questions to Ask
- What’s the fully loaded cost of this initiative over a three-year horizon? Including licenses, infrastructure, integration, change management, and ongoing operations. Sticker-price comparisons hide most of the truth.
- What’s the expected benefit, expressed in cash, hours saved, revenue captured, or risk reduced? Push for ranges with stated assumptions, not single-point estimates with false precision.
- How confident are we in the benefit estimate, and what evidence supports it? Benchmarks from comparable projects, internal pilots, or vendor case studies should anchor the math.
- What’s the payback period, and when does the project become net positive? If payback stretches beyond the planning horizon, the case needs to be exceptional on strategic grounds.
- What metrics will we report on monthly, quarterly, and at year-end? Define them now, in writing, with named owners. Metrics defined after launch tend to flatter the project.
- What’s the kill criteria, and who has authority to invoke it? Every funded initiative should have a clear set of conditions under which it gets paused or stopped. Without this, sunk-cost thinking takes over.
- How does this project’s expected return compare to other uses of the same capital? Opportunity cost matters. The best AI project may still be the wrong choice if a better one is waiting.
Putting the Framework to Work
This framework looks long on paper, but in practice it runs as a structured 45-minute conversation between the executive sponsor, the project lead, and a small group of critical stakeholders from data, security, legal, and the affected business unit. Walk the seven domains in order. Document the answers. Where answers are weak, mark them as conditions of approval rather than reasons to kill the project outright.
A few practical tips for using this in your organization:
- Make it routine. Embed the framework into your AI governance process so every project answers the same questions. Consistency builds organizational learning over time.
- Tier the rigor. A two-week internal automation experiment doesn’t need the same depth of review as a customer-facing model with regulatory exposure. Define tiers and apply the framework proportionally.
- Capture decisions, not just answers. Record what you approved, what conditions you attached, and why. Future you will thank present you when the project comes up for renewal or audit.
- Revisit at milestones. Diligence isn’t a one-time event. Re-run the relevant domains at the end of each phase, especially before scaling from pilot to production.
- Invite dissent. The strongest projects are the ones that survived hard questions. Reward the people who push back. Penalize the ones who go quiet.
Common Red Flags to Watch For
Beyond the structured questions, certain patterns in a pitch should prompt extra scrutiny. None of these are automatic disqualifiers, but each warrants a second look:
- The team can’t name the specific decision the model will inform or replace.
- Success metrics are aspirational language rather than measurable numbers.
- The data foundation is described in future tense (“once we get the data ready…”).
- Risk and ethics are mentioned only in response to direct questions.
- The vendor case studies all come from a different industry or scale.
- The proposal lacks a named executive sponsor or names one who wasn’t in the room.
- The cost model excludes integration, change management, or year-two operations.
- There’s no defined kill criteria, no off-ramp, and no plan B.
When several of these show up together, the project usually isn’t ready for approval. It’s ready for a sharper second draft.
The Executive’s Real Job in AI Approval
Your job as an executive isn’t to evaluate the algorithm. It’s to make sure the right algorithm is being built, for the right reason, on the right foundation, by the right people, with the right safeguards, on terms you can defend to your board, your customers, and your regulators. The framework above gives you a way to do that without becoming a technologist.
Done well, this kind of pre-approval discipline does more than catch weak projects. It elevates the strong ones. Teams that know they’ll face structured questions prepare differently. They tighten their problem statements, they invest in data readiness, they engage compliance early, and they show up with sharper economics. Over time, the framework raises the quality of every proposal that crosses your desk.
That’s the real prize. Not a single approved project, but an organization that gets steadily better at choosing, scoping, and delivering AI work that pays back. In our experience, companies that adopt this kind of governance see fewer pilots stall, faster movement from pilot to production, and measurable results inside 90 days rather than vague promises stretching across years.
Where to Go From Here
If you’re an executive staring at an AI proposal right now, take 45 minutes and walk it through the seven domains. If the proposal can’t survive the conversation, you’ve saved yourself a costly mistake. If it can, you’ve sharpened it and improved its odds of success.
If you’re earlier in the journey, looking at how to set up AI governance, build an AI readiness baseline, or design a roadmap your board can support, that’s exactly the work we do every week with mid-market and scaling enterprises. The right strategic foundation makes everything downstream cheaper, faster, and safer. Most leaders we talk to don’t need more AI options. They need a clearer path from where they are to results they can measure.
Ask better questions. Approve fewer, stronger projects. Deliver outcomes you can stand behind. That’s how AI moves from overwhelm to advantage.