Dave Trier (ModelOp): Turning AI Policies into Workflows

0:08Kevin Werbach: Hi, I'm Kevin Werbach, Professor of Legal Studies and Business Ethics at the Wharton School of the University of Pennsylvania. For decades, I've studied emerging technologies from broadband to blockchain. Today, AI is promising to transform our world. But AI needs accountability, mechanisms to ensure it's developed and deployed in responsible, safe, and trustworthy ways. On this podcast, I speak with the experts leading the charge for accountable AI.

0:39Kevin Werbach: Model Op provides AI governance solutions for large enterprises. I talked with CEO Dave Trier about what it means to turn corporate policies into automated workflows, why pre-approved patterns for low-risk AI can speed the deployment, why traditional governance risk and compliance, or GRC, approaches break down for AI, and what it takes to govern agents all the way down to the network layer. Here's my conversation with Dave.

1:11Kevin Werbach: Welcome, Dave, and thank you for joining me on the road to accountable AI. Thanks. Appreciate you having me, Kevin. Why don't we start by talking about what exactly Model Op is and where it fits within the larger AI governance stack? Sure, I'd be happy to. We're an enterprise software company that's focused on large-scale AI delivery and governance. And we'll talk, I'm sure, quite a bit more about where that fits into the overall ecosystem. But at the end of the day, we help large enterprises to go and implement AI governance, just part of how they do AI delivery. And we have a very powerful software platform to enable them to do that at scale.

1:51Kevin Werbach: What's different about doing AI governance for large enterprises? Yeah, with large enterprises, there is a lot that's involved from a policy perspective, right? So for large enterprises, it's not just the regulatory policy. There's all kinds of corporate policies, as you can appreciate. There's corporate policies that are related to the use of data, corporate policies related to security, corporate policies related to the type of information that can be exchanged, the type of usages that they may allow or disallow from a corporate perspective. So at the end of the day, it comes down to how do you help them implement and enforce those corporate policies at scale?

2:32There's a few other minor ones, Kevin, but that's at the core of it, the key difference when you talk about enterprise AI governance.

2:39Kevin Werbach: What does that look like in practice, taking those corporate policies and translating them? Yeah, it's one of the big things that you have to do is that generally there's corporate policies that are 80, 100 plus pages, right? So how do you translate that into something that is really straightforward, but also embedded into how the different business teams want to go and develop and use AI? So in practice, what happens is that, and this is obviously where our software is great at, but what happens is we take those 80 or 100-page documents, which have a lot of process flows as well, right? There's a number of different processes.

3:18So we take those, and first and foremost, we take the processes and turn those into something that is really orchestrated, right? So instead of somebody going to have to read the 120-page document, rather, it's orchestrated. So if you're just a developer of an AI solution or you buy an AI solution, You just kind of get shepherded through the process. You get shepherded through being able to adhere to all the different steps that are pertinent in the policy to what you're trying to do with your AI solution. So a lot of what we do is help to translate the policy into something that is usable, actionable, and obviously scalable around that policy, set of policies and procedures throughout the overall enterprise.

3:58Kevin Werbach: How automated is that? Yeah, we try to automate as much as possible, right? Obviously, we can't automate everything. And the purpose of governance and the risk teams and the control partners is really to have effective challenge. So we never want to get rid of the actual effective challenge that's done by the different humans involved, right? From legal risk compliance, governance risk, et cetera. But we try to automate all of the really just the mundane routine tasks. Things as simple as, you know, we do need to analyze what data is being used. And are there any potential PII, PHI in there? You know, a lot of times that is done manually, right?

4:39Another example is that you want to do a risk tiering. Very simple concept, but a lot of that's still done with an Excel spreadsheet. You go fill it out and this Excel macro kicks something out that says, oh, this is a high risk or this is unacceptable use in EU terms. So on average, to answer your question, it's for the lower priority or sorry, lower risk, maybe medium risk. You can actually automate between 60 and 90 percent of that process. For the high risk ones, that's where you do want to take a little bit of extra time, as you well know, to have humans go and take a very in-depth review, do their effective challenge around it, identify where there's potential findings or validations, conclusions in the banking world, etc.

