¿Cómo se preserva el historial de revisión y aprobación de documentos en la gestión de calidad?

¿Cómo se conserva el historial de revisión de documentos?

Abra cada revisión como una versión nueva bajo una identidad de documento inmutable; guarde sin eliminar el contenido anterior, la justificación del cambio, los revisores, la decisión de aprobación, la fecha de vigencia y la traza de distribución.

El objetivo no es solo archivar el archivo antiguo. El sistema debe poder volver a mostrar qué versión estaba vigente en una fecha de operación determinada y quién aprobó esa versión y con qué prueba.

¿Por qué deben separarse el documento controlado y el registro?

Respuesta breve: el documento describe cómo se hace el trabajo y puede revisarse; el registro da fe del resultado del trabajo realizado y su historial no debe modificarse retroactivamente.

Una política, un procedimiento, una instrucción, una plantilla o un formulario en blanco pueden ser documentos controlados. Un formulario de control cumplimentado, una decisión de aprobación o una asistencia a formación son registros. Aunque puedan guardarse en la misma área de archivos, sus estados, autorizaciones y reglas de conservación no deben ser iguales.

ISO 10013:2021 ofrece orientación para desarrollar y mantener la información documentada que respalda un sistema de gestión de calidad eficaz, según las necesidades de la organización. Esto significa que, en lugar de copiar a cada organización una única jerarquía de carpetas o documentos, el control debe alinearse con los procesos y el riesgo.

¿Cómo debe establecerse el modelo de identidad y versión del documento?

Separe la identidad inmutable del número de versión. Por ejemplo, manteniendo la misma identidad de documento, las revisiones 03, 04 y 05 son objetos distintos; el archivo nuevo no sobrescribe la fila antigua.

• Núcleo del documento: identidad única, nombre, tipo, proceso, rol propietario y clase de confidencialidad.
• Registro de versión: revisión, hora de creación, resumen del cambio, resumen del archivo de origen y enlace con la versión anterior.
• Registro de decisión: revisor, aprobador, momento de la decisión, rol/autoridad y, si la hay, justificación del rechazo.
• Registro de vigencia: fecha de inicio, puntos de uso, trabajos abiertos afectados y motivo de la retirada de vigencia.
• Registro de distribución: quién o qué rol lo vio, por qué canal accedió, ¿se recuperó la copia controlada antigua?

El nombre del archivo puede ser práctico, pero no es una identidad única. Cuando un archivo se renombra o se convierte a otro formato, el enlace documento-versión-aprobación no debe romperse.

¿Qué puertas debe incluir el flujo de revisión y aprobación?

Respuesta breve: quien prepara, el revisor técnico y la autoridad que pone en vigor deben quedar claros; el proceso no debe cerrarse con una justificación ausente o una decisión no autorizada.

1. Borrador: el propietario del documento registra el alcance y la justificación del cambio.
2. Revisión de impacto: se evalúan los formularios vinculados, las formaciones, los trabajos abiertos, los contratos y los requisitos externos.
3. Revisión técnica: el rol autorizado comprueba la exactitud y aplicabilidad del contenido.
4. Aprobación: quien decide vincula el registro de decisión con el valor de resumen del archivo que tiene delante.
5. Vigencia: la versión aprobada se vuelve seleccionable en la fecha definida; la versión antigua se cierra para trabajos nuevos.
6. Distribución y lectura: se informa a los roles afectados; si procede, el uso no se habilita hasta completar la prueba de formación o de competencia.

No incorpore al software, como regla universal, que quien prepara y quien aprueba deban ser siempre personas distintas. La segregación de funciones debe determinarse con la norma aplicable, la evaluación de riesgos de la institución, la matriz de autorizaciones y las condiciones contractuales. El sistema debe aplicar la regla elegida de forma coherente y no admitir excepciones sin justificación.

¿Cómo impide el uso de la versión antigua?

No basta con poner una etiqueta de “inválido”. Al iniciar una nueva orden de trabajo, la creación de un formulario o una tarea de campo, el sistema debe ofrecer solo la versión adecuada según la fecha de vigencia y el contexto del proceso.

