Disclosure and Barring Service Barring Referral AI Summary Tool
AI generated summary of a Barring referral which pulls through the key headlines with citations linked to source material to assist caseworkers in navigating and orienting through the referral documents/evidence.
1. Summary
1 - Name
Barring Referral AI Summary Tool
2 - Description
The tool is an AI generated summary of a Barring referral to assist caseworkers with navigating through the referral. The AI summarisation tool is designed to enhance not replace the current case evidence review process. At present caseworkers have to manually sift through large volumes of unstructured evidence. The summarisation capability is an automated support tool that generates a concise summary of the referral with citations to assist caseworkers with navigating through the referral evidence, helping to reduce review time and highlight key information. The original evidence remains the authoratitive source of truth and caseworkers retain full responsibility for decisions. The change is required to improve effeciency, consistency and scalability in handling growing volumes of case evidence, while maintaining compliance with legal and governance standards.
3 - Website URL
N/A
4 - Contact email
Disclosure and Barring Service- Barring Referral Service Team. customerservices@dbs.gov.uk
Tier 2 - Owner and Responsibility
1.1 - Organisation or department
Disclosure and Barring Service
1.2 - Team
Barring Referral Service Team
1.3 - Senior responsible owner
Acting Associate Director of DDaT, Security and Data Protection
1.4 - Third party involvement
Yes
1.4.1 - Third party
Reply
1.4.2 - Companies House Number
03847202
1.4.3 - Third party role
Leading on the development, delivery and maintenance of the tool.
1.4.4 - Procurement procedure type
Reply were the existing technical provider on the Barring Referral Service
1.4.5 - Third party data access terms
Access to sensitive data is restricted and only DBS staff can see this. Case workers will receive the output without the engineers visibilty over the data. Should there be exceptional circumstances where the engineer (Reply) needs to view/handle the sensitive data then this will be treated as a controlled exception, with explicit approval, time bound access and full audit (adhearing to the current Barring Referral Service process for Exceptional Access)
Tier 2 - Description and Rationale
2.1 - Detailed description
Foundation LLMs which generates a summary of the Barring Referral (the tool creates the summary using all evidence documents from the referral). Purpose- to provide Triage caseworkers with a consistent standardised AI generated summary of the barring referral, which includes headline evidence extracts and the relevent citations from the referral to assist the caseworker with the navigating through the referral evidence and documents. The users will be Triage caseworkers initially upon receving the referral and the managers, Information Gathering team, Appeal and Quality Assurance teams will also have access to the summary. Out of scope- the tool will not be making any automated decisions, the Triage caseworkers still review the evidence and make all decisions as before. The tool does not replace human judgement, review or decisions.
2.2 - Benefits
Time saving- reduced case orientation and evidence review time, as well as reduced narrative draft time. Reduced cognitive load for caseworkers. Increased consistency and accurate summaries (standardised summaries across triage, transparent citations, and evidence extracts- traceable audit trail for all decisions, lowering QA bounce back rate)
2.3 - Previous process
Previous process is highly manual and document heavy. Caseworkers navigate multiple systems and have to sift through large volumes of unstructured evidence. Stage 1: case intake, stage 2: initial review of referral, stage 3: evidence sift and checks, stage 4: draft decision rationale, stage 5: information gathering, stage 6: QA and sign off.The new process follows the same steps and the caseworker still reviews the evidence, drafts the rationale and makes the decisions (there are no automated decisions), the AI summary just as acts as a navigational entry point to the case upon initial review of the referral, helping guide through the evidence more effeciently.
2.4 - Alternatives considered
The AI summary will help assist caseworkers with navigating through high volumes of unstructured and fragmented referral evidence, in a more time effecient way to help meet the demands of an increasing workload by reducing the time taken to navigate through the referral and review evidence documents. AWS is the chosen cloud platform for DBS and LLMs selected based on LLM Selection and Evaluation process approved by DBS Digital Design Group, the selection process includes metrics such as performance, cost, accuracy, context window, modality, residency, ease of integration and suitability.
Tier 2 - Deployment Context
3.1 - Integration into broader operational process
The tool’s output provides a summary of key referral information to inform/support triage caseworkers. The AI summary will be automatically attached to the case in the caseworker system when the caseworker opens the case for the first time, for cases that come in via Barring Referral Service (digital portal) only. The information provided by the tool includes key information ie addresses, dates, key criteria along with citations for the information source. The information is then used to guide caseworkers to finding information in documents quicker and getting a clearer overview of the case in a shorter time. The caseworker still drafts decision rationale on the case as before- they input this into a separate tab in the caseworker system as before, the AI summary will not be making any decisions, it is there to increase the effeciency of caseworkers navigating through the case.
3.2 - Human review
A caseworker reviews the output when it is provided to them as a PDF summary, using the citations to validate the information against the source documents. The caseworker must review the AI-generated summary against the original referral evidence. Citations are provided for each key statement to enable validation against source documents. The AI output cannot be used as the sole basis for any case assessment, recommendation or barring-related decision. Any inaccuracies identified by users are reported through established operational feedback channels and quality assurance processes
3.3 - Frequency and scale of usage
The tool is to be used by the full triage team (~16) for all of their cases. They recieve approx 1,200 cases per month
3.4 - Required training
Understanding how the pdf should be used as a supporting document only and how to cross reference citations. Required controls include user training, guidance, quality checks, escalation routes, periodic assurance and training and awareness of internal policies on appropriate use and governance of AI. Training includes recognising the limitations of generative AI, understanding risks of automation bias, verifying outputs against source documents and reporting suspected inaccuracies. The controls show that staff use AI generated summaries only as support and not as a substitute for caseworker judgement or human review. Guidance documents across the Triage Team and wider Barring Operations teams are provided with guidance on how to use the AI summaries correctly.
3.5 - Appeals and review
The tool is not making any decisions. It is there to support the DBS case workers. The existing DBS appeals process applies.
https://www.gov.uk/government/publications/dbs-barring-appeals/dbs-barring-appeals
Tier 2 - Tool Specification
4.1.1 - System architecture
The solution is designed to ingest, understand, index, summarise documents, generate structured PDF summary. Core Components: Referral AI Summary Orchestrator: AWS Step function that coordinates Document Ingestion, Summary Generation and Pdf Generation
Document Ingestion AWS Lambda: Prepares validated documents for AI processing, including text extraction, image transcribing and content metadata.
Amazon Textract: Extracts structured data such as forms and tables from uploaded documents.
Bedrock Foundation Models: Provide AI capabilities including document classification, image description, embedding generation, and language reasoning.
Embedding Model (Titan Embed): Converts document content and prompts into vector embeddings for semantic search.
Amazon OpenSearch: Stores document embeddings and metadata, enabling hybrid semantic and keyword search.
Summary Generation Lambda: Builds prompts, retrieves relevant context, invokes the LLM, and enforces schema-validated structured outputs.
PDF Generation Lambda: Renders structured JSON summaries into HTML templates and converts them into final PDF documents stored in BRS clean bucket.
4.1.2 - System-level input
Referral documents submitted via the Barring Referral Service portal.
4.1.3 - System-level output
PDF Summary
4.1.4 - Maintenance
We are not training the model so it won’t require retraining. We have a process in place for updating the model should the LLM need changing. This will be regularly reviewed. LLM model upgrade process has been established and signed off and will be adhered by the Barring Referral Service. We are ahdering to wider govt standards (e.g Govt AI playbook). Any model upgrades or significant changes are subject to testing, assurance and governance approval prior to deployment.
4.1.5 - Models
OpenAI GPT OSS 120B, Nvidia nemotron nano 12b, Amazon Titan Embedding v2
Tier 2 - Model Specification
4.2.1. - Model name
OpenAI GPT OSS 120B, Nvidia nemotron nano 12b, Amazon Titan Embedding v2. All models are pre-trained and hosted on AWS Bedrock.
4.2.2 - Model version
openai.gpt-oss-120b-1:0, nvidia.nemotron-nano-12b-v2, Amazon Titan Embedding v2. All models are pre-trained and hosted on AWS bedrock
4.2.3 - Model task
openai.gpt-oss-120b-1:0 - text completions, nvidia.nemotron-nano-12b-v2 - image captioning, Amazon Titan Embedding v2 - Embeddings generation
4.2.4 - Model input
Referral evidence documents used by the DBS Barring Referral Service as supplementary documents to make an informed decision on a case.
4.2.5 - Model output
Extracted case information
4.2.6 - Model architecture
We are using a pre-trained (foundation) AWS bedrock models, hosted and managed by AWS. None of the models are being optimised / trained.
4.2.7 - Model performance
We are using a pre-trained AWS bedrock model hosted and managed by AWS.
We have undertaken user validation and testing in Alpha and Private Beta phases where case-worker output has been compared and contrasted - where one worker has access to the summary and the other hasn’t. This has been used to evaluate the quality of the supplied output in assisting the case workers to complete their activities. The metrics used for measuring the performance are: Effeciency (average case triage time saved, case triage range), Quality Critical field accuracy, Auditability (citation accuracy), overall accuracy, Ethics and Equality (bias flags, equality concerns, neutral tone) and Cognitive load (caseworker ease of use). Results against the metrics have been recorded and documented throughout the testing phases. Evaluation demonstrated that AI-generated summaries supported faster case orientation while maintaining traceability through citations. Quality testing assessed accuracy of critical fields, citation grounding and completeness.
4.2.8 - Datasets and their purposes
Pre trained (foundation) models only. None of the data has been used to train / optimise / refine the models. Instead, we have performed QA testing of the overarching service, utilising a selection of fabricated data, redacted caseworker training cases and production cases. The data has been used for RAG ingestion and validation of prompt engineering only.
2.4.3. Development Data
4.3.1 - Development data description
Testing has used a combination of fabricated case data, 15 redacted and anonymised training cases and approx 140 cases of production data. None of the data is being used to train / optimise / refine the used foundation models.
4.3.2 - Data modality
Text (word, excel, CSV, PDF, Web Form, etc.); and Images.
4.3.3 - Data quantities
For validation/testing. Fabricated data was used in the discovery phase. Alpha phase- 15 anonymised redacted training cases (max 60 pages in each training case). Private Beta, approx 140 production cases
4.3.4 - Sensitive attributes
Yes Personally Identifiable Information (PII data) / Special Category Data has been used in the Private Beta phase for validation and has been used in line with the approved Data Protection Impact Assessment (DPIA). Attributes are dealt with using Retrieval-Augmented Generation (RAG) integration model where the Large Language Model (LLMs) are used to query the data using pre-configured / hard-coded prompts. This data is not used to train the models.
4.3.5 - Data completeness and representativeness
Initial test data was fabricated and provided only a limited representational coverage in the discovery phase. In the Alpha phase the 15 anonymised training cases were reduced in size compared to a production case but covered a wide range of cases as approved by the Operations team. Private Beta test data is fully representative in terms of style, being live data. Representation in regards to variety depended on the submissions during this period. Testing included assessment of cases containing information relating to protected characteristics to identify any unintended bias or unequal treatment in generated summaries. When considering completeness of the private beta test data, any missing data is a helpful test case ensuring that the model identifies the gap rather than hallucinating a filler response, consequently all scenarios should be met throughout the testing in Private Beta. All outputs are produced using a Retrieval- Augmented Generation (RAG) approach, where the model answers a predefined set of questions using only the evidence snippets supplied in the prompt. The solution also uses Bedrock automated reasoning checks to validate that each response logically follows from the available evidence, and contextual grounding checks to ensure that generated answers remain anchored to the retrieval context and do not introduce unsupported information.
4.3.6 - Data cleaning
N/A. Test data is not cleaned/pre-processed. To note: some of the Regular Expressions (character set on what you are allowed to use) are changed to match back end system restrictions, the full answer is incorporated in the PDF which is incorprated into the AI summary
4.3.7 - Data collection
Test data was either purpose fabricated, repurposed from caseworker training examples or using production case submissions. The training examples were suitable as they met the required formats, show real scenarios and have redacted/reforrmated no PII to reduce security risk. Production cases are suitable for testing as they are exactly what we will require to work when the tool is productionised.
4.3.8 - Data access and storage
Access to sensitive data is restricted and only DBS staff can see this. Case workers will recieve the output without the engineers visibilty over the data. Should there be exceptional circumstances where the engineer (Reply) needs to view/handle the sensitive data then this will be treated as a controlled exception, with explicit approval, time bound access and full audit (adhearing to the current BRS process for Exceptional Access)
4.3.9 - Data sharing agreements
Supplier (Reply) have access to the development data (e.g code) but they are required to follow an exceptional access process (as per above) for production data
Tier 2 - Operational Data Specification
4.4.1 - Data sources
User referrals via Barring Referral Service (digital portal)
4.4.2 - Sensitive attributes
PII / Special Category data is provided as context to the LLM. PII data will be handled in line with the approved DPIA. The data is processed solely for generation of summaries relating to the specific referral and is not used to train, fine-tune or improve foundation models.
4.4.3 - Data processing methods
No pre-processing is performed.
4.4.4 - Data access and storage
Upon submission, data is stored within private S3 Buckets with restricted Identity and Access Management (IAM) permissions and Multi Factor Authentication (MFA). This is encrypted at rest and can only be accessed within tight networking restrictions. Access to sensitive data is restricted so only DBS staff can see this. Case workers will recieve the output without the engineers visibilty over the data. Should there be exceptional circumstances where the engineer (Reply) needs to view/handle the sensitive data then this will be treated as a controlled exception, with explicit approval, time bound access and full audit (adhearing to the current BRS process for Exceptional Access). Referral evidence, generated summaries, audit logs and supporting records are retained in accordance with DBS retention and records management policies. System logs capture processing activity, user access and audit information. Access is restricted according to role-based permissions and monitored through established security controls.
4.4.5 - Data sharing agreements
Supplier (Reply) are required to follow an exceptional access process (as per above) for production data
Tier 2 - Risks, Mitigations and Impact Assessments
5.1 - Impact assessments
The Data Protection Impact Assessment (DPIA) was approved on 07/05/26 following delegated DPO review, with all minor issues resolved and the remaining data-protection risks within DBS’s risk tolerance. The assessment confirms that the tool supports, but does not replace, human review or make automated barring decisions. Key risks relating to accuracy, fairness, inappropriate reliance on AI outputs, supplier or model changes, and legal compliance are managed through human oversight, quality and fairness testing, controlled model changes, UK-hosted processing, restricted access and ongoing review. The DPIA will be reviewed every 12 months due to the evolving AI risk and compliance landscape. Equality Impact Assessment assessed impact on protected groups and identified no disproportionate adverse impact in Private Beta testing. Security assessments were completed as part of the DBS technical assurance and accreditation process.
5.2 - Risks and mitigations
Risk: Bias - Summaries could unintentionally reflect bias or create unequal outcomes.
Mitigation: thorough bias testing and evaluation to evaluate system bias and its effects, equality assessment, neutral prompt design, human review and the fact that decisions remain entirely with DBS staff. Outcome is only used to support navigating the evidence and final decisions are made by the caseworkers’ analysis of the case documents themselves.
Relevant principles: Transparency - Metadata-linked and per-document approach ensures that there is a clear trail as to what source material the LLM used to generate its response.
Risk: Hallucinations or inaccuracies - The AI summary may contain inaccuracies, omissions or unsupported conclusions.
Mitigation: Citations, grounding controls, bedrock reasoning checks, mandatory human verification and QA sampling.
Risk: User over reliance - Caseworkers may place undue reliance on AI generated summaries.
Mitigation: Training, guidance, mandatory review of source material, management oversight and quality assurance processes.
Risk: Data Protection related risks
Mitigation: Data Protection Impact Assessment, secure systems, trained staff, operated in accordance with internal policies and AI playbook.
Risk: Model drift or supplier changes - Changes in model behaviour following supplier or model updates.
Mitigation: Controlled change management process, regression testing and governance approval.
We maintain granular audit logs of all AI outputs, support human-in-the-loop review before acting on AI summaries and have enabled error isolation (if one document is corrupted, processing others should continue unaffected) to improve overall traceability, accuracy and accountability. The model is assessed on a regular basis to identify any changes in performance, behaviour or output quality over time. This includes reviews of generated outputs, grounding accuracy, consistency against expected answers, and any user feedback or flagged issues.