Asistente de orientación con IA para recintos

Un asistente de orientación con IA interpreta una solicitud de navegación en lenguaje natural, determina un destino a partir de registros de lugares confiables y proporciona una guía de ruta o de coordenadas sin tratar el descubrimiento, el enrutamiento y el posicionamiento como una sola función. Un visitante puede preguntar qué entrada usar, cómo llegar al Pabellón B o dónde se encuentra el baño accesible más cercano. El modelo de lenguaje puede recuperar esos campos como intención inspeccionable; El sistema del recinto, el motor de enrutamiento y cualquier infraestructura de posicionamiento siguen siendo la fuente principal de información sobre geometría, conectividad, acceso y ubicación en tiempo real.

Las secciones siguientes abarcan la resolución de destinos, la conectividad en interiores, la accesibilidad y los filtros de acceso, las fuentes de origen, el estado de la navegación compartida, la compatibilidad pública actual de Kaleidr, la medición y los modos de fallo. Entre las lecturas relacionadas se incluyen Mapa de recintos con IA para eventos, Cómo crear un asistente de IA con reconocimiento de mapas, Mapas de experiencia del cliente con inteligencia de ubicación, Conserje de huéspedes con IA para hoteles y Datos de ubicación privados para flujos de trabajo de mapas con IA.

Fundamentos de la IA para la orientación espacial

• Descubrir no es lo mismo que calcular una ruta: Resolver la ubicación del Pabellón B no es lo mismo que calcular una ruta conectada al Pabellón B.
• Calcular rutas no es lo mismo que posicionar: Puede existir una ruta válida antes de que el sistema sepa dónde se encuentra el visitante.
• Un plano de planta no es una red: La orientación en interiores requiere información topológica sobre los espacios, puertas, pasillos y transiciones entre plantas.
• La accesibilidad y el acceso son filtros estrictos: Las escaleras, los pasillos del personal y los bordes cerrados deben salir del grafo, no solo tener una puntuación más baja.
• El modelo de lenguaje interpreta la intención: Los sistemas geoespaciales y del lugar calculan las rutas; el sistema valida las acciones del mapa.

¿Qué es un asistente de IA para la orientación espacial?

Un asistente de orientación con IA es una capa de interfaz de usuario que indica a dónde debe ir una persona en un lugar complejo y cómo debe desplazarse hasta allí, utilizando conversación, contexto del mapa y datos de ubicación fiables. Una búsqueda convencional puede devolver el nombre de una sala. Un póster estático puede mostrar un dibujo del edificio. Ninguno de estos métodos codifica el origen, la planta, la validez de las entradas, la accesibilidad, los cierres en tiempo real y la ruta actual como un único estado consultable. Salas de conferencias, campus universitarios, hospitales, aeropuertos, complejos turísticos y centros comerciales generan esta solicitud compleja cada pocos minutos. El producto útil mantiene el destino, la ruta y la planta visibles en el mapa, en lugar de dejar que el visitante tenga que reconstruirlos a partir de la señalización, archivos PDF y un panel de chat que no permite mover la cámara.

La página de IA espacial de Kaleidr incluye Navegar entre las experiencias de mapa y describe rutas que se ajustan a la forma en que se desplaza el usuario (AI Map Chat for Customer Discovery). Esta página es la fuente de información principal sobre el posicionamiento de navegación para exteriores y viajes de KaleidrLa guía paso a paso en interiores es un contrato diferente: inteligencia de destino, una red enrutable y, solo cuando la implementación lo incluye, un sistema de posicionamiento. La inteligencia de ubicación orientada al cliente sigue utilizando Descubrir → Comparar → Actuar. Descubrir recupera un destino elegible. Comparar permite inspeccionar el piso, la relación de viaje, la accesibilidad y el acceso. Actuar es un resaltado, un cambio de piso, una solicitud de ruta cuando existe enrutamiento o un traspaso de personal.

