One Evidence System — PDPA, ETDA และ EU AI Act บนหลักฐานชุดเดียวOne Evidence System, Many Obligations — PDPA, ETDA and the EU AI Act on One Set of Evidence

🤔 Your organization has an AI committee, an AI policy and a certificate on the wall — so who can order a system stopped on a Friday afternoon?

The previous post, Evidence Before Change, walked the loop that turns an abnormal event back into a better system, and that loop rests on two quiet assumptions nobody mentions while the diagram is being drawn. The first is that somebody actually holds the authority to press stop. The second is that a file of evidence already exists to be preserved before the system is touched. If neither is true, even the most elegant incident-learning loop is a picture on a whiteboard. This post is about what makes those two assumptions true.

The shortest answer the whole post has to offer sits in a single definition from Chapter 10 of AI Transformation as an Organizational Core: governance is not a document, not a committee and not a certificate, but the system that decides what AI may do, who authorizes it, what evidence is required, and who acts when results are contested or harmful.^[1] And the way to keep that system from bloating past usability as a new framework arrives every quarter is to tie the obligations from every framework to a single set of seven evidence artifacts, and then reuse that evidence responsibly — rather than opening a new file cabinet each time a new acronym appears.

1. A Committee Is Not Yet Governance

Hold this scene in your head first. It is Friday afternoon, and the customer-service team reports that the system screening incoming applications has been rejecting one group of applicants at an unusually high rate since the morning. Nobody can prove yet that it is genuinely wrong, or merely an accident of this week's data — and nobody can prove that it is not. The only question that has to be answered within the hour is stop or don't stop. The question that follows it immediately is: who answers?

A great many organizations cannot answer that, even though they hold everything that looks like an answer. There is an AI committee that meets monthly with twelve months of minutes behind it. There is an AI policy that legal reviewed and that sits published on the intranet. There is a certificate framed outside the main meeting room. And yet when Friday afternoon actually arrives, what happens is four rounds of email trying to establish whose call this is — and by Monday the question is still in the air, the system is still running, and the applications rejected across those three days have already gone out.

The book puts its definition of governance in a single paragraph, and I think it is a paragraph worth printing on the meeting-room wall in place of the certificate.

Governance is the system by which an organization decides what AI may do, who authorizes it, what evidence is required, and who acts when results are contested or harmful. A committee without decision rights is not governance. A policy without inventory, controls, and monitoring is not governance either.^[1]

The book's Thai companion renders that same sentence with four of its words deliberately left in English — Decision Right, Inventory, Control and Monitoring — and it does not translate governance either. I follow that convention for the whole post, in both tracks, for the reason the companion does: these four are the names of things that either exist in an organization or do not, not concepts that survive being softened into a warmer word.

The definition is testable, because it is really four questions

What makes this definition more useful than the general phrase "AI governance" is that it breaks into four questions that are answered with the name of a person and the name of a document, rather than with a value.

• What AI may do — what is each system's declared scope, and what are the prohibited uses the organization has ruled out explicitly? If you cannot say, there is no line for anyone to cross.
• Who authorizes it — the job title that holds a real Decision Right over release and over stopping, not the name of a body that meets monthly. A committee can give an opinion; an opinion is not a decision.
• What evidence is required — the list of evidence that must be complete before approval, and the list that must remain true after it. The second list is the one organizations forget most often.
• Who acts when results are contested — the path that can actually be walked on a Friday afternoon, from the person who takes the report, to the person with authority to stop, to the remedy for those already affected.

The two negative sentences that close the definition are the part that bites hardest. "A committee without decision rights is not governance" removes the most common alibi wholesale, because most organizations stand up a committee first, and most committees are constituted to advise — which is useful, and is not the same thing as authority. "A policy without inventory, controls, and monitoring is not governance either" removes the second most common alibi: the beautifully written policy document you agree with line by line, and about which there is no way whatsoever to know whether the organization complies, because there is no register of what systems exist, no control anyone can test, and no watching after release.

