Zum Hauptinhalt wechseln

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice

PegaWorld | 48:46

PegaWorld 2026: Moving Fast Without Losing Control: The New Rules of Governing Agentic Workflows

Agentic workflows are redefining how enterprises design, govern, and scale automation. Traditional governance models, built for static, deterministic processes, struggle to keep pace with systems that are goal‑driven, adaptive, and continuously evolving. This session explores why agentic workflows break conventional automation governance, and how organizations must shift from governing designs and approvals to governing behavior, constraints, and outcomes. Panelists will discuss the emerging operating model that enables speed, trust, and accountability through runtime guardrails, observability, and shared ownership, allowing enterprises to move fast without losing control.

Thank you, everybody, for coming today. Uh, my name is Paul Barnes. I'm going to be the moderator here. I'm a senior director of business excellence and responsible for adoption strategy. And my team particularly focuses on Agentic AI adoption strategy. And we run our lighthouse program at Pega. So, um, let me start with a question just to kind of frame what we're, we're going to be talking about to hear I'm talking about here today. I suspect a question many of you have wrestled with, and that is, how do you give agents real authority in your organizations and enough autonomy that they're actually able to move the needle without you losing control of them, losing transparency or accountability as you're going through it? And that tension is exactly what this session is all about, moving fast and adopting agentic functionality without losing control, and we are at a genuine inflection point in enterprise automation and AI systems don't just respond prompts, but they set goals, they make decisions, they take actions, and they do these things across your work.

It's no longer just a research experiment. A year ago, 95% of organizations were, you know, in full on experimentation stage. And it feels like that has just flipped overnight where it's no longer when or, or how, but, you know, specifically, what are you going to be doing next and how are you going to make it successful? So at Pega, we've been building towards this moment for years. We think that this is our time to shine, because we have the opportunity to approach this in a fundamentally different way, and that is that our architecture allows us to use creative AI at design time to build your to build your solutions. Reimagining with Blueprint. It allows you to leverage agents to build applications at enterprise scale using AI assisted engineering tools like cloud code, plugging into our MCP. And you can also now run your your Pega Agents workflow on any cloud.

And honestly with any agent as well. And it's all done through Pega's AI, autonomous enterprise architecture stack. So really a unique, um, you know, a unique offering that we have that we're bringing to the table this week with Pega Infinity 26. We're taking that vision further still. And the idea of re-imagined build and run is at the heart of our strategy. So the honest truth, though, is that the product, the platform is only half the answer, and the other half is the operating model, the ownership structures, the runtime guardrails that we put in place, the metrics and the cultural shifts that make trusted agent take AI possible in practice. And that's what today's panelists are going to be talking about. So I'm joined here today by three leaders who have been doing this work in the real in the real world, in highly regulated industries under real pressure.

And they're going to share exactly what's happening, happened, or will be happening in their organizations. It's not a roadmap. It's not aspirational, but it's real experiences of understanding how to govern a genetic systems at scale and real lessons that they've encountered along the way. So along those lines, let me introduce Mamadou Seck. He's the VP of AI engineering at Navy Federal Credit Union, which is the world's largest credit union. He's been on the front lines of governing a sprawling Agentic AI estate across highly regulated businesses. And he brings us Platform and architecture perspective today. Mamadou, welcome. Thank you. Uh, Peter, at the far end there. Peter la Croix is manager of platforms and integration at Achmea, one of the Netherlands largest insurance groups. And he has lived the tension between enabling fast moving decentralized teams and maintaining guardrails of a regulated financial services environment. And he'll bring governance and Platform perspective.

Peter, great to have you here. Thank you. Uh and lastly Shawna Maitia Seana comes from Blue Shield of California. And she's going to ground this conversation in what governance looks like on the contact center floor where regulations are changing. And humans have to keep up with it. Thinking about the empathetic aspect of these solutions and thinking about how AI has to make people better at their jobs without replacing their judgment. Seana. Welcome. Thank you. Okay we're going to jump straight into our questions once I get to the right page here. Okay so the first question I've got here um is uh, what was the first moment you realized traditional Workflow Automation, uh, or workflow governance would not scale to AI or agentic systems? Peter, we'll start with you. Yeah, I will start, um, if you visited the keynotes, you listened to Nick of a MetLife explain what had happened to him when the business started experimenting with AI exactly the same thing happened at Achmea.

