Global IT Standardisation: Local Flexibility and AI
Global IT standards need room for local realities. Rubens Daniel explores how managed exceptions, clear ownership and AI cost controls help organisations adapt without losing control.

In my work, the hard part is rarely the technology. It’s knowing what will work in practice, and what it will cost.
Over the years, I’ve learned to be wary of two phrases that turn up in almost every multinational: “let’s standardise everything” and “it’s different here”. The first usually comes from headquarters, the second from local operations. Both are partly right, and both become a problem once they’re treated as rules.
In the first episode of The IT Leaders’ Brief, Thiago Prado, who runs global infrastructure operations at Bunge, summed it up in one line.
“Standardisation doesn’t require the absence of exceptions.”Thiago Prado
I agree, and I’d take the idea a step further. An exception isn’t just something to tolerate. Managed well, it’s the best source of information a global standard has about itself.
Every exception is data
In most companies, an exception is treated as a favour granted or a cost to keep down. It gets approved by email, logged in a spreadsheet nobody opens again and forgotten until the next audit. Along the way, its most useful part is lost.
A well-recorded exception tells you which rule was relaxed, in which market, why, at what cost and for how long. With that history to hand, leaders can answer a question no compliance report can: is the standard right?
If the same exception appears in three countries, it’s no longer an exception. It’s the standard asking for a new version. And if an exception is still active only because nobody has looked at it again, it has become debt.
That’s why I argue that a global standard should be run as a product. A product has an owner, versions and a backlog of change requests, and it’s revised based on how it’s used.
Every exception should also come with an expiry date and a cost that’s visible to whoever requests it, so the decision is made with the numbers on the table.
What to record | What it helps you decide |
|---|---|
Rule and market | Which part of the standard needs to change, and where? |
Reason for the exception | Is this a regulatory requirement, an operational need or a preference? |
Owner and approval | Who is accountable for the decision and its consequences? |
Cost and impact | What does the exception cost, and what benefit does it deliver? |
Expiry and review date | When should it end, be renewed or become part of the standard? |
Which layer flexibility belongs in
Thiago described how this works in infrastructure. Standards pay off most where suppliers are global: in equipment, purchasing volume and negotiating power.
Exceptions appear later, in installation, configuration and service delivery, where a local cybersecurity rule or a regulatory restriction forces you to adapt. That fine line, as he called it, shifts from market to market.
The practical question is which layer each decision belongs in. That needs to be designed upfront, rather than negotiated case by case.
- Global: contracts, platforms, security principles and shared KPIs
- Regional: requirements shared by a group of markets, and decisions that sit between global policy and country-level delivery
- Local: configuration and service delivery that accommodate country-specific requirements
There’s a limit. Information security and rules that affect people’s safety are not up for country-by-country debate.
A mature standard has a short list of non-negotiables and a clear set of things that can be adapted. An immature one treats everything as mandatory on paper and almost nothing as mandatory in practice.
AI shifts the balance
Artificial intelligence affects this balance from two directions, and the market has paid more attention to one of them.
The first is cost. AI spending is variable, usage-based, easy for individual departments to buy and hard to forecast.
If every department chooses its own tool, model and way of consuming it, the fragmentation that global standards spent years fighting comes back, now with a bill that grows with every query.
McKinsey’s 2026 State of AI survey helps put that tension into context.
37%
Of respondents report some enterprise-level EBIT impact from AI.
1 in 5
Say AI operating costs have constrained their organisation’s use.
60%
Expect their organisation to increase AI investment over the next year.
The share reporting an enterprise-level financial impact is almost unchanged from 2025, even as AI adoption expands. My reading is that investment is moving faster than demonstrated returns.
The second direction gets less attention: AI can also make local adaptation cheaper.
Much of the case for standardising rested on the cost of adapting, such as documenting procedures in several languages, interpreting each regulator’s requirements and maintaining different configurations by country.
As some of that work is automated, adaptations that weren’t worth it before start to make sense. AI can move the fine line, and anyone who isn’t measuring won’t notice.
Set the platform rules. Measure the business result.
Both pressures point to the same design. The AI standard needs to sit at the platform layer:
- Which models are approved?
- Where can data go?
- How is consumption measured?
- How are costs allocated to each department?
Use cases stay close to where the business happens.
Thiago described Bunge’s technology function as both a customer and a regulator of AI. I’d add that a regulator without measurement is just a gatekeeper.
McKinsey’s survey also found that AI high performers were twice as likely as other respondents to have defined processes for measuring the impact of their AI initiatives.
Measuring before scaling is what separates a pilot from a recurring cost.
When machines start running the standard
I closed my conversation with Thiago by asking about agentic AI, and that’s where I see the deepest change.
Until now, a standard was a document read by people, who interpreted it, adapted it and sometimes worked around it.
When agents start raising tickets, changing configurations or calling on suppliers, the standard has to become an executable rule.
Non-negotiables must become technical limits:
- What can an agent do in each market?
- Which data can it access and use?
- Which actions require human approval?
A company that doesn’t know exactly where its line between global and local sits today risks discovering the gap when an agent crosses it in a country with different rules.
The standardisation work that many have been putting off is now a prerequisite for the next phase of AI.
There’s no single truth
The challenge Thiago set for his peers, and for himself, was to keep an open mind when looking for the balance between local and global, between regulation and freedom.
I agree there’s no single answer. Each company’s maturity and circumstances determine where that balance lies.
But the questions are the same for everyone:
- Where is the line today?
- Who decides when it moves, and on the basis of what data?
- Who pays for the exception, and how long does it last?
- Which agent is allowed to cross it, and when?
Organisations that answer these clearly can be flexible without losing control.
Those that don’t end up with a standard that exists at headquarters, exceptions that exist on the ground, and an AI bill growing in between.
The standard that works is the one that listens. But you only listen well if you record what you hear and know exactly what you’re not prepared to negotiate.



