Preguntas Frecuentes

NEXMO es un espacio de datos especializado en movilidad y logística que ayuda a organizaciones públicas y privadas a compartir y consumir datos de forma segura, trazable y bajo condiciones pactadas, para construir casos de uso de valor real.

Una plataforma tradicional suele centralizar datos en un repositorio. NEXMO se plantea como un ecosistema federado: cada participante mantiene control sobre sus datos y los comparte con otros para generar casos de uso de valor, utilizando conectores, contratos de uso, políticas de acceso, identidad y trazabilidad. La clave no es "subir datos a NEXMO", sino habilitar intercambios controlados entre participantes.

Porque puede transformar datos que hoy están infrautilizados en nuevas fuentes de eficiencia, ingresos, cumplimiento regulatorio, sostenibilidad o colaboración con terceros. Además, NEXMO reduce la fricción técnica, legal y comercial de compartir datos con otros actores del ecosistema.

Resuelve tres bloqueos habituales: falta de confianza para compartir datos, dificultad técnica para interoperar con terceros y ausencia de un modelo claro de valor. NEXMO ayuda a definir qué datos compartir, con quién, bajo qué condiciones, con qué retorno y mediante qué arquitectura segura.

No. La tecnología es necesaria, pero el valor de NEXMO está en combinar tecnología, gobernanza, contratos, casos de uso, comunidad, estándares e intermediación. En muchos proyectos, el reto principal no es conectar APIs, sino acordar reglas, incentivos, responsabilidades y modelos de explotación.

NEXMO puede prestar servicios de identificación y diseño de casos de uso, evaluación de activos de datos, preparación de productos de datos, onboarding en el espacio, publicación en catálogo, configuración de conectores, diseño de políticas de uso, soporte legal-operativo, generación de pilotos y acompañamiento en modelos de negocio basados en datos.

Significa que está orientado a casos de uso donde intervienen datos de transporte público, movilidad compartida, logística urbana, infraestructura viaria, emisiones, aparcamiento, incidencias, seguridad vial, planificación urbana, MaaS, movilidad laboral y otros dominios relacionados.

No. Una de las prioridades debe ser reducir barreras para PYMES, startups, operadores locales y entidades públicas. La participación puede modularse: desde un diagnóstico de caso de uso o la publicación de un producto de datos sencillo hasta integraciones técnicas más avanzadas.

Puede acceder a mejores datos para planificar, regular, medir impactos, diseñar incentivos, reducir emisiones, mejorar la seguridad vial o evaluar políticas públicas. También puede publicar sus propios datos con más gobernanza y entender mejor quién los consume y para qué.

Puede monetizar activos de datos, mejorar operaciones con datos de terceros, generar nuevos servicios, participar en pilotos público-privados, mejorar cumplimiento, posicionarse en economía del dato y explorar modelos win-win sin perder el control de sus datos.

Puede actuar como proveedor de datos, consumidor de datos, proveedor de servicios de valor añadido, intermediario técnico, entidad tractora de casos de uso, validador sectorial o participante institucional. Una misma organización puede tener varios roles según el caso de uso.

Significa poner a disposición de otros participantes un conjunto de datos, API, indicador, servicio analítico o producto de información bajo condiciones definidas. El proveedor decide qué ofrece, a quién, con qué finalidad, con qué restricciones y bajo qué modelo económico.

Significa acceder a datos o servicios de otros participantes para resolver un problema concreto: optimizar rutas, estimar demanda, reducir emisiones, mejorar seguridad, alimentar un algoritmo, enriquecer un dashboard o desarrollar un nuevo producto.

Es el proceso de incorporación de una organización al espacio de datos. Incluye validar su identidad, entender su rol, definir sus activos o necesidades de datos, aceptar las reglas de participación, preparar los contratos aplicables y, cuando corresponda, configurar el acceso técnico.

Depende del nivel de participación. Para una fase inicial puede bastar con una ficha de organización, una ficha de caso de uso, una descripción de datos y una revisión básica legal-técnica. Para una integración productiva se añaden conectores, APIs, políticas, pruebas de seguridad y acuerdos operativos.

