Insurance organisations have invested heavily in platforms, portals, automation, and AI. Yet many still rely on fragmented systems, duplicated data, document-heavy processes, and manual hand-offs. Information may enter through a digital channel, then require extraction, checking, and re-entry before the next activity can begin.

The next stage of digital insurance requires an operating model in which trusted data moves securely across internal systems, industry platforms, partners, and workflows. Connecting these environments allows organisations to reuse information across the insurance lifecycle, reduce repeated handling, and make relevant information available when people need it.

Four capabilities underpin this progression.

Trusted data

Common definitions, clear ownership, and appropriate governance establish a reliable foundation for operational processes, analytics, and AI. Aligning internal data models with relevant industry standards helps information retain its meaning as it moves between systems and organisations. Quality controls and traceability allow teams to understand where data comes from and whether it is suitable for its intended use.

Connected workflows

Integration connects people, systems, and processes across organisational boundaries. Flexible interfaces allow different channels and levels of digital maturity to feed the same governed workflow. This includes connecting existing applications and legacy systems with market platforms, so that information can support subsequent activities without repeated manual entry.

Automation

With dependable data and connected systems in place, organisations can automate repeatable work. Activities such as validating information, transferring approved data, and routing tasks can follow defined rules, with exceptions and approvals directed to the appropriate person. Visibility across the workflow helps teams identify delays and resolve failures.

Intelligence

Generative AI can support information extraction, summarisation, and access to knowledge. Agentic AI can operate as a ‘user’ through connected tools and services to coordinate tasks and take controlled action within an agreed scope. These capabilities can support both customer-facing processes and internal work, including reporting and analysis. Their usefulness depends on the quality of the available context, the permissions granted, and the guardrails around their use.

This whitepaper develops these capabilities through three connected phases: building trusted data foundations, connecting and automating workflows, and turning connected data into intelligent action. It then brings them together in a technical target operating model and considers how organisations can assess maturity, measure progress, and choose where to start.

The phases describe cumulative capabilities. Organisations can develop them in parallel, provided they understand the dependencies between data, integration, and the outcome they want to achieve. Progress begins with a defined business need and a clear way to assess whether the resulting change improves everyday insurance work.

Insurance creates and consumes information at every stage of the lifecycle. Submissions, quotations, contracts, premiums, claims, and reinsurance arrangements all depend on data that must remain understandable and usable as it moves between participants.

Digital platforms already support many of these activities. The challenge is connecting them so that progress in one part of the lifecycle carries through to the next. A transaction can pass through several digital environments while still relying on people to manually enter information between them.

Fragmented data is our reality

Partner portals, document management systems, legacy lifecycle systems, email, PDFs, and spreadsheets each hold information needed to complete insurance work. These sources often use different structures and definitions, leaving teams to reconcile records and establish which information is current.

Consider a submission that arrives through a partner portal. Brokers may submit the request digitally, but supporting documentation may have been received through other sources, so supporting documents may follow by email. Exposure information sits in a spreadsheet, and existing policy details remain in an internal system. Often operations teams, or even the brokers and underwriters, need to manually bring these sources together, validate completeness, resolve inconsistencies, and enter the relevant information into the relevant workflow.

The same preparation may happen again downstream. Policy administration, premium processing, and claims teams may each need to extract or check information that another team has already handled. Changes made in one system may require separate updates elsewhere, meaning operational overhead, re-keying and delays, which often means scale is reliant on more resources.

This fragmentation also affects internal analysis. Producing a portfolio or Bordereau report can require teams to combine extracts from several applications, align definitions, and investigate discrepancies before they can interpret the results. The effort involved limits how readily people can use the organisation’s data to answer business questions.

The future of data is intelligent

A more connected operating model allows information to retain its meaning and remain available as work moves across systems and participants. Four capabilities support this change.

Governed data

Shared, approved definitions, ownership, and quality controls give people and applications a dependable basis for using information. Traceability makes it possible to identify the source of a value, understand subsequent changes, and resolve discrepancies. Consistent access controls govern how teams, services, and AI tools can use that information.

Connected workflows

Integration makes relevant data available to the next activity without requiring people to recreate it. Different channels can feed the same workflow, accommodating participants that exchange structured data alongside those that still rely on documents or manual entry. Existing systems can continue to support the business while APIs and controlled agent interactions connect their capabilities to wider processes, even managing the workflow as a human operator using digital tools

Automated processes

Defined rules allow systems to carry out repeatable activities, including completeness checks, approved data transfers, and task routing. Exceptions reach the person responsible, with enough context to act. Teams can see where work stands, what has failed, and what needs attention.

Intelligent decisions

Connected, governed information gives people a stronger basis for judgement and analysis. Generative AI can help extract and summarise information, call out exceptions, or make relevant knowledge easier to access. Agentic AI can coordinate permitted activities across connected services, gathering context and carrying out tasks within defined controls.