Law, ethics and governance are three different layers

Chapter 10 opens with a summary sentence that places the three words in relation to one another without ambiguity: "Law defines obligations, ethics addresses the remaining gap, and governance turns both into decisions, evidence and remedy."^[1] Obligations come from the law; the gap that is left over is the business of ethics; and what governance owes is the conversion of both into three things you can hold in your hand — a decision, a piece of evidence, and a remedy.

I like this three-layer structure because it settles, on the spot, an argument that runs in circles inside organizations. The argument goes: one side says "the law does not forbid this", the other says "but we should not do it", and the two of them are speaking on different layers, so neither can ever be right or wrong. The structure says both are right on their own layer. Law is the bottom layer. Ethics is the layer that asks whether a thing that is legal should nonetheless be done. And governance is the layer that forces the two above it to end in three tangible things: who decides, on what evidence, and how anyone harmed is made whole. If a debate ends without those three, it means we argued on the top two layers and forgot the third.

The chapter carries five operating principles,^[1] and the first of the five is the condition on which the other four depend — "Maintain a live inventory and named owner: governance begins with knowing what exists." I lean on the word live, because a register compiled once at project kickoff and never touched again differs from having no register at all in exactly one respect: it leaves everyone comfortably wrong about already having one.

2. The Obligation Map — Start with Eight Dimensions, per System

If governance begins with knowing what exists, the next step is knowing what obligations came attached to it, and the book names that tool the obligation map in a sentence that wastes nothing.

Begin with an obligation map. For every system, identify jurisdictions, sector rules, organizational role, affected people, data categories, decision impact, supplier chain, and deployment context.^[1]

The most important words in that sentence are "For every system" — per system, not per organization. This is where an obligation map parts company entirely with an organization-level policy. One policy document can cover a whole organization; legal obligations do not work that way. An assistant that drafts internal email and a system that screens job applicants can live in the same organization and even call the same model, yet they sit under completely different jurisdictions, affected groups, data categories and decision impacts. Writing one policy over both therefore always produces one of two results: too loose for the second system, or so heavy for the first that nobody complies.

Each system's obligation map has to name eight dimensions,^[1] and the table below is my own expansion of how each one changes the answer.

The limits of the tool need saying plainly. An obligation map is a scoping instrument for the conversation with people who actually know; it is not a determination. The book says so itself: "Role and system classification require qualified legal analysis."^[1] Filling in all eight cells above does not mean the organization now knows whether it is a provider or a deployer in the legal sense. It means the organization is ready to put that question to counsel without spending the first two hours explaining what the system does.

Law is the floor, not the ceiling

The next sentence in the book is the one I want everybody who is currently waiting for "the AI law" to read before they wait any longer.

Existing privacy, consumer, employment, intellectual-property, cybersecurity, safety, and professional rules continue to apply even where there is no dedicated AI act. Law is the floor. Ethics asks what the organization should do when an action may be legal but conflicts with dignity, fairness, autonomy, cultural context, or purpose.^[1]

The book's Thai companion renders the same passage with the seven bodies of law kept in English — Privacy, Consumer, Employment, IP, Cybersecurity, Safety and Professional — and translates "law is the floor" as the minimum level, with ethics asking whether a legal action should still be taken when it touches dignity, fairness, autonomy, culture or mission.

I meet this misunderstanding so often that I think it is the most expensive misunderstanding in the whole subject. Its shape is: "Thailand has no AI law yet, therefore there is nothing to do here." That fails at the first logical step, because an AI system does not sit in a legal vacuum. It processes personal data, so it sits under data-protection law. It communicates with consumers, so it sits under consumer law. It screens people for employment, so it sits under labour law. It creates and consumes content, so it sits under intellectual-property law. It runs on infrastructure, so it sits under cybersecurity law. And if it operates inside a licensed profession, it sits under that profession's rules too. The absence of a dedicated statute does not make the general law disappear. It only means there is no single convenient document that gathers all of it in one readable place.

