Suppliers, Cost and Footprint — outsource ความรับผิดชอบไม่ได้Suppliers, Cost and Footprint — Outsourcing Technology Does Not Outsource Accountability

🤔 If your vendor swapped the model tonight without telling you, would yesterday's release evidence still hold?

The previous post, One Evidence System, ended on the proposal that an organisation should tie the obligations of many frameworks to a single body of evidence instead of opening a new folder every time a new rule arrives. This post asks the question that follows immediately and is almost never asked in the same room — if most of the evidence in that folder comes from systems we do not own, what are we governing it with, and when one of those systems changes itself on a Tuesday night, who finds out?

The whole post's short answer is one sentence from Chapter 10 of AI Transformation as an Organizational Core: "Outsourcing technology does not outsource accountability." What travels with the contract is the work, not accountability. Making that fact governable in practice takes three things at once: a contract covering eleven clauses including exit, the correct denominator for cost, and a footprint meter that measures the total after usage grows rather than measuring per token.

1. The Night the Vendor Changed the Model

Picture it this way. On Monday your team clears the release gate cleanly: the test suite is complete, there are results on the edge cases, there are severe-case statistics, the owner has signed. The evidence file is thick enough to put in front of an auditor on the spot. On Tuesday night the model provider upgrades the version sitting behind the same endpoint. The model name in the API does not change. The price does not change. The documentation does not change. On Wednesday your system still runs, still answers, still passes every line on the dashboard. The only thing that has changed is that the evidence file you signed on Monday now describes a system that no longer exists.

Let me be clear before going further: this is not an incident report with a company name and a date behind it. It is one sentence of the book made visible, and the sentence is very direct. Chapter 9 puts it this way: "Production is the final evaluation environment, not the end of evaluation. Supplier model changes, new user behavior, or policy updates can invalidate previous evidence." — and the Thai companion of the same book renders it as "Production is the final evaluation environment, not the end, because when the supplier, user behaviour or policy changes, the old evidence may no longer hold."

What makes this mechanism frightening is not its violence but its silence. Nothing crashes. No alert fires. Nobody calls at three in the morning. What expires is the claim that we once proved something, and a claim never makes a sound when it dies. It stays quiet until the day someone asks — an auditor, a regulator, a customer whose application was refused, or the other side's lawyer — and only then do we discover that the document in our hands describes something different from what has actually been running.

Chapter 10 files the behaviour that leads to this state under its list of failure patterns, in the shortest possible words: "assuming the vendor owns risk", or in the Thai companion, "believing the vendor carries the risk for us". Chapter 9 adds the one that always travels beside it: "treating vendor testing as sufficient" — "trusting the vendor's tests". Neither of these is the carelessness of a lazy team. Both are the reasonable conclusion if we think what we bought is a "service" in the sense that electricity or storage is a service. The trouble is that what we bought is not that. We bought a component that will take part in decisions with real people on the receiving end, and the duty to answer for whether those decisions were right has never moved with an invoice.

The book defines accountability in its glossary in a way that closes every exit: "Clear ownership for decisions and effects, supported by answerability, evidence, escalation, remedy, and consequences — not responsibility assigned to the model." That last clause is usually skimmed, and it is the heart of it. If responsibility cannot be assigned to the model, it cannot be assigned to the model's owner either.

💡 My view: of Chapter 10's five operating principles, the one I think changes how an organisation works most immediately is the fourth — "Make supplier change and exit governable · Vendor dependence is part of the risk perimeter", or in the Thai companion, "make supplier change and exit governable; vendor dependence sits inside the risk perimeter". The phrase doing the heavy lifting is risk perimeter. Most organisations draw the perimeter at the edge of their own systems and write along that edge "this part belongs to the vendor". This principle says the line has been drawn in the wrong place. Vendor dependence is inside the perimeter, not outside it.

The other four principles of the chapter always work around the fourth. Principle 1, Maintain a live inventory and named owner — governance begins with knowing what exists, which means the inventory must also record which provider each system hangs from. Principle 2, Map obligations to evidence — reuse artifacts responsibly without claiming the frameworks are identical. Principle 3, Use law as the floor and ethics for the gap — define prohibited uses, affected groups and remedy. And principle 5, Measure lifecycle sustainability and rebound — unit efficiency can coexist with rising total impact, which is the subject of the whole of section 4 of this post.

