Short answer. You add AI to a legacy insurance system by putting an integration layer between the model and the core, never by wiring the model straight into a 15 or 20 year old policy or claims platform. Most carriers run 4 to 7 separate systems for policy, claims, billing, and underwriting, so the AI reads and writes through an API facade and an event stream, not through the database. Start with one workflow, keep the core untouched, and prove the model is auditable before it touches a pricing or underwriting decision.
Adding AI to a legacy insurance system is an integration problem before it is a modeling problem. The model is rarely the hard part. The hard part is that the data the model needs sits in a policy administration system written before the cloud, a separate claims system, a billing engine, and two or three vendor tools that do not share a schema. A carrier that connects an AI model directly to that estate gets brittle jobs, overnight batch dependencies, and one change that breaks three downstream processes at once.
The pattern that works is a thin layer between the model and the core. The AI reads through an API facade or an event stream, runs its inference in a governed environment, and returns a result the human or the workflow can act on. The core keeps running as the system of record. Ableneo shipped 34 production AI projects in 2025 across banking and insurance, and roughly 4 of 5 reached production, which is the number that matters when the enemy is a pilot that stalls on the integration step.
Concrete starting points that respect the legacy estate:
Insurance is one of the most regulated places to deploy AI in Europe. The EU AI Act (Regulation (EU) 2024/1689) classifies AI systems used for risk assessment and pricing in life and health insurance as high-risk under Annex III, point 5(c). High-risk obligations, including risk management, data governance, human oversight, logging, and technical documentation, apply from 2 August 2026. A model bolted onto a legacy pricing engine with no audit trail cannot meet those obligations, and the penalty ceiling for the most serious breaches reaches EUR 35 million or 7% of global annual turnover.
EIOPA sharpened the picture on 6 August 2025 with its Opinion on AI governance and risk management (EIOPA-BoS-25-360), which reads the AI Act together with Solvency II, the Insurance Distribution Directive, DORA, and GDPR. DORA (Regulation (EU) 2022/2554) has applied to insurers since 17 January 2025 and treats every AI system as ICT that has to be tested, logged, and recoverable. The integration layer is where those controls live, which is why the architecture decision, not the model choice, sets whether the deployment passes an audit.
Add AI through an integration layer, not by wiring a model into a 15 or 20 year old policy or claims core.
They break at the seams, not in the model. Most carriers run 4 to 7 core systems that were never designed to feed a real-time model, so the first failures are data failures: a field that means one thing in the policy system and another in claims, a batch feed that updates once a night when the model needs the record now, and customer data spread across systems with no single identifier. The second failure is load. A 20 year old policy platform sized for overnight processing was not built to answer thousands of synchronous inference calls, so a naive connection slows the core for every user. The third is change risk. When a model writes back into a shared table, one schema change can break underwriting, billing, and reporting at the same time.
You put an integration layer in front of the core and let the model talk to that, not to the database. An API facade exposes the few operations the model needs, an event stream carries changes out of the core without a nightly batch, and a governed inference environment runs the model with its own logging and access control. Replacing a policy administration system takes years and carries its own risk, so most carriers keep the core and modernize the edges. Ableneo’s work in financial services and insurance is built on this pattern, and 94% of its 2025 projects used large language models that sit beside the system of record rather than inside it. The core stays the source of truth. The AI becomes a service the workflow calls.
If the AI touches risk assessment or pricing for life or health insurance, it is high-risk, and the obligations are specific. You need a documented risk management system, training and input data that meets quality and governance standards, human oversight a person can actually exercise, automatic logging of the system’s operation, and technical documentation a supervisor can read. You also register the system and run a conformity assessment before it goes live. These obligations apply from 2 August 2026. The practical consequence for integration is that every inference has to be traceable to its inputs and its model version, which only works if the AI runs through a layer that records that trail, not through an opaque call buried in the core.
Start where the value is clear and the regulatory weight is lower. Claims triage and document processing move the numbers early and do not sit inside a high-risk pricing decision, so they let a team prove the integration pattern before it carries a regulated workflow. Underwriting and pricing come next, once the audit trail and human oversight are in place, because those are the Annex III high-risk cases. A phased path also matches how these programs get funded: one workflow in production earns the budget for the next, and a carrier that tries to automate pricing on day one usually stalls on governance before it ships anything.
Auditability is an architecture property, not a document written at the end. Every inference records its inputs, the model version, the output, and the human decision that followed, and that log is stored where a DORA test or an EIOPA review can reach it. Explainability matters where a decision affects a policyholder, so the model surfaces the factors behind a score, not just the score. DORA adds resilience: the AI service has to be tested, recoverable, and covered by the same incident reporting as the rest of the ICT estate. When the integration layer owns logging, access control, and versioning, the same design that keeps the core safe also produces the evidence an auditor asks for.
Ableneo builds the architecture where people, data, and AI operate as one capability, and in insurance that architecture is the integration layer that keeps a legacy core running while the model does its work. Across 2025 the team shipped 34 production AI projects for 20 clients in financial services and insurance, with roughly 4 of 5 reaching production and repeat clients running 1.7 projects on average. That record comes from treating AI as infrastructure that has to be governed and observable, not as a demo. See how Ableneo approaches AI transformation for regulated carriers that modernize the edges without touching the core.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.