Webinar | Why Enterprise AI Fails – The Data Problems Nobody Fixed

Opening and Housekeeping (00:07–03:31)

Pete Youngs (00:07):
Hello everyone. Thank you for joining. It's 1 minute past so we'll just wait a little bit longer because I can see the attendee numbers going up. So we'll just let a couple more people join and then we'll get started. Right, it's going up fast. I think we'll get going. So, welcome everyone. Thank you for joining. Welcome to this Ortecha webinar on why enterprise AI fails, the data problems nobody fixed first.

In some ways I feel quite relieved that we're discussing this as I've been banging on about this for about the last 15 years and now I think it's getting the attention it deserves. So, Thank you, OpenAI, for launching ChatGPT in 2022 because I think that's triggered what we're seeing today. In case you don't know, Ortecha is the human-first data and technology consulting firm that helps organisations operate more effectively and use AI successfully. We focus on three foundations around trusted data. We're really going to touch on that today. Effective governance and connected enterprise knowledge.

Those should mean better operations, more reliable analytics, safer automation and AI of course and AI that understands the business context in which it is working. So today we're going to discuss why enterprise AI initiatives often struggle to deliver reliable value at scale. I think we're probably all seeing this with some of the hype around pilots. No, it's not all bad, of course. And we'll talk about that quite a bit today. Why the issue is not usually the AI model. They're really clever, but the enterprise foundations underneath it.

We recently published an article on this and we're going to drop the links to that in the chat. We've got a hub page on the website around operationalisation of AI. There are three articles we've published on there recently and this is the first in a series of three webinars. And just to say, I think this is the highest number of registrations we've had for a webinar so clearly the topic is resonating with people so I hope we get lots of questions from you as we go through today.

Speaker Introductions (03:31–05:53)

Pete Youngs (03:31):
So let's dive into the discussions and before we do that, we'll do intros. So just a brief one from me first. I'm Pete Youngs, Founding Partner at Ortecha. I'm actually a data architect by trade. And now I help organisations embed what I hope is excellent data management practices so that they can be successful with AI, but before the AI hype cycle, frankly, be successful in their business through great use of data. And I've got three fantastic guests with me today. So I'll let them introduce themselves and I'll hand over to you first, please, Lisa.

Lisa Lewis (04:02):
Great. Thanks, Pete. And thank you for having me. I'm very excited about the discussion today. Hi everyone. I'm Lisa Lewis, head of data governance, privacy, and compliance for the Enterprise Data Organization at S&P Global. I've held several roles with the company over 27 years across data and technology, operations, project, and product management, and landed most recently in data governance as the voice from all those roles that needed the data governance in order for any of my projects to be successful.

Pete Youngs (04:32):
Thanks, Lisa. Over to you, please, Barry.

Barry Panayi (04:35):
Hi everyone. Thanks for having me, Pete. I'm Barry. I'm currently the chief data officer for Howden Group, which is in insurance. Before that I was the chief data analytics officer at John Lewis Partnership and I've also been the group CDAO at Lloyds Banking Group, the UK's largest retail bank. So I'm a data person by trade so I think it should be obvious why I'm here and why I'm interested in this.

Pete Youngs (05:02):
Yeah. Thanks, Barry, and over to you, please, Mark.

Mark McQueen (05:05):
Thanks, Pete. I'm Mark McQueen, the Managing Partner for Ortecha in North America. We have Canadian and US operations. I reside in Nashville, Tennessee. I have a 22-year background at a very large global bank. Lisa puts me to shame at 27. It makes me feel like a short-timer at 22. But during that time I actually came from a business process design background that led me to a data project that two years later I discovered I was now a data guy rather than a process design guy. I've been consulting now for 10 years and joined Ortecha about seven years ago.

Why AI Does Not Know Your Workarounds (05:53–11:37)

Pete Youngs (05:53):
Great. Thank you, Mark, and thank you so much for joining us today, Mark, Lisa and Barry. So this is centered around the article today that we've mentioned and Louise will have dropped the link into the chat. So starting with you, Mark. The article opens with a simple but powerful point that AI doesn't know our workarounds.

So for years, and this is why I'm quite relieved that we're talking about this, organisations have managed to live with data problems because people knew which report to trust, which definition applied, who to ask when two systems disagreed, and where the unofficial source of truth could be found. AI doesn't really know this. It doesn't have that experience or informal business context. So why does this matter so much as we embrace, adopt, and experiment with AI? And really as we look at pilots and pilots move beyond controlled pilots into real business processes and decisions.

Mark McQueen (06:52):
I think this is the biggest mindset shift and as you pointed out, Pete, it's being driven by AI that has a different set of requirements and a different set of expectations for data. For years people have quietly made the enterprise work despite messy data. Again as you said they knew which report to trust. They knew what definition applied to the data, who to call when systems disagreed with each other and where the real business context resided and brought that context to the forefront through a manual approach. AI doesn't have that institutional memory. It doesn't know those workarounds.

And unless that's documented, we're leaving AI just to use statistical analysis to produce answers for us and not really understanding our business. AI just works with what it's given. When those informal workarounds move into operational AI, they become risk. The question is not just whether AI can produce an answer. We know that it can, but it's whether the enterprise has made enough context, meaning and accountability available for that answer to be trusted.