No necesariamente. Una organización puede empezar como observadora, participar en talleres, definir un caso de uso, evaluar activos de datos o consumir datos de terceros. La publicación de datos debe hacerse cuando exista un caso de uso, un incentivo claro y unas condiciones suficientemente definidas.

Normalmente: datos de contacto, rol esperado, problema de negocio, datos que podría aportar o necesitar, restricciones de confidencialidad, sistemas actuales, nivel de madurez técnica, requisitos legales y expectativas de retorno.

Sí. Es recomendable empezar por pilotos acotados con objetivos medibles, pocos participantes, datos bien definidos y un contrato claro. El piloto permite validar valor antes de escalar a un servicio recurrente.

Debe existir un proceso de offboarding: cierre de accesos, finalización de contratos, tratamiento de datos ya compartidos, obligaciones de eliminación o retención, continuidad de auditorías y resolución de obligaciones económicas pendientes.

Cumplir las reglas de participación, respetar las políticas de uso de datos, mantener medidas razonables de seguridad, no reutilizar datos fuera de las finalidades pactadas, colaborar en auditorías cuando aplique y comunicar incidencias relevantes.

Las reglas deben estar definidas por una autoridad o entidad de gobernanza del espacio, con mecanismos de participación de los miembros. La gobernanza debe equilibrar neutralidad, agilidad, representación de actores y protección de intereses legítimos.

Incluye criterios de entrada y salida, roles, derechos y obligaciones, mecanismos de decisión, gestión de conflictos, reglas de publicación y consumo, políticas de uso, seguridad, tratamiento de incumplimientos, KPIs, sostenibilidad económica y evolución técnica.

Con reglas transparentes, procesos no discriminatorios, órganos de gobernanza equilibrados, criterios objetivos de acceso, separación entre operación técnica y decisiones de comunidad, y mecanismos de resolución de conflictos.

La gobernanza del espacio define las reglas generales para todos. El contrato de datos regula un intercambio concreto entre proveedor y consumidor: qué dato, para qué finalidad, durante cuánto tiempo, con qué restricciones, precio, SLA, responsabilidades y medidas de seguridad.

Debe existir un procedimiento escalonado: revisión operativa, mediación por la entidad de gobernanza, suspensión temporal si hay riesgo, auditoría si procede y, en último término, mecanismos contractuales o legales. La clave es que las reglas sean conocidas antes de compartir datos.

Sí. Un espacio de datos debe evolucionar. Al principio conviene una gobernanza ligera para facilitar pilotos. A medida que crecen los casos de uso y el volumen de transacciones, se requieren reglas más completas, KPIs, comités, auditorías y modelos económicos más formales.

Soberanía del dato, trazabilidad, seguridad, proporcionalidad, transparencia, equidad, neutralidad, interoperabilidad, cumplimiento normativo, orientación a valor y facilidad de adopción por parte de PYMES y entidades públicas.

Sí. Por ejemplo: observador, participante piloto, proveedor de datos, consumidor recurrente, socio estratégico, proveedor tecnológico o miembro institucional. Cada nivel puede tener derechos, servicios y costes diferentes.

Mediante catálogo, reglas de publicación, metadatos claros, trazabilidad de accesos, contratos de uso, auditoría, indicadores de actividad y comunicación transparente a la comunidad.

Con KPIs como número de participantes activos, productos de datos publicados, contratos firmados, transacciones realizadas, tiempo medio de onboarding, incidencias resueltas, satisfacción de participantes, casos de uso escalados y valor económico o social generado.

Se pueden monetizar datasets, APIs, indicadores agregados, servicios analíticos, informes, algoritmos, acceso recurrente, servicios de integración, consultoría, certificación, soporte técnico, participación en pilotos y resultados derivados de casos de uso.

No necesariamente. Puede haber intercambio gratuito, acceso condicionado, reciprocidad de datos, pago por uso, suscripción, revenue share, pago por resultado, patrocinio de pilotos, modelos freemium o compensación no monetaria como visibilidad, aprendizaje o acceso preferente a servicios.

