Opening

David Park, VP of Engineering at an insurance company, was procuring an AI platform for claims processing. His purchasing team applied their standard software procurement playbook: issue an RFP, collect bids, evaluate on price and features, sign a contract, and deploy.

Six months in, the project was in crisis. The vendor's model had been trained on historical claims data that didn't reflect the company's actual claim distribution. The service-level agreement promised 99.5% accuracy, but the model was achieving 87%. The contract's liability clause didn't account for AI-specific risks like model drift or adversarial inputs. And the company had no rights to the training data or model weights, which meant they were locked into a relationship with a vendor whose performance was deteriorating.

The fundamental problem: AI procurement is not software procurement. A software contract specifies what code runs when, what data flows where, and what support the vendor provides. An AI contract has all those elements plus a crucial addition: the model's behavior changes based on input data it hasn't seen before. You're not buying a static thing; you're entering into an ongoing relationship where both parties' assumptions can be violated.

David realized his company had applied the wrong framework entirely. They needed a procurement approach that accounts for model performance, data ownership, ongoing training, retraining triggers, liability in edge cases, and vendor accountability for model quality.

This lesson walks through what makes AI procurement different and how to structure contracts and relationships that protect your organization.

As you navigate these decisions, you'll face pressure from multiple directions: stakeholders with competing interests, market conditions that shift faster than models can adapt, resources that are always constrained, and risk that's difficult to quantify. Without a clear framework and process, these pressures can drive reactive, inconsistent decisions that undermine your AI strategy.

This is why mature AI organizations treat this aspect with the same rigor they'd apply to financial decisions. They establish principles. They document reasoning. They create decision processes that balance speed with thoughtfulness. They learn from outcomes and adjust.

In this lesson, we'll build that framework for you.

Why This Matters

The financial stakes of AI procurement are substantial. When organizations treat AI procurement like software procurement, they systematically underestimate costs and overlook critical risks. We've seen companies allocate $2-3M for an AI platform and discover the true implementation cost is $8-12M. The incremental costs come from data preparation (often 50%+ of true cost), model training and validation, integration with existing systems, change management, and ongoing monitoring and retraining.

Second, strategic stakes. Choosing the wrong platform can lock you into a particular way of building AI that misaligns with your long-term strategy. A software vendor lock-in is annoying. An AI vendor lock-in can be existential. You've structured your entire AI capability around a vendor's tools and approaches, and now changing is prohibitively expensive.

Third, governance stakes. AI platforms often come with implicit assumptions about data governance, model governance, risk management. If you don't understand those assumptions before buying, you might end up with a platform that doesn't fit your governance requirements.

For your organization: How much have you budgeted for AI platform implementation? Is it just the software license or the full true cost including integration and change management?

Consider the financial stakes: a single misallocated $2M capital investment in an AI initiative that fails can trigger a 3-6 month recovery cycle, during which teams are reassigned and momentum is lost. But more importantly, poor capital allocation creates compounding losses. It's not just the $2M spent on the wrong project, it's the $1.5M NOT spent on the right project while you're recovering.

The Core Idea

The core differences between AI and software procurement:

Data requirements. Software is platform-agnostic about data. An accounting system works the same regardless of your financial data's quality or format. AI models are data-hungry and data-dependent. Your model's success depends critically on data quality, quantity, and structure. Before selecting a platform, you need to understand your data readiness.

Customization scope. Software you often buy off-the-shelf and implement as-is. AI requires significant customization. The platform is a foundation, but building AI that works for your use case requires substantial custom work on top of the platform.

Vendor dependency on expertise. With software, once it's implemented, your team can mostly operate it. With AI, ongoing model optimization requires data science expertise. You're often dependent on the vendor for guidance or you need to build internal expertise.

Cost structure. Software typically has licensing costs plus some implementation costs. AI has lower licensing costs but higher implementation costs, higher data preparation costs, and higher ongoing optimization costs.

Strategic impact. Software affects how you operate. AI affects how you compete. Choosing the wrong platform is more strategically consequential.

