Amazon construyó un reclutador con IA que aprendió solo a odiar a las mujeres. Yo construí uno que no puede.

En 2014, un equipo de ingenieros de aprendizaje automático en Edimburgo se propuso resolver la contratación a escala de Amazon. Le das al sistema 100 currículums y te devuelve los cinco mejores, clasificados de una a cinco estrellas — como si valoraras productos. Elegante. Eficiente. Y en menos de tres años descubrieron que el sistema se había enseñado a sí mismo que ser mujer era una característica descalificadora.

La IA penalizaba los currículums que contenían la palabra "femenino" — como en "Capitana del Club de Ajedrez Femenino". Rebajaba la puntuación de las graduadas de dos universidades exclusivamente femeninas. No porque nadie se lo hubiera indicado. Sino porque, cuando entrenas un modelo con diez años de datos de contratación de un sector dominado por hombres, "ser hombre" se convierte, estadísticamente, en uno de los predictores más fuertes de "ser contratado".

Recuerdo haber leído el reportaje de investigación de Reuters cuando salió a la luz. Ya estaba metido de lleno en la construcción de sistemas de grafos de conocimiento en Veriprajna, y mi primera reacción no fue de asombro — fue de reconocimiento. Llevaba meses argumentando que los motores de correlación estadística no tenían por qué tomar decisiones sobre el potencial humano. La historia de Amazon no era una anomalía. Era una inevitabilidad matemática. Y me radicalizó hasta convencerme de que todo el enfoque arquitectónico de la contratación con IA estaba roto — no en los bordes, sino en los cimientos.

El problema no es el sesgo. Es la arquitectura.

Esto es lo que la mayoría de la gente entiende mal sobre el desastre de Amazon: creen que los ingenieros fueron descuidados. No lo fueron. Eran algunos de los mejores ingenieros de aprendizaje automático del planeta. Cuando descubrieron el sesgo de género, intentaron corregirlo. Programaron explícitamente el modelo para que ignorara los términos específicos de género. Y el modelo encontró vías para eludirlo.

Este es el concepto de variables proxy, y es lo que me quita el sueño. Los modelos de aprendizaje profundo son buscadores incansables de patrones. Elimina la palabra "mujer" de la entrada, y el modelo se aferra a la estructura de las frases. Los estudios muestran que los currículums de hombres tienden a usar verbos como "ejecuté" y "capturé", mientras que los currículums de mujeres se inclinan por un lenguaje más comunitario. El modelo ve que "ejecuté" se correlaciona con "contratado" y reconstruye silenciosamente el sesgo de género solo a través de la lingüística.

Los ingenieros de Amazon no podían extirpar quirúrgicamente el sesgo sin destruir la capacidad predictiva del modelo. Así que cancelaron todo el proyecto.

No se puede arreglar un sistema que discrimina por accidente. Hay que construir uno que no pueda discriminar por diseño.

Esa frase ha sido mi estrella polar durante tres años. Y es la razón por la que construimos el motor de contratación de Veriprajna sobre grafos de conocimiento en lugar de redes neuronales.

¿Por qué todo reclutador de IA acaba aprendiendo a discriminar?

Necesito que entiendas algo sobre cómo funciona el aprendizaje profundo en la contratación, porque el modo de fallo es contraintuitivo.

Una red neuronal no entiende lo que significa "Python". No sabe que Python es un lenguaje de programación útil para la ciencia de datos. Solo sabe que la cadena "Python" aparecía con frecuencia en los currículums de las personas que fueron contratadas. Si "Lacrosse" también aparecía con frecuencia — quizás por correlaciones socioeconómicas entre ciertos deportes y ciertas escuelas que nutren a ciertas empresas — el modelo podría ponderar "Lacrosse" con tanto peso como "Python".

Esto es correlación disfrazada de inteligencia. El modelo no razona sobre causa y efecto. Encuentra patrones y los optimiza. Y aquí está la parte insidiosa: amplificación del sesgo significa que estos modelos no solo replican los sesgos históricos — los exageran. Si los hombres eran el 60 % de la fuerza laboral en los datos de entrenamiento, el modelo podría inclinarse a contratar un 80 % o un 90 % de hombres para maximizar su puntuación de precisión.