The other half of that same sentence is that the word "floor" implies space above it, and the space above is where ethics lives. The question on that layer is not "may we?" but "even if we may, should we?" The book names five criteria for asking it: dignity, fairness, autonomy, cultural context, and the organization's own purpose. Notice that the last one is not abstract at all. An organization that declares a mission on behalf of one group of users, then ships a system that systematically disadvantages that same group, has not necessarily broken any law — but it has broken faith with itself, and one day it will have to explain that to the people who believed the declaration.

In practice the gap between the floor and what ought to be done is closed by three things, following the chapter's third operating principle — "Use law as the floor and ethics for the gap: define prohibited uses, affected groups and remedy."^[1] All three are documents you can genuinely write on one page each: the list of things the organization declares it will not use AI to do, the list of affected groups and what each group is entitled to expect, and the route to remedy when something goes wrong. Organizations that have those three pages in hand before the first release find that the entire ethics debate gets surprisingly short.

3. Five Frameworks, One Evidence System

At this point the real problem starts to surface. An organization that has mapped obligations across every system discovers that it sits under several reference frameworks at once. Risk holds NIST AI RMF. Quality is preparing for ISO/IEC 42001. Strategy cites the OECD AI Principles on a board slide. Teams working with government agencies are asked about ETDA guidance. Legal already holds the PDPA and the sector rules. If each framework produces its own file cabinet, the organization ends with five sets of documents describing the same systems in five vocabularies, updated on five schedules, none of which matches what is actually running.

Chapter 10's proposal is to invert the problem. Instead of asking "what documents does this framework want?", ask "what evidence does this system already have to produce, and which frameworks can that evidence answer?" The answer is Figure 14 — five source boxes flowing down into one.

The dark box underneath is the organization's evidence system, and it holds seven artifacts^[1] — Inventory, Impact, Contract, Manifest, Evaluation, Trace and Incident. Above it are five source boxes^[1] — NIST, ISO/IEC 42001, OECD, ASEAN and ETDA together as one box in the role of regional and national guidance, and finally law by jurisdiction and by sector. The sentence the book prints beneath the figure is "Map obligations to artifacts once, then reuse evidence responsibly" — map once, then reuse with care.

💡 My view: the chapter's second operating principle is the sentence this whole post is arguing — "Map obligations to evidence: reuse artifacts responsibly without claiming frameworks are identical."^[1] Read the second half as attentively as the first. The first half is what makes the work possible; the second half is what keeps the work honest. Using one artifact to answer two frameworks is good practice. Saying that because it does, the two frameworks are therefore the same thing, is a different claim and a dangerous one — it is the sentence that gets read back to you on the day somebody asks why the organization concluded it had nothing left to do.

The remaining four principles read best together. The first is "maintain a live inventory and named owner". The third is "use law as the floor and ethics for the gap". The fourth is "make supplier change and exit governable — vendor dependence is part of the risk perimeter", which is the entire subject of the next post. And the fifth is "measure lifecycle sustainability and rebound — unit efficiency can coexist with rising total impact", which belongs to the next post as well.^[1]

What each framework supplies, and which artifact it consumes

This table is the heart of the post. The middle column uses the book's own wording rather than synonyms of my choosing, because the verb each framework attracts tells you its status — "supplies" is not "specifies", and "emphasize" is neither.

The seven artifacts, read one at a time

These seven are not folder names. Each answers a different question, and these are the questions an auditor, a regulator or the other side's lawyer will genuinely ask.

