They take an unsorted inventory and turn it into a tiered register that records reversibility and holds up under an examiner. Along the way, they flag the automation that’s been quietly relabelled as AI.

Built for technical and non-technical users alike.

Companion essay: /Your AI Portfolio Does Not Have One Speed Limit

Prompt Kit 10

67.7KB ∙ PDF file

Download

Download

TRIZ × AI | Regulated Markets · JL CREPPY

There is a kind of meeting I have learned to recognize by its silence. Someone presents a genuinely useful AI system, a document classifier or a claims-summarizer or a first-draft generator, and asks to ship it. Then the room splits. One half wants it live by Friday because the value is obvious. The other half wants six months of controls because the risk feels unbounded. Both halves are right, which is why the meeting ends where it began: a compromise slow enough to annoy the builders and loose enough to worry the risk officers. Everyone leaves faintly dissatisfied, having successfully defended a trade-off that did not need to exist.

On 13 November 2025, the Monetary Authority of Singapore issued its Consultation Paper on Guidelines on Artificial Intelligence Risk Management, designated P017-2025, and gave the industry until 31 January 2026 to respond. The commentary that followed did what commentary does. It counted up the new obligations and worried about the twelve-month transition clock. Most institutions read the paper as a list of things they would now have to do to every AI system they run.

That reading is what keeps the trade-off alive. And it is a misreading, of one sentence in particular.

The clause everyone quoted and nobody used

The consensus response to any new AI guideline is a defensive crouch: what controls do we add, and to what. The instinct is to take the longest, strictest reading of the requirement and apply it everywhere, because uniform is defensible and defensible is safe.

But the guidelines say something that uniform reading cannot accommodate. The expectations, the paper states, “may be applied in a proportionate manner, commensurate with the size and nature of FIs’ activities, use of AI, and their risk profiles.” That is not a footnote softening the rules. It is the regulator telling you to segment: to govern a marketing-copy generator and a reserving model as if they were different animals, because they are. The document everyone read as “more controls for everything” is, read literally, an instruction to stop treating your AI portfolio as one thing.

The thesis

Speed and quality are not opponents. They are two settings on a dial you have soldered into one position. Let the dial move by segment and the trade-off you have spent years managing turns into a routing problem you can actually solve.

A risk you never tiered is a risk you have already tiered as ordinary.

What’s inside

• Why the speed-versus-quality fight is a symptom of an ungoverned portfolio, not a law of nature

• The TRIZ principle that names the resolution, and why it sits first in the catalogue for a reason

• A three-tier build: the boundary you draw on Day 1, the definitions you set in Week 1, the register you make auditable by Month 1

• A diagnostic that reliably embarrasses the risk committee that runs it

• Where this stops being a financial-services problem and becomes everyone’s

The principle hiding in plain sight

TRIZ, the theory of inventive problem-solving distilled from a few million patents, opens its catalogue of forty principles with the least glamorous one on the list. Principle #1: Segmentation. Divide the object into independent parts. Make it sectional. Increase the degree of its fragmentation.

It is first for a reason. A startling share of “hard” contradictions are not really contradictions. They come from insisting that one object hold two incompatible properties at once. A shipping container has to be strong enough to survive transit and weak enough to open easily. Segmentation resolves it: a strong body, a weak seam. The property you wanted everywhere, you now supply only where it earns its place.

The speed-versus-quality contradiction in AI delivery has exactly this shape. You want speed, because the copy generator should ship this week. You want quality, because the underwriting agent must not ship until it is provably safe. Hold both against a single, undifferentiated “AI governance process” and they are irreconcilable, and you will spend your career splitting the difference. Segment the portfolio by risk class and each property goes where it belongs. The generator moves at the speed of its consequences. The underwriting agent moves at the speed of its scrutiny. Nothing is compromised, because nothing is shared.

In that one proportionality clause, the regulator is not granting you a concession. It is describing the segmentation and daring you to implement it.

Day 1: Draw the boundary before you draw the governance

Item 1: Classify by consequence, not by technology.

The universal pattern. Before you can apply a property selectively, you have to cut the object into parts that can hold different properties. In any AI program, the meaningful cut is not model versus rules, or generative versus predictive. It is the blast radius of a wrong output: who gets harmed, how reversibly, and whether a human sees it before it acts.

The regulated-industries manifestation. MAS frames its expectations around “risk profiles” precisely because a hallucinated meeting summary and a biased credit decision are not the same event in different clothes. In financial services the consequence axis is unusually legible. Customer harm, prudential exposure, conduct breach, regulatory reportability: the tiers almost draw themselves once you agree to draw them. Firms that skip this step apply model-validation rigor to a chatbot that answers “what are your opening hours,” and chatbot-grade oversight to an agent that moves money.

Your translation. Three tiers is usually enough. Tier 1 is outputs that reach a customer or a regulated decision with no human in the loop. Tier 2 is outputs a human reviews before they act. Tier 3 is internal-only outputs with no external consequence. Every system in production gets exactly one tier. The AI risk committee owns the boundary; the builders own placement within it.

What to build by Friday. A one-page classification rubric: three tiers, three or four consequence questions, a decision rule that maps answers to a tier. Not a policy. Something a project lead can apply in ten minutes without calling legal.

Item 2: Separate the reversible decision from the irreversible one.

The universal pattern. Speed is cheap where mistakes are cheap to undo. The single most useful cut inside any tier is reversibility, because it tells you how much pre-deployment certainty you actually need, and how much you can buy back later with monitoring and a rollback.

The regulated-industries manifestation. Regulated firms systematically over-invest in front-loaded assurance and under-invest in the ability to reverse. A model whose decisions can be re-run and remediated within a day carries a very different risk from one whose outputs are posted to customers or booked to a ledger the moment they are produced. MAS puts weight on lifecycle controls, not just pre-deployment gates, and that is the reason why. Sometimes the control that matters is the undo button rather than the sign-off.

Your translation. For each Tier 1 and Tier 2 system, ask one question. If this is wrong tomorrow, how fast and how completely can we reverse it? Systems that reverse fast can move at Tier 3 speed with Tier 1 monitoring. Systems that cannot earn their slowness honestly.

What to build by Friday. A reversibility column in your AI inventory. Two values to start, recoverable or not, with the rollback path named for anything marked “not.”

Week 1: Give each segment its own definition of done

Item 3: Write a per-tier “definition of done,” and let it differ.

The universal pattern. Segmentation only works if the segments are genuinely allowed to behave differently. A cut you refuse to act on is decoration. Each part has to carry its own standard, or you have just drawn lines on something you still govern as one.

The regulated-industries manifestation. This is where most governance frameworks quietly collapse back into uniformity. A firm draws three tiers, then writes one control checklist and applies it to all three “for consistency.” Consistency of process is the enemy here. What you want is consistency of proportionality. When MAS says expectations apply “commensurate with” activity and risk, that is an explicit license for Tier 3 to reach production by a shorter path than Tier 1, and an implicit warning that a firm applying identical rigor everywhere has missed the instruction.

Your translation. Three definitions of done, one per tier, each naming what must be true before deployment. Tier 3 might need a data-handling check and a named owner. Tier 1 needs full validation, bias testing, human-oversight design, and a monitoring plan. The heads of each delivery team own their tier’s definition. The risk function owns the fact that they differ.

What to build by Friday. A single page: three columns, the deployment gates for each tier listed beneath. If Tier 1 and Tier 3 have the same gates, you are not done. You have a uniform process wearing a segmentation costume.

Item 4: Route the control weight to the tier, not the tool.

The universal pattern. The resource you are actually rationing is senior human attention. Segmentation is, in the end, a way to spend scarce attention where consequence concentrates, instead of spreading it thin across everything that happens to contain a model.

The regulated-industries manifestation. AI risk committees are a bottleneck by design. An ungoverned portfolio floods that bottleneck with low-consequence items, the fourth internal summarizer this quarter, while a genuinely consequential agent waits in the same queue. The proportionality clause exists so the committee’s time tracks risk. A firm that reviews all AI at the same depth is not being careful. It is being undifferentiated, which only feels like care.

Your translation. Tier 1 goes to the committee. Tier 2 goes to a delegated reviewer with an escalation trigger. Tier 3 self-certifies against its checklist and gets audited by sample. The committee’s calendar should visibly shift toward the systems that can actually hurt someone.

What to build by Friday. A routing table: tier in the left column, approval authority and review depth in the right. Circulate it to everyone who currently waits in the single queue.

Month 1: Make the segmentation something an examiner can read

Item 5: Turn the boundary into an auditable register.

The universal pattern. A segmentation that lives in someone’s head is a preference. A segmentation written down, with each item’s tier and the reason for it, is a control. The difference is whether a stranger can reconstruct your judgement without you in the room.

The regulated-industries manifestation. Supervisors do not mainly test whether your AI is safe. They test whether you can show that you knew which of your AI needed to be. MAS’s expectations around oversight and lifecycle documentation are, in practice, a demand for exactly this register: a record showing that the firm classified its portfolio, applied proportionate controls, and can explain any given placement. A firm that segmented well but wrote nothing down will fail an examination it should have passed.

Your translation. One register: every AI system in production, its tier, its reversibility, its definition-of-done status, and one line of rationale for the tier. It is owned by the AI risk function and refreshed on a fixed cadence, not when someone remembers.

What to build by Month 1. The register itself, populated for everything currently live, even if the first pass is rough. A rough complete register beats an elegant empty template every time an examiner walks in.

A note on confidence

Let me grade my own claims, because a senior reader deserves to know which parts to lean on. The dates and the text are fact: MAS issued P017-2025 on 13 November 2025, closed consultation on 31 January 2026, proposed a twelve-month transition, and wrote the proportionality language quoted above, all confirmed from the published consultation paper. Reading that clause as a mandate for risk-tiered segmentation is my inference. It is a strong one, consistent with how supervisors have historically read “commensurate with risk,” but the guidelines do not prescribe a tiering scheme, and you should not tell your board that they do. And the specific shape I am proposing, three tiers with a reversibility cut, is a design hypothesis. It has held up across the portfolios I have seen, but it is not law. Lean on the first as fact, take the second as a well-supported reading, and treat the third as a starting point to argue with.

The diagnostic that embarrasses the committee

Here is a test worth running before your next AI risk meeting. Ask for the list of every AI use case in production. Then ask the committee to assign each one a tier using nothing but the consequence questions above. Two things reliably happen. Somewhere between thirty and fifty per cent of the “AI” turns out to be deterministic rule-based automation that got relabelled as AI for budget or board-narrative reasons, and it has been eating model-grade governance it never needed. And one or two systems everyone treated as routine land, under honest classification, in Tier 1, reaching a customer or a booked decision with no human in the loop, and nobody had noticed. The list you thought was uniform never was. It was a segmentation you were already living inside, unwritten and so ungoverned.

This is not a financial-services peculiarity. A hospital running diagnostic support next to appointment-reminder bots, a pharmaceutical firm doing both adverse-event triage and internal literature search, a grid operator with load forecasting alongside a customer chatbot: each makes the same error, governing a portfolio of wildly different consequences as if it carried one risk profile. The pattern holds everywhere. The trade-off is manufactured by the refusal to segment.

What the Prompt Kit does

Knowing that segmentation resolves the contradiction is the easy part. Doing it to a live portfolio is the work: drawing defensible tiers, catching the relabelled automation, writing definitions of done that genuinely differ, and producing a register an examiner would accept. Prompt Kit 10 runs that sequence. Four prompts take you from an unsorted inventory to a tiered, reversibility-annotated, examiner-ready register, generating the classification rubric and the routing table along the way. It is built to run on your actual list, by a technical or non-technical owner, in an afternoon rather than a quarter.

Run this before Friday

Take your AI inventory, the real one and not the board slide, and do two things. Sort every item into Tier 1, 2, or 3 using only the consequence questions. Then, for each, write the one-sentence reason. When you are done, look for the rows where the tier and the current level of governance disagree: Tier 1 systems moving at Tier 3 speed, and Tier 3 systems drowning in Tier 1 process. Those disagreements are exactly where your speed-versus-quality trade-off has been hiding. You will not have added a single control. You will have found that you were applying the ones you already have to the wrong things, which is the more uncomfortable finding, and the more useful one.

If you are working through how to tier a live AI portfolio under MAS AIRG or an equivalent regime, and you want a structured outside read on where your governance weight is misrouted and what an examiner-ready register actually requires, mention it in your reply. I take one such conversation a month.

Replies to this post reach me directly. I read all of them.

Regulated Intelligence | TRIZ × AI | Regulated Markets. Written by JL CREPPY.

The sequence moves from decision register, to fitness thresholds, to data population separation, to a reconstruction test with a defensible tolerance.

Designed for both technical and non-technical users.

Companion essay: /Your Data Is Not Ready, and It Never Will Be

Prompt Kit 09

154KB ∙ PDF file

Download

Download

TRIZ × AI | Regulated Markets · JL CREPPY

On 2 April 2026, the Hong Kong Monetary Authority issued its circular on Granular Data Reporting 3.0, with provisional implementation parameters attached as an annex. It is a multi-year program: three phases running tentatively from 2026 to 2031, the first of which (2026–2028) is concerned with establishing “the foundation and initial scope for granular submissions” by preparing data governance and scalable infrastructure. Banks will progressively stop sending the regulator summary templates and start sending it the underlying rows.

Most of the commentary has treated this as a reporting-infrastructure story. Upgrade the pipes, hire the data engineers, budget for 2031.

Buried in the implementation parameters is something far more interesting, and almost nobody has read it as an AI document. The HKMA specifies that data validation controls “should be anchored on ‘validation points’ defined for different data areas, i.e. key data points that can be systemically reconstructed by the granular data,” with “a predefined tolerance band (e.g., ±0.1%)” where necessary.

Because a regulator has just quietly answered the question your AI program has been arguing about for eighteen months.

It did not ask whether the data is good. It asked whether a named figure can be reconstructed from the granular record, within a *stated* tolerance. Quality is not a virtue, It is a measurement, taken at a specific point, against a specific number.

Meanwhile, three floors up, the AI steering committee is being told the models cannot go live because the data is not ready.

The consensus has the sequence backwards

Ask any institution why its AI deployment is behind and you will get the same answer: our data isn’t ready. Then comes the remediation program. Catalogue everything. Profile everything. Establish lineage across the estate. Stand up a governance council. Two years, a large number, and a roadmap whose final milestone is a state called “data readiness.”

Every one of those activities is defensible. The program is still built on a category error.

