Un generador de números de identificación nacional permite obtener valores con la forma correcta de cada país para probar formularios, validaciones y flujos de alta sin recurrir a documentos de personas reales. La dificultad no está en inventar cifras, sino en que esas cifras sean coherentes: cada país usa una longitud distinta, muchos incluyen un dígito de control calculado con una regla propia y algunos codifican en el número la fecha de nacimiento o la región de emisión. En esta guía se recorren esas diferencias, se explica por qué el marcador de posición que todo el mundo usa no sirve para nada y se traza la frontera entre probar un sistema y acreditar una identidad. Al terminar sabrás qué exigir a un conjunto de datos de prueba y por qué conviene configurarlo por país.
Qué cambia de un país a otro en un número de identificación
Las diferencias empiezan por la longitud, que va de nueve cifras en unos sistemas a dieciocho en otros. También cambia el conjunto de caracteres: algunos países usan solo dígitos, otros combinan cifras y letras, y hay sistemas que reservan un prefijo para distinguir a los residentes nacionales de los extranjeros. Y cambia el significado, porque en ciertos países el número no dice nada sobre la persona y en otros lleva incorporada información como la fecha de nacimiento.
En España, el documento nacional de identidad y el número de identificación de extranjero comparten una estructura parecida, con una parte numérica y una letra de control al final. En Turquía, el número de identidad nacional es una cadena puramente numérica con dos dígitos verificadores. En Brasil, el registro de personas físicas se calcula con una regla de control propia, y en Indonesia el documento de dieciséis cifras codifica datos demográficos en sus primeras posiciones.
Esa variedad tiene una consecuencia inmediata para quien construye un formulario internacional. No existe una validación única que sirva para todos, y tratar el campo como texto libre con un máximo de caracteres no es validar: es aplazar el problema hasta que el dato llegue a un sistema que sí lo comprueba. Un resumen de longitudes y formas está en la guía sobre la longitud del número de identidad por país.
El dígito de control y por qué un marcador de posición no sirve
Muchos de estos números terminan con un dígito o una letra que se calcula a partir de los anteriores mediante una regla aritmética conocida. En España se calcula con el resto de una división y se traduce a una letra; en otros países se combinan las cifras con pesos y se obtiene un valor verificador; en los sistemas con fecha incorporada, parte del número tiene que ser una fecha válida para que el documento exista. La comprobación es rápida, no necesita consultar ningún registro y por eso está implementada en casi todas partes.
De ahí que el marcador de posición clásico —una secuencia de cifras correlativas que muchos equipos usan en sus datos de ejemplo— resulte inservible. No supera ninguna de esas comprobaciones, así que el sistema lo rechaza en el primer filtro y la prueba se detiene antes de haber ejercitado la lógica que interesaba. Peor aún, algunos equipos responden a esa situación desactivando la validación en el entorno de pruebas, con lo que la prueba deja de medir lo que debía medir.
Lo que hace útil al material de prueba es precisamente que sus dígitos de control estén bien calculados. Un valor generado que pasa la comprobación llega hasta el siguiente paso del flujo, donde sí se puede comprobar el comportamiento del sistema. El detalle de las reglas por país está recogido en la guía sobre reglas de validación de documentos por país.
¿Por qué la longitud debe configurarse por país y no fijarse en el código?
Es tentador escribir una constante con la longitud esperada y no volver a pensarlo. El problema aparece en cuanto el producto se abre a un mercado nuevo: el campo que exigía una cifra concreta rechaza a todos los usuarios de ese país, y el error se descubre en producción, con las altas cayendo. La longitud es un dato de configuración, no una característica del sistema.
La misma lógica se aplica al conjunto de caracteres y a la normalización. Hay documentos que se escriben con puntos y guiones y otros que se escriben seguidos, y el sistema debe aceptar ambas formas y guardar una sola. Si la comparación se hace sobre la forma escrita, dos capturas del mismo documento pueden no coincidir. La guía sobre validación y normalización de direcciones plantea el mismo principio en otro terreno, y el razonamiento se traslada sin cambios.
Configurar por país tiene además un efecto sobre las pruebas. Si la regla vive en una tabla, se puede probar cada entrada de la tabla de forma aislada y comprobar que el comportamiento cambia correctamente al cambiar de mercado. Si la regla vive repartida por el código, cada país exige una prueba distinta y el mantenimiento se vuelve inmanejable. Para el mercado estadounidense, la forma y los rangos reservados del documento están descritos en la guía sobre el formato del número de la seguridad social.
¿Cómo se prueba un proceso de verificación sin datos reales?
Un flujo de alta que exige un documento suele tener cuatro tramos: la captura del valor, la validación de su forma, la comprobación de coherencia con otros campos y el envío a un proveedor externo. Los tres primeros se pueden ejercitar íntegramente con material sintético, porque dependen de reglas que están en el propio sistema. El cuarto es distinto, y ahí es donde conviene ser explícito sobre lo que se está probando.
Para los tres primeros tramos, el material de prueba debe incluir valores válidos de varios países, valores con el dígito de control alterado, valores con la longitud equivocada y valores con caracteres que no pertenecen al conjunto admitido. También conviene incluir un valor con espacios o guiones en posiciones poco habituales, porque el tratamiento de esos separadores es una fuente constante de errores. La fecha de nacimiento merece pruebas propias, y la guía sobre casos límite de la fecha de nacimiento recoge los más frecuentes.
Para el cuarto tramo, la estrategia razonable es sustituir al proveedor por una simulación controlada que devuelva respuestas conocidas. Así se prueba el manejo de los distintos resultados —correcto, incorrecto, pendiente, error de red— sin enviar ningún dato a ningún servicio. Ese enfoque también permite comprobar que el sistema no registra el documento en lugares donde no debería, un punto que se trata en la guía sobre datos de identidad en ficheros de prueba.
El contexto español y europeo
Para un producto que opera en España, el documento nacional de identidad y el número de identificación de extranjero son los dos casos más frecuentes, y ambos se comportan de forma parecida en un formulario. La diferencia que más se olvida es que el segundo se usa para personas que no tienen la nacionalidad, de modo que un sistema que etiqueta el campo como documento nacional está excluyendo a una parte de sus usuarios sin darse cuenta.
A escala europea, el marco de protección de datos añade una exigencia que conviene tener presente desde el diseño. Un número de identificación es un dato personal, y copiarlo desde producción a un entorno de pruebas es un tratamiento que necesita justificación. Como el material sintético no parte de ninguna persona, esa discusión desaparece. La relación entre el reglamento europeo y el uso de datos de prueba está desarrollada en la guía sobre el reglamento de protección de datos y los datos de identidad de prueba.
Hay otro detalle práctico en el caso español: el mismo número se escribe a veces con ceros iniciales y a veces sin ellos, y guardarlo como número los elimina. Es exactamente el mismo problema que aparece con los códigos postales y con cualquier identificador que empiece por cero. La solución es tratar todos estos campos como texto, sin excepciones.
El límite de cumplimiento en los procesos KYC
Un proceso de conocimiento del cliente existe para comprobar que una persona es quien dice ser, y ninguna herramienta de generación de datos puede participar en eso sin desnaturalizarlo. El material sintético sirve para probar la mecánica del proceso, nunca para superarlo. Esa frontera no es un matiz de redacción: es la diferencia entre verificar la lógica de tu sistema y engañar al sistema de otro.
De ahí se siguen dos reglas de uso. La primera es que los registros generados no deben enviarse a un proveedor de verificación real ni utilizarse para solicitar un alta. La segunda es que no deben presentarse ante un tercero como si fueran documentos de una persona. En pruebas internas, además, conviene etiquetar los registros para que nadie los confunda con datos de un cliente, y esa etiqueta también protege al equipo que los usa.
El marco regulatorio refuerza esta separación. Un documento sintético no activa obligaciones de conservación porque no pertenece a nadie, y esa ventaja desaparece en el momento en que alguien lo mezcla con datos reales. Mantener la separación es lo que permite que el material siga siendo útil y que el entorno siga siendo seguro. Las pruebas de edad, que comparten esta misma lógica, están tratadas en la guía sobre pruebas de verificación de edad.
Cómo integrar el material en las pruebas
La forma ordenada de trabajar tiene tres piezas. La primera es un conjunto fijo de valores guardado junto al código, con al menos un caso por país soportado y varios casos inválidos por cada uno. La segunda es una clave que identifique cada registro, de modo que un fallo citado en un informe se pueda reconstruir sin depender de la memoria de quien lo encontró. La tercera es una comprobación automática de que el conjunto sigue siendo válido cuando cambian las reglas de un país.
En el generador de datos de identidad de este sitio se elige un país y una división administrativa, y la herramienta devuelve un registro completo con nombre, fecha de nacimiento, dirección, teléfono y número de documento calculado con la regla de ese país. Como los campos provienen del mismo origen y las validaciones se aplican por construcción, el material llega a la prueba sin desajustes que discutir. Si el sistema que pruebas solo opera en un mercado, la página de Estados Unidos resume qué formatos aparecen allí y ayuda a decidir qué campos exigir.
Los límites de este material
Los valores que produce un generador son datos sintéticos. Tienen la longitud y el dígito de control correctos para su país porque se han construido siguiendo sus reglas, pero no pertenecen a ninguna persona ni figuran en ningún registro administrativo. Que un valor supere la validación de forma no significa que acredite una identidad.
Su uso está en probar tus propios formularios, tus validaciones y tus flujos internos en entornos que no sean de producción. No sirven para abrir cuentas, para superar una verificación de identidad ni para hacerse pasar por otra persona. Esa frontera es la que mantiene el material al margen de las obligaciones que sí se aplican a los datos de personas reales.
Siguientes pasos
Revisa cómo valida tu sistema el campo de documento y comprueba dos cosas: si la longitud está configurada por país y si la comparación se hace sobre el valor normalizado y no sobre el texto escrito. Con esas respuestas, el generador de números de identificación nacional devuelve valores válidos de los países que necesites, con sus dígitos de control calculados. Recuerda el límite: son datos de prueba generados para probar software, no corresponden a ninguna persona real y no sirven para acreditar nada ante nadie.