Identificación falsa > Artículos > Cómo funciona realmente nuestro generador de personas — y qué sigue haciendo mal

Cómo funciona realmente nuestro generador de personas — y qué sigue haciendo mal

La mayoría de los generadores de nombres falsos se reducen a una sola función: sacar un nombre de una lista, sacar una ciudad de otra lista y pegar ambos. El nuestro tampoco es mucho más que eso — pero es justo en la distancia entre «no mucho más» y «una sola función» donde viven todos los problemas interesantes.

Este artículo documenta toda la maquinaria: qué tiene en cuenta, cómo se mantiene reproducible y — la sección que más importa — la lista de lo que, demostrablemente, no modela. Todo lo que sigue se midió el 18 de julio de 2026 sobre el código y los ficheros de datos entregados, no sobre los documentos de diseño.

Las doce entradas

Una ficha generada es una función pura de (locale, seed). En tiempo de ejecución no hay ninguna base de datos. Esto es todo lo que la alimenta.

1. País

64 locales, cada uno con sus propios corpus de nombres de pila, apellidos, calles, ciudades, códigos postales, empresas y números de teléfono. «Locale» designa aquí más bien un país que una lengua: de_DE, de_AT y de_CH son tres conjuntos de datos distintos, y lo mismo ocurre con fr_CH, de_CH e it_CH — mismo país, tres lenguas, un único plan de numeración telefónica compartido.

El orden de las palabras en la dirección es propio de cada locale, porque un número de portal no se coloca dos veces de la misma manera:

PatrónLocalesEjemplo
{n} {s}en_US, en_GB, fr_FR, vi_VN192 Mill Street
{s} {n}por defecto — de_DE, pl_PL, nl_NLSchillerstraße 84
{s}, {n}uk_UA, ru_RU, es_ES, it_ITвул. Широка, 174
{s} nr. {n}ro_RO, ro_MDStrada Spitalului nr. 13
{s} {n}.hu_HUHonvéd utca 52.
{s} No:{n}tr_TRKale Sokak No:71
{s}{n}號zh_TW ( para zh_CN)中央路124號

La versión anterior de este código llevaba {s}, {n} — el modelo ucraniano — fijado en el código para los 64 locales. Toda dirección estadounidense se leía como Mill Street, 192.

El orden del nombre completo es, de nuevo, un asunto aparte. zh_CN, zh_TW, ja_JP y ko_KR colocan el apellido delante sin espacio (王達仁, no 達仁 王); hu_HU y vi_VN lo colocan delante con espacio (Ferenczi Bódog). Todo lo demás sigue el orden First Last.

63 de los 64 locales llevan ficheros de calles elaborados a mano. ja_JP deliberadamente no: una dirección japonesa es 丁目-番-号 (manzana–parcela–edificio), no calle más número, e inventar una capa de calles para Japón sería inventar un sistema que el país no tiene.

2. Sexo

Los nombres de pila y los apellidos se extraen de corpus propios de cada sexo, pero la razón por la que los corpus difieren se reparte en tres casos:

GrupoNúmeroQué ocurre
Apellidos idénticos49en_US, de_DE, ja_JP — el apellido no varía según el sexo
Apellidos declinados12Παπαδόπουλος ♂ / Παπαδοπούλου ♀; Novák / Nováková
Conjuntos de apellidos separados3en_IN, bn_BD, ka_GElistas distintas, no formas emparejadas

El tercer grupo es el que hace fracasar a los validadores ingenuos. La tradición sij atribuye Singh sobre todo a los hombres y Kaur a las mujeres; en bengalí, Begum y Khatun son exclusivamente femeninos. No son dos grafías de un mismo nombre, así que los ficheros masculino y femenino tienen legítimamente longitudes distintasen_IN entrega 836 apellidos masculinos y 842 femeninos; bn_BD, 400 y 404. Un validador que exige que «los dos ficheros coincidan línea por línea» bloquea en silencio que el apellido más frecuente de todo un país llegue a añadirse en ningún sitio.

El griego pertenece al segundo grupo, y eso fue una corrección: al principio figuraba como invariante, lo cual es falso — -ος-ου, -ης, y 545 de los 648 pares de apellidos griegos cambian efectivamente.

