How to Establish Clear AI Ownership in Insurance

73% have a governance committee. That's only half of accountability

Chaz Perera, BevayaOne of the key best practices we highlight for AI implementation, is establishing clear ownership and executive accountability. And that's exactly what this session is here to help you do. In our latest "State of AI Adoption in Insurance" report, 73% of insurers, you all told us they have an AI governance committee either established or in progress. That's a big number and it's great news.

But here's the catch. A governance committee at the top is only one piece of accountability. The other piece is named ownership for each deployment. Both pieces have to be there and the strongest AI programs in insurance have both.

So that's what we're going to spend our time today focusing on. We'll start with AI governance committee, then move into the ownership stack, look at the reporting cadence that ties the two together, and wrap up with how it with how to get this all set up. If you're starting at zero and maybe mid deployment, whether you've already got AI running, you're evaluating your first vendor, or you're still working out where to begin, the approach is still the same. So, let's get into it.

Every strategy has an owner. AI usually doesn't

I want to start with the thing we see most consistent in this work. Every strategy your organization runs has an owner. Your underwriting strategy has an owner, the chief underwriting officer. Your claims modernization plan has an owner, the chief claims officer.

Your distribution strategy has an owner. AI is no different. And yet, more often than not, that ownership doesn't actually exist. Here's what happens when it doesn't.

No owner means no one is accountable when things stall and no one is responsible for fixing it. Even well-resourced strategies lose momentum because adoption doesn't happen on its own. Someone has to drive it. And without a named owner, vendor relationships, deployment decisions, and escalation paths fall through the cracks.

Most AI initiatives that fall short in insurance don't fall short because the technology doesn't work. The technology works. We've deployed it 120 times across carriers, brokers, and TPAs. And we see it work every day.

Where these initiative struggle is usually on how AI is set up and implemented. And a big part of that comes down to structure and ownership. So, we're going to talk we're going to be talking less about technology and more about people. So what does ownership actually look like in practice?

Two levels of ownership working in parallel

Before we go deep on any one role, here's the full picture. A common pattern we see in organizations is that they have one piece and this assumes the whole thing but they don't have other each of the other pieces which are just as important. So two levels of ownership need to work in parallel. The first is the AI governance committee and this is the bit that most organizations typically have right that sits at the organizational level.

It sets policy, manages risk and compliance and oversees AI broadly across the entire company. It's a cross-functional body with defined authority. The second is the ownership stack. That's the deployment level.

We say stack here because it's not just one person. It's multiple people with defined roles. These are real people with their names attached to whether a specific AI initiative actually delivers. So if you're working on FNOL automation or using AI for submission triage or automating premium audit processing, you have a stack for each of those.

These two ownership levels do different jobs. By the way, one doesn't substitute for the other. An AI governance committee doesn't give your deployments an owner. And named owners don't replace organizational oversight.

With just the committee, you'll govern AI carefully, but specific deployments tend to slip. The pilot you're excited about ends up with three out of 10 people actually using it. With just the ownership stack, deployments might move faster, but you're exposed when a regulator asks how the model made its decision or when you need to demonstrate your AI is being used responsibly. So again, two levels working in parallel.

That's the idea.

The AI governance committee: purpose, composition, authority

Okay, let's dig deeper into the AI governance committee. The purpose is to define how AI is evaluated, approved, and monitored across the organization. It's the rules of the road, what AI gets used, what data it can touch, what decisions it can support, and where humans stay in the loop. The composition is cross-functional by design.

You can see it on the diagram. It involves leaders from across the organization because AI decisions affect everyone. Operational leadership including underwriting claims and servicing because their teams are closest to where the AI actually gets used. Compliance because controls matter.

Legal because AI raises real regulatory questions in insurance. Risk management because deploying AI carries real exposure. And IT and data operations because the technical reality has to inform policy not get added as an afterthought. Quick honest note here.

If your committee is all IT, it's not a real governance committee. It's an IT review board with a different name. The cross-functional piece is the whole point. The authority here matters too.

Decision rights have to be clearly assigned and the committee has to serve as the ultimate decision-making body for AI across the enterprise, not advisory decision-making. And the scope covers the full AI life cycle from use case approval through production monitoring. So let's talk through what the committee actually does day-to-day.