In the submission example, these capabilities could bring supporting information into a common workflow, identify missing details, and prepare a consistent record for underwriting review. Internally, the same data foundations could support a portfolio or Bordereau report without repeated manual reconciliation.

The transition will reflect different levels of digital maturity across the market. Organisations need flexible ways to work with both structured exchanges and document-based processes. Building trusted data foundations, connecting workflows, and introducing controlled intelligence provides a practical route towards that model.

Insurance operates through a network of participants whose work depends on shared information. Policyholders, brokers, insurers, MGAs and coverholders, Lloyd’s managing agents, reinsurers, and third-party administrators each contribute to different parts of the lifecycle. Regulators require information and oversight across relevant activities.

Each participant has its own responsibilities, systems, and information requirements. Connecting their work requires an understanding of how information moves between them and how each exchange supports the customer.

Market participants

Policyholders provide information about their insurance needs and exposures, agree cover, and submit claims. Brokers help represent those needs to the market, arrange placement, and support servicing and renewal.

Insurers assess risks and provide cover. MGAs and coverholders perform activities within their delegated authority, which may include underwriting, binding cover, and policy administration. Lloyd’s managing agents manage syndicates and their underwriting activities.

Reinsurers provide cover for risks assumed by insurers. Third-party administrators and other service providers support activities such as claims handling and policy servicing. Regulators oversee relevant conduct and prudential requirements, creating further reporting and information obligations.

These relationships vary by class, business model and transaction. A workflow may involve several organisations, with responsibility for particular activities distributed between them. Technical design needs to reflect those responsibilities, including who can provide, amend, approve, or act on information.

The insurance lifecycle

The lifecycle extends from product development and distribution through submission and triage, quotation, underwriting, placement and binding, policy administration, premium billing, claims management, reinsurance, and renewal.

Information created at one stage supports work elsewhere. Submission data informs underwriting and quotation. Agreed terms support policy administration and premium processing. Policy information provides context for claims handling, while claims experience can inform renewal discussions and future underwriting.

The sequence also includes revisions and feedback. A change to an exposure or an agreed term may affect several downstream activities. Connected workflows need to carry those changes through to the relevant systems and participants, with a clear record of what changed and who authorised it.

Data flows across the lifecycle

A useful starting point is to map the information required for a defined business activity. This means identifying its source, ownership, intended use, and the systems through which it passes.

For example, a broker and an underwriter may need access to the same risk information while using different applications. Once cover is bound, operational teams need the agreed information in a form they can use for administration and billing. Repeatedly extracting it from documents creates additional work and opportunities for inconsistency.

Internal reporting depends on these flows too. A portfolio view may draw on underwriting, policy, premium, and claims information. Common definitions and traceable data help teams combine those sources and understand the results.

Collaboration connects market participants

Effective information exchange requires agreement about both data and process. Participants need to understand what information an exchange contains, when it becomes available, and what action should follow.

They also need clear arrangements for missing information, conflicting values, and approvals. A technically successful transfer has limited value if the receiving team cannot interpret the data or determine what to do next.

Human involvement remains essential where work requires interpretation, negotiation, or judgement. Connected processes should give people the context they need and reduce the administrative effort involved in gathering it.

Industry platforms and enterprise technology support every stage

Industry platforms support interactions between market participants, while enterprise applications manage internal activities and records. Their contribution depends on how effectively information moves between these environments.

Improving one application may leave the wider transaction dependent on manual hand-offs. A connected approach considers the full workflow, including external exchanges, internal processing, and the information needed for analysis.

This provides the context for the first phase of development: establishing trusted data foundations that systems and participants can use consistently across the lifecycle.

Automation, analytics, and AI depend on information that people and systems can interpret consistently. Building trusted data foundations means establishing what data represents, who owns it, how its quality is assessed, and how it becomes available for use across the business.

The starting point is the information required for a defined business purpose. A submission workflow needs reliable risk and exposure information. An internal portfolio report may need to combine policy, premium, and claims data. Both require agreed definitions and a clear understanding of how the underlying information relates.

From fragmented data to a single source of truth

Internal systems, external sources, market data, documents, email, spreadsheets, and manual input all contribute information to insurance processes. Bringing these sources together requires decisions about which source is authoritative for each data domain and how teams should resolve conflicting or incomplete records.

A single source of truth provides an agreed, governed reference for that information. An enterprise data platform can support this by bringing relevant data together and making it available through consistent access mechanisms. Source systems may continue to hold operational records, with clear rules governing how the organisation combines and uses their data.

For example, producing a portfolio or Bordereau report requires agreement on what constitutes a policy, how premium values are represented, which reporting period applies, and how claims relate to the underlying cover. Without those definitions, a consolidated dataset can still produce inconsistent interpretations.

An internal data model aligned to ACORD, MRC, and CDR

A practical approach begins by defining the data domains the business requires, such as parties, risks, policies, premiums, and claims. Each domain needs agreed definitions, relationships, defined data attributes and ownership. From this, a business glossary can be produced which defines all the data a business needs internally and externally to succeed.