El apellido de soltera se extrae siempre del corpus femenino, porque un apellido de soltera es el apellido de la madre antes de casarse, sea cual sea el sexo del titular de la ficha.

3. Año de nacimiento → cohorte de edad

Para diez locales — de_AT, en_CA, en_GB, en_IE, en_NZ, en_US, es_ES, fr_FR, it_IT, no_NO — el nombre de pila se extrae de un corpus construido para la década en que nació la persona de la ficha, y no de la lista histórica del país. Ocho de los diez cubren las siete décadas; la serie austríaca empieza en 1984 y la italiana en 1999, lo que constituye un defecto en sí mismo y tiene su propio artículo. Los límites de década siguen la convención del INSEE: [1941, 1951, 1961, 1971, 1981, 1991, 2001], de modo que 1950 cae en la clase de 1941 y 1951 abre la siguiente.

El efecto sobre los corpus entregados, ordenados por los recuentos reales de nacimientos:

LocaleNacidos ~1951 (top 6)Nacidos ~2001 (top 6)
no_NOJan, Per, Bjørn, Kjell, Svein, TerjeJonas, Andreas, Mathias, Martin, Daniel, Sander
fr_FRJean, Michel, Patrick, Alain, Philippe, ChristianLucas, Enzo, Thomas, Théo, Hugo, Nathan
es_ESAntonio, José, Manuel, Francisco, Juan, José LuisAlejandro, Daniel, Pablo, David, Adrián, Álvaro
en_IEJohn, Patrick, Michael, James, Paul, ThomasJack, Sean, Conor, Adam, James, Daniel
en_NZJohn, Peter, David, Michael, Stephen, RobertJack, Joshua, Samuel, James, Benjamin, Daniel
en_USMichael, James, Robert, David, John, WilliamJacob, Michael, Joshua, Matthew, Ethan, Andrew
en_CARobert, David, John, Michael, James, RichardEthan, Jacob, Matthew, Joshua, Liam, Ryan

El noruego y el francés se renuevan por completo; el estadounidense apenas se mueve en la cabeza, lo que constituye en sí mismo el hallazgo — los nombres masculinos anglófonos rotan más despacio. El mecanismo, y los datos de registro que lo sustentan, son el objeto de Su nombre es una partida de nacimiento.

Una docena de fichas masculinas en_US reales, extraídas en los dos extremos, tienen este aspecto:

  • nacidas en 1951: David, John, Julian, Jessie, Allen, Dan, Willie, Keith, Gary, Dennis, Rodger, Rick
  • nacidas en 2004: Kevin, Caleb, Andrew, Jajuan, Carson, Jacob, Samson, Baylor, Talon, Benjamin, Daniel, Reece

Conviene notar que se trata de extracciones y no de la cabeza de la lista — Rodger y Jajuan salen de la cola. Ese es justamente el sentido de la ponderación: la cabeza domina sin que la cola desaparezca.

4. Frecuencia

Los nombres están ponderados, no son uniformes. Hasta el 18 de julio de 2026 el peso se expresaba repitiendo una línea en el corpus — un peso de 7 significaba siete líneas idénticas —, lo que limitaba la resolución a 255 y hacía la cola más pesada cuanto más completos eran los datos. Medido sobre el registro taiwanés: a plena profundidad (2.707 apellidos), el top diez sacaba un 24,9 % allí donde la cifra real es del 52,8 %, un error de −27,9 pp que crecía con cada apellido raro añadido. El formato antiguo castigaba la exhaustividad.

El corpus ya solo contiene valores únicos, con los pesos en un fichero .wgt paralelo — uint32 acumulados, uno por entrada, resueltos por búsqueda binaria. Ya no hay techo, la caché es más pequeña y el peso puede ser un recuento literal de portadores.

Doce corpus de apellidos llevan ahora recuentos reales de registro en lugar de puestos calibrados, remedidos el 22 de julio de 2026:

LocaleEntradasSuma de pesosApellido más frecuenteProporción del top 10
en_US2.064129.931.469Smith — 2.369.64410,80 %
es_ES2.52234.026.331García — 1.446.93724,94 %
en_GB1.51727.125.558Smith — 652.56312,05 %
zh_TW2.70723.367.536陳 — 2.618.99452,81 %
fr_FR1.73120.114.307Martin — 250.0136,24 %
pl_PL28.95916.682.538Nowak — 98.3873,19 %
uk_UA2.5629.752.950Мельник — 107.8788,42 %
sv_SE2.4455.594.332Andersson — 216.48823,28 %
da_DK7172.984.886Nielsen — 222.35546,27 %
no_NO3.7802.854.195Hansen — 47.87911,72 %
vi_VN29899.441Nguyễn — 30.49269,58 %
en_IE90880.922Murphy — 1.71713,21 %

