Forfis Blog

Category: Healthcare and Medtech

  • Cutting Medtech Invoice Error Rates in the UAE: A 3-Month Fixed-Scope Pilot

    The Back-Office Error Rate That No ERP Upgrade Fixed

    The accounts-payable team at a 201-500-person medtech company in the UAE processes 80 to 120 vendor invoices per week. Each invoice passes through a manual cycle: a clerk opens the PDF, reads the line items, cross-references the purchase order in the ERP, checks the vendor master for tax rate and payment terms, enters the data into the AP module, and flags anything that does not match. The average cycle time is 14 minutes per invoice. The field-level error rate—wrong vendor code, incorrect tax percentage, missing PO reference, duplicated line item—sits at 6 to 9 percent. Every error triggers a correction cycle: the invoice is rejected, the vendor is contacted, the data is re-entered, and the payment is delayed by 3 to 7 days. In a supply chain where device serials are tied to patient records and clinical trial sites, a mis-keyed invoice is not just an AP problem; it is a HIPAA-adjacent data-integrity risk. The AP team is stretched thin, and the error rate has not improved in two years despite two ERP upgrades.

    Why More Staff and Rules-Based OCR Do Not Fix the Error Rate

    The first common response is to add more AP staff. This reduces cycle time but does not reduce the error rate, because the errors are not caused by speed; they are caused by the cognitive load of cross-referencing four systems (PDF, ERP, vendor master, contract) in sequence. A clerk who has processed 40 invoices in a row makes more errors on the 41st than on the first. The second response is to deploy a rules-based OCR tool. These tools extract text accurately but do not validate it. They will faithfully extract ‘VAT @ 5%’ and ‘VAT 5%’ and ‘5% VAT’ as three different values, and they will not flag that the vendor’s contract specifies a 0% rate for intra-regional supply. The third response is to build a custom RPA bot that clicks through the ERP. RPA automates the keystrokes but not the judgment; it will enter the wrong vendor code with the same confidence as the right one. None of these approaches address the root cause: the back office is a data-enrichment problem, not a data-entry problem.

    A Model-Agnostic Pipeline That Validates Before It Enters

    The proposed approach treats invoice processing as a data-enrichment and cleanup pipeline, not a data-entry task. The pipeline has four stages. First, extraction: Anthropic Claude API processes the invoice PDF and returns structured fields—vendor, PO number, line items, tax, total, due date—with a confidence score per field. Second, PHI routing: a classifier checks whether the document contains protected health information (patient-specific device serials, clinical trial references). If it does, the document is re-processed by an open-weight model (Llama 3 70B) running on the client’s own GPU server inside the UAE data center, satisfying the requirement that regulated data does not leave the building. If it does not, the Claude extraction stands. Third, enrichment and validation: the extracted fields are cross-referenced against the vendor master, the open PO database, and contract terms. Mismatches are flagged. Fourth, human review: any field with a confidence score below 0.85, or any field flagged by the enrichment step, routes to a Slack or Microsoft Teams approval channel. The AP clerk sees the original document, the extracted fields, and the flags, and approves, corrects, or rejects. The system never auto-posts to the ERP without a human click. The architecture is model-agnostic: the orchestration layer is decoupled from the inference provider, so the client can swap models without re-architecting the pipeline.

    How to Start: A 3-Month Fixed-Scope Pilot

    The pilot is fixed-scope and runs for 3 months. Week 1-2: Process audit and baseline. The team collects 300 to 500 historical invoices from the past 6 to 12 months, manually annotates them with the correct extracted fields, and records the time each AP clerk spends per invoice. This produces the baseline: average cycle time (14 minutes) and field-level error rate (7 percent). The team also executes the Business Associate Agreement with the AI vendor and confirms the DHA and MOHAP data-residency requirements for the UAE. Week 3-4: Build. The extraction pipeline is configured with Claude for non-PHI documents and the open-weight model for PHI. The enrichment rules are coded against the vendor master and PO database. The Slack or Teams approval flow is built with the client’s existing workspace. Week 5-6: Run. The pipeline processes live invoices. The AP team reviews flagged items in Slack. The team tunes prompts and confidence thresholds weekly. Week 7-8: Measure and handover. The before/after report is produced: cycle time drops from 14 minutes to 3 minutes per invoice; the field-level error rate drops from 7 percent to under 2 percent. The documentation, prompt library, and enrichment rules are handed over for managed operation.

    Pitfalls That Turn a Pilot Into a Cost Center

    Three failure modes kill pilots before they produce a measurable result. First, under-scoping the enrichment step. If the pipeline extracts fields but does not cross-reference them against the vendor master and PO database, the error rate stays high because the model is guessing rather than validating. The enrichment layer is where the error rate drops from 7 percent to under 2 percent; skipping it means the pilot demonstrates extraction accuracy but not operational accuracy. Second, skipping the PHI routing rule. If the pipeline sends all documents to the Claude API without checking for PHI, the client creates a compliance gap that surfaces during a DHA or MOHAP audit. The routing rule must be in place before the first live invoice is processed, not added after the pilot. Third, treating the pilot as a demo. If the pilot only processes a curated set of clean invoices, the error-rate improvement will not hold at scale. The pilot must run on the full volume of live invoices, including the messy ones: multi-page PDFs, handwritten notes, vendor name variants, and missing PO references. The baseline must be measured on the same invoice set that the pilot processes, not on a different sample.

  • Cutting First-Response Time from 38 Hours to 4 in a German Medtech Distributor

    Background: A Mid-Size Medtech Distributor in Southern Germany

    This case study is a composite. It draws on patterns Forfis has observed across multiple engagements in German healthcare and medtech distribution. No named customer is represented; the company, metrics, and timeline are representative of the work we deliver, not a single identifiable client.

    The company in question is a mid-size medtech distributor in southern Germany, roughly 340 employees, operating across two regional warehouses and a central back office in Stuttgart. It handles order intake, shipment coordination, and after-sales support for orthopedic and diagnostic equipment. The ERP is SAP S/4HANA, the helpdesk is a legacy on-premises ticketing system, and the CRM is Microsoft Dynamics 365. The company had been running on a paper-and-email hybrid for inbound purchase orders and shipment confirmations for over a decade. No prior AI or automation project had been attempted; the operations team had flagged the bottleneck in internal reviews for three consecutive quarters without a funded solution.

    Challenge: A 24-Hour SLA the Manual Process Could Not Meet

    The trigger was a contractual deadline. A major hospital group, representing roughly 18 percent of the company’s annual revenue, issued a service-level agreement requiring order-status acknowledgments within 24 hours and shipment confirmations within 4 hours of dispatch. The existing process could not meet either threshold. Inbound purchase orders arrived as scanned PDFs, emailed attachments, and occasionally physical mail. A team of four operators manually transcribed each order into SAP, cross-referenced it against the shipment plan, and drafted a status email to the customer. The median first-response time was 38 hours. The 95th percentile was 72 hours. The error rate on transcribed fields was 6.2 percent, and each correction required a second pass through the approval chain.

    The operational pressure was compounded by GDPR. The documents contained patient identifiers, billing addresses, and in some cases clinical context. The company’s data protection officer had flagged the manual process as a compliance risk: paper documents were stored in unsecured filing cabinets, and email attachments were not consistently encrypted. The deadline was not optional. The hospital group had indicated that non-compliance would trigger a contract review in the following quarter.

    Approach: A Six-Week Integration Sprint on SAP and Claude

    Forfis ran a six-week integration sprint. The first week was a process audit: mapping every document type, every handoff, every approval gate, and every data field that touched the ERP. The audit identified 14 distinct document formats across purchase orders, packing lists, customs declarations, and shipment confirmations. The team selected the three highest-volume formats for the pilot, covering roughly 70 percent of inbound documents.

    The extraction pipeline used the Anthropic Claude API for document parsing and field classification. The model was prompted with structured output schemas matching the SAP data model. The orchestration layer, built on a workflow engine, routed each extracted record through a confidence check. Records above a 92 percent confidence threshold and containing no patient identifiers or payment amounts were auto-approved. Everything else went to a human approver in a queue built into the existing helpdesk. The SAP integration used the OData API to write order and shipment records directly into S/4HANA, bypassing the manual entry step entirely. The first-response template engine pulled the enriched record from SAP and generated a status email within 90 seconds of approval.

    Outcome: 38 Hours to 4 Hours, 6.2 Percent to 0.9 Percent

    The pilot went live in week seven on a subset of order types from two regional warehouses. The full rollout followed in weeks eight and nine, extending to all document types and both warehouses. The two-month stabilization phase that followed focused on reducing the human-review rate and tuning extraction thresholds per document type.

    The measured outcomes, tracked against the pre-pilot baseline, were as follows:

    • Median first-response time fell from 38 hours to 4 hours. The 95th percentile dropped from 72 hours to 11 hours.
    • Error rate on extracted fields fell from 6.2 percent to 0.9 percent.
    • Cycle time per document, from receipt to ERP entry, dropped from 4.5 hours to 22 minutes.
    • Human-review rate settled at 15 to 20 percent of records in steady state, down from the initial 25 percent.
    • Customer satisfaction for order-status inquiries rose by 11 points on a 100-point scale over the first quarter after go-live.

    Two full-time operators were redirected from manual data entry to exception handling and quality review. The GDPR compliance work, including the DPIA under Article 35 and the pseudonymization pipeline, was completed before go-live and required no rework during the stabilization phase.

    Lessons for Similar Teams in Healthcare and Medtech

    Five lessons from this engagement generalize to similar teams in healthcare and medtech distribution:

    • Start with the SLA, not the technology. The hospital group’s 24-hour acknowledgment requirement defined the success criterion. The technology choice followed from the constraint, not the other way around. Teams that start with a model demo and work backward to a business need tend to over-build and under-deliver.

    • The process audit is not optional. The 14 document formats, the unsecured filing cabinets, the inconsistent email encryption — none of this was visible from a technology specification. The audit took one week and saved an estimated three weeks of rework later in the sprint.

    • Human-in-the-loop is a design decision, not a fallback. The confidence threshold and the data-sensitivity routing were defined in week two, before any code was written. Teams that treat the human gate as an afterthought end up with either over-automation (errors in production) or under-automation (the human reviews everything, and the cycle time does not improve).

    • Model-agnostic architecture protects the client’s future. The client’s data protection officer asked, in week four, whether the pipeline could run on an open-weight model if the hospital group’s contract was renegotiated. Because the orchestration layer was decoupled from the model API, the answer was yes, and the rework estimate was under two weeks. A hard-coded dependency on a single vendor API would have made that conversation much harder.

    • The baseline is the deliverable. The before/after measurement on cycle time and error rate was agreed in the audit phase and tracked from day one of the pilot. Without that baseline, the 38-to-4-hour improvement would have been anecdotal. With it, the client could present the numbers to the hospital group’s procurement team with confidence.

  • Four-Week AI Pilot: Automating Order-Status Data Entry in a UK Medtech Firm

    The Problem: Manual Order-Status Data Entry in a Regulated UK Medtech Firm

    A 51-200 person UK medtech company handling order and shipment status updates for customer support is drowning in manual data entry. Every time a customer emails or calls about an order, an operator opens the CRM, searches for the order reference, checks the logistics provider’s tracking page, types the status back into the ticket, and logs the interaction. At 12-18 minutes per request and 3-5 percent transcription error rate, this single workflow consumes 15-25 percent of the support team’s capacity. The problem is not the volume alone; it is that the data is unstructured (email bodies, PDF attachments, voice notes) and the regulatory environment (ISO 27001, UK GDPR) means you cannot simply pipe customer emails into a third-party API without a documented risk assessment. The pilot targets this one process, automates the extraction and classification, and ships with a measured before/after baseline that proves the case for rollout.

    Prerequisites Before Week 1

    Before the dedicated AI team begins the four-week pilot, you need the following in place:

    • One named process owner from the customer support team who can answer questions about the current workflow and approve the pilot scope.
    • Access to historical documents: at least 200-500 examples of customer emails, PDFs, or spreadsheets containing order and shipment status requests, exported from Google Workspace or the CRM.
    • CRM API credentials with read/write permissions for the order and ticket objects, scoped to the pilot’s data set.
    • Google Workspace API access: Gmail API and Google Drive API scopes for the pilot mailbox, with data residency set to the UK or EU region.
    • A GPU server or cloud instance with at least 80 GB of VRAM (e.g., an A100 or H100) for running the open-weight model on-premise, or a confirmed decision to use a cloud GPU for the pilot phase only.
    • ISO 27001 documentation access: the client’s current statement of applicability and any existing risk assessments covering customer data handling, so the pilot’s controls align with the existing certification scope.

    Step 1: Run the Process Audit and Capture the Baseline

    The dedicated AI team maps every manual step in the order-status workflow and captures the baseline metrics. You export 200-500 historical requests from Google Workspace and the CRM, and the team tags each one with cycle time (from email receipt to ticket closure), error type (wrong order reference, missed shipment detail, incorrect status), and number of human touches. The output is a one-page scorecard: for a typical UK medtech firm, the baseline shows 14 minutes average cycle time, 4.2 percent error rate, and 3.1 human touches per request. This scorecard becomes the denominator for the before/after report and the justification for the pilot’s scope. The team also identifies which fields in the extracted data touch money, health data, or contracts, because those fields will require human-in-the-loop approval in the next step.

    Step 2: Select and Fine-Tune the Open-Weight Model On-Premise

    The team selects an open-weight model that fits the client’s GPU and data constraints. For a UK medtech firm where patient identifiers and order details cannot leave the building, the default is Llama 3 70B or Mistral 8x7B running on the client’s on-premise A100 server. The model is fine-tuned on the 200-500 historical documents from Step 1, using a supervised fine-tuning (SFT) dataset where each example pairs the raw email or PDF with the correctly extracted fields (order reference, shipment ID, status, date, customer name). The fine-tuning runs for 2-3 epochs on the client’s GPU, taking 4-8 hours. The team evaluates the fine-tuned model on a held-out set of 50 documents, targeting a field-level accuracy of 95 percent or higher before moving to integration. If accuracy falls below 95 percent, the team iterates on the SFT dataset or switches to a larger model variant.

    Step 3: Build the Google Workspace and CRM Integration

    The pipeline connects to Google Workspace through the Gmail API and Google Drive API. Incoming emails to the pilot mailbox trigger a push notification; the pipeline fetches the message body and any attached PDFs or spreadsheets, passes them to the on-premise inference endpoint, and receives structured JSON output containing the extracted fields. The pipeline then calls the CRM’s REST API to look up the order by reference, pulls the current shipment status from the logistics provider’s API (DHL, DPD, or the 3PL system), and merges the two data sets. The output is a draft customer-facing update and a structured record for the CRM. All API calls are logged with timestamps, request IDs, and data classification tags, feeding directly into the client’s ISO 27001 audit trail. The integration uses the client’s existing service accounts, not new credentials, to minimize the attack surface.

    Step 4: Configure the Human-in-the-Loop Approval Gate

    The approval interface is a simple web dashboard where the support operator sees a diff view: the source document on the left, the model’s extracted fields on the right, and a highlight on any field classified as touching money, health data, or a contract. The operator can approve, edit, or reject each field. In practice, 70-85 percent of routine order-status updates pass without human intervention because the model’s confidence score exceeds the threshold (typically 0.92) and no sensitive fields are present. The remaining 15-30 percent route to the approval queue with a 4-hour SLA. The queue is monitored by the process owner, and any rejection is logged with a reason code that feeds back into the SFT dataset for the next model iteration. This loop ensures the model improves with each week of live operation.

    Step 5: Run the Pilot and Produce the Before/After Report

    The pilot runs on a controlled sample of 50-100 live requests over two weeks. The measurement harness captures the same metrics as the baseline: cycle time, error rate, and human touches per request. The team compares the pilot results against the Step 1 scorecard and produces a before/after report. A typical result for a UK medtech firm is a 65 percent reduction in cycle time (from 14 minutes to 5 minutes) and a 50 percent drop in transcription errors (from 4.2 percent to 2.1 percent). The report also documents the ISO 27001 controls in place: on-premise data residency, access controls on the inference server, audit logging, and the human-in-the-loop gate for sensitive fields. This report becomes the business case for rollout to additional workflows, such as invoice processing or document extraction for clinical trial records.

  • Cutting Contract-Review Error Rates in UK Medtech Back Offices with AI Agents

    The Back-Office Error Tax in UK Medtech

    A 300-person UK medtech company processes roughly 400 to 800 contracts a month across sales, procurement, and clinical trial agreements. Each contract lands in a shared drive, gets read by a finance analyst, and is manually keyed into SAP or Microsoft Dynamics. The average cycle time from receipt to ERP entry is 14 to 22 business days. The field-level error rate on a sample of 500 historical records sits between 8 and 12 percent: wrong payment terms, misclassified liability clauses, missing termination dates. Every error triggers a correction cycle that adds 3 to 5 more days and costs the finance team an estimated 4 to 6 hours of rework per incident. The support ticket volume tied to these errors — internal queries from sales, legal, and procurement asking “what did we actually agree on?” — runs at 15 to 25 tickets per week, each consuming 20 to 35 minutes of analyst time. The cost per ticket, fully loaded, lands between 18 and 30 pounds. Multiply that by 50 weeks and the back-office error tax on a mid-size medtech firm is 15,000 to 40,000 pounds a year in direct labour, before counting the downstream risk of a mis-keyed contract clause surfacing in a dispute.

    Why Headcount, OCR, and RPA Do Not Fix the Problem

    The first common response is to add headcount. A 300-person firm hires two more finance analysts to clear the queue. The queue clears for six months, then grows again as contract volume scales with revenue. The error rate does not improve because the root cause is manual transcription from a PDF into a structured ERP field; more people make the same transcription errors at a higher volume. The second response is a rules-based OCR tool. These tools extract text accurately but stop at the text layer. They do not classify a liability clause, cross-reference a payment term against the ERP master data, or flag a missing termination date. The output still requires a human to read, interpret, and key the data, so the cycle time drops by 2 to 3 days at best and the error rate stays flat. The third response is a generic RPA bot that clicks through the ERP screens. RPA automates the keystrokes but not the judgment. When the contract format shifts — a new template, a redlined clause, a scanned image with poor contrast — the bot breaks and the human is back in the loop for every record. None of these approaches changes the underlying data flow: the contract is still read by a person, interpreted by a person, and entered by a person.

    The Integration Sprint: Audit, Pilot, Rollout

    The integration sprint starts with a two-week process audit that maps every workflow touching contracts, invoices, or master data in the finance and accounting function. The audit scores each workflow on volume, error rate, and cycle time, and the highest-scoring workflow becomes the pilot. For most 201 to 500-person UK medtech firms, that is contract review. The pilot runs for four weeks on a fixed scope: the AI agent reads the contract PDF, extracts parties, dates, payment terms, liability clauses, and termination conditions, enriches each field against the SAP or Dynamics master data, and writes the cleaned record back through the existing ERP API. The OpenAI API handles the extraction and classification because its reasoning quality on long, structured documents is currently ahead of open-weight alternatives. A named person in finance or legal approves every output that touches a contract clause or a payment amount. The pilot ships with a measured before/after baseline on cycle time and error rate, documented in a one-page report. If the baseline meets the pre-agreed threshold, the remaining scope is fixed in the sprint contract and the rollout proceeds over the next 16 weeks.

    Four Concrete First Steps

    Week one: assign a single named owner in the finance function who will act as the approver for the pilot. This person must have authority to sign off on contract fields and must be available for 30 minutes a day during the pilot. Week two: provision API access to the SAP or Dynamics environment. For SAP, that means the IDoc or OData endpoints the client already exposes. For Dynamics 365, the Web API or Dataverse connector. No ERP module is reconfigured. Week three: run the process audit. Pull a sample of 200 to 500 historical contracts from the last six months, measure the current cycle time and error rate, and score the workflows. Week four: freeze the pilot scope. The client and the delivery team agree on the exact number of contract fields to extract, the ERP objects to write to, and the approval workflow. The pilot contract is signed with a fixed price and a 16-week rollout window. The first live record enters the system in week five. The before/after baseline report is delivered at the end of week eight, and the decision to proceed to full rollout is made against that number.

  • AI Automation Audit and Pilot for Monthly Reporting in a UK Healthcare Firm

    The Problem: Manual Reporting and Fragmented Knowledge in a 51-200 Person UK Healthcare Firm

    You run a 51-200 person healthcare or medtech firm in the UK. Your monthly reporting cycle — pulling data from intake forms, candidate tracking sheets, and operational logs, then assembling it into a board-ready summary — takes a dedicated person three to four days each month. There is no AI in production yet. Your stack is Google Workspace, a CRM, and a handful of spreadsheets. You need round-the-clock customer response on your public channels and an internal knowledge search that lets any team member pull answers from your own documents without asking a specific person. The problem is not a lack of data; it is that the data sits in unstructured documents, email threads, and manual entries, and no one has a systematic way to turn that into a scored, searchable, report-ready output. The fix is a fixed-scope, four-week engagement that starts with a process audit, moves to a pilot on one workflow, and ends with a measured baseline you can use to justify rollout.

    Prerequisites: What You Need Before the Audit Starts

    Before Forfis engineers touch your systems, you need the following in place:

    • Google Workspace admin access for the domain where your team operates. Forfis engineers need read access to Gmail, Drive, and Calendar to map document flows and email-based intake. You do not need to grant write access during the audit.
    • A named internal owner with authority to approve scope changes and sign off on the pilot. This person should be the one who currently owns the monthly reporting cycle, not a proxy.
    • Two weeks of historical data from your last reporting cycle: the raw intake documents, the intermediate spreadsheets, and the final report. Forfis uses this to build the baseline and train the predictive scoring model.
    • A list of the top 10 questions your team asks repeatedly that currently require a human to answer. This becomes the seed set for the RAG assistant.
    • A decision on the pilot workflow. Forfis recommends picking the one with the highest cycle time and the clearest before/after metric. For most firms at your size, that is the monthly reporting assembly step.

    Step 1: Run the AI Process Audit and Build the Roadmap

    Forfis engineers spend the first five business days mapping your current workflow. They sit with the person who runs the monthly report, watch them pull data from each source, and log every manual step. The output is a process map showing where documents enter the system, how they are classified, where they sit in queues, and how the final report is assembled. They also run a document inventory across your Google Drive and Gmail, tagging each file by type, frequency, and owner. By the end of day five, you have a one-page decision matrix ranking your workflows by cycle time, error rate, and automation feasibility. The audit does not write code. It produces a prioritized roadmap with a recommended pilot workflow and a projected cycle-time reduction. You review the matrix with your internal owner and confirm the pilot scope before moving to step two.

    Step 2: Build the Internal Knowledge Search Assistant on Google Workspace

    Forfis engineers connect to your Google Workspace via the Google Workspace API and pull the last two months of relevant documents, emails, and calendar events. They build a vector index using OpenAI’s text-embedding-3-small model, storing embeddings in a managed vector database (Qdrant or Pinecone, depending on your data volume). The index covers your policy documents, past reports, onboarding guides, and any internal wiki you maintain. The RAG assistant is exposed through a simple web interface and a Google Chat app so your team can ask questions in the channel they already use. The model behind the assistant is GPT-4o via the OpenAI API, configured with a system prompt that enforces citation of source documents and a refusal to answer questions outside the indexed corpus. You test the assistant with your top 10 seed questions and adjust the retrieval parameters (top-k, similarity threshold) until answers are accurate and cited.

    Step 3: Implement Predictive Scoring for Monthly Reporting

    Forfis engineers take the historical data from your last three reporting cycles and build a predictive scoring pipeline. Each incoming document or data point is scored on three dimensions: category (e.g., clinical intake, commercial inquiry, internal ops), urgency (based on keywords and sender patterns), and completeness (whether required fields are present). The model is GPT-4o-mini via the OpenAI API, chosen for cost efficiency at your volume. The scoring output is a JSON object with a confidence score per dimension. Anything below a 0.85 confidence threshold is routed to a human reviewer in a Google Sheets queue. The reviewer approves, corrects, or rejects the classification, and that correction feeds back into the model’s training set for the next cycle. You set the threshold in a single configuration file; Forfis engineers tune it during the pilot based on your tolerance for false positives versus false negatives.

    Step 4: Run the Four-Week Pilot and Measure the Baseline

    The pilot runs in shadow mode for the first two weeks. The AI pipeline processes every document and data point that would normally go through your manual workflow, but the output is not used for the actual report. Forfis engineers compare the AI output against what your team would have produced manually, logging every discrepancy. In week three, the pipeline goes live: the predictive scoring model classifies incoming items, the RAG assistant answers internal queries, and the human-in-the-loop queue handles low-confidence items. Your team continues to produce the monthly report as usual, but now the AI has already drafted the data summary and flagged anomalies. In week four, Forfis engineers measure the before/after baseline: cycle time from document receipt to report completion, and error rate (misclassified or missing data points). The pilot report includes both numbers side by side, a list of every discrepancy found in shadow mode, and a go/no-go recommendation for full rollout. You review the report with your internal owner and decide whether to proceed.

    Common Pitfalls and How to Detect Them

    The most common failure mode is scope creep during the audit. The audit is fixed-scope and two weeks long. If you ask Forfis engineers to add a new workflow mid-audit, the timeline slips. Detect this by reviewing the decision matrix at the end of day five and confirming the pilot scope in writing before moving to step two.

    • Stale vector index. If you add new documents to Google Drive after the index is built, the RAG assistant will not find them. Detect this by running a weekly re-index job and checking the index size in the vector database dashboard. If the document count has not increased in two weeks, the job is failing.

    • Overly aggressive confidence threshold. Setting the threshold too high (e.g., 0.95) routes most items to human review, negating the automation benefit. Detect this by monitoring the queue length in Google Sheets. If the queue exceeds 30 items per day, lower the threshold to 0.80 and re-measure.

    • No baseline data. If you cannot provide two weeks of historical data before the pilot starts, Forfis engineers cannot build the before/after comparison. Detect this in the prerequisites check. If you are missing data, delay the pilot start rather than proceeding without a baseline.

  • Austrian Medtech Firm Cuts Invoice Reporting Cycle Time 61% in a 4-Week Pilot

    Background: A 1,200-Person Medtech Firm in Graz

    This case study is a composite drawn from patterns Forfis has observed across multiple engagements in the healthcare and medtech sector. It does not describe a single named client. The company, the metrics, and the timeline are representative of what we see in the field when a mid-sized European healthcare organization moves from isolated AI pilots to a compliance-safe, managed rollout of invoice-processing automation.

    The company is a 1,200-person medtech firm based in Graz, Austria, manufacturing surgical instruments and diagnostic kits. It operates in 14 EU markets and reports under Austrian GAAP with quarterly IFRS reconciliation. The finance and accounting team is 42 people, of whom 11 handle accounts payable and monthly reporting. Their ERP is SAP S/4HANA, their document management system is a legacy on-prem archive, and their internal communication runs on Microsoft Teams. They had run two prior AI pilots — one for email triage, one for contract clause extraction — but neither had moved past the pilot stage. The finance director’s mandate was clear: automate the monthly invoice-to-reporting cycle without introducing a new compliance surface, and do it within a 4-week pilot window before the Q3 close.

    The Challenge: 3,400 Invoices, 11 Staff, a 4-Week Window

    The monthly reporting cycle ran from the 1st to the 10th of each month. During that window, 11 finance staff manually processed roughly 3,400 vendor invoices, extracted line items, matched them to purchase orders, flagged discrepancies, and posted entries to SAP. The cycle time from invoice receipt to ERP posting averaged 6.2 days, and the error rate — measured as manual corrections per 100 invoices — sat at 14.3. The finance director had a hard deadline: the Q3 close was in 11 weeks, and the board had asked for a visible efficiency gain by year-end. Headcount was not the constraint; the constraint was that the 11-person team could not absorb the 14% error rate without a second review pass, which doubled the cycle time. The prior two AI pilots had stalled because they were scoped as “AI projects” rather than as workflow replacements with a measured baseline. The finance director wanted a fixed-scope pilot with a before/after metric, not a proof of concept.

    Approach: Audit, Then a Fixed-Scope Pilot on LangChain and LangGraph

    Forfis ran a two-week AI Automation Audit before the pilot began. The audit mapped the invoice-to-reporting workflow end-to-end, sampled 200 invoices from the prior month, and established the baseline: 6.2-day cycle time, 14.3% error rate, 11 FTEs. The audit identified three automation points: (1) invoice ingestion and OCR extraction from the legacy archive, (2) line-item classification and PO matching, and (3) discrepancy flagging with a human approval step before ERP posting.

    The pilot architecture used LangChain for the orchestration layer and LangGraph for the stateful workflow graph that tracked each invoice through ingestion, extraction, classification, review, and posting. The model layer was split: OpenAI’s GPT-4o handled the ambiguous line-item classification (where quality mattered), and an open-weight Llama 3 70B model ran on the client’s own GPU server for the regulated data extraction step, so no invoice data left the Graz data center. The integration points were SAP S/4HANA (via its OData API for posting approved entries), Microsoft Teams (for reviewer notifications and the approval workflow), and the legacy document archive (via a file-watcher ingestion pipeline). Every entry that touched money required a human approval in Teams before it hit SAP. The pilot ran for four weeks: Week 1 integration, Week 2 model tuning on the client’s actual invoice samples, Week 3 live operation with human-in-the-loop review, Week 4 measurement and the go/no-go report.

    Outcome: 61% Cycle-Time Reduction, 3.8% Error Rate

    By the end of Week 4, the pilot had processed 3,100 live invoices. The measured results against the audit baseline:

    • Cycle time dropped from 6.2 days to 2.4 days (a 61% reduction). The bottleneck shifted from manual extraction to the human approval step, which the finance team chose to keep as a compliance control.
    • Error rate fell from 14.3% to 3.8% (manual corrections per 100 invoices). The remaining errors were concentrated in two vendor categories with non-standard invoice formats, which the team flagged for a follow-up prompt-tuning pass.
    • FTE allocation: the 11-person team redirected 4 FTEs from manual extraction to exception handling and vendor relationship management. The finance director did not reduce headcount; the freed capacity was absorbed into the Q3 close workload.
    • Compliance surface: no new data left the building. The open-weight model ran on the client’s GPU server; the OpenAI API calls were limited to the classification step, which operated on anonymized line-item text, not on invoice metadata or vendor names.

    The go/no-go report recommended a phased rollout to the remaining 12 EU markets over two quarters, with the same human-in-the-loop approval step retained for all money-touching entries.

    Lessons for Teams Running Isolated Pilots

    • Baseline before pilot, not after. The audit’s 200-invoice sample established the 6.2-day / 14.3% baseline before any model was tuned. Without that, the pilot’s results would have been unmeasurable. Teams that skip the baseline step cannot distinguish model improvement from natural variance.
    • Split the model layer by data sensitivity, not by convenience. The open-weight model on the client’s hardware handled the regulated extraction step; the cloud API handled the classification step on anonymized text. This split is what made the rollout compliance-safe without requiring a full on-prem LLM deployment.
    • Human-in-the-loop is a design constraint, not a fallback. The Teams approval step was in the LangGraph state machine from day one, not added after the pilot showed errors. Removing it post-hoc would have broken the workflow graph and required a re-architecture.
    • Fixed-scope pilot, not open-ended POC. The 4-week window with a defined go/no-go report forced the team to ship a measurable result rather than iterate indefinitely. The finance director’s mandate — “show me a number by week 4” — was the single most important constraint in the engagement.
    • Integration through existing APIs, not replacement. The system plugged into SAP, Teams, and the legacy archive through their native APIs. No system was replaced, which kept the rollout risk low and the change-management burden minimal.

  • Dedicated AI Team vs Fractional Consultant for Medtech Monthly Reporting

    What Is Being Compared

    The firm is a 51-200 person UK healthcare and medtech company that has automated one back-office process and now faces two parallel needs: a customer-facing AI assistant for ticket triage and first-response, and an internal knowledge search layer over its own documentation and CRM records. The operational constraint is clear — scale these capabilities without adding headcount. The two options under evaluation are a dedicated AI team embedded for a 6-month engagement and a fractional consultant model where a single senior engineer works part-time across multiple clients. Both use LangChain and LangGraph as the orchestration layer, integrate with Google Workspace APIs, and ship with a human-in-the-loop approval gate for anything touching patient data or contractual obligations. The comparison below judges them against eight criteria that matter to a compliance-sensitive medtech operator in Tier-1 markets.

    Criteria for Judgment

    The eight criteria below reflect the specific constraints of a UK medtech firm at one-process-automated maturity:

    • Time-to-first-value: how many weeks until the agent handles a real workflow end-to-end.
    • Compliance documentation: whether the delivery model produces the audit trail MHRA and UK GDPR Article 22 expect.
    • Model-agnosticism: ability to swap OpenAI or Anthropic APIs for an open-weight model on client hardware if data residency rules tighten.
    • Integration depth: quality of the Google Workspace API layer (Drive, Gmail, Calendar) and CRM/ERP connectors.
    • Human-in-the-loop design: how the approval gate is architected, not just whether it exists.
    • Before/after measurement: whether the pilot ships with a quantified baseline on cycle time and error rate.
    • Knowledge-search recall: measured against a 200-query test set drawn from the firm’s own SOPs and regulatory correspondence.
    • Post-launch ownership: who monitors drift, handles model updates, and manages the eval suite after the 6-month window closes.

    Head-to-Head Comparison

    Criterion Dedicated AI Team Fractional Consultant
    Time-to-first-value 4-6 weeks to a working pilot on monthly reporting 8-12 weeks; consultant splits time across 3-4 clients
    Compliance documentation Full audit trail: prompt versions, model outputs, human-approval logs, eval results Partial; documentation depends on consultant’s personal practice
    Model-agnosticism Architecture designed for swap; open-weight Llama 3 70B on client hardware tested in week 3 Typically locked to one vendor API; swap requires re-architecture
    Google Workspace integration Native: Drive indexing, Gmail classification, Calendar-aware scheduling Basic: Drive read-only; Gmail integration often deferred
    Human-in-the-loop gate State-machine approval node in LangGraph; configurable per document type Simple if/else check; harder to extend to new document types
    Before/after baseline Measured at week 2 and week 12; cycle time and error rate tracked per workflow Often omitted or measured once at handover
    Knowledge-search recall 91-94% on 200-query test set after tuning 78-85% typical; tuning limited by consultant availability
    Post-launch ownership 3-month managed operation included; drift monitoring, eval suite maintenance Handover document; client owns all post-launch work

    When Each Option Wins

    The dedicated team wins when the firm needs the monthly reporting agent to feed a regulatory submission or board pack within the 6-month window. The state-machine approval node in LangGraph, combined with the measured before/after baseline, produces the documentation trail that a UK compliance lead can defend to an auditor. The fractional consultant model struggles here because the consultant’s time is split; the compliance documentation step, which takes 2-3 days of focused work, often slips to the end of the engagement or is delivered as a template rather than a filled-in record.

    For the customer-facing ticket triage agent, the dedicated team’s Google Workspace integration depth matters. The agent classifies incoming tickets by urgency and regulatory relevance, drafts a first response using the firm’s approved language, and escalates anything involving patient safety to a human. First-response time drops from 4 hours to under 15 minutes for routine queries. The fractional consultant can build this, but the integration with Gmail and Drive is typically read-only at handover, meaning the agent cannot draft responses into the firm’s existing workflow without additional work.

    For internal knowledge search, the dedicated team’s 91-94% recall on a 200-query test set, drawn from the firm’s own SOPs and regulatory correspondence, is the differentiator. The fractional consultant’s 78-85% recall is acceptable for casual lookups but insufficient when a compliance officer needs to find a specific regulatory decision from 18 months ago. The dedicated team’s tuning process, which includes iterating on chunking strategy and embedding model selection, is what closes that gap.

    Recommendation

    For a 51-200 person UK medtech firm at one-process-automated maturity, the dedicated AI team is the correct choice for a 6-month engagement covering monthly reporting, customer-facing ticket triage, and internal knowledge search. The reasons are specific: the compliance documentation requirement is non-negotiable in a healthcare context, the model-agnostic architecture protects the firm if data residency rules tighten, and the 3-month managed operation period after the 6-month build window means the firm is not left owning an eval suite and drift-monitoring pipeline it did not build. The fractional consultant model is appropriate for a firm that has already automated two or three processes and needs a single, well-scoped integration — not for a firm that is still at the one-process stage and needs the full audit-to-rollout lifecycle. The dedicated team’s EUR 18,000-25,000 per month cost over 6 months is comparable to the total cost of a fractional consultant at EUR 800-1,200 per day working 3-4 days per week, but the continuity of a named team and the built-in process-audit methodology make the dedicated model the lower-risk choice for a compliance-sensitive operator.

  • 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.

  • 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.

  • LangGraph Agent vs. Managed Pilot: HR Back-Office Automation in Swiss Healthcare

    What Is Being Compared: In-House LangGraph Agent vs. Managed Fixed-Scope Pilot

    The two options under evaluation are: (A) an in-house AI agent built on LangChain and LangGraph, where the company’s engineering team (or a product studio) designs the orchestration graph, manages the model calls, and owns the integration code; and (B) a managed workflow-orchestration service delivered as a fixed-scope pilot, where a vendor such as Forfis scopes one back-office workflow, ships a human-in-the-loop pipeline in 8 weeks, and hands over a measured before/after baseline on cycle time and error rate. Both options target the same use case: reducing the error rate in HR and recruiting back-office tasks (candidate data extraction, application triage, internal knowledge search) for a 201-500-person company in the Swiss healthcare and medtech sector, with round-the-clock candidate response as a secondary goal. The comparison is not “build vs. buy” in the abstract; it is “own the orchestration layer” versus “outsource the orchestration layer under a fixed-scope contract” while keeping the same model-agnostic architecture and the same Google Workspace integration points.

    Seven Criteria for the Comparison

    We judge the two options against seven criteria that matter for a Swiss healthcare company running isolated pilots:

    • Time to first measurable result — weeks from kickoff to a working pipeline with a logged baseline.
    • Error-rate reduction — percentage of extracted fields a human must correct, measured before and after.
    • GDPR compliance overhead — effort to satisfy Articles 28, 30, 32 and the Swiss FDPIC guidance on automated decision-making.
    • Vendor lock-in — how easily the orchestration layer can be swapped or taken in-house after the pilot.
    • Integration effort — number of API connections (Gmail, Drive, ATS, CRM) and the maintenance burden.
    • Model-agnosticism — ability to swap between OpenAI, Anthropic, and open-weight models without re-architecting.
    • Total cost of ownership over 12 months — build cost, API inference cost, and ongoing maintenance.

    Each criterion is scored in the table below with concrete figures where available.

    Side-by-Side Comparison

    Criterion Option A: In-House LangGraph Agent Option B: Managed Fixed-Scope Pilot
    Time to first result 10-14 weeks (design, build, test, baseline) 8 weeks (fixed scope, pre-built integration templates)
    Error-rate reduction Depends on prompt engineering; typically 8-15% residual after 3 iterations 4-6% residual at pilot close-out, with logged human corrections
    GDPR compliance overhead Internal legal + engineering must map data flows, sign DPA, document Article 30 records Vendor provides DPA, data-flow map, and Article 30 log as pilot deliverables
    Vendor lock-in None — code is owned; LangGraph is open-source Low — orchestration graph is documented; model calls are API-based, not proprietary
    Integration effort 3-5 engineer-weeks for Gmail, Drive, ATS, CRM OAuth + API wiring Included in pilot scope; vendor maintains integration during the 8 weeks
    Model-agnosticism Full — swap any OpenAI/Anthropic/open-weight model at the node level Full — same architecture; vendor configures the model endpoint per workflow
    12-month TCO ~CHF 180 000-250 000 (1 FTE engineer + API costs ~CHF 4 000/month) ~CHF 95 000-130 000 (pilot fee + managed operation ~CHF 3 500/month)

    The TCO figures assume a single workflow with two integration points and moderate inference volume (roughly 500 candidate applications per month).

    When the In-House Agent Wins

    Option A wins when the company already has a dedicated engineering team of at least two full-time developers who can maintain the LangGraph codebase, write integration tests, and iterate on prompts after the pilot. A 201-500-person medtech company with an in-house platform team and a clear long-term roadmap for multiple AI workflows (candidate screening, invoice processing, clinical-trial document extraction) will amortise the build cost across those workflows. The in-house agent also gives the team full control over the state machine in LangGraph, which matters when the workflow has complex conditional routing (for example, pausing at a human-approval node for any candidate data that touches health records under GDPR Article 9).

    Option B wins when the company’s engineering team is small or fully allocated to product development and cannot spare 3-5 engineer-weeks for integration wiring. The 8-week fixed-scope pilot ships a working pipeline with a measured baseline, a signed DPA, and a data-flow map. The vendor handles the Google Workspace OAuth setup, the ATS API connection, and the human-in-the-loop approval gate. For a company running isolated pilots for the first time, the managed service removes the operational overhead of standing up the orchestration infrastructure, monitoring model calls, and logging every transition for the Article 30 record.

    Recommendation for the Swiss Healthcare Scenario

    Option B is the better fit for the stated scenario. A 201-500-person Swiss healthcare and medtech company running isolated pilots, with an 8-week timeline, a fixed-scope delivery model, and a primary need to reduce the error rate in HR back-office work, does not have the engineering bandwidth to build and maintain a LangGraph agent in parallel with product development. The managed pilot delivers the same model-agnostic architecture (OpenAI or Anthropic APIs for high-quality extraction, open-weight models on the client’s own hardware for regulated data that cannot leave the building) but wraps it in a fixed-scope contract with a measured before/after baseline. The Google Workspace integration (Gmail for inbound applications, Drive for policy documents feeding the internal knowledge search, Calendar for recruiter scheduling) is handled by the vendor during the 8 weeks. The human-in-the-loop gate ensures that any output touching candidate personal data or health-related information is approved by a person before it enters the ATS, satisfying GDPR Article 22 and the Swiss FDPIC guidance on automated decision-making. After the pilot close-out, the company can either continue with managed operation or take the documented orchestration graph in-house; the model-agnostic design means neither path requires re-architecting the integrations.