Michael Privat: Data Weakness, Not AI Tools, Derails Enterprise AI Investments

[00:00:00] Welcome to the Business of Tech. Thank you for having me. So I want to start with a number that sits at the center of everything I think you've been writing about, because I think it's kind of the most important number that jumped right out at me in enterprise AI. That MIT research pegging 95% of enterprise AI pilots at zero measurable P&L impact, like despite the estimated 30 to $40 billion invested.

[00:00:24] From your vantage point, you're running 700 plus engineers. What actually separates the 5% that deliver from the 95% that don't? Yeah. So that came out of a Media Lab, MIT Media Lab report. I think it was last year. And yes, you're right. They're spending over $30 billion on pilots.

[00:00:46] And I think the answer to your question is you can't pilot your way out of a data problem. And I think that companies treat pilot as more of a procurement exercise. You know, I bought a tool, I ran a pilot, I declare a win, I put out a press release. But the problem is the pilot was never the deliverable. The outcome was an afterthought.

[00:01:11] And so now we're measuring outcome. So everybody's focused on building pilots. We're measuring outcomes. Of course, it doesn't match. That's the main issue with this. But I think embedded in your answer is another piece of that, right? Because you mentioned the data, right? And so I think we have to link data to outcome too. Tell me a little bit more about that piece.

[00:01:30] Yeah. So I think the first thing to understand is that AI is an amplifier. It basically amplifies what's already there. It doesn't actually fix anything. It just makes everything larger, weaker or stronger. So if you have strong fundamentals, they'll get stronger. But if you have broken plumbing, then AI will scale its dysfunction, essentially. And I think that's the picture that most people are missing.

[00:01:59] You're running pilots. You're on weak foundations. And these pilots, because you're using AI, are exposing all of this. And that leads to even faster failure. Broken processes will get even more broken with AI.

[00:02:13] Well, that's never a good thing. But I think there's another dimension here too. You've written about thin AI overlays that are getting repriced. Walk me through what a thin overlay looks like in practice. And I'm sure that ties back to the data infrastructure we were just talking about.

[00:02:32] Yeah. I think that clean balance sheet plus confused AI is now a discount and it's no longer a premium. So where before, you know, two years ago, just mentioning AI on some earning calls would get you 5%, you know, on top of your stock price average.

[00:02:50] I think that now we all realize that just AI is not the whole story. You know, there was a report, well, actually, it's the same report that states that out of all the companies, I think 74, 75% of companies are expecting revenue growth from AI and only 20% are getting it.

[00:03:22] So what's going on with the 80% that is remaining. And the problem is they're not actually failing at AI. They're failing at everything underneath it. So when I talk about that thin AI layer, I'm referring to that veneer that's on top of, you know, the thing that you should already have that should be strong.

[00:03:42] So I'm talking about like real data infrastructure, for example, so that, you know, a lot of companies have multiple systems running and they all kind of talk about the same data. But is the data actually the same underneath or do you have multiple copies that have drifted apart from each other? AI will expose all that. So as you put a thin veneer of AI on top of all this, if it was weak to begin with, it is now weaker. And that exposes all the failures just more rapidly.

[00:04:11] We'll be right back after this message.

[00:04:37] Next one is to learn more about managing multiple tenants, provisioning environments, managing policies, and optimizing as your costs. So MSPs can run Microsoft cloud services without the operational overhead that usually comes with it. Instead of building and maintaining those systems manually, Nerdio provides a platform designed specifically for MSP operations. If Microsoft cloud is part of your services strategy, Nerdio is worth a look. Learn more at getnerdio.com

[00:05:07] And we're back. Okay, so let's dive into some of how you're implementing here, because I think that the insights into the engineering investments that you're making and how you're executing on it really help. You're operating a DORA-driven operating model. So walk me through what that means. What is that? How does it work? And how does it become kind of predictive of whether the AI initiative is going to deliver some value?

[00:05:35] Yeah, so that's an interesting statement, because yes, we did start with DORA. One of the things that I realized going in was we gave everyone a Lamborghini, essentially. They now have AI, right? So that's akin to you have a Lamborghini, you can go a whole lot faster. And what I'm finding is our processes are the limiters. So think of it as you all got a Lamborghini, but the speed limit is 20 miles an hour. That's a problem.

[00:06:05] And so, you know, back to your question, all of these processes were all designed pre-AI. They were all designed to control predictability of the outcome. And that's the essence of your question. They never accounted for light year speed, which you could never get before. But now we do.

[00:06:30] And if you're focused only on predictability, even though you could go at light speed, you're not going to get light speed. So that is not the outcome you're looking for. You're going to get predictable outcome, but it's going to be predictably slow. And I think that's the main issue that, or one of the main issues that I addressed early on with the teams. We need to change the way we work. It relates to what I said earlier when I said AI makes everything, you know, bigger.

[00:07:00] It amplifies everything. If our development processes were broken before, because we've focused so much on Dora metrics, and they may or may not be relevant anymore, we are self-limiting. I had an interesting conversation just today earlier about how come, now that every developer has AI tools, how come we're not delivering any faster?