Se debe considerar coste de generación, calidad, exclusividad, frecuencia, criticidad para el caso de uso, ahorro o ingresos que genera al consumidor, riesgo asumido, nivel de soporte, SLA, grado de transformación y número de consumidores potenciales.

Es un modelo donde el proveedor recibe compensación o retorno suficiente para compartir datos y el consumidor obtiene valor superior al coste de acceso. En movilidad suele incluir además impacto público: reducción de emisiones, congestión, accidentes, tiempos de espera o costes operativos.

Sí. Por ejemplo, dos operadores pueden intercambiar datos agregados para mejorar predicciones; una administración puede aportar datos abiertos de calidad y recibir indicadores agregados; una empresa puede participar en un piloto a cambio de resultados analíticos o posicionamiento.

Es una opción de sostenibilidad, pero no la única. NEXMO puede combinar membresías, servicios profesionales, tarifas de onboarding, soporte técnico, comisiones por transacción, cuotas por uso de infraestructura, financiación pública, proyectos de I+D y patrocinios.

Con precios proporcionales al valor y al tamaño del participante, pilotos de bajo coste, paquetes para PYMES, servicios modulares, transparencia de tarifas y mecanismos de retorno claro para proveedores y consumidores.

Puede obtener insights agregados, benchmarking, mejora reputacional, acceso a datos de terceros, participación en proyectos financiados, reducción de costes operativos o cumplimiento de requisitos de administraciones y clientes.

Debe definirse caso por caso: titularidad del resultado, derechos de explotación, posibilidad de comercialización, reparto de ingresos, acceso por parte de cada participante, restricciones de publicación y protección de información sensible.

Antes del piloto se define una hipótesis de valor: ahorro de tiempo, reducción de km, mejora de ocupación, reducción de emisiones, incremento de demanda, reducción de fraude, mejora de planificación o nuevo ingreso. Después se mide contra una línea base y se decide si escalar.

Datos estáticos, dinámicos, históricos, agregados, anonimizados, geoespaciales, incidencias, disponibilidad, flujos, demanda, tiempos, emisiones, ocupación, sensores, operaciones logísticas, infraestructura, movilidad laboral, activos de transporte y resultados analíticos.

No. Pero sí deben describirse honestamente: cobertura, frecuencia, calidad, formato, limitaciones, actualización, posibles sesgos y usos adecuados. Muchas veces NEXMO puede ayudar a convertir datos imperfectos en productos útiles mediante limpieza, agregación y documentación.

Es una oferta de datos preparada para ser entendida y consumida por terceros. Incluye contenido, metadatos, formato, frecuencia, condiciones de uso, precio o modelo de acceso, calidad esperada, soporte, restricciones y forma técnica de consumo.

Un dataset suele ser un conjunto de ficheros o registros. Una API permite acceso programático. Un servicio de datos puede incluir además transformación, agregación, análisis, indicadores, alertas o modelos predictivos. En NEXMO conviene pensar en productos de datos, no solo en ficheros.

Es el escaparate controlado donde se describen los productos de datos disponibles. No necesariamente contiene los datos, sino la descripción de qué existe, quién lo ofrece, cómo se puede solicitar, bajo qué condiciones y cómo se accede técnicamente.

Sí. El catálogo puede aplicar distintos niveles de visibilidad: público, visible para miembros, visible para un grupo, bajo invitación o bajo aprobación expresa del proveedor.

Nombre, descripción, proveedor, cobertura geográfica, cobertura temporal, frecuencia de actualización, formato, método de acceso, calidad, restricciones, finalidad permitida, precio o modelo de compensación, contacto, SLA, sensibilidad y requisitos de seguridad.

Interoperabilidad significa que sistemas y organizaciones distintas pueden entenderse técnica, semántica, legal y organizativamente. Sin interoperabilidad, cada integración es artesanal, cara y difícil de escalar.

