¿Cómo funciona un software de certificación de productos? Del expediente técnico al certificado

¿Qué hace un software de certificación de productos?

Un software de certificación de productos gestiona en un único expediente trazable la solicitud, la familia de productos y sus variantes, el programa aplicable, el expediente técnico, las tareas de ensayo-inspección-auditoría, los hallazgos, la revisión y la decisión, el alcance del certificado, la vigilancia y los cambios de producto.

El objetivo no es producir un PDF de certificado más rápido. El objetivo real es poder mostrar conforme a qué requisitos técnicos se evaluó qué producto, con qué muestras y evidencias, en qué versión del expediente se basó la decisión y si un cambio posterior afectó al alcance del certificado. El software ordena esta cadena de evidencias; no asume la competencia del organismo de evaluación de la conformidad, las reglas del propietario del programa, las obligaciones del fabricante ni la decisión autorizada.

¿Qué determinan ISO/IEC 17065 e ISO/IEC 17067?

ISO/IEC 17065 establece los requisitos de los organismos que certifican productos, procesos y servicios; ISO/IEC 17067 ofrece la guía fundamental para comprender, desarrollar y operar programas de certificación de productos.

Según la página de estado de ISO de 11 de julio de 2026, ISO/IEC 17065:2012 sigue siendo la edición publicada; fue revisada y reconfirmada en 2024 y se prevé su sustitución por ISO/IEC FDIS 17065 en los próximos meses. ISO/IEC 17067:2013 también sigue siendo la edición publicada; para la segunda edición, ISO/IEC FDIS 17067 está en fase de desarrollo. Este panorama de transición muestra que el software debe gestionar la norma no solo por nombre, sino por edición, versión del programa y fecha de entrada en vigor. [1] [2]

TÜRKAK aborda la acreditación de organismos de certificación de productos en el marco de TS EN ISO/IEC 17065, los documentos y guías obligatorios aplicables de EA/IAF. Según la actividad que exija el producto o el programa, pueden entrar en juego también los requisitos aplicables de ISO/IEC 17025 para ensayos, ISO/IEC 17020 para inspecciones e ISO/IEC 17021-1 para la auditoría de sistemas de gestión. Por tanto, un software de certificación de productos no es solo un módulo de documentos; es una capa de orquestación que relaciona distintas fuentes de evaluación en el mismo expediente de decisión. [3]

¿De qué pasos consta el flujo digital del expediente técnico al certificado?

El flujo consta de solicitud y elección de programa, identidad del producto, expediente técnico, tareas de evaluación, cierre de no conformidades, revisión, decisión, certificado y seguimiento de vigilancia/cambios.

En la solicitud, ¿se define primero el producto o el programa?

Se aclara la identidad del producto y su uso previsto; después se asocia mediante revisión autorizada la reglamentación técnica aplicable, el documento normativo y el programa de certificación.

Nombres amplios como “dispositivo eléctrico”, “máquina” o “producto de construcción” no bastan por sí solos. El nombre comercial, modelo, variante, características técnicas, uso previsto, grupo de usuarios, lugar de fabricación, mercado objetivo y, si existen, certificados/informes actuales deben conservarse en campos estructurados. Distintas tensiones, materiales, versiones de software u opciones de componentes críticos del mismo producto pueden requerir evaluaciones distintas.

La elección del programa no debe hacerse al azar desde una lista desplegable. Deben examinarse en conjunto el propietario del programa, el documento normativo, el esquema de certificación, las actividades de evaluación requeridas, el enfoque de vigilancia, el uso de marcas y el alcance de autoridad de la organización. ISO/IEC 17067 da un marco para comprender y operar los programas; pero no determina por sí solo qué reglamentación o módulo se aplica a un producto concreto. [2]

¿Cómo se convierte la carpeta del expediente técnico en un modelo de datos trazable?

Cada archivo debe relacionarse con el producto/modelo, el requisito, la versión, quien lo emite, la fecha, el estado de evaluación y el registro de ensayo/inspección/decisión correspondiente.

