Put four enterprise architects in a room and ask them how AI should fit into architecture practice, and you will not get a single answer. However, it will spur a deeply insightful conversation about the very real struggles organizations today are facing in approaching AI adoption and enablement.
That is what happened on Ardoq's most recent Jumpstart webinar. Andy Neill (Info-Tech Research Group), Ben Clinch (former EA lead at BT and HSBC), Kevin Donovan (independent global EA consultant), and Ardoq's own Principal Enterprise Architecture Researcher James Tomkins spent 45 minutes disagreeing productively about AI-first architecture, data readiness, and governance. Here is what came out of it, and what it means if you are the one accountable for getting this right.
Watch the full webinar, or scroll on for highlights from the discussion.
The panel opened with a live poll: is your organization AI-first, rebuilding workflows around AI by default, or AI-enabled, adding AI only where it clearly earns its place?
The room split close to even, and so did the panel. Andy argued that his most advanced clients treat AI-first as the only way to build the organizational muscle memory that keeps them ahead. It gives people room to build with agents and MCP servers, then scale what actually gets used. James made the case that an AI-first mindset forces a discipline EAs have wanted for years anyway: to describe things properly, make data inference-ready, and stop treating diagram legends as optional.
Ben pushed back with the line of the session: business first, AI as the means, not the goal. His example was Klarna, which used AI to close customer service tickets faster and cheaper, cut roughly 700 staff, and then had to rehire a chunk of them once it became clear that ticket speed was not the right metric. Customer satisfaction was.
The takeaway for architecture leaders is not to pick a side. It is to be honest about which one your organization is actually doing, and whether the business case came before or after the AI decision.
One thing everyone on the panel did agree on was that nobody was going to get a six-month runway to fix the data before the business wants AI live. The question asked is not "is our data ready," but "what is the cost if it is wrong for this specific use case." Drafting an email with messy data is low stakes. Making an investment or resourcing decision on it is not, and the panel pointed to real-world facial recognition cases where uneven training data produced unreliable and harmful outcomes across demographic groups.
Kevin's practical advice is to tackle it one decision at a time, week on week. Pick one corner of the data estate to improve and evolve from there, providing a plan teams can act on and progress instead of a mammoth mandate that feels unachievable.
Kevin named the three words no Enterprise Architect says outside a room full of peers: semantics, ontology, and taxonomy. Say any of them in a business meeting, and the room checks out.
That's unfortunate, because all three describe the same unglamorous work that determines whether AI turns out to be useful or just expensive. Strip out the vocabulary and what's left is simple: they all tell a machine what your data means and how one thing relates to another. A relational database can confirm that a record in one table shares an ID with a record in another. It can't explain that "customer" in the CRM and "account" in the billing system are the same person. People fill that gap from experience, but agents will fill it with a guess.
Andy Neill has a story about what guessing costs. Years ago at the UK House of Commons, he classified content using an off-the-shelf taxonomy of world cities and towns. Every document mentioning the then-U.S. president started quietly routing to Japan because Obama is also a place name in Japan, and the business spent a while wondering why. It's funny in hindsight, but it's the same failure sitting inside a lot of AI pilots right now. The model does exactly what the classification tells it to do, and nobody notices until the output looks strange.
The upside of doing the work has been measured. Ben Clinch pointed to research from Juan Sequeda, Dean Allemang, and Bryon Jacob, published on arXiv, that quantified what a semantic layer is worth against a plain relational database.
"Even a small amount of semantic modeling, maybe about ten minutes' worth, improved the accuracy of an LLM's one-shot query over a SQL database by 400%."
Ben Clinch, former EA lead at BT and HSBC
Andy's point was that this argument is finally landing because it shows up on the invoice. Without context, people rerun the same prompt five times before the model understands the question. With it, the answer arrives correctly the first time, reducing overall token spend.
Ben would push it further. Context isn't only about data structure. It should carry business capabilities and intended outcomes too, so agents act on what the organization is actually trying to achieve rather than inferring it from whatever the database happens to contain.
Andy raised a question more architecture leaders should be putting to their vendors directly.
"When a platform routes your query to whichever model it picks, and some of those models are the vendor's own, how would you know if more of your traffic is quietly going to the house models to capture more of your spend?"
Info-Tech compared token usage across models on similar prompts and found the numbers don't reconcile. Andy described it as close to a black box.
Ben expanded the discussion to the issue of insight lock-in, which is whether you own the insights generated from your own data, or whether a vendor is learning how your business works and selling a homogenized version of it to your competitors.
Inside the organization, the problem inverts. Kevin's read is that AI didn't create a new governance problem so much as remove the slack that let sloppy practice survive, because an agent produces recommendations at speed and doesn't absorb the consequences of getting them wrong. His conclusion:
If governance isn't built into the golden path, the route of least resistance for the people actually building things, it doesn't exist.
Andy's proposal is to embed the rules into AI gateways and orchestration layers so compliance doesn't depend on anyone reading a policy document. Kevin's own starting point is finding something small enough to begin with fairly quickly, such as a one-page agent register listing every agent, a named owner, its read and write scope, and what breaks if it goes wrong. That exercise alone can reveal how many agents exist and how few people will put their name against one.
James adds time pressure to the picture. Most organizations are optimizing for speed, but token economics are shifting, and the EU AI Act is still being refined as it goes. Whatever is driving AI decisions today won't be what's driving them in a year.
The discipline isn't new. Visibility, ownership, context, and clear accountability for risk are what Enterprise Architecture has always done. What's new is the adoption pattern, because this is the first technology most EA teams have been asked to govern that the organization started using without waiting for permission. The work isn't inventing a new practice, but instead applying an existing one faster than the business is moving. AI is almost certainly on your board's agenda this year, and your architecture is either what makes that possible or what holds it up.
If you want a head start on understanding where your organization currently stands, Ardoq's free AI readiness assessment takes just 10 minutes and gives a straight read on how ready your architecture is for what the business is already doing with AI.