5:19But so that one is probably a little bit lower percentage. But like I said, the low risk ones are one that we're coming up quite a bit around, Kevin, the concept that we call just pre-approved patterns, especially in the Gen AI and agentic world. If there are, at the end of the day, that people are just creating chatbots, right? And so there are certain patterns that you've identified that say, okay, well, we know this pattern. We don't need to redo the whole risk analysis around it because 90 % is the same as the last one, right? So that's where we get some real, very nice savings, time savings, accelerations, because we say, you know what, 90 % of this is the same.

5:58We've got all the evidence and we've got all the reviews. Everything's already been done with that. So we can just focus on the 10%. So, again, that's just an area where you actually can help to streamline and automate a lot more than you would think through the use of technology like ours.

6:12Kevin Werbach: But presumably, as you said, companies have different policies, especially if we're talking about large enterprises. And certainly some of it is industry based. How do you help them decide what are those patterns that for them they can automate? Yeah. So first off, absolutely. On every single enterprise has a slightly different policy and sometimes drastically different. and you know just in general that's why we really from our company perspective only focus on the fortune 500 global 2000 is because we really designed it so that every company can make slight tweaks that can configure and tailor to their specific policies and procedures as they put forward so that's that on the first bit i completely agree with you and that's why we've designed it as such and then on the second one what you said of well how do i then take the learnings of let's say one customer to the next when they do have a different policy in general Well, that's where you do start to see some repeatable patterns, believe it or not, right?

7:08That all comes down to the usages. What are the target usages? What data do they have access to? What other tools in the agentic world do the tools they have access to? Is this internal versus customer facing? So there are a number of core questions or inputs that can help to determine what those patterns look like.

7:26Kevin Werbach: Even if it's you're looking at a bank versus wealth management, if you will. They get repeats that are fundamental to determining things like the risk rating and how we want to handle it from an ongoing process perspective. So let's just drill down a little bit more. You talked about the lower risk tiers where it's possible to have a lot of auto approval. Are there consistent factors that would put something in that bucket? Or does that have to be a bespoke process each time to say what's at a low tier for your organization? Yeah, so two parts of that. So in terms of the tiering, that is something that's often very well defined, especially for the regulated industry.

8:06So the initial risk tiering itself is something that is, again, well defined, very easy to help to automate based on the inputs, if you will. And the second part of that is then you can further do, like I said, those pre-approved patterns after the risk tiering is done. So let's just say that the risk tier kind of kicks it out as a low risk, if you will. And then you can look at a number to your question of factors. And those factors often come involved of, OK, is this a pre-approved LLM? So oftentimes that's, you know, the core team technology and risk and governance teams will go and kind of validate and approve an LLM version in particular to say, yep, we've looked through this one.

8:45We've reviewed it. We've done all the tasks. We've done all the testing. We've done all the due diligence. And so they'll list this as approved for production usage.

8:52Kevin Werbach: Okay, great. So if you are now developing a chatbot or an agent that's using that pre-approved LLM, that naturally says, all right, that's one item we can check to say, yep, we're into that pre-approved bucket. Another one, obviously very common, is this internal versus external. Internal, it obviously has a lot less risk potentially around it. So that's another one that you can look at. And then another one is also if you are connecting to different data sources, especially the corporate data sources around it. If it's something that you're really not connecting in and pulling in other corporate data, if you will, again, that's something that you can generally say, all right, well, we're limiting our exposure because we're not going to feed it any potentially sensitive data, whether or not that data source has sensitive data, it still limits your exposure around it.

9:37So those are kind of just a couple of examples. And, you know, each company is actually refining this as they go, right? So they'll get a new, you know, a new Gen AI agent that comes through the pipe and they say, oh, wait a second.

