Cómo preparar datos sintéticos para demostrar una app sin usar información de clientes

Empieza por la historia que vas a mostrar. Define qué operación debe entender el público: recibir una solicitud, asignar un responsable, comparar alternativas o completar un pedido. Después enumera los objetos que necesita esa historia y sus relaciones. Un escenario comercial puede requerir cuentas ficticias, contactos de prueba y oportunidades asociadas. No empieces pidiendo cientos de filas a un generador. Un conjunto pequeño y deliberado permite explicar mejor la aplicación y descubrir qué datos faltan para recorrer el proceso completo sin improvisar durante la demostración.

Construye desde reglas, no desde personas reales. Especifica campos, tipos y valores permitidos sin copiar registros de clientes. Utiliza nombres claramente ficticios, identificadores de prueba y descripciones creadas para el escenario. Cambiar nombres dentro de una base real no elimina necesariamente detalles que pueden identificar a alguien. Esta guía propone generar desde una estructura y situaciones inventadas, no anonimizar información existente. Si se utilizan métodos que aprenden de datos personales reales, hacen falta evaluaciones adicionales de privacidad; llamar sintético al resultado no demuestra por sí solo que sea seguro ni que no reproduzca información sensible.

Haz que las relaciones tengan sentido. Comprueba que cada pedido apunte a una cuenta que existe, que sus elementos pertenezcan al catálogo ficticio y que las fechas respeten la secuencia prevista. Un registro cerrado no debería aparecer sin la información que la aplicación exige para cerrarlo, salvo que sea un caso de error diseñado intencionalmente. Mantén identificadores estables entre archivos. La coherencia permite explicar el comportamiento del sistema; una colección de nombres plausibles con relaciones rotas solo produce una demostración frágil que depende de evitar las pantallas donde aparecen sus contradicciones.

Incluye diferencias que prueben el producto. Prepara un caso sencillo, uno con varios elementos, otro con información pendiente y alguno que deba ser rechazado por una regla. Añade textos largos, caracteres acentuados y listas vacías cuando tengan sentido. No necesitas una base enorme para comprobar esos comportamientos. Documenta qué resultado esperas en cada caso, de modo que un fallo pueda distinguirse de una situación deliberada. El conjunto debería mostrar el recorrido normal y sus límites, no únicamente una secuencia perfecta que oculta cómo responde la aplicación cuando recibe una entrada incompleta.

Desconecta consecuencias reales. Antes de ejecutar la demostración, verifica que los datos ficticios no activen correos, mensajes, pagos, reservas o integraciones sobre cuentas reales. Un nombre inventado no impide que una acción utilice una credencial de producción. Emplea un entorno de prueba y servicios de simulación o captura cuando estén disponibles, manteniendo visibles sus diferencias respecto del servicio real. En campos de contacto que no necesites, evita introducir números plausibles que podrían pertenecer a terceros. La separación debe aplicarse al entorno y a sus conexiones, no solamente al contenido que se muestra en pantalla.

Guarda una versión recuperable. Conserva el conjunto inicial y una forma clara de devolver la demostración a ese estado. Después de varias presentaciones, los registros pueden acumular cambios que alteran el recorrido previsto. Una restauración controlada evita corregir datos manualmente antes de cada sesión. Identifica también qué versión de la aplicación admite el conjunto y qué reglas comprueba. Si cambia un campo obligatorio, actualiza el escenario de prueba. La reproducibilidad ayuda a comparar mejoras y permite que otra persona presente el producto sin conocer todos los ajustes que su autor realizó durante el desarrollo.

Explica qué está viendo el público. Señala que la información y los resultados del escenario son ficticios. No conviertas importes, clientes inventados o tasas de éxito de la demostración en afirmaciones comerciales sobre desempeño real. El valor de la prueba consiste en mostrar cómo se relacionan las funciones y qué ocurre ante distintas entradas. Un paquete final puede incluir los datos, el guion del recorrido, resultados esperados y pasos de restauración. Así la demostración conserva fuerza explicativa sin depender de exponer información ajena ni de presentar un escenario diseñado como evidencia de resultados obtenidos con clientes.