• Inventory — what systems exist, who owns each, what Risk Tier each sits in, and when the list was last updated.
• Impact — who this system affects and how, what the assessment concluded, and who signed for that conclusion.
• Contract — what an outside provider has promised in writing, from data use, through model changes and breach notification, to the exit from the agreement.
• Manifest — the runtime-context manifest: everything that determines the system's behaviour at the moment it answers, including model version, prompts, data sources and callable tools.
• Evaluation — the evaluation performed before release: on which population, at which thresholds, with which results.
• Trace — a reconstructable trace with enough provenance attached to rebuild a single event after the fact.
• Incident — what happened when something went wrong: who knew when, what they did, how affected people were made whole, and what changed in the system afterwards.

The benefit of looking at it this way shows up the moment a new framework arrives. The question shifts from "does this mean another programme?" to "which of the seven artifacts we already hold does this framework want, and in what respect does it want them differently?" Most of the time the answer is the same artifact in a slightly different shape, which is a week of work rather than a quarter of it.

The caveat that must be spoken louder than the benefit

The book's frameworks paragraph opens with this: "Several frameworks can share evidence without being treated as interchangeable."^[1] That clause is not decoration attached to the method. It is a condition of the method.

The reason lies in the genuinely different legal standing of each framework. NIST states of its own framework that it is "designed for voluntary use".^[2] The ASEAN Guide says it outright: "Nothing in this Guide may be interpreted as replacing or changing any party's legal obligations or rights under any member state's laws".^[6] The ETDA guidance carries the boundary the book states for it — "institutional guidance does not replace applicable law, contracts, or sector-specific control requirements"^[1] — and the two ISO standards cited in this post are cited from their public descriptions only: nothing protected is reproduced here, and no certification is conferred.

4. Thailand — What Already Binds, and What Does Not Yet

The first question I hear in almost every Thai meeting room is "so does Thailand have an AI law yet or not?" I think that is the right question in the wrong order, because its answer — either way — changes nothing about what the organization must do this week. The better order asks first what already binds us today, and only then what is coming. This section follows that order.

The PDPA is the floor that already exists, and it covers AI completely

Checked 5 September 2026: the Personal Data Protection Act B.E. 2562 was published in the Royal Gazette, volume 136, part 69 Kor, on 27 May 2019, and section 2 brings it into force the day after publication except for Chapters 2, 3, 5, 6 and 7 and sections 95 to 96, which take effect one year after publication.^[9] The Act applies in full to personal-data processing carried out by AI; there is no technology exemption in it.

Section 3 of the PDPA explains the phrase "law is the floor" better than any metaphor could, because it says that where another law deals specifically with personal-data protection for a particular business, agency or matter, that law applies — except that the provisions on collection, use and disclosure, the data-subject rights and the related penalties apply under the PDPA in addition.^[9] Sector rules do not displace general rules. They stack on top of them.

The three things below are what I see AI teams get wrong most often, and all three are statutory text you can read for yourself.

First: consent is not the answer to every question. Section 19 makes consent the default position — a data controller may not collect, use or disclose personal data where the data subject has not given consent beforehand or at the time, unless a provision of this Act or another law permits it. The significant set of exceptions lives in section 24, which names six lawful bases besides consent:^[9] public-interest archives or research and statistics with appropriate safeguards; preventing or suppressing danger to a person's life, body or health; necessity for the performance of a contract with the data subject or for pre-contractual steps at their request; necessity for a public-interest mission or the exercise of state authority vested in the controller; the legitimate interests of the controller or another person, unless the data subject's fundamental rights outweigh them; and compliance with a legal obligation of the controller.

The reason this matters for AI systems in particular is that a team in a hurry takes the path that looks easiest — add one more tick box, and call it compliance. The book files this behaviour among its failure patterns as "using consent as the answer to every privacy question".^[1] The trouble with the shortcut is not only that it may select the wrong basis. It is that the organization never gets around to the harder question, which is what this processing is necessary for — because every one of the other six bases has a necessity or a demonstrable interest built into it.

Second: data-subject rights must remain exercisable even when the decision runs through AI. Sections 30 to 34 create five rights for data subjects^[9] — access and a copy, to receive or port data, to object, to request erasure, destruction or anonymisation, and to request restriction of use. Sections 35 and 36 are duties of the controller rather than rights of the data subject, and should not be counted in to make seven.