What we noticed was that our business started experimenting with AI outside the centralized guardrails we put in for our traditional IT development. So what happened was an explosion of of ideas, use cases, proof of concept. The business wanted to, to, to start, um, but they wanted to start it without the centralized governance. We were just in their eyes, too slow to keep up with the pace the agents were building. Um, but that is, that is not, not an option. We can't. We, um. What? What? Our traditional IT. Did the agents that were built. Um, we want to put our old governance structure in it. So we want to do guardrails. We want to do code reviews. We wanted to put them in sprint cycles. We wanted to to have peer reviews. And all of that just was too slow for them to, to accept that it was working that way.

So we needed to think of a way to get them into a mode where they can do their job. But we are, we are, we know that the agents will be, be, be, uh, secure and won't do anything risky or with data access restrictions that are not allowed. And that that moment, the tension between our traditional governance on IT applications and the expectations of the business with those agents and the pace they wanted to live at, that agents made us to rethink that, we need to help our customers, our divisions, do their work in a more autonomous way without being hammered on all those agents that they wanted to build, because all those use cases were enormously valuable to our stakeholders, to our insurers, to our employees. And that's when we started thinking that, well, we need to build guardrails into the platform and let them work within that platform as long as they stick to the guardrails we defined.

So the first moment for me, Paul, was the tension between traditional IT governance and the governance that our business expects in the pace of keeping up with all those agents and all those ideas they wanted to execute to make work better. Awesome. Yep. Seana what do you think. So from my perspective the call center frontline staff uh their work continues to get more complicated. Um Regulations make things more complex, and we provided them with 20 plus different applications. Just to answer one question, not to mention scrolling through dozens of knowledge to try to find an answer, which it's not. That's not scalable and it causes fatigue and burnout. And so that's when, you know, reality set in. We need to make some changes. I think Covid duration really highlighted this need. Not only were they struggling with systems and documentation, but now they're also struggling with working from home.

Everything was so new for them. So that's when it became very clear something needed to change and quickly. Mamadou, what do you think? Yeah, similar to, uh, both your answers. I think the first moment I realized that traditional governance wouldn't work in the agentic AI world is when you just look at the number of agents that get created on a day to day basis in organizations. Um, you know, at Navy Federal, I would say we are at the start of our agentic AI journey, but if you look at the number of agents that are tracked, you will find hundreds, if not thousands of agents already. Traditional workflows used to be very much aligned either with products or customer journeys. Agents are tiny units of behavior that proliferate very fast, and they exist on a number of different platforms. And, um, you know, just this agentic sprawl and the lack of centralized control of what they can do and what they can access is what makes traditional governance ineffective to handle the risk that comes with agentic AI, I think.

Yeah. Yeah. So I think kind of summarizing across you three that you can design an agent to do anything. The repercussions of it and execution are, you know, it's really hard to get a handle on from a security perspective, perspective, from a centralization perspective, from a human impact perspective. So there's all sorts of execution style, additional factors that you need to, to pull into it as you're thinking about it. So, um, on that riff, where do traditional controls like approvals, static static rules determine? I can't speak deterministic testing first fall apart when workflows start to become adaptive. And Shawna, can we start with you on this one? So traditional controls in our call center assume agents are always going to find the answer, interpret it, find the document, interpret it, and be able to answer the question immediately. And in reality, that's when things start breaking because they're under the gun.

