Assistente de orientação com IA para espaços e recintos

Um assistente de IA para localização interpreta uma solicitação de navegação em linguagem natural, determina um destino a partir de registros confiáveis ​​do local e coordena o mapa ou a rota sem tratar a descoberta, o roteamento e o posicionamento como uma única capacidade. Um visitante pode perguntar qual entrada usar, como chegar ao Hall B ou onde fica o banheiro acessível mais próximo. O modelo de linguagem pode recuperar esses campos como intenções inspecionáveis; O sistema de localização, o mecanismo de roteamento e qualquer infraestrutura de posicionamento permanecem como fontes de referência para geometria, conectividade, acesso e localização em tempo real.

As seções abaixo abordam resolução de destino, conectividade interna, acessibilidade e filtros de acesso, fontes de origem, estado de localização compartilhada, adequação pública atual do Kaleidr, medição e modos de falha. Leituras relacionadas incluem Mapa de IA para Eventos, Como Criar um Assistente de IA com Conhecimento de Mapas, Mapas de Experiência do Cliente com Inteligência de Localização, Concierge de IA para Hotéis e Dados de Localização Privados para Fluxos de Trabalho de Mapas de IA.

Fundamentos da navegação por IA

• Descoberta não é roteamento: Resolver o Hall B não é o mesmo que calcular um caminho conectado até o Hall B.
• Roteamento não é posicionamento: Uma rota válida pode existir antes que o produto saiba onde o visitante está.
• Uma imagem da planta baixa não é uma rede: A orientação em ambientes internos precisa da topologia entre espaços, portas, corredores e transições de piso.
• Acessibilidade e acesso são filtros rígidos: Escadas, corredores de funcionários e bordas fechadas devem sair do grafo, e não apenas ter uma pontuação menor.
• O modelo de linguagem interpreta a intenção: Sistemas geoespaciais e de localização calculam rotas; o host valida as ações do mapa.

O que é um assistente de navegação por IA?

Um assistente de IA para localização é uma camada voltada para o cliente que responde para onde uma pessoa deve ir em um local complexo e como ela deve chegar lá, usando conversação, contexto do mapa e dados de localização confiáveis. Uma busca comum pode retornar o nome de uma sala. Um pôster estático pode mostrar um desenho do edifício. Nenhum deles codifica a origem, o andar, a elegibilidade para ingressos, a acessibilidade, os fechamentos em tempo real e a rota exibida no momento como um único estado inspecionável. Salas de conferência, campi universitários, hospitais, aeroportos, resorts e shoppings geram essa solicitação complexa a cada poucos minutos. O produto útil mantém o destino, a rota e o andar visíveis no mapa, em vez de deixar o visitante reconstruí-los a partir de placas, PDFs e um painel de bate-papo que não permite mover a câmera.

A página de IA Espacial da Kaleidr lista o Navegar entre as experiências de mapa e descreve rotas que se adequam à forma como um usuário se desloca (AI Map Chat for Customer Discovery). Essa página é uma referência sobre o posicionamento da Kaleidr em relação à navegação externa e voltada para viagens. A orientação passo a passo em ambientes internos é um contrato diferente: inteligência de destino, uma rede roteável e, somente quando a implementação de fato a possui, um sistema de posicionamento. A inteligência de localização voltada para o cliente ainda usa Descobrir → Comparar → Agir. Descobrir recupera um destino elegível. Comparar torna o andar, o relacionamento de viagem, a acessibilidade e o acesso inspecionáveis. Agir é um destaque, uma troca de andar, uma solicitação de rota onde o roteamento existe ou uma transferência de responsabilidade para a equipe.

A tarefa deve ser escrita antes da pilha de tarefas. Um visitante de um local pode precisar da entrada mais próxima de um assento. Um participante de uma conferência pode precisar de um caminho do auditório atual para a próxima sessão. Um passageiro de aeroporto pode precisar de um lounge elegível perto de um portão de embarque. Um usuário de um campus pode precisar da entrada do prédio mais próxima de uma sala de aula. Um visitante de um hospital pode precisar de imagens da entrada principal. Cada tarefa altera os candidatos, as restrições rígidas, as transições verticais e a necessidade de posicionamento em tempo real. Começar com "navegação interna por IA" colapsa essas diferenças e convida a uma alegação de produto que o local não pode suportar.