El trabajo debe definirse antes de la pila de tareas. Un visitante de un recinto puede necesitar la entrada más cercana a su asiento. Un asistente a una conferencia puede necesitar un camino desde la sala actual hasta la siguiente sesión. Un pasajero de aeropuerto puede necesitar una sala VIP cerca de una puerta de embarque. Un usuario del campus puede necesitar la entrada del edificio más cercana a un aula. Un visitante de un hospital puede necesitar imágenes desde la entrada principal. Cada tarea modifica los candidatos, las restricciones, las transiciones verticales y la necesidad de posicionamiento en tiempo real. Partir de la "navegación con IA en interiores" simplifica estas diferencias y conlleva una afirmación sobre el producto que el recinto no puede cumplir.

¿Por qué deben mantenerse separados el descubrimiento, el enrutamiento y el posicionamiento?

El descubrimiento de destino determina qué lugar es relevante. El cálculo de ruta determina qué camino conectado puede usar un visitante elegible. El posicionamiento determina dónde se encuentra el visitante, en qué piso y, si el hardware lo permite, hacia dónde mira. Las tres capas pueden cooperar. Ninguna sustituye a las demás. Una imagen del plano de planta puede mostrar la Sala 204 y aun así carecer de conectividad de pasillos, puertas abiertas, transiciones accesibles, servicio de ascensor al piso de destino y un origen fiable. Las instrucciones paso a paso, como «gire a la izquierda en diez metros», requieren tanto una ruta como una posición en tiempo real con precisión y orientación útiles. El modelo de lenguaje puede coordinar la solicitud. Sin embargo, no puede proporcionar información sobre la topología faltante ni un punto azul.

El modelo conceptual Open Geospatial Consortium 2.0 Parte 1 de IndoorGML es el esquema conceptual OGC actual para redes de navegación en interiores. El estándar modela espacios y subdivisiones espaciales, propiedades geométricas y semánticas, tipos de conectividad y redes de navegación lógicas y métricas (OGC IndoorGML 2.0 Part 1 – Conceptual Model, OGC 22-045r5, publicado el 26 de junio de 2025). Un producto de producción no tiene que serializar IndoorGML. El producto sí debe respetar la misma distinción: la geometría visual no es un grafo de navegación. El aviso de publicación de OGC del 28 de agosto de 2025 describió las codificaciones de IndoorGML 2.0 Parte 2 como próximas (OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard). IndoorGML 1.1 sigue siendo un estándar IndoorGML publicado orientado a la codificación (IndoorGML 1.1, OGC 19-011r4, 5 de noviembre de 2020). Cite la Parte 1 para el contrato conceptual; no considere una codificación GML, JSON o SQL IndoorGML 2.0 como un estándar de implementación publicado hasta que la Parte 2 exista como tal.

El formato de datos de mapeo de interiores (Interior Mapping Data Format) es un estándar comunitario complementario OGC para archivos de ubicación en interiores utilizados para orientación, navegación y descubrimiento, incluyendo notas de modelado para aeropuertos, centros comerciales y estaciones de tren (Indoor Mapping Data Format, OGC 20-094, versión 1.0.0, publicado el 18 de febrero de 2021). La versión 2.0 Parte 1 de IndoorGML describe IMDF como un modelo integral a partir del cual las aplicaciones pueden derivar rutas, mientras que IndoorGML busca un enfoque unificado de grafo espacial. Para un asistente de IA de orientación, la lección operativa es más específica: los datos estructurados de interiores deben existir antes de que la conversación prometa navegación.

La orientación en exteriores suele ser más sencilla porque ya existen redes de carreteras o peatonales, API de enrutamiento y GNSS. El asistente puede entonces geocodificar un destino, solicitar una ruta a un proveedor y dibujar el resultado. Los flujos en campus interiores e híbridos suelen requerir infraestructura adicional: estado de planta, transiciones verticales, bordes con control de acceso y un origen que puede no provenir del navegador. Una ruta en el campus puede conectar un tramo exterior GNSS con la entrada de un edificio y, posteriormente, con un gráfico interior. La capa conversacional puede explicar la transición. Los motores de enrutamiento siguen gestionando cada tramo.

¿Cómo debería funcionar la resolución de destino antes del enrutamiento?

