The Authority Layer Every Enterprise AI Program Misses

Q: What is the "authority layer" in enterprise AI architecture?

The authority layer is a senior architecture function that sits above individual AI delivery teams and owns the coherence of the whole programme. It is not another platform or model; it is a role whose single deliverable is that many independent teams build toward the same target, speak the same architectural language, and do not each solve the same problem in a different way. Concretely it is made of six responsibilities: acting as the senior architecture authority across all AI and GenAI initiatives; developing and maintaining the enterprise AI target architecture and roadmap; translating business objectives into scalable architecture principles; defining reusable architecture patterns; establishing principles for the technical domains (model selection, RAG, agents, orchestration, data integration, platform services); and ensuring alignment with the enterprise's security, data, integration and infrastructure strategies. The reason it matters is economic and organisational: without it, an enterprise eighteen months into its GenAI journey typically has a dozen parallel initiatives, each with its own vector store and RAG stack, which sum to duplication, unbounded cost and technical debt that nobody is accountable for. The authority layer is the operating system that keeps the investment coherent as it scales from a handful of pilots to hundreds of production workloads.

Q: Why do enterprise AI programs fragment into duplication and cost?

They fragment because every team optimises locally and nothing owns the global coherence. Each initiative, taken in isolation, makes reasonable choices — a sensible model, a sensible vector store, a sensible retrieval stack — but because there is no function accountable for the sum, those locally-reasonable choices add up to duplication no one chose and a bill no one forecast. This is exactly the failure that platform engineering solved for cloud infrastructure: point solutions do not compose, platforms do. Eighteen months in, the symptoms are consistent across large organisations: a dozen RAG stacks that disagree, multiple opinions on which model to call, several definitions of what "good" looks like, and a quiet accumulation of technical debt spread across teams and delivery partners with no single owner. The fix is not to slow teams down or centralise all delivery; it is to introduce a senior architecture authority whose job is coherence — a shared vocabulary, reference architectures, published review criteria, and shared platform services built as products — so that the tenth use case is as cheap to say yes to as the first. Fragmentation is the default state of any sufficiently large AI programme; coherence is something a specific function has to be made accountable for.

Q: How does an architecture authority have influence without direct reporting authority?

It earns influence rather than being granted it, because in practice this role almost always operates without a direct reporting line over the teams and delivery partners whose work it shapes. The authority comes from three things. First, clarity and consistency: a shared vocabulary and a set of reference architectures every team can point to, plus architecture reviews with published, predictable Go/No-Go criteria, so a decision feels like a standard being applied rather than a personality being appeased. Second, durable memory: decisions captured as Architecture Decision Records so the reasoning survives staff turnover and partner rotation, which means the same debates are not re-litigated every quarter. Third, and most important, paving the road: making the compliant path the easy path, so teams choose it because it is genuinely the fastest way to ship, not because they were forced. The failure mode that destroys this kind of authority is architecture-as-bureaucracy — a review board that becomes a queue, a standard nobody can actually implement, or a "no" with no accompanying "here is the supported yes." Authority that blocks gets routed around; authority that makes teams' lives easier gets consulted before the build instead of after it, which is the entire point.

Q: What are the four planes of an enterprise AI target architecture?

A usable target architecture is layered rather than monolithic, and it is helpful to think of it as four planes so that every proposed solution can be located on the map. The data layer is where governed enterprise data lives and how AI reaches it — the systems of record, document repositories and data lakes, plus the controlled interfaces through which models get access. The model and platform layer holds model access, vector search, the AI gateway, orchestration and the other shared services that many applications depend on. The application layer is where business value is actually delivered: the assistants, agents and automations that end users and processes touch. And cutting across all three is the governance layer — security, evaluation, observability and compliance — which is not a separate silo but a set of concerns that apply to every plane. Two disciplines make the difference between a target architecture that is used and one that decorates a slide: it must be a living, versioned artifact that changes deliberately, dated and reviewed like code rather than baked once into a PowerPoint; and its roadmap must be capability-based rather than project-based, sequencing the shared capabilities that let future projects ship cheaply instead of listing which projects ship this quarter.

Q: What architecture principles should govern an enterprise AI program?