What the committee actually does

The committee has seven main responsibilities. It defines governance policies. It sets standards for data performance and oversight. It evaluates and approves use cases, technology and vendors.

It defines risk thresholds and controls. On the operational side, it monitors pilots and approves the move to production. That gate really matters. Pilots have more flexibility, but anything in production that affects policyholders needs the committee sign off.

It oversees performance, drift, and bias over time, and it reports performance risks and impact up to senior leadership. Ultimately, the governance committee ensures AI is not only implemented, but managed in a way that's controlled, sustainable, and actually delivering value across the organization. Here's the nuance. The committee sets the rules.

It doesn't run individual deployments. It can approve a use case, but it isn't the right body to drive day-to-day adoption of an AI submission intake tool, for example. That's a different job and that's where we're headed next. One last thing, if you're sitting here without a governance committee, that's okay.

Start your first deployment and build the committee in parallel. One doesn't have to wait for the other.

The ownership stack: four roles per deployment

So that's the org level. Now let's talk about the deployment level, the ownership stack for every AI deployment. for every AI deployment so every submission intake tool every claim summarization workflow or every endorsement processing automation there are four roles working together there's the executive sponsor the business owner the IT or vendor liaison and the end users the executive sponsor ensures that the AI initiative has the support and resources it needs you have to assign one person to that business owner is accountable for the initiative actually delivering results within the business again assign one person for that role. The IT and vendor liaison owns the technical infrastructure, not the business outcome. Again, one person responsible in that role as well.

And then there are the end users, the people working with the AI output every single day. Their experience, by the way, determines whether it succeeds. Unlike other roles, there's no single person to assign. End users are referenced as a group.

So, four roles, clear lines of separation, nobody doing somebody else's job. We're going to spend the next four slides covering each of these a bit more. The obvious place to start is the executive sponsor.

The executive sponsor

So the executive sponsor is the person who clears the path for AI initiatives to succeed. This is typically a senior leader with real decision-making authority, someone visible and actively engaged in the program, not someone who shows up for a kickoff and then disappears. They allow they own rather allocating resources, removing roadblocks, resolving competing priorities when they come up, and let's be frank, they will come up. They also keep leadership and the governance committee informed.

What they don't own is the day-to-day work that belongs to the business owner. The executive sponsor's job is to make sure the business owner has what they need to succeed. Their job is not to do the job. The role is important because it keeps AI on the priority list.

Without it, AI will compete with everything else that's already on a senior leader's plate, and it could lose. With it, momentum will hold. So for those who haven't appointed one yet, this is the role to think about first before you pick a tool, before you sign a vendor contract, get this person named and everything after this will get easier. You don't want a slow fade where priorities shift, the business moves on and the initiative never reached what it could have.

This role is key. The next role, the business owner.

The business owner

In my experience, this is so important. This is the person who owns the work day to day and whose team uses the output every single day. This is an underwriting manager. This is a claims director.

This is a an operations person that runs a a policy servicing team. It needs to be someone close enough to the work to know whether the AI is actually helping. They need to be senior enough to drive change on their own team. So, a title isn't enough.

It has to be someone with a real stake in whether this succeeds. What they own is a lot. They set the baselines. What does the work look like today in real numbers?

They define what success will look like. They measure the outcomes and then they drive adoption. Importantly, they'll escalate blockers to the executive sponsor and they'll provide input on vendor and tool decisions. What they don't own is the technical implementation or system performance. that sits with IT, which is the next role we'll get to.

The business owner role matters because AI initiatives need someone whose daily work depends on the AI succeeding. It means they're always available with a real answer to how's it going.

The IT and vendor liaison

Okay. The IT and vendor liaison role is someone who keeps AI connected, secure and running. This is a technical leader from IT or data operations responsible for how the AI will integrate into the organization. They own architecture, platforms, security and technical integration.

They ensure performance system performance and AI infrastructure works succinctly. If the API goes down, for example, if the model needs to be updated, if a new integration is required, these are the folks you're leaning into. what they don't own is the business outcome or a specific deployment that belongs to the business owner. And that distinction matters more than you think. Here's why.