The framework has several key components: First, categorize your AI initiatives by type, revenue-generating, cost-reducing, risk-mitigating, and strategic/capability-building. Each category deserves different evaluation criteria. A revenue-generating project needs aggressive growth targets; a risk-mitigation project needs lower hurdle rates but higher certainty.

The framework has several key components: First, categorization. Not all AI initiatives deserve the same treatment. Some are revenue-generating (should be evaluated on ROI). Some are cost-reducing (should be evaluated on payback period and certainty). Some are strategic/capability-building (should be evaluated on competitive positioning and option value). Some are risk-mitigating (should be evaluated on loss prevention). By categorizing initiatives, you apply the right evaluation criteria to each type.

Second, decision criteria need to be established before evaluation. Common criteria include: expected return on investment, payback period, strategic alignment, technical readiness level, team capacity available, option value (what do we learn?), and execution risk. By deciding criteria first, you avoid the bias trap where you shift criteria to justify your preferred project.

Third, staged commitment. Rather than making a single $5M bet, stage it across decision gates. $500K for proof of concept, then $1.5M for pilot, then $3M for scale. Each stage is conditional on the previous stage meeting criteria. This converts binary bets into sequential conditional decisions made with real data rather than optimistic projections.

Fourth, portfolio thinking. Don't optimize individual projects; optimize the portfolio. A project might be individually great but add correlated risk to the portfolio (for instance, three projects depending on the same unreliable data source). Kill that good project because it's redundant or correlated. Invest in projects that diversify the portfolio even if individually they're less exciting.

Fifth, discipline. Establish decision gates and sunset criteria from the start. If a project hits $2M sunk cost and isn't meeting criteria, you escalate for a reallocation decision, not just accept the sunk cost and continue.

Think of It Like This

Think of AI procurement like building a house with a contractor, not like buying furniture. When you buy furniture, you specify what you want and the vendor delivers it. When you hire a contractor to build a house, you're partnering on design, material choices, timeline, cost management. The contractor's expertise shapes the outcome. Similarly, AI platform selection requires a partnership approach where the vendor's expertise and your requirements align, not a transactional approach where you just specify and receive.

Imagine you're a venture capital investor managing a fund. You don't put all your capital into a single bet. You diversify. You fund some companies that are low-risk, steady cash generators. You fund some moonshots with 10x upside but high failure rates. You fund some that fill strategic gaps in your portfolio. Your goal isn't to pick the single best company; it's to construct a portfolio where the winners more than offset the losers and your total returns exceed your hurdle rate.

Think of ai procurement is not software procurement like you're a venture capital investor managing a fund. You don't put all your capital into a single bet. You fund some companies that are low-risk, steady cash generators (your core portfolio). You fund some that are exploratory moonshots with 10x upside but 80% failure rates (your venture portfolio). You fund some that fill strategic gaps (your strategic portfolio). You don't optimize individual investments; you optimize the overall fund returns.

Your goal isn't to pick the single best company. Your goal is to construct a portfolio where the sum of weighted returns exceeds your hurdle rate, where failure of individual bets doesn't sink the fund, and where the portfolio adapts as market conditions change.

Now apply that exact logic to ai procurement is not software procurement in your organization. Each AI project is like a portfolio company. Some should be low-risk, near-term value generators. Some should be strategic bets with longer time horizons and higher uncertainty. Some should be capability-building that don't generate direct revenue but unlock future projects. Your job is to construct a portfolio of AI initiatives where the portfolio returns meet your organization's financial targets, where individual failures don't cripple the organization, and where you're systematically learning and adapting.

What This Looks Like in Real Life

A manufacturing company wanted to deploy AI for quality control. They asked three vendors to propose solutions. Vendor A quoted $500K platform license. Vendor B quoted $400K. Vendor C quoted $600K. They selected Vendor A based on cost. But they hadn't thought through the full picture. Vendor A required extensive data labeling (50,000 images) before the platform could work effectively. Vendor B had pre-built models for common manufacturing use cases that required minimal customization. Vendor C had the best data integration with their existing manufacturing systems. True total cost: Vendor A $2.2M (licensing + data prep + integration). Vendor B $1.1M. Vendor C $1.4M. Cost winner was Vendor B, not Vendor A.