9:49Kevin Werbach: Yeah, this looks the same as this and this, but these two new things came in the door. But I think we can see that one of those two items, we'll see a lot again. So then they'll go and approve that and have that as part of that kind of pre-approved pattern, if you will, put that into the cycle, et cetera. So it's a learning piece as well from the overall kind of execution protocol from the different governance teams. All right. So at the bottom, there's things that get pre-approved. Presumably, there's some things that are absolutely prohibited at the top. What are the middle tiers look like? And what's the functionality that you help provide to organizations to go through the necessary processes?

10:26The middle tiers is where you get into just making sure that, well, first and foremost, you're following all the steps in the corporate policy. So this is where part of what we do is we're mainly focused on workflow automation and automation of those processes, right? So this is where the integrations come into play a lot. So integrating with your security scanning capabilities, integrating with, say, your data profiling, data integrity type capabilities to make sure that, yep, security scan came back clean, data profile came back, and indeed it does not have any PII. AI and then pulling in, excuse me, other corporate policies, like looking at if it's a third party AI, pulling in the T's and C's that might come from a procurement system.

11:03Hey, do we have the T's and C's as legal signed off on them? Terms of condition. Right. So those are the types of things. And then you move on to testing, right? So for the kind of that middle tranche, you can have a set of tests. It's not going to cover every use case specific nuance from a testing perspective, but there are some baseline tests that you can take a look at that again if you said hey there's no PII let's go and check right let's go and test and make sure there isn't any PII coming in or out of it you can look at things such as hey we said that this is going to be you know a chatbot and that this chat bot we wouldn't expect it to be overly negative let's go do run a sentiment analysis and determine hey is this coming back overly negative we would not want that for even if it was an internal chat if you will.

11:46So there is a set of tests that then you can run and help to automate as much of those as possible, looking at deviations from what was requested, as well as kind of the accepted norms

11:57Kevin Werbach: and risk tolerances that you have around some of those tests, if you will. So that's kind of what happens in that middle trance of just let's try to, again, run all the different scans and the tests, help to prepare some documentation so that the reviewers can then take a look. It's like, All right, well, here's a summary. Yep, it passed security scan. Yep, it passed the data integrity. Here's the tests that run. Here's the results of those tests. Here's where it actually failed a threshold. So you kind of just prepare a package, right? You prepare a package for the different reviewers, whether it's legal or the risk team or the technology team.

12:28And so in that way, you're trying to streamline the process. You're pulling in the right teams at the right time to try to, again, ease that process as much as possible.

12:37Kevin Werbach: Who are you typically selling to in these organizations? Yeah. So we're typically selling to, at the end of the day, the person or persons that are accountable for AI, right? That are accountable for what's happening. Accountable for accountable AI. Yes. So the person, and I say it because that role is different within each environment, within each, sorry, enterprise. It could be a chief AI officer if they have one, a chief data analytics officer. It could be a CIO in certain cases as well. They are the ones that are accountable to the executive C-suite around the use of AI. But ultimately, that's the main person to ensure that we can actually safely scale AI out to all the different teams.

13:21That's obviously the end goal for these large enterprises. Let's get AI into the hands of everyone to help to improve various aspects of the business. But they can't do that until they know that they got the foundation in place. They know that if John over in accounting has an AI idea and wants to use Copilot Studio, that it's going to go through the process. It's going to go through that engine that says, all right, we check, check, check, check, check. Came out, everything looks green. Now we can use it. That's really hard to do at the enterprise when you've got accounting that's not very technology or risk knowledgeable, if you will.

13:56No offense to them. Versus somebody that is potentially part of the data science team, super technical and pushing the bounds of it. But they're not experts.

14:03Kevin Werbach: They're not subject matter experts in risk and policy, right? So how do you make sure that all the different teams, technical, non-technical, are able to effectively go from idea to usage in a way that's scalable and also, of course, responsible back to the organization that we're following those corporate policies? How do you do that? Yeah. That's the reason we exist, to be quite honest, overall, Kevin. So we do that with a couple of key pieces. First and foremost is that we do have a very comprehensive system of record. We call it an inventory, obviously, just so you know, every single AI out there, that could be AI, could be ML, could be regressions, could be vendor.

