Chapter 9 — The AI Strategy Blueprint AI Pilot AI Pilot Purgatory AI Pilot Charter Template

AI Pilot Purgatory: Why 99% of AI Pilots Stall Before Production (And the Pilot Charter That Fixes It)

The typical enterprise has identified hundreds of AI use cases but deployed fewer than six to production. This is pilot purgatory — a graveyard of well-funded, well-intentioned initiatives that never cross the threshold from demonstration to deployment. Here is the disciplined execution framework that breaks the cycle, including the exact charter template, decision rubric, and entry-point economics that get working AI into users’ hands within 24 hours.

Hundreds Use Cases Identified
Fewer Than 6 Deployed to Production
4–6 Weeks Target Pilot Timeline
Sub-$100 Per-User Entry Point
Trusted by enterprise leaders
Government Acquisitions
TL;DR — Quick Answer

What Is Pilot Purgatory and How Do You Escape It?

Pilot purgatory is the state where an enterprise runs multiple AI proofs of concept indefinitely — consuming budget and credibility — without ever moving a single project to production. It is caused by four predictable failure modes: complexity overload, capability gaps, resource constraints, and change resistance. The escape requires three things working together: a bounded pilot with a fixed 4–6 week timeline, a 14-element pilot charter that forces objective success criteria before work begins, and a sub-$100/user entry point (like AirgapAI) that removes career risk from the decision. Organizations that apply the Crawl-Walk-Run framework consistently report moving from zero to working AI in 24 hours and from a single team to an enterprise in months, not years.

Skip to the Framework

What Is an AI Pilot?

An AI pilot is a time-boxed deployment of one AI capability to one named user group, run against a written baseline and pre-agreed success criteria so the organization can decide to scale, iterate, pivot or stop. The AI Strategy Blueprint sets the evaluation window at four to six weeks.

The word does a lot of work in enterprise settings, and most of the time it is used loosely enough to be meaningless. A demo is not a pilot. An unbounded experiment with no end date is not a pilot either — it is the raw material of pilot purgatory. An AI pilot has five parts, and a project missing any one of them cannot produce a decision at the end of it.

  • One use case A single, bounded task in a single department — not a portfolio, not a platform migration. Scope is the variable that decides whether the pilot finishes.
  • Named users A specific list of people who will use the capability daily. Anonymous “the finance team” produces a demo; named users produce usage data.
  • A written baseline What the task costs today in hours, error rate or cycle time. Without a before state there is no defensible after state, and the evaluation turns political.
  • A fixed evaluation date Four to six weeks, set before the work starts. The date is what converts an open-ended experiment into a decision.
  • A pre-committed decision rule Scale, iterate, pivot or stop — with the thresholds for each written down in advance, in the pilot charter, alongside the expansion path.

Those five parts map one-to-one onto the 14-element pilot charter further down this page, which is the artifact that forces each of them to be written down before implementation starts. Pilots that skip the charter are not faster; they simply move the ambiguity from week zero to week twelve, where it costs more.

How the AI pilot fits the wider program
The pilot is the Crawl phase of the Crawl-Walk-Run framework. Its output is not just a working capability — it is the organizational confidence, literacy and evidence required to justify the Walk phase. To choose what the pilot should cover in the first place, work upstream through AI use case identification.

Scope your first AI pilot in about ten minutes

The AI Blueprint Builder turns your answers about the department, the task and the data into a scoped pilot plan with success criteria you can drop straight into the charter. When you want to see the capability against your own material, Iternal runs a demo on your own documents.

AI Pilot vs. Proof of Concept vs. MVP

A proof of concept tests whether the technology can work at all. An AI pilot puts that capability in front of real users for four to six weeks against a baseline. An MVP is the smallest production-grade release you operate, support and expand after the pilot decision.

These three words are used interchangeably in most enterprise programs, and the substitution is not harmless. A proof of concept judged by pilot criteria looks like a failure because no user behavior changed. A pilot judged by proof-of-concept criteria looks like a success and then dies, because “the model works” was never the question the business asked. Each stage has its own question, its own evidence and its own sign-off.

