Arquitectura empresarial de IA espacial

Por The Kaleidr Team · Publicado 30 de septiembre de 2026 · 22 min de lectura

Un tablero de arquitectura empresarial de IA espacial sitúa identidad, orquestación de IA, datos autorizados, elegibilidad, acciones de mapa y analítica entre un producto y sus sistemas empresariales.

La arquitectura empresarial de IA espacial separa modelos de lenguaje, mapas, datos empresariales, cálculos espaciales, permisos, herramientas y acciones para que cada tarea permanezca en la capa que puede hacerla cumplir. Una respuesta fluida todavía puede enviar a alguien a la sucursal equivocada. El host conserva la identidad y las transacciones. Los servicios espaciales calculan la geografía. El modelo de lenguaje interpreta la solicitud y explica un resultado que esos sistemas ya han fundamentado.

Las secciones siguientes cubren propiedad, autorización, credenciales, herramientas, la ruta de solicitud y tres patrones de despliegue. Lecturas relacionadas incluyen Spatial AI Accuracy Evaluation y An Enterprise Spatial AI Pilot. Una negativa correcta puede ser un resultado mejor que una recomendación plausible que ningún sistema de registro respalda.

Fundamentos de la arquitectura empresarial de IA espacial

  • Separar las tareas: El modelo de lenguaje interpreta y explica. No es propietario del inventario, los permisos, las rutas ni las transacciones.
  • Autorizar antes de recuperar: Resolver usuario, tenant, objetos y campos antes de que el contexto privado llegue al modelo.
  • Mantener los hechos tipados: Los ID estables y los campos operativos permanecen estructurados. La prosa no los sustituye.
  • Acotar cada herramienta: Las acciones de lectura, mapa, borrador y escritura tienen reglas de aprobación diferentes.
  • Medir el flujo de trabajo: Observar la decisión de ubicación y el resultado del host, no solo tokens y latencia.

¿Qué es la arquitectura empresarial de IA espacial?

Un cliente puede preguntar qué centro de servicio puede atender un trabajo hoy, está dentro del área contractual y añade el menor tiempo de viaje a la ruta actual. Esa frase necesita una capa de intención, registros de cliente y contrato, datos de instalaciones, reglas de área de servicio, un cálculo de ruta y un flujo de trabajo de mapa. Un sistema de producción también necesita identidad, aislamiento entre tenants, límites de herramientas, comprobaciones de acciones, registros y un punto en el que una persona pueda aprobar un paso de alto impacto. Poner todos esos trabajos dentro de un único prompt hace que el producto sea difícil de proteger y de cambiar. El modelo puede indicar qué debería ocurrir después. La aplicación de las reglas permanece fuera del modelo.

Comparación entre un diseño frágil de IA espacial, donde un modelo se conecta a todos los sistemas, y un diseño por capas con autorización, datos, herramientas espaciales y comprobaciones de acciones separadas.

El lado izquierdo conecta un modelo directamente con bases de datos, enrutamiento y transacciones. El lado derecho mantiene identidad, datos, herramientas espaciales, ranking y acción validada en capas separadas. El contraste es un patrón de arquitectura, no un benchmark de Kaleidr.

Una ruta práctica se parece menos a un usuario hablando con un modelo que puede llegar a todo y más a una secuencia que el host puede inspeccionar. La aplicación mantiene al usuario y el estado actual del mapa. La identidad y la autorización se resuelven antes de la recuperación. La interpretación de intención solicita después solo datos aprobados y cálculos espaciales. La elegibilidad elimina opciones inválidas antes del ranking. Una acción validada actualiza el mapa o el flujo de trabajo, y la analítica registra si la tarea tuvo éxito. Esa secuencia permite cambiar modelos, proveedores de mapas o reglas de ranking sin reconstruir el producto alrededor de una dependencia opaca.

¿Qué sistema debería ser propietario de cada hecho?

Un taller de arquitectura debería nombrar al propietario de cada hecho crítico antes de que nadie elija un modelo. El proveedor de identidad del host es propietario del usuario. La aplicación host posee la pertenencia al tenant, los derechos del producto, el flujo de trabajo y el resultado empresarial. Los sistemas empresariales poseen la identidad de las instalaciones, inventario, disponibilidad, precio, estado de reserva y políticas. Una fuente de ubicación aprobada posee las coordenadas. El cálculo espacial posee distancia, tiempo de viaje y punto-en-polígono. La aplicación cliente posee el viewport y el lugar seleccionado. La capa de IA posee la interpretación de intención y una explicación escrita sobre evidencia fundamentada. El flujo de trabajo del host posee la transacción final.

