The previous article walked through why AI changed what data governance governs, from data itself to the knowledge a system derives from it, retains, and chooses to disclose. That stands on its own. This one starts from its conclusion and asks a narrower, more practical question. If the object being governed now lives inside architecture rather than inside a data asset, where does the actual governing happen.

Not in a policy document. Entitlement, classification, revocation, every concept it walked through, gets decided by how a system is built, whether it fine-tunes or queries live, whether an agent’s output persists into shared memory, months before anyone charged with governance ever reviews the finished thing. Governance decisions are now made in system architecture, whether or not anyone in the room called them that at the time.

Most teams make one design choice without ever labeling it a governance decision, whether an agent’s synthesised findings get written into memory shared across sessions or discarded and rebuilt fresh each time. Persisting it sets a default. One requester’s authorised context can later surface for a different requester who was never entitled to it. Nobody voted on that. An engineer picked the more efficient design, and governance inherited the consequence without ever being asked.

Governance no longer runs primarily through policy documents. It runs through architecture, whether or not the people writing the policy ever find out.

Policy defines intent. Architecture is where that intent actually executes, or quietly fails to. That is also why governance reviews so often feel like they arrive too late to matter. They are reviewing an implementation that already embodied whatever governance decision got made by default, weeks or months earlier.

Two blind spots, not one

That creates a real ownership problem, and the obvious candidates both fail it in different ways.

Neither side can optimise for a constraint it cannot see
Business
Sees the use case, not the architecture
A team asking for faster exposure aggregation knows the use case, not what a given architecture costs in auditability or blast radius, whether the fastest path involves fine-tuning on data that should never have left its original approval boundary, or caching collateral records somewhere nobody is tracking anymore.
Engineering
Sees the spec, not the governance intent
A system gets built against a spec, and if governance requirements are not already written into that spec, the decisions that matter most get made before governance ever sees the result. By the time a finished pipeline reaches a review, its real risk profile was set months earlier.

Neither side fails this by choice. Business cannot see the architectural consequences of what it is asking for. Engineering cannot see the governance intent sitting behind a requirement that arrives as a technical spec. Each optimises for the constraint it can actually see, and the constraint that matters most here is invisible to both of them at the point the decision gets made.

Why the hybrid skillset does not exist yet

The instinct is to look for someone who can hold both halves at once, business judgment and architectural literacy, in a single person with enough standing to insist on the tradeoff at the moment it gets made. That person is rare, and it is worth being honest about why. Before agentic systems, nobody’s job required combining all three. Business wrote requirements. Engineers built fixed logic against those requirements. Governance reviewed the result afterward, on its own schedule, at enough distance that a handoff worked fine. Agentic AI collapses that sequence. Deciding what a system is allowed to retain is now the same decision as deciding what it does, and there is no clean seam left to hand off across.

The decision collapsed. The person does not have to.

Waiting for that combined skillset to show up as a hire is a bet against a clock nobody controls, and systems are already shipping while the wait continues. The fix is smaller than it looks. What closes the gap is a standing point in the design process where business intent, architectural consequence, and governance requirement get weighed together, before the tradeoff calcifies into production, not a title added to an org chart after the fact.

A capability, not a title

This is a claim about what capability now has to sit at that table, not about who gets to sit there. Governance has traditionally been led by data owners, custodians, and security architects, and none of that expertise stops mattering. What has to join it is literacy in how these systems actually reason, retain, and disclose, since that is where the decisions described above are actually being made now. That literacy can come from enterprise architecture, from AI engineering, from security engineering, from wherever an organisation already has it. The title on the door has never been the point. An organisation needs to notice the seat is currently empty, before the next platform decision fills it by default with whoever happened to be standing there.

The governed object changed. Where it gets governed changed with it. Governance that never enters the room where architecture gets decided does not disappear. It just spends its life reviewing yesterday’s decisions.