Dimension Proof of Concept AI Pilot MVP
Question it answers Can the technology do this at all, on our data? Does it change the work for real users, measurably? Can we operate and support it as a product?
Users The project team, often a single technical evaluator A named group doing the job for real, day to day The full department or the first production cohort
Duration Days to two weeks Four to six weeks, evaluation date fixed in advance A release cycle, then continuous
Data 5–20 representative documents The live working set for one workflow Governed data with owners, retention and access control
Success measure Technical feasibility and output quality Improvement against a written baseline Adoption, reliability and cost per user
Who signs off The technical lead The executive sponsor, against charter criteria The service owner who inherits it
How it fails It works, and nothing happens next No baseline, no date, no decision rule — pilot purgatory Shipped without a support model or a training layer

When you can skip the proof of concept

If the capability is already commercially available and deployable in a day — a local, secure assistant over your own documents, for example — the proof of concept collapses into the first afternoon of the pilot. That is the practical meaning of the 24-hour rule further down this page: feasibility stops being a separate phase when the software installs on hardware you already own. Keep a distinct proof of concept when the work involves custom integration, a bespoke model, or a data source nobody has successfully queried before.

When the pilot becomes an MVP

The transition is a decision, not a date. It happens when the pilot clears its charter criteria and the executive sponsor makes the Scale call, at which point the questions change from “did it help?” to “who owns it, who supports it, what does it cost per user, and how do new joiners get trained on it?” The checklist for that handover lives on AI production readiness, and the delivery path for organizations that want it run for them is AI implementation services.

What Is Pilot Purgatory?

According to IDC, the typical enterprise has identified hundreds of GenAI use cases but deployed fewer than six to production. The gap between “we have a pilot” and “this is in production” is where most enterprise AI investment goes to die. That gap has a name: pilot purgatory.

Definition: Pilot Purgatory
The state in which an organization runs multiple AI proofs of concept indefinitely, consuming resources and credibility without any project graduating to production — while creating the dangerous illusion of AI progress. Every active pilot that never ships is a tax on your innovation budget and a signal to leadership that AI does not deliver.

“The most dangerous failure mode is ‘pilot purgatory’: multiple pilots running indefinitely without graduating to production, consuming resources without generating value, while creating the illusion of AI progress.”

— John Byron Hanby IV, The AI Strategy Blueprint, Chapter 9

The pattern is consistent across industries and organization sizes. A VP of Operations sees a compelling demo, secures budget, launches a pilot. Months pass. The pilot is “ongoing.” Another pilot starts. The first is still “ongoing.” Leadership asks for an AI update. The answer is a slide deck listing pilots. None are in production.

The cause is not a technology failure. Modern AI platforms are mature, deployable, and commercially accessible. The cause is a process failure — specifically, the absence of the discipline that converts demonstrated potential into shipped capability. Chapter 9 of The AI Strategy Blueprint provides that discipline in full. This article distills the core of it.

The Four Failure Modes of Large-Scale AI Initiatives

Before examining how to escape pilot purgatory, you must understand why ambitious AI initiatives fail with such consistency. Each failure mode is predictable, and each argues for a more measured approach grounded in bounded, time-boxed pilots rather than enterprise-wide transformation programs. Not sure which one is stalling you? Score your AI readiness to find the constraint before you scale.

Failure Mode What It Looks Like Why It Kills Pilots The Antidote
Complexity Overload Multiple departments, systems, and stakeholders required to align simultaneously Exponential coordination overhead causes delays, scope creep, and approval bottlenecks One use case, one team, one department — then expand
Capability Gaps Organization lacks skills, governance, or data infrastructure for large-scale deployment Gaps discovered at the worst possible moment — during production rollout Build capability incrementally through small pilots before scaling
Resource Constraints Large initiatives require sustained commitment across extended timelines Competing priorities or budget cycles starve the project before it ships Sub-$1,000 entry points remove budget as a barrier; fast timelines reduce exposure
Change Resistance Broad transformation triggers organizational resistance; employees resist mandates The wider the scope, the more constituencies must be convinced simultaneously Start with volunteers; let word-of-mouth pull adoption rather than mandate it

The common thread across all four failure modes: they are all amplified by scale and compressed by scope reduction. Every enterprise AI deployment that reached production — including the 3→15→35→65 license expansion documented in this chapter — began with a single well-defined use case in a single team.