14:44It doesn't matter to us. We took a lot of time to design. How do we make sure we encompass and be able to track every single AI system? Of course, with that, we have a discovery capability to help organizations go and find what's out there. But then the real secret sauce from there is what we call our model up AI delivery engine, our MAID. And that's what takes, as we started the conversation, those policies and turns those into enforceable workflows so that you can, it doesn't matter if you've got 40 different flavors of how you need to do the different steps in the process, but you have the ability to go and say, all right, if an idea comes in, here's the workflow that must be followed.

15:25those workflows will pull in the right people and the right systems at the right time to make sure every check is done, every tick in the box, every analysis, any evidence that needs to be captured, all of the, as I said, the risk tiering, the automated testing, the triggering of security scan, all of that is check. And really the powerful part about it and the most important part is that there's actually not one process to rule them all, right? There's actually a variety of different processes. It's based on risk, like we talked about, high risk versus low risk. High risk has a lot more involved versus a low risk.

15:58There's also different processes for, say, customer-facing versus internal or external, third-party purchase SaaS-based AI versus internal, as well as in target environment. Is it going to be running within our network or is it running within a partner network or maybe it's in a cloud? So there's a variety of different processes. And that's what, again, we took a lot of time to say for the Fortune 500, we have to accommodate all those different scenarios. And so what happens is to, again, back to your original question, we take their policies with all those variations, right, to 30, 31 flavors, right, and then can turn those into actionable workflows that are really AI and model context aware to know, okay, it's high risk, go down this path, and then make sure every step is followed.

16:45it's low risk, go down this path. Oh, it's low risk and it's cloud-based. Okay, well, we know what to do here. So it's that kind of delivery engine is what we call it that turns that, again, very manual paper-based policy that often spreadsheets, emails, super ad hoc into something that is scalable, repeatable, consistent, and of course, auditable and traceable to make sure, you know, no stone is untired, if you will.

17:08Kevin Werbach: And just to drill down a little more in where you started, the system of record. It makes sense. Seems obvious that you need to know what AI you have if you're going to govern it. But we're talking about large enterprises, all kinds of things going on, shadow AI, people bringing things in, third party. What are the big challenges and the keys to building that foundation effectively? Yeah, I think the first one is just making sure that you have a system of record, to be honest. But then from there, it's then making sure that you can tap into the various sources, that you can discover where those AI, shadow AI, and other components are.

17:50So that means that you can tap into the procurement system. So for some reason, they purchased some SaaS-based AI that they didn't report back to the governance team. God forbid, hopefully they don't, but being able to tap into the different accounts. So you think about your Azure, your Google, your AWS accounts to make sure you can go and scan, hey, out in agent core right now, I see 10 agents, five of them are registered, five or not, right? You know, being able to tap into your co-pilot studio, your agent 365 on the Microsoft side, et cetera. But then also being able to tap into at the network level, which so going way down in the stack, right, to determine, OK, well, we look like we actually detected some MCP traffic, if you will.

18:32The common security thing to do is just block it. You don't know it. You block it. Right. Which is what they should do. Right. But then from there, you want to say, all right, we detected this traffic. Maybe we do want to put this in the queue to get approved. Right. So that, again, you're kind of taking at multiple levels at the network level, the kind of account level for cloud and other type of platforms, if you will, as well as maybe even tapping into the procurement system. So now I make it sound easy, but as you can appreciate in a large enterprise, there's some red tape involved in that.

19:01But that's the way that you get into kind of full scope and understanding of here's all the different places AI might be used.

