Why

For artificial intelligence to be adopted effectively in an organization, there must be an organization wide policy and understanding of how the organization views AI in the first place. Without a stated position, departments and teams may decide independently. One team might restrict AI while other staff don't consistently know what data is and isn't allowed to be processed by AI. From this initial decision, the rest of AI policies will flow.

How

A concise document works better than a large manual that employees won't read. The best policy is one that is easy to remember and to find. It may be added onto existing policy documents; but ensure it is communicated clearly to the whole organization when the organization's position on AI is formulated.

Sources

• NIST AI RMF GOVERN 1.2
• NIST AI RMF MAP 1.3
• ISO/IEC 42001 A.2.2
• ISO/IEC 42001 A.2.3
• ISO/IEC 42001 A.2.4
• ISO/IEC 42001 A.9.3

Why

As AI is used by many different departments in different workflows and types of work, it becomes widely incorporated into the daily business. This may lead to a situation in which AI is unowned. As a result, there may be no clear accountability or department/person who can be reached for clarification, questions or expertise.

How

The organization should name a known department/team/individual as responsible for AI deployment and management within the organization and as the point of contact for questions and concerns. Typically this will be a well-known department or individual with an existing role, although some larger organizations may choose to appoint a person with AI as their sole responsibility.

Sources

• NIST AI RMF GOVERN 2.1
• NIST AI RMF GOVERN 3.2
• ISO/IEC 42001 A.3.2
• ISO/IEC 42001 A.3.3

Why

As a result of misinformation and/or misunderstanding of core AI mechanics, organizations may misjudge the risks of AI systems. Such misjudgment can lead to overly stringent rules concerning AI use, or to a lack of critical evaluation of AI output. Article 4 of the EU AI Act establishes AI literacy as an obligation for every organization using AI.

How

Employees must be informed on what is and isn't allowed, and how AI output is verified. The informing training material should be integrated into the onboarding process. For existing employees, an annual session (in which AI might be only a part) that integrates internal feedback on AI use is an excellent way of raising awareness. Acknowledgment of written policy is also sufficient. Ensure that attendance or acknowledgment is recorded.

Sources

• NIST AI RMF GOVERN 2.2
• NIST AI RMF GOVERN 4.1
• AI Act Art. 4

Why

AI systems present unique risks, such as hallucinated or incorrect output that is presented as fact, third-party AI systems training on organizational data, and insufficient access control. In order to effectively manage such risk, it must first be identified and documented.

How

AI risks should be added to existing risk registers and reviewed as part of the organization's existing risk management process. Organizations should review these risks every year at the least.

Sources

• NIST AI RMF GOVERN 1.3
• NIST AI RMF GOVERN 1.4
• NIST AI RMF MAP 1.5
• NIST AI RMF MANAGE 1.2
• NIST AI RMF MANAGE 1.3
• NIST AI RMF MANAGE 2.3
• NIST AI RMF MEASURE 1.1

Why

AI use is subject to both well-known regulations such as the GDPR and more recent regulations such as the EU AI Act, which bans certain AI practices outright. Obligations differ depending on whether the organization is purely a deployer or supplier/developer of AI systems.

How

An inventory of laws and regulations applicable to AI should be integrated into existing registers. Ensure that the inventory of laws and regulations (and the dates that specific clauses go into effect if applicable) is updated annually and that the last review date is noted.

Sources

• NIST AI RMF GOVERN 1.1
• AI Act Art. 5

Why

The EU AI Act requires AI-generated content that is published externally to be marked as such. Interactive AI systems such as chatbots must also be marked as such if they are available externally. Non-AI generated content with minor AI edits (translation, grammar, etc.) are exempt.

How

Departments tasked with external communication (marketing, recruitment, etc.) and those deploying external AI systems such as chatbots, should be trained on their obligations to mark AI-generated content and systems as such. Markings should be visible or audible.

Sources

• AI Act Art. 50(1)
• AI Act Art. 50(4) 1st sub
• AI Act Art. 50(4) 2nd sub
• AI Act Art. 50(5)

Trigger

AI is used in decisions about hiring, firing, promotion, pay, access to services or benefits.

Why

The EU AI Act obliges organizations using AI systems in processes classified as high-risk to retain logs, conduct human oversight and inform affected individuals. These obligations apply from 2 December 2027.

How