From the Book
“Large enterprises often stall AI initiatives by attempting comprehensive enterprise-wide strategies before proving value. Successful approaches start with specific use cases in specific departments, demonstrate measurable value, then expand based on success. Attempting to solve every AI use case simultaneously typically results in analysis paralysis and delayed value realization.”

To learn how to identify the right first use case before launching any pilot, see our companion article: AI Use Case Identification: The Value-Feasibility Matrix. For a full treatment of the compounding cost of staying stuck, see The Cost of AI Inaction.

The Four First-Project Anti-Patterns

Not all AI use cases are equal candidates for a first pilot. Certain categories should be explicitly excluded from initial deployments regardless of their theoretical potential. Each of the following anti-patterns has ended careers, killed programs, and sent organizations back to the drawing board after months of wasted investment.

High-Stakes Decisions

Autonomous medical diagnosis, credit approval, safety-critical systems. These applications demand accuracy levels, governance maturity, and validation depth that first pilots cannot provide. Organizational experience must be accumulated through lower-risk deployments before these use cases can be responsibly addressed.

Not for first pilots

Extensive Integration Requirements

Use cases requiring connections to multiple enterprise systems create implementation dependencies that extend timelines and multiply failure points. Each integration adds an approval cycle, a testing requirement, and a new stakeholder whose calendar must align. Start with standalone capabilities that deliver value without touching existing infrastructure.

Not for first pilots

Immature Data Foundations

Organizations with fragmented, inconsistent, or undocumented data should not begin AI adoption with use cases that depend on data quality they have not yet achieved. The book’s guidance: select 5–20 representative documents for proof-of-concept engagements rather than attempting comprehensive enterprise data ingestion. Representative beats comprehensive every time.

Not for first pilots

Unclear Success Criteria

If stakeholders cannot articulate what success looks like in quantifiable, pre-agreed terms, the project lacks the foundation for objective evaluation. Without a baseline and a target, every outcome is ambiguous. Ambiguity is the natural habitat of pilot purgatory. Establish measurable objectives before beginning implementation — full stop.

Not for first pilots
Pro Tip from Chapter 9
The ideal first AI use case is broad and horizontal: a local, secure AI chat assistant paired with training for every employee. This single deployment gives the organization outsized returns while building the AI literacy that prevents every subsequent pilot from failing for people reasons. See AI Academy for the workforce training layer.

The Crawl-Walk-Run Framework

Every successful enterprise AI deployment follows the same maturation curve. The framework is not theoretical — it is extracted from hundreds of production deployments across regulated industries, federal agencies, and enterprise technology teams. The goal of each phase is not completion; it is the accumulation of organizational confidence required to operate at the next level of autonomy.

Phase Name Duration Human Oversight Level Primary Goal Validation Criteria
Crawl Internal Validation 1–3 months All outputs reviewed before use Identify error patterns and edge cases; build internal trust in AI capabilities Team can articulate where AI excels and where it struggles; no production exposure
Walk Monitored Production 3–6 months Spot-checking; escalation paths for uncertainty Measure time savings and accuracy improvement; develop operational support procedures Quantified productivity gains documented; exception handling protocols established
Run Scaled Automation Ongoing Exception handling only; continuous monitoring Realize full productivity value; confidently expand to additional use cases Full ROI documented; expansion roadmap committed; organizational capability proven

“A critical best practice for AI automation projects is maintaining a ‘human in the loop’ approach. Even when AI can automate 95% of a workflow, organizations should deploy internally first — run it for six months at small scale with human oversight, work out all the kinks — before considering broad customer-facing deployment.”

— John Byron Hanby IV, The AI Strategy Blueprint, Chapter 9

The Crawl phase is the phase most organizations skip — and the skipping is exactly what triggers pilot purgatory. Without an internal validation phase, the first production failure becomes an organizational crisis instead of a learning opportunity. With it, failure at the Crawl stage is a $0 lesson that makes the Walk stage succeed.

For organizations building toward full production readiness, see our deep-dive: AI Production Readiness Checklist. For the phase-by-phase plan that takes a validated pilot onto a funded production timeline, see the AI Implementation Roadmap. For the broader AI transformation roadmap that these phases feed into, see The Enterprise AI Strategy Guide.

The Scale / Iterate / Pivot / Stop Decision Rubric