Al principio tuve una conversación con un posible inversor que me dijo: "Simplemente usa GPT-4 para el cribado de currículums. Todos los demás lo hacen". Le pregunté: si introduces el mismo currículum en GPT-4 dos veces, ¿obtienes la misma puntuación? Hizo una pausa. La respuesta es no — los LLM son estocásticos. Son no deterministas. Ejecuta la misma entrada dos veces y obtienes dos salidas diferentes. En un escenario de auditoría, eso no es una peculiaridad. Es un fallo de cumplimiento.

Los muros regulatorios se están cerrando

Esto ya no es teórico. Los gobiernos han visto la historia de Amazon y están legislando.

La Ley Local 144 de Nueva York, vigente desde julio de 2023, exige que cualquier empleador que utilice una herramienta automatizada de decisión de empleo se someta a una auditoría de sesgo independiente anual. No una auditoría vaga de "comprobamos la equidad" — una específica y cuantitativa. La ley obliga a calcular las tasas de selección y las ratios de impacto para cada categoría de raza, etnia y sexo. Si la tasa de selección de un grupo protegido dividida por la tasa del grupo más seleccionado cae por debajo de 0,8 — la "regla de los cuatro quintos" — eso constituye evidencia prima facie de impacto dispar.

La Ley de IA de la UE va más allá. Clasifica los sistemas de IA utilizados para la contratación como de alto riesgo — la misma categoría que los dispositivos médicos y las infraestructuras críticas. El Artículo 13 exige que estos sistemas sean "suficientemente transparentes para permitir a los usuarios interpretar la salida del sistema". El Artículo 14 requiere supervisión humana — la capacidad de anular las decisiones de la IA. Pero no se puede anular de forma significativa una decisión que no se entiende.

Y bajo el RGPD, el Artículo 15(1)(h) otorga a los interesados el derecho a acceder a "información significativa sobre la lógica aplicada" en las decisiones automatizadas. El Considerando 71 menciona explícitamente el derecho a "obtener una explicación de la decisión alcanzada".

Intenta explicar la decisión de una red neuronal. Adelante. "La neurona 4.502 se activó con una intensidad de 0,8" no es una explicación significativa. Tampoco lo es "el modelo determinó que eras un 73 % de coincidencia" sin más detalles.

La brecha entre la complejidad técnica y el requisito legal de una explicación sencilla es la crisis central de la moderna tecnología de RR. HH.

Escribí sobre este panorama regulatorio con más profundidad en la versión interactiva de nuestro whitepaper, que recorre exactamente cómo se aplica cada regulación a las diferentes arquitecturas de IA.

¿Y si la IA no pudiera ver el género en absoluto?

Aquí es donde necesito contarte sobre la noche en que todo encajó para mí.

Habíamos estado experimentando con distintos enfoques de eliminación de sesgos — entrenamiento adversarial, aumento contrafactual, el conjunto de herramientas habitual. Y estaba sentado en nuestra oficina a las 11 de la noche, mirando una visualización de grafos en mi pantalla, cuando tuve una de esas revelaciones obvias en retrospectiva: estábamos intentando enseñar al modelo a ignorar el sesgo. ¿Y si construyéramos una arquitectura en la que el sesgo literalmente no pudiera entrar en el motor de razonamiento?

En un grafo de conocimiento, los datos se almacenan como nodos (entidades) y aristas (relaciones). Un nodo Persona se conecta con nodos Habilidad. Los nodos Habilidad se conectan con otros nodos Habilidad a través de relaciones semánticas. El grafo sabe que "PyTorch" es una biblioteca para "aprendizaje profundo", que es un subconjunto de la "inteligencia artificial". Así que si un puesto requiere "experiencia en IA" y un candidato incluye "PyTorch", el grafo traza la ruta y encuentra una coincidencia — incluso sin que la palabra clave "IA" aparezca en ningún lugar del currículum.

Aquí está la decisión arquitectónica crítica: cuando se ejecuta nuestro algoritmo de emparejamiento, opera sobre un subgrafo restringido. Este grafo de inferencia contiene Habilidades, Roles, Niveles de experiencia y Certificaciones. Excluye explícitamente los nodos de Nombre, Género, Etnia, Dirección y fechas de graduación.

El sesgo no se suprime. Se corta estructuralmente. No existe ninguna ruta de "Candidato" a "Género" a "Rol" porque el nodo Género no existe en el grafo que el algoritmo puede ver.

