At the request of VVP, featured in  the latest issue  VVP, the leading platform for financial advisors in the Netherlands, our CTO and 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
• Measuring = learning: KPIs for ML
• Ethics, regulations, and society
• AI and ML: a glimpse into the near future

Naturally, we start in this first edition with the basics: what is it and how do you get started? If you have any questions following this article, feel free to contact Dennie (dennie@onesurance.nl).

AI vs. Machine Learning (ML) AI is a machine or software that performs tasks traditionally requiring human intelligence. Machine learning (ML) is a specific subset of AI, allowing a machine or software to learn from historical predictions or actions. The most well-known and discussed example of ML software is ChatGPT, designed to generate meaningful text for users. However, there are countless other issues where machine learning can assist us. There is often (still) no ready-made solution like ChatGPT that you can use directly. To build such a usable AI solution, you must bring the right competencies together at the right time. It is the AI strategist’s task to work with a multidisciplinary team of business experts, ML engineers, data engineers, and data scientists to determine what you want to predict, how (accurately) it should be done, which techniques to use, and finally how everything is operationalized and secured to achieve the desired results.

Example: Predicting Cancellations As a firm, you want to ensure that the right customers get the right attention from your advisors at the right time, minimizing cancellations. Ideally, you would know which customers are likely to cancel. But how do you translate this to the team? Often, a customer cancels a single policy, which is usually just a change and something you don’t want to contaminate your ML model with. Suppose a customer cancels all policies within the main liability branch but not the others (yet). Is this a customer about to leave? And what if they cancel everything within the main fire branch but still have legal aid and term life insurance? Have any policies been internally transferred? What is the actual cancellation rate? These are all things you want to determine before putting an ML engineering team 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 next 1, 3, 6, or 12 months? This may seem 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 see if your data is sufficiently Accurate, Available, and Consistent (the ‘data ABC’). The main reason customers cancel often boils down to receiving too little attention. The question is, of course, from whom, when, and why there was ‘too little attention.’ This information is not in your data warehouse and must be constructed through feature engineering. What features (characteristics) significantly affect the likelihood of cancellation? This is an analytical and creative process where the knowledge and experience of insurance experts and data scientists come together. Once a solid initial table with features is shaped, you can finally start with machine learning. Experience shows that predicting cancellations is best modeled with classification or survival analysis. There are hundreds of different ML techniques theoretically suitable for this. In your choice, it’s important to consider: to what extent does the algorithm need to be explainable, how complex can the patterns be, and how much data is ABC?

Validating Patterns After the ‘machine’ is set to work to find patterns and make predictions, there’s always an exciting moment… how accurate are the different models? The ML engineer has an extensive toolbox for this. First, they keep part of the data separate to test and validate a trained model. This ensures the robustness of the discovered patterns and prevents a model from making inaccurate predictions in the ‘real world.’ Next, they look at the false positives and false negatives and their costs. For example, a false positive prediction that someone will cancel next month isn’t too bad. The advisor calls the customer and concludes that nothing is wrong: it only costs 15 minutes of their time. If the algorithm incorrectly predicts that someone will remain 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 more lenient, so they better fit the intended business process. This is called parameter tuning, and an experienced ML engineer knows how to do this responsibly.

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

AI is not always ML. For example, the algorithm Deep Blue (which defeated chess grandmaster Garry Kasparov) in 1997 is AI but not ML. ML is always AI.

Three Sentences About Dennie Himself 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 for clients in the insurance sector.