2. Eleven Clauses — and the Eleventh Is Exit

Chapter 10 does not leave this as a floating principle. It lists the contract topics as a closed list of eleven^[1] in a single sentence: "Govern suppliers through contracts covering data use, customer-data training, model and subprocessor changes, evaluation evidence, logs, security tests, incident notice, audit support, continuity, intellectual property, and exit." The Thai companion renders it as "govern suppliers through contracts covering data use, training on customer data, model or subprocessor change, evaluation evidence, logs, security tests, incident notice, audit support, continuity, IP and exit."

Before the table, one condition stated clearly, once, because this section reads like contract drafting and it is not — the book states plainly that this is not legal advice, and that real use must go through review for the jurisdiction and the industry. The eleven items are a starting frame for asking questions, not wording to drop into an agreement. The book itself insists that "Role and system classification require qualified legal analysis."

The table below is the worksheet I walk through with the procurement team and the legal team together, in one room, half a day per provider. The second column is what to ask for, the third is the evidence that request turns into, and the fourth — the column that shortens the meeting most — is what breaks if the box is empty.

Clause 11 is the one that goes missing most often, and it goes missing for an understandable reason. At signing time nobody wants to talk about ending the relationship; it looks like distrust on day one. Chapter 3 solves that political problem by reframing it as a budgeting question. Its fifth principle reads "Fund scale and exit together — every investment needs fallback rollback and retirement conditions", or "fund the scale-up together with the way out; every proposal needs fallback, rollback and retirement conditions." Once exit is a line in the budget, it stops being an accusation and becomes the standard shape of an approval paper.

Provider concentration is a portfolio-level risk

Even the best contract, with all eleven clauses in place, cannot answer one question, because the question does not live at contract level. Chapter 3 puts it in the metrics list of the decision portfolio in two words — provider concentration — which the Thai companion calls "concentration at the provider", and pairs it with one of the same chapter's failure patterns: "ignoring shared-model concentration".

The mechanism that lets this risk slip past every approval process is more interesting than the risk itself. Every team assesses its own system separately. Each team concludes, honestly, that "the risk of our system is acceptable", and every one of those conclusions is correct at its own level. But no forum asks the question that is only visible from the portfolio: if every job the organisation cannot do without runs on the same provider, what is the risk at organisational level? Concentration is a property of the sum, not of the parts, and so it is invisible in any component's report, however well written.

Model providers carry legal duties of their own

Contracts are not the only instrument. In the European Union, the law places some duties directly on model providers. Verified against the official text on 5 September 2026: EU AI Act Article 53 requires providers of a general-purpose AI model to draw up and keep up to date the technical documentation of the model, including its training and testing process and evaluation results, and to make information and documentation available to developers who intend to integrate the model, so that they can genuinely understand its capabilities and limitations^[2] — and that article was not amended by the 2026 amendment.

Two cautions must always travel with the paragraph above. First, this law does not attach duties to the word "supplier"; it attaches them to defined roles — provider, deployer, importer, distributor, and provider of a general-purpose AI model — and your organisation may itself be one of them. Classifying roles requires qualified legal advice. Second, the deadlines have just moved. Verified on 5 September 2026: the EU AI Act has been generally applicable since 2 August 2026, while the high-risk deadlines were postponed by Regulation (EU) 2026/1744 of 8 July 2026, in force from 27 July 2026, to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems^[3]. A postponement does not delete a duty; it moves a date. An organisation that waits for that date before starting to ask providers for documentation will be starting several of its own contract cycles too late.

At the level of standards and frameworks, the book uses wording I think is worth copying whole: "Several frameworks can share evidence without being treated as interchangeable". NIST AI RMF supplies lifecycle functions; ISO/IEC 42001 specifies an AI management system, which as of 5 September 2026 remains a standard published in December 2023^[4]; ISO/IEC 42005 addresses lifecycle impact assessment; and the OECD AI Principles, adopted in May 2019 and updated in May 2024, ask actors to "apply a systematic risk management approach to each phase of the AI system lifecycle on an ongoing basis" together with traceability across the system's life^[5].