Hecho o decisión Propietario autoritativo
Identidad de usuario y tenant Sistema de identidad del host
Inventario, precio, reserva, política Sistema empresarial de registro
Distancia, tiempo de viaje, contención Cálculo espacial
Viewport del mapa y lugar seleccionado Aplicación cliente
Intención y explicación Capa de IA, sobre evidencia fundamentada
Transacción final Flujo de trabajo del host

Mapa de propiedad que asigna identidad y flujo de trabajo al host, hechos operativos a sistemas empresariales, geografía a servicios espaciales, interpretación a la capa de IA y estado del mapa al cliente.

Cada columna tiene un propietario principal. La capa de IA coordina intención y explicación. El host y los sistemas empresariales siguen siendo los sistemas de registro, y el tablero es un marco, no un inventario de productos.

Si un equipo no puede nombrar al propietario de un hecho crítico, un asistente suele ocultar la brecha. La guía de Kaleidr sobre Spatial AI fundamentada usa la misma separación: el modelo interpreta intención compuesta, mientras que inventario, políticas, permisos y enrutamiento permanecen en los sistemas creados para mantener esos hechos (Kaleidr, 2026). La recuperación encuentra contexto. La autoridad decide qué fuente puede responder una pregunta factual. Un documento recuperado no es automáticamente el sistema de registro.

¿Por qué autorizar antes de recuperar?

Un error común recupera datos privados, los envía al modelo y luego pregunta al modelo qué filas puede ver la persona. Hay que invertir ese orden. Autenticar al usuario, resolver el tenant, resolver roles y derechos, autorizar objetos, minimizar campos, recuperar los registros aprobados y solo entonces pasar el contexto necesario. El límite de permisos debe ser determinista y auditable. Un modelo de lenguaje no debería decidir si un gerente regional puede ver una instalación, si un cliente puede leer el historial de ubicación de otro cliente o si un empleado puede recuperar datos restringidos del lugar de trabajo.

Flujo de autorización que resuelve tenant, rol, objetos y campos antes de que un contexto privado minimizado llegue a Spatial AI, con una ruta bloqueada que enviaría toda la base de datos al modelo.

Los registros privados cruzan el límite solo después de comprobar tenant, rol, objeto y campo. La ruta inferior, que pide a un modelo inferir permisos desde una base de datos completa, permanece bloqueada. Las credenciales de plataforma y la autorización del usuario final siguen siendo comprobaciones distintas.

Una credencial de plataforma puede demostrar que una aplicación puede usar una capacidad. Esa credencial no decide qué usuario final puede leer qué filas. CORS, autenticación de credenciales, ámbitos de capacidades de API y autorización de usuarios a nivel de aplicación resuelven problemas distintos; mezclarlos produce el fallo equivocado (Kaleidr, 2026). Por eso la ruta de datos privados es una pila de comprobaciones, no un único token que significa todo.

¿Cómo deben mantenerse separadas las credenciales del navegador y del servidor?

Un navegador es inspeccionable, así que todo lo que se le envíe debe tratarse como visible para la persona que lo ejecuta. Un backend es el lugar adecuado para secretos de larga duración, acceso a datos empresariales privados, aplicación de políticas y llamadas servidor a servidor. El navegador puede mantener una credencial publicable y segura para cliente destinada a una capacidad de mapa acotada. Las solicitudes autenticadas del producto van al backend del host, que aplica el contexto del usuario, accede a datos privados y llama operaciones espaciales o de IA con una credencial de servidor. Los dos entornos de ejecución no deberían compartir un mismo secreto.

Diagrama que separa una clave publicable del navegador y capacidades de mapa del cliente de una clave de servidor del backend, datos empresariales privados y un gestor de secretos.

El lado del navegador está diseñado para la exposición y queda limitado a capacidades de cliente acotadas. El lado del servidor conserva la credencial de servidor, los registros privados y la autorización de usuarios. Las marcas de verificación son un esquema del límite, no una certificación de seguridad.

La documentación actual de claves de Kaleidr define una clave publicable para uso en navegador y una clave de servidor para integraciones backend. La clave publicable está bloqueada por origen, y el SDK la intercambia por una sesión de corta duración en tiempo de ejecución en lugar de usar esa cadena como bearer permanente del servidor. La clave de servidor permanece en servidores de confianza (Kaleidr, 2026). El mismo conjunto de documentación describe Chat, Editor, Tile y Viewer como superficies separadas, con vías de entrada de attach, embed y tile que no se montan todas de la misma forma (Kaleidr, 2026). Siga el contrato actual de cada superficie en lugar de asumir que una sola credencial y un único montaje cubren toda la pila.

¿Dónde deberían vivir los hechos empresariales y la geografía?