The consensus frames this as a trade-off along a single axis — speed against quality, deploy now and accept risk, or clean first and accept delay. Both camps agree on the axis and argue about where to sit on it. But the axis is invented. It exists because we have been treating data quality as an *attribute of a dataset*, like temperature, when it is in fact a *relationship between a dataset and a decision*, like fitness.

The thesis

Data quality is not a property of your data. It is a relationship between your data and one named decision, which means “our data isn’t ready” is never a true statement, only an unfinished one.

Finish the sentence and the contradiction between quality and speed does not get resolved. It was a segmentation error.

This is TRIZ in its most useful mode. When a system is being fought over on an axis where both ends are correct, the axis is usually wrong. Separate the problem along a different dimension, here, by use case rather than by time, and the two sides stop competing for the same resource.

What follows:

- Why enterprise-wide readiness programs are structurally incapable of terminating what they have plan so carefully

- The decision register that must exist before the data catalogue does

- Converting “clean” into a threshold you can actually pass or fail is a better way to approach the situation

- The three data populations most institutions are treating as one, and what it costs them

- A diagnostic to run before Friday that tells you, in one number, whether your data program has a destination

The framework: segment by decision, threshold by tolerance, reconstruct by point

Three tiers. The first is a fortnight of conversation and produces no engineering. The second changes what your pipelines are for. The third is where you stop reporting on quality and start proving it.

A framework that cannot be held in a practitioner’s head between reading it and the next steering committee is a document, not a tool.

Tier One — Foundation: name the decision before you touch the data

1. The decision register precedes the data catalogue

The universal pattern. Any quality standard requires a purpose to be measured against, because “sufficient” is a two-place predicate, sufficient *for what*. Remove the second term and the standard becomes unfalsifiable, and an unfalsifiable standard cannot be met, only funded. This is why enterprise data-readiness programs so rarely end. They are not failing. They are structurally incapable of concluding, because no one has specified the condition under which they would be allowed to stop.

The regulated-industries manifestation. Regulators reached this conclusion first and stated it in the plainest possible terms. The HKMA does not ask banks for good data; it asks for named validation points reconstructible within ±0.1%. MAS, in the *MindForge AI Risk Management Operationalization Handbook* published in March 2026 at the conclusion of Project MindForge phase two, organizes its guidance around AI inventories, materiality assessments and key risk indicators, all of which are use-case-scoped objects. Not one major regulator in this region has asked an institution to certify that its data is, in general, good. They have asked what specific thing it is being used to decide, and how well it needs to perform to be trusted with that.

Your translation. Before any further remediation spend is approved, produce a register of decisions the institution intends to make with AI over the next twelve months, underwriting triage, claims routing, suitability checks, surveillance alerting, whatever they are. One row per decision. Each row names the decision, the owner accountable for its outcome, and the consequence of getting it wrong. This is a business exercise conducted with the data office in the room, not a data exercise with a business stakeholder.

What to build by Friday. The register itself, at roughly twenty rows, deliberately incomplete. The purpose is not coverage. The purpose is to discover, reliably, and how many funded data work streams cannot be mapped to any row on it.

2. Convert “clean” into a threshold with a number in it

The universal pattern. A quality target expressed as an adjective cannot be passed or failed, which means it cannot gate anything. A target expressed as a number against a named field can. The tolerance band is not a compromise on rigor; it is the mechanism that makes rigor operable, because it converts an argument into a test.

The regulated-industries manifestation. The ±0.1% in the HKMA’s parameters is worth dwelling on, because it is doing something subtle. It concedes, in a formal supervisory document, that perfect reconstruction is not the standard. What is required is that the deviation be *bounded, stated in advance, and defensible*. That is a far more sophisticated position than the one most internal data policies take, which is to demand completeness in principle and then quietly tolerate whatever arrives in practice, a posture that produces neither quality nor speed, only ambiguity about which one was sacrificed.

Your translation. For each decision on the register, specify the fields that actually feed it, usually a startlingly small number, frequently under twenty, and for each field, a tolerance: acceptable null rate, acceptable staleness in days, acceptable variance against the system of record. The threshold is set by the decision owner, who bears the consequence, and reviewed by risk. He is the one who know what the decision can survive.

What to build by Friday. A single-page fitness threshold sheet for your highest-materiality use case. Fields down the left, three tolerance columns across, decision owner’s signature at the bottom. If nobody will sign it, you have learned that the decision has no real owner.

Tier Two — Process Maturity: stop treating three populations as one

3. Training data, inference data, and evidence data are different objects

The universal pattern. Systems that conflate distinct populations under one label inherit the strictest requirement of all of them and the clarity of none. Data used to build a model, data the model consumes in production, and data retained to explain the model’s behavior later have genuinely different quality profiles, different retention obligations, and different failure consequences. Governed as one estate, every one of them gets over-controlled in the places that do not matter.

The regulated-industries manifestation. The third population is the one institutions consistently underweight, and it is the one supervision runs on. When an examiner asks why a particular customer received a particular outcome fourteen months ago, the question is not answerable from the training set or the current production feed. It is answerable only from a preserved record of the inputs, model version and decision at that moment. This is where personal-data obligations bite hardest, and where the regional direction of travel is unambiguous: Hong Kong’s Privacy Commissioner for Personal Data launched compliance checks on 60 organizations in January 2026 and published results in May 2026 showing 95% used AI in day-to-day operations, with more than half running three or more AI systems, recommending governance structures, privacy impact assessments, AI audits and incident-response plans. Note the shape of that finding. The problem is that adoption has outrun the ability to reconstruct what was adopted.

Your translation. Tag every data flow feeding an AI use case as training, inference, or evidence. Apply different controls deliberately: training data needs representativeness and provenance; inference data needs freshness and availability; evidence data needs immutability and retrievability under a retention clock. The same physical table often appears in more than one population wearing a different obligation each time, and that is fine — provided somebody has noticed.

What to build by Friday. A one-page flow map for a single use case with the three populations colored differently. The gap that shows up in almost every first attempt is the evidence population, which frequently turns out not to exist at all. Its function assumed to be covered by application logs that were configured for debugging and are rotated out after thirty days.

4. Provenance is a deployment gate, not a remediation task

The universal pattern. Controls applied at the end of a process are cleanup; the same controls applied at the entry point are architecture. The cost differential is not marginal. It compounds with every downstream system that has already consumed the unverified input and made it load-bearing.

The regulated-industries manifestation. Provenance in a regulated deployment answers three questions: where did this data originate, what right do we have to use it for this purpose, and can we demonstrate both without a two-week archaeology exercise. The second question is the one that quietly kills projects late. A dataset lawfully collected for policy administration is not automatically available for model training under the purpose-limitation principles running through PDPA and PDPO alike. Institutions discover this at the point of deployment with unhelpful regularity, having already built the model.

Your translation. Add provenance to the go-live checklist as a gate with the power to stop a release, alongside security review and model validation. Three fields per source: origin system, lawful basis for this specific purpose, and named data owner. If any field is blank, the deployment does not proceed. The discipline is unpopular for roughly one quarter and then becomes invisible.

What to build by Friday. Three lines added to your existing go-live checklist. That is genuinely the whole deliverable, and it is the highest-leverage half-hour.

Tier Three — Scale: make quality reconstructible rather than reportable

5. Replace the quality dashboard with the reconstruction test

The universal pattern. A metric that is reported is a claim. A metric that can be independently rebuilt from primitives is evidence. Mature control environments in every domain move from the first to the second, and the transition is nearly always resisted, because the first is comfortable and the second occasionally embarrasses somebody.

The regulated-industries manifestation. This is precisely the HKMA’s move, and it is why GDR 3.0 deserves attention well beyond the reporting function. A validation point that can be “systemically reconstructed by the granular data” is a quality assertion that survives contact with an examiner, because the examiner can rebuild it. Contrast this with the standard institutional artifact, a red-amber-green data quality dashboard, sixty metrics, most of them green, none of them reconstructible by anyone outside the team that produces them. The pattern generalizes well past financial services: pharmaceutical batch records, grid telemetry, and clinical registries have all run this same migration from asserted quality to reconstructible quality, and all of them found it painful for about a year.

Your translation. Pick three validation points per material use case — figures a senior person would recognize and care about. Define each so it can be rebuilt from raw records. State the tolerance. Then run the rebuild monthly and report the deviation, not the color.

What to build by Friday. One validation point, fully specified: the figure, the reconstruction method, the tolerance, the owner. One is sufficient to expose whether reconstruction is currently possible at all.

A note on confidence

Worth being explicit about what is known here and what is argued.
Confirmed from public documents: the HKMA’s GDR 3.0 circular of 2 April 2026, its phasing, and the validation-point and tolerance-band language in the annexed implementation parameters; the MAS MindForge AI Risk Management Operationalization Handbook of March 2026; the PCPD compliance-check findings published in May 2026.
Strong inference from observed patterns: that enterprise data-readiness programs systematically fail to terminate, and that the evidence population is the most commonly missing of the three. I have seen this often enough across enough institutions to state it with confidence, but it is a pattern claim, not a measured one. Design hypothesis, offered for testing: that the decision register reliably outperforms the data catalogue as a starting artifact. The reasoning is sound and the early evidence is encouraging.

The data ready for a decision is the only data that is ready.

The Prompt Kit

Reading a framework and applying it to your own estate are separated by a surprising amount of work. Mostly the tedious kind, where you must hold a definition steady across twenty use cases without drifting. That is exactly the work a well-built prompt sequence absorbs.

Prompt Kit 09 runs the diagnostic in four sequenced steps: building the decision register from a plain description of your AI portfolio, deriving fitness thresholds per decision, separating the three data populations for a chosen use case, and specifying a reconstruction test with a defensible tolerance. It is designed to be run by the person who owns the decision, not only by the data team, which is rather the point of the whole essay.

Before Friday

Take your highest-materiality AI use case. Write down, without consulting anyone, the single figure that would tell you the model is being fed adequately. Now attempt to reconstruct that figure from raw records, not from the dashboard, from the underlying rows.

Time the attempt. That duration is your actual data quality score, and it is the only one an examiner will ever experience.

Most people find the reconstruction either impossible or possible in a way that required a specific individual’s tacit knowledge, which is the same finding with a different packaging. Either way, the exercise takes an afternoon and tells you more than the last quarterly data council pack did. Whether it is a comfortable afternoon depends largely on how long the dashboard has been green.

If you are standing up AI governance against a regulatory timetable and want a structured outside read on decision registers, fitness thresholds, or reconstruction testing, particularly across multiple jurisdictions where the obligations do not align neatly, mention it in your reply. I take one such conversation per month.

Replies to this post reach me directly. I read all of them.

Regulated Intelligence — TRIZ × AI | Regulated Markets. Written by JL CREPPY.

They run in sequence: inventory schema and scope test, then the entry points through which AI arrives, then a materiality rubric with fixed axes and configurable thresholds, then the gap statement written in the language a supervisor uses.

Designed for both technical and non-technical users.

Companion essay: [Nobody Is Watching You Build Yet ]

Prompt Kit 08

84.2KB ∙ PDF file

Download

Download

TRIZ × AI | Regulated Markets · JL CREPPY

The Singapore MAS AI consultation closed five months ago. The transition clock has not started. That gap is not a delay. It is the only unobserved building time you will ever be given, and most institutions are spending it waiting for a document.

On 10 June 2026, the Monetary Authority of Singapore published a consultation paper on proposed amendments to its Notices on Technology Risk Management. It closes on 31 July 2026, and MAS proposes that the revised Notices “shall take effect 12 months after the date that the finalised Notices are published.” Eight domains, including immutable offline backup and unplanned-outage monitoring — the sort of requirement that reads dull and costs a great deal.

That is the third technology-governance instrument MAS has put into the market in seven months. On 13 November 2025 came the Consultation Paper on Guidelines on Artificial Intelligence Risk Management, closing 31 January 2026, with a proposed twelve-month transition after issue. On 6 March 2026 came the proposed Guidelines on Third-Party Risk Management — which supersede the Outsourcing Guidelines and extend from institutions with outsourcing arrangements to all institutions that rely on third-party services, a scope change that quietly captures almost everyone — closing 20 April 2026, with a proposed transition of six months rather than twelve.

Three consultations. Seven months. One direction.

And in the middle of it, the AI Guidelines sit finished-but-not-final. The consultation closed on 31 January. It is July. The transition clock has not started, which means — and this is the part the industry has been reading exactly backwards; the observation period has not started either.

The consensus is treating the gap as a delay

Ask a Steering Committee what it is doing about the AI Risk Management Guidelines and you will hear a version of the same sentence: we are waiting for the final text. It is said with a certain professional dignity, as though waiting were a form of diligence. The logic is not stupid. Why build against a draft that may move? Twelve months of transition is generous; when the document lands, we will start.

The mistake is subtle, and it is a mistake about what a transition period is.

Every regulatory briefing this year has framed the sequence as: draft, wait, final text, transition, comply. Read it that way and the gap between consultation-close and publication is dead time, a delay imposed on you by someone else’s calendar. But the gap is not dead. It is the last stretch of road in which what you build is not yet evidence. Once the Guidelines are issued, your AI inventory stops being an internal artefact and becomes a supervisory one: dated, versioned, and read backwards by someone with the benefit of hindsight and the full text in front of them.

The thesis

A transition period is not when you build. It is when you are watched building. The only unwatched construction time you will ever get is the gap you are currently spending on waiting, and the parts of the Guidelines you can safely build against today are precisely the parts nobody is arguing about.

That second clause is the practical half, and it deserves stating plainly, because it inverts the instinct: the boring provisions are the safe ones. Consultation feedback moves thresholds, carve-outs, proportionality language and definitions at the edges. It almost never moves the spine. What survives from draft to final is what nobody bothered to contest, and what nobody contests is what everybody already accepts they must do.

What follows:

- Why the seven-month, three-track sequence is one instrument, not three

- The invariants — the provisions that cannot change, and can therefore be built against today

- The contested layer — where the final text will move, and what to build so the move costs a calibration rather than a rebuild

- The convergence — why your AI inventory, your third-party register and your IT asset inventory are one object seen from three angles

- A diagnostic to run before Friday that tells you, with one number, whether you have an AI inventory or a list

The framework: build the invariants, scaffold the contested, converge the registers

TRIZ has a name for the situation where a system is fought over on its most visible axis while the real constraint sits somewhere unglamorous: wrong problem segmentation. The visible axis here is the deadline. The real constraint is the sequence of work, most of which does not depend on the deadline at all.