Depende del caso: GTFS, GTFS-RT, NeTEx, SIRI, DATEX II, MDS, GBFS, DCAT, NGSI-LD, modelos FIWARE, vocabularios propios de movilidad y otros estándares sectoriales. La recomendación es usar estándares existentes siempre que sean adecuados y documentar las extensiones.

Se define un modelo mínimo común para el piloto, se documentan los campos y se activa vigilancia tecnológica para migrar cuando el estándar madure. La prioridad es no bloquear el caso de uso, pero evitar soluciones propietarias difíciles de federar.

Es el componente que permite a un participante publicar, negociar y transferir datos de forma controlada con otro participante. En términos sencillos, es la "puerta segura" que conecta a una organización con el espacio de datos sin obligarla a entregar todos sus datos a un tercero.

No como principio general. El enfoque federado busca que los datos permanezcan en origen cuando sea posible. NEXMO facilita descubrimiento, negociación, políticas, transferencia y trazabilidad. Puede haber almacenamiento temporal o datasets derivados si el caso de uso lo requiere y está pactado.

El enfoque está alineado con estándares europeos como GAIA-X, IDSA y Dataspace Protocol. En la capa de conectividad se contemplan conectores compatibles, como Eclipse Dataspace Connector o distribuciones basadas en EDC, junto con identidad, catálogo, políticas y registro de transacciones.

EDC, Eclipse Dataspace Components/Connector, es una tecnología open source para implementar conectores y capacidades de intercambio de datos en espacios de datos. Permite separar negociación, control de acceso y transferencia de datos.

Es un protocolo impulsado en el ecosistema IDSA para que conectores compatibles puedan comunicarse, negociar contratos y ejecutar transferencias. Su objetivo es evitar integraciones propietarias y facilitar la interoperabilidad entre espacios de datos.

GAIA-X aporta un marco de confianza, identidad, cumplimiento y descripciones verificables para servicios y participantes. Para un cliente, el mensaje práctico es que NEXMO busca alinearse con estándares europeos de confianza y soberanía, no crear un sistema cerrado.

Un gestor de identidad permite autenticar usuarios y servicios, gestionar roles y controlar quién puede acceder a qué. Es una pieza habitual para reforzar autorización, trazabilidad y separación de permisos.

Depende del caso. Puede usar conectores gestionados, conectores dedicados, APIs ya existentes o entornos sandbox. Para empezar, lo recomendable es minimizar fricción y escalar la infraestructura solo cuando haya valor validado.

Sí. En muchos casos, el conector o el servicio de intermediación se apoya en APIs existentes del participante. No se trata de rehacer los sistemas internos, sino de exponerlos de forma controlada y contractualizada.

El plano de control decide quién puede acceder, bajo qué contrato y con qué política. El plano de datos ejecuta la transferencia real. Esta separación permite gobernar el intercambio sin imponer una única forma de mover los datos.

Significa que el proveedor mantiene capacidad de decisión sobre quién usa sus datos, para qué, durante cuánto tiempo, con qué restricciones y bajo qué condiciones económicas o legales. No implica bloquear el uso, sino compartir con control.

Con autenticación, autorización, cifrado en tránsito, control de accesos, segmentación de entornos, registro de operaciones, contratos de uso, revisión de APIs, gestión de incidentes y medidas específicas según sensibilidad del dato.

Aplicando minimización, anonimización o agregación cuando sea necesario, evaluando si hay datos personales, definiendo roles RGPD, limitando finalidades, reduciendo granularidad, evitando reidentificación y documentando el tratamiento.

Puede haber casos donde existan datos personales o pseudonimizados, pero deben tratarse con especial cuidado, base jurídica adecuada, contratos específicos, análisis de riesgos y medidas de privacidad desde el diseño. En muchos casos de movilidad conviene trabajar con datos agregados o anonimizados.

Es la capacidad de saber qué se ha publicado, quién ha accedido, cuándo, bajo qué contrato, con qué política y qué transferencia se ha realizado. La trazabilidad no solo aporta seguridad; también permite facturación, auditoría y confianza.

