Should organisations use one AI policy for Legal, HR, Compliance, Security, and business teams?

Why one AI policy usually fails across legal, HR, compliance, security, and business

Organisations should not treat AI policy as a single flat rulebook. The policy needs one control architecture, but each function should apply different evidence standards, approval thresholds, and acceptable-use boundaries based on the sensitivity of its work. That is the practical way to keep governance consistent without pretending every team faces the same risk.

The main design choice is separation of policy intent from local interpretation. Central teams should define what must be true, who can approve exceptions, what gets logged, and which data classes or workflows are prohibited; business functions then tailor the operating rules to their own use cases. That keeps the policy coherent while preserving business-fit decisions where judgement matters.

This is also where AI policy starts to resemble broader governance architecture rather than a one-off acceptable-use memo. A federated model works best when legal, HR, compliance, security, and business owners all operate from the same control language, because the real failure mode is usually fragmentation: different tools, different wording, different records, and different escalation paths for the same underlying risk.

What should stay centralised, and what should be local

The central layer should define shared requirements such as model and tool approval, data handling rules, audit logging, retention, incident reporting, and ownership. Those controls are what make the policy enforceable across the enterprise. Central governance should also set the minimum evidence needed to show compliance, so each function is not inventing its own proof standard.

Local teams then decide how those controls operate in practice. Legal may need stronger review before any external-facing drafting support is used, HR may need stricter handling of employee data, compliance may require more complete traceability, security may demand tighter integration with monitoring and access controls, and business teams may prioritise speed for lower-risk use cases. The control is shared; the threshold is not.

That split prevents two common failures: over-standardising low-risk work until people bypass the policy, and under-standardising high-risk work until the organisation cannot explain why a model, prompt, or output was allowed. The policy should centralise the guardrails, but not erase functional accountability for the final decision.

How to keep a federated AI policy consistent in practice

Use one governance model, one taxonomy of risk, and one audit trail format across all teams. Then require each function to document its specific evidence, such as review notes, approved use cases, redaction rules, or human-approval steps, so the central function can compare decisions without forcing identical workflows.

For AI policy design, ISO/IEC 42001:2023 AI Management System Standard is the strongest external anchor because it supports an organisation-wide management system with auditable roles, controls, and continual improvement. That maps well to a federated operating model where local teams adapt execution but not governance intent.

For teams building the operating model itself, Agentic AI Compliance Guide is a useful internal reference because it ties audit evidence, human oversight, and regulatory mapping to the same policy backbone. Where organisations are also choosing tools, AI Security Platform Buyer's Guide helps translate policy requirements into platform capabilities and evaluation criteria.

A further operational advantage of the federated model is that it scales better than committee-by-committee exceptions. Once the policy language, logging standard, and review evidence are centralised, teams can move faster on routine cases and escalate only the genuinely unusual ones. That reduces delay without turning the policy into a symbolic document that nobody can apply consistently.

Risk and Threat Considerations

Fragmented AI policy creates exposure when one function approves behaviour that another function would treat as prohibited or high-risk. The result is inconsistent data handling, unclear accountability, and poor auditability, which makes it harder to detect misuse, investigate incidents, or prove that a decision was properly authorised.

Failure mechanism: Different teams apply different thresholds, records, or review paths to the same AI use case, so a sensitive workflow can slip through one function’s lighter process and later appear non-compliant or unsafe under another team’s standard.

Impact: The organisation gets policy drift, weak evidence, and avoidable rework, and it may also miss material misuse until the underlying data, output, or decision has already propagated into business processes.

Practitioner Guidance

What to prioritise: Define the few controls that must never vary, then allow functions to vary only the evidence threshold and approval path. If a team cannot explain why its exception is different, the policy is too fragmented.

What to verify: Check that every function can produce the same minimum audit evidence for its AI use cases, even if the local workflow differs. If the evidence cannot be compared across teams, the organisation does not have one governance model yet.

Common mistake: Writing a single “AI acceptable use” statement and assuming that counts as enterprise policy. The useful unit is not the statement, but the combination of central controls, local thresholds, and a defensible record of decisions.

Practitioner takeaway: Treat AI governance as centrally designed, locally applied control architecture, not as a one-size-fits-all rule set; consistency should come from shared evidence and escalation logic, not identical treatment of every use case.

Related resources from NHI Mgmt Group

• How should organisations govern AI use when responsibility is split across security, legal, HR, and compliance?
• How should organisations build a policy governance framework that keeps policies consistent across HR, legal, IT, and compliance teams?
• How should organisations operationalise GDPR compliance across privacy, security, legal, and business teams?
• How should security teams govern non-human identities for compliance?