The next question is whether every action can be governed while it happens.

Integration companies have spent three decades solving the connectivity problem. What most have not solved is the AI governance layer that decides what connected systems are permitted to do, and that is the problem that now defines the next era. At Maicell we call this Governed Intelligence.

The gap is already visible

The evidence is not hard to find. Gartner predicts that over forty per cent of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. A 2025 DATAVERSITY survey found that only fifteen per cent of organisations describe their data governance programmes as mature.

Set those findings side by side and the picture is uncomfortable: organisations are deploying autonomous capability at scale while, by their own account, lacking the governance maturity to control it. Two of Gartner’s three reasons are commercial. The third, inadequate risk controls, is architectural. It is not a failure of the technology; it is the absence of a layer that decides what the technology is allowed to do. In most organisations, that layer does not exist.

We have watched this pattern before

When we founded ConnectPlaza in 2009, the problem we set out to solve was not connectivity for its own sake. It was what uncontrolled connectivity had already done inside organisations. Integration scripts had proliferated across departments, written by individual administrators to solve individual problems. Each one was reasonable on its own. Collectively, nobody knew what they did. When the administrator who wrote a script left, the knowledge left with them. Failures could not be explained. Data moved along routes nobody could trace, and when an auditor asked how a record had ended up where it did, the honest answer was often that no one knew.

Eighteen years and more than 1,500 enterprise customers later, we are watching the same pattern repeat with AI. The actors have changed. Models and agents have replaced scripts and administrators. The shape is identical: capability spreading faster than accountability, useful things built in good faith by people solving local problems, and an organisation that gradually loses track of what is acting on its behalf. The difference this time is speed, and the fact that the things acting are no longer deterministic.

What iPaaS solved, and what it left open

iPaaS solved the connectivity problem. The platforms that matured through the 2010s made it possible to connect almost any combination of systems without writing substantial custom code, and that capability transformed how organisations operate.

What iPaaS left open was a different question. Integration platforms were designed to move data reliably; what those systems did with what they received was treated as outside the platform’s concern. That was a reasonable decision at the time, when the systems being connected were largely deterministic and deferring the governance question was workable.

Cloud migration, SaaS adoption, and the introduction of AI-driven systems whose outputs vary with context have changed those conditions. The question is no longer only whether the data arrived. It is whether the action taken on that data was authorised, and by whom. The governance question that was deferred is now the one the board, the auditor, and the regulator are asking. In Europe the timetable is concrete: the EU AI Act‘s transparency obligations take effect in August 2026, with the high-risk obligations following in 2027.

The marginal cost of connection has collapsed

The other structural change since the iPaaS era is the marginal cost of a connection. As an internal exercise, we recently implemented an MCP server against a single Excel workbook to establish what the effort actually involved. The working implementation took four hours and ran to fewer than forty lines of code. The conclusion was difficult to avoid: anyone with modest technical skill can now expose a system, a dataset or a spreadsheet to a language model within a working day. The industry is standardising in the same direction. Forrester expects roughly thirty per cent of application vendors to ship MCP servers in 2026, at which point connection stops being an integration project and becomes a standard property of the software estate.

The implementation was the trivial part, and that is the observation worth dwelling on. Nothing in those forty lines specified what the model was authorised to read, what it was permitted to do with the result, or where accountability would sit when it acted. The engineering effort of establishing a connection has collapsed. The engineering discipline of deciding what a connection is permitted to do has not, and no protocol will supply it.

When the cost of connection collapses, sprawl accelerates. Each of those inexpensive connections is a route through which a model can read data or trigger an action, and most of them are created outside any review process. They are the modern equivalent of the administrator’s script, multiplied. But there is one material difference. A script could only ever do what it was written to do. A model connected to your systems decides what to do in the moment, based on context you did not fully anticipate. The constraint on enterprise AI is therefore no longer how quickly you can connect. It is whether you can govern what you have connected.

The architectural answer: an AI governance layer

Connection and governance are different problems. Connection moves data reliably between systems. Governance determines whether what those systems do with that data is authorised, accountable, and on the record. Treating them as the same problem produces the same failure every time: policy applied after the fact, to actions that have already occurred.

None of this dismisses the governance tooling the industry already has. API management enforces policy at the gateway. Policy engines externalise authorisation decisions. Audit and lineage tools reconstruct what happened. That generation of tooling was built for deterministic traffic: a known caller invoking a known operation with a predictable payload. It answers whether a request is allowed. It was not designed for the question a non-deterministic actor raises, which is whether an action nobody anticipated, taken on the actor’s own initiative, should proceed, and on whose authority. That is the gap between governing API calls and governing intelligence.

Governed Intelligence is the layer that embeds policy in the execution of every connected action, making each decision visible, explainable in business language, bound by policy before it becomes an action, and recorded. It closes the gap by governing at the point of action rather than applying policy afterwards, so the control trail holds up when questions are asked.Every agent acts under an identity, within scopes, and every action traces back to the human decision that authorised it. In practice, the questions a board or a regulator asks after an incident have answers that existed before the incident: who approved this, who can stop it, what did it decide and why.

There is an obvious objection, and it deserves a straight answer: an ungoverned connection does not route itself through anyone’s governance layer, ours included. This is why governance cannot sit beside the estate as a separate product. The lesson of the integration era is that prohibition has never stopped sprawl; convenience has. The governed path has to be the easiest path, with connectivity, identity and policy in one place, so that building through the layer is faster than building around it.

You cannot govern how a model reasons, but you can govern what it is permitted to do when it acts through that layer. It is where every consequential action lands, and it is where the data lives. For European enterprises in particular, governance at this layer is what allows data, increasingly the real intellectual property of the business, to keep working inside a controlled environment rather than leaking into tools and models the organisation cannot see.

Why this matters now

Every technology leader is effectively answering the governance question right now, through what they build and what they choose to defer. The pressure is always to connect the next system, ship the next integration, and treat governance as something to address later. We understand that pressure. We have worked inside it for the better part of two decades.

What we have also watched, across enough transitions in this industry, is how deferred infrastructure questions resolve. They do not disappear. They accumulate until something forces the issue: an incident, an audit, a regulator, a customer. By then the cost and the circumstances are rarely of your choosing. The organisations that came through the integration era in good shape were not the ones that connected fastest. They were the ones that could still explain, years later, what was connected to what and why. The same will be true of this era, with less time to get it right.

One caveat belongs on the record. A platform can enforce policy; it cannot author it. Deciding what an agent may touch, and who is accountable when it acts, remains an organisational discipline. What the architecture changes is whether that discipline is enforceable, and whether it costs speed. Embedded in the execution layer, it does not: the guardrails travel with the work, and teams connect and automate at the pace the business wants. Governance applied afterwards slows everything down and catches little. Governance built in is what allows speed to be safe.

What comes after iPaaS

Every business adopting AI is chasing the speed advantage it offers. But speed without governance is a liability, not an asset. The gap between the two is where the next decade of enterprise incidents will come from.

That is what comes after iPaaS. Not more connectivity, but the AI governance layer that makes connectivity trustworthy. Governed Intelligence is the answer, and the future of the enterprise depends on getting it right. It is not artificial. It is governed.