De prototipo IoT a producción: qué cambia en un proyecto

Llevar un prototipo IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil a producción es sobre todo el trabajo que la demo no enseñaba: instalar, actualizar, certificar y dar soporte a escala.

Piensa en un piloto que salió bien. Veinticinco sensores de nivel LoRaWANProtocoloLoRaWANLPWAN abierta de largo alcance y bajo consumoVer perfil en los depósitos de una empresa de aguas, firmware cargado desde un portátil, claves de dispositivo tecleadas en un formulario web y un panel que el ingeniero del proyecto revisa cada mañana. A los cuatro meses las lecturas coinciden con las medidas manuales, y el cliente hace la pregunta lógica: ¿podemos tenerlo en los 300 emplazamientos, unos 1.200 equipos, antes de primavera?

Del piloto, casi nada sobrevive intacto a esa pregunta. Los sensores funcionaron. Lo que no escala es todo lo que los rodea: cómo recibe cada equipo su identidad, cómo le llega el firmware cuando ya está atornillado a un depósito, a quién se despierta cuando uno rebosa y cuánto cuesta una visita cuando el emplazamiento está a dos horas.

Es un punto de fallo bien documentado. En una encuesta de Cisco de 2017 a 1.845 responsables de TI y de negocio, el 60 % de las iniciativas IoT se quedaban atascadas en la prueba de concepto, y solo el 26 % de las empresas había tenido alguna que considerara un éxito completo. La encuesta tiene años. El patrón que describe es el mismo con el que siguen tropezando integradores y fabricantes de dispositivos.

Esta guía repasa qué cambia al pasar de prototipo IoT a producción (equipos y certificación, alta de dispositivos, actualizaciones de firmware, alertas y modelo de costes) y termina con una lista de comprobación para revisar antes de que el cliente firme el despliegue.

Por qué un prototipo IoT se atasca antes de producción

Un prototipo responde a una pregunta: ¿se puede medir esto con la fiabilidad suficiente para que sirva? Producción plantea otra distinta: ¿puede funcionar durante años, operado por gente que no lo construyó, con un coste que el contrato soporte?

La mayoría de los pilotos se montan para contestar la primera pregunta cuanto antes, y es lo correcto. El problema es que los atajos que hacen rápido un piloto son los mismos que bloquean el despliegue:

• Claves de dispositivo tecleadas a mano, o una misma clave compartida por todos los equipos.
• Firmware cargado por USB, sin forma de actualizar un equipo una vez instalado.
• Un panel que mira un solo ingeniero, con umbrales ajustados a ojo.
• Un intervalo de envío elegido para que la demo se vea viva, no pensando en la batería ni en la normativa de radio.
• Cuentas de plataforma y de conectividad en un plan gratuito o con el usuario personal de alguien.
• Ninguna estimación escrita de lo que cuesta operar un equipo al mes.

Nada de esto es un error en un piloto. Cada punto se convierte en un proyecto propio cuando el pedido es 50 veces mayor, y el cliente suele esperar que el despliegue arranque al precio y a la velocidad del piloto.

La solución pasa por decidir pronto qué atajos son provisionales y sustituirlos antes de presupuestar el despliegue, no después. Fuera del IoT se ve la misma brecha: la distancia entre un piloto de IA y un despliegue en producción sale del mismo sitio, una operación que nadie costeó durante la demo.

Ayuda escribir la lista al revés: qué sustituye a cada atajo cuando el proyecto pasa a producción. La página de funcionalidades de la plataforma sirve de referencia para ver qué suele incluir esa capa.

Del kit de desarrollo a un equipo que se instala 1.200 veces

El kit de desarrollo que demostró la idea rara vez es el equipo que se vende. El hardware de producción tiene que aguantar el emplazamiento, durar con su batería y cumplir la normativa para poder comercializarse.

Envolvente, batería e intervalo de envío

El grado de protección de la envolvente, los prensaestopas, la fijación y la posición de la antena deciden si un sensor sigue transmitiendo después de su primer invierno. La autonomía depende sobre todo de cada cuánto transmite el equipo y a qué velocidad de datos, así que hay que calcularla con el intervalo de envío de producción, no con el que se usó en la demo.

Además, el intervalo tiene un techo normativo. Los parámetros regionales de la LoRa Alliance para la banda europea de 868 MHz piden que los dispositivos mantengan su ciclo de trabajo de transmisión por debajo del 1 %, en línea con las normas de ETSI para esa banda. El 1 % de una hora son 36 segundos en el aire.

