Federated by Design — ใครกำหนดมาตรฐาน สร้าง อนุมัติ และดำเนินงานFederated by Design — Who Sets Standards, Builds, Approves and Operates

🤔 Ask this in tomorrow's meeting — "who decides to change the refund-policy corpus?" If the room goes quiet for more than five minutes, does your organization really have an operating model at all?

The previous post, The AI and Data Factory, ended with a factory that produces six reusable things — data products, context services, model services, evaluation services, a tool registry and observability — and with one observation left hanging: a factory does not run itself. Somebody has to set its standards, somebody has to build, somebody has to approve a release, and somebody has to look after it while it is running. This is the post that says who those people are, and how to write it down so that the answer comes back inside five minutes.

The short answer to the whole article is the federated operating model — the centre owns the foundations and the reusable rails, domain teams own business meaning and outcomes, and an independent risk function challenges high-consequence claims — after which decision rights split into four verbs: set standards, build, approve, operate. There is exactly one pass/fail criterion: if you cannot name the decision maker and the required evidence within five minutes, the model is incomplete.

1. Two Roads That Do Not Last

Chapter 6 of AI Transformation as an Organizational Core opens by closing two doors at once: AI transformation cannot be sustained by a central center of excellence (CoE) that builds everything, nor by unrestricted domain units choosing their own models, data and controls^[1] I think that sentence matters, because a great many of the organizations I sit down with are standing on one of those two poles and believe, in perfectly good faith, that they picked the safe road.

Before going any further, one term, because the whole article turns on it. An operating model, in the definition the book uses, is "the structure of decision rights, roles, management forums, budgets, standards, platforms and accountability that turns strategy into shared practice" — notice that the word technology does not appear in it even once. It is the answer to who decides what, on what evidence, and who carries the consequence when it goes wrong, not the question of which cloud the system runs on. I will use the book's own short form, Operating Model, from here on.

The first road — the CoE that builds everything

This shape always begins with good intentions. The organization sees that AI is new, that the expertise is scarce and that the risk is high, so it gathers everything into a single central team. The team is genuinely good — it holds the best people in the building — and for the first stretch it delivers impressively. The trouble starts when the queue grows long enough that a business unit which filed its request at the start of the year gets its slot at the end of it.

The symptom that follows is not only about speed. It is about meaning. A central team taking briefs from every unit cannot possibly know, as deeply as the people who own the work, which clause of the refund policy applies to which group of customers, whether "regular customer" in the old policy document and "regular customer" as the marketing team uses it today refer to the same people, or which cases must always go to a human no matter how high the confidence score is. That knowledge sits in the heads of the people on the floor, not in the ticket that reaches the central team. The result is that the central team ships something that "works" while nobody in the business unit is willing to own it.

The third symptom is what I call floating accountability. When the system misbehaves, the business unit points at the central team — "your team built it" — and the central team points back — "your unit wrote the requirement". Neither of them is lying; both are right from where they stand. And while both parties are right, the customer keeps getting the wrong answer. This is not a problem of anyone's personality. It is the structural consequence of nobody clearly owning any single property of the system.

The second road — every unit chooses for itself

The opposite pole grows out of a reaction to the first. When the queue is long and the output does not fit, a business unit does the most rational thing available to it in the short run: it finds its own tool, puts a subscription on the department credit card, wires an API straight into a spreadsheet, and solves the immediate problem inside a week. In pure speed terms this is a win, and I have never once blamed a team for doing it, because they are solving a problem the organization created.

The cost of this road arrives later, and it arrives in layers. The first layer is invisible risk: nobody knows which providers the customer data has flowed to, under what contract, where it is retained, or whether it is being used for further training. The second layer is duplicated cost: several units build their own policy-answering system, each with its own corpus, each updated on its own cycle, each giving a different answer to the same question. The third layer is the expensive one. When something actually happens, the organization cannot reconstruct the event — no trace, no prompt version, no record of who changed what and when — and so it cannot even say how many customers were affected.

The observation I want you to take away from those two paragraphs is that these are not two different problems. They are the same problem showing two faces: the organization never decided what should be centralized and what should be distributed, and so it ended up centralizing all of it or distributing all of it — the two options that require the least thought, in equal measure.

The question that opens this article — "who decides to change the refund-policy corpus?" — is my favourite diagnostic for these two poles. In a CoE organization the answer is usually "the central team", which is wrong, because the central team does not own the policy. In a fully distributed organization the answer is usually "depends which unit", which means there is no answer. In an organization that genuinely has an Operating Model, the answer comes back within seconds, with a person's name attached, with the kind of evidence that has to accompany it, and with the name of the person the matter goes to if the first one disagrees.

