Work Instruction: Operating an LLM-Assisted GxP Screening Tool with a Human Checkpoint

This is a ready-to-use work instruction for the person who operates an AI screening tool in a regulated workflow, for example a tool that flags audit trail anomalies, checks documents for gaps, or triages deviations. The tool screens; a qualified human decides. This instruction makes that division real at the task level, including what to do when the model returns garbage, times out, or is unavailable, and when to stop using the tool. Replace every <<FILL: ...>> placeholder and run it under its parent SOP and validation. A filled specimen follows. This content is educational reference, not legal or regulatory advice; adapt it to your validated tool and quality system.

Control header

Before you start

• Confirm the tool is in its validated state: the pinned model identifier and prompt version above match what is deployed. If either differs, stop and route to <<FILL: role>>; a changed model or prompt is a change, not a task.
• Confirm you are an authorized user with the training on record for <<FILL: WI-ID>>.
• Confirm the input source is the controlled location, not a local copy.

Procedure

Step 1, Pull the inputs from a controlled source

Retrieve the documents or records to be screened from <<FILL: controlled source, e.g. the document control register, the validated audit trail export>>, so the version screened is the effective one.

• Acceptance: every input is traceable to a controlled source and its version is recorded.

Step 2, Invoke the tool

Run the tool on the inputs. The tool sends each item to the pinned model with the controlled prompt and requests a structured (schema-defined) answer, and logs the call per <<FILL: call log, e.g. FRM-QA-...>>.

• Acceptance: each call is logged with input reference, prompt version, model identifier, timestamp, and user context.

Step 3, Let the code validate the output, not you

The tool validates each model output against its schema and performs the deterministic checks (exact-match version comparison, numeric checks, joins against the user roster or maintenance calendar) in code, never in the model.

• Acceptance: output that fails schema validation is not shown as a flag; it is routed to the exception path in Step 6. No numeric or exact-match decision is taken from model free text.

Step 4, Review the flags

For each flag the tool presents, review it as a question, not a verdict. Open the cited source (the specific clause, the audit trail entry, the deviation) and confirm what the flag claims against the evidence.

• Acceptance: every flag is dispositioned against its cited source, not accepted on the tool’s say-so.

Step 5, Record your disposition with a reason

Confirm or override each flag and record the disposition with a reason. Overriding must be as easy as accepting; a reason is required either way.

• Acceptance: each flag has a disposition (confirm / override / needs investigation) and a reason; confirmed items that indicate a real problem are routed to the quality system per the parent SOP.

Step 6, Handle the negative paths

Do not guess when the tool cannot give a clean answer. Follow the path for the condition:

• Malformed / schema-invalid output: route the item to manual review; do not infer intent from broken output.
• Model timeout or unavailable: retry per <<FILL: retry policy>>; if still failing, complete the item manually and note the tool was unavailable.
• Low-confidence or ambiguous flag: treat as needs-investigation, not a pass.
• Acceptance: no item is silently passed because the tool failed; the failure and the manual handling are recorded.

Step 7, Watch for the off-switch conditions

Stop using the tool and notify <<FILL: role>> if any documented off-switch condition is met: the override rate breaches its threshold, the periodic held-out test set degrades, a model or prompt change has not been assessed, or the tool is producing output the review cannot reliably catch.

• Acceptance: an off-switch condition triggers a stop and a notification, not a workaround.

Roles

Records generated

• The per-call log (Step 2), retained per <<FILL: retention>>.
• The flag dispositions with reasons (Step 5).
• Any exception or unavailable-tool note (Step 6).

References

Parent SOP <<FILL: SOP-ID>> and the tool’s validation summary <<FILL: report ID>>. 21 CFR Part 11 (electronic records) and the predicate rule for the activity. FDA guidance, Computer Software Assurance for Production and Quality Management System Software. FDA and EMA, Guiding Principles of Good AI Practice in Drug Development (January 2026), for context of use and lifecycle management.

Confirm the current version of each reference before use.

Filled specimen

An operator runs a document gap-analysis screen on 40 batch records before a campaign closeout. Illustrative only.

The operator spent the session on 18 flags and 3 exceptions instead of 480 manual lookups, and every disposition is reconstructable from the call log and the recorded reasons. The tool screened; the operator decided; the decisions are documented. That is the whole pattern.

Common mistakes this work instruction prevents

• Accepting a flag without opening the cited source, so the human review is a rubber stamp.
• Letting the model do the version comparison or the arithmetic instead of the code.
• Silently passing an item when the model timed out or returned malformed output.
• Running the tool after a model or prompt change that was never assessed.
• No defined stop condition, so a drifting tool keeps running.

How to adapt this work instruction

1. Set the parent SOP, tool ID, pinned model, and prompt version in the header.
2. Name your controlled input source, retry policy, and off-switch conditions in the steps.
3. Point the records section at your real per-call log and disposition records.
4. Keep the human-disposition-with-reason step mandatory; it is the control of record, not the model.