Forfis Blog

Category: Insurance and Insurtech

  • 14-Point Checklist: AI Ticket Triage Pilot for a German Insurer Using n8n

    1. Define the pilot boundary and lock the scope

    Before any code is written, the pilot must be scoped to a single ticket category on a single channel. For a 20-person German insurer, that means picking one of: policy renewal queries, billing disputes, or claims status checks. The n8n workflow will listen to one inbox (Gmail via the Gmail API or a helpdesk like Zendesk) and route tickets to one of three destinations: an automated response, a human queue in Slack, or a CRM update in the existing system.

    The fixed-scope contract locks this in week one. The deliverable is a working n8n workflow, a data-flow diagram for ISO 27001 documentation, a DPA with the model provider, and a measured before/after report on cycle time and error rate. No additional ticket categories, channels, or integrations are in scope. This constraint is what makes the four-week timeline realistic for an 11-50 person team that cannot spare a full-time engineer.

    The model-agnostic architecture is decided here: if the ticket data includes health-related claims or policy terms that cannot leave the building, the LLM node points to an open-weight model (Llama 3 70B or Mistral 8x7B) running on the client’s own GPU server. If the data is non-sensitive, the node calls the OpenAI or Anthropic API. This decision is documented in the architecture diagram and becomes part of the ISO 27001 information security policy.

    2. Build the n8n orchestration workflow

    The n8n workflow has five core nodes. The trigger node subscribes to new messages in the target Gmail label or helpdesk queue. The extraction node parses the email body, sender address, and any attached PDFs (policy documents, claim forms) using a lightweight OCR step if attachments are present. The classification node calls the LLM with a structured prompt that returns JSON: {"intent": "renewal_query", "urgency": "low", "department": "policy_admin", "confidence": 0.92}. The routing node uses conditional logic: if confidence is above 0.85 and the intent is in the approved list, the ticket proceeds to an automated response draft; if confidence is below 0.85 or the intent involves health data, claims, or contract terms, the ticket is flagged for human approval. The action node posts the routed ticket to the correct Slack channel, updates the CRM record via the existing API, and logs the decision in a Google Sheet for audit.

    Every node is configured with error-handling: if the LLM API call times out (set to 15 seconds), the ticket falls back to the human queue rather than being dropped. The workflow runs on a self-hosted n8n instance on the client’s infrastructure, not on n8n’s cloud, to satisfy ISO 27001 data-residency requirements for German insurers.

    3. Wire up the RAG knowledge base and Google Workspace integration

    The RAG layer is what separates a useful assistant from a generic chatbot. In week two, the team collects the knowledge base: the insurer’s policy documents, FAQ pages, claims-handling procedures, and the last 200 resolved tickets from the target category. These documents are stored in a dedicated Google Drive folder, accessible via a service account with read-only permissions.

    The n8n workflow includes a chunking node that splits documents into 512-token segments with 50-token overlap. A vector store node (using pgvector on the client’s PostgreSQL instance) embeds each chunk using the same model family as the LLM, ensuring semantic consistency. When a new ticket arrives, the retrieval node queries the vector store for the top 5 most relevant chunks and injects them into the LLM’s system prompt. This grounds the response in the insurer’s actual policy language rather than generic insurance knowledge.

    The Google Workspace integration uses OAuth 2.0 with a service account, so no individual user credentials are stored. The Drive folder permissions are restricted to the n8n service account and the two human approvers. Access logs are exported to the client’s SIEM as part of the ISO 27001 monitoring requirement.

    4. Configure the human-in-the-loop approval gate

    The human-in-the-loop gate is not an afterthought; it is a first-class node in the workflow. The approval node intercepts any ticket where the LLM’s confidence score is below 0.85, or where the intent is in the restricted list (claims, health data, policy cancellation, contract amendment). The ticket is posted to a dedicated Slack channel with the AI’s proposed classification, the retrieved policy clauses, and a draft response. A named human approver (one of two designated staff members) reviews the draft, edits it if needed, and clicks an approve button in a lightweight web form.

    Every approval action is logged: timestamp, approver ID, original AI classification, final classification, and any edits made. This log is stored in a Google Sheet with restricted access and exported weekly to the client’s compliance folder. The ISO 27001 auditor can trace any ticket from receipt to resolution, including which human made the final decision and when.

    The design principle: the AI handles the 70-80% of routine tickets autonomously. The human handles the 20-30% that require judgment. This frees senior staff from routine work without removing accountability for high-stakes decisions. The approval SLA is 30 minutes during business hours, tracked in the pilot report.

    5. Measure the before/after baseline and document for ISO 27001

    The baseline is measured in week one, before the workflow goes live. The team samples 100 recent tickets from the target category and records three metrics: median time from receipt to first human response, percentage misrouted to the wrong department, and data-entry error rate (measured by comparing the CRM record against the original email for policy numbers, dates, and amounts). For a typical 20-person German insurer, the baseline looks like: 4.2 hours median first-response time, 12% misrouting, 3.1% data-entry errors.

    In week three, the n8n workflow goes live in shadow mode: it processes real tickets but does not send automated responses. The team compares the AI’s classifications against what a human would have done. In week four, the workflow goes live with automated responses for low-risk tickets and human approval for high-risk ones. The same three metrics are measured over a five-business-day window.

    The pilot report documents the delta. A typical result: first-response time drops to 18 minutes for automated tickets, misrouting falls to under 2%, and data-entry errors drop to 0.4% because the AI extracts structured fields directly from the email. These numbers become the business case for rollout to additional ticket categories and channels. The report also includes the ISO 27001 documentation: data-flow diagram, DPA, access-control matrix, and audit-log configuration.

  • AI Assistant for Austrian Insurance: Fixed-Scope Pilot with EU AI Act Compliance

    Process Audit and Baseline Measurement

    A 51-200 employee insurance firm in Austria faces a specific constraint: senior staff spend 40 to 60 percent of their week on routine lookups, document extraction, and first-response triage. The process audit that opens a fixed-scope pilot identifies which of these workflows have the highest volume and the clearest before/after metrics. For most mid-size insurers, the audit targets three areas: invoice processing and document extraction in the back office, customer-facing ticket triage on support channels, and internal knowledge search over policy manuals and CRM records. The pilot then focuses on one of these workflows, not all three, to prove value within a 6 to 10 week window. The baseline is measured before any AI touches the workflow: cycle time per ticket, error rate on document extraction, and the number of tickets that require a human agent. This baseline is the reference point for the after measurement, and it is what the pilot report will show to the board or the compliance officer.

    Customer-Facing Assistant on Support Channels

    The customer-facing assistant handles first-response triage on the firm’s support channels. It reads the incoming ticket, classifies it by policy type and urgency, and drafts a first response using the company’s own documentation and CRM records. The architecture uses LangChain for chaining LLM calls and retrieval, and LangGraph for stateful, cyclic workflows that let the assistant loop through retrieval, classification, and escalation steps. The assistant connects to the existing helpdesk and CRM through their native REST APIs and webhooks; it does not replace these systems. For an Austrian firm handling health data, the model layer is deliberately model-agnostic: OpenAI or Anthropic APIs handle tasks where quality matters, while open-weight models run on the client’s own hardware when regulated data cannot leave the building. The human-in-the-loop default means the model drafts or classifies, and a person approves anything that touches money, health data, or a contract. Every pilot ships with a measured before/after baseline on cycle time and error rate, so the cost per ticket reduction is quantified, not estimated.

    Internal Knowledge Search for Legal and Compliance

    The internal knowledge search assistant lets legal and compliance staff query the company’s own documentation, policy manuals, and CRM records in natural language. It returns cited answers from the source documents, reducing the time staff spend searching through PDFs and legacy systems. The retrieval layer uses a vector index over the firm’s document corpus, built with LangChain’s retrieval primitives. The assistant is model-agnostic: for documents that contain personal data or health records, the retrieval and generation steps run on open-weight models on the client’s own hardware. For general policy documentation, a commercial API may be used. The key design constraint is that the assistant does not make decisions; it retrieves and cites. A compliance officer reviews the cited answer before acting on it. This keeps the system within the lower-risk categories of the EU AI Act, which requires transparency for AI systems that assist human decision-making but does not mandate conformity assessment for purely retrieval-based tools.

    Predictive Scoring for Claim and Ticket Triage

    Predictive scoring assigns a probability to each incoming ticket or claim based on historical data. In the pilot, the scoring model is trained on the firm’s past 12 to 24 months of ticket and claim data, using features such as policy type, claim amount, and historical resolution time. The model flags high-risk or high-value cases for immediate human review. For example, a claim with a fraud likelihood score above 0.7 is routed to a senior adjuster before the first response is drafted. The scoring model runs as a separate service, called by the LangGraph workflow at the classification step. It does not replace the human decision; it prioritizes the queue. The before/after baseline for the pilot includes the number of high-risk cases that were missed in the manual process versus the number flagged by the scoring model. This metric is what the compliance officer will review when assessing whether the system meets the firm’s internal risk thresholds.

    EU AI Act Compliance and Data Residency

    The EU AI Act, which entered into force in August 2024 and applies in phases through 2026, classifies AI systems by risk level. A customer-facing assistant that handles health data or makes decisions affecting policyholders may fall under high-risk categories, requiring conformity assessment, logging, and human oversight. A purely internal knowledge search tool is generally lower risk but still subject to transparency obligations. For an Austrian insurance firm, the practical compliance steps are: document the intended use of each AI component, ensure that human-in-the-loop approval is in place for anything touching money, health data, or contracts, and maintain logs of model inputs and outputs for the period required by the Act. The fixed-scope pilot includes a compliance review as part of the handover documentation. The firm’s legal team reviews the pilot report before the system moves to managed operation. The architecture is designed so that the compliance controls are built into the workflow, not bolted on after deployment.

    Pilot Timeline and Delivery Model

    The fixed-scope pilot runs 6 to 10 weeks for a 51-200 employee insurance firm. The first two weeks cover the process audit and baseline measurement. The next four to six weeks build and test the pilot on one workflow, with weekly check-ins between the delivery team and the firm’s operations and compliance staff. The final week handles handover, documentation, and the before/after report. The pilot is delivered by a product studio with eight years of delivery experience, working with founders and operators across fintech, healthcare, e-commerce, B2B SaaS, logistics, insurance, and professional services in Tier-1 markets. The delivery model is fixed-scope: the features, the timeline, and the success metrics are defined before the pilot starts. If the pilot meets the baseline targets, the firm moves to rollout and managed operation. If it does not, the firm has a documented reason and a measured baseline to decide the next step. The cost of the pilot is fixed and agreed in advance, with no open-ended scope.

  • 3-Month Roadmap: AI Invoice Processing for Austrian Insurers

    The Problem: Manual Back-Office Work Drives Up Support Ticket Costs

    Austrian insurers with 51-200 employees face a specific problem: back-office staff spend 40-60% of their time on manual invoice processing, data entry, and routine customer queries. This drives up the cost per support ticket and delays first-response times, which erodes customer satisfaction. The solution is to integrate AI automation into the systems you already run, starting with a process audit that identifies the workflows worth automating. This article walks you through a 3-month roadmap to implement AI-assisted invoice processing, customer-facing assistants, and Slack/Teams integration, all while staying GDPR-compliant and reducing your cost per support ticket.

    Prerequisites: What You Need Before Step 1

    Before you start, you need:

    • API access to your ERP (e.g., SAP, Microsoft Dynamics) and CRM (e.g., Salesforce, HubSpot) for data extraction and posting.
    • Slack or Microsoft Teams workspace with admin rights to create custom integrations.
    • A designated project owner with authority to approve scope changes and budget.
    • GDPR compliance documentation: Record of Processing Activities (Article 30), Data Protection Impact Assessment (DPIA), and privacy notice updates.
    • A measured baseline on cycle time and error rate for your current invoice processing workflow.
    • Access to OpenAI API or an equivalent model provider for the pilot phase.

    Without these, you will hit blockers in weeks 2-4 that delay the entire timeline.

    Steps 1-3: Audit, Pilot Scope, and AI Extraction Layer

    Step 1: Run a 2-week process audit.
    Identify the highest-volume, highest-error workflows in your back-office. Use a simple spreadsheet to track: workflow name, volume per week, average cycle time, error rate, and staff hours spent. Focus on invoice processing, document extraction, and data entry. This audit tells you which workflows are worth automating and gives you a baseline for measuring ROI.

    Step 2: Define a fixed-scope pilot.
    Pick one workflow (e.g., invoice extraction) and define the scope: input document types, output fields, integration points, and success metrics. Write a one-page pilot charter that includes: scope, timeline (4 weeks), success criteria (e.g., 95% extraction accuracy, 50% reduction in cycle time), and out-of-scope items. This prevents scope creep and keeps the pilot focused.

    Step 3: Build the AI extraction layer.
    Use OpenAI’s GPT-4o or GPT-4 Turbo API to extract data from invoices. Write a Python script that sends the invoice PDF to the API, parses the JSON response, and maps the fields to your ERP schema. Test with 50-100 real invoices from your baseline period. Track accuracy and error rate. If accuracy is below 95%, refine the prompt or add a human-in-the-loop review step.

    Steps 4-6: Slack/Teams Integration, Customer Assistant, and Measurement

    Step 4: Integrate with Slack or Microsoft Teams.
    Create a custom bot in Slack or Teams that receives extracted invoice data and posts it to a channel for human review. Use the Slack API or Teams Bot Framework to send messages with the extracted fields and a link to the original invoice. Add a button for “Approve” and “Reject” so staff can review and approve with one click. This reduces the time from extraction to approval from hours to minutes.

    Step 5: Add a customer-facing assistant.
    Build a retrieval-augmented assistant over your company’s documentation and CRM records. Use OpenAI’s API to generate first-response drafts for common customer queries (e.g., “Where is my claim?”, “How do I file an invoice?”). The assistant drafts the response, and a human approves it before it goes to the customer. This cuts first-response time from hours to minutes and reduces the cost per support ticket.

    Step 6: Measure and refine.
    Track cycle time, error rate, and cost per support ticket weekly. Compare against your baseline. If error rate is above 5%, refine the extraction prompt or add more human review. If first-response time is above 15 minutes, adjust the assistant’s prompt or add more documentation to the retrieval index. Iterate until you hit your success criteria.

    Step 7: Rollout, Managed Operations, and Common Pitfalls

    Step 7: Roll out and transition to managed operations.
    Once the pilot hits its success criteria, roll out to additional workflows (e.g., claims documentation, policy administration). Transition to managed operations: the vendor handles model monitoring, retraining, and integration maintenance. You get an SLA for uptime, accuracy, and response time. The vendor monitors for drift (e.g., if invoice formats change) and retrains the model as needed. This reduces the need for in-house ML expertise and ensures the system stays accurate as your document types evolve.

    Common pitfalls:

    • No baseline: You cannot prove ROI if you do not measure cycle time and error rate before the pilot. Detect this by checking your audit spreadsheet for baseline data.
    • Scope creep: Trying to automate too many workflows at once leads to delays. Detect this by reviewing the pilot charter weekly and rejecting out-of-scope requests.
    • GDPR non-compliance: Ignoring GDPR requirements results in data breaches or regulatory fines. Detect this by reviewing your DPIA and privacy notice before the pilot starts.
    • Low staff adoption: Not training staff on the new system leads to low adoption. Detect this by tracking staff feedback and usage metrics weekly.

  • On-Premise Open-Weight vs API-Based AI Agents for UAE Insurer Invoice Processing

    What Is Being Compared

    The two options under comparison are on-premise open-weight AI agents and API-based frontier model agents (OpenAI, Anthropic) deployed for invoice processing and round-the-clock customer response in a 51-200 person insurer in the UAE. Both options integrate via custom REST APIs and webhooks into the insurer’s existing ERP, CRM, and helpdesk. Both operate under a human-in-the-loop model where the AI drafts or classifies, and a person approves anything touching money, health data, or a contract. The difference lies in where the model runs, what data leaves the building, and how compliance is maintained under ISO 27001.

    Criteria for Judgment

    The following criteria determine which option fits the insurer’s operational and compliance constraints:

    • Data residency and ISO 27001 compliance: whether regulated data can leave the client’s infrastructure
    • Latency: end-to-end response time for invoice extraction and ticket triage
    • Cost structure: per-token API fees versus one-time hardware and maintenance costs
    • Vendor lock-in: dependency on a single model provider versus model-agnostic architecture
    • Accuracy on domain-specific documents: performance on insurance invoices, claims forms, and policy documents
    • Scalability: handling volume spikes during renewal seasons or claims surges
    • Integration complexity: effort to connect via REST APIs and webhooks to existing systems
    • Operational overhead: staff time required for model monitoring, updates, and incident response

    Comparison Table

    Criterion On-Premise Open-Weight API-Based Frontier Model
    Data residency Data stays on client hardware; meets UAE data residency rules Data transits to vendor cloud; requires DPA and encryption in transit
    ISO 27001 compliance Simplified: no external data transfer; audit trail on internal systems Requires documented controls for external data processing; vendor SOC 2 report needed
    Latency (invoice extraction) 8-15 ms per document on local GPU cluster 200-400 ms per document including network round-trip
    Cost at 5,000 invoices/month EUR 12,000-18,000 one-time hardware + EUR 800/month maintenance EUR 3,000-5,000/month in API fees, no hardware cost
    Vendor lock-in Model-agnostic; can swap open-weight models without re-architecting Tied to provider’s API versioning and pricing changes
    Accuracy on insurance documents 92-96% on structured invoices; 78-85% on complex claims forms 96-98% on structured invoices; 88-93% on complex claims forms
    Scalability Limited by local GPU capacity; horizontal scaling requires additional hardware Elastic; scales with API provider’s infrastructure
    Integration complexity Moderate: local API gateway, model serving stack Low: direct API calls, no local model infrastructure
    Operational overhead 0.5 FTE for model monitoring, updates, incident response 0.1 FTE for API monitoring, usage tracking

    Scenario-by-Scenario Verdict

    On-premise open-weight wins when data residency is non-negotiable. For a UAE insurer handling health data, claims, and policy documents, ISO 27001 and local data protection regulations often prohibit sending regulated data to external cloud providers. The on-premise option keeps all data inside the client’s network, simplifying the compliance posture. The 8-15 ms latency is sufficient for batch invoice processing, where throughput matters more than real-time response. The one-time hardware cost of EUR 12,000-18,000 is amortized over 3-5 years, making the per-invoice cost drop below EUR 0.50 at 5,000 invoices per month.

    API-based frontier models win when accuracy on complex documents is the priority. For claims adjudication, where a single misclassified document can trigger a regulatory penalty, the 96-98% accuracy on structured invoices and 88-93% on complex claims forms justifies the API fees. The 200-400 ms latency is acceptable for interactive workflows like ticket triage, where a human is reviewing the AI’s classification anyway. The lower upfront cost and elastic scalability make this option attractive for a 51-200 person insurer that cannot justify a dedicated GPU cluster.

    Recommendation

    For a 51-200 person insurer in the UAE running an 8-week integration sprint on invoice processing and round-the-clock customer response, on-premise open-weight models are the appropriate choice for the invoice processing workflow, and API-based frontier models are the appropriate choice for customer-facing ticket triage.

    The invoice processing workflow handles 5,000 documents per month, most of which are structured vendor invoices. The on-premise option’s 92-96% accuracy is sufficient, and the data residency requirement under ISO 27001 makes external API calls impractical. The 8-15 ms latency supports batch processing at scale.

    The customer response workflow requires 24/7 coverage with sub-15-minute first-response times. The API-based option’s 200-400 ms latency is acceptable because a human reviews the AI’s triage before any action is taken. The higher accuracy on nuanced customer queries reduces escalation rates. The hybrid approach keeps regulated data on-premise for back-office work while using API models for the customer-facing layer where data sensitivity is lower.

  • 12-Step Checklist: RAG Pilot for Lead Qualification in German Insurance

    Pre-Pilot: Scope and Compliance Setup

    A 2-week fixed-scope pilot in a German insurance firm must produce a working RAG assistant on one workflow, a GDPR-compliant data-flow document, and a measured before/after baseline. The checklist below is operational: each item is a task a team can mark done or not done. It assumes the team uses LangChain and LangGraph, integrates with Slack or Microsoft Teams, and targets lead qualification to cut first-response time. The pilot is not a production deployment; it is a scoped experiment with a clear exit criterion. Work through the items in order. Skipping the audit or the baseline measurement invalidates the pilot’s value as a decision input for rollout.

    Build the RAG Pipeline on LangChain and LangGraph

    The RAG pipeline is the core of the pilot. Build it on LangChain for document chunking, embedding, and vector search, and on LangGraph for the stateful workflow that routes queries, handles multi-turn context, and triggers the human-approval gate. Keep the graph simple: one retrieval node, one generation node, one approval gate. Use a managed vector store in an EU region for the pilot. If the client’s data cannot leave the building, switch to an on-premises vector store and an open-weight model on the client’s GPU hardware. The RAG code is identical; only the embedding and inference endpoints change. Test the pipeline against 20 real lead queries before integrating with Slack or Teams.

    Integrate with Slack or Microsoft Teams

    The pilot must integrate with the channel the team already uses: Slack or Microsoft Teams. Build a bot that receives the lead query, calls the RAG pipeline, and returns the draft qualification score and suggested next step. The bot must include a human-approval gate: if the AI’s confidence drops below a threshold, or if the lead involves health-related data, the bot flags the query for a human agent. Log every human override. The integration must not replace the existing CRM or helpdesk; it plugs into them via their APIs. For a 2-week pilot, use a single OpenAI or Anthropic API endpoint for the LLM layer. Keep the model-agnostic layer thin: a single abstraction over the API call so switching providers later requires only a config change.

    Measure the Before/After Baseline

    Before the pilot starts, measure the baseline: cycle time from lead entry to qualified status, and error rate (misclassified leads) for the 2 weeks prior. Document the sample size, the definition of ‘error,’ and the measurement method. During the pilot, measure the same metrics for the 2 weeks of the pilot. The before/after comparison is the pilot’s primary deliverable. Without it, the client has no objective basis for the rollout decision. The baseline report must include: the number of leads processed, the average cycle time before and after, the error rate before and after, and the number of human overrides. This report is the exit criterion for the pilot.

    Define the Pilot Exit Criterion

    The pilot is a fixed-scope engagement: the vendor delivers a defined set of artifacts within the 2-week deadline. It is not a subscription or managed service. After the pilot, the client decides whether to proceed to rollout. The pilot includes a measured before/after comparison on cycle time and error rate, giving the client objective data to justify or reject the full deployment. The exit criterion is clear: if the pilot reduces cycle time by at least 30% and error rate by at least 20%, the client proceeds to rollout. If not, the pilot ends, and the client retains the baseline report and the RAG pipeline code. The vendor does not retain any client data after the pilot ends.

    Maintain the Checklist Over Time

    The checklist is a living document. After the pilot, review each item: mark what worked, what did not, and what needs adjustment. If the pilot proceeds to rollout, update the checklist to reflect the new scope: additional workflows, multi-language support, production monitoring. If the pilot ends, archive the checklist with the baseline report. Revisit the checklist before any new pilot: the GDPR landscape, the LLM provider landscape, and the integration landscape change. The checklist is not a one-time artifact; it is a tool for continuous improvement in AI-native operations. Keep it in the team’s project management tool, not in a static PDF.