An ISO 42001 AI policy that boards and buyers both approve

Defining Purpose and Risk Appetite over Platitudes

The primary mistake I see founders make is treating an AI policy like a PR exercise filled with words like 'fairness' and 'transparency' without defining the mechanics. Boards don't care about your philosophy; they care about liability, intellectual property leakage, and regulatory fines. Buyers, on the other hand, care about your data provenance and whether your model will hallucinate a commitment you can't keep. Your policy must be a bridge that translates technical AI risks into commercial safeguards.

ISO 42001 Clause 5.2 requires the AI policy to be appropriate to the purpose of the organisation and provide a framework for setting AI objectives. This means you must explicitly state what you will and will not use AI for. If you are a fintech, your policy should be vastly different from a creative agency. You need to define your 'AI risk appetite' in stone, identifying 'no-go' zones such as autonomous decision-making in HR or using sensitive customer data for model retraining without explicit consent.

Operationalising the AI Risk Assessment

A board-level policy must mandate a formal AI Risk Assessment process that goes beyond a standard ISO 27001 risk register. In ISO 42001, we are looking at the 'systemic' risks of the AI lifecycle. This includes the risk of 'model drift' where the performance of an AI system degrades over time as real-world data changes. Your policy needs to dictate how often these models are re-validated and who owns the 'kill switch' if the model begins to deviate from expected parameters.

Buyers are increasingly asking for 'AI Transparency Logs'. Your policy should pre-empt this by mandating that every AI system used in your product has a corresponding entry in your AI Inventory (Clause 8.2). This inventory should detail the data sources, the logic behind the model selection, and the results of bias testing. By making this a policy requirement, you turn a compliance chore into a powerful sales collateral piece that demonstrates maturity to any procurement team.

• Data Provenance: Where did the training data come from and do you have the rights?
• Model Robustness: How does the system handle adversarial inputs or unexpected 'out-of-distribution' data?
• Explainability: Can you provide a human-readable reason for a specific AI output?
• Human Oversight: Is there a 'human-in-the-loop' for high-impact decisions?

Transparency and the Explainability Tiering

One of the biggest hurdles in AI adoption is the 'black box' problem—not knowing why a model made a specific choice. A buyer-approved policy must address ISO 42001's requirements for transparency and explainability. You should define 'Tiers of Explainability' based on the impact of the AI output. For example, a recommendation engine for content might require minimal explanation, but a tool that scores creditworthiness must have a mandatory 'reason code' output for every result.

This level of detail reassures the Board that the company isn't flying blind. It also answers the inevitable question from enterprise buyers: 'What happens when my customer complains about an AI decision?' Your policy should stipulate the creation of a 'System Impact Assessment' for every high-risk AI application. This document becomes the evidence that you have considered the societal and individual impacts of your technology, directly addressing the requirements found in Annex A of the standard.

Third-Party AI and the Supply Chain Risk

Your AI governance is only as strong as your weakest vendor. If your product relies on third-party LLMs or APIs, your ISO 42001 policy must extend its reach. You need to define how you evaluate the 'AI posture' of your vendors. Are they retraining their base models on your data? Do they have their own ISO 42001 certification? I advise clients to build an 'AI Vendor Annex' into their procurement process that mirrors their internal standards.

For the Board, this is about supply chain resilience. They need to know that if a vendor’s model is found to be biased or insecure, it won’t bring down your entire operation. Your policy should mandate a 'Model Portability' or 'Contingency Plan' for mission-critical AI functions. This proves to buyers that you have thought about the long-term viability of your AI features and aren't just chasing the latest trend without a safety net.

• Prohibition of 'shadow AI' where employees use unapproved LLMs for company work.
• Mandatory watermarking or disclosure of AI-generated content where applicable.
• Regular auditing of third-party AI sub-processors (e.g., OpenAI, Anthropic).
• Defined protocols for 'Red Teaming' models before major releases.

Continuous Monitoring and the Governance Loop

ISO 42001 is a 'Management System' standard, which means it values continuous improvement over static documentation. Your policy must establish a cadence for reviewing AI performance against defined KPIs. These aren't just technical metrics like 'accuracy' or 'F1 score,' but governance metrics like 'percentage of AI systems with completed impact assessments' or 'number of bias-related support tickets.' This data is what the Board needs to see quarterly to maintain their oversight.

In the eyes of a buyer, a company that shows a history of monitoring and correcting AI performance is infinitely more trustworthy than one that claims its AI is 'perfect.' Use your policy to institutionalise 'Post-Market Monitoring' (Clause 10). This involves active feedback loops from users and automated monitoring for performance degradation. When you can show a prospect your incident response plan specifically tailored for AI failures, you have effectively de-risked the sale and positioned yourself as a market leader.

Frequently asked questions