Búsqueda en marketplaces basada en la ubicación

Un mercado con reconocimiento de ubicación relaciona la demanda del cliente con la oferta utilizando tanto la elegibilidad comercial como el contexto espacial. En lugar de listar todos los proveedores, propiedades, citas, lugares o servicios cercanos, el producto primero determina qué oferta puede satisfacer la solicitud y luego compara las opciones válidas según el tiempo de viaje, el área de servicio, los desvíos, la disponibilidad, la intención del cliente y las reglas comerciales. El modelo de lenguaje puede interpretar una solicitud en lenguaje natural y convertirla en restricciones estructuradas; El mercado sigue siendo la fuente principal de inventario, precios, permisos y transacciones.

Las secciones siguientes abarcan la búsqueda frente a la coincidencia frente a la transacción, la elegibilidad estricta, los modos de coincidencia espacial, la intención en lenguaje natural, el estado compartido, la idoneidad pública actual de Kaleidr, la medición y los modos de fallo. Entre las lecturas relacionadas se incluyen Clasificación de lugares API según la intención del cliente, Reservas con reconocimiento de ubicación, Mapas de experiencia del cliente con inteligencia de ubicación, Cómo crear un asistente de IA con reconocimiento de mapas y Datos de ubicación privados para flujos de trabajo de mapas de IA.

Aspectos esenciales de un mercado basado en la ubicación

• Elegibilidad antes de la clasificación: La oferta no disponible, no autorizada o fuera del área de cobertura se elimina del conjunto; no se trata simplemente de una puntuación más baja.
• La característica espacial se ajusta a la tarea: El área de servicio, el tiempo de viaje, el desvío de ruta y la compatibilidad con múltiples anclas responden a diferentes preguntas.
• El modelo de lenguaje interpreta la intención: Los sistemas del mercado siguen siendo la autoridad en cuanto a inventario, precio, permisos y proceso de pago.
• El mapa y la lista comparten un mismo estado: Los marcadores, las tarjetas, las explicaciones y la transacción utilizan los mismos identificadores de oferta.
• Coincidencia y finalización de la medición: Los clics no son prueba de que la oferta elegible haya alcanzado una acción del host.

¿Qué es un mercado basado en la ubicación?

Un mercado basado en la ubicación es un producto de búsqueda donde la geografía participa en la elegibilidad, la clasificación y la entrega, en lugar de simplemente decorar un directorio. La búsqueda convencional en los mercados suele recuperar una categoría, aplicar un radio y colocar marcadores. Los clientes aún deben deducir si un resultado realmente cubre la dirección, si la cita sigue disponible o si la parada representa un pequeño desvío en un viaje ya realizado. El producto útil integra el estado de la oferta, el cálculo espacial y la transacción gestionada por el proveedor en un único flujo de información.

La página de inicio actual de Kaleidr enumera las experiencias de reserva y mercado entre los recorridos del cliente impulsados ​​por IA y afirma que esas experiencias son aquellas en las que «la ubicación, la disponibilidad y la intención del cliente influyen en cada decisión» (AI-Powered Map Experiences for Business). Esa página es la fuente autorizada del posicionamiento de Kaleidr. La arquitectura que se muestra a continuación es un contrato de producto para anfitriones: el modelo de lenguaje interpreta la solicitud; la oferta, los precios, los permisos y el proceso de pago siguen siendo fuentes de información fidedignas.

La inteligencia de ubicación orientada al cliente sigue utilizando Discover → Compare → Act. Discover recupera la oferta disponible. Compare permite inspeccionar la relación de viaje, la adecuación del servicio, la disponibilidad y la política. Act es una transferencia de reserva, solicitud, contacto o compra dentro del mercado. La clasificación existe para mejorar esa decisión. La reserva con conocimiento de la ubicación es la versión de reserva del mismo contrato; Un mercado generaliza la búsqueda entre proveedores, propiedades, servicios y otros suministros propios.

¿Por qué la búsqueda en un mercado es una decisión espacial?