Relevant industry standards and market requirements should inform this model. The Market Reform Contract (MRC) structures contract information, while the Core Data Record (CDR) defines data requirements that support London Market processing. Their relevance depends on the business activity and the exchanges involved.

Organisations should map their internal definitions to these requirements and apply the resulting model across systems where feasible. Where applications use different structures, explicit mappings and lineage help preserve meaning as information moves between them. 

This creates a basis for aligning data across the lifecycle. Information captured during submission can support subsequent activities without each system independently redefining it.

Data governance and ownership

Governance establishes responsibility for data and the rules governing its use. Data owners need to define what information their domain requires, what acceptable quality looks like, and how teams should resolve issues. Agreed definitions can then be catalogued and kept under change control.

Organisations can establish governance through tooling, policies, processes, and assigned responsibilities. Tools can help enforce access rules, maintain definitions, and monitor quality, but their effectiveness depends on the decisions and accountability behind them.

For each priority data domain, the organisation should establish:

• An accountable business owner (The data owner).
• Agreed definitions and permitted uses.
• Authoritative sources and rules for resolving discrepancies.
• Quality requirements appropriate to the business activity.
• Access permissions and procedures for managing changes.

These arrangements allow teams to treat data as a maintained business resource, with responsibilities that continue beyond the delivery of an individual project.

Data quality and lineage

Data quality needs to reflect the intended use. A record may contain enough information for an initial enquiry while remaining incomplete for quotation, binding, or reporting.

Checks should therefore assess the information required at each stage. These may include completeness, validity, consistency between related fields, and whether values remain current. Exceptions need a clear route to the person responsible for correction.

Lineage provides traceability from a data item to its source and through subsequent transformations. This helps teams investigate discrepancies and understand how a report, operational record, or AI output uses the underlying information.

For an internal BI report, that means being able to trace a reported figure to the contributing records, definitions, and calculation logic. For a submission, it means understanding which source supplied a value and whether someone subsequently reviewed or amended it.

Generative and agentic AI in the data foundation

Generative AI can support extraction from structured and unstructured sources, including documents and correspondence. It can help identify relevant information and flag potential inconsistencies or exceptions for review. Validation remains necessary before extracted information becomes a trusted input to operational processes.

This capability also supports flexibility across different levels of digital maturity. One participant may provide structured data through an interface, while another supplies a PDF or spreadsheet. Extraction can help bring those inputs into a common data model, with checks appropriate to each source.

Agentic AI can help coordinate the activities around that preparation. Within defined permissions, an agent could act as a human operator exchanging information with a client via email, retrieve supporting information, invoke validation services, route an exception, or prepare an approved update for a connected system. API and agent interfaces around legacy applications can make existing capabilities available to these workflows, reducing repeated manual entry.

These activities depend on the right security, agent persona, and the same ownership, access controls, and traceability as other data processes. The organisation needs to know what the agent accessed, which checks it performed, and what requires human approval. These ‘Guardrails’ need to be defined and adhered to in the same way organisations ensure their employees train and action their policies and procedures.

Trusted data for AI and analytics

An enterprise data platform can make governed information available to operational applications, analytics, and AI services. Data Lake’s and a semantic layer can express agreed business definitions and relationships so that different consumers interpret the data consistently.

This supports both external workflows and internal insight. The same governed policy and claims data may inform a servicing activity, a BI report, or an authorised natural-language query. Each use still requires appropriate permissions and validation.

The foundation can grow as the business develops. Establishing a dependable data model creates an opportunity for reuse, provided its definitions, quality, and access arrangements also meet the requirements of the next use case.

Trusted data foundations establish what information means and how the organisation governs it. Integration makes that information available where work happens, connecting internal applications, market platforms, and the people responsible for each activity.

Insurance organisations need to support different channels and levels of digital maturity. Some participants exchange structured information through APIs. Others use portals, email, or documents. A connected operating model allows these channels to feed the same governed workflow, with appropriate validation and exception handling.

Flexible risk placement support

Risk placement can involve several ways of supplying and receiving information:

• Email and manual entry.
• Email with optical character recognition (OCR) or AI-assisted extraction.
• Manual entry through a portal.
• API integration.
• AI Chatbots to that respond in natural language through forms, texts or email
• Specialist risk placement platforms.

Each channel requires a way to bring information into the organisation’s agreed data model. Structured exchanges need validation and mapping. Documents, images, video and email may also require extraction and human review before their contents can support downstream work.

For example, a submission received through a placement platform and one received by email may need the same completeness checks, enrichment, and underwriting review. Their initial processing will differ, but both can enter a common workflow once the information meets the required standard.

This flexibility allows organisations to improve internal processing while continuing to work with partners whose technical capabilities differ.

Connected operations

Enterprise workbenches provide a place for people to manage activities using information from connected systems. Linking these workbenches to the single source of truth helps teams work from consistent data while retaining access to the operational applications they need.

