Action Policies

An action policy defines what AI is allowed to do in your workspace. Each policy attaches to one or more action descriptors (the named actions AI can take) and specifies how each action is governed: suggest-only, autonomous, requires approval, blocked.

This is the layer that turns AI from “can produce text” into “can take a specific action under specific conditions, with audit.” Without an action policy, AI produces suggestions that go nowhere. With an action policy, AI suggestions can become applied changes — under the constraints the policy specifies.

When you would reach for this

You set up action policies when:

• A new AI system or profile is being introduced and you need to constrain what it can do.
• An existing policy needs tightening (a permitted action is being moved from autonomous to suggest-only after a review).
• A new action descriptor is being added (a new capability the AI can propose to take).
• An audit requires evidence that AI actions are bounded and approved.

You don’t reach for this for the AI’s text outputs themselves (those are runs and suggestions, in Runs & Evidence). Action policies govern side-effect actions the AI can propose or take.

What lives in action policies

Two record types:

Action descriptor is the named action AI can take. Each descriptor identifies an action by name, the target it acts on, and the permission requirements. Examples: propose-control-creation, update-document-metadata, assign-finding-to-owner, draft-meeting-summary, extract-document-fields.

Action policy specifies how one or more action descriptors are governed for a particular scope (a specific AI system, a specific profile, a specific role). Each policy carries:

• The descriptors in scope.
• The mode per descriptor: suggest-only, requires-approval, autonomous, blocked.
• The approver routing when the mode is requires-approval.
• Constraints (rate limits, value bounds, scope restrictions).
• A status walking through draft, published, retired, archived.

Modes explained

The mode menu is intentionally narrow. Every AI action falls into one of these four shapes; the policy decides which.

A worked example: a book publishing house governs Copilot actions in editorial workflows

A book publishing house uses Copilot for editorial workflows: drafting catalog copy, summarizing manuscript reports, proposing metadata for newly-acquired titles. The team wants Copilot helpful but tightly governed: nothing autonomous that changes catalog or rights data without human sign-off. The editorial operations lead, Theodora, sets up Action Policies like this.

Step 1: define the action descriptors. Theodora works through the actions Copilot might take:

• draft-catalog-copy — produce a draft of catalog copy from a manuscript brief.
• propose-title-metadata — propose metadata for a new title (genre, themes, comparable titles).
• update-title-metadata — apply metadata changes to a title record.
• summarize-manuscript-report — produce a summary of an internal reader’s manuscript report.
• propose-marketing-tags — propose marketing tags for a title.
• apply-marketing-tags — apply marketing tags to a title record.

Each descriptor is registered with its name, target, and required permissions.

Step 2: define the policy. A single policy governs Copilot’s editorial actions:

• draft-catalog-copy — suggest-only. Output is always a draft for human editing.
• propose-title-metadata — suggest-only. Editor reviews and applies or modifies.
• update-title-metadata — blocked. Updates always come from human action via the title record UI.
• summarize-manuscript-report — suggest-only. The summary is a draft.
• propose-marketing-tags — requires-approval. Tags are auto-routed to the marketing lead for approval; on approval they apply.
• apply-marketing-tags — blocked. Tags never apply autonomously.

Step 3: publish. The policy is reviewed by the AI governance committee, then published.

Step 4: live operation. As editors invoke Copilot through the relevant profiles, the policy gates each action. Drafts appear for editing. Metadata proposals appear in the editor’s queue. Marketing tags go through the marketing lead’s approval queue. No catalog updates ever happen without a human action.

Step 5: policy evolution. After six months, the team has confidence in the marketing tag proposals. They revise the policy: propose-marketing-tags becomes requires-approval with auto-approval for tags appearing in the top-100 in-house tag library. The revised policy is published; the prior version is retired.

After a year:

• Editorial Copilot has clear, documented action boundaries.
• Every action AI takes (or doesn’t take) is traceable to a published policy.
• Audit evidence is the policy version + the action history per invocation.

What you’ll see in the product

Action Policies lives under Governance → AI Governance → Action Policies in the workspace.

Two top-level tabs: Action Descriptors, Action Policies.

The Action Descriptors list shows every registered descriptor with its name, target, required permissions.

The Action Policies list shows every policy with status, scope (which systems or profiles it covers), the count of descriptors in scope.

Inside a policy, you see:

• The descriptor list with mode per descriptor.
• The approver routing where applicable.
• The constraints.
• The version history.

Every change is captured in the workspace Audit Log.

Constraints

Beyond the mode, policies can carry constraints:

• Rate limits: maximum actions per period (e.g., no more than 20 metadata updates per hour per editor).
• Value bounds: maximum value or quantity per action (e.g., no rent change above a threshold).
• Scope restrictions: limit to specific scope nodes (e.g., only for titles in the imprint’s active list).

Constraints are evaluated at action time. Actions exceeding constraints either fall back to suggest-only or are blocked, per the policy.

Common workflows

Defining a new action descriptor

1. Action Descriptors → New. Name, target, required permissions.
2. Register the descriptor.
3. Reference it from policies.

Creating a policy

1. Action Policies → New. Scope (which AI systems or profiles).
2. Add descriptors with their mode and constraints.
3. Capture approver routing for requires-approval modes.
4. Route for review.
5. Publish.

Revising a policy

1. From the policy, create a new version.
2. Adjust modes, descriptors, constraints.
3. Publish; prior version is retired.

Related

• AI Systems - policies scope to systems.
• Governance Copilot - Copilot profiles reference policies.
• Document Intelligence - DI profiles reference policies.
• Runs & Evidence - every action-aware AI run records the policy in effect.
• Review-Approval - the approval routing system policies use.