Los productos de los mercados resuelven un problema de emparejamiento: la demanda del cliente frente a la oferta disponible. La ubicación determina si ese emparejamiento es útil. Un proveedor puede ser relevante y aun así estar fuera del área de servicio, tardar demasiado en llegar, no tener la franja horaria solicitada, estar en una ruta desfavorable, no tener licencia para operar en el mercado o no ofrecer el servicio solicitado. Una propiedad puede ajustarse al presupuesto y las características, pero no cumplir con los requisitos de desplazamiento. Un lugar puede tener capacidad y aun así ser inconveniente para la ubicación geográfica de los asistentes. La proximidad en línea recta oculta estos problemas.

La pregunta clave es qué oferta elegible se ajusta mejor a las necesidades de este cliente en este contexto geográfico. Generalmente, se combinan cuatro entradas. La intención del cliente abarca el servicio solicitado, el tiempo, el presupuesto, el vecindario, la accesibilidad, la ruta y la urgencia. El estado de la oferta abarca el proveedor, la propiedad, el espacio, el alquiler, el lugar, la tienda o la unidad reservable. El contexto espacial abarca el origen, el destino, el área de servicio, el tiempo de viaje, la ruta y los límites. Las reglas de negocio abarcan la elegibilidad, la licencia, el nivel de cuenta, el estado del socio, el mercado operativo, el inventario y la capacidad. Una recomendación es tan confiable como estas entradas.

La búsqueda, la coincidencia y la transacción son etapas diferentes. La búsqueda encuentra candidatos en una categoría, ciudad o área de visualización. La coincidencia determina qué candidatos son válidos y útiles para la solicitud actual. La transacción completa la acción comercial. El modelo de lenguaje no debe controlar las tres etapas. El mercado anfitrión debe mantener la autoridad para el proceso de pago, la gestión de inventario y las reglas de la cuenta.

¿Por qué se debe ejecutar la elegibilidad estricta antes de la clasificación?

Un candidato que no puede satisfacer la solicitud debe ser descartado antes de la puntuación. Proveedores no disponibles, listados inactivos, espacios ocupados, servicio fuera de área, capacidades no compatibles, mercados sin licencia, capacidad insuficiente del lugar y clientes no autorizados son barreras. Convertir una regla estricta en una penalización aún permite que el registro inválido gane. La clasificación de lugares API utiliza el mismo orden: recuperar, autorizar, filtrar y luego clasificar. La coincidencia del mercado hereda ese flujo con el suministro de primera parte como catálogo.

Algunas reglas del mercado son geográficas y binarias. La restricción del área de servicio pregunta si el punto del cliente se encuentra dentro del polígono del proveedor. La elegibilidad del mercado pregunta si el anuncio está permitido en la región seleccionada. La opción de recogida o entrega pregunta si una tienda puede completar la solicitud desde un área postal. Estas comprobaciones son filtros espaciales. La clasificación compara a los proveedores restantes según el tiempo de viaje, el desvío, la adecuación al vecindario, las preferencias, la frescura y la política comercial. Una puntuación baja no convierte a un proveedor no válido en válido.

| Candidato | Distancia en línea recta | Tiempo de viaje | Disponible |

| --- | ---: | ---: | --- | | A | más lejos | más lento | Sí |

| B | aún más lejos | más rápido | Sí |

| C | más cercano | más rápido | No |

La opción "más cercano por distancia" devuelve C. La elegibilidad elimina C. El viaje en red puede entonces clasificar a B por encima de A. Una consulta de radio no puede expresar esa secuencia. El modo de viaje debe ser explícito: conducir, caminar, bicicleta o transporte público. La falta de disponibilidad no es una característica de clasificación cuando se requiere disponibilidad; El registro se excluye hasta que el sistema del mercado confirme que se puede reservar.

¿Qué características espaciales debería usar el sistema de coincidencia del mercado?