They got to get to the next call. Um, and so that's when things start falling apart. Peter. Yeah. I've gotten a very good example, which we are in a long debate at Achmea. Um, we are heavily regulated within the European Union, but also within the Netherlands. We are highly regulated by, by our, by our, uh, compliancy auditors. Um, every month we have to comply. We have to prove to our auditors that we are in control over our platforms. Achmea has 34 platforms. And every time we have to prove on paper that we were in control, that our platforms are up to date with security baseline, with security patches, with the latest versions, and we have to do it on paper, point in time, print screens delivered on paper to the auditors, and they control what we delivered on paper. And when we started, we started practicing at centralized IT with with agents ourselves.

So we built an agent that instantly always controls that. The baseline of Pega, for example, is exactly the baseline that we have at, at Achmea at our private cloud solution. So we are instantly in control. We can show to our auditors what the state of our platforms is. It goes bye bye. Traffic lights green. We're in control. Orange. We have to do something. But not not that necessary yet. Or red. There is a serious CV, CVS error or that the platform needs to be fixed always. Instantly. The agent checks continuously what the state of the platform is. So we go into conversations with our auditors. And why do you still want it on paper? Why do you want a quarterly report? If you can just come over, we show you the dashboards, we'll tell you what the agent is doing. We'll tell you how we arrange the observability of the agent and just have a discussion that this is much better than a point in time solution.

And then that's still the discussion at Achmea that governance shifts from point in time paper solutions, checking if we if we are in control to an always on observability observed observed Platform, that proves via agents that it is control. And that's an example that that's still in the discussion, because we are maybe old fashioned, where auditors are also old fashioned. They just want it on paper. We will not check your dashboard. We want it on paper. And that needs to shift. We need to rethink the way we do that. Very good. Yeah, I think this is a great question. Um, so traditional governance I think is, is based on the idea of determinism, uh, meaning that a business process goes through a sequence of well recognized steps. Each step has its own inputs and outputs. And you can test for these activities and for edge cases and gain confidence that the process will be executed according to the design.

When you go to an agentic view of reality, um, each agent is responsible for a subset of these activities. And these agents can get, uh, connected in an infinite number of ways at runtime, meaning that governance that used to happen at design time now has to move at runtime. And I think that's the main challenge, meaning that governance is not just procedures that you put in place and people adhere to. It has to be something that has to be now implemented as code through observability, detecting signals and, uh, maybe even implementing kill switches so that you could stop agents from engaging in certain behaviors. Uh, if you sense that this could lead to, uh, failure of compliance. So I think that's the switch of paradigm going from determinism to non-determinism and discovering behavior at runtime, which is, uh, which I think is the biggest challenge.

Yeah. And I think, um, you know, leading into the next question there. So if you can't pre-approve every decision, what can you govern? And where do you draw the line between autonomy and control in that governance model? Um, Peter we'll head it back to you for this one. Yeah. Um, I explained that we were confronted with an explosion of ideas by our business, and our pace was too slow. We need to think how we can support our businesses, deploy those agents. Um, I explained that we arranged an always on instantly, uh, managed control over the environment via the agents that, uh, check the baselines from our platforms to the baselines we have implemented. And so we took care of that. And then we started to think about, uh, what do we do for the, for our development teams to make sure they can work within, within the platform.

So how can we make sure that they can, they can do the work. And, um, and we came up with the thought that, well, let's not manage all the agents, let's manage the context and the platform and the patterns that they behave in. So we needed to manage the platform. We implemented observability. All the agents that work on the platform are continuously monitored and not only on the individual decisions, but also on patterns, on risk, on security baselines, on exceptions, on, on, on, on the platform. And the agents that were working on. We were, we are monitoring the platform. So we divided observability. The observability of the platform is implemented. Once that is done, you can start thinking about guardrails. And those guardrails are non-negotiable. Our development teams have to comply to the non-negotiable guardrails that run on that platform. And those non-negotiable, non-negotiable guardrails are about data access restrictions.

