Every EA vendor claims their AI is revolutionary now. I've tested most of them. The gap between marketing and reality is wider in AI than in any other category I've worked with.

This isn't an anti-AI post. AI is genuinely useful in EA — just not in the ways vendors tend to advertise. Let me walk you through what actually works.

What Doesn't Work: AI That Generates Advice

Several tools now offer "AI-generated recommendations" — asks you questions about your architecture and spits out suggestions. "Your application landscape has redundancy issues." "Consider consolidating these services."

This sounds useful. It isn't, for one simple reason: the AI has no context. It doesn't know your business, your constraints, your regulatory environment, or your roadmap. Its recommendations are based on generic patterns that might apply to some organizations but probably don't apply to yours.

I've seen teams spend months reviewing AI recommendations that turned out to be obvious or irrelevant. The AI generated confidence, not value.

What Works: AI That Reads Your Existing Documents

Here's where AI actually helps in EA: document processing.

Your organization produces a constant stream of documents that describe your architecture. Requirements docs mention applications. Integration specs describe connections. Project charters include system dependencies. Jira tickets track changes.

None of this documentation was created to build an EA repository. But it's all there, and it all contains architecture information. AI that's good at extracting structure from these documents — identifying applications, mapping relationships, classifying elements — that's genuinely useful. Because it's working with information that already exists.

What this looks like in practice:

→

Upload a requirements document. AI extracts application names, descriptions, relationships.

→

Import a Jira export. AI identifies applications, maps to ArchiMate layers.

→

Add an integration spec. AI updates the connection diagram automatically.

The key difference: this AI doesn't try to be smart about architecture. It just extracts what's already documented. The judgment about whether the architecture makes sense stays with the human architects. That's how it should be.

What Doesn't Work: AI Diagrams from Natural Language

Some tools let you type "show me the application landscape for the order-to-cash process" and generate diagrams. This sounds like magic. In practice, it produces generic diagrams that look plausible but don't reflect reality.

The problem is that natural language descriptions miss the nuance that makes your architecture specific. "Order management system" might refer to three different systems depending on who wrote the description. "Connects to" might mean batch file transfer or real-time API. The AI fills in these gaps with assumptions that are usually wrong.

I've seen teams spend weeks refining AI-generated diagrams to match reality — more time than if they'd just built the diagram manually in the first place.

What Works: AI That Reduces Maintenance Burden

The most valuable AI feature I've found in EA tools is the one that receives the least marketing: keeping diagrams current without human effort.

When your AI reads documents and updates diagrams, it does something more important than generating new architecture: it maintains existing architecture. The diagram you built six months ago stays current because new documents trigger updates. You don't have to remember to update it. You don't have to assign someone to maintain it. It just stays accurate.

This is the AI feature that actually changes how teams use EA tools. Because the problem most EA teams face isn't building the initial diagram — it's keeping it current over time. AI that solves the maintenance problem changes the ROI calculation entirely.

How to Evaluate AI Features

When an EA vendor claims AI capabilities, ask these questions:

"Where does the AI get its information?"

If they can't explain exactly what data sources the AI uses, the answer is probably "from generic training data, not your specific context."

"What does the human review process look like?"

If AI outputs don't need human review, be suspicious. If they do need review, understand what that review entails — some AI requires more cleanup than the manual approach would have.

"How does the AI handle ambiguity?"

Real organizations have ambiguous situations. A good AI flags uncertainty instead of guessing. A bad AI fills in gaps with confident wrong answers.

The best AI in EA tools I've used doesn't try to replace architectural judgment. It tries to reduce the manual work that takes up most of an architect's time without requiring judgment. That's the right scope, and it's the difference between AI that's actually useful and AI that's impressive in demos but frustrating in practice.