Una vez que la oferta es elegible, la geografía se vuelve comparativa. La distancia en línea recta es una aproximación económica cuando el viaje por la red es irrelevante. El tiempo de viaje suele ser la característica más conveniente para citas, desplazamientos a domicilio y visitas de servicio, ya que utiliza la red que el cliente realmente utiliza. La coincidencia a lo largo de la ruta se aplica cuando la demanda surge durante un viaje: una parada de servicio de camino a casa, una actividad con el menor desvío adicional antes del aeropuerto o puntos de recogida a lo largo de una ruta existente. La característica es el costo adicional de viaje en relación con una ruta, no la distancia desde el origen.

La documentación actual de Mapbox Search Box admite la búsqueda con reconocimiento de ruta y muestra added_distance en metros y added_time en minutos en los objetos de sugerencia cuando hay una ruta de entrada presente (Search Box API). Estos campos ilustran el desvío como una señal de recuperación. Google Places puede sesgar la búsqueda de texto hacia una polilínea de ruta a través de searchAlongRouteParameters (Search along route). La búsqueda de proveedores no es un inventario del mercado. La coincidencia de productos comienza cuando el proveedor enriquece la oferta propia con información que el proveedor no posee.

La comparación de múltiples anclas pregunta si un candidato funciona en relación con varios lugares importantes, como un espacio de coworking frente a un hotel y la oficina de un cliente. Una política requiere que cada ancla esté por debajo de un umbral y luego clasifica por precio. Otra minimiza el peor de los dos viajes. Estas políticas producen diferentes ganadores a partir del mismo vector de tiempo de viaje. Elija la función que refleje la decisión del cliente. La geografía del lado de la oferta también es importante: base del proveedor, territorio de servicio, área de trabajo activa, capacidad de ruta, ubicación actual del trabajo, región de cumplimiento y geometría del listado. La geografía del lado de la demanda puede ser una dirección, vecindario, ruta, destino, área de visualización o área dibujada. No fuerce la geolocalización del dispositivo. La especificación W3C Geolocation, una instantánea de recomendación de candidatos con fecha del 26 de marzo de 2026, proporciona acceso a la ubicación del dispositivo solo después de una autorización expresa e indica que API no garantiza la ubicación real del dispositivo.

¿Cómo debería funcionar la intención del lenguaje natural con los filtros del mercado?

Los filtros estructurados siguen siendo más rápidos para restricciones explícitas como fecha, precio, categoría, disponibilidad y capacidad. La conversación resulta útil cuando la solicitud combina varias de estas restricciones.«Buscar un fotógrafo disponible cerca del lugar del evento que pueda cubrir un evento de dos horas mañana por la noche» codifica categoría, disponibilidad, duración y una relación espacial.«Mostrar espacios de coworking entre el aeropuerto y el centro que tengan salas de reuniones» codifica geografía con múltiples puntos de referencia y un servicio. El modelo de lenguaje puede recuperar estos campos como restricciones verificables. El mercado los valida con respecto a la oferta, el calendario y las políticas.

Las restricciones interpretadas deben ser visibles y editables. Si un cliente solicita opciones cerca del aeropuerto con un presupuesto determinado, la interfaz debe mostrar la relación con el aeropuerto, el precio máximo y la puerta de disponibilidad recuperados para que el cliente pueda corregirlos. Frases como «cerca», «próximo», «conveniente» y «de camino» no tienen un significado numérico universal. Los filtros deterministas, el mapa, la lista y la conversación deben compartir un conjunto de candidatos. La conversación no debe ser la única vía para encontrar un proveedor específico o una dirección escrita.

El mapa, la lista, la explicación y la transacción deben usar los mismos identificadores de suministro. Al seleccionar un marcador, se debe seleccionar la misma tarjeta del mercado. Al cambiar un filtro, se deben actualizar ambas superficies. Una recomendación del asistente debe centrarse en la misma entidad en lugar de un segundo resultado no oficial. Los nombres no son suficientes: dos proveedores pueden compartir una marca, un edificio puede contener varias unidades y un lugar puede tener múltiples espacios reservables. Los identificadores estables mantienen sincronizados la búsqueda, el mapa, los análisis y el proceso de pago.

