Líneas de trabajo del centro
Cada white paper parte de una pregunta concreta de un equipo de seguridad o de riesgo. No publicamos panorámicas genéricas: comparamos arquitecturas, medimos umbrales operativos y dejamos explícito qué condiciones del corpus no cubrimos.
Redes siamesas frente a transformers con atención sobre parches faciales, evaluadas sobre corpus mixtos de impresión, replay y máscaras 3D. Reportamos APCER y BPCER a varios umbrales y señalamos dónde la calibración por dominio cambia el resultado en dispositivos móviles.
Seguimiento del paso de la verificación unimodal a esquemas compuestos donde la biometría facial convive con señales de dispositivo, geolocalización aproximada y patrones de interacción. Incluye lectura regulatoria bajo PSD2 y GDPR y los límites de gobernanza que aparecen al fusionar señales.
Por qué el AUC agregado oculta fallos por subgrupo demográfico y por tipo de ataque. Proponemos métricas operativas: tasa de aceptación de impostores a umbral fijo, coste del falso rechazo por canal y estabilidad temporal del score.
Documentamos iluminación, resolución, compresión y sesgo de dispositivo de cada conjunto de datos usado. Si un corpus no representa el canal de despliegue del lector, lo indicamos antes de cualquier conclusión comparativa.
Cada informe incluye particiones de entrenamiento y validación, semillas, versiones de framework y criterios de selección de umbral. El objetivo es que un equipo externo pueda repetir la comparación sin depender de nuestros scripts.
Preguntas que llegan a la mesa de investigación con más frecuencia, resueltas sin rodeos legales ni promesas de laboratorio.
Si tu caso no aparece aquí, escríbenos a info@cuauhtemoc-blanco.com y lo incorporamos a la próxima revisión del informe.
Un ataque de presentación ocurre frente al sensor: impresión, replay en pantalla, máscara. Un deepfake se inyecta en el canal digital y puede no pasar nunca por la cámara. Los tratamos como familias separadas porque las métricas no son comparables: APCER frente a impresión no dice nada sobre robustez ante caras generadas con difusión. En los white papers siempre indicamos el tipo de ataque y el canal de captura.
Porque el AUC resume el comportamiento en todos los umbrales posibles, y en producción se opera en uno solo. Dos modelos con AUC casi idéntico pueden divergir de forma severa al fijar el umbral por canal: uno acepta impostores en condiciones de baja luz, el otro rechaza usuarios legítimos en dispositivos antiguos. Publicamos tasa de aceptación de impostores a umbral fijo y coste del falso rechazo por canal para que la comparación sea útil.
Sí, y conviene decirlo sin matices. Cuando la verificación facial se combina con señales de dispositivo, geolocalización aproximada y patrones de interacción, el volumen de datos tratados crece y también la superficie de riesgo. Nuestros informes describen qué señales aportan valor real frente al spoofing y cuáles se pueden descartar sin perder precisión. La gobernanza de datos no es un anexo: condiciona qué arquitectura es viable.
Priorizamos mezcla de condiciones: iluminación variable, distintos sensores móviles, ataques de impresión, replay y máscaras 3D. Un corpus limpio y homogéneo produce métricas bonitas y conclusiones frágiles. Cuando un corpus público no cubre un tipo de ataque relevante, lo indicamos como limitación explícita en lugar de extrapolar resultados.
Publicamos el método de calibración y los criterios de selección de umbral, no un número fijo. El umbral depende del coste relativo del falso rechazo y del falso positivo en cada despliegue: banca móvil, control de acceso físico y verificación remota no comparten el mismo punto de operación. Damos la curva y el procedimiento para que cada equipo lo fije con sus datos.
Revisamos los informes cuando cambia el panorama de ataques o cuando un piloto interno muestra un fallo que las métricas publicadas no capturaban. No hay calendario fijo: preferimos una revisión sustantiva a una actualización cosmética. Las versiones anteriores quedan archivadas con la fecha y el motivo del cambio.
Cada white paper sobre detección de spoofing o evolución de perfiles de seguridad sigue la misma ruta interna. No es un proceso rígido, pero sí ordenado: primero acotamos la pregunta, después medimos y al final publicamos con los datos y las limitaciones a la vista.
Recibimos la consulta y la convertimos en una pregunta verificable. Si el encargo es comparar arquitecturas anti-spoofing, fijamos qué ataques entran (impresión, replay, máscaras 3D, sintéticos generativos), qué canales se evalúan y qué queda fuera. Ese recorte inicial evita informes que prometen más de lo que los datos permiten sostener.
Antes de tocar datos, mapeamos lo publicado: papers, normas ISO/IEC 30107, guías regulatorias bajo PSD2 y GDPR, y resultados reproducibles de terceros. Anotamos qué metodologías se repiten y dónde hay vacíos. Esta fase suele revelar que la pregunta original necesita un ajuste fino.
Definimos particiones, umbrales operativos y métricas que importan en producción: APCER, BPCER, coste del falso rechazo por canal y estabilidad temporal del score. Cuando el corpus es propio, documentamos su composición demográfica y los sesgos conocidos. Cuando es público, indicamos versión y fecha de descarga.
Corremos los modelos, comparamos contra líneas base y revisamos subgrupos. Un AUC alto puede esconder un mal comportamiento en dispositivos móviles o en ciertos rangos de iluminación, así que cruzamos métricas agregadas con desgloses por canal y tipo de ataque antes de dar cualquier número por bueno.
El informe se escribe con la metodología completa, los resultados y una sección explícita de límites. Un revisor que no participó en el análisis audita cifras, gráficos y afirmaciones. Si algo no se sostiene con los datos, se retira o se reformula antes de pasar a edición.
El white paper se publica con su versión, fecha y conjunto de datos asociado. Después hacemos seguimiento: si aparecen ataques nuevos o cambia el marco regulatorio, actualizamos el documento y dejamos registro del cambio. La evolución de los perfiles de seguridad no se detiene, y los informes tampoco deberían.
Si tu encargo no encaja en esta ruta, escríbenos a info@cuauhtemoc-blanco.com y lo revisamos antes de comprometer plazos.
Niveles de acceso a la investigación
Cada línea de trabajo responde a una necesidad distinta: seguir la evidencia publicada, participar en la revisión de un informe en curso o encargar un análisis comparativo sobre un corpus propio. Los alcances, la periodicidad y el grado de exposición de los datos cambian según el formato.
Lectura completa de los white papers ya cerrados: comparativas de arquitecturas anti-spoofing, series históricas de perfiles de seguridad y notas metodológicas sobre métricas operativas. Entrega en PDF y versión web, con las matrices de resultados y los anexos de calibración incluidos.
Acceso anticipado a los borradores en revisión y posibilidad de comentar la metodología antes del cierre. Pensado para equipos de seguridad, laboratorios académicos y responsables de cumplimiento que quieran contrastar criterios de evaluación con otros revisores del sector.
Trabajo sobre un corpus propio: se define el conjunto de ataques a evaluar (impresión, replay, máscaras, deepfakes generativos), las familias de modelos a comparar y los umbrales operativos relevantes. El resultado se entrega como informe cerrado con trazabilidad de cada decisión metodológica.
Monitoreo continuo de cómo evolucionan los perfiles de seguridad biométrica en banca y servicios digitales: qué señales se incorporan, qué exigencias regulatorias aparecen y dónde se están produciendo los desplazamientos metodológicos. Notas breves con periodicidad mensual y acceso al archivo histórico.