Por que a Descoberta, o Roteamento e o Posicionamento Devem Permanecer Separados?

A descoberta de destino responde qual local é relevante. O cálculo de rota responde qual caminho conectado um visitante elegível pode usar. O posicionamento responde onde o visitante está agora, em qual andar e, se o hardware suportar, para que lado o visitante está virado. As três camadas podem cooperar. Nenhuma substitui as outras. Uma imagem da planta baixa pode mostrar a Sala 204 e ainda assim não incluir conectividade de corredor, portas abertas, transições acessíveis, serviço de elevador para o andar de destino e uma origem confiável. Instruções passo a passo, como "vire à esquerda em dez metros", exigem tanto uma rota quanto uma posição em tempo real com precisão e orientação adequadas. O modelo de linguagem pode coordenar a solicitação. O modelo de linguagem não pode fornecer topologia ausente ou um ponto azul.

O modelo conceitual Open Geospatial Consortium 2.0 Parte 1 do IndoorGML é o esquema conceitual atual do OGC para redes de navegação interna. Os modelos padrão abrangem espaços e subdivisões espaciais, propriedades geométricas e semânticas, tipos de conectividade e redes de navegação lógicas e métricas (OGC IndoorGML 2.0 Part 1 – Conceptual Model, OGC 22-045r5, publicado em 26 de junho de 2025). Um produto de produção não precisa serializar o IndoorGML. O produto precisa respeitar a mesma distinção: geometria visual não é um grafo de navegação. O aviso de publicação de OGC de 28 de agosto de 2025 descreveu as codificações da Parte 2 de IndoorGML 2.0 como futuras (OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard). IndoorGML 1.1 permanece um padrão IndoorGML orientado à codificação publicado (IndoorGML 1.1, OGC 19-011r4, 5 de novembro de 2020). Cite a Parte 1 para o contrato conceitual; não trate uma codificação GML, JSON ou SQL IndoorGML 2.0 como um padrão de implementação publicado até que a Parte 2 exista como tal.

O Formato de Dados de Mapeamento Interno é um padrão comunitário complementar OGC para arquivos de localização interna usados ​​para orientação, navegação e descoberta, incluindo notas de modelagem para aeroportos, shoppings e estações de trem (Indoor Mapping Data Format, OGC 20-094, versão 1.0.0, publicada em 18 de fevereiro de 2021). A Parte 1 do IndoorGML 2.0 descreve o IMDF como fornecedor de um modelo abrangente a partir do qual os aplicativos podem derivar rotas, enquanto o IndoorGML visa uma abordagem unificada de grafo espacial. Para um assistente de IA para localização, a lição operacional é mais específica: dados estruturados de ambientes internos devem existir antes que a conversa prometa navegação.

A localização em ambientes externos costuma ser mais simples porque redes viárias ou de pedestres, APIs de roteamento e GNSS já existem. O assistente pode então geocodificar um destino, solicitar uma rota de um provedor e desenhar o resultado. Fluxos em campus internos e híbridos geralmente exigem infraestrutura adicional: estado do andar, transições verticais, bordas com controle de acesso e uma origem que pode não vir do navegador. Um caminho no campus pode conectar um trecho externo GNSS à entrada de um prédio e, em seguida, a um grafo interno. A camada conversacional pode explicar a transição. Os mecanismos de roteamento ainda são responsáveis ​​por cada trecho.

Como a resolução de destino deve funcionar antes do roteamento?

Roteamento para a string bruta “Hall B” é um defeito do produto. O aplicativo deve resolver um identificador de destino, prédio e andar estáveis ​​antes que o mecanismo de roteamento seja executado. Nomes de exibição colidem: Portão 12 e Entrada 12 são entidades de tipos diferentes. Identificadores de sala, cabine e sessão colidem na linguagem humana pelo mesmo motivo que o mapa de local de IA mantém a geometria separada da sobreposição de eventos. Registros digitados para edifícios, andares, entradas, salas, portões, cabines, banheiros, elevadores, escadas, zonas de estacionamento e balcões de atendimento mantêm a busca, o mapa, a rota, a acessibilidade e as análises sincronizadas quando os rótulos mudam.

