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.
Leave a Reply