19:08Kevin Werbach: What do you see about the organizations that are more effective in implementing AI governance versus the ones that struggle? Yeah. So I think the first is just top-down support. And I know that sounds so fundamental. And so I hate that. That's like what a first-grade answer would say. But it is so true because there's so much focus. There's a lot of different leaders or different technologists that are kind of chasing the latest and greatest technology. technology and so there's a lot of emphasis and a lot of focus on let's just go and find the best llm right let's go and build some bunch of agents and so that's kind of the unfortunately gets too much attention from leadership and then you forget okay well that's not going to be effective if we can't get any of them over the line it's not going to be effective i you need to make sure that you have the right governance and as i like to say governance can actually be an accelerator doesn't have to be the brakes so it's it's first is the top down to say we're going to do this we're going going to build these different AI solutions, but we're going to do so in a way that has governance embedded in about how we do delivery.

20:12You can't have one without the other. And so that for me, that's the first one, but ones that do the best at the top down support. And then obviously the different program teams underneath it to have that tight interlock between AI development, delivery and governance overall. So that's number one. The second is, I'll just say really is kind kind of a lesson learned from enterprises out there is that you can't just use your traditional approaches to governance. Kind of you think your traditional GRC type approaches, which were designed for a whole bunch of corporate reasons, right? So you could, you know, there's physical, there's access to the location itself, right?

20:49There's a whole bunch of policies, but AI is its own beast, right? It's constantly changing. It's related to data. It's a unique combination of software, data, risk that's inherent because it's not deterministic, right? So trying to take what has been done in the past and apply it to AI just leads to a lot of slowdowns, a lot of failures on the delivery side, if you will. So, again, the best ones think about, OK, this is fundamentally distinct from what we've done in the past from a governance perspective. And second, it's fundamentally distinct from the development and execution side of the house, as well as distinct from security.

21:27And I'm sure you all have questions and we can get onto that. Right. But these are different disciplines, right? You develop and your student cannot grade their own papers, right? So developers cannot grade their own papers, right? So governance and development are distinct. Security is focused in a different area, if you will. So again, back to your original question, it's a recognition that these are distinct disciplines that are interrelated and need to work together, but they need to be there, you know, again, in a distinct basis overall.

21:54Kevin Werbach: You made the argument that governance is actually an accelerator, and I've made this argument as well. And I've had conversations like this with a number of guests. And so I believe that's true, but I'm really curious in practice, how do you make that case and where do you see evidence in companies that that can actually happen? Sure. So just based on what we've done with our customers over the many years, before walking into our customers, we did some analysis and the different governance and risk activities generally were causing anywhere between 40 and 70 % of the delays. What I've talked about from the beginning, the idea to actual production usage.

22:29That's a pretty big range. So if you think about, hey, you've got this pent up business demand for this AI solution that's going to deliver X dollars in benefit. And the governance tasks are the things that are slowing it down to the point where in some of our customers before us, it would take them between nine and 12 months to get an AI or ML solution out the door. By the time you get it out the door, it is deprecated, right? You know, it is fundamentally not going to provide the business value that you would expect overall. So that's where we start is just saying, OK, let's look at where it is today.

23:01And Kevin, to your original question, a lot of it is the manual processes that ad hoc cycles that are involved. You know, you're a developer and you develop something wonderful. And then you go and you say, all right, I'm ready to push a button. Let's get a tiny little ploy. It's like, whoa, whoa, whoa, whoa. Did you talk to Johnny? Oh, wait, no. Johnny says you're using, you know, a PII data. Now you get to talk to Jay and Jay says, oh, no, you got to talk to legal. So then you get this run around and you're just kind of a ping pong nature of going out to the different teams. And nobody has that fundamentally understanding.

23:30They don't have the blueprint at the end of the day of how do you go from idea to production. It's a constant. You got to go and figure it out yourself, read the policy document, et cetera. So that's the way that we help to become an accelerator. I'll go back to that case of before we came in as a large financial. is between nine and 12 months to get an AI and even an ML solution out the door. And that was because, as I said, there was just not a cohesive collaboration across the teams. There wasn't a documented process across here's the different steps involved. Here's the different teams involved, the different approvals, the evidence, et cetera.