Three tiers. The first can start this month with no further information from anyone. The second can be scaffolded now and calibrated later. The third is where institutions treating the three tracks as three programmes will discover they have built the same register three times.

Tier One — Foundation: build the invariants

1. The AI inventory — and the deletion that comes first

The universal pattern. You cannot govern a population you have not enumerated. Every governance regime begins with a register, and every register begins with an argument about what counts as a member. The argument about membership is the actual work; the list is the residue.

The regulated-industries manifestation. MAS is unusually precise here. The consultation defines AI across three objects: a model (”method or approach that converts assumptions and input data into outputs such as estimates, decisions or recommendations”), a system (”can comprise one or more models and other machine-based components”), and a use case (”specific real-world context that the model or system is applied to”). Then it draws a boundary most institutions have not yet felt: “Calculators or tools whose outputs are solely based on predefined programming logic or rules would not be regarded as AI.” The requirement is an “accurate and up-to-date inventory of AI use cases, systems or models... maintained across the FI.”

Note what that boundary does. It does not expand your inventory. It shrinks it. Somewhere in your organization is a deterministic rules engine that acquired the word “AI” during a budget cycle and has been carrying it ever since, like a knighthood. It is not in scope. Removing it is not a loophole; it is the first act of governance — and it is free.

Your translation. The inventory is not a spreadsheet exercise for the AI team. It is a definitional exercise run across every business and functional area, resolving three questions per candidate: is it a model, a system, or a use case; is it in scope under the rules-based exclusion; and who owns it. Model risk, technology and the business owner sign each row.

What to build by Friday. A one-page inventory schema — the columns, the in/out test, the named owner per row. Not the populated inventory. The schema. Populating it is a quarter’s work and it cannot begin until people agree what a row is.

2. AI identification — the process, not the artefact

The universal pattern. A register decays the moment it is completed. What a supervisor examines is not whether your list was right on the day it was written, but whether the machinery producing it is capable of staying right. An inventory is an output. Identification is a system.

The regulated-industries manifestation. MAS separates the two deliberately. Alongside the inventory sits the expectation that “systems, policies and procedures should be established to ensure consistent identification of AI usage across all relevant business and functional areas,” with “clear roles and responsibilities for AI identification” assigned. Consistent. Across all areas. Assigned. Three words doing an enormous amount of work — because AI in a regulated institution no longer arrives through the AI team. It arrives inside a procurement bundle, inside a SaaS release note, inside a feature nobody asked for and everybody enabled.

Your translation. Identification must be attached to the places AI enters: procurement, vendor change notification, the software development lifecycle, the annual attestation from each functional head. If it lives only in the AI CoE, you have built a searchlight and pointed it at your own feet.

What to build by Friday. A one-page identification map: the doors through which AI enters your institution, and the named control at each. The doors you cannot name are your finding.

Tier Two — Process maturity: scaffold what will be calibrated

3. Risk materiality — the method is fixed, the thresholds are not

The universal pattern. Proportionate regimes split into a method and a dial. The method; how you asses, is structural, and survives because nobody contests it. The dial; where the threshold sits, what counts as material, who is exempt — is where every industry response spends its ink. Build the method; leave the dial loose.

The regulated-industries manifestation. MAS is explicit about the method and silent about your dial. It expects an assessment methodology considering “the inherent risk materiality of an AI use case, system or model before appropriate risk management controls are applied” and “residual risk materiality after risk management controls are applied,” across risk dimensions “at a minimum, covering impact, complexity and reliance.” Inherent and residual. Impact, complexity, reliance. That structure is not going to change in the final text — it is the least controversial paragraph in the paper. What may change is how hard MAS presses on proportionality. Industry responses broadly accepted the twelve-month transition; what they asked for was checklists, toolkits and templates. That is a request for dials, not for a different method.

Your translation. Build the scoring instrument now with the three MAS dimensions as fixed axes and your thresholds as configurable parameters. When the final text lands, you turn dials. You do not rebuild an instrument.

What to build by Friday. A one-page materiality rubric: three axes, a scoring scale, an inherent column and a residual column, and one worked example on your highest-stakes live use case. If the worked example takes more than an hour, your scale is too clever.

4. Third-party AI — the line you cannot delegate

The universal pattern. Responsibility for a system does not transfer with the invoice. This is the oldest principle in outsourcing supervision and the one most reliably forgotten the moment a technology is new enough to be frightening.

The regulated-industries manifestation. AIRM expects institutions to ensure “onboarding, development and deployment controls for third-party AI are adequate for the risk materiality of the use case, system or model that uses or depends on third-party AI.” Read that beside the TPRM proposal of 6 March 2026, which supersedes the Outsourcing Guidelines and applies not only to institutions with outsourcing arrangements but to all institutions relying on third-party services — on a proposed six-month clock rather than twelve. The AI you did not build and the vendor you did not classify as an outsourcing arrangement are converging on the same register, on the shorter clock.

Your translation. Your third-party AI population is almost certainly larger than your AI inventory and your outsourcing register combined, because it includes AI features shipped into tools you already own. Someone must own the sentence ”we do not delegate governance to the vendor” and be able to show what that sentence costs.

What to build by Friday. A single joined view: for each third-party arrangement, does it contain AI; for each AI use case, is it third-party. The cells where the two answers disagree are the reason those must stop being two registers.

Tier Three — Scale: converge the registers, and buy the capability early

5. One register, three tracks

The universal pattern. When a supervisor upgrades three adjacent regimes inside one cycle, they are not asking for three programs. They are describing a single object — the institution’s technology estate, from three angles.

The regulated-industries manifestation. Set the three consultations side by side. AIRM wants an AI inventory. TPRM wants a register of third-party arrangements. The proposed TRM Notice amendments want a complete IT asset inventory across hardware, software and cloud, with lifecycle tracking. These are not three inventories. They are three projections of one estate. Note too the direction of legal travel: TRM requirements are moving from Guideline (supervisory expectation) into Notice (statutory obligation). The soft instruments harden.

Your translation. Design the AI inventory as a view over the asset and third-party registers, joined on a common identifier — not as a standalone artifact belonging to the AI function. The institution that gets this right answers a supervisor’s cross-cutting question in an afternoon. The ones that do not answer it in a quarter, from three systems, with three reconciliations and one apology.

What to build by Friday. A one-page data model: the three registers, the join key, the owner of the key. A fifteen-minute drawing that saves a nine-month integration.

6. Capability and capacity — the longest lead time in the paper

The universal pattern. Every control in a governance framework can be documented in weeks. The people who can operate it cannot be hired in weeks. Capability is always the critical path, and always the line item the deadline-driven program discovers last.

The regulated-industries manifestation. MAS expects an institution to “determine and ensure the necessary competence and proper conduct of personnel involved in developing an AI use case, system or model,” with regular review that they are “equipped with adequate capabilities and capacity for effective AI risk management.” This is the only expectation in the paper on which no consultation response will win you relief, because there is nothing to argue with. You either have people who can evaluate a model’s fairness, or you have a policy that says you do.

Your translation. Count the people who could independently challenge a model’s evaluation evidence and be believed by your regulator. If the number is under three, that is your program risk, and it will not be solved inside a twelve-month transition window — particularly one shared with two other tracks and a market of institutions hiring the same people at once. The cross-sector reader should sit up here: the same bottleneck governs a pharmaceutical firm’s model validation function under EMA scrutiny, an energy operator’s control-system assurance, and a hospital group’s clinical algorithm review. The regimes differ. The scarcity does not.

What to build by Friday. A named list. Not roles — names. The gap between the roles you have written down and the names you can write next to them is the honest state of your capability.

A note on confidence

Confirmed: the dates, scope and quoted expectations above come from the published MAS consultation papers of 13 November 2025, 6 March 2026 and 10 June 2026, and the law-firm analyses that followed them. The definitional boundaries, the four AIRM domains, the twelve- and six-month proposed transitions, and the eight TRM domains are matters of public record.

Strong inference: that the AIRM final text will retain the inventory, identification and materiality structure essentially intact. I cannot confirm this. MAS has not published a Response to Consultation at the time of writing, and I have no visibility into the feedback beyond the published industry responses. The inference rests on a pattern, not a promise: provisions that attract no contest survive; provisions that attract contest get calibrated. If you believe the spine will move, do not build against it. I would take that bet.

Design hypothesis, offered as such: that institutions treating the three registers as one data model will materially outperform those treating them as three programs. This has not been tested at scale in this cycle. It is what the structure of the three papers implies, and it is what I would build.

The two lists

Here is a diagnostic that costs an hour and reliably ruins an afternoon.

Ask two people — one from technology, one from a business function that has been buying software, to independently write down every AI system in production in your institution. Do not let them confer. Then lay the lists side by side.

The union will be longer than either list. The intersection shorter than both. And the interesting number is neither: it is the count of items appearing on exactly one list. That is not a measure of your inventory. It is a measure of your identification process, and if it is not close to zero, then what you are maintaining is a list, not an inventory. An inventory is a thing two people arrive at independently.

The most common finding is not that items are missing. It is that the two people disagree about whether an item is AI at all — which, given that MAS has published a definition excluding rules-based tools, is a disagreement you can settle this week rather than during an inspection.

The Prompt Kit

Reading a framework is pleasant. Discovering which parts of it your institution has silently skipped is what changes next week’s plan.

Prompt Kit 08 does that work: four sequenced prompts taking you from an unstructured description of your AI estate to an inventory schema with a working scope test, an identification map with named door-controls, a materiality rubric scored on the three MAS dimensions, and a gap statement written in the language a supervisor uses rather than the language a program manager uses. It runs in an afternoon, by someone who is not a model risk specialist, and produces an artefact you would be willing to show.

It is not a compliance product. It is a way of finding out how much of the gap you have already spent.

Before Friday

Run the two-list test. Then do one more piece of arithmetic, and do it honestly.

The AI Risk Management consultation closed on 31 January 2026. Count the working days between that date and today. That is the unobserved build time your institution has been given, days in which nothing you produce is yet evidence, nothing you revise is yet a version history, nothing you get wrong is yet a finding. Now, put next to that number the count of AI-governance artefacts your institution has actually produced in that window.

The first number will be in the hundreds. The second, for most readers, in the single digits. The uncomfortable part is not the ratio. It is that the ratio was a choice, made by nobody in particular, in a series of meetings where the sentence ”we are waiting for the final text” was said aloud and no one asked what, precisely, we were waiting to be told.

You already know what the inventory needs. You have known since November.

If you are inside this window, you want an AI inventory that is really a list, three registers that are really one estate, a materiality method waiting on a threshold, and you want a structured outside read on where your identification process leaks, how your registers should join, and which capability gaps cannot be closed inside a transition period, mention it in your reply.

I take one such conversation per month.

Replies to this post reach me directly. I read all of them.

Regulated Intelligence — TRIZ × AI | Regulated Markets.

Written by JL CREPPY.

They sequence from a use-case explanation matrix, to the instrumentation layer around a chosen model, to a human-in-the-loop that captures the reason, to a decision-reconstruction pack that ends in one number: your time-to-explain. Designed for both technical and non-technical users.

Companion essay: “Stop Asking the Black Box to Explain Itself”

Prompt Kit 07

80.2KB ∙ PDF file

Download

Download

TRIZ × AI | Regulated Markets · JL CREPPY

One requirement did not move. Article 50, the duty to tell a person they are dealing with a machine and to mark synthetic content, still lands on 2 August 2026. Set the two side by side and the Union has said something precise, if by accident: you must disclose that the machine is present, but you have another eighteen months before you must make it interpretable. The easy half kept its date. The hard half slipped. Oops!!

The reaction in most steering committees has been relief — which is the wrong response, and not because the delay is unwelcome. The deadline was never the reason to do the work; the delay has merely exposed how many firms believed it was.

The consensus is reading a reprieve where there is only a runway

The consensus take is that the explainability pressure has eased; the interpretability line on the roadmap slides down a few quarters, and the vendor briefings say “delayed to 2027.” That treats explainability as a compliance artifact — something you produce because a regulator asks, on the regulator’s calendar.

That is the mistake. Explainability is not, at root, a regulatory deliverable; it is an operating necessity you also happen to owe a regulator. You need it the afternoon a model declines a good customer and someone has to say why, and the morning an output drifts and the on-call engineer has to find the cause before the customers do, not the auditors. December 2027 changes none of that. We have spent a decade asking the wrong entity to do the explaining.

The trade-off is a category error

The received wisdom is a trade-off: more performance, less explainability. The powerful models are opaque, the transparent ones weak, and governance is the melancholy art of choosing a point on that line. It is drawn as a straight line because everyone has agreed, without quite noticing, on one hidden premise — that the explanation must come from inside the model.

Drop that premise and the line dissolves. Here is the inversion it hides, and the thesis of this essay: the most explainable AI systems are usually built on the least explainable models. Explainability is not extracted from a model by crippling it; it is engineered into the system around it.

We even named the problem after its own cure. We call an opaque model a “black box” — which is precisely what aviation calls the one device on the aircraft designed to make an unexplainable event explainable. The flight recorder is not the engine made transparent; it sits outside the engine, reconstructing what the engine will never confess. The explanation was never in the component. It was in the system around it.

What follows:

- The TRIZ move that dissolves the performance-versus-explainability trade-off instead of splitting the difference

- The three altitudes of explanation — model, system, institution — and why most programs never leave the ground floor

- What each altitude owes you, quoted from MAS, the HKMA and the EU AI Act

- The two audiences of every explanation — the reason a regulator needs, the diagnosis an engineer needs — and why one mechanism cannot serve both

- A diagnostic to run before Friday on your highest-stakes model, ending in a single uncomfortable number

The framework: explainability is an altitude, not a property

TRIZ — the inventive-problem-solving tradition built from studying how thousands of hard engineering contradictions were resolved — has a name for this move. When two requirements fight inside one system and no compromise satisfies both, you stop hunting for the compromise and *transition to the supersystem*: you let the larger system carry the property the component cannot. An engine cannot both burn hot for power and stay cool for longevity, so the cooling requirement moves outward, into a system wrapped around it. Nobody demands a cooler flame; they build a better surround.

Model performance and explainability are that contradiction exactly. The resolution is not a more interpretable model, bought with accuracy you cannot spare; it is a more intelligent system around the model you already run. Three altitudes, each with two moves — and most programs never leave the first, which is why they feel explainability as a tax on performance rather than a property of design.

Altitude One — The model: decide what the model does not owe you

1. Let the decision set the standard, not the architecture

The universal pattern. How much explanation a decision requires is a function of its stakes, not the model’s internals. A recommendation you can reverse needs almost none; a decision that denies a livelihood needs a great deal. The standard is set by the consequence, and can never be read off the architecture.