Mediante contrato, políticas de uso legibles por máquina cuando sea posible, controles técnicos, auditoría, trazabilidad, sanciones contractuales y diseño del producto de datos para limitar el riesgo, por ejemplo entregando datos agregados en vez de datos brutos.

Debe activarse un procedimiento de gestión de incidentes: contención, análisis, comunicación a partes afectadas, evaluación de obligaciones regulatorias, medidas correctivas, registro del incidente y revisión de controles para evitar recurrencia.

El RGPD aplica cuando se tratan datos personales. En cada caso hay que determinar si los datos son personales, anonimizados o agregados; quién es responsable o encargado; cuál es la base jurídica; y qué medidas de privacidad y seguridad son necesarias.

La Data Governance Act refuerza la confianza en mecanismos voluntarios de intercambio de datos y servicios de intermediación. La Data Act, aplicable desde septiembre de 2025, aporta claridad sobre acceso y uso de datos, especialmente datos generados por productos conectados. NEXMO debe diseñarse compatible con este marco europeo.

No. NEXMO puede facilitar modelos, checklists y contratos base, pero cada organización debe validar sus obligaciones específicas, especialmente en privacidad, competencia, confidencialidad, propiedad intelectual, contratación pública y datos regulados.

Normalmente se firma un acuerdo de participación en el espacio y, para cada intercambio, un contrato o anexo específico de datos. Este anexo debe describir dataset, finalidad, permisos, prohibiciones, duración, precio, responsabilidades, seguridad, confidencialidad, auditoría y terminación.

Son reglas que indican qué se puede y no se puede hacer con los datos: uso permitido, prohibición de reventa, obligación de agregación, límite temporal, territorio, finalidad, destinatarios, conservación, borrado, atribución o uso solo para un piloto.

Sí. Estándares como ODRL permiten expresar políticas de forma estructurada. En la práctica, conviene que la política exista en dos niveles: lenguaje claro para negocio y representación técnica cuando sea necesario para automatizar controles.

Salvo pacto distinto, el proveedor conserva sus derechos sobre los datos originales. El consumidor obtiene un derecho de uso limitado por contrato. Los resultados derivados deben regularse expresamente para evitar ambigüedades.

Se debe definir una gobernanza de derivados: quién puede usarlos, si pueden comercializarse, cómo se reparten ingresos, qué nivel de agregación exige cada proveedor y si hay límites para identificar contribuciones individuales.

Sí. Es una cláusula habitual. También puede permitirse reventa solo de resultados agregados, solo con autorización previa o bajo reparto de ingresos.

Es un compromiso de servicio: disponibilidad, frecuencia de actualización, latencia, soporte, tiempo de respuesta, calidad mínima, formato y procedimiento ante incidencias. No todos los pilotos requieren SLA fuerte, pero los servicios productivos sí.

Mediante cláusulas que definen información confidencial, personas autorizadas, medidas de protección, excepciones, duración, retorno o destrucción de información y consecuencias de incumplimiento.

Reduciendo granularidad, agregando datos, aplicando retardos temporales, suprimiendo identificadores, limitando acceso a determinados perfiles, revisando competencia y definiendo finalidades concretas.

En parte. La negociación y ejecución técnica puede apoyarse en políticas y conectores, pero el acuerdo legal y de negocio debe estar claro. La automatización no elimina la necesidad de gobernanza y responsabilidad humana.

Debe partir de un problema real, tener usuarios claros, datos disponibles o accesibles, proveedores y consumidores identificados, hipótesis de valor medible, bajo riesgo inicial, viabilidad técnica y un camino de escalado.

Casos donde ningún actor tiene todos los datos: movilidad laboral sostenible, logística urbana y carga/descarga, seguridad bici-peatón, incidencias viarias para transporte interurbano, emisiones, aparcamiento, predicción de demanda, multimodalidad, accesibilidad e incentivos a modos sostenibles.