{
  "destinationId": "hall_b",
  "buildingId": "expo_center",
  "floorId": "floor_1",
  "type": "hall"
}

A elegibilidade deve ser verificada na mesma etapa. Um lounge fisicamente conectado ainda pode ser proibido por classe de ingresso, zona de segurança ou designação de acesso exclusivo para funcionários. Os espaços candidatos devem passar por autorização e verificação de status operacional antes da comparação e explicação espacial. Polígonos restritos devem ser filtrados antes da recuperação, para que o modelo de linguagem nunca precise "lembrar" quais corredores são privados. OWASP’s LLM01:2025 Prompt Injection descreve como o texto do usuário ou recuperado pode alterar o comportamento do modelo, incluindo a influência sobre funções conectadas. A OWASP Top 10 for LLM Applications 2025 lista LLM06:2025 Excessive Agency: ações prejudiciais decorrentes de saídas inesperadas ou manipuladas do modelo quando um sistema recebe funcionalidades, permissões ou autonomia excessivas. Um assistente de localização deve sugerir um destino e uma ação permitida. O aplicativo host deve executar a solicitação de movimento da câmera, troca de andar ou rota após a validação do esquema, acesso e estado da rede.

A ambiguidade é um resultado desejável."Entrada principal", "entrada norte" e "entrada VIP" podem ser interpretações válidas. O produto deve perguntar, listar candidatos digitados no mapa ou exigir um toque em vez de adivinhar com base na similaridade da string. A busca direta de destino deve continuar funcionando mesmo quando a conversa falhar. Um visitante que digita Hall B não deve precisar de um diálogo. A pesquisa determinística, os filtros, o mapa e a conversa para perguntas compostas devem compartilhar os mesmos identificadores.

Por que o roteamento interno precisa de conectividade e não de uma imagem de planta baixa?

A pesquisa de local destaca uma geometria. O roteamento interno calcula em um grafo conectado: sala para corredor para porta para escada ou elevador para outro andar. Os polígonos de exibição e os nós de roteamento podem ser separados propositalmente. Um polígono de sala pode se conectar a um nó de porta; as arestas do corredor carregam o trajeto; as arestas do elevador e da escada carregam a mudança de andar, a acessibilidade e o status operacional. Uma planta baixa rasterizada com uma polilinha decorativa não representa esse grafo. O guia de mapa do local traça a mesma linha entre mostrar uma sala e reivindicar um caminho passo a passo.

O estado de um local com vários andares precisa ser explícito. A origem e o destino devem conter identificadores de prédio e andar. A interface do usuário deve mostrar quando uma rota muda de andar, em vez de ocultar a transição em uma única linha 2D. As arestas verticais precisam de atributos tipados: escadas, elevadores, escadas rolantes, rampas, acessibilidade, andares atendidos e status (aberto ou fechado). O mecanismo de roteamento usa esses atributos. O modelo de linguagem pode explicá-los depois que o mecanismo retornar etapas estruturadas. O fluxo preferencial é: mecanismo de roteamento para etapas estruturadas e, em seguida, para uma redação mais clara, e não a invenção livre de direções. Instruções relativas a pontos de referência, como "continue em direção ao saguão central e, em seguida, use o elevador leste", permanecem utilizáveis ​​quando a direção da bússola não estiver disponível.

Fechamentos temporários são registros operacionais, não decoração cartográfica. Uma falha em uma escada rolante, um corredor bloqueado, uma entrada fechada, um andar restrito ou uma falha em um elevador devem marcar uma aresta como fechada e forçar um novo cálculo. A explicação que o visitante lê deve refletir a versão atual da rota. Geometria desatualizada, desenhada em prosa conversacional, é uma questão de segurança em locais reais, não um problema de cópia. O recálculo de rotas é responsabilidade do mecanismo: quando a origem muda ou uma aresta é fechada, a rota anterior torna-se inválida e uma nova rota é calculada. Pedir ao modelo de linguagem para corrigir coordenadas é a superfície de controle errada.

