Voces de clientes
Estos comentarios vienen de equipos que ya pasaron por una verificación completa: banco de pruebas adversariales, desglose por subgrupos y revisión de umbrales. No son promesas de marketing, son observaciones concretas sobre qué se detectó y qué se corrigió.
Patricia Flores Navarro
Responsable de modelos, sector financiero
Nos entregaron el informe con los ataques separados por tipo, no promediados. Ahí vimos que el modelo aguantaba bien las perturbaciones de brillo pero caía frente a oclusiones parciales. Ese detalle no aparecía en nuestras métricas internas.
Eduardo Perez Sanchez
Coordinador de identidad digital
El desglose por subgrupos nos obligó a revisar el conjunto de validación. Teníamos muestras suficientes para dos grupos y casi nada para un tercero. Preferimos saberlo antes de desplegar que descubrirlo con reclamos.
Laura Ruiz Flores
Analista de riesgos algorítmicos
Lo que más nos sirvió fue la trazabilidad: cada umbral quedó documentado con la fecha y el motivo del cambio. Cuando el modelo se actualizó tres meses después, pudimos comparar sin rehacer todo el proceso.
Oscar Garcia Aguilar
Jefe de operaciones, verificación remota
Esperaba un documento largo y abstracto. Recibimos una lista de comprobación concreta: qué revisar cada trimestre, qué señales monitorizar y cuándo hace falta una revisión humana en lugar de confiar en el panel automático.
Cada corrida adversarial queda versionada con su semilla, su conjunto de imágenes y los parámetros exactos de perturbación. Si un modelo cambia, comparamos contra la misma base y no contra un promedio histórico que ya no dice nada.
Reportar una exactitud global del 97% es cómodo y suele esconder lo importante. Separamos resultados por franjas de edad, tono de piel, condiciones de iluminación y calidad de captura antes de firmar cualquier conclusión.
Un modelo auditado hace un año describe un sistema que ya no existe. Definimos señales de monitorización, umbrales de revisión y un calendario de reauditoría acordado con quien opera el sistema.
Entregamos el procedimiento, los datos de prueba y las decisiones metodológicas por escrito. No escondemos los límites del análisis: si una conclusión depende de supuestos, queda anotado junto al resultado.
Evitamos cifras que suenan bien pero no se pueden verificar. Preferimos un intervalo con su tamaño de muestra antes que un número redondo sin contexto de cómo se obtuvo.
Hablamos de robustez cuando el modelo se somete a perturbaciones controladas: ruido en la imagen, oclusiones parciales, cambios de iluminación o variaciones de pose. No cuenta como prueba adversarial un simple recorte o un cambio de resolución. Cada perturbación se documenta con su intensidad y se repite sobre el mismo conjunto de referencia para que los resultados sean comparables entre versiones.
Un porcentaje único de acierto no describe el comportamiento real del sistema. Reportamos siempre el desglose por subgrupo cuando el tamaño de muestra lo permite, y cuando no lo permite lo decimos en lugar de rellenar el hueco. Un subgrupo con menos de doscientos casos no sostiene una conclusión firme y así queda anotado en el informe.
Sesgo no es sinónimo de error. Es una diferencia sistemática de rendimiento entre grupos que persiste al repetir la medición. Una variación puntual en un lote pequeño puede ser ruido estadístico. Para declarar sesgo exigimos que la brecha se mantenga en al menos tres ejecuciones independientes sobre datos distintos.
Una auditoría describe el modelo tal como estaba el día de la prueba: pesos, versión del pipeline y conjunto de datos utilizados. Cualquier reentrenamiento posterior invalida las conclusiones hasta que se repita la verificación. Indicamos la fecha de corte y la versión exacta para que nadie arrastre un resultado viejo a un sistema nuevo.
Si el cliente no puede compartir la distribución de sus datos de producción, trabajamos con un conjunto sustituto y lo declaramos como tal. Los resultados entonces son indicativos, no concluyentes. Preferimos señalar esa limitación antes que presentar un número limpio que no refleja el uso real del sistema.
Una revisión interna del propio equipo que entrenó el modelo no es una verificación externa, aunque use la misma metodología. Tampoco lo es una prueba de integración que solo confirma que el sistema responde. La independencia exige que quien audita no haya participado en el diseño ni en el ajuste del modelo evaluado.