24:05And so we, with our product overall, but first and foremost laid down, here's the blueprint. Here's the playbook, right? Here's the playbook across all the different teams, the different flavors, the different plays that use a football analogy, you've got your playbook and you've got a bunch of different plays. Those plays, as I said, high risk play versus low risk, right? You know, cloud versus internal. So you develop that playbook and then obviously model up is great about taking that playbook and enforcing it, using it with automation, putting those processes as live orchestrations, et cetera.

24:31So in that way, we took that nine to 12 and reduced that to under three months. And that was purely because they had the repeatable playbook. They had the streamlined understanding of who needed to be doing different approvals, reviews, testing, et cetera, and orchestrating as much of that as possible via automations and integrations. So that's like, again, why both you and I agree that it can be an accelerator as it's proven through some of our case studies with our customers thus far.

25:00Kevin Werbach: Speed to market is one way companies can think about how effective they are with AI governance, which you've talked about. What are the other ways that that managers in these enterprises are able to evaluate how they're doing. Yeah. So I think the, there's a couple of ways speed to market, obviously from a business perspective, the second is that the demand for AI, especially with Gen AI and now at Gentic off the charts. And I'm sure you've talked about this with some of your guests before. So if you think about it from the, I'll just say control partner perspective, the legal risk, compliance, governance, et cetera, they're staring down at gauntlet.

25:37Oh my gosh. We're going to have to go and review, you know, a thousand, right? Or we have one customer that's, you know, in the many, many thousands of different AI solutions. So they're sharing on this gauntlet. What do I do? Like, there's a way I can keep pace with this. So the second reason is actually they're faced with two choices. I go and scale up and have a massive team to handle this demand. Or I turn to, you know, software that can help us to keep pace with this demand. So, yes, time to market. But second is, can we have that pace of innovation without massively increasing the cost, the human cost, the human headcount from that, again, control partner perspective?

26:18So that's a second reason to do, you know, have an effective, responsible, accountable AI program. And then the third, of course, is just why it exists in the first place and protect the organization. Right. So protecting the organization from, you know, undue risk from potential brand exposure. Hopefully it never happens. Obviously, any audit or regulatory concerns. But at the end of the day, you just want to protect the organization from something going wrong. It will go wrong. But how do you protect it from catastrophic wrong, if you will?

26:48Kevin Werbach: Yeah, but how do executives assess that? Because if the catastrophic wrong hasn't happened, then you're proving a negative. And clearly legal and compliance matters a lot, but there are all these gray areas. And, you know, we've got the EUA, IAC, and we've got, you know, GDPR and different data protection requirements. And those, at least, it's concrete what the obligations are. But there's still a lot of these areas where, for most of these organizations, there's not a definitive legal mandate or regulatory mandate they have to follow. How should they think about how far to go? Yeah. So, again, first off, we always hope they do the right thing and protect the organization.

27:26Kevin Werbach: And many leaders will do that. Second, that their AI will go wrong. And there's plenty of examples out there that you've seen where I think one of the first ones was that a chat bot, you know, responded to an airline passenger and said, oh, yeah, sure, that's fine. You can get the grievance rate for, you know, the funeral you have to go to. So there's actually a financial implication should AI go wrong around it. But then third, I would say of why, again, really a catalyst to take this seriously is actually the spend, believe it or not. So the spend that is starting to come about because of just the token maxing and just in general, the variable nature of how the different frontier lab providers are doing this and changing kind of their variable rates.

28:14The spend is growing quite significant, right? So it's not just a regulatory bit. It's also a financial and operational governance, if you will. So you can, in a way, if you have the proper governance in place, you're not just looking at, did I, as I said, do all the reviews, approvals, regulatory, compliance, et cetera, but you're looking at what's it costing us? What's the value we're getting out of it? Does this make sense? Right?

