Sponsored content: Arek Baran, head of Guidewire practice at Acini, discusses the impact AI is having on the work required from insurance professionals
Like the industrial and digital revolutions before it, AI is quietly redesigning the entire insurance puzzle. Recent developments have shaken the foundations of global markets and while the initial tremors were impossible to ignore, today’s subtler aftershocks are doing the real work.

These incremental advances are more than software upgrades – they are reshaping the insurance operating model and redefining the roles of software providers, insurers and advisory partners.
Why is this happening? AI projects can struggle to move beyond proof of concept, particularly when data quality is poor and processes are fragmented.
Embedded tools such as Guidewire ProNavigator can help insurers move past proof of concept faster, with the greatest gains coming when teams pair them with updated ways of working.
The insurance puzzle has changed – in order for the insurance pieces to create the desired picture, software providers, insurers and advisory partners have to redefine their boundaries and fit together in an entirely new way.
Those key industry stakeholders mentioned above have long shared the work of getting core systems into production. AI-native tools do not so much remove the build effort as relocate it.
Less of it goes into application logic and more into the unglamorous foundations – taxonomy, document governance and data lineage – which is precisely where most organisations discover how much operational debt they have accumulated.
This reveals the first trap for insurers – trying to force an ‘AI-shaped puzzle piece’ into a process map designed a decade ago. For the resulting picture to make sense, participants need to clarify their responsibilities across three areas.
Data hygiene and knowledge architecture
Here, the software provider’s role is to deliver RAG-based semantic search capabilities within the platform. The insurer is another essential piece, contributing product knowledge, growth appetite and invaluable first-hand understanding of legacy systems.
Advisory partners can support this work by helping internal teams organise repositories, standardise taxonomy and identify authoritative sources before they are indexed.
Process re-engineering and the human in the loop
This is where the shift will be most visible.
AI may reduce the time claims handlers spend sorting through information, while making the review and validation of its outputs a more significant part of their work. The change is fundamental because staff must be retrained to act as critical evaluators rather than ‘manual search engines’.
That, in turn, requires close alignment across insurers’ operational and technology teams, with advisory support when needed. Together, they must redesign workflow boundaries, role-based access controls (RBAC) and other guardrails. Only then can a digital assistant be embedded without introducing unnecessary risk.
Evaluation, validation and continuous adaptation
Past technology shifts, including the current AI transition, have shown that transformation is not a one-off event, but a continuous process.
In practical IT terms, prompt design and validation require rigorous domain testing against live claims scenarios.
The three puzzle pieces must therefore form a model of shared ownership – software providers supply and improve the technology, insurers contribute real-world edge cases and advisors can establish testing frameworks and feedback loops.
Completing the puzzle
With embedded AI assistants placing key puzzles on the table, the industry has a strong opportunity not merely to absorb the next wave of AI change, but to benefit from it.
Software vendors provide the technology, insurers contribute domain expertise and advisory partners can support changes where additional expertise is needed.
Yet achieving outcomes such as a significant reduction in processing time depends on how they fit into day-to-day operations. To do so, leaders must stop treating AI as a software module that can simply be ‘switched on’ and start assembling the operating model required to support it.









































