Build a pharma SOP assistant that shows its evidence and limits

A fluent answer can still cite the wrong procedure

An employee asks how to perform a task. The assistant gives a confident answer based on an obsolete standard operating procedure (SOP) that remains in a shared folder. The response reads well, but its apparent authority exceeds the evidence behind it.

A pharma AI SOP assistant should help authorised users locate and understand approved information within a defined purpose. It should not invent operating instructions, grant task qualification or replace the site's controlled procedure and decision process.

NIST's Generative AI Profile discusses risks including confabulation, information integrity and information security. It is voluntary technical guidance, not a pharmaceutical compliance certification. NIST AI 600-1.

Define the assistant's intended use narrowly

Describe the users, document collection, questions and permitted output. “Answer anything about GMP” is too broad to evaluate. “Help authorised warehouse users find current approved receiving procedures and show the relevant sections” is more concrete.

Decide whether the assistant provides document navigation, a referenced explanation or another bounded function. Identify the actions users may take based on its output and the consequences of an incorrect answer. That assessment should inform assurance, oversight and the design of the user flow.

The AI prioritisation guide helps compare this use with simpler search or workflow improvements. If users mainly need an exact document number, a well-maintained search function may solve the problem without generated text.

Build the document scope from controlled records

Connect document identity, revision, approval state, effective dates, site, role and task applicability as relevant. A folder path is not a reliable substitute for these relationships. Copies exported from a document system can lose the metadata that makes the original meaningful.

Define how the retrieval collection updates when a document changes. The system should distinguish approved future versions, current effective versions and retained historical versions. Historical access may be needed for review, but it should not silently become the basis for a current operating answer.

The SOP training-change guide explains the related readiness implications. Finding the current procedure does not establish that the reader is qualified or authorised to perform the task.

Apply access before retrieval

Resolve the user's permitted document scope before searching or supplying context to the model. Filtering a generated answer after restricted material has already been retrieved is an incomplete access design.

Test permissions across source documents, search indexes, cached results, citations and exports. A document title or snippet can reveal restricted information even if the full file cannot be opened. The access model should cover those surfaces deliberately.

The clinical and employee data privacy guide provides a field and purpose map for information flows. Use it when documents or prompts may contain personal information, rather than assuming a private-looking interface makes every use appropriate.

Worked example: an obsolete SOP and an out-of-role request

Consider an illustrative warehouse user asking about a receiving step. The collection contains SOP R12 version 3, which is current for that site, and version 2, retained for historical review. A useful response identifies the applicable current source and provides a link to the relevant section.

Now the user asks what version 2 required during an earlier investigation period. If the user is authorised for that historical purpose, the assistant can retrieve the historical evidence with its date and status clearly labelled. It should not present that answer as today's operating instruction.

Next, the user requests a restricted laboratory procedure outside their permitted scope. The system should decline to provide unavailable content and direct the user through the approved access or expert route. It should not reveal restricted snippets while explaining why it cannot answer.

Finally, the question lacks the site or task context needed to choose between two permitted procedures. The assistant should request the necessary context or direct the user to the document owner rather than blend both procedures into a plausible new sequence.

The example shows retrieval boundaries and uncertainty handling. It does not authorise execution of a task based solely on an AI response.

Make evidence usable at the point of answer

Show the document title, identifier, revision, relevant section and applicability information needed to evaluate the answer. The citation should open the supporting evidence for the authorised user, not merely the document library homepage.

Check whether the cited passage actually supports the generated statement. A valid link can accompany an unsupported conclusion. Evaluation needs to inspect both retrieval correctness and the relationship between evidence and answer.

Where a question requires interpretation beyond the approved material, make that limitation clear and provide the responsible escalation route. The assistant should not manufacture a threshold, exception or approval simply because the user expects a complete answer.

Test abstention as a useful outcome

Include questions with no supporting source, conflicting applicable documents, obsolete terminology and requests outside the intended use. Define the expected response with the document and quality owners before testing.

Do not score every refusal as failure. A well-placed abstention protects the boundary of the intended use. Equally, excessive refusal on straightforward permitted questions may make the tool impractical and should be investigated.

Treat retrieved content as evidence, not software authority

Documents and attachments can contain text that looks like instructions to the assistant. The application should treat that material as content to retrieve and assess, not as permission to change its access rules or perform unrelated actions.

Evaluate direct and indirect prompt-injection scenarios in an authorised test environment. Include a document containing instructions to ignore restrictions and a user asking the assistant to disclose hidden material. Keep the tool's capabilities limited to its approved purpose so a misleading answer cannot automatically change operational records.

Assign security and document owners to review failures. Correcting a prompt may help one example, but the team should assess whether the underlying access, retrieval or tool design needs improvement.

Govern changes to the whole system

The assistant's behaviour depends on the model, prompts, retrieval logic, document processing, permissions and source collection. A change to any of these can affect performance. Retain enough configuration information to understand what version was evaluated and deployed.

Define an appropriate evaluation set and repeat the relevant checks when changes occur. Include newly introduced document types and known difficult cases. Supplier model updates should be assessed through the agreed lifecycle process rather than accepted solely because the service remains available.

Review user feedback with source evidence. A thumbs-up is useful product feedback, but it does not establish technical correctness. Document owners should inspect material failures and decide the appropriate correction or escalation.

Pilot with measurable limits

Choose one document family and user group. Compare time to find the correct evidence, citation support, inappropriate disclosure, useful abstention and recurring question gaps against the existing search process.

Keep the pilot's intended use visible in the design and training. Expand only when the organisation can maintain the source scope, explain the evaluation results and operate the exception process. NextEdge Labs can support that bounded retrieval and evaluation workflow with the site's document, quality and IT owners.

Summary and next actions

An SOP assistant is useful when it retrieves the right permitted evidence and recognises the limits of that evidence. Fluency should never substitute for version control, applicability or authorised judgement.

• Define one user group, document family and permitted question set for the pilot.
• Connect current versions, applicability and permissions before building retrieval.
• Test supported answers, obsolete sources, restricted content, ambiguity and prompt injection.
• Assign owners for document updates, evaluation, incidents and expansion decisions.