Equipo Consultto
Especialistas en sistemas de gestión · 8 sep 2026
La pregunta llegó en la tarde del segundo día de auditoría y parecía inofensiva: el sistema con el que liberan los lotes, el que calcula si el muestreo pasó y bloquea el embarque cuando no, quién lo validó y dónde está el registro. El sistema llevaba cuatro años corriendo sin un solo incidente, se había comprado configurado por el proveedor y la planta no tenía nada más que el manual de usuario y el correo de la capacitación. La respuesta que se dio fue la que se da siempre, que el software funciona y lo demuestra el historial, y sirvió de poco: el requisito no pide que funcione, pide que se haya demostrado que funciona para el uso que se le da antes de empezar a usarlo. El hallazgo se levantó como mayor y arrastró a la hoja de cálculo que calcula el tamaño de muestra y al sistema documental, que tampoco tenían nada.
Antes de validar hay que separar tres familias de software que la gente mezcla y que se tratan de forma distinta. La primera es el software que forma parte del dispositivo médico o que es en sí mismo un dispositivo: ese no se valida por este camino, sino que se desarrolla y se verifica dentro del diseño, con un ciclo de vida propio y su análisis de riesgo. La segunda es el software que se usa en la producción y en el seguimiento y medición: el programa del equipo de prueba, la máquina de visión, el controlador de la selladora, el sistema que registra parámetros del proceso. La tercera es el software que se usa en el sistema de gestión de calidad: el gestor documental, el sistema de acciones correctivas, el de capacitación, el de calibración, el módulo de liberación del ERP y las hojas de cálculo que hacen cálculos que sustentan decisiones.
Las dos últimas familias son las que caen bajo la obligación de validar el software antes de su uso inicial y después de cada cambio. Y ahí el criterio no es el precio ni el tamaño del sistema, sino la decisión que se toma con él. Una hoja de cálculo de veinte celdas que decide si un lote se libera pesa más que un sistema corporativo caro que solo almacena documentos de lectura. Por eso el inventario de software es el primer entregable: qué sistemas hay, quién los usa, qué decisión del sistema de calidad depende de cada uno y qué pasaría si diera un resultado equivocado sin que nadie lo notara.
Conviene aclarar también qué no es esta validación. No es la calificación del equipo, aunque se apoye en ella: la calificación demuestra que la máquina instalada opera dentro de sus parámetros, y la validación del software demuestra que la aplicación hace lo que la organización necesita que haga en su configuración concreta. Tampoco es la certificación del proveedor: que el fabricante del sistema tenga su propio proceso de desarrollo verificado no valida el uso que se le da en esta planta, con estos flujos, estos permisos y estos campos configurados. Lo que se valida es el uso, no el producto.
La validación empieza definiendo el uso previsto en una frase que se pueda probar: para qué se va a usar el sistema, qué decisiones dependen de él y qué está fuera de su alcance. De ahí salen los requisitos del usuario, que son la lista de lo que el sistema tiene que hacer y de lo que tiene que impedir, escritos de manera verificable. Sobre esa lista se aplica el análisis de riesgo, que es lo que determina la profundidad de todo lo demás: los requisitos cuyo fallo afectaría la seguridad del paciente o la conformidad del producto se prueban a fondo y con casos negativos, y los que solo afectarían la comodidad del usuario se prueban de forma básica.
Después viene el plan, que dice quién prueba, en qué ambiente, con qué datos y qué criterio de aceptación se aplica. Las pruebas se documentan caso por caso, con el paso ejecutado, el resultado esperado, el resultado obtenido, la evidencia (una captura, un reporte, un impreso), la fecha y quién la ejecutó. Las pruebas que fallan no se borran: se registran, se corrige la configuración o el requisito, y se vuelve a probar dejando las dos vueltas a la vista. Al final se emite un informe que concluye si el sistema es apto para el uso previsto, con la lista de las desviaciones aceptadas y sus justificaciones, y lo aprueba alguien con autoridad, no el mismo que lo configuró.
La validación no termina ahí porque el software cambia. Hay que dejar establecido cómo se controla la configuración, qué versión está en uso, quién puede cambiar permisos y campos, y qué se hace cuando llega una actualización. Un parche del proveedor obliga a evaluar el impacto y a repetir las pruebas afectadas antes de aplicarlo en el ambiente productivo, y ese es el punto donde más sistemas validados dejan de estarlo: se validó la versión de hace tres años y desde entonces se han aplicado once actualizaciones automáticas que nadie evaluó. También se planifica el respaldo, la recuperación y qué se hace si el sistema se cae en medio de un turno.
La hoja de cálculo es el software más usado y el menos validado. Cuando hace un cálculo que sustenta una decisión de calidad (el tamaño de muestra, un índice de capacidad, la conversión de una lectura, un resultado de estabilidad) es una aplicación y se valida como tal: se prueba con valores conocidos y con valores límite, se comprueba que redondea como debe, se bloquean las celdas de fórmula, se restringe quién puede editarla, se identifica con versión y se controla dónde vive el archivo maestro. La versión que cada quien guarda en su escritorio y modifica es, en términos del sistema, un cálculo sin control.
Los sistemas en la nube agregan una capa que no existía cuando la práctica se escribió. El proveedor actualiza cuando quiere, a veces sin aviso detallado, y el ambiente de pruebas y el productivo pueden no estar sincronizados. Eso obliga a tratar al proveedor como lo que es, un proveedor externo que afecta la conformidad: evaluarlo, dejar por escrito en el acuerdo cómo notifica los cambios, si hay ambiente de validación disponible y qué evidencia entrega de su propio desarrollo, y a definir internamente qué se prueba tras cada actualización. Delegar el servicio no delega la responsabilidad sobre la decisión que se toma con el resultado.
¿Quieres implementar tu sistema de gestión?
La ISO 9001 no tiene un requisito llamado validación de software, pero llega al mismo lugar por tres caminos. La producción bajo condiciones controladas obliga a disponer de recursos de seguimiento y medición adecuados y a implementar actividades de seguimiento en las etapas apropiadas, y cuando esa medición la hace un equipo con software, la aptitud del software es parte de la aptitud del recurso. Los recursos de seguimiento y medición obligan a asegurar que son apropiados para el tipo de actividad y a mantenerlos para asegurar su idoneidad continua, lo que incluye la verificación de que el cálculo que hacen sigue siendo correcto.
A eso se suman el control de la información documentada, que obliga a proteger la información contra la pérdida de integridad y a controlar el acceso, el almacenamiento y la recuperación, requisitos que en un sistema electrónico se cumplen con permisos, respaldos y traza de auditoría; el control de los procesos, productos y servicios suministrados externamente, que aplica al proveedor de un sistema en la nube igual que a un proveedor de material; y la planificación de los cambios, que obliga a llevarlos a cabo de manera planificada considerando las consecuencias potenciales, que es exactamente lo que no ocurre cuando una actualización entra sola un martes.
La ISO 13485 lo pide por su nombre y en más de un lugar. Exige documentar los procedimientos para la validación de las aplicaciones de software usadas en el sistema de gestión de calidad, validarlas antes de su uso inicial y, cuando corresponda, después de cualquier cambio, con un enfoque proporcional al riesgo asociado a su uso, incluido el efecto sobre la capacidad del producto para cumplir las especificaciones, y conservar los registros de esa validación. El mismo criterio se repite para el software usado en la producción y la prestación del servicio y para el software usado en el seguimiento y la medición, que además debe verificarse.
Para quien exporta a Estados Unidos el requisito equivalente vive en la regulación, que obliga a validar el software usado como parte de la producción o del sistema de calidad conforme a un protocolo establecido y a conservar los registros, y a controlar los registros electrónicos y las firmas electrónicas cuando se usan en lugar del papel: usuarios individuales, traza de auditoría que no se puede desactivar, y firma vinculada al firmante y a su significado. En la práctica, un solo paquete de validación bien armado atiende los dos marcos, porque ambos piden lo mismo con palabras distintas: propósito definido, riesgo evaluado, pruebas ejecutadas con evidencia y control de los cambios posteriores.
El quiebre está en que el software se compra como una herramienta de productividad y no como parte del sistema. Lo elige sistemas o compras, lo configura el proveedor, lo capacita el usuario clave y calidad se entera cuando ya está en producción; para entonces validar significa parar el uso o documentar hacia atrás, y casi siempre se elige la segunda. En Tijuana, donde buena parte de las plantas de dispositivos médicos y de electrónica opera bajo el sistema de calidad de un corporativo en Estados Unidos, con equipos de prueba y sistemas de piso configurados localmente pero actualizaciones que bajan desde la matriz, el riesgo específico es que nadie se sienta dueño de la validación: la planta asume que el corporativo la hizo y el corporativo asume que la planta valida su configuración. Definir quién valida qué, con inventario y con control de cambios, es parte de lo que se ordena en la Consultoría ISO 9001 en Tijuana, donde el sistema tiene que sostenerse ante la auditoría del cliente y ante la de la autoridad del país al que se exporta.
Validar el software del sistema de calidad es demostrar, antes de usarlo y después de cada cambio, que hace lo que la organización necesita en su configuración real. Se empieza por el inventario y el uso previsto, se dimensiona con el riesgo de la decisión que depende del sistema, se prueba caso por caso con evidencia, se aprueba por alguien distinto de quien lo configuró y se mantiene con control de versiones y evaluación de cada actualización. Aplica al ERP, al gestor documental, al software del equipo de prueba y a la hoja de cálculo que decide un tamaño de muestra. No aplica al software que es parte del dispositivo, que se resuelve dentro del diseño. Que funcione no es evidencia; la evidencia es el registro de que se probó.
Empieza hoy
Sin compromisos. Sin presentaciones genéricas. Te escuchamos, entendemos tu empresa y te decimos honestamente qué necesitas y cómo podemos ayudarte.
Reunión confirmada
Solicitud enviada · Mié 2 Abr, 10:00 AM
Déjanos tus datos y un consultor se pone en contacto contigo en menos de 30 minutos.