Fase 1: problema e hipótesis. Fase 2: actores y datos. Fase 3: contrato y privacidad. Fase 4: integración técnica. Fase 5: ejecución y medición. Fase 6: decisión de escalado y modelo económico.

Ficha de caso de uso, mapa de actores, inventario de datos, propuesta de producto de datos, modelo de valor, diseño de gobernanza, contrato o términos de intercambio, arquitectura técnica, resultados medidos y recomendación de escalado.

Debe ser corto y enfocado. Lo razonable es trabajar en ciclos de 8 a 12 semanas para validar valor, siempre que los datos estén accesibles. Si hay integración compleja o temas legales sensibles, puede requerir una fase previa de preparación.

No siempre se necesitan datos en tiempo real. Muchas veces se puede empezar con históricos, muestras, datos agregados o datos sintéticos para validar el caso. La conexión en tiempo real se justifica cuando el caso de uso ya ha demostrado valor.

Se puede trabajar con indicadores, agregados, APIs restringidas, datos anonimizados, entornos seguros, ejecución de algoritmos cerca del origen o resultados derivados. Compartir no siempre significa entregar el dato bruto.

Con criterios acordados: valor económico, impacto ambiental o social, calidad de datos, coste operativo, interés de participantes, repetibilidad, riesgos legales, madurez técnica y viabilidad comercial.

La IA puede generar valor al fusionar datos, predecir demanda, optimizar rutas, detectar anomalías, estimar emisiones, simular escenarios o construir indicadores. Pero la IA depende de datos de calidad, permisos claros y gobernanza adecuada.

Desde el inicio se define quién paga, quién se beneficia, qué decisión mejora, qué métrica se moverá y qué condiciones permitirán escalar. Un piloto sin modelo de explotación es una demo; un piloto con hipótesis de valor es una oportunidad de negocio.

Precisamente por eso NEXMO propone compartir con soberanía: se puede limitar finalidad, granularidad, destinatarios, duración y reutilización. También se puede empezar con datos agregados o derivados para validar valor sin exponer datos sensibles.

Las APIs resuelven conectividad, pero no necesariamente confianza, gobernanza, contratos, catálogo, trazabilidad, interoperabilidad, modelo de valor o escalabilidad multi-actor. NEXMO ayuda a convertir APIs en productos de datos gobernados.

Puede serlo si se intenta desplegar todo desde el primer día. La recomendación es empezar con un caso de uso acotado, bajo riesgo, pocos datos y objetivos medibles. NEXMO debe modular servicios para que la entrada sea proporcional al valor esperado.

Es normal. Uno de los servicios iniciales de NEXMO es identificar activos de datos, cruzarlos con problemas reales y priorizar oportunidades. El valor no está solo en el dato, sino en la decisión o servicio que habilita.

La calidad debe medirse frente al caso de uso, no de forma abstracta. Datos imperfectos pueden ser suficientes para tendencias, baseline o simulaciones. Si se requiere producción, se define un plan de mejora y calidad mínima.

El enfoque de NEXMO debe basarse en estándares abiertos, componentes compatibles con GAIA-X/IDSA/DSSC, APIs documentadas y portabilidad. La meta es reducir lock-in, no crear otro silo.

El acceso se controla por contrato, políticas, visibilidad de catálogo y autorización. Además, se pueden usar agregaciones, retardos, límites de finalidad y grupos cerrados para evitar exposición competitiva.

El valor de un espacio de datos crece con la comunidad, pero no hace falta esperar a tener muchos miembros. Se puede empezar con casos bilaterales o trilaterales y diseñarlos para que luego sean replicables.

Depende del tipo de dato y sector. La tendencia europea va hacia más acceso, reutilización e interoperabilidad, pero NEXMO se posiciona sobre todo como una forma voluntaria, segura y orientada a valor de anticiparse y aprovechar la economía del dato.

Una primera reunión debería acabar con una hipótesis de caso de uso, una lista inicial de datos disponibles o necesarios, posibles participantes, barreras principales y una propuesta de siguiente paso: diagnóstico, workshop, piloto o integración.