One of the defining structural differences between organizations that escape pilot purgatory and those that do not is the existence of a pre-defined decision rubric. When a pilot ends, four outcomes are possible. Organizations that define these outcomes and their criteria before the pilot begins make faster, more objective decisions. Organizations that leave outcomes undefined at launch invent justifications for continuation — the primary mechanism by which good pilots become bad purgatory.

Scale
Criteria: Results meet or exceed pre-agreed success criteria
Action: Proceed to broader deployment using the Crawl-Walk-Run framework. Budget expansion. Brief leadership on production timeline.
Iterate
Criteria: Results are promising but specific improvements are required
Action: Refine the approach and continue. Define a second iteration with updated success criteria and a fixed timeline. Do not extend indefinitely.
Pivot
Criteria: Fundamental approach needs change; current direction will not work
Action: Redesign the approach before proceeding. This is not failure — it is the Crawl phase delivering exactly the intelligence it was designed to generate.
Stop
Criteria: Value proposition is not validated; the use case is not viable
Action: Discontinue investment and reallocate resources. A stopped pilot that was properly scoped costs little. This is the system working correctly.

The discipline of this rubric is what the 14-element pilot charter enforces before work begins. Organizations that use the charter consistently make their Scale / Iterate / Pivot / Stop decisions in days, not months. For the phase-gate version of the same discipline — the checkpoints a program clears before the next phase is funded — see the governance gate criteria on the AI Implementation Roadmap.

The AI Strategy Blueprint book cover
Recommended Reading

The AI Strategy Blueprint

Chapter 9 of The AI Strategy Blueprint details the complete pilot-to-production playbook — including the 14-element pilot charter template and the sub-$100 entry point paradigm that lets you start in 24 hours. Available now on Amazon.

5.0 Rating
$24.95

The Land-and-Expand Case Study: From 3 Licenses to 65 (and Then 4,500)

Theory is useful. Documented outcomes are more useful. Chapter 9 of The AI Strategy Blueprint provides two case studies that demonstrate the land-and-expand motion in action — one in healthcare information services, one in county government. Both started with the smallest possible footprint. Both became enterprise programs.

Case Study 1: Healthcare Information Services — 3 → 15 → 35 → 65

A healthcare information services company followed the classic land-and-expand trajectory with AirgapAI:

1
Initial Purchase

3 AirgapAI licenses with 3 Intel AI PCs. A bounded, low-risk starting point with a specific team and a defined use case.

2
Two Weeks Later

12 additional licenses and devices purchased — without any additional sales conversation. Internal users became internal advocates.

3
One Month Later

Approximately 20 more units. Departments that saw colleagues using AI requested their own access based on word-of-mouth productivity gains.

4
Current Total

65 licenses and devices. Each expansion decision was made independently, based entirely on internal experience — not on sales pressure.

“Organizations that achieve the highest AI penetration are typically those that began with the smallest initial deployments.”

— John Byron Hanby IV, The AI Strategy Blueprint, Chapter 9

Case Study 2: County Government — Five Counties, One Day, 4,500 Users

The speed of the land-and-expand motion is not limited to private enterprise. One Iternal channel partner sold five AirgapAI licenses to each of five county governments in a single day, with total investment under $2,500 per county. The pitch was not a technology transformation program. It was a low-risk way to “get exposure” to AI capabilities without committing to anything larger.

The initial seed deployment subsequently opened executive discussions to scale to 4,500 users across those same county governments after initial testing proved the value proposition. The path from five licenses to a 4,500-seat enterprise deployment began with a $2,500 decision that no government official needed approval committee to make.

Why This Pattern Repeats
Low initial risk limits downside if the technology underperforms. Early users share positive experiences through internal evangelism. Real productivity gains justify budget for expansion through demonstrated ROI. Users find use cases the original project never anticipated. Small deployments prove security and compatibility before organizational scale.

For a deeper treatment of the land-and-expand motion and how to engineer it deliberately, see our companion article: Land and Expand AI: How a 3-License Deployment Became 65 Users.

The 14-Element Pilot Charter Template

The pilot charter is the structural antidote to pilot purgatory. It is not a bureaucratic form. It is a forcing function that surfaces every assumption, ambiguity, and undefined criterion before a single hour of implementation work begins. Organizations that skip the charter and get burned universally wish they had used it. Organizations that use it consistently report faster decisions, cleaner evaluations, and higher production conversion rates.