Enrutar a la cadena de texto sin formato «Pabellón B» es un defecto del producto. La aplicación debería resolver un identificador de destino, edificio y planta estables antes de que se ejecute el motor de enrutamiento. Los nombres para mostrar se superponen: Puerta 12 y Entrada 12 son entidades de tipos diferentes. Los identificadores de sala, cabina y sesión se superponen en el lenguaje natural por la misma razón que el mapa de eventos con IA mantiene la geometría separada de la superposición de eventos. Los registros tipográficos de edificios, pisos, entradas, habitaciones, puertas, cabinas, baños, ascensores, escaleras, zonas de estacionamiento y mostradores de servicio mantienen sincronizadas las búsquedas, los mapas, las rutas, la accesibilidad y los análisis cuando cambian las etiquetas.

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

La elegibilidad pertenece al mismo paso. Un salón físicamente conectado aún puede estar restringido por la clase de boleto, la zona de seguridad o la designación de acceso exclusivo para personal. Los espacios candidatos deben superar la autorización y el estado operativo antes de la comparación espacial y la explicación. Los polígonos restringidos deben filtrarse antes de la recuperación para que el modelo de lenguaje nunca tenga que "recordar" qué pasillos son privados. OWASP’s LLM01:2025 Prompt Injection describe cómo el texto del usuario o recuperado puede alterar el comportamiento del modelo, incluida la influencia sobre las funciones conectadas. OWASP Top 10 for LLM Applications 2025 enumera LLM06:2025 Excessive Agency: acciones perjudiciales derivadas de la salida inesperada o manipulada del modelo cuando se otorga a un sistema demasiada funcionalidad, permiso o autonomía. Un asistente de orientación debe proponer un destino y una acción permitida. La aplicación anfitriona debe ejecutar el movimiento de la cámara, el cambio de piso o la solicitud de ruta después de la validación del esquema, el acceso y el estado de la red.

La ambigüedad es un resultado de primera clase."Entrada principal", "Entrada norte" y "Entrada VIP" pueden ser análisis sintácticos válidos. El producto debería preguntar, mostrar los candidatos escritos en el mapa o requerir un toque en lugar de adivinar por similitud de texto. La búsqueda directa de destino debe seguir funcionando incluso si la conversación falla. Un visitante que escriba Hall B no debería necesitar un diálogo. La búsqueda determinista, los filtros, el mapa y la conversación para preguntas compuestas deben compartir los mismos identificadores.

¿Por qué el enrutamiento en interiores necesita conectividad, no un plano de planta?

La búsqueda de lugares resalta una geometría. El enrutamiento en interiores se calcula a través de un grafo conectado: de la habitación al pasillo, de la puerta a la escalera o al ascensor y a otra planta. Los polígonos de visualización y los nodos de enrutamiento pueden estar separados a propósito. Un polígono de habitación puede conectarse a un nodo de puerta; los bordes del pasillo indican el recorrido; los bordes del ascensor y la escalera indican el cambio de planta, la accesibilidad y el estado operativo. Un plano de planta rasterizado con una polilínea decorativa no es ese grafo. La guía del mapa del lugar establece la misma línea divisoria entre mostrar una habitación y proporcionar una ruta paso a paso.

El estado de las diferentes plantas debe ser explícito. El origen y el destino deben incluir identificadores de edificio y planta. La interfaz de usuario debe mostrar cuándo una ruta cambia de planta, en lugar de ocultar la transición dentro de una sola línea 2D. Los bordes verticales necesitan atributos tipados: escaleras, ascensores, escaleras mecánicas, rampas, accesibilidad, plantas atendidas y estado (abierto o cerrado). El motor de rutas utiliza estos atributos. El modelo de lenguaje puede explicarlos después de que el motor devuelva los pasos estructurados. El flujo preferido es del motor de rutas a los pasos estructurados y a una redacción más clara, en lugar de la invención libre de direcciones. Las instrucciones relativas a puntos de referencia, como «continúe hacia el vestíbulo central y luego use el ascensor este», siguen siendo útiles cuando no se dispone de la dirección de la brújula.

