4.2 Clause 6.1.4: AI System Impact Assessment

Clauses 6.1.4 and 8.4: AI system impact assessment

AI system impact assessment is one of ISO/IEC 42001’s distinctive requirements. It directs attention to consequences beyond technical performance or organizational loss. The organization must understand how an AI system can affect individuals, groups of individuals, and societies in its real context.

What Clause 6.1.4 requires

The organization defines a process for assessing potential consequences that can result from the development, provision, or use of AI systems. The process covers consequences to:

• individuals;
• groups of individuals, or both individuals and groups; and
• societies.

It determines potential consequences of an AI system’s deployment, intended use, and foreseeable misuse. It takes account of the specific technical and societal context in which the system is deployed and the applicable jurisdictions.

The assessment result is documented. Where appropriate, the organization can make the result available to relevant interested parties it has identified. The organization also considers the result in the Clause 6.1.2 AI risk assessment.

This language establishes the minimum process boundary without prescribing one scoring table, report template, committee, or software tool.

What the clause does not say

Avoid several common additions:

• It does not create four mandatory impact categories of “individual, group, society, environment.” Environmental consequences may be relevant societal impacts, organizational objectives, legal requirements, or risk sources, but the clause names individuals, groups, and societies.
• It does not require publication of every assessment. Results may be made available where appropriate.
• It does not require top management to sign every system assessment. The organization should allocate suitable roles and approval authority through its processes.
• It does not prescribe a five-step methodology, numerical matrix, or named stakeholder panel.

Designing an effective process

A useful process usually answers these questions:

1. What is being assessed? Define the system, version, components, purpose, boundaries, and organizational role.
2. What is the context? Identify users, affected people, geographic and sector setting, technical dependencies, and applicable jurisdictions.
3. What uses are in view? Include intended use and reasonably foreseeable misuse, not arbitrary science-fiction possibilities.
4. Who can be affected? Consider individuals, relevant groups, and societal institutions or conditions.
5. What can happen? Identify positive and negative consequences, their distribution, severity, duration, scale, and reversibility as appropriate.
6. What controls exist? Record preventive, detective, corrective, and communication measures and their limitations.
7. How will results be used? Feed findings into risk assessment, requirements, control selection, deployment decisions, monitoring, and communication.

Those steps are an implementation pattern. An organization can use another method if it meets the requirements and produces useful, repeatable evidence.

Sources of impact

Potential impacts depend on the system. Examples include:

An assessment should also identify benefits and opportunities. Impact assessment is not limited to cataloguing harms, although potential adverse consequences need effective treatment.

Relationship to risk assessment

A false “inward risk versus outward impact” diagram can be too rigid. Clause 6.1.2 assesses risks affecting organizational objectives, and those objectives can include responsible use, legal conformity, fairness, safety, and stakeholder outcomes. Clause 6.1.4 supplies focused evidence about consequences for people and society. The standard explicitly requires the impact result to be considered in risk assessment.

For example, unequal denial rates in a credit model are impacts on applicants and groups. They also create risk to objectives concerning fair service, legal compliance, trust, and model effectiveness. Treatment decisions should reflect both views.

Clause 8.4: performing the assessment

Clause 6.1.4 defines the process; Clause 8.4 operates it. The organization performs AI system impact assessments in accordance with its process:

• at planned intervals; or
• when significant changes are proposed.

It retains documented information on all assessment results.

The standard’s trigger language does not say “continuously,” and it does not list development and procurement as the only triggers. An organization can schedule assessments at lifecycle gates and add event triggers. Examples of potentially significant change include a new intended purpose, user population, jurisdiction, data source, automation level, supplier model, interface, or decision authority. The organization applies its defined significance criteria.

Third-party systems

Using a vendor model does not make impact assessment irrelevant. The organization may lack access to training details, but it controls or influences intended use, integration, users, data supplied, communications, monitoring, and response. Supplier information and testing limitations become inputs to the assessment.

Documented result

A useful result can identify system and version, intended use, context, affected parties, foreseeable misuse, potential consequences, evidence, assumptions, controls, unresolved uncertainty, decisions, and review triggers. Consultation records and residual-impact ratings can be useful when appropriate, but ISO/IEC 42001 does not state that every report must contain one universal set of fields.