Como a acessibilidade, as regras de acesso e os fechamentos filtram as rotas?

A acessibilidade exigida é uma restrição rígida de roteamento. Se o visitante solicitar uma rota acessível, as arestas das escadas podem ser excluídas. Um caminho totalmente acessível pode exigir deslocamento sem degraus, um elevador funcionando, uma entrada acessível e largura da porta que o local tenha de fato registrado. Incorporar a acessibilidade a um peso de preferência flexível ainda pode classificar um caminho inacessível em primeiro lugar. A falta de dados de acessibilidade não é uma licença para inventar uma rota totalmente acessível. Quando o sistema conhece apenas uma entrada e um elevador acessíveis, a afirmação honesta é que esses recursos são mostrados no mapa, não que um caminho totalmente acessível tenha sido certificado. As obrigações legais de acessibilidade continuam sendo uma decisão para um advogado qualificado e o operador do local; Esta postagem descreve o contrato de dados.

A conectividade física é apenas um dos eixos de elegibilidade. Corredores de funcionários, portões VIP, zonas de segurança, áreas com ingressos e entradas de funcionários podem ser transitáveis ​​no grafo e ainda assim proibidos para este visitante. A elegibilidade da rota é a conectividade física mais a permissão de acesso mais o status operacional. Caminhos restritos nunca devem chegar à camada conversacional antes que o controle de acesso seja aplicado. A sequência segura é autenticar, determinar o acesso, recuperar os espaços permitidos, calcular uma rota permitida e, em seguida, explicar. Calcular um caminho por todos os espaços e ocultar as etapas restritas posteriormente revela a topologia. Autenticação da API do mapa abrange chaves publicáveis ​​versus chaves de servidor para as superfícies Kaleidr que conectam a conversa a um mapa host; as regras de acesso ao local ainda residem nos sistemas de identidade e ingressos do host.

O roteamento de emergência e segurança é de alto risco. Um assistente generativo não deve inventar rotas de evacuação, procedimentos de emergência ou orientações de segurança restritas a partir de conhecimento genérico de modelos. Utilize conteúdo de emergência aprovado pelo local, planos oficiais, funcionários em tempo real e alertas operacionais. Um produto de orientação pode exibir locais de primeiros socorros ou saídas aprovados quando esses registros forem confiáveis. Roteamento de alto risco pertence ao sistema operacional projetado para essa função.

Quando o Sistema de Orientação Precisa de Posicionamento e Quando Não Precisa?

Toda rota precisa de uma origem. As origens podem vir de uma seleção explícita no mapa, um ponto de referência conhecido, como a entrada principal, uma área informada por último ("Estou no Hall A"), a localização de um dispositivo externo ou a infraestrutura de posicionamento interno. A origem manual deve permanecer disponível mesmo quando o posicionamento automático existir. Confiança é dado. Um relatório de posicionamento preciso a poucos metros pode fornecer orientação em escala de corredor. Um relatório com incerteza de dezenas de metros em ambientes internos pode selecionar o corredor ou andar errado. O produto deve ser capaz de informar que a localização interna é incerta e pedir ao visitante que selecione a área atual. Roteamento baseado em confiança a partir de uma origem imprecisa é pior do que um breve esclarecimento. A especificação W3C Geolocation, um Snapshot de Recomendação Candidata datado de 26 de março de 2026, fornece acesso à localização do dispositivo somente após permissão expressa e afirma que a API não garante a localização real do dispositivo. Uma correção de localização do navegador não é um ponto azul em ambientes internos. Beacons Bluetooth, posicionamento Wi-Fi, posicionamento visual ultra-wideband e sistemas específicos do local são infraestrutura, não um recurso do modelo de linguagem. A orientação é um requisito adicional para instruções de "vire à esquerda". Um mapa ainda pode mostrar uma rota correta sem direção. Quando a direção não estiver disponível, a descrição de pontos de referência ou palavras relativas ao mapa devem substituir as indicações da bússola.

