Welcome, everyone. I am so excited to be here. My name is Kelsey Rich. I'm the VP of digital product and innovation at Employers, which is a workers' compensation carrier.And I know what you're all thinking. I'm sure you can't wait to hear about the fast paced world of workers' comp. But joking aside, if you can lead an AI transformation in one of the most heavily regulated, historically change resistant corners of business, you can do it anywhere. So consider me your proof of concept. A little bit about me, fifteen plus years in insurance and financial services, leading teams through what I'll politely call seismic industry shifts. I've worked with carriers, insurtechs. I spent some time working at Intuit. I have credentials in product strategy and AI business strategy from Northwestern's Kellogg's executive program, and I lead a team of product managers and designers across distribution, customer experience, policy, claims, finance, and experience design.

But the real reason you should listen today isn't my CV. It's that I am right now in the middle of leading my team through this transformation. I'm not here to tell you what worked perfectly. I'm here to share what I've learned, including what I got wrong, so you don't have to learn it the hard way. By the end of the session, you'll have three frameworks you can take back to your team this week. So when AI started accelerating, when demos got impressive and headlines got loud, the question I kept hearing from my team, sometimes spoken and sometimes just hanging in the air, was this, is this thing going to replace us? I didn't have a perfect answer, and honestly, if your team isn't asking that question right now, they're probably thinking it. So quick check-in before I dive in.

Drop a word in the chat. When your team talks about AI, is the vibe excited? Is it anxious? Is it maybe some of both? Where are your teams at right now? Both mixed? Absolutely. I think we run the gamut when we're talking about how we feel about AI. Yes, seeing a lot of good mixed opinions. I think that really resonates for me as well. But the way I was able to reframe this in a way that really resonated for me was thinking about AI like a wave. A massive powerful wave with two choices. You stand still and get toppled by it, or you learn to ride it. And while that sounds simple, turning this ride the wave theory from a motivational poster to actual leadership strategy is what I continue to focus on.

So really the gap between AI could transport more work and our team is actually using AI well is almost entirely a leadership and culture problem. And I have three frameworks that really helped me close that gap. The first framework is psychological safety. And I think it's the most important one because without it, nothing else works. When we first started bringing AI tools into our workflow, I noticed that people were hesitant. Not because the tools are hard to use, but because they were afraid. Afraid of looking incompetent, afraid of making a mistake with sensitive data, and underneath all of that, afraid that getting good at AI meant proving their own role wasn't necessary. That fear is real, and as leaders, we cannot dismiss it or skip past it to get to the exciting part.

So first, to support psychological safety, you need to name the fear out loud. I had direct conversations with my team where I said, I know some of you are wondering if AI is coming for your job. Let's talk about that. What does that look like? What are your fears? When the leader names the uncomfortable thing, it loses its power and it stops being the elephant in the room and starts being a problem that you can solve together. Next to support psychological safety is making experimentation a team sport, not an individual test. So one of the most transformative things we did was run a hands on AI workshop.

We had product managers who had been cautious observers becoming enthusiastic adopters in a single session. It was awesome. They built product briefs and working prototypes together using AI, discovering what it did well and having honest conversations about what it did poorly. The shift really wasn't about the technology. It was about experiencing possibility firsthand in a space where it was safe to stumble. People don't need to be convinced AI is powerful. We all know that it's powerful. They just need a safe place to feel that power for themselves. And then supporting psychological safety, celebrate the learning, not just the polished output. This is really hard to do sometimes. But if someone on your team tries an AI tool and it goes sideways, that's gold. That's someone who took a risk.

If you only celebrate the polished results, you're teaching people to hide their experiments until they're perfect. And that really kills this this culture of experimentation that you're trying to build. So here's a question for you to think about. When was the last time someone on your team shared an AI experiment that didn't work? If the answer is never, your team might not feel safe enough to try. The second framework is a heavy one, and it's ethics. But what I found is that a clear ethics foundation actually creates freedom, not friction. So early in our AI journey, I realized we were asking our team to experiment with powerful tools without giving them guardrails. That's not empowering. That can be terrifying. So people were paralyzed when they didn't know what the boundaries were. So here's what I wanna give you today. These are two layers that I use.

One is personal and one is operational, and I found that using both is incredibly beneficial. So taking a look at my six personal principles, these I live by when I'm making decisions about AI. They emerge from the work that I did in Kellogg's AI executive strategy program, but also from a lot of late nights wrestling with hard calls, inclusivity, equity, accountability, safety, human centricity, and sustainability. So these are questions I actually ask myself or another person when someone comes and shares a a use case with me. Will this serve the people who tend to get left out or only the easier to serve majority? Are outcomes fair across populations we touch, or are we baking in disparate impact? Are we taking accountability for outcomes, not just outputs?