There are security restrictions. And very, very important. We explain for every platform to, to, to the development teams what the agents are not allowed to do. We don't tell them what they are allowed to do. We tell them what they are not allowed to do. And that's mostly about external communication. A claims, calls, data restrictions. We have a health department with very secure data. That's where the human steps in the agent can never make its own decision, and every team has to comply to those non-negotiable guardrails. That's that's what we agreed upon. And then if something happens, if an agent is built that that breaks that guardrails accidentally or accidentally, it will be taken out by that observer observability and the agent will be flagged. And then when the agent doesn't get shut down, we get into a conversation with the build team, explain what the agent has done and what the observed observability has seen, and they get a chance to fix the agent and to make sure that it works within the guardrails again.

And if we all comply to that, they have a platform where they know where they can act, they have the rules, where they know they have to be within the boundaries, and then they are stay within the governance and they can move very fast, developing that agent within the platform with all the agreements we made with them, you see. And what we see is that that is a perfectly working mode for Achmea to work in. We can all do the things, and I know they're supported by guardrails and observability. Yeah. Yeah. I think the explicit constraints perspective that you set around PII, having the observability and traceability for that so that you can understand whether it's guardrails is. So we moved from controlling individual decisions to monitoring the platform and things that happen in the platform. Seana so as we look to implement AI in the call center, one of the things that we will have to do is we will have to keep an agent in the loop so that if something is wrong the agent can fix it.

For instance, call summarization. If. If an agent is seeing something not captured right, they're going to have the ability to make the tweak. And then there's an audit trail of it. We'll be able to learn from that data and make the necessary corrections to the agent. So we're not looking to governance. We're not governance isn't about blocking any automation or AI. It's more about having that traceability so that you can make that continuous improvement. Mamadou Seck. Yeah. What this question actually raises for me is the fine balance that you have to find when you design the human in the loop in agentic applications. You could find yourself in a situation where every Agentic decision is forwarded to the human for approval. Then when you do that, you've just displaced the workload and the human ends up rubber stamping agentic decisions without any additional compliance being achieved by that.

Or, you know, you could automate a lot and then you expose yourself to risk. I think one of the biggest challenges in our industry is to think about how to design human in the loop properly, where, you know, you can measure the risk of decisions that agents take and then sort of triage those risks in such a way that some of it is totally fine for the agent to execute automatically. Some of it definitely has to go to the human, and some of it maybe can be treated on a spot basis and escalated depending on, uh, maybe something that an LLM as a judge would detect as being potentially more risky. So, um, so as we move forward in this agentic journey, uh, I think the big challenge is not really a technical challenge. These LMS will keep improving. The big challenge is figuring out how do we manage the interaction between agentic autonomy and human responsibility.

Uh, so that we don't just exaggerate in one or the other way, uh, because we're not implementing these very expensive solutions for the human to rubber stamp everything. So I think that's where we're still trying to figure it out. Yeah. I think that spectrum of, you know, human in the loop on everything to really full autonomy is so nuanced. Um, and when we were talking about this a couple of weeks ago, there were, I think three questions, if I can bring those up. You suggested teams think through. One of them was around competency. The second was around authority and the third was around responsibility. Could you talk a little bit about that? That's right. So competency is really about, you know, any time you implement an agentic process, you know, the core process, the core business process that you're executing, do you trust statistically that the agent can execute this maybe 99.99% of the time correctly?

Right. That's a competency question. The second question is an authority question, right? So somebody can be competent to do something without having the authority to act. And then the third layer is the layer of responsibility for every action that is taken in an organization. There has to be a human who will take the fall when that action is audited, right? And it doesn't matter whether the agent is capable or not. Right? So when we are in these processes of designing agentic applications, part of the controls we try to put in place is analyzing each of the decision points and figuring out, okay, can we test on competency? Can we figure out, do we want to really give authority to an agent to act on behalf of the human? And then who's responsible? Who's the executive in the organization, who is responsible and who will be, uh, basically on the hook if we get audited and we find out that this agent engaged in this action and by connecting this and, you know, decoupling it from the technology itself and making it, uh, you know, a socio technical decision, you're able now to, to, to have the right people around the table and decide whether this is actually something okay to automate or not.