[00:07:26] And that is the exact same conversation that should say, yes, everybody's equipped with better tools, but our processes are limiting us. And that's what we have to change. So that's what we changed. And that's how we're approaching AI in the organization, at least at the development layer. Again, never forget that AI is the amplifier.

[00:07:48] I'm never going to say this enough, because every little thing that is wrong, that was wrong before, that was not noticeable before, is now 10 times or 100 times bigger. This is very noticeable. So for those listeners that may not understand, walk me through a little bit about the Dora model, because I think what's interesting to understand then is, is what are the pieces of that that were working for you? What were the ones that you quickly identified didn't? Yeah. Yeah.

[00:08:14] So there are various metrics, you know, that obviously that you can use for Indora. And some of them are related to speed. Some of them are related to quality. Those that are related to quality are obviously still valid. Those that are related to velocity are probably now less valid. So you can measure velocity.

[00:08:36] But if your velocity is stopped by your process and you are now slowed down by something that's different from what you're trying to address with AI, you're slowed down by your process. You can go, you actually can get tools that get you faster and you're slowing down. So like, you know, an example of that is Scrum Ceremonies, everyday standup. We're now going to spend 15 minutes every day getting into a meeting and we're going to discuss some of these things that we've done yesterday with the roadblocks, etc.

[00:09:05] The problem with that is those are 15 minutes where we were going at light speed or we could have been going at light speed where we were just at a standstill. I'm not saying these meetings are useless. Not quite. I think there is value, but I think we need to collect that value differently now that we have better tools. We'll be right back after this message. This episode is brought to you by Control Map.

[00:09:32] Growing MSPs are using Control Map to build recurring revenue by expanding their GRC services. Starting now, Control Map is offering a free plan for MSPs looking to get started with providing compliance as a service. Create a free account and run an assessment. Track key items like policies, risks, and evidence in one place. It's a practical way to prove value to a client before deciding to expand your compliance offering. Try Control Map for free today.

[00:10:00] Visit scalepad.com slash Dave to get started. That's scalepad.com slash Dave. One of the things that I thought was interesting is you're investing in tripling your engineering headcount, particularly your engineering headcount in India, by the end of this year. There's obviously a lot of headlines about organizations that are shrinking and saying you're having an AI conversation and talking about expanding.

[00:10:25] Talk to me a little bit about the driver behind that decision and how you intend to preserve your engineering culture and quality at that pace, both in people and AI. Yeah. So that's a really good question. Part of the premise should be, first of all, that there should be no difference where the engineering function is located. Other than time zones, obviously, I call that a complication. It's not so much a huge problem. It's a complication.

[00:10:54] There's a cultural difference, to your point. You account for it. But none of the sort of location, you know, location-based cultural differences are the things that I'm after. For my teams, I'm very focused on what I call engineering discipline. You know, I always tell my teams I want lovable software. And lovable software means something to everyone in my org because I've been sort of describing that.

[00:11:23] It means it's, you know, you get joy from working on it. And you get happy when you run it. And our customers are excited about it. And it's beautiful to read. The code is pretty. The documentation is complete, etc. That's the kind of engineering discipline that I want. So test automation, those sort of things. I mean, you know all the things. And I summarize that in lovable products.

[00:11:48] Now, to the question of India versus the U.S., to me, it doesn't matter. Obviously, there's an economic topic related to that. And if everything else is the same, then obviously it makes a whole lot of sense to grow the staff in India. AI doesn't really play a role for me in that topic. Obviously, there is a, everyone's talking about staff reduction because of AI.

[00:12:17] I think the punchline for me there is AI is a reasonably intelligent system. And I say reasonably because I, and I mean that in a sense of it's not super intelligent in the same sense as your rockstar engineers. And so if you, you know, and I get that question a lot where a lot of people are asking me, am I getting replaced by AI? Why is my job at risk?

[00:12:47] And my answer usually is, well, if a reasonably intelligent, whether it's an agent or a person, can take your job, and what does it say about how you're doing your job? There is a topic about how much of your intellect are you applying to your job that would make you irreplaceable. There's also a second topic related to that, which is we've been asking a lot of the engineers.

[00:13:16] Technology moves fast. They have to learn fast. Cybersecurity is rampant. You know, our hacks are rampant. We have to protect. We have to do a lot of upgrades all the time. We now ask a lot more out of our engineers than we used to even 15 years ago. And so if everybody's going at 120% of their capacity all the time, they welcome AI that's going to take, you know, 30% back. And so that's kind of how I look at AI.

[00:13:44] Frankly, it's to me is not a staff reducer. It's an efficiency enhancer. Again, the amplifier. But the premise is that everything underneath it is solid. So it assumes that everybody's applying engineering excellence. It assumes that we've done the work to clean up our processes. It assumes that we've done the work to simplify our systems.

[00:14:10] There's a lot that needs to be done before you can efficiently apply AI. If you do not do that, you will apply AI. And I think you'll embarrass yourself because it's just going to expose all the inefficiencies that you've accumulated. Everyone's accumulated. Everyone does that, right? So it's time for spring cleaning. Then you do AI. So that seems to lead us quite naturally into the governance conversation, which is one that I've been having a lot on my own show.