Los cierres temporales son registros operativos, no elementos cartográficos. Una avería en una escalera mecánica, un pasillo bloqueado, una entrada cerrada, una planta restringida o un fallo en un ascensor deben marcar un borde como cerrado y obligar a recalcularlo. La explicación que lee el visitante debe reflejar la versión actual de la ruta. La geometría obsoleta dibujada en prosa conversacional representa un problema de seguridad en espacios físicos, no un problema de copia. El reenrutamiento corresponde al motor: cuando cambia el origen o se cierra un borde, la ruta anterior deja de ser válida y se calcula una nueva. Solicitar al modelo de lenguaje que corrija las coordenadas es una superficie de control incorrecta.

¿Cómo filtran las rutas la accesibilidad, las reglas de acceso y los cierres?

La accesibilidad requerida es una restricción de enrutamiento estricta. Si el visitante solicita una ruta accesible, es posible que se excluyan los bordes de las escaleras. Un camino completamente accesible puede requerir un recorrido sin escalones, un ascensor en funcionamiento, una entrada accesible y un ancho de puerta que el lugar haya registrado. Incluir la accesibilidad en una ponderación de preferencia flexible aún puede dar prioridad a un camino inaccesible. La falta de datos de accesibilidad no justifica la invención de una ruta totalmente accesible. Cuando el sistema solo conoce una entrada accesible y un ascensor, lo correcto es indicar que esas características se muestran en el mapa, no que se haya certificado un camino completamente accesible. Las obligaciones legales en materia de accesibilidad siguen siendo una cuestión de criterio para un asesor legal cualificado y el operador del lugar. Esta publicación describe el contrato de datos.

La conectividad física es solo uno de los ejes de elegibilidad. Los pasillos del personal, las puertas VIP, las zonas de seguridad, las áreas con entrada y las entradas para empleados pueden ser transitables en el gráfico y aun así estar prohibidas para este visitante. La elegibilidad de la ruta se basa en la conectividad física, el permiso de acceso y el estado operativo. Las rutas restringidas nunca deben llegar a la capa conversacional antes de que se aplique el control de acceso. La secuencia segura es: autenticar, determinar el acceso, recuperar los espacios permitidos, calcular una ruta permitida y, finalmente, explicar. Calcular una ruta a través de todos los espacios y ocultar los pasos restringidos posteriormente filtra la topología. Autenticación de la API del mapa abarca las claves publicables frente a las claves del servidor para las superficies Kaleidr que vinculan la conversación a un mapa del host; las reglas de acceso al recinto siguen residiendo en los sistemas de identidad y venta de entradas del host.

El enrutamiento de emergencia y seguridad es de alto riesgo. Un asistente generativo no debe inventar rutas de evacuación, procedimientos de emergencia ni guías de seguridad restringidas a partir de modelos genéricos. Utilice información de emergencia aprobada por el lugar, planes oficiales, personal disponible y alertas operativas. Un sistema de orientación puede mostrar ubicaciones de primeros auxilios o salidas aprobadas cuando estos registros sean fidedignos. El enrutamiento en situaciones críticas corresponde al sistema operativo diseñado para tal fin.

¿Cuándo se necesita posicionamiento en la orientación y cuándo no?

Cada ruta necesita un origen. Los orígenes pueden provenir de la selección explícita de un mapa, un punto de referencia conocido como la entrada principal, la última ubicación indicada («Estoy en la Sala A»), la ubicación de un dispositivo exterior o la infraestructura de posicionamiento interior. El origen manual debe estar disponible incluso cuando exista posicionamiento automático. La fiabilidad se basa en los datos. Un informe de posicionamiento con una precisión de pocos metros puede servir de guía para pasillos. Un informe con una incertidumbre de decenas de metros en interiores puede seleccionar el pasillo o la planta equivocados. El sistema debe poder indicar que la ubicación interior es incierta y pedir al visitante que seleccione su área actual. Un enrutamiento fiable a partir de un origen erróneo es peor que una breve aclaración. La especificación W3C Geolocation, una instantánea de recomendación candidata con fecha del 26 de marzo de 2026, proporciona acceso a la ubicación del dispositivo solo tras autorización expresa e indica que la API no garantiza la ubicación real del dispositivo. La ubicación del navegador no se representa con un punto azul en interiores. Las balizas Bluetooth, el posicionamiento Wi-Fi, el posicionamiento visual ultra-wideband y los sistemas específicos del recinto son infraestructura, no una característica del modelo de lenguaje. La orientación es un requisito adicional para las instrucciones de «girar a la izquierda». Un mapa puede mostrar una ruta correcta sin necesidad de orientación. Cuando no se dispone de orientación, se debe sustituir la indicación de brújula por referencias a puntos de referencia o al mapa.

