AI Governance at Scale Is an Architecture Problem
Agencies the size of VA are trying to keep up with a flood of AI use cases by buying better governance tools. Scale is an architecture problem first, and the architecture has to be built in a deliberate order.
Within a large federal agency, the number of AI use cases is growing faster than any central governance office can review them one at a time, and at the scale of an agency like the Department of Veterans Affairs, that pressure is already here. The usual response is to reach for a more capable governance platform, more automation and more dashboards to push the volume through, on the theory that a scaling problem calls for a scaling tool.
The instinct is understandable and mostly wrong, because scale is a governance architecture problem well before it is a tooling problem. A tool laid over an inconsistent governance model does not resolve the inconsistency; it runs it faster and pushes it into more places at once. Buy the platform before the underlying architecture is sound, and what you have really done is automate the mess.
VA is a useful case precisely because it is many organizations at once, several administrations and a wide range of program offices, each running its own systems at its own pace, now moving from a small central AI authority toward governance spread across all of those components. At that scale, what breaks is rarely the absence of tools. It is the same governance question getting answered a dozen different ways across a dozen offices with nothing in place to reconcile them, and that is not something another platform can fix. It is a question of architecture, and three design choices carry most of the weight.
Tier the work by risk, and do it early. Not every AI use case requires the same level of governance intensity, and treating them as if they do is what turns review into a bottleneck. A model that informs a clinical decision and an algorithm that optimizes internal scheduling have no business sitting in the same queue under the same scrutiny. A documented way of sorting them by what is actually at stake- things like rights impact, clinical relevance, data sensitivity, and reversibility- lets an agency spend its real governance effort where the consequences live and move the low-stakes cases through quickly. The catch is that this only works if it exists before the volume arrives. Stand it up early, and it keeps review moving; come to it late, after the backlog is already real, and you are retrofitting under pressure, which rarely goes the way anyone hopes.
Standards before decision rights. Federated governance only works when enterprise standards and escalation paths are finalized and tested before any component office begins governing on its own. Hand a VHA or VBA governance lead real decision authority before the standards meant to bound it exist, and what comes back is a dozen good-faith interpretations that do not reconcile with one another, which is just the original inconsistency problem wearing a different hat. So the transition needs a standards-first phase, where enterprise standards are finalized and piloted with a few representative components before anyone broadens the rollout. That sequencing is the sole safeguard, and it is the same point that determines whether a federated structure can hold itself accountable at all.
A framework that learns as it runs. At enterprise scale, a governance framework that does not improve through its own operation goes stale within a cycle or two because the conditions it was written for keep moving beneath it. The people most likely to notice are the component leads actually doing the work, who hit the edge cases and the framework gaps long before anyone at the center does. An agency the size of VA should give them a real channel to surface what they find, on a set cadence, and route it back into the standard so the framework changes when reality does. That is the difference between governance as a document slowly aging on a shelf and governance as something that runs and corrects itself in the field.
The pull at this scale is always toward the tool, because a platform is something you can buy and point to, while architecture is slow and mostly invisible work. The agencies that end up governing AI well at enterprise scale are the ones that get the order right anyway, with standards and risk tiers in place before anyone holds the authority to act on them and a framework built to learn as it goes. Get that sequence right, and the tools you eventually buy amplify good governance. Get it wrong, and a better platform just helps you make the same inconsistent decisions faster, and at greater volume.
Getting that architecture right and in the right order is the work behind the governance framework I have been building, ERIGO-AI, and the maturity assessment that comes with it. If you are governing AI across a large agency and can feel the volume starting to outrun the structure, I would be glad to compare notes.
Brian Morgan is the founder of SMB Accelerators and has spent more than 25 years in federal health IT across the VA, DoD, and HHS ecosystem.