El contenido del expediente técnico varía según el producto y la reglamentación aplicable. La descripción del producto, los planos de diseño/fabricación, la lista de piezas o materiales críticos, el análisis de riesgos, las normas aplicadas, los informes de ensayo, los registros de inspección, las instrucciones de uso, el diseño de etiqueta/marcado y la información de control de producción son ejemplos frecuentes. El software no debe presentar esta lista como una lista de verificación normativa universal e inmutable; debe versionarla según el programa y la reglamentación técnica elegidos.

La Decisión 768/2008/CE de la UE contiene el marco común que prevé que el fabricante elabore la documentación técnica necesaria y realice o haga realizar el procedimiento de evaluación de la conformidad aplicable, y que la documentación técnica sea suficiente para permitir la evaluación de la conformidad del producto con los requisitos aplicables. En los textos de los módulos se ejemplifican elementos como planos, descripciones, normas aplicadas y evaluación de riesgos. Esta fuente no dice que baste el mismo expediente técnico para todos los productos; la reglamentación sectorial y el módulo son los determinantes. [4]

¿Cómo se vinculan los registros de muestra, ensayo e inspección?

Cada resultado de evaluación debe vincularse a la identidad correcta del producto y de la muestra, al método utilizado, al laboratorio o fuente de inspección y a la versión inmutable del informe.

En la aceptación de muestras deben rastrearse serie/lote, modelo, variante, cantidad, fotografía, sello o información de entrega y estado de conservación. Si el ensayo o la inspección se subcontrata, el encargo, el alcance, el informe, la revisión y la evaluación de la organización deben permanecer en el mismo expediente. Que un informe esté cargado en el sistema no significa que se acepte automáticamente; debe revisarse en cuanto a identidad de producto, método, alcance, resultado y autoridad.

Si el programa de evaluación incluye auditoría del lugar de fabricación, el plan, el equipo, el emplazamiento, los procesos, la evidencia y los hallazgos se vinculan al expediente del producto. La auditoría del sistema de gestión, el ensayo del producto y la inspección del producto son actividades distintas; el software no debe fundirlas todas bajo el nombre de “informe de auditoría” perdiendo la distinción de método y competencia. La explicación de TÜRKAK sobre certificación de productos muestra en este sentido que, según el programa, pueden entrar en juego los requisitos aplicables de ISO/IEC 17025, ISO/IEC 17020 o ISO/IEC 17021-1. [3]

Al cerrarse la no conformidad, ¿puede publicarse automáticamente el certificado?

No. El tratamiento de la no conformidad, la completitud del expediente de evaluación y el paso de revisión/decisión autorizada deben mantenerse separados; el software solo debe respaldar el flujo de control y evidencias.

Un registro de no conformidad debe mostrar el requisito aplicable, la evidencia, el alcance, el responsable, la corrección, la necesidad de análisis de causa raíz/acción correctiva, el documento presentado y el resultado de la verificación. Que el solicitante suba un archivo nuevo no debe cerrar el registro por sí solo. La persona evaluadora registra la suficiencia de la evidencia; si el expediente tiene un asunto abierto o condicional, el decisor recibe el estado correcto.

La pantalla de decisión puede resumir resultados, mostrar contradicciones y bloquear campos obligatorios incompletos. Sin embargo, decisiones como emitir el certificado, reducir el alcance, pedir evaluación adicional, suspender o retirar deben registrarlas con su motivo personas autorizadas según el programa y el procedimiento de la organización. Si después cambia un informe de ensayo, la decisión antigua no debe vincularse silenciosamente al informe nuevo; debe abrirse una revisión de impacto.

¿Cómo se controlan el alcance del certificado y el uso de marcas?

El certificado debe coincidir uno a uno con el producto, modelos, documento normativo, programa, lugar de fabricación y condiciones aprobados en la decisión; el uso de marcas debe gestionarse solo según la autoridad real.

Campos como el número de certificado, primera publicación, validez, revisión, descripción del producto, modelos, versión de norma/programa, fabricante y lugar de fabricación deben generarse desde el registro estructurado. La corrección tras la aprobación debe abrir una nueva versión del certificado; el PDF y el registro de verificación anteriores deben conservarse. El panel del cliente destaca solo el documento vigente, mientras el usuario interno debe poder ver el historial de cambios.