Compara esto con un modelo de aprendizaje profundo, que ingiere todo el texto sin procesar. Aunque elimines el campo "Género", el modelo lee "Club de Ajedrez Femenino" e infiere el género. En nuestro sistema, el LLM que analiza el currículum asigna "Club de Ajedrez Femenino" a un nodo neutralizado: (:Activity {type: "Strategy Club", role: "Leadership"}). El modificador de género se elimina antes de que entre en el motor de razonamiento.

Recuerdo la discusión del equipo sobre esto. Uno de mis ingenieros se opuso con fuerza — pensaba que estábamos perdiendo una señal valiosa al eliminar el contexto. "¿Y si el Club de Ajedrez Femenino es en realidad más competitivo que el regular?" Un buen argumento. Pero no estábamos optimizando la máxima extracción de información. Estábamos optimizando la equidad bajo escrutinio legal. Y prefiero pasar por alto una señal marginal antes que construir un sistema que aprenda a penalizar a la mitad de la población.

¿Cómo se mide realmente el talento sin sesgos?

No predecimos quién tendrá éxito. Medimos la distancia de habilidades — la brecha geométrica entre lo que un candidato tiene y lo que un puesto requiere. Esto traslada la contratación de la probabilidad subjetiva a la medición objetiva.

Los sistemas tradicionales de seguimiento de candidatos usan lógica booleana: ¿contiene el currículum la palabra clave "Java"? Sí o no. Esto es frágil y estúpido. Se le escapa cualquiera que use una terminología distinta para la misma competencia.

Usamos incrustaciones de grafos — algoritmos como Node2Vec que aprenden una representación vectorial para cada habilidad de nuestra ontología. Las habilidades que coinciden con frecuencia en el grafo (como "Python" y "Pandas") acaban juntas en el espacio vectorial. Las habilidades que no están relacionadas (como "Python" y "Flebotomía") acaban muy separadas.

Para puntuar a un candidato, calculamos la similitud del coseno entre el conjunto de vectores de habilidades del candidato y el conjunto de vectores de requisitos del puesto. Esto nos da crédito parcial. Un candidato que carece de "Tableau" pero tiene "Power BI" obtiene una puntuación de similitud alta porque esos nodos son vecinos semánticos en el clúster de "Inteligencia de Negocio". Una búsqueda por palabra clave le daría un cero.

Superponemos la similitud de Jaccard para la superposición bruta de habilidades y la distancia geodésica — cálculos de la ruta más corta a través del grafo — para el análisis de brechas. Si un puesto requiere Kubernetes y un candidato tiene Docker, el grafo encuentra la ruta: Docker → Contenerización → Orquestación → Kubernetes. Distancia: 3 saltos. Interpretación: capacitable. Si la distancia es de 6 saltos o más, es una brecha difícil.

La puntuación final de distancia de habilidades es una métrica puramente basada en competencias, completamente ciega a la demografía. No adivinamos quién es bueno. Medimos cuán cerca están.

Para el desglose técnico completo de estos algoritmos — incluyendo la matemática detrás de la similitud del coseno y nuestro modelo de puntuación compuesto — consulta nuestro artículo de investigación.

El momento del "SQL ausente"

Déjame concretar esto con algo que ocurrió durante las pruebas.

Pasamos el perfil de un candidato tanto por un reclutador estándar de caja negra como por nuestro sistema. La caja negra rechazó al candidato. Sin dar ninguna razón. (Más tarde determinamos que el candidato había asistido a una universidad pequeña y poco conocida — una clásica penalización por pedigrí.)

Nuestro sistema devolvió esto: "El candidato carece de experiencia explícita en SQL. Sin embargo, el análisis del grafo muestra amplia experiencia con Pandas DataFrames y R dplyr. La distancia en el grafo entre DataFrames y SQL es corta (concepto compartido: Manipulación de Datos). Recomendación: Entrevistar. Alta transferibilidad."

Ese candidato — al que la caja negra descartó — tenía todas las habilidades que el puesto necesitaba. Solo que usaba palabras distintas para describirlas. Y había ido a una escuela de la que la caja negra no había visto lo suficiente en sus datos de entrenamiento como para considerarla "exitosa".

Esto es lo que quiero decir cuando afirmo que los grafos de conocimiento amplían la reserva de talento. Encuentran personas que tienen las competencias pero no el pedigrí ni el vocabulario exacto. Y eso mejora naturalmente la diversidad — no mediante cuotas ni ajustes, sino mediante una mejor medición.