3. The Economics Column — Getting the Denominator Right

The book's executive brief lays out a board scorecard with six columns — Value, Quality, Risk, People, Learning and Economics — and the Economics cell is written in a single very short line: "Total cost per successful outcome and reusable capability share". The Thai companion compresses it to "Economics, from cost per successful outcome."

And the sentence that must travel with this scorecard every time is: "No single composite score should replace this view. A faster process with rising severe errors is not progress. A safe system that produces no outcome value is not transformation. A productive workflow that exhausts reviewers is not sustainable." The six columns may never be collapsed into one score. A faster process with more severe errors is not progress. A safe system that creates no value is not transformation. And a workflow that produces a great deal while exhausting its reviewers is not sustainable.

The important word in this column is per, not cost. The numerator is what everyone enjoys arguing about, but what decides whether the report tells the truth is the denominator — and the denominator the industry uses by default is the token. The FinOps Foundation, the profession's central reference, lists AI cost KPIs as cost per token, per inference and per API call^[6]. These figures are not wrong; they are exactly what an engineer tuning a system needs. But they cannot answer the board's question, because a falling cost per token while the number of jobs that actually complete also falls is a report in which the numbers improve and the business declines at the same time — and nothing in that report is inaccurate.

To be straight about attribution: the unit "total cost per successful outcome" belongs to the book, not to the FinOps Foundation. I cite that source to show that the industry's default meter really is the token, rather than a caricature I invented. And because it is the default, an organisation has to spend deliberate effort to change it. The correct denominator will never appear in a report on its own.

The word "total" has five lines in it

The numerator can be truncated too. Chapter 4 expands "total cost" to all of its lines in its metrics list: "value after model, control, review, incident, and rework cost" — value after the cost of the model, controls, review, incidents and rework. These five lines almost never appear in the same document, because each is recorded by a different system and lands on a different budget.

Chapter 3 adds a sixth line that I think matters most for deciding what to stop: evidence cost — the money and time spent proving the system works correctly. When the evidence cost of a job exceeds the value that job creates, the answer is not to reduce the evidence. The answer is to retire the job. Cutting evidence to make the number look better simply moves the cost into the Risk column and then stops measuring it.

The other half of the Economics column is reusable capability

The second half of the Economics line is reusable capability share, which connects straight into Chapter 5's AI and data factory. The book says the factory has six reusable services: data products provide governed facts; context services assemble instructions, retrieved evidence and memory; model services route tasks to the smallest adequate model and manage provider change; evaluation services hold labeled cases, judge calibration and test execution; tool registry services define scopes, schemas, effect classes and approval requirements; and observability services capture traces, outcomes, cost, drift and incidents.

And the closing sentence of that paragraph in the book is what makes this a single post rather than two topics stitched together: "Shared security, privacy, FinOps, and sustainability controls span the six." Security, privacy, FinOps and sustainability run across all six services. In Figure 6 of the book, the dark band beneath the factory reads SHARED ASSURANCE • SECURITY • PRIVACY • FINOPS • GREENOPS, drawn bilingually with the Thai gloss beside it. That is the structural answer to why cost and footprint belong in one post — in the book's architecture they are the same band running under every service, not two departments' separate projects.

The practical consequence is that Chapter 5's metric holds the two together in one unit from the start: "energy and cost per successful task" — energy and cost per successful task. If an organisation measures both with the same denominator, the argument about "saving money but burning energy", or the reverse, ends in numbers instead of ending in opinions.

4. Footprint — Read the Numbers Correctly, Then Measure Your Own

The book opens this topic with a sentence that fixes the position of the whole subject: "Sustainability belongs inside the business case." — sustainability lives in the business case, not in an annual report published after every decision has already been taken. And the glossary defines sustainable AI as "designing and operating AI with measured attention to energy, carbon, water, hardware, location, utilization, vendor efficiency, and societal value." Notice vendor efficiency in that list. It is the bridge the book itself throws back to section 2: in the book's own words, the contract question and the energy question are not separate.

