Verificar no es certificar que un sistema es seguro para siempre. Es medir su comportamiento actual frente a un conjunto de pruebas definido, con datos y umbrales documentados. Si el modelo cambia, si los datos de entrada cambian o si el contexto de uso se mueve, la verificación anterior deja de describir lo que hay en producción. Por eso entregamos el método junto con el resultado: para que pueda repetirse sin depender de nosotros.

Trabajamos con perturbaciones controladas sobre las imágenes de entrada: ruido dirigido, transformaciones geométricas, oclusiones parciales y variaciones de iluminación que simulan condiciones reales de captura. No incluimos ataques que requieran acceso físico al dispositivo ni manipulación del hardware, porque quedan fuera del alcance de una auditoría de software. Cada tipo de ataque se reporta por separado; promediar resultados entre categorías esconde justamente lo que interesa saber.

Un desvío entre subgrupos solo es defendible si la muestra de cada grupo tiene tamaño suficiente para sostener la conclusión. Cuando no lo tiene, lo decimos y lo marcamos como observación preliminar, no como hallazgo. Tampoco aceptamos subgrupos definidos a posteriori para forzar un resultado: los criterios de segmentación se acuerdan antes de abrir los datos.

No evaluamos la infraestructura donde corre el modelo, ni la seguridad de las bases de datos asociadas, ni el cumplimiento normativo de la organización. Tampoco auditamos el proceso de etiquetado histórico salvo que el cliente lo solicite como módulo aparte. Si durante el trabajo detectamos un problema fuera de alcance, lo señalamos por escrito y queda a decisión del cliente cómo abordarlo.

Cada informe lleva una versión y una fecha. Si el modelo se reentrena o se ajustan los umbrales, la verificación anterior no se actualiza: se emite una nueva. Mantener ese historial es lo que permite reconstruir qué se sabía en cada momento, algo que suele pedirse cuando un sistema lleva meses en producción y hay que explicar una decisión pasada.

Necesitamos acceso a una muestra representativa de los datos de entrada, a la versión exacta del modelo y a una descripción del uso previsto. Sin esos tres elementos el trabajo se vuelve especulativo. También pedimos un interlocutor técnico que pueda responder dudas sobre el pipeline, porque las suposiciones no documentadas son la causa más común de conclusiones mal interpretadas.