The Boundary Was Doing Work

On 29 September, Google asked a European court to stop two doors from being opened. One leads into Android. The other leads into data generated by Google Search.

In July, the European Commission issued binding measures under the Digital Markets Act requiring Google to make both more accessible to competitors. Rival AI assistants are to receive access to Android capabilities currently available to Google's own services. Eligible competing search engines, including AI chatbots that provide search are to receive certain anonymised ranking, query, click and view data collected by Google Search.

Google has now challenged both decisions in the General Court of the European Union. Its objection is not simply that competitors are being given something Google would prefer to keep. Google says the Commission is forcing it to weaken boundaries that protect users.

The company argues that broader access to Android functionality creates device-security risks and that mandatory sharing of search data could expose sensitive information about European users. The Commission disagrees. It says its measures contain substantial privacy and security safeguards and are necessary because Google's control of Android functionality and search data gives its own services an advantage competitors cannot reproduce.

This can easily be reduced to a familiar argument: Europe wants competition; Google wants control. There is truth in that description, but something is missing from it.

The boundary being contested was doing more than keeping competitors out. It was also keeping responsibility in.

Closed systems make some questions easy

Imagine a system with one owner. The owner controls the interface, decides which applications can access it, determines what information leaves, monitors activity and can remove participants it considers dangerous.

Economically, this arrangement can be problematic. Control of the interface can become control of the market. A company that owns the operating system can give its own products capabilities competitors cannot obtain. A search engine operating at enormous scale can accumulate behavioural data that makes its service better, attracting more users, generating more data and reinforcing the advantage.

This is the feedback loop the Digital Markets Act is designed partly to interrupt. The Commission notes that Google Search has held more than 90% of the European search market for decades. Its scale gives it access to a quantity of user interaction data that competitors cannot independently reproduce. The Commission's answer is to require some of that advantage to become accessible under regulated conditions.

There is a strong competition argument for doing this. But closed systems have another property: they make accountability relatively legible.

If Google alone decides how a sensitive Android capability works, Google is plainly responsible for securing it. If search interaction data remains entirely inside Google's infrastructure, the number of organisations capable of mishandling that data is limited.

Opening the system changes both things. The market becomes less closed, but the trust model does too.

Interoperability is an interface between trust domains

The word interoperability sounds benign. Two systems work together. One application can call another. A user can choose a different provider without losing functionality. Data can move. From the user's perspective, this is usually the point.

From an engineer's perspective, interoperability means something else as well: a boundary has been crossed.

One system must now accept something from another system it does not entirely control. That may be data, an instruction, a credential or access to a device capability. The receiving system therefore has to decide what it trusts. Who is calling? What are they allowed to request? What information may they receive? How long does the permission last? Can the caller pass the information elsewhere? What happens if the caller is compromised? How is access revoked?

Those are not secondary questions added after interoperability has been designed. They are the architecture of interoperability.

This is why the Google dispute is more interesting than an ordinary antitrust case. The European Commission is not simply ordering a company to stop a particular commercial practice. It is beginning to specify how interfaces between independently operated technological systems should work.

The Commission knows the door cannot simply be opened

Look closely at the search-data decision and the architecture becomes visible.

Google is not being required to hand competitors a copy of every user's search history. The Commission requires personal data to be anonymised. Account information is excluded. Precise timestamps are withheld. Location information is generalised. Very long queries and queries containing rare words are suppressed because unusual combinations of information can make individuals easier to identify.

Recipients must satisfy eligibility requirements. They must operate search services and demonstrate sufficient trustworthiness and capability to handle sensitive data. Companies presenting serious structural cybersecurity or data-protection risks can be excluded, and international transfers must comply with the GDPR.

Recipients are also restricted in what they may do with the information. They cannot use it to train general-purpose AI models, for advertising or consumer profiling, or to systematically reproduce Google's search results instead of developing their own technology. An independent audit is required before access, another follows within six months, and further audits occur annually.

This is not merely data sharing. It is a trust framework.

The regulation creates a right of access and then has to construct an institutional system around that right because access without trust controls would create a different problem from the monopoly it is trying to solve.

The boundary cannot simply disappear. Its functions have to move somewhere else.

Boundaries are easy to mistake for obstruction

This is a recurring mistake in technological change. A boundary prevents something desirable, so the boundary appears to be the problem.