En la práctica, una lectura de 12 bytes enviada con factor de dispersión 12, la velocidad más lenta y la que acaban usando los equipos lejanos, ocupa unos 1,5 segundos de tiempo en el aire. Ese equipo puede mandar unos 24 mensajes por hora. Una demo que envía cada 30 segundos manda 120.

Los equipos cercanos a un gateway transmiten mucho más rápido y van sobrados, y por eso el problema no aparece en un piloto donde todos los sensores están cerca del gateway. Si el equipo técnico empieza con LoRaWAN, la guía de LoRaWAN para ciudades inteligentes explica la arquitectura y la cobertura de gateways con más detalle.

La certificación ya incluye ciberseguridad

Si diseñas el hardware o lo vendes con tu marca, estás introduciendo equipos radioeléctricos en el mercado de la UE, y eso trae consigo la Directiva de Equipos Radioeléctricos. Desde agosto de 2025, el Reglamento Delegado (UE) 2022/30 hace obligatorios tres requisitos de ciberseguridad de esa directiva para los equipos de radio que se conectan a internet: proteger la red, proteger los datos personales y proteger frente al fraude.

Las normas armonizadas EN 18031-1, EN 18031-2 y EN 18031-3 describen cómo cumplirlos. En el día a día empujan hacia cosas que un prototipo nunca tiene, como una autenticación que no dependa de una contraseña de fábrica compartida por todas las unidades, un almacenamiento protegido de las credenciales y una forma segura de actualizar el software. La página de la Comisión sobre la Directiva de Equipos Radioeléctricos enlaza a la guía oficial y a la lista de normas armonizadas.

La certificación consume tiempo de laboratorio y hay que repetirla cuando cambia el diseño de radio. Tiene que estar en el plan antes del pedido de 1.200 unidades, no después.

Alta de dispositivos e identidad a escala de producción

En el piloto, alguien tecleó 25 identificadores y sus claves en un formulario. Con 1.200 equipos eso es una semana de trabajo propenso a errores. Con 12.000 no es una opción.

El alta en producción empieza en la fábrica o en el almacén:

1. Claves únicas por equipo, generadas e inyectadas durante la fabricación, nunca escritas dentro de la imagen de firmware.
2. Un manifiesto por lote, con identificador, claves, revisión de hardware y versión de firmware, que se importa en la plataforma mediante una API o una carga masiva.
3. Una etiqueta o un código QR con el identificador del equipo, para que el instalador lo asocie a su emplazamiento desde el móvil.
4. Un responsable con nombre para el material de claves, ya sea el fabricante, el integrador o el cliente final, acordado antes de que salga el primer lote.

El segundo cambio está en el modelo de datos. En un piloto, lo que se vigila es el propio equipo: su nombre es el título del panel y su histórico es el histórico del proyecto. En producción, lo que se vigila es el depósito, la bomba o la cámara frigorífica, y el equipo es una pieza sustituible que va montada en ello.

Esa diferencia se amortiza la primera vez que falla un sensor. Si el histórico pertenece al equipo, el sustituto empieza con una gráfica vacía y alguien tiene que volver a configurar cada umbral. Si pertenece a la ubicación, el técnico cambia la unidad, escanea la etiqueta nueva y la gráfica sigue donde se quedó.

Cada estado de ese ciclo necesita una regla. Un equipo en almacén no debe disparar alarmas de desconexión. Un equipo retirado debe dejar de contar en el plan de conectividad. Un equipo que lleva callado tres veces su intervalo de envío debe generar una alerta propia, porque en producción una lectura que no llega suele ser la primera señal de una avería.

Cuando el despliegue abarca varios clientes, esa misma estructura tiene que mantenerlos separados: cada cliente ve sus emplazamientos y sus equipos, y ninguno más. Para eso sirve el multi-tenant, y conviene probarlo pronto si piensas vender el servicio con tu propia marca, como se explica en la guía sobre plataformas IoT white-label.

Actualizaciones de firmware: lo que un prototipo nunca necesita

