Todo proyecto de IoT empieza con una decisión de plataforma que parece reversible. Eliges un proveedor, conectas unos cuantos dispositivos, construyes un dashboard y lanzas. Dos años después tienes diez mil dispositivos reportando, una compilación de firmware a medida atada a una sola nube y tres años de datos históricos que no puedes sacar en ningún formato aprovechable. La decisión nunca fue reversible. Solo lo parecía al principio, y esa brecha entre cómo se sentía y cómo era en realidad es justo donde vive el vendor lock-in.
El lock-in no es una sola trampa. Son cuatro trampas distintas, y la mayoría de los compradores solo verifica una de ellas antes de firmar. Este artículo desglosa cada tipo, te da la pregunta concreta que debes hacerle a un proveedor para detectarlo y es honesto sobre el hecho de que la única forma de llegar a un lock-in cercano a cero es asumir trabajo que quizá no quieras.
El lock-in de datos es el caro
Tus datos históricos son el activo que crece cada día y lo más difícil de mover. Si una plataforma almacena tu telemetría en un formato propietario y solo te deja leerla de vuelta a través de su propio dashboard, no eres dueño de esos datos en ningún sentido práctico. Puedes verlos. No puedes irte con ellos.
La pregunta de prueba: “¿Puedo exportar todos mis datos históricos en bruto, y en qué formato?”. Ve más allá de la respuesta de marketing. Un vago “sí, puedes exportar tus datos” no es lo mismo que una exportación masiva documentada a CSV, JSON o una lectura directa de la base de datos. Pregunta si la exportación cubre los payloads en bruto del dispositivo o solo los valores agregados que el dashboard muestra. Pregunta si hay un límite de filas o una ventana de tiempo. Pregunta cuánto cuesta extraer años de datos de una sola vez, porque para conjuntos de datos grandes la transferencia y las horas de ingeniería para darle nueva forma pueden convertirse en la factura real.
El lock-in de datos es el que hay que combatir con más fuerza, porque es el único tipo que empeora cuanto más tiempo te quedas.
El lock-in de dispositivo y protocolo decide si tu hardware viaja
Si una plataforma exige su propio firmware, su propio SDK o un protocolo de transporte cerrado para poner un dispositivo en línea, tu hardware queda casado con esa plataforma. Cambia de nube y tendrás que reflashear cada unidad en campo, lo que en una flota desplegada no es una migración, es una retirada del producto.
La pregunta de prueba: “¿Mi dispositivo se conecta sobre estándares abiertos, o necesito tu firmware?”. Los protocolos abiertos son lo que mantiene portátiles los dispositivos. MQTT es el habitual para telemetría: está publicado, ampliamente implementado, y tu dispositivo lo habla igual ante cualquier broker. Para redes de sensores de largo alcance, LoRaWAN cumple el mismo papel, con las capas de servidor de red y de aplicación definidas por una especificación abierta en lugar de por una sola empresa. Un dispositivo que habla MQTT plano o que vive en una red LoRaWAN estándar puede apuntarse a un nuevo endpoint con un cambio de configuración en vez de una visita en campo. Un dispositivo que solo habla el protocolo propietario de un proveedor no puede.
El lock-in de integración trata sobre si puedes construir alrededor de la plataforma
Una plataforma que no puedes programar es una plataforma que no puedes superar. Si la única forma de meter o sacar datos es a través de las propias pantallas del proveedor, cada flujo de trabajo que llegues a necesitar tiene que existir ya como funcionalidad, o te quedas esperando una hoja de ruta.
La pregunta de prueba: “¿Hay una API REST documentada que cubra todo lo que hace el dashboard, o solo una parte?”. La versión honesta de esta pregunta importa. Muchas plataformas tienen una API que lee datos pero no puede aprovisionar un dispositivo, o una que maneja dispositivos pero no la gestión de usuarios. Quieres cobertura completa: crear dispositivos, enviar y extraer datos, gestionar usuarios, configurar lo que de otro modo harías a golpe de clic. Si la API es un subconjunto del producto, el resto del producto es un muro.
El lock-in contractual es el que está escrito en lenguaje llano
El último tipo no es técnico en absoluto. Es la duración del contrato, la cláusula de renovación automática, el precio por dispositivo que castiga el crecimiento y el nivel de soporte que tienes que comprar para mantener todo funcionando. Nada de esto está oculto. Está en el contrato, que es por lo que es lo más fácil de revisar y lo que más a menudo se pasa por alto.
La pregunta de prueba: “¿Cuál es el plazo de aviso para irse, y mi acceso a la exportación sobrevive al final del contrato?”. Una función de exportación que pierdes el día que caduca tu suscripción no es portabilidad. Lee las condiciones de salida antes que las de entrada.
El intercambio honesto: software de código abierto que tú mismo alojas
Si el lock-in es el enemigo, la opción de menor lock-in es el software de código abierto que ejecutas tú mismo. ThingsBoard es el más conocido, y TagoCore es nuestro propio runtime de borde de código abierto. Tú tienes el código, la base de datos y el despliegue. Nadie puede cambiar tus condiciones, descontinuar tu plan ni retener tus datos, porque todo eso reside en infraestructura que tú controlas.
Esa libertad tiene un precio, y no está en dólares. Cuando alojas tú mismo, eres dueño de las operaciones. Tú parcheas los servidores, tú escalas la base de datos cuando sube el número de dispositivos, tú manejas el corte de las 3 de la madrugada, tú cargas con la postura de seguridad. El lock-in que eliminaste queda reemplazado por una carga operativa que ahora pertenece a tu equipo. Para algunas organizaciones con la profundidad de ingeniería y las ganas, ese es el intercambio correcto. Para la mayoría no lo es, y fingir lo contrario no le hace ningún favor a nadie.
Así que la verdadera pregunta no es “gestionada o código abierto”. Es “qué tipos de lock-in estoy dispuesto a aceptar a cambio de que otro ejecute la plataforma”. Toda plataforma gestionada conlleva algo de lock-in. Esa es la naturaleza de un servicio gestionado. La meta es minimizar los tipos costosos, tus datos y tus dispositivos, y aceptar el resto como el costo de no operar infraestructura.
Dónde encaja TagoIO
TagoIO es una plataforma gestionada. Eso significa que no es lock-in cero, y preferimos decirlo con claridad en vez de disfrazarlo. Lo que hacemos es empujar el lock-in hacia los tipos que menos duelen.
En datos, TagoIO admite exportar tus datos, así que tu historial no vive en una caja de un solo sentido. En dispositivos, habla MQTT y funciona con datos de dispositivos LoRaWAN estándar, así que tu hardware no queda atado a una compilación de firmware propietaria para hablar con nosotros. En integración, hay una API REST completa que cubre lo que hace la plataforma, así que puedes construir, aprovisionar y automatizar alrededor de ella en lugar de esperar una solicitud de funcionalidad. La plataforma es multi-tenant y ejecuta TagoRUN para despliegues de marca blanca, está certificada ISO 27001 y alineada con GDPR, y el mismo enfoque de protocolos abiertos se extiende hasta el borde a través de TagoCore, que es de código abierto si quieres ejecutar esa parte tú mismo.
Sigues estando en un servicio gestionado, y sigue habiendo un costo de cambio si te vas. Lo que no hay es un formato de datos cerrado ni un candado de firmware que convierta el irse en una reconstrucción.
Próximos pasos
Antes de comprometerte con cualquier plataforma de IoT, hazle las cuatro preguntas de prueba: formato de exportación, protocolos abiertos, API completa, condiciones de salida. Luego contrasta las respuestas con la plataforma misma.
- Mira cómo funcionan la conectividad de dispositivos y los datos en TagoIO
- Lee los detalles de la API y la integración en la documentación de TagoIO
- Compara planes y costos por dispositivo en los precios de TagoIO
Una plataforma que da respuestas claras a las cuatro preguntas es una de la que puedes irte. Esa es justo la razón por la que deberías sentirte seguro al quedarte.