AI and decision-related logs, such as chats and prompts, should be retained for at least six months. Oversight should be documented and assigned to a person with the authority to overrule decisions made with AI. Affected individuals or organizations must be informed that AI is used, and may request an explanation of decisions made with it. Organizations must also follow the provider's instructions for use, monitor the system and report serious incidents to the provider.

Sources

• AI Act Art. 26
• AI Act Art. 79
• AI Act Art. 86
• ISO/IEC 42001 A.6.2.8
• ISO/IEC 42001 A.9.4

Trigger

The organization is a public body or provides a public service, and AI is used in decisions about hiring, firing, promotion, pay, access to services or benefits.

Why

The EU AI Act obliges public bodies and organizations providing public services to perform a Fundamental Rights Impact Assessment (FRIA) before deploying high-risk AI. Public authorities must also register the high-risk use in the EU database before first use. These obligations apply from 2 December 2027.

How

Conduct and document a FRIA before first use of high-risk AI. If the use of the AI system in this high-risk process changes or a new AI system is introduced, the FRIA must be updated. Existing DPIAs can be used where those cover the required content (intended use of the AI system, affected individuals, groups or organizations, identified risks, oversight measures, etc.).

Sources

• AI Act Art. 27
• AI Act Art. 49(3)
• ISO/IEC 42001 A.5.2
• ISO/IEC 42001 A.5.3
• ISO/IEC 42001 A.5.4

Why

AI enters organizations in many ways; it can be procured, employees can sign up for AI tooling directly, it can be integrated into existing tools by suppliers, etc. This may lead to a situation in which AI tools are used without the organization's approval, bypassing security and privacy requirements in place. If multiple rules regarding what data may enter which AI are in place, the absence of a central register may lead to confusion and questions.

How

Registers of AI systems should contain each system's name, provider, and what kinds of data may be processed in this system (if all AI systems follow the same rules, this can be stated once). The register should ideally be integrated into existing software/IT registers and be updated as part of the organization's existing IT inventory processes. Unapproved AI systems ('Shadow AI') found within the organization should be logged alongside unapproved platforms or software ('Shadow IT').

Sources

• NIST AI RMF GOVERN 1.6
• ISO/IEC 42001 A.4.3
• ISO/IEC 42001 A.4.4

Why

AI systems that are embedded in processes (scripts, workflows, agents) often operate independently of their creator, and may continue to do so after that person leaves. If the provider and logic are not logged, this important information may be lost and the AI system cannot properly be assessed on compliance with security/privacy controls and (changed) regulations.

How

For each listed AI use (as understood here: an AI system set up for a specific task, such as an agent, script, workflow or dedicated tool), its purpose should be included in the register (see RG.1), along with what the system does, what it connects to and what data it sends where.

Sources

• NIST AI RMF MAP 1.1
• NIST AI RMF MAP 2.1
• ISO/IEC 42001 A.9.4
• ISO/IEC 42001 A.4.4

Why

Large general-purpose large language models (LLMs) are frequently applied to narrow tasks. Smaller, lesser-known models or non-LLM tools are often faster, cheaper, more accurate and less resource intensive than LLMs on such tasks.

How

For listed AI uses (see RG.2), record which alternatives were assessed, along with a short reasoning on why they were not selected.

Sources

• NIST AI RMF MAP 3.3
• NIST AI RMF MANAGE 2.1

Why

AI systems connected to internal mailboxes, calendars or file stores may retain their access after trials or subscriptions expire, presenting an access risk. Organizational data supplied to the provider may also remain with the provider, unless a deletion request is made.

How

AI system decommissioning should follow the organization's existing offboarding process. After offboarding, the register must be updated. To prevent future training on data if terms change, the organization should request that the provider deletes or returns all organizational data.

Sources

• NIST AI RMF GOVERN 1.7
• NIST AI RMF MANAGE 2.4
• NIST AI RMF MANAGE 4.1

Why

AI functionality is regularly added to existing products and platforms, which remain covered by the existing processing agreements. Often no reassessment is triggered, and organizational data may then be processed by an AI model or used to train it. Processing agreements and privacy statements are subject to change.

How

Privacy assessments of existing and new suppliers should include whether organizational data may be used as training data for AI models. Known risks inherent to LLM's and other AI systems (see GV.4), such as incorrect output and access inherited from users (see AC.1), should also be considered when AI functionality is added to existing software.

Sources

• NIST AI RMF GOVERN 6.1
• NIST AI RMF MANAGE 3.1
• ISO/IEC 42001 A.10.3