Pete Youngs (08:21):
Yeah. Okay. Thank you. And coming to you, Barry, a CDO at Howden now and in other organisations before. So what's your perspective on this? Because it seems in most organisations we're constantly adding that human context and it's not written down anywhere. Yes. Yes. There's cataloguing and metadata, but I think we've perhaps not done such a good job as we could have done now that there's this scale issue with AI. So do you see organisations relying on that tacit or human knowledge and what happens when AI starts using the data without automatically understanding that human knowledge?

Barry Panayi (08:57):
What I would say is: first, it shouldn't do it in a productionised way, right? If you're testing the model out, then of course it's actually quite useful for the AI to expose where it doesn't know that tacit knowledge. So during development, I can see it being quite useful because it could highlight where the risks are. If you've pressed go on this thing, I think your best case scenario is that you've just added loads of cost because the manual checking and processes will come in through the back door again.

So you've paid for the AI, you've paid for the original process, and now you're paying for some sort of new verification process. That's the best case because that means some human is checking it. In the worst case, of course, everyone understands how quickly errors can compound in a literally exponential way with AI, the loss of trust and so on and so on. So for me, I'd use that as part of the development process. And if you think that's not important, you're kidding yourself because you're just layering more cost and more cost.

Yeah, you'll be painting yourself as this productivity champion, but all you've done is create brand new manual processes and layering them on top. So, we absolutely cannot think that AI has all the context it needs for, I think, the vast majority of use cases because of that tacit knowledge especially in the mid- to back-office productivity arena. In the kind of insight-giving, information-guiding work, perhaps it is less risky.

But when you're going agentic, say, which is typically in the mid- to back-office then I don't think you can work around that you have to crack it and either document it or have the AI observe the human processes and then codify it for you to check that it's done it correctly.

Pete Youngs (10:53):
Face into it, really. By all means run your pilot experiment and every organisation should be. But really think about where you're prioritising that effort where you have because there will be a variation in foundations, of course, so I guess pick the ones that are going to potentially work rather than expose weak foundations but if they are going to expose foundation issues, do it quickly.

Barry Panayi (11:15):
At the risk of sounding like Eeyore, the grumpy donkey from Winnie-the-Pooh, which is my usual mode: if it looks too good to be true, it usually is. So unless you've done immaculately documented processes and incredible discipline from every single contractor, consultant, and employee you've ever had, then you've got this to some degree.

From Successful Pilot to Production Frustration (11:37–18:52)

Pete Youngs (11:37):
Yeah. Which surely leads to frustration. So, I think where you've said there like we take a pilot, we experiment and we put it into production and then we get frustrations when it's not working and it's not necessarily the AI's fault. So, Lisa, people are talking about pilots and Copilot at one end of the spectrum RAG experiments and, obviously, the implementation of generative AI the early results can look very impressive but the article argues that the difficult questions tend to emerge when organisations try to move from what we've discussed as a controlled demonstration or pilot into real, everyday business use.

Questions emerge about privacy, appropriate data use, accountability and assurance, whether the AI outputs can be genuinely trusted and I guess can the data inputs be trusted as well. Are you seeing organisations move from that initial excitement into that real frustration?

Lisa Lewis (12:30):
Absolutely. We're definitely seeing both still the continued excitement and innovation. We are a data company so we do have lots of data that is AI-ready, governed, well documented and proceduralised and the AI is working really well and we're able to get those processes out into production Then there are others where that isn't the case. So you start operationalising on data that is not so AI-ready, not so governed and not so well documented and you very quickly find that gap. The data isn't so clearly described. We're missing metadata. We're unsure of ownership.

All of those things roll up into the teams having real frustration, real issues getting their innovations over the line, real issues with deployments, and generally being blocked by questions that we maybe can't answer. We don't know who to ask. We don't know whether we can trust the outputs. We don't know what the data was intended for or who the owner is. Sometimes our biggest blocker is that sign-off to actually move this thing to production. Whose name goes on the line, right? The one person. Who's accountable? This can be really challenging.

Pete Youngs (13:45):
Okay. Yeah, it definitely resonates. So, yeah, Mark, coming to you when organisations reach that point of frustration the pilot has worked technology looks promising but it's still not becoming part of trusted everyday operations maybe even just because of that final sign-off or product-owner approval point, people then naturally ask why it is not scaling. So in your experience, what are the common root causes? Is it the AI, the foundations or the definitions? I feel like I'm a bit biased because I'm that sort of data management guy. But yeah, what are you seeing? What are your thoughts?

Mark McQueen (14:23):
So, you know, from an advisory and consulting perspective, you know, one thing we hear repeatedly is our pilot worked brilliantly. You know, why isn't the business adopting it? And to answer your question, usually it's not because the AI itself has failed. It's because the pilot was protected by SMEs, by humans who understood the data, the caveats, the definitions, you know, so they made sure that worked in the pilot. You move into operations and you don't have that protection or human layer because you're trying to move at AI speed; that is why you created it.

Without that protection, you know, the ownership gaps, the controls that need to be applied aren't understood unless the SME is involved. That is also how many organisations have made data management work historically. You know, even very successful data management programmes today largely have been built on the backs of manual labour. You know, it's a very labour-intensive activity of doing data management. So, what do I mean by brute force manual labour? I'm going to try to make you squirm in your seat a little bit.

