> 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/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security.md).

# G.7 Ownership and RACI for AI security

Names the owners across workspace admin, platform admin, security policy, endpoint, compliance, legal, privacy, procurement, and incident response.

*Last reviewed: August 18, 2026*

{% hint style="info" %}
AI security fails when every team owns a slice and nobody owns the workflow. Assign owners by deployment model, data class, and control domain before rollout.
{% endhint %}

AI systems cross normal team boundaries. A single workflow can involve an identity provider, SaaS admin console, endpoint policy, browser session, model vendor, connector, DLP rule, compliance export, SIEM detection, and legal notice obligation.

The RACI should show who can approve or reject a use, who keeps the evidence, and who responds when something breaks. Use the role names below as a template and map them to real teams. Keep one accountable role for each activity, even when several teams are responsible for the work.

## Core roles

| Role                     | Primary responsibility                                                            |
| ------------------------ | --------------------------------------------------------------------------------- |
| Executive AI sponsor     | Sets risk appetite and resolves cross-functional disputes.                        |
| Business owner           | Owns the use case, users, business value, and residual business risk.             |
| Security owner           | Owns AI security controls, threat model, monitoring, and incident readiness.      |
| Platform owner           | Owns AI platform configuration, feature enablement, integrations, and support.    |
| Identity owner           | Owns SSO, SCIM, RBAC, tenant restrictions, groups, and access review.             |
| Data owner               | Approves data classes, data flows, retention, and allowed AI use.                 |
| Privacy owner            | Reviews personal data, DPIA needs, privacy notices, and affected-person rights.   |
| Legal owner              | Reviews regulatory obligations, contract terms, notices, and incident disclosure. |
| Compliance owner         | Owns evidence requests, control mapping, audit records, and review cadence.       |
| Procurement owner        | Owns vendor intake, contract routing, security addenda, and renewal gates.        |
| Endpoint owner           | Owns desktop apps, browser controls, MDM policy, and local agent restrictions.    |
| Developer platform owner | Owns coding agents, repositories, secrets, CI/CD, and developer tooling controls. |
| SOC owner                | Owns detections, triage, SIEM routing, and escalation.                            |
| Incident response owner  | Owns AI incident runbooks, evidence preservation, containment, and recovery.      |

## RACI by control domain

| Control domain                                    | Accountable              | Responsible                               | Consulted                            | Informed            |
| ------------------------------------------------- | ------------------------ | ----------------------------------------- | ------------------------------------ | ------------------- |
| AI tool approval                                  | Business owner           | Security owner, procurement owner         | Legal, privacy, compliance, platform | SOC, help desk      |
| SSO, SCIM, and RBAC                               | Identity owner           | Identity team, platform owner             | Security, compliance                 | Business owner      |
| Tenant restrictions and personal-account blocking | Security owner           | Identity owner, network or endpoint owner | Legal, HR                            | Users               |
| Connector and MCP review                          | Security owner           | Platform owner                            | Data owner, privacy, legal           | Business owner      |
| Coding-agent controls                             | Developer platform owner | Security engineering, developer tooling   | Legal for license/data issues        | Engineering leads   |
| Browser and desktop agents                        | Endpoint owner           | Endpoint team, platform owner             | Security, privacy, legal             | Users               |
| Data classification for AI                        | Data owner               | Security, privacy                         | Legal, compliance, business owner    | Users               |
| Retention and training-use settings               | Data owner               | Platform owner                            | Legal, privacy, compliance           | Business owner      |
| Logging and compliance exports                    | Security owner           | Platform owner, SOC                       | Compliance, legal, privacy           | Business owner      |
| SIEM detections                                   | SOC owner                | Detection engineering                     | Platform owner, IR owner             | Security leadership |
| AI threat modeling                                | Security owner           | Security architect, platform owner        | Business, data, privacy, legal       | Compliance          |
| Red-team and abuse-case testing                   | Security owner           | Red team or appsec                        | Platform owner, business owner       | Compliance          |
| Incident response                                 | Incident response owner  | SOC, platform owner, identity owner       | Legal, privacy, business owner       | Executive sponsor   |
| Policy exceptions                                 | Security owner           | Business owner                            | Legal, privacy, compliance           | Executive sponsor   |

## RACI by deployment model

| Deployment model         | Accountable owner        | Required co-owners                          |
| ------------------------ | ------------------------ | ------------------------------------------- |
| Workforce chat           | Platform owner           | Identity, data, security, compliance        |
| Coding agent             | Developer platform owner | Security, identity, endpoint, data          |
| Browser or desktop agent | Endpoint owner           | Security, platform, privacy, legal          |
| Hosted agent             | Business owner           | Platform, security, data, SOC, IR           |
| API app                  | Application owner        | Security, developer platform, data, privacy |
| Low-code agent builder   | Platform owner           | Business owner, security, data, compliance  |

## Minimum ownership record

Every approved AI workflow should have:

* Business owner.
* Technical platform owner.
* Security owner.
* Data owner.
* Identity owner.
* Evidence owner.
* Incident owner.
* Review date.
* Exception owner, if any.

Do not approve production use without these names.

## Decision rights

