Quando o Google Maps começou a entender “me mostra pastel que aceita vale-refeição perto de mim” como se fosse um pedido do iFood para um humano, alguma coisa mudou de figura. Segundo o Eurisko.com.br, o Ask Maps — recurso alimentado pelos modelos Gemini — saiu dos Estados Unidos e da Índia e está chegando a mais de 150 países, incluindo o Brasil, com suporte nativo a português desde o Google for Brasil 2026. Na prática, isso é o fim da busca por keywords em um dos produtos mais usados da internet. E para quem programa, abre um leque de possibilidades — e de cuidados que muita gente ainda não está olhando.
O que realmente muda com o Ask Maps (e o que muda para você, dev)
O ponto central não é “agora o Maps entende linguagem natural” — é como essa camada conversacional foi costurada em cima de três peças que já existiam: Places API, roteamento e reviews. Quando você digita uma pergunta em vez de uma busca estruturada, o Gemini recebe o contexto de localização, histórico recente e a intenção extraída do texto, e decide qual API chamar, qual filtro aplicar e como sintetizar a resposta.
Em outras palavras: o Maps virou um agente. E a diferença entre um chatbot genérico e um agente de verdade está justamente nessa capacidade de decompor uma intenção em chamadas de ferramentas — coisa que o Gemini 2.5 já faz por padrão via tool use e function calling. Isso explica por que a experiência parece tão diferente de simplesmente colar uma pergunta no Bard antigo.
O pipeline técnico por trás das cortinas
Embora o Google não tenha publicado a arquitetura interna do Ask Maps, dá para reconstruir a lógica combinando o que já sabemos do Gemini e do Maps Platform:
- Camada de entrada: texto em linguagem natural + contexto de geolocalização + permissões do dispositivo.
- Camada de raciocínio: o Gemini identifica a intenção (achar lugar, montar rota, comparar opções), extrai entidades (“pastel”, “vale-refeição”, “aberto agora”) e gera um plano de chamadas.
- Camada de dados: Places API para pontos, Directions API para rotas, reviews e fotos para enriquecer o resultado.
- Camada de saída: resposta em linguagem natural com cards visuais, marcadores no mapa e, quando faz sentido, CTA direto.
Quando testo implementações parecidas com Gemini, percebo que o gargalo quase nunca é o modelo — é a forma como você monta o prompt de sistema, as descrições das tools e o cache do contexto geográfico. Erro clássico: mandar lat/long cru a cada turno. Isso queima token e aumenta latência sem necessidade.
Na Prática: montando um protótipo com Places API + Gemini
Se você quer entender na carne como essa camada conversacional conversa com o Maps, dá para reproduzir o esqueleto em poucas linhas. O exemplo abaixo usa Node.js e mostra como um agente poderia responder “lugares com bom pastel que aceitam VR”:
import { GoogleGenerativeAI } from "@google/generative-ai";
import { Client } from "@googlemaps/google-maps-services-js";
const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY);
const maps = new Client({});
const tools = [{
functionDeclarations: [{
name: "buscar_estabelecimentos",
description: "Busca estabelecimentos próximos com base em critérios de texto e tipo.",
parameters: {
type: "object",
properties: {
query: { type: "string", description: "Termo principal (ex: 'pastel', 'padaria')." },
tipo: { type: "string", enum: ["restaurant","cafe","tourist_attraction","bar"] },
raioMetros: { type: "number", default: 2000 },
abertoAgora: { type: "boolean", default: false }
},
required: ["query"]
}
}]
}];
async function responder(perguntaUsuario, lat, lng) {
const model = genAI.getGenerativeModel({
model: "gemini-2.5-flash",
tools,
systemInstruction:
"Você é um concierge local. Sempre que precisar de dados de lugares, chame buscar_estabelecimentos. Responda em português e cite o nome e a avaliação média de cada sugestão."
});
const chat = model.startChat();
const result = await chat.sendMessage(perguntaUsuario);
const call = result.response.functionCalls()?.[0];
if (call?.name === "buscar_estabelecimentos") {
const { query, tipo, raioMetros, abertoAgora } = call.args;
const places = await maps.textSearch({
params: {
query, location: { lat, lng }, radius: raioMetros,
opennow: abertoAgora, type: tipo, key: process.env.MAPS_KEY
}
});
const resumo = places.data.results.slice(0, 5).map((p) => ({
nome: p.name, rating: p.rating,
endereco: p.vicinity, place_id: p.place_id
}));
const final = await chat.sendMessage([{
functionResponse: { name: "buscar_estabelecimentos", response: { locais: resumo } }
}]);
return final.response.text();
}
return result.response.text();
}
Esse é o esqueleto que o Ask Maps provavelmente roda em escala. As diferenças reais estão no cache de contexto por usuário, no ranking proprietário do Google e nas nuances do prompt de sistema — coisas que a empresa não publica, mas que qualquer dev consegue inferir com um pouco de experimentação.
Comparativo honesto: Ask Maps versus o que existia antes
| Aspecto | Maps tradicional | Ask Maps (Gemini) |
|---|---|---|
| Tipo de busca | Palavras-chave estruturadas | Linguagem natural + intenção |
| Filtros combinados | Poucos por vez | Múltiplos, inferidos automaticamente |
| Memória de contexto | Sessão isolada | Histórico recente + localização |
| Resposta | Lista de pinos | Narrativa + mapa + cards |
| Custo para o usuário | Zero, mas tempo gasto | Zero, dados enviados ao Google |
Alternativas no ecossistema dev: o Mapbox mistura bem com LLMs via API própria, o HERE tem um Places SDK muito competente, e se você quer algo 100% local/offline, dá para combinar Nominatim (OpenStreetMap) com um modelo pequeno rodando em servidor próprio. Nenhuma chega perto da base de dados do Google — e isso é deliberado. Quando o assunto é review, fotos e horário em tempo real, o moat do Ask Maps é a quantidade absurda de signal que o Google coleta há 20 anos.
Erros comuns que devs cometem ao montar agentes de localização
Já vi muita equipe tropeçar nas mesmas pedras. Anota aí, porque isso aparece em produção mais cedo do que você imagina:
- Mandar o contexto bruto a cada turno. Localização precisa é útil só uma vez por sessão; depois vira cache. Senão você paga token caro e ainda atrasa a resposta.
- Esquecer do prompt de sistema. Sem ele, o Gemini alucina nomes de lugares. No exemplo acima, eu forcei “sempre cite nome e avaliação” — esse tipo de amarração elimina 80% das respostas ruins.
- Não tratar o caso de tool call vazio. Quando o Gemini decide que não precisa chamar nenhuma função, a resposta vem direto. Se você não cobre o
else, a UI trava em loading infinito. - Confiar só em
rating. Avaliação média esconde muita coisa. Um 4.2 com 5 reviews vale menos que um 3.9 com 800. Normalize por volume antes de apresentar. - Ignorar custo de Places API. Text Search e Details são cobrados por chamada. Em escala, um agente que dispara Places a cada turno estoura o orçamento. Cache agressivo + debounce é obrigatório.
- Não anonimizar localização antes de logar. LGPD pega pesado com isso. Trunque para 3 casas decimais se precisão total não for essencial para o caso de uso.
FAQ — o que devs reais perguntam sobre o Ask Maps
1. O Ask Maps roda 100% no Gemini ou tem modelo próprio?
A versão atual usa os modelos da família Gemini como camada de raciocínio, mas a execução das chamadas (Places, Directions, Routes) continua nas APIs clássicas do Google Maps Platform. Em outras palavras: Gemini é o cérebro, Maps Platform é o corpo.
2. Dá para integrar algo parecido no meu próprio app?
Sim, e é exatamente o que mostrei no exemplo acima. Você precisa de uma chave do Google Maps Platform habilitada para Places API e outra do Gemini API. O segredo está em descrever bem as tools e manter o prompt de sistema enxuto e determinístico.
3. Quais idiomas o Ask Maps aceita hoje?
Conforme reportado pelo Eurisko.com.br, no Brasil o rollout está acontecendo em português. A expansão global atinge 150+ países, mas a qualidade da resposta varia conforme a maturidade do modelo em cada idioma. Em japonês e coreano costuma chegar mais redondo do que em idiomas com menos dados de treino.
4. O Ask Maps substitui a busca tradicional do Maps?
Não, as duas convivem. Você ainda pode digitar “farmácia 24h” e receber a lista clássica. O Ask Maps entra quando a intenção é ambígua, conversacional ou envolve múltiplos critérios combinados.
5. Vale a pena usar Gemini em produção para localização?
Depende do caso. Para UI conversacional rica, sim — o custo-benefício do gemini-2.5-flash é imbatível. Para fluxos críticos que exigem latência sub-200ms, eu testaria um classificador pequeno antes, para acionar o Gemini só quando realmente precisar.
O que isso significa para o seu próximo projeto
Se você está tocando um produto que envolve lugar — delivery, turismo, mobilidade, real estate, qualquer um — essa virada do Google é um sinal claro de que interface conversacional vai virar padrão. Não como diferencial, e sim como tabela. Na minha experiência, o melhor caminho é começar pequeno: um endpoint só com Places + Gemini, testado com usuários reais, e ir apertando o cinto de custo e latência à medida que o tráfego cresce.
E o detalhe que quase ninguém menciona: quando o seu usuário descobre lugar pelo Ask Maps dentro do Google, você perde a relação direta com ele. Se lugar é core do seu negócio, depender exclusivamente do Google para descoberta é perigoso. Seu próprio app precisa de uma camada conversacional equivalente — não para competir com o Ask Maps em escala, mas para reter contexto, marca e dados de primeira parte.
No fim das contas, a expansão global do Ask Maps é menos sobre o Maps e mais sobre o quanto o Gemini está virando a camada de raciocínio padrão dentro de toda a suíte do Google. Quem programa para web já sentiu esse cheiro com os AI Overviews. Quem programa para mobile vai sentir agora. Hora de ajustar a stack antes que vire dívida técnica.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.