Muitos locais podem fornecer informações úteis de localização sem rastreamento contínuo em ambientes internos. O visitante seleciona um ponto de referência, o mecanismo retorna uma rota, etapas estáticas permanecem no mapa e o visitante avança manualmente. Conferências, campi universitários, resorts e museus muitas vezes precisam desse padrão mais do que de um ponto azul em tempo real. O padrão também reduz a privacidade e os custos de infraestrutura. O sistema de localização pode criar um histórico de movimento detalhado: localização interna atual, rota, destinos repetidos, local de trabalho, departamento médico ou participação em eventos. O NIST Privacy Framework (NIST.CSWP.01162020, 16 de janeiro de 2020) trata a privacidade como gerenciamento de risco corporativo: identificar o que é coletado, por que e por quanto tempo. Preferir contexto temporário de origem, destino e rota em vez de um perfil de movimento persistente. Dados de localização privados para fluxos de trabalho de mapas com IA abrange o mesmo limite de propriedade do host.

Como o sistema de localização conversacional deve compartilhar o estado com o mapa?

A interação por meio de conversas torna-se útil depois que um destino ou rota já estiver no mapa. Ações subsequentes, como a localização de um banheiro ao longo do caminho atual, uma solicitação para evitar escadas ou uma entrada mais próxima da origem selecionada, dependem de um estado compartilhado, e não de uma segunda lista de resultados não oficial. Mapa, lista, instruções e chat devem utilizar um único registro de localização: origem, destino, andar ativo, identificador da rota, versão da rota, modo de acessibilidade e confiabilidade da posição quando um sistema de posicionamento estiver presente. Selecionar um destino pode exibir uma rota. Alterar o modo de acessibilidade pode invalidar a versão atual e solicitar um novo cálculo. Os resultados do assistente devem aparecer no mesmo mapa que o visitante já está utilizando.

{
  "routeId": "route_north_to_hall_b",
  "originId": "entrance_north",
  "destinationId": "hall_b",
  "mode": "accessible",
  "activeFloorId": "floor_1",
  "routeVersion": 4
}

As ações semânticas devem ser concisas: definir origem, focar no destino, exibir rota, trocar de andar, destacar uma transição, abrir um registro de destino, limpar rota, solicitar um novo cálculo de rota. O host valida cada payload em relação aos identificadores, acesso e versão de rede atuais antes da execução do adaptador de renderização. O mapa arbitrário JavaScript não é um contrato de controle. As permissões para essas ações pertencem ao aplicativo e à infraestrutura, nunca ao modelo de linguagem. O guia assistente com reconhecimento de mapa abrange o estado do mapa compartilhado e as ações validadas para essa transferência.

As atualizações operacionais devem versionar tanto a rede quanto a rota. O fechamento de um elevador pode invalidar a versão 4 da rota na versão 18 da rede e exigir a versão 5. O versionamento torna as orientações desatualizadas depuráveis. A validação antes de aplicar uma rota deve confirmar se a origem, o destino, a permissão, a atualização da rota, os fechamentos e o modo de viagem ainda correspondem. O estado de localização muda rapidamente em locais em funcionamento. Conectividade offline ou fraca também é normal em ambientes internos. Armazene em cache a geometria do local, os rótulos, o último andar e a última rota válida, quando apropriado. A busca direta de locais deve funcionar mesmo se a camada conversacional falhar. Os KPIs do painel de análise espacial pertencem à medição do produto, não à avaliação do volume de chats como indicador de sucesso.

Como Kaleidr se encaixa em uma pilha de navegação existente?

A documentação atual para desenvolvedores de Kaleidr posiciona o Chat como uma camada conversacional anexada a um mapa que o host já executa. O Quickstart mostra a integração do Chat a uma instância ativa de Mapbox, MapLibre, Google Maps ou Leaflet. Chat attach descreve a Torre de Controle como navegação orientada por chat, resumos de locais e marcadores de locais sobre o mapa do host. As chaves publicáveis ​​são vinculadas à origem para o navegador; as chaves do servidor permanecem fora da página (Auth & Scopes). Os snippets devem usar um marcador de posição óbvio em vez de uma chave com formato dinâmico.

const handle = Kaleidr.mount("#chat", {
  product: "chat",
  publishableKey: "YOUR_PUBLISHABLE_KEY",
  map: myMap,
});

