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