La dispersión es, por sí sola, todo el argumento a favor de los recuentos reales: el top diez polaco llega al 3,19 % y el vietnamita al 69,58 %. Cualquier generador que calibre todos los países en la misma banda de concentración borra una diferencia de veinte veces. La metodología para comprobarlo — y las trampas que esa comprobación encierra — está en Cómo auditar un conjunto de datos de frecuencia de nombres.

Los nombres de pila van más retrasados: solo ocho locales funcionan con recuentos reales de nacimientos (en_US, en_GB, fr_FR, es_ES, sv_SE, no_NO, en_IE, en_NZ). Los apellidos ucranianos se apoyan en recuentos de registro, pero los nombres de pila ucranianos no — el locale está migrado solo a medias, y decir «uk_UA tiene pesos reales» sin esa reserva sería falso.

5. Ciudad ↔ código postal como un solo par

La ciudad y el código postal no son dos extracciones independientes. Cada locale entrega locality/<locale>.tsv, cuyas filas tienen la forma City⇥Region⇥Postcode, más una cuarta columna opcional de población añadida el 18 de julio de 2026. Se extrae una sola fila, y la ciudad y el código postal salen juntos de ella, de modo que siempre concuerdan. La región se conserva para la ponderación y la comprobación, pero no se imprime en la ficha.

6. Tamaño de las ciudades

A 22 de julio de 2026, 44 de los 64 locales ponderan la selección de ciudad por población. La diferencia se ve en 400 extracciones:

LocaleCiudades distintas alcanzadasCabeza del recuento
uk_UA (ponderado)51Київ 67, Харків 38, Донецьк 21, Одеса 19
es_AR (sin ponderar)60Salta 13, Cipolletti 12, Rafaela 12, Concepción del Uruguay 11

En la columna argentina salieron las 60 ciudades, y Buenos Aires — tres millones de habitantes en la ciudad propiamente dicha — no se extrae más a menudo que Rafaela, que ronda los 100.000. Eso es lo que significa una selección uniforme, y resulta invisible en cualquier ficha tomada por separado. El tratamiento completo está en Por qué los generadores de direcciones producen ciudades implausibles.

7. Determinismo — y por qué cada extracción es exactamente una extracción

La URL /<country>/<id> debe devolver siempre la misma persona. Es un requisito de producto, no una coquetería técnica: un enlace permanente a una ficha no vale nada si la ficha se va desplazando.

La semilla se obtiene aplicando una función de hash a la sal secreta de la instalación junto con el id, y el resultado inicializa el PRNG. Todo lo que viene después se extrae de ese único flujo. El hash exacto, su truncamiento y el propio secreto no se publican aquí de forma deliberada — son la única parte de este diseño que debe permanecer privada, y la razón está en la sección siguiente.

Lo sutil no está en la siembra de la semilla. Está en este patrón:

function pick(string $dataset): ?string
{
    $h    = open($dataset);
    $keep = mt_rand(0, PHP_INT_MAX);          // exactly one draw, in BOTH branches
    $v    = ($h !== null && $h['total'] >= 1) ? read_at($h, index_for($h, $keep)) : null;
    mt_srand($keep);                          // stream returns to the same point in BOTH branches
    return $v;
}

Cada función de selección gasta exactamente un mt_rand() y después vuelve a sembrar el flujo con $keep. Tras la llamada, el RNG queda en un punto idéntico tanto si el conjunto de datos existía, como si faltaba, como si se acabó cayendo en un mecanismo de reserva que quemó un número desconocido de extracciones.

