6.2 Controls A.2 (AI Policies) & A.3 (Internal Organization)

Annex A.2 and A.3: policy and internal organization

The first two Annex A groups create organizational direction and accountability. They are often misnumbered because the objective rows are mistaken for controls. The actual controls begin at A.2.2 and A.3.2.

A.2 Policies related to AI

The group objective is to provide management direction and support for AI systems according to business requirements. It has three controls.

A.2.2 AI policy

The organization documents a policy for the development or use of AI systems.

This control complements Clause 5.2. Clause 5.2 specifies leadership-level policy content and communication requirements; A.2.2 makes an AI policy a reference control for treatment. Depending on scope, a policy can address responsible development and use, decision authority, restricted practices, lifecycle expectations, data, transparency, oversight, reporting, and supplier relationships.

The control does not require a separate policy document for each AI system or a public list of prohibited uses. The organization chooses a structure suitable to context.

A.2.3 Alignment with other organizational policies

The organization determines where other policies can be affected by, or apply to, its objectives for AI systems.

This control is missing from many inaccurate summaries. AI policy can interact with information security, privacy, quality, records, acceptable use, procurement, human resources, safety, incident response, intellectual property, and product-development policies.

Alignment does not mean copying text. It means identifying dependencies and resolving contradictions. For example, an AI experimentation policy allowing public uploads of data would conflict with a privacy or confidentiality policy that restricts such transfers.

A.2.4 Review of the AI policy

The AI policy is reviewed at planned intervals or additionally as needed to ensure continuing suitability, adequacy, and effectiveness.

The organization chooses the planned interval and additional triggers. Potential triggers include a scope change, serious incident, new legal requirement, major supplier or technology change, or significant change in AI role. The control does not state that every minor software patch requires immediate policy review.

Useful evidence can include controlled policy versions, review records, identified dependencies, approvals, and communications. Evidence examples are not extra mandatory controls.

A.3 Internal organization

The group objective is accountability within the organization for implementation, operation, and management of AI systems. It has two controls.

A.3.2 AI roles and responsibilities

Roles and responsibilities for AI are defined and allocated according to organizational needs.

Possible roles include top management, AIMS manager, system owner, risk owner, developer, data steward, validator, operator, procurement owner, incident lead, and internal auditor. The standard does not prescribe those titles.

Role design should answer:

• Who owns the decision to develop, provide, or use a system?
• Who defines requirements and accepts residual risk?
• Who can authorize deployment, change, suspension, or retirement?
• Who monitors performance and impacts?
• Who handles concerns and incidents?
• Who manages suppliers and customer commitments?

Segregation of duties can protect objectivity when the same team faces conflicting incentives. It may be appropriate for high-consequence validation or audit. A.3.2 itself does not state an absolute rule that developers can never validate their own work; allocation should reflect need, competence, and conflict risk. Clause 9.2 separately requires objective and impartial internal auditing.

A cross-functional committee is one design option, not a universal requirement. A small organization can use named accountable roles and escalation to top management; a large organization may need multiple governance forums.

A.3.3 Reporting of concerns

The organization defines and puts in place a process for reporting concerns about the organization’s role with respect to an AI system throughout its lifecycle.

A concern can relate to unsafe behavior, unfair outcomes, misuse, data, security, privacy, user information, pressure to bypass controls, or an unclear responsibility. The process should make it possible to receive, route, evaluate, and respond to relevant concerns.

The control text does not expressly require anonymous reporting, external access, legal whistleblower protection, or a particular hotline. Those can be important implementations depending on law, workforce, interested parties, and risk. Do not convert good practice into universal clause wording.

Concern reporting is not the same as A.8.3 external reporting. A.3.3 establishes the organizational concern process; A.8.3 provides capabilities for interested parties to report adverse impacts.

Policy-to-action example

A logistics company adopts route-optimization AI. Its A.2 controls document responsible-use policy, align that policy with safety and driver-monitoring rules, and schedule review after major scope or legal change. Its A.3 controls allocate system ownership, data responsibility, operating authority, monitoring, and incident escalation. Drivers and dispatchers receive a route to report safety or fairness concerns.

The company need not create an “AI Ethics Board” merely to name one. It must establish effective direction, accountability, and reporting consistent with selected controls.

Control-number memory map

• A.2.2: AI policy
• A.2.3: alignment with other policies
• A.2.4: review
• A.3.2: roles and responsibilities
• A.3.3: reporting concerns