The following 14-element template is drawn directly from Chapter 9 of The AI Strategy Blueprint. Each element should be documented and signed off by the executive sponsor and project lead before any technical work begins.

# Charter Element What It Must Define Why It Matters
1 Project Name Clear, descriptive title identifying the specific use case Creates shared language; prevents scope from blurring over time
2 Executive Sponsor Individual accountable for pilot success and expansion decisions Without named accountability, pilots drift; no one is empowered to make the Scale/Stop call
3 Project Lead Day-to-day owner responsible for execution Separates strategic ownership (sponsor) from operational ownership (lead)
4 Business Problem Specific pain point being addressed with quantified current state Forces articulation of baseline; required for ROI measurement at close
5 Proposed Solution AI capability to be deployed, including technology and data requirements Scopes the technical work; prevents “let’s also add” creep
6 Success Criteria Measurable outcomes that define success (time savings, accuracy, cost reduction) The absence of this element is the single most common cause of pilot purgatory
7 Baseline Metrics Current performance against which improvement will be measured You cannot prove improvement without a before state; this is non-negotiable
8 Timeline Start date, key milestones, evaluation date (4–6 weeks recommended) The fixed timeline creates urgency that prevents indefinite extension
9 Resources Required Budget, personnel, data access, technology infrastructure Surfaces resource conflicts before they cause mid-pilot delays
10 Risk Assessment Potential failure modes and mitigation approaches Identifies the conditions that would trigger a Pivot or Stop decision early
11 Data Requirements Documents, systems, or information needed for the pilot For POC: 5–20 representative documents — not full enterprise data ingestion
12 User Group Specific individuals who will use the AI capability Named users prevent the pilot from becoming a theoretical exercise
13 Evaluation Criteria How Scale, Iterate, Pivot, or Stop decisions will be made Pre-committed decision logic eliminates post-hoc rationalization of continued inaction
14 Expansion Path If successful, how the pilot will transition to broader deployment Signals to the organization that the pilot is a beginning, not the end state

Download the AI pilot charter template

The PDF is free and ungated — one click, no form. Take the editable Word version if you want to fill in the 14 elements in place and circulate it for sponsor sign-off. Both files carry the same template shown above, with a blank field under every element.

  • US Letter, all 14 elements with a blank field under each — short enough that a sponsor signs it in one sitting.
  • The Word file opens in Microsoft Word, Google Docs and Pages, so the sponsor and project lead can edit it directly.
  • Fill the baseline and success criteria first; everything else in the charter follows from those two rows. Prefer to draft it interactively? Use the AI Blueprint Builder, then see it running on your material with a demo on your own data.
Implementation Guidance
The discipline of completing a pilot charter forces clarity about objectives, resources, and evaluation criteria before investment begins. Pilots that skip this step often lack the baseline measurements required to demonstrate value or the success criteria needed to make objective decisions about continuation. For a Waypoint consulting engagement, charter completion is the first deliverable.

Hardware Entry Points: The $30K Path vs. the $150K Path

One of the most durable myths in enterprise AI is that you need a GPU-powered data center to run meaningful AI workloads. Chapter 9 of The AI Strategy Blueprint dismantles this myth with economics. The real question is not what infrastructure you ultimately need — it is what infrastructure you need to start.

Entry Point Hardware Estimated Cost Best For If AI Fails If AI Succeeds
Edge / Device Intel AI PCs (NPU-equipped) ~$2,000/device Individual users; first AI literacy deployments; DDIL environments Devices remain productive general-purpose workstations. Zero stranded capital. Proves value at individual level; identifies use cases for server investment
CPU Server Standard Xeon CPU server running Blockify ~$30,000 Team-level document AI; RAG deployments; cost-sensitive environments Server joins existing virtualization cluster. Full reuse. Zero waste. Proven ROI justifies GPU investment and scale-out
GPU Server NVIDIA-equipped GPU inference server ~$150,000+ High-throughput production; large-context models; enterprise-scale concurrent users Significant stranded capital. Career risk for the decision-maker. Full enterprise AI throughput; supports concurrent workloads at scale

The recommended progression is deliberate: deploy AirgapAI on AI PCs for immediate, low-risk value. Build AI literacy and identify high-value use cases through hands-on experience. Invest in CPU server infrastructure (the $30K Blockify path) once specific high-ROI document AI applications justify it. Advance to GPU infrastructure when proven ROI from the CPU server provides objective justification.

