Insight · Architecture Governance

What good EA governance looks like in an AI-augmented practice

By Sparx Services · May 17, 2026 · 7 min read

Traditional architecture governance was built for a world where architects authored every element, every relationship and every description in the repository. The reviews, completeness checks and metadata validation all assumed a human author and a human reviewer catching errors as they happened.

That assumption breaks once an AI starts writing into the model. It does not matter which one: Kernaro Assist inside EA, or Claude or GitHub Copilot working on the repository through AI Power Tools, create the same governance problem. Content arrives faster than people can author it, and stakeholders can ask for architecture data directly instead of emailing an architect. The governance logic in this piece applies to any AI that writes into the model, so it does not depend on the tool you chose.

We expect teams to hit one of two failures if they apply traditional governance to an AI-augmented practice. The old review cycles become bottlenecks that cancel the productivity gain, or governance gets skipped and data quality degrades without anyone noticing. The way through is to redesign governance around three shifts.

Shift one: when AI writes the model content

The first shift is authoring accountability. In traditional practice, an architect authors a description and it goes to review. In an AI-augmented practice, the AI proposes a description and an architect approves it. This is a bigger change than it sounds.

Approval is a different task from authorship. When you author, you own the thinking. When you approve, you verify correctness without having done the original thinking, and that takes discipline, because approving AI-generated descriptions quickly and without review is both tempting and corrosive.

Approval is a different task from authorship. Treat AI-generated content as a draft to be verified.

What works is treating generated content as a draft with explicit approval criteria. Does this description reflect the system's purpose? Does it capture the constraints we care about? Does it follow our naming conventions? Does it reference dependencies correctly? These become active checklist items instead of passive scanning.

Validate structure as well as prose

The second part of this shift is relationship validation. Traditional review catches misnamed relationships, missing cardinality and incorrect stereotype assignment. An AI can generate these errors at volume, so review has to move from "is the description correct?" to "are the relationships structurally sound?" Your review process becomes more technical and less editorial.

This is where MDG Technology becomes a governance tool as well as a metadata specification. If your MDG profiles define strict cardinality rules, stereotype requirements and composition constraints, those rules can be checked as content is generated, which puts governance nearer the point of entry than a downstream review step. How far a given tool enforces a given rule varies, so test it on your own configuration. For the deeper version of this argument, see MDG Technology as your AI quality gate.

Version discipline at AI volume

The third part is version discipline. When humans author slowly, version proliferation is not a practical problem. When an AI generates content at far greater volume, it becomes one. You need explicit decisions about which versions of elements and relationships stay in the active model, which move to historical, when snapshots are taken, and how long draft content can sit in review before it is committed or rejected.

Teams that skip this end up with repositories that look clean at first glance but hide dozens of draft versions of a critical application and no clear record of why some were rejected. Effective governance says: "Draft content expires in two weeks. Either it is approved and committed, or it is rejected and archived." That gives you velocity without chaos.

Shift two: when stakeholders can self-serve architecture data

The second shift happens when stakeholders move from "I'll email the architect" to asking the model directly, whether through Kernaro AI Hub, Prolaborate 6 with AI or Microsoft 365 Copilot reading a published model. The architecture data is now a product that non-architects can query.

This changes what you govern. You are no longer mainly governing model authoring. You are governing access, accuracy and timeliness.

Questions are governance data

If your tool records what stakeholders ask, that is valuable governance information. A pile of questions about which systems support customer onboarding tells you the question matters and that the model may not represent it clearly. Some teams use question patterns to trigger completeness reviews: if a question is asked often and answered inconsistently, the model needs attention. Confirm with your vendor what is kept before you plan around it.

Granular access and accuracy

Access control becomes more granular. Finance stakeholders can see financial systems and data flows without seeing security architecture details, and product managers can see application capabilities without the underlying technical decisions. Where your tool supports role-based restrictions, this means thinking through data sensitivity in ways traditional EA did not, and it is worth doing.

Accuracy monitoring becomes a governance responsibility. An AI can return answers grounded in your live model, yet the large language model layer can still produce an answer that is technically true and meaningfully wrong. A human architect needs to spot-check periodically: is the AI representing our architecture accurately? When you find an inaccuracy, is it a model problem or a reasoning problem? That is different work from traditional governance, and it is essential.