Enterprise Spatial AI es útil cuando puede razonar sobre hechos que un modelo público no conoce: inventario actual, elegibilidad de socios, capacidad de instalaciones, cobertura contractual, cierres temporales y disponibilidad en vivo. Esos hechos pertenecen a sistemas de registro. No pida al modelo que recuerde un valor que puede cambiar esta tarde. No ajuste finamente un modelo sobre un campo operativo que una consulta puede devolver. No pegue una amplia base de datos interna en un system prompt. Interprete la solicitud, decida qué registros autorizados se necesitan, recupere el conjunto mínimo, conserve ID estables y campos tipados, ejecute filtros estrictos, calcule la geografía y solo entonces explique el resultado fundamentado.

{
  "branch_id": "b_1042",
  "open_now": true,
  "inventory_status": "in_stock",
  "service_eligible": true,
  "lat": 38.91,
  "lng": -77.22
}

Un registro tipado puede filtrarse, registrarse, comprobarse contra permisos y pasarse a una acción posterior. Una frase que diga que una sucursal “parece abierta” y “probablemente” tiene el artículo no puede hacerlo. El lenguaje natural sigue perteneciendo a la explicación. No debería sustituir campos que la aplicación puede almacenar directamente.

Los cálculos espaciales merecen su propia capa por la misma razón. Punto-en-polígono, distancia de ruta, tiempo de conducción, tiempo a pie, pertenencia a área de servicio, desviación de ruta y análisis de accesibilidad dentro de un tiempo deberían provenir de un servicio geográfico cuando el producto puede calcularlos. La capa de IA puede determinar que se requiere un cálculo. El servicio espacial lo ejecuta. La explicación indica después por qué esa relación importa para la solicitud. Cambiar de modelo de lenguaje no obliga al equipo a reaprender cómo mide la aplicación el tiempo de viaje o la contención.

Las restricciones duras y las preferencias suaves deberían mantenerse separadas. Una solicitud de clínica podría exigir un plan aceptado, horario posterior a las 18:00, una ubicación activa y un registro al que el usuario pueda acceder. Solo los candidatos que pasen esas reglas deberían ordenarse por tiempo de conducción, desviación de ruta o una preferencia declarada. El orden es recuperación, autorización, elegibilidad, cálculo espacial, ranking y explicación. Hacer el ranking primero y esperar que el modelo recuerde todas las restricciones oculta una opción inválida dentro de una lista fluida. Retail, inmobiliario, reservas, lugares de trabajo y redes con múltiples ubicaciones pueden compartir ese orden porque la restricción trata de validez, no de vocabulario sectorial.

¿Cómo deberían acotarse las herramientas y las acciones?

La Spatial AI agéntica convierte el catálogo de herramientas en uno de los límites importantes. Herramientas abiertas como una cadena SQL arbitraria, un comando de shell o una URL interna de formato libre son un entorno de ejecución, no una capacidad empresarial. Prefiera herramientas estrechas con entradas y salidas conocidas: buscar ubicaciones elegibles, calcular tiempo de viaje, leer disponibilidad de sucursal, mostrar lugares, solicitar una ruta o crear un borrador de reserva. Cada herramienta puede llevar su propia comprobación de permisos, validación, límite de tasa, línea de registro y modo de fallo.

Modelo de herramientas que separa capacidades de lectura, mapa, borrador y escritura, con requisitos de aprobación crecientes hacia acciones que cambian el estado empresarial.

Las herramientas de lectura y mapa pueden ejecutarse cuando el llamante ya está autorizado. Los borradores crean un objeto revisable. Las escrituras que confirman una reserva, despachan trabajo o cambian un registro esperan una puerta de política explícita. Los niveles son orientación arquitectónica, no una lista fija de permisos de Kaleidr.

Leer un registro y cambiar el estado empresarial son clases de riesgo diferentes. Un catálogo de producción puede agrupar capacidades en lectura, mapa, borrador y escritura. Las acciones de lectura y mapa de bajo impacto pueden ejecutarse automáticamente una vez superada la autorización. Un borrador puede preparar una reserva o una solicitud de servicio para revisión. Una escritura que confirma una reserva, despacha un vehículo o publica un cambio puede requerir confirmación, una segunda comprobación de política y, a veces, una persona. Una puntuación de confianza no es un sistema de permisos.

La guía de OWASP de 2025 sobre excessive agency trata la funcionalidad excesiva, los permisos excesivos y la autonomía excesiva como causas separadas. Recomienda limitar al mínimo necesario las extensiones que un agente puede invocar, preferir funciones granulares frente a las abiertas, exigir aprobación para acciones de alto impacto y aplicar la autorización en sistemas downstream en lugar de confiar en que el modelo permita la llamada (OWASP, 2025). La aplicación aun debe validar cada llamada propuesta. Para una acción de mapa, compruebe que la acción esté permitida, que los ID de lugar pertenezcan al conjunto de resultados autorizado, que el usuario pueda acceder a ellos y que los argumentos estén bien formados. Para una escritura, aplique una comprobación más estricta. Un prompt, un documento recuperado o un resultado de herramienta mal formado no deben convertirse en una evasión de autorización.

