No hay respuestas universales: dependen del modelo, del volumen de datos y de cómo se use el sistema. Estas son las dudas que más se repiten cuando revisamos una red de reconocimiento antes de firmar un informe.
Depende del número de versiones activas y de si el sistema ya tiene registro de decisiones. Cuando existe trazabilidad previa, la fase de recolección se acorta y el trabajo se concentra en las pruebas adversariales y en el desglose por subgrupos. Sin esa base, hay que reconstruir el histórico antes de medir nada, y eso añade semanas al calendario.
La precisión global es un promedio y puede ocultar fallos concentrados. Un modelo con 96% de acierto general puede estar fallando de forma sistemática sobre un grupo concreto de personas. Por eso reportamos ambos números por separado y señalamos cuándo la diferencia entre ellos es lo bastante grande como para justificar una revisión del conjunto de entrenamiento.
Aplicamos perturbaciones controladas sobre las imágenes de entrada: ruido, oclusiones parciales, cambios de iluminación y variaciones que imitan intentos de suplantación. Cada tipo de ataque se mide por separado, porque un modelo puede resistir bien uno y caer con facilidad ante otro. El resultado se entrega como una tabla de resistencia, no como una cifra única.
Bastan tres cosas para arrancar: la arquitectura del modelo, una muestra representativa de datos de validación y los umbrales de decisión que usa el sistema en producción. Si además existe un registro de falsos positivos y falsos negativos de los últimos meses, el análisis gana precisión porque permite contrastar lo que medimos con lo que ya ocurrió en campo.
No del todo. Un informe describe el modelo tal como estaba el día de la prueba. Si el conjunto de datos se actualiza, si cambia el umbral de decisión o si se reentrena, las conclusiones anteriores dejan de aplicar. Recomendamos fijar una revisión periódica y documentar cada cambio relevante para que la trazabilidad no se pierda entre auditorías.
Lo primero es cuantificar el fallo: cuántos casos afecta, con qué frecuencia y bajo qué condiciones. Después se revisa el origen, que suele estar en la composición del conjunto de entrenamiento o en un umbral mal calibrado. No siempre se resuelve reentrenando; a veces basta ajustar el criterio de decisión para ese grupo. Lo que evitamos es maquillar el resultado en el informe.
Si tu caso no encaja en ninguna de estas preguntas, en recursos publicamos notas metodológicas más detalladas, y puedes escribirnos directamente desde la página de contacto.
Cada encargo sobre un sistema de identificación se descompone en frentes concretos. No entregamos un informe genérico: medimos ataques, precisión y sesgo por separado, con protocolos que puedes reproducir en tu propio entorno.
Aplicamos perturbaciones controladas sobre las imágenes de entrada y registramos cómo cambia la decisión del modelo. Separamos ataques de caja blanca y caja negra, porque el esfuerzo de un atacante real no se parece al de un experimento académico.
Un único número de exactitud no dice nada útil. Entregamos curvas de falsos positivos y falsos negativos en función del umbral, para que puedas elegir el punto de operación según el coste real de cada error en tu flujo.
Desglosamos los resultados por edad, tono de piel, iluminación y calidad de captura cuando los metadatos lo permiten. Reportamos intervalos, no promedios, y señalamos cuándo el tamaño de muestra no alcanza para concluir.
Un informe firmado caduca. Definimos qué señales monitorizar, cada cuánto revisar los umbrales y cómo documentar cada cambio del modelo para que la trazabilidad se mantenga viva entre auditorías.
Revisamos de dónde salen las imágenes de entrenamiento, cómo se etiquetaron y qué se descartó. Muchos fallos de identificación se originan antes del modelo, en decisiones de recolección que nadie documentó.
Entregamos scripts, semillas y versiones de cada dependencia para que otro equipo pueda repetir las pruebas. Si un resultado no se puede reproducir, no lo incluimos como conclusión.
Antes de encargar una auditoría conviene revisar el material de referencia que publicamos, o ver cómo trabajamos en nuestro equipo.
Lo que reportan quienes pasaron por una auditoría
Cada verificación termina en un informe con hallazgos, umbrales y cambios aplicados. Estos son algunos casos reales, con lo que se midió antes y lo que cambió después de la intervención.
Responsable de calidad, sistema de control de acceso
Trabajábamos con una tasa de falsos positivos que nadie terminaba de explicar. La auditoría separó los resultados por franja horaria y tipo de iluminación, y ahí apareció el problema: el modelo se degradaba con luz lateral. Ajustamos el preprocesado y volvimos a medir con el mismo banco de pruebas. La diferencia se notó en la primera semana de operación.
Coordinador técnico, verificación documental
Nos interesaba saber cuánto resistía el modelo frente a manipulaciones deliberadas. El equipo armó un set de ataques adversariales reproducible y lo corrió sobre varias versiones. No todo salió bien, y eso fue lo útil: pudimos priorizar qué parchear antes de exponer el sistema a usuarios reales.
Analista de datos, área de sesgos
La precisión global era alta, así que nadie miraba más allá. El desglose por subgrupos mostró diferencias sostenidas en dos categorías. Nos costó aceptarlo, pero el informe dejó claro qué tamaño de muestra hacía falta para sostener la conclusión. Con eso pudimos discutirlo con dirección sin caer en interpretaciones vagas.
Jefe de operaciones, identificación biométrica
El modelo llevaba meses en producción y ya no coincidía con el informe original. La verificación continua nos dio señales claras: qué métricas vigilar, cada cuánto revisar los umbrales y cuándo hace falta una revisión humana. Ahora sabemos cuándo el sistema está derivando antes de que se convierta en un incidente.