The regulated-industries manifestation. This is how MAS found mature banks operating. Its December 2024 information paper on AI Model Risk Management, from a thematic review of selected banks, observed that they applied global and local explainability methods and, in stronger cases, defined *the minimum level of explainability required for different use cases*. The same network can be fine behind a marketing ranker and unacceptable behind a credit refusal — nothing about the weights changed, only the altitude of the decision.

Your translation. You stop asking “is this model explainable?” and start asking “what does this decision require, and can our system produce it?” — set by model risk, the business owner and compliance together, before a model is chosen.

What to build by Friday. A one-page use-case explanation matrix: every live AI decision, its stakes tier, the standard that tier demands. The mismatches are your finding.

2. Separate the two audiences of every explanation

The universal pattern. An explanation for a customer or regulator is a different object from one for an engineer. The first is a reason — why this outcome, in language a person can act on or contest. The second is a diagnosis — which feature moved the output, in numbers a builder can debug. A feature-attribution chart is a fine diagnosis and a useless reason.

The regulated-industries manifestation. The regulators are unambiguous about which they want, and it is never the weights. MAS’s FEAT principles require that data subjects receive, on request, “clear explanations on what data is used to make AIDA-driven decisions about the data subject and how the data affects the decision,” and on “the consequences that AIDA-driven decisions may have on them.” The EU AI Act’s Article 86 grants a person subject to a high-risk decision the right to “clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken.” Both ask for a reason a human can hold.

Your translation. Every high-stakes use case gets two explanation templates — a reason-shaped artifact for the customer and regulator, a diagnosis-shaped one for the engineer. Different mechanisms, different owners.

What to build by Friday. For your highest-stakes model, draft the two side by side. If you cannot fill the reason-shaped one without gesturing at a feature-importance plot, you have found the gap.

### Altitude Two — The system: build the thing that produces the explanation

3. Instrument the model; do not interrogate it

The universal pattern. You cannot make an opaque process honest by staring harder at it. You wrap it in instruments. Post-hoc explanation methods, counterfactual probes, a challenger model in shadow, complete input-output logging — none of these open the box, and none need to. They are sensors bolted to an engine no one can see into, and together they produce the account the engine never could.

The regulated-industries manifestation. The EU AI Act, tellingly, does not demand a high-risk model be inherently interpretable. It demands the *system* ship with the means to explain it: Article 13 requires the instructions for use to state “the technical capabilities and characteristics of the high-risk AI system to provide information that is relevant to explain its output” — the supersystem move, written into statute.

Your translation. Model risk owns an instrumentation specification, not a hope that the vendor’s model is legible: which explanation method attaches to which model, what is logged and for how long, whether a challenger runs alongside to catch the day the box and a transparent approximation disagree.

What to build by Friday. An instrumentation sheet for your highest-materiality model — explanation method, logging retained, any challenger. Blank cells are the build backlog.

4. Make the human-in-the-loop an explanation surface, not a rubber stamp

The universal pattern. Somewhere, a model’s output becomes an accountable human decision. That handover is the richest place in the whole system to capture a reason. A human who approves or overrides, and records why, converts a silent output into an explained decision — but only if the system is built to catch the sentence.

The regulated-industries manifestation. Hong Kong’s regulator has made this structural. The HKMA’s guiding principles on generative AI in customer-facing applications, issued 19 August 2024, require that customers be able to request human intervention and that institutions continuously monitor generative outputs; its Deputy Chief Executive clarified in April 2025 that the human-in-the-loop is a safeguard scaled to the risk of the use case.

Your translation. The human-review step is redesigned to capture the reason at approval or override — a structured field, not a signature — so review produces a logged explanation instead of mere delay. Done well, your reviewers become your largest source of genuine reasons.

What to build by Friday. A revised review protocol for one high-stakes workflow, in which every human decision records a one-line reason in a retrievable field.

Altitude Three — The institution: make the supersystem the unit of accountability

5. Audit the system, not the model

The universal pattern. Return to the aircraft. When a flight ends badly, the board does not interrogate the turbine and wait for a confession; it reads the recorder, the maintenance history and the crew testimony, and assembles an account the engine could never give. An institution that can only explain its AI by pointing at the model has no account at all.

The regulated-industries manifestation. This is exactly the shape of explanation Article 86 requires — “the main elements of the decision taken,” assembled from the record, not extracted from the network. MAS makes the stakes explicit in its AI Model Risk Management paper: explainability is vital for accountability, inside the institution and toward the customer.

Your translation. You can assemble, for any challenged decision, the documents that constitute its explanation — the input record, the model version, the instrumentation output, the reviewer’s reason, the governing policy. Not a diagram of the model. A dossier from the system, owned by governance.

What to build by Friday. A decision-reconstruction pack for one live high-stakes decision: the exact artifacts you would assemble, and where each lives today. The gaps are the parts of your supersystem that do not yet exist.

6. Put the explanation on a clock

The universal pattern. An explanation you cannot produce in time is not an explanation; it is an intention. Resilience engineering measures what matters by recovery time. Explanation is the same: not “could we, eventually, reconstruct why?” but “how many hours until we can?”

The regulated-industries manifestation. Article 86 gives an affected person the *right* to an explanation, and a right with no latency behind it is a right in name only. No regulator has yet named a number — this is the frontier — but the direction is one way.

Your translation. Time-to-explain becomes a tracked metric for your highest-stakes decisions: the measured hours to reconstruct, from the system, why one specific decision was made. Architecture and governance own the number.

What to build by Friday. An explanation runbook for your most consequential AI decision, ending in one number: hours-to-reconstruct. The first time you run it, that number will embarrass someone. That is the point.

None of this is unique to finance. A pharmaceutical company whose model flags an adverse-event signal, a hospital deploying a diagnostic aid — each will one day be asked not “how does your model work?” but “why did it decide *this*, for *this* person, on this day?” That is answered by the supersystem or not at all, under whichever regulator holds jurisdiction. Regulated intelligence is wider than financial services, and the altitude problem is identical across it.

A note on confidence

The reader deserves the line between what is documented and what is argued. Confirmed, and linked below: the Digital Omnibus, approved by the Council on 29 June 2026, postponing the stand-alone Annex III high-risk regime — Article 13 included — to 2 December 2027, while Article 50 transparency holds at 2 August 2026; the verbatim texts of Articles 13 and 86; the MAS FEAT transparency principles; the MAS AI Model Risk Management paper of December 2024; the HKMA’s August 2024 generative-AI principles. One caveat: the Omnibus still awaits publication in the Official Journal, and until it appears the original dates remain, technically, the law plan against the new timeline, document against the old.
Strong inference, from repeated observation rather than measurement: that most firms treat explainability as a model property, and are surprised by how little their instrumentation yields when a real explanation is demanded. I have seen this across jurisdictions; I have not seen it counted, and will not dress a pattern as a statistic. Design hypothesis, for argument: that time-to-explain is the metric this decade converges on, and that three altitudes is the right decomposition — fewer collapses the system into the model, more rebuilds the bureaucracy the supersystem was meant to replace. Disagree with that last one; I would like to be wrong cheaply.

What a heat-map cannot say

A diagnostic that takes an afternoon and tends to end the argument.
Ask your model-risk committee to produce, for one live high-stakes decision, the explanation a customer would actually receive. What comes back, reliably, is a feature-attribution chart — the third variable contributed 0.18, the seventh minus 0.04. A competent diagnosis and a worthless reason; no customer was ever consoled by a ranked list of partial derivatives. That gap is the whole distance between the model and the system you failed to build around it — visible in ten minutes, which is why so few teams look.

What the kit does

Knowing explainability lives in the supersystem is the easy half. Building it — turning “score the decision, instrument the model, reconstruct the account” into artefacts your risk and engineering teams can produce next week — is the work, and it is exactly the structured, repetitive work a well-made prompt does quickly.

This week’s Prompt Kit is four sequenced prompts: the first builds the use-case explanation matrix that sets each decision’s standard, the second designs the instrumentation layer around a chosen model, the third turns the human-in-the-loop into a logged explanation surface, the fourth assembles the decision-reconstruction pack and its time-to-explain number. It is this essay’s framework rendered as something you run against a real model, not admire as a diagram.

Run this in seventy-two hours

Take your highest-stakes AI decision — the one that most affects a real person. Imagine that tomorrow a customer, or a regulator behind them, demands a clear and meaningful explanation of one specific instance of it. Ask four questions. Who produces it — a person, or a vendor you have to email? From what — a dossier the system assembled, or a model no one can read? In what form — a reason the person can act on, or a chart only your engineers understand? And in how many hours? Most readers reach the recognition by the third question: they spent their effort trying to make the model talk, when they should have been building the system that speaks for it. The black box was never going to explain itself. It was never supposed to. That was always the supersystem’s job — and Brussels just gave you until December of next year to build it, which is not the same as permission to wait.

If you are building AI governance for high-stakes decisions — and want a structured outside read on your explanation standards, your instrumentation layer, or your institution’s ability to reconstruct a decision on demand — mention it in your reply.

I take one such conversation per month. Specific beats general: name the decision that would be hardest to explain under pressure, and we will start there.

Replies to this post reach me directly. I read all of them.

Regulated Intelligence — TRIZ × AI | Regulated Markets. Written by JL CREPPY.

They sequence from an audit of your current scorecard, to the model-transparency questions for your RFP, to the contract addendum and flow-down clause, to a concentration map with a time-to-substitute number. Designed for both technical and non-technical users.

Companion essay: “Your Vendor Scorecard Is Grading the Wrong Company”

Prompt Kit 06

80.5KB ∙ PDF file

Download

Download

TRIZ × AI | Regulated Markets · JL CREPPY

On 18 November 2025, the three European Supervisory Authorities did something they had never done before. They published a list of the companies the financial system cannot afford to lose. The press release is dry the ESAs “publish today the list of designated critical ICT third-party providers (CTPPs) under the Digital Operational Resilience Act.” Read past the acronyms and it is remarkable: a banking regulator, an insurance regulator and a markets regulator agreed, jointly, on the firms whose failure would threaten European finance. None of them are banks. They are the cloud, data and infrastructure providers everyone else quietly runs on.

The criteria are worth holding onto, because a vendor scorecard never asks about them. The assessment weighed each provider’s “systemic importance, its role in supporting critical or important functions for financial entities, and the level of substitutability of its services.” Not revenue. Not certifications. Substitutability — how badly you are stuck if it changes or fails.

DORA had applied since January 2025; November is when it bit, the moment third-party concentration stopped being a slide in a risk deck and became a named supervisory object. Earlier this month the Financial Stability Board put the same anxiety into a global frame, consulting on twelve “sound practices” for AI adoption — a report it says draws on “financial institutions and their technology vendors.” The regulators have noticed where the dependency now lives. Most procurement functions have not caught up.

The consensus is sharpening the wrong instrument

Every third-party briefing this quarter is asking the same question: how do we get AI vendors into our vendor risk management process? Tighten the scorecard. Add a row for “AI.” Bolt a model-risk annex onto the supplier questionnaire and move on.

That instinct treats the scorecard as incomplete. It is not incomplete. It is pointed at the wrong entity. A traditional vendor scorecard was built to answer one question
will this supplier still be standing next year, and it answers that question well. Financial health, uptime, certifications, support responsiveness. But AI did not add a row to that question. It moved the risk to two places the scorecard has no column for: the model, which you cannot see into, and your own accountability, which you were never permitted to hand over. You cannot patch a measurement problem by measuring the same thing harder.

Here is the thesis, and it is meant to land somewhere uncomfortable. A vendor scorecard tells you whether the company will survive. Your regulator is measuring whether you will — and those are not the same audit. You can buy the capability. You cannot sell the accountability.

What follows:

- Why AI relocates risk from the supplier to the model — and why “the vendor is certified” stops being an answer

- The two metrics your selection process is missing: opacity and concentration

- The two clauses that do the work a scorecard cannot: on-demand audit, and flow-down to the model behind your model

- The two operating metrics that matter after signature: compensatory testing in your context, and time-to-substitute

- A seventy-two-hour diagnostic on your last three AI purchases that names which company your scorecard was really grading

The framework: score the model, write the access, measure the dependency

Three stages, following the life of a vendor relationship: selection, contract, operation. Each carries two metrics the traditional scorecard omits — and the omission is not carelessness but an artefact of the question the old scorecard was built to answer.

The contradiction underneath rewards naming. You want the vendor’s capability that is why you are buying rather than building, but you cannot accept the vendor’s opacity, because your regulator holds you to account regardless. Outsource the build; insource the verification and the accountability. That separation is the whole design, and every missing metric falls straight out of it.

Stage One — Selection: score the model, not the company

1. Measure opacity, not just assurance

The universal pattern. Procurement rewards what it can inspect — certifications, audited accounts, reference calls. The trouble with AI is that its core risk sits in the part you cannot inspect: the training data, the weights, the behaviour at the edges. A scorecard that only credits the visible is structurally blind to what matters most.

The regulated-industries manifestation. The Singapore MAS information paper on AI Model Risk Management names this directly. Third-party AI, it observes, brings “the lack of transparency” as “a key challenge,” because providers “may be reluctant to disclose proprietary information about their training data or algorithms, hindering banks’ efforts in risk assessment and ongoing monitoring.” The Bank of England and FCA’s 2024 survey of AI in UK financial services found the predictable consequence: 46% of firms reported only “partial understanding” of the AI technologies they use, the gap concentrated in the third-party models they bought rather than built.

Your translation. Opacity becomes a scored dimension in selection, not a footnote discovered later. The RFP asks for training-data provenance, evaluation access, model-card depth and change-notification policy — and a vendor that will not answer scores worse than one that answers badly, because a known weakness is governable and an unknown one is not. Procurement, model risk and architecture own it together, not in sequence.

What to build by Friday. A model-transparency disclosure section appended to your AI RFP template; six to eight questions a vendor answers in writing before the commercial conversation starts.

2. Map the concentration, not just the contract

The universal pattern. Resilience engineering measures shared dependencies, not the quality of individual parts. Ten excellent components that all rest on one power supply is not a robust system; it is one failure wearing ten green lights.

The regulated-industries manifestation. This is the risk DORA’s designation was built to surface, with substitutability as a named criterion. The European Banking Authority’s outsourcing guidelines require firms to weigh “concentration risks at the sector level, e.g. where multiple institutions or payment institutions make use of a single service provider or a small group of service providers.” And it is already measurable: the Bank of England and FCA survey found the top three providers account for **73%, 44% and 33%** of all reported cloud, model and data providers respectively, while a third of AI use cases are now third-party implementations, up from 17% two years earlier.

