The Whole Building

AI doesn't hit a company on one floor. It hits the staircase.

Almost every corporate conversation about artificial intelligence happens inside a specialty. The infrastructure team discusses capacity. The data team discusses quality and provenance. The security team discusses attack surface. Legal discusses regulatory exposure. Every one of those conversations is competent, and every one of them is right about its own subject.

The problem doesn't live in any of them. It lives in the space between them, and that space has no owner.

The number that reaches the board, and the wrong way to read it

Eighty-eight percent of organizations already use AI in at least one function. Six percent can attribute more than five percent of EBIT to it.

Both numbers come from the same survey, McKinsey's State of AI, 2025, and they're almost always read the same way: the technology hasn't matured yet, it's early, the sensible move is to watch and enter later.

That's not what the survey found.

The gap between the six percent and everyone else is organizational, not technological. The ones getting results don't have better models. They don't have bigger budgets or access to anything unavailable to everyone else. They did one different thing, and it's a boring one: they redesigned the process before automating it, instead of hanging the tool on the process that already existed.

That's not a detail of method. It changes the nature of the problem, and it changes the math for anyone deciding to wait.

If the bottleneck were technological, waiting would be the prudent choice: technology gets better and cheaper over time, and whoever enters later buys better. Since it's organizational design, waiting is the most expensive option available: process redesign can't be bought off the shelf, doesn't get cheaper, and doesn't speed up because leadership decided it's now a priority. It takes years, and the years only start counting once someone starts.

The one position from which you could see both

I was on the first team assembled to stand up an international card network's operation in Brazil, in charge of the infrastructure connecting banks to the network.

It was like swapping an outlet in the morning and, that afternoon, sitting with a bank's CIO to decide how to connect the entire institution. That's not small-operation folklore, and it doesn't count as nostalgia from someone who used to do everything. It counts for another reason: it was the one position from which you could see that the morning's tactical problem and the afternoon's strategic decision were the same subject — and that nobody else was seeing both at once.

Whoever was only on the technical side saw a requirement. Whoever was only on the business side saw a schedule. Both readings were correct, and neither one contained the whole decision.

That was possible because the operation was small. As a company grows, that position disappears — and it disappears for a good reason.

Specialization is the right call. The side effect is that it has no owner

A large company solves complexity with specialization, and there's no serious alternative to that. Nobody wants a generalist deciding data architecture, or a data specialist deciding legal exposure. The division exists because it works.

The side effect is that nobody ends up owning the space between the specialties. That space has always existed, and for decades it was manageable: there were few interfaces, they changed slowly, and the cost of a mismatch was some rework.

With AI, that space got too big to keep going without an owner. Not because the technology is harder, but because it runs through every department at once, and each one receives it with a different vocabulary.

The same word, different things

An infrastructure engineer and a marketing director use the same word and aren't talking about the same thing.

They don't share the problem, don't share the vocabulary, don't share the fear, and — what matters most — don't share the criteria for success. For one, the system worked if it didn't go down and stayed inside the capacity budget. For the other, it worked if it produced more units in less time. Both are right within their own constraint, and that's exactly why the conversation between them sounds like agreement when it isn't.

Notice that the mismatch doesn't show up in the meeting. It shows up three months later, in the result.

How correct decisions produce a wrong result

It's worth walking through the mechanism slowly, because it's the whole thing.

The infrastructure engineer sizes for the queue and chooses to consolidate with one vendor. Correct: a scattered base gives you neither scale nor negotiating power. The architect picks the platform with the most mature tooling. Correct: mature tooling lowers delivery risk. The data team prioritizes volume, because volume is what makes the model work. Correct. Security asks for containment. Correct. Legal asks for supervision documentation. Correct. Strategy asks for speed, because the competitor started first. Also correct.

Add it all up.

The company concentrated dependency without ever calculating what it costs to leave. It delegated an action that can't be undone to a system nobody really audits. And it produced an approval trail that, on the day of the incident, documents, with date and time, that supervision was impossible.

Nobody got it wrong. And the result is wrong.

This is usually the point where the conversation turns to governance, committee, and policy — and it's usually where it dies, because a committee is where the same departments repeat the same correct positions, now with minutes attached.

What this puts on your desk

The useful question isn't which tool to adopt, or which floor you need to understand better. It's this: which decisions, from every floor, are already on your desk without a label?

They arrive disguised as a technical matter. A capacity request is actually a decision about where your workload runs when the resource gets scarce. A vendor choice is a decision about how much it'll cost to leave them two years from now. A workflow with human approval is a decision about who answers when it gets it wrong.

None of those three is technical. All three will be presented to you as if they were — not in bad faith, but because whoever presents them sees their own floor, and is right within it.

And there's a second question, the one that separates what can be delegated from what can't: which of these decisions can you not pass along, because the consequence isn't delegable? If something goes wrong and the explanation has to come from you, the decision was yours from the start, regardless of who actually made the call.

Why this is a series, not a manifesto

What I won't do is explain what each floor is. That's available everywhere, written better than I would write it.

What's worth trying is something else: walking the building floor by floor, showing, on each one, which decision is already on a leader's desk without having been labeled as such. Basement: energy and physical infrastructure. First: silicon. Second: data. Third: the builders of models and agents. Fourth: security. Fifth: regulation. Sixth: strategy. Seventh: creation and attention. Rooftop: leadership.

That's eight floors and ten weeks. The next floor is the basement, where I'll argue that the energy discussion that reaches the board is the wrong discussion, and that the number everyone repeats is true and useless.