Los datos de lugares públicos y la oferta de mercado de primera mano cumplen funciones diferentes. Los lugares públicos son útiles para el contexto del vecindario, los servicios cercanos y los puntos de referencia. La oferta de primera mano es la fuente autorizada para la disponibilidad, el precio, el inventario, el servicio, el estado del proveedor, las unidades reservables y la elegibilidad del mercado. Un listado público puede existir aunque el artículo correspondiente en el mercado no esté disponible. No sustituya la base de datos de oferta por una búsqueda de lugares API.

Los datos de mercado privados requieren una ruta de recuperación precisa. Autentique, resuelva el inquilino, autorice, recupere un conjunto mínimo elegible, clasifique y luego explique. No envíe el catálogo completo al modelo de lenguaje. Datos de ubicación privados para flujos de trabajo de mapas de IA abarca ese límite de propiedad del host. Las plataformas multiusuario deben preservar la organización, el inquilino, el mercado y el usuario en cada solicitud de clasificación. Las credenciales API a nivel de organización no reemplazan la autorización del inquilino a nivel de aplicación. La autenticación de la API de mapas abarca las claves publicables frente a las claves de servidor para las superficies Kaleidr que vinculan la conversación a un mapa anfitrión.

OWASP LLM01:2025 Prompt Injection describe cómo el texto del usuario o recuperado puede alterar el comportamiento del modelo, incluyendo 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, permisos o autonomía. Un asistente de mercado debe proponer un identificador de suministro y una acción permitida. La aplicación anfitriona debe ejecutar la reserva, el pago o el bloqueo de inventario tras la validación del esquema, la elegibilidad y la revalidación. Los permisos pertenecen a la aplicación y la infraestructura, nunca al modelo de lenguaje.

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

La página actual de IA espacial de Kaleidr describe un patrón de implementación empresarial que consiste en conectar tus lugares, fundamentar la IA e implementarla en tu plataforma, e indica que las respuestas pueden basarse en el inventario, la voz de la marca y las políticas, en lugar de solo en la búsqueda web genérica (AI Map Chat for Customer Discovery). Chat attach incorpora navegación conversacional, resúmenes de lugares y marcadores sobre una instancia de Mapbox, MapLibre, Google Maps o Leaflet que el host ya ejecuta. Location Intelligence APIs and Map SDK es la superficie comercial actual para la inferencia APIs, los sistemas de clasificación, el análisis y el soporte para la implementación. Las claves publicables están bloqueadas en el origen para el navegador; las claves del servidor no se muestran en la página (Auth & Scopes).

La pila práctica es el mercado existente, la base de datos de suministro, el sistema de transacciones y el mapa, más Kaleidr para IA espacial e interacción consciente del mapa. Kaleidr no necesita tener el proceso de pago. Reservar, solicitar, reservar, contactar y comprar pueden seguir siendo acciones de host clavedas a un identificador de suministro validado. Las credenciales de inventario privado deben estar en el backend. La documentación actual de la plataforma pública API enumera los puntos finales de chat, ruta, enriquecimiento de POI y diseño (Endpoints). La página de puntos finales no documenta una ruta dedicada /marketplace/search o /match. La clasificación o inferencia personalizada debe confirmarse a través de la integración empresarial compatible en lugar de codificarse a partir del lenguaje de marketing.

Un programa piloto eficaz comienza con una solicitud de cliente, como encontrar el mejor proveedor disponible para un servicio cerca de su domicilio. La primera fase es determinista: filtro de servicio, disponibilidad, área de servicio y tiempo de viaje. La segunda fase sincroniza la oferta disponible en el mapa y la lista de un estado. La tercera fase añade preguntas compuestas conversacionales. La cuarta fase muestra razones objetivas. La quinta fase mide la tasa de falta de oferta, el tiempo de selección, la conversión de la transacción y las brechas de cobertura geográfica. Amplíe el programa solo cuando la clasificación mejore la decisión del mercado.

