Validation and AI assurance.

Requirements and risk

Keep URS, FS, DS and configuration specification (CS) records as controlled records, linked to the configuration, its risks and its tests.

Change impact

Keep changes linked to affected requirements, configuration and evidence. Record what needs verification and why existing evidence can be reused.

Automated checks

Run the selected UATs in a background simulation when a change is prepared for review. Keep results with the change under review, including failures and retests.

Connected evidence

Bring supplier evidence, automated results and human testing into the same assurance record. Trace a requirement through its checks, anomalies and review.

Release and ongoing review

Approve a defined baseline with its evidence and residual risks. Keep subsequent changes, incidents and periodic reviews connected to that accepted state.

Requirements and specifications can be kept as controlled records linked to the configuration and its tests. The user requirements specification (URS) describes what the operation needs. The functional specification (FS) describes the required behaviour; the design specification (DS) describes how it is implemented.

For a configured process, the configuration specification (CS) describes the actual fields, workflows, calculations, permissions, interfaces and approval rules.

Requirements link to the checks that verify them, so a revision and its evidence can be reviewed together. The depth of specification follows the complexity and risk of the intended use. These records can live in the platform without becoming four separate document-writing exercises.

Seal provides the platform controls and integrated assurance capabilities. Review the supplier verification and release evidence for the version in scope, then identify the process, configuration and integration checks needed for your use.

Your team owns the intended use, process requirements, risk acceptance and production approval. That includes qualification of integrations and migrated data, user procedures, training and operational readiness.

ISPE’s GAMP 5, Second Edition (2022) describes a risk-based lifecycle for GxP computerized systems. It supports iterative development, supplier involvement and automation, with expert judgment applied to the intended use. The aim is to protect patient safety, product quality and data integrity.

In Seal, requirements and specifications can be controlled records linked to the configured process and its verification. Change Sets, version history, review requirements and Checks support the cycle of proposing, testing, approving and publishing changes. Assess assurance at three boundaries:

The managed platform

Review Seal’s development, verification and release evidence for the platform version in scope. Reuse relevant supplier evidence where your assessment supports it, recording coverage and any gaps.

Your configured process

Define the intended use, requirements and failure consequences. Verify the workflows, calculations, permissions and approvals your team will rely on. Risk and complexity determine the depth of specification and testing.

Custom logic and connected systems

Assess scripts, integrations, instruments and migrated data within their actual operating boundary. Test data mappings, failure paths and reconciliation, with clear ownership of the controls outside Seal.

Software categorization follows the actual components and their use. A configurable platform does not give every script, integration or deployment the same GAMP category. Agree the scope and assurance rationale in your validation plan.

Assess each platform or configuration change against the accepted intended use, requirements and risks. Record which evidence still applies and which checks must run again. Retain failures, corrections and retests with the candidate revision; resolve or accept remaining findings before production approval.

Keep incidents, access reviews, recovery checks and periodic reviews in your operating procedures. A new intended use or a changed interface may need additional qualification. At retirement, plan how records, audit trails and signatures will remain accessible for the required retention period, and verify the export or migration.

FDA’s Computer Software Assurance (CSA) guidance (final, February 2026) addresses software used in medical-device production and quality management systems. It supports proportionate assurance activities and objective evidence, including automated and unscripted testing where appropriate to the risk.

Continuous validation describes the operating approach: assess changes, verify affected functions and retain the evidence supporting each release. GAMP 5 and CSA guide that work; your quality team still approves the intended use, assurance scope and release decision.

Under Seal’s agreements, customer data is not used to train AI models. Records retained in Seal provide working context for Neil; that is different from training the underlying model.

Neil acts with the requester’s access permissions, within their organisation, and does not grant itself further access. Required people and signatures still govern changes: a recommendation is not a released change.

Seal agrees the hosting region at onboarding and confirms the AI provider, processing location, retention and model terms for your organisation during onboarding and supplier review. The platform’s storage location and the model’s processing location are separate parts of the deployment review.

Ask us to confirm the hosting provider and region, model endpoint, subprocessors and any cross-border processing for your proposed deployment. Include backups, logs and support access in that review—not only the primary database.

Seal manages the supported model routes. The model picker selects a route operated by Seal rather than a customer-owned provider account, and available routes can change as the service is updated.

