Loading home page
Platforms operate continuously, so governance must shift from episodic project approval to embedded decision rights
Curated by

Dr. Stéphane Niango
Research LeadershipExpert in DCOs & Strategic Transformation
DigitalQatalyst
Dr Stéphane Niango is a globally recognised digital transformation architect, strategy consultant and organisational design expert specialising in the evolution of Digital Cognitive Organizations (DCOs).
Platforms operate continuously, so governance must shift from episodic project approval to embedded decision rights, policy and exception handling that operate at platform speed.
Enterprise governance was largely shaped around projects: discrete commitments, approval points and bounded delivery phases. Platforms operate differently. They evolve continuously, distribute decisions across teams and increasingly execute policy through software and AI-enabled workflows. Applying project-era governance to this environment creates either latency or uncontrolled exceptions. Platform governance therefore needs a different logic: decision rights, policies, evidence and escalation paths embedded into the operating model so routine decisions can move at platform speed while consequential exceptions receive deliberate human judgment.
Governance does not become less important in a platform model; it changes location and cadence. The central design problem is no longer how to approve a technology initiative before delivery. It is how to coordinate thousands of recurring decisions after the platform becomes part of the operating system. Effective platform governance moves from episodic approval to continuous coordination, with controls designed into workflows rather than layered above them.
Stage gates are rational when the dominant decision is whether to fund, release or change a bounded project. They create moments at which leaders can examine scope, cost, risk and accountability before an irreversible commitment. Platforms weaken that assumption because the consequential decisions continue after launch. Access rules change, models are updated, data products evolve, interfaces are versioned and teams create new combinations of existing capabilities. Governance that concentrates attention at the beginning of the lifecycle can miss the decisions through which platform risk and value actually accumulate.
The alternative is not fewer controls. It is explicit decision architecture. Routine decisions should have defined parameters, evidence requirements and accountable owners. Decisions inside those parameters can move without waiting for a committee. Decisions outside them should trigger escalation based on materiality, uncertainty or impact. Policy-as-code, automated controls and observability can support this model, but the technology is secondary. The primary work is agreeing who may decide what, under which conditions, using which evidence and with what route for exception.
This reframes governance from a sequence of meetings into an operating capability. A well-governed platform should make compliant action easier, exceptions visible and accountability traceable. Governance then supports velocity because teams know the boundaries within which they can act.
AI-enabled workflows and agents increase the number and speed of decisions a platform can execute. That makes ambiguous authority and undocumented policy more consequential. If every machine-assisted decision requires manual approval, the promised velocity disappears. If decisions are automated without explicit boundaries, the organization scales uncertainty instead. Agentic systems therefore expose a governance question that already existed: which decisions can be parameterized, which require contextual judgment and how does the system know the difference?
Embedding policy into platforms creates its own risk. A poorly designed rule can be applied consistently at scale, and automated controls can create false confidence that a decision is sound simply because it is compliant. Some decisions remain too novel, irreversible or ethically consequential to reduce to parameters.
Continuous governance must therefore include mechanisms for policy review, exception learning and human override. The goal is not to eliminate committees or judgment. It is to reserve them for decisions that benefit from deliberation rather than forcing every routine decision through the same machinery.
Start by mapping governance latency. Identify decisions whose approval cycle is materially slower than the operational cycle they control. Separate routine decisions from high-impact exceptions. Define standing decision rights for the former and explicit escalation criteria for the latter. Then instrument the system so leaders can see not only whether policies were followed, but whether the policies are producing the intended outcomes.
A Platform Coordination Team can own this decision architecture across product, risk, data, security and operations. Its purpose is not to centralize every choice. It is to maintain the parameters that allow decentralized choices to remain coherent. Measures should include decision cycle time, exception frequency, policy overrides, control failures and the time required to update a rule when evidence changes.
Governance protects decisions. The logic of enterprise governance was developed for a world of project-based IT delivery: technology came in discrete packages, defined, built, tested, and handed over. Risk lived at the front of the process. Stage gates, change-control boards, and risk committees gave organizations a way to review major decisions before committing resources, and to catch bad decisions before they became expensive. This governance architecture was rational for what it was designed for. In a project world, risk is front-loaded. Governance at the approval stage is the right control point.
This logic still governs most enterprise technology programs. Most organizations apply it to platforms as well as projects, because the governance infrastructure was built before the distinction between projects and platforms was operationally significant. The assumption, still operating in most enterprises today, is that the same governance that protects project decisions can be applied to platform operations. It cannot.
A digital platform is not a project. It does not have a defined end state, a handover moment, or a post-go-live phase where governance steps back. A platform generates value continuously, through hundreds or thousands of decisions made across every team it serves, every day. BCG's analysis of 850 companies finds that only 35% of digital transformation projects reach their stated goals. IBM's Q4 2025 Think Circle finds that 79% of organizations report AI productivity gains but only 29% can measure ROI confidently. EY CEO Outlook 2026 finds that 80% of CEOs increased AI investment while only 19% are satisfied with their current governance frameworks.
The pattern is consistent: platforms are producing gains that existing governance cannot measure, scale, or protect. The governance is not absent ; most organizations have extensive governance. The problem IBM's research named directly is that "AI ambitions often collide with internal realities long before technical limitations do." The internal realities are governance mechanisms designed for project decision approval that are now being applied to platform operations at continuous velocity. Every decision that could be made in hours gets queued behind a committee cycle that runs over weeks. The platform cannot deliver what the investment thesis projected ; not because the technology failed, but because the coordination mechanism around it was not built for this kind of work.
The research on what this looks like in organizations that have made the shift is consistent. MIT CISR (December 2025) finds that enterprises with governance designed for their strategic context consistently outperform peers running the same strategy with misaligned governance ; by 26% in profitability on average. The condition attached to that finding matters: the comparison is not governed versus ungoverned, but well-designed governance versus governance designed for a different context. Almost every enterprise in the study has governance. Most of it is optimized for the wrong environment.
IBM's December 2025 research on governance and velocity finds that governance increases velocity when it is embedded in platform operating logic rather than queued above it. The mechanism is direct: when a decision falls within defined parameters, the platform executes it without human escalation. When a decision falls outside defined parameters, escalation is triggered. This is not reduced oversight ; it is oversight operating at platform speed rather than committee speed. Gartner's 2025 research found 61% of organizations evolving their operating models specifically because of AI, and identified governance as shifting from a compliance function to a platform capability.
The New Logic requires governance to live inside the design ; decision rights embedded in system logic, policy enforcement automated, coordination mechanisms that activate without requiring human escalation for every instance.
The diagnostic question is one: for each governance mechanism currently in place, was it designed for a platform operating continuously, or for a project delivering once? Where the answer is the latter, the mechanism needs to be redesigned, not removed.
CX and EX are distinct outcomes with shared operating causes. Where employees produce customer outcomes, redesigning the work can improve both more effectively than managing their scores separately.

Decomposition creates independent components. Composability comes from explicit contracts and stable boundaries that let those components combine predictably without bespoke translation every time.

CX and EX are distinct outcomes with shared operating causes. Where employees produce customer outcomes, redesigning the work can improve both more effectively than managing their scores separately.

Interoperability is created by design-time agreements about meaning, authority and contracts. Runtime integration can connect systems, but it cannot cheaply repair semantics that were never aligned.