La oferta cambia rápidamente: se reserva un espacio, un proveedor deja de estar disponible, se reserva un alquiler, se agota el inventario, un local cierra o cambia el área de servicio. Asigne información actualizada a los campos operativos y revalide el precio, la disponibilidad y la elegibilidad antes de la transacción. Si el estado cambia, informe al cliente. No cambie de proveedor sin previo aviso. Las razones en la tarjeta de resultados deben corresponder a datos reales: disponibilidad a la hora solicitada, dentro del área de servicio, tiempo de viaje estimado y el servicio solicitado. La información comercial debe mantenerse independiente de la relevancia para el cliente y cumplir con los requisitos de divulgación aplicables. La capacidad puede ser un factor determinante cuando un proveedor está completo, o un indicador de clasificación más sutil cuando la utilización es solo una preferencia. Es importante aclarar esta distinción.

La liquidez del mercado es geográfica. Una sólida oferta nacional puede fallar en un vecindario. Compare la demanda, la oferta disponible, la calidad de las coincidencias y el resultado de las transacciones por área. Analice por qué una consulta no arrojó resultados: mala búsqueda, falta de oferta disponible, área de servicio incorrecta, disponibilidad agotada, datos obsoletos o intención mal interpretada. No agrupe todos los estados vacíos en un evento genérico de "sin resultados". El documento NIST Privacy Framework (NIST.CSWP.01162020, 16 de enero de 2020) trata la privacidad como gestión de riesgos empresariales: identifique qué se recopila, por qué y durante cuánto tiempo. Prefiera una dirección explícita o un área seleccionada en lugar del seguimiento continuo del dispositivo cuando el trabajo no requiera una posición en vivo.

¿Cómo deben medir los equipos la búsqueda en el mercado basada en la ubicación?

Mida el trabajo que coincide, no el volumen de chat. Las métricas del lado del cliente incluyen la tasa de resultados, el tiempo para una selección útil, la tasa de re-consulta, la selección, el inicio de la transacción y la finalización. Las métricas del lado del proveedor incluyen el suministro elegible por consulta, la distribución de la exposición del proveedor, el rechazo de capacidad y el rechazo del área de servicio. Las métricas espaciales incluyen el tiempo de viaje medio, la distribución de desvíos, la geografía sin suministro, las brechas de cobertura y la conversión por banda de tiempo de viaje. Los nombres de eventos editoriales como candidatos elegibles, sin suministro, resultado seleccionado, revalidación fallida y transacción completada son análisis de producto, no eventos automáticos documentados Kaleidr Analytics. Los KPI del panel de análisis espacial pertenecen a esa capa de medición.

Un resultado nulo que en realidad indica una brecha de cobertura es una señal operativa, no un fallo en la relevancia de la búsqueda. La diferencia entre la demanda y la oferta disponible por área puede mostrar vecindarios con estados de vacantes recurrentes, zonas de servicio insuficientes, mercados con exceso de oferta, tiempos de viaje excesivos y regiones que necesitan captar proveedores. La conversión se puede comparar entre diferentes rangos de tiempo de viaje para que la plataforma aprenda la tolerancia geográfica de la demanda en lugar de asumir un radio. La finalización de la tarea tiene mayor prioridad que el número de interacciones. Un cliente que reserva un proveedor disponible mediante filtros sin chatear ha tenido éxito. Una conversación larga que termina con un anuncio no disponible no lo ha tenido.

¿Qué modos de fallo deben evitar los productos de las plataformas de comercio electrónico?

