Alignment before architecture
In large enterprises, cross-functional alignment (not models) often determines whether AI reaches production. A field note on the ~40% nobody budgets for, and why business, risk, security, and technology must decide as one.
The technology is rarely the bottleneck.
In a recent large regulated programme, the kind with hundreds of use cases in the pipeline, multiple platforms, and every function claiming a stake in AI, my rough estimate is that around 40% of effort went to alignment. Not coding. Not model selection. Not infrastructure diagrams.
Alignment means talking with different stakeholders, translating between teams, sharing context that lived in fifteen different decks, and getting perspectives close enough that execution could actually move.
That number will vary by organisation. But the pattern is consistent enough that I would treat it as a planning assumption, not an anomaly.
Everybody has a legitimate opinion
Walk into any enterprise AI conversation and you will hear four competent, partialy overlapping views.
Business wants value, speed, and something the board can point to this quarter.
Technology wants a coherent platform, reuse, and standards that survive past the pilot.
Security wants boundaries, identity, data handling, and controls that scale with agents, not bolted on after the demo.
Risk and compliance want proportionate assurance. What can go wrong, for whom, and under what authority.
Data sits underneath all of them. So does internal audit. So does procurement. So does the line manager who will own the workflow on day one.
None of these perspectives is wrong. The failure mode is when they dont meet as one decision.
What the frameworks actually say
If you look at how the major advisory firms frame enterprise AI (Deloitte’s Trustworthy AI, KPMG’s Trusted AI, EY’s responsible AI governance, PwC’s work on responsible AI operating models) the language differs, but the structure repeats.
People, process, and technology, aligned end to end.
Not a security annex. Not a risk checklist stapled to a business case. Not an architecture review that happens after the budget is approved. An operating model where roles are clear, decisions are joint, and governance runs through the lifecycle, from use-case intake to production monitoring.
The World Economic Forum’s 2026 work on organizational transformation in the age of AI pushes the same point from a different angle. The constraint is increasingly organizational readiness, not model capability.
Consulting slides call this an “AI governance operating model.” In practice, it is a standing forum where trade-offs get made in the open, with enough authority that the answer sticks.
What happens when alignment is missing
I have seen the alternative. It is expensive and it rhymes.
Parallel platforms, each function funds its own stack because nobody agreed what “shared” means.
Architecture by escalation, solution design shifts in the meeting after the meeting, depending on who was in the room.
Risk assessments that talk past each other, business rates a use case “low risk” because the demo looked fine; security rates it “high” because agents can read email; nobody reconciled the frame.
Use cases that die in committee, not because they were bad ideas, but because no one owned the integrated answer.
Business alone will over-commit. Technology alone will over-standardise. Risk alone will over-block. You need a single thread, one goal, one reporting line, one definition of “ready for production” that all four can sign up to.
That is not bureaucracy. That is how you avoid building four different companies inside one enterprise.
The role that unlocks progress
Someone has to do the cross-domain work. Not as a permanent committee chair. Not as a process cop.
The useful profile is closer to this.
Optimistic enough to keep conversations moving when they stall on vocabulary.
Easy enough to approach that security, risk, and engineering will actually pick up the phone.
Technical enough to understand what is being proposed.
Commercial enough to know why it matters.
Patient enough to run the same alignment conversation ten times without sounding bored.
In the programme I reference above, that work looked like platform ownership sitting next to solution architecture. Not because the title matters, but because someone had to hold the whole picture while specialists did their part.
Call it an AI product owner, a platform solution owner, a transformation lead, or an enterprise AI architect. The label is negotiable. The function is not.
A practical recommendation
If you are trying to move AI into production-grade environments, especially regulated, especially at scale, especially with a long pipeline of use cases, budget for alignment explicitly.
- Name a cross-functional forum with decision rights (not just “awareness”).
- Define a single intake-to-production path (business case, technical design, security review, risk sign-off, operational handover) as one workflow, not four parallel tracks.
- Assign someone to stitch it together, the person who translates, follows up, and closes gaps between teams.
- Report progress in one language, value, risk, and delivery status on the same page, for the same steering group.
- Assume ~30-40% of programme time for alignment in year one. Adjust down only when you have evidence, not hope.
The organisations that scale AI are not the ones with the flashiest models. They are the ones where business, technology, security, and risk learned to act as one, communicated, reported, and executed toward a single goal.
That is unglamorous work. It is also, in my experience, the work that separates pilots from production. More alignment work then technology, if you are honest about where the hours go.
Field note from the build-in-public log. NDA-safe, no client names, rounded figures only. If this matches what you are seeing, get in touch.