2. The Federated Model — Who Holds the Foundations, Who Holds the Meaning

The way out the book proposes is not a midpoint between the two poles. It is a sorting of things into separate piles, with a different kind of owner over each pile. The book uses the word federated, which is far more precise than "hybrid", because a federation does not mean a half-and-half blend — it means there are jurisdictions, stated plainly, saying who may decide what inside their own territory.

The figure looks simple enough that many readers pass straight over it, but it says three things. First, the central disc is a platform and shared assurance, not an "AI team" — the difference being that a platform is something other people take and use, while a team is something other people wait for. Second, the satellites are not only business lines: risk and legal and people and change sit in the same plane as the value streams, which is a declaration that neither of them is a checkpoint at the end but a player from the beginning. Third, along the bottom of the figure runs the sentence that compresses the entire chapter into one line: the central team owns reusable rails, and domain teams own decisions, outcomes and adoption.

The centre supplies seven things

The book gives the centre's list in full, seven items, and I want you to read it as a closed list — not a starting point that anyone may add to — because everything added to this pile is one more thing a business unit has to queue for in order to get.

• Policy — the policies that apply across the whole organization, from data use and retention through to what the system is absolutely forbidden to do.
• Identity — identity for users, for agents and for tools, together with authorization that is checked on every single call.
• Model access — contracted, reviewed access to models, instead of each unit signing up for its own.
• Evaluation infrastructure — the infrastructure for evaluation: the reference datasets, the runner, and the store the results land in.
• Reusable controls — controls written once that every product can call, such as the authorization check that runs before any real effect.
• Observability — being able to see what the system is doing right now and what it has done before. I will keep the English term, as the book does.
• Portfolio visibility — the view across the whole portfolio: how many AI products the organization has, at which stage, with which owner, consuming what budget.

Notice that not one of them is "build products for the business units". That is the sharpest line between a CoE and a federated centre. A federated centre produces things other people use; it does not produce other people's work. And if one day you find the queue at the centre lengthening, that is almost always the signal that something in this pile is sliding back towards the old shape.

Domain teams own five things

On the other side of the line, the book names five things that belong to the domain teams and should not be pulled into the centre for any reason: business meaning, workflow design, data quality, adoption and outcomes. All five share one characteristic — none of them has a universally correct answer. What "serious customer harm" means in insurance is not what it means in retail, and there is no central team that can decide it on their behalf without getting it wrong.

Then there is the third leg, which is the one most often missing from the diagrams I see in organizations: an independent risk function, with exactly two jobs — to challenge high-consequence claims, and to approve exceptions. "Independent" here has a structural meaning, not an attitudinal one: these people must not report to the person accountable for delivering the same system, or the challenge quietly turns into an internal negotiation.

Organize around products and decisions, not around projects

The book's next sentence changes how budgets are set more than it changes any org chart: organize teams around products and decisions rather than temporary projects^[1] The concrete difference is that a project has a closing date, while a product closes only when the organization decides to close it. A released AI system still needs somebody to look after a corpus that changes, a model the provider updates, and user behaviour that shifts — none of which appears in any project plan ever written.

Accountability is property specific

Here is the idea I take to be the spine of the whole chapter, and the one most often misread. Accountability does not attach to "the system" as a lump. It attaches to properties, one at a time. The book calls this property specific, and lays out two sides of it that must always travel together.

On the first side, the Platform team can guarantee that every tool call passes an authorization service, but it cannot guarantee whether an answer about the refund policy is substantively correct — substantive correctness is the Domain Owner's obligation. On the second side, which is the half that usually gets dropped in the retelling, the converse holds: a domain expert cannot declare an effect path secure without evidence from Platform and Security^[1]

I press on the second side because if you tell only the first, the idea instantly becomes a device for pushing blame onto the business ("the platform did its part, the rest is yours"), which is a complete misreading of it. The substance of it is that no single party can declare a system ready — a readiness declaration is an assembly of assurances from several owners, each of whom vouches only for the thing they hold evidence about.

The example the book carries through the entire volume is CX-REFUND-01, the assistant that answers questions and proposes refunds at Luma Commerce Thailand (a fictional case from the playbook), which is a good case for this point precisely because it holds both a textual answer and an action that moves real money inside one system. Those two things need different owners, need different kinds of evidence, and fail in different ways.

This angle lines up with what the international principles say too. The OECD AI Principles were adopted as instrument OECD/LEGAL/0449 on 22 May 2019 and amended on 3 May 2024, and the instrument's status as of 5 September 2026 was still In force^[2] Principle 1.5, on Accountability, holds AI actors accountable for the proper functioning of AI systems "based on their roles, the context, and consistent with the state of the art" — that phrase based on their roles is the same thing the book calls property specific, said from the vantage point of international policy. The full set comprises five values-based principles and five policy recommendations, with Accountability the last of the first group^[3]