Sin esa invariante, añadir un solo conjunto de datos desplaza el flujo para todos los campos posteriores. Construya un corpus nuevo y todas las fichas del sitio cambiarán de nombre, dirección, teléfono, contraseña y fecha de cumpleaños. Peor aún, nos topamos con la versión real de esto: un worker que una vez vio que faltaba un conjunto de datos guardó en caché ese resultado negativo y se quedó con el mecanismo de reserva Faker durante el resto de su vida, de modo que la misma URL servía personas distintas desde distintos workers PHP-FPM en el mismo instante. La corrección tenía dos partes — nunca guardar en caché una búsqueda negativa y hacer que ambas ramas cuesten una extracción.

La misma disciplina cubre la búsqueda de cohorte. Una función auxiliar del tipo «el primero de estos candidatos» — probar el corpus decenal y, si no, replegarse al general — recorre los candidatos en orden pero gasta una sola extracción en total; un ingenuo pick($a) ?? pick($b) ?? faker() gastaría dos o tres y haría que la presencia de datos de cohorte volviese a barajar la ficha entera.

8. El año de creación de la ficha va codificado en su id

El id no es opaco. Algunos de sus primeros bytes llevan estructura en vez de entropía — entre ellos la versión del archivo, el intervalo de edad solicitado con el deslizador, un indicador de sexo forzado y el año en que se creó la ficha. Los desplazamientos exactos se omiten por la razón dada en el §7; lo que importa para este artículo es que el año de creación se almacena, no dónde.

El año de nacimiento se calcula como card_year − age, no como current_year − age. Sin el año almacenado, cada ficha cambiaría en silencio su fecha de nacimiento cada 1 de enero: la edad es estable porque viene de la semilla, así que el año de nacimiento se desplazaría hacia adelante con el calendario. Este byte se añadió el 16 de julio de 2026, y los id emitidos antes llevan ahí un valor aleatorio — por eso se acota a [1990, current year]. Sin acotar, un byte 0x93 se leía como el año 2147 y producía una ficha nacida en 2103.

9. La sal de la instalación

El generador se despliega con una única sal secreta. Sin ella, /<country>/<id> sería una función pura del id y de nada más — cualquiera que ejecutase el mismo código sobre los mismos corpus devolvería literalmente la misma persona para la misma URL. La sal entra tanto en la semilla de identidad como en el hash del país aleatorio, así que mueve la ficha entera, no uno solo de sus campos. Sustituir la sal por otra y volver a extraer el mismo id muestra hasta qué punto el efecto es total:

Valor de la sal (ilustrativo)Mismo id, en_US, edades 30–60
salt-a|v1Bryan Foster · 192 Mill Street · San Diego 92101 · 1994-11-24
salt-b|v1Michael Jones · 199 Forest Avenue · Fresno 93701 · 1989-02-01
salt-c|v1Jillian Thompson · 67 Lincoln Avenue · Oklahoma City 73101 · 1987-03-27

Ni un solo campo sobrevive al cambio: nombre, calle, ciudad, código postal y fecha de nacimiento son todos distintos. Las sales de arriba son valores de relleno — el valor real no se publica, y en eso consiste precisamente el mecanismo. El sufijo |v1 es la salida de emergencia: incrementarlo regenera todas las fichas de la base. Es un recurso de un solo uso, lo que es una razón más para no gastarlo publicando el valor actual.

10. Números de teléfono

Los teléfonos proceden de una tabla de 963 prefijos móviles reales repartidos en 65 entradas de locale, emitidos en formato E.164 (+, indicativo de país, número nacional, sin separadores). Faker se abandonó para este campo por dos razones medidas: dentro de un mismo locale su formato variaba (el_GR producía tanto 698 7681 770 como 6969005371) y varios proveedores sorteaban al azar el propio indicativo de países_AR emitía 35 indicativos de país distintos e it_IT emitía 99. Cada ficha italiana llevaba un número de teléfono de un país elegido al azar.

Se usan rangos de móvil en lugar de líneas fijas: son más actuales y no están ligados a una ciudad concreta, lo que evita atribuirse una precisión (el prefijo de zona concordando con la ciudad) que nada más en la ficha respalda.

11. Eircode

Un Eircode irlandés se compone de una clave de enrutamiento de 3 caracteres más un identificador de 4 caracteres que designa un único edificio. Copiar un código tal cual del fichero de localidades daría a todas las fichas de una misma ciudad un Eircode idéntico — un defecto que cualquier lector irlandés detecta de inmediato.

