001 · Punto de partida: las decisiones antes del producto

Este diario documenta, en abierto, la preparación de nuestro producto de IoT agrícola para el Cyber Resilience Act — incluidas las decisiones que acaben revelándose erradas. El producto está en fase de prototipo, con ensayo de campo en Coruche, y la previsión de mercado es 2027–2028. Es decir, si todo sale según lo planeado, el producto nace ya dentro de la aplicación plena del reglamento, sin período de transición para nosotros. Fue una elección deliberada.

Lo que ya está decidido

1. La clasificación de trabajo es “producto por defecto”. La monitorización agrícola no figura en el anexo III. La hipótesis queda documentada con su fundamentación y se revisa con cada cambio de alcance funcional — la lección del artículo sobre clasificación es que una funcionalidad añadida puede cambiar la categoría, y en nuestro caso la tentación existirá (un sensor que “también detecta intrusiones” sería otra conversación).

2. SBOM desde la primera build con tag. Generada por el sistema de build, nunca a mano, archivada con el binario. La elección concreta de tooling depende del build system que fijemos al final de la fase de prototipo; el criterio ya está fijado: solo entra en la lista corta lo que genere SBOM de forma nativa. Las lagunas (blobs de proveedor) se declararán como lagunas.

3. El período de soporte es una restricción de diseño, no un campo de formulario. Objetivo de trabajo: cinco años. Consecuencia inmediata, ya en vigor en la fase de prototipo: ningún componente entra en la BOM sin fecha de fin de vida conocida y compatible, y el coste anual de la infraestructura de actualización entra desde ya en el modelo de costes del producto.

4. El proceso de notificación se monta antes de que haya algo que notificar. Las obligaciones del artículo 14 solo nos afectarán cuando haya producto en el mercado — pero el proceso (triaje, decisión de conocimiento, plantillas de las tres notificaciones) queda escrito y ensayado mucho antes, porque es también lo que recomendamos a los clientes y no recomendamos lo que no hacemos.

5. Divulgación coordinada desde el sitio web. El security.txt de este sitio es el embrión de la política de divulgación coordinada de vulnerabilidades que el CRA exigirá para el producto. Próximo paso documentado aquí: publicar la clave PGP y la política formal.

Lo que todavía no sabemos

Con la honestidad que un diario exige: aún no tenemos respuesta cerrada para (a) la arquitectura de actualización OTA en un contexto de conectividad intermitente rural — que es nuestro contexto — y sus implicaciones en el requisito de actualizaciones seguras; (b) si el procesamiento remoto que planeamos será “integral a las funciones del producto” en el sentido del reglamento, lo que definiría el perímetro de la documentación técnica; (c) el estado de las normas armonizadas del CRA en la fecha en que las necesitemos.

Cada una de estas tendrá su entrada cuando exista la respuesta — o cuando falle el primer intento.

Por qué esto es público

Un caso de estudio de cliente nunca puede tener este detalle; nuestro propio producto sí puede. Si el lector está haciendo el mismo recorrido y discrepa de alguna decisión, el correo está en el pie de página — la discrepancia fundamentada es más útil que la lectura silenciosa.