Sometimes it is. Organisations accumulate unnecessary permissions, incompatible systems, proprietary formats and bureaucratic controls. Incumbents can invoke security to defend commercial advantages. "For your protection" has a long history as an explanation for restrictions that also happen to benefit whoever controls the gate.

Google therefore deserves scrutiny when it argues that opening its systems creates risk. Its incentives are obvious. But incentives do not determine whether an engineering claim is true. A self-interested company can identify a genuine security problem, just as a well-intentioned regulator can create one.

The useful question is not whether the boundary should exist exactly as it does today. It is:

What work was the boundary performing, and where will that work happen after the boundary changes?

Sometimes the answer is nowhere. That is when openness creates fragility.

An open door needs a different kind of lock

The Android half of the dispute makes the problem more tangible.

The Commission wants competing AI assistants to receive access to functionality that allows Google's own AI services to interact more deeply with a device. Its examples include invoking an AI service through system-wide controls and allowing an assistant to perform actions through applications.

This matters because an AI assistant confined inside its own application is less useful than one capable of acting across the device. It is also less dangerous.

An assistant that can see context from another application, send an email, share a photograph or initiate an action occupies a different security position from a chatbot sitting inside an isolated window. Opening those capabilities to competitors therefore improves contestability by increasing capability. Increasing capability also increases consequence.

The Commission's response is not to deny that tension. Its rules allow Google to impose objective and non-discriminatory eligibility requirements concerning privacy, security and integrity.

That phrase contains much of the future of digital regulation.

The platform may protect the boundary. It may not protect the boundary selectively in ways that conveniently exclude competitors. Security controls themselves therefore become subject to governance.

The regulator is no longer asking only whether access exists. It has to ask whether the conditions imposed on access are genuinely necessary, proportionate and equally applied.

That is considerably harder.

Competition changes the attack surface

This problem will not remain confined to Google.

Consider open banking. For decades, banks controlled most of the interface between customers and their account data. Regulation and technical standards then enabled authorised third parties to connect to accounts through APIs.

This increased competition, but it also meant the security model could no longer stop at the bank. Identity, consent, authentication, API security, third-party certification and revocation became part of the system.

The same pattern appears in healthcare data, cloud portability, digital identity, smart-home ecosystems and increasingly in AI agents. Every interoperability mandate creates a new interface between organisations that do not share the same incentives, engineering practices or risk tolerance.

That does not mean interoperability is undesirable. It means its benefits and risks come from the same architectural change.

The system becomes less dependent on one controller because more participants can interact with it. It also becomes more dependent on the mechanisms governing interactions among those participants.

Power moves outward. Trust has to follow.

This creates a regulatory paradox

Competition authorities have traditionally worried about concentration. Cybersecurity teams often prefer fewer trusted parties. Those objectives can collide.

From a competition perspective, a platform that controls every important interface is dangerous because it can exclude rivals. From a security perspective, reducing the number of entities with privileged access can be desirable because every additional trusted party expands the attack surface.

Neither principle can simply defeat the other. Maximum openness is not automatically healthy competition, just as maximum closure is not automatically good security.

The design problem is finding the smallest set of privileges necessary to create meaningful competition while preserving enough control to contain failure.

That is an architectural problem. It involves least privilege, segmentation, identity, telemetry, certification, audit, revocation, data minimisation, purpose limitation and incident response.

These are familiar security concepts. What is changing is who has to design them.

Increasingly, regulators do.

Regulation is moving down the stack

Older regulation could often remain relatively abstract: do not discriminate, protect personal data, maintain competition, treat customers fairly. The organisation decided how to translate the rule into systems.

Digital regulation is moving closer to implementation.

The Commission's Google decision specifies categories of data, latency requirements, anonymisation methods, eligibility conditions, permitted purposes, audit mechanisms and implementation milestones. Its Android proceedings identify particular operating-system capabilities with which competing AI services must be allowed to interoperate.

The regulator is entering the architecture.

There is a reason. Market power increasingly resides in architecture.

A dominant digital platform does not need to explicitly tell a competitor that it cannot compete. It can control the API, the default, the identity layer, the data, the permission, the operating-system hook, the latency or the ranking signal.

Each technical choice can be individually defensible while collectively producing a market that outsiders cannot realistically enter.