This “From Device to Data Center” progression eliminates stranded capital at every stage. If AI proves less valuable than anticipated, each piece of infrastructure has a non-AI use case. This is the opposite of the typical enterprise pattern of pre-purchasing GPU infrastructure in anticipation of use cases that never materialize.

For the full economics comparison of edge vs. cloud AI deployment, including TCO calculations, see: Edge AI vs. Cloud Cost: A CFO’s Guide.

The 24-Hour Imperative

Chapter 9 contains one directive that overrides every other consideration in early-stage AI deployment. It is not qualified by organization size, industry, or technical readiness. It applies universally:

Get working AI in users’ hands within 24 hours, demonstrate value immediately, then expand based on proven success.
— John Byron Hanby IV, The AI Strategy Blueprint, Chapter 9

This directive exists because the traditional enterprise approach to AI — 12–18 months of platform evaluation, procurement, infrastructure provisioning, security review, and change management before a single user touches the system — is the factory that produces pilot purgatory. Chapter 9 calls this POC Limbo: extended proof-of-concept phases that stall adoption. Complex infrastructure requirements create analysis paralysis. Technical decision-makers get lost in architecture discussions while competitors deploy.

The solution is not to skip security. It is not to skip governance. It is to use an entry-point-priced, immediately deployable platform that makes a 24-hour first deployment possible without compromising on air-gap security, data sovereignty, or compliance posture. That platform exists. Organizations have deployed it in SCIFs, nuclear facilities, and county government networks — and still started in under 24 hours.

AI Academy

Every Successful Pilot Starts With People Who Know How to Use It

The 70% of AI success that depends on workforce skill is exactly why pilots get stuck. AI Academy delivers the literacy that makes your first pilot the one that actually sticks. 810+ courses, role-based curricula, and a $7/week trial that starts in minutes.

  • 912+ courses across beginner, intermediate, advanced
  • Role-based curricula: Marketing, Sales, Finance, HR, Legal, Operations
  • Certification programs aligned with EU AI Act Article 4 literacy mandate
  • 7-day free trial — start learning in minutes
Explore AI Academy
912+ Courses
7-Day Free Trial
8% Of Managers Have AI Skills Today
$135M Productivity Value / 10K Workers
Expert Guidance

Turn the Framework Into a Funded Plan

Turn these frameworks into action with hands-on expert guidance. Iternal's AI strategy consulting programs help organizations implement cost-optimized AI architectures that deliver measurable ROI.

$566K+ Bundled Technology Value
78x Accuracy Improvement
6 Clients per Year (Max)
Masterclass
$2,497
Self-paced AI strategy training with frameworks and templates
Transformation Program
$150,000
6-month enterprise AI transformation with embedded advisory
Founder's Circle
$750K-$1.5M
Annual strategic partnership with priority access and equity alignment
FAQ

Frequently Asked Questions

Pilot purgatory is the state in which an organization runs multiple AI proofs of concept indefinitely — consuming resources and credibility — without any project ever graduating to production deployment. It creates the illusion of AI progress while delivering no actual business value. According to IDC data cited in The AI Strategy Blueprint, the typical enterprise has identified hundreds of GenAI use cases but deployed fewer than six to production. The difference between the identified and the deployed is pilot purgatory.

Chapter 9 of The AI Strategy Blueprint identifies four root causes: (1) Complexity Overload — attempting enterprise-wide change before proving value in a single team; (2) Capability Gaps — discovering missing skills, governance, or data infrastructure during production rollout rather than before; (3) Resource Constraints — long timelines expose large programs to competing priorities and budget cycles; (4) Change Resistance — broad mandates trigger organizational antibodies that narrowly scoped, volunteer-driven pilots avoid. Each failure mode is amplified by scale and compressed by scope reduction.

The AI Strategy Blueprint recommends targeting four to six weeks for initial value demonstration. This compressed timeline creates urgency that prevents scope creep and forces decisions. The book advises setting worst-case timeline expectations at eight weeks while internally targeting four weeks — creating buffer while typically delivering ahead of schedule. Open-ended exploration without a fixed evaluation date is the structural mechanism that produces pilot purgatory.