Un prototipo que necesita firmware nuevo vuelve al banco de trabajo. Un equipo de producción en una azotea, en una arqueta o dentro de la máquina de un cliente, no. Las actualizaciones remotas (OTAOTérminoOTA (over-the-air)OTA (over-the-air) es la actualización remota del firmware de un dispositivo IoT a través de la red, sin acceso físico, imprescindible para flotas grandes.Ver perfil) hay que diseñarlas desde el primer lote de producción, porque el cargador de arranque y la distribución de memoria que las hacen posibles no se pueden añadir después con una actualización.

Empieza por cómo viajan las actualizaciones. En equipos con conectividad móvil o wifi, descargar una imagen nueva es rutina. En LoRaWAN las actualizaciones remotas son posibles pero lentas: la imagen se divide en muchos fragmentos pequeños, y esos fragmentos están sujetos al mismo ciclo de trabajo que el tráfico normal. Cuenta con campañas que duran horas o días por lote, y mantén las imágenes pequeñas.

Después, versiona la carga útil. Incluye una versión de formato en cada mensaje. Cuando el firmware 1.3 añade un campo, el decodificador de la plataforma tiene que seguir leyendo lo que envía el firmware 1.2, porque una flota nunca se actualiza entera de una vez.

Haz cada despliegue por fases. Actualiza el 5 % de la flota, vigila durante unos días la tensión de batería, los errores y el número de mensajes, y después continúa. Conserva la imagen anterior para poder volver atrás.

Por último, decide quién corrige las vulnerabilidades. Desde el 11 de septiembre de 2026, los fabricantes de productos con elementos digitales que se venden en la UE deben notificar las vulnerabilidades explotadas activamente y los incidentes graves según el Reglamento de Ciberresiliencia, empezando por una alerta temprana en 24 horas, según la guía de notificación de la Comisión. Un equipo que no puedes actualizar es un equipo que no puedes corregir dentro de ese plazo.

Aquí también se nota la elección de plataforma. Si los decodificadores, los perfiles de dispositivo y las campañas de actualización viven junto a los datos, un cambio de firmware es un paso controlado. Si están repartidos en scripts de un portátil, cada actualización se convierte en una pequeña migración, y la guía de migración de plataforma explica por qué los decodificadores son la pieza que más se subestima.

Alertas, datos y las personas que las reciben

El panel del piloto tenía un lector, el ingeniero que lo montó. En producción, las alertas llegan a operadores que no diseñaron los umbrales, muchas veces de noche y casi siempre al móvil.

Imagina la primera noche de lluvia después del despliegue. El piloto usaba un único umbral de nivel alto, y se copió a los 300 emplazamientos. Los depósitos que se llenan rápido con la lluvia lo cruzan en menos de una hora, y el operador de guardia recibe unas 400 notificaciones antes de medianoche. A la una, el canal está silenciado. El depósito que rebosa a las tres manda su alarma a ese canal silenciado.

Las alertas de producción necesitan varias cosas que el piloto podía saltarse:

• Umbrales por emplazamiento o por tipo de activo, con una duración mínima, para que una sola muestra con ruido no despierte a nadie.
• Reglas de escalado: a quién se avisa primero, a quién si nadie confirma en 15 minutos y por qué canal.
• Detección de silencio, tratada como una alarma más.
• Roles, para que los operadores del cliente confirmen alarmas mientras los ingenieros del integrador cambian las reglas.
• Un modo mantenimiento, para que un técnico que cambia un sensor no active toda la cadena de avisos.

Con los datos pasa lo mismo. Decide cuánto tiempo se guardan las lecturas en bruto, si el histórico agregado se almacena aparte y en qué formato puede exportarlo el cliente. Esas respuestas acaban en el contrato, y es mucho más fácil darlas antes del despliegue que en plena renovación.

Los detalles de transporte también pesan a escala. Si los equipos o los gateways publican por MQTTProtocoloMQTTEl protocolo pub/sub estándar del IoTVer perfil, la guía sobre el MQTT broker cubre las sesiones, los mensajes retenidos y los ajustes que se comportan de otra forma con miles de clientes conectados.

Pasar un prototipo IoT a producción: el modelo de costes

El presupuesto de un piloto cubre el hardware y unas semanas de ingeniería. Un presupuesto de producción tiene que cubrir años de operación, y las partidas más grandes casi nunca son las que midió el piloto.

Las visitas a campo merecen su propia fila. Con cifras orientativas de planificación: si falla el 2 % de 1.200 equipos al año y cada visita cuesta 150 € entre desplazamiento y tiempo, salen 24 visitas y 3.600 € al año antes de cambiar una sola batería. Si se duplica la distancia a los emplazamientos o la tasa de fallos, esa partida se mueve más que cualquier cuota de plataforma. El diagnóstico remoto, la detección de silencio y las correcciones OTA existen en buena parte para contenerla.

