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

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

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

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

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

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

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

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

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

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

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

6. The synthesis: measurement is the product

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