Por eso la clave de enrutamiento se conserva tal como figura en la fila de localidad (es real y concuerda con la ciudad) y los cuatro caracteres finales se extraen del alfabeto Eircode, ACDEFHKNPRTVWXY0123456789 — 25 símbolos, excluidos B, G, I, J, L, M, O, Q, S, U, Z, que Eircode omite a propósito para evitar confusiones entre caracteres. Cinco fichas consecutivas:

Kildare      R51 X775
Tullamore    R35 5RT8
Drogheda     A92 HNK0
Sligo        F91 XAPK
Listowel     V31 29FX

Esas cuatro extracciones adicionales solo ocurren para en_IE; todos los demás locales pasan de largo por esa rama, así que las fichas de ningún otro locale se desplazan.

12. Dominio de correo

El dominio del buzón procede de un archivo versionado, de solo adición, de instantáneas congeladas, y el número de instantánea son los dos primeros dígitos hexadecimales del id. Una ficha nueva recibe current; una ficha antigua lee su versión de su propio id y obtiene para siempre esa instantánea congelada. La lista viva de dominios que funcionan cambia constantemente; los enlaces permanentes, no.


Lo que el generador no hace

Cada punto de los que siguen es una limitación real y reproducible. Ninguno es teórico.

Los nombres no varían por región dentro de un país

Baviera y Hamburgo ponen nombre a sus hijos de forma distinta; Cataluña y Andalucía, también. Nosotros modelamos una sola distribución de nombres por país. Una ficha de Múnich y una ficha de Kiel se extraen del mismo corpus. Las calles adolecen de la misma planitud: hay un único fichero de calles por país, así que nada distingue una lista de calles bávara de una hanseática.

Los apellidos no varían con la edad

Los datos de cohorte existen solo para los nombres de pila. Los apellidos de origen migratorio tienen una estructura por edad muy marcada — un corpus alemán de apellidos de personas de 20 años no es el de las de 80 — y nosotros la aplanamos por completo. Una ficha alemana nacida en 1941 tiene la misma probabilidad de sacar Öztürk que una nacida en 2001.

El nombre de pila y el apellido no están coordinados

Este es el defecto más visible en las fichas tomadas una a una. Los dos campos son extracciones independientes de corpus independientes, así que las capas se cruzan. En de_DE, los nombres de pila de la capa turca llevan el 0,69 % del peso de los nombres de pila, y los apellidos de la capa turca, el 0,87 % del peso de los apellidos. Extraídos de forma independiente:

CombinaciónProbabilidad
Nombre turco + apellido no turco0,68 %
Nombre alemán + apellido turco0,87 %
Nombre turco + apellido turco0,006 %

Así pues, alrededor del 1,5 % de las fichas alemanas cruza la capa y solo seis de cada cien mil producen una pareja turco-alemana coherente — Mehmet Müller es unas 100 veces más probable que Mehmet Öztürk. Lo mismo sucede allí donde un corpus contiene más de un estrato onomástico: un nombre de pila árabe aterriza sobre un apellido asquenazí en he_IL, Aidan Paun sale de en_IE. La solución consiste en agrupar los corpus en estratos y extraer la pareja de un solo estrato; es una deuda abierta, no un plan que hayamos ejecutado. Véase La capa migratoria que falta.

Las calles no están ligadas a las ciudades

La calle y la ciudad son extracciones independientes dentro de un locale. Doce fichas ucranianas consecutivas producen вул. Захисників України, 154 en Сімферополь y вул. Гетьмана Павла Скоропадського, 161 en Київ — bastante plausible —, pero nada impide que una calle que solo existe en una ciudad se coloque en otra, ni que un nombre que corresponde a una plaza y no a una calle aparezca con un número de portal. El emparejamiento que imponemos es ciudad↔código postal; calle↔ciudad, no.

Los pesos de los nombres de pila de 56 locales están calibrados, no medidos

