Un fundador no necesita ser experto en ataques adversarios, pero sí saber qué exigir al proveedor y qué documentar dentro de casa. Esta página reúne las preguntas que conviene hacer antes de firmar, los supuestos de atacante que deberían estar por escrito y las señales que obligan a revalidar un modelo ya en producción.
La defensa adversarial no se resuelve comprando una herramienta: se sostiene con preguntas concretas al proveedor, documentación interna del flujo de datos y una rutina de revalidación. Si estás armando el área de riesgo de una fintech, empieza por dejar escrito qué supuestos de atacante se evaluaron, cómo se mide la robustez frente a entradas manipuladas y cada cuánto se revisa el modelo. Ese registro también te sirve cuando una decisión automatizada afecta a una persona y alguien pide explicaciones.
Un AUC global estable puede esconder errores concentrados en perfiles concretos. Antes de aprobar la integración, pide la curva de rendimiento desglosada por tramos de ingreso, antigüedad laboral y tipo de solicitud. Si el proveedor solo entrega la métrica agregada, esa es la primera señal de que la validación frente a entradas manipuladas no se está haciendo en serio.
No todos los campos pesan igual. Un mapa de sensibilidad por variable muestra dónde conviene reforzar validaciones cruzadas: coherencia entre ingresos declarados y actividad registrada, consistencia entre composición del hogar y gastos fijos. Documenta ese mapa con fecha y versión del modelo; cuando cambie el formulario, sabrás qué revisar primero.
Cada despliegue del modelo debería quedar anotado con su fecha, los datos de entrenamiento usados y quién aprobó el cambio. Define por escrito qué señales activan una revisión: caída de rendimiento en un segmento, aumento de solicitudes con patrones atípicos, o cambios en la fuente de datos. Sin ese registro, cualquier incidente futuro se convierte en una discusión sin evidencia.
Pregunta qué tipo de manipulación se evaluó: cambios pequeños en campos declarativos, registros contaminados en el histórico, o intentos de inferir la lógica del modelo desde fuera. Un proveedor serio describe los escenarios probados y sus límites. Si la respuesta es que el modelo "no se puede engañar", conviene seguir buscando.
Si estás integrando un scoring de terceros o entrenando el tuyo, hay decisiones que no conviene dejar para después del lanzamiento. Escríbenos con el contexto de tu producto y te devolvemos una lectura ordenada: qué supuestos de atacante conviene exigir al proveedor, qué documentar internamente desde el primer día y qué señales deberían disparar una revisión antes de que el problema llegue a un cliente.