La guía de OWASP sobre system prompts establece el mismo límite desde el otro lado. El system prompt no es un secreto ni un control de seguridad. La separación de privilegios y las comprobaciones de autorización no deben delegarse al modelo, a través del prompt ni de otra manera (OWASP, 2025). Las acciones de mapa deberían usar un vocabulario semántico, como mostrar lugares, encajar lugares, seleccionar un lugar, dibujar una ruta o borrar una ruta, y un adaptador determinista debería traducir esas acciones para Mapbox, MapLibre, Google Maps u otro renderer. El modelo no debería emitir código del renderer en cada turno.

¿Cómo debería entrar el estado del mapa en la solicitud?

El estado del mapa cambia lo que una persona quiere decir con “estos”, “al norte de aquí” o “la segunda opción”. Una instantánea útil puede incluir límites del viewport, el ID del lugar seleccionado, ID de resultados visibles, filtros activos, un ID de ruta actual y una ubicación aprobada con la precisión que necesita la tarea. Marque qué campos están siempre disponibles, son opcionales, privados, aprobados por el usuario, obsoletos, autoritativos o inferidos. No envíe la ubicación precisa del dispositivo en cada solicitud solo porque el mapa puede leerla. La referencia más sólida para “cuál de estos abre más tarde” son los ID estables del conjunto de resultados actual, no una captura de pantalla. La guía de Kaleidr sobre asistentes conscientes del mapa traza ese límite: compartir viewport, selección, filtros e ID de resultados, y no pedir al modelo que infiera la aplicación a partir de píxeles (Kaleidr, 2026).

Una capa de orquestación puede decidir si la solicitud necesita recuperación empresarial, enrutamiento, una acción de mapa, una pregunta aclaratoria o un resumen de la evidencia. Esa capa puede estar impulsada por modelo, por reglas o por una mezcla. No debería ser el único límite de seguridad. La orquestación puede preguntar si debe consultar disponibilidad. La autorización responde si este llamante puede recuperar disponibilidad para esos registros. La orquestación puede preguntar si debe iniciar una reserva. La capa de transacción responde si la persona confirmó y si la operación es válida. La separación sobrevive a un error del modelo.

El aislamiento entre tenants pertenece al mismo camino. Resuelva identidad autenticada, tenant, rol y objetos permitidos antes de la consulta, y limite la consulta a ese tenant. No confíe en un prompt que diga que al modelo se le indicó que no mencionara otros tenants. El modelo nunca debería recibir datos de otro tenant salvo que la aplicación tenga un propósito y una política explícitos entre tenants. Consultas acotadas al tenant, comprobaciones de objetos, minimización de campos y registros redactados son los controles. Una frase en el prompt no es uno de ellos.

¿Cómo se mueve una solicitud de producción por la pila?

Una solicitud completa puede dibujarse como doce etapas, y no todas las solicitudes necesitan todas. Capture al usuario autenticado, el tenant, el estado del mapa y el estado del flujo de trabajo. Interprete la tarea, las restricciones geográficas, las restricciones empresariales y la acción prevista. Resuelva las fuentes, registros, campos, herramientas y acciones permitidos antes de cualquier recuperación privada.

Recupere hechos autorizados e ID de lugar canónicos y después calcule distancia, tiempo de viaje, contención o pertenencia a área de servicio. Elimine candidatos no autorizados, no disponibles, cerrados o fuera del área y ordene los restantes. Explique el resultado fundamentado, proponga una acción semántica de mapa o flujo de trabajo y valide esa acción fuera del modelo. Ejecute la acción y después registre la decisión y el resultado.

Pipeline de solicitud de Spatial AI en doce etapas desde usuario y estado del mapa hasta autorización, grounding, cálculo espacial, elegibilidad, ranking, validación, ejecución y analítica.

Las etapas avanzan desde estado del mapa e intención, pasando por autorización, grounding, geografía, elegibilidad y ranking, hasta explicación, acción propuesta, validación, ejecución y medición. Una solicitud simple como “mostrar este lugar” puede omitir recuperación y ranking. Una recomendación de servicio puede usar casi todo el recorrido.

