AI policy for business: who approves tools and exceptions?

AI policies work when they have named owners, documented use cases, and clear approval rules for tools and exceptions. Accountability is the key.

A few employees move ahead with AI while others hesitate, improvise, or struggle to apply company rules. Your AI policy for business should name a business owner for each use case, assign tool approval to an accountable technology owner, and route exceptions to a designated decision-maker with security, privacy, or legal input where needed. Employees need a clear route from an approved task to its boundaries, an output check, and a person who can answer questions.

TL;DR

• An AI policy for business needs named owners for tool approval, use cases, and exceptions.
• Employees need approved tasks, information-handling rules, output checks, and a clear escalation route.
• EU AI Act Article 4 addresses AI literacy; training supports duties without guaranteeing compliance.
• ISO/IEC 42001 and NIST support documented responsibilities, risk-based approvals, and managed exceptions.

Why this matters

An approved tool does not tell an employee whether they can upload a customer complaint, assess a job applicant, or send generated advice to a client. Those decisions depend on the task, the information involved, and the consequences of an error.

Approval must cover the use, not just the tool. Otherwise, employees inherit decisions that should belong to managers, IT, privacy specialists, or legal teams.

A shared foundation helps employees understand the rules behind those decisions; company owners still need to define and enforce them.

Who approves tools and exceptions?

Assign an accountable owner to each decision, then name the specialists that owner must consult. The following translates ISO/IEC 42001 and NIST governance principles into an example approval model; neither framework prescribes these job titles or this exact table. Smaller companies can combine roles, while keeping independent review where a conflict of interest or the risk warrants it.

Decision	Recommended accountable owner	Required input when relevant	Record to retain
Accept a business use case	Business process owner	Employees doing the work, IT, legal	Purpose, expected benefit, and consequences of error
Approve a tool	Technology or IT owner	Security, privacy, procurement, legal	Approved configuration, permitted information, and restrictions
Approve sensitive use	Named business risk owner	Privacy, legal, security, and affected process owners	Assessment, safeguards, and human review requirements
Approve an exception	Designated exception owner	Owners of the controls being changed	Reason, scope, conditions, expiry, and reviewer
Release an output	Responsible employee or process owner	Subject expert where necessary	Checks required by the workflow

The benefit is clear accountability: employees know where a request goes, and reviewers know what they are deciding. The trade-off is coordination work. Keep the process proportionate so routine requests do not follow the same route as decisions affecting people’s rights.

Document a deputy for each owner. A policy that depends on one unavailable executive creates an avoidable blockage.

What evidence supports this approval process?

This is a standards-grounded approach, not a workflow proven to outperform every alternative. ISO/IEC 42001 and NIST support its underlying controls: clear authority, assessment of the intended use, bounded permissions, and recorded decisions. They do not establish that these exact roles or steps are the best fit for every company.

ISO/IEC 42001: assign responsibility and manage AI risks

ISO’s explanation of ISO/IEC 42001:2023 describes a management system for organizations developing, providing, or using AI. It covers defined responsibilities, AI risk assessment, documented policies, monitoring, and corrective action. That makes it directly relevant to a company buying AI tools, not only a company building models.

The practical application is to connect each approval to a responsible owner, the intended use, assessed risks, and a record that can be reviewed when circumstances change. A vendor name alone leaves those questions unanswered. ISO’s public explanation supports these principles; it does not prescribe the approval matrix above, a particular exception form, or a universal expiry period.

Using this process alone does not establish conformity with the full standard or confer certification. ISO also states that the standard does not replace applicable laws.

NIST AI RMF: approve the use, not just the tool

The NIST AI Risk Management Framework 1.0 Core, published in 2023, makes the connection more explicit:

• GOVERN 2.1: Document roles, responsibilities, and communication routes. This supports a named approver and escalation contact.
• MAP 1.1 and MAP 3.3: Document intended purposes, deployment context, and application scope. This supports approval for a defined task and information type.
• GOVERN 2.3: Executive leadership takes responsibility for AI risk decisions. Specialist advice must connect to someone authorized to decide.
• MANAGE 1.3 and 1.4: Document risk responses and remaining negative risks. An approval should explain what safeguards address and what risk remains.

NIST describes its framework as voluntary and adaptable, not a mandatory sequence. The approval model here is an implementation of those outcomes, not a NIST-issued workflow.

Cybersecurity practice: bound access and track exceptions

The NIST Cybersecurity Framework 2.0 Core, published in 2024, supplies direct support for the exception process. ID.RA-07 calls for changes and exceptions to be managed, assessed for risk impact, recorded, and tracked. An informal manager’s permission does not document those elements.