Solo ocho locales toman los pesos de sus nombres de pila de registros de nacimientos. Los otros 56 se ajustaron hacia una banda supuesta de «20–35 % de proporción del top 10 en todas partes» — una norma que no existe. Medido frente a los seis locales que disponían de recuentos reales cuando se hizo la comparación, en julio de 2026: la concentración real del top 10 abarca 9,88–33,32 % (un factor de 3,4), nuestros corpus calibrados abarcan 20,68–24,84 % (factor de 1,20), y la correlación de puestos de Spearman entre nuestras cifras y las reales es de 0,056. Eso no es una señal comprimida; es la ausencia total de señal de país. Los errores individuales alcanzan los 13 pp — la proporción real del top 10 femenino en Estados Unidos es del 9,88 % y nuestro corpus dice 23,01 %. La calibración también aplanó la diferencia real de concentración entre hombres y mujeres, de 7,41 pp a 1,81 pp. Cálculos completos en El desplome de la diversidad de nombres de pila.

20 locales no tienen pesos de ciudad

44 de los 64 ficheros de localidades llevan una columna de población. Los 20 restantes extraen las ciudades de manera uniforme. Una parte de ellos es trabajo pendiente en cola; otra es deliberada. Allí donde el instituto de estadística de un país solo publica cifras regionales, o donde los números disponibles mezclan unidades incompatibles — la kommune noruega frente al tettsted, la gobernación saudí frente a la ciudad —, dejamos el locale en extracción uniforme en lugar de montar una columna a partir de dos cosas de naturaleza distinta. Una ciudad extraída uniformemente es una aproximación documentada; una columna en la que dos tercios de las filas son una unidad y un tercio otra es un defecto que nadie, nosotros incluidos, vería jamás.

Las cohortes cubren 10 locales de 64

Cincuenta y cuatro locales extraen un nombre de pila sin ninguna referencia al año de nacimiento de la ficha. En ellos, una ficha nacida en 1945 y una ficha nacida en 2005 se extraen de la misma lista.

Faker sigue siendo el suelo

Allí donde falta un conjunto de datos, el campo recurre a la biblioteca Faker — abandonada desde 2020, que lanza avisos de obsolescencia en PHP 8.5 y es el origen de los defectos de número de teléfono y de formato de dirección descritos más arriba. Deliberadamente nunca se llega a ella cuando los corpus están construidos, pero sigue siendo el suelo que hay bajo cada campo.


Por qué todo esto importa a quien usa el sitio

Dos de estas propiedades son las que un usuario nota de verdad.

El enlace permanente funciona para siempre. La URL de una ficha es una promesa: el nombre, la dirección, el teléfono y la fecha de nacimiento que figuran en ella serán idénticos dentro de cinco años. Por eso el año de nacimiento queda congelado en el id, por eso el dominio de correo procede de un archivo versionado y por eso cada función de selección está disciplinada hasta exactamente una extracción. Que falte cualquiera de esas tres cosas y la URL pasa a ser en silencio otra persona — y en silencio es la palabra que cuenta, porque nada en una ficha llega nunca a parecer roto. Simplemente ya no es la ficha que se guardó en marcadores.

El realismo es una propiedad de la distribución, no de la ficha tomada una a una. Cada ficha brasileña extraída uniformemente lleva una ciudad real con un código postal correcto. El conjunto de todas ellas describe un Brasil donde São Paulo tiene el mismo tamaño que Palmas. Ninguna inspección de fichas individuales, por minuciosa que sea, lo revela: por eso las limitaciones anteriores se enuncian como mediciones y no como impresiones — las que detectamos, las detectamos contando, y varias de ellas eran cosas que habíamos supuesto correctas.


Datos actualizados a 2026-07-18

Cada recuento, cada proporción y cada ejemplo de este artículo se midieron en esa fecha directamente sobre el código en funcionamiento y los ficheros de datos entregados: 64 directorios de locales que contienen 261 ficheros de pesos y 20 ficheros de cohortes, 64 tablas de localidades y 63 tablas de calles. Los recuentos de extracciones de ciudad y de prefijos se volvieron a medir el 22 de julio de 2026.

Los ejemplos de fichas se generaron ejecutando la función de identidad en producción sobre los corpus entregados, por la misma vía de siembra de la semilla que usa el sitio en línea. Las tablas de cabeza de corpus se calcularon descodificando los ficheros de pesos acumulados y ordenando por peso; son las cifras propias de los corpus, que, para los doce locales listados, son los recuentos propios de los registros.

Las fuentes de registro que hay detrás de los corpus ponderados están documentadas locale por locale en los artículos complementarios: Los 10 apellidos más frecuentes por país, Curvas de concentración de apellidos y Datos abiertos sobre los registros de apellidos.

← Artículos