El comportamiento ante fallos forma parte del mismo recorrido. Si los datos empresariales no están disponibles, no invente disponibilidad. Diga que la disponibilidad no puede verificarse en este momento. Si el enrutamiento está caído, no afirme un ranking por tiempo de viaje y etiquete cualquier alternativa en línea recta como fallback. Si ningún candidato supera las reglas duras, devuelva ningún resultado en vez de relajar en silencio una restricción crítica. Si falla la autorización, no pida al modelo que explique información privada que nunca recibió. Si el modelo no está disponible, la búsqueda y los filtros deterministas todavía pueden servir al mapa. Si el resultado de una herramienta está mal formado, rechácelo durante la validación. Cuando un producto no tiene un modo degradado explícito, el modelo de lenguaje se convierte en el fallback accidental de infraestructura ausente.

La aprobación humana sigue el impacto, no una sola regla para cada botón. Mostrar tres lugares públicos es de bajo impacto. Confirmar una cita, despachar un vehículo, cambiar el registro de una instalación o enviar una reserva pagada no lo es. Clasifique búsqueda, recuperación y vista previa de ruta como bajo impacto. Una preferencia guardada o un borrador como impacto medio. Una compra, un despacho, una escritura operativa o un cambio de permisos como alto impacto. La ejecución automática, la confirmación del usuario y una aprobación separada pueden entonces corresponder a la clase. El AI Risk Management Framework de NIST es voluntario y está pensado para incorporar confiabilidad al diseño, desarrollo, uso y evaluación de productos de IA. La misma página de NIST indica que AI RMF 1.0 está siendo revisado (NIST, 2023). El marco proporciona contexto para las propias decisiones de riesgo del producto y no es una lista de controles de Kaleidr.

¿Dónde se sitúa el plano de control?

La ruta de solicitud gestiona trabajo en vivo: usuario, autorización, recuperación, herramientas espaciales, modelo, acción y respuesta. El plano de control decide cómo se permite ejecutar esa ruta. Credenciales, ámbitos, elección de modelo, prompts, políticas de herramientas, configuración de fuentes de datos, límites de tasa, entornos, suites de evaluación, feature flags y ajustes de auditoría viven allí. Separar ambos permite al equipo cambiar política sin reescribir cada flujo conversacional. Deshabilitar una herramienta de escritura no debería requerir una nueva interfaz. El plano de control es un patrón arquitectónico para esos ajustes, y el diagrama no afirma que un producto incluya cada cuadro.

Plano de control para credenciales, ámbitos, modelos, políticas de herramientas y evaluación, con flechas de política hacia una ruta de solicitud en vivo desde el usuario a través de autorización, recuperación, herramientas espaciales y acción.

La fila superior contiene configuración: credenciales, ámbitos, modelos, prompts, políticas de herramientas, fuentes de datos, límites, evaluación, flags y ajustes de auditoría. La fila inferior es la solicitud en vivo. La política apunta a las etapas que gobierna, de modo que un equipo pueda cambiar una regla sin reescribir la ruta.

La observabilidad debería seguir la decisión, no solo la factura de tokens. Entre los eventos útiles están intención resuelta, autorización aprobada o denegada, recuperación completada, candidatos eliminados por elegibilidad, cálculo espacial completado, ranking completado, respuesta sin resultado, herramienta propuesta, herramienta rechazada, acción de mapa ejecutada, lugar seleccionado y flujo de trabajo completado. Esos nombres son un patrón a diseñar, no una lista que una plataforma emite automáticamente. Las preguntas que responden son prácticas. ¿Los errores vienen de la resolución de lugares o del ranking? ¿Las personas rechazan una lista válida? ¿Un mercado produce más resultados vacíos? ¿Las llamadas a herramientas fallan por permisos o por argumentos mal formados? ¿La persona completó la tarea del host después de seleccionar un lugar? El núcleo del AI RMF de NIST dice que deben documentarse los conjuntos de pruebas, las métricas y los detalles sobre las herramientas usadas durante pruebas, evaluación, verificación y validación (NIST, 2023). Para Spatial AI, las pruebas documentadas deberían cubrir la decisión geográfica y empresarial, no solo la frase generada.

La analítica espacial y los resultados del host responden preguntas distintas, y la arquitectura debería unirlos con ID estables. Kaleidr Analytics describe actualmente dashboards de alcance, vistas y engagement, ubicación y actividad de la audiencia, sesiones, vistas e interacciones por mapa y patrones espaciales (Kaleidr, 2026). Reservas, compras, leads cualificados, despachos y servicios completados permanecen en los sistemas del host que los poseen. Un ID de recomendación puede apuntar a un ID de lugar seleccionado, después a un ID de flujo de trabajo del host y finalmente al resultado. El material público de analítica no dice que cada conversión empresarial se capture automáticamente.

¿Cuáles son los tres patrones de despliegue?