Now the numbers. The IEA estimates that data centres worldwide used about 485 TWh of electricity in 2025 — a figure for all data centres, not for AI workloads alone — and projects roughly 950 TWh in 2030, about 3 percent of global electricity demand in that year^[7]. Verified on 5 September 2026: the IEA's Key Questions on Energy and AI was published on 16 April 2026 and still carries this set of figures exactly as the book cites them. That report builds on the IEA's 2025 flagship, Energy and AI^[8].

And the sentence that must always travel with all three figures is the book's own: "These are uncertain sector scenarios, not the meter for one use case." — uncertain sector scenarios, not the meter for a single use case. The IEA's own report notes that its central estimate remains close to the trajectory the 2025 report laid out, and that bottlenecks along the value chain are making the more aggressive scenarios less likely in the near term. That is the language of modelling, not the language of forecasting.

If a global figure cannot be a meter, what should an organisation measure? The book gives a list of five in one sentence: total energy, emissions where estimable, water where material, hardware lifecycle, and rebound when lower unit cost drives far more use. The first four are accounting. The fifth is behaviour, and it is the one that gives the other four their meaning.

Rebound is the mechanism that makes most sustainability reports comfortable reading for no good reason. The standard story runs like this. A team moves to a smaller model. Cost per call falls visibly. Energy per call falls with it. The slide goes to the board with a beautifully descending line. What the slide does not show is what happened next — once it is cheap, other teams switch it on too; work that was not worth doing becomes worth doing; call volume across the organisation grows faster than unit cost fell; and the absolute total, in both money and energy, ends up higher than before. Every per-unit number on that slide is correct.

Chapter 10's fifth principle compresses this into one sentence I would put on the cover of every report of this kind: "Unit efficiency can coexist with rising total impact". The word coexist was chosen carefully. The book does not say unit efficiency is a deception. It says the two numbers can be true at the same time, so a report that shows only one is not wrong but is incomplete. There is exactly one practical remedy: every time a per-unit figure is reported, the absolute total for the same period must be reported next to it.

One caution about attribution. The list of five things to measure belongs to the book, not to the OECD. What is verifiable in the OECD documents is the first value-based principle, "inclusive growth, sustainable development and well-being", and Principle 1.5 Accountability, which calls for a systematic risk management approach across the AI system lifecycle^[5]. No text was found there requiring energy, carbon or water to be measured. So I cite the OECD for the lifecycle risk-management frame, and the book and the IEA for the list of what to measure.

5. Route to the Smallest Adequate Model — and Measure It

The rule the book gives is one self-contained sentence: "Route tasks to the smallest model that meets quality and risk requirements and compare footprint per successful outcome rather than token alone." The Thai companion renders it as "use the smallest model that meets the criteria, and compare footprint per successful outcome."

The words readers skip most often are that meets the requirements. This rule is not "use the smallest model", and it is not "use the cheapest model". It is a two-layer rule: the first layer is the quality criteria and the risk criteria, declared in advance; the second layer is choosing the smallest of those that clear the first. The order may not be swapped. An organisation that swaps it will get a system that is genuinely cheaper and genuinely wrong more often, and will pay the difference back in the review, incident and rework lines of section 3, where nobody counts it.

The book's architecture places this responsibility at a single point on purpose. The AI and data factory's model services do two things in one service: "route tasks to the smallest adequate model" and "manage provider change". That grouping is not an accident. Choosing model size and coping with a provider's version change are the same question asked at different times — both ask "what level of capability does this job need, and how do we know we are still getting it?"

The advice also has independent confirmation from outside the book. The FinOps Foundation states directly that organisations should "avoid using the most complex and expensive models for every task, as this often leads to unnecessary costs"^[6]. The difference is that the book puts a risk-criteria layer in front, which a cost-focused document has no duty to carry.

A caution for anyone about to set a target: both "reusable capability share" and "share of tasks routed to the smallest adequate model" are metric definitions in the book, not values measured anywhere. The book gives no target numbers, and I will not invent any. The right value depends on the mix of work in that particular organisation. What can genuinely be measured is your own trend against your own previous quarter.

The measurement design table