La estructura común de los sistemas de gestión de ISO con fecha 1 de julio de 2026 exige que la información documentada sea apta para el uso y accesible donde se necesite, y que se proteja contra el uso inadecuado o la pérdida de integridad. El mismo texto aborda también que las externalidades documentadas necesarias se identifiquen y controlen. El equivalente en VizyonTech son estas puertas técnicas:

• No permita seleccionar una plantilla retirada de vigencia en una operación nueva.
• Fije con qué versión comenzaron los trabajos abiertos; cuando cambie la versión, abra automáticamente una tarea de impacto.
• Vincule a la copia controlada descargada la versión y la hora de descarga; distinga explícitamente la copia no controlada.
• Si el dispositivo de campo está sin conexión, verifique la versión vigente antes de sincronizar; ante ambigüedad, no inicie operaciones nuevas.
• Cuando se actualice una norma externa o una especificación de cliente, localice por relación los procedimientos, formularios y formaciones afectados.

¿Qué eventos debe registrar el historial de aprobaciones y la pista de operaciones?

Un único campo “último en actualizar” es insuficiente para la auditoría. Creación, carga, comparación, envío a revisión, rechazo, reenvío, aprobación, vigencia, descarga, distribución y cambio de autoridad deben ser eventos separados.

NIST SP 800-92 aborda la gestión sólida de registros no solo como generación de logs, sino como el establecimiento de una infraestructura de logs y su gestión regular. Por eso el evento de aprobación y la pista de auditoría deben mantenerse separados pero relacionados; el administrador de la aplicación no debe poder editar el historial silenciosamente y el acceso a los logs también debe restringirse.

¿Cómo deben gestionarse el acceso, la copia de seguridad y la conservación?

Proteger el historial de aprobaciones no significa abrirlo a todos. Conceda acceso basado en roles y alcance según la clase de contenido, datos personales, información del cliente y secreto comercial.

La declaración oficial de seguridad de datos de la KVKK subraya que las medidas deben ser adecuadas al negocio, la estructura y el riesgo de los datos protegidos por el responsable del tratamiento, y que debe prevenirse el acceso ilegal y garantizarse la conservación de los datos. El equivalente técnico es operar conjuntamente la matriz de autorizaciones, el registro de accesos, la copia de seguridad, la prueba de restauración y la política de conservación/destrucción.

• No considere exitoso el mensaje de copia de seguridad realizada; restaure una cadena de documentos de ejemplo y verifique las relaciones.
• No copie un único plazo de conservación a todos los documentos; vincúlelo al propósito, los contratos y la normativa aplicable.
• Si existe retención legal o contractual, detenga de forma controlada el flujo normal de destrucción.
• No elimine los registros de aprobación antiguos de un usuario al que se retiró la autorización; desactive la cuenta y conserve la identidad histórica.

¿Qué escenarios deben probarse en el piloto de VizyonTech?

Vizyon Periyodik o al evaluar el flujo de calidad de VizyonTech adaptado a su organización, pilote de principio a fin un procedimiento real y su familia de formularios vinculados.

• Envíe a aprobación sin justificación del cambio; el flujo debe detenerse.
• Intente aprobar con un usuario no autorizado; no debe generarse decisión.
• Cambie en el último momento el archivo presentado a aprobación; la aprobación anterior debe invalidarse y debe pedirse una nueva revisión.
• Abra un trabajo nuevo con una versión antigua del formulario; el sistema debe bloquear la selección.
• Actualice un documento de origen externo; deben generarse tareas de impacto para los procedimientos y formaciones vinculados.
• Restaure desde la copia de seguridad; las relaciones de documento, versión, aprobación y distribución deben verificarse juntas.

El criterio de éxito del piloto no es que un documento pueda cargarse. Es que el sistema se cierre ante pruebas ambiguas o incompletas, conserve el historial y que el auditor pueda reconstruir, en una única cadena, la versión vigente en una fecha determinada. Para el ciclo de vida distinto del informe de inspección firmado, consulte la guía sobre versiones y trazabilidad de operaciones en la revisión de informes firmados electrónicamente , que puede consultar.