S5.01 - Responsibility

S5.01 ? Responsibility

flowchart LR
    A[Background problem:
principles without run-level proof] --> B[RAIDT
run-level evidence framework]
    A2[Traditional limitation:
unclear authority, weak boundaries,
informal oversight] --> B
    B --> C[[Responsibility
justified, bounded, authorised,
and overseen use]]
    H[Practical fields:
healthcare, finance, education,
public services, enterprise workflows] --> C
    C --> D[Evidence pack:
purpose, limits, approvals,
escalation, safety controls]
    C --> E[Score profile:
Responsibility plus four-pillar view]
    C --> I[Governance move:
evidence over assertion]
    D --> F[Reviewability and contestability]
    E --> G[Governance readiness]
    D --> J[Organisational learning and policy alignment]

? Star S5 - RAIDT Pillars and Scoring

Star context: Responsibility is one of RAIDT's five governance pillars. It defines whether a specific GenAI run was appropriate, bounded, authorised, and overseen, so that scoring reflects accountable use rather than technical performance alone.

Academic picture

Definition / background

Responsibility in RAIDT asks whether a particular run of a generative AI system was appropriate, bounded, safe, authorised, and overseen in relation to the task being performed. It is therefore concerned with accountable use, not simply with whether the model generated a plausible or useful output. The concept matters because a technically successful answer can still be organisationally irresponsible if it was used outside scope, without authority, without safeguards, or without a route for escalation and review.

Conceptually, Responsibility sits at the intersection of governance, risk ownership, and justified action. In general AI governance discourse, responsibility is often discussed at the level of principles, organisational values, or high-level policy statements. RAIDT narrows the focus to the run as the unit of governance. That shift matters because organisations do not govern generative AI in the abstract; they govern situated uses by named roles, for specific tasks, at specific moments, under concrete constraints.

Responsibility differs from adjacent terms. It is not the same as auditability, which concerns whether a reviewer can inspect and reconstruct what happened. It is not the same as traceability, which concerns whether relevant artefacts, decisions, and transformations can be followed across the run. It is also not identical to dependability, which asks whether the process and outcome are sufficiently stable and reliable for the intended use. Responsibility instead asks whether the run should have occurred in the way it did, under the conditions it did, with the oversight it did.

Within RAIDT, Responsibility belongs inside the five-pillar profile because governance readiness requires more than records. A strong evidence pack with weak responsibility controls would still expose the organisation to misuse, unmanaged risk, and contestable decisions. For that reason, Responsibility connects the evidence pack to organisational accountability: it shows whether the run was normatively and procedurally justified, and whether that justification can be defended to supervisors, auditors, managers, and affected stakeholders.

Why this concept matters

Responsibility solves a recurring governance problem in organisational GenAI use: the gap between having general principles and being able to justify one concrete use. Without this concept, teams often assume that approved access to a tool, a broad acceptable-use policy, or a manager's informal endorsement is enough. RAIDT makes that assumption visible and testable by asking for run-specific evidence that the use was appropriate, bounded, and overseen.

The concept also prevents a common confusion between usefulness and legitimacy. A run may save time and produce a convincing output, but still be irresponsible if it involves sensitive information, bypasses review, exceeds delegated authority, or creates downstream risk for staff, clients, patients, students, or citizens. Responsibility therefore acts as a governance filter on model use, not as a quality judgement on text generation alone.

If Responsibility is missing, organisations drift towards principle-washing: they can claim alignment with responsible AI values while lacking evidence that real uses are governed in a disciplined way. By contrast, RAIDT operationalises responsibility through evidence that can be inspected, challenged, and improved over time. That move is central to RAIDT's wider aim of shifting governance from assertion to documented, reviewable practice.

Key idea: Responsibility matters because it shows whether a specific GenAI run was justified and governable, rather than merely possible or productive.

What this item captures

Whether the run had a legitimate and clearly stated purpose.
Whether the task fell within an authorised and appropriate use case.
Whether limits, exclusions, and safety boundaries were defined before or during use.
Whether accountable human roles were assigned for initiation, review, escalation, and sign-off.
Whether the run was subject to policy, procedural, legal, ethical, or sector-specific constraints.
Whether the use of outputs was controlled so that generated material was not treated as self-authorising.
Whether there is evidence that oversight decisions were made, rather than assumed.
Whether organisational accountability can be reconstructed if the run is challenged later.

Practical example / likely audience question

Audience question

If RAIDT already records prompts, outputs, and logs, why does it need a separate Responsibility pillar?

Answer

The concern behind this question is the assumption that documentation alone equals good governance. It does not. Logs can show what happened, but they do not by themselves show whether the run should have happened in that form, under that authority, and within those limits.

The direct answer is that Responsibility addresses the legitimacy of use, whereas logs mainly support reconstruction of use. A run can be perfectly logged and still be irresponsible. For example, a member of staff might use a generative AI system to draft advice for a vulnerable service user without checking whether that use case is permitted, whether the data entered were appropriate, or whether a qualified reviewer was required before the output was acted on.

RAIDT handles this issue better than a generic AI governance approach because it asks for evidence at the level of the specific run. Rather than relying on broad policy language such as ?staff should use AI responsibly?, RAIDT looks for concrete indicators: a purpose statement, task scope, approval route, safety constraints, escalation rules, reviewer role, and conditions of use for the generated output. That is more operational, more defensible, and more useful in supervision, audit, and post-hoc review.

Practical example in RAIDT terms

Consider a healthcare administration team using a GenAI assistant to draft patient appointment follow-up letters. The use case appears low-risk because it is administrative rather than diagnostic, but a specific run becomes governance-sensitive when staff include details about treatment pathways, missed appointments, or vulnerability indicators.

The run-level issue is not simply whether the output reads well. The real question is whether this use of GenAI was authorised for patient communication, whether the prompt content stayed within approved data boundaries, whether a human reviewer had to approve the final letter, and whether escalation rules existed if the generated draft introduced clinically inappropriate wording.

The required evidence would include the stated purpose of the run, the approved task category, the user's role, any data-handling restrictions, the review requirement before sending, the relevant policy link, and the decision rule for when GenAI drafting must not be used. Responsibility is the primary pillar here, but Auditability, Traceability, and Dependability are also affected because the organisation must reconstruct the run, understand what was generated, and trust that the process is stable enough for repeated administrative use.

In governance-readiness terms, Responsibility improves the organisation's position by showing that GenAI was used under defined authority with explicit boundaries. That is more defensible than claiming after the fact that the tool was merely ?helping with drafting?.

Detailed link to RAIDT

Responsibility links to RAIDT in four ways.

First, it expresses RAIDT's core idea that governance should focus on the run, not only on the model or policy environment.
Second, it attaches accountability to the specific configured use of GenAI for a task, at a time, in a context.
Third, it feeds the evidence pack and score profile by requiring explicit evidence of purpose, authority, boundaries, oversight, and control.
Fourth, it strengthens reviewability, contestability, audit readiness, and organisational learning because a challenged run can be justified in governance terms rather than defended by informal explanation.

Responsibility ? Run-level evidence ? Evidence pack ? RAIDT score profile ? Governance readiness

In this chain, Responsibility is the pillar that asks whether the run was appropriately governed before its outputs are treated as usable organisational artefacts.

Link to the five RAIDT pillars

Responsibility

Responsibility is the primary pillar because it establishes whether the run was appropriate, authorised, bounded, and overseen.