Your translation. Concentration is mapped across the AI estate, not assessed one contract at a time — because a per-contract review structurally cannot see a cross-portfolio risk. Architecture owns the map; risk reads it. The question it answers: how many of our critical use cases trace back to the same foundation model, cloud region, or data provider.

What to build by Friday. A one-page concentration map. List your live AI use cases; behind each, name the underlying model and cloud region; count the use cases sharing a single model. That number is your finding.

Stage Two — Contract: write the access you cannot see into the agreement

3. The audit-and-notification clause

The universal pattern. When you cannot inspect something continuously, you contract for the right to inspect it on demand, and to be told when it changes. Every discipline that depends on something it cannot watch every second — aviation maintenance, food safety, reinsurance — writes the right to look, and the duty to disclose, into the agreement.

The regulated-industries manifestation. MAS sets this out almost as a checklist. Legal agreements with third-party AI providers, the AI MRM paper advises, should include clauses on “performance guarantees, data protection, the right to audit, and notification when AI is introduced (or not incorporating AI without the bank’s agreement) in existing third-party providers’ solutions.” That last clause is the quietly radical one — the right to be told when a vendor *adds* AI to a product you already bought without it. A traditional scorecard has no mechanism for a supplier silently becoming an AI vendor between renewals.

Your translation. These clauses become a standard addendum, drafted once and attached to every AI procurement, not renegotiated deal by deal — because a right you must argue for each time is a right you will eventually trade away under deadline. Legal, procurement and model risk own the template jointly.

What to build by Friday. A one-page AI contract addendum naming four non-negotiable clauses: right to audit, performance guarantees, data-protection terms, and change-notification — including when AI is newly introduced into an existing service.

4. The flow-down clause: reach the model behind your model

The universal pattern. A guarantee that stops at your direct supplier is not a guarantee; it is a handoff. The risk lives one layer down, in their suppliers, and obligations that do not pass downstream leak out the bottom of the chain.

The regulated-industries manifestation. The EU AI Act writes this into law. Under Article 25, the provider of a high-risk AI system and a third party supplying a component “shall, by written agreement, specify the necessary information, capabilities, technical access and other assistance” needed for compliance. The EBA guidelines make the same demand of sub-outsourcing: a subcontractor must grant “the same contractual rights of access and audit” as the primary provider. Translated: your right to audit is worthless if it stops at the reseller and never reaches the foundation-model provider doing the actual work.

Your translation. The contract requires your vendor to pass audit and notification rights through to the model provider behind them — and you first establish which of your vendors are, in truth, reselling someone else’s model. Legal and architecture own this together, because you cannot write a flow-down clause for a dependency you have not mapped.

What to build by Friday. A flow-down clause for your addendum, plus a short list of which current AI vendors are intermediaries for a larger model provider. The list is usually longer than procurement expects.

Stage Three — Operation: measure the dependency, not just the performance

5. Compensatory testing in your own context

The universal pattern. You test the bridge under your traffic, not the manufacturer’s. A vendor’s benchmark describes the vendor’s conditions; your risk lives in yours — your data, your customers, your edge cases — and the gap between the two is where the unpleasant surprises wait.

The regulated-industries manifestation. MAS calls this compensatory testing: “conducting rigorous testing of third-party AI models using various datasets and scenarios to verify the model’s robustness and stability in the bank’s context, and to detect potential biases.” The phrase “in the bank’s context” carries the whole point. A vendor’s 94% accuracy on their evaluation set tells you almost nothing about behaviour on the population you actually serve.

Your translation. You own an evaluation harness, run it on your data on a cadence — and you treat the vendor’s dashboard as a marketing artefact, not an assurance one. Model risk and engineering own the harness; its output is a drift metric you control, not one the vendor reports to you.

What to build by Friday. A context-specific test set for your highest-materiality third-party model, and one drift metric you own — measured by you, on your data, on a fixed interval.

6. Substitutability: measure time-to-exit

The universal pattern. Resilience is measured by recovery, not by uptime. For any dependency, the metric that matters is not how well it performs on a good day but how quickly you can replace it on a bad one. A supplier you cannot leave is not a supplier; it is a single point of failure with an invoice attached.

The regulated-industries manifestation. This is the criterion the European regulators placed at the centre of the DORA designation — substitutability — and the contingency MAS asks firms to plan for: “developing robust contingency plans to address potential failures, unexpected behaviour of third-party AI, or discontinuing of support by vendors.” The accountability spine sits underneath it, and three regulators say it in nearly identical words. The HKMA: outsourcing transfers “day-to-day managerial responsibility, but not accountability.” The EBA: “the outsourcing of functions cannot result in the delegation of the management body’s responsibilities.” MAS, on outsourcing, expects an arrangement “managed as if the services were still managed by the Bank.” If the model fails and you cannot exit, the regulator does not turn to your vendor. It turns to you.

Your translation. Time-to-substitute becomes a tracked metric for high-materiality use cases — the measured cost, in days, of moving off the current model. Architecture and the product owner own it. A dependency you have never rehearsed leaving is one you do not actually understand.

What to build by Friday. A vendor-exit runbook for your single most critical AI use case, ending in one number: the realistic time-to-substitute. The first time you measure it, it will be longer than anyone guessed.

None of this is unique to finance. A pharmaceutical company validating a vendor’s model for adverse-event triage, an energy operator buying a model for load-balancing, a hospital deploying a supplier’s ambient documentation — each carries an accountability no contract can transfer, under a different regulator using the same logic. Regulated intelligence is wider than financial services, and the scorecard problem is identical across it.

A note on confidence

The reader deserves the line between what is documented and what is argued. Confirmed, and linked below: the DORA designation and its substitutability criterion; the FSB consultation and its dates; the EBA guidelines on non-delegation and sector concentration; the HKMA and MAS accountability language; the MAS AI Model Risk Management paper’s third-party section; the Bank of England and FCA statistics. Strong inference, from repeated observation rather than measurement: that most firms’ AI vendor scorecards are inherited wholesale from SaaS and IT procurement, carrying no column for model opacity, concentration, or time-to-exit. I have seen this across jurisdictions; I have not seen it counted at scale, and will not dress a pattern as a statistic. Design hypothesis, for argument: that time-to-substitute is the highest-leverage metric to add, and that six across three stages is the right granularity — fewer misses the model, more rebuilds the bureaucracy you were escaping. Disagree with that last one.

What the column count tells you

A diagnostic that takes ten minutes and tends to settle the argument. Pull the vendor scorecard your team used on its last three AI purchases and sort its columns into two piles: those describing the vendor — revenue, headcount, certifications, SLA, support tier — and those describing the model — evaluation results on your own data, training-data provenance, audit rights actually exercised, measured time-to-substitute. The first pile is almost always full, the second almost always empty. That lopsidedness is not a gap in diligence. It is a portrait of which company you were really grading — rarely the one whose model is now making decisions about your customers.

What the kit does

Knowing the scorecard is pointed at the wrong entity is the easy part. Rebuilding it — turning “score the model” into six questions your procurement and risk teams can run on Monday — is the work, and it is exactly the structured, repetitive work a well-built prompt does fast. This week’s Prompt Kit is four sequenced prompts: the first audits your existing scorecard for the missing columns, the second builds the model-transparency disclosure for your RFP, the third drafts the contract addendum and flow-down clause, the fourth produces the concentration map and time-to-substitute template. It is this essay’s framework rendered as something you run against your real vendor list, not admire as a diagram.

Run this in seventy-two hours

Take your three most important AI vendors. For each, answer four questions without calling the vendor. Have we tested this model on our own data, or are we trusting their benchmark? Do we hold a written, exercisable right to audit it and to be told when it changes? If they retired it next quarter, how many days to substitute? And how many of our other critical use cases sit on the same underlying model? Most readers reach the recognition by the second vendor: the scorecard answered none of these. It certified the vendor was solvent and SOC 2 compliant — which is to say it graded a company that was never the source of the risk. That accountability, every regulator above agrees, did not move when the contract was signed. It is still sitting on your side of the table.

If you are rebuilding AI vendor governance — and want a structured outside read on your selection metrics, your contract addendum, or the concentration map of your AI estate — mention it in your reply. I take one such conversation per month. Specific beats general: name the vendor or use case that is keeping you up, and we will start there.

What the Prompt kit does

This week’s Prompt kit 6 is Four prompts to rebuild your AI vendor scorecard around the metrics that actually de-risk you.

Replies to this post reach me directly. I read all of them.

Regulated Intelligence — TRIZ × AI | Regulated Markets. Written by JL CREPPY.

They sequence from a four-question materiality classifier, to a sort of your live AI inventory, to an explicit fast-lane skip-list, to a one-page graded gate map. Designed for both technical and non-technical users.

Companion essay: “Your Slowest AI Use Case Is Pricing All the Others”

Prompt Kit 05

83.6KB ∙ PDF file

Download

Download

TRIZ × AI | Regulated Markets · JL CREPPY

The MindForge consortium — two dozen banks, insurers and capital-markets firms convened under the Monetary Authority of Singapore — published its AI Risk Management: Executive Handbook, the operational companion to the MAS Consultation Paper on Guidelines on Artificial Intelligence Risk Management, issued on 13 November 2025 and closed to comment on 31 January 2026. The Handbook sets out seventeen Considerations spanning board accountability, third-party risk, data management, pre-deployment testing and ongoing monitoring. It is the most concrete articulation yet of what a regulator in this region expects an AI program to look like from the inside.

Buried in the consortium’s own description of its purpose is the line that matters more than the seventeen Considerations combined. The Handbook exists, in its authors’ framing, to enable AI use that is “rapid but responsible.” Three words, one conjunction, and the entire tension of the regulated-AI program folded inside it. Everyone underlines “responsible.” Almost nobody asks how the “rapid” survives contact with it.

That is the question this essay is about. Not what controls to add the Handbook lists those well enough. The question is why most firms experience every new control as a tax on speed, and what the firms that don’t have understood that the rest have missed.

The consensus is reading it as an addition problem

Steering committees are already turning the seventeen Considerations into a program backlog, and the backlog is already being described, with a straight face, as the reason the AI roadmap has slipped two quarters. Seventeen Considerations; build seventeen capabilities; check seventeen boxes; deploy.

That reading misses the load-bearing word in the entire document. It is not “governance.” It is “proportionate.” The organising principle of both the Guidelines and the Handbook is that controls scale to risk — that the depth of governance applied to an AI use case is a function of how much damage that use case can do, not a flat tariff levied on all of them equally. The consensus treats the Handbook as a longer checklist. Read correctly, it is the opposite: a licence to do less, deliberately, almost everywhere — so that you can do far more where it counts.

Here is the thesis, and it is meant to sting a little. Speed and regulatory readiness only trade off when you refuse to sort. A portfolio governed by a single gate pays the compliance cost of its most dangerous use case on every use case it ships — and then calls the bill “prudence.”

What follows:

- Why the AI inventory is a speed instrument, not a compliance chore — and why most firms build it last

- The risk-materiality classifier that turns one queue into three, and the four questions that drive it

- How “prior action” — readiness built before deployment, not during it — is the only thing that makes a gate fast

- Why two deployment lanes beat one, and what the fast lane is actually allowed to skip

- A seventy-two-hour diagnostic that will tell you, uncomfortably, which gate your last ten deployments were really waiting behind

The framework: sort, pre-load, release

The framework has three stages, and they are strictly ordered. You cannot pre-load readiness for a use case you have not classified, and you cannot run differentiated lanes if you have not pre-loaded the controls each lane depends on. Sort, then pre-load, then release.

There is a TRIZ move underneath it, and it is worth naming once. A contradiction that looks unwinnable the system must be both fast and rigorous usually dissolves the moment you stop demanding both in general. Separate the requirements by condition. Be rigorous where the stakes are high, fast where they are not, and let a classifier decide which is which. The rest of this is engineering.

Stage One — Sort (before anything ships)

You cannot move fast on anything until you know what is allowed to move fast. Sorting is not the bureaucratic prelude to the work. It is the work that makes everything downstream cheap.

1. The AI inventory as a speed instrument

The universal pattern. Every system that triages a hospital, an airport, a help desk — begins by knowing what is in the queue. You cannot prioritize a queue you cannot see. The inventory is not a record-keeping artefact; it is the precondition for ever treating two items differently.

The regulated-industries manifestation. The Executive Handbook’s sixth Consideration requires firms to ensure AI inventory capabilities that record and maintain core information on AI use cases. In financial services the inventory is invariably built last and resented most a compliance deliverable assembled the week before an examination. That sequencing is exactly inverted. The inventory is the first thing that lets you go fast, because it is the thing that lets you decide what not to govern heavily.

Your translation. The inventory is owned by whoever owns delivery velocity, not by whoever owns the audit response. Its primary consumer is the person deciding which use case ships next quarter, not the examiner arriving next year. If your AI inventory lives in the second line of defense and nowhere else, it has been built for the wrong reader.

What to build by Friday. A single register with one column most inventories lack: a materiality tier. Not a description. A verdict.

2. The risk-materiality classifier

The universal pattern. Triage works because it sorts on consequence, not on category. The emergency room does not prioritize by which limb is involved; it prioritizes by what happens if the patient waits. Good sorting asks one question: how bad is “wrong” here?

The regulated-industries manifestation. The Handbook’s fifth Consideration directs firms to enhance use-case-level risk management through risk-materiality assessments, proportionate controls, and pre- and post-deployment reviews. Public commentary on the MAS Guidelines has converged on four dimensions that drive that assessment: the significance of the impact on customer outcomes, the financial loss if the model fails, the reputational exposure, and the criticality to ongoing operations. A model that drafts internal meeting summaries and a model that shapes a claims decision are not the same animal, and the entire point of proportionality is to stop pretending they are.

Your translation. The classifier is a one-page rubric: four questions, a forced ranking high, medium, low and no ties permitted. The roles affected are the use-case sponsor, who proposes the tier, and a risk owner, who can challenge it. Critically, the classifier runs in hours, not weeks. A sorting function that is itself slow has reintroduced the problem it was built to solve.

What to build by Friday. The four-question rubric, applied retroactively to your ten most recent AI deployments. The distribution will surprise you, and the surprise is the finding.

Stage Two — Pre-load (before the queue forms)

This is TRIZ Inventive Principle #10, Prior Action, applied to governance: perform the required change in advance, so it need not be performed in the rush. A gate is slow when every passage through it is bespoke. A gate is fast when the controls it checks for were built, approved and shelved months earlier, waiting to be picked up.