I'm going to read a long list of these nightmare examples of manual labour, and ask you to mentally count how many of these you've personally lived through. So, here we go. Reconciled fragmented data across systems. Check. Mapped data elements by hand. Interpreted inconsistent business definitions. Maintained spreadsheets of glossaries and ownership. Called or chased data stewards for approvals. Investigated data quality breaks with a 24-hour SLA. Reconciled trades, customers, products or accounts between platforms, documented lineage after the fact, checked reports manually before they went to executives, assembled control evidence for audit - I'm almost done.

Applied policy rules in review meetings, and translated business meaning into something others could trust. So, I don't know about you, but I squirm when I see that list because I've lived that nightmare over and over. So, now ask yourself, how many of those nightmares still exist in your organisation today? And that's what you're trying to solve for if AI is to be effective in the organisation. In so many AI pilots, that same manual labour still is what makes the pilot work, but that human scaffolding does not scale.

Once the pilot moves into real operations, these manual workarounds become adoption barriers, and that's why it's not being used consistently. The technology may look really impressive, but the enterprise foundations aren't yet mature enough for the AI to really rely on at scale.

Pete Youngs (17:46):
Yeah. And surely what we're touching on in most of those is accountability and ownership, dare I say. So not data quality or technology problems, accountability problems.

So when an AI-supported decision is made, organisations need to be clear about who owns the data I think we take that as a given - that it relied on, who owns a definition and business rules behind it, who's responsible for the controls around the model and of course what feeds into it, and ultimately who's accountable for the outcome of the AI If those responsibilities are only implied and I think we touched on this quite a lot in the article rather than explicit, AI can expose and amplify the gaps, weaknesses and risks quickly..

Mark McQueen (18:36):
Well, I was just going to say that accountability attached to that AI process, all the way up to the C-suite and the board, is ultimately what creates confidence in what the AI is generating.

Ownership and Accountability for AI Readiness (18:52–25:06)

Pete Youngs (18:52):
Yeah. And touches on broader operating model for sure. So yeah, Barry, that leads to the obvious question of ownership and geez, we've been talking about data ownership for far too long, haven't we? And we're in a place where perhaps it is more relevant than ever. But in terms of AI readiness in an enterprise, who would you say owns it? Is it someone like yourself as a CDO because it depends so much on trusted data? Is it a chief tech officer? Is it everyone? I don't quite know how that works. So what's your view on ownership of AI and AI readiness?

And obviously again I lean towards the data underneath, but what are your thoughts?

Barry Panayi (19:31):
I don't think it's the CDO.

Pete Youngs (19:34):
Okay.

Barry Panayi (19:35):
And I don't think it's everyone either, although that's a neat answer. That would be like a nice poster when everyone owns AI and you'd feel great about it until you tried to figure out what exactly the hell you were on about. So I personally think there's no shortcut and you have to break down the elements for me like you would with other things starting from the business outcome or decision that's going to be made by this AI and that is the business executive on whose P&L that revenue, productivity or other outcome sits - someone on the GEC or executive committee.

So I think you start with who owns that decision. The CDO should absolutely take responsibility for the data and the knowledge that feeds that model and then lay out any potential risks or incompleteness or things that should be known about it. And that should then be overlaid with the overall appetite that the board sets for risk or use of AI. If the board hasn't discussed that then they really should and that should be clear. The CTO will own the tech right?

So if they've said these are the off-the-shelf tools you use and this is when you have to home-brew it and if you home-brew a tool this is the governance it goes through they have to make sure that happens and those signoffs are obtained.

Then there's risk and independent challenge; obviously, risk has to own that and then depending on what format your CDO team's in then the CDO can also own the product or model that sits behind that but I'm aware that not all CDOs have that; it could be part of tech or it could be a part of the chief product officer or whatever but for me there are probably three layers: there's the overall appetite and framework that the board must have discussed and there must be something written down and if it's not practical then it's absolutely fine to ask the board for guidance.

Then there's the business sponsor who's the person who's going to book that revenue or productivity from the thing that's getting built and then it's the people that are building it and that's usually tech data with a little risk check. So it's not that neat an answer in my opinion. It would really be everyone and it would be easy - or stupid, I think - to say all sits with the data people because you'll soon lose touch with the business.

So it would just I think it just needs a bit of a mature framework and someone needs to write it down and make sure everyone agrees and if they don't agree ask which bit they don't agree with, because it's better working this out now than getting to a pilot realizing it doesn't work and then every time you do a pilot you've got this same pain. Go through the pain once properly, live the pain, write it down, get people to sign it up. That's my view. No substitute for graft to get it right.

Pete Youngs (22:33):
Yeah, indeed. Yeah. And then Lisa, I guess explicit ownership is at the core of what Barry said. So, I know we've touched on it in some of the early conversations we've had here, but when that ownership is implied, someone else owns the data, someone else owns the decision, someone else owns the control, someone else owns the outcome, or maybe that's all ambiguous. When you review an AI pilot in the context of what we're talking about, where do you see those problems start to appear?

Lisa Lewis (23:07):
Yeah, they start to appear everywhere. But it's a cultural shift first, right? It's understanding that everyone is accountable to their piece and together we're all accountable for it, right? Ownership specifically, you know, decisions may be made by somebody who isn't the owner. We can't have that. Rules may be documented by someone who maybe doesn't know all the rules, right? They may not know what its original intended use was and some of the logic that went into how it got to its current state, right? Both of those introduce significant risk.

