By David Goff, General Manager UK, PuurData UK Ltd

There was something palpable — and remarkably consistent — across almost every session I attended at DTX London 2026. AI is getting some bad press, but this time from within the industry itself.

Whether it was agents going rogue, questionable accuracy, regulation struggling to keep pace, or developers becoming a little too reliant on their new AI colleagues, the message was clear: the honeymoon period may not be over, but AI has definitely been asked to explain itself. So, after a day listening to some genuinely engaging speakers, here’s my decidedly non-scientific download.

AI assurance is coming. But who’s in charge? Apparently, everybody.

Governments around the world are understandably grappling with how to regulate AI. During the keynote, there was discussion of the UK developing AI assurance standards in collaboration with international partners, including the US, Europe and Singapore.

One point came through strongly: leaving governments and Big Tech alone to write the rulebook isn’t the answer. SMEs, practitioners and the wider technology ecosystem all need a seat at the table.

The birth of the AI assurance practitioner

A job title we’re likely to hear a lot more. But there’s an interesting dilemma. If Big Tech is responsible for much of the AI technology we’re consuming, how comfortable are we with it marking its own homework?

That makes independent assurance increasingly important. What I found particularly interesting was the argument that assurance doesn’t have to slow innovation down. Done properly, it could actually accelerate it. Establish the evidence, controls and guardrails early, and organisations can potentially move through development and into production faster and with greater confidence. So perhaps governance isn’t the handbrake. It’s the seatbelt that lets you drive faster.

Pilot to production: a convincing demo is a starting point

One recurring theme was the distance between an impressive demonstration and a system you would trust with your customers, information or business processes. A prototype shows what could be possible. Moving towards production requires evidence that the application works under the conditions it will encounter.

For an AI search application, for example, producing a plausible answer is only part of the task. Does it retrieve the right information? Is that information current? Can the user check the source? Does the application respect existing access permissions? Those are useful questions to bring into a pilot from the beginning.

Data quality came up repeatedly during the day. It is easy to underestimate how much an application depends on the information available to it. A carefully prepared demonstration dataset can help explain an idea. Testing with representative business data, within agreed security and access controls, helps establish whether that idea will work for the organisation.

Agreeing on what success means

Another theme was the importance of understanding what decision a pilot is meant to support. Which problem are we trying to solve? What evidence would justify further investment? What level of accuracy is acceptable for this use case? Which errors would make deployment unacceptable?

One suggestion was that a pilot should continue until you’ve satisfied around 90–95% of your success criteria. I’m less convinced by a percentage on its own. Surely it depends on which criteria remain unmet. A minor usability issue and a failure to respect access permissions are rather different reasons to hold things up. And I’m not sure perfection has ever survived first contact with a development team.

What makes an AI project successful?

The speakers consistently returned to organisational structure, communication and training. Everyone needs to understand where the organisation is going and, ideally, be walking roughly in the same direction.

But keep an eye out for the rogue engineers already three steps ahead of everybody else. The message wasn’t to stop them. Quite the opposite. They’re often your innovators. Give them room to experiment — just make sure there are some sensible guardrails around the playground.

From vibe coding to value: AI vs the software engineer

This discussion became particularly interesting and raised a difficult question: could junior software engineers be among those most exposed to AI-driven disruption? There’s a twist, though. AI dependency itself may contribute to the problem.

The panel discussed the “illusion of learning” — where AI dramatically increases someone’s output while potentially reducing how much of the underlying subject they actually understand. The code works. The output looks impressive. But do you actually know why?

One argument was that experienced engineers retain a significant advantage: they understand the business context. AI can generate code, but understanding why an organisation works the way it does, what customers actually need and which compromises matter remains a very human advantage. For now. We’re probably only a few miles into the marathon of AI maturity, so how long that advantage lasts is anybody’s guess.

When agents go rogue

Perhaps the clearest message of the day concerned accountability: organisations cannot simply point to their AI system when something goes wrong.

Examples discussed ranged from chatbots apparently losing patience and swearing at customers — which I’d quite like to test — to agents offering unauthorised discounts on products and services. I’d also like to test that one. Behind the anecdotes was a serious question: what happens when an AI system makes a promise or takes an action the organisation never intended?

As AI moves from answering questions to taking actions, the need for clear boundaries, governance and accountability becomes considerably more important.

And finally…

One speaker’s comment that I couldn’t resist sharing — my cheesy quote of the day: “Silos in the enterprise don’t exist, only misaligned incentives.” If only it were that simple.

My main takeaway from DTX?

AI isn’t really on the naughty step because it’s failing. It’s there because it’s becoming embedded in everyday life, and we’re starting to take the consequences much more seriously. The conversation is moving beyond “look what AI can do” towards the much harder questions: should it do it? Can we trust it? Who is accountable? And, most importantly, does it actually create value?

That feels like progress.

At PuurData UK, we’re helping organisations explore some of those questions practically — particularly where AI, search and enterprise data come together.

About the author

David Goff is General Manager UK at PuurData UK Ltd. He works with organisations and Elastic teams to identify where PuurData’s expertise in Search & AI, Observability and Security can help – from proving a use case to improving an existing Elastic environment.

Get in touch: dgoff@puurdata.com | +44 7764 926512