So coming up with a framework, Uh, I think, uh, Agentic AI is advancing faster on the technology side than on the organizational awareness of how do we, how do we actually make this work? Right? So, uh, it's upon all of us to sort of try to come up with these frameworks that engage the business more broadly beyond it, uh, to figure out how, how, uh. You look to be a green vehemently with that. Peter. Absolutely. Something to it. Yeah. Um, so I guess the next question that we have here is around making it work in the real world and trust intervention and outcomes. So in live operations, what tells you that an agent is helping, um, not harming. And how do you intervene without necessarily killing momentum of, uh, you know, bringing the value of the AI or adjunctive functionality to life in your world.

Shawna will pick this one with you. So in the call center, I think you'll see this show up in practical ways. Your first call resolution should go down your repeat calls should, you know, improve your after call work should go down. Um, and your agents should start feeling more confident in their answers. Um, they will feel supported and not replaced, which is a concern. And, you know, for a lot of actual humans doing the work that AI is going to replace them. So you have to change it to where they feel like they're being supported, they're able to focus more on their customer, get the answer to them as quickly as possible. Yep. We talked about that trust also building up gradually with, you know, your frontline agents, right? The people that are starting to use this. So, um, you want to start out with things that are assisting them in their work, not.

More assistive versus replacing. Yes, exactly. We still talked last night a little bit about, um, like the change fatigue that, uh, your call center agents are going through. So it's new ways of thinking, um, and different layers of complexity now that they're dealing with because the agents are able to help them in different ways. Can you talk about that a little bit? Yeah. So one of the things that I feel like the call center struggle with today is we get them so much information and it's all by email, and we're expecting them to read these emails and still take their call and focus on the customer's need all at the same time. Whereas if you're just surfacing information to them, they're not going to be exhausted from all of that. I mean, maybe the fatigue shifts a little bit to for new reasons because they're focused on the customer more, maybe.

But I think it's important that they feel like they have the tools that are supporting them. And this is a great way to do that. All right. Peter. Yeah we do almost similar as Seana is doing it. We our business uses the agents also in an assistive way. In the end the employee makes make makes the call on the decision especially customer impact or external external actions. Um but if it's quite similar if you want to see if the agent is helping you, you don't manage the decisions or control the decisions. You look, if the work is being done better and you have some points to check whether the work is done better, you it's less handling time. It's less, uh, more, less manual work, more consistent output. And once you establish those, you're probably on the right way to implement implementing the agent. And just as I explained with with those boundaries and those guardrails, um, it will happen that an agent makes a decision that is not consistent with the decisions that have been made before.

And then we still don't show that agent down. We get in contact with the team that developed that agent. We report something is going on. They adjust the agent and we just go on. And that's that's the killing momentum part. Paul. Um, you don't shut the agent down if you do that immediately. Uh, the, the, they're getting used to it. They're being held by it. It gives them a more, more, more, more, better work that helps them support the customer better. So the agent should be should be adjusted, adjusted to do the work better. And everybody can continue after that. And that keeps up the pace and doesn't kill the momentum of the agent. I think it's Understanding the runtime signals both from the system and from the people, right? Being able to capture those and do something with them in a structured way that is so different than just defining all of your business rules up front, testing them and, you know, giving your runbook to the end user that this is how it's going to go because it is going to be a little bit different.

Um, you know, making those, getting those small wins before you roll things out, earning that trust over time. Um, and, uh, yeah, it's, uh, it certainly is, is an interesting shift as it goes. So, um, the next question we had in this space was I just lost my place here. Um, all right. So as we think about how control actually works, thinking about shared ownership for trusted, trusted outcomes, who owns an agent when it fails and how does that change your operating model for these types of solutions. It's about a shared ownership now. It's the teams. It's not just it or not just the auditors or not just the business. It's a shared, shared responsibility that that agent does what that agent should be doing. And that means that it's no longer who is responsible for the task, but who is responsible for the outcome.