Problems arise in the data and in knowing who's responsible for them. How they get resolved introduces trust issues if we don't have that clearly documented and understood by the entire team, right? Not just the data people who own it, right? The business owners, the data owners, the technology owners. You know, having their names on the line, right? We need to know who to contact in each of those different scenarios because they're all part of the whole, right?

And we have to have clear ownership of the whole, which is each of its component parts, so that we don't block progress, so that we don't stifle innovation, so that we don't create quality questions along the way.

Pete Youngs (24:23):
Yeah. Think we did a piece of work with a client recently and it involved very progressive thinking, but one of the first things that we did was we did a bit of a RACI matrix and even a risk matrix and that was written down on paper in the context of a use case: who is the product owner who's going to own the outcome who's going to own the technology Yes, it's the CTO, but that delegates down, and so on so I feel like we're cycling over some of this. It's just how you do good change management, isn't it?

And we seem to be being a bit distracted by the AI hype and rushing into things around the hype cycle and excitement. But yeah, maybe we just need to check ourselves. Yeah. Okay. So moving to what everyone talks about 'garbage in, garbage out' and bad data. Mark, I think it's too simple a diagnosis in this context. So AI doesn't just need clean data. Obviously, we want good-quality data always to drive decision-making, but it needs that information and context so that AI can trust and understand it. And we're saying that a lot.

So, what does AI actually need from enterprise information in order to produce reliable answers? I know you've listed some of the things that we've done badly in the past, but what does it need? What does it need beyond clean data?

Beyond 'Bad Data': Business Context and Trusted Information (25:06–28:41)

Mark McQueen (25:43):
Yeah. I mean, I can't agree with you more that bad data, in my opinion, has become an unhelpful phrase because it's created a scapegoat, a way to defend AI because we don't have good data. Yeah. And it's more than that. So, you know, it is that business context. I mean, if you have five banks lining the street here that are all using AI to create, you know, a statistical answer based on what it knows in the world, you haven't provided that AI any understanding of your business.

You know, your risk tolerance, your value propositions, you know, your product set, you know, all of these all of these different components that go into that business understanding. And actually the third in the series of these webinars is about business memory. So make sure you show up in two weeks. Don't skip governance next week but in two weeks, it's going to be a deep dive on what is that business memory and how do you capture that business memory?

I would suggest that it's enterprise architecture on steroids it's really you know forget enterprise architecture of 20 years ago that is a book of lists I've listed all my technology I've listed all my organisation you know but take that and turn it into using knowledge graph and ontology, turn it into a connected set of knowledge about your business where you bring those additional things in like risk tolerance and so forth and that becomes a very valuable input to AI along with good-quality data at the right time with the right ownership for the AI solution that you're driving.

Pete Youngs (27:58):
Okay, thanks, Mark. So yeah, we will touch on that in a couple of weeks time. And I do think some of that gets quite technical, but we're aiming to elevate that up so people can understand more because there has to be business understanding and business impact of that clearly rather than it being a technical geek-out on vectors, knowledge graphs and ontology because some of that can lose people quite quickly. So focus on the outcome. So that'll be a really interesting conversation.

Mark McQueen (28:24):
And bring our data expertise to the table. I mean what we're describing there is a knowledge product. Manage that product like we manage the other data products in the organisation so that it becomes a valuable asset.

Questions Leaders Should Ask Before Scaling AI (28:41–33:47)

Pete Youngs (28:41):
Yeah, the same practices. Good point. Okay, coming to you, Barry and thinking about how we scale AI. Is there a list of questions that leaders should be asking about the information that AI models will rely on? Is it about data trust on the way in? Is it about clarity of ownership? I think it probably comes back to your first point. Do we have to prove the data is approved and ready before we go into the AI case?

I think we're probably saying yes, but you could experiment and you could see what the outcome is from the model and presumably there's a fail-fast aspect of that as well.

Barry Panayi (29:22):
Yeah, I mean it's not a question one would answer with data, but I think you should be asking can we explain stop or reverse this? You need to be able to answer yes to probably all three. That would make me a bit more comfortable. How do you know if it still remains effective or accurate? So, what monitoring is in place, and do people understand it? And what humans are in the loop and what does that really mean? Is it someone overworked just clicking next, next, next or is it someone actually reviewing the output in a structured way and documenting it?

Not that I'm saying that the poor humans that are in these loops aren't doing anything other than clicking next, next, next, but you can see it being on the side of someone's desk and the pressure for productivity would mean that would be a tax on that, wouldn't it? And then is the information at the appropriate level, you know, is it permitted to be used? I won't use is it good, is it bad? Because of course there's no such thing. Is it as authoritative as it should be for the use case?

Someone should know that and they should know who to call. If it's not, they should be able to answer that question. And what business knowledge does it depend on to understand what it's saying, you know, because it's probably unrealistic to suggest everyone's got the same taxonomy and language across massive organisations. So, it needs to be clear. And if there's any room for ambiguity, one should know who you're going to call when that happens. And I think the question I would always ask is the obvious one that maybe someone knew ages ago before it got completely mangled out of shape.

What decision or action am I actually going to make, or is the AI going to make, with this? Is that still the right one? Because if that has changed or it isn't the right one, then the data is not the right data I think. So I've just lobbed some questions over. That's what I would ask, but again it's about clarity and not assuming because of humans having a sniff somewhere down the process that it's all okay because humans did everything before and mistakes happened.

