Most organisations pursuing AI at scale reach the same point. The proofs of concept worked. The pilot delivered. But somewhere between the lab and the operating environment, the initiative stalled. The explanation offered is that the organisation lacks the right talent.
In Brief
- When organisations struggle to scale AI, the default response is to create a new role rather than examine the structure that produced the gap.
- SAFe, ServiceNow, and the broader market are all converging on the same structural compensation: a bridging role that sits across teams because the operating model separates what AI requires to be integrated.
- Roles that compensate for structural gaps become permanent fixtures, and the gap is never addressed because the role absorbs the symptoms.
- The executive decision is whether to hire a bridge or redesign the structure that made bridging necessary.
The response is familiar: create a new role. In 2024 and 2025, that role was the AI architect. ServiceNow University describes it as a senior position accountable for AI strategy, infrastructure, governance, data readiness, business translation, and technology selection (ServiceNow, n.d.). In June 2026, Scaled Agile Inc. went further and formalised the pattern into a framework: AI-Native SAFe introduced a dedicated “AI value architect” responsible for guiding teams toward outcomes while navigating cost, ethics, legal, and risk considerations (Scaled Agile, 2026). Deloitte’s 2026 AI Governance Operating Model Guide defines three parallel governance layers, each with its own decision rights and escalation paths (Deloitte, 2024). The market is pricing the role aggressively. Autodesk’s 2025 AI Jobs Report showed a 109% year-on-year increase in demand for AI solutions architect positions (Autodesk, 2025).
Everyone can see the gap. Almost no one is asking what produced it.
The AI scaling gap is structural
The structural pattern beneath the AI scaling problem is not a talent gap. It is an operating model gap. Organisations running a Technical Operating Model (TOM), or “Plan-Build-Run,” create a functional separation of design, delivery, and operations by definition. Architecture decisions are made periodically, at approval gates and design reviews. Business translation happens through governance forums, not through the delivery cadence. Risk and compliance sit in a separate function from the teams building the product.
When AI enters this structure, it exposes every one of those separations. AI initiatives require continuous architectural decisions, not periodic ones. They require business context embedded in the team, not translated through a governance layer. They require data governance, model lifecycle management, and operational monitoring as integrated capabilities, not as oversight activities performed by a separate function. The Plan-Build-Run model cannot provide any of these because it was not designed to.
This is why the AI architect role bundles so many unrelated capabilities into a single position. The role includes:
- Business translation: because the organisation separates business and technology structurally.
- Governance: because the operating model does not embed governance in delivery.
- Change leadership: because existing TOM structures don’t support iterative deployment as a default behaviour (Conway, 1968; Skelton & Pais, 2019).
Each of these responsibilities exists in the role description because the operating model cannot perform them natively. The role compensates for the structure.
This pattern persists because the role itself absorbs the symptoms. Once an AI architect is in place and producing results, the structural gap that made the role necessary becomes invisible. The executive who approved the headcount receives confirmation that the decision worked. The operating model that produced the gap remains unchanged, and will produce the same gap the next time a capability arrives that requires cross-functional, continuous, integrated governance.
SAFe responded with more architect roles
SAFe’s response to AI-Native SAFe is instructive. The AI value architect sits alongside the existing System Architect and Solution Architect. It does not replace either. SAFe now has three architect roles operating at different levels, plus an Enterprise Architect at portfolio (Scaled Agile, 2026). The structural response to the AI governance gap is more structure. This is SAFe’s established pattern: when the framework encounters a capability it cannot process, it adds a role to the Big Picture rather than questioning whether the model’s separation of concerns produced the gap.
Deloitte’s approach is more considered. Their 2026 Pulse Check found that 48% of organisations had introduced AI without redesigning the workflows or roles it sits within, and only 12% reported redesign at scale with a new operating model behind it (Deloitte, 2026). Deloitte’s own risk leader warned that organisations that have not designed their accountability model by the end of 2026 risk finding it designed for them, whether by an audit finding, a regulatory requirement, or a visible AI failure (Deloitte, 2026). That is a structural diagnosis. But the practical response is still a parallel governance structure bolted onto the existing operating model, not a redesign of the model itself.
Even at the team level, the same pattern is appearing. New roles are emerging for “AI Product Owners” who sit at the intersection of product strategy and AI system behaviour (Codebasics, 2026). This is a separate, AI-specific version of the Product Owner, created because the existing role apparently cannot absorb AI governance into its normal accountability. The assumption underneath is that AI is so different it requires its own functional management. The alternative explanation is that the Product Owner’s accountability was already too narrow, and AI simply made that visible.
AI governance belongs inside the operating model
A single role for AI design creates a single point of failure.
The capabilities these roles describe are not the job of one person. In a product operating model, they are distributed across a product leadership structure:
- Product Manager, the product’s CEO: product strategy, including how AI supports customers.
- Chief Product Architect for that product: continuous technical accountability, including how AI is integrated into products and services.
- Product COO: process accountability, including the consistent use of AI tooling by teams within the value stream.
AI adds complexity to each of these roles. Model lifecycle management, data pipeline governance, and bias monitoring are real and demanding responsibilities. But they do not change where the accountability sits. What changes is what each role needs to know, not whether the role exists.
Over successive budget cycles, this bridging role becomes permanent infrastructure. What began as one AI architect becomes a team, then a function. The organisation has recreated the separation it was trying to overcome in a new form. Each decision made without addressing the underlying operating model gap makes the next reorganisation harder to justify and more expensive to execute.
Hire the role or fix the structure
The executive decision is not whether to hire an AI architect. It is whether the operating model can govern AI investment through its normal delivery structure, or whether a new role is being created to compensate for the fact that it cannot.
That distinction matters because the two paths lead to different organisations. One produces an AI capability that is integrated, governed through the delivery cadence, and scalable through the same structure that governs every other product investment. The other produces an AI capability that depends on a bridging role, one that works until the person leaves, the workload exceeds one person’s capacity, or the organisation’s AI ambitions outgrow the structure that was never designed to support them.
What this means for senior leaders
- The AI architect is a legitimate capability. The error is treating the hire as the solution to a structural problem it was designed to compensate for.
- When the operating model separates the concerns that AI requires to be unified, no single hire resolves the separation — regardless of seniority or scope of the role.
- The organisations scaling AI reliably are not distinguished by the AI roles they have created. They are distinguished by the operating model that made those roles unnecessary.
References
- Autodesk. (2025). AI jobs report 2025. Autodesk.
- Codebasics. (2026, May 29). How AI is changing the product manager role in 2026. Codebasics. https://codebasics.io/blog/how-ai-is-changing-the-product-manager-role-in-2026
- Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31.
- Deloitte. (2024). AI governance operating models and framework. Deloitte AI Institute.
- Deloitte. (2026, June 2). Enterprise AI trends 2026: AI transformation strategy. Deloitte AI Institute. https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/blogs/pulse-check-series-latest-ai-developments/ai-transformation-predictions-2026.html
- Hodgson, M. (2026). Evolve: The operating model AI demands. Zen Ex Machina.
- Scaled Agile. (2026, June 23). Scaled Agile releases AI-Native SAFe, a new version of the world’s most trusted framework, to provide governance for the AI era [Press release]. https://www.prnewswire.com/news-releases/scaled-agile-releases-ai-native-safe-a-new-version-of-the-worlds-most-trusted-framework-to-provide-governance-for-the-ai-era-302807369.html
- ServiceNow. (n.d.). What is an AI architect? ServiceNow University. https://www.servicenow.com/university/what-is-an-ai-architect.html
- Skelton, M., & Pais, M. (2019). Team topologies: Organizing business and technology teams for fast flow. IT Revolution Press.
