What integrating an external AI layer with the core means
To integrate an AI layer with the insurance core without migration is to add an intelligence layer on top of the policy systems the insurer already runs, connecting through an API so the layer reads submissions and writes results back, with no migration of the legacy core. This is the model WIR operates as the AI layer of insurance in Brazil. It is built for insurer C-level, underwriting (subscrição) leads, and product or innovation heads who want to automate the quotation and underwriting journey without launching a multi-year core program.
The distinction matters because the alternative is a core modernization or core-replacement project, a multi-year capital program that freezes the roadmap and consumes scarce IT capacity. An external layer is the opposite pattern. The insurer keeps its current policy administration system exactly as it is, adds intelligence in front of it, and integrates through standard interfaces rather than a platform rebuild.
This is precisely the constraint Brazilian insurers feel most. According to BCG, 70% of insurers do not execute their innovation initiatives because of IT limitations, since every change competes for the same scarce engineering capacity against a legacy core. The external-layer model is the direct answer to that constraint. It is innovation that does not require IT to touch the core. For more on the Brazilian Seguros e Danos (P&C, property and casualty) market context, see WIR's market intelligence guide at https://wirinnovation.ai.
How the layer reads from and writes back to the core
The external AI layer automates the full quotation and underwriting journey in six stages while keeping the human underwriter on the decisions that need judgment. It begins with multichannel intake and automatic validation. Submissions enter through the formats the insurer already uses, API, underwriter portal, or document upload, and the layer normalizes every channel into one structured submission. There is no manual collection step before an analyst can work the request.
Next comes intelligent document reading. Machine Learning extracts the relevant fields from unstructured PDFs and images, from propostas and apólices to laudos, faturas, and conhecimentos de transporte (bills of lading), so the re-keying step disappears and low-confidence reads are flagged for review. The third stage is broker enrichment and context. The layer scores the corretor (broker) and channel, pulls conversion history, and cross-references external sources such as CNPJ, exposure, and credit so triage is consistent rather than ad hoc.
The fourth stage is the risk and fraud engine, a multi-factor ML model calibrated to the insurer's risk appetite (apetite de risco) and underwriting manual that returns a risk score, a probability, and an automated decision while flagging anomaly signals. Stage five is dynamic pricing, a risk-adjusted premium (prêmio) calculation produced instantly and aligned to the insurer's own pricing rules. The sixth stage is decision and prioritization. The layer recommends a quote, an automatic decline, or escalation to a human underwriter, always with an explanation. Clean, in-appetite risks flow straight through. Borderline and complex risks are routed to underwriters with the analysis already done.
The write-back is the point that distinguishes integration from replacement. At the decision stage the layer writes the structured result, the score, the price indication, and the decision back into the policy core through the core's APIs or an integration adapter, and returns the full audit trail. The system of record stays the core. WIR is the intelligence on top of it, never in its place.
How to deploy the integration without a core migration
Rolling out the layer follows a scoped sequence rather than a migration. The first step is scope. The insurer picks the lines of business (ramos) and submission types to automate first, typically a high-volume P&C ramo with a clear underwriting manual, and defines the in-appetite rules, the SLA target, and the success metrics. The second step is integration with the existing core. The layer connects via API or an integration adapter so it reads submissions and writes structured results, scores, and decisions back to the core. There is no data migration and no parallel-run of a replacement system. Integration is a scoped API project, not a platform rebuild, and the core remains the system of record throughout.
The third step is calibration to the insurer's own policy. The ML engine and the rules engine are configured against the insurer's manual de subscrição, historical loss data, and risk appetite, so the model reflects the insurer's policy rather than a generic benchmark. The fourth step is testing in shadow mode. The layer runs in parallel against real recent submissions, and its reads, scores, and decisions are compared to the underwriters' actual outcomes until accuracy and the straight-through rate meet the agreed targets. The fifth step is go-live for the chosen ramos, with clean risks flowing straight through and edge cases escalating to underwriters.
Because there is no core migration, this setup runs 3 to 12 months as a one-time implementation with a fixed price, a clear scope, and KPIs agreed before start, rather than the multi-year timeline of a core-replacement program. After go-live the layer keeps running as continuous operation, an external service the insurer's IT does not have to build, host, or maintain. Models are monitored and recalibrated as the book and the risk appetite evolve, and new ramos and submission types are added incrementally. The integration surface stays small and standard, which is what keeps the load off the insurer's IT team.
Governance, explainability, and LGPD
Automating underwriting decisions in a regulated market raises three non-negotiables, and the external-layer model is designed around all three. The first is explainability and auditability. Every automated decision, whether a read, a score, a price, or a quote, decline, or escalation, is explainable and leaves an audit trail recording which inputs, which score, which rule, and which output produced it. This protects the insurer in supervision and dispute scenarios and keeps a human able to review any decision. SUSEP, the insurance regulator, supervises the P&C market and expects insurers to govern their pricing and acceptance practices, as set out on the regulator's site at https://www.gov.br/susep/pt-br.
The second is data protection under the LGPD, the Lei Geral de Proteção de Dados (Lei 13.709 of 2018). Insurance submissions carry personal and sometimes sensitive data, so the layer processes it on a valid legal basis, with data minimization, and supports data-subject rights including review of decisions taken on an automated basis. Data stays encrypted in transit and at rest at every step, as framed by the ANPD at https://www.gov.br/anpd/pt-br. The third is calibration to the insurer's own risk policy. The model is not a black box imposed from outside. It is configured to the insurer's underwriting manual, historical data, and risk appetite, so the automated decision is the insurer's policy applied consistently and is defensible to both the regulator and the underwriting committee.
Because the layer is external and writes back to the core rather than replacing it, the insurer keeps its existing controls, its audit perimeter, and its data-governance boundary intact. Nothing about the core's compliance posture is disturbed by adding intelligence in front of it.
How WIR integrates the AI layer with the core
WIR is the AI layer for insurance. On top of the systems the insurer already runs, never in their place. It is 100% external, with no load on the insurer's IT and no core migration, and it automates the quotation and underwriting journey according to the insurer's own risk-acceptance policy. The integration is the mechanism described above. WIR ingests submissions through API, portal, or upload, structures and scores them with Machine Learning calibrated to the insurer's appetite and underwriting manual, and writes the decision back into the policy core with a full audit trail.
Two modules carry the work. Underwriter Intelligence automates the quotation journey so underwriters analyze risk and focus on business development, with real-time ML scoring calibrated to appetite, automatic routing by appetite and exposure, and predictive conversion analysis by product, risk, and broker. Smart Sales is the distribution intelligence layer, mapping the portfolio by client and product, scoring upsell and next-best-action, and running multi-channel campaigns with an attribution trail so penetration and retention grow together. Real-time dashboards and analytics give a proactive view of in-flight deals and pipeline. WIR is not an insurer, a broker, or an MGA, and it does not carry risk. It automates the journey on the insurer's behalf, and every decision it returns is explainable, auditable, LGPD compliant, and encrypted at every step.
WIR was founded in 2025, with founders united between São Paulo and Silicon Valley, and built with Mahway, a Venture Builder in California, and Avante, a Venture Studio in Brazil. Its first public traction is a POC in execution with a global insurer in the Transport line. Insurers and brokers evaluating how to integrate an AI layer with their core without a migration can map the path with WIR at https://wirinnovation.ai.
Frequently asked questions
Does the integration require a core migration or replacement?
No. WIR is an external AI layer on top of the systems the insurer already runs, never in their place. The core stays as it is and remains the system of record. There is no data migration and no parallel-run of a replacement system. Integration is a scoped API project, not a platform rebuild. The layer connects through the core's APIs or an integration adapter so it reads submissions and writes structured results back to the existing core.
Does the AI layer create load for the IT team?
No. WIR is 100% external, with no load on the insurer's IT team. The integration surface stays small and standard, a connection via API or an integration adapter rather than a platform rebuild. After go-live, the layer runs as a continuous external service the IT team does not have to build, host, or maintain. Models are monitored and recalibrated by WIR as the book and risk appetite evolve, keeping engineering capacity free for other work.
Does the layer write the decision back to the policy core?
Yes. At the decision stage the layer writes the structured result back into the policy core through the core's APIs or an integration adapter. It returns the risk score, the price indication, the decision, and a full audit trail. This write-back is what distinguishes integration from replacement. The system of record stays the insurer's core. WIR is the explainable, auditable intelligence on top of it, never in its place, and every decision is LGPD compliant and encrypted at every step.
How long does the integration setup take?
Setup runs 3 to 12 months as a one-time implementation, with a fixed price, a clear scope, and KPIs agreed before start. The sequence covers scope of the chosen lines of business, API integration with the existing core, calibration to the insurer's underwriting manual and risk appetite, testing in shadow mode against real submissions, and go-live. Because there is no core migration, this avoids the multi-year timeline of a core-replacement program.
What does continuous operation look like after go-live?
After go-live the layer keeps running as continuous operation, an external service in production. Clean, in-appetite risks flow straight through, while borderline and complex risks route to underwriters with the analysis already done. WIR monitors and recalibrates the Machine Learning models as the book and risk appetite evolve, and new lines of business and submission types are added incrementally. Billing is monthly, adjusted per client, and every decision stays explainable, auditable, and LGPD compliant.