Technology
Assurtech AI delivers a cloud-native insurance platform architecture with modular services, APIs, EDI, secure infrastructure, resilience, logging and enterprise-grade scalability.
The technical architecture is based on four core principles:
The platform is not a monolith. It is organised around interconnected specialist services. Each functional domain is isolated to limit side effects, support change, strengthen security and preserve long-term technical consistency.
The platform relies on a structured Azure cloud environment.
Environments are strictly separated: Development, Staging / Test, Production.
Resources are organised according to:
The objective is to guarantee environment isolation, control of access and audit capability.
The architecture is organised around specialised services:
Each service exposes APIs, has its own responsibilities, keeps its own logs and integrates through controlled mechanisms.
This organisation enables independent module evolution, functional resilience and targeted scalability.
A SaaS platform for insurance brokers cannot be designed like a standard business application. It must support complex workflows, sensitive document flows, auditability requirements and demanding security controls.
In a brokerage environment, the technical architecture must support policy management, claims handling, document structuring, third-party reference data, compliance controls and interoperability needs with the insurance ecosystem.
This reality requires a modular software architecture that can isolate responsibilities, secure processing and evolve business domains without weakening the platform as a whole.
The objective is not technical performance alone. The objective is to build a durable software infrastructure that is operable, auditable and compatible with the requirements of a regulated sector.
Architectural robustness is not a secondary concern. It directly shapes the operational quality and credibility of the product.
Choosing an Azure cloud architecture reflects a logic of control, separation of environments and operational security.
Cloud infrastructure is not merely a hosting layer. It directly contributes to the system’s security, auditability and resilience.
An insurance brokerage platform must be able to interact with third-party systems without creating new information gaps.
Interoperability relies on clear APIs, controlled flows and the ability to integrate structured exchanges with insurers, partners and peripheral services.
In the insurance sector, this also includes EDI flows, external data integration, synchronization of selected reference data and the reduction of duplicate data entry.
A well-designed architecture makes it possible to open the system without losing control over the consistency, security and traceability of exchanges.
Interoperability is not an afterthought. It must be designed as a native property of the platform.
A cloud-native architecture is not judged only by technological modernity. It is judged by its ability to remain stable, readable and evolvable as usage, data volumes and constraints increase.
Meaningful scalability is not only quantitative. It also concerns the system’s ability to grow without losing control.
In a regulated environment, the quality of an architecture is also measured by its ability to produce usable traces.
Technical logging, separation of responsibilities, identification of significant events and structured retention of logs improve the readability of the processing performed.
This technical auditability supports security, supervision, incident analysis and demonstrability in the event of internal or external control.
It also provides a valuable foundation for evolving the platform more safely, because system behaviors become observable and documentable.
An auditable platform is a platform that is easier to govern, easier to maintain and more credible.
Functional representation of the main flow:
When AI is involved:
Every significant step generates a trace.
The business interface relies on a structured web application, process-oriented components, validated forms and a clear separation between business data and display. The objective is to reduce input errors, structure workflows and embed compliance controls directly into the user experience.
Internal exchanges rely on REST or GraphQL APIs depending on the needs, controlled flow orchestration and asynchronous mechanisms where necessary. Critical communications are isolated and logged. Calls between services are: authenticated, controlled and limited to defined responsibilities.
Business data (policies, claims, reference data) is stored in a structured relational database. The principles applied are: data normalization, integrity constraints, controlled indexing and historization where necessary. This organisation enables consistency of business objects, efficient querying and limitation of inconsistencies.
Documents are stored in an object storage system. Each document has a unique identifier, is linked to a business object, can be versioned and keeps an integrity hash. The separation between structured data and binary documents is intentional. It enables scalability, security and differentiated lifecycle management.
Logging includes application logs, access logs, administration logs and logs related to AI interactions. Logs are centralised, protected against alteration and retained according to a defined policy. This organisation guarantees: auditability, investigative capability and full traceability.
The AI architecture relies on a RAG (Retrieval-Augmented Generation) mechanism. Components: 1. Query analysis, 2. Vector search in the corpus, 3. Contextual filtering, 4. Injection into the model, 5. Controlled generation, 6. Cited output. The queried corpus is: selected, versioned and structured. It is not an open-ended query.
The Knowledge Graph structures: risk concepts, types of damage, relevant assets and relationships between business objects. This model reduces: ambiguities, interpretation errors and semantic confusion. AI does not rely solely on textual probabilities. It relies on explicit structuring of the domain.
The AI service is isolated from the transactional core. It cannot: directly modify business data, validate an action without confirmation or act without logging. Any generated action requires validation.
Access is individual, subject to strong authentication and managed by roles. Rights are granted according to responsibilities, the principle of least privilege and segregation of duties where necessary.
Communications are encrypted, secured and controlled. Technical secrets are not stored in code, are centralised and may be subject to rotation.
The platform implements regular backups, retention policies and restoration tests. Critical services are designed to limit interruptions, isolate incidents and enable recovery.
Services can be sized independently. This makes it possible to absorb increased load, adapt resource consumption and maintain overall performance.
The modular architecture makes it possible to add business rules, integrate new controls and adapt workflows. Regulatory changes do not require a complete redesign.