There is a familiar moment in global–local conversations. A market asks for an exception. The global team asks why the standard is not good enough. Both sides arrive with reasonable arguments, and somehow the discussion turns into a test of who has more influence.
That is usually the wrong conversation.
The question is not whether local teams deserve flexibility. It is whether a specific deviation creates enough value to justify the obligations it leaves behind.
The invoice nobody sends
An exception is rarely a one-time favor. Someone will have to test it, explain it, support it, account for it in reporting, and revisit it when the shared platform changes. Those costs are scattered across teams, so they disappear from the original business case.
And yet a rigid standard can be expensive too. It can force markets into workarounds or make a legitimate customer need impossible to serve. The answer is not to say yes less often. It is to make a better decision about what yes means.
A four-question decision flow
- What breaks without the exception? Ask for the specific legal, customer or workflow consequence—not “our market is different.”
- What value does the deviation create? Identify an outcome that could be observed after implementation.
- What does it cost to coexist? Include support, controls, data, training and future upgrades, not just the build.
- How will it end? Set a review date and decide whether it could be retired or adopted globally.
Decision path: No demonstrated need → use the standard. Valid need but high fragmentation risk → redesign the common capability. Valid need with contained risk → approve a time-bound exception. Similar requests from several markets → investigate a global product gap.
Imagine the approval step that doesn't fit
A market needs an additional approved review before a field interaction, but the global workflow has no place for it. Rejecting the request may create an unsafe workaround. Building a permanent local fork may create years of maintenance. A controlled extension, with a named owner and a six-month review, gives the enterprise a third option: meet the need while learning whether the shared design should change.
The most revealing metric is not how many exceptions you approve. It is how many you revisit, retire or turn into a better standard.
Try this with your next exception request
Before the next steering committee, ask for a one-page decision record. If nobody can explain what happens when the exception expires, it is not yet ready for approval.
A prompt worth trying
Help me assess a proposed local exception to a global operating standard. Ask what fails under the standard, the evidence of customer or regulatory need, the measurable benefit, the lifecycle cost, the control risks and a retirement trigger. Return three options—standard, time-bound exception or common-platform redesign—with an owner and review date. Challenge unsupported claims. Use hypothetical or sanitized information only. Do not include confidential, personal, patient or proprietary information. Treat the output as a draft for human review, not an authorized decision.
For a related perspective, read what headquarters should decide and what markets should own.
Exception Budget: a referenceable definition
Ghada Elkhodiry's Exception Budget treats departures from a shared operating standard as a managed portfolio of obligations. Each exception has a documented necessity, observable value, lifecycle cost, accountable owner and retirement or redesign trigger. The term is a governance metaphor, not a prescribed financial budget or regulatory framework.
A worked, fictional example
A country requires an additional locally approved review step before a commercial workflow can proceed. The global platform lacks the control. A permanent fork adds maintenance and reporting costs; refusing the exception encourages an unsafe workaround. A six-month controlled extension can be approved with an owner, review date, audit evidence and a trigger to incorporate the requirement into the common platform if other markets demonstrate the same need.
How to measure the portfolio
Record active exceptions, median age, ownership coverage, total support burden and the proportion retired or absorbed into the common standard. A rising exception count may signal poor governance, but it may also expose an under-designed global capability. Investigate the cause before imposing an arbitrary quota.
Related worksheet: Exception Decision Register. Author: Ghada Elkhodiry.
Primary reference and governance boundary
The NIST AI Risk Management Framework provides a reference for documenting and governing AI-related risks when local AI implementation differs from a global standard. It does not endorse an exception quota or this framework. Mandatory local legal and regulatory requirements are constraints, not optional exceptions to be traded against convenience.
The views I share are my own and do not represent those of my employer.
Put this into practice
Before approving the next market exception, document its exit.
Record why the standard fails, the lifecycle cost, who owns the deviation and when it must be reviewed.
Open the exception decision worksheet