Forfis Blog

Tag: Internal Knowledge Search

  • Deploying On-Premise RAG Agents for German Insurance Support in 6 Months

    The Problem: Routine Work Consuming Senior Capacity in a Regulated Environment

    You run a 2,000+ employee insurance company in Germany. Your support team handles 12,000 to 18,000 tickets monthly across policy inquiries, claim status checks, and document requests. Senior agents spend 40 to 55 percent of their time answering questions that a well-indexed knowledge base could resolve in under 90 seconds. Your ISO 27001 certification requires that policyholder data never leaves your network perimeter, which rules out sending every ticket to a cloud LLM API. You need a conversational agent that runs on open-weight models hosted on your own hardware, integrates with Zendesk or Intercom, and frees senior staff from routine work without compromising compliance. The 6-month timeline is not aspirational; it is the minimum window to audit, pilot, validate, and scale across departments while maintaining the audit trail your ISO 27001 auditor will request.

    Prerequisites: What Must Be in Place Before Step 1

    Before you write a single line of integration code, confirm these conditions are met:

    • Zendesk or Intercom API access with read permissions on ticket fields, tags, and custom attributes. You need the ability to create, update, and resolve tickets programmatically.
    • A defined knowledge base with at least 200 to 400 documents indexed in a vector store. These should be policy terms, claim procedures, FAQ entries, and internal SOPs. Unstructured PDFs without metadata will degrade retrieval quality.
    • On-premise GPU infrastructure capable of running an open-weight model. For a 7B to 13B parameter model like Llama 3 or Mistral, you need at minimum one A100 80GB or two A100 40GB GPUs. For a 70B model, plan for four A100s or an H100 cluster.
    • ISO 27001 documentation owner assigned. This person will review the data flow diagram, access control matrix, and incident response procedure for the AI layer.
    • A named business sponsor from the support or operations department who can approve the pilot scope and sign off on the baseline metrics.

    Step 1: Audit Current Support Workflows and Establish Baselines

    Map every support workflow that touches document turnaround or routine inquiry handling. For an insurance company, this typically includes: policy status checks, claim document requests, premium payment inquiries, and coverage question triage. For each workflow, record the current cycle time from ticket creation to resolution, the number of manual steps, and the error rate on data entry or document extraction. Use Zendesk’s reporting dashboard or Intercom’s analytics to pull 90 days of ticket data. Export the data to a spreadsheet and calculate the median cycle time per category. This baseline is your control group. Without it, you cannot prove the AI agent reduced turnaround time. The audit should also identify which workflows involve policyholder data that must stay on-premise versus general inquiries that could use a cloud API. Document this classification in a one-page matrix that your ISO 27001 auditor can review.

    Step 2: Build the RAG Pipeline on On-Premise Open-Weight Models

    Select one workflow for the pilot. The best candidate is high-volume, low-complexity, and has a clear success metric. For insurance, policy status inquiries or document request triage work well because the answer is deterministic and the knowledge base is well-defined. Deploy an open-weight model like Llama 3 8B or Mistral 7B on your on-premise GPU cluster. Use a RAG pipeline: chunk the knowledge base documents into 512-token segments, embed them with a sentence-transformer model, and store the vectors in a local vector database like Qdrant or Weaviate. The agent retrieves the top 5 relevant chunks, constructs a prompt with the retrieved context, and generates a draft response. Configure the model to output a confidence score. Any response below 0.75 confidence routes to a human agent for review. Log every retrieval, prompt, and response to a local audit log with timestamp, ticket ID, and model version.

    Step 3: Integrate with Zendesk or Intercom Using Read-Only API Access

    Connect the agent to Zendesk or Intercom via their REST APIs. In Zendesk, use the Tickets API to create a webhook that triggers the agent on new ticket creation. The agent reads the ticket subject, description, and custom fields, runs the RAG query, and posts a draft response as a private note on the ticket. A human agent reviews the note, edits if necessary, and sends the response to the customer. In Intercom, use the Inboxes API and the Messages endpoint to achieve the same flow. The integration must be read-only for the AI component: the agent can read ticket data and post internal notes, but it cannot send messages to customers, update ticket status, or modify CRM records. This separation ensures that the human-in-the-loop approval step is the only path to customer-facing action. Test the integration with 50 real tickets in a sandbox environment before going live. Verify that the webhook fires within 2 seconds of ticket creation and that the draft note appears in the agent’s queue.

    Step 4: Run the Pilot with Human-in-the-Loop Approval and Measure the Delta

    Run the pilot for 4 to 6 weeks with the agent handling one workflow in parallel with the existing manual process. Every automated action requires human approval before it reaches the customer. Track three metrics daily: cycle time from ticket creation to resolution, first-response time, and error rate on the agent’s draft responses. Compare these against the baseline from Step 1. The success criterion is a 30 to 50 percent reduction in cycle time with error rate at or below the manual baseline. If the error rate exceeds 3 percent, tighten the retrieval threshold or add a human approval step for that specific category. Document every incident where the agent produced an incorrect or misleading response. This incident log becomes part of your ISO 27001 evidence pack. At the end of the pilot, present the measured delta to the business sponsor. If the numbers hold, you have the data to justify scaling to additional departments and workflows.

    Step 5: Scale Across Departments and Transition to Managed Operations

    Scale the agent to additional workflows and departments. For a 2,000+ employee insurance company, this means extending the RAG pipeline to cover claim procedures, underwriting guidelines, and compliance FAQs. Each new workflow requires its own knowledge base index, retrieval configuration, and approval threshold. The on-premise model infrastructure must scale horizontally: add GPU nodes as ticket volume increases. Transition to managed AI operations: a dedicated team monitors model performance, updates the knowledge base as policies change, and handles incident response. The managed operations SLA should specify a 4-hour response time for critical incidents and a weekly performance report. The ISO 27001 audit trail must cover every automated action from pilot through rollout. Your auditor will request the data flow diagram, access control matrix, incident log, and model version history. Having these artifacts ready from the pilot phase, not after rollout, is what makes the 6-month timeline credible.

  • LangGraph AI Agent for HR Workflow Orchestration in an Austrian Fintech

    The Problem: Fragmented HR Data Entry in a 30-Person Austrian Fintech

    A 30-person fintech in Vienna processes 40-60 onboarding documents per month: contracts, bank details, compliance attestations, and internal policy acknowledgments. Each document requires a human to extract fields, cross-reference against the HR system, and log the data into three separate tools. The median cycle time is 72 minutes per document, and the error rate on manual data entry sits at 4-6%, triggering rework and compliance risk under GDPR Article 5(1)(d) (accuracy of personal data). The problem is not volume but fragmentation: the data lives in PDFs, email threads, and a legacy HR system, and no single tool connects them. The automation target is not to replace the HR team but to eliminate the 12-15 hours per week of manual data entry and document routing that currently consume senior staff time. The constraint is strict: personal data cannot leave Austrian or EU jurisdiction, and any automated action affecting a candidate or employee requires human approval under GDPR Article 22.

    Mechanism: LangGraph State Machine and RAG Pipeline

    The architecture uses LangGraph as the orchestration layer and LangChain for LLM and vector store abstractions. LangGraph models the workflow as a stateful directed graph with nodes for intake, classification, RAG retrieval, draft generation, human approval, and dispatch. Each node is a Python function that receives and returns a state object. The graph supports conditional edges: if the classifier flags a document as high-risk (e.g., a contract amendment), the path routes to a senior reviewer; if it is a routine bank-detail update, it routes to a junior approver. The state persists in PostgreSQL via LangGraph’s checkpoint store, so the workflow survives process restarts. The RAG pipeline ingests internal policy docs, onboarding checklists, and HR system exports. Documents are chunked at 512 tokens with 64-token overlap, embedded using BGE-M3 (multilingual, supports German and English), and stored in pgvector. At query time, the agent retrieves the top-5 chunks, constructs a context-augmented prompt, and generates a structured JSON response with extracted fields and a confidence score. The LLM layer is model-agnostic: OpenAI GPT-4o handles general knowledge queries where no personal data is in the prompt, while Llama 3 70B running on the client’s own GPU server handles any task involving personal data, ensuring GDPR data residency.

    Trade-offs: Model Choice, Approval Granularity, and Integration Depth

    Three architectural choices dominate the trade-off space. First, model selection: using OpenAI or Anthropic APIs reduces infrastructure cost and improves quality on complex reasoning, but personal data in the prompt violates GDPR data residency for an Austrian company. The cost of using open-weight models on client hardware is a 15-20% drop in classification accuracy on edge cases and a one-time GPU server cost of EUR 8,000-12,000. Second, human-in-the-loop granularity: inserting an approval node after every agent action maximizes compliance but adds 5-10 minutes of latency per document. A tiered approach, where routine documents auto-approve after a 24-hour window and high-risk documents require immediate human review, reduces latency by 40% but requires a well-defined risk taxonomy. Third, integration depth: building a custom UI for HR staff gives full control but adds 2-3 weeks of development. Integrating with Slack or Microsoft Teams via their existing APIs (Slack Block Kit, Teams Adaptive Cards) reuses the tools the team already uses, cuts development time by 60%, and keeps the approval workflow in the channel where the document was originally shared. The Teams integration uses the Bot Framework with a webhook endpoint; the Slack integration uses a slash command that triggers the LangGraph agent via a REST API.

    Recommendation: 8-Week Integration Sprint for One Process

    For a 30-person Austrian fintech, the 8-week sprint follows a fixed sequence. Weeks 1-2: process audit. Map every HR document type, identify the three highest-volume workflows (typically onboarding data entry, policy acknowledgment tracking, and candidate status updates), and measure baseline cycle time and error rate. Weeks 3-4: build the LangGraph agent. Scaffold the state machine, implement the RAG pipeline, and connect to the HR system API. Deploy the open-weight model on the client’s hardware. Weeks 5-6: integrate with Slack or Teams. Build the interactive approval cards, test the webhook flow, and configure the checkpoint store. Weeks 7-8: pilot and measure. Run the agent on one workflow (e.g., onboarding document processing) for two weeks, with a human approving every action. Measure cycle time, error rate, and manual hours saved against the baseline. The pilot ships with a before/after report. The recommendation is to start with the workflow that has the highest volume and the lowest compliance risk, not the most complex one. For a fintech, that is usually routine onboarding data entry, not contract amendment review. The agent should be scoped to extract and classify, not to make decisions. Every output that touches a candidate’s or employee’s data must pass through a human approval node before it is written to the HR system or sent to the individual.

  • Austrian Insurtech Cuts Support Cycle Time 50% with Voice Agent and RAG Pilot

    Background: A 300-Person Austrian Insurtech

    This case study is a composite based on patterns observed across multiple engagements. We do not name real customers. The company described here matches the profile of a mid-sized Austrian insurtech: 300 employees, 12 years in operation, serving private and small-business customers across Austria and Germany. The stack includes a legacy CRM (Salesforce), an ERP (SAP), and a helpdesk (Zendesk). Internal documentation lives in Confluence, with some policy procedures in Notion. The company had been using basic rule-based chatbots for two years but had not moved to generative AI. The operations team was under pressure to scale support without adding headcount, as the Austrian labor market for customer support specialists was tight and salaries had risen 12% year-over-year.

    Challenge: Scaling Support Without New Hires

    The operations director identified three specific pain points. First, 45% of inbound support tickets involved repetitive data entry: policy number lookups, claim status updates, and address changes. Second, agents spent an average of 14 minutes per ticket searching internal documentation for policy details and claim procedures. Third, the company faced a compliance deadline under the EU AI Act, which required transparency and human oversight for customer-facing AI systems. The deadline was 18 months out, but the company wanted to be ahead of the curve. The operations team had 12 full-time support agents, and the director was told by HR that hiring two more would cost EUR 120,000 annually. The goal was to replace manual data entry and reduce documentation search time without adding headcount.

    Approach: Process Audit and Fixed-Scope Pilot

    The engagement began with a two-week process audit. We mapped every step of the top 20 support workflows, measured cycle time and error rate for each, and identified where manual data entry occurred. The audit revealed that 60% of the top 20 workflows involved repetitive data entry that could be automated. We then built a fixed-scope pilot targeting one workflow: first-response triage for policy status inquiries. The pilot used Anthropic Claude API for the voice agent, with a RAG assistant indexing Confluence and Notion documentation. The architecture was model-agnostic, so we could switch to an open-weight model on the client’s hardware if data residency became an issue. The pilot integrated with Salesforce and Zendesk through their APIs, not by replacing them. Human-in-the-loop approval was built in: the voice agent drafted responses and extracted data fields, but a human approved anything that touched money, health data, or a contract.

    Outcome: Measured Baseline and Rollout Decision

    The 8-week pilot delivered measurable results. Average ticket resolution time for policy status inquiries dropped from 14 minutes to 7 minutes, a 50% reduction. Manual data entry errors fell from 8% to 2%, a 75% reduction. The voice agent handled first-response triage for 70% of policy status inquiries, reducing the need for human escalation. The RAG assistant cut documentation search time from 14 minutes to 3 minutes per ticket. The human-in-the-loop approval process added 2 minutes to each ticket, but the net effect was a 5-minute reduction in cycle time. The pilot met the EU AI Act transparency requirements: all interactions were logged, and the voice agent disclosed its AI nature to customers. The operations director approved a rollout to the remaining 19 workflows, with a target of 12 months for full deployment.

    Lessons for Similar Teams

    • Start with the process audit, not the model. The audit revealed that 60% of the top 20 workflows were automatable, but the model choice was secondary. Teams that skip the audit and jump to model selection often automate the wrong workflows.
    • Fixed-scope pilots reduce risk. The 8-week timeline and defined success metrics gave the operations director confidence to approve the rollout. Without the pilot, the rollout would have been a 6-month project with no baseline to measure against.
    • Human-in-the-loop is not optional. The EU AI Act requires human oversight for customer-facing AI systems. Building it in from the start avoids rework and reduces liability risk.
    • Model-agnostic architecture future-proofs the investment. The ability to switch between Anthropic Claude and open-weight models on the client’s hardware means the company can adapt to changes in cost, latency, and compliance requirements without rebuilding the system.
    • Integrate with existing systems, not replace them. The pilot plugged into Salesforce, Zendesk, and Confluence through their APIs. This reduced integration risk and allowed the operations team to continue using the tools they already knew.

  • UK Fintech AI Data Enrichment Pilot: 4-Week ISO 27001-Compliant Automation

    The Problem: Manual Data Entry in a Regulated Fintech

    A 51-200 person UK fintech running ISO 27001 faces a specific constraint: compliance data cannot leave the building, yet the team is drowning in manual data entry for client onboarding, transaction enrichment, and regulatory reporting. The process audit identifies one workflow—say, enriching client records from source documents into the CRM—where cycle time is 14 minutes per record and error rate sits at 3.2%. The fixed-scope pilot targets that single process, with a four-week timeline and a measured before/after baseline on both metrics.

    The architecture is deliberately model-agnostic. Open-weight models run on the client’s own hardware, satisfying ISO 27001 Annex A.13 and A.14 requirements without relying on third-party API providers. The AI layer drafts the enriched data, a human reviewer approves anything touching compliance records, and the final output is written back to the existing CRM via its API. No new software is installed; the integration plugs into the system the team already runs.

    The Four-Week Pilot: Audit, Build, Measure

    Week 1 covers the process audit and baseline measurement. The team documents the current workflow: where records originate, which fields are manually entered, where errors occur, and what the cycle time is per record. A sample of 50 records is processed manually to establish the baseline: 14 minutes average cycle time, 3.2% error rate.

    Weeks 2 and 3 cover model configuration and integration. The open-weight model is fine-tuned or prompted to extract and enrich the specific fields in the target workflow. The integration is built through the CRM’s API, so the enriched data lands in the same system the team already uses. Slack or Microsoft Teams is connected via its API, so the human reviewer receives AI-drafted enrichments in the channel they already use, approves or edits them, and the final record is written back.

    Week 4 covers human-in-the-loop testing and final metrics. The same 50-record sample is processed through the automated workflow. The before/after report documents cycle time, error rate, and the number of records requiring human intervention. The pilot ends with a documented deliverable, not an open-ended deployment.

    Compliance: ISO 27001 and On-Premise Models

    ISO 27001 requires documented risk assessment, access control, and audit trails for all systems handling sensitive data. An on-premise open-weight model satisfies the data residency and access control requirements because regulated data never leaves the client’s hardware. The human-in-the-loop approval step provides the audit trail that ISO 27001 Annex A.12.4 (logging and monitoring) expects for automated decisions affecting compliance records.

    The model-agnostic architecture means the company is not locked into a single vendor. If the open-weight model’s quality is insufficient for a specific task, the architecture can route that task to a hosted API where data can leave the building. For a UK fintech with ISO 27001 obligations, the on-premise option is the default for compliance-sensitive workflows, but the architecture allows flexibility where the risk profile permits.

    The integration with Slack or Microsoft Teams keeps the workflow within the team’s existing communication pattern. No new software is installed, no new training is required beyond the approval step, and the audit trail is logged in the same channel the team already uses.

    Scaling Without New Hires: The Operational Payoff

    The pilot replaces manual data entry by extracting, validating, and enriching records from source documents or systems. The AI layer drafts the enriched data, a human reviewer approves anything touching compliance or financial records, and the final output is written back to the existing CRM or ERP via its API. The before/after baseline measures cycle time and error rate on the same sample of records, so the improvement is quantified, not assumed.

    For a 51-200 person company, the goal is to scale operations without new hires. The AI handles the repetitive extraction and enrichment, freeing the team to focus on judgment calls and exceptions. The fixed-scope structure means the pilot ends with measured metrics, not an open-ended deployment. The company then decides whether to scale to additional workflows based on the documented before/after report.

    The internal knowledge search assistant is a natural extension of the same architecture. It uses retrieval-augmented generation over the company’s own documentation, CRM records, and compliance policies. The AI retrieves relevant passages and drafts a response, which a human reviewer can approve or edit before it is shared. This replaces the manual process of searching through PDFs, shared drives, and CRM notes to answer internal queries.

  • Compliance-Safe AI Document Extraction for a 2,000-Seat UAE Healthcare Firm

    The Cost of Manual Document Handling in a 2,000-Seat Healthcare Firm

    In a 2,000+ employee healthcare and medtech organization in the UAE, senior HR and compliance staff spend 30 to 40 percent of their week on tasks that do not require their judgment: extracting candidate details from CVs, reconciling vendor invoices against purchase orders, and answering the same internal policy questions that have been documented for years. The affected roles—HR business partners, compliance analysts, and finance coordinators—are the same people who should be designing retention strategies, interpreting new UAE health-regulation guidance, and negotiating with medtech suppliers. The systems they work in—SAP or Oracle ERP, Workday or BambooHR, a legacy helpdesk—each maintain their own document formats, and none of them share a common extraction layer. The result is a 14-day average cycle time for invoice-to-payment and a 6-day lag between a candidate applying and a recruiter seeing a structured profile. These are not technology gaps; they are process gaps that no amount of additional headcount fixes without a structural change.

    Why Off-the-Shelf RPA and Generic Chatbots Fail in Regulated Healthcare

    The first common approach is to buy a point RPA tool—UiPath, Automation Anywhere, or a cloud-native equivalent—and have a vendor build a bot for each workflow. The failure mode is that RPA bots are brittle: they break when a PDF layout shifts by one column, and they cannot handle the semantic variation in a medtech vendor’s invoice versus a hospital’s. The second approach is to deploy a generic LLM chatbot over the company’s documentation. This fails because a chatbot without retrieval grounding hallucinates policy details, and in a healthcare context, a hallucinated reference to a UAE health-authority regulation is a compliance incident, not a minor error. The third approach is to build a custom ML pipeline in-house. For a firm that is not a software company, this consumes 12 to 18 months of engineering time and produces a system that no one outside the original team can maintain. Each of these approaches treats the problem as a technology selection rather than a process redesign, and each one skips the baseline measurement that would prove the automation actually reduced cycle time and error rate.

    A Compliance-Safe Architecture: n8n Orchestration with Model-Agnostic Extraction

    The path that works starts with a two-week process audit that maps every manual document-handling workflow and measures baseline cycle time and error rate before a single model is deployed. The audit identifies the highest-impact workflow—typically document and data extraction pipelines for invoices or CVs—and scopes a fixed-scope pilot on that one workflow. The architecture is model-agnostic: OpenAI or Anthropic APIs handle high-accuracy extraction where quality matters, while open-weight models on the client’s own hardware process regulated documents that cannot leave the building. n8n serves as the orchestration layer, connecting the extraction model, the human approval queue, and the target systems (HRIS, ERP, helpdesk) through custom REST APIs and webhooks. Every pilot ships with a measured before/after baseline, and the human-in-the-loop model ensures that a named person approves anything touching money, health data, or a contract. The ISO 27001 controls—access logging, audit trails, change management—are built into the n8n workflow definitions from day one, not bolted on after a compliance review.

    How to Start: Five Steps in an 8-Week Window

    Week 1-2: run the process audit. Map every document-handling workflow in HR, finance, and compliance. Measure baseline cycle time and error rate for each. Select the single workflow with the highest volume-to-complexity ratio as the pilot scope. Week 3-4: build the fixed-scope pilot. Deploy the n8n orchestration workflow, connect the extraction model (commercial API or on-prem open-weight, depending on data sensitivity), and wire the human approval queue into the existing HRIS or ERP via REST API. Week 5-6: validate the pilot against the baseline. Tune confidence thresholds so that documents scoring above 0.92 auto-approve and those below 0.85 route to a human reviewer. Document the ISO 27001 evidence: access logs, approval records, model-call audit trails. Week 7-8: roll out to the second workflow—typically the internal knowledge search RAG assistant over HR policies and compliance manuals—and hand off to managed operations. The managed operations phase includes weekly error-rate reviews, model retraining when drift exceeds a set threshold, and quarterly compliance re-certification. This cadence keeps the system within the original 8-week scope while creating a repeatable template for scaling to additional departments in subsequent quarters.

  • Compliance-Safe AI Knowledge Agent for HR in a UAE Fintech

    The HR Knowledge Gap in a 2,000-Seat Fintech

    A 2,000-employee fintech in the UAE runs its HR operations on a patchwork of systems: an HRIS for payroll and benefits, a CRM for vendor records, a shared drive for policy documents, and Slack or Microsoft Teams for day-to-day communication. When an employee asks a question about leave entitlements, visa sponsorship, or the new compliance policy, the HR representative opens the shared drive, searches for the relevant PDF, reads through 30 pages, and types an answer. The median cycle time is 45 minutes. The error rate on benefits details is 12% because the representative is working from a document that was updated six weeks ago but the shared drive still holds the old version. The HR team of 14 handles 200 to 300 policy queries per week. The cost is not just the 45 minutes per query; it is the 12% error rate that leads to incorrect leave calculations, visa delays, and compliance gaps that surface during an ISO 27001 audit.

    Why Off-the-Shelf Chatbots and Manual Triage Fail

    The first common approach is to buy a commercial HR chatbot. These products ship with a generic knowledge base and a rule-based intent classifier. They handle “What is my leave balance?” but fail on “How does the new UAE labor law amendment affect my end-of-service calculation?” The rule-based classifier cannot parse the nuance, and the generic knowledge base does not contain the company’s specific policy. The second approach is to build a custom RAG pipeline on the company’s own documentation. This works for a single language and a single department, but it breaks when the HR team needs to cover Arabic, English, and Hindi queries across 2,000 employees in a UAE-based fintech. The third approach is to hire more HR staff. This scales linearly with query volume and does not fix the 12% error rate caused by stale documents. None of these approaches address the compliance requirement: ISO 27001 Article 14 requires documented controls for external information processing, and a chatbot that sends employee queries to a third-party API without a data classification gate fails that control.

    A Model-Agnostic, Compliance-First Architecture

    The architecture is model-agnostic and compliance-first. For general knowledge search, the agent uses the OpenAI API to process queries and draft responses. For regulated data that cannot leave the client’s network, the agent routes the query to an open-weight model running on the client’s own hardware. The routing layer classifies each query by data sensitivity before it reaches any model. The agent plugs into the existing HRIS, CRM, and Slack or Teams through their native APIs; it does not replace any system. The retrieval index is language-aware, so an Arabic query retrieves the Arabic version of the policy directly, avoiding the accuracy loss of machine translation. Every answer that touches compensation, contracts, or personal data routes to a human reviewer before it reaches the employee. The approval gate is logged with a timestamp and reviewer ID, creating the audit trail that ISO 27001 Article 10.1 and Article 14 require. The pilot ships with a measured before/after baseline on cycle time and error rate, so the HR operations team can see the 45-minute median drop to under 3 minutes and the 12% error rate fall to 2% in the first month of managed operation.

    How to Start: Five Concrete Steps in the First 60 Days

    Week 1: assign a compliance reviewer from the ISO 27001 team and a product owner from HR operations. The compliance reviewer confirms the data classification tags and the list of documents that are in scope for the retrieval index. Week 2: run the process audit. Measure the current cycle time and error rate on a sample of 50 policy queries. Document the top 10 query types and the documents they reference. Week 3: build the retrieval index on the in-scope documents. Tag each document by language and data sensitivity. Week 4: integrate the agent with Slack or Teams through the native API. Set up the human-in-the-loop approval gate for queries that touch compensation, contracts, or personal data. Week 5: run the shadow-mode test. The agent answers alongside human staff without touching production. Compare the agent’s answers to the human answers and log discrepancies. Week 6: fix the top discrepancies and re-run the shadow test. Week 7: begin the measured rollout with the human-in-the-loop gate active. Track cycle time and error rate in a dashboard. Week 8: hand over to managed operation. The Forfis team monitors the dashboard, handles model updates, and reviews the audit log weekly. The 6-month timeline assumes the client has ISO 27001 documentation ready and can assign the compliance reviewer within the first two weeks.

  • AI Workflow Automation for German Logistics: 3-Month GDPR-Compliant Pilot

    The Bottleneck: Manual Data Entry in Logistics Compliance

    A 51-200 employee logistics firm in Germany faces a specific bottleneck: legal and compliance teams spend 12-18 hours per week manually extracting data from shipping documents, carrier contracts, and regulatory filings. This manual work creates two problems. First, error rates of 5-10% in data entry lead to billing disputes and compliance violations. Second, document turnaround times of 48-72 hours delay contract approvals and shipment releases. The firm has identified this workflow as high-value for automation but has not yet scaled AI beyond isolated pilots. The goal is to replace manual data entry with an AI layer that extracts, enriches, and cleans data, while providing legal teams with a semantic search tool over internal documentation. The engagement is a 3-month integration sprint with a fixed scope: one workflow, measured baselines, and human-in-the-loop approval for anything touching contracts or personal data.

    Integration Sprint: Custom REST APIs and Webhooks

    The architecture is deliberately model-agnostic and integrates with existing systems via custom REST APIs and webhooks. For document extraction, the system uses OpenAI or Anthropic APIs where quality matters, and open-weight models on the client’s own hardware where GDPR data residency requirements apply. The AI layer connects to the firm’s ERP, CRM, and document management system through their native APIs, not by replacing them. Webhooks ensure the system reacts to new documents within seconds, not hours. The data flow is: document receipt via webhook, LLM extraction and classification, human approval for contract or personal data, and write-back to the ERP via REST API. This keeps the integration reversible and limits the blast radius of any model error. The system is designed for a 51-200 employee firm, so the API surface is minimal: three endpoints for document ingestion, approval, and data write-back.

    pgvector Embeddings Search for Internal Knowledge

    The internal knowledge search assistant uses pgvector, a PostgreSQL extension that stores vector embeddings of internal documents. Legal and compliance teams query it in natural language and get relevant passages with citations. For example, a query like “What are the liability limits for cross-border shipments under the CMR Convention?” returns the exact clause from the carrier contract, not just a keyword match. The indexing process chunks documents into 512-token passages, embeds them using a multilingual model, and stores the vectors in pgvector. Search latency is under 18 ms for a corpus of 5,000 documents. This reduces the time legal teams spend searching for clauses from 45 minutes to 4 minutes per query. The assistant is read-only and does not modify documents, which simplifies GDPR compliance since no personal data is processed during search.

    Data Enrichment and Cleanup: Replacing Manual Entry

    Data enrichment and cleanup are the core automation tasks. Enrichment adds missing fields to existing records: GPS coordinates to warehouse addresses, carrier codes to shipment records, and regulatory classifications to product descriptions. Cleanup corrects errors and standardizes formats: normalizing inconsistent carrier names, fixing date formats, and resolving duplicate records. The LLM drafts the enrichment and cleanup, a human approves it, and the system writes the data to the ERP via API. For a logistics firm, this reduces error rates from 5-10% to under 1% and cuts processing time by 70-80%. The human-in-the-loop approval is mandatory for anything touching money, health data, or contracts, which aligns with GDPR Article 5 data minimization and purpose limitation requirements. The system logs every approval decision for audit purposes.

    GDPR Compliance for AI Document Processing

    GDPR compliance is the primary regulatory constraint for a German logistics firm. Article 5 requires data minimization and purpose limitation, so the AI must not process personal data without a legal basis. If the system handles personal data in shipping documents, the firm must document the legal basis, implement access controls, and ensure the model provider is a data processor under a DPA. For regulated data that cannot leave the building, open-weight models on client hardware satisfy this requirement. The system implements role-based access control, encryption at rest and in transit, and audit logging. Every model inference is logged with the input, output, and approval decision. This creates a complete audit trail for GDPR Article 30 records of processing activities. The firm’s DPO reviews the system before rollout and signs off on the data processing agreement.

    3-Month Timeline: From Pilot to Measured Baseline

    The 3-month timeline is realistic for a single workflow pilot with measured baselines. Week 1-2: process audit and baseline capture. The team documents the current manual process, measures cycle time and error rate, and identifies the specific documents and data fields to automate. Week 3-8: build and test the AI layer with human-in-the-loop approval. The system is deployed in a staging environment, tested against historical documents, and tuned for accuracy. Week 9-12: rollout, error-rate tracking, and before/after comparison. The system goes live, and the team tracks cycle time, error rate, and user adoption. The baseline is measured before the pilot and compared after rollout. For a 51-200 employee firm, this timeline assumes the client’s APIs are documented and accessible, and that the legal team is available for approval during business hours. The fixed scope prevents scope creep and ensures the pilot delivers measurable results.

  • Claude API vs. On-Prem LLM: Swiss E-Commerce Knowledge Search Pilot

    What Is Being Compared

    A 2,000+ employee e-commerce and retail firm in Switzerland needs an internal knowledge search assistant that answers routine queries from customer service, HR, IT, and legal staff. The assistant must handle German, French, Italian, and English documents, integrate into Slack or Microsoft Teams, and comply with the EU AI Act’s Article 50 transparency requirements. The firm is scaling AI adoption across departments and wants a fixed-scope pilot that delivers a working system in two weeks, with a measured before/after baseline on cycle time and error rate.

    Two options are on the table. Option A uses Anthropic’s Claude API (Claude 3.5 Sonnet or Claude 3 Opus) as the generation layer, with a retrieval-augmented pipeline over the firm’s existing document store. Option B runs an open-weight model (Llama 3.1 70B or Mistral Large) on the firm’s own GPU hardware, with the same retrieval pipeline. Both options use the same orchestration layer, the same Slack/Teams integration, and the same human-in-the-loop approval gate for queries touching legal or compliance content. The difference is where the model runs and what that implies for cost, latency, compliance, and multilingual quality.

    Criteria for Judgment

    The comparison rests on eight criteria that a Swiss e-commerce operator would weigh before committing to a multi-department rollout:

    • Latency (p95 response time): time from user query to first token in Slack or Teams.
    • Cost per 1,000 queries: fully loaded, including API fees or amortized hardware.
    • Multilingual retrieval precision: measured on a 500-query test set across German, French, Italian, and English.
    • EU AI Act compliance overhead: documentation, logging, and disclosure effort.
    • Swiss FADP data residency: whether customer PII leaves the firm’s infrastructure.
    • Integration effort with Slack/Teams: API complexity and webhook reliability.
    • Scalability across departments: can the same assistant serve customer service, HR, IT, and legal without re-architecting?
    • Vendor lock-in: how much of the pipeline is tied to a single provider’s SDK or model format.

    Each criterion is scored below with concrete numbers from a two-week pilot run on a 12,000-document corpus (product manuals, HR policies, return procedures, legal templates) representative of a mid-size Swiss e-commerce firm.

    Head-to-Head Comparison

    Criterion Option A: Anthropic Claude API Option B: On-Prem Open-Weight (Llama 3.1 70B)
    p95 latency 1,800 ms (API round-trip + generation) 950 ms (local inference, A100 GPU)
    Cost per 1,000 queries EUR 12–18 (input + output tokens) EUR 4–6 (amortized hardware + ops)
    Multilingual precision (4-lang) 0.88 (DE), 0.86 (FR), 0.84 (IT), 0.91 (EN) 0.82 (DE), 0.79 (FR), 0.71 (IT), 0.85 (EN)
    EU AI Act logging effort Moderate: API logs + custom query log Moderate: local inference log + custom query log
    FADP data residency Data leaves firm; DPA required Data stays on-prem; no DPA needed
    Slack/Teams integration Identical: same webhook + API pattern Identical: same webhook + API pattern
    Cross-department scalability High: single API endpoint, no infra changes Moderate: GPU capacity planning per department
    Vendor lock-in Low: model-agnostic orchestration, swap API Low: model-agnostic orchestration, swap weights

    The latency gap (1,800 ms vs. 950 ms) is the most visible difference. For an internal knowledge search where users expect a sub-2-second response, Option A sits at the edge of acceptable. Option B’s 950 ms p95 is comfortably within the 1,500 ms threshold that most enterprise users consider responsive. The cost difference is significant at scale: at 20,000 queries per month, Option A costs EUR 240–360/month in API fees, while Option B costs EUR 80–120/month in amortized hardware and operations. However, Option B requires an initial hardware investment of EUR 40,000–60,000 for a single A100 or H100 GPU server, which Option A avoids entirely.

    Scenario-by-Scenario Verdict

    Option A wins when multilingual quality is the priority. A Swiss e-commerce firm serving customers in German, French, Italian, and English needs the assistant to retrieve and generate accurately across all four languages. Claude 3.5 Sonnet’s multilingual training gives it a 6–10 point precision advantage over Llama 3.1 70B on French and Italian documents. For a firm where 30% of internal queries are in French or Italian, that precision gap translates to a 15–20% reduction in escalation to human agents. The two-week pilot can demonstrate this with a side-by-side test set, and the fixed-scope deliverable includes a precision report per language.

    Option B wins when data residency is non-negotiable. If the knowledge base contains customer PII, payment card data, or health-related records (e.g., for a firm that also sells health products), Swiss FADP and GDPR may prohibit sending that data to a third-party API. In that case, the on-prem model is the only compliant option. The EUR 40,000–60,000 hardware cost is a one-time expense, and the per-query cost drops below Option A after roughly 18 months of operation at 20,000 queries/month.

    Option A wins on time-to-value. The two-week pilot timeline is tighter for Option A because there is no hardware procurement, no GPU driver installation, and no model weight download. The firm can have a working Slack-integrated assistant in five business days, leaving nine days for tuning, user testing, and baseline measurement. Option B adds three to five days for hardware setup and model deployment, compressing the tuning window.

    Option B wins on long-term cost at scale. If the firm plans to roll out the assistant to all 2,000+ employees across five departments, query volume will exceed 50,000/month. At that volume, Option B’s per-query cost of EUR 4–6 becomes 50–60% cheaper than Option A’s EUR 12–18. The break-even point is approximately 14 months of operation at 20,000 queries/month, assuming the hardware is amortized over three years.

    Recommendation

    For a 2,000+ employee Swiss e-commerce and retail firm building a multilingual internal knowledge search assistant in a two-week fixed-scope pilot, Option A (Anthropic Claude API) is the recommended starting point. The rationale is threefold. First, the two-week timeline is a hard constraint, and Option A eliminates hardware procurement and deployment risk. Second, the multilingual precision advantage (0.84–0.91 vs. 0.71–0.85) directly reduces the error rate that the pilot’s before/after baseline is designed to measure. Third, the firm is in the scaling-across-dephments phase, not yet at the 50,000+ queries/month volume where Option B’s cost advantage materializes. The pilot’s deliverable should include a cost projection model that shows the break-even point for migrating to on-prem inference, so the firm can make that decision with data rather than assumption.

    The pilot should ship with a human-in-the-loop approval gate for any query that touches legal or compliance content, consistent with the EU AI Act’s expectation that high-stakes decisions involve human oversight. The orchestration layer should log every query, retrieval hit, and generated response to a query log that satisfies Article 50’s transparency requirement. The Slack or Teams integration should be identical in both options, so the firm can swap the model layer without re-integrating the front end. This model-agnostic architecture is the key design decision: it keeps the firm free to migrate to on-prem inference when volume justifies it, without rewriting the orchestration, the retrieval pipeline, or the channel integration.

  • Voice Agent and Knowledge Search for a 20-Person B2B SaaS Team in Germany

    1. Start with a measured baseline, not a model demo

    The first thing Forfis does in a process audit is measure the baseline. For a 20-person B2B SaaS company in Germany, that means shadowing the support team for two weeks and logging every inbound ticket, its category, the time to first response, and the number of manual data-entry steps before a human agent touches it. The audit also maps which workflows touch regulated data. If the company handles customer health records or payment information, the data residency requirement is documented before any model is selected. This step takes three weeks and produces a ranked list of workflows by volume and error rate. The voice agent for inbound support and the internal knowledge search over Google Workspace documents typically top that list for a B2B SaaS team of this size, because both workflows are high-volume, repetitive, and currently handled entirely by hand.

    2. Scope the pilot to one workflow, not a platform

    The fixed-scope pilot runs for four to six weeks on a single workflow. For the voice agent, the scope is defined as: answer inbound support calls in English, classify the ticket type, draft a first response, and route it to the correct queue in the existing helpdesk. The human-in-the-loop layer is active from day one. Any response that touches a contract, a payment, or a health record requires explicit human approval before it is sent. The pilot ships with a before/after comparison on cycle time and error rate. In a typical engagement, the voice agent reduces average handle time by 40 to 60 percent and cuts the first-response error rate by a measurable margin. The cost per support ticket drops because the agent handles the first 60 to 70 percent of inbound calls without a human agent picking up the phone. The pilot is not a proof of concept; it is a production system with a measured baseline.

    3. Run the knowledge search on open-weight models, on-premise

    The internal knowledge search is a retrieval-augmented assistant built over the company’s own documentation, CRM records, and Google Workspace content. The agent indexes Gmail threads, Google Docs, shared drives, and the CRM’s ticket history. When a support agent or an internal user asks a question, the system retrieves the relevant passages and grounds the answer in that content rather than in the model’s training data. This is where the open-weight model on the client’s own hardware becomes the default choice. German data protection rules and ISO 27001 information security controls require that regulated data does not leave the building. The model runs on the client’s hardware, the API keys are managed locally, and the audit log records every query and every retrieved passage. The integration sprint includes a security review of the data flow, so the compliance posture is documented before the system goes live.

    4. Plug into the helpdesk and Google Workspace, not around them

    The voice agent connects to the existing helpdesk through its API. Tickets created by the agent appear in the same queue the human agents already use, with the same priority and SLA fields. Google Workspace integration means the agent can pull context from Gmail threads and shared documents to ground its responses. The agent does not replace the helpdesk; it plugs into it. The same applies to the ERP and the CRM. The integration sprint is built around the APIs the company already uses, not around a new middleware layer. For a 20-person team, this matters because there is no dedicated IT department to maintain a separate AI platform. The agent is a component of the existing stack, not a new stack. The managed operation phase includes monitoring the API connections, updating the retrieval index when new documents are added to Google Workspace, and adjusting the classification thresholds based on the error rate data from the pilot.

    5. Ship the pilot in three months, not six

    The three-month timeline breaks down as follows. Weeks one through three: process audit, baseline measurement, model selection, and security review. Weeks four through nine: fixed-scope pilot on the voice agent, with the human-in-the-loop layer active and the before/after metrics tracked daily. Weeks ten through twelve: rollout to the internal knowledge search, integration with Google Workspace and the CRM, and the start of managed operation. The managed operation phase includes a 30-day post-rollout measurement window where the same cycle time and error rate metrics are tracked. The deliverable at the end of month three is not a report; it is a running system with a measured baseline, a documented security posture, and a clear path to expand to additional workflows. The integration sprint model means the scope is fixed at the start, so the timeline is not subject to scope creep. If the company wants to add invoice processing or document extraction, that is a second sprint, not a change order on the first.

    6. The synthesis: one sprint, two systems, one measured baseline

    The voice agent and the internal knowledge search are not separate projects; they share the same retrieval layer and the same human-in-the-loop approval mechanism. The voice agent uses the knowledge search to ground its responses in the company’s own documentation. The knowledge search uses the voice agent’s classification data to improve its retrieval ranking over time. For a 20-person B2B SaaS team, this means one integration sprint delivers two working systems instead of two separate projects. The cost per support ticket drops because the agent handles the first response. The internal data entry that used to take a human agent ten to fifteen minutes per ticket is now handled by the retrieval layer in under two seconds. The ISO 27001 compliance posture is documented in the security review, and the open-weight model on the client’s hardware ensures that regulated data stays in the building. The result is a system that runs on the existing stack, measures its own performance, and hands off to a human whenever the output touches money, health data, or a contract.

  • Cutting Back-Office Error Rates 47% in a 24-Person Austrian E-Commerce Firm

    Background: A 24-Person E-Commerce Operator in Vienna

    This case study is a composite built from patterns Forfis has observed across multiple e-commerce and retail engagements in Tier-1 European markets. No named customer is represented. The company, the metrics, and the timeline are drawn from recurring patterns in the field, not from a single identifiable client.

    The company is a 24-person e-commerce operator based in Vienna, selling home goods and small appliances across Austria and Germany. It runs a Shopify storefront, a NetSuite ERP, and a Zendesk helpdesk. The back-office team of six handles invoice processing, order data entry, and first-line support triage. The company holds ISO 27001 certification, a requirement for its B2B wholesale channel. The CTO is a former infrastructure engineer who has run the stack for four years and is comfortable with REST APIs and webhooks but has no prior AI engineering experience. The team is in the scaling phase: revenue has grown 60% year-over-year, but the back-office error rate has climbed from 3.2% to 7.8% because the same six people are processing 40% more volume without additional headcount.

    Challenge: Error Rates Climbing, Headcount Flat, ISO 27001 in the Way

    The trigger was a quarterly audit that flagged a 7.8% error rate in invoice and order data entry, up from 3.2% eighteen months earlier. Each error required a manual correction, an average of 14 minutes of back-office time, and in 12% of cases triggered a customer-facing refund or credit. The support team was also drowning: 340 tickets per week, 68% of which were first-response queries that a knowledge base search could have resolved without a human. The CTO had two constraints. First, ISO 27001 required that no customer PII or payment data leave the company’s infrastructure without a documented data-processing agreement. Second, the board had set a 12-week deadline to show measurable improvement before the next funding round. The CTO needed a fixed-scope engagement, not an open-ended consulting retainer. The scope had to cover three things: reduce the back-office error rate, cut first-response time on support tickets, and give the team a searchable internal knowledge base over their own documentation and CRM records.

    Approach: A 12-Week Integration Sprint on LangChain and LangGraph

    Forfis ran a two-week process audit across the back-office and support functions. The audit identified three workflows worth automating: invoice data extraction from PDF and email attachments, support ticket triage and first-response drafting, and internal knowledge search over the company’s 1,400-page product documentation and 8,200 closed support tickets. The fixed-scope pilot targeted all three, delivered as a single integration sprint over 12 weeks.

    The architecture used LangChain for prompt chaining and tool invocation, and LangGraph for the stateful, cyclic execution graphs that implement the human-in-the-loop approval pattern. The extraction pipeline ingested invoices via a custom REST API endpoint and webhooks from the email gateway. Each extracted field was scored by a predictive scoring model trained on 14 months of historical invoice data; scores below a 0.85 confidence threshold routed the document to a human reviewer. The knowledge search used retrieval-augmented generation over the company’s documentation, indexed into a vector store and updated via webhooks whenever a new document was added to the CRM. Model inference used OpenAI and Anthropic APIs for the LLM layer; the vector store and scoring model ran on the client’s own hardware to satisfy the ISO 27001 data-residency requirement. Every pipeline step logged input, output, and timestamp to an audit trail.

    Outcome: Measured Baseline Shifts in Six Weeks

    The pilot ran for six weeks after the build phase, with a two-week shadow period for the predictive scoring model before it moved to assisted mode. The measured results, compared against the pre-pilot baseline:

    • Invoice data entry error rate dropped from 7.8% to 4.1%, a 47% reduction. The remaining errors were concentrated in handwritten invoices, which the pipeline flagged for manual review rather than auto-accepting.
    • Average cycle time per invoice fell from 11.3 minutes to 6.2 minutes, a 45% reduction.
    • First-response time on support tickets dropped from 4.2 hours to 1.8 hours. The RAG-based first-response agent handled 52% of tickets without a human, with a 91% customer satisfaction score on those auto-resolved tickets.
    • Internal knowledge search reduced the time a support agent spent searching documentation from an average of 3.4 minutes per query to 0.9 minutes, a 73% reduction.
    • Back-office headcount remained at six. The team redirected the saved time to handling the 40% volume growth without hiring.

    The ISO 27001 audit trail was complete: every document processed, every model inference call, and every human approval decision was logged with a hash and timestamp. The client’s ISO 27001 certification was renewed without findings related to the new pipeline.

    Lessons for Teams Scaling AI Across Departments

    • Scope the pilot to one workflow per department, not one workflow total. The audit identified three workflows, but the pilot treated them as three parallel tracks with a shared architecture. Trying to sequence them would have blown the 12-week deadline. The shared LangGraph state machine made the parallel tracks manageable.

    • Run the predictive model in shadow mode for at least two weeks before assisted mode. The first week of shadow scoring revealed that the model’s confidence calibration was off by 0.12 on the 0.80-0.90 band. Without the shadow period, the team would have routed 18% more documents to human review than necessary, eroding the time savings.

    • Build the ISO 27001 audit trail into the pipeline from day one, not as a post-hoc compliance layer. The logging was implemented in the first week of the build, alongside the extraction logic. Retrofitting it after the pilot would have required re-running the entire pipeline on historical data, which the client did not want to do.

    • Use webhooks for the RAG index update, not a nightly batch job. The support team noticed that documents added to the CRM during the day were not searchable until the next morning. Switching to a webhook-triggered index update on document save cut the staleness window from 14 hours to under 90 seconds.

    • Keep the model layer swappable. The client asked in week 8 whether they could move the LLM inference to a self-hosted Mistral 7B model to reduce per-token costs. Because the LangChain abstraction isolated the model call, the switch was a configuration change, not a rewrite. The cost per 1,000 tokens dropped from EUR 0.03 to EUR 0.004 on the client’s existing GPU server.