In this section, AI strategist Dennie van den Biggelaar explains how to apply specific AI and machine learning to 'advice in practice'. In various editions, the following topics will be highlighted:

• Starting with specific AI and ML

• Operationalizing in business processes

• Integrating into existing IT landscapes

• Measure = Learn: KPIs for ML

• Ethics, regulations, and society

• AI and ML: a glimpse into the near future 

Of course, we begin this first edition at the very start: what is it, and how do you get started?

AI vs machine learning (ML)

AI is a machine or software that performs tasks traditionally requiring human intelligence. Machine learning (ML) is a specific part* of AI, allowing a machine or software to learn independently from historical predictions or actions. The most famous and discussed example of ML software is ChatGPT, which is specifically designed to generate meaningful text for the user. However, there are numerous other issues where machine learning can assist us. However, there is (still) not always a ready-made solution available for direct use, like ChatGPT.

To build such a usable AI solution, you need to bring together the right competencies at the right time. It is the task of an AI strategist to collaborate with a multidisciplinary team of business experts, ML engineers, data engineers, and data scientists to determine what to predict, how (accurately) that should happen, which techniques to use, and finally, how everything is operationalized and secured so that it actually leads to the desired outcomes.

Example: Predicting CancellationAs an office, you want to ensure that the right customers receive the right attention from your advisors at the right time, minimizing cancellation. It is ideal if you know which customers are at a high risk of canceling. But how do you convey this to the team?

It often happens that a customer cancels a single policy. In most cases, this is just a change, and you don't want to contaminate your ML model with it. Suppose a customer cancels all policies within the main liability category but doesn't cancel the rest (yet). Is this then a customer who is likely to leave? And what if they cancel everything within the main fire category but still have legal assistance and life insurance? Are there policies internally switched? How high is the cancellation rate anyway? All matters you want to establish before putting a team of ML engineers to work. Additionally, you must consider your forecast horizon: how far ahead do you want to predict? Do you want to know which customers will cancel in the coming 1, 3, 6, or 12 months? This also seems like a detail, but under the hood, it means you will train a completely different ML model.

Finding Patterns

Once you have clearly defined what you want to predict, it's time to check if your data is sufficiently Accurate, Available, and Consistent (the 'data ABC'). The main reason customers cancel usually boils down to them receiving too little attention. The question naturally is with whom, when, and why there is 'too little attention.' This information is not available in your data warehouse and needs to be constructed through feature engineering. What characteristics (features) have a significant impact on the cancellation likelihood? This is both an analytical and creative process where the knowledge and experience of insurance experts and data scientists come together.

Once a decent initial table with features is molded, you can finally start with machine learning. Experience shows that predicting cancellations is best modeled with classification or survival analysis. Hundreds of different ML techniques are theoretically suitable for this. In your choice, consider: how explainable must the algorithm be, how complex can the patterns be, or how much is the data ABC?

Validating Patterns

Once the 'machine' starts finding patterns to make predictions, there’s always an exciting moment... how accurate are the different models? For this, the ML engineer has an extensive toolbox. First, they set aside part of the data to test and validate a trained model. This ensures the robustness of the found patterns and prevents a model from making inaccurate predictions in the 'real world.' Then, they examine the false positives and false negatives and what their costs are.

A false positive is predicting that someone will cancel next month when they won't—it’s not so bad. The advisor calls the customer and concludes nothing is wrong: it only took 15 minutes of their time. If the algorithm wrongly predicts someone will stay loyal (false negative), this is much more costly: you lose a customer.

Based on, among other things, precision, recall, and AUC scores, the best ML model is determined. Additionally, it's possible to adjust algorithms to be stricter or less strict, better fitting the intended business process. This is called parameter tuning, and an experienced ML engineer knows how to do this responsibly.

How do you make it usable?

Then, you integrate the algorithm into operational processes. How can the data be transferred safely and efficiently, how can the advisor easily use the prediction? This is the work of data and software engineers. Finally, you want the advisor to provide feedback on the quality of the algorithm, so it learns from the user. The algorithm becomes smarter and more effective with more use. That’s the real 'AI' component, but more on that in the next edition! 

*AI is not always ML. For instance, the Deep Blue algorithm (which defeated chess grandmaster Garry Kasparov) in 1997 isn’t ML but is AI. ML is always AI.

Dennie is an econometrician with 12 years of experience in designing, building, and implementing machine learning solutions in practice. As co-founder and CTO of Onesurance, he is responsible for developing AI solutions and successfully operationalizing them with clients in the insurance sector.