> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan.md). # 7.1 Roll out by risk: the phased plan Four phases from inventory and ownership through pilot, controlled expansion, and steady-state operations — the sequence that avoids governance gaps. *Last reviewed: August 18, 2026* {% hint style="info" %} Do not start with a feature tour. Start with inventory, owners, pilot controls, evidence, and clear gates for wider rollout. {% endhint %} ## What security teams need to know about roll out by risk: the phased plan AI rollout works best in phases. Phase 0 inventories tools and owners. Phase 1 pilots with narrow groups and data classes. Phase 2 expands by use case. Phase 3 moves into steady operations. The point of phases is evidence. Before widening, prove that identity, DLP, connector, runtime, and audit controls work for a real user doing real work. Phasing is also how NIST AI RMF governance becomes operational: each gate assigns ownership and oversight before autonomy and data exposure widen. ## Phases and gates Each phase has an objective, entry criteria, exit evidence, and an owner. Exit evidence is the gate: the rollout does not advance until the evidence exists and has been reviewed. **Phase 0: Inventory and baseline** * Objective: know every AI tool, account path, owner, and data class in scope before anything new is enabled. * Entry criteria: executive sponsor named; a single accountable rollout owner assigned. * Exit evidence: tool and owner inventory published; SSO enforced for every approved surface with password login disabled (see 1.1, SSO and SCIM for AI platforms); shadow accounts identified and queued for remediation (see 1.4, Shadow account remediation and managed-account consolidation). * Owner: security lead, with identity and IT asset owners contributing. **Phase 1: Controlled pilot** * Objective: prove that controls and evidence paths work for a small cohort doing real work. * Entry criteria: pilot cohort, use cases, data classes, and blocked uses defined; go/no-go criteria agreed before launch (see 7.2, Pilot design and success metrics). * Exit evidence: DLP alerts generated and triaged during the pilot (see 4.1, DLP for GenAI); every enabled connector has a logged approval in the intake register (see 2.7, The supply-chain review workflow); audit records reconciled against the pilot roster (see 6.1, The audit gap, and 6.3, Compliance APIs by platform). * Owner: security lead, with the pilot business owner and support lead contributing. **Phase 2: Expansion by use case** * Objective: widen access group by group and use case by use case, not by enthusiasm. * Entry criteria: pilot gate passed; support and incident paths staffed (see 5.6, Incident response for AI systems); pilot exceptions closed or given owners and expiry dates. * Exit evidence: each new group passes the same identity, data, runtime, and audit checks as the pilot (see 7.3, The security team checklist); telemetry from newly enabled surfaces lands in the SIEM (see 6.5, Routing AI telemetry to your SIEM). * Owner: platform or IT owner for enablement, with security signing each gate. **Phase 3: Steady-state operations** * Objective: run AI surfaces as a normal operational service with owners and cadence. * Entry criteria: expansion complete for the approved scope; review cadence and owners assigned (see 6.7, Continuous review cadence). * Exit evidence: first quarterly access and usage review completed; unattended and scheduled agent runs have named owners, scoped credentials, and log review (see 3.6, Scheduled and background tasks). * Owner: security operations, with platform and compliance contributing. Two gate rules apply across all phases. First, regulated data classes need their own gate: hold regulated data off any surface whose retention posture is not proven for that class (see 4.4, Retention and Zero Data Retention). Vendor example (Anthropic): Claude Managed Agents is in beta, and its sessions persist state server-side and are not currently eligible for zero data retention or HIPAA BAA coverage, so a phase gate should keep regulated data classes off Managed Agents until that eligibility changes. Second, an exception is a gate outcome, not a workaround: every exception needs an owner and an expiry date. ## Common roll out by risk: the phased plan security failures * The rollout starts with broad enablement and retrofits controls later. * A pilot succeeds on productivity but fails on evidence. * User groups expand before support and incident paths are ready. * Exceptions become permanent access. * The operating cadence is not assigned to owners. ## Roll out by risk: the phased plan security controls checklist * Run Phase 0 inventory before enabling new products, surfaces, or execution paths. * Pilot with known users, data classes, workflows, owners, and prohibited uses. * Define go, hold, and stop gates for identity, data, supply chain, runtime, threats, evidence, and support. * Train pilot users on allowed data, approvals, connectors, incident reporting, and output review. * Measure control effectiveness, audit completeness, support load, cost, incidents, and exceptions. * Expand by group and use case, not by enthusiasm. * Assign steady-state owners, review cadence, support, incident response, and budget before expansion. * Maintain a tested rollback and exit plan for every production deployment. ## Exit and rollback gate Before production, document how the organization will: * disable new access and stop active, scheduled, remote, and queued work; * revoke users, agent identities, API keys, service accounts, OAuth grants, and connectors; * transfer or retire agent, project, repository, skill, plugin, and artifact ownership; * export records needed for legal, audit, investigation, and business continuity; * delete prompts, files, memory, knowledge sources, indexes, caches, generated artifacts, and downstream copies; * remove public links, published sites, messages, code changes, and application integrations; * verify that billing, credits, webhooks, schedules, and background tasks have ended; and * restore the previous approved tool, model, configuration, or workflow. Exercise the disable and revocation path during the pilot. A contract termination checklist is not a technical exit test. ## Anthropic ### Overview Anthropic rollout gates map onto Enterprise controls, but Cowork needs separate gates for remote and local execution. Remote sessions run in Anthropic-managed sandboxes and can follow a user across web, desktop, and mobile. Local folders, applications, browser use, and computer use depend on the desktop and its endpoint controls. Custom roles can scope the pilot cohort, while connector permissions and Claude Code managed settings control integrations and coding-agent behavior. Gate Cowork observability before expansion. Anthropic excludes Cowork from audit logs, the Compliance API, and data exports, so a Team or Enterprise pilot should prove OpenTelemetry collection and downstream-log correlation. Gate Managed Agents separately because the product is in beta and its sessions are not currently eligible for zero data retention or HIPAA BAA coverage. Scheduled deployments and Cowork scheduled tasks belong in Phase 3 with named owners, scoped credentials, and log review. Roll Claude Tag out as a shared service identity, not as an ordinary Slack bot. Start in a private channel with the member restriction enabled, one low-risk Access bundle, narrow domains, dedicated service accounts, spend limits, and tested audit correlation. Add broader channels, write-capable connections, repositories, and routines only after the previous phase has an owner and evidence path. ### Anthropic documentation * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Scheduled deployments](https://platform.claude.com/docs/en/managed-agents/scheduled-deployments) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Monitor Claude Cowork activity with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) * [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI rollout gates split across ChatGPT workspace policy, Work cloud controls, local Codex managed configuration, and API organization settings. ChatGPT Desktop (Work / Codex) presents Chat, Work, and Codex together, but the control planes do not collapse with the interface. Web and mobile Work use workspace controls and cloud execution. Desktop Work and Codex can act on local files and applications under local Codex permissions and managed configuration. Pilot them separately. RBAC and app action controls can stage access by cohort. The Plugin Directory now covers plugins that may package skills, apps, and app templates, so plugin review belongs in the supply-chain gate. For exit evidence, verify known gaps rather than assuming a successful message export proves complete visibility. OpenAI's Compliance API covers messages and responses across Chat, Work, and Codex, but not Work files, actions, or tool calls. API-key-authenticated Codex automation also needs its own evidence path. ### OpenAI documentation * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Admin Controls, Security, and Compliance in apps](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-in-apps-enterprise-edu-and-business) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about roll out by risk: the phased plan ### What is a risk-based AI rollout? A risk-based rollout expands AI access only after controls and evidence are proven for each use case and data class. Instead of enabling a platform for everyone at once, it moves through phases: inventory, pilot, expansion, and operations, with a gate between each. The gate is evidence, not opinion: identity, data, runtime, and audit controls must be shown working for real users before the next group is enabled. ### What should Phase 0 include? Phase 0 is inventory and baseline. List every AI tool in use or requested, the account paths people use to reach them, the owners, the data classes involved, the connectors already enabled, and the audit sources available. It should also close the identity basics: SSO enforced, shadow accounts found, and a single accountable rollout owner named (see 1.1 and 1.4). ### What makes a good pilot gate? A good gate is a short list of verifiable checks, each backed by evidence. For example: SSO enforced for the pilot cohort, DLP alerts generated and triaged during the pilot, every connector approval logged in the intake register, and audit records reconciled against the pilot roster. If a check cannot produce evidence, the gate fails, and that is the gate doing its job. ### When should rollout stop? Stop expanding when a control fails for the next group: identity gaps, untriaged DLP alerts, connectors enabled without approval, runtime approvals bypassed, or audit records that cannot be reconciled. Pause, fix, re-verify against the gate, then resume. A rollout that cannot stop is enablement, not governance. ### Who should own rollout? Name a single accountable owner, typically the CISO or the security lead who chairs the AI governance group, who owns the phase plan, the gates, and the decision to advance or stop. Identity, platform and IT, compliance, business owners, and support all contribute checks and evidence to each gate. Accountability itself should not be shared: diffuse ownership is how gates get skipped. ## Applicable regulations and frameworks | Governance page | Relationship to this article | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | G.1 Map your controls to NIST AI RMF and CSF 2.0 | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports risk-based rollout, control validation, and recovery readiness. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and GRC guidance. | | G.8 ISO/IEC 42001 AI management system | This article supports ISO/IEC 42001 AIMS preparation through risk-based implementation and governance gates. | *G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.* ## Related handbook guidance * [7. Rollout & Operations](/handbook/7.-rollout-and-operations.md) * [7.2 Pilot design and success metrics](/handbook/7.-rollout-and-operations/7.2-pilot-design-and-success-metrics.md) * [7.3 The security team checklist](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist.md) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix.md) * [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.