Interoperabilidade de IA no Android: o que o DMA obriga a especificar
A proposta europeia para interoperabilidade de IA no Android é mais interessante pelo que ela obriga a especificar do que pela disputa entre Google e regulador. A Comissão Europeia enviou, em 27 de abril de 2026, conclusões preliminares à Alphabet dentro de um procedimento do Digital Markets Act para definir medidas de acesso e interoperabilidade com recursos centrais do Android. A consulta pública fica aberta até 13 de maio de 2026, e a decisão final está prevista para 27 de julho de 2026. O recorte técnico relevante não é “qual assistente vence”, mas quais interfaces do sistema operacional passam a ser necessárias para que um assistente de IA funcione como parte real do ambiente móvel.
Assistentes como camada de execução
A tese é que assistentes de IA deixaram de ser apenas aplicativos com uma janela de chat. Quando podem ser chamados por voz, acessar contexto de tela, ler sinais de aplicativos, agir em nome do usuário e usar modelos locais, eles passam a operar como uma camada de execução sobre o sistema operacional. Nessa posição, o modelo importa, mas não basta. A capacidade prática depende de invocação, permissões, APIs, superfícies de exibição, acesso a recursos de hardware e contratos claros com os aplicativos instalados.
O procedimento não nasce do AI Act, mas do DMA. A Comissão já havia aberto, em 27 de janeiro de 2026, dois procedimentos de especificação relacionados ao Google, um sobre interoperabilidade do Android com serviços de IA e outro sobre compartilhamento de dados de busca. No caso do Android, a base é a obrigação de fornecer interoperabilidade efetiva e gratuita com recursos de software e hardware controlados pelo sistema operacional. Isso muda a natureza da discussão. Não se trata de avaliar o conteúdo produzido por um modelo, mas de definir se concorrentes conseguem acessar as mesmas alavancas operacionais usadas pelo Gemini no Android.
As quatro áreas da consulta técnica
A consulta técnica organiza o problema em quatro áreas que, juntas, descrevem a anatomia de um assistente integrado ao sistema.
A invocação inclui frase de ativação própria, acesso por botões ou gestos de sistema e recebimento de dados contextuais para tarefas como traduzir ou buscar informação na tela. O contexto inclui acesso centralizado a dados armazenados no dispositivo e participação em sugestões proativas. A ação inclui integração com aplicativos instalados e execução de tarefas dentro deles. Os recursos incluem entradas como áudio e conteúdo da tela, superfícies de exibição, capacidade de processamento, modelos no dispositivo e desempenho suficiente para que a experiência seja responsiva.
Instalar versus integrar
Há uma diferença técnica grande entre permitir que um usuário instale um app de IA e permitir que esse app seja invocado como parte do sistema. Um aplicativo comum espera que o usuário abra a interface, cole contexto e autorize ações de forma explícita. Um assistente integrado precisa operar em fluxo contínuo, muitas vezes a partir de um comando curto, com estado parcial, dados de tela e intenção ainda ambígua. A frase de ativação e os pontos de acesso do sistema não são detalhes de conveniência. Eles definem quem pode iniciar uma interação no momento em que a intenção do usuário aparece.
O acesso a contexto torna o problema mais delicado. Para responder a “mande isso para o financeiro” ou “resuma esta conversa e crie um lembrete”, o assistente precisa identificar o que “isso” significa, qual aplicativo está ativo, quais dados podem ser lidos e quais partes devem ficar fora do escopo. Esse tipo de contexto não é equivalente a uma janela de tokens maior. É uma combinação de estado de interface, dados persistidos por apps, permissões do usuário e políticas do sistema. Sem uma API estruturada, o caminho tende a virar raspagem de tela, automação frágil ou integrações proprietárias difíceis de auditar.
A camada de ação e seus riscos
A camada de ação é ainda mais sensível, porque transforma entendimento em efeito. A proposta menciona serviços de IA interagindo com aplicativos para enviar email pelo app preferido do usuário, pedir comida, compartilhar fotos, controlar aplicativos instalados e ajustar configurações do sistema, como brilho da tela ou modo “não perturbe”. Cada uma dessas ações exige semântica operacional. O sistema precisa saber o que pode ser feito, por quem, em qual contexto, com qual confirmação, com qual registro e com qual possibilidade de reversão. Um assistente que escreve um texto incorreto gera um erro de conteúdo. Um assistente que executa a ação errada altera estado.
Os recursos locais fecham o argumento. A Comissão não está tratando apenas de acesso a botões ou permissões; a consulta inclui desempenho, disponibilidade, responsividade, modelos no dispositivo e uso efetivo de modelos próprios por terceiros. Isso reconhece um ponto que aparece cada vez mais em produtos de IA: latência e privacidade não são apenas propriedades do modelo remoto. Em um celular, parte da experiência depende de execução local, captura de áudio, interpretação de tela, cache, priorização de recursos e superfícies de resposta. Se essas peças forem exclusivas ou assimétricas, a competição entre assistentes fica limitada antes mesmo de o modelo ser chamado.
O dilema do Google
A reação do Google também expõe o dilema técnico real. A empresa argumenta que o Android já permite assistentes de IA e que a intervenção poderia reduzir autonomia de fabricantes, elevar custos e comprometer privacidade e segurança ao exigir acesso a hardware e permissões sensíveis. Esse ponto não deve ser descartado como defesa corporativa genérica. Abrir recursos profundos do sistema para terceiros aumenta a superfície de ataque, amplia o impacto de erros de autorização e exige mecanismos mais fortes de isolamento, consentimento, telemetria e revogação. Interoperabilidade efetiva sem modelo de segurança efetivo apenas transfere concentração para risco operacional.
Implicações para desenvolvedores
A implicação para desenvolvedores de software é direta, mas não no sentido simplista de trocar um assistente por outro. Aplicativos móveis tendem a precisar de contratos mais explícitos para ações, dados e contexto. Um app de email, calendário, mensagens ou entregas não pode depender apenas de uma interface visual pensada para humanos se assistentes forem executar tarefas com confiabilidade. Passa a ser necessário expor intenções, parâmetros, estados permitidos, erros, confirmações e limites de acesso em formatos que o sistema e o assistente consigam interpretar. Essa é a diferença entre automação por clique e integração por contrato.
Esse desenho também afeta a avaliação de assistentes. Benchmarks de resposta, raciocínio ou uso de ferramentas medem parte do problema, mas não capturam a confiabilidade de uma ação executada dentro de um sistema operacional com permissões reais. Um assistente móvel precisa ser avaliado por sucesso de tarefa, respeito a escopo, uso mínimo de dados, recuperação de erro, latência percebida e comportamento sob permissões parciais.
Padronização da fronteira IA–sistema operacional
Se as medidas forem convertidas em obrigação, o impacto mais duradouro pode ser a padronização da fronteira entre IA e sistema operacional. O modelo continuará sendo importante, mas a vantagem prática dependerá de uma infraestrutura de invocação, contexto, ação e recursos locais que seja documentada, auditável e segura. A discussão sobre IA móvel deixa de caber apenas em comparações de modelos ou em rankings de chatbots. Ela passa a envolver o desenho das APIs pelas quais a IA percebe o ambiente, decide o que pode fazer e executa mudanças no estado do dispositivo. Nesse ponto, interoperabilidade deixa de ser uma abstração regulatória e vira uma propriedade técnica do produto.