Annual Product Quality Review: Using AI to Compile APQR Evidence

Every year, somewhere between October and March, a quality assurance team in a mid-size European manufacturing site assembles a document nobody wants to write and every inspector wants to read. The Annual Product Quality Review — or Product Quality Review (PQR) in EU GMP parlance — is required by EU GMP Part I, Chapter 1.10 and, for APIs, by ICH Q7 Section 2.5. In the US it appears as the Annual Product Review under 21 CFR 211.180(e). The scope is broad by design: starting materials, in-process controls, critical deviations, OOS results, changes, stability trends, returns, complaints, recalls, technical agreements, and the qualification status of equipment and utilities.

The regulatory expectation is clear. The operational reality is that most APQRs are compiled by a validation or QA specialist copying numbers out of LIMS exports, chasing batch records, reconciling deviation numbers against the QMS, and re-reading last year's report to work out which commitments were actually closed. For a CDMO producing forty products across three dosage forms, this consumes months of qualified headcount. And the compilation effort crowds out the part regulators actually care about: the evaluation.

Why APQR Compilation Is an Evidence Retrieval Problem

Strip the APQR down and it is a structured evidence retrieval exercise followed by a trend assessment. Chapter 1.10 lists eleven categories of input. Each category requires pulling records from a different system — ERP for starting material batches, LIMS for release testing, the deviation module of the QMS, the change control register, the stability database, the complaint log. In a typical DACH mid-size manufacturer these are rarely a single integrated platform. Even where an MES exists, it does not hold the technical agreement review status or the marketing authorisation variation history.

The specialist compiling the APQR is therefore performing dozens of searches across heterogeneous sources, each with its own naming conventions. That is precisely the problem retrieval-augmented generation solves — provided the retrieval layer is governed as a GxP system rather than deployed as a convenience tool.

An AI assistant does not write your APQR. It finds, cites, and cross-references the evidence so your qualified reviewer spends their time on evaluation and conclusion, which is where the regulatory value sits.

Where AI Retrieval Adds Real Value

Based on how QA teams actually use a GxP-aware assistant during APQR season, the highest-value applications are narrow and well-defined:

• Deviation and CAPA cross-referencing. "List all deviations raised for Product X between 01.01 and 31.12, grouped by root cause category, with the associated CAPA status." The assistant returns sourced records with document IDs, so the reviewer can verify each one rather than trusting an aggregate.
• Prior-year commitment tracking. The most commonly cited APQR finding in EU inspections is failure to follow up on actions identified in the previous review. Querying last year's APQR text against this year's change control and CAPA records surfaces open commitments in minutes.
• Change control impact mapping. Identifying which approved changes in the review period touched the product's manufacturing process, specification, or supply chain — and whether a corresponding variation was filed.
• Technical agreement currency. For CDMOs, Chapter 1.10(xi) requires review of technical agreements to ensure they remain up to date. An assistant indexed on the agreement corpus can flag agreements with expired review dates or scope misalignment against current product registrations.
• Specification and method version history. Confirming which specification version was in force for each batch released during the period — a frequent source of inconsistency in manually compiled reviews.

Notice what is absent from this list: calculating process capability indices, generating trend charts, or drawing conclusions about process performance. Those remain the responsibility of validated statistical tools and qualified personnel. The AI layer handles document and record retrieval with source traceability, which is exactly what GAMP5 Second Edition would place in a lower risk band when the output is human-verified against cited sources.

Validation Positioning Under GAMP5 and Annex 11

The intended use statement matters enormously here. If you define the assistant's intended use as "retrieve and cite source records to support APQR compilation, with all retrieved evidence verified by the qualified reviewer against the cited source," you have a system whose failure mode is a missed or irrelevant retrieval — detectable by the reviewer and not directly product-impacting.

If instead you define it as "generate APQR trend conclusions," you have assumed a far heavier validation burden and a much worse position in front of an inspector.

Practical requirements under EU GMP Annex 11:

• Annex 11 §4 — validation proportionate to risk. Document retrieval test cases should cover known-answer queries across each APQR input category, including negative tests where the record does not exist.
• Annex 11 §9 — audit trail. Every query, the documents retrieved, the version of each document, the response, and the user identity must be logged. During an APQR inspection, the ability to show how a figure was located is as valuable as the figure itself.
• Annex 11 §7 — data storage and accuracy checks. Where the assistant indexes exported data rather than live systems, the export and ingestion process requires its own verification and a defined refresh frequency.
• 21 CFR Part 11 §11.10(a) — the ability to discern invalid or altered records. Retrieval must be version-aware: an assistant that returns a superseded specification without flagging its status creates a data integrity exposure.

The Superseded Document Trap

This deserves emphasis because it is the single most common failure mode we see in APQR retrieval. A review period spanning twelve months may include three versions of a given SOP or specification. A naive RAG system indexes all three and returns whichever chunk scores highest on semantic similarity — often the oldest, because older documents accumulate more indexed content.

A GxP-aware system treats document status and effective dates as first-class retrieval metadata. When a reviewer asks about batches released in March, the system must scope retrieval to the specification version effective in March, and say so explicitly in the citation. Anything less produces an APQR with internally inconsistent evidence — a finding waiting to happen.

EU AI Act Considerations

An APQR support assistant used in this configuration is not a high-risk AI system under the EU AI Act. It is not a safety component of a product and does not make autonomous decisions affecting health. However, since general-purpose AI model obligations and the broader transparency provisions came into application, DACH QA teams should maintain documented evidence of: the model and provider used, the transparency notice informing reviewers they are interacting with an AI system, and the AI literacy training required under Article 4 for personnel operating the tool. These artefacts sit naturally alongside your Annex 11 validation file.

What Changes in Practice

Teams that deploy retrieval support for APQR typically report the compilation phase compressing from weeks to days — not because the AI writes anything, but because the reviewer stops hunting for records. The time released goes into trend evaluation, comparison against prior periods, and drafting defensible conclusions about process consistency and the adequacy of existing specifications. That is the part of Chapter 1.10 that inspectors actually probe.

The APQR will never be automated. It should not be. But the evidence-gathering underneath it is mechanical work that qualified people should not be doing by hand.

See how ComplianceGxP handles Annual Product Quality Review evidence compilation for pharma and CDMO teams: See how it works →