Review the terms for that endpoint, its model-change policy and any additional services receiving data. Processing and retention terms can differ between services from the same provider.

Review the data flow for the intended job: the request, retrieved record content, attachments, tool results and generated response. Agree which data classes may be processed before connecting production records.

No training does not mean zero retention. Confirm retention and deletion separately for Seal records, AI-provider requests and responses, operational logs and backups. Do not assume a single retention period covers them all.

Scope the deployment around the data you intend to use. Before sharing sensitive records, agree the permitted data classes, processing purposes, access, locations and retention with your privacy and security teams. Confirm the applicable contractual arrangements for Seal and the selected AI provider.

An initial evaluation can use sample or appropriately redacted records. Include attachments, free-text fields and retrieved context in the assessment: removing a name from the prompt does not remove identifying information elsewhere in a record.

Review the finding against its source records before relying on it. A citation helps you inspect the evidence; it does not prove the interpretation. An investigation may identify a hypothesis without establishing a cause.

For a GxP use case, define acceptable outputs, reviewer responsibilities and the actions Neil is allowed to propose. Include incomplete, conflicting and misleading source material in the evaluation. Release decisions stay with the authorised team.

Agree the evidence needed for the job: the request and requester, source records and versions, generated output, proposed or executed actions, and the reviewer’s decision. Confirm which model and configuration details are available in the deployment and how they are retained.

Preserve what supported the decision at the time. Sources can change, and a new response may differ from the original. Retain the original output and action evidence rather than relying on a later rerun or a generated explanation.

Yes. An organisation-level control disables AI features (formula inline suggestions remain available); a separate control disables generated descriptions. Scope its use to the tasks and records your team has assessed, with the required approval gates in place.

Review tenant isolation, identity and access management, encryption and key ownership, connector permissions, support access, incident response, backup recovery and data export.

See the published controls for data protection, access protection, recovery and security testing.

Retrieved documents can contain instructions that try to redirect an agent. Examine how the deployment handles this prompt-injection risk, restricts tool permissions and checks access when retrieving records or taking actions. Test attempts to expose restricted information or bypass an approval gate; a model instruction alone is not an access control.

Assess the actual deployment and its remaining risks; prompt-injection defences are not an absolute guarantee.

The European Commission’s draft Annex 22 to EU GMP sets expectations for AI models in critical GMP applications: those with direct impact on patient safety, product quality or data integrity. It was published for consultation in July 2025 and, at the time of writing, has not been adopted. It covers static models with deterministic output. It says generative AI and large language models should not be used in critical GMP applications, and that in non-critical ones qualified, trained personnel stay responsible for the output: a human in the loop.

Neil is built on large language models, so Seal treats it on those terms. Neil is not used in GMP execution. It helps set up and change configuration: workflows, limits, required fields and review gates. Your team verifies that configuration and releases it under change control, so what runs in the work is a configured rule, not model output. Neil also gathers evidence and drafts findings for investigations and reviews. A qualified person assesses them, and authorised people make the approval and disposition decisions.

For generative AI the draft says its other principles may be considered where applicable. Three carry over directly: defining the reviewer’s responsibility, keeping records of the human review, and change and configuration control. In Seal, define the reviewer’s responsibilities and what Neil may propose for each use (2.7), keep the request, sources, output and the reviewer’s decision (2.8), and assess a change of model or AI configuration like any other change (5.1). AI can be limited or switched off for the organisation (2.9).

Which uses are critical is your quality unit’s assessment for each intended use. We will revise this answer when the annex is adopted.

Scope an initial investigation around reading the records it needs. Confirm that the selected connector and credentials can enforce that scope. Treat permission to write back as a separate decision, with defined actions, review gates and audit evidence.

Review service-account access as well as user access. A connector with broad source permissions needs an explicit assessment of how those permissions are narrowed for each requester. Test revoked access and permission changes, not just successful retrieval.

Define source identifiers, field mappings, units, time zones and acceptable data freshness. Test missing or delayed records, duplicates, changed schemas and partial failures. Reconcile the transferred records against the source rather than treating a successful connection as proof of complete data.