Here's a real-world example: TechCorp, a B2B software company with $300M in revenue, had $8M to allocate across AI initiatives in 2023. They evaluated four projects: Project A (customer churn prediction) promised 18-month payback and $4M annual revenue at full scale; Project B (code generation for sales engineers) was lower-revenue but highly strategic, positioning their product differently from competitors; Project C (internal operations AI) would save $1.5M annually but created no customer value; Project D (advanced research into ML interpretability) had no near-term revenue but could become table-stakes in their market in 3 years.

Without a framework, TechCorp would have funded all four and spread resources too thin. Instead, they used a staged allocation approach: Project A got $2.5M upfront for the full build (proven market need, clear ROI). Project B got $1.2M for a pilot (strategic but unproven). Project C got $800K (necessary but lower-impact). Project D got $400K for a 6-month research sprint (option value, explore before committing).

Here's a real example: TechCorp, a B2B software company with $300M revenue, had $8M to allocate in 2023. They evaluated four projects: Project A (customer churn prediction) promised 18-month payback and $4M annual revenue at scale. Project B (product positioning AI) was lower-revenue ($1.2M annually) but strategically important. It positioned them differently from competitors. Project C (internal operations AI) would save $1.5M annually but didn't generate customer value. Project D (research into ML interpretability) had no near-term revenue but could become table-stakes in their market in 3 years.

Without a framework, they'd fund all four and spread resources too thin. Instead, they used staged allocation: Project A got $2.5M upfront (proven market need, clear ROI). Project B got $1.2M for an initial pilot (strategic but unproven, so staged). Project C got $800K (necessary but lower-impact). Project D got $400K for a 6-month research sprint (explore before committing $2M+).

At 6 months: Project A was tracking 22% above forecast. Project B's pilot showed promise but revealed market challenges; they requested an additional $600K and 3 months rather than the $2M originally planned. Project C was on plan. Project D's research revealed that interpretability wasn't yet a market differentiator, so they reduced it to $100K annual on-demand research.

At 12 months: Project A accelerated to launch after 14 months instead of 18 (outperforming). Project B had validated the market; they committed the additional funding and moved to full build. Project C was delivering promised value. Project D was paying dividends in adjacent research projects.

This is real ai procurement is not software procurement execution: staged, adaptive, portfolio-oriented. TechCorp didn't predict the future perfectly. They made conditional decisions with real data.

Where People Get This Wrong

1. Comparing only licensing costs, not total cost of implementation. 2. Assuming the vendor handles all the heavy lifting when actually your team needs to build significant custom work. 3. Not assessing your data readiness before selecting a platform. 4. Underestimating integration complexity. 5. Treating platform selection as a one-time decision instead of an ongoing partnership where you'll need to work closely with the vendor.

Mistake 1: Treating capital allocation as a one-time annual decision. Leaders lock in budgets in January and fund projects regardless of what they learn. Better approach: establish quarterly or semi-annual reallocation windows where you can shift capital based on actual performance data. A project that's performing 30% above forecast might deserve additional capital; a project tracking 40% below might need scaling back or killing.

Common mistakes in ai procurement is not software procurement:

Mistake 1 is treating allocation as a one-time annual decision. Lock in budgets in January and fund projects regardless of what you learn. Better approach: establish quarterly or semi-annual reallocation windows where you adjust based on performance data. A project performing 30% above forecast might deserve additional capital; a project 40% below target might need scaling back or killing.

Mistake 2 is using the same criteria for all projects. Applying a "must achieve 40% ROI" hurdle to everything systematically rejects strategic investments that generate value in harder-to-measure ways. Better approach: explicitly categorize projects, then apply differentiated criteria. Cost-reduction projects need quantifiable ROI. Strategic capability-building projects can have longer time horizons and softer metrics.

