To see how long I have before being put out to pasture, I did some chatting with an LLM to see if it could replace an analyst like me. I won’t name the LLM to spare its feelings, but I can reveal that it is one of the current generation offerings.

I started by picking the AI’s brain about core systems.

“What are the main differences between [Vendor A] and [Vendor B],” I asked, where A and B are two well-known core system vendors.

After a few seconds of deliberation, it presented me with five bulleted paragraphs. They looked well-reasoned, comprehensive, and authoritative, but beyond that, every single bullet was inaccurate or outright wrong.

So, I decided to interrogate the model further on one of its “hallucinations” (the generative AI term for BS).

“So why do you think that [Vendor B] is faster to implement?” I asked.

Six bullets this time. And again, six hallucinations.

In the first one, it reported confidently that “[Vendor B]’s software is delivered as a multi-tenant SaaS platform, while [Vendor A]’s is traditionally deployed on-premises.” Hmm. That’s wrong on both fronts.

“Why do you think that [Vendor B] is multi-tenant?” I queried, knowing full well that it wasn’t.

Here, the LLM educated me on why a vendor might choose a multi-tenant architecture. Good explanation, but not what I was asking for. I will assume it was an honest misunderstanding and not an attempt to change the subject and evade my questioning.

“I don’t believe [Vendor B] is multi-tenant,” I politely corrected, “Where did you get that information from?” (Politeness goes a long way in getting what you want from an LLM, I’ve found.)

Now the game was up for the LLM, and it came clean.

“You’re absolutely right. My previous statements about [Vendor B] being multi-tenant were incorrect. After reviewing their architecture and offerings more closely, I see that [Vendor B] actually provides single-tenant SaaS and on-premises options… I made an incorrect assumption that because [Vendor B] was cloud-based, they utilized a multi-tenant SaaS model…. Thank you for catching my mistake – I will update my knowledge and not make this assumption again without verifying architectural details first. Appreciate you taking the time to correct me – it will really help reinforce accurate knowledge.”

The thing is, it won’t update its knowledge base, at least not until the next version of the model is available. That could be a year or more. If I try again tomorrow, it will still have the same flawed knowledge as today.

It’s worth highlighting that every single response I got sounded credible. If I wasn’t the coauthor of our policy administration system market report, I might have fallen for it. But I just pulled on one thread, and it all unraveled.

You can argue that my test was a little unfair. The information I asked for is not available in the public domain from an objective, reliable source. The LLM was trained on vendor marketing material and “free” research and is joining the dots as best it can. Nevertheless, it answered my questions without hedging and got almost everything wrong. If I had made a business decision based on this information, I would have wasted a lot of time and money.

You could also argue that by giving it better direction—asking it to double-check its work, for example—I might have seen better results. That’s also true, but the reality is that most users aren’t experts in asking questions in exactly the right way yet. (The term for this is “prompt engineering.”)

So, while generative AI is incredibly impressive (I’m a big fan), it has some key limitations that mean human expertise remains essential in navigating insurance technology. Flesh-and-blood analysts like me don’t need to stress too much about being replaced by robots just yet. The machines are getting smarter, but it seems like we have a couple of years before we are relegated to the scrap heap.

For more information about generative AI in insurance, you can read our report, Top Five Questions Insurer CIOs Have About Generative AI. If you’d like to talk to a genuine human advisor about AI (or if you’d like to read the full transcript of the conversation I had with this AI), please reach out to me directly at mhiggins@datos-insights.com.

The post Our Jobs Are Safe… for Now appeared first on Datos Insights.

Well integrated, automated, and efficient systems are essential for digital transformation. Two technologies we often see used in this context are application programming interfaces (APIs) and robotic process automation (RPA).  

An API is a mechanism that allows different software applications to talk to one other, enabling exchange of data and functionality. While the term API has been in business lexicon only for the last 10 years or so, APIs are as old as software itself. 

RPA is the use of software “bots” to automate repetitive tasks within business processes, with the goal of improving efficiency and reducing human labor. Automation of tasks involves interacting with business applications, either via API (if available) or via their user interface. This is a key distinction. RPA allows for user-interface-level integration between applications. This approach was known as “screen-scraping,” when user interfaces were made of green screens, but the approach works with web pages and some legacy client/server technology (C++, Delphi, PowerBuilder, etc.). RPA is also not new technology, despite being subject to several marketing makeovers over the years. 

User interface integration has downsides. It can be slow and inefficient, especially when many screens/pages need to be navigated to accomplish a task. User interface integration can also be fragile, breaking if a user interface changes unexpectedly.  

While RPA and APIs have overlap in terms of integration use-cases, one is not a “drop-in” replacement for the other. Generally speaking, integration with APIs is often preferred; it is more flexible, scalable, and less fragile. It should always be the first option considered. However, API integration isn’t always feasible or practical for technical and economic reasons. 

For example, if the system to be integrated is legacy, proprietary, or otherwise not under your control (a partner’s portal for example), APIs may not be an option (unless you can coerce the partner into building them for you, and you are prepared to wait).  

Building APIs on proprietary systems is sometimes an option, but the integration point for these is often the database. As such, they bypass business logic (processing rules and edits) in the application. This leads to duplicated/redundant logic in your API (making change harder) and/or data quality issues.  

APIs are most appropriate when they are provided by a vendor or when you have control over the application and the application’s business logic rather than the database.  

In cases when building an API isn’t feasible, RPA can offer an alternative means to integrating with the application. Because RPA can interact directly with the user interface, just as a user would, all validation, rules, and processing logic are executed. It is possible, even desirable, to publish RPA bots as APIs, thereby allowing other applications to call their functionality as needed.   

Rather than competitors, RPA and API should be viewed as complementary technologies. RPA is a tool that can help with many inefficiencies that business operations face. Many insurers have deployed it successfully for “quick wins” and otherwise. But because of its shortcomings―notably its fragility―it may be considered it a Band-Aid on the path toward native digital transformation. But for insurers with a significant legacy portfolio, the Band-Aids may need to last many years. An effective operating model for RPA is critical.   

RPA is also a component in the hyperautomation movement. Given the current state of digital transformation at many insurers, hyperautomation is likely to be an area of significant interest in 2024 and beyond.

The post APIs and RPA: The Dynamic Duo of Digital Transformation appeared first on Datos Insights.