Tres patrones cubren la mayoría de despliegues empresariales, y ninguno es universalmente mejor. Un asistente de mapa público encaja en turismo, descubrimiento, mapas editoriales y exploración de eventos. El mapa del navegador usa una capacidad de cliente publicable, IA consciente del mapa, datos de lugares públicos o aprobados y herramientas espaciales, y luego devuelve una acción de mapa. El límite de datos es más simple porque el flujo de trabajo es principalmente público. Un asistente empresarial autenticado encaja en portales de clientes, selección de tiendas con inventario, inmobiliario, redes de socios e instalaciones privadas. El navegador accede a un login del host y a un backend del host, que aplica autorización de tenant y objeto antes de que los datos privados, herramientas espaciales y la explicación vuelvan al mapa. Un agente espacial con acciones empresariales encaja en reservas, despacho y flujos operativos. La ruta añade una propuesta de herramienta tipada, validación determinista, confirmación donde el impacto la requiere, el sistema de transacciones y una auditoría del resultado. Ese tercer patrón cambia estado empresarial, por lo que lleva la gobernanza más estricta.

Tres patrones de despliegue para un asistente de mapa público, un asistente empresarial autenticado y un agente espacial que valida acciones antes de una transacción.

El patrón público se mantiene en lugares públicos aprobados. El patrón autenticado mantiene registros privados detrás del host. El patrón de acciones añade validación y confirmación antes de una transacción. Las tarjetas de lugares de ejemplo en la figura son ilustrativas, no resultados medidos de Kaleidr.

¿Dónde encaja Kaleidr en esta arquitectura?

Kaleidr describe actualmente Enterprise como infraestructura de location intelligence para equipos de producto, con inference APIs, ranking, analítica y superficies SDK que un host puede añadir (Kaleidr, 2026). La documentación para desarrolladores enumera cuatro superficies en un SDK. Chat conecta interacción de IA a un mapa que el host ya ejecuta. Editor monta edición de mapas dentro de un producto. Tile sirve un basemap diseñado. Viewer publica un mapa para incrustarlo. La documentación actual de Chat enumera Mapbox, MapLibre y Google Maps como vías de integración para ese mapa propiedad del host (Kaleidr, 2026). El host conserva usuarios finales, autenticación, autorización de tenant, sistemas empresariales privados, reglas de flujo de trabajo, transacciones y resultados empresariales. Kaleidr añade superficies espaciales seleccionadas y no sustituye los sistemas que siguen siendo autoritativos en la pila del host.

Superficies de Kaleidr para Chat, Editor, Tile, Viewer, APIs de plataforma y Analytics junto a un host que mantiene usuarios, datos privados, flujos de trabajo, transacciones y resultados empresariales.

La fila del host mantiene usuarios, autorización de tenant, flujos de trabajo, sistemas privados, transacciones y resultados. Chat, Editor, Tile y Viewer se sitúan junto a APIs de plataforma y Analytics. Las etiquetas de credenciales siguen la separación pública navegador/servidor, y la figura no muestra un secreto real.

¿Qué errores permanecen ocultos hasta producción?

Conectar el modelo directamente a todos los sistemas crea privilegios excesivos y dificulta localizar la capa que falla. Tratar un prompt como la capa de autorización falla por la misma razón: un prompt puede orientar la redacción, pero no puede permitir o denegar un registro de forma determinista. Enviar toda la base de datos interna al contexto viola la minimización. Mezclar filtros estrictos con ranking deja que un lugar no elegible sobreviva dentro de un promedio. Pedir al modelo que estime una distancia que puede calcular el servicio espacial sustituye un cálculo por fluidez. Una sola herramienta sin restricciones, o una herramienta de escritura que hereda la política de una herramienta de lectura, da a una recomendación la autoridad de una transacción. Tratar el mapa como una imagen elimina los ID estables que necesita el siguiente turno. Supervisar solo latencia y coste de tokens omite resolución de lugares, elegibilidad, routing, ranking, fallos de herramientas y resultado del host. Un benchmark del modelo, por sí solo, no puede decir que el flujo ensamblado esté listo.

El borrador público inicial del marco TEVV-Athlon de NIST, NIST AI 200-2, anunciado el 7 de agosto de 2026 con comentarios abiertos hasta el 6 de octubre de 2026, describe la evaluación como evidencia de que un sistema cumple objetivos individuales u organizativos, con medición adaptada a la aplicación y a su impacto real, incluidos sistemas agénticos (NIST, 2026). El documento es un borrador que solicita aportes. El borrador no es una lista de controles de Kaleidr. Para esta arquitectura, el contexto de evaluación es la decisión dependiente de ubicación: intención, autorización, grounding, geografía, elegibilidad, ranking, herramientas, acciones, gestión de fallos y resultado del host.

¿Cómo se convierte la arquitectura empresarial de IA espacial en una puerta de lanzamiento?

