Building a governance framework for AI-generated EA content

In one of the first teams to put Kernaro Assist to work, an architect pointed it at a design document and watched it generate forty-three model elements in an afternoon. The elements were the easy part. Sorting out which were usable as-is, which needed context added, and which were quietly wrong took far longer than the generation ever saved.

That gap is not a failure of the AI. It is a failure of governance.

The short version: 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 — not the friction that slows it down.

When you bring Kernaro Assist into an EA practice, you are not just adding a tool. You are adding a new content source with a different reliability profile for every kind of thing it produces. Descriptions might be ninety percent 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 Kernaro Assist to describe a “transaction processing API” and you start from something usable: it draws on language patterns in your existing documentation and the domain knowledge encoded in your MDG, then writes readable prose. Perfect every time? No. But 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 not a governance failure — it is human judgment used exactly where it belongs.

Element names and classifications can be delegated further than most teams expect. It sounds backwards, but once you have formalized your naming conventions in your Sparx EA MDG (and you should), Kernaro Assist can learn 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

The mistake most teams make is treating AI output as a separate stream — generate the artifacts, then hand-fold them into the model later. That is double work. Instead, 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.

Extend your MDG to cover the AI

Here is where most teams haven’t caught up. The MDG — the metamodel definition system that governs element types, relationships, and attributes in Sparx EA — is still aimed only at human-created content. When you add generation, extend the same MDG to govern the AI.

Formalize what the AI is expected to produce

If you want Kernaro Assist 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. The last three are non-negotiable. The AI learns to produce them; your governance checks that they are present.

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 auto-validated against the MDG. You are matching review to risk rather than treating every output identically.

Make the MDG the source of truth for the AI

When you onboard Kernaro Assist, you feed it your MDG. It learns your metamodel, your naming conventions, your attribute requirements. The better your MDG, the better the AI performs — the inverse of most software, where governance 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 hold up in practice.

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: either 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 doesn’t. If eighty-five percent of generated descriptions sail through, descriptions are a low-effort win. If only thirty percent of generated relationships survive review, relationships need human-first capture, with the AI assisting on validation rather than generation. The loop tightens your governance on its own.

The mature state

Mature teams use Kernaro Assist 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 couldn’t resolve. The model stays cleaner because nothing generated sits in it unvetted; it is reviewed and validated before it is trusted.

Governance usually reads as friction. With AI-generated content it is the opposite: it is the mechanism that makes the AI safe to use at scale. The teams doing this well have stopped asking “Can we trust the AI?” and started asking “What level of review makes each kind of content trustworthy?” That shift — 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. Start there.

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. And because the rules above run on your repository, the quality of that repository sets your ceiling — see AI Power Tools for EA and the broader AI Augmented Architecture approach for how the pieces fit together.