Para un integrador, la cuestión del precio es cómo convertir todo esto en una cuota recurrente que el cliente entienda. Lo habitual es un precio por equipo al mes que incluye conectividad, plataforma y un nivel de soporte definido, con el hardware y la instalación cobrados una sola vez. Modélalo con el tamaño del piloto, con el del despliegue y con diez veces el despliegue, y comprueba dónde se rompe el margen. Después compara el resultado con los planes de precios de la plataforma sobre la que lo vas a construir.

Queda además la tentación de construirlo en casa. Tras un piloto que ha salido bien, algunos equipos deciden escribir su propia plataforma porque los scripts del piloto parecen casi listos. Convertir esos scripts en un sistema con alta masiva, campañas de actualización, multi-tenant y escalado de alertas suele ser un proyecto mayor que el propio despliegue al que tenían que dar servicio.

Lista de comprobación antes de llevar un prototipo IoT a producción

Repasa esta lista antes de presupuestar el despliegue. Cada «no» es un paquete de trabajo dentro del presupuesto o un riesgo que conviene dejar por escrito.

1. El equipo de producción está certificado para los mercados donde se va a vender, incluidos los requisitos de ciberseguridad de la RED si lleva radio y se conecta a internet.
2. La autonomía está calculada con el intervalo de envío y la velocidad de datos de producción, y el intervalo respeta el ciclo de trabajo de la banda.
3. Cada equipo tiene claves únicas, generadas fuera de la imagen de firmware y con un responsable documentado.
4. Los equipos se pueden dar de alta en bloque desde un manifiesto, y los instaladores los asocian a su emplazamiento sin necesitar a un ingeniero.
5. El histórico y los umbrales pertenecen a la ubicación o al activo, no al equipo.
6. El firmware se puede actualizar en remoto, por fases y con marcha atrás, y cada carga útil lleva una versión de formato.
7. Las alertas tienen umbrales por emplazamiento, escalado, detección de silencio y modo mantenimiento.
8. Los clientes están separados por tenant, cada uno con sus propios usuarios y roles.
9. Hay un coste por equipo al mes escrito, que incluye visitas a campo y sustitución de baterías.
10. Hay una persona responsable de gestionar vulnerabilidades y una forma de cumplir el plazo de 24 horas de la alerta temprana.

Un hábito facilita casi toda la lista: monta el próximo piloto como si fuera el primer lote de producción. Veinticinco equipos dados de alta desde un manifiesto, actualizados una vez en remoto y con alarmas que recorren la cadena de escalado real cuestan poco más que un piloto hecho a mano, y el presupuesto del despliegue se apoya entonces en cosas ya probadas. Para elegir qué sensores y qué protocolo encajan en cada caso, la guía de sensores IoT: tipos y protocolos es un buen punto de partida.

Conclusiones

• Pasar un prototipo IoT a producción cambia la pregunta: de «¿sirven los datos?» a «¿se puede instalar, actualizar, mantener y pagar durante años?».
• Certifica pronto el equipo de producción. Desde agosto de 2025, los equipos de radio que se conectan a internet deben cumplir los requisitos de ciberseguridad de la Directiva de Equipos Radioeléctricos para venderse en la UE.
• Calcula la autonomía y el intervalo de envío con la velocidad de datos real. En la banda europea de 868 MHz, un equipo LoRaWAN lejano a SF12 tiene margen para unos 24 mensajes pequeños por hora.
• Da a cada equipo claves únicas, haz las altas en bloque y asocia el histórico al activo, no al sensor.
• Diseña las actualizaciones de firmware, el escalado de alertas y el coste por equipo al mes antes de presupuestar el despliegue, no después de la primera visita a campo.

Cloud Studio IoT da a los partners la capa de producción que suele faltar en los pilotos: alta masiva de dispositivos, network server LoRaWAN integrado, separación multi-tenant entre clientes, alertas por reglas con avisos por correo, SMS, notificación push y webhook, y despliegue en la nube o en tus propios servidores, todo con tu marca. Si tienes un piloto esperando la decisión del despliegue, echa un vistazo al programa de partners o solicita una demo y trae contigo los números del piloto.