The connection I want visible is that these five rights translate straight into engineering requirements. If the system cannot say where one person's data has been used, the right of access cannot be honoured. If there is no lineage tracking where data flowed, the right to erasure is a promise that cannot be kept. And if there is no appeal route a real person can walk, the right to object is only a line in a privacy notice. This is why the Trace and Incident artifacts in the set of seven are not purely a technical concern. They are what makes a statutory right real in practice.

Third: controllers and processors carry different duties, and that line is the line your vendor contract runs along. Section 37 sets three duties for the data controller^[9] — to provide appropriate security measures and review them when necessary or when technology changes, meeting the minimum standard the Committee notifies; to prevent unauthorised use or disclosure when personal data is passed to another party; and to provide a system for erasing or destroying data when the retention period lapses, when it is irrelevant or beyond purpose, on request, or on withdrawal of consent. Section 40 sets three duties for the data processor^[9] — to act only on the controller's instructions unless those instructions are unlawful; to provide appropriate security measures and notify the controller of any personal-data breach; and to keep a record of processing activities per the criteria the Committee sets.

The second paragraph of section 40 is the sentence I want procurement and legal to read side by side, because it provides that a processor acting outside the controller's instructions is deemed to be the controller for that processing.^[9] Put another way: the law assigns roles by actual conduct, not by the label in the contract. That is the legal reason the Contract artifact has to state precisely what a provider may do with our data — not because we distrust them, but because the scope of the instruction is what determines who is who in the eyes of the law.

Finally, PDPA duties do not live in the Act alone. Checked 5 September 2026: the subordinate-legislation index of the Office of the Personal Data Protection Committee remains live and still publishes Committee notifications^[10] — for example the criteria for sending or transferring personal data abroad under sections 28 and 29, dated 21 February 2025, and the criteria for imposing administrative fines by the Expert Committee, as amended 8 May 2024. That list is what the page displayed on the date searched, not a complete inventory of all subordinate legislation. The point I want remembered is that PDPA duties are elaborated by living notifications, so reading the Act once three years ago is not enough.

ETDA guidance — not law, but a structure that works

Checked 5 September 2026: ETDA's Generative AI Governance Guideline for Organizations, Vol. 1, was announced on 30 October 2024, builds on the earlier AI Governance Guideline for Executives, and remains a free download on ETDA's site.^[8] The guideline stresses five areas — governance structure, strategy, operations, human oversight and incident reporting.^[1]

I recommend this document to Thai organizations often, for a reason that has nothing to do with law: it is written in language a Thai executive team reads and understands the same way, and its five areas fit what a mid-sized organization can genuinely do. But it must always be read alongside the boundary the book states — "institutional guidance does not replace applicable law, contracts, or sector-specific control requirements".^[1] Following every point of the ETDA guidance does not mean the PDPA is satisfied, and it does not mean the contract clauses with our overseas provider are adequate.

Checked 5 September 2026 as well: ETDA's AI Job Redesign Guideline remains published in ETDA's knowledge library, marked with a 2025 copyright year, and is organizational guidance rather than a legal requirement.^[11] For what this document contains I cite the book's description rather than the page, because the page carries none. The book calls it "a Thai organizational pathway from task analysis through human–AI workflow, levels of authority, competency needs, and job-description redesign" — a route from analysing the work, through the human–AI workflow, the levels of authority and the competencies required, to redesigning the job description — with the boundary that "organizations still need employee consultation, labor-law review, and local measurement of job quality and outcomes".^[1] Consultation with employees, a labour-law review, and local measurement of job quality and outcomes remain the organization's own work regardless.

A dedicated Thai AI law — status on the date checked