Muchos recintos pueden ofrecer sistemas de orientación útiles sin seguimiento continuo en interiores. El visitante selecciona un punto de referencia, el sistema devuelve una ruta, los pasos estáticos permanecen en el mapa y el visitante avanza manualmente. Las conferencias, campus, complejos turísticos y museos suelen necesitar este patrón más que un simple punto azul. El patrón también reduce los costos de privacidad e infraestructura. La navegación puede generar un historial de movimientos detallado: ubicación actual en interiores, ruta, destinos repetidos, lugar de trabajo, departamento médico o asistencia a eventos. El documento NIST Privacy Framework (NIST.CSWP.01162020, 16 de enero de 2020) trata la privacidad como gestión de riesgos empresariales: identificar qué se recopila, por qué y durante cuánto tiempo. Se prioriza el contexto temporal de origen, destino y ruta sobre un perfil de movimiento persistente. Datos de ubicación privados para flujos de trabajo de mapas de IA abarca el mismo límite propiedad del host.

¿Cómo debería la navegación conversacional compartir el estado con el mapa?

La conversación resulta útil una vez que el destino o la ruta ya están en el mapa. Las solicitudes de seguimiento, como la de encontrar un baño en la ruta actual, evitar las escaleras o encontrar una entrada más cercana al origen seleccionado, dependen del estado compartido, no de una segunda lista de resultados no oficial. El mapa, la lista, las instrucciones y el chat deben leer un único registro de orientación: origen, destino, planta activa, identificador de ruta, versión de la ruta, modo de accesibilidad y precisión de la posición cuando se dispone de un sistema de posicionamiento. Al seleccionar un destino, se puede mostrar una ruta. Cambiar el modo de accesibilidad puede invalidar la versión actual y solicitar un nuevo cálculo. Los resultados del asistente deben aparecer en el mismo mapa que el visitante ya utiliza.

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

Las acciones semánticas deben ser sencillas: establecer el origen, enfocar el destino, mostrar la ruta, cambiar de planta, resaltar una transición, abrir un registro de destino, borrar la ruta, solicitar un cambio de ruta. El host valida cada carga útil con respecto a los identificadores, el acceso y la versión de red actuales antes de que se ejecute el adaptador de renderizado. El mapa arbitrario JavaScript no constituye un contrato de control. Los permisos para estas acciones pertenecen a la aplicación y la infraestructura, nunca al modelo de lenguaje. La guía del asistente con reconocimiento de mapas abarca el estado compartido del mapa y las acciones validadas para esta transferencia.

Las actualizaciones operativas deben versionar tanto la red como la ruta. El cierre de un ascensor puede invalidar la versión 4 de la ruta en la versión 18 de la red y requerir la versión 5. El versionado permite depurar las guías obsoletas. La validación previa a la aplicación de una ruta debe confirmar que el origen, el destino, los permisos, la vigencia de la ruta, los cierres y el modo de viaje coinciden. El estado de la orientación cambia rápidamente en entornos en funcionamiento. La conectividad débil o sin conexión también es habitual en interiores. Almacene en caché la geometría del lugar, las etiquetas, el último piso y la última ruta válida cuando corresponda. La búsqueda directa de lugares debe mantenerse si falla la capa conversacional. Los KPI del panel de análisis espacial pertenecen a la medición del producto, no a considerar el volumen de chat como un indicador de éxito.

¿Cómo se integra Kaleidr en una pila de navegación existente?

La documentación actual para desarrolladores de Kaleidr presenta el chat como una capa conversacional integrada en un mapa que el host ya ejecuta. Quickstart muestra cómo integrar el chat en una instancia activa de Mapbox, MapLibre, Google Maps o Leaflet. Chat attach describe la Torre de Control como navegación basada en chat, resúmenes de lugares y marcadores de ubicación sobre el mapa del host. Las claves publicables están bloqueadas para el navegador; las claves del servidor no se muestran en la página (Auth & Scopes). Los fragmentos de código deben usar un marcador de posición claro en lugar de una clave con formato de archivo.

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

