Opening AI access to Android and search data needs field-level control tests
Google is appealing EU interoperability and search-data orders. The dispute shows why access, privacy and security must be tested at the exact field, action and recipient boundary.

What happened
Google said on 29 September that it is challenging European Commission orders requiring Android AI interoperability and access to certain Google Search data, arguing the measures create privacy and security risks.
Why it matters
A binary choice between openness and protection hides the engineering work. Each shared field and interoperable action needs a purpose, recipient, privacy transformation, abuse test, revocation rule and measurable residual risk.
Google is challenging European Commission decisions that specify how Android should interoperate with third-party AI services and how eligible rivals may access certain Google Search data. Reuters reported on 29 September that Google argues the orders create privacy and security risks. The Commission says its July decisions considered privacy and platform integrity; rival DuckDuckGo argues robust access is needed for competition.
The dispute is legal and technical. This article does not resolve whether the Commission’s orders are proportionate or whether Google’s appeal will succeed. It identifies the operational control problem: “open” and “secure” are not mutually exclusive system properties, and neither can be assessed without naming the exact data field, action, recipient and threat.
Separate data from actions
Build two inventories. The first covers every search-data field offered to recipients: query representation, result features, interaction signals, location, timing, device attributes and any linkage key. The second covers every Android function exposed to another AI service: read, invoke, modify, route, present, purchase or communicate. For each item, record purpose, legal basis, recipient class, transformation, rate limit, retention, audit evidence and revocation path.
The Commission’s detailed materials describe privacy-oriented measures such as suppressing direct identifiers, treating long or rare queries carefully, generalising location and interaction data, limiting refinement sequences and coarsening durations. Those are design controls, not proof that re-identification is impossible. Risk depends on combinations, external datasets, recipient behaviour and repeated access.
Define a change process as well. A new field, recipient class or callable Android function should reopen the relevant privacy and security tests before launch. Emergency changes need a short expiry and retrospective review. Otherwise an interface can remain formally compliant while its effective attack surface expands through incremental additions that nobody evaluates together.
Maintain a joint evidence log for regulator, gatekeeper and qualified recipients. It should distinguish confirmed vulnerabilities, disputed assumptions, implementation defects and policy questions, and show whether a fix changes availability. This prevents a privacy claim from becoming a permanent veto and an access claim from bypassing unresolved security evidence.
Test combinations and recipients
Run re-identification and inference tests against realistic auxiliary data. Measure singling-out risk across rare queries, time sequences and location combinations. Red-team extraction, reconstruction, membership inference, cross-recipient collusion and attempts to exceed query-session limits. Publish aggregate test methods and failure thresholds while protecting sensitive exploit details.
For Android interoperability, test privilege escalation and confused-deputy paths. A third-party AI service should receive only the action and object a user approved, with clear attribution and a narrow time window. Revoking the service must stop queued and cached actions. Logs should let a user and regulator reconstruct which service requested, authorised and executed an outcome.
The counterargument is that extensive testing can become a delaying tactic or entrench the incumbent’s preferred interface. That is a real governance risk. Define deadlines, independent test access, a public issue taxonomy and measurable acceptance criteria. Permit challengers to propose adversarial cases. Separate unavoidable residual risk from remediable implementation choices and record who accepts each exception.
Access recipients also need obligations. Verify identity, purpose limitation, retention, onward-sharing controls, incident reporting and deletion. Suspend a recipient when evidence shows abuse, but preserve a challenge route so security controls do not become opaque exclusion.
The Skills Intelligence Role Dictionary can help assign owners for privacy engineering, interoperability testing, incident response and legal interpretation. It cannot decide the legal merits of the appeal. Teams should keep technical evidence versioned as interfaces and orders change.
The immediate move is a field-and-action control matrix with adversarial tests and independent review. That makes privacy and security claims falsifiable while preserving a route to meaningful access, instead of asking decision-makers to choose between two unmeasured slogans.