AI Governance Checklist: 12 Things Every Team Should Do Before Using AI at Work

Published: August 2026

In most organizations, AI tools arrive before AI governance does. A team starts pasting text into a chatbot, a vendor switches on an "AI-powered" feature inside software you already own, someone wires a model into a workflow — and only later does anyone ask who owns it, what data went in, what uses were approved, and whether anybody is watching the outputs. By then the answers have to be reconstructed instead of retrieved.

This checklist is the short version of doing it in the right order. Twelve checks, each with why it matters, one practical action, the question a governance reviewer should ask, and the evidence worth retaining. It draws on four widely used references — the voluntary NIST AI Risk Management Framework, the voluntary ISO/IEC 42001 management-system standard, the binding EU AI Act, and the OWASP Top 10 for LLM Applications — with a mapping table at the end.

Educational content only — not legal, regulatory, security or certification advice. Prepared with AI assistance and reviewed against the official sources linked in this article.

First, know what kind of rules these are

One distinction keeps this whole topic honest. The NIST AI RMF 1.0, released on 26 January 2023, is explicitly intended for voluntary use — it is not a law and imposes no legal obligations. It organizes AI risk work into four functions: Govern, Map, Measure and Manage, and NIST notes the framework is currently undergoing revision. Its companion Generative AI Profile (NIST AI 600-1), published 26 July 2024, helps organizations identify risks unique to or exacerbated by generative AI and suggests risk-management actions. ISO/IEC 42001:2023, published in December 2023, specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS); ISO calls it the world's first AI management system standard. It is a voluntary standard you can be audited and certified against — it is not legislation.

The EU AI Act is different: it is binding law. It entered into force on 1 August 2024 and became generally applicable on 2 August 2026, with a four-tier risk structure — prohibited practices (such as harmful manipulation and social scoring), high-risk systems with strict obligations (risk assessment, data quality, human oversight), limited-risk transparency duties (disclosing that people are interacting with AI, labeling deepfakes), and minimal-risk systems with no specific rules. Prohibited practices and AI literacy obligations have applied since 2 February 2025, governance rules and obligations for general-purpose AI models since 2 August 2025, and transparency rules came into effect in August 2026. Most high-risk obligations were deferred by a simplification amendment that entered into force on 27 July 2026: they apply from 2 December 2027 for certain high-risk areas and from 2 August 2028 for AI embedded in regulated products — the runway we covered in our December 2027 deadline article.

Finally, the OWASP GenAI Security Project's Top 10 for LLM Applications (2025) is a community security reference — the security half of several checks below leans on it.

The 12-point checklist

1. Define the use case and the outcome you expect

• Why it matters: "We're using AI" is not a use case. Without a defined purpose and an expected outcome, nobody can judge whether the tool is working, drifting, or being used for something it was never assessed for.
• One practical action: Write a one-paragraph statement: what the AI does, for whom, and what a good outcome looks like. If you cannot write it, you are not ready to deploy it.
• A reviewer should ask: "What was this system approved to do, and how would we know it is doing it well?"
• Evidence to retain: The written use-case statement, dated, with the intended outcome and scope boundaries.

2. Name an accountable business owner

• Why it matters: AI systems without owners drift. When something goes wrong, "the vendor" and "IT" both point elsewhere. Accountability has to sit with a person who can make decisions about the system.
• One practical action: Assign a named business owner — not a committee — who approves the use case and accepts the risk level.
• A reviewer should ask: "Who is the accountable owner, and did they formally accept this system's risk?"
• Evidence to retain: The owner's name and role, and their dated approval of the use case and risk level.

3. Record the model, vendor and system details

• Why it matters: You cannot govern what you have not written down. Which model, which version, which vendor, what integrations — these facts decide what risks apply, and they change over time.
• One practical action: Create an entry in a central AI register: system name, vendor, model and version, hosting location, integrations, and data flows. Our free AI risk register template gives you the columns.
• A reviewer should ask: "Is there a single register entry that describes this system accurately today?"
• Evidence to retain: The register entry itself, with a last-reviewed date.

4. Classify data before it goes in