APIs can expose defined capabilities from existing systems, such as retrieving a policy record or submitting an approved update. Where legacy applications have limited interfaces, an API or AI agent wrapper can provide controlled access to selected functions. The approach depends on the application’s capabilities and the reliability of the available interaction.

Connections also need to reflect when information becomes available and when another activity requires it. Some exchanges can run on a schedule. Others need an event or update to trigger the next step. Real-time information is useful where the business process requires an immediate response.

For a submission workflow, connected operations could link receipt, extraction, validation, enrichment, underwriting review, and transfer of approved information into the relevant operational system. Each step needs clear inputs, outputs, and responsibility for exceptions.

Internal reporting benefits from the same approach. Preparing a BI report could involve retrieving governed policy and claims data, applying agreed calculation rules, refreshing the reporting dataset, and notifying the relevant team when it is ready. Failed checks or missing records should remain visible so that teams can investigate them before relying on the results.

Integration and real-time information

Different integration mechanisms serve different needs.

Messaging protocols allow systems to exchange information without requiring every activity to complete at the same time. Events can notify connected services that something has changed, such as a submission becoming ready for review or an approved policy update becoming available.

APIs provide defined interfaces through which applications can request data or invoke a service. These connections are useful where the required interaction and its inputs and outputs are known in advance.

MCP-connected agents provide a further way to access approved tools and services dynamically. The Model Context Protocol (MCP) gives an AI application a consistent interface for discovering and using the capabilities exposed to it. The underlying services still need reliable integration, authentication, and permissions.

For example, an authorised agent could retrieve submission information, call a validation service, and request additional context from another connected system. Its available actions should remain limited to the task and the permissions granted. Decisions about whether an action is allowed must remain enforceable by the connected services.

These mechanisms can work together. A workflow may begin with an event, use APIs to retrieve records, and involve an agent where the next permitted step depends on the information gathered.

Automated downstream data flow

Once information has passed the required checks and approvals, connected services can make it available to subsequent activities. This reduces the need to extract and re-enter the same data as work moves through the lifecycle.

Following binding, for example, approved information could flow into policy administration and premium processing. Relevant updates could also become available to reporting services. The workflow needs to preserve the relationship between the approved transaction and the records created or changed downstream.

Automation must account for failed transfers and partial completion. Teams need to know whether an update reached its destination, whether the receiving system accepted it, and what action is required if processing stops. Reconciliation and controls against duplicate processing help maintain consistency across systems.

Business rules and underwriting system integration

Business rules define how predictable activities should proceed. They can support completeness checks, routing, and referrals based on agreed criteria.

Integrating these rules with underwriting systems makes them available within the working process. For example, a workflow could check that required information is present before presenting a submission for review or route a case to the appropriate person when it falls outside defined parameters.

Generative AI can assist with document interpretation and information preparation. Agentic AI can coordinate permitted steps across services. Both need to operate within the organisation’s business rules and approval requirements, with uncertain or conflicting information directed for review.

Workflow automation and human involvement

Workflow orchestration coordinates the sequence of activities and tracks their status. It establishes what can proceed automatically, what depends on another task, and where a person must intervene.

Human involvement should reflect the activity and its consequences. Reviewing an extracted value, approving a record update, and making an underwriting decision require different levels of authority and oversight. The workflow should present the relevant context and make the required decision clear.

Operational visibility is equally necessary. Teams need to see what has completed, where work is waiting, and who owns the next action. Logs should support investigation across system boundaries, including actions performed by AI agents.

The result is a workflow that can accommodate different channels while applying consistent data controls and business rules. This provides the connected environment in which AI can use relevant context and take controlled action.

Connected data and workflows give AI access to the context and services needed to support insurance work. AI assistants can help people interpret information and access knowledge. Agentic AI can coordinate activities across connected systems, using approved tools to carry out tasks within defined limits.

The starting point is a specific decision or outcome. This establishes what information the AI needs, which actions it may take, and where human judgement remains necessary. The approach applies across broking, underwriting, MGA operations, claims, and renewals, as well as internal reporting and analysis.

Trusted information

Useful AI depends on relevant information that retains its meaning and context. Customer records, policy and claims data, external sources, real-time events, and business knowledge each contribute a different part of that context.

An underwriting assistant, for example, may need submission details, exposure information, and the organisation’s underwriting guidance. A claims assistant may need the applicable policy wording, claim history, and supporting correspondence. Access should reflect the task and the user’s permissions.

The data foundations established in Phase 1 remain essential. Ownership, validation, and alignment with relevant ACORD standards for data exchange, MRC structures, and CDR requirements for data alignment help maintain consistency. Lineage allows users to trace information to its source and understand whether it is current and appropriate for the activity.

Knowledge and rules also need clear ownership. An AI service using outdated guidance can produce an answer that appears credible but no longer reflects the organisation’s requirements. Maintaining these sources forms part of operating the service.

