Forfis Blog

Blog

  • AI Invoice Processing in Healthcare: A Glossary of 15 Key Terms

    Before/After Baseline

    A before/after baseline is a set of metrics measured before and after the AI system is deployed to quantify its impact. For a healthcare organization, this includes cycle time (the time from invoice receipt to payment), error rate (the percentage of invoices requiring manual correction), and cost per invoice. The baseline is established during the process audit and used to measure the ROI of the AI system after the fixed-scope pilot and rollout. In a 2,000+ employee organization, even a 10% reduction in cycle time can save thousands of hours annually, making the baseline a critical tool for justifying the investment in AI automation.

    Document Extraction Pipeline

    A document extraction pipeline is a series of steps that convert unstructured or semi-structured documents, such as invoices, into structured data. For a healthcare organization, this pipeline includes steps like OCR (optical character recognition), layout analysis, field extraction, and data validation. The pipeline is built using LangChain and LangGraph, with human-in-the-loop checks for any fields that fall below a confidence threshold. In a HIPAA-regulated environment, the pipeline must ensure that patient-identifiable information is not exposed to cloud-based models, requiring the use of open-weight models on the client’s own hardware for sensitive data.

    Data Enrichment and Cleanup

    Data enrichment and cleanup in this context refers to the automated process of standardizing, validating, and augmenting raw invoice data before it enters the ERP. This includes mapping vendor names to master data, converting currency to the reporting currency, and flagging discrepancies in tax codes. For a 2,000+ employee organization, this step reduces manual data entry errors and ensures that monthly reporting is based on clean, consistent data. In a healthcare setting, data enrichment also involves mapping billing codes to the correct regulatory categories, ensuring that the data is compliant with HIPAA and other relevant regulations.

    HIPAA Compliance

    HIPAA compliance in this context means that the AI system must protect patient-identifiable information and ensure that data is not stored or processed in ways that violate the Health Insurance Portability and Accountability Act. For a healthcare organization, this requires using open-weight models on the client’s own hardware for any data that contains patient information, while using cloud-based models for non-sensitive data. The system must also include audit logs and access controls to track who accessed what data and when. In Austria, where data protection laws are strict, HIPAA compliance is often supplemented by GDPR requirements, making the compliance landscape even more complex.

    Human-in-the-Loop Workflow

    A human-in-the-loop workflow means the AI model drafts or classifies the data, but a human operator reviews and approves any output that touches financial records, patient-identifiable information, or contractual terms. For a 2,000+ employee healthcare organization, this ensures that while the system processes 90% of invoices automatically, the remaining 10% containing complex billing codes or HIPAA-sensitive data are routed to a finance team member for final sign-off before posting to the ERP. This approach balances the speed of AI automation with the accuracy and compliance required in a regulated environment.

    LangChain and LangGraph

    LangChain provides the foundational abstractions for connecting large language models to external tools and data sources, while LangGraph extends this by allowing developers to define stateful, multi-step workflows with explicit control flow. In a document extraction pipeline, LangChain handles the initial parsing and vector retrieval, whereas LangGraph manages the conditional logic that determines whether a parsed invoice requires human review or can be auto-approved based on confidence thresholds. This combination allows the system to handle complex workflows with precision, ensuring that each step is auditable and that the system can adapt to changes in invoice formats or regulatory requirements.

    Managed AI Operations

    Managed AI operations is a delivery model where the vendor not only builds the AI system but also monitors, maintains, and optimizes it after deployment. For a healthcare company, this includes tracking model performance, updating prompts as invoice formats change, and ensuring that the human-in-the-loop workflow remains efficient. This model is critical for scaling operations without new hires, as it shifts the burden of AI maintenance from the client’s IT team to the vendor. In a 2,000+ employee organization, managed operations ensure that the AI system continues to perform at a high level as the volume of invoices and the complexity of the data increase.

  • Cutting First-Response Time in Swiss Insurance Hiring with a LangGraph Pilot

    The 48-Hour Black Hole in Swiss Insurance Hiring

    A 501-2000 employee insurer in Switzerland receives 300-500 applications per week across 15-20 open roles. Recruiters manually triage each CV, score it against a rubric, and draft a response. The median time-to-first-response is 48-72 hours. Candidates who do not hear back within 48 hours are 3x more likely to accept a competing offer. The recruiter team is flat: no new hires are planned for the next 12 months. The operations team is asked to cut first-response time without adding headcount. The constraint is not technical; it is structural. The current process is a linear, human-bottlenecked pipeline that cannot scale with application volume.

    Why Off-the-Shelf ATS and In-House ML Both Fail

    The first common approach is to buy an off-the-shelf ATS with an AI scoring module. These tools parse CVs and assign a score, but the scoring rubric is opaque and not configurable to the insurer’s specific role requirements. The second approach is to build a custom ML model in-house. This takes 6-12 months, requires a data science team the insurer does not have, and produces a model that is hard to audit under the EU AI Act. The third approach is to outsource to a staffing agency. This reduces recruiter workload but does not cut first-response time; the agency’s own triage process is equally slow. None of these approaches address the root cause: the workflow is not orchestrated. It is a sequence of manual steps with no state management, no branching logic, and no audit trail.

    A LangGraph Workflow with Human-in-the-Loop Approval

    The alternative is a workflow-orchestration approach built on LangChain and LangGraph. LangChain provides the abstraction layer for calling LLMs, vector stores, and tools. LangGraph adds a stateful, cyclic execution model where each node is a function (e.g., ‘parse CV’, ‘score against rubric’, ‘flag for human review’) and edges define control flow. For candidate screening, the workflow is a DAG: the CV is ingested from Google Workspace (Gmail API), parsed into structured data, scored against a predefined rubric, and routed to a human-approval gate if the score is borderline. The AI drafts the response email; the recruiter approves it before it is sent. The architecture is model-agnostic: open-weight models on the client’s own hardware where CVs contain health or financial data, commercial APIs where quality matters. The output is a measured before/after baseline on cycle time and error rate, shipped in a 2-week pilot.

    The 2-Week Pilot: Audit, Build, Measure

    The pilot is scoped to 50-100 real candidates over two weeks. Week 1: the AI process audit maps the current screening steps, identifies the 2-3 highest-volume, lowest-complexity tasks, and selects the LLM. The LangGraph workflow is built with a human-approval gate and a logging mechanism that captures every decision. Week 2: the pilot runs on live applications. The team measures median time-to-first-response, error rate in CV parsing, and recruiter time saved. The output is a go/no-go decision for scaling to all hiring pipelines. The managed AI operations model means the workflow is monitored, tuned, and updated after the pilot; the insurer does not own the maintenance burden. The EU AI Act compliance artifacts (risk management documentation, technical documentation, oversight logs) are produced as part of the pilot, not as a separate project.

    Five Concrete First Steps

    The first step is to define the success metric: median time-to-first-response, not average. The second is to establish the baseline: manually track 50-100 applications for one week before the pilot. The third is to scope the pilot: select the 2-3 highest-volume roles, define the scoring rubric (5-7 criteria), and identify the human-approval gate. The fourth is to choose the LLM: open-weight on-prem if CVs contain regulated data, commercial API otherwise. The fifth is to build the LangGraph workflow with a logging mechanism that captures every decision for the EU AI Act compliance file. The pilot is not a proof of concept; it is a measured, compliance-ready baseline that the insurer can use to justify scaling to all hiring pipelines.

  • AI Process Audit and 8-Week Integration Sprint for E-Commerce Support in the USA

    The Back-Office Bottleneck in a 2,000+ Employee E-Commerce Operation

    A 2,000+ employee e-commerce and retail company in the USA runs customer support across multiple channels: email, live chat, phone, and a self-service portal. The support team handles 15,000 to 25,000 tickets per month, with an average first-response time of 45 minutes and a misclassification rate of 12 percent. Back-office operations process 8,000 to 12,000 invoices monthly, with a data-entry error rate of 4 to 6 percent. Internal teams spend 3 to 5 hours per week searching through documentation, CRM records, and policy files to answer routine questions. The company has already automated one process, typically a document extraction workflow on the invoice pipeline, but the rest of the support and back-office stack still runs on manual triage, copy-paste data entry, and ad-hoc knowledge lookups. The pain is not a lack of tools. It is the absence of a measured baseline and a fixed-scope path from one automated process to a repeatable, auditable system that satisfies ISO 27001 controls.

    Why Off-the-Shelf Chatbots and In-House LLM Pipelines Fall Short

    Most companies at this stage reach for a generic chatbot platform or a point-solution RAG tool. The chatbot platform handles ticket routing but cannot access the company’s CRM, ERP, or internal documentation, so it deflects 60 to 70 percent of queries to a human agent without reducing cycle time. The RAG tool indexes a static document set but does not connect to live CRM records or helpdesk tickets, so the answers it returns are stale by the time a support agent reads them. A third common approach is to build a custom LLM pipeline in-house. This works for a single use case but requires a dedicated ML team, a GPU infrastructure budget of $15,000 to $40,000 per month, and 6 to 9 months of development before the first measurable result. None of these paths produce a fixed-scope pilot with a documented before/after baseline, which is the minimum evidence a CFO or compliance officer needs to approve a rollout. The failure mode is not technical. It is the absence of a delivery model that ties the build to a measurable outcome in 8 weeks or less.

    The Integration Sprint: Audit, Pilot, and Measured Baseline in 8 Weeks

    The integration sprint model starts with a process audit that maps every workflow in the support and back-office stack, measures cycle time and error rate on each, and ranks them by impact. The output is a fixed-scope pilot specification: one workflow, one integration, one measured outcome. For a company at the One Process Automated maturity stage, the next pilot is typically a conversational agent for customer support ticket triage or an internal knowledge search assistant built on retrieval-augmented generation over the company’s own documentation and CRM records. The architecture is model-agnostic: OpenAI or Anthropic APIs handle tasks where quality matters and data is non-sensitive, while open-weight models run on the client’s own hardware where regulated data cannot leave the building. The agent connects to the existing helpdesk, CRM, and ERP through their native REST APIs and webhooks. No system is replaced. The AI layer drafts, classifies, or retrieves; a human approves anything that touches money, health data, or a contract. The pilot ships with a documented before/after baseline on cycle time and error rate, which is the evidence the compliance team needs to map the new system to ISO 27001 Annex A controls.

    How to Start: Four Concrete Steps in the First 8 Weeks

    Week 1: run the process audit. Pull 90 days of ticket data from the helpdesk, 60 days of invoice data from the ERP, and a sample of internal knowledge queries from the support team. Measure cycle time, error rate, and volume on each workflow. Identify the two or three highest-impact candidates that can run in parallel without conflicting with the existing automation. Week 2: write the fixed-scope pilot specification. Define the target workflow, the integration points (which CRM fields, which helpdesk API endpoints, which document sources for the RAG index), the human-in-the-loop approval rules, and the before/after measurement plan. Week 3 to 5: build and integrate. Deploy the open-weight model on the client’s on-premise hardware for regulated data paths. Connect the agent to the helpdesk and CRM via REST API and webhooks. Build the RAG index over the company’s documentation and CRM records. Week 6 to 8: validate and measure. Run the agent in production with human approval on edge cases. Re-measure cycle time and error rate. Document the delta. Deliver the pilot report with the compliance mapping to ISO 27001 controls.

  • AI Ticket Triage for UK Professional Services: An 8-Week Claude API Pilot

    The Process Audit: Finding the One Workflow Worth Automating

    A 201 to 500-person professional services firm in the UK typically runs its support operation on a shared Gmail inbox, a helpdesk like Zendesk or Freshdesk, and a Google Sheet for monthly reporting. The support team of 5 to 15 agents handles 200 to 1,000 tickets per month, and the first 15 to 25 percent of each agent’s day goes to reading, classifying, and routing tickets before any actual problem-solving begins. The monthly report that goes to partners or clients takes an analyst 4 to 6 hours to compile from three or four different sources. The process audit that precedes any automation identifies which of these workflows have clear, rule-based logic that an LLM can replicate with high confidence. For most firms at this scale, ticket triage and routing is the first process worth automating because it is high-volume, repetitive, and the routing rules are already documented in the team’s onboarding materials. The audit also establishes the before/after baseline: average first-response time, misrouting rate, and hours spent on classification per agent per week. This baseline is what the 8-week pilot measures against.

    Model Selection and the Predictive Scoring Layer

    The pilot uses Anthropic’s Claude API as the classification engine. Claude handles long context windows up to 200,000 tokens, which matters because a support ticket thread can include 10 to 20 email exchanges with attachments. The prompt engineering phase takes two weeks and produces a classification schema: ticket category, urgency level, recommended routing team, and a confidence score. Predictive scoring sits on top of this classification. The model assigns a numerical probability to each ticket indicating escalation risk, resolution time estimate, and churn signal, learned from 30 to 60 days of historical ticket data. Tickets scoring above a threshold (typically 0.75) are flagged for senior agent review before routing. The architecture is model-agnostic by design: the integration layer talks to Claude’s API endpoint, but if a client contract later requires data to stay in the UK, the endpoint switches to an open-weight model deployed on the firm’s own hardware. The integration code does not change. This is the difference between a locked-in vendor solution and a system that adapts to regulatory or contractual constraints without a rebuild.

    Integration with Google Workspace and the Existing Helpdesk

    The AI agent plugs into the firm’s existing tools through their APIs rather than replacing them. For Google Workspace, the agent uses the Gmail API to monitor the shared support inbox, read incoming tickets, and draft responses. It uses the Google Calendar API to schedule follow-up calls and the Google Drive API to log ticket metadata and monthly report drafts. The helpdesk integration (Zendesk, Freshdesk, or similar) handles the ticket lifecycle: status changes, assignment, and resolution tracking. The agent does not replace the helpdesk; it sits in front of it, classifying and routing before the ticket reaches a human agent. For monthly reporting, the agent pulls ticket volume, resolution times, escalation rates, and CSAT scores from the helpdesk API and compiles them into a structured Google Sheet or Drive document. The analyst reviews the draft, adds narrative context, and finalizes the report. The human-in-the-loop design means any ticket involving billing, contracts, or sensitive client data triggers a mandatory human approval before the agent takes action. This is not a compliance checkbox; it is the operational reality of a professional services firm where a misrouted contract question can cost a client relationship.

    GDPR Compliance: What the UK Data Protection Act Requires

    GDPR compliance for a UK professional services firm using an LLM API requires three specific controls. First, data minimization under Article 5: strip names, email addresses, phone numbers, and other direct identifiers from ticket content before sending it to Anthropic’s API. The classification prompt receives anonymized ticket text; the agent maps the classification back to the original ticket in the helpdesk where full data resides. Second, processor agreement under Article 28: Anthropic must be listed as a data processor in the firm’s GDPR register, and the data processing agreement must specify that ticket content is used only for the classification task and not for model training. Third, data residency: if client contracts require data to stay in the UK, the firm deploys an open-weight model on its own hardware. The model-agnostic architecture means this switch is a configuration change, not a rebuild. The 8-week pilot includes a compliance review in week six, where the firm’s data protection officer or external counsel verifies that the data flow diagram, processor agreement, and anonymization logic meet UK GDPR requirements. This step is non-negotiable for professional services firms handling client data under confidentiality agreements.

    The 8-Week Pilot: From Baseline to Measured Outcome

    The 8-week timeline breaks down as follows. Week one: process audit and data preparation. The team exports 30 to 60 days of historical tickets, tags them by category and resolution time, and identifies the top three categories consuming the most agent hours. Weeks two and three: model selection and prompt engineering. The team tests Claude’s classification accuracy against the historical data, iterates on the prompt schema, and builds the predictive scoring model. Weeks four and five: integration. The agent connects to the helpdesk API, Gmail API, and Google Drive. The support team runs the agent in shadow mode: it classifies and routes tickets in parallel with the human process, and the team compares the agent’s decisions against what the agents actually did. Week six: human-in-the-loop testing and compliance review. The agent goes live for a subset of tickets (typically the top two categories), with mandatory human approval for anything flagged as high-risk. The data protection officer reviews the data flow. Weeks seven and eight: measured baseline comparison and documentation. The team compares first-response time, misrouting rate, and hours spent on classification against the week-one baseline. A successful pilot shows a 30 to 50 percent reduction in first-response time and a misrouting rate under 3 percent. The documentation package includes the prompt schema, integration configuration, compliance review notes, and a rollout plan for additional categories or channels.

  • UK Advisory Firm Cuts Support Ticket Cost 34% with a LangGraph Voice Agent

    Background: A 1,200-Person UK Advisory Firm at the Pilot Stage

    This case study is a composite built from patterns observed across multiple engagements. No named customer appears. The firm described below is a fictional 1,200-person UK professional services company—call it Meridian Advisory—that provides tax, audit, and compliance services to mid-market clients. Its back office handles roughly 4,000 inbound support interactions per month across phone, email, and a Zendesk portal. The team is at the “running isolated pilots” stage of AI maturity: they have tested a chatbot on their website but have not yet connected AI to operational workflows. Their stack includes Zendesk for support, a legacy ERP for order and shipment tracking, and a CRM for client records. The operations director set a hard deadline: reduce the cost per support ticket by at least 25% within two quarters, driven by a 12% headcount freeze and rising call volumes from a new client onboarding cohort.

    Challenge: 11% Error Rate on Status Calls and a GDPR Constraint

    The operations team tracked 300 calls over two weeks and found that 62% of inbound volume was order and shipment status inquiries. Agents spent an average of 4.2 minutes per call, and 11% of those calls ended with the customer reporting incorrect information—usually a stale shipment date pulled from a spreadsheet that had not synced with the ERP. The back-office data entry team, which transcribed call outcomes into Zendesk, logged an 8.4% error rate on status fields. GDPR added a constraint: voice data and client records could not be processed on infrastructure outside the UK, and any automated handling of client data required a documented lawful basis under Article 6(1)(f) and a Data Protection Impact Assessment. The deadline was 8 weeks from audit to a limited live rollout, with a hard requirement that no customer-facing change went live without sign-off from the DPO.

    Approach: LangGraph State Machine with a UK-Hosted Voice Pipeline

    Forfis ran a two-week AI automation audit that scored five candidate workflows on volume, error rate, cycle time, and compliance risk. Order and shipment status updates scored highest: structured data, low financial risk, and a clear API path through the ERP. The pilot used LangGraph to model the conversation as a state machine: intent classification → ERP API call → response generation → escalation check. LangChain handled prompt templates, a vector store over the firm’s shipping policy documents, and tool calling for the Zendesk API. The voice layer used a UK-hosted speech-to-text and text-to-speech pipeline to keep data inside the UK border. Human-in-the-loop was built in: if the customer asked to cancel, dispute, or escalate, the graph routed to a live agent with a call summary. The pilot shipped with a measured baseline: 4.2-minute average handle time and 11% error rate on status fields.

    Outcome: 34% Cost Reduction and a 2.3% Error Rate

    After eight weeks, the voice agent handled 71% of order and shipment status calls in shadow mode, then 40% in live mode with human fallback. Average handle time for agent-handled calls dropped from 4.2 minutes to 1.8 minutes. The error rate on status fields fell from 11% to 2.3%, because the agent pulled data directly from the ERP rather than from a stale spreadsheet. Cost per support ticket for the status-inquiry segment dropped by 34%, from an estimated £11.20 to £7.40. The back-office data entry team reduced transcription errors by 61% because the agent logged structured outcomes into Zendesk automatically. The DPO signed off after the DPIA confirmed that voice data was encrypted in transit (TLS 1.3) and at rest (AES-256), and that no client data left the UK. The firm extended the pilot to invoice discrepancy handling in week 10.

    Lessons for Teams Running Isolated Pilots

    • The audit is not optional. The two-week process audit identified that 62% of call volume was status inquiries. Without that number, the team would have spent the 8-week window on a lower-impact workflow. Score every candidate on volume, error rate, and compliance risk before writing a line of code.
    • Model-agnostic design protects you from vendor lock-in. The LangGraph state machine ran on OpenAI’s API for the pilot but was architected to swap in an open-weight model on the client’s own hardware if the DPO later required on-premises inference. This flexibility cost nothing in the pilot and saved a renegotiation later.
    • Human-in-the-loop is a design constraint, not a feature. The escalation path was defined in the LangGraph topology before the first prompt was written. Teams that bolt on human approval after the model is live tend to ship with gaps that GDPR reviewers flag.
    • Measure the baseline before you touch the system. The 11% error rate and 4.2-minute handle time were logged during the audit, not after the pilot. Without that baseline, the 34% cost reduction would have been an anecdote, not a defensible number for the board.

  • 12-Point Checklist: AI Lead-Qualification Pilot for a 20-Person UK Fintech Firm

    1. Verify the pilot scope is locked to one workflow

    Before any code is written, confirm the scope is locked to one workflow. For a 20-person fintech firm, that means the pilot covers lead qualification only — not invoice processing, not document extraction, not voice. The audit deliverable should name the specific CRM fields the agent will read and write, the webhook endpoints it will call, and the exact lead-qualification criteria the sales team already uses. A fixed scope prevents the pilot from drifting into a multi-week integration project that buries the team in configuration work instead of measuring cycle-time savings.

    2. Document the PCI DSS data-flow and risk assessment

    Run a formal risk assessment under PCI DSS Requirement 12.10 before the agent touches any production data. Document the data flow from first contact to qualified-lead status, confirm that cardholder data never enters the LLM prompt, and obtain a signed attestation from OpenAI that they do not retain training data. This documentation pack is a deliverable, not an afterthought. Without it, the pilot cannot pass internal governance review, and the 4-week timeline slips.

    3. Configure the CRM and webhook integration points

    Map every integration point before the pilot starts. The agent reads lead records from the CRM via its REST API, writes qualification scores back to the same CRM, and triggers webhooks to the helpdesk when a lead is flagged for human follow-up. Each endpoint needs an API key, a rate-limit budget, and a fallback path for when the CRM is down. For a 20-person firm, this typically means 3-5 endpoints, not 30.

    4. Define the human-in-the-loop approval threshold

    Set the human-in-the-loop threshold before the first test. The agent drafts the qualification response and classifies the lead, but a person approves any action that touches a contract, payment, or regulated data. For lead qualification, this means the agent can mark a lead as “qualified” or “unqualified” but cannot send a payment link or modify a contract clause. The approval step is logged with a timestamp and user ID, which feeds the error-rate baseline.

    5. Measure the before-state baseline on cycle time and error rate

    Capture the baseline before the agent goes live. Track time from first contact to qualified-lead status and the percentage of misclassified leads over a 2-week window using the existing manual process. These two numbers — cycle time and error rate — are the only metrics that matter for the pilot report. Everything else is noise. For a 20-person firm, a 2-week baseline is sufficient to establish a statistically meaningful before-state.

    6. Implement the cardholder-data filter and test it

    Build a pre-processing filter that strips or masks any field containing cardholder data, PAN, or CVV before the prompt is sent to the OpenAI API. Test the filter with synthetic data that includes edge cases: partial PANs, CVVs embedded in free-text notes, and card numbers in email subject lines. The filter must reject or flag any input that fails the mask, and the rejection log must be retained for the PCI DSS audit trail.

    7. Write and version the prompt template for lead qualification

    Write the prompt template that the agent uses to classify leads and draft responses. The template should include the firm’s specific qualification criteria, the tone of voice the sales team expects, and a clear instruction to reject any input that contains cardholder data. Version the prompt in a repository, not in a config file. Each change to the prompt should be logged with a reason, because prompt drift is the most common cause of error-rate spikes in the first two weeks of operation.

  • AI Candidate Screening for a Swiss B2B SaaS Company: 3-Month Fixed-Scope Pilot

    The Back-Office Bottleneck in Swiss B2B SaaS Hiring

    A 120-person B2B SaaS company in Zurich processes 40 to 60 candidate applications per week across three hiring pipelines. Each resume is a PDF or Word document. A recruiter opens it, copies fields into the ATS, flags mismatches against the job description, and posts a summary to the hiring channel in Slack. The average cycle time per applicant is 42 minutes. The field-level error rate, measured over a two-week sample, is 11.3%: wrong years of experience, missed certifications, misclassified seniority. The cost is not just time. A misclassified candidate who reaches the interview stage wastes the hiring manager’s 30-minute slot and delays the pipeline by a week.

    The constraint is not the volume. It is the accuracy. Manual extraction from unstructured documents is where the errors concentrate. The fix is not a new ATS. It is an extraction layer that reads the document, structures the data, and routes it to the existing workflow with a human approval step before anything touches the hiring decision.

    Fixed-Scope Pilot: What Gets Built in 3 Months

    The pilot scope is locked in a one-page document before any code is written. The workflow: resumes arrive via email or the ATS API. An extraction model parses the document and outputs structured JSON: name, email, phone, years of experience, skills, certifications, current role, location. The output lands in a Slack channel with a formatted card. A recruiter reviews the card, corrects any field, and clicks approve. The approved record syncs back to the ATS via its API. Every step is logged with a timestamp and the user ID of the approver.

    The architecture is model-agnostic. Because candidate data includes personal information subject to the Swiss FADP and the company holds ISO 27001 certification, the extraction model runs on the client’s own hardware using an open-weight model. No resume data leaves the building. The orchestration layer is n8n, which handles the API calls, the Slack message formatting, and the audit log. The existing ATS is not replaced; it remains the system of record. The AI layer sits in front of it, doing the extraction and routing work that currently consumes 42 minutes per applicant.

    Measuring the Baseline: Cycle Time and Error Rate

    The pilot ships with a measured baseline. Before go-live, the team samples 50 resumes processed manually over two weeks. They record the time from receipt to ATS entry and count field-level errors against the source document. The baseline: 42 minutes per applicant, 11.3% error rate. After go-live, the same 50-resume sample is processed through the automated pipeline. The recruiter still reviews and approves, but the extraction and formatting are done by the model. The post-pilot measurement: 7 minutes per applicant, 1.4% error rate. The remaining errors are cases where the source document is ambiguous (a candidate lists two overlapping roles) and the model flags them for manual review rather than guessing.

    The ISO 27001 requirement is addressed in the design, not as an afterthought. The n8n workflow logs every document processed, every field extracted, every approval action, and the user ID of the approver. Access to the model and the data store is restricted to the operations team via role-based controls. The audit log is retained for 12 months, satisfying the ISMS documentation requirement. The data deletion process for GDPR/FADP requests is a single API call that purges the candidate record from the extraction store and the Slack channel.

    ISO 27001 and Swiss FADP: Where the Model Runs

    The model selection is a compliance decision first, a quality decision second. The candidate data includes names, contact details, work history, and sometimes health-related information (a candidate may mention a disability accommodation). Under the Swiss FADP, this is personal data. Under ISO 27001, the company must demonstrate that data handling meets its ISMS controls. Sending this data to a third-party API without a documented data processing agreement and a clear retention policy violates both.

    The default architecture runs an open-weight model on the client’s own server. The model is fine-tuned on the company’s historical resume data (with consent) to improve extraction accuracy for the specific job families the company hires for. The n8n workflow calls the local model via a REST endpoint. No data leaves the network. If the client later wants to add a classification step (e.g., flagging candidates who match a specific certification requirement), a commercial API can be used for that narrow sub-task, provided the data flow is documented in the ISMS and the candidate has been informed of the processing. The human-in-the-loop step remains: the model drafts, the recruiter approves, the system logs the decision.

    Rollout Beyond the Pilot: What Changes After Month 3

    The pilot is not a one-off. The n8n workflow is designed to be extended. After the 3-month pilot proves out on one hiring pipeline, the same extraction logic applies to the other two pipelines with minor adjustments to the job description mapping. The Slack integration means the hiring team sees the structured output in the channel they already use, not in a new dashboard. The ATS remains the system of record; the AI layer is a front-end that reduces the manual work before data enters the ATS.

    The managed operation phase covers model monitoring, prompt updates when the job description changes, and the quarterly audit log review required by ISO 27001. The client’s operations team can view the n8n workflow in a visual interface, adjust routing rules, and add new document types (cover letters, reference letters) without a new development cycle. The fixed-scope pilot de-risks the initial investment. The rollout is incremental, measured, and tied to the same before/after metrics that justified the pilot.

  • On-Premise AI Invoice Processing for Austrian Healthcare: A 2-Week Pilot

    The Problem: Manual Data Entry in Austrian Healthcare Finance

    Finance teams in Austrian healthcare and medtech companies face a persistent bottleneck: manual data entry from invoices. For a company of 201-500 employees, this means dozens of hours per week spent transcribing vendor details, line items, and tax codes into the ERP. The risk is not just cost; it is error. A single misclassified VAT code can trigger an audit finding under Austrian tax law. The goal is to replace this manual process with an AI workflow that extracts data, enriches it with vendor master data, and posts it to the ledger. This must be done on-premise to comply with GDPR, ensuring patient data on invoices never leaves the building. The timeline is tight: two weeks to a working pilot.

    Prerequisites for a 2-Week Pilot

    • On-premise GPU server: Minimum 24 GB VRAM (e.g., NVIDIA A5000 or RTX 4090) for running 7B-13B parameter open-weight models.
    • ERP API access: A stable REST API or webhook endpoint for your accounting system (SAP, Dynamics, or Lexware).
    • Baseline data: At least 500 historical invoices with their correct ledger entries to measure accuracy.
    • Legal review: A DPO or legal counsel to approve the GDPR Article 30 record of processing activities.
    • Network isolation: A dedicated VLAN for the AI server to prevent data exfiltration.
    • Human-in-the-loop workflow: A defined process for finance staff to review and approve AI-extracted data.

    Steps 1-3: Deployment, Preprocessing, and Fine-Tuning

    Step 1: Deploy the open-weight model on-premise.
    Install Ollama or vLLM on your GPU server. Pull a 7B or 13B parameter model (e.g., Llama 3 8B or Mistral 7B). Configure the model to run in a secure, isolated container. Ensure the server is on a dedicated VLAN with no internet access except for model updates. Test the inference speed; it should process an invoice in under 5 seconds.

    Step 2: Build the invoice preprocessing pipeline.
    Use a library like PyMuPDF to extract text from PDF invoices. Implement a rule-based filter to strip personal data (names, addresses) that is not required for the ledger entry. This satisfies GDPR data minimization. Store the cleaned text in a local database.

    Step 3: Fine-tune the model on your invoice data.
    Use your 500 historical invoices to fine-tune the model. Focus on the specific fields you need: vendor name, invoice number, line items, total, and VAT rate. Use a low learning rate (1e-5) to avoid overfitting. Evaluate the model on a holdout set of 50 invoices. Aim for 95% accuracy on key fields.

    Steps 4-6: ERP Integration, Human-in-the-Loop, and Pilot

    Step 4: Integrate with the ERP via REST API.
    Build a Python service that takes the extracted data and sends it to your ERP’s REST API. Use OAuth 2.0 for authentication. The payload should include the invoice ID, vendor, line items, and tax breakdown. Implement a webhook to notify the finance team when an invoice is processed. If the API fails, queue the data and retry with exponential backoff. Log all API calls for audit purposes.

    Step 5: Implement the human-in-the-loop workflow.
    Configure the system to route invoices with a confidence score below 95% to a human reviewer. Use a simple web interface for finance staff to approve or correct the data. Ensure the interface clearly shows the AI’s confidence score and the original invoice image. This step is critical for GDPR compliance and error prevention.

    Step 6: Run the pilot with 10-20% of invoice volume.
    Start with a small subset of invoices to validate the pipeline. Monitor the accuracy, speed, and rejection rate. Collect feedback from the finance team. Adjust the model or preprocessing pipeline based on the feedback. Do not scale to 100% volume until the error rate is below 2%.

    Common Pitfalls and How to Detect Them

    • Hallucination in vendor details: The model invents a vendor name or misclassifies a tax code. Detect this by monitoring the confidence score. If the score for a field drops below 95%, route the invoice to a human reviewer.
    • Data leakage: Personal data is not stripped before processing. Detect this by auditing the logs for any personal data in the model’s context window. Ensure the preprocessing pipeline is working correctly.
    • ERP API downtime: The ERP API is down, and the system drops invoices. Detect this by monitoring the API health and implementing a queue with exponential backoff. Ensure the system does not lose data during outages.
    • Model drift: The model’s accuracy degrades over time as invoice formats change. Detect this by tracking the rejection rate. If the rate increases, retrain the model with new data.

    Conclusion: From Pilot to Managed Operations

    The 2-week pilot is a validation, not a full rollout. Once the pilot is successful, the next step is to scale to 100% of invoice volume and add new invoice types. This should take 2-4 weeks. After that, move to managed AI operations, where a partner handles monitoring, retraining, and updates. The goal is to reduce manual data entry by 80-90% and cut cycle time from days to hours. The on-premise architecture ensures GDPR compliance, and the human-in-the-loop workflow ensures accuracy. The next logical step is to extend the AI workflow to other finance processes, such as expense reports or purchase orders.

  • 12-Point Checklist: Automating Lead Qualification in Swiss Fintech

    12-Point Checklist: Automating Lead Qualification and Monthly Reporting in 8 Weeks

    1. Map every manual step in the current lead qualification and monthly reporting process.
      Document who touches each lead, how long it takes, and where errors occur. This baseline is your before/after measurement point.

    2. Score each workflow on volume, error cost, and data sensitivity.
      Prioritize the highest-impact, lowest-risk workflow for the 8-week pilot. Lead qualification typically wins over complex reporting automation.

    3. Verify data residency and compliance requirements under the EU AI Act.
      For Swiss fintech, regulated data must stay on-premises. Confirm that your CRM, Confluence, and model hosting meet FINMA and EU AI Act transparency rules.

    4. Configure pgvector in your existing PostgreSQL instance.
      Embed CRM records, Confluence documentation, and historical deal outcomes into 1,536-dimensional vectors. This keeps regulated data in-house and adds roughly 18 ms of retrieval latency.

    5. Build the workflow orchestration layer.
      Use n8n, Temporal, or a custom state machine to coordinate: ingest lead, call classification model, retrieve context via pgvector, draft score, route to human approver, write back to CRM.

    6. Integrate Notion or Confluence as the single source of truth for qualification criteria.
      Embed these documents into pgvector so the AI retrieves relevant passages during scoring. Sales ops can update rules without redeploying code.

    7. Implement human-in-the-loop approval for high-value or high-risk leads.
      Any lead flagged as high-value or affecting a customer’s financial standing must be reviewed by a human. Log every decision with timestamp and reviewer ID.

    8. Document the model’s intended purpose and decision logic for EU AI Act compliance.
      High-risk AI systems require transparency. Maintain an audit trail mapping each AI decision to a specific human reviewer and the criteria used.

    9. Measure baseline cycle time and error rate before the pilot.
      Track how long it takes to qualify a lead and the percentage of misclassified leads. This is your before/after baseline.

    10. Run the pilot on one lead qualification workflow for 4 weeks.
      Keep the scope fixed. Do not expand to monthly reporting or other workflows until the pilot ships with measurable results.

    11. Analyze before/after metrics and document compliance artifacts.
      Compare cycle time, error rate, and human review load. Prepare the audit trail for EU AI Act and FINMA review.

    12. Plan rollout and managed operations for the next phase.
      Define SLAs for model monitoring, re-training, and human-in-the-loop queue management. Assign ownership of the AI layer to the vendor and the CRM to your internal team.

    Maintaining the Checklist Over Time

    The checklist above is a living document. After the 8-week pilot, revisit each item and mark it “done,” “not done,” or “needs revision.” If the pilot revealed that the orchestration layer could not handle peak load, or that the pgvector retrieval latency exceeded 50 ms under concurrent queries, update the relevant item with the specific fix. Assign a single owner—typically the head of sales operations or the AI vendor’s project lead—to review the checklist quarterly. As the EU AI Act evolves and your CRM or Confluence schema changes, the checklist must adapt. The goal is not to freeze the process but to ensure that every change is deliberate, documented, and measured against the baseline you established in week one.

    Timeline and Scope Constraints

    The 8-week timeline assumes your CRM and Confluence APIs are accessible and that data residency requirements are met by hosting models on-premises. If your firm uses a cloud-hosted CRM that does not support on-premises model inference, you will need to add a data-sync layer, which can extend the timeline by 2–3 weeks. Similarly, if your Confluence instance is not API-accessible, you will need to export documents manually, which adds friction to the embedding pipeline. The checklist is designed to be flexible: if an item cannot be completed in the allocated time, document the blocker and adjust the pilot scope rather than extending the timeline. The goal is to ship a measurable pilot, not a perfect system.

  • UAE Payments Firm Cuts Ticket Cycle Time 38% with a Claude-Based Triage Agent

    Background: A 2,400-Person Payments Firm in the UAE

    This case study is a composite drawn from patterns Forfis has observed across multiple engagements in Tier-1 markets. No named customer is represented. The details below reflect a recurring profile: a mid-to-large fintech or payments company in the UAE or Gulf region, operating under GDPR-equivalent data-protection rules, with a helpdesk that has outgrown manual triage.

    The company in this scenario is a payments processor with roughly 2,400 employees, a mix of engineering, compliance, and customer-operations staff. Its product stack includes a core payment engine, a merchant portal, and a customer-facing helpdesk running on a commercial platform. The helpdesk handles 18,000 to 22,000 tickets per month, the majority of which are routine: failed-payment inquiries, settlement-delay questions, and document-request follow-ups. Senior operations staff spend an estimated 35 to 45 percent of their week reading, categorizing, and routing these tickets before any substantive work begins.

    Challenge: Senior Staff Buried Under Routine Triage

    The operations director set a clear constraint: senior staff were being consumed by work that did not require their judgment. A payment-failure ticket that follows the standard runbook in Confluence should not be read by a team lead with eight years of settlement experience. The pressure was not just efficiency; it was retention. Three senior operations managers had left in the preceding year, citing repetitive triage as a primary factor.

    Compliance added a second constraint. The firm processes customer data subject to the UAE Data Protection Law (Federal Decree-Law No. 45 of 2021), which aligns closely with GDPR Articles 5, 28, and 30. Any AI system touching ticket content had to demonstrate data minimization, processor accountability, and a documented right-to-erasure path. The firm had already run two isolated pilots on document extraction for onboarding, but those pilots had not produced a measured baseline and had not moved to production. The operations team was skeptical of a third pilot unless the scope was narrow, the timeline was fixed, and the success criteria were written into the contract before a single line of code was written.

    Approach: A Fixed-Scope Pilot on One Workflow

    Forfis scoped the engagement as a fixed-scope, three-month pilot on a single workflow: ticket triage and routing for the payment-failure and settlement-delay categories. The architecture used the Anthropic Claude API for classification and summarization, with the model called from a lightweight service that read ticket content from the helpdesk’s REST API and wrote routing decisions back. The knowledge base lived in Confluence, queried through its search API to pull the relevant runbook for each ticket category.

    The delivery model was managed AI operations from day one. Forfis handled the technical planning, the prompt engineering, the evaluation harness, and the integration work. The client’s operations team provided the labeled sample set (400 historical tickets with correct routing decisions) and the Confluence content owners. The human-in-the-loop boundary was explicit: the agent classified and routed, but any ticket flagged as involving a refund, a contract amendment, or a regulatory report was suppressed from auto-routing and escalated to a senior reviewer. Every model call was logged with a retention window matching the firm’s records-management policy, satisfying the processor-accountability requirement under the UAE law and GDPR Article 30.

    Outcome: Measured Cycle-Time Reduction and Error-Rate Drop

    The pilot ran for twelve weeks. The first two weeks were the process audit: Forfis mapped the top ten ticket intents, measured the current median cycle time (4.2 hours from ticket creation to first substantive response) and the current misrouting rate (11.3 percent on a 300-ticket sample). Weeks three through six built the triage agent and the evaluation harness. Weeks seven through twelve ran shadow mode: the agent drafted a routing decision, a human approved or overrode it, and the override was logged.

    By week twelve, the agent’s classification accuracy on a held-out set of 200 tickets was 94.1 percent. The median cycle time for the two target categories dropped to 2.6 hours, a 38 percent reduction. The misrouting rate fell to 3.8 percent. Three senior operations managers reported spending roughly 12 to 15 hours per week less on initial triage, which they redirected to escalation handling and vendor-management work. The client extended the engagement to a managed-operations contract covering model monitoring, Confluence content review, and incident response at a fixed monthly fee. The pilot did not expand to fraud detection or chargeback handling; those remain separate engagements with their own baselines.

    Lessons for Teams Running Isolated Pilots in Regulated Sectors

    Five lessons from this engagement generalize to similar teams in regulated, high-volume operations:

    • Scope the pilot to one workflow, not a category. “Ticket triage” is too broad. “Triage and routing for payment-failure and settlement-delay tickets” is a contract. The narrower the scope, the more defensible the baseline and the faster the rollout decision.

    • Write the success criteria before the audit. The 94 percent accuracy threshold and the 30 percent cycle-time reduction were in the statement of work before Forfis touched the helpdesk API. Without that, the pilot becomes a demo, not a decision.

    • Keep the knowledge base in the tool the team already uses. Confluence was the source of truth for runbooks. Pulling from it via API meant the content owners did not need to learn a new system, and updates propagated without a retraining step.

    • Log every model call from day one. The compliance team asked for the audit trail in week four, not week twelve. Having it from week one turned a potential blocker into a non-issue.

    • Do not let the pilot absorb adjacent workflows. The operations team wanted fraud triage in week five. Holding the line kept the timeline realistic and the error-rate target achievable.