Mistake 3 is incomplete capital allocation. A project gets approved for $2M but doesn't get the data infrastructure investment, senior engineer time, or business stakeholder alignment it needs. The project fails not because the idea was bad but because allocation was incomplete. Better approach: when you allocate capital to a project, also commit to complementary resources required to make it succeed.

Mistake 4 is never killing projects. Your portfolio becomes a graveyard of zombie initiatives that consume resources without generating returns. Better approach: establish explicit sunset criteria. Projects need to hit specific milestones by specific dates, or they get escalated for reallocation decisions.

Mistake 5 is not learning from allocation decisions. Projects end, you move to the next one, nobody captures what was learned about estimation accuracy, risk realization, market assumptions. Better approach: conduct post-decision reviews. If your revenue forecasts are consistently 30% too optimistic, that's crucial input for future planning.

Practical Takeaways

1. Before evaluating vendors, assess your data readiness. Do you have the data the platform needs? Is it clean enough? Is it structured properly? 2. Request detailed implementation timelines and costs, not just licensing. 3. Understand what customization your use case requires. 4. Assess vendor expertise in your domain. Can they guide optimization or do you need to build internal expertise? 5. Think about long-term partnership. Is this vendor someone you want to work with for 3+ years as AI evolves?
2. Map your AI initiatives into a 2x2 grid: one axis is risk/uncertainty (low to high), the other is time-to-value (short to long). This simple visualization immediately shows you whether your portfolio is balanced or skewed. Ideally you have initiatives in all four quadrants, some near-term wins, some long-term bets, some low-risk incremental progress, some exploratory.
3. For each initiative, document: what stage of the project lifecycle it's in (exploration, pilot, scaling, mature), what capital has been deployed, what you've learned, what the next decision gate is, and what criteria would trigger a kill decision. This forces you to make allocation decisions continuous and data-driven rather than set-and-forget.

Actionable takeaways for ai procurement is not software procurement:

1. Create a 2x2 grid of your AI initiatives: one axis is risk/uncertainty (low to high), the other is time-to-value (short to long). This single visual immediately shows whether your portfolio is balanced or dangerously skewed. Ideally you have initiatives across all four quadrants.
2. For each initiative, document: current project stage (exploration, pilot, scaling, mature), capital deployed to date, what you've learned, what the next decision gate is, what criteria would trigger a reallocation or kill decision. This forces continuous, data-driven allocation decisions.
3. Establish a regular rhythm (quarterly works) for portfolio reviews where you assess performance and make reallocation decisions. Explicitly ask: Which projects are outperforming and deserve more capital? Which are underperforming and should be scaled back? What new opportunities have emerged that deserve exploration? This creates adaptive portfolio management rather than set-and-forget.
4. Build decision discipline: don't approve projects without clear decision criteria, don't expect perfect foresight, do stage capital commitments so you can adjust based on real data, and do kill projects that don't meet criteria. Sunk cost bias is real, most organizations keep funding failing projects because they've already invested heavily. Resist that.
5. Connect allocation to organizational learning: conduct post-decision reviews on completed projects. Capture lessons about forecasting accuracy, risk realization, and execution. Share these learnings across the organization to improve future allocations.

Key Insight

AI procurement requires strategic partnership thinking, not transactional vendor-selection thinking.

This is an important aspect of the overall framework we're building. king, not transactional vendor-selection thinking.

t aspect of the overall framework we're building. king, not transactional vendor-selection thinking. This aspect of ai procurement is not software procurement deserves deeper consideration in your planning.

Before You Move On

For your next AI procurement: Calculate the full true cost of ownership, including data preparation, integration, and change management. Don't just compare platform licensing costs.

This is an important aspect of the overall framework we're building. ment. Don't just compare platform licensing costs.

t aspect of the overall framework we're building. ment. Don't just compare platform licensing costs. This aspect of ai procurement is not software procurement deserves deeper consideration in your planning.

Before moving forward, take time to reflect on how these concepts apply to your current situation. What decisions are you facing? What frameworks would help? How would you structure the decision process to get buy-in from stakeholders? What would success look like?