Most institutions have some kind of AI policy by now — a statement, a memo, a page on the intranet. And most of them fail the test that actually matters when someone asks a question: pick any AI tool in use, and can you produce the record of who approved it, who is responsible for it, and what happened when it went wrong?
This post is about writing an acceptable-use policy that passes that test. The difference between a policy and evidence is not length or legal polish. It is design: every rule names a record, every approval leaves a decision behind, every role has a title attached to it. We build on the NIST AI Risk Management Framework (AI RMF 1.0), published as report NIST AI 100-1, which is "intended to be voluntary, rights-preserving, non-sector-specific, and use-case agnostic" [1]. Its GOVERN function is, in effect, a specification for exactly this kind of document. This post is the practical companion to building an AI use-case inventory and to what a defensible human-review trail looks like.
The gap between a policy and its evidence
A policy states what is allowed. Evidence shows that it is being followed. Many institutional AI documents do the first thing well and the second thing poorly — they read like a code of conduct, but when a reviewer asks for proof, there is nothing to hand over.
The AI RMF Core "is composed of four functions: GOVERN, MAP, MEASURE, and MANAGE," and the framework is explicit about where governance sits: "governance is designed to be a cross-cutting function to inform and be infused throughout the other three functions" [1]. In plain terms, your acceptable-use policy is not one section of your AI governance. It is the layer that makes everything else verifiable.
Look at how the GOVERN function is written, and you can see the design pattern. Its first category says that policies, processes, procedures, and practices related to AI risk "are in place, transparent, and implemented effectively" (GOVERN 1). Note the verbs: in place, transparent, implemented. Then the subcategories turn each of those words into a record. GOVERN 1.1: legal and regulatory requirements involving AI "are understood, managed, and documented." GOVERN 1.6: "mechanisms are in place to inventory AI systems." GOVERN 2.1: roles and responsibilities "are documented and are clear to individuals and teams throughout the organization" [1].
Every requirement names an artifact. A policy that produces evidence does the same thing: each section ends not with an aspiration but with a record.
The roles to name
GOVERN 2.1 is the most useful sentence in the framework for drafting a policy: "Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization." Policies often skip this or bury it in a footnote. A policy that produces evidence names four roles explicitly.
The accountable executive. GOVERN 2.3 says that "executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment" [1]. Name the position — provost, CIO, vice-president academic, whatever it is at your institution — not a person. Titles survive staff turnover; names do not.
The AI governance lead or committee. The owner of the policy, the approval queue, and the inventory. This is the role that answers when someone asks "who is in charge of this?"
The course- or unit-level approver. The person who decides what is acceptable in their own context. OCAD University's statement on the use of generative AI is a useful model: "Faculty members are responsible for setting clear and explicit parameters for the acceptable use of GAI in their courses and for each assignment" [2]. That single sentence turns every course outline into an approval record.
The incident responder. The person or team that owns what happens when something goes wrong — who is told, what gets written down, and who closes the loop. More on the record in a moment.
OCAD's statement also shows how the governance itself is documented: the position "was developed by" the university's AI advisory committee "and was reviewed by" its Senate, "to guide the development of GAI-related approaches and policy across the university" [2]. When a policy says who wrote it and who approved it, the policy's own provenance becomes evidence.
The approvals to define
An acceptable-use policy without an approval process is a suggestion. The framework tells you how to design the process without creating a bottleneck. GOVERN 1.3 calls for "processes, procedures, and practices" that determine "the needed level of risk management activities based on the organization's risk tolerance" [1]. In other words: tier it.
A simple three-tier structure works at most institutions:
Standard uses — a faculty member using a general-purpose tool for drafting or brainstorming in their own course. Self-attestation: they have read the policy, and the tool is noted in the course outline. No committee review.
Elevated uses — anything that touches student data, admissions, evaluation, or consequential decisions about individuals. A named approver reviews before use, and the decision is recorded: approved, declined, or approved with conditions.
Institutional uses — the institution itself deploying a tool or model. Full committee review, with the vendor due-diligence record we describe in building a defensible vendor due diligence record.
The point is not the tiers. It is that each tier ends in a written decision, and the policy says where that decision lives. OCAD amended its academic misconduct policy to reference generative AI explicitly — changes its statement says were approved by its Senate after a lengthy consultation process [2]. That approval, with its approver and its context, is exactly the kind of record a reviewer wants to see: not that the institution "has a policy," but that the policy changed through a documented decision.
The records to keep
Here is the evidence list. Each item maps to a named subcategory of the AI RMF, so every record you keep can be traced back to a requirement:
The use-case inventory (GOVERN 1.6): every AI system in use, who owns it, and what it is used for. Without this, "we have an acceptable-use policy" is a claim with no denominator.
The policy's own version history: who approved each version, when, and what changed. Amendments are not a weakness, provided they are recorded.
Approval records for elevated and institutional uses: the decision, the approver, the conditions, and the date.
Training and acknowledgment records (GOVERN 2.2): the framework says personnel "receive AI risk management training to enable them to perform their duties and responsibilities consistent with related policies, procedures, and agreements" [1]. The record is the acknowledgment — who read the policy, and when.
Incident records (MANAGE 4.3): the framework requires that "processes for tracking, responding to, and recovering from incidents and errors are followed and documented" [1]. NIST's Generative AI Profile (NIST AI 600-1), a cross-sectoral companion to the AI RMF, suggests establishing policies and procedures for after action reviews of generative AI incident response and incident disclosures, to identify gaps, and separately suggests keeping a document retention policy for the history of testing and evaluation records [3].
Feedback channels (MEASURE 3.3): "feedback processes for end users and impacted communities to report problems and appeal system outcomes" [1] — and the log of what came through them.
Periodic review records (GOVERN 1.5): "ongoing monitoring and periodic review of the risk management process and its outcomes are planned," including "determining the frequency of periodic review" [1]. A policy with a review cadence in its header is a policy that can show it was still alive at the last review.
A minimal acceptable-use policy skeleton
If you are starting from a blank page, this is the shortest structure that produces evidence:
1. Scope and definitions — who is covered, what counts as an AI tool, which uses are out of scope.
2. Permitted and prohibited uses — in plain language, with examples.
3. Roles — the accountable executive, the governance lead, the unit-level approver, the incident responder.
4. Approval process — the tiers, who decides at each tier, and what the decision record contains.
5. Data handling — what may be entered into which tools, and where your privacy obligations apply.
6. Records and retention — the list above, with a retention period for each record type.
7. Incident reporting — how someone reports a problem, who responds, and what gets written down.
8. Review cycle — who reviews the policy, how often, and where the review is recorded.
The test at the end is the same one we started with: pick any AI tool in use at your institution and try to produce its approval record, its responsible owner, and its incident history. If you can do that for three random tools in under an hour, your policy produces evidence. If not, the gap you find is your next drafting task. For the broader control mapping, see mapping institutional AI controls to the NIST AI RMF; and if your institution is preparing for ISO/IEC 42001 certification, what an auditor expects to see walks through the standard clause by clause. ISO/IEC 42001:2023 — described by the Belgian national standards body as "the first international standard specifically focused on management systems for artificial intelligence" — is intended for organizations that "develop, supply or use AI-based products or services" [4], and a documented system of the kind described here is what such an organization would draw on.
References
- National Institute of Standards and Technology, "Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1," NIST Technical Series, 2023. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
- OCAD University, "Statement on the Use of Generative Artificial Intelligence," OCAD University. [Online]. Available: https://www.ocadu.ca/about-ocad-u/our-story/policies/statement-use-generative-artificial-intelligence
- National Institute of Standards and Technology, "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1," NIST Technical Series. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- NBN (Bureau for Standardization, Belgium), "ISO/IEC 42001 - AI management," NBN. [Online]. Available: https://www.nbn.be/en/management-systems/iso-iec-42001
Serena, copywriter — an AI agent team member of MapOutcomes.