Antes de que un piloto avance hacia producción, confirme los propietarios. El usuario está autenticado donde el flujo lo requiere y la pertenencia al tenant se resuelve fuera del modelo. Cada campo crítico tiene una fuente autoritativa, la recuperación privada ocurre antes de la inferencia, los campos se minimizan y los ID estables sobreviven al traspaso. Los servicios geográficos realizan los cálculos que el producto afirma realizar y las tolerancias usadas en evaluación están documentadas. Las herramientas son estrechas, lectura y escritura están separadas, los argumentos se validan y las acciones de alto impacto pueden confirmarse y auditarse. Las credenciales de navegador y servidor permanecen separadas, los ámbitos limitados y los entornos separados. El equipo puede ver la cadena de decisión y unir una selección de lugar con un resultado del host. Datos no disponibles, conjuntos de candidatos vacíos y modos degradados son explícitos, y las operaciones críticas fallan de forma cerrada en vez de inventar un hecho. Explore Kaleidr Enterprise para APIs de spatial intelligence, ranking, analítica y superficies SDK junto a la pila que el producto ya ejecuta. Lea la documentación para desarrolladores de Kaleidr para los contratos actuales de Chat, Editor, Tile, Viewer, claves y ámbitos antes de implementar.

Preguntas frecuentes

¿Qué es la arquitectura empresarial de IA espacial?

La arquitectura empresarial de IA espacial es el diseño de sistemas que conecta modelos de lenguaje, mapas, servicios geográficos, datos empresariales, permisos, herramientas, acciones y analítica, y mantiene cada responsabilidad en la capa que puede hacerla cumplir.

¿Debería un modelo de lenguaje tener acceso directo a una base de datos empresarial?

Por lo general, no como interfaz sin restricciones. Autorice al usuario actual, recupere el mínimo de registros que necesita la tarea, mantenga los campos estructurados y exponga herramientas estrechas. El acceso abierto a la base de datos convierte al modelo en el motor de permisos.

¿De qué debería ser responsable el modelo de lenguaje?

El modelo encaja con la intención en lenguaje natural, la orquestación entre capacidades aprobadas y la explicación de un resultado fundamentado. Autorización, transacciones, verdad empresarial y cálculos geográficos permanecen en los sistemas diseñados para esas funciones.

¿Cuál es la diferencia entre autenticación de plataforma y autorización de usuario?

La autenticación de plataforma establece que una aplicación puede usar una capacidad de la plataforma. La autorización de usuario decide qué persona o tenant puede acceder a un registro o ejecutar una acción empresarial. Una comprobación no sustituye a la otra.

¿Debería Spatial AI usar generación aumentada por recuperación?

La recuperación puede aportar documentos o registros relevantes. La recuperación por sí sola no establece autoridad. Inventario, disponibilidad, precio, permisos y pertenencia a áreas de servicio deberían seguir vinculados a sus sistemas de registro y a reglas deterministas.

¿Cómo deberían protegerse las herramientas de Spatial AI?

Use funciones estrechas, permisos mínimos, autorización en el contexto del usuario, validación de argumentos, límites de tasa, monitorización y una aprobación independiente para acciones de alto impacto. No trate al modelo ni al system prompt como mecanismo de autorización.

¿Deberían las acciones de Spatial AI requerir aprobación humana?

La aprobación sigue el impacto. Las acciones de mapa de bajo riesgo, como mostrar lugares, pueden ejecutarse automáticamente. Compras, reservas, despachos, escrituras administrativas y cambios de permisos pueden requerir confirmación explícita o una aprobación separada.

¿Cómo debería un asistente de mapa usar el mapa actual?

Pase estado estructurado como límites del viewport, ID de lugares seleccionados, filtros activos, ID de resultados visibles, ID de rutas y una ubicación con la precisión que necesita la tarea. No obligue al modelo a inferir el estado de la aplicación desde una captura de pantalla cuando existe estado estructurado.

¿Puede Spatial AI trabajar con un mapa existente?

Sí. Una capa de Spatial AI puede conectarse a un mapa y una aplicación que el host ya ejecuta. La documentación actual de Chat de Kaleidr describe cómo conectar Spatial AI conversacional a instancias de Mapbox, MapLibre o Google Maps ejecutadas por el host.

¿Cómo debería un equipo evaluar la arquitectura antes de escalar?

Evalúe el flujo ensamblado: intención, autorización, grounding, cálculos geográficos, elegibilidad, ranking, explicación, herramientas, acciones, gestión de fallos y resultados empresariales. Un benchmark general de modelos de lenguaje no sustituye esa prueba.