Essas superfícies suportam descoberta de destinos em linguagem natural, conversas com reconhecimento de mapas, respostas sobre locais, marcadores em tempo real e atualizações de câmeras. O host continua sendo responsável pelo renderizador, dados do local, mecanismo de rotas, topologia interna, posicionamento e controle de acesso. A documentação pública do Kaleidr descreve o chat de mapas com IA, mapas publicados, mapas base projetados e edição de mapas. Essa documentação não inclui, atualmente, um mecanismo de posicionamento interno dedicado ou um produto especializado de navegação interna passo a passo. Portanto, uma arquitetura correta consiste em interação conversacional e com reconhecimento de mapas no Kaleidr, com roteamento ou posicionamento interno especializado permanecendo no sistema de navegação ou do local quando a implementação exigir. O Location Intelligence APIs and Map SDK é a superfície comercial atual para APIs de inferência, sistemas de classificação, análises e suporte à implementação. Classificação e roteamento interno ainda são produtos diferentes; não codifique uma rota de navegação interna fictícia a partir da linguagem de marketing.

Locais híbridos ainda se encaixam nessa divisão. Trechos externos podem usar um provedor de roteamento. Percursos internos podem usar um grafo do local. Sobreposições de eventos podem alterar estandes e sessões sem reconstruir paredes, como descrito no artigo sobre mapas de locais. Solicitações para hospitais e aeroportos geralmente falham primeiro na identificação e acesso ao destino, não no desenho do caminho: “imagem” e “o lounge que posso usar perto do Portão 42” são problemas de elegibilidade antes de serem problemas de geometria. O modelo de linguagem pode interpretar a solicitação. Dados comerciais autorizados e serviços geoespaciais ainda fornecem as informações.

Como as equipes devem avaliar um assistente de IA para navegação?

Meça a tarefa de localização, não o volume de conversas. A taxa de resolução de destino, a taxa de não resultado, o sucesso da rota, as correções de andar errado, a taxa de redirecionamento, as negações de acesso, o tempo para uma rota de retorno, a confirmação de destino e o abandono de rota descrevem se os visitantes realmente chegam a algum lugar. Se o posicionamento estiver presente, adicione eventos de desvio de rota, falhas de confiança de localização e falhas de detecção de andar. Mantenha a descoberta separada da navegação: um destino resolvido com uma rota falha é um defeito diferente de uma pesquisa falha. Nomes de eventos editoriais, como destino resolvido, rota solicitada, rota falhou, andar alterado e redirecionamento, são análises de produto, não eventos automáticos documentados Kaleidr Analytics.

A avaliação deve incluir ambiguidade, caminhos entre andares, arestas fechadas, acesso restrito, dados de acessibilidade ausentes e fallback para baixa conectividade. Teste se o mapa, a lista e as etapas faladas ou escritas mostram a mesma versão da rota. A latência deve ser atribuída por etapa; equipes que culpam a "IA" geralmente descobrem que o roteamento ou a resolução de origem são os principais fatores. A conclusão da tarefa é mais importante do que a contagem de interações. Um visitante que encontra o Hall B por meio de busca, sem usar o chat, obteve sucesso. Uma longa conversa que termina no andar errado, não.

Quais modos de falha os produtos de orientação devem evitar?

A falha recorrente é a fusão de três sistemas em um único parágrafo gerado. Uma imagem da planta baixa é tratada como um roteador. O modelo de linguagem é tratado como um sistema de posicionamento. Os andares desaparecem. A acessibilidade se torna um peso de preferência. Arestas restritas vazam. A descrição passo a passo aparece sem orientação. A conversa se torna obrigatória. O histórico de movimento persiste por padrão. Cada linha abaixo representa um defeito do produto com uma correção concreta.

A navegação móvel precisa de alvos grandes, etapas legíveis e um mapa que permaneça utilizável quando o modelo ou uma rota complexa expirar. Armazenar em cache a geometria base. Degradar o enriquecimento de forma controlada. Preservar um caminho da busca digitada para destacar mesmo quando a conversa não estiver disponível.

Construindo uma Experiência de Navegação Conversacional