In most insurance organizations, when something new comes in, a new vendor, a new tool, IT signs the contract. IT runs the implementation. So, by default, IT ends up being held responsible for whether the thing actually works for the business. This is why adoption stalls and IT is the one holding on to it.

So defining this role clearly fixes that. IT is focused on the system. The business is focused on the results. Both report up, neither doing the other's job.

The end users

Finally, you've reached the last role in the stack, the end users. As we've said, these are the people who use the AI output every single day. underwriters reviewing submissions, adjusters working on claims that were set up by the AI, servicing reps helping to push COIs or premium audits through. They're not passive recipients of the technology. They're the people whose experience determines whether the deployment succeeds.

This is where the feedback loop starts. Questions, exceptions, and friction get reported as they happen. It all flows to the business owner first who then carries it forward either up the stack or laterally. They need real training on the workflow, on the tool and when to escalate, not a one-hour overview before go-live.

And as the deployment evolves, they need to be kept in the loop because surprises erode trust. When end users find accidents, trust drops. Or rather, when end users find change by accident, trust drops. When they hear it first, trust grows.

Their experience determines whether the deployment succeeds or fails. If end users don't trust or use the output, adoption stalls, regardless of how well the technology actually works.

The reporting cadence that ties it together

So, how do these four roles actually work together? Through reporting, a a consistent reporting cadence. This is what keeps accountability fresh and it's where a lot of AI programs can quietly lose their way or really flourish. There's three layers with three different reporting frequencies.

On an ongoing basis, end users report to the business owner. Questions, exceptions, and workflow friction get reported as they happen. Monthly, the business owner reports to the executive sponsor. They talk about utilization rate, any issues affecting adoption of the tools.

They judge they judge the outcome metrics against the baseline and they explain what's working and what isn't. It's honest reporting with real numbers. If utilization is at 30%, the report says 30% and includes a plan to move it. A good monthly check-in doesn't have to be long, 15 minutes max.

The business owner comes with three numbers. Utilization rate, outcome metrics against the baseline and the top blocker. That's the meeting. If those three things are healthy, it's obviously a short conversation.

If they're not, you know exactly where to focus. On a quarterly basis, the executive sponsor reports to leadership and the AI governance committee. This is where the deployment gets evaluated at the highest level. Outcomes, ROI, and whether the initiative is delivering what it promised.

It's where decisions get made about whether to continue to scale or redirect. These reports give the governance committee the visibility it needs to do its job. A good quarterly review doesn't need to be a big production. The executive sponsor comes prepared.

The governance committee comes ready to make a decision and the meeting ends with a clear answer on where the deployment stands. The key to this is to make this reporting structure a rhythm, not a one-time exercise. When programs lose momentum, it's almost always around months three and four when the cadence starts to drift. So hold the cadence even when there's nothing dramatic to report.

That's how you catch the small drift before it becomes a big one.

A six-step path if you're starting from zero

So there was a lot of structure. Let me leave you with something practical to take back to your teams. Now, if you're starting from zero or close to it, here's a six-step path. Step one, audit what's what's already been deployed.

Name every AI tool in production and who currently owns it, even informally. The person whose office people walk into when the tool isn't working. You'll be surprised what shows up. Some organizations have more AI running than they actually think they do. a tool a claims team adopted 18 months ago, a pilot that never formally ended, an automation someone built that only they know how to maintain.

The audit surfaces all of these things and it usually the first time anyone has the full picture in one place. Step two, assign a business owner to each formalize what may already be happening unofficially. Put a name and a title neck next to every deployment. Step three, appoint an executive sponsor.

One person, make it official, not assumed. Clarify decision rights alongside the appointment. Who approves resourcing? Who approves funding?

And who has the authority to pause or shift focus? Step four, set a baseline for each deployment. Maybe it's volume handled, maybe it's cycle time, maybe it's error rate. Whatever the tool is meant to improve, define it before you try to measure it.

Step five, build a reporting cadence. Start simple. Ongoing monthly and quarterly touch points. Make it a habit before you make it comprehensive.

Finally, step six, assess your governance structure. If a formal governance committee doesn't exist yet, don't let that hold you up. Standing up one is a parallel workstream, not a prerequisite. Start with ownership and build from there. before any initiatives begin.