Analyse, reason, and recommend

AI assistants can bring relevant information together, summarise it, and help users explore questions in natural language. With access to approved sources, it can support tasks such as preparing a submission summary, retrieving policy information, or explaining the contents of a report.

Recommendations need enough supporting context for a person to assess them. This may include source references, the information used, and any gaps or conflicting values that affect the answer. Where a task requires a calculation, the AI can call an approved calculation or analytical service and use its results in the response.

For an internal portfolio query, for example, an assistant could retrieve governed data, invoke an agreed analytical service, and summarise the results. The user should be able to inspect the underlying figures and definitions before relying on the interpretation.

The level of review should reflect the decision. A summary prepared for initial review and a recommendation that could affect cover or a claims outcome carry different consequences and require different controls.

Take action with controls

Agentic AI extends information support into coordinated activity. An agent can use connected services to retrieve records, perform checks, prepare updates, or initiate tasks where it has permission to do so.

For example, a submission agent could check whether required documents are present, retrieve relevant information, and prepare a request for missing details. Depending on the agreed workflow, sending that request may require approval. The agent should escalate conflicting information rather than resolve it through an unsupported assumption.

MCP-connected tools can provide access to defined services. APIs, messaging, and workflow orchestration support the underlying exchanges. Each service must enforce its own permissions and validate requests before accepting an action.

The design needs to establish:

• What persona (Role) the agent has
• What information the agent can access.
• Which tools and actions it can use.
• What requires approval or referral.
• When it must stop or escalate.
• How teams can review its activity and recover from failures.

These limits make the agent’s role explicit and allow the organisation to assess whether its behaviour remains appropriate as the service develops.

Workflow orchestration with delegation, denial, and approval

An agent operates within a wider process. Workflow orchestration coordinates its activities with business rules, system services, and human responsibilities.

Delegation assigns a task within a defined scope. An agent might gather information or prepare an update, while another service performs a calculation and a person approves the resulting action.

Denial prevents an activity from proceeding when permissions, business rules, or required information do not allow it. The workflow should record the reason and provide an appropriate route for resolution.

Approval creates a decision point for an authorised person. That person needs the relevant evidence, the proposed action, and any unresolved issues. The workflow should record the decision before allowing subsequent activity.

Together, these mechanisms support controlled execution across systems. They also clarify who remains accountable when an agent contributes to a process.

Real-time and on-demand AI-powered analysis

Connected services can support analysis when a user asks a question or when a relevant event occurs.

On-demand analysis allows an authorised user to query portfolio information, investigate a change, or request a report through natural language. Governed definitions and approved analytical services help keep the response consistent with established reporting.

Event-driven analysis can begin when new information becomes available. A change to an exposure, a policy update, or a new claims record could trigger a defined check and bring relevant findings to someone’s attention.

The required response time should follow the business need. Some activities benefit from immediate analysis, while scheduled processing remains suitable for others. In both cases, users need to understand the information’s freshness and any limitations affecting the result.

Outcomes across the insurance lifecycle

The intended outcomes include more personalised service, better-informed decisions, proactive risk management, and increased productivity. It ultimately allows organisations to scale without the need for more resources and do more with the same (or less). Connected information can also help organisations identify opportunities that fragmented records make difficult to see.

In broking, AI agents can support submission administration through email and text-based conversations with customers. An agent can receive submission information, validate it against defined requirements, and reply in natural language to request missing details or clarify inconsistencies. It can also provide status updates as the submission progresses and refer exceptions and questions that require judgement to the broker. This reduces routine follow-up work and gives brokers more time to focus on advice, placement, and client relationships.

Internal teams could use the same AI assistant to ask ad hoc questions, curate data sets, prepare BI reports, explore portfolio performance, and investigate data-quality issues. These are potential applications whose value depends on the workflow, available information, and effort required to review and operate the service.

Success should be assessed against the defined outcome. Relevant evidence includes the quality of the result, time saved across the complete activity, correction effort, and operating cost. Human judgement and accountability remain part of the model, with AI supporting the people responsible for insurance decisions and customer relationships.

The technical target operating model

The technical target operating model brings the three phases together in a connected architecture. It shows how infrastructure, applications, integration, data, intelligence, and user experience support one another, providing a foundation for workflows that span internal systems and the wider insurance ecosystem.

Each layer has a distinct role. Clear interfaces between them allow organisations to introduce capabilities incrementally and retain existing systems where they continue to serve the business effectively.

1 Infrastructure layer

The infrastructure layer provides the environment in which applications, data services, and AI capabilities operate. Cloud services support hosting and processing, with security, resilience, observability, and cost optimisation built into their operation.

Security includes managing identities and controlling access between users, applications, and services. Resilience addresses how the organisation maintains or restores a workflow when a component becomes unavailable. Observability gives operational teams the information needed to identify failures and investigate their causes.