Define decision rights in writing:

* Security can block a tool or feature that lacks required controls.
* Data owners can block use of their data in unapproved AI workflows.
* Legal and privacy can require notice, DPIA, impact assessment, or contractual changes.
* Platform owners can block unsupported configurations.
* Incident response can suspend an AI workflow during investigation.
* Executive sponsor can accept residual risk only after control gaps are documented.

## Common AI security ownership and RACI security failures

* The AI platform owner enables features but does not own data risk.
* Security writes policy but cannot change platform settings.
* Procurement approves a vendor without knowing the deployment model.
* Business teams publish low-code agents without a named owner.
* SOC receives alerts with no runbook or platform contact.
* Exceptions are approved in chat and never added to a register.

## AI security ownership and RACI security controls checklist

* Assign accountable owners by deployment model.
* Assign responsible owners by control domain.
* Keep a system-of-record for owners and review dates.
* Define who can approve, reject, suspend, and accept risk.
* Review ownership after reorganizations, vendor changes, and incidents.
* Include ownership in the AI inventory and control matrix.

## Frequently asked questions about AI security ownership and RACI

### Who should own AI security overall?

Name one executive who can resolve control gaps and accept or escalate risk. The CISO often fills that role for the security program, while broader enterprise AI governance may be accountable to another executive or committee. Document the boundary and the escalation path.

### Should legal own AI governance?

Legal should own legal interpretation and regulatory advice. Security should own technical controls and evidence. The business owner should own the use case and residual business risk.

### Who owns low-code agents built by business users?

The platform owner owns the builder controls. The business team owns each published agent. Security owns the approval rules and monitoring requirements.

### Who owns AI incidents?

Incident response owns the process. Platform, identity, endpoint, data, legal, privacy, and the business owner support containment, evidence, notification, and recovery.

## Applicable handbook articles

These links are limited to control domains for which this RACI assigns an owner, operating responsibility, or decision right.

| Handbook area                            | Applicable articles                                                                                                                                                                                                                                                                                                                                                     | Why they apply                                                      |
| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| 1. Identity & access                     | <p>1.1 SSO & SCIM for AI platforms<br>1.2 RBAC across AI platforms<br>1.3 Tenant restrictions: blocking personal accounts<br>1.5 Agent and non-human identity<br>1.6 API keys and service accounts governance<br>1.7 Human-in-the-loop and approval policies</p>                                                                                                        | Assigns accountable and responsible owners for this control domain. |
| 2. Connectors, extensions & supply chain | <p>2.1 Connectors and apps: the integration backbone<br>2.2 MCP servers: securing the protocol<br>2.3 MCP gateways and allowlisting<br>2.4 Analyzing skills for risk<br>2.5 Plugins and marketplaces<br>2.6 Hooks and lifecycle scripts<br>2.7 The supply-chain review workflow<br>2.9 SaaS agent-building supply-chain<br>2.10 Hosted-agent framework dependencies</p> | Assigns accountable and responsible owners for this control domain. |
| 3. Runtime, sandboxing & autonomy        | <p>3.2 Approval policies and least-privilege autonomy<br>3.4 Internet access and browser automation<br>3.5 Computer Use / desktop control risks<br>3.8 File and filesystem access controls<br>3.9 Central hosted-agent runtime hardening</p>                                                                                                                            | Assigns accountable and responsible owners for this control domain. |
| 4. Data protection                       | <p>4.1 DLP for GenAI<br>4.2 Data classification for AI prompts and outputs<br>4.4 Retention and Zero Data Retention<br>4.5 Training opt-out and data usage<br>4.6 Cross-app data flow and live artifacts<br>4.7 Secrets and credential hygiene in prompts and tools</p>                                                                                                 | Assigns accountable and responsible owners for this control domain. |
| 5. Threats & adversarial testing         | <p>5.5 Red-teaming AI systems<br>5.6 Incident response for AI systems<br>5.7 Threat modeling AI systems</p>                                                                                                                                                                                                                                                             | Assigns accountable and responsible owners for this control domain. |
| 6. Observability, audit & evidence       | <p>6.1 The audit gap: what you can and can't see<br>6.3 Compliance APIs by platform<br>6.5 Routing AI telemetry to your SIEM<br>6.6 Evidence by surface and investigation paths<br>6.7 Continuous review cadence</p>                                                                                                                                                    | Assigns accountable and responsible owners for this control domain. |
| 7. Rollout & operations                  | 7.4 The vendor-neutral control matrix                                                                                                                                                                                                                                                                                                                                   | Assigns accountable and responsible owners for this control domain. |

## Further reading

The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page.

* [NIST AI RMF GOVERN function](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/)
* [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework)
* [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng), especially Articles 4, 26, and 27

## Related handbook guidance

* [Governance & Frameworks](/reference/governance-and-frameworks.md)
* [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan.md)
* [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system.md)
* [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence.md)
* [G.1 Map your controls to NIST AI RMF and CSF 2.0](/reference/governance-and-frameworks/g.1-map-your-controls-to-nist-ai-rmf-and-csf-2.0.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/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security.md?ask=<question>&goal=<endgoal>
```

`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.