So now we've got more things to do, the human things and the things where we're in the loop of the AI. All of the productivity benefits and gains that people quote, I think, are gross. I mean gross as in they're not net of the effort needed to be in the loop. Not gross as in absolutely disgusting.

Pete Youngs (32:08):
Yeah. I guess they might be.

Barry Panayi (32:10):
Yeah. Sometimes.

Pete Youngs (32:13):
Yeah. Yeah. And you're also making me think surely it's about confidence in stopping like sometimes we get caught up in activity is progress and pushing things through as well, isn't there?

Barry Panayi (32:24):
Yeah.

Pete Youngs (32:25):
Yeah.

Barry Panayi (32:26):
I mean I am no expert in the soft, people side of things. I've been a data person for too long. I think it's probably been hammered out of me. But if one is in a culture where it's not okay to say do you know what I'm not sure about this. I know we've spent X amount of money getting it to this point. I know go-live is on Tuesday and I know we presented it to the exec a couple of weeks ago, but can we just hit pause?

There should be an absolutely safe environment for someone to do that with real senior support and almost celebrating the fact that someone's pressed that emergency button. I tell you, it makes a hell of a lot more noise if you press it after it's launched. So, there is a cultural element to this which I'm definitely not, you know, qualified to opine on.

I try my best, but all of this relies on people saying what's on their mind rather than, well, I knew it would fail or that data was never good enough for that or the service was never going to be able to handle that much traffic, you know, that's fireable in my opinion.

Pete Youngs (33:28):
Yeah.

Barry Panayi (33:29):
But saying it early.

Pete Youngs (33:31):
Yeah. Yeah. It's interesting, isn't it? It's a data-focused, AI-focused conversation. Still comes back to culture, accountability, people, operating model. So, yeah. It's interesting.

Privacy, Permitted Use and Enterprise Risk (33:47–35:57)

Pete Youngs (33:47):
Okay. Thank you, Barry. Lisa, in the article we highlight that AI and I think we touched on this already briefly. AI can take information collected or approved for one purpose and especially when we think about that from a data privacy and protection perspective, use it in a completely different context because clearly it doesn't have that context and understanding. I think it builds on what Mark and Barry have said. So, from a privacy and compliance perspective, which I know is a core part of your role, but surely from a reputational perspective for the organisation as well, is this catching firms out?

What's your view on this?

Lisa Lewis (34:26):
Yeah, absolutely. Top of mind for lots of companies. Taking data out of context, being unclear about any particular privacy rules, laws, or otherwise applicable legislation, data rights, contractual obligations, sourcing constraints, all of those things play into the question: can I do what I'm trying to do with this data? And without the proper gates in place to verify that, you're putting your AI in a really bad place. But it's not the AI's fault. It'll look like it is the AI's fault, but it's not the AI's fault, right? You've got to have those attributes.

You've got to provide the AI all of the information that it needs to understand and that the AI can trust the data that it's getting. You know, we talk a lot about the people trusting the data. We've got to build the information in a way that the AI can trust that it's going to do a good job with what we're giving it.

Pete Youngs (35:23):
Yeah. Yeah. And I think it's really easy to think about data protection and privacy there. But your point on contractual obligations like market data in financial services, I can just foresee people pumping their market data into a platform and the AI going crazy and there are so many restrictions built into those market data contracts. So...

Lisa Lewis (35:43):
That is a tricky situation.

Pete Youngs (35:45):
Very tricky. Yeah. I don't know why Zoom has added me twice to the meeting now. So maybe the Zoom AI is getting a bit carried away, but there's now a clone of me in the meeting.

Barry Panayi (35:54):
You have to say it twice.

Machine-Speed AI and Human-Speed Governance (35:57–44:30)

Pete Youngs (35:57):
Thank you. I'm going to take that, Barry. Okay, moving on. If we move into what the article talks about around the speed mismatch and that AI moves faster than traditional governance. It's a really strong point in the article. AI acts continuously across large volumes of information. Governance - not always, but often still quite traditional - depends on people reviewing documents, interpreting policies and so on and fundamentally manual processes. So we really have machine-speed execution running on human-speed governance, and risk builds up in the gap. There are a couple of parts to this, and control latency is the next one.

But, Lisa, coming back to you: are you seeing AI moving faster than organisations can review approve and assure what it's doing? We've touched on this. Does that mean controls need to be built in a different way - surely through automation - so governance and control can catch up with the speed and scale of AI? What's your perspective on that?

Lisa Lewis (37:00):
Yeah, and we're needing to build AI into our governance and compliance tooling to keep up, right? We can't be a bottleneck. We can't build, you know, large manual teams to monitor these massive amounts of data that we have. You know, the AI is absolutely moving faster than anybody else could track it and govern it. So we definitely are looking at how far upstream in the processes we can build the tooling and catch issues and errors as soon as possible. Checking processes have to be set up to scale.

We need to make sure that we're building them out in a way that we can deploy them quickly into the next sets of data as they come up. Right? The tooling is allowing us to at least attempt to keep up. Whereas I'm certain that there's a lot of places that are really falling behind.