Cost optimisation applies across the model. Teams need to understand the resources a workflow consumes, including data processing, integration services, and AI usage, so that they can assess its operating cost alongside its business contribution.

2 Application layer

Core insurance systems, risk placement platforms, and partner and industry systems provide the operational capabilities used throughout the lifecycle. These applications hold records and execute activities such as underwriting, policy administration, and claims handling.

The model allows existing applications to participate through defined interfaces. Modernisation can focus on a capability or connection that limits a priority workflow, with API or agent wrappers providing controlled access to selected legacy functions where appropriate.

Clear responsibilities remain essential. The architecture should establish which application maintains an authoritative record, which service can update it, and how approved changes become available elsewhere.

3 Integration layer

APIs, messaging protocols, event streaming, and workflow orchestration connect applications and coordinate exchanges between them.

APIs expose defined data and business capabilities. Messaging supports exchanges that can complete independently, while event streaming makes changes available to services that need to respond. Workflow orchestration manages the dependencies between activities, including approvals and exception handling.

For example, an approved change in an underwriting system could trigger an update to a downstream application and make the revised information available for reporting. The integration layer needs to track completion, identify failed exchanges, and support recovery without creating duplicate records or actions.

Reusable interfaces allow the same capability to support several workflows where their requirements align.

4 Data layer

The enterprise data platform and single source of truth provide governed information for operational use, analytics, and AI. Agreed definitions, ownership, quality controls, and lineage help consumers interpret that information consistently.

Internal data models should align with relevant ACORD standards, MRC structures, and CDR requirements. Explicit mappings connect those definitions to the structures used by individual applications.

Graph models can represent relationships between entities such as customers, policies, risks, and claims where those relationships support a defined use case. This can help services retrieve connected context while preserving the meaning and provenance of the underlying information.

The data layer also needs to reflect how current information must be for each activity. A reporting process may use an agreed snapshot, while an operational decision may require the latest approved update.

5 Intelligence layer

AI agents, semantic search, decision services, and MCP connections make governed data and application capabilities available for intelligent workflows.

Semantic search helps retrieve information relevant to a question or task. Decision services apply defined logic or analytical models. AI agents can combine retrieved context with approved tools to prepare recommendations and coordinate permitted activities.

MCP provides a consistent interface through which AI applications can access exposed tools and services. The underlying systems remain responsible for enforcing permissions and validating requested actions.

This layer supports both on-demand analysis and decisions that need a timely response to an event. Its design must establish which activities can proceed automatically, what requires approval, and when the service should escalate incomplete or conflicting information.

6 Experience layer

Enterprise notebooks, self-service analytics, and natural-language access give people different ways to work with the connected capabilities beneath them.

Analysts may use notebooks to explore governed datasets and develop analyses. Business users may use self-service analytics to inspect performance through agreed measures. Natural-language interfaces can help authorised users retrieve information, request an analysis, or initiate a defined task.

Each experience needs to preserve the controls of the underlying services. Users should receive information appropriate to their permissions and be able to inspect supporting sources, understand the status of a task, and review proposed actions where approval is required.

The interface should also make uncertainty and exceptions visible. A clear request for clarification or referral helps the user act when the system cannot complete an activity reliably.

Built for change: Open, secure, and composable

The layers work together through interfaces that allow components to evolve independently. An organisation can extend a data service, replace an application, or introduce an AI capability while managing the effect on connected workflows.

An open architecture supports interoperability across internal and external environments. Security governs access and actions throughout those connections. A composable approach allows teams to assemble workflows from defined, reusable capabilities.

The model provides a direction for investment and implementation. Each initiative should improve a specific business activity while contributing capabilities the organisation can maintain, reuse, and extend as its needs develop.

Organisations begin this journey with different systems, capabilities, and constraints. Some still depend on isolated legacy applications and manual exchanges. Others have established common data foundations and are connecting services across their operations and partner networks.

The progression below describes increasing maturity and the opportunity to improve productivity as capabilities develop. An organisation may operate at several levels simultaneously. One workflow may support intelligent services while another still relies on spreadsheets and manual entry.

Siloed operations and the constraints of legacy systems

Information sits in separate applications, with people bridging the gaps through email, documents, spreadsheets, and repeated data entry. Teams often need to reconcile records before they can complete an activity or produce a reliable report.

At this stage, understanding the dependencies around a priority workflow helps identify where fragmentation creates the most effort. Mapping its data sources, systems, and hand-offs provides a basis for focused improvement.

Digitising individual activities across the business

Digital channels and applications make individual activities easier to access and manage. Portals can capture information, electronic records can replace paper files, and local automation can reduce repetitive tasks.

The wider process may still depend on manual transfers between applications. A digitally submitted request, for example, may require someone to copy its contents into an internal system before work can proceed. Further progress depends on connecting these activities and preserving the information between them.

Connecting workflows through common data foundations

Agreed definitions, ownership, and quality controls allow systems and teams to use information consistently. Integration makes that information available across workflows, reducing the need to prepare it repeatedly.