The table below is this post's second worksheet, and it should be filled in before measurement starts, not after the first pile of data has arrived. The most important column is the fourth: a metric with no named owner becomes a slide nobody updates within two quarters. And the second column forces every row onto the same denominator — the successful outcome.

The last row exists to prevent one mistake: reporting the first seven rows and stopping. All seven of those are per-unit figures, and by Chapter 10's fifth principle, an improving per-unit figure and a rising total can be true together. The eighth row is therefore not an extension. It is the row that makes the first seven readable honestly.

None of this happens in a vacuum — it belongs in the previous post's working session

Neither of this post's two topics needs a new forum. Both are steps in the Impact and obligation mapping working session, the same session post #16 One Evidence System already walked. That session has seven steps, and the fifth and sixth are ours — "Review vendor evidence and exit", and "Estimate energy and model-sizing options" — before reaching the seventh, deciding proceed, modify, pause or prohibit and naming the evidence gaps.

I like that placement a great deal, because it makes the supplier question and the energy question happen before the decision, rather than after the system is live in the form of a questionnaire circulated back for completion. And it means an organisation does not need a new working group to start on this. It needs two extra lines on an agenda that already exists.

6. Metrics That Matter

Chapter 10's metrics list has thirteen entries. The table below takes only those that concern suppliers, cost and footprint, then adds two from Chapter 3 and the board scorecard, with a Scorecard column as this series does, so that each metric's column on the board is visible.

This table leans visibly towards Economics and Risk, and that is correct for this post's role. Other posts in the series own the Value, Quality, People and Learning columns — the caution is not to lift this table and use it as a whole scorecard, because the book forbids collapsing the six columns into a single view from its first page.

Failure patterns

• Assuming the vendor owns risk — the book's own words. It is a reasonable conclusion if we mistake what we bought for a utility service, but the duty to answer for whether a decision was right has never moved with an invoice.
• Treating vendor testing as sufficient — Chapter 9's failure pattern. The provider's test results sit in the provider's context, not in our workflow, our language, our data and our users.
• No exit clause — this one I derive from Chapter 10's fourth principle together with Chapter 3's fifth principle. It is not wording the book prints in its failure list, but the result is the same: a relationship we cannot leave is not a relationship we chose.
• Cost per token as the KPI — derived from the book's instruction to compare footprint per successful outcome rather than per token alone. Per-token figures are useful to engineers, but they can improve while fewer jobs actually complete.
• Efficiency claims without the total — Chapter 10's fifth principle directly. Improving unit efficiency and rising total impact can always live together.
• Sustainability outside the business case — the inverse of "Sustainability belongs inside the business case". Once sustainability is a separate annual report, it can never change a decision in time.
• Describing guidance or certification as proof of legal compliance — the book's own words, and the one that bites hardest in a supplier context, because a certificate is the thing a salesperson always has to hand.

Six of these seven can be fixed with documents — the contract in section 2 and the measurement table in section 5. The last one cannot, because it is a mistake about the type of the argument. A certificate says that one organisation operates a management system of a certain kind. Legal evidence says that a particular act in a particular jurisdiction is lawful. No quantity of the first converts into the second.

7. The Road Ahead

If I had to compress this whole post into one change of practice, I would choose changing the denominator. Change the question in the monthly report from "how much did we pay for models this month?" to "this month, what did one usable outcome cost in total and how much energy did it use, and what is the organisation-wide total against last year?" The first question produces price negotiations. The second produces decisions.

Three things you can do next week. One: take the largest AI supplier contract the organisation holds and walk the table in section 2 clause by clause, marking which are present and which are absent — in my experience clauses 3, 5 and 11 are most often empty together. Two: open one spreadsheet and fill in every cell of the table in section 5, especially the Owner column; the cells you cannot fill are the most useful answer this exercise produces. Three: take the latest AI cost report and look at what the denominator is. If it is tokens or requests, add one more line divided by the number of genuinely usable outcomes, and put the two lines side by side in next month's report.

All of this — a classified portfolio, redesigned workflows, an assembled factory, complete contracts and a meter that divides correctly — is still not a sequence an organisation can start on Monday morning. It is a list of what must exist, not a plan. What is missing is the timeline and a scope small enough to actually finish, and that is the whole subject of the next post.