El fallo recurrente consiste en tratar la búsqueda cercana como una coincidencia. Se clasifica la oferta no válida. Los datos de lugares públicos se tratan como inventario. La distancia sustituye al tiempo de viaje o al área de servicio. La conversación oculta las restricciones recuperadas. El modelo de lenguaje inventa la disponibilidad. El mapa y la lista divergen. Se omite la autorización del inquilino. El proceso de pago se entrega a la salida del modelo sin restricciones. Los clics se tratan como un indicador del estado de la plataforma. La liquidez geográfica permanece sin medir. Una ruta ficticia Kaleidr /match se codifica a partir de una copia de posicionamiento.

| Error | Resultado | Mejor enfoque |

| --- | --- | --- | | Clasificar antes de la elegibilidad | Aparecen proveedores no válidos | Filtrar primero las restricciones estrictas |

| Usar datos de lugares públicos como inventario | La disponibilidad se vuelve poco fiable | Mantener la autoridad del suministro de primera parte |

| Ordenar solo por distancia | La conveniencia se simplifica demasiado | Usar tiempo de viaje, desvío o área de servicio |

| Ocultar restricciones interpretadas | Los clientes no pueden corregir la intención | Exponer y editar campos recuperados |

| Dejar que el modelo de lenguaje invente la disponibilidad | Transacción sin salida | Leer el estado del mercado en tiempo real |

| Mezclar estados de mapa y lista | Los resultados no coinciden | Compartir ID canónicos |

| Ignorar la autorización del inquilino | El suministro privado puede filtrarse | Autorizar antes de la recuperación |

| Dejar que el modelo gestione el proceso de pago | La integridad de la transacción se debilita | Transferir al host |

| Medir solo los clics | El resultado no está claro | Medir la coincidencia y la finalización |

| Supongamos una ruta Kaleidr /match | Objetivos de integración ficticios | Confirmar el contrato empresarial actual |

La búsqueda en el mercado móvil requiere objetivos amplios, razones legibles y un mapa que siga siendo utilizable cuando el modelo o una matriz de tiempo de viaje costosa caduquen. La búsqueda directa por categoría y nombre debe seguir funcionando. Almacenar en caché la geometría base. Degradar el enriquecimiento de forma controlada. Revalidar antes de la transacción del host.

Integrar IA espacial en su mercado

El patrón de producción es: intención de demanda, recuperación de oferta, autorización, elegibilidad, características espaciales, clasificación, explicación, mapa y lista sincronizados, y luego una transacción del host. Kaleidr puede incorporar IA espacial conversacional al mapa que ya utiliza el mercado, mientras que la oferta, la política y el proceso de pago se mantienen como información autorizada.

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 mercado basado en la ubicación?

Un mercado basado en la ubicación utiliza el contexto geográfico para conectar la demanda con la oferta disponible. El producto puede usar áreas de servicio, tiempo de viaje, contexto de ruta, disponibilidad e intención del cliente en lugar de mostrar todas las opciones cercanas.

¿Es un mercado basado en la ubicación lo mismo que un mercado local?

No. Un mercado local se centra en la geografía. Un mercado basado en la ubicación utiliza las relaciones espaciales directamente en la búsqueda, la elegibilidad, la clasificación o la entrega.

¿Debe un mercado clasificar primero al proveedor más cercano?

No automáticamente. El proveedor más cercano podría no estar disponible, estar fuera del área de servicio, no poder proporcionar el servicio solicitado o resultar inconveniente debido al tiempo de viaje real.

¿Qué debe hacer un modelo de lenguaje en un mercado?

Un modelo de lenguaje es útil para traducir la compleja intención del cliente en requisitos estructurados y explicar los resultados. El modelo de lenguaje no debe inventar la oferta, los precios, la disponibilidad ni la elegibilidad.

¿Quién debe ser el propietario del inventario del mercado?

El sistema de oferta o inventario autorizado del mercado debe ser el propietario de los datos de disponibilidad, precio, estado del proveedor y transacciones.

¿Qué es la coincidencia de área de servicio?

La coincidencia de área de servicio verifica si la ubicación del cliente se encuentra dentro del área operativa permitida de un proveedor. La coincidencia de área de servicio suele ser una regla de elegibilidad estricta.

