ISO 42001 AI Policy Controls: Direction, Alignment and Review

Start with decisions, then write the direction

A productive policy discussion begins with situations people cannot resolve consistently. Can a customer-service team introduce a new AI assistant? Who decides whether an experimental model may handle operational information? What happens when a customer wants an automated decision that the organisation cannot adequately explain or oversee? Different organisations will answer differently because their roles, obligations, objectives and risk positions differ. The policy should make those differences deliberate.

Collect a small set of realistic decisions before drafting. Include routine approval, a doubtful use, an exception request and a change to an established system. Ask the relevant leaders how they would respond and why. Inconsistent answers reveal where direction is missing. The resulting policy can state principles and decision boundaries while detailed procedures explain the steps. This is an implementation method, not an ISO-prescribed workshop or document structure.

Annex B discusses connecting policy with organisational strategy, values, objectives, obligations and willingness to take risk. Clause 6.1.3 requires consideration of that guidance. Annex B is normative, while its introduction permits tailored implementation; every illustrative policy topic is not automatically a separate compulsory section. The organisation still needs a reasoned approach that supports its actual AI activities.

Resolve conflicts before asking staff to comply

AI governance often crosses established security, privacy, quality, procurement and people-management rules. A new AI policy may permit experimentation while an existing data rule prohibits placing confidential information in unapproved services. Those positions can coexist, but people need to know how. A vague statement that all policies apply does not tell an engineer what information is permitted or who may approve a controlled trial.

Use A.2.3 to examine the intersections rather than copying whole policies into a new document. Identify the governing instruction, its owner and the practical decision route. Some gaps are best addressed by updating an existing policy; others need an AI-specific provision. Keep specialist requirements with competent owners. AI policy should coordinate their application, not invent a replacement interpretation of contractual or legal obligations.

Exceptions deserve similar care. An exception process can be a useful way to make constrained, justified decisions visible, but it must not become a general escape from obligations. Identify who can approve which departures, what supporting assessment is needed, whether compensating arrangements are appropriate and when the decision expires. These are suggested design questions. The necessary detail depends on the organisation's risks and authority structure.

Illustrative BPO example: conflicting instructions for assisted responses

A BPO provider introduces an AI tool that drafts customer email replies. Operations wants faster handling; quality wants consistent explanations; the client contract restricts how customer information may be used. Staff have been told both to explore approved productivity tools and to avoid transferring customer data to unapproved systems. The conflict is practical: people do not know whether the new drafting service is covered by the approval.

The provider maps the service, information categories, client conditions and operational roles. Its AI policy gives direction on approved uses and accountability. The information-handling procedure supplies the detailed restrictions, while the service-specific approval identifies the permitted environment and review arrangements. Supervisors receive examples showing the difference between a generic drafting exercise and processing live customer material. No assumption is made that a vendor's marketing statement resolves the provider's obligations.

For review, the policy owner samples actual approvals, rejected uses and staff questions. If repeated questions concern the same boundary, the owner revises the instruction and checks understanding. Evidence of success is not merely a new policy version: it is a clearer and consistently applied decision. The organisation can retain the revision rationale and relevant approval records without recording every routine conversation.

Illustrative construction example: AI planning advice across projects

A construction group uses AI-assisted planning tools across projects with different contractual responsibilities. One project team wants to use suggested sequencing directly; another uses the tool only to identify questions for qualified planners. A single statement allowing “AI to improve project performance” does not establish who remains accountable for reviewing the proposed schedule or which project restrictions matter.

The group separates broad direction from local application. Its policy sets expectations for appropriate use and accountable decisions. Project arrangements identify competent reviewers, permitted information and escalation when recommendations conflict with site knowledge or contractual conditions. Procurement and information-security requirements remain applicable through their established routes. The policy does not claim that using the tool validates construction methods or replaces relevant professional judgement.

A major change in the tool's function prompts a policy review. The owner asks whether the existing boundary still fits, whether users understand the new limitations and whether project instructions need updating. This makes review responsive to meaningful change rather than a calendar exercise that reconfirms unchanged wording without examining its use.

Make policy review an operating feedback loop

A.2.4 connects policy review with planned intervals and relevant changes. Useful inputs can include organisational changes, new AI activities, evolving obligations, technical developments, concerns, incidents and management-review decisions. The selected inputs should reflect the policy's purpose. The organisation does not need to treat every public discussion about AI as an automatic trigger for rewriting its rules.

Assign an owner who can collect evidence, propose changes and obtain appropriate management approval. Check whether an update changes responsibilities, acceptance boundaries or related procedures. Publication alone is insufficient when the change affects a decision people make: explain the change to those people and, where appropriate, confirm that they can apply it. A review may reasonably conclude that no revision is necessary, provided the review has actually considered relevant information.

For implementation evidence, distinguish required documented policy from optional supporting tools. A conflict map, decision log or sample-based review record can help demonstrate coherence, but ISO 42001 does not prescribe those particular names. The stronger question is whether a reviewer can trace policy direction to an operational decision and understand why the instruction remains suitable.

Common weaknesses and a useful readiness check

Common weaknesses include aspirational language without decision boundaries, excessive detail that duplicates procedures, competing instructions from different functions and reviews measured only by approval dates. Another weakness is assuming a signed policy proves awareness. A short discussion with users about a difficult scenario often reveals more than a distribution record.

Before treating the policy arrangement as established, test one new use, one exception and one significant change. Ask the responsible people to identify the applicable instruction, decision authority and escalation route. Where answers differ, improve the policy connection or supporting process. Use the internal organisation controls to connect that direction with roles and concerns, and the Annex A overview to see the wider control structure.

Individual controls in this theme

Why AI policy controls matter to the business

Policy controls decide whether AI decisions across a business are made consistently or case by case. Without agreed direction, one team may treat a new assistant as an experiment while another treats it as a customer-facing service, and nobody can say which view the organisation holds. The three controls in this theme cover the document that sets direction, its fit with security, quality, privacy and people rules already in force, and its review as the business changes. Together they reduce arguments, shorten approvals and give customers a clear answer when they ask how the organisation governs AI. They also make later controls easier to apply, because roles, assessments and operating limits can point back to a common statement of intent.