3. Four Verbs That Pull Decision Rights Apart

Once you know who holds which pile, the next question is the verb — who may do what with the things in that pile. The book proposes a decision-rights model split into four verbs, and I think this is the most immediately usable tool in the chapter, because it converts "who owns AI", which has no answer, into four questions that can each be answered one at a time.

Two observations about that table. First, the words typically central in the first row are carefully chosen by the book. They do not say everything must always be centralized; they say that these five things — Identity, Security, Manifest, Trace, Evaluation Protocol — are the ones which, if each unit is left to define them alone, leave the organization unable to compare or combine evidence across systems at all. Second, the verb approve is always tied to consequence, never to seniority. The person who approves a change to a refund threshold need not be the person who approves a change of model provider, and there is no reason both should have to climb to the same individual.

The executive portfolio council

One layer above the four verbs, the book places an executive portfolio council, with exactly three duties and no more.

1. Allocate capability funding — money goes to reusable capabilities, not to projects one at a time. This is the duty that solves the problem no individual team can solve for itself, because no business unit has any incentive to pay for a rail that other units will also use.
2. Accept residual risk at its proper level — the risk left over once all the controls are in place has to be accepted by somebody, formally, and that somebody has to sit at a level that can actually carry the consequence if it lands.
3. Decide when something stops — this is the duty most often missing. Organizations always have a forum that approves starting a project; they rarely have a forum with the authority to stop one. The result is systems that no longer earn their keep running on indefinitely, because nobody has the right to close them.

The five operating principles

The book closes the structural part of the chapter with five operating principles, which I recommend printing and pinning up in whichever room you use for the working session in section 6. The numbers 1–5 are the book's and should never be reordered.

1. Centralize foundations, not every decision — shared rails should be enterprise capabilities.
2. Keep meaning and outcomes in the domain — definitions, acceptance and benefits stay with the people who own the work.
3. Assign one owner per property — committees advise, but an assurance claim needs a name.
4. Separate creation from challenge for high stakes — use independent scrutiny on consequential claims and exceptions.
5. Federate learning through reusable assets — incidents, controls, schemas and cases must improve the platform without erasing context.

Principle 5 is the one that ties this chapter back to the learning loop running through the whole series. Its closing clause — "without erasing context" — is, I think, the part readers skim past most often. It means that when the lesson from one incident is lifted into a central control, the specific context of the unit that hit the incident must not be lost along with it. Otherwise what you get is a central rule so broad that every unit has to request an exception from it, which takes us straight back to the original bottleneck with nothing but a new name.

4. Eight Owner Roles, and the Rule of One Owner per Property

The book states that every AI product needs named owners in eight roles: product owner, domain owner, technical owner, data-product owner and operations owner, plus named owners for security, privacy and release^[1] Before anyone objects that a small organization does not have the people, note the word role rather than position — one person can hold several roles, but every role must have a name against it, and that name has to be written somewhere other people can look it up without having to ask.

💡 My view: principle 3 of this chapter is the sentence I take into meeting rooms more often than any other — "Assign one owner per property. Committees advise but an assurance claim needs a name." — because it cuts away the most popular executive escape route there is, which is to convene a committee so that "everyone can keep an eye on it", meaning in practice that nobody does. A good committee makes the decisions of the person with the name better. It does not stand in for that name.

The owner roster for CX-REFUND-01

The book fills this roster in against the fictional case already. I have set it out as a table and added a column for evidence, because in practice an owner's name with no evidence attached to it becomes a decorative name inside a quarter.

The role the book names but which is most often overlooked is the Release Owner, because the job is not to approve. It is to verify that all the assurances resolve to one single Manifest. Put another way, this is the person who asks "everything you have all signed — did you sign it on the same version?" Which sounds like clerical work right up until the first time Security tests on one version of the corpus while the system goes live on another.

I have left the Privacy Owner out of the table because the book's fictional case does not name a holder for it, though the book does list it among the roles that must have a name — and in the Thai context this is usually the easiest of the eight to find an owner for, because most organizations already have someone looking after personal-data protection.

What the international standards say