Why

Most AI systems that can, among other things, search and return organizational data do so under the access rights of the user querying them. Excessive permissions that were previously unexploited become easily discoverable (potentially unintentionally) as the AI system may search within all files the user has access to.

How

Before an AI system that inherits its access rights from a user or existing permission set is connected to organizational data, the access rights on that data are reviewed. This process should be integrated into existing access review processes and be triggered upon the procurement of new inheritance-based AI systems or when such functionality is added to existing systems.

Sources

• No equivalent in NIST AI RMF, ISO/IEC 42001 or the EU AI Act.

Trigger

The organization has deployed AI systems (agents, scripts or automations) that access systems or data with their own credentials (such as service accounts, API keys or app registrations).

Why

Non-human identities, and identity more broadly, are a significant and increasing part of an organization's digital attack surface. AI systems' access rights should be scrutinized and reviewed at least as much as those of human accounts. With no documented scope, the access cannot be reviewed or reduced.

How

AI systems using their own credentials should be given a dedicated identity, separate from any human account. The scope of the AI system's credentials should be documented (which systems and data it can reach, and whether it can read or write). These identities should be managed through the organization's existing identity and access management processes (see AC.4).

Sources

• No equivalent in NIST AI RMF, ISO/IEC 42001 or the EU AI Act.

Trigger

The organization has deployed AI systems (agents, scripts or automations) that can act autonomously.

Why

AI systems that act or make decisions cannot be held accountable. Accountability of actions or choices made by AI systems, and responsibility for the AI system, must therefore always be transferred to an individual or team.

How

For deployed systems that can act autonomously, an individual or team/department is named as owner. The owner is responsible for the actions or decisions made by the AI system, and for its operation. The organization should also document which actions the system may take autonomously, without human approval.

Sources

• No equivalent in NIST AI RMF, ISO/IEC 42001 or the EU AI Act.

Why

As with human identities, it is much easier to manage, review, and adjust access that is granted through defined roles or permission sets. Integrating AI identities into the organization's existing access control policy keeps AI systems' access manageable and clear.

How

Access should be granted to AI identities through the organization's existing access control policy (this may be role-based, attribute-based or policy-based) instead of directly. All AI identity access control should be part of the organization's access control processes.

Sources

• No equivalent in NIST AI RMF, ISO/IEC 42001 or the EU AI Act.

Why

AI systems are almost always adopted with the expectation that they will increase productivity, output, and automation of repetitive tasks. However, such benefits are rarely tracked and measured. Without such measurements, the actual benefits of deployed AI systems are hard to gauge against the costs of these systems.

How

The organization should formulate KPIs that compare the AI system against the situation in which it is not used. Such measurements should include the time spent checking and fixing AI output. Time spent setting up and fine-tuning the AI system should also be considered. Measurements should include the total cost of the AI system (or the percentage of purchased usage/tokens).

Sources

• NIST AI RMF MANAGE 1.1
• NIST AI RMF MAP 1.4

Why

Feedback from employees who use AI systems can provide information on AI benefit and usage that KPIs cannot. These employees see where output is unreliable, where it saves time, and where it may need a specific approach. If the organization does not collect this feedback, it misses the information on which it can better act with regard to AI policy or procurement.

How

The organization should collect such feedback through the existing communication channels, such as meetings, chats, e-mail, or feedback forms. An annual session (see GV.3) may be a good moment to collect feedback. Feedback should be collected by and go to the responsible person or team/department (see GV.2). Outcomes should be shared internally.

Sources

• NIST AI RMF GOVERN 4.2
• NIST AI RMF GOVERN 4.3
• ISO/IEC 42001 A.3.3

Why

AI output can be factually incorrect, miss critical context or hallucinate details. Most such errors do not need to be recorded, yet errors that appear in business-critical documents or processes can show the organization where AI systems fail in practice. Patterns become clear after collecting such errors and can act as powerful feedback to the organization and a reminder to employees to always check AI output or decisions.

How

The organization should facilitate a simple way to report AI errors, and should encourage employees to share errors and other negative feedback with the responsible person or team/department (see GV.2), or in a dedicated chat channel. This feedback should be considered as part of the AI risk review (see GV.4).

Sources

• NIST AI RMF GOVERN 4.3
• NIST AI RMF MANAGE 4.3
• ISO/IEC 42001 A.3.3