Pete Youngs (37:50):
Yeah, we were working with a client recently on drift and hallucination. This isn't really new. I know it's the probabilistic nature of generative AI, but this goes back to machine learning models, their safety, and testing the outputs, making sure they're still doing what we want them to do. And that risk of a generative probabilistic model drifting and hallucinating and we have to have automated control in there, don't we, to spot that. So, absolutely, I hope people really know that and are making sure that's built in when they're using generative AI models.

But yeah, maybe drop in the chat and let us know if you've got that nailed. Okay. I mentioned control latency. So, Barry, this is the idea of the gap between AI doing something and the organisation being able to understand, govern or correct it. So I guess fundamentally a decision being made and then risk and governance keeping up with that and maybe you touched on something similar to this in your Databricks interview around insight lag. So is this a real cost around that gap between the AI doing something and the governance keeping up? It feels like it is.

But are you seeing this?

Barry Panayi (39:05):
I think it relates a bit to what we discussed earlier in that I think it's acceptable to be slower and have that lag the first time you do something. Yeah, it's unacceptable to take shortcuts to pretend it's not there because it will get bigger and bigger until it goes pop and ultimately you'll lose organizational value in my opinion because you're just absorbing manual effort, aren't you? As well by trying to keep up and not doing it properly. There's also this thing about learning loops and you know you're doing your first pilot for the first time, there is a lag.

People are going to moan you're going to have to suck it up and do it properly. You're not going to get it right first time and then you need to be able to have a look at what's caused that lag and then build it into the next pilot. It'll be shorter and shorter and shorter and eventually hopefully it will become negligible and not so much of a pain. But the pressure of getting things done and launched so quickly. So there's some metric somewhere that says that it's gone live. I think again we're creating and masking learning and effort.

So you do eight pilots, you'll have that same lag eight times. Eight times X if that's the lag. If you've done it in X the first time and taken a little learning from it and there's X minus a bit on the next one and the next one and the next one those learning loops will keep you going and that's the long game. And I think that we're at the stage of AI now. I know it's in its infancy.

It is going to get better and everything, but I think there's been enough people having a go at this and realizing this stuff that it would again be quite inexcusable for a senior data professional not to take the learnings and build it in and understand what that lag is as opposed to thinking it's just a technology or it's a technology problem or an adoption problem. It's not. It's just a product problem. If you've got proper product people that will hold you to account to launch a product, then they'll tell you that is how things get better and better and better.

These features are added and then suddenly things get quicker and you don't hit that problem again. It's madness to keep making the same mistake again and again. But that's where you get to if you want to reduce that lag immediately and almost mask it with operational processes and new little backdoor manual things you have to do.

Lisa Lewis (41:37):
Yeah, I like that learning. I think some of that too goes back to that cultural shift, right? The more that teams understand and are aware of the processes and they know that we've got to build in these controls and why they're important, understanding the why, right? Knowing what happens if we don't do those things is part of the culture: we want it to be right. We want it to go smoothly. We want it to deliver as expected on the outcomes.

And I think that you know we can collectively get faster with it when the participants have that cultural mindset: I am going to design my flow, my processes, my operationalised stream to take into account those gates and I'm going to be prepared with all the material that I need to pass through those gates quickly.

Pete Youngs (42:29):
Right. Yeah. I think that helps the overall process there. And surely when that doesn't happen we must be working in silos like if those learning loops and cross-pollination of learning isn't happening then people are working in silos and making the same mistakes in parallel or whatever. Yeah. Okay. Interesting. Lisa coming back to you. This control latency point then the gap between AI processing an outcome at scale and the governance keeping up. In a regulated, complex environment - and with the human barriers in financial services organisations - is the risk greater, or is it the same for everyone?

What are your thoughts?

Lisa Lewis (43:12):
Absolutely, and it's not the same for everyone. Even within our company it's not the same for everyone because some parts of the businesses are highly regulated and others are not. And there are different processes that we have in each of those areas, right? The different data sets, the different use cases for products, the different use cases for customers lead us into having to manage a couple of different governance streams. That's fine. Everything isn't, you know, one for one across the board and we're okay with that.

The most highly regulated and complex are going to have, you know, additional board reviews and certifications within their organisations, within, you know, their group of, you know, accountable parties and additional peripheral compliance teams and additional risk evaluations and, you know, lots of additional pieces. They know that, and that's part of their culture, though. They understand because they are highly regulated, because they are that complex, they need to have those additional gates and approvals.

Pete Youngs (44:14):
Yeah. And ironically, surely the business-context application of regulation within a business and within sub-businesses are part of your business and part of your business understanding and context that we want the AI to know. Yeah. Okay.

What Must Change Inside the Operating Model (44:30–48:14)

Pete Youngs (44:30):
Mark, coming to you. So if the answer is not another policy, human governance, a steering committee or another impressive AI demo, what really has to change? We presumably still need policy and steering committees - with project management AI coming into play, of course. What really has to change inside the organisation? So we've touched on ownership, we've touched on automation of governance and controls so that we can make AI scale. Is there like maybe three key points? We've touched on them. Maybe it's just a bit of a takeaway on the three key points that you see.

Mark McQueen (45:06):
Yeah. So to make it simple and quick, if I could change one thing, it would be to stop reducing AI readiness to bad data. You know the real issue is whether the organisation can deliver good-quality, controlled data at the speed AI requires. That means governance by design, not governance by check and committee and so forth. When the controls are automated, observable and continuously evidenced by that design, you've automated a control environment. And that's when data becomes genuinely AI-ready because it's not just good data, it's data at the speed that AI needs to operate at.