PR.AA-05 calls for access permissions to be managed, enforced, and reviewed using least privilege and separation of duties. In plain terms, give people only the access their task needs and separate conflicting responsibilities. Applied to AI approvals, the requester should not be the sole approver of a sensitive exception. IT must enforce relevant access restrictions; policy wording alone is insufficient.

GV.SC-06 and GV.SC-07 address supplier due diligence and ongoing supplier risk management. This supports reviewing a tool’s handling of company information before use and reassessing relevant changes afterward.

These controls explain why the process is defensible: it makes authority, scope, and remaining risk visible. They are standards-based support, not comparative evidence of fewer incidents or faster approvals. Your company must still check whether the process works in its own setting.

Tool approval: define what employees can actually do

An approved-tool list should explain permitted use, not merely list vendor names. A tool can be suitable for drafting public marketing copy while remaining unsuitable for processing confidential employee records.

For each approved use, tell employees:

• Who can use it: the roles or teams covered by the approval.
• What they can enter: permitted information and information they must keep out.
• What they can produce: approved tasks and restricted decisions.
• Who checks results: the employee, a subject expert or another named reviewer.
• Where questions go: a named team or role with a clear contact route.

Approval also needs technical support. IT must apply the relevant access and configuration controls; employees cannot enforce every restriction through judgment alone.

A tool approval is permission for a defined use, not permission for every use. Teach that distinction during onboarding and reinforce it when teams introduce a new workflow.

Exception approval: limit the permission and name the owner

An exception should identify the exact rule being changed. A request to use a different tool is different from a request to enter restricted information into an existing tool.

Require the requester to describe the business need, the proposed use, the information involved, and why the approved route does not work. The exception owner should consult whoever owns the affected control. If risk remains after safeguards are applied, send the decision to a person with delegated authority to accept that risk; a security review is advice, not automatically business authorization.

Keep an exception record with:

• The rule and scope: Which restriction changes, for whom, for which task and information.
• The risk assessment: What could go wrong, who could be affected, and what risk remains after safeguards.
• The decision: Approval or rejection, the authorized decision-maker, and the reason.
• The conditions: Required access controls, information restrictions, and human checks.
• The follow-up: An owner, an end date or review condition, and the action to withdraw permission.

Choose the end date and review conditions according to the risk and your existing change-management policy. NIST CSF ID.RA-07 supports assessing, recording, and tracking exceptions; it does not mandate this form or a fixed renewal schedule. Reassess when the task, information type, access, or relevant supplier terms change.

The advantage is controlled flexibility. The drawback is that exceptions need maintenance: without review, a temporary permission becomes an undocumented operating practice.

An internal exception cannot authorize unlawful activity. If a request conflicts with applicable law, the route is to stop or redesign the use, not seek a more senior signature.

Why approval routes vary

Use these factors to design the route. They are decision criteria, not a substitute for a legal or security assessment.

• Information sensitivity: Public text and identifiable employee records require different handling decisions. Ask the privacy or security owner to define the boundary.
• Effect on people: A draft meeting agenda differs from a recommendation affecting recruitment or access to services. Involve the relevant process owner and legal team.
• Autonomy: A suggestion that a person checks differs from a system that acts. Define who can intervene and stop the workflow.
• External exposure: Internal notes and public-facing content need different review instructions, especially where disclosure duties apply.
• Change from approval: A new task, configuration, or information type can fall outside an existing permission. State when employees must ask again.

Avoid asking employees to classify complex legal risks themselves. Teach recognizable triggers and give specialists responsibility for the assessment.

How do employees follow the policy during everyday work?

Employees need a repeatable sequence they can apply while doing their job. The four steps below are a teaching aid derived from the governance principles above, not a separately validated framework or a sequence prescribed by ISO or NIST. Start with a useful, approved task that does not require employees to resolve unfamiliar policy questions unaided.

1. Choose the task. Confirm that the intended use falls within an approved workflow.
2. Check the boundaries. Use the permitted tool and information; stop if the request falls outside the approval.
3. Check the result. Verify relevant facts, sources, calculations, and suitability before using the output.
4. Ask the owner. Escalate uncertainty, unexpected behavior, or a proposed change through the named route.

For example, a communications employee drafts an announcement using approved public information. The employee checks names and claims against the source material, then follows the normal publication approval process. This is a hypothetical workflow, not a customer result.

For employees who hesitate, that bounded task provides a credible first step. Managers can observe whether employees follow the process rather than measuring confidence alone.

What does the EU AI Act require companies to consider?

For global companies, establish whether the EU AI Act applies to the organization and the particular activity. Its scope can extend beyond organizations established in the EU, including certain situations where system outputs are used in the EU. Legal teams should assess the actual arrangement.

