How should organisations govern AI use without writing a huge new policy first?

Why This Matters for Security Teams

Organisations do not need to wait for a perfect AI policy to begin governing use, but they do need a defensible control model. Most of the risk sits in existing domains: data leakage, unauthorised tool use, weak human oversight, and poor vendor governance. A practical starting point is to extend current security and acceptable-use rules, then map AI activities to accountable owners, review points, and escalation paths. The NIST Cybersecurity Framework 2.0 is useful here because it frames governance as an operating discipline rather than a one-time document exercise.

That matters because AI adoption usually arrives through business teams, not security programmes. Employees paste data into chat tools, developers add model calls into products, and procurement approves services before controls are fully defined. A huge new policy often becomes a shelf document if it is not anchored to the processes people already follow. The better approach is to decide what is allowed, what requires approval, what must never be shared, and who reviews outputs that influence customers, code, or regulated decisions. In practice, many security teams encounter AI misuse only after data exposure or shadow procurement has already occurred, rather than through intentional policy design.

How It Works in Practice

Governance works best when it is layered. Existing policies should define the baseline, while a short interim AI standard handles the specifics that those policies do not yet cover. Current guidance suggests focusing on use cases, data classes, and decision impact rather than trying to regulate “AI” as one broad category. For example, a marketing team using a public chatbot for copy drafts is not the same risk as a development team sending source code to an external model or a support function using AI to draft customer responses.

• Update acceptable-use rules to cover prompts, uploads, output handling, and prohibited data types.
• Extend privacy and confidentiality rules so personal data, customer data, and secrets cannot be shared casually with AI tools.
• Require human review for outputs that affect external communications, access decisions, hiring, finance, or legal positions.
• Apply vendor review to model providers, plug-ins, agents, and RAG pipelines, including retention and training-use terms.
• Log high-risk use cases so security, legal, and business owners can track approvals and exceptions.

For AI-specific risk framing, NIST AI guidance and the OWASP Top 10 for Large Language Model Applications help teams think about prompt injection, insecure output handling, and tool abuse. If the organisation is deploying autonomous agents, the governance model should also cover execution authority and approval boundaries, because an agent with tool access behaves more like a privileged system than a simple content generator. The practical test is whether someone can explain who owns the use case, what data is allowed, and how harmful output is intercepted before it matters.

These controls tend to break down when AI is embedded inside third-party SaaS workflows and the organisation cannot see the prompts, logs, retention settings, or downstream integrations.

Common Variations and Edge Cases

Tighter AI governance often increases friction for employees and delivery teams, requiring organisations to balance speed against review overhead. That tradeoff is real, especially where teams use AI for experimentation, prototyping, or low-risk drafting. Best practice is evolving, and there is no universal standard for every use case, so policy should be risk-based rather than binary. A blanket prohibition usually drives shadow use, while overly broad approval gates can stall legitimate work.

One common edge case is the difference between internal productivity use and customer-facing or regulated use. Low-risk drafting may only need tool approval and data restrictions, while high-impact decisions need stronger controls, documentation, and traceability. Another edge case is open-source or locally hosted models. Those reduce some data-transfer concerns, but they do not remove risks from prompt injection, model tampering, weak access controls, or unsafe outputs. Organisations should also treat AI agents differently from static models because agentic systems can take actions, chain tools, and persist state. The governance question is not just “Can the model answer?” but “What can the system do next?”

For identity and access-sensitive environments, the intersection with NHI governance becomes important when AI systems call APIs, use service accounts, or act on behalf of users. Those identities need ownership, rotation, and monitoring just like any other privileged credential. A useful reference point for broader security structuring is the NIST Cybersecurity Framework 2.0, which supports policy extension without forcing a separate AI bureaucracy. In practice, the organisations that do this well do not start with a massive AI policy; they start by making existing controls explicit for AI use.

Related resources from NHI Mgmt Group

• How should organisations govern shadow AI without blocking legitimate use?
• How should security teams use AI in secret scanning without creating new blind spots?
• How should security teams govern API keys used for generative AI access?
• Should organisations prioritise external exposure or internal credential governance first?