Most GxP findings that look technical are actually accountability failures. A validation package approved by someone without the standing to approve it. A change implemented because everyone assumed someone else had assessed it. A system with no named owner, so nobody ran the periodic review. The controls existed; it was unclear who owned them.
This guide sets out the roles a GxP system depends on, what each is genuinely accountable for, why separation of duties is a regulatory requirement rather than a courtesy, and the handover gaps that produce findings.
The core roles
Process owner
Owns the business process the system supports, and therefore owns the requirements. Accountable for defining what the system must do, confirming during qualification that it does, and owning the SOPs describing how people use it. This is the role most often left vacant or delegated to IT — and when that happens, requirements get written by people who do not perform the work, which shows up later as user acceptance testing that passes while the process fails.
System owner
Owns the system as an asset through its life: configuration, access management, backup and restore, supplier relationship, upgrade planning, periodic review. Distinct from the process owner. One system can serve several processes, each with its own process owner, but there is exactly one system owner.
Quality Assurance
Approves the validation approach and its conclusion, and holds the authority to say a system is not fit for GxP use. QA approval is not administrative sign-off — it is an independent judgment that the evidence supports the claim. QA must be organisationally independent of the people who built or configured the system.
IT / infrastructure
Accountable for the technical environment: servers, network, security patching, backup execution, disaster recovery, infrastructure qualification. Note the boundary — IT is accountable for backups running, the system owner is accountable for restore having been tested and proven.
Validation lead
Plans and coordinates the validation effort, authors or oversees the deliverables, and maintains traceability from requirement through risk to test and result. Often external. This does not transfer accountability: the process owner still owns the requirements and QA still owns the approval, regardless of who wrote the documents.
Supplier
Provides the system and, where qualified, supporting evidence you may leverage. The supplier holds no GxP accountability for your use of their product. You may use their test evidence, but you own the decision to rely on it — the subject of supplier qualification.
Who signs what
- User requirements — authored by the process owner, approved by process owner and QA. IT contributes technical constraints but does not own it.
- Risk assessment — authored jointly, approved by process owner, system owner and QA. See GxP risk assessment.
- Validation plan — authored by the validation lead, approved by QA.
- Test protocols — approved before execution. Approving a protocol after the testing has been performed is a finding, and a common one.
- Executed tests — performed by a competent tester who is not the person who wrote the code or configuration under test.
- Deviations during testing — assessed and approved by QA, not closed informally by the test team.
- Validation summary report — approved by process owner, system owner and QA. This is the document that declares the system fit for GxP use.
- Change requests — assessed by system owner and process owner, approved by QA where GxP impact exists.
The governing principle: whoever performed the work cannot be the sole approver of it. This is what separation of duties means in practice, and it is why administrator access held by the person performing the regulated activity is a recurring inspection finding.
Where AI changes the picture
Introducing AI into validation or quality work does not create a new approver and does not remove an existing one. Under EU GMP Annex 22 the position is explicit: a person remains accountable for GxP-critical decisions. AI can draft, propose, classify and summarise. It cannot hold an approval.
What does change is the competency required of the reviewer. Approving a document a colleague drafted and approving one a system drafted are different cognitive tasks — the second requires the reviewer to know the system's failure modes, not just the subject matter. That is a training obligation, covered in updating SOPs and training for AI.
Your RACI should therefore stay structurally the same when you adopt GxP AI. If a proposed workflow removes a human approval step, that is a compliance problem rather than an efficiency gain.
The gaps that cause findings
- No named system owner. Periodic reviews lapse, supplier updates arrive unassessed, and access lists go stale. The most consequential single gap on this list.
- Process owner role filled by IT. Produces requirements that describe the software rather than the work.
- Role held by a person, not a position. When that person leaves, the accountability leaves with them. Define roles by position in the SOP and maintain a current assignment record.
- QA approving without independence. A QA reviewer who reports to the project sponsor is not independent, whatever the org chart says.
- Outsourced validation treated as outsourced accountability. A consultant can author every deliverable. You still own the outcome, and the inspector will ask your staff, not theirs.
- No handover at role change. Ownership transfers should be documented events with an explicit acceptance, not implied by a reporting-line update.
A simple test: pick any GxP system and ask three people who owns it. If you get three answers, you have found the gap before an auditor does.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.