And once you establish altogether that we are shared responsibility for that outcome, you identify that the teams need to collaborate and work together because the responsibility of that agent changes. Um, a siloed approach just doesn't work anymore. In this case, outcomes matters. More matters more than tasks. You don't wait for the quarterly review. In my example of the auditors, you go to continuously constantly monitored system where you see how the shared responsibility is being taken care of. Sara. Yeah, I agree. It's a shared responsibility. Um you're not the agents aren't making the decisions. They're informing. And if something goes wrong, you have to work together to figure out what went wrong. Why and how are we going to fix it as quickly as possible? It's definitely a shared ownership between operations and your technical teams developing the agents. I'm gonna do anything to add to that.

Right? I would say I'd go back to the responsibility question. Right. So when we design an agent, we need to figure out what its capability is. And we test it extensively and we test it on edge cases as well. And. You know, ultimately when when the agent fails, you know, we, we need to be able to trace it back to, you know, the assumptions we made during its development. And I like some of your previous answers where we must tie agent behavior to actually ultimate business outcomes, like, you know, uh. You know, issue resolution or things like that, which are not technical metrics, but actually, why are we actually doing this in the first place? It's not just for the technology, but it's to achieve better business outcomes. So, uh, that's where I would connect it back. And, uh, I would say this also connects back to the identity and access management, right?

And the observability of agents and being able to know for each agent what entitlements does it have? What data can it access? You know, what databases does it have the right to write to us? And most likely we would like to have most of our agents reading and not writing, especially for customer facing things. So just being, um, I would say very defensive early in this agent journey. And hopefully in the future, we'll get to a point where agents can actually, uh, make significant business changes on actual customer files. But I would say we're in a crawl, walk and run. And right now we're still, I would say for the most part in the crawl phase. Uh, so. So I heard a handful of things. So one, shared ownership across IT risk and operations. I'm tearing down any silos that exist. And I want to, um.

When I say the rest of these bullets, I want to come back and ask a question about anything that your organizations have done to help bring down those silos as you've brought together governance boards around this. Uh, Seana, you talked about outcome based metrics. Uh, you know replacing task metrics making sure that you're really focused on the business value um, cultural resistance. Uh, and uh, you know, how, um, how it's showing up in terms of, uh, who feels ownership for something, um, and how they react to it. So I guess going back to the IT risk and operations, shared ownership, what's worked for your organizations to bring those groups together as you're thinking about, you know, the guidance, uh, in establishing what, um, what you want agents to be doing, uh, design time and runtime perspective, any specific lessons? Well, we, we have, um, quite a process to get any agent approved.

I mean, we have to go through three different governance review boards. It's very extensive. Just to get approval to use an AI agent, never mind trying to figure out what workflows are going to fall in that realm. And you have to work with the business and make sure that not only are the outcomes the right outcomes, but also that the solution is the right solution to begin with. And you're doing it for the right reason. Is that different for either of you two? Um, on the governance side, I would say no, it's not different. Uh, that's good to hear. Yeah. Um, and I think that's, that's a great thing and something that I would say Nfcu has done very well is, um, that, you know, the AI journey that we're on is not just considered sort of an IT technical journey, but it's really a business transformation journey that is actually driven from the strategy office.

Right. And us as it we are kind of the operating arm of that strategy. Um, but it's really an enterprise wide, wide strategy that involves multiple business units. Uh, you know, it involves legal, it involves an AI working group that brings together model risk. And, and I think that way of looking at AI as a strategic priority that is driven by the business sort of creates the conditions of shared ownership. Um, you know, and of course, it creates some slowness. You have to, uh, you know, get agreement from, from many people. And as it people sometimes we complain about that, but I think that's really the right frame, uh, sort of to create shared ownership and cross collaboration, uh, and also create the patience across the organization where everybody is really excited to, to have their own agent. But are you seeing that that velocity increase at all in terms of the change that, you know, the board reviews that need to happen and, um, the confidence with which they can move through those review cycles?