• Why it matters: The fastest way to turn a productivity tool into an incident is to paste confidential, personal or regulated data into it. OWASP lists sensitive information disclosure (LLM02) among its Top 10 risks for LLM applications for a reason.
• One practical action: Decide — per data class, not per person — what may and may not enter the tool: public, internal, confidential, personal data, regulated data. Publish the decision where users will actually see it.
• A reviewer should ask: "What data classes are permitted in this system, and how would we detect a violation?"
• Evidence to retain: The data classification decision, the permitted/prohibited data list, and the date it was communicated to users.

5. Assess impact and assign a risk level

• Why it matters: A meeting-notes summarizer and a system that influences decisions about people do not deserve the same scrutiny. Risk-tiering is also the EU AI Act's core structure — the law attaches obligations by risk tier, so knowing your tier is the first legal question, not an optional extra.
• One practical action: Score each system on who is affected and how badly a wrong output could hurt them, then assign a risk level that determines the depth of the remaining checks.
• A reviewer should ask: "What risk level was assigned, on what basis, and would the EU AI Act's tiers classify it differently?"
• Evidence to retain: The impact assessment and the assigned risk level, with the reasoning.

6. Define acceptable and prohibited use

• Why it matters: Tools approved for one purpose get quietly reused for others. Without explicit boundaries, "approved" silently becomes "approved for everything".
• One practical action: Write short acceptable-use rules for the system: approved tasks, prohibited tasks, and what must never be automated without human sign-off.
• A reviewer should ask: "Where are the acceptable-use rules, and how were they communicated to the people using the system?"
• Evidence to retain: The acceptable-use rules and the communication record (announcement, training, onboarding note).

7. Establish human review and override

• Why it matters: Somebody has to be able to catch a wrong output before it causes harm — and be able to overrule the system. Human oversight is also among the obligations the EU AI Act attaches to high-risk systems.
• One practical action: Define which outputs require human review before they take effect, who performs it, and how the system's decision can be overridden or reversed.
• A reviewer should ask: "Show me the last time a human corrected or overrode this system — where is that recorded?"
• Evidence to retain: The review-and-override procedure, plus samples of review records showing it operates in practice.

8. Test for accuracy, bias, safety and failure modes

• Why it matters: A demo is not a test. Systems behave differently on your data, your edge cases, and your adversarial users than they did in the sales call. OWASP's 2025 list includes misinformation (LLM09) and improper output handling (LLM05) — failure modes you find by testing, not by hoping.
• One practical action: Before go-live, run a structured test on representative cases: accuracy against known answers, behavior across relevant user groups, response to bad or malicious input, and what happens when the system fails.
• A reviewer should ask: "What testing was done before deployment, and what were the documented results?"
• Evidence to retain: The test plan, the results, the issues found, and the go-live decision that weighed them.

9. Secure access, prompts, integrations and credentials

• Why it matters: AI systems add attack surface. OWASP's 2025 Top 10 for LLM Applications names prompt injection (LLM01) as the top risk, alongside supply-chain vulnerabilities via models and components (LLM03), system prompt leakage (LLM07) and excessive agency (LLM06) — an AI integration granted more autonomy and permissions than its task requires.
• One practical action: Apply least privilege to the AI system itself: restrict who can use it, what data and tools it can reach, and keep credentials and API keys out of prompts entirely. Treat every integration the system can trigger as part of its risk assessment. Our own security posture is documented in the Trust Center.
• A reviewer should ask: "What can this system reach — data, tools, credentials — and what is the worst it could do if manipulated through its inputs?"
• Evidence to retain: The access-control configuration, the list of integrations and their permissions, and the security review that considered prompt-injection and supply-chain risks.

10. Monitor outputs, incidents, changes and vendor updates

• Why it matters: AI systems change under you. Vendors swap models, retrain, and ship new features into tools you already approved. Yesterday's assessment describes yesterday's system.
• One practical action: Set up a lightweight monitoring routine: periodic output sampling, an incident log anyone can add to, and a subscription to vendor change notices — with a trigger to reassess when something material changes.
• A reviewer should ask: "Who reviewed this system's outputs last month, and what vendor changes have shipped since the last assessment?"
• Evidence to retain: Monitoring records, the incident log, and notes on vendor updates reviewed.

11. Preserve decisions, approvals, tests and evidence