Common data foundations also support internal analysis. Teams can combine relevant information using agreed business definitions, with traceability to the underlying records. Reusable data and integration services provide a basis for extending these improvements to additional workflows.

Bringing intelligence into everyday insurance work

Connected information supports services that help people interpret context and decide what to do next. Search, analytics, and AI assistance become available within the workflow, closer to the activity they support.

An underwriting workbench could bring together submission information, relevant guidance, and approved analytical results for review. An internal reporting service could help users explore portfolio information and investigate changes.

The value of these services depends on the relevance and quality of their outputs, alongside the effort required to assess and use them.

Extending connectivity across the insurance ecosystem

Connectivity extends across organisational boundaries. Internal applications, industry platforms, and partner services exchange information through defined interfaces and agreed data structures.

Organisations can accommodate different channels and levels of digital maturity while applying consistent controls to the information they receive. New services can join a workflow through established interfaces, reducing the need to create a separate connection for every use case.

This requires agreement about responsibilities as well as technology. Participants need to understand who owns the information, which changes they can make, and how they should resolve exceptions.

Expanding autonomy within controlled workflows

As workflows become more connected and dependable, organisations can delegate more routine activity within defined limits. Services and agents can coordinate permitted tasks, respond to events, and progress work without requiring a person to initiate every step.

For example, a workflow could receive submission information, check completeness, request missing details, and prepare the case for review. Exceptions, approvals, and decisions requiring judgement remain with authorised people.

Extending this autonomy depends on evidence that the workflow performs reliably. The organisation needs visibility into its actions, clear operating boundaries, and a way to intervene or recover when something goes wrong.

Embedding AI to deliver trusted data when it is needed

At greater maturity, generative and agentic AI become part of how information is prepared, accessed, and used across everyday work. Generative AI supports extraction and interpretation, while agents coordinate the services needed to bring relevant context into an activity.

Just-in-time data means making the required information available when the workflow needs it, with the quality, freshness, and permissions appropriate to its use. This may involve retrieving an approved record, checking an external source, or identifying missing information before the next step proceeds.

AI also supports earlier stages of the journey. Document extraction can help a fragmented workflow, while an assistant can improve access to knowledge before an organisation achieves wider interoperability. Its role expands as the supporting data, integration, and controls mature.

Progress should follow the needs of the business and the evidence from each implementation. The maturity model helps organisations identify their current constraints, choose the next useful capability, and assess whether greater connectivity and intelligence improve productivity and outcomes.

Progress needs to show how a change improves insurance work. A connected system or a functioning AI service demonstrates technical delivery. Assessing its value requires evidence about the quality of information, the effort involved in completing a workflow, and the experience of the people using it.

Measurement begins with a baseline. Before introducing a capability, establish how the current process performs, including its costs, delays, errors, and manual handling. Define the expected improvement and who will assess it.

Data quality: More trusted information for better decisions

Data quality measures should reflect the information required for a particular activity. Useful indicators include completeness, validation results, conflicting records, and the frequency with which teams need to correct or reconcile information.

For a submission workflow, this could mean tracking how often required fields are missing and how much correction is necessary before underwriting review. For an internal report, it could mean measuring reconciliation effort and the number of discrepancies between contributing sources.

AI-assisted extraction requires additional attention to whether the extracted values match the source and are suitable for downstream use. Review effort should form part of the assessment.

Operational efficiency: Smoother processes with fewer delays and errors

Operational measures show whether connected workflows reduce repeated work and help activities progress more reliably. Relevant indicators include processing time, manual re-entry, rework, exception rates, and time spent waiting between steps.

Measure the complete activity as well as individual tasks. Faster extraction may provide limited benefit if information then waits for review or requires extensive correction.

For example, a submission workflow could track the time from receipt to readiness for underwriting, alongside the number of manual interventions required. A reporting workflow could measure the time from data preparation to an approved report, including reconciliation and review.

Results should distinguish between routine cases and more complex work. This helps teams understand where the approach performs well and where further changes are needed.

Customer experience: Simpler and quicker interactions

Customer experience measures should capture whether changes make it easier for policyholders, brokers, and other users to complete their work or obtain a useful response.

Relevant indicators include response times, repeated requests for information, the number of interactions needed to resolve a query, and feedback on the clarity of communication.

For a broker using an AI agent to support submission administration, this could include how quickly customers receive requests for missing details, whether those requests are accurate and understandable, and whether status updates reduce the need to chase progress.

Speed should sit alongside service quality. A prompt response adds value when it helps the customer understand what is happening and what they need to do next.

Cost and impact: Lower operating costs and measurable business value

Cost measures need to include the resources required to deliver, operate, and maintain the capability. These may include integration services, data processing, AI usage, human review, and ongoing support.

Assess these costs against the improvement achieved. Relevant measures could include cost per transaction, reduced rework, or employee time released for other activities. Where teams gain capacity, establish how they use it before treating it as a financial saving.

