Forfis Blog

Tag: Internal Knowledge Search

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

    Process Audit and Baseline Measurement

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

    Customer-Facing Assistant on Support Channels

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

    Internal Knowledge Search for Legal and Compliance

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

    Predictive Scoring for Claim and Ticket Triage

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

    EU AI Act Compliance and Data Residency

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

    Pilot Timeline and Delivery Model

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

  • PCI DSS-Compliant AI Support Agent for a 2000+ Employee Fintech in Austria

    The Problem: Routine Work in a Regulated Fintech

    A 2,000-employee fintech in Austria faces a common problem: senior engineers and support specialists are buried in routine tasks. Ticket triage, document extraction, and data entry consume 40% of their time, leaving little room for high-value work. The company wants to deploy an AI agent to handle customer-facing support and internal knowledge search, but the compliance constraints are strict. PCI DSS Requirement 3.7.1 mandates that cardholder data must not be stored in logs or accessible to unauthorized systems. The AI agent must operate within these boundaries while still providing accurate, context-aware responses. The challenge is to build a system that is both technically robust and compliant, without replacing the existing CRM or ERP systems. The solution must integrate via custom REST APIs and webhooks, ensuring that data flows through controlled channels. This deep dive examines the architecture, trade-offs, and implementation details of such a system, focusing on how to free senior staff from routine work while maintaining compliance.

    Mechanism: RAG, LangGraph, and Predictive Scoring

    The core of the system is a retrieval-augmented generation (RAG) pipeline built on LangChain and LangGraph. LangChain provides the abstractions for prompt templates, vector stores, and LLM calls. LangGraph adds a stateful execution engine that models the agent as a graph of nodes. Each node represents a step in the workflow: classify intent, retrieve documents, draft response, human review. This structure is critical for compliance because it allows you to insert mandatory human-approval nodes at specific points. The RAG pipeline ingests documentation from the internal knowledge base, CRM records, and product manuals. Documents are chunked, embedded using OpenAI’s text-embedding-3-small, and stored in a vector database like Pinecone. At query time, the user’s question is embedded, and the top-k most relevant chunks are retrieved. These chunks are injected into the LLM’s context window, allowing the model to generate answers grounded in the company’s specific data. The predictive scoring model, trained on historical ticket data, outputs a confidence score that drives the routing logic. High-risk tickets are flagged for immediate human review, while low-risk tickets are handled by the AI agent.

    Trade-offs: Latency, Accuracy, and Compliance

    The primary trade-off is between latency and accuracy. Using a large, high-quality model like GPT-4 or Claude 3 Opus provides better accuracy but increases latency and cost. Using a smaller, faster model like GPT-3.5 or a local open-weight model reduces latency and cost but may sacrifice accuracy. For a support context, the recommended approach is to use a smaller model for initial classification and retrieval, and a larger model for drafting the final response. This hybrid approach balances speed and quality, keeping the average response time under 2 seconds while maintaining high accuracy. Another trade-off is between centralization and decentralization. A centralized RAG pipeline is easier to manage but may not scale well across departments. A decentralized approach, where each department has its own RAG pipeline, is more scalable but harder to maintain. The recommended approach is a modular architecture where the core components are reusable services that can be configured for different departments. This reduces the time and cost of scaling, as the core infrastructure is already in place. The final trade-off is between automation and human oversight. Full automation is faster but riskier. Human-in-the-loop is slower but safer. The recommended approach is to use human-in-the-loop for high-risk tasks and full automation for low-risk tasks, with the predictive scoring model driving the routing logic.

    Recommendation: A 6-Month Rollout Plan

    The 6-month timeline is aggressive but feasible if the scope is tightly controlled. Months 1-2 cover the process audit, PCI DSS gap analysis, and infrastructure setup. Months 3-4 focus on building the RAG pipeline, integrating with the CRM via REST APIs, and developing the predictive scoring model. Months 5-6 are dedicated to the pilot, including human-in-the-loop testing, baseline measurement, and final compliance validation. The pilot should measure three key metrics: cycle time, error rate, and customer satisfaction. The baseline is established by measuring these metrics over a 2-week period before the AI agent is deployed. After the pilot, the same metrics are measured over another 2-week period. The goal is to reduce cycle time by at least 30% and error rate by at least 20% while maintaining or improving CSAT. These metrics are tracked in a dashboard that is reviewed weekly by the project team. The managed AI operations model ensures that the system is monitored, updated, and optimized continuously. The vendor provides 24/7 monitoring, monthly model retraining, and quarterly compliance audits. This approach ensures that the system remains compliant and effective over time, freeing senior staff from routine work and allowing them to focus on high-value tasks.

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

  • Swiss E-Commerce Firm Cuts Invoice Processing Time 71% with On-Premise AI

    Background: A 300-Person Swiss E-Commerce Firm at Capacity

    This case study is a composite based on patterns observed across Forfis engagements. We do not name real clients. The company described here is a mid-size e-commerce and retail operator based in Zurich, with roughly 300 employees across operations, customer service, and finance. The stack is a mix of a legacy ERP (SAP Business One), a modern CRM (HubSpot), and Slack as the primary internal communication channel. The company had already automated one process — a basic rules-based invoice matching workflow — and was looking to extend AI automation to the next layer of back-office work without adding headcount. The constraint was clear: the finance team was at capacity, and the CTO had a hard deadline to reduce manual data entry before the next fiscal year close.

    Challenge: 12 Hours a Week Lost to Manual Data Entry

    The finance team was spending an estimated 12 hours per week on manual document extraction: pulling supplier invoice fields (vendor name, amount, tax code, line items) from PDFs and entering them into the ERP. The error rate on manual entry was around 8%, and each correction cycle added 45 minutes of rework. The operational pressure was threefold: the fiscal year close was eight weeks away, the team had no budget for additional hires, and the company was in the middle of a PCI DSS re-certification audit, which meant any new system touching payment-related data had to pass a formal risk assessment under Requirement 12.8. The CTO needed a solution that would free senior staff from routine work without introducing a new compliance liability.

    Approach: On-Premise Llama 3 with a Slack Approval Loop

    Forfis ran a two-week process audit that mapped every manual touchpoint in the invoice processing workflow. The audit identified that 70% of the extraction work involved supplier invoices in a consistent PDF format, making them a strong candidate for a fixed-scope pilot. The pilot used an open-weight model (Llama 3 70B) fine-tuned on 500 historical invoice examples, running on the client’s own A100 GPU node inside their VPC. The integration layer connected to Slack: the AI posted extracted fields to a dedicated channel, a human approved or flagged each entry, and approved fields were pushed to the ERP via its REST API. The entire pilot ran in eight weeks, with a measured baseline captured in week one and a shadow run in weeks seven and eight.

    Outcome: 71% Faster Cycle Time, 2.4% Error Rate

    The pilot reduced the average cycle time per invoice from 14 minutes to 4 minutes, a 71% improvement. The field-level error rate dropped from 8% to 2.4%, below the 3% threshold agreed in the pilot scope. The human approval step required intervention on roughly 15% of documents in the first two weeks, tapering to 6% by the end of the shadow run. The finance team reported that the senior staff who had been doing manual entry were now spending that time on supplier negotiations and exception handling. The PCI DSS risk assessment was completed in week six, and the audit trail (every extraction event logged with a document hash) satisfied Requirement 10.2.2 without additional controls.

    Lessons for Teams Scaling AI Without New Hires

    • Baseline before you build. Capturing a 200-document baseline in week one is non-negotiable. Without it, you cannot prove the pilot worked, and the go/no-go decision becomes a gut call. Forfis treats the baseline as a contract: the same sample size, the same measurement method, before and after.
    • Pick the highest-volume, lowest-complexity workflow first. The pilot should target the workflow where the ratio of document volume to format variability is highest. A consistent PDF format with 70% of the volume is a better pilot candidate than a mixed-format pipeline with 30% of the volume.
    • The approval loop is the product, not the model. The Slack channel where a human clicks approve is where the real value lives. The model is a swappable component; the approval workflow is what the team actually uses every day.
    • PCI DSS compliance is a design constraint, not an afterthought. The on-premise architecture and the audit trail were built in from day one, not bolted on after the pilot. Requirement 12.8 risk assessment and Requirement 10.2.2 logging were part of the pilot scope, not a separate workstream.

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

  • How a 15-Person UK Medtech Firm Cut Back-Office Errors 40% in Two Weeks

    1. The pilot scope is one workflow, not a platform

    A 15-person medtech company in Manchester was losing 11 hours per week to manual invoice data entry and document extraction. The finance lead typed supplier invoices into the ERP, cross-checked line items against purchase orders, and flagged discrepancies in a shared spreadsheet. Error rate: 6.2% on a sample of 200 invoices. Cycle time: 4.3 hours per batch.

    The fix was not a new hire. It was a fixed-scope pilot with a two-week deadline: automate the extraction and validation step for one supplier, integrate it into the existing ERP via API, and measure the before/after delta. The pilot used the Anthropic Claude API for document parsing because the invoice formats were inconsistent and required nuanced field mapping. A human approved every extracted record before it hit the ERP. The result: error rate dropped to 1.8%, cycle time fell to 1.1 hours per batch, and the finance lead spent the freed time on supplier negotiations instead of data entry.

    2. The integration lives in Slack, not a new dashboard

    The pilot ran inside the team’s existing Slack workspace. A bot posted extracted invoice fields into a dedicated channel, tagged the finance lead for approval, and logged the decision. No new UI, no new login, no training session. The integration used the Slack API and the ERP’s REST endpoint — both already in production.

    This matters because a 15-person team does not have the bandwidth to adopt a new tool. The workflow orchestration layer sat between the Claude API and the ERP: it handled retries, format validation, and the approval gate. When the finance lead approved a record in Slack, the orchestration layer pushed it to the ERP. When they rejected it, the bot asked for the correction and re-processed. Every interaction was logged for the GDPR audit trail. The team never left Slack. The AI never replaced the ERP. It filled the gap between the two.

    3. GDPR compliance is a design constraint, not an afterthought

    The pilot processed supplier invoices, which contain no patient data. But the company’s broader documentation — SOPs, regulatory checklists, clinical trial protocols — does. The architecture was designed from day one to be model-agnostic: the orchestration layer could route a request to the Anthropic Claude API for general document work, or to an open-weight model running on the company’s own server for anything touching special-category data under GDPR Article 9.

    The DPIA was completed before the pilot started. It documented: what data the AI processes, where it is stored, who can access it, and how a human can override any automated decision. The Data Processing Agreement with Anthropic was signed. The open-weight model (a 7B-parameter Llama variant) ran on a single GPU workstation in the office. No patient data left the building. The pilot’s scope was narrow enough that the compliance overhead was a one-day task, not a multi-week project.

    4. The baseline is measured, not assumed

    The pilot’s success metric was not “the AI works.” It was: error rate drops from 6.2% to under 3%, and cycle time drops from 4.3 hours to under 2 hours per batch. The baseline was measured in week one, before any automation was live. The team processed 50 invoices manually and logged every error and every minute. In week two, the AI processed the same 50 invoices, and the finance lead approved or corrected each one. The delta was the deliverable.

    This is what separates a pilot from a demo. A demo shows the AI extracting fields from a sample PDF. A pilot measures whether the extraction is accurate enough to trust in production, and whether the human approval step is fast enough to be worth the overhead. The 4.3-hour to 1.1-hour drop was not theoretical. It was logged in the ERP’s audit trail, timestamped, and attributable to the automation.

    5. The rollout is a sequence of fixed-scope engagements

    The pilot’s scope was one supplier, one document type, one integration point. The rollout plan was explicit: week three adds the second supplier, week four adds the third, week five adds the document extraction for purchase orders. Each expansion was a separate fixed-scope engagement with its own baseline and success metric.

    This is how a 15-person company scales operations without new hires. The finance lead’s role did not change — she still approved every record. But the time she spent typing dropped from 4.3 hours to 1.1 hours per batch. The freed capacity went to supplier management, which had been neglected for two years. The company did not hire a data entry clerk. It did not buy a new ERP. It added an AI layer to the workflow it already ran, measured the delta, and expanded only when the numbers justified it.

    6. The knowledge search is a byproduct, not the goal

    The pilot’s real value was not the 40% error reduction. It was the internal knowledge search capability that emerged from the same architecture. The orchestration layer that routed invoice data to the ERP was repurposed to route queries to the company’s document store. A support agent in Slack could now ask, “What is the recall procedure for device X?” and get a cited answer from the SOP, with the relevant section highlighted. The agent still reviewed the answer before sending it to a customer. The AI did not replace the agent. It cut the search time from 12 minutes to 90 seconds.

    The synthesis: a 15-person UK medtech company did not need a new hire, a new ERP, or a new helpdesk. It needed a two-week fixed-scope pilot that measured a real delta, ran inside the tools the team already used, and kept a human in the loop for every high-stakes action. The AI was a layer, not a replacement. The compliance was a constraint, not a blocker. The rollout was a sequence, not a big bang. That is the pattern that works when the team is small, the data is regulated, and the timeline is two weeks.