The project and my role
For the course my team built an AI claim processing system called ClaimAI. The workflow is simple. A customer uploads photos of the damage, the AI looks at them and lists the damaged parts, and then the system estimates the repair cost and checks for fraud using the customer’s story and the photos. If the claim is small and no fraud is detected, it can even be settled automatically. My contribution to the project was mostly technical, including some testing as well. This post will look into my journey of building this MVP.
The project was split based on our aptitudes. I took up developing the prototype since I had done it numerous times previously for my bachelor’s. The prototype itself had two dashboards, one that the customer used. This contained a form, a chat assistant and a status page. The insurer side had a dashboard for the people who handle the claims.
Decisions and iterations
A teammate came up with multiple ideas, which were then voted upon. After the voting, we knew we wanted to do something in the insurance sector, so after thorough discussion, we came up with the idea that AI would handle the claims processing and fraud checks. The idea was still too broad for the limited time we had, hence we narrowed it down to car damage only. Car damage is visible in a photo and the repair cost can in principle be calculated. This was beneficial for the prototype as well since it enabled us to specialise in one type of claim.
A decision I kept iterating over was the strictness of the fraud checks and the rules around it. A claim only settles automatically once it goes through 13 criteria. Two of these were that the policy has to be valid and the fraud risk has to be low. Two more were that the confidence of the AI had to be at least 0.80 and the estimate had to stay under €1,500. If the rules were too strict, almost nothing would pass in the demo. Conversely, if the rules were made lenient, the demo would go smoothly, but then the prototype would not be realistic. During this dilemma we also did not have a price list for damaged parts across car manufacturers. We ended up noting this as a limitation of the prototype which could be worked on in the future.
What surprised me and what went wrong in testing
The first full test used 8 photos of damaged cars from the internet. None of the 8 claims were settled automatically. The confidence scores were between 0.55 and 0.75, all below the limit of 0.80. Also 7 of the 8 estimates came out above €1,500. I imagined the prototype would become a generic application that passes every claim to a human. It would be like a lot of products that have AI in the name, but where the AI does not really do much. But then I had to get it to work. I did not know if the model was bad, the rules were wrong or the test itself was the problem.
It turned out to be the test photos. Each claim had only one photo from the internet, with no view of the whole car and no number plate. With so little to look at, a low confidence score was actually fair. So I left the limits as they were. With a photo of the whole car, a close-up of the damage and the number plate, our demo claim settled automatically, while a doubtful one still goes to a person. I also started to look at the result differently. At first I saw 0 of 8 as a failure. Now I think strict is the safe outcome, because sending an unclear claim to a person is much better than paying out on one bad photo.
The fraud check also picked up that my test photos came from the internet. They had no camera data, so in the first test it rated 6 of the 8 claims as medium or high risk. Later we made the check stronger by reading the number plate and model in the photos and comparing them with the car on the policy. In a second test with 7 internet photos of other cars, it caught 6. The only miss was a close-up of a light where the car could not be seen.
How evidence and feedback changed the work
Among the many tests I did, one that particularly pointed out a big flaw. I gave ClaimAI the same image and asked it to process it twice, and it gave me a different output each time. This was due to a one-word difference in the AI’s output, since it said repair one time and replace the other time for the same bumper, which caused a €306 difference in the repair estimate. To address this, I got the AI to describe the damage and the code to use a fixed set of rules to make the decision, which kept the varying part to a minimum. Also, to account for the fluctuations in the estimate, the AI assesses the photos three times and the code uses the middle result. This only happens when the estimate is near the €1,500 threshold.
After the MVP was made I got some feedback from my teammates which mainly concerned the governance aspect of the AI. In order to address it I had to make some last-minute changes, such as making it clear on every page of the prototype that AI is used. Also, whenever someone is injured according to the incident report, the claim goes to a human automatically, since we decided AI should not handle such incidents.
What I learned from the collaboration
As a team we worked efficiently, with very little overlap between our parts. We used a Google Doc as an information dump, where everyone added what they knew, and we built the slides on top of it. I learned two things from this. First, splitting the work is the easy part, but bringing it together at the end takes more time than you expect, for example making sure every slide used the latest AI cost figures from the prototype. Second, when tasks are split by what each person is good at, and not by what seems hard or easy, everyone ends up making a real contribution.
How my understanding of AI and strategy changed
What surprised me most was how good and how cheap the assessment was. The model described the damage correctly, down to the corner of the car, and that too for about 10 cents. Hence, I found that using an AI model is the cheaper side, and what is actually expensive is the data to feed the AI, like the price list of the automotive parts. The bumper test also showed me that AI is good at assessing but not at deciding. This fits the difference between prediction and judgment from the Session 6 reading. Prediction has become cheap, but someone still has to decide what to do with it. In ClaimAI, those were the coded fixed rules and the person handling the unclear claims.
Looking ahead
At Demo Day our team was picked to pitch. In the beginning, it was nerve-wracking, since it was my first time pitching in front of over 100 people. It turned out people liked our pitch and prototype. It taught me that being nervous is not a reason to hold back. Next, I would like to try the prototype with real price tables and limits from an insurer, and compare its estimates with real repair bills.