A pilot charter is a pre-implementation document that defines the 14 elements required for an objective pilot evaluation: project name, executive sponsor, project lead, business problem, proposed solution, success criteria, baseline metrics, timeline, resources required, risk assessment, data requirements, user group, evaluation criteria, and expansion path. The charter matters because pilots without pre-agreed success criteria cannot be objectively evaluated — making the Scale/Iterate/Pivot/Stop decision a political exercise rather than a data-driven one. Organizations that use the charter consistently make their evaluation decisions in days, not months.

Chapter 9 of The AI Strategy Blueprint recommends starting with a broad, horizontal capability: a local, secure AI chat assistant paired with training for every employee. This single deployment gives the organization outsized returns while building the AI literacy required for every subsequent pilot. Workflow automation is a Walk or Run phase project — it requires the organizational experience, governance maturity, and user adoption that only the Crawl phase can build. Starting with automation before establishing literacy is one of the most consistent patterns in failed pilots.

The book prescribes five concrete disciplines: (1) Complete a 14-element pilot charter before any technical work begins; (2) Set a fixed 4–6 week evaluation timeline with a pre-committed Scale/Iterate/Pivot/Stop rubric; (3) Choose a use case that avoids the four anti-patterns (high-stakes decisions, extensive integration, immature data, unclear success criteria); (4) Use a sub-$100/user entry point like AirgapAI to remove career risk from the initial decision; (5) Apply the Crawl-Walk-Run framework to build confidence incrementally rather than committing to full automation before proving value at internal review.

Run it as a decision, not an experiment. Write the 14-element pilot charter before any technical work starts, so the business problem, the baseline, the success criteria, the named users and the expansion path all exist on paper and are signed by the executive sponsor. Pick one bounded use case in one department and avoid the four anti-patterns: high-stakes decisions, extensive integration, immature data and undefined success criteria. Fix the evaluation date at four to six weeks and put the capability in users’ hands within 24 hours, because usage data is the only evidence that survives an executive review. Instrument the baseline metric from day one. At the evaluation date, apply the pre-committed Scale / Iterate / Pivot / Stop rubric and record the decision in writing. Pilots reach production when the expansion path was agreed before the pilot began, when a named owner inherits the service, and when the workforce has the literacy to use it — which is why the first deployment should be a broad, horizontal capability paired with training.

A proof of concept answers a technical question: can this capability work at all on our data? It runs for days to two weeks, uses 5 to 20 representative documents, and is judged by the project team on output quality. An AI pilot answers a business question: does the capability measurably change the work for a named group of real users? It runs four to six weeks against a written baseline, and the executive sponsor judges it against charter criteria. An MVP is the stage after that — the smallest production-grade release that a named owner operates, supports and expands. Confusing the three is expensive in both directions: a proof of concept evaluated by pilot criteria looks like a failure because no user behavior changed, while a pilot evaluated by proof-of-concept criteria gets declared a success and then quietly dies, because feasibility was never the question the business was asking. When the software installs in a day on hardware you already own, the proof of concept collapses into the first afternoon of the pilot.

The dominant challenges are organizational rather than technical. Scope is the first: attempting an enterprise-wide program before proving value in one team multiplies coordination overhead until the initiative stalls. Capability gaps are the second: missing skills, governance or data foundations get discovered during rollout instead of before it. Resource and attention constraints are the third: long timelines expose a program to competing priorities and budget cycles. Change resistance is the fourth: broad mandates trigger organizational antibodies that a narrowly scoped, volunteer-driven pilot never encounters. Underneath all four sits workforce literacy — most people cannot adopt a tool they have never been taught to use, which is why the AI Academy training layer usually determines whether a technically sound pilot survives contact with the organization. Data readiness, security review cycles and cost uncertainty compound each of them, and all three shrink when the deployment runs locally on infrastructure and devices the organization already owns.

John Byron Hanby IV
About the Author

John Byron Hanby IV

CEO & Founder, Iternal Technologies

John Byron Hanby IV is the founder and CEO of Iternal Technologies, a leading AI platform and consulting firm. He is the author of The AI Strategy Blueprint and The AI Partner Blueprint, the definitive playbooks for enterprise AI transformation and channel go-to-market. He advises Fortune 500 executives, federal agencies, and the world's largest systems integrators on AI strategy, governance, and deployment.