¿Puede la clasificación del mercado utilizar el tiempo de viaje?

Sí. El tiempo de viaje puede ser un mejor indicador de conveniencia que la distancia en línea recta, ya que refleja la red real y el modo de transporte.

¿Qué es la búsqueda en ruta en un mercado?

La búsqueda en ruta compara la oferta con un trayecto existente, minimizando a menudo el tiempo adicional o los desvíos en lugar de la distancia desde el origen.

¿Puede un mercado usar múltiples ubicaciones de referencia?

Sí. Un producto puede clasificar la oferta en relación con varias ubicaciones importantes, como un aeropuerto y una oficina, o dos destinos de clientes.

¿Cómo debe medir la inteligencia de ubicación un mercado B2B?

Se debe medir la tasa de resultados, el tiempo de selección útil, la oferta disponible por consulta, la conversión de transacciones, la distribución del tiempo de viaje, los rechazos en el área de servicio y las brechas geográficas entre la oferta y la demanda.

¿Puede Kaleidr reemplazar la capa de aplicación de un mercado?

Reemplazar la capa de aplicación del mercado no es la arquitectura recomendada. El mercado debe mantener la información sobre la oferta, los permisos, los precios y las transacciones. Kaleidr puede agregar inteligencia espacial e interacción conversacional con mapas a estos sistemas.

¿Kaleidr cuenta con un punto final público para la búsqueda de coincidencias en el mercado?

La documentación actual de la plataforma pública API no incluye un punto final específico para la búsqueda de coincidencias en el mercado. Los requisitos personalizados de clasificación o inferencia del mercado deben confirmarse mediante la integración Kaleidr Enterprise compatible.

Referencias

• Google Maps Platform. Search along route. Places API. Accessed 28 August 2026. https://developers.google.com/maps/documentation/places/web-service/search-along-route
• Kaleidr. AI Map Chat for Customer Discovery. Accessed 28 August 2026. https://kaleidr.com/ai
• Kaleidr. AI-Powered Map Experiences for Business. Accessed 28 August 2026. https://kaleidr.com/
• Kaleidr. Auth & Scopes. Kaleidr Developer Docs. Accessed 28 August 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
• Kaleidr. Chat attach. Kaleidr Developer Docs. Accessed 28 August 2026. https://docs.kaleidr.com/sdk/chat-attach
• Kaleidr. Endpoints. Kaleidr Developer Docs. Accessed 28 August 2026. https://docs.kaleidr.com/platform-api/endpoints
• Kaleidr. Location Intelligence APIs and Map SDK. Accessed 28 August 2026. https://kaleidr.com/enterprise
• Mapbox. Search Box API. Accessed 28 August 2026. https://docs.mapbox.com/api/search/search-box/
• 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
• OWASP Gen AI Security Project. LLM01:2025 Prompt Injection. Accessed 28 August 2026. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• OWASP Gen AI Security Project. OWASP Top 10 for LLM Applications 2025. Accessed 28 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 28 August 2026. https://www.w3.org/TR/geolocation/

@misc{google_search_along_route_2026_08_28,
  title  = {Search along route},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 28 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/search-along-route}
}

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

@misc{kaleidr_marketplace_home_2026_08_28,
  title  = {AI-Powered Map Experiences for Business},
  author = {{Kaleidr}},
  note   = {Accessed 28 August 2026},
  url    = {https://kaleidr.com/}
}

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

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

@misc{kaleidr_endpoints_2026_08_28,
  title  = {Endpoints},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 28 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

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

@misc{mapbox_search_box_2026_08_28,
  title  = {Search Box API},
  author = {{Mapbox}},
  note   = {Accessed 28 August 2026},
  url    = {https://docs.mapbox.com/api/search/search-box/}
}

@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}
}

@misc{owasp_llm01_prompt_injection_2025,
  title  = {LLM01:2025 Prompt Injection},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 28 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 28 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 28 August 2026},
  url    = {https://www.w3.org/TR/geolocation/}
}