Principles are the bridge between a business objective like "reduce cost-to-serve" and the architecture that delivers it, and good principles are opinionated and few because each one constrains hundreds of downstream decisions so they do not have to be re-argued. Five recur across engagements. Reuse before build: a new component must justify its existence against the shared platform rather than being spun up by default. Data sovereignty by default: where data is sensitive, the architecture keeps it under the organisation's control — on-device, in-region or air-gapped — as the default rather than an exception, which often makes open-weight or on-prem models the requirement, not a compromise. Measure before you scale: no use case graduates from pilot to production without an evaluation baseline. Cost-aware by design: unit economics such as cost per interaction, per token and per retrieval are a first-class design constraint, not a bill discovered later. And human-in-the-loop where the stakes demand it: autonomy is earned by evidence, not granted by default. Underlying all of them is a distinction that is easy to blur — "scalable" means three things at once: technical scale (handling load), organisational scale (many teams building without a central bottleneck), and economic scale (unit cost falling, not rising, as volume grows). An architecture can ace one and fail the others, and the principles exist precisely to protect all three simultaneously.

Q: Why is a reusable pattern catalogue so valuable, and what makes a pattern useful?

Principles set direction, but patterns make that direction reusable, and a pattern catalogue is the single highest-leverage artifact the architecture function produces because it converts hard-won architectural judgement into something a delivery team can pick up and apply without re-deriving it. The recurring patterns in enterprise GenAI are surprisingly few — retrieval-augmented generation, the agentic or tool-using pattern, intelligent document processing, enterprise knowledge search, batch and streaming inference, and a handful of orchestration shapes — and most real use cases are combinations of these. What makes a pattern genuinely useful, as opposed to a diagram someone drew once, is a consistent anatomy: context and problem (when the pattern applies and, just as importantly, when it does not); solution and components (the building blocks and how they connect); trade-offs (what you are giving up by choosing it); and a reference implementation (a golden template or paved-road starter that turns the pattern from documentation into a running head start). The catalogue itself needs an owner and an evolution process, because patterns rot as the underlying technology moves and a stale catalogue is worse than none — teams stop trusting it and go back to re-deriving everything. Treated well, the catalogue is what lets an enterprise say yes to the tenth use case as easily as it said yes to the first.

Q: What is "governed access, never direct access" for enterprise data?

It is the principle that AI systems must reach enterprise data through controlled, contract-defined interfaces that respect classification and identity, rather than by pointing a model directly at a production database or data lake. Direct access is a trap because it bypasses the very controls that make enterprise data safe to use: there is no enforcement of data classification, no propagation of the requesting user's identity and entitlements, no rate or lineage control, and an effectively unbounded blast radius if the model or its prompt is compromised. A governed interface, by contrast, declares what it exposes, at what classification, with what identity requirements, at what freshness and rate — which lets the team that owns the system of record stay the owner while still serving AI use cases. This distinction becomes especially sharp for retrieval-augmented generation, where the hard enterprise problem is not retrieval quality but permissions: a user must never be able to retrieve a chunk they are not entitled to see, which means identity has to propagate all the way to the index. Get that wrong and RAG becomes a data-leak engine that dissolves years of carefully built access control. Governed access also cleanly separates read paths (context for RAG) from write and action paths (agents that mutate systems), each of which needs its own controls, and it keeps AI from forming a parallel data pipeline that ignores the enterprise's existing data standards.

Q: How does enterprise AI stay aligned with security, data, and infrastructure strategy?

By treating AI as subject to the same concerns that govern the rest of the enterprise rather than exempt from them, because AI amplifies those concerns rather than escaping them. On security, GenAI introduces a genuinely new attack surface — prompt injection, data exfiltration through retrieval, model supply-chain risk and over-permissioned agents — so least privilege, input and output guardrails, and secrets discipline apply with more force here, not less. On data, classification, lineage, residency, DLP and PII handling are foundational, and this is where data-sovereignty commitments become concrete through on-device PII detection, in-region processing and auditable evidence of what the system did and why; regulatory regimes such as the EU AI Act, ISO 42001 and the NIST AI Risk Management Framework increasingly require that evidence to exist by design rather than be reconstructed after an audit. On integration and infrastructure, AI solutions must fit the existing enterprise architecture — API standards, event-driven patterns, established integration platforms — instead of forming a parallel universe, and they must respect an infrastructure strategy that now includes GPU economics, hybrid and edge deployment, resilience and FinOps discipline aimed at AI's unusual cost curve. The architect who ensures this alignment is not slowing AI down; they are the reason it can go into production and stay there, because a system that violates the enterprise's security, data or integration standards never makes it past review, or is pulled back out after its first incident.