El software no debe convertir la librería de logotipos o marcas de conformidad en una zona de diseño libre. El marcado CE, la marca de acreditación, la marca del programa y el logotipo del organismo de certificación están sujetos a reglas jurídicas y contractuales distintas. No debe añadirse ninguna marca al documento sin verificar la autoridad, el alcance, las reglas gráficas y la aprobación de uso. La frase “el sistema emitió el certificado” no prueba por sí sola la conformidad normativa del producto ni la autoridad acreditada de la organización.

¿Son el mismo proceso la certificación de productos, el CE y la reglamentación técnica?

No. La reglamentación técnica aplicable determina qué vía de evaluación de la conformidad se sigue; algunas vías implican a un tercero mientras otras pueden basarse en módulos de responsabilidad del propio fabricante.

La Guía Azul 2022 de la Comisión Europea es una guía exhaustiva que explica la aplicación de las normas de producto de la UE; la guía en sí no es texto legislativo vinculante y la fuerza jurídica real reside en la legislación de armonización de la Unión pertinente. Aborda en conjunto los roles de los operadores económicos, la documentación técnica, los organismos de evaluación de la conformidad, la acreditación, la supervisión del mercado y los límites del marcado CE. Por ello, en el software el registro del mercado objetivo del producto y de la reglamentación aplicable es un punto de partida más correcto que un producto genérico de “certificación CE”. [5]

En Turquía, en el marco de la Ley n.º 7223 de Seguridad de Productos y Reglamentaciones Técnicas, los productos deben ajustarse a la reglamentación técnica aplicable; la página oficial de preguntas frecuentes del Ministerio de Comercio indica que, sin subsanar la no conformidad, el producto no puede ponerse en el mercado, mantenerse en el mercado ni ofrecerse en servicio. El Reglamento de Métodos de Evaluación de la Conformidad explica que el módulo o módulos que se seguirán para un producto se indicarán en la reglamentación técnica correspondiente. El software puede ofrecer una biblioteca de reglas que ayude a elegir la normativa; la selección final deben determinarla el texto oficial vigente y la evaluación autorizada. [6] [7]

¿Por qué el cambio de producto y la vigilancia deben seguirse en el mismo expediente?

Porque un cambio de material, componente, lugar de fabricación, diseño o software puede afectar a la validez de las evidencias previas y del alcance del certificado.

Cuando la organización solicitante notifica un cambio, el sistema debe comparar la estructura antigua y la nueva del producto y marcar los registros de planos, riesgos, ensayos, inspecciones, producción y certificado afectados. El cambio no puede cerrarse automáticamente con la opción “menor”. La persona autorizada debe determinar con registro de decisión si se requiere un nuevo ensayo, documentación adicional, inspección del lugar de fabricación o revisión del certificado.

Si hay programa de vigilancia, las fechas, actividades, muestras y registros de mercado o lugar de fabricación se planifican según la regla del programa. El retraso, el resultado o la no conformidad se vinculan al estado del certificado. Las quejas y apelaciones también se gestionan con un flujo separado de autoridad y confidencialidad; no deben perderse como nota de atención al cliente. Cuando cambie el programa, debe determinarse según una regla de transición escrita en qué versión completarán los expedientes abiertos.

¿Qué registros separa un modelo de datos robusto de certificación de productos?

Producto, modelo, variante, requisito técnico, evidencia, muestra, evaluación, hallazgo, decisión y certificado deben ser objetos distintos; sus relaciones deben establecerse con información de versión y fecha.

• Familia de productos: Relación de modelo principal, variantes y componentes críticos.
• Matriz de requisitos: Reglamentación técnica, artículo de norma/programa y estado de la evidencia.
• Versión del documento: Emisor del archivo, fecha, alcance de producto y vínculo con la versión anterior.
• Cadena de muestras: Registro de aceptación, identidad, conservación, envío, ensayo/inspección y devolución/destrucción.
• Evaluación externa: Organismo encargado, alcance, informe y resultado de la revisión técnica.
• Vínculo de decisión: Versiones de evaluación y expediente utilizadas por la decisión.
• Ciclo del certificado: Publicación, revisión, suspensión, retirada, validez y estado de verificación.
• Impacto del cambio: Elemento cambiado, evidencia afectada, actividad requerida y decisión.

