Should organisations treat AI safety and cybersecurity governance as separate programmes or one combined risk function?

Organisations should treat them as closely linked governance functions because AI safety controls and cybersecurity controls overlap in practice. The same programme should cover testing, vulnerability management, model use, and responsible deployment. Splitting them too far apart creates gaps between policy, engineering, and operational oversight, which makes it harder to define due diligence and consistent accountability.

How AI safety and cybersecurity overlap in governance

For most organisations, the practical answer is to run one combined risk function with clear sub-discipline ownership, not two disconnected programmes. AI safety concerns such as harmful output, misuse, and unsafe deployment depend on the same governance machinery as cybersecurity: policy, testing, access control, change management, monitoring, and incident response. Treating them separately often creates duplicate committees and inconsistent escalation paths.

The useful distinction is not organisational separation, but control specialisation. AI-specific review is needed for model behaviour, output boundaries, and use-case approval, while cybersecurity review is needed for identity, exposure, logging, secrets, and adversary behaviour. A combined function lets those checks converge on one risk register, one assurance cycle, and one accountable owner for deployment decisions.

This is why ai governance increasingly looks like NIST AI Risk Management Framework work at the same time as security governance, not instead of it. Organisations that already align to NIST Cybersecurity Framework 2.0 can usually extend that structure to AI rather than building a parallel oversight model.

What a combined operating model should cover

A workable combined programme should cover the full lifecycle of the AI system, from use-case intake through testing, deployment, monitoring, and retirement. That includes security sign-off for data sources, API and model access, prompts or tooling that can trigger external actions, and the controls that prevent unsafe or unauthorised changes after release.

It also needs a single view of assurance evidence. AI teams often think in terms of evaluation results, model cards, and red-team findings, while security teams think in terms of vulnerability remediation, configuration hardening, and incident handling. Those artefacts need to land in one governance process so that risk acceptance is explicit and comparable across both safety and cyber concerns.

For organisations already under sector pressure, external expectations reinforce this combined approach. EU NIS2 Directive pushes security governance, incident handling, and supply-chain discipline, while EU AI Act regulatory framework adds obligations around AI risk management and deployment accountability. A combined function is usually the only practical way to satisfy both without contradictory controls.

Where organisations get the structure wrong

The biggest failure mode is splitting policy from engineering reality. If the AI team owns “safety” and the security team owns “cyber,” each side can approve different parts of the same system while nobody owns the combined blast radius. That is especially dangerous when AI systems can use tools, call APIs, or influence operational workflows.

Another common error is treating model testing as a one-time launch gate. That misses the fact that security posture changes when model versions, prompts, tools, dependencies, or access rights change. The same programme should therefore monitor runtime behaviour, not only pre-deployment review, and should have a clear path for rollback, disablement, or escalation when controls fail.

Threat-oriented guidance also points in the same direction. Real-world attack patterns increasingly mix AI misuse, credential abuse, and lateral movement, so the governance boundary must include both the model and the surrounding identity and access controls. That is why practitioners should treat platform controls and operational controls as one chain of assurance, not as separate buckets.

Risk and Threat Considerations

Separating AI safety from cybersecurity governance creates exposure where model behaviour, access control, and incident handling do not line up. The result is usually slower escalation, weaker accountability, and blind spots when an AI system is misused, compromised, or allowed to act beyond its intended scope.

Failure mechanism: One programme approves safe use of the model while another approves secure operation of the system, but neither owns the combined path from prompt or tool use to real-world action. Attackers and unsafe deployments exploit that gap through prompt abuse, stolen credentials, unsafe integrations, or unreviewed change.

Impact: Organisations can miss harmful outputs, unauthorised actions, exposed secrets, or an incident that is visible to one team but not escalated through the right governance channel. Over time, that weakens due diligence and makes accountability harder to prove.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF and NIST CSF 2.0 set the technical controls, while ISO/IEC 42001:2023, ISO/IEC 27001:2022 and DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST AI RMF	AI Risk Management Framework	AI safety and governance depend on formal risk management across the lifecycle.
Recommendation — Align AI oversight to a shared risk function and document lifecycle testing and accountability.
NIST CSF 2.0	GV.OC-01 — Organizational Context	Combined AI and cyber governance needs one operating context and ownership model.
	GV.RM-01 — Risk Management Strategy	The question is about whether risk should be managed in one function or split.
	GV.RR-01 — Roles, Responsibilities, and Authorities	Split programmes fail when accountability for AI and cyber controls is unclear.
Recommendation — Define one governance scope that covers AI and cyber responsibilities together. Set a single risk strategy for AI safety and cybersecurity controls. Assign one accountable owner for AI deployment risk decisions.
ISO/IEC 42001:2023	AI management system	AI governance requires a structured management system for responsible deployment.
Recommendation — Use an AI management system to integrate safety, accountability, and review.
ISO/IEC 27001:2022	A.5.1 — Policies for information security	A combined governance model needs unified policy and assurance for AI systems.
Recommendation — Extend security policy to cover AI safety controls and operational oversight.
DORA	Digital Operational Resilience	Operational resilience depends on coordinated governance of technology and risk.
Recommendation — Embed AI systems in one operational resilience and incident governance process.

Practitioner Guidance

What to prioritise: Build one governance forum and one risk register for AI systems, then assign sub-owners for safety testing, security testing, access review, and deployment approval. The key is shared accountability, not merged technical expertise.

What to verify: Make sure every AI deployment has a documented owner, a rollback path, a defined review cadence, and clear evidence of both model evaluation and security control validation. If any of those are missing, the control stack is incomplete.

Practitioner takeaway: Keep the programme combined at the governance level, but explicit at the control level, because the real failure is not usually lack of policy, it is split accountability across the same production system.