Pete Youngs (45:52):
Yeah. Okay. And Barry, from your internal CDO perspective, is there one thing that you're sort of focused on changing in the Howden operating model to help make this work.

Barry Panayi (46:03):
Well, I think it's about understanding the operations. I need to educate myself more about what actually happens in the operations of a business. And a role that I don't see very often is kind of a global process owner role or something similar that I think is a massive unlock for AI. Because they're the ones that are going to make sure that the processes are changed properly in the way that the business works day-to-day. Otherwise, I worry that I'm doing a bit of a Jenga thing.

I'm kind of building things higher and higher with cooler and cooler things and it all looks really neat at the top. So I'm really pushing myself to understand what the actual process is, what people actually do, and who owns that because it is never as simple as I think. There's a reason why things are as they are today and we're just replacing something with another thing that fixes one of the things but something else breaks. So I think this problem is as old as organisations. This is process improvement; AI is just another tool.

I don't want to reduce AI just to that, but if it's going to work it needs to be in some sort of process somewhere.

Pete Youngs (47:19):
I'm pleased you said that because we should always take things back to business process, don't we? All a business does is run processes in the context of that organisation to achieve an outcome. I know it does diminish it and it's not that simple, but yeah, I like it personally. Lisa, anything to add, one thing that you would fix now?

Lisa Lewis (47:38):
Yeah, and I think it's something that we've had in progress for quite a while. It's using the automation controls, using the governance design as early in the process as you can. Because we can't use humans to keep up with the pace, right? The speed of the data is far outgrowing any ability for us to think that anything that is a manual process today can continue. We've got to have the time and the tooling put in place for AI-enabled governance, AI-enabled quality checking and controls monitoring and implementation.

AI Data Readiness Reality Check (48:14–49:28)

Pete Youngs (48:14):
Great. Thank you. Right. We're 49 minutes in which I can't believe. So for one minute now, there is going to be an absolutely shameless plug for Ortecha's AI data readiness reality check. So Mark, I've used 5 seconds of your one minute. So can you tell us a bit more about this?

Mark McQueen (48:32):
Our reality check is designed to move quickly from diagnosis to action to get to business value. It helps leaders identify where AI use cases are most exposed, which data foundations are not yet ready and what needs to be fixed first. So in a matter of weeks, I mean this is a short blitz kind of approach. We help identify specific gaps limiting AI performance, prioritise the fixes that matter most and have a 30-, 60- and 90-day roadmap coming out of that. What the organisation does with that you know it depends.

It could be resolving one exposed AI use case, or it could be overhauling and building a broader AI operationalisation programme. It all starts with a conversation. We'd love to have a conversation with you to talk through where you are and see whether this reality check would be valuable for you.

Audience Q&A (49:28–56:50)

Pete Youngs (49:28):
Great. Thank you, Mark. So we're going to shortly move to questions. Before that we'll just do a quick takeaway and then we'll dive into the - no, we'll do the questions first, then we'll go to the takeaways because it might reorientate some of them. So clearly I think every organisation is using some AI in some way but there is a vast difference in maturity from obviously like Copilot rollout - getting it onto people's desktops to advanced models being built. Obviously, that is right and it is for the organisation to decide where they're at.

So, just to summarise the key things we've touched on. It's all about data foundations that should help us scale AI. Trust is clearly a key one. Do we trust the data? Ownership. We've said ownership and accountability. We've said those a huge amount. We've touched on the operating model points.

Business context is one that I think if you're a data geek, you've been thinking about this for a while, but I think it's really come to the fore in this conversation in recent times around how we can ground our clever AI models more so than we've had to with this human and tacit knowledge that we've talked about today. We've talked about good old change management and change management practices and actually some of this isn't new. It's just doing change right and fail fast, confidence to stop, some of those things.

So yeah, I think it's really about thinking about those points of good-quality data foundations underneath. Think about those gaps in the risk and the speed that AI makes you move and how your traditional governance needs to move into not just governance, but data management also needs to move into automation. But yeah, we'll dive into some questions and then we'll wrap up with some key takeaways and aim to wrap up on the hour. So, we have had some questions and this one is interesting. So, I'm just going to read this to the floor and one of you can chime in.

So, how are you measuring business trust in the AI's outputs on a day-to-day basis? I'm not sure I want to answer that, but anyone willing to give it a go?

Barry Panayi (51:43):
I don't know. Off to you.

Lisa Lewis (51:46):
I don't think there is an actual measurement of trust that we use consistently. You know, and there's definitely the difference in data that we are commercializing, right? Our data products out to customers externally versus the data that we have internally for things like KPIs and metrics and performance and other internal kind of back-office data. But I do think that we are able to look holistically: is the data meeting the use case and how confident are we that the data is doing that.

Pete Youngs (52:28):
Okay, thanks, Lisa. Barry, anything to add?

Barry Panayi (52:31):
I'd say no given time. Nothing that's going to be as useful as what Lisa said.

Pete Youngs (52:39):
And surely it has to. I hate to say it, but surely it does depend, doesn't it? It probably depends on the use case and the.

Barry Panayi (52:45):
End use case. Yeah, maybe trust is in the eye of the beholder.

Lisa Lewis (52:51):
Yes.

Pete Youngs (52:51):
Good. Let's go with that.

