How to draft an internal policy with AI

Convert the objective into decision rules

Begin with the policy objective and the harm or inconsistency it is intended to address. Define who and what is in scope, important terms, accountable roles, required actions, prohibited actions, exception authority, records to retain, and consequences for non-compliance. Keep unresolved choices visible instead of letting a model fill them.

A practical drafting map is:

| Policy element | Required input | Drafting question | |---|---|---| | Objective | Approved business purpose | What behavior must change? | | Scope | People, systems, activities | Where does the rule begin and end? | | Rule | Owner-approved control | What must someone do or avoid? | | Evidence | Record and custodian | How can operation be checked? | | Exception | Decision authority | Who may approve what, for how long? | | Enforcement | Response owner | What happens when the rule is missed? |

Ask AI to identify ambiguous verbs such as “appropriately,” “regularly,” or “where possible.” Replace them with a trigger, actor, action, deadline, and record where the organization can support those details.

Work a policy fragment through a real workflow

Suppose a fictional company is drafting a policy for external AI tools. A generic clause—“Employees should use AI responsibly and protect sensitive data”—does not tell a project lead what to do.

A more operable synthetic fragment might read:

> Before entering company information into an external AI tool, the user must confirm that the tool appears on the approved-services list and that the information classification is permitted for that service. If either condition is unknown, the user pauses submission and sends the request to the Security Operations queue. The queue owner records the decision, scope, expiry date, and any handling conditions.

This fragment names the trigger, actor, decision source, stop condition, escalation route, and evidence record. It still requires review by the organization’s security, privacy, legal, and operational owners. It is an educational example, not a statement about any real company or legal obligation.

Test normal and exception paths

Walk the draft through several cases: an ordinary approved use, a prohibited use, an urgent request, a contractor, an unavailable approver, a rule violation, and an expired exception. For each case, ask who acts, what information they need, how long the decision lasts, and which record proves completion.

NIST’s AI Risk Management Framework provides a voluntary structure for governing, mapping, measuring, and managing AI risk. The UK Orange Book discusses governance, risk ownership, controls, assurance, and continual improvement in its public-sector context. They are useful structural references, not substitutes for the organization’s obligations or counsel.

A failure example is an exception clause stating that “management may approve special cases.” It omits which manager, decision criteria, time limits, documentation, and review. Repair it with an authority matrix and an exception record rather than more polished prose.

Verify the policy draft

Before approval, verify that:

Keep a source map beside the draft showing which approved input supports each section. Record open decisions and named approvers. The final artifact is the policy draft plus the scenario-test log, exception matrix, and approval record.

• the objective maps to concrete rules;
• scope boundaries and definitions resolve likely ambiguity;
• every rule has an actor, trigger, action, and evidence record;
• exceptions identify authority, criteria, duration, and review;
• enforcement and escalation routes exist in the actual operating model;
• referenced systems, teams, and forms exist;
• scenario tests cover both routine and difficult cases; and
• AI-generated language introduces no invented control, obligation, or capability.

Sources

NIST AI Risk Management Framework

• The Orange Book: Management of Risk

Sources: [1] [2]