Forfis Blog

Tag: Candidate Screening

  • Building a Candidate Screening AI Pilot for Austrian Professional Services

    The Problem: Manual Candidate Screening at Scale

    Your 15-person Austrian professional services firm receives 200-300 applications per month across German, English, and Austrian German. Manual screening takes 15-20 hours per week, and response times average 5-7 days. You need a system that processes applications 24/7, responds in the candidate’s language, and integrates with your existing ATS. The challenge: you’re running isolated pilots, not a full AI transformation. You need a focused, measurable pilot that proves value before scaling. The solution: a retrieval-augmented knowledge assistant built on LangChain and LangGraph, with human-in-the-loop approval for every candidate-facing response. This pilot runs in 8 weeks, costs EUR 25,000-40,000, and delivers a 70-80% reduction in screening time.

    Prerequisites: What You Need Before Starting

    • ATS API access: Your ATS must expose a REST API for reading applications and updating candidate status. Document the endpoints, authentication method, and rate limits.
    • Baseline metrics: Measure current screening time (hours per 100 applications), error rate (misclassified applications), and response time (days from application to first contact).
    • Language requirements: List the languages you need to support (German, English, Austrian German) and the tone for each.
    • Approval workflow: Define who reviews AI-drafted responses and the approval criteria. This is non-negotiable for legal and compliance reasons.
    • Infrastructure: You need a server or cloud instance to run open-weight models for sensitive data. The system uses cloud APIs for general queries and local models for personal data processing.
    • Data access: Provide sample applications (anonymized) for testing the extraction pipeline. Include edge cases: incomplete applications, unusual formats, multilingual documents.

    Step 1: Audit the Current Screening Process

    Map the current screening process end-to-end. Document every step: application receipt, initial review, criteria matching, response drafting, and ATS update. Measure the time for each step and identify bottlenecks. For example, if initial review takes 8 minutes per application and response drafting takes 12 minutes, the total is 20 minutes. This baseline is your success metric. Without it, you cannot prove the AI system’s value. Use a simple spreadsheet: columns for step, time per application, error rate, and owner. This takes 2-3 days and involves 2-3 team members.

    Step 2: Define the AI System’s Scope

    Define the AI system’s scope. It will: (1) extract candidate data from applications (name, email, skills, experience), (2) classify applications against your criteria (e.g., minimum 3 years experience, specific certifications), (3) draft initial responses in the candidate’s language, and (4) update your ATS via REST API. It will NOT: make final hiring decisions, communicate with candidates without human approval, or process applications outside your defined criteria. Document this scope in a one-page brief. This prevents scope creep and sets clear expectations for the pilot.

    Step 3: Build the LangGraph State Machine

    Build the LangGraph state machine. The graph has five nodes: extract (pull candidate data from application), classify (match against criteria), draft (generate response in candidate’s language), approve (human review), and update_ats (send to ATS via REST API). Each node is a LangChain chain with a specific prompt. The extract node uses a document parser (e.g., PyPDF2 for PDFs, BeautifulSoup for HTML). The classify node uses a structured output parser to return JSON with confidence scores. The draft node uses a multilingual prompt template. The approve node pauses the graph and sends the draft to your reviewer via email or Slack. The update_ats node makes a POST request to your ATS API. This takes 3-4 days to build and test.

    Step 4: Integrate with Your ATS via REST API

    Connect the AI system to your ATS. You provide the API base URL, authentication token, and endpoint documentation. The system makes three types of API calls: (1) GET /applications to fetch new applications, (2) POST /applications/{id}/status to update candidate stage, and (3) POST /applications/{id}/message to log the AI-drafted response. The system also subscribes to webhooks for status changes (e.g., candidate accepts offer). Test the integration with 10-20 sample applications. Verify that data flows correctly in both directions and that error handling works (e.g., API timeout, invalid token). This takes 2-3 days.

    Step 5: Run Shadow Mode and Calibrate

    Run the system in shadow mode for 2 weeks. The AI processes all new applications and drafts responses, but humans handle the actual communication. Compare the AI’s classifications and drafts against human decisions. Track: (1) classification accuracy (AI vs. human), (2) draft quality (human rating on a 1-5 scale), and (3) processing time (AI vs. manual). If classification accuracy is below 85%, adjust the criteria or prompt. If draft quality is below 4/5, refine the prompt templates. This phase reveals edge cases and calibrates the system. It takes 2 weeks and involves 1-2 reviewers.

  • AI Candidate Screening and HR Reporting for a UK Insurance Firm: A 3-Month Pilot

    The Problem: Scaling HR Operations Without New Hires

    A 2,000+ employee insurance firm in the UK faces a familiar constraint: HR and recruiting teams are stretched thin, and the volume of candidate applications and monthly reporting cycles keeps growing without a corresponding increase in headcount. The firm needs to process more applications, produce more reports, and maintain compliance with GDPR Article 22 on automated decision-making, all within a 3-month window. The solution is not a new HR platform or a full AI transformation. It is a fixed-scope pilot that automates one or two specific workflows, measures the impact, and establishes a foundation for scaling across departments. The pilot targets candidate screening and monthly reporting, using a retrieval-augmented knowledge assistant that reads from the firm’s existing Confluence or Notion workspace. The architecture is model-agnostic: OpenAI or Anthropic APIs for tasks where output quality matters, and open-weight models on the firm’s own hardware for any data that cannot leave the building. The pilot ships with a measured before/after baseline on cycle time and error rate, so the business case is quantified, not assumed.

    Pilot Scope: Candidate Screening and Monthly Reporting

    The pilot begins with a process audit that maps the current candidate screening workflow end to end. The team identifies where manual effort concentrates: parsing application PDFs, matching candidates against job descriptions, flagging compliance issues, and drafting initial feedback. The same audit covers the monthly reporting cycle, which typically involves pulling data from the HR system, formatting it into a template, and writing narrative summaries. The data sources are the firm’s existing Confluence or Notion workspace, which holds job descriptions, screening criteria, and reporting templates. The assistant connects to these platforms through their public APIs, so the HR team continues to maintain content where it already lives. The architecture uses pgvector for embeddings search, storing vector representations of the source documents in a PostgreSQL instance on the firm’s own infrastructure. This keeps the data within the firm’s control, which matters for an insurance company handling regulated data. The model layer is deliberately model-agnostic: the pilot uses OpenAI or Anthropic APIs for drafting and classification tasks, and open-weight models on the firm’s hardware for any step that touches sensitive candidate data.

    Human-in-the-Loop and GDPR Compliance

    The assistant does not make final decisions on candidates. It classifies applications against the screening criteria stored in Confluence, ranks them, and drafts a summary for the recruiter to review. A human recruiter approves or overrides every screening decision before it reaches the candidate. This human-in-the-loop design satisfies GDPR Article 22, which requires human involvement in automated decisions with legal or similarly significant effects. The same principle applies to monthly reporting: the assistant assembles the data, formats the report, and drafts the narrative sections, but a human analyst reviews and approves the final document before distribution. Every pilot ships with a measured before/after baseline. The baseline captures cycle time, the time from application receipt to screening decision, and error rate, the percentage of screening decisions that a human reviewer would overturn. The baseline is measured during the first two weeks of the pilot, before the AI is fully active, so the comparison is direct. The firm gets a quantified picture of the impact, not a qualitative impression.

    3-Month Timeline and Delivery Phases

    The 3-month timeline breaks into three phases. Weeks 1 to 4 cover the process audit and data mapping: the team interviews HR and recruiting staff, maps the current workflow, identifies the data sources in Confluence or Notion, and defines the success metrics. Weeks 5 to 8 are development and integration: the team builds the retrieval-augmented assistant, connects it to the HR system and the documentation platform, and configures the model layer. Weeks 9 to 12 are user testing and measurement: the HR team uses the assistant in a live environment, the team captures the before/after baseline, and the firm makes a go/no-go decision on broader rollout. The pilot covers one or two workflows, not the entire HR function. The output is a working system, a measured baseline, and a clear picture of what scaling across departments would look like. The architecture is designed so that the next department, whether it is claims processing or customer service, plugs into the same stack without rebuilding from scratch.

    Scaling Across Departments After the Pilot

    The pilot is not the end of the engagement. It is the first step in scaling AI across departments. The architecture established in the pilot, the model-agnostic layer, the human-approval workflow, the pgvector embeddings search, and the measurement framework, is reusable. When the firm decides to extend the assistant to claims processing or customer service, the team reuses the same integration patterns and the same compliance controls. The marginal cost and time for each new use case is lower than the initial pilot because the foundational work is already done. The firm also gets a managed operation model: the team monitors the assistant, handles model updates, and maintains the integration with the HR system and documentation platform. This is not a one-off project; it is a managed service that scales with the firm’s needs. The 3-month pilot gives the firm a quantified business case, a working system, and a clear path to scaling without new hires.

  • 8-Week RAG Pilot: Cutting Candidate Data Entry by 73% in a UAE Logistics Firm

    Background: A 300-Person Logistics Firm in the UAE

    This case study is a composite based on patterns observed across multiple engagements. We do not name real clients. The company described here is a mid-size logistics and supply chain operator in the UAE, with roughly 300 employees, operating in Dubai and Abu Dhabi. The firm runs a standard stack: SAP for ERP, Salesforce for CRM, Google Workspace for email and documents, and a legacy ATS (applicant tracking system) that predates the current hiring volume. The company is in a scaling phase, having doubled headcount over 18 months, and the HR and compliance teams are stretched thin. The CEO and COO are the decision-makers; there is no dedicated data science team. The firm handles personal data (candidate resumes, visa documents, salary history) subject to both GDPR (for EU-based candidates) and the UAE Personal Data Protection Law (PDPL, Federal Decree-Law No. 45 of 2021).

    Challenge: Manual Data Entry at Scale, with a Compliance Deadline

    The HR team was processing 150 to 200 candidate applications per week across three departments: operations, compliance, and IT. Each application required a recruiter to manually extract fields from PDF resumes into the ATS: name, contact, years of experience, certifications, visa status, and expected salary. This took 3 to 5 minutes per candidate, roughly 12 to 15 hours of manual data entry per week. The error rate was 8 to 12%, with common mistakes including misread visa expiry dates and transposed phone numbers. The compliance team flagged a risk: under GDPR Article 22 and UAE PDPL Article 17, any automated decision-making affecting candidates required human oversight. The firm had no process to audit AI outputs, and the CEO set a hard deadline: a working pilot within 8 weeks, before the Q3 hiring surge. The constraint was not budget; it was time and compliance certainty.

    Approach: A Fixed-Scope RAG Pilot with Human-in-the-Loop

    Forfis ran a one-week process audit, mapping the resume-to-ATS workflow and identifying the 12 fields most prone to manual error. The pilot scope was fixed: a retrieval-augmented knowledge assistant that ingests PDF resumes, extracts structured fields using an LLM, and returns a pre-filled ATS form for human review. The architecture used pgvector for embedding search over a small corpus of past hiring decisions (to calibrate extraction accuracy), OpenAI’s API for generation, and a thin integration layer into Google Workspace (Gmail for resume intake, Google Docs for review notes). The model was model-agnostic: the pipeline called an API endpoint, so the client could swap to an on-prem open-weight model (Llama 3 70B) if data residency requirements tightened. A dedicated AI team of three (one engineer, one product designer, one compliance consultant) worked on-site in Dubai for the first two weeks, then remotely. Every extraction was logged; a human reviewer approved or corrected each field before it entered the ATS.

    Outcome: 73% Faster Processing, 80% Fewer Errors

    After two weeks of pilot operation, the team measured before/after baselines. Cycle time per candidate dropped from an average of 4.2 minutes to 58 seconds, a 73% reduction. The error rate on the 12 tracked fields fell from 9.5% to 1.8%, with the remaining errors concentrated in visa expiry dates (a known OCR weakness on scanned PDFs). The HR team processed 180 applications in the pilot week versus 140 in the prior week, with the same headcount. The compliance team signed off on the human-in-the-loop workflow: no field entered the ATS without a human click. The model-agnostic design meant the client could migrate to on-prem inference in Q4 if the UAE PDPL enforcement tightened. The pilot cost was within the fixed-scope budget; the ongoing managed operation (monitoring, model updates, support) was priced at a monthly retainer. The CEO approved rollout to the IT and operations departments in the following quarter.

    Lessons for Teams Scaling AI Across Departments

    • Start with the process audit, not the model. The one-week audit identified which fields were worth automating. Skipping this step leads to over-engineering: building a RAG pipeline for fields that are already 95% accurate. – Human-in-the-loop is not a compromise; it is the compliance architecture. Under GDPR Article 22 and UAE PDPL Article 17, the human approval step is what makes the system lawful. Design the workflow around the approval, not around the model. – pgvector is the right choice for 201-500 employee companies. You already run PostgreSQL. Adding pgvector avoids a separate vector database, reduces operational overhead, and handles 100k to 1M vectors on a single node. – Model-agnostic design is a risk hedge. The client started with OpenAI for speed. The architecture allowed a swap to on-prem Llama 3 if data residency rules tightened. This flexibility was not a technical detail; it was a compliance decision. – Measure before/after baselines from day one. The pilot shipped with a measured baseline on cycle time and error rate. Without this, the business case for rollout is anecdotal. With it, the CEO approved the next phase in a single meeting.

  • RAG Candidate Screening for a 20-Person German Logistics Firm

    The Problem: Senior Staff Buried in Candidate Screening

    A 20-person logistics and supply chain company in Germany faces a recurring problem: senior operations managers spend 45 minutes per CV screening warehouse and fleet candidates, a task that scales linearly with applicant volume but adds no strategic value. The firm has no AI in production yet, no dedicated data team, and a hard constraint that personal data cannot leave German infrastructure due to GDPR. The need is not to replace HR but to free senior staff from routine work so they can focus on route optimization, supplier negotiations, and stakeholder management. The delivery model is a fixed-scope AI automation audit followed by a four-week pilot, with the goal of scaling operations without new hires. The use case is candidate screening, integrated with the firm’s existing Confluence documentation, and the AI stack is deliberately model-agnostic, using OpenAI’s API where quality matters and open-weight models on client hardware where regulated data cannot leave the building.

    How the RAG Assistant Works: Pipeline and Model Selection

    The system is a retrieval-augmented generation (RAG) assistant that ingests job descriptions, internal competency matrices, and past interview notes from Confluence via its REST API. The pipeline has three stages. First, a document parser extracts structured fields from CVs: name, contact, work history, certifications, and location. Second, a vector database (pgvector or Qdrant) stores embeddings of the job requirements and competency rubrics. Third, a language model scores each CV against the role’s requirements using a rubric defined by the hiring manager. The model is model-agnostic: OpenAI’s gpt-4o-mini handles non-personal tasks like formatting, while Llama 3 70B or Mistral 8x7B runs on the client’s own GPU server for any step touching personal data. The assistant drafts a shortlist with rationale and flags mismatches, such as a missing forklift certification for a warehouse role. A human reviewer approves or rejects each candidate before any communication goes out. The architecture is human-in-the-loop by default, and every pilot ships with a measured before/after baseline on cycle time and error rate.

    Trade-offs: Model Choice, Integration Depth, and Scope

    The architect faces three key trade-offs. First, model choice: OpenAI’s API offers higher quality for nuanced reasoning but requires a Standard Contractual Clause and data transfer to the US, which complicates GDPR compliance for personal data. Open-weight models on client hardware avoid this but require GPU infrastructure and tuning effort. For a 20-person firm, the cost of a single A100 GPU (roughly EUR 12,000 upfront or EUR 1,500/month via cloud) is justified if it eliminates the need for a data engineering hire. Second, integration depth: the assistant reads from Confluence via API but does not write back unless explicitly configured, preserving the existing governance model. This avoids the risk of the AI modifying source documents without human oversight. Third, scope: the pilot covers one hiring function, not the entire HR workflow. This keeps the four-week timeline realistic and the success criteria measurable. The trade-off is that the firm must decide which function to automate first, typically warehouse operations or fleet management, based on applicant volume and senior staff time spent.

    Recommendation: Audit, Pilot, and Rollout Path

    For a 20-person German logistics firm with no AI in production, the recommendation is a two-week audit followed by a two-week pilot on one hiring function. The audit maps the candidate screening workflow end-to-end, identifies which steps are rule-based versus judgment-based, and produces a prioritized automation roadmap. The pilot runs with a measured baseline: average time per CV, error rate on qualification decisions, and reviewer confidence. Success criteria are predefined: at least 40% reduction in screening time and no increase in false-positive rates. The architecture uses open-weight models on client hardware for any step touching personal data, with OpenAI’s API reserved for non-personal tasks. The assistant integrates with Confluence via its REST API, preserving existing access controls. The firm must provide candidates with information about the automated processing under GDPR Article 13 and 14, and the data processing agreement must specify that personal data is used for recruitment purposes only. The system does not make the final hiring decision; it reduces the time from 45 minutes per CV to under 5 minutes, freeing senior staff for strategic work.

  • 4-Week AI Candidate Screening Pilot for UK Professional Services

    The Problem: Scaling Back-Office Operations Without New Hires

    You run a 20-person professional services firm in the UK. Candidate screening consumes senior staff time, error rates creep up as volume grows, and you cannot hire more back-office staff without eroding margins. The problem is not a lack of talent; it is a lack of automation in the workflows that already exist. An AI-native operations approach automates candidate screening, document extraction, and data entry, reducing error rates and cycle times. The 4-week timeline is realistic for a fixed-scope pilot on one workflow, with a measured before/after baseline on cycle time and error rate. This allows you to prove ROI before committing to broader rollout. The architecture is model-agnostic: open-weight models on-premise for regulated data, OpenAI or Anthropic APIs where quality matters. The integration plugs into Google Workspace via APIs, not replacing your existing stack.

    Prerequisites: What You Need Before Step 1

    Before step 1, you need the following in place:

    • Access to candidate screening data: CVs, job descriptions, competency matrices, and past interview notes, organized in a format the AI can ingest.
    • Google Workspace API access: OAuth credentials for Gmail, Google Docs, and Google Calendar, so the AI can read CVs, draft notes, and schedule interviews.
    • On-premise hardware: A server with at least 80 GB of VRAM to run open-weight models like Llama 3 70B or Mistral 7B locally.
    • A baseline measurement: Current cycle time per CV, error rate, and volume per week, measured over the last 4 weeks.
    • A human reviewer: One person who will approve or reject AI recommendations, with clear criteria for what constitutes an error.

    Steps: Deploying the Candidate Screening Assistant in 4 Weeks

    1. Conduct the process audit. Measure current cycle time, error rate, and volume for candidate screening over the last 4 weeks. Track how long it takes to review each CV, how many errors occur, and how many CVs arrive per week. This baseline is the foundation for the before/after comparison.

    2. Build the retrieval-augmented assistant. Index your job descriptions, competency matrices, and past interview notes into a vector store. Use a tool like LangChain or LlamaIndex to retrieve the most relevant policy snippets for each CV. Prompt the model to score the candidate against those specific documents.

    3. Integrate with Google Workspace. Use the Gmail API to read CVs from attachments, the Google Docs API to draft screening notes, and the Google Calendar API to schedule interviews. The AI works within your existing stack, not replacing it.

    4. Set up the human-in-the-loop workflow. The AI drafts a recommendation, but a human reviewer approves or rejects it before any decision is made. Log every AI recommendation and human decision for auditability.

    5. Measure the after baseline. Run the pilot for 2 weeks, measuring cycle time and error rate. Compare against the before baseline. If error rate drops by 30% or more and cycle time drops by 50% or more, the pilot is a success.

    Common Pitfalls: What Goes Wrong and How to Detect It

    • Hallucinated criteria: The model invents hiring criteria not in your documents. Detect this by logging every AI recommendation and checking it against the retrieved policy snippets. If the model references a criterion not in the vector store, flag it for review.

    • Data leakage: Regulated data leaves the building. Detect this by monitoring network traffic on the on-premise server. If any data is sent to an external API, the system is misconfigured. Use a firewall to block outbound traffic except for approved APIs.

    • Integration failures: The AI cannot read CVs from Gmail or draft notes in Google Docs. Detect this by testing the API integrations before the pilot. If the Gmail API returns a 403 error, your OAuth credentials are misconfigured.

    • Human reviewer bottleneck: The human reviewer cannot keep up with the volume of AI recommendations. Detect this by tracking the time between AI recommendation and human approval. If it exceeds 10 minutes, the workflow is not scalable.

    • Model drift: The model’s accuracy degrades over time as your hiring criteria change. Detect this by re-measuring the error rate every 2 weeks. If it rises by 10% or more, retrain the model on the latest data.

    Conclusion: The Next Step After the Pilot

    The 4-week pilot proves the AI layer reduces error rate and cycle time for candidate screening. The next logical step is to scale to other back-office workflows, such as invoice processing, document extraction, and data entry. The same architecture applies: a retrieval-augmented assistant over your firm’s own documentation, integrated with Google Workspace, with a human-in-the-loop approval workflow. The process audit identifies the next workflow to automate, and the fixed-scope pilot proves ROI before you commit to broader rollout. This is how you scale operations without new hires, reducing error rates and cycle times across the firm.

  • Compliance-Safe AI Candidate Screening for a 51-to-200-Person German Firm

    The Manual Data-Entry Bottleneck in Candidate Screening

    A 51-to-200-person professional-services firm in Germany runs candidate screening the way most firms of that size do: a recruiter or HR coordinator opens each application, reads the CV, copies the name, contact details, and relevant experience into the ATS or a Google Sheet, and flags the candidate for the hiring manager. The process is manual, sequential, and error-prone. A single recruiter handling 40 to 60 applications per week spends 15 to 25 minutes per application on data entry alone, which is 10 to 25 hours per week of work that adds no judgment value. The error rate on manual transcription is 3 to 7 percent, and every error means a follow-up call, a corrected record, or a missed candidate. The affected roles are the recruiter, the HR coordinator, and the hiring manager, who receives a delayed and sometimes inaccurate shortlist. The systems involved are the ATS, Google Workspace (Gmail, Drive, Sheets), and the CRM if the firm tracks candidates there. The metric that matters is cycle time from application receipt to shortlist decision, and the current baseline is measured in days, not hours.

    Why Off-the-Shelf AI Recruiting Tools and In-House Builds Fall Short

    The first common approach is to buy an off-the-shelf AI recruiting tool. These products promise automated screening, but they are built for high-volume, high-turnover hiring, not for the nuanced, role-specific screening a professional-services firm does. The model is trained on generic job descriptions and generic CVs, so it misclassifies candidates whose experience is relevant but phrased differently. The tool also sits outside the firm’s existing systems: it has its own database, its own login, its own data model. The recruiter now has to enter data into the ATS and into the AI tool, doubling the work. The second approach is to build a custom solution in-house. For a 51-to-200-person firm, the engineering team is small or nonexistent, and a custom build takes three to six months, which is longer than the firm’s tolerance for a process that is broken today. The third approach is to hire a larger recruiting team. This increases cost without reducing the error rate, and it does not address the cycle-time problem. None of these approaches produce a measured before-and-after baseline, which is the only way to know whether the change actually worked.

    A Fixed-Scope Pilot on One Process, Built for Compliance

    The path that fits a 51-to-200-person professional-services firm in Germany is a fixed-scope pilot on one process, delivered in two weeks, with a measured baseline and a human-in-the-loop approval step. The pilot starts with a process audit that maps the current candidate-screening workflow, identifies the single process worth automating, and defines the success metric: a reduction in manual data-entry time and error rate. The architecture is model-agnostic. Where the data is sensitive and cannot leave the building, the pipeline runs open-weight models on the firm’s own hardware. Where quality matters and the data is not regulated, it uses OpenAI or Anthropic APIs. The retrieval layer uses pgvector embeddings search: candidate documents and job descriptions are embedded and stored in a Postgres instance, and the pipeline retrieves the most relevant context for each application before the model classifies and extracts. The integration layer plugs into Google Workspace through its API, so the recruiter’s inbox is the intake point and the enriched record appears in the ATS or a Google Sheet without manual copy-paste. The pilot ships with a before-and-after baseline on cycle time and error rate, and every output that touches a candidate’s record is approved by a human reviewer.

    EU AI Act Compliance as a Design Constraint, Not an Afterthought

    The EU AI Act, which entered into force on 1 August 2024, classifies AI systems used for candidate screening as high-risk under Annex III, point 4. This triggers obligations under Articles 8 through 15, including risk management, data governance, technical documentation, record-keeping, transparency, human oversight, and accuracy, robustness, and cybersecurity. For a 51-to-200-person firm, the practical burden is documentation and audit trails, not building a compliance team. The fixed-scope pilot addresses this by design. The human-in-the-loop approval step satisfies the human-oversight requirement under Article 14. The measured baseline and the logged corrections satisfy the data-governance requirement under Article 10. The technical documentation, which includes the model used, the prompt, the retrieval logic, and the approval workflow, satisfies Article 11. The record-keeping requirement under Article 12 is met by logging every document read, every model output, and every human approval with a timestamp and the reviewer’s identity. The model-agnostic architecture eliminates the data-residency question: if the data cannot leave the building, the pipeline runs on local hardware, and the technical documentation reflects that. The pilot is not a compliance project; it is a process-automation project that happens to be built to the Act’s requirements from day one.

    How to Start: Five Concrete Steps in Two Weeks

    The first step is a three-to-five-day process audit. The audit maps the current candidate-screening workflow: who does the data entry, how long it takes per application, what the error rate is, and which systems hold the data. It identifies the single process to automate and defines the success metric. The output is a one-page roadmap. The second step is to agree the fixed-scope pilot: the deliverable is a working candidate-screening pipeline on one process, the deadline is two weeks, and the success metric is a measured reduction in manual data-entry time and error rate compared to the pre-pilot baseline. The third step is to set up the data layer: embed the job descriptions and a sample of candidate documents into pgvector, and configure the Google Workspace API integration with the correct OAuth 2.0 scopes. The fourth step is to build the pipeline: the model classifies and extracts, the human reviewer approves, and the enriched record is written to the ATS or a Google Sheet. The fifth step is to measure: run the pipeline on a live batch of applications, compare the cycle time and error rate against the baseline, and document the result. If the pilot meets the metric, the firm decides whether to extend scope to additional processes or to rollout and managed operation.

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

    The 48-Hour Black Hole in Swiss Insurance Hiring

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

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

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

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

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

    The 2-Week Pilot: Audit, Build, Measure

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

    Five Concrete First Steps

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

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

    The Back-Office Bottleneck in Swiss B2B SaaS Hiring

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

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

    Fixed-Scope Pilot: What Gets Built in 3 Months

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

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

    Measuring the Baseline: Cycle Time and Error Rate

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

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

    ISO 27001 and Swiss FADP: Where the Model Runs

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

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

    Rollout Beyond the Pilot: What Changes After Month 3

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

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

  • 8-Week RAG Candidate Screening Pilot for a German E-commerce Team

    The problem: manual screening and reporting eat your HR team’s week

    You run an e-commerce or retail operation in Germany with 11 to 50 employees. Your HR and recruiting team spends 6 to 10 hours per week manually screening CVs, extracting skills and experience into a spreadsheet, and matching candidates against job postings. The monthly reporting cycle compounds the problem: you pull data from the ATS, reconcile it with the spreadsheet, and format a report for leadership, all by hand. The goal is not to replace the recruiter but to cut the manual back-office work around screening and reporting, so the team spends time on interviews and hiring decisions instead of data entry. The constraint is that candidate data is personal data under GDPR, and your ISO 27001 certification requires documented access controls and audit trails. The pilot must prove a measurable reduction in cycle time and error rate within 8 weeks, using the OpenAI API for the model layer and a custom REST API with webhooks to connect to your existing ATS and reporting tools.

    Prerequisites before week one

    Before the pilot starts, confirm the following are in place:

    • A working ATS or candidate log. Even a structured spreadsheet with columns for name, email, skills, experience, and job applied to qualifies. The pipeline needs a defined schema to write results back to.
    • A set of 10 to 30 active job postings with written competency requirements. These become the RAG index source. If your job descriptions are vague, the model will match vaguely.
    • A named data owner who can approve the data-processing agreement for the OpenAI API and sign off on the ISO 27001 security annex.
    • A 200-sample gold set of past CVs with manually verified extraction fields. This is your error-rate baseline. Without it, you cannot measure whether the pipeline is accurate.
    • API access to your ATS or reporting tool, or a willingness to expose a minimal REST endpoint. The pilot integrates through custom REST API and webhooks, not by replacing your existing system.
    • A point of contact who can approve scope changes within 48 hours. Fixed-scope means the SOW is locked after week one; slow approvals stall the timeline.

    Step 1: Run the process audit and capture the baseline

    Spend the first five business days mapping the current workflow. Have the HR team process a sample batch of 50 CVs manually and time each step: receipt, initial read, field extraction, matching against the job posting, and entry into the log. Record the cycle time in minutes per CV and the error rate by having a second person verify the extracted fields. This baseline is the denominator for every metric in the week-8 report. Simultaneously, inventory the document types you receive: PDFs, DOCX, scanned images, and email attachments. Note which fields vary by job type. The audit output is a one-page process map with timestamps and a list of the top five error categories. This document becomes the scope anchor for the pilot SOW.

    Step 2: Build the document extraction pipeline

    Build the extraction pipeline to parse incoming CVs into structured JSON. Use a document parser such as Apache Tika or a cloud OCR service for scanned PDFs, then feed the text to the OpenAI API with a system prompt that specifies the target schema: name, email, phone, skills (array), years_experience (number), education (array of objects), and job_titles (array). The prompt should include two or three few-shot examples from your gold set to anchor the output format. Log every API call with the input hash, the model version, the response, and a timestamp. Store the structured output in a staging table. The pipeline should handle a batch of 20 CVs in under 90 seconds at the OpenAI gpt-4o token rate, which is roughly 120 tokens per CV for a typical one-page document. If a CV fails to parse, flag it for manual review rather than guessing.

    Step 3: Build the RAG index over your job postings

    Index your job postings, competency matrices, and past hiring decisions into a vector store. Use a chunking strategy that keeps each job requirement as a separate chunk so the RAG retrieval can cite specific criteria. Embed the chunks with a model such as text-embedding-3-small from OpenAI and store them in a vector database like Weaviate or Qdrant running on your own infrastructure, since the job-posting data may contain internal compensation bands or hiring criteria you do not want in a third-party vector service. The RAG query flow is: take the extracted candidate profile, generate a query string, retrieve the top 5 most relevant job-requirement chunks, and pass them to the OpenAI API with a prompt that asks the model to score the match from 0 to 100 and cite which specific requirements were met or missed. The output is a JSON object with the score, the cited requirements, and a one-paragraph rationale.

    Step 4: Wire the REST API and webhooks to your ATS

    Expose three REST endpoints: POST /documents to upload a CV, GET /jobs/{id} to retrieve a job posting’s indexed criteria, and POST /results to submit the classification back to your ATS. Configure webhooks so that when the pipeline finishes processing a batch, it fires a batch.completed event to your integration layer with a payload containing the correlation ID, the list of candidate references, the average confidence score, and a link to the full output. Your ATS or integration layer acknowledges with a 200 response within 5 seconds. If it does not, the pipeline retries with exponential backoff: 10 seconds, 30 seconds, 90 seconds. After three failed retries, the record is flagged in the review queue with a webhook_failed status. The human-in-the-loop step sits here: a recruiter sees the model’s score, the cited requirements, and the raw CV side-by-side, and clicks approve or reject. Every approval or rejection is logged with the recruiter’s user ID and timestamp for the ISO 27001 audit trail.

    Step 5: Run the pilot with human-in-the-loop review

    Run the pipeline on a live batch of 50 to 100 CVs over two weeks. The recruiter reviews every classification, and you log each correction: which field was wrong, what the model said, and what the correct value was. At the end of the run, compute the error rate against the gold set and compare it to the baseline from step 1. If the error rate is above 5 percent, identify the top three error categories and adjust the extraction prompt or the RAG retrieval parameters. Common fixes: tighten the few-shot examples, add a negative constraint to the prompt (“do not infer skills that are not explicitly stated”), or increase the number of retrieved chunks from 5 to 8. Re-run the batch after each adjustment. The goal is to bring the error rate under 5 percent and the cycle time under 30 seconds per CV before the week-8 report. Document every prompt change and its effect in a change log.

  • Dedicated AI Team vs. SaaS Platform for Candidate Screening in German E-commerce

    What is being compared

    The two options are a dedicated AI team that builds a custom system on the company’s existing stack, and a SaaS platform that provides pre-built candidate screening and reporting tools. The dedicated team runs a process audit, selects one workflow for a fixed-scope pilot, and rolls out to a second workflow within three months. The SaaS platform offers a subscription service with pre-configured templates for resume parsing, candidate matching, and report generation. The dedicated team integrates with Notion and Confluence through their APIs, while the SaaS platform typically requires data export or a limited integration layer. The dedicated team uses a model-agnostic architecture, swapping between OpenAI, Anthropic, and open-weight models on the client’s hardware. The SaaS platform uses a fixed model stack, usually a single commercial API, and does not support on-premise deployment.

    Criteria for comparison

    The comparison judges against seven criteria: cycle time reduction, error rate, integration depth, model flexibility, cost structure, compliance posture, and scaling path. Cycle time reduction measures how much faster the system processes candidate applications or monthly reports compared to the manual baseline. Error rate tracks the percentage of misclassified candidates or miscalculated metrics. Integration depth assesses how tightly the system plugs into Notion, Confluence, and existing CRMs. Model flexibility evaluates whether the company can swap between commercial APIs and open-weight models on-premise. Cost structure compares fixed-scope engagement fees against per-seat SaaS subscriptions. Compliance posture checks whether the system can handle regulated data without leaving the building. Scaling path measures how easily the system extends to other departments without new hires.

    Comparison table

    Criterion Dedicated AI Team SaaS Platform
    Cycle time reduction 60-80% on candidate screening, 70-90% on monthly reporting 40-60% on candidate screening, 50-70% on monthly reporting
    Error rate 2-5% with human-in-the-loop approval 5-10% without human approval
    Integration depth Native API integration with Notion, Confluence, CRM, ERP Limited API integration, often requires data export
    Model flexibility Model-agnostic: OpenAI, Anthropic, open-weight on-premise Fixed model stack, usually one commercial API
    Cost structure EUR 25,000-40,000 per month, fixed-scope EUR 500-1,500 per month, per-seat
    Compliance posture Can deploy open-weight models on client hardware Data leaves the building, no on-premise option
    Scaling path Extends to other departments without new hires Per-seat fees scale linearly with headcount

    Scenario-by-scenario verdict

    The dedicated AI team wins when the company needs deep integration with Notion and Confluence and wants to scale across departments without new hires. A 15-person e-commerce firm in Germany that already uses Notion for job descriptions and Confluence for monthly reports benefits from a system that plugs into these tools through their APIs. The SaaS platform wins when the company wants a quick start with minimal setup and is willing to accept a fixed model stack. For a firm that processes fewer than 50 candidate applications per month, the SaaS platform’s lower upfront cost and faster deployment may justify the trade-off. However, the SaaS platform’s per-seat fees scale linearly with headcount, so the cost advantage erodes as the company grows. The dedicated team’s fixed-scope engagement does not scale with usage volume, making it more predictable for a firm planning to expand into customer support or logistics within 12 months.

    Recommendation

    The dedicated AI team fits this scenario. The company is a 15-person e-commerce firm in Germany that needs to automate candidate screening and monthly reporting within three months. The process audit identifies candidate screening as the highest-volume workflow, with a current cycle time of 4 hours per application and an error rate of 12%. The fixed-scope pilot reduces cycle time to 45 minutes and error rate to 3% with human-in-the-loop approval. The rollout to monthly reporting reduces cycle time from 8 hours to 1 hour and error rate from 8% to 2%. The system integrates with Notion and Confluence through their APIs, so the company does not replace existing tools. The model-agnostic architecture allows the company to swap between OpenAI and Anthropic APIs for drafting responses and open-weight models on-premise if data sensitivity increases. The dedicated team’s fixed-scope engagement costs EUR 30,000 per month, totaling EUR 90,000 for three months, which is higher than the SaaS platform’s EUR 1,500 per month but delivers a system that scales across departments without new hires.