S4.03 - User_role_operator_role

S4.03 ? User role / operator role

flowchart LR
    A[Background: Human oversight often asserted but not evidenced at role level] --> B[RAIDT: Run-level evidence framework]
    B --> C[[User role / operator role]]
    C --> D[Evidence pack]
    C --> E[RAIDT score profile]
    C --> F[Reviewer reconstruction]
    D --> G[Reviewability and contestability]
    E --> H[Governance readiness]
    I[Role taxonomy]
    J[Initiator role]
    K[Reviewer role]
    L[Authorisation level]
    M[Escalation route]
    I --> C
    J --> C
    K --> C
    L --> C
    M --> C

? Star S4 - Evidence Architecture and Artefacts

Star context: Specifies the concrete fields and artefacts that make a run record inspectable, including who acted in the run at the level of organisational role rather than unnecessary personal exposure.

Academic picture

Definition / background

User role / operator role records the organisational function of the person who initiates, oversees, reviews, or otherwise materially shapes a GenAI run. In RAIDT terms, this is not primarily an identity field. It is a governance field that captures the authorised position from which the run was undertaken, for example clinician, fraud analyst, contact-centre adviser, procurement officer, or senior reviewer.

Conceptually, this item sits between access control, accountability design, and evidential traceability. Traditional system logs often record a username or device event, while policy documents speak in general terms about human responsibility. RAIDT requires something more operational: a run-level record that shows what kind of actor was involved and why that role matters for interpreting the run. This helps distinguish a permitted operational user from a reviewer, approver, auditor, or escalation authority.

This distinction matters because role is not the same as name, identity, or job title. A named individual may change posts, a job title may be too broad, and a system account may hide the human context entirely. Role, by contrast, captures the governance-relevant function attached to the run. In many settings, this is the right level of abstraction for balancing privacy, proportionality, and accountability.

Within RAIDT, the item belongs in Evidence Architecture and Artefacts because it is part of the minimum evidential structure needed to inspect a run after the event. It contributes to the run-level evidence pack by showing who was allowed to act in the workflow, and it supports the RAIDT score profile by strengthening evidence for Responsibility, Auditability, and Traceability. It also helps interpret whether the output was used in a context requiring specialist judgement, review, or escalation.

Why this concept matters

Organisations often say that a human remains responsible for AI-assisted work, but that claim is weak unless the run record shows what role that human occupied. Without this item, it becomes harder to determine whether a run was initiated by an appropriate actor, whether a review step was performed by someone with the right authority, or whether a contested output can be traced back to the correct decision-making layer.

The concept also avoids a common governance error: conflating privacy-preserving evidence with absent evidence. RAIDT does not require every run to expose personally identifying information to every reviewer. Instead, it requires enough structured evidence to show the organisational role that framed the run. That is often sufficient for audit, challenge, and process improvement, especially when combined with internal identity systems under controlled access.

If this item is missing, responsibility can collapse into vague institutional language such as "the team used the model" or "the system generated the draft". That weakens post-hoc review, obscures role boundaries, and makes it more difficult to improve training, controls, or escalation design. By contrast, recording role at run level helps move governance from principle statements toward operational accountability.

Key idea: User role / operator role matters because RAIDT needs evidence of who functionally acted in a run, not merely a generic claim that a human was involved.

What this item captures

The functional role of the person initiating or operating the GenAI run.
The distinction between operational user, reviewer, approver, and other governance-relevant actors.
The authority context in which the run occurred, such as frontline delivery, specialist analysis, managerial approval, or quality assurance.
The level of abstraction needed for accountability without unnecessary disclosure of personal identity.
The human context required to interpret whether a run was appropriate for the task, domain, and risk level.
A basis for linking run records to authorisation rules, escalation routes, and review obligations.

Practical example / likely audience question

Audience question

Why record role rather than the person?s name if the organisation wants accountability?

Answer

The concern behind this question is usually that role sounds too abstract to support real accountability. The direct answer is that role and identity serve different governance functions. A name identifies a specific individual; a role shows the organisational capacity in which the person acted. RAIDT needs role because it makes the run interpretable and reviewable at the correct governance level, while still allowing identity to be managed proportionately through separate internal systems where necessary.

For example, a hospital may log that a medication-summary draft was generated by a ward pharmacist and reviewed by a consultant physician. Those role labels immediately tell an auditor what level of expertise and authority shaped the run. If the note instead exposed only personal names, the governance meaning would be less clear to external reviewers; if it exposed neither names nor roles, there would be little basis for assessing whether the run followed the correct process.

RAIDT handles this better than a generic AI governance approach because it ties the role field to a specific run, a specific task, and a specific evidence pack. That makes role operational rather than rhetorical. The issue is no longer "Do humans oversee AI?" but "Which role initiated this run, which role reviewed it, and was that role appropriate for this context?"

Practical example in RAIDT terms

Consider a healthcare trust using a generative AI assistant to draft discharge summaries from structured patient data. In one run, the draft is initiated by a junior doctor, checked by a ward pharmacist for medication consistency, and released only after consultant review for complex cases. The run-level issue is not merely that humans were involved; it is whether the right roles handled the run at the right stages.

The evidence needed includes the initiating role, review role, any escalation role, the task label, timestamp, prompt version, and reviewer notes. If an incorrect medication instruction appears in the discharge summary, RAIDT can reconstruct whether the run was handled within the intended governance pathway or whether the output bypassed the expected review role.

The pillars most affected are Responsibility, Auditability, and Traceability, with Dependability also strengthened because role-based handling reduces the chance of unsupported deployment in high-risk contexts. Recording user role / operator role therefore improves governance readiness by making it possible to test whether operational practice matched policy claims about competent oversight.

Detailed link to RAIDT

User role / operator role links to RAIDT in four ways.

First, it links to RAIDT's core idea that the run, rather than the model in the abstract, is the correct unit of governance.
Second, it links directly to run-level evidence because role is part of the minimal metadata needed to reconstruct how a specific use took place.
Third, it links to both the evidence pack and the score profile, since a documented role structure strengthens scoring claims about accountability, review design, and traceability.
Fourth, it links to reviewability, contestability, audit readiness, and organisational learning by making it possible to ask whether the correct kind of actor used or reviewed the system in the relevant context.

User role / operator role ? Run-level evidence ? Evidence pack ? RAIDT score profile ? Governance readiness

In short, RAIDT turns role from a background HR concept into an inspectable governance artefact attached to a specific run.

Link to the five RAIDT pillars

Responsibility

This item strongly affects Responsibility because it shows which organisational function carried operational or review responsibility within the run.