A arquitetura confiável é: intenção, resolução de destino, roteamento autorizado, cálculo de rota, explicação e uma ação de mapa validada. O posicionamento em ambientes internos é uma camada opcional adicionada posteriormente, somente quando o local opera um sistema adequado. Kaleidr pode conectar IA espacial conversacional ao mapa que um host já executa, enquanto a topologia do local e roteadores especializados permanecem como autoridade onde a verdadeira navegação em ambientes internos é necessária.

Explore o Kaleidr Enterprise para conhecer as APIs, as interfaces de SDK e o suporte à implantação atuais. Antes de definir um caminho de integração, consulte os padrões de conexão e os tipos de chave na documentação para desenvolvedores da Kaleidr.

Perguntas frequentes

O que é um assistente de IA para localização?

Um assistente de IA para localização interpreta perguntas de navegação em linguagem natural, determina o destino pretendido a partir de registros confiáveis ​​e coordena o mapa ou a orientação da rota. Roteamento e posicionamento permanecem sistemas separados.

A localização por IA é a mesma coisa que a navegação em ambientes internos?

Não. A conversação pode interpretar uma solicitação de navegação. A navegação em ambientes internos também requer uma rede de roteamento estruturada e pode exigir posicionamento em ambientes internos.

Uma imagem de planta baixa pode ser usada para roteamento passo a passo?

Não sozinha. O roteamento confiável requer conectividade entre espaços, portas, corredores, escadas, elevadores e outras transições.

O que é IndoorGML?

IndoorGML é um padrão OGC para dados espaciais e de navegação em ambientes internos. IndoorGML 2.0 Parte 1 é o modelo conceitual atual para espaços, conectividade e redes de navegação (OGC 22-045r5). OGC descreveu os esquemas de codificação IndoorGML 2.0 como futuros a partir de agosto de 2025; IndoorGML 1.1 permanece como uma versão publicada orientada à codificação.

O que é IMDF?

O Formato de Dados de Mapeamento Interno é um Padrão da Comunidade OGC (OGC 20-094, versão 1.0.0) para arquivos de localização em ambientes internos usados ​​para orientação, navegação e descoberta.

O Kaleidr oferece posicionamento interno atualmente?

A documentação pública atual do Kaleidr descreve IA espacial, bate-papo por mapa, mapas personalizados, publicação e integração com mapas existentes. Ela não documenta um sistema de posicionamento interno dedicado; portanto, o posicionamento interno deve ser tratado como um recurso de implantação separado, a menos que o host integre um.

O Kaleidr funciona com um mapa interno?

O Kaleidr pode integrar IA conversacional a implementações de mapas existentes compatíveis. O aplicativo host continua responsável pelos dados do mapa, pela rede de rotas e por qualquer posicionamento interno.

Como deve funcionar a navegação acessível?

Os requisitos de acessibilidade devem ser codificados como restrições de rota rígidas usando dados de locais verificados. O assistente não deve inventar uma rota acessível a partir de informações incompletas.

Um assistente de mapa com IA pode recalcular a rota de um visitante?

O assistente pode solicitar ou explicar uma nova rota. O mecanismo de roteamento autoritativo deve recalcular usando as condições de rede e as regras de acesso atuais.

O sistema de navegação deve rastrear a localização do usuário continuamente?

Somente quando o produto precisar e o usuário tiver o aviso ou consentimento apropriado. Muitas tarefas de navegação podem funcionar com uma origem ou ponto de referência selecionado sem rastreamento persistente.

Referências