[00:14:39] You know, if you're having to think about frameworks and ways of applying this, talk to me a little bit about the way that you're thinking about that. I know you've argued that agentic AI requires a new approach. How are you thinking about governance in this space? Yeah. So a lot of the companies that I talk to are trying to take their traditional AI governance and extend it to become agentic AI governance.

[00:15:07] And obviously there's a fundamental difference. Traditional AI governance is all about point in time governance. So if I have an AI model, I want to govern the accuracy of its output. I want to govern biases, those sort of things. So this is all about input versus output governance. But when you talk about governing agentic AI, you're talking about a dynamic system.

[00:15:35] You're talking about a system that makes decisions. And by the time that you discover that it may have made the wrong decision, the decision already has consequences. And therefore, you can't take traditional AI governance and apply the same techniques. So the framework that I use, which I actually got from the CEO of Cisco on a podcast. I forget which one, but he described it as three parts.

[00:16:00] One is you have to have you have to define the capability gates, which is what the agent is actually allowed to touch. So that would be scope permissions and no ambient authority. It's I give you the ability to read, but I don't give you the ability to write. It is I give you the ability to suggest, but I don't give you the ability to execute. Those are capability gates. The second one is behavioral guardrails.

[00:16:29] So I gave you capabilities. Now I'm going to control what you're doing. So those would be like more. They're more. Think of them as runtime constraints. It is maybe checking on whether an action is reversible or not. So if it's reversible, I'll allow you to do it. If it's not, I want to be in the loop. It is about setting confidence thresholds, specifically, you know, before consequential steps.

[00:16:56] And it is designing sort of the seamless interaction between humans and agents very deliberately so that you don't discover them in a postmortem. So those are like behavioral guardrails. And then third, very, very important, especially for us because of ALEDs in the healthcare space are audit trails. So that means every action, everything the agent is intending to do, we must be able to reproduce it.

[00:17:25] We have to log intent, not just the outcome. The outcome is needed, but it's not necessary. I mean, it's not all the things that you need. You need the intent as well. That's super, super important. Now, healthcare itself is a space that you spend a lot of time in. It's a highly regulated sector. Does that make governance easier or harder to implement than, say, professional services or retail? Like, how is that difference in a regulated environment?

[00:17:54] It may make it harder, but the way I look at it is it's not so much that it's making compliance harder or governance harder. I think of it as a forcing function for the work that we should have been doing anyway. It doesn't matter whether you're regulated or not regulated. At the end of the day, you should protect yourself against cyber attacks and whatnot regardless.

[00:18:23] Now, of course, in healthcare, there's a lot of private data that's flying around. And so, of course, we are very, very careful. Luckily, I'm very lucky because it is, out of validity is never an afterthought. It's part of our DNA. So we think about it all the time. And so I look at standards like high trust in HIPAA and things like this as forcing functions. They help us do the right thing.

[00:18:49] They force us to do the thing that everybody should be doing anyway. I think that in some way, it is true that regulation makes you slow down, undeniably. But it may be the right speed when the cost of being wrong is somebody's care. It may be the right speed. And that's what I mean by it's a forcing function.

[00:19:16] So we build governance as infrastructure. I don't really like having governance that's sort of hovering over the rest of the organization because sooner or later, that starts deteriorating. People start taking shortcuts. And all of a sudden, you realize that you're no longer governing even though you thought you were.

[00:19:38] So I like governance built in the infrastructure, in the capability gates that I mentioned earlier, in the behavioral guardrails, in the audit trails. Well before AI even makes it into, you know, well before AI was fashionable, that governance had to be in the infrastructure. This is governance is not just an AI problem. It's certainly exacerbated by AI.

[00:20:05] And maybe, you know, you will say instead of me by the end of this podcast, but AI is an amplifier. So, you know, any failure of governance will be amplified as well. Well, AI is amplifier leading to governance as infrastructure is a perfect place to end it because in theory, MSPs are the ones dealing with infrastructure.

[00:20:26] Michael Provod is the chief data and engineering officer at Avality and leads a 700 engineer organization inside of healthcare's most data intensive platforms focused on making enterprise AI accountable to real business outcomes. Michael, this has been super useful. Before I let you go, for someone in the audience who wants to follow your work or continue the conversation, where should they go? Best place is LinkedIn. Find me there. Send me a connection. I'll accept it. I accept all. I love the discussions. Awesome.

[00:20:55] Well, thanks for the discussion here, Michael. It's been a pleasure. Thanks, Dave. Want more from the Business of Tech? Join Business of Tech Plus for ad-free episodes, early interviews, extended cuts, subscriber-only shows, and exclusive member perks and analysis. Sign up at businessof.tech slash plus. And follow this show in your podcast app. And if you're on YouTube, hit subscribe and the bell so you never miss a story. Reviews and comments help spread the word, too.

[00:21:26] Interested in advertising? Head to mspradio.com slash engage. The Business of Tech is written and produced by me, Dave Sobel, under ethics guidelines posted at businessof.tech. Thanks for listening. I'll see you on the next episode. Produced by Picture This Video. Part of the MSP Radio Network. The Business of Tech. Thank you.