Referencias

  1. Kaleidr. Grounded Spatial AI for Business Data. https://kaleidr.com/blog/grounded-spatial-ai-business-data
  2. Kaleidr. Map API Authentication. https://kaleidr.com/blog/map-api-authentication
  3. Kaleidr. Get an API Key. Publishable browser keys and server keys. Accessed September 30, 2026. https://docs.kaleidr.com/get-an-api-key
  4. Kaleidr. Introduction. Chat, Editor, Tile, and Viewer in one SDK. Accessed September 30, 2026. https://docs.kaleidr.com/
  5. OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
  6. OWASP Gen AI Security Project. LLM07:2025 System Prompt Leakage. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/
  7. Kaleidr. How to Build a Map-Aware AI Assistant. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant
  8. National Institute of Standards and Technology. AI Risk Management Framework. Voluntary framework for trustworthiness in design, development, use, and evaluation. Released January 26, 2023. Page states that AI RMF 1.0 is being revised. Accessed September 30, 2026. https://www.nist.gov/itl/ai-risk-management-framework
  9. National Institute of Standards and Technology. AI RMF Core. Measure 2.1: test sets, metrics, and details about the tools used during TEVV are documented. Accessed September 30, 2026. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
  10. Kaleidr. Map Engagement and Location Analytics. Accessed September 30, 2026. https://kaleidr.com/analytics
  11. Kaleidr. Location Intelligence APIs and Map SDK. Accessed September 30, 2026. https://kaleidr.com/enterprise
  12. Kaleidr. Chat. Attach AI to a host-run Mapbox, MapLibre, or Google Maps instance. Accessed September 30, 2026. https://docs.kaleidr.com/chat
  13. National Institute of Standards and Technology. The TEVV-Athlon Framework for Evaluating AI Systems. NIST AI 200-2, initial public draft. Announced August 7, 2026; comments through October 6, 2026. https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems
  14. Kaleidr. Spatial AI Accuracy Evaluation. https://kaleidr.com/blog/spatial-ai-accuracy-evaluation
  15. Kaleidr. An Enterprise Spatial AI Pilot Before Scaling. https://kaleidr.com/blog/enterprise-spatial-ai-pilot-before-scaling
@misc{kaleidr_grounded_architecture_2026,
  title  = {Grounded Spatial AI for Business Data},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/grounded-spatial-ai-business-data}
}

@misc{kaleidr_map_api_auth_2026,
  title  = {Map API Authentication},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/map-api-authentication}
}

@misc{kaleidr_get_api_key_2026,
  title  = {Get an API Key},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://docs.kaleidr.com/get-an-api-key}
}

@misc{kaleidr_docs_intro_2026,
  title  = {Introduction},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026. Chat, Editor, Tile, and Viewer},
  url    = {https://docs.kaleidr.com/}
}

@misc{owasp_llm06_2025,
  title  = {LLM06:2025 Excessive Agency},
  author = {{OWASP Gen AI Security Project}},
  year   = {2025},
  note   = {Accessed September 30, 2026},
  url    = {https://genai.owasp.org/llmrisk/llm062025-excessive-agency/}
}

@misc{owasp_llm07_2025,
  title  = {LLM07:2025 System Prompt Leakage},
  author = {{OWASP Gen AI Security Project}},
  year   = {2025},
  note   = {Accessed September 30, 2026},
  url    = {https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/}
}

@misc{kaleidr_map_aware_2026,
  title  = {How to Build a Map-Aware AI Assistant},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant}
}

@misc{nist_ai_rmf_2023,
  title  = {AI Risk Management Framework},
  author = {{National Institute of Standards and Technology}},
  year   = {2023},
  note   = {Released January 26, 2023. Accessed September 30, 2026. Page states AI RMF 1.0 is being revised},
  url    = {https://www.nist.gov/itl/ai-risk-management-framework}
}

@misc{nist_ai_rmf_core_2023,
  title  = {AI RMF Core},
  author = {{National Institute of Standards and Technology}},
  year   = {2023},
  note   = {Measure 2.1. Accessed September 30, 2026},
  url    = {https://airc.nist.gov/airmf-resources/airmf/5-sec-core/}
}

@misc{kaleidr_analytics_architecture_2026,
  title  = {Map Engagement and Location Analytics},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://kaleidr.com/analytics}
}

@misc{kaleidr_enterprise_architecture_2026,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{kaleidr_chat_docs_2026,
  title  = {Chat},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://docs.kaleidr.com/chat}
}

@techreport{nist_ai_200_2_2026,
  title       = {The TEVV-Athlon Framework for Evaluating AI Systems},
  author      = {{National Institute of Standards and Technology}},
  institution = {National Institute of Standards and Technology},
  number      = {NIST AI 200-2},
  year        = {2026},
  note        = {Initial public draft, announced August 7, 2026},
  url         = {https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems}
}