Forfis Blog

Category: Healthcare and Medtech

  • 4-Week AI Automation Audit for a 2,000+ Employee UK Healthcare Firm

    1. The audit measures what you actually do, not what you think you do

    The audit starts by pulling 90 days of ticket, invoice, and contract logs from Google Workspace, the CRM, and the ERP. The team interviews the finance team, the clinical operations lead, and the IT security officer to map every data flow that touches the AI layer. Each workflow is scored on three axes: volume (how many instances per week), complexity (how many manual steps and exceptions), and sensitivity (does it touch patient data, money, or a contract?). The output is a ranked list of automation candidates with a measured baseline on cycle time and error rate for each. For a 2,000+ employee UK healthcare firm, the top three candidates are almost always invoice processing, contract review, and patient-facing query triage. The audit does not recommend a model or a vendor; it recommends a workflow and a success metric. That distinction matters because the model choice is a technical decision that can be made after the business case is approved.

    2. The pilot is one workflow, one team, one measurable outcome

    The pilot runs for 4-6 weeks on a single workflow, with a fixed scope defined in the audit. For a healthcare and finance firm, the most common pilot is a conversational agent that monitors a shared Google Workspace inbox, classifies incoming queries, retrieves relevant documentation from a pgvector store, and drafts a first response. The human-in-the-loop step is a simple approve/edit/reject action in the Gmail UI. The agent does not send anything to a patient or a supplier without a human clicking approve. The success criterion is a statistically significant reduction in median first-response time and a measurable drop in error rate, both measured against the baseline captured in the audit. For a 2,000+ employee firm, the pilot team is typically three to four people: one engineer, one product manager, one domain expert from the target department, and one security officer who signs off on the ISO 27001 control mapping. The pilot ships with a written report that includes the before/after metrics, the error log, and the list of edge cases the agent could not handle.

    3. The model-agnostic stack keeps regulated data on-premises

    The architecture routes queries to the appropriate model based on a sensitivity tag assigned during the audit. Patient-identifiable data, financial records, and contract terms are tagged as regulated and routed to open-weight models (Llama 3, Mistral) running on the client’s own GPU hardware. The pgvector store lives on the same on-prem PostgreSQL instance, so no data leaves the building. Non-regulated flows (internal process documentation, general FAQ) are routed to OpenAI or Anthropic APIs where quality and speed matter more than data residency. The routing logic is documented in the ISO 27001 Annex A.8.13 (threats) and A.8.15 (access control) sections. The model-agnostic design means the company can swap models as they improve without changing the RAG pipeline, the approval workflow, or the audit trail. The pgvector index is rebuilt when the document store changes, and the embedding model is versioned so that a model upgrade does not silently change the search results.

    4. ISO 27001 controls are built into the pilot, not bolted on

    ISO 27001 requires documented risk assessment, access control, and audit logging for all information assets. When the AI layer processes financial or patient-adjacent data, the model’s input/output logs become part of the information security scope. In practice, this means three things: (1) every classification or draft is logged with a timestamp, user ID, and confidence score; (2) access to the model API keys and the pgvector store follows the same least-privilege rules as any other system; (3) the data flow diagram in the ISO 27001 documentation explicitly includes the AI component. Forfis builds these controls into the pilot from day one rather than retrofitting them after the model is live. The security officer signs off on the control mapping before the pilot goes to production. The audit trail is exportable in a format the company’s ISO 27001 auditor can review, which saves weeks of back-and-forth during the annual certification audit.

    5. Scaling is a repeat of the audit-pilot-rollout cycle, not a bigger agent

    The audit produces a prioritised roadmap, but the pilot is deliberately narrow. Scaling across departments means repeating the audit-pilot-rollout cycle for each new workflow, not pointing the same agent at more data. Each new department’s pilot gets its own baseline measurement, its own human-in-the-loop approval rules, and its own ISO 27001 control mapping. For a 2,000+ employee firm, the realistic timeline is 8-12 weeks per additional department, with the first department’s rollout feeding lessons into the second. The architecture (pgvector, model-agnostic API layer, Google Workspace integration) stays the same; the prompts, approval thresholds, and data sources change per department. The key discipline is that no department skips the baseline measurement. The first department’s error log becomes the test suite for the second department’s pilot, which catches edge cases that the first team did not anticipate. This is how a 4-week audit becomes a 12-month programme without losing the measurement rigour that makes the business case defensible.

    6. The synthesis: measurement is the product

    The most common failure mode is skipping the baseline measurement. Teams deploy an agent, see it working, and assume it is faster and more accurate than the manual process, but they never measured the manual process’s cycle time and error rate before the agent went live. Without that baseline, the business case is anecdotal, and the ISO 27001 audit trail is incomplete. The second failure mode is treating the pilot as a demo: the agent works on the test data but fails on edge cases in production. The third is ignoring the human-in-the-loop approval step, which means the agent makes errors that a human would have caught. The fourth is choosing the model before the audit, which locks the architecture into a vendor and makes the ISO 27001 control mapping harder to document. Forfis builds the baseline measurement, the approval workflow, and the model-agnostic routing into the pilot specification from day one. The 4-week audit is not a cost centre; it is the measurement infrastructure that makes every subsequent rollout defensible to the board, the auditor, and the team that has to live with the agent in production.

  • n8n Pilot vs. Compliance-Safe Rollout: AI Lead Qualification for German Medtech

    Two Postures for the Same Lead-Qualification Task

    The two options under comparison are not competing products but two delivery postures for the same technical task: scoring inbound sales leads using a large language model and writing the result back to the CRM. Option A is an n8n-orchestrated pilot: a fixed-scope, 8-week engagement that builds one automated workflow, measures it against a pre-pilot baseline, and hands the client a working pipeline with a human-in-the-loop review step. Option B is a compliance-safe rollout: the same technical architecture, but the engagement is scoped from day one around data-minimization, audit logging, and a documented human-override path, with the pilot embedded inside a broader rollout plan that covers all inbound channels and the Confluence or Notion knowledge base as a retrieval source. Both options use the same model-agnostic stack, the same n8n orchestration layer, and the same CRM integration. The difference is in scope, risk posture, and what the client owns at the end of week eight.

    Baseline Metrics the Audit Establishes

    The audit phase, which precedes both options, produces the baseline numbers that make the comparison meaningful. The team maps the current lead-qualification workflow: where leads enter (web form, trade-show scan, inbound call), what fields a sales rep captures, how the rep scores fit against product criteria stored in Confluence, and how long a lead sits in a queue before first contact. The audit measures median cycle time from lead creation to qualified response, the misclassification rate (leads scored as qualified that the rep later downgrades, or vice versa), and senior-staff hours per week spent on manual triage. For a 201-to-500-person company in the German healthcare and medtech sector processing 200 to 400 leads per month, typical baselines are a 48-to-72-hour cycle time, a 12-to-18 percent misclassification rate, and 20-to-35 hours of senior staff time per week on triage. These numbers become the yardstick for both options.

    Criteria and Side-by-Side Comparison

    The following table compares the two options against the criteria that matter for a German healthcare and medtech company in the isolated-pilot maturity stage. Each cell states a concrete figure or mechanism, not a qualitative judgment.

    Criterion Option A: n8n Pilot Option B: Compliance-Safe Rollout
    Median cycle time (target) 18 to 24 hours, measured in week 7 12 to 18 hours, measured across all channels in week 8
    Misclassification rate (target) Below 10 percent vs. baseline Below 8 percent, with logged rationale per decision
    Senior-staff hours freed (per month) 15 to 25 hours 25 to 40 hours
    Data fields sent to LLM Lead name, company, product interest, source Same, plus redacted interaction history from Confluence
    Human-review step Required for all leads Required for all leads; override logged with timestamp
    Audit trail n8n execution log, 30-day retention n8n log plus Confluence decision journal, 12-month retention
    Integration surface CRM webhook, one Confluence space CRM webhook, Confluence and Notion, email notification
    Client ownership at week 8 Working n8n workflow, prompt, baseline report Same, plus rollout plan, data-flow diagram, review SOP
    Cost structure (indicative) Fixed fee, 8 weeks Fixed fee, 8 weeks plus optional 4-week rollout extension

    When Each Option Wins

    Option A wins when the company’s primary goal is to prove the concept and free senior staff from a single, well-defined triage task. A medtech company with a dedicated sales team of eight to twelve people, a single CRM instance, and a Confluence space that holds product-fit criteria will get the most value from the n8n pilot. The 8-week timeline is tight but sufficient: three weeks for audit and baseline, three weeks for build and tuning, one week for the pilot run, and one week for review and handover. The client walks away with a working workflow, a measured before-and-after report, and a clear picture of whether the error rate justifies scaling. The risk is narrow: if the pilot misses the 10 percent misclassification target, the team adjusts the prompt or the feature set in a short follow-up sprint rather than re-scoping the entire engagement.

    Option B wins when the company anticipates scaling the workflow to all inbound channels within the same quarter or when the lead data includes even indirect references to patient interactions, which is common in medtech where a sales lead may mention a specific hospital or clinical trial. The compliance-safe posture adds a data-flow diagram, a 12-month audit trail, and a documented human-override SOP. The additional cost is modest, roughly 15 to 20 percent over Option A, but it removes the rework that would otherwise occur when the client tries to scale a pilot that was never designed for multi-channel ingestion or long-term audit retention.

    Recommendation for the German Medtech Scenario

    For a 201-to-500-person German healthcare and medtech company running isolated pilots, the recommendation is Option B: the compliance-safe rollout, scoped to an 8-week pilot with a documented path to multi-channel rollout. The reasoning is specific. First, the company is in the isolated-pilot maturity stage, which means it has not yet standardized how AI outputs are reviewed, logged, or escalated. Building that standard during the pilot, rather than retrofitting it after the pilot succeeds, costs less and creates fewer integration conflicts. Second, the lead data in medtech frequently touches on hospital names, clinical trial identifiers, or patient-interaction context, even when no explicit health data is stored in the CRM. The data-minimization and redaction steps in Option B handle this without requiring a formal GDPR Article 22 assessment, because the human-review step keeps the decision out of the automated-decision scope. Third, the 8-week timeline is identical for both options; the compliance-safe posture adds documentation and a data-flow diagram but does not add calendar time. The client pays a modest premium for a deliverable that is ready to scale rather than a proof of concept that needs rework.

  • HIPAA-Compliant Invoice AI for a Swiss Medtech Firm: A 3-Month Fixed-Scope Pilot

    The Problem: 4,200 Invoices, 9 People, and a HIPAA Boundary

    A 120-person Swiss medtech company processes 4,200 vendor invoices per month across four languages. The finance team of nine spends 38 hours per week on manual data entry, error correction, and supplier reconciliation. The average cycle time from invoice receipt to payment approval is 11.4 days. The error rate is 6.2%, meaning 260 invoices per month require manual correction. The company has no AI in production yet. The CFO wants to reduce cycle time to under 5 days and error rate to under 2% without hiring additional accountants. The constraint is HIPAA: the invoice data contains patient identifiers and diagnosis codes for US-based research programs, so the data cannot leave the company’s network. The engagement is a fixed-scope pilot, 3 months, targeting one invoice stream, with a measured before/after baseline on cycle time and error rate.

    Mechanism: On-Premise Open-Weight Models and the Extraction Pipeline

    The architecture is model-agnostic. The application layer sits above an abstraction layer that routes requests to either a cloud API (OpenAI GPT-4o or Anthropic Claude 3.5 Sonnet) or an on-premise open-weight model (Llama 3.1 70B or Mistral 7B) depending on the data classification tag. For regulated data, the request goes to the on-premise model running on a server with 2x NVIDIA A100 80GB GPUs, deployed via vLLM. The model is fine-tuned on the client’s invoice data using LoRA adapters, which take 2.5 days on a single A100. The extraction pipeline uses a two-stage approach: first, a layout analysis model (DocLayNet) identifies the document regions; second, the LLM extracts the structured fields from each region. The output is a JSON object with field names, values, and confidence scores. The confidence score is computed from the LLM’s token probabilities. Fields below 0.85 are flagged for human review. The human review interface is embedded in Slack and Microsoft Teams via the Slack Web API and Microsoft Graph API. The reviewer sees the original document, the extracted fields, and the confidence scores. All corrections are logged and fed back into the model’s training data.

    Trade-offs: Accuracy, Cost, and the Human Review Threshold

    The architect makes three key trade-offs. First, model choice: the on-premise Llama 3.1 70B achieves 94.2% field-level accuracy on the client’s invoice data, compared to 96.8% for GPT-4o. The 2.6% accuracy gap is acceptable because the human-in-the-loop workflow catches the remaining errors. The cost of the on-premise hardware is EUR 180,000, versus EUR 4,200/month for the GPT-4o API at the client’s volume. The break-even point is 14 months. Second, integration depth: the system plugs into the existing SAP S/4HANA ERP via the OData API and the Salesforce CRM via the REST API. It does not replace either system. The integration adds 3-5 days of development time per system but avoids the 6-12 month ERP migration that would be required to replace SAP. Third, human review threshold: setting the threshold at 0.85 means 12% of invoices require human review. Lowering the threshold to 0.95 reduces human review to 4% but increases the risk of missed errors. The client chose 0.85 because the finance team has the capacity to review 500 invoices per month.

    Recommendation: The 3-Month Pilot and the Rollout Path

    The pilot runs for 8 weeks. Week 1-2: process audit. The team maps the current invoice workflow, samples 100 invoices over 2 weeks, and measures the baseline: 11.4 days cycle time, 6.2% error rate. Week 3-6: pilot build. The team fine-tunes the Llama 3.1 70B model on the client’s invoice data, builds the extraction pipeline, and integrates it with SAP and Slack. Week 7-8: pilot validation. The AI processes 200 invoices in parallel with the manual process. The results: cycle time drops to 4.8 days, error rate drops to 1.8%. The human review queue contains 24 invoices (12%), all corrected within 2 hours. The client meets the acceptance criteria. The rollout plan covers the remaining three invoice streams, the multilingual support for German, French, Italian, and English, and the managed operation phase. The managed operation costs EUR 5,200/month, including model updates, human review monitoring, and integration maintenance. The client scales to all 4,200 invoices per month in month 4, with no new hires.

  • 12-Point Checklist: Running a 4-Week AI Support Agent Pilot in Swiss Healthcare

    1. Run the process audit and lock the baseline

    Before writing a single line of prompt engineering, the audit must answer three questions: which workflow has the highest volume-to-complexity ratio, which data sources are API-accessible, and which compliance constraints are non-negotiable. For a Swiss healthcare company with no AI in production, the answer is usually ticket triage or first-response drafting on a customer support channel. The audit documents current cycle time (median minutes from ticket open to first human response) and error rate (misrouted or incomplete replies per 100 tickets). These two numbers become the baseline against which the pilot is measured. Without them, the pilot cannot prove ROI. The audit also maps every system the agent will touch—CRM, helpdesk, Notion or Confluence knowledge base—and confirms API credentials, rate limits, and data residency requirements. In Switzerland, FADP and the EU AI Act both apply; the audit flags which fields are personal data, which are health data, and which require human approval before any automated action. The output is a one-page roadmap: one workflow, one integration set, one success metric, four weeks. This document is the contract for the fixed-scope pilot and the reference for every subsequent decision.

    2. Define the fixed-scope pilot boundary

    The pilot scope must be narrow enough to finish in four weeks and broad enough to prove value. For a healthcare and medtech company, the typical scope is a conversational agent that triages incoming support tickets, drafts a first response using the company’s internal knowledge base, and routes the ticket to the right team. The agent does not close tickets, does not touch patient records, and does not send responses without human approval. The knowledge base lives in Notion or Confluence; the agent indexes those spaces via API and retrieves relevant passages to ground every draft. The CRM and helpdesk integrations are read-write for ticket metadata and read-only for customer history. The Anthropic Claude API handles classification and drafting; the model is selected for its instruction-following quality and context window, not for cost. The architecture is model-agnostic: if the client later moves to an open-weight model on local hardware for data residency reasons, the prompt layer and integration layer remain unchanged. The pilot ships with a dashboard showing cycle time, error rate, and human override rate, updated daily. At week four, the team compares the pilot numbers against the audit baseline and makes a go/no-go decision on rollout.

    3. Configure EU AI Act and Swiss FADP compliance gates

    The EU AI Act, effective in phases from 2025, requires transparency for AI systems that interact with humans. Article 50 mandates that users be informed they are interacting with an AI, unless it is obvious from context. For a healthcare support agent, this means the first message must state that the response is AI-drafted and subject to human review. The Act also classifies systems that make decisions affecting health as high-risk under Article 6, but a triage-and-draft agent that does not diagnose, prescribe, or alter treatment plans falls outside that category. Still, the agent must not process health data without a legal basis under GDPR and Swiss FADP. The pilot configuration includes a data classification layer: fields tagged as health data are routed to a human approver before any action. The agent’s system prompt explicitly forbids it from making medical claims, interpreting test results, or advising on treatment. Every response is logged with the model version, prompt hash, and retrieval context for auditability. The compliance checklist is signed off by the client’s data protection officer before the pilot goes live, and the log retention period matches the client’s regulatory requirement, typically 12 months for healthcare records in Switzerland.

    4. Build the retrieval layer over Notion or Confluence

    The agent’s value depends on retrieval quality. The knowledge base in Notion or Confluence must be structured so the agent can find the right passage in under 200 ms. Before the pilot, the team runs a retrieval audit: take 50 real support tickets from the past quarter, identify the correct knowledge base article for each, and measure how often a vector search over the raw document text returns that article in the top three results. If the hit rate is below 80%, the knowledge base needs restructuring before the agent is built. Concretely, this means splitting long pages into discrete, self-contained sections, adding metadata tags (product, issue type, severity), and removing deprecated content. The retrieval pipeline uses a hybrid approach: dense vector embeddings for semantic matching and BM25 for exact keyword hits, with a reranking step using the Claude API to score the top ten candidates. The agent’s system prompt instructs it to cite the specific knowledge base section in every draft, so the human approver can verify the source. If the retrieval confidence score falls below a threshold the team sets during the audit, the agent flags the ticket for manual handling rather than drafting a potentially wrong response. This guardrail is non-negotiable in a healthcare context.

    5. Measure cycle time, error rate, and override rate daily

    The pilot runs for four weeks with a daily standup and a weekly metrics review. The team tracks three numbers every day: median cycle time from ticket open to first human-approved response, error rate (tickets requiring rework after approval), and human override rate (percentage of drafts the approver rejects or significantly edits). The audit baseline from step one is the reference. A successful pilot shows at least a 30% reduction in cycle time and a 20% reduction in error rate, with an override rate below 15% by week three. If the override rate stays above 25%, the team investigates: is the retrieval missing the right article, is the prompt too vague, or is the knowledge base outdated? The fix is applied within 48 hours and the metrics are re-measured. The pilot also includes a shadow mode for the first three days: the agent drafts responses but does not send them; the human approver compares the draft against what they would have written. This calibrates the prompt and the retrieval thresholds before the agent goes live. At the end of week four, the team produces a one-page report: baseline vs. pilot numbers, override rate trend, top five failure modes, and a recommendation on rollout scope. The report is the input to the next engagement, not a marketing document.

    6. Maintain the checklist and the agent after go-live

    The pilot is not a one-and-done deliverable. The knowledge base in Notion or Confluence changes weekly; new product releases, policy updates, and support macros all alter the retrieval landscape. The team schedules a monthly retrieval audit: take 20 new tickets, measure the hit rate, and restructure sections if the rate drops below 80%. The prompt layer is versioned in a repository with a changelog; every change is tested against a fixed set of 30 evaluation tickets before deployment. The compliance log is reviewed quarterly by the data protection officer to confirm that no health data was processed without approval and that the AI transparency notice is still present in every first response. The model provider’s terms of service and the EU AI Act’s obligations are re-checked at each quarterly review, because both evolve. The team also maintains a runbook for model degradation: if the Claude API’s response quality drops due to a provider-side change, the runbook specifies the fallback—switch to the open-weight model on local hardware, re-run the evaluation set, and deploy within 24 hours. The checklist itself is stored in the same Notion or Confluence space the agent indexes, so the team can search for it the same way the agent searches for support articles. This keeps the maintenance process visible and auditable.

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

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

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

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

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

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

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

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

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

  • Four-Week Sprint: On-Prem LLM Contract Review for a Swiss Medtech Firm

    The Problem: Senior Staff Buried in Contract Clause Checks

    A 11-50 person Swiss medtech firm processes 40-80 vendor contracts per month. Each one requires a senior finance or legal reviewer to extract liability caps, data-processing terms, and termination triggers, then cross-check them against the company’s standard playbook. The median cycle time is 6.2 hours per contract; the 95th percentile hits 14 hours when a data-processing annex is involved. Senior staff spend roughly 30% of their week on this routine work, which is precisely the work that should not require a person with a law degree. The problem is not the volume alone. It is that the workflow is isolated: no baseline exists, no approval gate is documented, and the ISO 27001 evidence trail for contract handling is incomplete. The fix is a four-week integration sprint that puts an on-prem open-weight LLM on the single highest-volume contract-review workflow, ships a measured before/after baseline, and produces the ISO 27001 evidence pack in the same window.

    Prerequisites Before Day One

    Before the sprint starts, you need five things in place. First, a named sponsor with authority to approve the pilot scope and the rollout decision. Second, access to the last 90 days of contract PDFs, including at least 50 that have been manually reviewed, so the gold-standard baseline can be built. Third, a Slack or Microsoft Teams workspace where the approval loop will run, with a dedicated channel for contract review. Fourth, a Swiss data center or on-prem server with at least 80 GB of GPU memory (an A100 or H100) for the open-weight model. Fifth, the current ISO 27001 risk register and data-processing register, so the sprint can append new controls rather than rebuild them. If any of these are missing, the sprint timeline slips. The four-week window assumes all five are available on day one.

    Step 1: Run the Process Audit and Pick the Pilot Workflow

    Map every contract that enters the finance and accounting function over the last 90 days. Classify each by type (vendor service agreement, purchase order, data-processing annex, SLA addendum) and measure the median cycle time, the 95th percentile, and the number of senior staff hours consumed. Export the results into a spreadsheet with columns for contract ID, type, cycle time, error count, and reviewer name. Select the single workflow with the highest volume-to-complexity ratio. For most Swiss medtech firms, that is vendor service agreements with recurring data-processing clauses. Document the selection rationale in the sprint charter. This step takes two to three days and produces the baseline that the pilot will be measured against.

    Step 2: Stand Up the On-Prem Open-Weight Model and Retrieval Layer

    Deploy the open-weight model on the client’s own hardware inside the Swiss data center. Llama 3 70B or Mistral Large 123B are the typical choices for contract clause extraction at this scale. The model runs behind a local inference server (vLLM or TGI) with no outbound network access. The retrieval-augmented layer indexes the company’s standard playbook, past approved contracts, and the ISO 27001 data-processing register into a vector store (Qdrant or Weaviate) on the same server. The agent’s prompt template is version-controlled in a Git repository. The model-agnostic layer sits between the agent and the inference server, so the same prompt and retrieval pipeline works if a non-sensitive triage task later moves to an OpenAI or Anthropic API. This step takes three to four days.

    Step 3: Build the Conversational Agent with a Human-in-the-Loop Approval Gate

    Build the conversational agent that reads a contract PDF, extracts obligations, liability caps, termination triggers, and data-processing terms, and flags deviations from the standard playbook. The agent posts a structured message into the designated Slack or Teams channel containing the contract ID, the flagged clauses, the recommended action, and a link to the full extraction. The human-in-the-loop gate is hard-coded: no clause touching money, health data, or a contract is marked as processed without a reviewer clicking approve, edit, or reject in the channel. The approval event is logged with a timestamp, reviewer identity, and the exact clause text. The agent does not send the contract to a counterparty, does not execute, and does not modify the document in the CRM or ERP. This step takes four to five days.

    Step 4: Run the Pilot and Measure the Before/After Baseline

    Run the pilot on the selected workflow for two weeks. Every contract that enters the finance function goes through the agent. The reviewer approves, edits, or rejects each flagged clause in Slack or Teams. The system logs cycle time per contract, error rate on clause extraction (measured against the 50-contract gold standard), and senior staff hours consumed. At the end of the two weeks, re-measure the same three metrics. A typical result for a 11-50 person medtech firm is a 60-75% reduction in cycle time and a 40-60% reduction in senior staff hours, with error rate on par or slightly below the manual baseline. Document the numbers in the sprint report. This step takes ten business days, including the two-week live window.

    Step 5: Roll Out to the Full Team and Connect the CRM and ERP

    Roll the agent out to the full finance and accounting team. The integration point is the same Slack or Teams channel, but now all reviewers use it. The CRM and ERP connections go live: a read-only CRM connection for contract metadata, a write connection to the ERP for the finance ledger entry once a contract is approved, and a webhook into the channel for the approval loop. The model-agnostic layer is unchanged. The rollout takes three to four days. The key constraint is that the on-prem model must remain inside the Swiss data center. No contract text, no PHI, no clause extraction result leaves the building. The ERP write is the only outbound data flow, and it carries only the approved contract ID and the finance ledger entry, not the contract text.

  • Retrieval-Augmented Candidate Screening: A 4-Week Pilot for Austrian Healthcare

    1. Replace Manual Data Entry First

    Most companies that automate candidate screening start by replacing the manual data entry step. Recruiters spend 2-3 hours per week copying data from resumes into their ATS. A retrieval-augmented assistant built on pgvector can extract structured fields (name, experience, certifications) and classify candidates against your job description in under 18 seconds per application. The human-in-the-loop design means a recruiter approves or rejects each classification before it touches the hiring pipeline. This single process automation reduces cycle time by 40-60% and eliminates transcription errors, giving you a measurable baseline before you consider expanding to other workflows.

    2. Build EU AI Act Compliance Into the Pilot

    The EU AI Act, which entered into force in August 2024, classifies AI systems that make decisions affecting individuals as high-risk. Candidate screening tools that process personal data and influence hiring decisions fall squarely into this category. Article 10 requires data governance, Article 13 mandates transparency, and Article 14 demands human oversight. Forfis builds these controls into the pilot from day one: every classification is logged, every decision is auditable, and no candidate is screened out without human review. This is not a compliance checkbox added at the end; it is the architecture of the system.

    3. Use pgvector for Grounded Answers

    pgvector is a PostgreSQL extension that stores vector embeddings and performs similarity search. For a 501-2000 employee company, this means you can run your RAG pipeline on the same database as your transactional data, avoiding the cost and complexity of a dedicated vector database. The assistant embeds your job descriptions, screening criteria, and past hiring decisions into pgvector. When a new application arrives, the system retrieves the most relevant chunks and feeds them to an LLM, which generates a classification grounded in your data. This reduces hallucinations and keeps answers current as your criteria change.

    4. Integrate With Your Existing ATS via REST APIs

    The assistant connects to your ATS, HRIS, or recruitment platform via their REST APIs. Webhooks trigger the screening workflow when a new application arrives. The system extracts structured data from resumes, classifies candidates, and writes results back to your existing system. No replacement of your current tools is required. The architecture is deliberately model-agnostic: OpenAI or Anthropic APIs where quality matters, open-weight models on your own hardware where regulated data cannot leave the building. This means you can switch models without rebuilding the pipeline, and you can keep candidate data within your infrastructure if required.

    5. Ship a Measurable Result in 4 Weeks

    A 4-week timeline is realistic for a single-process pilot. Week 1: process audit and baseline measurement. Week 2: build the RAG pipeline and API integration. Week 3: test with real data and tune the model. Week 4: measure results, document findings, and hand over. This assumes your APIs are accessible and your data is in a usable format. The pilot ships with a report showing whether the automation meets the agreed thresholds on cycle time and error rate before you commit to rollout. This fixed-scope approach protects you from scope creep and ensures you have a measurable result before expanding to other workflows.

    6. Keep Humans in the Loop for High-Risk Decisions

    The assistant drafts a shortlist of candidates based on your job description and screening criteria. A recruiter reviews each draft, approves or rejects the classification, and the system logs the decision. This human-in-the-loop design ensures no candidate is screened out without human review, satisfying EU AI Act requirements for high-risk AI systems. The model classifies, the person decides. This is not a limitation; it is the correct architecture for a regulated environment. Every pilot ships with a measured before/after baseline on cycle time and error rate, so you know exactly what the automation achieved and where human judgment still adds value.

  • Deploying a RAG Assistant for Lead Qualification in a UK Healthcare Company

    The Problem: Manual Lead Qualification and Document Turnaround in a Regulated Environment

    You run a 2,000+ employee healthcare and medtech company in the UK. Your sales team spends 12-15 hours per week manually qualifying inbound leads, extracting data from PDFs and spreadsheets, and updating CRM records. Monthly reporting takes 3-5 days of back-office work. You need faster document turnaround and automated monthly reporting, but you cannot send patient-identifiable data to third-party APIs without explicit consent. You must comply with UK GDPR and the Data Protection Act 2018. This guide walks you through a 3-month integration sprint to deploy a retrieval-augmented knowledge assistant that grounds answers in your own CRM and document corpus, using OpenAI API where quality matters, with human-in-the-loop review for anything touching health data or contracts.

    Prerequisites: What You Need Before Step 1

    • CRM access: API credentials for Salesforce or HubSpot, with read/write permissions for the relevant objects (Leads, Contacts, Opportunities, Cases).
    • Document corpus: A structured repository of your internal documents, product specs, and compliance policies, stored in a format the RAG pipeline can ingest (PDF, DOCX, HTML).
    • Data mapping: A documented schema of your CRM fields, including which fields contain personal data, health data, or financial figures.
    • GDPR compliance: A signed DPA with your AI vendor, a data processing impact assessment, and a lawful basis under GDPR Article 6 for processing personal data.
    • Baseline metrics: Measured cycle time and error rate for your current lead qualification and document turnaround workflows, captured over a 2-week period.
    • Human-in-the-loop workflow: A defined approval process for anything touching money, health data, or contracts, with named reviewers and SLAs.

    Step 1: Map Data Sources and Compliance Boundaries

    1. Map your data sources and compliance boundaries. Identify which CRM fields and document types contain personal data, health data, or financial figures. Tag each field with its GDPR lawful basis and purpose limitation. This mapping determines which data can be sent to OpenAI API and which must stay on-premise. Use a spreadsheet with columns for field name, data type, GDPR category, and permitted processing locations.

    2. Build the vector store and ingestion pipeline. Ingest your document corpus into a vector database (e.g., Pinecone, Weaviate, or pgvector). Chunk documents at 512 tokens with 50-token overlap. Embed using OpenAI’s text-embedding-3-small model. Store metadata (document ID, section, last updated date) alongside each vector. Test retrieval precision: for 50 sample questions, measure the percentage of retrieved passages that are relevant. Target 80% or higher.

    Step 2: Integrate with Salesforce or HubSpot CRM

    1. Integrate with your CRM via API. Connect the RAG assistant to Salesforce or HubSpot using their REST APIs. For Salesforce, use the /services/data/v58.0/sobjects/Lead endpoint to read and write lead records. For HubSpot, use the /crm/v3/objects/contacts endpoint. Implement OAuth 2.0 authentication with refresh tokens. Test bidirectional data flow: the assistant reads inbound leads, scores them, and writes the score and tags back to the CRM. Log all API calls for audit purposes under GDPR Article 30.

    Step 3: Configure the RAG Pipeline with OpenAI API

    1. Configure the RAG pipeline with OpenAI API. Use OpenAI’s gpt-4o model for generation and text-embedding-3-small for embeddings. Set the temperature to 0.2 for deterministic answers. Implement a retrieval step that fetches the top 5 most relevant passages from the vector store. Feed these passages to the model with a system prompt that instructs it to answer only from the provided context and cite sources. Log all prompts and responses for audit purposes. Store logs in an encrypted database with access controls.

    Step 4: Implement Human-in-the-Loop Review

    1. Implement human-in-the-loop review. Define the approval workflow: the assistant drafts or classifies, but a person approves anything that touches money, health data, or contracts. For lead qualification, the assistant scores and tags leads, but a sales rep confirms the final disposition. For document extraction, the AI populates CRM fields, but a human reviews and approves before the record is saved. Build a review dashboard with a queue of pending approvals, each showing the AI’s draft, the source passages, and an approve/reject button. Track approval time and rejection rate.

    Step 5: Run User Acceptance Testing and Measure the Baseline

    1. Run user acceptance testing and measure the baseline. Conduct UAT with 5-10 sales reps over 2 weeks. Measure cycle time and error rate for lead qualification and document turnaround. Compare against your pre-pilot baseline. Target a 60-80% reduction in manual data entry and a 50-70% reduction in lead response time. If retrieval precision is below 80%, clean your data and re-run UAT. If error rate is above 5%, adjust the system prompt or retrieval parameters. Document all findings in a UAT report.

  • AI Workflow Automation for German Medtech Compliance: A 2-Week pgvector Pilot

    The Compliance Team Is a Search Engine With a Law Degree

    A 300-person German medtech company runs its compliance and legal operations on a patchwork: SOPs live in Confluence, regulatory correspondence in Notion, contract templates in a shared drive, and the actual expertise in the heads of two senior compliance officers. When a new BfArM submission deadline lands, the team spends 14 to 22 minutes per query hunting through 40,000+ documents, and the error rate on first-draft responses sits at 12 to 18 percent. The compliance lead is not a knowledge worker; she is a search engine with a law degree. The same pattern repeats across the legal team, the clinical documentation group, and the quality assurance unit. No single system holds the full picture, and no one has the bandwidth to build one manually. The cost is not just time. It is the risk that a missed clause in a prior decision becomes a regulatory finding at the next audit.

    Why Off-the-Shelf RAG and Keyword Search Fail Here

    The first instinct is to buy a RAG product off the shelf. Most require you to restructure your document taxonomy, migrate content into their platform, and accept their model selection. For a German firm under GDPR, that means personal data in SOPs and correspondence leaves your infrastructure to a third-party cloud, triggering a full DPIA and a data processing agreement with a vendor whose sub-processors you cannot fully audit. The second instinct is to build a custom search on Elasticsearch with keyword matching. That handles exact-string lookups but fails on the queries that actually consume time: “What did we decide about the 2023 IEC 62304 update for the implant line?” Keyword search returns zero hits because the document says “software lifecycle revision” instead. The third approach — hiring a data science team to build a bespoke NLP pipeline — takes 6 to 9 months and produces a system only that team can maintain. None of these address the core problem: the knowledge is already in Notion and Confluence, and the team needs a retrieval layer that speaks to those systems without moving the data.

    A Retrieval Layer That Plugs Into What You Already Run

    The architecture that fits a 201-500 person German medtech firm is deliberately narrow: a retrieval-augmented search endpoint that ingests content from Notion and Confluence via their REST APIs, chunks documents into 256-512 token segments, generates embeddings with a multilingual model (BGE-M3 or multilingual-e5), and stores them in pgvector on the firm’s existing PostgreSQL instance. The search endpoint accepts a natural-language query in German or English, retrieves the top-k semantically relevant chunks, and returns them with source links. For the generation layer, a model-agnostic router calls OpenAI or Anthropic APIs for high-quality drafting where data residency permits, and falls back to an open-weight model on the firm’s own hardware for regulated content that cannot leave the building. The human-in-the-loop rule is non-negotiable: the model drafts, a compliance officer approves anything that touches a contract, a regulatory filing, or patient data, and every approval is logged with timestamp and identity. The system does not replace Confluence or Notion. It sits in front of them as a query layer.

    Two Weeks, Five Concrete Steps

    Week 1, days 1-3: process audit. Map the top 20 query types the compliance and legal teams handle weekly. Identify which documents in Notion and Confluence are referenced most often. Establish the baseline: median cycle time per query, error rate on first-draft responses, and the number of queries that require escalation to a senior officer. Week 1, days 4-5: data mapping and embedding. Ingest the target document set (typically 5,000 to 20,000 chunks for a 300-person firm), generate embeddings, and load them into pgvector with HNSW indexing. Verify that the API tokens for Notion and Confluence have read-only permissions scoped to the relevant spaces. Week 2, days 1-3: build the retrieval pipeline and the search endpoint. Wire the multilingual query interface, the top-k retrieval, and the source-link output. Run 50 test queries from the baseline set and measure cycle time and error rate. Week 2, days 4-5: before/after report and go/no-go recommendation. The deliverable is a working endpoint, a measured baseline comparison, and a documented path to scaling the same architecture to the clinical documentation and QA departments.

    Pitfalls That Sink a 2-Week Pilot

    The most common failure is treating the pilot as a proof of concept rather than a measured baseline. If you do not capture cycle time and error rate before the system goes live, you cannot quantify the improvement, and the business case for scaling across departments collapses. The second pitfall is over-scoping the document set. A 2-week pilot that tries to ingest every document in every Confluence space will spend the entire first week on data cleaning and the second week on debugging the embedding pipeline. Start with the 20 most-referenced document types. The third pitfall is ignoring access control. If the search endpoint returns a document that the querying user would not see in Confluence, you have created a GDPR Article 5(1)(f) violation and an internal trust problem. Enforce the same permissions at query time as the source system. The fourth pitfall is skipping the multilingual requirement. A German compliance team that queries in German and gets English-only results will abandon the tool within two weeks. The embedding model must handle both languages natively, not via a translation step.

  • 8-Week AI Automation Audit: Cutting First-Response Time in a UAE Medtech Firm

    1. Map the ticket flow before touching the model

    The audit phase is where most 11-50 person firms stall. Forfis starts by mapping every ticket that hits the support queue over a 10-day window, tagging each by topic, resolution path, and time-to-first-response. For a UAE medtech company, the data typically shows 60-70% of tickets are “where is the protocol for X” or “what is the warranty window for Y” questions that live in Confluence or Notion but are buried under 200+ pages. The audit output is a ranked list of the top five question categories by volume and time cost, with a measured baseline: average first-response time of 4.2 hours, error rate of 12% on a 200-ticket sample. This baseline is the number the pilot must beat, and it is documented in a one-page report the team signs off on before any code is written.

    2. Build the RAG layer on LangGraph, not a monolith

    The RAG pipeline indexes Confluence and Notion pages into a vector store, chunking at 512 tokens with 64-token overlap. LangGraph orchestrates the retrieval, generation, and scoring nodes. The predictive scoring module evaluates each draft on three axes: retrieval relevance (cosine similarity of the top-3 chunks), answer coherence (a secondary LLM call that checks the draft against the retrieved context), and historical approval rate (a running average from the pilot’s first 50 tickets). Responses scoring below 0.85 route to a human; those above auto-post to the helpdesk. For a 15-person team, this means the AI handles roughly 75% of tickets, and the human agent reviews the remaining 25% in under 5 minutes each. The scoring threshold is tunable in the LangGraph config without redeploying.

    3. Run the pilot with a measured before/after baseline

    The pilot runs for two weeks on a live subset of tickets. The team uses the agent in production, and every interaction is logged: the ticket ID, the retrieved chunks, the draft answer, the predictive score, and whether the human approved, edited, or rejected it. By the end of the soak period, the team has a 200-ticket dataset with before/after metrics. For a UAE medtech firm, the typical result is first-response time dropping from 4.2 hours to 18 minutes, with error rate holding at 11% or below. The 8-week timeline includes a one-week buffer for model tuning if the initial scoring threshold is too aggressive or too conservative. The final deliverable is a one-page baseline report with the numbers, the model used, the cost per 1,000 tokens, and a recommendation on whether to scale to all ticket categories or adjust the scope.

    4. Keep the model layer swappable from day one

    The architecture calls the LLM through an abstraction layer in LangChain, so the model is a config parameter, not a hard dependency. For a UAE healthcare firm with no compliance mandate, starting with OpenAI’s GPT-4o API is the fastest path: no hardware procurement, no MLOps overhead. The audit phase documents the cost per 1,000 tokens (typically $0.03-0.06 for GPT-4o) and the latency (18-25 ms for a 512-token response). If the team later decides to move to an open-weight model like Llama 3.1 70B on their own hardware, the LangGraph nodes do not change. The swap is a one-line config update. This matters for a 15-person team because it removes the risk of being locked into a single vendor’s pricing or API changes mid-engagement.

    5. Plug into the helpdesk, not around it

    The agent does not replace the helpdesk. It plugs into the existing ticketing system via API. When a ticket arrives, the agent retrieves relevant chunks, drafts a response, and posts it as a suggested reply in the ticket. The human agent sees the draft, approves or edits it, and sends it. The agent logs the retrieval context and the predictive score in the ticket metadata, so the team can audit why a particular answer was suggested. For a 15-person team, this means no new UI to learn, no workflow redesign, and no training beyond a 30-minute onboarding session. The agent operates inside the tools the team already uses, which is critical for adoption in a small firm where every hour of context-switching is expensive.

    6. Plan for the knowledge base to change

    The most common failure mode is treating the pilot as a one-time deliverable. For a 15-person UAE medtech firm, the knowledge base changes weekly: new protocols, updated warranty terms, revised SOPs. The RAG pipeline must re-index Confluence and Notion on a schedule (daily or on webhook trigger) to keep the chunks current. The predictive scoring model also drifts: the approval rate that was 75% in week 6 may drop to 60% in week 10 if the team starts asking different questions. The 8-week engagement includes a handover document that specifies the re-indexing cadence, the scoring threshold review schedule (monthly), and the escalation path if error rate exceeds 15% on a rolling 50-ticket window. Without this, the agent degrades silently within 60 days.

    7. Define the success metric before the pilot starts

    The 8-week engagement is not a product launch; it is a measured experiment with a clear success criterion. For a UAE medtech firm, the success criterion is: first-response time under 30 minutes on 80% of tickets, error rate under 12%, and the team reporting that the agent saves at least 3 hours per week per agent. The audit phase sets the baseline, the pilot measures against it, and the final report states whether the criterion was met. If it was, the team decides whether to scale to all ticket categories, add a voice channel, or extend the RAG layer to other internal tools. If it was not, the report identifies which axis failed (retrieval, generation, or scoring) and what the next iteration should target. The engagement ends with a decision, not a demo.