Lisa Lewis (52:52):
Same thing with risk, right? How risky is this? Well, it depends on what you're saying with it, right?

Pete Youngs (52:58):
Yeah, and both sides should be considered because you could be saying you trust it but there's risk in the next step. So yeah, that consideration of both is really important, isn't it? Mark, you mentioned enterprise architecture earlier. I know Barry has then mentioned process which is a lovely connection down into enterprise architecture thinking into how we really understand our business processes. But Mark, what role do you see enterprise architecture playing in documenting data processes and being AI-ready? Because I think this really varies, doesn't it?

I've seen good enterprise and enterprise data architecture diminish over recent years and maybe it's having a bit of a comeback.

Mark McQueen (53:38):
And I think what we're seeing with some of the enterprise architecture tooling capability is they are bringing ontology and knowledge graphs into play in a way that you can harvest out of lots of your other operational tools and bring that content. Even just thinking about data management: if you've got a capability in your enterprise architecture model of data management, how do you build that out? How do you formalize the business processes and capture metadata? How do you bring metadata into your enterprise architecture tool in a way that you are linking all of your data together?

And truly some of the tools are moving towards becoming a digital twin of your business environment. But from a data perspective, a digital twin of your data environment that allows you to manage it in a very different way and feed into the AI to give it that knowledge and context. Yeah. Okay.

Pete Youngs (54:43):
It is that context. Okay. I think maybe one more question here. It's quite broad. It's for Barry or Lisa. Are there some use cases clearly for AI and thinking about the data foundations, have you seen be more successful than others?

Barry Panayi (55:05):
At the risk of answering with an obvious answer. So you can tell me to play again if you like. The ones that are always better are where someone has asked an actual business question directly rather than where we've come up with something that is solving a particular issue that we think we've seen. And therefore the person asking the question is the de facto final product owner who sees it all the way through. They've asked a question; we've not said, 'Is there anything we can do to help you?' They've proactively come to us.

I think sometimes we spend too much time thinking clever thoughts when actually the right questions are out there with people who are in my case selling the business, making our clients happy and understand what our clients want. So I would say just do that and if you're in the lucky position where you do all that and you've exhausted all the good questions by all means come up with the clever, beautiful thoughts. There's an element of humility required. It's taken me much longer than it should have to understand: just do what people need.

Pete Youngs (56:25):
They know best. Customers know best, don't they? Whether they're internal or external. Yeah, it's a 'build it and they will come', isn't it? Don't build it thinking they'll come. Just answer the business. Answer the business questions. Yeah.

Barry Panayi (56:38):
It's a prevalent mindset in our industry - the data industry, I'm talking about. It's easier said than done, isn't it? But just do the things that people actually want.

Key Takeaways and Closing (56:50–60:35)

Pete Youngs (56:50):
Yeah, I love that. Okay. We'll do key takeaways and then we'll close and I think we'll be just about on the hour. So, coming to you first, Lisa: one key takeaway and only one and maybe something that you wish you'd known like six to twelve months ago before this AI hype cycle really kicked in.

Lisa Lewis (57:10):
Yeah, I would say: definitely spend the time to focus on that culture shift first. You know that really drives an understanding of ownership and accountability, understanding the operating models, getting that right helps the rest of it to fall into place.

Pete Youngs (57:32):
Okay.

Lisa Lewis (57:32):
I think some of that often comes on after the fact.

Pete Youngs (57:35):
Yeah, indeed. And Barry, one key takeaway.

Barry Panayi (57:39):
Don't replace a bunch of manual processes that you've automated away with some others that are in the shadows just to make it look like the AI is working smoothly.

Pete Youngs (57:49):
Well, don't replace your robotic process automation with AI just for the sake of it. Okay. And Mark, coming to you for one key takeaway.

Mark McQueen (57:58):
Data management has struggled for a couple of decades with getting business ownership of the data. The business process that creates the data has to own the data. And that's because we put too much manual labour in the process. If we can get rid of the manual labour and just use the brain rather than the brawn of the business, we will solve a big problem. And that comes through automation like Barry was describing.

Pete Youngs (58:27):
Yeah. Cool. Thank you. I think we've got some good little snippets for today. Brain, not brawn and some others that we've said earlier on. I'm going to get these posted on LinkedIn next week. So, we are almost on the hour. So, thank you very much, Lisa, Barry, and Mark. That's a great conversation. I guess key takeaway, enterprise AI does not become reliable because the AI gets better on its own. It becomes reliable when those enterprise data foundations are considered and put in place.

And when we say that, we're talking about the data, understanding of the data, the ownership, the context, clearly the quality, but not just bad data, the governance, the controls, the accountability, and being able to evidence that. And if those foundations are unclear, AI is going to expose them, and it's going to expose them pretty fast. And it's not just in your pilot stalling or failing. It's a broader perception of what you do as a team and what the organisation's doing with progressive tooling and capability.

So we believe it's obviously better to expose or fix those foundations deliberately before they're exposed by AI. Please don't stop doing AI; continue. It isn't going away. This is a fundamental shift in how businesses operate but maybe think about building those foundations incrementally as you go whilst enabling your AI delivery. So we are basically done. We're one minute over. As we said, this is one of three webinars that we're doing. Next week focuses on governance readiness, making AI controllable and the week after - maybe a week after that - enterprise memory readiness, making AI accurate.