¿Qué ocurre cuando el sistema detecta un problema?

La gente me pregunta: "¿Y si tu sistema sigue produciendo resultados sesgados?" Es una pregunta justa, y desconfiaría de cualquiera que afirmara que su sistema es perfecto.

Esta es la diferencia: cuando una caja negra produce resultados sesgados, estás atascado. Puedes ver el impacto dispar en los números, pero no puedes ver por qué. ¿Son los nombres de las universidades? ¿Los códigos postales? ¿El estilo de redacción? Estás depurando un sistema con millones de parámetros y una lógica ilegible.

Cuando nuestro sistema produce una anomalía estadística — digamos, una ratio de impacto por debajo de 0,8 para un grupo demográfico concreto — podemos rastrearla. Podemos identificar los nodos específicos del grafo que causan la disparidad. Quizás una descripción de puesto exige una certificación cara y particular que se correlaciona con el estatus socioeconómico. Podemos verlo, señalarlo, y el equipo de contratación puede decidir si esa certificación es realmente necesaria o solo un requisito heredado que nadie cuestionó.

La caja de cristal no significa que el sistema tenga siempre razón. Significa que, cuando se equivoca, puedes averiguar por qué y corregirlo.

El LLM sigue teniendo un trabajo — solo que no el importante

Debo ser claro: sí usamos LLM. No somos luditas. Pero los usamos de la forma en que usarías a un traductor — para leer y escribir, no para juzgar.

Nuestra arquitectura impone una estricta separación de responsabilidades. El LLM se encarga de la percepción: lee el texto no estructurado del currículum y extrae entidades. "Coordiné un equipo de 5 desarrolladores para construir una aplicación de React Native" se convierte en datos estructurados — Habilidad: React Native, Habilidad: Liderazgo de Equipos, Contexto: Desarrollo Móvil. El LLM normaliza los sinónimos: "ReactJS" y "React.js" se asignan ambos al mismo nodo.

Pero el LLM nunca toma una decisión de contratación. Todo el emparejamiento, la puntuación y la clasificación ocurren a través de un recorrido determinista del grafo. El mismo grafo más la misma consulta equivale al mismo resultado, siempre. También usamos el LLM en el extremo de salida — genera explicaciones legibles para humanos, pero solo a partir de hechos verificados por el grafo. No puede alucinar una coincidencia de habilidades que el grafo no respalde.

Lo concibo como que el LLM son los ojos y la boca del sistema, mientras que el grafo de conocimiento es el cerebro. No dejarías que tu boca tomara decisiones por ti. (Bueno, la mayoría de nosotros no lo haríamos.)

¿Entre qué estamos realmente eligiendo?

Tal como yo lo veo, la industria está en una encrucijada. Un camino conduce a modelos más grandes, más parámetros, más opacidad — y a un juego interminable de whack-a-mole con el sesgo que sigue encontrando nuevas variables proxy que explotar. El otro camino conduce al razonamiento estructurado, la medición semántica y sistemas que pueden explicarse a un regulador, a un reclutador o a un candidato rechazado.

He hablado con líderes de RR. HH. de empresas que todavía usan herramientas de cribado de caja negra. Conocen el riesgo. Han leído sobre Amazon. Pero cambiar de arquitectura les parece caro e incierto, así que siguen parcheando. Añaden "capas de mitigación de sesgos" sobre sistemas fundamentalmente sesgados. Contratan consultores para realizar auditorías anuales que les dicen qué está roto sin darles las herramientas para arreglarlo.

Los datos son un espejo. Si entrenas un modelo con el pasado, replicas el pasado. En un mundo que aspira a la equidad, replicar el pasado es una condición de fracaso.

No voy a terminar esto con una salvedad. He pasado años construyendo esto, he visto fracasar espectacularmente la alternativa, y estoy seguro de la conclusión: el futuro de la IA de contratación no consiste en predecir quién tendrá éxito basándose en quién lo tuvo antes. Consiste en medir la distancia real entre lo que alguien puede hacer y lo que un puesto requiere — y hacer que esa medición sea transparente, determinista y estructuralmente incapaz de discriminar.

Puedes seguir prediciendo el pasado. O puedes empezar a medir el futuro.