El pasaporte es un riesgo de acceso al mercado, no un proyecto informático

Dónde está el pasaporte digital de producto (DPP) en tu organigrama predice si vas a estar listo. No el presupuesto, no el proveedor, no la tecnología. La línea de reporte.

Qué controla realmente la obligación

El registro del pasaporte es obligatorio para introducir un producto en el mercado único. Para mercancía importada, el pasaporte tiene que existir antes de que la aduana pueda despacharla a libre práctica.

Léelo literalmente: sin pasaporte, el producto no puede venderse. No vendido en desventaja, no vendido con una sanción encima. No vendido.

Esa es la definición de un riesgo de acceso al mercado, y los riesgos de acceso al mercado se gestionan en el consejo.

Qué pasa cuando se archiva en informática

Un ticket en un backlog informático compite con todos los demás tickets. Se prioriza frente a caídas, trabajo de seguridad, una migración de ERP y lo que necesite comercial este trimestre. Se retrasa, razonablemente, porque nada en cómo está planteado dice que la empresa pierde facturación cuando se retrasa.

Peor: informática no puede hacer la parte que más tarda. El cuello de botella de todo proyecto de pasaporte son los datos de proveedores: conseguir evidencias de empresas que no tienen ninguna obligación de darte prioridad. Eso requiere peso comercial, cláusulas contractuales y autoridad de compras. A un equipo informático al que se le pide entregar un pasaporte se le ha dado la responsabilidad sin los medios, que es la forma más fiable de producir un proyecto tarde y un equipo desmoralizado.

Los datos respaldan este planteamiento. El reto más citado en un estudio de KPMG sobre más de 70 organizaciones europeas fue la recogida de datos de proveedores y de la cadena de valor ampliada, con el 31 por ciento, muy por delante de las restricciones tecnológicas con el 14 por ciento. El problema que las empresas encuentran de verdad es comercial, no técnico.

Qué cambia cuando se gestiona como continuidad de ventas

Cambia de inmediato, de tres formas.

Consigue una fecha real. Los riesgos de acceso al mercado se siguen contra fechas, no contra sprints.

Consigue peso comercial. Un responsable que reporta a comercial puede exigir datos de proveedores como condición para hacer negocios, que es el único mecanismo que funciona de forma fiable.

Consigue presupuesto proporcional a la exposición. La comparación deja de ser «cuánto cuesta este software» y pasa a ser «cuánta facturación hay en esta categoría». Son conversaciones distintas y producen respuestas distintas.

Cómo defenderlo internamente

Si hay que sacar el pasaporte de informática, el argumento cabe en tres frases.

El pasaporte determina si podemos vender en la UE en esta categoría. La facturación en riesgo es la de esa categoría. Por tanto el responsable debería ser quien responde de esa facturación, con informática apoyando en lugar de liderando.

Ese planteamiento sobrevive a un consejo. «Necesitamos implementar un modelo de datos para metadatos regulatorios» no, y con razón, porque describe un medio en lugar de un riesgo.

Qué debería poseer informática

Para que quede claro: el trabajo técnico es real. Alojamiento, interfaces, gestión de identificadores, disponibilidad. Informática debería poseerlo todo.

Lo que informática no debería poseer es el resultado, porque el resultado depende de que respondan los proveedores, y ningún equipo técnico tiene autoridad para conseguirlo.

Fuentes

• Comisión Europea, *Digital Product Passport: FAQ*, actualización de enero de 2026, preguntas 3 y 11:
• el registro es obligatorio para introducir un producto en el mercado único.
• KPMG, *European Digital Product Passport Readiness Survey*, febrero de 2026: datos de proveedores
• citados como reto principal por el 31 por ciento, restricciones tecnológicas por el 14 por ciento.
• Muestra pequeña y autoseleccionada.