I wrote that sentence with a date attached on purpose, and I want to explain why. In this subject, a sentence without a date is a sentence that can become false silently. "Thailand has no AI law" written on a slide last year and still in use on this year's slide may already be untrue with nobody in the organization aware. The only defence is to write the date every time and let the date tell you when to check again. My own rule is simple: every statement of legal status has a shelf life of one quarter, and must be re-checked before any release decision, no matter how recently it was last checked.

The national strategy, the UNESCO assessment, and regional guidance

These three are cited often in executive slide decks, and all three have the same standing: they describe direction or describe a condition. None of them creates an obligation, and none of them removes one.

Checked 5 September 2026: Thailand's National AI Strategy and Action Plan 2022–2027 was approved by the Cabinet on 26 July 2022 and sets five strategic pillars across 15 work plans.^[13] In the source's own wording the five are preparing Thailand's readiness in social, ethics, law and regulation for AI application; developing infrastructure for sustainable AI development; increasing human capability and improving AI education; driving AI technology and innovation development; and promoting the use of AI in the public and private sectors. The boundary the book states for this document is admirably direct: a national strategy expresses direction; it does not create permission for any particular processing activity or deployment.^[1]

Checked 5 September 2026: UNESCO's Thailand Artificial Intelligence Readiness Assessment Report was published on 7 July 2025, assesses five dimensions on the basis of consultations with over 30 institutions, and identifies gaps in policy coherence, institutional coordination and capacity development.^[14] The report is genuinely useful for explaining to an executive team why the state's answers do not yet cover every question, but it has to be read with the boundary the book attaches: an assessment is a time-bound institutional synthesis, not a compliance verdict on individual organizations.^[1] A country's gaps are not your organization's score, and your organization's score does not improve because the country's does.

Checked 5 September 2026: the ASEAN Guide on AI Governance and Ethics (copyright 2024) and the Expanded ASEAN Guide on AI Governance and Ethics — Generative AI (January 2025) both remain published on the ASEAN website. Both are voluntary regional guidance and are not legally binding.^[6][7] The later document states its own relationship plainly: "This document supplements and supports the ASEAN Guide on AI Governance and Ethics (2024)" — it supplements and supports the 2024 edition; it does not replace it.

5. The EU AI Act — Why a Thai Organization Has to Read It

The question that always follows is: we are a Thai organization, so why should we care about European law? The short answer is that this body of law attaches to where the affected people are, not to where the company is. A Thai organization with users in Europe, with corporate customers who resell into Europe, or doing contract development for European clients, is already in this conversation whether it meant to be or not. The longer answer is that even for an organization with no European users at all, the shape of this law has already become the common language in which enterprise customers and auditors worldwide phrase their questions.

Checked 5 September 2026: the EU AI Act entered into force on 1 August 2024 and applies generally from 2 August 2026, with the prohibitions and the AI-literacy duties applying from 2 February 2025 and the governance rules and the obligations for general-purpose AI models from 2 August 2025.^[15][16] The high-risk system deadlines were deferred by Regulation (EU) 2026/1744, adopted 8 July 2026, published in the Official Journal of the European Union on 24 July and in force from 27 July 2026, to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.^[17]

The right-hand column of that table is my observation, not a requirement of the law, and I put it there because it is the point I most want visible in this whole section — what each deadline calls for is one of the artifacts we already discussed in section 3. An organization that already runs the seven-artifact evidence system finds the remaining work is reformatting and filling gaps. An organization that does not, finds it is starting from zero on somebody else's schedule.

One last observation in this section is about reading the news rather than reading the law. The 2026 deferral of the high-risk deadlines was reported in many places under headlines suggesting the rules had been relaxed. I would be careful with that reading, because deferring one category's deadline does not defer another's. The enforcement powers and transparency obligations that began on 2 August 2026 are a date already past, and the prohibitions that began on 2 February 2025 are long past. What the deferral hands over is preparation time for the heaviest category — a gift that is only useful to organizations that have already started preparing.

6. Proportional Control — Lighter, but Never Empty