Organizations that have to explain a structure like this to auditors or partners usually ask for a standard to point at. The closest one is ISO/IEC 42001:2023, on AI management systems, published in December 2023, and whose status on the ISO website as of 5 September 2026 was still Published, edition 1^[4] ISO's public description states that the standard specifies requirements for establishing, implementing, maintaining and continually improving an artificial intelligence management system within organizations, and defines an AI management system as a set of interrelated or interacting elements of an organization intended to establish policies and objectives, together with processes to achieve those objectives, in relation to the responsible development, provision or use of AI systems^[4] A second ISO explainer page adds that, as a management system standard, 42001 is built around a Plan-Do-Check-Act cycle^[5]

I raise this not to send anyone off in pursuit of a certificate, but to make a single point: if an international standard views AI governance as a management system that has to be maintained and continually improved, while our organization views it as a policy document that gets approved and then filed, those two views produce very different results inside a year. The eight-role roster above is the most tangible part of the first view.

5. From Project, to Capability, to Operating Model

The question I am asked most often once I have finished explaining all this is "so how do we know where we are today?" My favourite answer does not come from the book directly; it comes from the masterclass episode the book uses as a source and paraphrases in its appendix — EP01 of The Foundation, at 34:04–37:18^[6] — which proposes a ladder of three clearly separated levels.

The stretch of the episode just before that (31:13–34:04) reinforces a point that bears directly on this chapter. Paraphrased: customers and important decisions already cross organizational boundaries even when the org chart was never designed for them to. What is needed, therefore, is a shared data and AI platform, governance, and cross-functional teams that put business, data, technology and operations people in the same room — with the sharpest caution of that stretch being that the goal is not to set up an AI department that receives requirements and returns models, because that is simply building a new silo and calling it AI^[6]

I would read that sentence alongside section 1 of this article, because it explains why a CoE that builds everything is not merely slow but the wrong shape — it converts a cross-functional problem into one department's problem, when the problem was never inside a single department to begin with.

Four groups that must change together

Another point the episode presses, and one that matches what I see in the field, is that a transformation needs four groups of people to change together: leaders, domain experts, the data and AI teams, and the frontline teams — with change management beginning at product design rather than at the training session before go-live. The bluntest observation of that stretch is that the hidden constraint is usually leadership, at the point where short-term per-project return measurement leaves nobody able to invest in shared capability at all^[6]

That observation connects precisely back to the first duty of the portfolio council in section 3 — capability funding needs a forum of its own, because if it is left to compete against projects with their own individual return figures, it loses every time. Not because it is not worth it, but because its worth is distributed across all the other projects, leaving no single sponsor able to claim it.

6. The Decision-Rights Wall — the Decision Rights and Handoffs Session

Everything so far has been structure. This section is the instrument that puts that structure to the test inside two hours. The book calls it the Decision rights and handoffs working session. The method is to lay the system's entire lifecycle out across a wall, then at each stage name five things: who recommends, who decides, who performs, who supplies evidence, and who receives escalation.

This table is an example I have filled in so the pattern is visible; it is not a chart the book prescribes, and nearly every cell in it ought to be argued about in a real organization — that is the point of it. Arguing about who belongs in the Decides cell of the Classification stage is arguing about the right thing. Arguing about who owns "AI" is an argument with no end.

Three stress tests

A completed wall proves nothing until it is tested. The book gives three stress tests, and I suggest running them in this order because they escalate in difficulty.

1. A corpus update — the policy owner rewrites one paragraph of the refund policy. The questions to answer: who approves the new meaning, who publishes the new version, does the evaluation have to be re-run, when will the running system see the new version, and if the answers change for the worse, who notices first?
2. A provider change — the model provider announces that the version you are on is being deprecated within a few months. The questions: who decides which version to move to, which evaluation sets have to be re-run, who assures that the changed behaviour is still inside the approved envelope, and if a temporary exception is needed, who has the authority to approve it?
3. An unauthorized refund attempt — a user tries to make the system issue a refund in a case that is out of scope. The questions: at which layer did the Guard stop it, who saw the event, who decides whether to halt the service or let it run, and what evidence lets you answer that nothing slipped through? In the book, this fictional case's Guard may execute no more than THB 2,000 per refund after confirmation, with everything else routed to a person — and the book states plainly that the values are illustrative, not universal thresholds.

Pass or fail

The book closes the working session with a single criterion. I quote it word for word, because it is sharp enough that it needs no elaboration:

💡 My view: the book writes it as "If the group cannot name the decision maker and required evidence within five minutes, the model is incomplete." — and what I like is that it does not measure whether the answer is right. It measures how fast the answer arrives. Because an operating model that needs two meetings to establish who decides is a model that does not exist on the day something goes wrong. Nobody convenes a meeting at two in the morning.

One caution: five minutes is a criterion for running a working session. It is not a performance metric of any organization and it does not come from measuring any real group of them. It is a device for making a room see its own gaps as fast as possible. Do not turn it into a KPI.

