Welcome to Insider Insights, where we dive into hot topics facing the financial services industry. Today, Kartik Sakthivel, Chief Information Officer, LIMRA and LOMA and Nelson Lee, Founder and CEO, iLife Technologies candidly discuss the importance of tackling data issues upstream and stress that the value of AI hinges on resolving business problems.
Hey, Nelson. Good to see you, man. How you been?
Good. Good. It's always good to see you, Kartik.
Always good to see you, my friend. Hey, listen. You know, we should talk about AI. Right? Because everybody's been talking about AI. Every session, every conference, every committee, every study group, we're all talking about AI. But, Nelson, you and I have been talking about this since, gosh, January of this year. Right?
You know, data in most organizations is not turnkey, and ready to be consumed for AI. Right? It's just not there yet. I know you're pretty passionate about it. I'm pretty passionate about it. Let's just talk about the readiness and the state of data readiness for AI for a second. What does data readiness mean to you?
Yeah. There's parts I think that's more obvious, in AI readiness, and there are parts that is not. I think the most obvious one is probably format. Right? When people say, is data usable or is that cleansed? Is there AI ready? Generally, the first thing that comes to mind for people is format. Right? Is everything in a generally standardized format, right, to the various degrees of being standardized? What is not as obvious is that even as you standardize formatting, which itself is a humongous challenge. Right?
Yeah.
Because we know most of the industry is not even there on step one.
Yep.
That's actually just step one. Step two and three is the labeling and then contextualizing the data. Because I think you gave a really good example, Kartik, the other day.
Nineteen. We all can write nineteen in the same format. Great. We all write nineteen using the numerical symbols 1 and 9. But nineteen doesn't literally mean anything to anyone necessarily. It's the right format. There's no labels on it. Nineteen what? And why does that matter? What is the context of nineteen?
And that's the deeper level of contextualization. I think that makes any organization not only AI ready but get more practical ROI out of AI. Right? Because we're not using AI for the sake of AI. Although it's a hot topic, we would love to see ROI. And without context — big data — there's only one thing that's worse than having non usable data, and that's misleading data.
Most leaders I know and I agree with them. Misleading data is worse than no data.
Yeah. I completely concur with that. You know what's interesting? I remember when I said that example. I just tell you the number nineteen. Right? No context, no meaning, no definition. And if I tell you, you know, if it's an instrument to measure the temperature. Right? That still has no meaning. Right? Because 19°C and 19°F have very, very different connotation. Right? So, I think for the most part, we still have some work to do in our industry. We've done a lot of work in our industry, Nelson, as you know, in terms of modernization of our systems, in terms of trying to make cogency of the data.
But data readiness, to your point, is the contextualization of data — is the availability of data. Right? Because as soon as a data element enters an insurance company, if it’s distributed across seventeen different systems, right, how do you trace that data? How do you track that data? How do you clean that data? Those are Gartner's statistic that, 2/3 of data within an organization — and this is not just insurance — all organizations, all industries is, of poor or suspect quality.
How can you get anything done with a 1/3 of data? And then when this data enters an AI system where it's making these trillions of computations in a second that you can't even understand and fathom, that becomes a huge, huge issue. Right?
Right? Yes. Yes. Absolutely. Issues could stem from anywhere on the spectrum of unusable to misleading conclusions. Right? All of which is some degree of problematic. I think of this data issue as like a stream or river, to visualize it.
Data enters an insurance org or any org for that matter starting from the beginning of a river, so we call that upstream, and then it flows downstream just like an actual river would. A lot of people are thinking of downstream solutions. Right? Now that data is fragmented across x number of systems of format. How do we standardize formatting? How do we contextualize or label? And their entire large, amazing companies like Scale AI, whose entire job is not actually AI model. It's just to label your data so that AI models can use it. But when I think of it — and those downstream, you know, solutions are very important — but it's also really important to think of it as:
What do we need to fix from the upstream? Because how data flows in, is it flowing into generally one or semblance of one single entry or is it flowing from many different entries and then and then it aggregates, it splits, aggregates, it splits again. Does it go into branch? Does it look like a tree, or does it look like a river network?
Yeah. Because while the downstream solutions are very important, if you don't fix the upstream, you're always going to be doing a lot more work for a lot less results.
I completely concur with you. And, you know, our industry and our downstream systems, rather our upstream systems. Right? Which way is the river flowing? Our upstream system, I think by and large, we've done a pretty good job, with structured data. Right? So what do I mean by structured data? Think about your email. Right? Email is a perfect example. First name, you know, if you have your email address field, that is structured data. Right? You have email address and you have the actual value. The CC field has an actual value. The BCC field has an actual value. It's the unstructured data that most organizations struggle with, in terms of quality and efficacy and completeness and being able to trace the genealogy. An unstructured data is the body of your email. Right? It is completely unstructured.
Claim notes, is a perfect example of unstructured data being a mess because, you know, you have some people using claim notes as my dear diary, and some people using it as, as basically what can fit into a tweet. Right? So, the quality of data, Nelson, continues to be a challenge with our industry. I mean, you know, think about it. Right? Our industry is a mature established industry, and the systems implemented in our industry are commensurate to that. So, you know, why do you think data readiness and the good, quality efficacy of data is important for successful implementation of AI?
Yeah. That's a great point. And I think people all have to kind of start with the problem and then the goal and then leave the solution last. Right?
Yeah.
Because there's a lot of great AI solutions and AI — for obvious reasons — is a hot topic, but I feel like sometimes not as prominent in the conversation is, before we talk about any solution and the merit of any of them. It's like, what is the problem we're solving? What is the goal we want to accomplish if we solve these problems?
And if you think about a lot of these, like the email text body example. Right? It's really easy to structure data like first name, last name, CC, BCC. It is a lot harder to text, the body of the text. It's even harder to do attachments, which could be any combination of PDF documents
Yep.
Images, PowerPoints, or even videos.
Yep.
And so, people try to analyze these downstream, but I think the right approach is to first ask, why does it matter that something is structured or nonstructured? Why does it matter? And if it matters, what do we want to accomplish now that it matters in a particular way? Does that matter because we think structured data is necessarily easier to analyze than unstructured?
Well, if that's the goal and the ROI, we need to challenge that assumption. Right? Is, in fact, structured data easier to analyze? Maybe it was, but with AI, maybe that's not necessarily the case. Or we don't care how it's structured. We just want to reach a business conclusion and decision. And if that's the case, then we'll have very, very different solution-oriented mindsets about, like, what we want to do with regards to structure versus nonstructured.
We know, Nelson, something you said. Right? I think it's important for us to keep in mind AI is a tool. AI is a technology. Right? We need to define the business problem so it's not a sandwich looking for a picnic. Right?
AI is not a goal.
AI is not a goal. A hundred percent. Solving the business problem is a goal, and how you get there is, is by virtue of AI. Something you said, I've heard this somewhere, so it's not original.
We learn to love the problem as much as we tend to love the solution. So, completely concur with you on that one.
Hey. Let's switch lanes for a second. You and I have had plenty of conversations about this. Right? And I've said this in multiple forums. Our industry — right, wrong, or indifferent — does one thing better than every other industry. Right? And it’s that firms operate in silos. Right?
So you know how digital transformations were effectuated? They were effectuated in silos, not across the insurance value chain.
You and I have talked about this is why APIs became so prominent, right, in the industry starting with three ish years ago. And completely concur because APIs are a really elegant way for us to be able to connect disparate systems that quote “are siloed” and don't talk to each other, especially when it comes to, these legacy systems that were implemented ten, fifteen, twenty, thirty, forty years ago. Right? So, you know, your company actually specializes, in development of these integration APIs. Right? So, you know, without talking about what it is that you guys do, can you help me understand, like, what are some of the common problems companies are facing when they're trying to integrate back-office data with these new generation AI model in the AI system?
Yeah. I would say the number one issue is everyone knows data is everywhere, different formats or lack labeling, whatever. But the reason why data is everywhere is because workflow is everywhere. And when workflow is everywhere, it is impossible or very expensive to standardize data. Right? There are so many siloed workflows, not only across different product or product lines. Like, even within the product line, the upstream and the downstream operations and systems, everything is siloed. And then people run RFPs. Right? RFPs were, like, whatever is a comparable process for point solutions. But point solutions on top of point solutions on top of point solutions make things rather more expensive.
There's a lot of different points. So other than data and workflow everywhere, the other the other issue is that now that everyone generally has sets of APIs. Right? I've seen companies from fifty APIs internally to literally three thousand internal microservices.
So individual APIs are not rocket science to build. Anybody can build an individual API that does one thing. Yeah. What's really difficult is when you want to string workflow together instead of workflow everywhere, there is no good way that any company has that dictates the logic of how these three thousand APIs internally work together. That's both for internal and external purposes.
Yeah.
So whenever they work with, an internal or outside stakeholders, like, okay. These are three thousand APIs, two thousand documentations, two thousand different ways to combine workflow data, but, like, how do we orchestrate this? Right?
It's in generic term. Like, orchestrating containers for cloud native code.
And sometimes and oftentimes, the solution you and I both see is we'll just hard code this. Right? Fastest, easiest way to get this project down, we want a point solution. We have two hundred APIs relevant for this topic. Why don't we hard code two hundred of views together? Boom. You get a spaghetti ball when you do that a few times.
Yeah. So hard coding, you and I talked about this passionately.
Hard coding has to be technology malpractice, right, in the in the in the scripted sense of the word. Hey. Something you said, Nelson, about workflows, I think it's important for us to understand and for our listeners to appreciate. Workflows are a necessity in our industry. Right? If you think about how legacy systems have been so entrenched and why it's so hard for us to effectuate modernization, it's not because of the technology. Right?
You can buy an off-the-shelf product and kerplunk it into your organization, but I think the rub always becomes with integration, of this said kerplunk product with everything else that you have. And it's not about technology for technology's sake, in my opinion. It's around the workflow that each siloed department within a firm has. Right?
And then what happens? You implement a cost product, a commercially off-the-shelf product, something turnkey. Right? You go out and buy it.
And then five minutes after it enters a carrier's ecosystem, it is going to be customized to an unrecognizable burden itself. Right? And even with that, even with those customizations, no off-the-shelf product does a hundred percent of the things that we want it to do. So rather than tweak our business processes to meet the technology, we try and make — bend — the technology to our will. Right? We implement work around. And over the arc of history, these workarounds become institutionalized. Right?
So when you're talking about modernization, when you're talking about data integration, when you're talking about harvesting data for AI, it is through these disparate siloed systems, and more importantly, through these disjointed workflows that are regimented to a particular department, in my opinion, in my view of the world.
Yeah. Yeah. Absolutely. I think there's always this debate, like, do human processes cater to technology parameters or vice versa? And you will have strong advocates in both sides of the camp, but, it's hard to say one way is necessarily better than the other in all, like, blanket terms, all scenarios. What I will say, when technology is customized to an unrecognizable state, like you said, generally, that's someone is customizing a lot of the code base. Right. And the danger you and I both know of that is there's nothing wrong with customizing a code base in and of itself.
But if the technology org is not necessarily structured to maintain, enhance, and manage many code bases, then, eventually, it becomes technical debt. And then when you have technical debt, the first inclination, especially when budget time is tight is to, well, we hard coded a few things when we customize. We got to fix it. We only have thirty days. Why don’t we just hard code it some more?
That's, that's a great segue into my question for you, Nelson. So, you're a technology guy. Right? A leader, a business leader, but with a strong technical background. So, you see it all. You see both sides of the fence if there was a fence to be had. My question to you, what best practices can you think about, from a data integration point of view that makes it easier for organizations to be able to successfully harvest the data for AI systems?
Yeah. So, before I answer, I'll just tell you I'm extremely biased on this answer because my company does this. But I'm always a believer in that, fixing things upstream where data originates is the most cost and, like, out human hourly effective way to solve a problem. Yeah.
Because if you have so many bespoke — I call this I call it bespoke because many things are bespoke in our world today. If you have so many bespoke ways of workflow, bespoke ways where you manage interface. Right? Interfaces where most things more interactions mostly begin for insurance.
When you have so many bespoke things, you have to validate data in so many places. And then you have issues like, oh, the same piece of policy with the same data doesn't have the same value because it's coming in four different places. And that's why we have to manually verify them. And instead of trying to verify better in four different places, I think the better fix is always upstream. Why don't we just make sure the data entry door, right, not necessarily interface. I think people can be interface agnostic, but they should have a relatively aggregated, and a standardized way of how data is originated and comes into an org.
Because all the problems we're trying to fix is a result of that stuff upstream.
Right.
Right.
Oh, I think I think you're spot on. Right? Fixing problems at the group, at the source rather than destination, is definitely the best. So Nelson, what are the top two things you would you would tell people you should be doing these things to make sure that your data is ready for AI? What are the top two things that you would ask people?
Yeah. I would say the number one thing is making sure you have some semblance of a universal front door entry from a data perspective, and data always becomes workflow. So, eventually, like how can you do workflow and data in a relatively universal way so it's all validated in one place, and your downstream problems go away or at the minimum don't get worse. So I would say that's number one. And that doesn't necessarily mean everyone needs the same interface, right, just from a data engineering perspective.
I would say number two, I always advocate even though I love engineering, you know — you and I both — I always advocate for there to not be a fence between IT engineering and the business side. Let's all get together and just talk about the problem, what's our goal, and then the business and IT should enable each other as components of that solution as opposed to this old school way of thinking, like, this is an IT matter or this is a business matter. Well, at the end of the day, everything is a business matter whether IT is in it or not, so let's enable each other.
I completely agree, man. So data isn't an IT issue. Data isn't a business issue. Data is everybody’s issue. Right?
Yeah. I mean, we're all, like, tech companies like my own and also insurance companies. All of us are ultimately in the business of selling outcomes. Right?
Yep. Yep.
Insurance companies sell outcomes to their consumers and distributors. We sell outcomes to insurance companies, but, like, none of us are selling lines of code.
Just that's I don't think that's what actually matters to people.
I love that, Nelson. As always, it is such a great time talking with you. I feel smarter at the end of our conversation — every single conversation — than I did coming in. So, I do appreciate you, brother. So let's, let's do this again sometime soon. Yeah? Wow.
Thank you so much. You are too kind. Let's catch up soon.
Alright, pal. Yeah.
Thanks for listening to LIMRA's insider insights podcast series. To hear future podcasts, subscribe at LIMRA.com/podcast.