If reading this far has left you feeling that it is more work than can be done, I think that feeling is correct, and the book answers it in the same paragraph. The way out is not to lower the bar across the board. It is to accept that not every system has to pass through the same gate.

Apply proportional control. Low-impact drafting does not require the same gate as employment, credit, health, education, or safety decisions, but still needs inventory, data rules, supplier control, security, and user guidance. High-impact systems require impact assessment, independent challenge, meaningful human authority, appeal and remedy, and explicit residual-risk acceptance.^[1]

The book's Thai companion renders this passage keeping Control, Gate, Inventory, Supplier Control, Security, Impact Assessment, Independent Challenge, Human Authority, Appeal, Remedy and Residual Risk in English, and translating the rest: an ordinary drafting tool should not have to pass the same gate as an employment, credit, health, education or safety system, but it still has to sit in the inventory with data rules, supplier control, security and user guidance in place.

The words to underline are "but still needs". The low-impact tier needs five things, and the high-impact tier adds five more.^[1] The low tier is lighter; it is never empty. A table whose low-impact column is blank all the way down is a table that has misread the book.

The last two rows are the ones organizations skip most often, and they are the two I think separate organizations doing governance from organizations doing paperwork. Appeal is what gives the phrase "affected people" in the obligation map its meaning, because if the person who was refused has no way of telling anyone the answer was wrong, the organization will never learn that the system is wrong. Explicit residual-risk acceptance is what converts risk from something floating in the air into something with an owner and a date. I have seen beautifully written risk assessments end on the word "acceptable" with no name underneath — which means nobody accepted anything.

The criterion for assigning a tier needs stating just as plainly. What sets the tier is the impact of the decision on people, not the sophistication of the model or the size of the project budget. A system running a very small model that decides who gets an interview sits in a higher tier than a system running the largest model in the organization to summarise internal meeting notes. Swapping those two round is the mistake that has already parked governance resources in the wrong place in a number of organizations, and it happens very easily when the people assigning the tier are the same people who are proud of the system's technical complexity.

7. The Impact and Obligation Mapping Workshop

Everything so far comes down to one meeting, held once per use case, and the book gives the order of that meeting in a single paragraph.

Define the use case, decision, role, and jurisdictions. Map affected groups, rights, benefits, and credible harms. Identify privacy, employment, sector, AI, IP, security, and transparency obligations. Set risk tier, human authority, notice, appeal, and monitoring. Review vendor evidence and exit. Estimate energy and model-sizing options. Decide proceed, modify, pause, or prohibit and name evidence gaps.^[1]

I have broken that paragraph into a table you can genuinely fill in during the meeting, adding only two columns the book does not write: the evidence each step produces, and the owner of that step. A meeting that ends without those two is a meeting that has to be scheduled again.

Step 6 in that table deliberately carries no numbers, because estimating energy and choosing model size belongs to sustainable AI, which has both its own numbers and its own traps waiting in the next post. What this workshop has to do is keep the question on the agenda, not answer it in this room.

The last two steps are the ones I would protect time for hardest, because they are always the ones squeezed into the final five minutes. Step 7 forces a choice of one word among four, and its value lies in having Pause and Prohibit genuinely on the table. An organization whose only options are Proceed and Modify is not deciding; it is negotiating the terms of something already decided. Step 8 asks for the opposite of everyone's instinct in the room: it asks you to write down, in writing, what you still do not know. That feels like an announcement of weakness, and is in fact what gives the approval meaning — an approval that names its gaps is an approval that knows what it is approving, whereas an approval with no gaps at all usually means nobody has looked.

The last caution in this section is not to let the workshop turn into a form that teams fill in and send upward to wait for an approval to come back down. The sequence above works because everyone is in the same room hearing each other's answers — legal hears what the system actually does, the development team hears who the affected people are, and the Decision Right holder hears both sides before signing. Once it becomes a form, what is left is paperwork, which is precisely what the definition in section 1 already told us is not yet governance.