28:39Kevin Werbach: And so having that level of financial due diligence just to add that, again, fiduciary duty back to your company doesn't even make sense to continue on with this AI solution because the cost is X, value, TBD, right? So in that way, it is something that I'm seeing. I'm sure you've heard, Kevin, with some of your conversations and what you're seeing. That is a catalyze. It's a big catalyst to say, all right, it's time to rein it in. Let's get a little bit of control around this wild west of AI, just purely from a fiduciary perspective. And then how much does the rise of Agendic AI change what you do?

29:20Kevin Werbach: It's been exciting, Kevin. From our perspective, it's been super exciting. It doesn't change our technology because we designed our technology from the very beginning to be able to support all types of AI, both now and in the future. So when LLMs came out, we added it overnight because we just designed our technology. So it hasn't changed our technology. What has changed and again why it's exciting is because agentic AI really has been the catalyst that's pushed over the edge. These enterprises said, nah, you know what, we can just get by with what we have with our responsible AI program. Yeah, we can just continue on with SharePoint and spreadsheets.

29:55That doesn't work with agentic AI. There's too many. It's too much. there's too much that could go wrong because now the agents can make decisions on behalf instead of just informing employees of what decisions could be made but they're making decisions on it which could have real actions and even if they say well i don't want it to make decisions there's still the opportunity there's still the chance that the agent does it anyway right which we've seen all those stories of out in the wild about different agents that have gone rogue and even despite the directions not to go rogue, right? So for us, it's changed in that, as I said, agents are in such high demand from the different business teams that it has, as I said, pushed over the edge to say, you know what, we need to fundamentally do something different here.

30:40We need to have this as a comprehensive program and not just an afterthought.

30:46Kevin Werbach: And we're almost out of time. So how can agents, though, be effectively governed? I understand we're talking in the enterprise. we're not talking about, you know, unreleased frontier models in testing at the labs, but there is still this problem that, you know, we have this alignment issue where you can tell the agent something, but it may still do something else. Yeah. So there's a couple levels, as you probably well know from a control perspective, the first thing on the controls is just limiting the usage and making, well, first defining the usage and then defining what are the limits of that usage so that you have an understanding, okay, hey, this agent is designed to do this.

31:20Here's the autonomy that we want to give it or not give it. Here's the limits of that autonomy. Here's where we need human in the loop, et cetera. And then making sure that, again, those limits and usages are part of how the agentic system is designed. Then second, you'll go down a level to more of the system level controls, and you get into place and making sure that especially the tool and data and system access is well understood and that there are appropriate low level controls in place to limit it to only those tools, data, and systems that you have defined that are possible. And that's where you need to get down into the execution and potentially even the network layer because you're defining, hey, we don't want it to reach out to the internet.

32:04We don't want to reach out to NCP servers, et cetera. So multiple levels, as you can appreciate, Kevin, from, again, the limits and here's the usages down to the platform level of here's type of access and integrations that are allowed. And then all the way down to the network level of, okay, now let's enforce that, especially for don't let it outside this network, right? If the network level is saying, nope, can't get out there, then it can't do anything. So all of those kind of examples in the wild that we see wouldn't be possible if the appropriate network level controls are in place around it.

32:35So again, multilayer. Got it.

32:37Kevin Werbach: All right. Well, as you say, it is an incredibly exciting time and I am glad to have the opportunity to talk with you about what you're doing at Model Up. Thanks a lot, Dave. Yeah. Thank you so much, Kevin. This has been the Road to Accountable AI. If you like what you're hearing, please give us a good review and check out my substack for more insights on AI accountability. Thank you for listening.

33:01Kevin Werbach: If you wanna go deeper on AI governance, trust, and responsibility with me and other distinguished faculty of the world's top business school, sign up for the next cohort of Wharton's Strategies for Accountable AI Online Executive Education Program, featuring live interaction with faculty, expert interviews, and custom-designed asynchronous content. Join fellow business leaders to learn valuable skills you can put to work in your organization. Visit execed.warden.upenn.edu slash ACAI for full details.