Article 4: teach people for their role and context

EU AI Act Article 4 requires providers and deployers to take measures, to their best extent, to ensure sufficient AI literacy among staff and others operating AI systems on their behalf. It calls for attention to their knowledge, experience, education and training, the context of use, and the people affected.

Translate that into role-relevant learning. Employees drafting internal text need a shared foundation; people supervising consequential uses need instruction matched to those responsibilities. Article 4 does not prescribe one universal course or certificate.

Article 5: recognize uses that need to stop

Article 5 prohibits specified practices, subject to the provisions’ detailed conditions and exceptions. Relevant examples include certain manipulative practices and, with specified exceptions, AI used to infer emotions in workplaces and educational institutions.

Employees need recognizable warning signs and a stop-and-escalate instruction. Legal teams must assess the precise practice; a policy should not present every emotion-related application as having identical legal treatment.

Article 50: identify transparency duties before deployment

Article 50 addresses transparency for specified systems and uses, including certain interactions with people and generated or manipulated content. Under the AI Act’s application timetable, these provisions apply from Aug. 2, 2026, with duties and exceptions depending on the activity and responsible party.

The policy should tell employees who decides whether disclosure is required, who prepares it, and who checks it before release. Do not turn this into a blanket instruction to label every AI-assisted document.

Training helps people carry out these rules. It does not replace legal assessment, technical security controls, or the other obligations that apply to a particular system.

How can you prove employees understand the policy?

Measure decisions employees can make, not attendance alone. Completion records show participation; scenario answers show whether employees recognize boundaries and know when to ask for help.

Use exercises tied to the approved workflows. Ask employees to identify information they must remove, explain how they would check an output, and name the owner for an exception request.

Retain the training version, learning objectives, assigned roles, completion records, and assessment results. Connect those records to the policy version employees learned. This provides evidence of the training delivered and the understanding assessed, without promising an audit outcome.

Managers should also review how the workflow operates. Repeated questions about the same rule can identify instructions that need rewriting, while repeated output errors can identify a task that needs stronger review.

What should company buyers ask a training provider?

Choose the delivery approach after defining the employee behavior you need to change. Compare the following options against the same approved task and policy scenario:

• Internal training — best for company-specific rules. Your owners can explain local decisions directly. The limitation is the work needed to develop, maintain, and assess the training.
• Large learning-platform courses — best for evaluating existing learning options. Review the actual content against your objectives. General instruction still needs a connection to company tools, rules, and escalation routes.
• Specialist company-wide training — best for evaluating a shared employee baseline. Ask for evidence of what employees learn and how understanding is assessed. Specialist content still requires company-specific context.
• A learning management system — best for organizing delivery and records. Assess its administration separately from the content. Course delivery does not itself establish employee understanding.

These are buying criteria, not claims about any particular vendor’s features.

Ask a provider to demonstrate how its training connects foundational understanding to your approved tasks and policy decisions. Company owners remain responsible for defining and authorizing those decisions.

FAQ

Who should own our AI policy for business?

Name an executive sponsor and an operating owner who maintains the policy. Assign tool, use-case, and exception decisions explicitly so policy ownership does not become responsibility for every approval.

Can a manager approve an employee’s AI tool?

A manager can approve a tool only within the authority your company assigns. Business approval should not bypass required technology, security, privacy, or legal review.

Do we need to approve every prompt employees write?

Define approved tasks and boundaries rather than requiring separate approval for every routine prompt. Employees should request review when the task, information, or intended use falls outside those boundaries.

Can an exception override a prohibited AI use?

An internal exception cannot authorize unlawful activity. The decision-maker must reject or redesign a use that conflicts with applicable law.

Does AI literacy training guarantee EU AI Act compliance?

AI literacy training does not guarantee EU AI Act compliance. It supports employee understanding and relevant literacy duties while legal, technical, and operational obligations still require separate attention.

Is a learning management system enough for AI training?

A learning management system alone does not establish AI skills. You also need suitable content, company-specific instructions, and a way to assess whether employees can apply them.

Does ISO/IEC 42001 prescribe who must approve AI tools?

ISO/IEC 42001 supports defined responsibilities and risk management, but the approval matrix in this article is an example implementation, not a mandated list of job titles. Assign authority to fit your organization and assess the full standard separately if seeking conformity or certification.

One last thing

Ask an employee to explain the next step when an approved tool produces an answer that looks wrong. If the employee cannot name the check or the person to ask, the policy has not yet become a workable habit.

Fix that handoff before expanding the workflow. A named owner and a practiced response make the rule useful at the moment an employee needs it.