Yeah. I think we're getting more and more velocity, but it's still slower, right? So if you experiment on your own, you know, in your own, uh, free time playing with the new tools, you know, you get excited about a new Cloud, uh, implementation or something. It will happen in the enterprise maybe in six months, but I think that's the right way. Uh, you know, especially in our sectors, right? If you speak of insurance or health or banking, we have to be careful and we have to take things slow. So we don't necessarily need to be, uh, the Googles of this journey, you know? So yeah. Our board is enormously impatient. They want those agents. They want to, to, to, to the business to be successful. And we had the same as Seana several approval boards that you have to pass by for those agents. And that's what I explained why we try to implement Platform guidance within the platform.

And then you can build those agents. And then those agents don't have to go to all those approval boards to get to get approved. Because our business we are convinced that our business will step outside it if they're not served enough or not quickly enough. With all those potential of the ideas they thought of. So we are trying to get it into that platform that the platform be observed and managed. And then within that, you can build your agency. That saves a lot of approval boards. MM. Um, last question. We've got five minutes. I think this will be quick. And then we'll hopefully have some time for a bit of Q&A. So very last thing here. If leaders were to do one thing in the next 90 days, what would it be? Peter we'll just go. I'm more or less to say that now build governance into, into, into the platform and make sure that the approval process of the agent can be more lightweight because the platform will observe what's going on you, and then you start doing the observability in the guardrails on that platform to make sure that the agents stay in control of what of what they're doing.

Paul, for the record, he said, build on Pega as your platform, as the control plane. Yeah. That's not what he said. That's what he meant. Um, Sean. You're next. So for me in the call center, I think the biggest thing is that the call center leaders need to make sure that they understand and familiarize themselves with the technology and the tools that we're offering their agents. If the agents see that their leaders understand it and know how it works and trust it, they're going to buy in more easily versus some of that resistance, which is often felt when you're implementing uncomfortable new things. Yeah. Just like getting them in and saying, is this intuitive? Is it helping you? Is it confusing? Is it creating drag? Is it creating extra steps? Is it dumb? Yeah. Awesome. Mamadou Seck you. Um, I would say two things. Um, I'd say invest in observability.

That's, you know, anytime I talk about agents, Observability is the first thing that comes to mind. That's what really scares me. And you mentioned if you don't build the platform, right, people will create their own thing. Shadow it or shadow AI, as we say right now, will emerge, right? So, um, yeah, that would be one thing. And then I would say working really on education across the enterprise to understand the interface between AI and humans. Uh, I'll see you at Navy Federal calls AI augmented intelligence, right to, to create the understanding across the enterprise that it's not really about AI replacing anybody, but really humans getting stronger. And, you know, so doing that strategic work of educating the workforce and understanding how they can best benefit from from AI, I think that's really where we need leaders to help. Yeah. And I think, um, you know, all of you kind of hit on this taking a crawl, walk, run approach to it where you understand, you know, your business scenario that you want to improve and how can you begin to start incorporating adjunctive functionality in safe ways that drive towards a business outcome, um, that are intuitive, right?

That are driving towards that goal. One of the things that our team is working on is this crawl, walk, run series of use cases across each of the industries that Pega serves and thinking about, uh, you know, our six Rs receive and route work, how can you use agents to do those effectively? Then moving on to research and reporting, how can you use agents within workflow to improve that and then responding and resolving work? How can you use agents in structured ways to help with that? So, um, you know, those are again the agent six sixes. For those of you who've been around for a while, you may have recognized them as the regular sixes. But yeah, I think, uh, applying those things in the way that you've described is great. So, um, I know that we're nearly at time. Uh, if there are any questions.

I think we can maybe take a couple before we have to wrap up. Um, thank you all. By the way, for your time. Today has been wonderful preparing for this with you and having this panel with you. Thank you so much. Thank you. Just yell you're loud enough. Yeah, well, it sounds like you guys talked about mostly about three types of governments. Like I think Seana you talked up front about approval for agents. Right right. Peter you talked a lot about real time monitoring. Yeah for the most part it's like which is mostly based on telemetry. What I did and you kind of touched on it but I don't know if you're going there. How do you look at the end outcome? Like who's responsible and how often does that happen? We're looking at things like you brought it up next call or our first or what's called first call resolution.

