IA no telemóvel: como saber o que é executado no dispositivo

Dizer que um telemóvel integra IA no dispositivo pode descrever uma capacidade do processador, uma funcionalidade específica ou uma parte do fluxo de trabalho. Por si só, não prova que todas as ferramentas inteligentes do telemóvel funcionem localmente. Uma aplicação pode usar um modelo instalado para uma tarefa e recorrer a servidores para outra, ou combinar os dois métodos durante a mesma interação. Por isso, é mais útil perguntar que tarefa é processada onde do que simplesmente se o telemóvel «tem IA local». Uma designação geral do produto pode referir-se a uma tecnologia disponível sem explicar como funciona, na prática, uma funcionalidade concreta para o utilizador.

A distinção é importante por razões práticas. Se uma operação ocorrer no próprio telemóvel, poderá continuar disponível sem ligação, embora isso dependa da aplicação e dos seus restantes requisitos. Se houver um servidor envolvido, poderão ser necessários uma ligação e a disponibilidade do serviço. O local de processamento também é relevante para compreender o tratamento dos dados, mas a execução local não equivale automaticamente a privacidade garantida. É necessário verificar que dados a aplicação recolhe, o que sincroniza e que controlos disponibiliza. Saber onde ocorre o cálculo responde apenas a essa questão específica; não descreve, por si só, todo o fluxo de dados nem todas as condições de utilização da funcionalidade.

Comece pelo nome exato da funcionalidade, não pelas expressões genéricas de uma campanha. Procure a documentação do fabricante ou do programador que explique essa funcionalidade específica e confirme se indica processamento no dispositivo, na nuvem ou uma combinação de ambos. A documentação para programadores Android descreve, por exemplo, como integrar a inferência de modelos de linguagem no Android através do Google AI Edge. Permite confirmar que existe uma via técnica para a execução local, mas não prova que uma funcionalidade específica de um telemóvel comercial a utilize. Um guia da plataforma e a implementação de um produto são tipos de prova diferentes; não trate um como confirmação do outro.

Registe também as condições que podem alterar o resultado: modelo do dispositivo, versão do sistema, idioma, região, transferência prévia do modelo, permissões e ligação. A disponibilidade anunciada pode depender destes requisitos e ser diferente para cada utilizador. Para organizar a verificação, compare os pontos seguintes. Procure indicações relativas à funcionalidade concreta e à respetiva configuração atual, em vez de presumir que um requisito indicado para um modelo ou uma região se aplica a todos. Se a documentação não esclarecer algum destes pontos, registe essa incerteza em vez de preencher a lacuna com uma inferência.

• Tarefa: a ação exata descrita pela fonte, como resumir texto ou reconhecer uma imagem.
• Processamento: se afirma explicitamente que o cálculo ocorre localmente, em servidores ou de forma híbrida.
• Requisitos: ligação, modelo do dispositivo, versão, região, idioma e definições.
• Dados: que informações são enviadas, conservadas ou associadas a uma conta, de acordo com a política aplicável.

Um guia para programadores pode demonstrar que uma plataforma permite executar modelos no dispositivo. O Google AI Edge documenta a inferência de modelos de linguagem no Android através do MediaPipe. Isso esclarece uma possibilidade de implementação, mas não identifica automaticamente que aplicações a adotam, que modelo utilizam ou se enviam pedidos adicionais para a nuvem. A capacidade da plataforma e o comportamento de uma funcionalidade não são a mesma afirmação. Um guia técnico ajuda a compreender o que os programadores podem criar; para determinar como funciona uma funcionalidade específica destinada aos consumidores, são necessárias provas que se refiram a essa funcionalidade. Ao tirar conclusões, mantenha estes níveis de prova separados.

Também é importante distinguir a execução local do funcionamento totalmente independente da rede. Uma aplicação pode calcular uma resposta no telemóvel e, ainda assim, precisar de ligação para iniciar sessão, transferir recursos, atualizar dados ou sincronizar resultados. Por outro lado, o facto de uma funcionalidade funcionar offline num teste concreto não revela, por si só, o que acontece noutros contextos de utilização. O guia do Android sobre a arquitetura offline-first trata a disponibilidade offline como uma decisão de conceção da aplicação e da sua camada de dados; não permite inferir onde qualquer produto específico executa IA. Um teste sem ligação informa, assim, sobre a disponibilidade durante esse teste, mas não resolve as questões mais amplas do local de processamento ou do tratamento de dados.

Para avaliar a privacidade, procure informações separadas sobre processamento, conservação e controlos. A documentação da Apple sobre o Apple Intelligence distingue o processamento no dispositivo dos pedidos que, para determinadas tarefas, podem recorrer ao Private Cloud Compute. A Apple descreve o seu sistema na nuvem como concebido para proteger os dados durante esse processamento. Trata-se da explicação do fornecedor sobre a sua arquitetura e as garantias declaradas; não deve ser convertida numa afirmação universal sobre todos os assistentes, fabricantes ou serviços. Ao consultar estas informações, identifique o ecossistema e os pedidos em causa, sem presumir que a mesma configuração se aplica a produtos diferentes.

Uma descrição útil deve permitir identificar que dados são processados, quando saem do telemóvel, com que finalidade e o que lhes acontece depois. Se o texto apenas promete que os dados estão «protegidos» ou que a IA é «privada», sem especificar o fluxo, fica uma pergunta por responder. Verifique também as definições de histórico, atividade, sincronização e utilização de dados, e se pertencem ao sistema operativo ou a uma aplicação de terceiros. Não confunda uma medida de segurança anunciada com a ausência de transferência de dados, nem a falta de uma explicação pública com prova de que os dados são enviados. Uma conclusão cuidadosa deve indicar o que a documentação disponível confirma, o que não demonstra e que pormenores permanecem por esclarecer.

Ao analisar uma funcionalidade, a conclusão deve refletir o alcance das provas. Se a documentação específica da funcionalidade disser que uma tarefa é processada localmente, pode descrevê-la dessa forma, incluindo os requisitos e limites indicados. Se um documento explicar apenas uma ferramenta para programadores ou a capacidade geral de uma plataforma, a conclusão deve ficar nesse nível. Se não houver uma explicação verificável para a funcionalidade, o correto é assinalar que o método de processamento não foi confirmado pelas fontes consultadas. Esta abordagem evita transformar uma possibilidade técnica numa afirmação sobre um produto comercial e evita classificar como local ou na nuvem um processo que continua por esclarecer.

Antes de escolher um telemóvel ou ativar uma ferramenta, é razoável fazer quatro verificações: encontrar a documentação da funcionalidade exata, identificar os respetivos requisitos, consultar a política de dados aplicável e testar o comportamento offline apenas como verificação prática da disponibilidade. Esse último teste não substitui a documentação de privacidade nem demonstra, por si só, o que acontece a cada dado. A informação disponível aqui não comprova um anúncio recente específico nem permite atribuir um método de processamento a todas as funcionalidades de uma marca. Este guia é, portanto, um método de verificação, não uma notícia sobre um lançamento. A conclusão deve manter-se limitada à tarefa, às provas e às condições que foram efetivamente verificadas.