What AI do we actually have? What are people and systems allowed to do with it? And do the people operating it understand enough to use it safely, recognize limits, and escalate problems?
Those questions point to three connected controls: an AI inventory, an acceptable-use approach, and AI literacy. The inventory creates visibility. Acceptable use creates boundaries. Literacy gives people the knowledge and judgment needed to operate inside those boundaries. None of the three, by itself, proves that an AI system is safe, fair, secure, or lawful. Together, they create a practical starting layer for ongoing governance.
Imagine a fictional company, Northstar Services, introducing an internal assistant that can answer questions from approved business documents. Six months later, the same assistant can also update selected records and send internal messages. A simple “we allow AI” statement is no longer enough. The organization needs to know which system is deployed, where it may be used, what actions it can trigger, who is accountable, and what people must understand before they use it.
Do not govern “AI” as an abstract technology. Govern identifiable AI uses, with identifiable owners, boundaries, evidence, and review points.
| Control | Main question | Typical owner | Useful evidence |
|---|---|---|---|
| AI inventory | What AI use or system exists, where, and with what scope? | AI system owner or governance function | Inventory record, ownership, dependencies, review date |
| Acceptable use | What may, may not, and must not happen? | Policy owner with business, legal, security and risk input | Approved-use rules, exceptions, enforcement and escalation records |
| AI literacy | What must each role understand to use or oversee the AI responsibly? | Business owner / learning function / AI governance | Role-based learning records, guidance, acknowledgements, exercises |
01
AI Inventory: Knowing What Exists
Think about a school that suddenly discovers there are 30 different “special rooms,” but nobody has a map. Some rooms contain chemicals, some contain computers, and some contain nothing important. The first governance problem is not deciding what happens in every room. It is knowing which rooms exist and what each one is for.
An AI inventory is the organizational record that makes AI uses visible and attributable. NIST’s AI RMF Playbook explicitly identifies mechanisms to inventory AI systems and describes an inventory as a collection of artifacts that can include system documentation, incident-response information, data dictionaries, implementation references, and the identities of relevant AI actors. NIST also connects inventorying to a holistic view of organizational AI assets. NIST AI RMF Playbook — Govern
The important governance insight is that an inventory should describe the system or use, not merely the model name. A single foundation model can sit behind many applications with different data, users, permissions, workflows, and impact profiles. Governance that records only “we use Model X” can therefore be too coarse to support a meaningful risk decision.
The following is a fictional record. Its fields are a practical recommendation, not a claim that NIST or ISO requires this exact template.
Name: Internal Operations Assistant
Purpose: Answer questions from approved internal procedure documents
Users: Operations employees; supervised pilot group
Provider/model: External model service, version recorded in procurement record
Data: Approved business documents; no unrestricted customer records
Tools/actions: Read approved knowledge source; no write actions in pilot
Human role: User verifies important answers before acting
Impact class: Medium — preliminary internal assessment
Owner: Operations Product Owner
Risk owner: Business Risk Manager
Policy status: Approved for defined use only
Literacy audience: End users, support staff, owner, reviewers
Last review: 2026-09-15
Next review trigger: Scope, model, tool or data change
Incident path: AI Operations Queue → Risk Owner → Security/Legal as applicable
Notice what is deliberately absent: a promise that the model is “accurate,” “safe,” or “compliant.” Those are conclusions that require evidence. The inventory instead records the conditions under which the system exists and the people who are accountable for it.
A practical inventory should usually answer: what is the purpose; who uses it; who owns the decision; what data enters and leaves; which external providers are involved; what tools or actions are available; what human oversight exists; what population can be affected; what approvals are required; what evidence is retained; and what changes force reassessment.
Risk → Control → Evidence → Remaining risk
Risk: An undocumented AI tool is used for a consequential business task.
Control: Require AI uses to be registered before production use, with an owner, purpose, data scope, permissions, and review triggers.
Evidence: A versioned inventory record plus approval and change history.
Remaining risk: A tool may still be misused or change between reviews. Inventory creates visibility; it does not replace monitoring or technical controls.
An organization has many AI experiments, SaaS assistants, embedded AI features, departmental tools, or agentic workflows and leadership cannot confidently answer “what AI are we running, and who owns each use?”
02
Acceptable Use: Turning Principles into Boundaries
A sign saying “use the playground responsibly” is a principle. A rule saying “do not climb outside the marked area; ask an adult before opening the maintenance gate” creates boundaries people can actually follow. Acceptable-use governance has the same job: turn broad intent into decisions that people can apply.
There is no single universal acceptable-use rulebook for every organization and AI use. In practice, an acceptable-use policy is an internal governance control that should reflect the organization's risk appetite, legal obligations, contracts, security requirements, data rules, and the actual capabilities of the AI system.
NIST’s AI RMF encourages organizations to understand intended purpose, context, users, possible impacts, limitations, and organizational risk tolerance. It also warns that broadly deployed AI tools can be reused, repurposed, or misused beyond original intentions. That makes “purpose plus boundary” more useful than a blanket statement such as “employees may use AI for productivity.” NIST AI RMF Playbook — Map
A good acceptable-use approach normally separates three categories:
| Category | What it means | Governance example |
|---|---|---|
| Allowed | Uses permitted under defined conditions | Drafting internal summaries from approved, non-sensitive content |
| Restricted | Uses requiring extra controls, approvals, or a specific environment | Processing confidential information only through an approved enterprise service |
| Prohibited | Uses the organization will not permit | Using an unapproved public tool to disclose protected customer information |
The strongest policies also distinguish use restrictions from decision restrictions. For example, “you may use an assistant to draft a recommendation” is different from “the assistant may make the final decision.” The second statement concerns authority and accountability, not just tool usage.
ALLOWED: Use approved AI assistants for drafting, summarization, brainstorming and knowledge discovery when the source data is permitted for that service.
RESTRICTED: Use AI outputs in customer, financial, employment or operational workflows only when the workflow owner has approved the use and the required human review is present.
PROHIBITED: Enter protected information into an unapproved AI service; delegate final consequential decisions to an AI system when policy requires a human decision-maker; bypass a configured approval or access-control step.
ESCALATE: Report material AI errors, unexpected tool actions, suspected data exposure, or policy conflicts through the defined incident path.
This is an illustrative policy excerpt, not a legally sufficient template. The important design pattern is rule + condition + exception/approval + enforcement + escalation.
People understand that “AI may help” but disagree about what data may be shared, what decisions may be delegated, or when a human must verify an output.
03
AI Literacy: Making Policy Usable
Imagine giving someone a bicycle with a card that says “Ride safely.” That card is useful, but the rider still needs to know how brakes work, what a warning sign means, and when not to ride. AI literacy is the capability layer that helps people turn rules into responsible action.
AI literacy is broader than “attend an AI training.” It includes the knowledge, skills, judgment, and practical understanding relevant to a person’s role. NIST’s AI RMF connects governance to training, role clarity, organizational policies, risk awareness, and proficiency for different groups of AI actors. NIST AI RMF Playbook — Govern
The EU AI Act provides a current legal example. Article 4, as amended in 2026, requires providers and deployers to take measures to support the development of AI literacy for staff and other people dealing with AI systems on their behalf, taking account of technical knowledge, experience, education, training, and the context in which the AI system is used. The amended provision does not require organizations to guarantee a specific literacy level for an individual. The Commission states that Article 4 entered application on 2 February 2025, and supervision and enforcement rules apply from 3 August 2026. EU Regulation 2026/1744 amending Article 4 · EU AI Office AI Literacy Q&A
That is an important governance lesson: literacy should be proportional to role and context. A casual user of a low-impact drafting tool does not need the same depth as a developer, operator, risk reviewer, or person responsible for a system that can take external actions.
| Role | What to understand | Useful practice | Evidence |
|---|---|---|---|
| Everyday user | Purpose, limitations, prohibited data, verification expectations | Short scenario-based learning | Guidance acknowledgement or practical exercise |
| System operator | Failure modes, monitoring, permissions, change triggers, escalation | Runbook drills and incident scenarios | Operational exercises and review record |
| Developer / builder | System boundaries, data flows, evaluations, tool permissions, security and safety risks | Design reviews and risk-focused testing | Review and test evidence |
| Oversight / risk reviewer | Risk criteria, evidence quality, role accountability, impact and residual risk | Case review and challenge sessions | Assessment record and decision rationale |
A mature literacy program therefore does not ask, “Did everyone take the same one-hour course?” It asks, “What decisions does this person make around AI, what could go wrong if they misunderstand the system, and what evidence shows that the required capability exists?”
Risk → Control → Evidence → Remaining risk
Risk: Users know the policy exists but cannot recognize a risky output, unsafe data use, or an unexpected AI action.
Control: Provide role-specific learning using realistic scenarios, system limitations, escalation instructions, and examples of prohibited or restricted use.
Evidence: Learning records, scenario results, acknowledgements, and periodic review of whether the material still matches the system.
Remaining risk: Training does not eliminate human error, automation bias, or deliberate misuse. Technical controls and oversight remain necessary.
04
How the Three Controls Reinforce Each Other
The most useful way to think about these controls is as a chain:
↓ tells us what exists, who owns it, and what has changed
Acceptable Use
↓ tells people and systems what is permitted, restricted, or prohibited
AI Literacy
↓ gives people the knowledge to apply those boundaries and recognize exceptions
Operational Evidence
↓ shows whether the control actually operated
Reassessment
↺ updates the inventory, policy and learning when the system changes
This loop matters because AI governance is not a one-time approval. A model can change. A vendor can change a service. A new connector can add write permissions. A business team can broaden the user population. A previously harmless assistant can become consequential once it starts taking actions.
A useful change trigger is capability-based, not only calendar-based. A new tool permission, data class, user group, model/provider, decision role, or deployment geography can be more important than the passage of a fixed number of days.
NIST’s AI RMF also emphasizes continuing risk management as context, capabilities, risks, benefits, and impacts evolve. Its Playbook is voluntary, and NIST is currently updating the AI RMF 1.0-based Playbook. That means organizations should treat the framework as a living governance aid rather than a permanent checklist. NIST AI RMF Playbook
05
A Worked Governance Example
Consider the fictional Northstar Services assistant again. The company wants to expand it from question answering into a controlled workflow where it can propose an update to a service record and draft a message for a human operator to send.
Step 1 — Inventory update. The existing record is updated to show the new action capability, data path, user group, and external dependency.
Step 2 — Use classification. The organization decides that proposing an update is allowed in the workflow, but committing the update remains a human-authorized action.
Step 3 — Control design. The application shows the proposed change, requires the authorized user to confirm it, and records the outcome.
Step 4 — Literacy update. Operators learn not only how to click “approve,” but how to recognize when the assistant's evidence is incomplete, when the proposed change conflicts with policy, and when to escalate.
Step 5 — Evidence. The organization retains the approval record, relevant system version, user role, decision outcome, and incident path.
The distinction between human presence and meaningful human oversight is important here. A person who clicks a button without understanding the task, without sufficient information, or without authority may not provide meaningful governance merely because a human was physically involved.
Risk → Control → Evidence → Remaining risk
Risk: An operator rubber-stamps AI-generated actions because the interface makes the recommendation look authoritative.
Control: Require enough context for review, preserve the proposed change separately from the committed change, define who has decision authority, and train operators on known failure modes.
Evidence: Review records, sample audits, exception/escalation records, and change history.
Remaining risk: Reviewers can still make mistakes, and system behavior can drift. Oversight must therefore remain part of ongoing monitoring.
06
Implementation in Practice
A practical rollout does not need a giant enterprise program on day one. Start with a repeatable path for getting from “someone is using AI” to “the organization understands and governs that use.”
02 Record → create an inventory entry with an accountable owner
03 Classify → understand purpose, users, data, actions, impacts and constraints
04 Bound → define allowed, restricted and prohibited uses
05 Enable → give each role the knowledge needed for its decisions
06 Evidence → retain approvals, training, assessments, changes and incidents
07 Review → reassess after material changes, incidents or changed context
Step 1 — Discover. Look beyond centrally procured models. Departmental SaaS features, embedded copilots, vendor workflows, prototypes, open-source components, and AI functions inside existing enterprise software can all matter.
Step 2 — Record. Use one recognizable inventory identity for each governed AI use. Link it to owners, vendors, documentation and relevant evidence rather than maintaining a disconnected spreadsheet that nobody can reconcile.
Step 3 — Classify. Ask what the AI is actually doing, what could be affected, which data and actions are involved, and what role humans play. NIST's AI RMF encourages documenting intended purpose, context, users, benefits, risks, system task and limitations as part of mapping. NIST AI RMF Playbook — Map
Step 4 — Bound. Write rules that map to actual behaviors: which data can be submitted, which tools can be called, which decisions can be supported, which actions require approval, and what must be escalated.
Step 5 — Enable. Create role-specific learning. A short user briefing may be enough for a low-impact writing assistant; a system operator may need deeper instruction on incidents and changes; a reviewer may need evidence interpretation and challenge skills.
Step 6 — Evidence. Evidence should demonstrate that a control operated, not simply that a policy document exists. Examples include an inventory entry, approval record, access rule, training acknowledgement, evaluation result, change record, incident ticket, or review note.
Step 7 — Review. Define reassessment triggers. For example: a new model provider; a new data class; a new external connector; a new user population; a new geography; a new automated decision; a change in business purpose; or a material incident.
| Decision point | Evidence to look for | Escalate when... |
|---|---|---|
| Should this AI use be registered? | Clear purpose, owner, data and user scope | Owner or scope is unclear |
| Can the proposed use proceed? | Risk decision, applicable constraints, control plan | Risk exceeds tolerance or evidence is incomplete |
| Are users ready? | Role-specific guidance and demonstrated understanding | Role requires capability not covered by training |
| Did the system materially change? | Version, configuration and dependency history | New actions, data, users or impacts appear |
07
Common Mistakes
1. Mistake: inventorying only models.
Why it happens: model names are easy to collect.
Why it matters: risk often depends on the application, data, tools, users and decisions around the model.
Correction: inventory the governed AI use or system and record the model/provider as one dependency.
2. Mistake: writing “do not misuse AI” as the acceptable-use policy.
Why it happens: the intent sounds obvious.
Why it matters: users need operational boundaries, not slogans.
Correction: specify allowed, restricted and prohibited uses, required approvals and escalation paths.
3. Mistake: treating a training completion percentage as proof of literacy.
Why it happens: completion is easy to report.
Why it matters: a completed course does not demonstrate that a user can recognize a risky output or follow an approval rule in practice.
Correction: use role-based scenarios, practical checks or other evidence proportionate to the risk.
4. Mistake: keeping the policy separate from the system design.
Why it happens: governance documents are owned by one team while tools are built elsewhere.
Why it matters: a policy may prohibit an action that the application still technically enables.
Correction: translate key policy statements into enforceable technical or procedural controls where feasible.
5. Mistake: assuming the vendor's description is your governance decision.
Why it happens: vendors know their own product best.
Why it matters: the same service can create different risks in different deployments.
Correction: validate the deployed system, its context, permissions, data, users and evidence independently.
6. Mistake: forgetting people affected by the AI.
Why it happens: inventory and policy exercises can become internally focused.
Why it matters: people outside the AI team may bear the consequences.
Correction: identify affected people and relevant feedback, transparency, contestability or remedy mechanisms where the use warrants them.
7. Mistake: reviewing only once.
Why it happens: governance is treated like a launch gate.
Why it matters: AI systems, providers, permissions and contexts change.
Correction: define event-based reassessment triggers and keep inventory, policy and literacy materials aligned with the current system.
08
❓ FAQ
No. An approved-tool list can tell employees which products may be used. An AI inventory is broader: it identifies governed AI uses or systems, their purpose, owner, data, users, dependencies, controls and review information. One approved provider can support multiple systems with different risk profiles.
Not necessarily. Governance should be proportionate to context and risk. A low-impact drafting tool may need a lighter path than a system that processes sensitive data, influences consequential decisions, or can take external actions. The important requirement is that the organization can explain why the control level is appropriate.
No. Prompting can be useful, but governance-oriented literacy also covers system purpose, limitations, data handling, permitted use, verification, human responsibilities, security or safety considerations that are relevant to the use case, and escalation when something goes wrong.
No. As of the 2026 amendment to Article 4, providers and deployers must take measures to support AI literacy for relevant staff and other persons dealing with AI systems on their behalf, while considering their knowledge, experience, education, training and context. The amended provision does not require a specific literacy level for each individual. High-risk AI uses can bring additional, specific human-oversight training obligations under other provisions, so the exact legal analysis depends on the deployment.
There is no single universal artifact. A stronger evidence trail connects the inventory record, the governing decision, the implemented control, the role-specific learning or guidance, and the evidence produced during operation. That chain makes it easier to explain who decided, what was permitted, what was actually done, and what changed later.
09
🔗 References & Further Reading
NIST AI Risk Management Framework (AI RMF 1.0) — voluntary framework for managing AI risks across Govern, Map, Measure and Manage. Official NIST page
NIST AI RMF Playbook — Govern — includes AI inventory and role/training guidance used to support this article. Official Playbook section
NIST AI RMF Playbook — Map — used for intended purpose, context, risk tolerance, system scope and affected-party considerations. Official Playbook section
EU Regulation 2026/1744 — current amendment to Article 4 on AI literacy. Official EUR-Lex text
European Commission — AI Literacy Q&A — official explanation of Article 4, role-based approaches, evidence and enforcement information. Official Commission Q&A
OECD AI Principles — intergovernmental principles covering trustworthy AI, transparency, human agency, accountability and skills. Official OECD page
ISO/IEC 42001:2023 — international standard for an AI management system; use the official standard information for formal requirements and do not treat this article as a substitute for the standard text. Official ISO information
Framework, regulator and standard names remain the property of their respective owners.
10
📝 Summary
AI inventory: Know which AI uses exist, what they do, who owns them, and what can change their risk.
Acceptable use: Convert governance intent into specific allowed, restricted and prohibited behaviors.
AI literacy: Give each role enough practical understanding to use, review or oversee the relevant AI responsibly.
Evidence: Retain the trail that connects the decision, the control, the people responsible and what actually happened.
Reassessment: Treat new capabilities, data, tools, users and contexts as potential governance change triggers.
Responsible AI governance is not created by one policy document or one training course. It is built through visibility, boundaries, capability, evidence and continual review—applied proportionately to the AI use and the people affected by it.
Comments
Post a Comment