If power is exercised through architecture, regulation eventually has to understand architecture well enough to distinguish a genuine constraint from a convenient one.

That is a much more demanding form of state capacity than writing rules.

The difficult failures will occur between organisations

There is another consequence. When a closed system fails, responsibility may be relatively obvious. When interoperable systems fail, organisations can disagree about where the failure began.

The platform says the third party mishandled access. The third party says the platform exposed unsafe functionality. The regulator says both were required to implement safeguards. The user sees only that something happened.

This is the organisational equivalent of a distributed-systems problem. Every participant sees part of the event. No participant necessarily sees the whole chain.

That makes evidence increasingly important.

Who requested access? Under which entitlement? What information crossed the boundary? Which safeguards ran? Which system made the consequential decision? When was anomalous behaviour detected? Who possessed the ability to revoke access?

These questions will sound familiar because they are the same questions emerging around AI-agent identity and delegated authority.

The common problem is not AI. It is distributed responsibility.

Openness needs observability

This suggests a principle that may become increasingly important:

The more open a system becomes, the more observable its interfaces need to become.

If multiple independent actors can interact with consequential infrastructure, the system needs enough evidence to reconstruct those interactions. Otherwise openness distributes action faster than it distributes accountability.

This is where competition policy, privacy regulation and cybersecurity begin to converge. Competition asks for access. Privacy asks that access not reveal more information than necessary. Security asks that access not create uncontrolled capability. Audit asks whether everyone obeyed the conditions. Incident management asks what happened when they did not.

Those are often treated as separate disciplines.

At the interface, they become one system.

There is a second danger: openness that does not work

The opposite failure should not be ignored.

A platform can technically comply with an interoperability requirement while making access so slow, restricted, expensive or degraded that no serious competitor can use it. An API can exist without producing interoperability. A dataset can be shared without containing enough useful information to compete. A permission can be available behind requirements nobody can practically satisfy.

Security can become the vocabulary through which closure survives regulation.

This is why the Commission's task is unusually difficult. It cannot simply require safeguards. It has to determine whether those safeguards are proportionate.

Too weak, and users inherit unnecessary risk. Too strong, and the incumbent retains the advantage the regulation was designed to remove.

The correct boundary is not obvious. It has to be discovered through evidence.

That makes the court case useful. Google says the Commission has opened the boundary too far. The Commission says it has designed protections sufficient to make opening safe.

Neither proposition should be accepted merely because of who is making it.

Now the architecture has to prove one of them right.

The boundary was doing work

We tend to think of boundaries spatially: inside and outside, allowed and blocked. But a boundary in a complex system performs several functions simultaneously.

It can concentrate power while preserving accountability. It can inhibit innovation while reducing attack surface. It can protect privacy while entrenching an incumbent.

All of those things can be true at once.

That is why removing a boundary is not enough. If the boundary was performing a necessary function, that function has to be rebuilt somewhere else.

The European Commission appears to understand this. That is why its Google decision contains anonymisation, eligibility, auditing, contractual restrictions and security exclusions rather than simply ordering Google to publish a dataset.

The experiment is whether those mechanisms can reproduce the useful properties of the old boundary without reproducing its concentration of power.

That is a much more interesting question than whether Brussels is hostile to Big Tech or Google is afraid of competition. And it is a question we will encounter repeatedly as digital systems become more interconnected.

The future is likely to contain more interoperability, not less. AI agents will interact across platforms. Financial services will exchange more data. Digital identities will travel between organisations. Health records will become more portable. Software will act across institutional boundaries that were previously difficult to cross.

Each opening will be described as increased choice, competition or convenience, often correctly. But every opening will also move something less visible: trust.

The lesson from this dispute is therefore not that systems should remain closed. It is that opening a system does not abolish the work its boundary was performing.

It merely forces us to decide who must perform that work now.

References

European Commission, “Commission provides guidance to Google for AI interoperability on Android and sharing of Google Search data under the Digital Markets Act,” 16 July 2026.

European Commission, “Alphabet specification proceedings — Sharing of Google Search data,” final measures adopted 16 July 2026.

European Commission, “Alphabet specification proceedings — Interoperability for AI services,” final measures adopted 16 July 2026.

Reuters, “Google challenges EU orders to open up to AI, search-engine rivals,” 29 September 2026.