Esta separación hace consultable para qué variantes se usó el mismo informe de ensayo o qué certificados deben revisarse cuando cambia un componente. En un sistema basado solo en un árbol de carpetas, estas relaciones quedan a merced de los nombres de archivo y la memoria del usuario.

¿Cómo se planifica la transición a un software de certificación de productos?

Primero se modela el flujo real de expediente técnico y decisión de un programa; después se valida el piloto con escenarios de familia de productos, evaluación externa, certificado y cambios.

1. Extraiga el inventario de programas y documentos

Reúna el formulario de solicitud, la lista de requisitos, el formulario de muestra, los registros de ensayo/inspección, el informe de auditoría, los hallazgos, la decisión, el certificado, la regla de uso de marcas y el plan de vigilancia. Determine la fuente de cada documento y el rol que lo aprueba.

2. Construya el árbol de evidencias con una familia de productos

Elija el modelo principal y al menos dos variantes. Separe la documentación técnica común y las evidencias específicas del modelo. Siga en el piloto qué informes afecta un cambio de componente crítico.

3. Pruebe el flujo de laboratorio/inspección externa

Ensaye con escenarios de error reales los pasos de encargo, envío de muestras, aceptación de informes, revisión y revisión técnica. Un informe de un modelo equivocado o un alcance incompleto deben ser visibles para el sistema.

4. Valide la decisión y la revisión del certificado

Pruebe en conjunto el rol de decisión autorizada, el bloqueo por expediente incompleto, la selección de alcance, la versión del certificado y el estado de verificación del documento antiguo. Generar el PDF no debe suponer que el control de decisión está completo.

¿Cuáles son los errores más frecuentes en software de certificación de productos?

Los mayores errores son ver el CE y el certificado como sinónimos, diluir las variantes en un único producto y aceptar automáticamente la evidencia cuando se carga un archivo.

• Fijar el programa: Usar la misma lista de requisitos para todos los productos y mercados.
• Confiar en el nombre del archivo: Dejar el vínculo de producto, versión y requisito solo al nombre del archivo.
• Perder el rastro de la muestra: No asociar el resultado del ensayo con la serie/lote y variante correctas.
• Aprobar automáticamente el informe externo: No pasar por revisión técnica la correspondencia de alcance, método y producto.
• Vincular la decisión a la generación del PDF: Usar la creación del documento en lugar de la decisión autorizada.
• Usar las marcas libremente: Añadir el marcado CE o la marca de acreditación/programa sin verificar la autoridad y las reglas gráficas.
• Guardar el cambio como nota: No evaluar el impacto de la revisión del producto en evidencias y certificado.

¿Cómo respalda Vizyon Cert el proceso de certificación de productos?

Vizyon Cert puede unificar en un único expediente operativo la solicitud, la familia de productos, el expediente técnico, las tareas de evaluación, el hallazgo, la decisión, el certificado y los registros de vigilancia, según la estructura de programas y autoridad de la organización.

En la página de la solución Vizyon Cert puede examinar la estructura modular de la operación de certificación. Servicio de software de certificación En su ámbito se analizan el programa, los formularios, las decisiones y las integraciones actuales para diseñar el modelo de datos adecuado. La instalación del software no significa que la organización cumpla automáticamente ISO/IEC 17065 o esté acreditada; el proceso y la aplicación deben validarse con evaluaciones autorizadas.

Para la demo, preparar una familia de productos anónima, dos variantes, un informe de ensayo, una no conformidad, un cambio de componente y una revisión de certificado da el resultado más realista. Análisis de proceso con VizyonTech puede hacerse un recorrido de extremo a extremo, del expediente técnico a la decisión, sobre estos ejemplos.

Preguntas frecuentes