Estas plataformas admiten la búsqueda de destinos mediante lenguaje natural, conversaciones con reconocimiento de mapas, respuestas sobre lugares, marcadores en tiempo real y actualizaciones de la cámara. El anfitrión sigue siendo propietario del motor de renderizado, los datos del lugar, el motor de rutas, la topología interior, el posicionamiento y el control de acceso. La documentación pública de Kaleidr describe el chat con IA en mapas, los mapas publicados, los mapas base diseñados y la edición de mapas. Actualmente, dicha documentación no incluye un motor de posicionamiento interior dedicado ni un producto especializado de navegación paso a paso en interiores. Por lo tanto, una arquitectura correcta implica interacción conversacional y con reconocimiento de mapas en Kaleidr, con el enrutamiento o posicionamiento interior especializado en el sistema del lugar o de navegación cuando la implementación lo requiera. Location Intelligence APIs and Map SDK es la plataforma comercial actual para las API de inferencia, los sistemas de clasificación, el análisis y el soporte de implementación. La clasificación y el enrutamiento interior siguen siendo productos diferentes; no se debe codificar una ruta de navegación interior ficticia a partir del lenguaje de marketing.

Los lugares híbridos aún se ajustan a esta división. Los tramos al aire libre pueden usar un proveedor de rutas. Los tramos interiores pueden usar un gráfico del lugar. Las superposiciones de eventos permiten cambiar stands y sesiones sin necesidad de reconstruir paredes, como se describe en el artículo sobre mapas de lugares. Las solicitudes a hospitales y aeropuertos suelen fallar primero por problemas de identificación y acceso al destino, no por problemas con el trazado de la ruta: "imagen" y "la sala VIP que puedo usar cerca de la puerta 42" son problemas de elegibilidad antes que problemas geométricos. El modelo de lenguaje puede interpretar la solicitud. Los datos comerciales autorizados y los servicios geoespaciales siguen proporcionando la información necesaria.

¿Cómo deberían los equipos medir un asistente de orientación con IA?

Mida la funcionalidad de la guía de navegación, no el volumen de chat. La tasa de resolución de destinos, la tasa de resultados no obtenidos, el éxito de la ruta, las correcciones de piso incorrecto, la tasa de redireccionamiento, las denegaciones de acceso, el tiempo hasta la ruta de retorno, la confirmación del destino y el abandono de la ruta describen si los visitantes llegan a su destino. Si se utiliza el posicionamiento, añada eventos de desvío de ruta, fallos de confianza de ubicación y fallos de detección de piso. Mantenga el descubrimiento separado de la navegación: un destino resuelto con una ruta fallida es un defecto diferente a una búsqueda fallida. Los nombres de eventos editoriales, como «destino resuelto», «ruta solicitada», «ruta fallida», «piso cambiado» y «redireccionamiento», son análisis de producto, no eventos automáticos documentados Kaleidr Analytics.

La evaluación debe incluir ambigüedad, rutas entre pisos, bordes cerrados, acceso restringido, datos de accesibilidad faltantes y alternativas de baja conectividad. Compruebe que el mapa, la lista y los pasos hablados o escritos muestren la misma versión de la ruta. La latencia debe atribuirse a cada etapa; los equipos que culpan a la «IA» a menudo descubren que el enrutamiento o la resolución del origen son los factores predominantes. La finalización de la tarea tiene mayor prioridad que el número de interacciones. Un visitante que encuentra el Pabellón B mediante la búsqueda sin chatear ha tenido éxito. Una conversación larga que termina en el piso equivocado no lo ha tenido.

¿Qué modos de fallo deben evitar los productos de orientación?

El fallo recurrente consiste en colapsar tres sistemas en un párrafo generado automáticamente. Una imagen de plano se trata como un enrutador. El modelo de lenguaje se trata como un sistema de posicionamiento. Los pisos desaparecen. La accesibilidad se convierte en una ponderación de preferencia. Se filtran los bordes restringidos. Las indicaciones paso a paso aparecen sin orientación. La conversación se vuelve obligatoria. El historial de movimientos persiste por defecto. Cada fila a continuación es un defecto del producto con una corrección concreta.