3. The reusable control library

The universal pattern. No fast-moving operation re-engineers its safety equipment per journey. The fire door, the circuit breaker, the seatbelt — pre-built, pre-certified, installed on demand. Speed at the moment of action comes from rigour completed before it.

The regulated-industries manifestation. Most firms assemble guardrails per use case, which means every high-materiality deployment re-litigates prompt-injection defences, human-override design, logging standards and — for any agentic use case — the zero-trust controls at the agent boundary that a high-materiality classification should make non-negotiable. The Handbook expects use cases to be built with appropriate guardrails. It does not require that they be invented from scratch each time. A control library is how “appropriate” becomes “already on the shelf.”

*Your translation.* The platform or architecture function owns a versioned catalogue of pre-approved controls. The high-materiality lane assembles from the catalogue; it commissions bespoke controls only at the genuine frontier. This is the difference between a readiness function that scales and one that becomes the bottleneck everyone routes around.

What to build by Friday. A list — even a short one of the five controls your high-materiality use cases always need, with an owner for each and an honest note on which are built versus aspirational.

4. The graded pre-deployment gate

The universal pattern. A gate that asks every traveller the same hundred questions is not secure; it is theatre with a queue. Real screening varies its depth by risk, and is trusted precisely because it does.

The regulated-industries manifestation. The Handbook calls for thorough testing and review prior to deployment. “Thorough” is not the same as “uniform.” For a low-materiality use case, thorough may be a one-page attestation against the control library. For a high-materiality use case, thorough is a full adversarial review with documented sign-off. Same principle, calibrated depth. The firms that run one gate at maximum depth are not safer than the firms that grade it; they are merely slower, and they have taught their delivery teams that governance is the enemy of shipping.

Your translation. The gate is a branch, not a wall. The materiality tier set in Stage One selects the review depth. Low clears in days against pre-built controls; high gets the scrutiny it earns. The role that changes most here is the reviewer, who stops being a uniform bottleneck and becomes a risk-weighted allocator of their own scarce attention.

What to build by Friday. A one-page gate map: three tiers down the side, the required evidence for each across the top. One page. If it needs more than one, it is not yet a decision aid.

Stage Three — Release (and keep watching)

5. Differentiated deployment lanes

The universal pattern. Every mature logistics system runs more than one speed of delivery. Express and standard are not a failure to standardize; they are the standard. One lane for everything optimizes for the wrong case.

The regulated-industries manifestation. The Handbook asks firms to consider risk-informed deployment options. Read that phrase slowly: the regulator’s companion document is explicitly endorsing differentiated release. A low-materiality summarization tool and an agentic underwriting assistant should not share a deployment path, an approval chain, or a rollback posture. The firm that forces them to has not reduced risk on the dangerous one; it has only added drag to the harmless one.

Your translation. Two lanes, minimum: a fast lane for low-materiality use cases that clears on attestation against pre-built controls, and a gated lane for high-materiality use cases with full review and named accountability. A third, middle lane is optional and usually emerges on its own. The product owner takes the lane the classifier assigns and cannot self-upgrade to the fast lane without re-classification.

What to build by Friday. A written definition of what the fast lane is allowed to skip. This is the hardest and most clarifying artefact in the entire framework, because it forces you to state, on paper, the risks you have consciously decided are acceptable to move quickly on.

6. Proportionate monitoring

The universal pattern. Attention after launch should follow consequence, the same way attention before launch did. You do not watch the smoke detector in the store cupboard as closely as the one over the stove.

The regulated-industries manifestation. The Handbook requires ongoing monitoring of AI use cases to ensure they remain fit for purpose over time. Proportionality does not stop at deployment. High-materiality use cases earn real-time drift and performance monitoring; low-materiality ones earn periodic review. Monitoring everything equally produces the same failure as gating everything equally scarce attention spread thin enough to miss the case that mattered.

Your translation. Monitoring cadence is set by the materiality tier, recorded against the inventory entry, and owned by the use-case sponsor with second-line oversight on the high tier. The same four-question verdict that set the gate depth now sets the watch interval. One sort, used three times.

What to build by Friday. A monitoring-cadence column added to the inventory quarterly for low, continuous for high — so the watch plan is visible the day the use case ships, not reconstructed after an incident.

None of this is peculiar to finance. A pharmaceutical company validating a generative model for adverse-event triage, an energy operator placing AI in load-balancing, a hospital network deploying ambient clinical documentation, each faces the identical sorting problem under a different regulator, and each pays the same hidden tax if it refuses to sort.

A note on confidence

The seniority of the reader deserves the distinction. What is confirmed: the MAS Consultation Paper’s dates and scope, the existence and structure of the MindForge Executive Handbook and its seventeen Considerations, and the proportionality principle running through both; these are matters of public record, cited above and linked below. What is strong inference from observed pattern, not documented fact: that the default failure mode in regulated AI programs is the single uniform gate, and that it is the largest uncosted drag on delivery velocity in most portfolios. I have seen this repeatedly across jurisdictions; I have not seen it measured at industry scale, and I will not pretend the plural of steering-committee anecdote is data. What is design hypothesis, offered for testing rather than asserted: that two-to-three lanes is the right number, and that a four-dimension classifier is sufficient. Fewer lanes under-sort; more lanes re-introduce the overhead you were trying to escape. That one is worth arguing with.

The diagnostic

It takes an afternoon. Take your last ten AI deployments. For each, write down two dates: when it was ready to ship, and when it actually shipped. Then, for each, name the single governance step that consumed the gap. The pattern is reliable enough that I will predict it before you run it: most of your delay was low-materiality work waiting behind a review designed for a use case far more dangerous than it was. The summarization tool sat in the queue behind the underwriting model’s risk assessment, inherited its scrutiny, and waited. You did not govern the harmless thing. You taxed it at the dangerous thing’s rate.

What the Prompt kit does

Reading about proportionate governance is pleasant. Knowing which of your own use cases are over-governed, and which are dangerously under-governed, is the part that changes what you build next week. That is mechanical work; apply a rubric, sort a list, define a lane and mechanical work is exactly what a well-built prompt does fast and consistently. This week’s Prompt Kit is four sequenced prompts: the first builds your materiality classifier, the second runs your existing inventory through it, the third drafts the fast-lane skip-list, and the fourth produces the one-page gate map. It is the sorting machine in this essay, rendered as something you can run on Monday against your real portfolio rather than admire as a diagram.

Run this in seventy-two hours

Open your AI inventory — or, if you have none, list your AI use cases on one page, which is itself the finding. Tier each one high, medium or low against four questions: customer impact, financial loss on failure, reputational exposure, operational criticality. Now look at how each is governed today. If a use case you tiered “low” went through the same review as one you tiered “high,” you have found a tax you have been paying without booking it. If a use case you tiered “high” took the same fast path as a “low,” you have found something worse than a tax. The uncomfortable recognition most readers reach, somewhere around use case number six, is that their governance has been sorting on visibility who shouted loudest rather than on consequence. That is the gap. It has been hiding inside the word “thorough.”

If you are standing up a proportionate AI governance model — and want a structured outside read on your materiality classifier, your lane definitions, and the specific controls your fast lane is allowed to skip, mention it in your reply.

I take one such conversation per month. Specific beats general: name the use case that is currently stuck, and we will start there.

Replies to this post reach me directly. I read all of them.

Regulated Intelligence — TRIZ × AI | Regulated Markets. Written by JL CREPPY.

Built for both technical and non-technical practitioners. The output is an artefact your AI Centre of Excellence can put in front of a supervisor — not a generic checklist.

Companion essay: Essays/Governing the System When the System Is Not Just AI

Prompt Kit 04

339KB ∙ PDF file

Download

Download

TRIZ × AI | Regulated Markets · JL CREPPY

It is not the agentic accountability problem — Singapore IMDA’s Model AI Governance Framework for Agentic AI v1.5 names that. It is not the chained accountability problem inside agentic systems — my last essay covered that through the lens of TRIZ Local Quality. It is the gap one level up: governance frameworks address single classes — agentic, GenAI, model risk, data governance — but most real-world AI workflows in regulated industries are mixed environments. Agentic systems hand off to deterministic rules engines. GenAI summaries feed human reviewers. Human approvals trigger orchestrated agentic actions. Each link is governed by a different framework. The chain itself, as a unit of governance, is governed by none.

I have not seen this composition problem cleanly named in any framework I have read. That is the gap this essay names.

The Gap Defined

The MAS November 2025 Consultation Paper on AI Risk Management for Financial Institutions addresses AI risk in regulated FIs. IMDA’s Agentic AI Framework v1.5 (May 2026) addresses agentic systems specifically. ISO/IEC 42001 addresses AI management systems. NIST AI RMF addresses AI risk management. Each is rigorous within its scope. Each leaves a structural problem at the boundary.

The problem is not inside any framework. It is in what happens between them.

Consider the actual shape of a credit decision in a modern regulated financial institution. The application arrives in a deterministic rules engine that performs eligibility filters. A GenAI component produces a structured narrative summary of the applicant’s profile. An agentic policy lookup queries the firm’s exception-handling history and recommends a decision tier. A human reviewer reads the GenAI summary and the agent’s recommendation and chooses to override, escalate, or approve. The approved decision flows through a deterministic booking system that updates the loan portfolio.

That is one workflow. Four governance classes. Four different frameworks. One chain.

When the decision is wrong, and they will be wrong — accountability traces back across class boundaries. The rules engine logged its filter outcome cleanly. The GenAI summary’s reasoning is partial and difficult to reconstruct. The agentic recommendation carries the IMDA v1.5 attribution chain within its own boundary, but the boundary itself is the discontinuity. The human reviewer’s override rationale sits in free text. The booking system logged its parameters but not the reasoning that produced them.

Reconstructing the decision requires assembling evidence across four governance regimes, each speaking a different language about risk, control, and accountability. The supervisor asking *who decided* receives four partial answers. None is wrong. None is complete.

TRIZ Frame — Inventive Principle #5: Merging

TRIZ Inventive Principle #5, Merging or Consolidation, instructs the designer to combine in space or time related operations that have been treated as separate. Applied to mixed-environment AI governance, the implication is structural: the governance overlay must be the chain itself, not the components.

Most current AI governance investment runs in the opposite direction. Each class gets its own discipline. Agentic AI gets agentic governance. Model risk gets MRM. Data lineage gets data governance. Rules engines get business-process management. The chain that runs across them gets a project manager.

The structural fix inverts that allocation. Govern the chain explicitly. Treat each class as a node within it. Class-specific governance becomes a property of nodes. Chain governance becomes the binding artefact.

Three Implications for Regulated Financial Services

First: every multi-class chain needs an explicit governance manifest.

A document that names each link’s class — deterministic, GenAI, agentic, human — the framework applicable to that link, the handoff contract between adjacent links, and the chain-level accountability assignment. Most current chain documentation describes the workflow as a process. The governance manifest describes the chain as a regulated artefact, audit-defensible end-to-end. The institutions that name this artefact first will be the ones whose first cross-class supervisory examination resolves cleanly.

Second: handoff contracts are the load-bearing element, and they do not yet exist.

When an agentic system hands off to a deterministic rules engine, what evidence accompanies the handoff? When a human reviewer overrides an agentic recommendation, what reasoning is captured in a form the downstream rules engine can act on? Most current handoffs lose the reasoning at the class boundary. The fix is structural: every cross-class handoff must carry forward four things — the input state, the reasoning trace, a confidence indicator, and the named human accountable for the decision to hand off. Handoff contracts borrow directly from API contract design and inter-team RACI matrices. They are new in AI governance practice. They will not be new in twenty-four months.

Third: incident response must span classes natively.

When a credit decision is challenged, the response cannot triage to the AI team or the rules team, it must trace the chain. This requires a single chain-level incident protocol, not class-level protocols stitched together at the end of the investigation. Most current incident response stitches. The chain breaks at the seams. The fix is operational rather than architectural; a single incident-response runbook keyed to chain identifiers, with class-specific evidence collection as steps within that runbook rather than as separate workflows.

What’s Worth Doing Tomorrow

For any AI program with a multi-class chain in production, three actions are worth taking before the next governance review.

1- Map your chains by class. For your top three AI workflows, draw the chain and label each link with its governance class. Count the cross-class boundaries. That count is the number of handoff contracts you need.

2- Write one handoff contract end-to-end. Pick the highest-stakes cross-class boundary in your portfolio. Specify what evidence crosses, what reasoning is preserved, what accountability is named. This is the artefact regulators will increasingly expect to see when they begin to ask about chains as chains rather than as collections of governed components.

3- Designate a chain owner. Not a process manager. An accountable role whose remit is the chain as a unit — across classes. This role does not exist in most current AI governance organisation charts. It is the role the supervisor will ask for first when the cross-class examination begins.

Closing

The frameworks are not wrong. They are addressing what they were designed to address. The gap is what runs between them — and the supervisor asking who decided will increasingly not accept four partial answers.

The mixed-environment governance gap will be named by a regulator within the next twenty-four months. The frameworks that name it will probably start in agentic-rich jurisdictions — Singapore’s IMDA, the EU’s evolving AI Act guidance, perhaps the UK’s emerging AI assurance ecosystem. The institutions that already have chain-level governance manifests will be ready. The institutions stitching frameworks at the seams will not.

Which chain in your AI portfolio currently has no chain-level accountability assigned — and what is the first cross-class handoff in it that carries no contract?

Acknowledgement: This essay draws on peer conversations in the IT GRC, ISO 42001, and ISMS communities. The structural insight that mixed-environment composition is the gap most current frameworks miss came from those exchanges and is credited generally rather than specifically out of respect for private feedback channels.

This essay accompanies the Mixed-Environment Chain Audit Prompt Kit — An interactive audit you can run against your own AI delivery pipelines, paired with “Governing the System When the System Is Not Just AI” on Regulated Intelligence.


Download it alongside this essay on Regulated Intelligence.

Regulated Intelligence · TRIZ × AI · Regulated Markets

Sequenced from agent chain discovery and mapping, through accountability allocation per IMDA v1.5’s five-role taxonomy (platform / system / prompt / workflow / end-user), to HITL effectiveness audit against the override-rate and response-time guidance, finishing with the vendor governance reframe that absorbs agent provenance into procurement.

Each prompt produces the operational artefact that closes a specific structural gap in agentic AI governance. Anchored on the IMDA Model AI Governance Framework for Agentic AI v1.5, section 2.2.1 (published 20 May 2026).

