ISO 42001 preparation starts with clear AI boundaries

Before writing an AI policy, establish where AI is actually used and who can make decisions about it. A company may have one centrally purchased assistant, several AI features inside existing software and employees experimenting with other tools. A management system built around only the first purchase will give leaders an incomplete picture.

ISO/IEC 42001:2023 sets requirements for an AI management system and is intended for organisations providing or using AI products and services. 1 That makes its relevance broader than software developers. The preparation method below is an original implementation aid. It does not replace the licensed standard, a complete assessment or legal advice for a particular jurisdiction.

Define the business activity as well as the tool. Assign ownership for the use case, the information entering it and the decision leaving it. Revisit the boundary when a pilot gains users, receives new data or starts influencing consequential decisions.

Ask departments what they do with AI: draft proposals, summarise meetings, classify incoming requests or assist software development. Record the business purpose, tool and account type, users, input information, output recipients and any connection to another system. Include AI features embedded in purchased services where their use affects the activity being assessed.

Avoid an inventory consisting only of vendor names. Two teams can use the same product with very different consequences. Summarising public material for internal reading and screening applicants require different scrutiny, even if both begin with a text prompt.

Use interviews and a clear reporting route to discover informal use. Give staff a practical way to ask whether a proposed activity is permitted. A policy that people cannot apply to their daily work can leave the inventory incomplete.

Write a scope statement describing the organisational units, activities and locations covered, together with relevant interfaces. Explain why any exclusion is appropriate. Keep dependencies visible: an outsourced model may sit outside the organisation, while procurement, configuration, information handling and approval of its outputs remain internal responsibilities.

A narrow pilot can be useful if its limitations are explicit. It becomes misleading when the organisation describes that limited work as assurance over all AI use. Public statements, procurement responses and any future certification claims should match the actual scope and supporting evidence.

For businesses operating across MENA, Asia and English-speaking markets, maintain a separate applicability check covering the specific activity, information and jurisdiction. This article makes no claim that a single policy establishes legal compliance in all of those markets.

The business owner defines the purpose and acceptable operating conditions. The information owner decides which data may be used. Technical staff assess configuration and integrations. Relevant specialists assess matters such as privacy, security, employment or safety when the use case raises them. A designated authority approves release and accepts any residual exposure within its mandate.

One person may hold several roles in a small organisation, but the decisions still need to be explicit. Identify who can pause the activity, who receives an incident report and who can authorise restart. “IT owns AI” is too broad to resolve a disputed business outcome.

Assume a Southeast Asian service business pilots an assistant that summarises public procurement notices. Staff check each summary against the original notice. The pilot excludes customer data and does not submit bids.

A manager later proposes uploading confidential bid documents and using generated recommendations to determine pricing. That is a different use of information with different commercial consequences. Before allowing it, the company should revisit access, provider terms, data handling, review competence and approval authority. The earlier pilot result does not establish that the expanded activity is acceptable.

This example is invented to illustrate a decision boundary. It is not a report of a client engagement or evidence that any particular tool is suitable.

Fictional completed change request. The procurement-summary pilot has one approved purpose: help staff read public notices, with a human checking each output against its source. The proposed pricing use is recorded separately.

A successful summary demonstration cannot establish that confidential inputs are permitted or that pricing advice is dependable. The changed purpose and information require new evidence, including provider terms, access boundaries, review competence and the relevant legal applicability assessment. Define the questions and acceptance conditions before choosing test material.

For the proposal, use synthetic or appropriately authorised data when designing tests; mark them planned until they have actually run. If the proposed integration can submit a bid, that action is an additional boundary to assess rather than an incidental feature. This record illustrates scoping and accountable decisions; it does not certify the pilot, approve the tool or classify the activity under any jurisdiction's AI law.

Maintain a versioned record of the purpose, approved conditions, assessment, test results, known limitations and release decision. Define what operational records are needed and how long they are retained. Avoid collecting sensitive prompts merely to create a large audit trail; information retention itself needs a justified purpose and access controls.

Schedule reassessment around meaningful changes, including new data classes, integration permissions, model or vendor changes and evidence of harmful output. A review date provides a backstop, but significant changes should not wait for it.

Does using a third-party model remove our responsibilities? It does not resolve the decisions about how your organisation uses the service, supplies information and acts on outputs. Make those responsibilities clear in your operating arrangements.

Is this an ISO certification checklist? No. It prepares useful evidence and questions. A conformity assessment requires the applicable standard and the full management system context.

What can we do this week? Select one active use case, agree its boundary and name its decision owners. Test whether staff know how to report an exception before extending the approach to other activities.

AI assisted research and drafting. Sources checked 1 October 2026.

This article is general information. Verify current requirements and seek qualified advice for your specific circumstances.

Spotted an issue? Contact our editorial desk.