• Why it matters: Every framework in the mapping below expects documented oversight — named owners, review records, evidence. Verbal assurances and buried chat threads satisfy none of them. Evidence you cannot find is evidence you do not have.
• One practical action: Keep the artifacts from checks 1–10 in one findable place per system — the register entry is the natural anchor — so a reviewer gets answers in minutes, not archaeology.
• A reviewer should ask: "For this system, show me the approval, the risk assessment and the last test — without reconstructing them."
• Evidence to retain: This is the evidence: the organized set itself, with dates and owners on each artifact.

12. Reassess periodically and before material changes

• Why it matters: Governance is a loop, not a gate. ISO/IEC 42001 is built around continually improving a management system, NIST's Manage function is ongoing by design, and the EU AI Act's obligations keep phasing in through 2027 and 2028 — a one-time sign-off ages fast.
• One practical action: Put a reassessment date on every register entry, and define the triggers that force an early one: new model version, new data source, new user group, expanded use case, significant vendor update.
• A reviewer should ask: "When was this system last reassessed, and what would trigger the next review before that date?"
• Evidence to retain: The reassessment schedule, the trigger list, and the record of the most recent review.

How the 12 checks map to NIST AI RMF, ISO/IEC 42001, the EU AI Act and OWASP

This is an educational mapping to help you see how one set of working practices relates to four different references. It is not a certification claim, a legal determination, or a statement of compliance with any framework or law.

If you want the deeper per-framework treatment, we keep dedicated guides: NIST AI RMF from Jira, ISO 42001 from Jira and EU AI Act from Jira.

Three fictional walk-throughs

All three examples below are fictional. They describe made-up organizations, invented purely to illustrate how the checklist changes emphasis by context. They are not customers, case studies, or measured results.

Fictional example 1: a healthcare support chatbot

A fictional clinic group wants a chatbot answering patients' administrative questions — opening hours, appointment rescheduling, billing queries. The checklist bites hardest at checks 4, 6 and 7: patient messages can contain health information, so the data classification decision (check 4) must be made before launch, not after; acceptable use (check 6) must prohibit the bot from giving anything resembling medical advice; and human review (check 7) needs a clear escalation path to staff the moment a conversation leaves administrative territory. The risk level (check 5) lands higher than "it's just a support bot" suggests — because of who is affected when it goes wrong.

Fictional example 2: a financial-services document assistant

A fictional lender deploys an assistant that summarizes and extracts fields from customer-submitted documents — proof of address, income statements — for back-office staff. This is document-processing governance, and the emphasis falls on checks 4, 8 and 11: the documents are confidential and personal by default, so data boundaries and access control come first; extraction accuracy must be tested against known documents before anyone relies on it (check 8), because a mis-read field propagates into downstream decisions; and every extraction that feeds a decision about a customer needs retained evidence of human verification (check 11). The assistant drafts and extracts — people decide.

Fictional example 3: a manufacturing predictive-maintenance model

A fictional plant operator uses a model predicting which machines need maintenance before failure. Here checks 2, 10 and 12 carry the weight: the accountable owner (check 2) must be someone who can act on predictions — a maintenance lead, not a data team with no authority over the schedule; monitoring (check 10) must track prediction accuracy against actual failures, because sensor drift and changed operating conditions degrade models silently; and reassessment triggers (check 12) must include physical changes — new equipment, new sensors, changed shift patterns — not just software updates. A wrong prediction here costs money and, in the worst case, safety margins.

Frequently asked

Who should own an AI system inside a business? A named business owner who is accountable for the system's outcomes — not a committee and not "IT" in general. The owner approves the use case, accepts the risk level, and is the person a reviewer or auditor contacts first.

What evidence should an AI-governance review retain? The approved use case, the named owner, the system record, the data classification decision, the risk assessment, testing results, acceptable-use rules, monitoring and incident logs, and dated approvals — kept where a reviewer can find them without reconstructing history from chat threads.

Do voluntary frameworks like NIST AI RMF or ISO/IEC 42001 make this checklist mandatory? No. NIST AI RMF is a voluntary framework and ISO/IEC 42001 is a voluntary management-system standard — neither is law. The EU AI Act is law, and where it applies its obligations are binding regardless of which voluntary framework you follow.

When should an AI system be reassessed? On a defined schedule — for example annually — and additionally before any material change: a new model version, a new data source, a new user group, an expanded use case, or a significant vendor update.