Building a governance framework for AI-generated EA content

Generating model elements from a design document is the easy part. The work that remains is sorting out which elements are usable as they are, which need context added and which are quietly wrong. That review decides whether the generation saved any time, and it needs a governance framework to do it consistently.

The framework below does not depend on which AI wrote the content. Kernaro Assist inside EA, and Claude or GitHub Copilot working on the repository through AI Power Tools, put the same kinds of content into the same model and carry the same risks.

AI-generated EA content is not uniformly reliable, so do not govern it uniformly. Descriptions are usually safe to accept with a glance, relationships always need an architect, and naming can be automated against your MDG Technology. Stage every generation, run automated checks against your governance rules before a human looks, and route what is left by element type. Governance is what makes AI safe to use at scale, and it works best when it is built in from the first generation.

When an AI starts writing into an EA practice, you gain a new content source with a different reliability profile for every kind of thing it produces. Descriptions are usually solid. Relationship logic needs an architect before anyone trusts it. Naming can be delegated almost entirely. If you cannot tell those apart up front, you inherit a backlog of one-off decisions instead of a workflow.

What you can trust, and what you can’t

Begin by being precise about risk. Not every piece of generated content carries the same weight, and treating it as if it does is how teams lose the time the AI was supposed to give back.

Descriptions and documentation are the safe zone. Ask an AI to describe a “transaction processing API” and you start from something usable: it draws on the language in your existing documentation and the domain knowledge encoded in your MDG, then writes readable prose. It will not be perfect every time, but it is rarely wrong enough to create architecture risk. One question, does this match what we already know about this component?, and you are done. This is where AI returns real hours.

Relationships and dependencies are where you stop and look. A suggestion that Service A calls Service B is not something you confirm at a glance. Relationship logic carries assumptions about data flow, coupling and runtime behavior. An AI that sees “A” and “B” in the same sentence cannot tell whether A depends on B or whether the two are simply listed as alternatives. Verifying these needs an architect who knows the domain. That is human judgment used exactly where it belongs.

Element names and classifications can be delegated further than you might expect. Once you have formalized your naming conventions in your Sparx EA MDG, and you should, the AI can work to them. A rule like “APIs ending in ‘Service’ are integration points” or “databases named ‘DW_*’ are data-warehouse tables” can be encoded once. You do not review every name. You review the pattern.

The governed pipeline, in four steps

A common mistake is treating AI output as a separate stream: generate the artifacts, then hand-fold them into the model later. That is double work. Make generation a stage inside your standard workflow, with a governed path from raw output to trusted model content.

None of this adds governance overhead. It uses your governance rules, the same ones that already constrain human-authored content, to make review faster and the model cleaner.

What a gate looks like

The automated step is where tool and architect divide the work. 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, so none would have appeared in a report built from stereotyped elements, although somebody had classified them deliberately.

The check did its part: it found them and counted them. It could not decide what an unstereotyped Business-Critical system should be, whether the missing stereotype was an accident or an intended exclusion, or whether the modeling language needs a stereotype it does not have. Those calls are the architect's. Automation checks completeness, and people own correctness. The full example is in AI skills and human skills.

Extend your MDG to cover the AI

The MDG, the metamodel definition system that governs element types, relationships and attributes in Sparx EA, is usually written with human-created content in mind. When you add generation, extend the same MDG to govern the AI.

Formalize what the AI is expected to produce

If you want AI to create API elements, say so precisely: an API element has a name, a description, a version, a responsible team and a list of exposed endpoints, and the last three are non-negotiable. The AI can be told to produce them, and your governance checks that they are present. Writing that definition is a skill. The architect who states it well gets usable output, and the architect who leaves it open gets plausible filler.

Define the review path per element type

Descriptions to a junior architect for a quick pass. Relationships to a senior architect who knows the domain. Naming validated against the MDG. You are matching review to risk instead of treating every output identically.

Make the MDG the source of truth for the AI

An AI working in Enterprise Architect works with the structures and MDGs in your repository, so your metamodel, naming conventions and attribute requirements shape what it produces. The better your MDG, the better the AI performs. In most software, discipline and tool quality pull against each other. Here your governance directly raises the quality of what the AI returns.

Making it stick

Two patterns help.

The first is a role-based review cycle. Name one architect the “AI content shepherd” for a fixed stretch, a two-week sprint, say. They review staged content, watch for patterns in what needs fixing and feed those patterns back to the governance team. If the AI keeps misreading relationships in one domain, that is a signal to give it better examples or tighten the MDG in that area. The shepherd becomes the clearing house for improvement.

The second is measuring what you accept. Track what passes review unmodified and what does not. If most generated descriptions sail through, descriptions are a low-effort win. If only a minority of generated relationships survive review, relationships need human-first capture, with the AI assisting on validation instead of generation. The loop tightens your governance on its own.

The mature state

A mature practice uses AI to free judgment, not replace it. Junior architects spend less time transcribing design documents into the model and more time asking whether those designs are sound. Senior architects spend less time ticking governance boxes and more time on the exceptions, the anomalies the AI could not resolve. The model stays cleaner because nothing generated sits in it unvetted.

Governance usually reads as friction. For AI-generated content it is the mechanism that makes the AI safe to use at scale. The useful question shifts from “Can we trust the AI?” to “What level of review makes each kind of content trustworthy?” That change, from binary skepticism to calibrated confidence, is where governance turns practical. Your AI-Augmented Architecture will only ever be as good as your ability to govern it, and AI is only as good as the person prompting it. Start with both.

If you want the wider picture of how review, accountability and oversight reshape an AI-augmented practice, read what good EA governance looks like in an AI-augmented practice. Because the rules above run on your repository, its quality sets your ceiling. See AI tools for Sparx EA for the options, the free AI Power Tools for Sparx EA, and AI-Augmented Architecture for how the pieces fit together.

We can teach your architects to stage, validate and review AI-generated content on your own repository, or build and update the model for you with that governance built in.