Qué hacer ante una verificación fallida

Cuando una verificación de firma o de procedencia falla, hay pocas explicaciones posibles: un error del propio pipeline (un archivo que cambió después de atestar, una atestación incompleta), un artefacto subido por un camino no previsto o una manipulación. Desde fuera las tres se ven igual, y por eso la respuesta no depende de cuál sospeches: el rechazo se mantiene hasta saber cuál es. Saltarse la verificación «para ver luego» convierte la única alarma de la cadena en un trámite.

Lo que sí se hace de inmediato es conservar la evidencia tal como llegó, medir qué está afectado y avisar a quien debe decidir.

Un control de admisión casi siempre tiene una vía de excepción, y está bien que la tenga: hay casos legítimos. Lo que la vuelve peligrosa es que la pueda usar sobre producción una sola persona, sin la aprobación que el procedimiento exige. En una revisión, cada excepción vigente sobre producción se lee con tres preguntas: quién la creó, quién la aprobó y qué permitió entrar.

Antes de decidir qué revertir hay que saber qué tocó el artefacto. Un mismo modelo suele servir a varios servicios, y el despliegue que se hizo con la excepción pudo llegar a todos o solo a algunos. El inventario por huella es lo que responde: los servicios que corren la huella que no pasó la verificación son los afectados.

Volver atrás no es volver a «la anterior» a ojo, ni a la que diga un alias que alguien pudo mover: es volver a la última versión que pasó la verificación, y el lugar que lo prueba es el registro de admisión, no la memoria del equipo.

La excepción sigue vigente: mientras exista, la verificación de ese modelo en producción no protege nada. Y el artefacto que entró sigue sin explicación: su huella no está en ninguna atestación y nadie sabe aún de dónde salió.