Business impact may also include the ability to handle more work, respond sooner to opportunities, or produce information that previously required substantial preparation. Claims about increased revenue or improved retention need their own evidence and should remain separate from directly observed operational results.

AI-enabled workflows also require monitoring of output quality, correction effort, escalation, and failed actions. These measures help establish whether the service remains useful as volumes and use cases change.

Using evidence to guide the next investment

Each initiative should have a defined scope, baseline, expected benefit, and review point. Agree in advance what results would justify extending the approach and what would require further work.

Compare results using consistent definitions and account for differences in transaction volume and complexity. Include the effort required to operate the workflow, so that apparent improvements do not conceal additional work elsewhere.

Measure what matters and adds value. The evidence should help the organisation decide which capabilities to improve, reuse, or extend, and whether the resulting benefit justifies further investment.

A useful starting point is a workflow with a clear business need and enough scope to demonstrate an improvement. Understanding how it operates today helps establish which capabilities are required and how to assess the result.

The following questions connect the immediate challenge with a practical implementation plan.

What is the biggest challenge we need to solve?

Identify where work waits, information requires repeated handling, or teams spend time correcting avoidable problems. Establish who experiences the difficulty and how it affects the wider process.

A submission workflow may involve several rounds of correspondence before it is ready for underwriting. An internal reporting process may require extensive reconciliation before anyone can use the results. Defining the problem at this level gives the initiative a concrete purpose.

Map the current workflow, including the people, systems, documents, and external participants involved. Capture exceptions and approvals alongside the usual sequence of activities.

Do we have the right data to solve it?

Establish what information the workflow requires, where it originates, and whether it is accessible at the point of use. Check its definitions, ownership, quality, and permissions.

The assessment should reveal which sources are authoritative, where values conflict, and which information still arrives in documents or correspondence. It should also establish how relevant industry standards and market requirements inform the data model.

For an internal reporting use case, this means checking whether contributing datasets use consistent definitions and reporting periods. For a submission workflow, it means identifying the information needed at each stage and how teams will validate it.

Addressing these requirements within a focused use case can create foundations that support further applications.

Which workflows would deliver the most value if automated?

Look for activities with repeated handling, clear rules, and a measurable operational cost. Assess the frequency of the activity, the effort involved, and the consequences of errors.

Consider the complete workflow. Automating a transfer may save little time if the receiving team still needs to reconcile every record. Connecting the transfer to validation and exception handling may create a more useful improvement.

The assessment should distinguish predictable activities from those requiring interpretation, negotiation, or judgement. This helps define the scope of automation and the points where a person needs to act.

What role can AI realistically play now?

Identify where extraction, summarisation, retrieval, or task coordination could help address the defined problem.

Generative AI may support the preparation of information from documents or make relevant knowledge easier to access. Agentic AI may coordinate permitted activities across connected services, such as checking submission completeness and requesting missing details.

Assess whether the required sources and tools are available, how outputs will be checked, and what actions require approval. Include the effort needed for review and exception handling when estimating the benefit.

A focused pilot can test these assumptions using representative cases. Its results should establish whether the capability improves the workflow and what further work is necessary before wider use.

What do we need in place to scale?

Scaling requires dependable data, maintainable connections, and clear operational ownership. Teams need to understand how the workflow behaves when volumes increase, information is incomplete, or a connected service fails.

Establish who maintains data definitions and business rules, who supports the integrations, and who monitors AI behaviour. Define how teams investigate errors, introduce changes, and recover interrupted work.

Reuse should follow a review of the next use case’s requirements. A service developed for one workflow may provide a useful starting point, but differences in permissions, data quality, or approval rules may require changes.

Turning the assessment into a practical roadmap

Organisations will begin from different positions. Some need stronger data foundations. Others have established data platforms but fragmented workflows. Some are ready to test AI within a defined process.

Under the acronym CREATE, this practical roadmap connects the immediate business need with the capabilities required to address it.

The future of digital insurance depends on how effectively organisations connect information, systems, and activity across the insurance lifecycle.

Govern data so it can be trusted and reused. Common definitions, ownership, and quality controls provide a dependable foundation for operational processes, analytics, and AI.

Connect systems and partners through flexible integration. Existing applications, industry platforms, and partner services need to exchange information in ways that accommodate different levels of digital maturity.

Automate repeatable hand-offs, with clear routes for human review and decisions. Connected workflows can reduce repeated effort while keeping exceptions visible and responsibilities clear.

Apply AI where it improves a defined decision or outcome. Generative AI can help prepare and interpret information, while agentic AI can coordinate permitted activities across connected services.

Connected data enables automation. Automation creates scale. Intelligence turns scale into advantage.

To show how this approach can work in practice, we plan to develop a companion whitepaper featuring practical examples of services that Vega IT and our partners offer. It will explore how those services support the data foundations, integration, automation, and AI capabilities described here, helping organisations connect this direction with concrete opportunities in their own operations.