AI as an externally provided process is the framing almost every management system is missing right now. Your organization did not build the model. It bought access to one, pointed it at a process that lives inside a certified system, and in most cases never opened a supplier file. That single omission is where the exposure sits — not in the technology, and not in whether the outputs are any good.
Direct Answer
AI as an externally provided process means treating a purchased or subscribed artificial intelligence tool as what ISO management system standards already call an externally provided process, product or service. The organization did not develop it, cannot fully inspect it, and remains accountable for the results it produces. ISO 14001:2026 Clause 8.1 requires that externally provided processes relevant to intended outcomes be controlled or influenced, with the type and extent of that control defined inside the management system. Nothing in that sentence contains an exemption for software that reasons.
This article covers what AI as an externally provided process actually requires, why the vendor belongs in your supplier file, the five clauses that already govern the arrangement, the silent model update that changes your process without a change request, and the question underneath all of it — who owns the harm when the output is wrong. If your organization is running more than one standard, the ISO Procedure Templates and Guides library carries the procedure families this article keeps pointing back to.
A note on scope before going further. This is a management system article, not a technology review. MSI does not implement ISO/IEC 42001, and where that standard appears below it appears as landscape only. The argument here is that you do not need a new standard to control AI as an externally provided process. You need the one already on your wall, applied honestly.
Definition
What Is AI as an Externally Provided Process?
Bought. Not built.
Start with the plain reading. ISO 14001:2026 replaced the older language of “outsourced processes” with externally provided processes, products or services. The change was not cosmetic. It widened the net. An externally provided process is anything supplied from outside the organization that is relevant to the intended outcomes of the management system, whether or not anyone described it as outsourcing when the contract was signed.
By that definition, AI as an externally provided process covers a very ordinary list. A subscription language model drafting procedure revisions. A vendor platform scoring supplier risk. A classifier flagging defects on an inspection line. A summarizer condensing complaint narratives before they reach the corrective action process. A scheduling engine deciding maintenance intervals. None of these were built by the organization using them. All of them sit on a path that leads to an intended outcome.
The reason this framing matters is that it resolves a question people keep asking the wrong way. The common question is “which clause covers AI?” There isn’t one, and waiting for one is the mistake. The better question is “what is this thing, in the vocabulary my system already uses?” Answered that way, AI as an externally provided process is not a novel category at all. It is a provider, and providers have been governed by these standards for three decades.
The standards were written to absorb things that had not been invented yet. That is the entire point of requirements expressed as risk and control rather than as a list of approved technologies. Treating AI as an externally provided process as ordinary external provision is not a workaround. It is the design working as intended.
MSI client experience suggests the organizations that struggle here are not the ones with weak systems. They are the ones with strong systems whose purchasing process was built around physical goods and named service providers, and who never had a reason to ask whether a monthly software subscription belonged in the same file. It does. MSI’s pillar on the purchasing and supplier control procedure covers why external provision is missed structurally rather than carelessly.
Where the confusion usually starts
Three habits keep AI as an externally provided process out of the supplier file, and they are worth naming because each has a different fix.
- It was expensed, not procured. A departmental card paid for a subscription under the approval threshold, so purchasing never saw it and no evaluation was triggered.
- It was classified as a tool, not a process. Nobody puts a spreadsheet in the supplier file, and the AI tool arrived looking like a spreadsheet. The distinction that matters is not what it looks like — it is whether it produces or influences an output the system relies on.
- It arrived inside something else. The vendor added an AI feature to a platform you already approved. The supplier evaluation on file predates the feature and says nothing about it.
That third one is the most common and the least visible. Your approved supplier record is accurate about a product that no longer exists in the form you approved. Understanding AI as an externally provided process starts with an inventory honest enough to catch it.
Supplier Status
Why Your AI Vendor Is a Supplier You Never Evaluated
Evaluate. Approve. Record.
Direct Answer
Treating AI as an externally provided process correctly means the provider enters the same evaluation, selection, approval and re-evaluation cycle as any other external provider. ISO 9001 Clause 8.4 requires the organization to determine and apply criteria for evaluating external providers and to retain documented information of the evaluations and any actions arising. ISO 14001:2026 and ISO 45001 reach the same place through Clause 8.1. The obligation does not depend on whether the provider ships a physical item.
Ask the question the way an auditor eventually will. Who evaluated this provider? Against what criteria? Who approved them, and on what record? When were they last re-evaluated, and against what performance data? For conventional suppliers most organizations can answer in under a minute. For AI as an externally provided process the answer is usually silence, followed by someone explaining that it is just software.
That answer does not survive contact with the standard. The determination required is not about the physical form of what is supplied. It is about the effect on the organization’s ability to achieve intended outcomes. A model that drafts your work instructions has a larger effect on conformity than most of the vendors currently sitting on the approved list. The supplier management program that fails in year two usually fails for exactly this reason — the list reflects spend rather than risk.
Control or influence, and why AI lands on the influence side
ISO 14001:2026 Clause 8.1 asks for control or influence, and requires the organization to define the type and extent of both. That distinction does real work when the subject is AI as an externally provided process, because direct control is mostly unavailable. You cannot inspect the training data. You cannot audit the weights. You cannot require the provider to hold the model static for your convenience.
What you can do is exercise influence, and influence is the larger half of the obligation rather than the optional one. Specification. Selection criteria. Contract terms covering notification of change. Defined use boundaries. Required disclosures. Performance data exchanged on a schedule. MSI’s coverage of ISO 14001 externally provided processes develops the control-versus-influence split in depth, and every argument in it transfers to AI as an externally provided process without modification.
| Determination | Conventional provider | AI provider |
|---|---|---|
| Inspect the product | Incoming inspection, certificate of conformity | Not possible directly — substitute output sampling against a known-answer set |
| Audit the provider | Second-party audit, questionnaire | Documentation review, published evaluations, third-party attestations |
| Control change | Change notification clause, first-article on revision | Contractual notification of model change — rarely offered, must be negotiated |
| Measure performance | On-time delivery, defect rate | Error rate against sampled outputs, override frequency, escalation rate |
| Disqualify | Criteria set in advance, alternate source qualified | Criteria rarely set; alternate source rarely qualified — the real single-source risk |
The bottom row deserves a sentence of its own. Organizations that would never single-source a critical component have single-sourced AI as an externally provided process without noticing, because the decision was never framed as sourcing. If the provider changes terms, degrades performance, or exits, there is no qualified alternate and no transition plan. That is a continuity risk sitting inside a certified system with no entry in the risk register.
Score your purchasing process before you rewrite it
The free Purchasing and Supplier Control Maturity Framework scores eight elements — criteria, evaluation, approval, re-evaluation, records, change control, contingency and competence — and returns a band and a priority order in about six minutes. Nothing to enter first. If your AI providers are missing from the file, this is the diagnostic that shows you where they should sit.
Clause Map
Which Clauses Govern AI as an Externally Provided Process?
Five. Not one.
Direct Answer
Five clause families already govern AI as an externally provided process across ISO 9001, ISO 13485, ISO 14001:2026, ISO 45001 and ISO 7101: operational control and external provision, purchasing and provider evaluation, planning of changes, competence, and monitoring validity. No new clause is required and none is coming in time to help. The organization that maps its AI arrangements onto these five is compliant today; the one waiting for an AI clause is uncontrolled today.
1. Operational control and external provision
ISO 14001:2026 Clause 8.1 states that externally provided processes, products or services relevant to the intended outcomes shall be controlled or influenced, and that the type and extent of control shall be defined within the management system. ISO 9001 Clause 8.4 carries the equivalent obligation with an explicit evaluation and re-evaluation requirement. ISO 13485 Clause 7.4 goes further still, tying the extent of control to the effect on the medical device. Whichever standard you hold, AI as an externally provided process is squarely inside the clause. The ISO 14001:2026 Procedure Templates and Guides resolve the external provision wording for the new edition directly.
2. Purchasing and provider evaluation
Criteria set in advance. Evaluation performed. Approval recorded. Re-evaluation on a defined trigger. Disqualification criteria decided before the relationship is under strain rather than during it. Applied to AI as an externally provided process, the criteria have to be written fresh, because nothing on a conventional purchasing questionnaire asks a provider what happens to your outputs when they retrain.
3. Planning of changes
ISO 14001:2026 Clause 6.3 requires that changes affecting the management system be carried out in a planned manner and managed so intended outcomes are still achieved. Its guidance names developments in knowledge and technology, and changes in external providers, among the sources of change the organization plans for. Introducing AI as an externally provided process into a controlled process is a change. So is the provider changing the model underneath you — which is the section that follows, and the hardest problem in the whole subject. MSI’s work on change management workflow and on regulatory change management both run through Clause 6.3 as the routing point.
4. Competence
Clause 7.2 requires the organization to determine the competence necessary for persons doing work under its control that affects performance, and to retain evidence of it. When AI as an externally provided process enters a process, the competence requirement changes shape rather than disappearing. The person reviewing an AI-drafted procedure needs the competence to know when the draft is wrong, which is a higher bar than the competence to write it slowly. MSI’s human resource management procedure guidance covers why a determination like this cannot be satisfied with a single verification method.
5. Monitoring that produces valid results
Clause 9.1 requires the organization to determine the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results. Where AI as an externally provided process is the instrument — classifying, scoring, flagging, ranking — validity is a live question rather than a formality. The parallel that lands with operations teams is calibration. An uncalibrated gauge produces numbers, and the numbers are worthless. MSI’s pillar on control of monitoring and measuring equipment and the calibration maturity model both make the argument better than an AI-specific framework would.
One handoff worth naming. This article is about selecting, approving and controlling AI as an externally provided process. Once the arrangement is live and an internal auditor has to examine a process the system now runs, the evidence question changes entirely — MSI’s pillar on auditing AI agents picks up precisely where this one stops.
The procedures that make the clause map operational
Reading the clause map is the easy part. Writing the procedure that assigns owners, criteria and records to each of the five is the work. MSI’s ISO Procedure Templates and Guides cover fifteen procedure families across five standards in editable Word, with the decisions an experienced practitioner would make already recorded and every point where two standards diverge documented rather than averaged away.
The Core Problem
The Silent Model Update: AI as an Externally Provided Process That Changes Without You
Changed. Unannounced. Unrecorded.
Direct Answer
The defining risk in AI as an externally provided process is that the provider can change the product after you validated it, without a change request, without notification, and without any record entering your system. Every conventional supplier control assumes you find out when the thing you buy changes. AI providers routinely update models on their own schedule. The result is a process operating against evidence that quietly expired.
Consider how this fails in an ordinary week. A team validates an AI-assisted classification step, samples two hundred outputs against a known-answer set, records an acceptable error rate, and puts the arrangement into service with a documented control. Six weeks later the provider ships an update. The behavior shifts — possibly for the better, possibly not. No purchase order changed. No revision number moved. The validation record still says the process was verified, and it is now describing a product that no longer exists.
No conventional supplier could do this. A machined part arriving with a different tolerance triggers incoming inspection. A revised chemical formulation triggers a certificate review. The entire apparatus of purchasing control assumes change is visible. AI as an externally provided process breaks that assumption, and it breaks it silently, which is why it belongs in the risk register rather than the IT backlog.
A supplier changed the product, the change was not notified, the verification evidence was not refreshed, and the process continued. Written that way, it is a finding any auditor would recognize. The only reason it goes unnoticed is that nobody filed the AI provider as a supplier in the first place.
Four controls that actually work
- Negotiate notification into the contract. Most providers do not offer change notification by default. Enterprise agreements sometimes allow it, including version pinning or a deprecation window. Ask before signing, because you will not get it afterward.
- Pin the version where the standard permits. Where the provider offers a stable model reference, use it and treat a move between versions as a planned change under Clause 6.3, with re-verification as the acceptance condition.
- Re-verify on a schedule, not only on notification. If the provider will not tell you when the model changed, detect it. A small fixed evaluation set run monthly against a recorded baseline turns an invisible change into a data point. This is calibration logic applied to AI as an externally provided process, and it is cheap.
- Define what a failed re-verification triggers. Decided in advance: who is notified, whether the process suspends, what happens to output produced since the last passing check. Deciding this during an incident is how organizations end up with no answer at all.
Control four is the one MSI client experience suggests is most often skipped, and it is the one that determines whether the other three produce anything. Detection without a defined response is a monitoring arrangement that generates concern rather than action. The risk management procedure template guidance covers why treatment routing — decisions becoming actions with owners and dates — is the element that most registers leave hollow.
Accountability
Who Is Responsible When AI as an Externally Provided Process Causes Harm?
Delegated. Never transferred.
Direct Answer
Responsibility for AI as an externally provided process can be delegated. Accountability cannot. ISO 14001:2026 states the principle directly in its guidance on terminology: the word “ensure” means the responsibility can be delegated, but not the accountability. Clause 5.1 places accountability for the effectiveness of the management system on top management, and the annex confirms that the organization retains authority and accountability for how it fulfils the requirements. Buying the process does not buy your way out of owning it.
Three separate systems answer this question, and they converge. The first is the standard itself, and the language above is as close to unambiguous as ISO gets. The registrar writes the finding against the certificate holder. There is no mechanism by which a nonconformity attaches to your provider instead.
The regulatory split — and the trap inside it
The second system is regulation, and the EU AI Act is currently the clearest articulation of how responsibility divides. It separates the provider, which develops and places the system on the market, from the deployer, which uses it professionally under its own authority. Provider obligations sit at Article 16; deployer obligations at Article 26, covering human oversight, usage logs, and reporting serious incidents. For most organizations running AI as an externally provided process, deployer is the correct classification.
Article 25 is the trap. A deployer becomes a provider — inheriting the full obligation set — in three circumstances: putting its own name or trademark on a high-risk system, making a substantial modification to a high-risk system already on the market, or changing the intended purpose of a system so that it becomes high-risk. Fine-tuning a vendor model on proprietary data, restructuring a retrieval pipeline, or pointing a general-purpose system at a high-risk use sits close to that line. The reclassification is automatic. There is no notification step and no registration event that tells you it happened.
Sector regulators reach the same destination by their own routes. The employer owns the workplace safety duty regardless of which tool produced the assessment. The device manufacturer owns the quality system obligation regardless of which vendor supplied the analytics. The organization holding the environmental permit answers for the emissions number regardless of what generated it. MSI’s article on AI governance for business develops the red-line version of this principle: a consequential decision should not be handed to a system that can bear no responsibility for it.
The third system: ordinary liability
The third is tort law, and it follows the defect. Where harm traces to the design of the model itself, exposure sits with the developer. Where it traces to how the organization dropped AI as an externally provided process into a process without oversight, competence or monitoring, that is the deploying organization’s own negligence and the provider is not part of the conversation. Both can be true simultaneously, which is how liability normally distributes across a chain of supply.
What none of the three permit is the assumption that responsibility left the building when the invoice arrived. MSI’s piece on ISO 9001:2026 for boardrooms makes the governance version of the argument, and the future of risk covers the accountability gap that opens when decisions cannot be explained.
Contracts
Why the Indemnity Clause Does Not Move the Duty
Allocates cost. Not duty.
Direct Answer
An indemnity clause allocates cost between two companies after a loss. It does not transfer the duty owed to the injured party, and it does not change which organization a regulator considers responsible for AI as an externally provided process. Under the EU AI Act, reclassification from deployer to provider happens automatically on substantial modification or repurposing, and contractual allocation does not touch it. Procurement teams routinely believe the contract closed this. It did not.
The belief is understandable. In conventional supply, indemnity does real work — a defective component that causes a recall produces a recovery action against the supplier, and the commercial risk genuinely shifts. What does not shift, and never did, is the obligation the organization owes to the person harmed, the regulator with jurisdiction, or the registrar holding the certificate.
Applied to AI as an externally provided process, three distinctions are worth stating plainly for anyone reviewing a vendor agreement.
| What the contract does | What it does not do |
|---|---|
| Allocates financial loss between you and the provider | Extinguish your duty of care to a third party who was harmed |
| May cap the provider’s exposure — often at fees paid | Cap your exposure to a regulator, a claimant, or a certification body |
| Can create a notification and cooperation obligation you should negotiate for | Substitute for your own evaluation, monitoring and change control records |
The middle row is where the commercial reality bites. AI provider agreements frequently cap liability at the value of fees paid, which for a monthly subscription is a number with no relationship to the loss a wrong output can cause in a regulated process. An organization that has accepted that cap has not transferred risk. It has documented its acceptance of nearly all of it.
Read the cap before the indemnity. If the ceiling is twelve months of subscription fees and the process it feeds can produce a recall, a permit exceedance or an injury, then the contract has told you exactly how much of the risk stays with you. That number belongs in the risk register, not in the legal file.
The practical response is not to abandon the contract but to stop treating it as the control. Negotiate for change notification, cooperation on incident investigation, and data handling terms. Then build the internal controls as though the contract did not exist, because in front of a regulator it substantially does not. MSI’s guidance on supplier qualification in regulated supply and on supply chain best practices both make the same point from the buyer side.
Practical Method
How Do You Evaluate and Approve AI as an Externally Provided Process?
Criteria. Evidence. Decision.
Direct Answer
Evaluating AI as an externally provided process uses the same four-step structure as any provider evaluation — criteria set in advance, evidence gathered against them, an approval decision recorded with a named approver, and a re-evaluation trigger defined. What changes is the content of the criteria. Delivery performance and price are irrelevant. Change transparency, output verifiability, data handling, and defined use boundaries carry the weight instead.
Below is a working criteria set. It is written to be lifted into an existing purchasing procedure rather than to stand alone, because AI as an externally provided process should not get its own parallel process. One procedure, one approved list, one re-evaluation cycle.
| Criterion | What to ask | Evidence to retain |
|---|---|---|
| Intended use boundary | What process will this touch, and what is it explicitly not approved for? | Written use statement, approved by the process owner |
| Change transparency | Will the provider notify model changes? Is version pinning available? What is the deprecation window? | Contract clause or written provider statement |
| Output verifiability | Can outputs be checked against a known-answer set? Who checks, and how often? | Baseline evaluation record with date and error rate |
| Data handling | What happens to the information entered? Is it retained, used for training, or transferred? | Data processing terms, retention statement |
| Human decision point | Where does a competent person review before the output has effect? | Procedure step naming the role and the record |
| Competence impact | What must the reviewer know to recognize a wrong output? | Updated competence determination under Clause 7.2 |
| Continuity | If this provider stops or degrades, what happens Monday? | Named alternate or documented manual fallback |
| Disqualification | What performance or conduct removes approval? | Criteria recorded before the relationship begins |
A thirty-day sequence that fits around real work
Organizations rarely have the appetite to stop and rebuild. This sequence assumes the system already works and only the treatment of AI as an externally provided process needs to catch up.
- Days 1–5 — Inventory. List every AI arrangement touching a process inside the scope. Include the features that arrived inside platforms you already approved. Expect the list to be longer than anyone predicted.
- Days 6–12 — Classify by effect. Rank by effect on intended outcomes, not by cost. A free tool drafting controlled documents outranks an expensive one summarizing meeting notes.
- Days 13–20 — Apply the criteria to the top tier. Evaluate, record, approve or restrict. Restriction is a legitimate outcome and is faster to defend than an approval with no evidence behind it.
- Days 21–26 — Set the re-verification baseline. Build the fixed evaluation set, run it once, record the result and the date. This is the artifact that makes the silent update detectable.
- Days 27–30 — Route into the system. Update the purchasing procedure, the risk register, the competence matrix, and the management review agenda. If it does not enter those four, it will not survive the quarter.
MSI’s guidance on ISO procedure order and on what makes an effective ISO procedure both apply here, and the general test holds: hand the procedure to a competent person who has never done the task and see whether they can complete it without asking a colleague anything.
Move a 2015 environmental system to 2026 in a week, not a quarter
If the external provision wording is what stands between your environmental management system and the new edition, the ISO 14001:2026 Procedure Templates and Guides were built for exactly that position — experienced EHS managers with a system that already works and documents that need to catch up. External provision, planning of changes, and risks and opportunities are resolved to the 2026 text, with the clause movement mapped rather than guessed.
Closing The Loop
Feeding AI as an Externally Provided Process Into Management Review
Report. Decide. Resource.
Direct Answer
Management review is where AI as an externally provided process stops being an IT arrangement and becomes a governed one. ISO 14001:2026 Clause 9.3.2 requires inputs covering changes in external and internal issues, changes in risks and opportunities, monitoring and measurement results, audit results, adequacy of resources, and opportunities for continual improvement. AI provider performance lands in at least four of those. Clause 9.3.3 then requires decisions on changes and resources to come out the other side.
Management review is required across ISO 9001, ISO 13485, ISO 14001 and ISO 45001 — it is not an ISO 9001 peculiarity, and organizations running several standards can carry AI as an externally provided process into a single review rather than four. Five inputs are worth naming explicitly on the agenda.
- Provider performance data. Error rate against the fixed evaluation set, trend since the last review, override frequency by the humans reviewing outputs.
- Model changes in the period. Notified or detected, with what re-verification followed and what it found.
- Risks and opportunities. New entries arising from AI as an externally provided process, and whether continuity exposure has a named alternate yet.
- Competence adequacy. Whether the people reviewing outputs can actually recognize a wrong one, evidenced rather than assumed.
- Resource adequacy. Whether verification is being done because it is resourced, or skipped because it is not.
The fifth input is the one that determines whether the other four keep appearing. Verification that depends on somebody’s goodwill in a busy month is not a control. Putting the resource question in front of top management is how it becomes one, and Clause 9.3.3 requires that decisions related to resources be an output of the review rather than an afterthought.
Make the review produce decisions, not minutes
The ISO Management Review Toolkits carry the agendas, input tables, and decision records that turn Clause 9.3 into a working governance step — including the input rows most agendas leave off. If AI provider performance is going to reach top management at all, it reaches them through this meeting or not at all.
Two further connections are worth carrying into the same cycle. Nonconformities arising from a wrong output route through corrective action, and MSI’s work on the corrective action procedure where AI alone fails covers why cause analysis is the step that does not delegate. And in a device context, ISO 13485 risk management requires post-production information to feed the risk file — a linkage that AI-assisted complaint handling makes easier to break and easier to evidence, depending entirely on whether anyone designed it.
The Payoff
What Changes When AI as an Externally Provided Process Is Controlled Properly
Faster. Safer. Defensible.
It is worth ending on the benefit rather than the obligation, because organizations that do this well are not primarily buying protection. Four things change, and none of them are about certification.
Adoption speeds up. Teams that know the approval path can take it. Teams that do not, adopt tools quietly and outside the system, which is the outcome nobody wanted. A defined route for AI as an externally provided process converts shadow adoption into governed adoption without a moratorium.
Questionnaires get easier. Customer and regulator questions about AI use are arriving now. An organization with an inventory, criteria, evaluation records and a review cadence answers in an afternoon. One without spends a fortnight assembling something it hopes is true.
Failures get caught early. A fixed evaluation set run monthly finds drift while it is still a data point rather than after it has propagated into released work. That is the difference between a correction and a recall.
The decision becomes defensible. Foreseeability without a record is exposure. Foreseeability with a documented risk determination, a control, and evidence the control works is the strongest position an organization can hold — and it is available to anyone willing to write it down. Organizations transitioning both standards at once will find the sequencing covered in MSI’s ISO 9001 and 14001 transition plan, and the readiness scoring approach in MSI’s ISO 9001:2026 readiness scoring guide.
ISO 9001:2026 publishes on 16 September 2026, and ISO 14001:2026 published on 15 April 2026 with a transition deadline of 30 April 2029. Neither edition contains an AI clause. Both contain everything needed to control AI as an externally provided process for organizations willing to read external provision as it is written.
Talk it through before you write anything
If you are unsure whether your AI arrangements belong in the supplier file, whether a fine-tune crossed a line, or how much verification is proportionate to the process it feeds, a planning session will tell you in half an hour whether this is a procedure revision or a rebuild. No preparation required — bring the list of tools and the standards you hold.
Questions
Frequently Asked Questions About AI as an Externally Provided Process
Asked. Answered. Applied.
Is AI as an externally provided process really covered by ISO 9001 and ISO 14001?
Yes. Neither standard names artificial intelligence, and neither needs to. ISO 14001:2026 Clause 8.1 requires externally provided processes, products or services relevant to intended outcomes to be controlled or influenced, with the type and extent defined inside the management system. ISO 9001 Clause 8.4 carries an equivalent obligation with explicit evaluation and re-evaluation requirements. AI as an externally provided process meets the definition of external provision on a plain reading, so the clause applies without interpretation. The requirements were written as risk and control rather than as a list of approved technologies precisely so they would still work when the technology changed.
Do we need ISO/IEC 42001 to control AI in our management system?
No. ISO/IEC 42001 is an AI management system standard and exists in the landscape, but it is not required in order to control AI as an externally provided process inside an existing ISO 9001, ISO 13485, ISO 14001 or ISO 45001 system. MSI does not implement ISO/IEC 42001 and does not position it as a service line. The practical position is that an organization holding a current certificate already has the clause structure it needs — external provision, purchasing, planning of changes, competence and monitoring validity — and the work is applying it rather than acquiring a second system.
Does a free or low-cost AI tool still count as an external provider?
Cost has no bearing on it. The determination in the standard is about the effect on the organization’s ability to achieve intended outcomes, not about spend or contract value. A free tool drafting controlled documents affects conformity more than a costly one summarizing internal meeting notes. Ranking by effect rather than by invoice is the step that makes an inventory of AI as an externally provided process useful, and it usually reorders the list substantially. MSI’s supplier management program guidance covers why rating providers on spend rather than risk is the common failure.
Our AI vendor updated their model without telling us. Is that a nonconformity?
Not by itself — the provider is entitled to develop their product. The potential nonconformity is on your side: a change affecting the management system that was not planned under Clause 6.3, or verification evidence that is no longer valid for the process in operation. The defensible position is a contractual notification clause where one can be negotiated, plus a fixed evaluation set re-run on a schedule so an unannounced change becomes a recorded data point rather than an invisible one. That detection arrangement is the single most useful control in the whole of AI as an externally provided process.
Who is legally responsible when an AI output causes harm?
It depends where the defect sits, and the answers stack rather than substituting for each other. Under the standards, accountability stays with the organization — ISO 14001:2026 is explicit that responsibility can be delegated but accountability cannot. Under the EU AI Act, obligations divide between provider and deployer, and Article 25 automatically converts a deployer into a provider on rebranding, substantial modification, or repurposing into a high-risk use. Under ordinary liability, harm traceable to the model design points at the developer while harm traceable to careless deployment points at the deploying organization. Sector regulators are unaffected by any of it: the employer, the manufacturer and the permit holder each keep their own duties.
Can an indemnity clause in the vendor contract transfer our risk?
It transfers cost between the two companies, and it does so subject to whatever liability cap the agreement contains — frequently the value of fees paid, which for a subscription may be trivial against the loss a wrong output can cause. What it does not do is extinguish the duty owed to a person harmed, change which organization a regulator holds responsible, or substitute for your own evaluation and monitoring records. Negotiate the contract for change notification and cooperation, then build internal controls for AI as an externally provided process as though the indemnity did not exist.
How much verification is proportionate for an AI-assisted process?
Proportionate to the effect of a wrong output, using the same logic that sets calibration intervals and competence verification methods. A summarizer feeding an internal newsletter needs almost none. A classifier feeding release decisions, emissions reporting or clinical workflow needs a baseline evaluation set, a defined re-verification interval, a recorded acceptance threshold, and a decided response when the threshold is missed. MSI’s control of monitoring and measuring equipment pillar sets out the reasoning, and it transfers cleanly to AI as an externally provided process.
How does this differ from auditing an AI agent that is already running?
Different moment and different reader. This article covers selection, approval, change control and accountability — the work of bringing AI as an externally provided process into the system correctly. Auditing covers what an internal auditor samples once the arrangement is live: logs rather than interviews, the reconciliation of loaded procedure revisions against current ones, and the competence to evaluate evidence a person did not generate. MSI’s pillar on auditing AI agents covers that half, and MSI’s internal audit services and ISO 19011:2026 internal audit procedure guidance support the program around it.
Related Reading
Continue Building the System Around AI as an Externally Provided Process
Read. Score. Implement.
- Your Purchasing and Supplier Control Procedure Misses This — the clause almost every system skips
- ISO 14001 Externally Provided Processes — control versus influence under the 2026 edition
- Auditing AI Agents — what to sample once the arrangement is live
- AI Governance for Business — the red lines worth drawing before adoption
- ISO 19011:2026 Changes — the edition that withdrew 2018 with no transition period
- Why Your Sales Management Procedure Is Never Optional — change control on the customer-facing side
- Culture Change for Industrial Transformation — automation, knowledge loss, and the clauses that carry them
- ISO 9001 Procedure Templates and Guides — the full procedure family in editable Word
- SurePath — turnkey ISO certification when the system is being built rather than repaired
- SureResults — year-round maintenance that keeps provider re-evaluation from slipping
References and further reading
- ISO 14001:2026, Environmental management systems — Requirements with guidance for use
- ISO 9001, Quality management systems
- ISO 13485, Medical devices — Quality management systems
- ISO 45001, Occupational health and safety management systems
- ISO/IEC 42001, Artificial intelligence management system (reference only)
- European Commission AI Act Service Desk — Article 25, responsibilities along the AI value chain
- European Commission AI Act Service Desk — Article 26, obligations of deployers
- European Commission AI Act Service Desk — Article 16, obligations of providers
- NIST AI Risk Management Framework
- MIT AI Risk Repository
- U.S. FDA — Artificial intelligence and machine learning in software as a medical device
- eCFR — 21 CFR Part 820, Quality Management System Regulation
- U.S. OSHA — Law and regulations
- ASQ — Supplier quality resources
- OECD AI Principles
- Global ACI — accreditation authority
This article is general guidance and does not replace ISO 9001, ISO 13485:2016, ISO 14001:2026, ISO 45001:2018, ISO 7101:2023, any applicable regulation, or the judgement of a competent professional.
About Management Systems International (MSI)
Diana Lynn is President and Principal ISO Consultant at Management Systems International (MSI), a consulting firm she co-founded in 1998. With 28 years of experience including extensive AS9100 work in MSI’s early years, MSI’s track record includes 80+ certifications supported, 200+ audits attended, and 600+ professionals trained across manufacturing, technology, medical device, government, healthcare, and other regulated industries. Today MSI implements ISO 9001, ISO 13485, ISO 14001, and ISO 45001, with an expanding focus on ISO 7101 healthcare quality.
msi-international.com · 760-434-9141