How to actually run it in two hours

If you are going to hold one next week, this is the shape I recommend. The room needs all three sides present — Domain, Platform and Risk — with at least one person from each who can genuinely decide, not a delegate who has to go back and ask. A physical wall or an online board both work, but all eleven stages have to be visible at once in a single field of view, because the thing this session catches best is the handoffs, and handoffs are invisible if you look at one stage at a time.

Spend the first thirty minutes filling in the Decides column across all eleven stages, and nothing else. If that column cannot be filled, the remaining columns have no meaning. Spend the next thirty on Supplies evidence, which is the painful column, because it exposes that the evidence you believed you had is in fact a slide rather than something that can be checked after the fact. Spend the final hour walking the three stress tests, timing five real minutes every single time, and recording which ones you could not answer inside it.

The room should produce three things. One, a list of the cells still empty, each with the name of the person who will go and find the answer. Two, a list of Assurance Properties with more than one owner, which violates principle 3 and has to be cut back to a single name. Three, a list of the evidence that cannot be produced today, which becomes the Platform team's work for the next quarter — and notice that none of the three is a new policy document.

7. Metrics That Matter, and Failure Patterns

An Operating Model with no metrics turns into an opinion inside a quarter, the same way the portfolio in post #5 does. The book gives a list of twelve. I have kept the book's order and added a Scorecard column, as this series does throughout, so you can see which square of the board each metric moves — the mapping to Scorecard columns is mine, the six column names are the book's.

The metric I weight most heavily of the twelve is the third — the share of Assurance Properties with one owner — because it is the only one that measures the operating model itself directly, while the rest measure its effects, and because it can be measured immediately without waiting for data to accumulate. You simply open the list of declared properties and count how many have a single name. The organizations I have persuaded to count it are usually startled by their own answer.

The caution about this table is that it carries no target figure in any cell, deliberately. The appropriate threshold depends on the consequence level of each piece of work and on the organization's own capability; there is no general value. In particular, no number from the fictional CX-REFUND-01 case should ever be dropped into this table as a target or a threshold.

Failure patterns

The book names seven. I keep the book's order.

• The CoE becomes the bottleneck — the centre takes on the building work in place of the business units, until the queue is longer than the business cycle of the units waiting in it.
• Uncontrolled local tools — each unit procures and uses its own, with nobody holding a view of where the data goes or who is using what.
• RACI charts where everyone is consulted and nobody decides — a chart full of Consulted with the Accountable cell blank or filled with the name of a working group. Everyone gets a veto; nobody gets a decision.
• Governance arriving only days before launch — read in English this one sounds like a good thing, but the book's Thai companion spells out that the problem is that it arrives only days before the system ships, far too late to change anything, leaving two options: sign it off, or delay.
• Asking Risk to approve the word "safe" with no evidence — sending an adjective for approval instead of evidence, so that when something does happen later, the signature helps nobody.
• Measuring the Platform without connecting it to value — reporting API call counts and response times with not one line saying whether business outcomes improved, which leaves the centre unable to defend its own budget when the cuts come.
• A human-in-the-loop queue with no budget and no people — declaring that there is human oversight without rostering anyone to actually review. The queue ends up cleared by clicking approve, which is worse than having no queue at all, because it manufactures evidence that a human reviewed it.

The first five are failures of where decision rights were placed, and the wall in section 6 fixes them. The last two are resource failures, which the wall catches but cannot fix — they need budget and people, and that is exactly why the portfolio council has to exist in fact, not only on the org chart.

8. The Road Ahead

If I had to compress the whole chapter into one change of practice, I would pick this one: stop asking "who owns AI" and start asking four separate questions instead — who sets standards, who builds, who approves and who operates. The first question has no right answer; the four that follow can each be answered one at a time, and once you have answered all four you will find you have just written your organization's first operating model without convening a single new working group.

There are three things you can do next week. One, open the list of Assurance Properties for one AI system that is genuinely in service, and count how many carry a single person's name and how many still carry the name of a working group. Two, run the two-hour decision-rights wall from section 6, timing five real minutes on each of the three stress tests. Three, check which of the management forums that exist in your organization today has the authority to stop a system that has already shipped — and if none does, that is the largest gap you have, and closing it costs nothing.

The book opens Part three, Engineering the core, with the sentence that makes the best bridge from this chapter into the next: "When model behavior becomes load bearing the organization needs a precise contract for what the system may do what it can prove and how it fails."^[1] A contract, in other words — not a policy and not an intention — stating what the system is permitted to do, what it is able to prove, and how it behaves when it fails. Put another way: now that we know who approves, the next question is approving what.