Those are also your pre-pilot questions. Who's the executive sponsor? Who's the business owner? What's the baseline?

What does success actually look like? Who owns the escalation path if adoption slows? If you can't answer all of those by name, take a couple of days to a couple of weeks to get the answers before you start. Teams that do this upfront save themselves a ton of confusion later.

Where to leave this

Okay, here's where I want to leave this. Two levels of ownership working in parallel. A governance committee at the organizational level and a named ownership stack at the deployment level connected by a reporting cadence that holds the whole thing together. AI is going to scale in your organization.

Not because the technology is ready. It's ready. It's been ready for a while. It's it's going to scale because someone decided it was their job to make it work.

Name that person. Give them the authority. Hold them accountable. That's where transformation really starts.

Awesome. Thanks everyone for joining us today. With that, I'm going to hand it back to you, Jill.

Jill Zakarian, BevayaThanks, Chaz. Hopefully, everyone's sitting here feeling like this is more within reach than maybe it seemed at the start. Clear ownership, the right roles, and a reporting cadence that keeps it all honest. All right, let's now get into some questions.

Q&A: We're a small carrier without headcount for all these roles

Jill Zakarian, BevayaOkay, so Chaz, the first question I see, we're a small carrier. we don't have the headcounts to fill all these roles with different people. How do you think about the structure when resources are limited?

Chaz Perera, BevayaSo I suppose I should start by saying don't worry, this is a pretty common situation. and I would argue that the structure still applies. May maybe you compress it a bit. What do I mean? on a small team roles can overlap. The IT liaison can be someone who already manages your vendor relationships. for example, the executive sponsor can be a senior leader who's also really close to the work.

I think that's fine. Maybe the one thing that I I'd say, you know, we'd encourage is to protect as much separation as you can between the business owner and the executive sponsor. those feel to me like where differentiation or different people matter. and the reason I say this is because the whole point of having both is that the business owner has someone that they can escalate things to when there's a blocker. Right? If if the same person is acting in both, then that path disappears and typically things stall.

So keep those two things separate and you know you might be able to collapse the thing the things around it.

Q&A: What if the business owner leaves mid-deployment?

Jill Zakarian, BevayaAwesome. Next question. what happens if the business owner leaves the company mid deployment?

Chaz Perera, BevayaI suppose the risk isn't really the departure itself. It's that there was one person who held all the context I guess. so the answer is probably two things. succession and documentation. Why do I say succession? The executive sponsor's job in this moment is to move faster.

The longer the business owner role sits empty, the more momentum the deployment will lose. So you need to name an interim quickly even if it's not the perfect fit for the long term. That could by the way be someone on that same team or a peer from another team on documentation. If the business owner was doing their job well, the baseline, the success metrics, the outcome data, and the escalation history should all exist somewhere, right?

If you're following the reporting practices we suggested, for sure it should exist somewhere and not just simply in someone's head. So the practical answer is the structure itself should protect you here because a good ownership stack means the context isn't trapped with it in one person's head and the executive sponsor is the one who owns the response when it happens.

Q&A: What if the business owner and IT liaison disagree?

Jill Zakarian, BevayaAwesome. All right, I think we have time for one last question. How do you handle it when the business owner and IT liaison disagree on a decision?

Chaz Perera, BevayaSo I guess most of the time if the roles are clearly defined these disagreements should resolve themselves right that the the decision belongs to one person not both. it's if we're following through on our structure and cadence, the business owner owns whether the deployment is delivering the results. The IT liaison owns whether the system is running effectively from a performance perspective, right? Is it is it is it working in a timely way? is the experience exactly what you intended? Right?

I think those are fundamentally different questions. I let's be honest that there are some genuine gray areas. you know a vendor decision, a build versus buy call, something that touches both sides. That's what the executive sponsor is for. And they should act as the tiebreaker.

It's what it's it's one of the most practical reasons to have that role clearly named before, not after.

Jill Zakarian, BevayaAwesome. All right, we are going to wrap up here. Thank you all for joining us today. We really appreciate you being here.

And if something comes to mind later, you can always reach us at resources@bevaya.ai. We've run these regularly, so we hope to see you back soon for the next one. Thanks again and enjoy the rest of your day.