How to stand up AI governance policies from templates

To stand up AI governance policies from templates, start with a small core set, generate each policy from a template tailored to the AI systems you run and the risks you have found, and have the accountable owner review and adopt it. This guide covers the three parts of the job. It sets out what policies a programme actually needs and how to build them from templates instead of drafting by hand. It then covers the part most people skip, which is how to keep them current once they exist.

What an AI governance programme’s policy layer needs

A policy pack does not need to be long to be useful. It needs to cover the decisions your organisation keeps having to make about AI, so that people are not making them case by case. ISO/IEC 42001 requires a top-level AI policy (clause 5.2) and lists the policies that sit under it as Annex A controls. The NIST AI RMF puts policies, processes and accountability under its Govern function. In practice the core set is small.

• AI acceptable use policy. The umbrella document. Who can use AI, for what, what is acceptable, what is prohibited, where a use has to be reviewed before it goes ahead, and who owns AI governance.
• AI risk assessment policy. When an assessment is required, the rating scale and tolerance, and who may accept a risk that stays above it.
• AI ethics and human rights policy. How the organisation treats fairness, human oversight and the people affected by its AI, including how someone can challenge an outcome.
• AI data governance policy. What data can go into which systems, the limits on how it is used, and how data quality and provenance (where the data came from) are checked.
• AI incident response plan. What counts as an AI incident, who is called, how it is contained and investigated, and when notification is considered.
• AI transparency statement. When and how the organisation tells people that AI is being used, and what it says about it.

Procurement is usually handled with a vendor due diligence checklist rather than a policy, setting out what has to be checked before an AI product or an AI feature inside existing software is adopted.

These cover the ground the major frameworks are built on, which is accountability, transparency, fairness, privacy and security, human oversight and safety. A set that covers the list above is grounded in those principles rather than in one author’s judgement.

Build each policy from a template, not a blank page

A policy written from scratch is slow to produce and hard to keep consistent with the rest of the programme. A pack commissioned from a consultant arrives complete and then starts to age from the day it lands, because it is not connected to how your AI use actually changes. Starting from templates avoids both problems.

1. Register the AI systems you have. Policies written against a guess at the footprint miss what is really in use. The AI system register guide covers this step.
2. Open the policy templates. Each template already carries the structure and the expected content for its policy type, so you are editing a grounded draft, not composing one.
3. Generate each policy from its template. Tailor the draft to your registered systems and to the risk assessments and controls the programme has already produced, so the document reflects your organisation rather than a generic sample.
4. Review and adopt. The generated policy is a draft for review. You and the accountable owner read it, adjust it and decide whether to adopt it. That decision stays with your people.

Done this way, standing up the policy layer is a matter of review and sign-off, not months of drafting.

Keep the policies current as your AI use changes

This is the part that gets skipped, and it decides whether the policy layer is worth anything a year in. AI use inside an organisation moves. New tools arrive, existing tools gain features and the frameworks themselves are revised. A policy that was accurate when it was written drifts out of step with the footprint it was meant to govern, and a one-off pack has no way of noticing.

Keep the policies connected to the register, the risk assessments and the controls. When your registered footprint changes, or when a policy needs to reflect a new control, review the affected policies against the frameworks you govern against and record what changed. Set a review rhythm regardless. An accountable owner should look over the set on a fixed schedule and after any material change to your AI use, and record that the review happened.

A policy states intent and relies on people reading it. Where a rule must hold whether or not anyone read the policy, such as keeping personal information out of prompts, it belongs in a guardrail as well. The guardrails guide covers that step.

Where this sits in the programme

Policies read from the same register and risk picture as your controls and your risk register, which is why they can be generated and kept current rather than written and forgotten. If you are building the programme in order, the risk assessments and the controls come first, and the policies are written against them.

How Aicura fits

From Essentials, Aicura carries a template for each of the six policy types above and for the vendor due diligence checklist. A generated policy is a first draft to review, never a finished document. Once you publish it into governance policies, each one is scanned against the frameworks you choose for that review type in Settings, and what the scan finds comes back as recommendations. A coverage figure shows how many of the six types have a policy, so a missing incident response plan is visible on the dashboard rather than discovered in an audit. At Pro, the Cadence view, which tracks when governance work is next due, shows how long ago each policy was last scanned and marks it Aging or Stale as it falls behind.

Aicura provides governance support, not legal advice, and it does not certify or sign off a policy. The decision to adopt sits with you and the accountable owner.

In Australia

The National AI Centre’s Guidance for AI Adoption (AI6, October 2025), published by the Department of Industry, Science and Resources, superseded the Voluntary AI Safety Standard and is published with an AI policy template. NSW Government agencies work under the NSW AI Assessment Framework, and Commonwealth agencies under the DTA’s policy for the responsible use of AI in government, which sets its own accountability and transparency statement requirements. A policy set built on the core list above covers the ground all three expect. See the Guidance for AI Adoption, NSW AI Assessment Framework and DTA AI policy pages.

A note on this page

This guide is written to help you do the work. It is guidance, not legal advice, and it is not a certification, an audit or a compliance verdict. For the requirements themselves, go to the primary sources, including ISO/IEC 42001:2023 and the NIST AI Risk Management Framework. Where your organisation needs a formal legal or regulatory view of its obligations, get advice that is specific to your circumstances.