Use Authorizations

A use authorization is the explicit, audited record that a named member (or a defined role) is permitted to invoke a specific AI system for a specific purpose. Without an authorization, no member can invoke an AI system. With an authorization, every invocation falls within its defined scope.

This is the gate that turns AI from a feature you’ve registered into AI that your organization actually uses, deliberately, with someone accountable.

When you would reach for this

You set up use authorizations when:

An AI system has been registered and you need to give specific members the ability to invoke it.
A new role or business area is being onboarded to use existing AI capabilities.
Authorization scope needs to be tightened (or widened) for a specific system or member.
A regulator or framework requires documented authorization records per AI use.

You don’t reach for this for registering the system itself (that’s AI Systems) or for what the system is allowed to do (that’s Action Policies). Use Authorizations is the who, for what purpose layer.

What lives in an authorization

A single record type:

Use authorization carries:

A stable key and a title.
The AI system being authorized (link to AI Systems).
The subject being authorized — typically a member or a role (responsibility assignment).
A purpose describing what the authorization permits (“draft adjuster review notes,” “summarize policy documents for member services”).
A scope snapshot capturing constraints (data categories permitted, scope nodes in scope, allowed action set).
A status walking through proposed, approved, active, suspended, expired, revoked, archived.
An approver (a responsibility assignment that approved the authorization).
A valid-from and a valid-until date (expiry is the discipline).
A review-due date for periodic reconfirmation.

A worked example: a research-focused biopharma authorizes AI use in clinical workflows

A research-focused biopharma company has registered three AI systems: a clinical-trial document summarizer, a regulatory-correspondence drafting copilot, and an adverse-event report drafting assistant. The clinical operations director, Inez, decides who is authorized to use each, for what, and within which constraints.

Step 1: define the policy in advance. Before any individual authorization, Inez sets the policy:

The clinical-trial summarizer is authorized for the clinical operations team and the medical writing team. Purpose: drafting summaries of trial documentation for internal review. Constraint: no patient-level data in scope.
The regulatory-correspondence copilot is authorized for the regulatory affairs team only. Purpose: drafting correspondence with regulators. Constraint: no submission-bound content; outputs always require human review and sign-off.
The adverse-event report drafting assistant is authorized for the pharmacovigilance team only. Purpose: producing draft AE report narratives. Constraint: every output requires senior pharmacovigilance officer review before any onward use.

Step 2: create authorizations. For each authorized member or role:

Inez creates a use authorization linked to the AI system and the subject (a specific member or a responsibility assignment representing a role).
Captures the purpose verbatim.
Captures the scope snapshot with the constraints.
Routes for approval (the chief medical officer for clinical-related authorizations, the head of regulatory for regulatory-related, the qualified person for pharmacovigilance authorizations).
Sets validity (12 months by default) and review-due (6 months).

Step 3: live authorization. Once approved and active, the authorization lets the subject invoke the system. Invocations outside the scope (e.g., a member trying to use the regulatory copilot without authorization) are blocked.

Step 4: review and renewal. As authorizations approach their review-due, Inez’s team reconfirms or revises. Authorizations no longer needed are revoked. New authorizations follow the same flow.

Step 5: incident response. If an authorization needs to be suspended quickly (a member leaves the relevant role, a provider issue surfaces), Inez transitions it to suspended with rationale. The subject cannot invoke until resumed.

After six months:

Every AI invocation in the biopharma is tied to a named, approved authorization.
The authorization register is the audit-grade record of who’s allowed what.
Reviews keep authorizations current and prune stale ones.
An auditor reviewing AI governance sees the full who/what/why/until.

Status lifecycle

Status	Meaning
`proposed`	Submitted for approval. Cannot be used.
`approved`	Approved but not yet active (e.g., valid-from in the future).
`active`	In effect; the subject can invoke the system within scope.
`suspended`	Temporarily suspended. Subject cannot invoke.
`expired`	Past valid-until. Subject cannot invoke; reissue or renew.
`revoked`	Revoked before expiry. Audit trail preserved.
`archived`	Archived for historical reference.

Expiry and review discipline

Authorizations don’t last forever. A use authorization with no expiry and no review-due is a governance red flag: AI use should be deliberate, periodic, and refreshed as conditions change.

The system surfaces approaching expiries and approaching review-due dates so they aren’t silently missed. An expired authorization stops working; a review-due-past authorization remains active but is flagged for reconfirmation.

Common workflows

Issuing an authorization

Use Authorizations → New. Pick the AI system and the subject.
Capture the purpose and scope constraints.
Route for approval.
Set validity and review-due.
Once approved and active, the subject can invoke within scope.

Renewing an authorization

As an authorization approaches review-due, the system surfaces it.
The owner reconfirms with the original approver (or escalates if conditions have changed).
Update the review-due date.
For a complete renewal at expiry, create a new authorization with refreshed scope.

Revoking an authorization

From the authorization, transition to revoked with rationale.
The subject can no longer invoke.
The audit trail is preserved.

What you’ll see in the product

Use Authorizations lives under Governance → AI Governance → Use Authorizations in the workspace.

The Authorizations list shows every authorization with its status, subject, AI system, purpose, validity, review-due.

Inside an authorization, you see the full record, the approver, the scope snapshot, the activity history.

Every change is captured in the workspace Audit Log.

AI Systems - the systems being authorized.
Action Policies - constraints on what authorized invocations can do.
Runs & Evidence - each invocation under an authorization is recorded.
Responsibilities - approvers and subjects are responsibility assignments.