Designed for both technical and non-technical users.

Companion essay: [LINK to Essays/The Agentic AI Governance Gap Most CoEs Are About to Discover]

Prompt Kit 03

357KB ∙ PDF file

Download

Download

TRIZ × AI | Regulated Markets · JL CREPPY

Single-agent governance is largely a solved problem. The architecture is the same one most regulated financial institutions already operate. A risk-tiered review process. Model documentation aligned to the proportionality clause. Human-in-the-loop checkpoints at high-stakes decisions. Audit trails for individual model outputs. The system works because every AI action is traceable to a single model, and behind that model, a single accountable owner.

The current frontier is not single-agent AI. It is Agentic AI — systems where one agent invokes the tools of another, where orchestrators coordinate sub-agents, where third-party agents are introduced through emerging protocols like Model Context Protocol. IMDA’s v1.5 framework names this evolution directly: “Compared to generative AI, AI agents can take actions, adapt to new information, and interact with other agents and systems to complete tasks on behalf of humans.”

The governance question that follows is not technical. It is structural:

when an action takes place at the end of a chain involving multiple agents, multiple platforms, and multiple human actors at different points in the value chain, who is accountable?

IMDA’s framework calls this the accountability diffusion problem. Most Centres of Excellence have not yet noticed they have it.

TRIZ Frame — Inventive Principle #3: Local Quality

TRIZ Inventive Principle #3 — Local Quality, instructs the designer to make each part of an object operate under conditions optimal for its specific function, rather than under uniform conditions. Applied to agentic AI governance, the implication is direct: accountability is not uniform across an agent chain.

In a chained workflow, five distinct accountabilities operate at five different links:

The platform provider

the LLM vendor, the orchestration framework, the agent-as-a-service vendor — is accountable for model behaviour, alignment evaluation, and documentation of known failure modes. This is the layer where MAS FEAT principles and IMDA Trusted AI guidance land most directly.

The system integrator

the team building the chained workflow itself — is accountable for what tools each agent can invoke, how context is managed between agents, what permissions cascade through the chain, and what change-management process governs upgrades to any link in the chain.

The prompt designer

is accountable for how each agent’s instructions translate to actions, including reactions to adversarial or malformed inputs. This is increasingly a security discipline, not a content discipline.

The workflow owner

the business function deploying the agent system — is accountable for whether the chain’s outputs are appropriate for the business decision they influence. This is the layer the IMDA framework most clearly addresses in section 2.2.

The end-user

is accountable for how they invoke and validate the agent’s work. Here automation bias becomes the dominant risk. The IMDA framework names this explicitly: “human-in-the-loop has to be adapted to address automation bias, which has become a bigger concern with increasingly capable agents.”

Each role carries a different local quality requirement. Each accountability gap creates a different failure mode. Uniform agentic governance that treats the chain as a single accountable system is structurally incoherent.

This is what IMDA’s framework, particularly section 2.2.1 of v1.5, asks organisations to map explicitly. Most CoE governance documents do not currently support this mapping.

Three Implications for Regulated Financial Services

First: The MAS proportionality logic must extend into the agent chain — proportionality applies to each step, not to the workflow as a whole. A multi-agent workflow that includes both a low-risk summarisation step and a high-risk decision step cannot inherit a single tier classification. The chain has a *risk profile*, not a tier. The MAS November 2025 *Consultation Paper on AI Risk Management for Financial Institutions* anchors proportionality firmly to single-model deployments. Applied naively to agentic AI, the proportionality clause produces incoherent classifications: either over-restricting the low-risk summarisation step (because the whole chain inherits the high-risk decisioning tier) or under-scrutinising the high-risk decisioning step (because the chain entry-point looks like a copilot use case). The fix is structural: tier the chain step-by-step, not the workflow as a whole. The institutional discipline required to do this is harder than it sounds. Most existing AI inventories cannot even *represent* a multi-agent chain in a single record.

Second: Vendor governance must absorb agent provenance, not just model provenance. A traditional AI vendor governance review asks: which model is being used, what is its training-data lineage, what audit reports are available, what is the change-management process. An agentic workflow vendor governance review must additionally ask: which agents are in the chain, which tools can each agent invoke, what is the least-privilege baseline for each agent, who provides each agent (vendor, platform, in-house), and what is the change-management process when any agent in the chain is updated independently. The IMDA v1.5 framework adds explicit guidance on the distinction between platform providers and system providers in the agentic value chain — and that distinction is the load-bearing one for vendor governance. Procurement functions that have not yet absorbed this distinction are signing contracts they cannot accurately assess. The first sign of this gap: a vendor risk assessment that names a foundation-model provider but does not name the orchestration layer, the agent registry, or the tool-permissioning infrastructure as separate vendor entities.

Third: Human-in-the-loop must be redesigned around automation bias, not around oversight theatre. The IMDA framework names this directly. Most existing HITL designs in regulated AI assume the human reviewer will catch errors when prompted to review an output. Empirically, this fails — particularly when reviewers face high volume, time pressure, or repeated near-identical outputs. The framework recommends monitoring *override rates and response times* as the indicator that HITL is functioning. A CoE that cannot produce these metrics for its current HITL checkpoints does not have functioning oversight — regardless of what the documentation says. The discipline is operational, not architectural: instrument the override rate, alert when it drops below a threshold, treat low override rate as the failure signal rather than the success signal. Most internal dashboards for AI governance currently report the inverse.

What’s Worth Doing Tomorrow

For any CoE leader reading this with an agentic AI initiative either in production or in the pipeline, three actions are worth taking before the next governance review:

Map the agent chain. For each workflow involving more than one agent, draw the chain on a single page. Mark which platform provides each agent, which tools each agent can invoke, what data each agent can access, and who the business owner is at each link. If the chain cannot fit on a single page, that is the first finding — the chain is more complex than the governance documentation acknowledges.

Identify the diffusion points. For each link in the chain, ask: if this step caused material harm, who is the specific named human accountable? The answer should not be “the project sponsor.” That is decorative governance. The answer should be a specific role with a specific decision authority who can demonstrate, in writing, what they signed off on. Where the answer is unclear or shared across multiple roles, that is a diffusion point — and it requires explicit re-allocation, not implicit assumption.

Test the human-in-the-loop. For any HITL checkpoint in your agentic workflows, pull the override rate and response time data for the last 90 days. If you cannot pull it, the HITL is decorative. If you can pull it and the override rate is zero, the HITL is decorative. If the response time is consistently below the time required to actually review the artefact, the HITL is decorative. The fix is not adding more reviewers. It is redesigning the checkpoint so the reviewer’s role is one they can actually perform.

A Living Document Asks for Living Work

The IMDA v1.5 framework names itself as a living document. The expectation is that it will evolve as the technology evolves. The work the framework asks of organisations is also living. The CoE that builds an agent governance architecture aligned to v1.5 *now* is the CoE that does not need to redesign it when v1.6 lands. The CoE that waits for v2.0 is the CoE that will discover the gap during a regulatory examination, not before it.

The accountability diffusion problem is not solved by writing a longer governance document. It is solved by mapping the chain, naming the responsible humans at each link, and instrumenting the oversight that has to remain functional as the chain extends.

Which step in your most consequential agentic workflow currently has no named accountable owner?

This essay accompanies the Agent Chain Accountability Prompt Kit— four prompts to run the accountability-diffusion audit against your own chained agentic AI workflows.

Download it alongside this essay on Regulated Intelligence.

Regulated Intelligence · TRIZ × AI · Regulated Markets

*Source: IMDA Model AI Governance Framework for Agentic AI v1.5, published 20 May 2026, available at imda.gov.sg

The proximate cause, according to Gartner, is uniform governance, the same controls applied to every AI agent regardless of autonomy level. Over-restrict the simple ones, you get shadow development. Under-restrict the autonomous ones, you get incidents that reach the board before the risk committee hears about them.

Two months earlier, Singapore MAS concluded phase two of Project MindForge and published an AI Risk Management Toolkit with a consortium of twenty-four banks, insurers, and capital market firms. The Toolkit’s centrepiece is an Operationalisation Handbook, practical guidance for implementing the AI risk management framework MAS proposed in its November 2025 consultation paper. The implicit message: MAS does not believe the industry can operationalise AI governance from first principles alone. It commissioned the handbook because the gap between governance-on-paper and governance-in-practice was wide enough to require a structured bridge.

These two events, read together, say the same thing from different angles.
The governance most organisations have built for AI is not wrong in intent.

It is wrong in structure.

The differentiation

The consensus response to AI governance gaps is predictable: more policy, more review gates, more framework documents. Every consultancy in the region is selling “AI governance maturity assessments” that produce colour-coded matrices and recommend additional layers of oversight.

This essay argues the opposite. The problem is not insufficient governance. The problem is that most AI Centres of Excellence have optimised for the appearance of governance — artefacts that satisfy audit questions — rather than for the operational capacity to make and track consequential decisions about AI in production.

The distinction matters because governance artefacts and governance capacity produce entirely different organisational behaviours. One produces documents. The other produces decisions.

Thesis

The most dangerous AI governance is the kind that looks good in a board deck but cannot answer three questions: what is in production, what risk does each carry, and who decided.

What is inside

- Why the “centre of excellence” model defaults to governance theatre — the structural incentives that make artefact-production easier than decision-making

- A three-tier operating model — what to fix on Day 1 (mandate and taxonomy), Week 1 (operating rhythm), and Month 1 (capability transfer) — with specific artefacts for each

- The proportional governance principle — why uniform controls fail and what risk-proportionate review actually looks like in a regulated environment

- A diagnostic you can run on Monday — four questions that reveal whether your AI CoE is governing or performing

The framework: Day 1 / Week 1 / Month 1

Day 1 — Mandate clarity and risk taxonomy

The single highest-leverage fix for a struggling AI CoE is not a new framework. It is a clear, written mandate that answers four questions: what decisions does the CoE make (not “advise on” — *make*), what decisions require escalation, who is accountable for each decision class, and what happens when someone bypasses the process?

Most CoE charters answer none of these. They describe the CoE’s purpose in aspirational terms — “accelerate AI adoption,” “ensure responsible AI,” “drive innovation” — without specifying decision rights. A charter that says “ensure responsible AI” is a mission statement. A charter that says “the CoE approves or rejects all AI deployments that interact with customer data, with escalation to the CRO for any model that influences pricing or underwriting decisions” is a governance mandate. The difference is the difference between decoration and authority.

The universal pattern. Decision rights are the irreducible foundation of governance. Without explicit decision rights, a governance function defaults to advisory — and advisory functions get bypassed the moment they slow delivery.

The regulated-industries manifestation. In financial services and insurance, the MAS AI Risk Management Guidelines (proposed November 2025) expect boards and senior management to establish “frameworks, structures, policies and processes for AI risk management.” The critical word is *structures* — MAS is not asking for documents alone. It is asking for organisational design that assigns accountability. The MindForge Toolkit reinforces this: its Operationalisation Handbook walks through governance structures precisely because policy documents alone were insufficient across the twenty-four-firm consortium.

Your translation. Pull your CoE charter. If it does not specify which decisions the CoE owns, which it escalates, and what the consequence of bypass is, it is not a governance document. It is a brochure. The people who need to care about this are the CoE lead, the CTO, and the CRO. If any of them cannot recite the decision rights from memory, the mandate is not operational.

What to build. A one-page decision-rights matrix: rows are decision types (new deployment, model update, data source change, vendor integration, exception request), columns are CoE authority level (approve, escalate, advise, inform). Circulate it to every AI project lead. If someone is surprised by what is on it, the mandate was not previously clear.

The second Day 1 action is a risk taxonomy that is actually used. Not a risk register — a taxonomy. The distinction: a risk register is a compliance artefact that catalogues individual risks. A taxonomy is a classification system that determines how every AI initiative is governed from its first week.

The universal pattern. Proportional governance requires a classification scheme. Without it, every initiative receives the same scrutiny — which means either too much friction for low-risk tools or too little scrutiny for high-risk deployments. This is precisely the failure mode Gartner identified: “Enterprises are treating AI agent governance as binary — either locked down or fully trusted.”

The regulated-industries manifestation. Singapore MAS’s proposed guidelines distinguish between AI used in customer-facing or regulated activities and AI used in internal operations. The former is subject to “more exacting standards around explainability, fairness, human oversight and testing.” This is not a suggestion to treat all AI the same. It is an explicit instruction to differentiate. Yet a surprising number of AI CoEs in the region apply a single review process to everything from an internal document-summarisation tool to a customer-facing underwriting model.

Your translation. If your review process for a Slack bot takes the same calendar time as your review for a credit-decisioning model, your taxonomy is not functioning. The roles affected: AI project leads (who will finally understand why some projects move faster), the risk function (who gains a defensible basis for proportional review), and the CoE itself (which stops drowning in low-risk approvals).

What to build. A three-tier classification:
Tier 1 (internal, no customer data, no regulated decision — fast-track review, CoE informed),
Tier 2 (customer-adjacent or uses sensitive data — standard review, CoE approves), Tier 3 (customer-facing, regulated decision, or autonomous action — full review, CRO escalation). Map every current AI initiative to a tier. The mapping exercise alone will reveal initiatives that have never been classified.

Week 1 — Operating rhythm and proportional review

Governance without cadence is governance without memory. A CoE that meets quarterly to review AI initiatives is not governing — it is auditing, badly, with a three-month lag.

The universal pattern. The operating rhythm of a governance function determines its relevance. Too infrequent, and decisions are made without it. Too frequent with too broad a scope, and it becomes a bottleneck that teams route around. The design challenge is matching cadence to decision velocity.

The regulated-industries manifestation. AI deployment cycles in regulated financial services are accelerating — particularly with agentic AI, where a new agent can move from prototype to production in weeks, not quarters. A quarterly governance cadence designed for traditional model risk management cannot keep pace. The MindForge consortium’s experience underscores this: the Toolkit exists partly because the gap between deployment speed and governance speed had become a structural problem across multiple institutions.

Your translation. Redesign the CoE operating rhythm around three cadences: weekly triage (fifteen minutes — new requests classified by tier, blockers surfaced), monthly deep review (Tier 2 and 3 initiatives reviewed against risk taxonomy, decisions recorded), and quarterly portfolio review (full AI portfolio mapped against strategic objectives, retirement candidates identified). The weekly triage is the critical addition. Without it, the CoE learns about new AI initiatives only when they are already in production or already in trouble.

