Blog

Vanguard reframes scalable AI as an organisational and architectural question

A Vanguard session at MIT Technology Review argues that scalable AI requires integrated governance, data and controls, not just better models.

· By

A red stop switch on a steel panel and a key in the lock of a sealed metal cabinet, with blurred stacked control panels in the background.
Scalable AI requires controls and human intervention built in by design, before agents are connected to real systems.Image: IamVera.ai — original editorial illustration

A Vanguard session at MIT Technology Review argues that scalable AI does not depend on model power alone, but on an interplay of governed data, platform controls, authorisation, provenance, oversight and evidence. The practical consequence: treat governance as production infrastructure that you build in before you give AI agents more autonomy.

What exactly did the Vanguard session at MIT Technology Review establish?

During EmTech Future 2026, Jing Wang of Vanguard presented a session titled The Foundations of Scalable AI. The core of the session description: scalable AI only emerges when data, engineering, platforms, operating models and governance come together as a single foundation, certainly in the responsible deployment of agentic systems within a heavily regulated investment environment.

That is a shift in how the question is posed. Scaling is presented here not as a matter of a more powerful model, but as an organisational and architectural question. In our assessment, that is the most important interpretation: the session reframes scale from a model problem into a system problem. Our reading is at the same time that the Vanguard session does not prove a universal technical architecture and does not demonstrate that a single governance framework guarantees security; it is a well-founded reframing, not conclusive proof.

Which building blocks must governance for scalable AI include?

Recent academic work supports this systems approach and makes concrete which building blocks it involves. Together, these studies point to a control layer that covers more than the model itself.

  • Identity and authorisation: who or what may perform which action. The paper AGL-1 describes a governance layer spanning foundation models, retrieval, orchestration, memory, policy engines, observability, tools and applications, and identifies authorisation, provenance and memory governance among its governance domains.
  • Provenance and knowledge integrity: where an answer comes from and whether the underlying knowledge is reliable.
  • Controlled memory and tool use: the study Governance by Design argues that governance for agentic AI is established through architecture and working arrangements covering tools, data access, memory, learning and human oversight, built into the design rather than only as an external compliance layer.
  • External verification: research titled Avoid Overstretching LLMs for every Enterprise Task advocates placing knowledge storage, repeatable reasoning and verification in inspectable modules, and using the language model mainly as a structured interface. The paper links that modularisation to clearer fault attribution, more targeted evaluation and enforceable governance.
  • Observability and ultimate human responsibility: continuous visibility of behaviour, with a human able to intervene.

Our synthesis of these sources is that reliability is promoted by separating model generation from authoritative knowledge, computation and verification. In our analysis, a concrete audit consequence follows from this: a model that has to remember, reason and check everything itself is harder to audit than a system in which those functions are separate and inspectable.

What does this mean for executives, lawyers and CISOs who want to expand agentic AI?

Our analysis: because the session reframes scale as a control question and not as a model choice, responsibility shifts towards governance and architecture; therefore the board must put governance on the project budget as production infrastructure, not as an afterthought. Because the academic work names authorisation, provenance and memory as separate domains, this directly affects the operator's liability in the event of errors; therefore the lawyer must now set out in contracts with AI suppliers that decision chains are reconstructable and that the provenance of knowledge remains traceable. Because autonomy grows together with data access and memory, the attack surface increases as soon as an agent is connected to real systems; therefore the CISO must assign an owner and a stop authority per agent before that agent goes live, not afterwards. Because the cited paper links modularisation to clearer fault attribution, a unanimous answer from several models is not proof of independent fact-checking across multiple models; therefore anyone working in a regulated sector must record verification and disagreements as part of the file. What remains unanswered across all sources: how organisations can quantitatively validate the effectiveness of built-in governance. As long as that is missing, restraint with autonomy is, in our assessment, more defensible than speed.

This consequence is not stated in the sources themselves, but follows, according to our analysis, from the design approach: anyone who only adds governance after rollout builds control around a system that is already running. For this reason, it is advisable to include control in the design and operations from the outset. See also our topic hub on AI governance.

What steps does an organisation take before connecting AI agents to real systems?

The UK National Cyber Security Centre provides related guidance on the careful adoption of agentic AI, including concrete operational steps. The common thread is to start small and arrange control before connecting an agent to real data or systems.

  1. Inventory the full AI system, not only the model, but also data, tools, connections and external dependencies.
  2. Start with low-risk pilots before deploying an agent more broadly.
  3. Assign ownership and a stop authority before the agent goes live.
  4. Grant minimal rights (least privilege) and use short-lived, temporary credentials instead of permanent access.
  5. Limit the scope of the agent and manage third-party dependencies.
  6. Monitor both the behaviour of the agent and the connected systems.
  7. Plan the response to incidents, so that intervention is tested when it becomes necessary. The NCSC guidance discusses this preparation; see also our guide on a second response playbook for AI incidents.

Our synthesis is that these steps form a bridge between the session's finding and everyday practice: governance only becomes a foundation once it is built in, tested and governed, not when it exists as a document alongside the system.

Sources and references

  1. The Foundations of Scalable AI - Presented by VanguardMIT Technology Review EmTech Future 2026 · 2026-09-29
  2. AGL-1: The Enterprise AI Governance Layer as a Control Plane for Trusted Enterprise IntelligencearXiv · 2026-07-03
  3. Governance by Design: Architecting Agentic AI for Organizational Learning and Scalable AutonomyarXiv · 2026-04-17
  4. Avoid Overstretching LLMs for every Enterprise TaskarXiv · 2026-06-08
  5. Thinking carefully before adopting agentic AIUK National Cyber Security Centre · 2026-06-01

Sources: The article draws on the Vanguard session at MIT Technology Review EmTech Future 2026, academic work on arXiv and the guidance of the UK National Cyber Security Centre.

← All articles in this topic ← All articles