For write-back, test retries and conflicting updates. A repeated request should not create an unintended duplicate action. Agree who resolves exceptions and how incomplete work is identified before a downstream decision relies on it.

Automation executes the defined acceptance scenarios repeatedly: calculations, required fields, permissions, approval gates and interface behaviour. Run Checks obtains results for the selected tests against the candidate under review. The risk assessment determines whether the change also needs new scenarios or additional human testing.

Your team still reviews the acceptance criteria, assesses the results and approves the intended use. A passing automated suite is evidence for that decision, not an automatic production approval. Failed checks, unresolved issues and retests remain part of the release review.

A reviewable result identifies the test version, application and configuration, environment, input data, expected and actual outcome, execution time and responsible person or automated runner. Supporting logs or records should make the outcome inspectable.

Use representative jobs with expert-reviewed acceptance criteria. For an investigation, assess source selection, factual support, missing evidence and the distinction between a hypothesis and a conclusion. For process configuration, inspect the proposed fields, calculations and gates against the approved procedure.

Include obsolete procedures, conflicting records, missing units, insufficient evidence and restricted access. Define when Neil should stop or ask for clarification. Evaluate the same cases after a relevant model or configuration change, retaining failures as well as successful examples. A general model benchmark does not establish suitability for your process.

Retain the original failure and link it to the investigation, correction and retest. Distinguish a product defect from a test-data or environment problem. An unexecuted or inconclusive check is not a pass.

The release review considers unresolved anomalies, their impact and any accepted limitation or compensating control. A later passing run should not erase the earlier evidence.

No. A proposed test is a starting point. Review its expected behaviour against the requirement, execute it in the relevant environment and retain the actual result.

For a critical function, include adverse and boundary conditions. Generating the configuration and its test from the same mistaken interpretation can make both agree while missing the requirement.

Confirm model-version availability and retirement notices for the selected provider. Do not assume a model name guarantees an unchanged version or that a provider will keep an older model available indefinitely.

Agree notification, evaluation and approval arrangements before adopting a replacement. Include changes to instructions, tools and retrieved context in the assessment, even when the model name has not changed.

Separate work that depends on the unavailable service from work that can continue under the approved procedure. Define what pauses, how people are notified and who authorises any manual alternative. An outage should not become permission to bypass a required control.

Test recovery with interrupted requests and partially completed actions. Confirm timeout, retry and reconciliation behaviour for the deployment. If an alternative model or endpoint is proposed, assess its data-processing terms and intended-use evidence before authorising the switch.

No. The impact assessment sets the scope. Reuse relevant evidence with a documented rationale and verify affected functions through regression checks, new tests or further assessment as needed.

Agree change notification, test-environment access, deployment approval and recovery arrangements for your service. Periodic review should consider changes, incidents, access, recovery evidence and whether the intended use is still current.

Inspect who created or changed a record, when it happened and the relevant version. Test required signatures, authority checks and the effect of changing an approved record. Include restricted users and attempts to act on an obsolete version.

For records within Part 11 scope, 21 CFR 11.50 requires a signed record to show the signer’s printed name, the date and time of signing and the meaning of the signature. 21 CFR 11.70 requires signatures to be linked to their records so they cannot be excised, copied or otherwise transferred to falsify a record by ordinary means.

Agree record retention, readable export, audit-trail review, backup and restoration requirements. Demonstrate that retained records and their associated context can be retrieved for the required period.

Agree an exit plan before production use: the records to export, available formats, attachments, version history, signatures and audit evidence. Test that the receiving system can preserve the meaning and relationships your team needs to review the records.

Confirm retrieval access, migration support and deletion timing, including backups and provider-held data. Distinguish closing an account from ending a record-retention obligation. These details belong in the service and data-processing arrangements, not in an assumption that an export contains everything.

No software alone makes an operation compliant. Applicability depends on the intended use, jurisdiction and records involved. Your quality system, configuration, procedures, training and ongoing controls remain part of the assessment.

Review 21 CFR Part 11 for electronic records and signatures within its scope, with FDA’s 2003 scope and application guidance, and EU GMP Annex 11 for computerised systems. For medical devices, the Quality Management System Regulation (21 CFR Part 820), effective 2 February 2026, incorporates ISO 13485:2016 by reference. These are assessment references, not software certifications.