What to build. A single-page operating rhythm document specifying: who attends each cadence, what is reviewed, what decisions are made (not discussed — made), and where decisions are recorded. Publish it. If the rhythm document does not exist, neither does the rhythm.

The second Week 1 action: implement proportional review that the organisation actually respects. This means review depth scaled to risk tier, with explicit cycle-time targets for each tier.

The universal pattern. Proportional review fails when it exists in policy but not in practice. The most common failure: Tier 1 reviews that take three weeks because the process was designed for Tier 3. Teams learn that the CoE adds three weeks to everything, and they stop submitting. Shadow AI accelerates. The CoE’s portfolio view becomes incomplete. Governance degrades precisely because the governance process was too heavy.

The regulated-industries manifestation. MAS’s expectation of board and senior management oversight does not mean every AI deployment requires board attention. It means the governance structure must ensure appropriate oversight reaches the appropriate level. A well-functioning proportional review gives the board confidence that Tier 3 initiatives are rigorously governed, while Tier 1 initiatives move at a pace that discourages bypass.

Your translation. Set explicit cycle-time commitments: Tier 1 classification confirmed within 48 hours, Tier 2 review completed within two weeks, Tier 3 review completed within four weeks with CRO sign-off. Publish these targets. Measure against them. If the CoE consistently misses Tier 1 targets, the process is too heavy. If it consistently clears Tier 3 in under a week, the review is too shallow. Both are governance failures, just in different directions.

What to build. A proportional review protocol with documented cycle-time targets, escalation triggers, and a bypass-reporting mechanism. The bypass report is not punitive — it is diagnostic. If teams are bypassing, the process has a design flaw. Fix the process, not the teams.

Month 1 — Capability transfer and federated enablement

A CoE that hoards governance capability is a bottleneck by design. The Month 1 objective is building the organisational muscle for governance to operate at the edge — in the business units, in the project teams — without the CoE being in the room.

The universal pattern. Centralised governance scales linearly with headcount. Federated governance scales with organisational capability. The transition from centralised to federated is the maturity move that separates CoEs that accelerate from CoEs that obstruct. But federation without standards is fragmentation. The CoE’s role shifts from gatekeeper to standard-setter and auditor.

The regulated-industries manifestation. In multi-jurisdictional regulated environments — Singapore, Hong Kong, Bermuda, Dubai — the federated model is not optional. Each jurisdiction has distinct regulatory expectations. A Singapore-centric CoE that attempts to centrally govern AI deployments in Hong Kong under MAS-only standards will either slow Hong Kong delivery to a crawl or, more likely, be ignored entirely. The MindForge Toolkit, notably, was built by a multi-institution consortium — an implicit acknowledgment that governance standards must be developed collaboratively across organisational boundaries, not imposed from a single centre.

Your translation. Identify two to three business units with active AI delivery. Embed a governance liaison from the CoE (or train an existing team member) who can perform Tier 1 classifications and initial Tier 2 assessments locally. The CoE retains Tier 3 authority and audit rights. This is not delegation of responsibility — it is distribution of capability with retained accountability. The CTO and business unit heads need to agree on this model explicitly, because it changes who does the work without changing who carries the risk.

**What to build.** A capability-transfer package: the risk taxonomy (from Day 1), the proportional review protocol (from Week 1), a classification decision tree (if X, then Tier Y), and a quarterly self-assessment template that each federated unit completes for CoE review. The self-assessment is not optional — it is the mechanism that prevents federation from becoming fragmentation.

This framework also applies beyond financial services. Any organisation in a regulated industry — pharmaceutical, energy, telecommunications, defence, healthcare — deploying AI at scale faces the same structural tension between centralised governance and operational speed. The proportions change; the architecture does not.

A note on confidence

The structural argument — that governance artefacts and governance capacity are different things — is confirmed by the pattern across every AI CoE engagement this author has observed and by the MindForge consortium’s decision to build an operationalisation handbook rather than another policy template. The three-tier classification scheme is a strong inference from regulatory expectations (MAS, HKMA) and Gartner’s proportional governance recommendation, but the specific tier boundaries will vary by organisation. The cycle-time targets (48 hours, two weeks, four weeks) are design hypotheses calibrated to regulated FS delivery cadences — they should be tested and adjusted, not adopted as gospel. The capability-transfer model is well-established in mature organisations but remains aspirational for most AI CoEs currently operating in the APAC region.

The diagnostic worth running

Here is a pattern worth examining. Ask your AI CoE lead to produce, within one hour, a complete list of every AI initiative currently in production across the organisation. Not in development. In production. Classify each by risk tier. Name the individual who approved each deployment.

The result is reliably instructive. Thirty to fifty per cent of AI initiatives in production have never been formally classified. Approval records, where they exist, point to email threads rather than decision logs. And the list itself is almost always incomplete — because initiatives that bypassed the CoE are, by definition, not in the CoE’s portfolio view.

This is not an indictment of the people running the CoE. It is an indictment of the structure they were given to work with. A CoE without decision rights, without a risk taxonomy, and without an operating rhythm that matches deployment velocity will produce exactly this result — regardless of the talent operating it.

The tool that makes this operational

Reading about governance architecture is useful. Knowing which parts of your current structure are missing is what changes what you build next week. The Prompt Kit does that work — four sequenced prompts that walk from mandate audit through risk taxonomy design, operating rhythm specification, to capability-transfer planning. Each prompt is designed to surface the specific gap in your current governance structure and produce the artefact that closes it.

The first prompt audits your existing CoE charter against the decision-rights framework described above. The fourth produces the capability-transfer package for your first federated unit. Run them in sequence. The output is not a report — it is the governance infrastructure itself.

The close

Here is a diagnostic to run before your next steering committee. Pull up your AI CoE’s last board-ready governance report. Count the number of pages dedicated to frameworks, policies, and maturity models. Now count the number of pages that answer these three questions: what AI is in production today, what risk tier is each initiative classified under, and who specifically approved each one.

If the ratio is more than three to one in favour of frameworks over decisions, your CoE is governing the idea of AI. Not the reality of it.

The good news: the fix is structural, not cultural. Decision rights, risk taxonomy, proportional review, operating rhythm, capability transfer. Five components. Each one buildable. Each one measurable. The hard part is admitting that the current structure, however professionally it presents — is not yet doing the work it was designed to do.

That admission, in the author’s experience, is the actual Day 1.

This essay accompanies the AI CoE Governance Architecture Prompt Kit— four prompts to run the diagnostic against your own AI delivery program.
Download it alongside this essay on Regulated Intelligence.

If you are leading an AI Centre of Excellence in a regulated environment and recognise the pattern described here — governance artefacts that satisfy audits but do not drive decisions — a structured outside read on mandate design, risk taxonomy calibration, and operating rhythm can compress months of iteration into weeks. I take one such conversation per month. Mention it in your reply.

Replies to this post reach me directly. I read all of them.

Regulated Intelligence — TRIZ x AI | Regulated Markets. Written by JL CREPPY.

Four prompts to run the diagnostic from “Your AI Centre of Excellence Is a Governance Mirage” against your own AI delivery program.

Sequenced from mandate audit through risk taxonomy design, operating rhythm specification, to capability-transfer planning — each prompt produces the governance artefact that closes a specific structural gap.

Designed for both technical and non-technical users.

Companion essay: Your AI Centre of Excellence Is a Governance Mirage

Prompt Kit 02

294KB ∙ PDF file

Download

Download

TRIZ x AI | Regulated Markets · JL CREPPY

Every AI team in regulated financial services lives inside the same room: deliver fast enough to justify the investment, deliver carefully enough to survive the audit. Most organisations respond by applying uniform governance to everything — the same review cycle for a meeting summariser as for a pricing model. The result is predictable. Everything moves at the speed of the highest-risk use case. The organisation concludes that “AI is slow to deploy.” Leadership funds more reviewers. Delivery slows further. The story closes with a budget cut and a quiet conclusion that the technology was not yet mature.

The technology was not the problem. The segmentation was.

The TRIZ Frame: Principle #1 — Segmentation

TRIZ — the Theory of Inventive Problem Solving — gives this contradiction a precise name. Speed and quality of an AI deployment look like opposing parameters of one system. They are not. They are properties of three different systems being mistakenly treated as one.

Inventive Principle #1 — Segmentation — instructs you to divide an object into independent parts so that each part can be optimised for its own dominant property. Applied to AI delivery in regulated environments, the insight is structural. An AI delivery pipeline is at least three systems stacked together:

The Experimentation Layer.

Hypotheses are tested, prompts are iterated, models are evaluated against synthetic or anonymised data. Risk is near zero — no customer data, no production integration, no regulatory exposure. Governance should be lightweight: version control, experiment logging, peer review. Anything heavier here is theatre.

The Integration Layer.

A validated model connects to production data sources, APIs, downstream systems. Risk increases — data lineage matters, access controls matter, error handling matters. Governance is engineering governance: code review, integration testing, security validation.

The Deployment Layer.

Model output reaches customers, influences decisions, or generates regulatory artefacts. Risk is maximal. Governance is regulatory governance: model cards, bias testing, explainability documentation, human-in-the-loop validation, audit trails.

The contradiction dissolves when you stop treating these as one pipeline. Speed belongs to the experimentation layer. Quality belongs to the deployment layer. The integration layer is the bridge, and its governance is proportionate to its function — not inherited from the layer below it, not anticipated from the layer above it.

Three Implications for Regulated Financial Services

First: Tiered governance is not regulatory arbitrage — it’s regulatory alignment.

The Monetary Authority of Singapore’s November 2025 *Consultation Paper on Proposed Guidelines on AI Risk Management for Financial Institutions* states that controls “should be applied based on their relevance and be proportionate to the assessed risk materiality of AI usage.” It further specifies that the guidelines “may be applied in a proportionate manner — commensurate with the size and nature of FIs’ activities, use of AI, and their risk profile.” That is not a softening clause. It is the operational principle. A risk-tiered delivery framework is not sidestepping compliance; it is implementing what the regulator asked for. Organisations applying uniform heavyweight governance to every AI use case are, paradoxically, less aligned with regulatory intent than those operating a tiered model. The same proportionality logic threads through MAS FEAT principles and the broader trajectory of Asian regulatory guidance on AI. Proportionality is the regulatory ask. Uniform governance is the institutional answer to a question the regulator did not ask.

Second: Segmentation forces an explicit risk taxonomy, which is where most organisations fail.

Uniform governance persists because it avoids the harder question: what actually makes an AI use case high-risk? Segmentation demands a taxonomy — who consumes the output, what decisions it influences, what the blast radius of failure looks like, whether the output is advisory or deterministic, whether a customer can detect the error before the firm can. Building this taxonomy is uncomfortable because it requires cross-functional agreement between technology, risk, legal, and business. It is the load-bearing work that makes everything else possible — and the work that program leaders most consistently underestimate.

A diagnostic worth running before the architecture: ask your AI risk committee to list every AI use case in production, then to risk-classify each one. The result is reliably surprising. A meaningful fraction — frequently 30–50% — turns out to be rule-based automation rebranded as AI for budget purposes, or pilot demos that never had a target deployment, or vendor tools whose actual data flows are unclear. These are not high-risk use cases. They are *unrisk-classifiable*, which is a different problem with a different fix. Most governance machines treat unrisk-classifiable as Tier 3 by default, which is exactly how you end up with the uniform-treatment failure mode the regulator did not ask for. The taxonomy work is the moment the inventory stops being a list and becomes a map.

Third: The bottleneck is almost never the model — it’s the approval chain.

In most regulated AI deployments, the model itself is validated in days or weeks. The months-long timeline comes from routing every use case through the same committee structure, the same documentation template, the same sign-off hierarchy. Segmenting the pipeline means segmenting the approval chain. A Tier 1 (internal-facing, advisory) use case should not require the same governance artefacts as a Tier 3 (customer-facing, decision-influencing) deployment. When the approval chain is uniform, the technical pipeline has nowhere to express its segmentation. Form forces function.

The Practitioner Test

If you lead an AI program in a regulated environment, run this diagnostic on your current pipeline.

Pick your fastest-deployed AI use case and your slowest. Map the governance steps each went through. If the steps are identical, you have a segmentation problem — not a speed problem and not a quality problem. The contradiction is artificial, and the resolution is structural.

Go further. For each governance step the slowest use case went through, ask one question: what specific risk does this step mitigate, and how would I know if the mitigation worked? If the answer is “it’s part of the process,” that step is decorative governance. It slows you down without making you safer. Multiply the time cost of every decorative step across your pipeline, and you will find the actual source of the “AI is slow” narrative. It was never the technology.

The organisations that will scale AI in regulated markets are not the ones that move fastest or govern hardest. They are the ones that know precisely which parts of the pipeline need which kind of rigour — and waste nothing applying governance where it does not reduce risk.

The argument here is anchored in financial services because that is where the regulatory pressure currently sits sharpest. But the segmentation logic is industry-agnostic. Any sector where governance is applied uniformly to a multi-layered delivery pipeline — pharma, energy, defence, healthcare, telecommunications — carries the same misdiagnosis and resolves it the same way.

What’s Worth Doing Tomorrow

Open your AI governance documentation. Find the steps your slowest deployment passed through. For each step, write one sentence naming the specific risk it mitigates and the observable signal that the mitigation worked.

The steps that resist the sentence are decorative. Most pipelines carry 30–50% decorative governance — the technical term for *work that slows delivery without reducing risk*. The number is rarely zero. It is rarely under 20%. It is most often the largest single source of the lag every program blames on the technology.

You will recognise the moment you find them. They are the steps everyone privately knows are theatre but nobody removes, because nobody owns the removal.

That is the work. The TRIZ frame is the lens. The Prompt Kit is the structured method. The decision to redesign the pipeline around what actually mitigates risk is yours.

This essay accompanies the Tiered Governance Diagnostic Prompt Kit — four prompts to run the diagnostic above against your own pipeline. Download it alongside this essay on Regulated Intelligence.

If you are working through this exercise in a regulated environment and want a structured outside read — on the segmentation design, the risk taxonomy, or the approval-chain redesign that follows — mention it in your reply. I take one such conversation per month.

Replies to this post reach me directly. I read all of them.

Regulated Intelligence — TRIZ × AI | Regulated Markets. Written by JL CREPPY.

Sequenced from pipeline mapping → decorative-governance diagnosis → risk taxonomy construction → approval chain segmentation.

Designed for both technical and non-technical users.

Companion essay: [Your AI Governance Is Solving the Wrong Problem]

Prompt Kit Post 01

289KB ∙ PDF file

Download

Download

TRIZ × AI | Regulated Markets · JL CREPPY