8. Metrics That Matter, and Failure Patterns

The book gives a long list of metrics for this chapter, and the first ten belong to this post.^[1] The final three — smallest-adequate-model routing, energy and estimated emissions per successful outcome, and total footprint after usage growth — belong wholly to the next post. I split them that way on purpose, not by oversight.

The rule that governs every row comes from the book's appendix: every operational metric needs all three of a threshold that decides, a named owner, and the learning action that follows when the value crosses the threshold.^[1] A metric missing any one of the three is a chart on a dashboard, not a metric.

The Scorecard column in the table below says which of the organization's six scorecard columns each metric moves — that pairing is my own editorial judgement; the book prints this as one undivided list.

I would point out that the Economics column never appears in this table, which is no accident: the metrics that move it are the three the book places at the end of the list, and they are in the next post. That this chapter moves Risk primarily, and Quality, People and Learning secondarily, also says something about the nature of governance work itself — it is work whose results show up most clearly in the shape of things that did not happen, which is why it is the first budget line cut, and why these ten metrics need to sit on the same board as the revenue numbers rather than in the appendix of yet another report nobody opens.

Failure patterns

This list has eight items,^[1] and I keep the book's order. The one further item the book names — assuming the vendor carries the risk on our behalf — is the opening of the whole next post, so it is carried there.

• Governance after development — starting the conversation about obligations and evidence when the system is close to release, which is the point where the options are fewest and the cost of change is highest.
• Copied principles without decision rules — seven values on the wall, and not one sentence saying who approves what, at what level of evidence.
• Using consent as the answer to every privacy question — adding a tick box instead of asking what this processing is necessary for, when the statute offers six other bases to weigh.
• Hidden worker monitoring — measuring working behaviour through AI tools while the people being measured do not know what is measured, or where the results end up.
• Nominal human oversight — somebody presses confirm, with no time, no information and no real authority to press reject, which transfers accountability to a person who cannot change the outcome.
• No appeal — with no route for an affected person to say this answer is wrong, the organization has cut off its own cheapest channel for learning.
• One control level for every case — whether so strict that nobody complies, or so loose that it prevents nothing, the result is the same: a control that does not work.
• Describing guidance or certification as proof of legal compliance — the most dangerous of the eight, because it sounds like responsibility, and because it is usually said by people who mean well.

I want to close this section with an observation about the list as a whole. Not one of these eight failure patterns comes from ignorance. Every one of them comes from choosing the cheaper path in the short run under real constraints — too little time, too few people, and pressure to ship on schedule. Which means the fix is not more training. The fix is making the right path also the cheaper path, and that is what a single shared evidence system has been trying to do throughout this entire post.

9. The Road Ahead

If I had to compress the whole chapter into a single changed question, I would choose changing the question on the meeting agenda from "what more do we have to build to satisfy this new framework?" to "which of the seven artifacts we already hold does this new framework want, and in what respect does it want them differently?" The first question produces programmes. The second produces work that can finish.

Three things you can genuinely do next week. One, open a single spreadsheet and write down every AI system actually running in the organization, with a named owner. No tiering, no assessment, just the list — how hard that turns out to be will tell you where the organization stands. Two, pick the single highest-impact system and walk the eight dimensions in section 2 until every cell is filled; the cells you cannot fill are this exercise's most valuable output. Three, run one workshop from section 7 on that system, with legal, the business owner and the holder of the Decision Right in the room together, and force it to end on one of the four words.

What this post has not answered — and what will make the entire obligation map above unusable if it goes unanswered — is that most of the evidence in the seven-artifact system is not produced by the organization at all. It comes from model providers, cloud providers, and the subprocessors one layer beyond them, which means the quality of the whole governance system is set by contract language procurement negotiated eighteen months ago. And every answer an AI gives carries an energy cost that nobody in the organization is yet dividing by the right denominator.