Overview

Lourival Macedo had ninety days. The chief transformation officer at a São Paulo–based logistics company had just convinced the board to fund a $4 million AI initiative - and now had to show measurable results before the next budget cycle. He sat in front of a whiteboard, marker in hand, staring at a list of twenty-three proposed AI use cases, a skeleton IT team, and no data governance policy. The money was real. The plan was not.

Why Sequence Matters More Than Speed

Most enterprise AI efforts fail not because the technology is wrong but because the order of operations is wrong. Teams rush to deploy machine learning models before they have clean data. They buy expensive platforms before they understand their own workflows. They train employees on tools that change every six months.

Think of it like building a house. You don't hang doors before you pour concrete. You don't install a roof before you raise walls. Every phase depends on the one before it. An AI capability roadmap works the same way: *foundation before walls before roof*.

Lourival's mistake - nearly everyone's mistake - is treating AI like software procurement. It is not. It is organizational infrastructure. And infrastructure has to be sequenced.

The Foundation: Data, Governance, and Talent Baseline

Before any AI tool goes live, three things must be in place: accessible data, a governance policy, and at least a small cluster of people who understand both.

Audit your data before you buy anything

Lourival's team spent their first three weeks doing something unglamorous: a data inventory. They mapped every internal system - their transport management system (TMS), warehouse management system (WMS), customer relationship management (CRM) platform - and graded each data source on completeness, consistency, and freshness. Only 40 percent of their data was usable without significant cleaning.

That number is typical. Most enterprises discover that 30–50 percent of their data is either siloed, duplicated, or too stale to train models on. If you skip this audit, you will buy an AI platform and then spend six months arguing about whether the output is trustworthy. Do the audit first. It costs time but saves money.

Write a governance policy before you scale

AI governance - the rules that determine who can use AI tools, what data they can touch, how outputs get reviewed, and who is accountable when something goes wrong - is not a compliance checkbox. It is the load-bearing wall of your AI house. Without it, every team builds its own shadow system. You end up with seventeen different ChatGPT accounts, no audit trail, and a security incident waiting to happen.

A minimum viable governance policy covers four things: data classification (what is confidential, what is public), acceptable use (which AI tools are approved and for which tasks), output review (who checks AI-generated work and how), and incident escalation (what happens when an AI system makes a costly mistake).

Lourival's team wrote a four-page policy in week two. It was not perfect. But having something written meant every team had a shared reference point instead of thirty individual interpretations.

Identify your AI literacy baseline

You need to know where your people actually stand. Not their enthusiasm - their ability. A short diagnostic assessment (ten to fifteen questions) across a sample of your workforce tells you how many people can distinguish a large language model (LLM) from a rule-based system, how many can write a useful prompt, and how many are still unsure whether AI is "the same as Google search."

Lourival surveyed 120 employees. He found three rough bands: 15 percent were already experimenting with AI tools independently, 55 percent were curious but passive, and 30 percent were actively skeptical or disengaged. That segmentation drove a tiered training plan - not one mandatory course that bored the 15 percent and overwhelmed the 30 percent.

The Walls: Prioritizing Use Cases and Build vs. Buy

With foundation in place, you can start building. The most common trap here is trying to build everything at once. You end up with nine half-finished pilots and no production deployments.

Score use cases on two axes only

Plot every proposed use case on a simple two-by-two grid: *value to the business* on one axis, *feasibility given your current data and talent* on the other. Start with the high-value, high-feasibility quadrant. Ignore the rest for now.

Lourival's team had twenty-three proposed use cases. After scoring, four made the first phase: automated invoice exception detection, route optimization suggestions, driver performance reporting, and a customer service draft-reply tool. Everything else was parked for phase two or dropped entirely. This is the hardest conversation - telling stakeholders their pet project is not in the first wave - but it is the conversation that keeps a roadmap realistic.

Build vs. buy: the honest version

The build-vs-buy decision has a simple rule of thumb: buy when a vendor has already solved your problem at a quality level you cannot match in twelve months; build when your data or process is genuinely proprietary and a generic tool will miss too much context.

For route optimization, Lourival's team evaluated three vendors - Routific, OptimoRoute, and a module inside their existing TMS. The TMS module was 70 percent of the capability at 20 percent of the integration cost. They bought it. For invoice exception detection, the company's invoice formats were highly non-standard. No vendor covered them well. They built a lightweight classifier using Python and scikit-learn, trained on two years of historical data, deployed in eight weeks at a cost of roughly $40,000 in engineering time. A vendor quote for comparable functionality was $180,000 per year.

The build-vs-buy decision is not ideological. Run the numbers. Make the choice specific to each use case.

The Roof: Scaling, Measuring, and Sustaining

The roof goes on last. It depends on solid walls. Scaling an AI capability before you have operational discipline is how you get expensive sprawl instead of leverage.

Set metrics before you deploy, not after

Every AI initiative needs a measurement plan written before go-live. What does success look like in sixty days? In six months? Lourival's invoice detection tool had a clear metric from day one: reduce the time finance staff spent on manual invoice exceptions from 11 hours per week to under 4 hours. At week eight, it was at 5.5 hours. Imperfect, but measurable and improving. That number justified continued investment and earned the finance team's trust.

>
"If you can't measure it before you build it, you can't defend it when the CFO asks why you spent $200,000."

Plan a realistic timeline

Most enterprise AI roadmaps underestimate time by a factor of two. A realistic phasing for a mid-sized organization looks like this: months one through three for foundation work (data audit, governance policy, talent assessment, first training cohort); months four through eight for first-wave use case pilots with defined success metrics; months nine through twelve for scaling what worked, retiring what didn't, and starting the second-wave use cases. Year two is when AI starts to feel like a muscle rather than a project.

Lourival's ninety-day board deadline was too short to show full returns. What he showed instead was a completed foundation, two pilots in production, and a measurement dashboard with early results. That was enough to secure the next funding round. Boards do not need miracles in ninety days. They need evidence of disciplined progress.

Build internal capability, not just vendor dependency

Every AI vendor relationship creates a dependency. That dependency is acceptable if you are also building internal understanding of what the tool does, why it works, and what happens when it fails. At minimum, one person on your team should be able to explain each production AI system in plain language and identify its failure modes. If no one on your team can do that, you do not have an AI capability. You have an AI subscription.

Lourival's team hired two AI product managers (not data scientists - product managers with AI literacy) whose job was to own vendor relationships, monitor model performance, and translate between the technical team and business stakeholders. That role, often overlooked, is what keeps an AI roadmap alive past the first year.

Key Takeaways

• Foundation before walls before roof. Data quality, governance policy, and talent baseline must exist before any AI use case goes to production.
  - Audit your data first. Expect 30–50 percent of enterprise data to be unusable without cleaning. Knowing this early prevents expensive surprises.
  - Write a minimum viable governance policy before you scale. Four pages covering data classification, acceptable use, output review, and incident escalation is enough to start.
  - Score use cases on value and feasibility, then pick the top quadrant. Running too many pilots at once produces nothing production-ready.
  - Build vs. buy is a per-use-case numbers question, not a philosophy. Generic tools win when they cover 80 percent of your need at a fraction of the build cost.
  - Set success metrics before deployment, not after. Predefined metrics are the only way to defend AI investments to leadership and earn team trust.
  - Realistic timelines run twelve months for first-wave maturity. Boards need evidence of disciplined progress in ninety days - not full returns.
  - Hire AI product managers, not just data scientists. Someone must own vendor relationships, monitor performance, and translate between technical and business teams for AI capability to survive past year one.