La navegación móvil requiere objetivos grandes, pasos legibles y un mapa que siga siendo utilizable cuando el modelo o una ruta costosa caduquen. Almacenar en caché la geometría base. Degradar el enriquecimiento de forma controlada. Conservar una ruta desde la búsqueda escrita hasta el resaltado, incluso cuando la conversación no esté disponible.

Crear una experiencia de navegación conversacional

La arquitectura confiable se basa en la intención, la resolución de destino, el enrutamiento autorizado, el cálculo de la ruta, la explicación y una acción de mapa validada. El posicionamiento en interiores es una capa opcional posterior, que se añade solo cuando el lugar cuenta con un sistema adecuado. Kaleidr puede integrar IA espacial conversacional al mapa que ya utiliza el host, mientras que la topología del lugar y los enrutadores especializados siguen siendo la fuente principal cuando se requiere navegación en interiores.

Explora Kaleidr Enterprise para conocer las API, las interfaces del SDK y el soporte de implementación actuales. Revisa los patrones de conexión y los tipos de claves en la documentación para desarrolladores de Kaleidr antes de definir una ruta de integración.

Preguntas frecuentes

¿Qué es un asistente de orientación con IA?

Un asistente de orientación con IA interpreta preguntas de navegación en lenguaje natural, determina el destino deseado a partir de registros fiables y proporciona indicaciones de ruta o mapas de coordenadas. El enrutamiento y el posicionamiento siguen siendo sistemas independientes.

¿Es la orientación con IA lo mismo que la navegación en interiores?

No. La conversación puede interpretar una solicitud de navegación. La navegación en interiores también requiere una red de enrutamiento estructurada y puede requerir posicionamiento en interiores.

¿Se puede usar un plano de planta para la navegación paso a paso?

No por sí solo. Una navegación fiable requiere conectividad entre espacios, puertas, pasillos, escaleras, ascensores y otras transiciones.

¿Qué es IndoorGML?

IndoorGML es un estándar OGC para datos espaciales y de navegación en interiores. IndoorGML 2.0 Parte 1 es el modelo conceptual actual para espacios, conectividad y redes de navegación (OGC 22-045r5). OGC describió los esquemas de codificación IndoorGML 2.0 como disponibles a partir de agosto de 2025; IndoorGML 1.1 sigue siendo una versión publicada orientada a la codificación.

¿Qué es IMDF?

El formato de datos de mapeo de interiores es un estándar comunitario OGC (OGC 20-094, versión 1.0.0) para archivos de ubicación en interiores utilizados para orientación, navegación y descubrimiento.

¿Kaleidr ofrece actualmente posicionamiento en interiores?

La documentación pública actual de Kaleidr describe la IA espacial, el chat de mapas, los mapas personalizados, la publicación y la integración con mapas existentes. No documenta un sistema de posicionamiento en interiores específico, por lo que este debe considerarse una funcionalidad de implementación independiente, a menos que la aplicación anfitriona lo integre.

¿Kaleidr puede funcionar con un mapa de interiores?

Kaleidr puede integrar IA conversacional con implementaciones de mapas existentes compatibles. La aplicación anfitriona sigue siendo responsable de los datos del mapa, la red de rutas y el posicionamiento en interiores.

¿Cómo debería funcionar la orientación accesible?

Los requisitos de accesibilidad deben codificarse como restricciones de ruta estrictas utilizando datos verificados del lugar. El asistente no debe generar una ruta accesible a partir de información incompleta.

¿Puede un asistente de mapas con IA redirigir a un visitante?

El asistente puede solicitar o explicar una nueva ruta. El motor de enrutamiento autorizado debe recalcularla utilizando las condiciones actuales de la red y las reglas de acceso.

¿Debería el sistema de orientación rastrear la ubicación del usuario de forma continua?

Solo cuando el producto lo requiera y el usuario haya recibido la notificación o el consentimiento correspondiente. Muchas tareas de orientación pueden funcionar con un origen o punto de referencia seleccionado sin necesidad de un seguimiento persistente.

Referencias

• 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/}
}