Or, you know, average handle time or net promoter score. Those are things that feels like a business person should know. Is that part of the governance process? Is that part of some place that you're going? Because it feels like that's something that people like to ignore. But I'm just kind of wondering how you handle it and Mohammed Dawood love it. I love it because it seems like you're, you're not. So I'm not. Definitely. I think that's and as I was mentioning right hour before an AI use case reaches us in our IT department, it goes through what we call our member strategy office. And they define that use case in terms of how it's going to change something like, you know, Net promoter score or, or some cost reduction or something like that. Right. Um, and then in theory, right now we have a review cycle where we will come back, uh, six months after the agent has been implemented and check whether that actually ended up being the case.

We've not yet been to that process yet, but that's part of our, uh, you know, framework. And I think that's really important because many of these agents that are being implemented could be exciting from a technology point of view, but we yet need to see that it actually moves the needle on the business. Mhm. Any other questions? I've got 40s on the clock here. Actually that's over. I'm negative 40s, but we'll go ahead and take this one from the gentleman here. That microphone might be on for you actually if you want to just grab that. My sorry, my question is what role does security play in the this journey of AI governance. Security. What role does security play? Those are mostly data. Data data restriction driven. Uh, the you call them the PII rules. And we have a different though those are the security rules based on that and no external context, no external decision can be made autonomously by an agent without an assistant checking or approving the decisions the agent is making.

Those are the security boundaries we are implementing. I think it's about access to data just generally like what access can agents get. But then it's also thinking about it in terms of role based security. And one of the things that Pega has done is we want agents to align with the security of the role that that agent is, is supporting or executing to support. Right. So, um, you know, role based access control and other things like that within Pega really allow you to apply that same type of security mechanism to Pega Agents, um, and to any data or information that Pega Agents are getting at. So that's how we've kind of tried to solve it. I know that there's a lot more that can happen from an enterprise architecture perspective to lock down on things. I think other questions are around just like what part of the world and what models are you using and what are your security, uh, you know, requirements around that.

So, um, definitely. Yeah, I would say, uh, DLP like data loss prevention, uh, access controls, different types of access control. And you've mentioned models, right? So something we've been thinking about is, you know, these LMS are served from different parts of the world, right? And as part of Navy Federal, for example, we have very stringent, uh, guidelines on where our data should sit. Right. And that will prevent us from using a particular model, right? Whether it's a cloud model that is being served right now, and it doesn't guarantee, for example, continental US data residency. So there are many issues that that, you know, that come from, whether it's data loss prevention, you know, whether the data is encrypted in transit or in storage, whether it's stored in the US, whether the model provider deletes the data after the prompt is executed. Many questions. So security is definitely a big question that we have to think about.

So I'm over time. Uh, thank you all for coming today. I hope you enjoyed the conversation here. Really. Again, thank you to our three panelists.

Weiteres Informationsmaterial

Produkt

App-Design völlig neu gedacht

Optimieren Sie mit Pega Blueprint® blitzschnell Ihr Workflow-Design. Legen Sie Ihre Vision fest und erleben Sie, wie Ihr Workflow umgehend erstellt wird.

Möchten Sie einen Blueprint erstellen?
Wählen Sie die für Ihre Anforderungen geeignete Innovationsplattform.
Für Workflows und App-Design

Gestalten Sie Ihre Prozesse neu und verwandeln Sie jeden Workflow spielend einfach in eine einsatzbereite Anwendung.

Pega Blueprint®
Für das Design von Marketing- und Kundenerlebnisstrategien

Visualisieren Sie die Customer Journey und Engagement-Strategien für alle Touchpoints und setzen Sie diese effizient um.

Pega Customer Engagement Blueprint™
Weiterempfehlen Über X teilen Über LinkedIn teilen Copying...