Freshness tied to decisions, not the calendar

Data-freshness governance means making sure the model is updated before major decisions are made against it. That is harder to enforce when stakeholders can query at any moment. A simple rule helps: model reviews are tied to decision gates, not calendar cycles. Before a major investment decision, before budget cycles and before project charters are approved, the model is reviewed for completeness and accuracy. The governance rhythm follows the business rhythm.

Shift three: what a governance team can now get done

An AI-augmented practice makes governance work possible that traditional governance could not afford. Each of these four changes who does what.

Task 01

Check completeness continuously

Today, completeness is an annual audit that someone dreads. AI-augmented, you state the rule, for example "every application must have an owner, a business process that uses it and documented technology standards", and an automated check flags exceptions as the model changes. Senior architects review the exceptions, not the whole repository. The skill is writing the rule so a tool can apply it.

Task 02

Enforce standards at the point of entry

Today, a reviewer catches non-conformance days after it was entered, if at all. AI-augmented, validation against your MDG and standards catches it while content is created. If your MDG says every business service has an SLA artifact attached, the check looks for it. The skill is deciding which rules are worth enforcing and which have exceptions.

Task 03

Screen content before a person sees it

Simple checks run first: are descriptions above a minimum length, required fields populated, proposed relationships valid on both ends, naming conventions followed? Reviewers see only content that passes. The skill is setting the screen so it removes noise without hiding real problems.

Task 04

Spend senior time on judgment

With rote checking automated, senior architects concentrate on the hard questions. Does this decision align with strategy? Does this pattern match our standards? Is this system truly business-critical? The skill is knowing the estate well enough to answer.

A gate in practice

A governance gate shows the line between what the tool does and what the architect decides. On the Westbrook Bank reference model, a completeness check run before building a reporting database surfaced three application components. Each was classified Business-Critical and scoped to a financial-privacy regulation, with a business owner and a technical owner named. None had a stereotype. Because the reporting database is built from stereotyped elements, these three would never have appeared in any report, even though somebody classified them deliberately.

The check counted and reconciled. It could not decide what an unstereotyped Business-Critical system should be, whether the omission was an accident or a deliberate exclusion, or whether the modeling language needs a new stereotype. Those decisions belong to an architect who knows the estate. Automation checks completeness, and people own correctness. We walk through the full example in AI skills and human skills.

Putting it into practice

Redesigning governance for AI augmentation is a short sequence of moves you can run in order.

Map the governance you already run

Write down what you review today: what gets checked, when, by whom and how long each step takes. You cannot redesign a process you have not made visible, and the map is also your baseline for measuring the gain.

Separate rote checking from judgment

For each step, decide which part is rote checking that a rule could do and which part needs an architect's judgment. Expect a large share of traditional governance to be rote work. That is where accuracy slips, because tired reviewers skim the boring checks and miss the consequential ones.

Write your rules explicitly enough to automate

"Architectures should be good" cannot be measured. "Applications in the core category must have a documented disaster-recovery plan, a named owning architect and at least a quarterly review" is a rule a tool can enforce. Encode these in your MDG Technology so they hold at the point of entry.

Run a quarterly review of what changed

Do not re-review the whole repository. Review what changed, which questions stakeholders are asking and which exceptions the automated checks raised. That tells you whether the governance is working or needs adjusting.

If you are standing up these checks for the first time, our Configure the Solution stage builds the validation rules into your repository, and Paralysis to a Plan scores where your repository and MDG consistency stand before you start.

The teams best placed to succeed in AI-augmented EA are the ones willing to rethink governance and to treat its improvement as a main benefit, not a necessary cost. Done well, it delivers better data quality, faster decisions and clearer accountability. We can teach your architects to govern an AI-augmented model on your own repository, or build and update the model for you with that governance built in. The wider approach is described in AI-Augmented Architecture.

Ready to rethink governance for AI augmentation?

We can teach your architects to run this on your own repository, or build the model for you with the governance built in. Most teams want some of both.

Book a call

Keep reading