What's the worst case if this fails, and is that acceptable? Is there a human in the loop where it matters? And is what we're building sustainable, or are we creating technical debt and trust debt at the same time? Every leader needs principles like this, and yours may be different from mine. The point is that you've done the thinking before the heat is on you. Shifting to how we operationalize this at scale, personal principles alone are not enough. As I mentioned, I work at a workers' compensation carrier writing in 46 states with regulators in every one of them, looking very closely at how AI is being used. So we've built an operating system for AI governance in our industry, but these lessons translate to any environment.

Three principles to take with with you, and really none of these require you to be an insurance. So first of all, anchor first, don't reinvent. Start with something like the NIST AI risk management framework. It's free, it's public, it's sector agnostic, and it's the closest thing we have to common language right now. You don't need to write a framework from scratch, anchor to one, and adapt it. If you're in a regulated industry like me, you'll layer in your sector's framework on top. For me in insurance, that's the NAIC model bulletin. But in health care, it's HIPAA and the FDA's emerging AI guidance. If you operate in the EU, it's the AI Act. But really, whatever sector you're in, you don't need to invent the playbook. Adopt one and adapt it.

The second tenet here is to screen every initiative against a small set of universal questions. Things like, where does the data go? Could this introduce bias or unfair outcomes? Can we actually audit the third party model we're relying on? And who's monitoring this in production? What does the user need to be told? When an initiative trips a trigger on any of these questions, we generate a short summary that maps the work to whichever frameworks apply and then surfaces what needs legal, security, or compliance review before before the solutioning starts. We really baked this into our intake process. Additionally, we give every initiative a preliminary risk tier at intake. So high, medium, or low, with some of these questions helping guide that decision making. What's the worst case if this fails? How much human oversight is in the loop? How much do we depend on systems that we don't control?

That tier shapes how much governance attention the initiative gets and travels with the work all the way through delivery. So if something comes in and it's a high risk, you better believe there's a lot of governance supporting that initiative and make sure that we are operating as intended. So we built this with our security, legal, and compliance teams from day one. And it's really not a gate to pass through, but really something that as partners we could all stand behind. So that collaboration was essential in my regulated industry, but the same principle applies everywhere. Your governance is only as strong as the buy in from the people who have to enforce it.

So, ultimately, as a result of creating this environment, we stop screening use cases just to say no. We screen them to figure out how we can execute responsibly. It's not intended to be a bureaucratic bottleneck. It's a structured conversation that flags where we need to lean in deeper and make sure that what we want to do, we actually can do. And what I found is that teams appreciate it. They really wanna do the right thing. They just need a framework that makes the right thing concrete for them. When the boundaries are clear, team members move fast inside them. When the boundaries are vague, they default to nothing. So ethics shouldn't be the thing that slows you down. It's the thing that gives your team confidence to speed up. The third framework is what I refer to as the permission structure.

And this is about shifting your team's default question from, is it okay to use a a AI to how are we using AI? It's a small linguistic shift, but it has massive cultural implications. In most organizations, AI adoption follows a pattern. You have a few early adopters start using tools on their own, everyone else watches, and then leadership sends a vague signal that AI is encouraged. And then months go by without meaningful change because no one felt like they had explicit permission. What I did was to make AI part of the expectation, not the exception. We integrated AI fluency into our product development methodology. We've now embedded product managers with our data science and AI teams through a rotation program, so they could see firsthand how these tools work, how we're measuring accuracy, and how we govern them effectively.

We didn't just say, yep. It's okay to use AI. We really made it part of how we define great product work. So also part of this permission structure is how permission flows from every level. Whether you're a VP, a first time manager, an individual contributor, you can build permission structures wherever you sit in an organization. If you're leading a team, make it visible. Share your own AI experiments, even the ones that failed. Talk about what worked, what didn't, what AI did well. When your team sees you learning in public, that is the most powerful permission signal you can send. If you're an individual contributor, you can advocate for culture on your team. You can be the person who starts sharing AI tips in Slack channels.

You could be the one who asked, hey. Have you tried using AI for that in the next meeting? That one question gives 10 people permission. It does not have to flow from the the top. Permission comes from anywhere, and sometimes the most powerful cultural shift starts from one person who's willing to go first. So when I think about what's changed most for my team through this journey, it isn't about the tools we use. It isn't how we see ourselves. We've stopped thinking about product design and engineering teams as people who execute tasks, many of which AI could do faster. Instead, we are reframing our value around what's uniquely and irreplaceably human. The empathy to understand a customer's real problem, the judgment to know what's worth building, the creativity to see connections that data alone won't surface, and the courage that it takes to make decisions when a path forward isn't clear.

AI amplifies those capabilities. It doesn't replace them. And our job as leaders is to help our team see that and own it. So here's what I'd ask for you to take away today. You don't need all the answers on AI. I certainly don't have them. But you can give your team three things right now. Give them safety, a place to experiment without fear of looking incompetent. Give them framework, clear personal principles paired with those operational guardrails. Both layers are important. And give them permission, an explicit signal that this isn't just allowed, it's expected. If you do all those things well, your team won't just survive this transformation, they'll lead it and so will you. Thank you.