Forfis Blog

Tag: Germany

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

  • 12-Step Checklist: RAG Pilot for Lead Qualification in German Insurance

    Pre-Pilot: Scope and Compliance Setup

    A 2-week fixed-scope pilot in a German insurance firm must produce a working RAG assistant on one workflow, a GDPR-compliant data-flow document, and a measured before/after baseline. The checklist below is operational: each item is a task a team can mark done or not done. It assumes the team uses LangChain and LangGraph, integrates with Slack or Microsoft Teams, and targets lead qualification to cut first-response time. The pilot is not a production deployment; it is a scoped experiment with a clear exit criterion. Work through the items in order. Skipping the audit or the baseline measurement invalidates the pilot’s value as a decision input for rollout.

    Build the RAG Pipeline on LangChain and LangGraph

    The RAG pipeline is the core of the pilot. Build it on LangChain for document chunking, embedding, and vector search, and on LangGraph for the stateful workflow that routes queries, handles multi-turn context, and triggers the human-approval gate. Keep the graph simple: one retrieval node, one generation node, one approval gate. Use a managed vector store in an EU region for the pilot. If the client’s data cannot leave the building, switch to an on-premises vector store and an open-weight model on the client’s GPU hardware. The RAG code is identical; only the embedding and inference endpoints change. Test the pipeline against 20 real lead queries before integrating with Slack or Teams.

    Integrate with Slack or Microsoft Teams

    The pilot must integrate with the channel the team already uses: Slack or Microsoft Teams. Build a bot that receives the lead query, calls the RAG pipeline, and returns the draft qualification score and suggested next step. The bot must include a human-approval gate: if the AI’s confidence drops below a threshold, or if the lead involves health-related data, the bot flags the query for a human agent. Log every human override. The integration must not replace the existing CRM or helpdesk; it plugs into them via their APIs. For a 2-week pilot, use a single OpenAI or Anthropic API endpoint for the LLM layer. Keep the model-agnostic layer thin: a single abstraction over the API call so switching providers later requires only a config change.

    Measure the Before/After Baseline

    Before the pilot starts, measure the baseline: cycle time from lead entry to qualified status, and error rate (misclassified leads) for the 2 weeks prior. Document the sample size, the definition of ‘error,’ and the measurement method. During the pilot, measure the same metrics for the 2 weeks of the pilot. The before/after comparison is the pilot’s primary deliverable. Without it, the client has no objective basis for the rollout decision. The baseline report must include: the number of leads processed, the average cycle time before and after, the error rate before and after, and the number of human overrides. This report is the exit criterion for the pilot.

    Define the Pilot Exit Criterion

    The pilot is a fixed-scope engagement: the vendor delivers a defined set of artifacts within the 2-week deadline. It is not a subscription or managed service. After the pilot, the client decides whether to proceed to rollout. The pilot includes a measured before/after comparison on cycle time and error rate, giving the client objective data to justify or reject the full deployment. The exit criterion is clear: if the pilot reduces cycle time by at least 30% and error rate by at least 20%, the client proceeds to rollout. If not, the pilot ends, and the client retains the baseline report and the RAG pipeline code. The vendor does not retain any client data after the pilot ends.

    Maintain the Checklist Over Time

    The checklist is a living document. After the pilot, review each item: mark what worked, what did not, and what needs adjustment. If the pilot proceeds to rollout, update the checklist to reflect the new scope: additional workflows, multi-language support, production monitoring. If the pilot ends, archive the checklist with the baseline report. Revisit the checklist before any new pilot: the GDPR landscape, the LLM provider landscape, and the integration landscape change. The checklist is not a one-time artifact; it is a tool for continuous improvement in AI-native operations. Keep it in the team’s project management tool, not in a static PDF.