Pick AI Pilots You Can Afford to Succeed At

The worst outcome for an enterprise AI pilot is not failure. Failure is cheap. The vendor packs up, the innovation team writes a post-mortem, and the discretionary budget is reallocated. The worst outcome is a runaway success that the organization has no mechanism to fund, integrate, or operate.

Most pilot governance is designed to decide go or no-go. Almost none of it is designed to execute a go. The pilot succeeds, the model performs exactly as advertised, and the organization suddenly realizes it has no landing pad. The failure mode is not a bad model. It is a good model with nowhere to live.

A steering committee watches a demonstration of an internal contract-review assistant. The system searches and summarizes five PDF agreements in seconds. The enterprise architect asks how the application will enforce document-level Active Directory permissions across the 400,000 legacy contracts stored on the shared drive. The room goes quiet.

The demo used a static, scrubbed CSV file and a curated folder of selected agreements. Production requires real-time integration with a messy, permission-gated SharePoint environment and a legacy document management system. The cost of the AI model is a fraction of the project. The cost of building the data pipelines, access-control logic, and records retention checks to feed the model safely is the rest. The cleaned-up data set is part of the demo, not a property of the business.

There is also a shift in the underlying physics of the software budget. Traditional enterprise software gets cheaper per user at scale. You buy a site license or amortize the hardware. Generative AI API costs scale linearly, or worse.

A development team pilots a coding assistant. A group of fifty engineers uses the tool and reports a massive boost in velocity. The steering committee authorizes a rollout to the entire engineering department. By month three, twelve hundred engineers have access. The VP of engineering receives a cloud invoice showing that API costs have consumed the entire departmental software budget for the quarter, because developers left the auto-complete running constantly in the background.

In traditional software, scaling lowers the marginal cost. In AI, scaling just multiplies the API calls. A successful pilot creates a permanent, fluctuating monthly operating expense that procurement has no mechanism to cap without throttling the application. Vendor credits and subsidized pilot pricing are just a bridge to retail compute pricing.

Pilots are usually built by a dedicated innovation team or a vendor’s white-glove deployment unit. They operate outside the standard change management framework. When the pilot succeeds, the project team throws it over the wall to IT operations. Operations refuses to catch it, because there is no runbook, no dedicated support tier, and no budget for model drift monitoring.

A vendor’s solution architect is embedded with the team for eight weeks. She configures the integration, tunes the prompts, and writes the initial runbook. On the last day, she hands over a Confluence page and a Slack channel that goes quiet. The internal team realizes they have been renting competence, not building it.

This creates a structural gap in support. The vendor’s support contract covers the API. It does not cover your prompt, your integration, your data, or your user. Your service desk does not know the difference between a model issue and an integration issue. The support model is usually invented after the first incident.

The vendor updates their foundation model over a weekend. The prompt engineering that kept an internal HR chatbot from hallucinating salary bands no longer works. The chatbot begins telling employees they are eligible for executive bonuses. The original pilot builder has already left the company, and the operations team on the incident bridge has no idea how to adjust the system prompt or tune the temperature parameters.

Building an evaluation harness for an AI feature is real engineering work. It is not a spreadsheet or a subjective survey. It requires labeled data, regression suites, drift monitoring, and a person who owns the numbers. Pilots rarely budget for evaluation because the demo does not need it. Evaluation is the tax you pay for not knowing what your model does in production.

Integration is where pilots go to become projects. If the pilot does not touch the systems of record, it is a prototype. If it does, you have started a migration. The work required to move from an isolated prototype to an operable service wired into the corporate nervous system includes SAML integration, security compliance reviews, network egress audits, and automated data pipelines. This pilot-to-production gap usually requires three to ten times the effort of the pilot itself.

When the sanctioned path to production is blocked by this gap, the work routes around it. A finance analyst builds a reporting pilot on a personal API account, expenses it as software, and it becomes load-bearing for the monthly close. When she leaves, the team discovers the API key is tied to her personal email. The security review for the pilot was waived because it was just a pilot. Now the pilot is processing customer data, and the remediation requires a full security audit.

You do not pilot a technology to see if the model works. The model almost always works in a vacuum. You pilot it to see if your organization can tolerate the result.

Choosing a pilot is choosing a future cost. If the pilot works, you are on the hook for inference costs, integration maintenance, evaluation infrastructure, and an owner. If you cannot afford the second act, do not stage the first.

Price the production run at full enterprise scale before signing the pilot contract. If the scale-out number is impossible to get approved, the pilot is a waste of time. Put the operations team and the enterprise architects in the room during the pilot design phase. If they do not agree on how the system will be supported and integrated on day ninety-one, do not start day one.

Name the owner before the pilot starts. The owner is the person who will run it in production. If that person is not in the room, the pilot is just a demo with a longer timeline. Force the pilot to use real, messy, permission-gated corporate data. A pilot on clean data proves nothing about your environment.

Keep the option to stop credible, even when the pilot works. A favorable result should start a deployment decision, not substitute for one. If a pilot succeeds but the organization cannot afford to scale it, turn it off. A pilot running in a production-adjacent state without a budget is a liability. The discomfort of shutting it down is smaller than the discomfort of an unowned system processing real data.

A pilot is a commitment device. The pilot budget is the down payment. The production budget is the mortgage. Before you select a use case, identify the system it must connect to, the team that would own it, and the person who could fund the next stage.

The pilot asks if the model can do the work. The organization has to decide if it can afford the answer.