Using Third-Party AI in Your Organisation? ISO/IEC 42001 Governance Still Applies

Most organisations using AI aren’t building their own systems from scratch. 

AI is often brought in through software the organisation already buys or through tools supplied by somebody else. That can make adoption much easier, but it doesn’t transfer responsibility for how the technology is used. 

ISO/IEC 42001 applies to organisations that use AI systems as well as those that develop or provide them. When the technology comes from a third party, the organisation may have less control over the underlying model, but it still needs to understand what it is introducing and decide how that system should be governed once it becomes part of the business.

Using a third-party AI system creates a different relationship with the technology than developing one internally. 

The organisation may have little control over how the model was trained, and some technical information may be unavailable because the supplier considers it proprietary. 

What remains within the organisation’s control is how the system is used. 

Take a company introducing an AI assistant for customer support. The supplier may operate the underlying model, but the company still decides whether the assistant can access customer information and how much employees should rely on its responses. 

It can also decide when an output needs to be reviewed before it reaches a customer. 

Similar problems can appear when AI is added to software the organisation already uses. 

A new AI feature shouldn’t work under the same assumptions that were made when the original product was approved. If the capability starts handling information differently or begins to influence decisions in a new way, the organisation needs to recognise that the original assessment may no longer be enough. 

Implementing an AI inventory can help keep track of these kinds of considerations. 

Before third-party AI can be governed consistently, the organisation needs to know where it is being used and who is responsible for each use case. Once that picture is clearer, it becomes easier to decide which systems need closer assessment and where more oversight may be necessary.

Supplier assessment should give the organisation information it can actually use to make a decision. 

A long questionnaire can create an impressive record of due diligence without necessarily telling anyone whether the product is suitable for the way it will be used. 

The questions need to reflect the use case. 

The organisation will usually want to understand what the AI capability is designed to do and what limitations the supplier already recognises. How information submitted to the system is handled may also need closer attention, especially where employees could enter confidential or sensitive material. 

The amount of evidence required will depend heavily on what the system is being asked to do. 

A tool used to summarise internal meeting notes may not need the same level of scrutiny as one influencing recruitment decisions. In the second case, uncertainty around performance becomes much more important because unreliable outputs could directly affect applicants. 

There will also be situations where the supplier can’t provide everything the organisation would ideally like to know. 

That doesn’t automatically make the product unusable. The real question is whether the information gap creates uncertainty that can be managed within the proposed use. 

Internal testing may help. The organisation might also limit what the tool is allowed to do, or require somebody to review certain outputs before they’re acted upon. 

Sometimes that still won’t provide enough confidence. If too much remains unknown for the intended use, choosing not to deploy the system may be the appropriate decision.

Supplier assessment isn’t about finding a vendor capable of answering every conceivable question. It’s about gathering enough relevant information to understand what the organisation is agreeing to and where additional controls may be needed. 

Approving a supplier is only the beginning of third-party AI governance. 

AI products can change after deployment without the organisation deliberately altering anything itself. A supplier may update the underlying model, or introduce a feature that changes how the product behaves. 

Employees can also change the way a system is used. 

A generative AI tool might initially be approved for drafting low-risk internal material. Over time, the same tool could start appearing in customer-facing work that wasn’t considered during the original assessment. 

The product may be unchanged, but the context around it is not. 

An organisation therefore needs a way to recognise when its original assumptions should be reviewed. 

Some supplier updates may justify another look at the system, depending on what has changed. Internal use also needs enough oversight that significant shifts don’t go unnoticed simply because the software itself appears familiar. 

There needs to be a practical way to respond when something goes wrong too. 

Employees using the system should know where unexpected behaviour can be reported. The people responsible for the use case then need enough authority to investigate what happened and restrict its use if necessary. 

At that point, third-party AI governance has clearly moved beyond procurement. 

ISO/IEC 42001 is concerned with maintaining and continually improving the wider Artificial Intelligence Management System, which means decisions made during initial approval need to remain connected with what happens once the product becomes part of normal operations.

Organisations implementing ISO/IEC 42001 don’t necessarily need an entirely separate governance programme for every external AI tool they use. 

Existing processes can often provide a useful starting point. 

The organisation may already review technology suppliers before purchase, or have established processes for areas such as security and contract review. The AIMS can build on that work by making sure AI-specific concerns are considered where they’re relevant. 

This avoids creating a second governance structure alongside work that is already happening. 

A practical place to begin is with the third-party AI systems already in use. Once those systems are visible and responsibility has been established, the organisation can look at whether the supplier information it holds is still sufficient and whether the original approval reflects how the system is being used today. 

Third-party AI can then be brought into the wider processes used to manage AI risk and respond when circumstances change. 

For organisations beginning ISO/IEC 42001 implementation, this can make the work much more manageable. Perfect visibility into an external model may not be possible, but the organisation can still build a repeatable way to understand what it is using and make informed decisions about the parts that remain within its control. 

Buying an AI system does change the organisation’s relationship with the technology, but it doesn’t remove the need to govern its use. 

Third-party systems still need to be understood before they’re approved, and those decisions may need to be revisited once the technology is in use. ISO/IEC 42001 provides a management-system structure for keeping that governance connected over time. 

Safeshield’s ISO/IEC 42001 Resource Hub brings together practical guidance on Artificial Intelligence Management Systems and implementation. You can use the Hub to explore third-party AI governance in the wider context of ISO/IEC 42001 and find the resources most relevant to your organisation.