• Kaleidr. AI Map Chat for Customer Discovery. Accessed 27 August 2026. https://kaleidr.com/ai
• Kaleidr. Auth & Scopes. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
• Kaleidr. Chat attach. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/sdk/chat-attach
• Kaleidr. Introduction. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/
• Kaleidr. Location Intelligence APIs and Map SDK. Accessed 27 August 2026. https://kaleidr.com/enterprise
• Kaleidr. Quickstart. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/quickstart
• National Institute of Standards and Technology. NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0. NIST.CSWP.01162020. 16 January 2020. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf
• Open Geospatial Consortium. IndoorGML 1.1. OGC 19-011r4. 5 November 2020. https://docs.ogc.org/is/19-011r4/19-011r4.html
• Open Geospatial Consortium. Indoor Mapping Data Format. OGC 20-094. Version 1.0.0. 18 February 2021. https://docs.ogc.org/cs/20-094/index.html
• Open Geospatial Consortium. OGC IndoorGML 2.0 Part 1 – Conceptual Model. OGC 22-045r5. 26 June 2025. https://docs.ogc.org/is/22-045r5/22-045r5.html
• Open Geospatial Consortium. OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard. 28 August 2025. Accessed 27 August 2026. https://www.ogc.org/announcement/ogc-publishes-indoorgml-2-0-part-1-conceptual-model-standard/
• OWASP Gen AI Security Project. LLM01:2025 Prompt Injection. Accessed 27 August 2026. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• OWASP Gen AI Security Project. OWASP Top 10 for LLM Applications 2025. Accessed 27 August 2026. https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf
• W3C. Geolocation. W3C Candidate Recommendation Snapshot, 26 March 2026. Accessed 27 August 2026. https://www.w3.org/TR/geolocation/

@misc{kaleidr_wayfinding_ai_2026_08_27,
  title  = {AI Map Chat for Customer Discovery},
  author = {{Kaleidr}},
  note   = {Accessed 27 August 2026},
  url    = {https://kaleidr.com/ai}
}

@misc{kaleidr_auth_scopes_2026_08_27,
  title  = {Auth \& Scopes},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}

@misc{kaleidr_chat_attach_2026_08_27,
  title  = {Chat attach},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/sdk/chat-attach}
}

@misc{kaleidr_docs_intro_2026_08_27,
  title  = {Introduction},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/}
}

@misc{kaleidr_enterprise_wayfinding_2026_08_27,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  note   = {Accessed 27 August 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{kaleidr_quickstart_wayfinding_2026_08_27,
  title  = {Quickstart},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/quickstart}
}

@techreport{nist_privacy_framework_2020,
  title       = {NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0},
  author      = {{National Institute of Standards and Technology}},
  number      = {NIST.CSWP.01162020},
  institution = {National Institute of Standards and Technology},
  year        = {2020},
  month       = jan,
  url         = {https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf}
}

@techreport{ogc_indoorgml_1_1,
  title       = {IndoorGML 1.1},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 19-011r4},
  institution = {Open Geospatial Consortium},
  year        = {2020},
  month       = nov,
  url         = {https://docs.ogc.org/is/19-011r4/19-011r4.html}
}

@techreport{ogc_imdf_1_0_0,
  title       = {Indoor Mapping Data Format},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 20-094},
  institution = {Open Geospatial Consortium},
  year        = {2021},
  month       = feb,
  note        = {OGC Community Standard, version 1.0.0},
  url         = {https://docs.ogc.org/cs/20-094/index.html}
}

@techreport{ogc_indoorgml_2_0_part1,
  title       = {OGC IndoorGML 2.0 Part 1 – Conceptual Model},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 22-045r5},
  institution = {Open Geospatial Consortium},
  year        = {2025},
  month       = jun,
  url         = {https://docs.ogc.org/is/22-045r5/22-045r5.html}
}

@misc{ogc_indoorgml_2_0_announcement_2025_08_28,
  title  = {OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard},
  author = {{Open Geospatial Consortium}},
  year   = {2025},
  month  = aug,
  note   = {Accessed 27 August 2026},
  url    = {https://www.ogc.org/announcement/ogc-publishes-indoorgml-2-0-part-1-conceptual-model-standard/}
}

@misc{owasp_llm01_prompt_injection_2025,
  title  = {LLM01:2025 Prompt Injection},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 27 August 2026},
  url    = {https://genai.owasp.org/llmrisk/llm01-prompt-injection/}
}

@misc{owasp_llm_top10_2025,
  title  = {OWASP Top 10 for LLM Applications 2025},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 27 August 2026},
  url    = {https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf}
}

@misc{w3c_geolocation_2026_03_26,
  title  = {Geolocation},
  author = {{W3C}},
  note   = {W3C Candidate Recommendation Snapshot, 26 March 2026; accessed 27 August 2026},
  url    = {https://www.w3.org/TR/geolocation/}
}