Una consultora tech argentina con unos 30 empleados recibía alrededor de 400 CVs por semana para búsquedas abiertas. El equipo de HR (3 personas) pasaba cerca de 15 horas semanales haciendo screening inicial: descartando los que estaban claramente fuera de perfil y armando shortlists para los manager técnicos. Era trabajo agotador, repetitivo y generaba errores por fatiga: al final del día los últimos CVs recibían menos atención que los primeros.
Nos contactaron para ver si se podía automatizar parte del proceso. Lo que implementamos reemplaza aproximadamente el 70% del trabajo manual, con cero falsos descartes de candidatos fuertes verificados en retrospectiva. Este post explica cómo.
Por qué "filtrar CVs con IA" casi siempre suena peor de lo que es
Cuando decís "usar IA para filtrar CVs" mucha gente se pone nerviosa, y con razón. Los sistemas de reclutamiento automáticos tienen historial de amplificar sesgos, descartar candidatos válidos por frases mal interpretadas, y tomar decisiones opacas que nadie puede auditar. Amazon tuvo que abandonar un sistema interno de screening por exactamente estos problemas hace varios años.
El error en esos casos fue delegar la decisión. El sistema decidía a quién descartar y ese descarte era final. Nadie revisaba, nadie apelaba.
Lo que hicimos nosotros es distinto en un punto esencial: el sistema no descarta a nadie. Ordena. Sugiere. Genera un resumen. Pero el humano sigue decidiendo, con mucho menos tiempo y mejor información. Esa distinción es lo que separa un proyecto viable de un riesgo legal.
El contexto del cliente
La consultora trabaja con equipos técnicos: desarrolladores, data engineers, product managers, diseñadores de producto. Las búsquedas tienen entre 3 y 8 criterios objetivos (stack específico, seniority, idioma, modalidad) y varios criterios subjetivos (fit cultural, comunicación, motivación).
Los CVs llegaban por tres canales: formulario web propio, LinkedIn Easy Apply, y referidos por mail. Todos terminaban en un ATS propio (un software de reclutamiento custom que ya tenían).
La arquitectura
El flujo end-to-end terminó siendo relativamente simple:
1. Ingesta. Un webhook del ATS se dispara cada vez que llega un CV nuevo. n8n recibe el payload con el PDF adjunto y metadata básica (búsqueda asociada, canal de origen, fecha).
2. Parsing. El PDF se convierte a texto estructurado. Para CVs de buen formato usamos pdfplumber; para CVs escaneados o con diagramación rara los pasamos por Azure Document Intelligence, que los convierte razonablemente bien. El texto resultante se normaliza: saltos de línea, secciones, bullets.
3. Extracción estructurada. Un primer llamado a GPT-4o-mini con structured output. La instrucción es "extraé de este CV los siguientes campos en JSON: nombre, años de experiencia estimados, stack técnico mencionado, roles pasados, educación, idiomas, ubicación declarada, modalidad preferida si se menciona". Los outputs van a un schema Zod que valida y rechaza lo que viene mal.
4. Scoring contra la búsqueda. Un segundo llamado al LLM con tres inputs: el CV estructurado del paso anterior, el job description de la búsqueda (también estructurado), y una rúbrica específica. La rúbrica incluye los criterios de la búsqueda con pesos y una escala 0-5 por criterio. El output es un objeto con scores por criterio, score total, y un texto corto explicando la fundamentación.
5. Revisión humana. Los resultados llegan al ATS como un enriquecimiento del CV original. HR ve el CV, el score, el razonamiento del sistema, y decide si avanzar, descartar o pedir revisión manual. El sistema nunca borra ni auto-descarta.
6. Feedback loop. Cada decisión humana (avanzar, descartar, "este estuvo bien sugerido", "este estuvo mal sugerido") se loggea. Semanalmente revisamos el delta entre sugerencias del sistema y decisiones reales para ajustar la rúbrica.
El sistema de scoring
Esto fue lo más delicado del proyecto. Un sistema de scoring mal diseñado amplifica sesgos; uno bien diseñado los reduce. Las decisiones clave:
Puntuación por criterio explícito, no por "feeling". La rúbrica obliga al modelo a dar un número separado para cada criterio del job description. No puede "impresionarse positivamente" en general; tiene que decir "3/5 en stack Python, 4/5 en experiencia backend, 2/5 en inglés autodeclarado". Esto hace auditable cada decisión.
Nada de señales demográficas. El prompt explícitamente instruye al modelo a ignorar nombre, foto, año de nacimiento, universidad concreta (solo tipo de grado), y cualquier información demográfica. Antes de pasarle el CV al scorer, un paso intermedio redacta esos campos si aparecen explícitos. No es perfecto pero reduce vectores de sesgo conocidos.
Criterios con pesos explícitos por búsqueda. Cada búsqueda tiene su propia rúbrica con pesos. Para un puesto senior, "años de experiencia" puede pesar 30%; para uno junior, "demostración de aprendizaje reciente" puede pesar lo mismo. No hay una rúbrica universal.
Threshold de incertidumbre. Si el score total queda en una zona gris (entre 2.5 y 3.5 sobre 5), el sistema no ordena: marca como "revisar manualmente" y lo pone arriba de la cola. Esto fuerza a que los casos dudosos siempre los decida un humano.
El paso que casi nadie hace: calibración
Este fue el momento que decidió el éxito del proyecto. Antes de activar el sistema en producción, tomamos 200 CVs que HR ya había procesado manualmente. Los corrimos por el sistema sin que HR viera las respuestas, guardamos los scores, y después comparamos contra las decisiones humanas reales.
Los resultados de la primera corrida:
- 68% de correspondencia perfecta entre "score alto" del sistema y "avanzado" por humano.
- 12% de correspondencia parcial (el sistema dio score medio y el humano avanzó, o viceversa).
- 20% de desacuerdo claro.
Ese 20% fue lo más valioso. Revisamos cada uno de los desacuerdos con el equipo de HR. En algunos casos el sistema tenía razón (encontró detalles que el humano pasó por alto por fatiga). En la mayoría, el sistema estaba mal calibrado: valoraba demasiado la presencia literal de keywords del stack, no entendía contextos locales (ej. "trabajé con Tango Gestión" es un dato relevante para algunos puestos y el modelo no lo sabía), y no ponderaba bien la progresión de carrera.
Ajustamos el prompt, incorporamos ejemplos del desacuerdo como few-shot, y volvimos a correr los 200. Segunda iteración: 84% de correspondencia perfecta, 10% parcial, 6% desacuerdo. Tercera iteración: 89% de correspondencia perfecta. En ese punto el equipo de HR decidió que estaba listo para producción supervisada.
Sin esta etapa de calibración, el sistema hubiera parecido "funcionar" pero hubiera amplificado sesgos invisibles durante meses.
Resultados a los dos meses
Con el sistema corriendo en producción durante dos meses completos:
- Tiempo humano semanal en screening: bajó de ~15 horas a ~4 horas. Las 11 horas recuperadas se reasignaron a entrevistas de calidad con candidatos fuertes.
- Tiempo promedio desde aplicación hasta primera respuesta: bajó de 6 días a menos de 24 horas.
- Candidatos en shortlist por búsqueda: aumentó ligeramente, no por cantidad sino porque el equipo podía evaluar bien más casos en el mismo tiempo.
- Quejas de candidatos sobre falta de respuesta: bajaron a casi cero (hicimos además un auto-email de rechazo cordial para los descartes, manejado por los mismos humanos).
- Tasa de contratación exitosa (candidato contratado que pasa período de prueba): sin cambio estadísticamente significativo. Era lo más importante: el sistema no empeoró la calidad de las decisiones.
Los riesgos que mitigamos
Automatizar screening tiene riesgos reales. Los tres principales y cómo los manejamos:
Sesgo algorítmico. Redacción de datos demográficos antes del scoring, rúbrica explícita por criterio, revisión mensual del delta de sugerencias por categoría demográfica cuando hay dato disponible. Ningún sistema automatizado es 100% insesgado, pero un sistema con auditoría activa es mucho mejor que 3 humanos cansados a las 7 de la tarde.
Opacidad. Cada decisión del sistema guarda su razonamiento. HR puede ver por qué un CV recibió cierto score. Si un candidato pide feedback sobre su aplicación (derecho que muchas empresas respetan), podemos generar una respuesta concreta.
Falsos negativos de alto impacto. El threshold de incertidumbre evita que casos dudosos se descarten. Los descartes solo ocurren cuando el humano lo decide y el humano siempre ve el CV completo, no solo el score.
Lo que NO delegamos a la máquina
Algunas decisiones siguen y seguirán siendo manuales:
- Evaluación de fit cultural: el sistema no toca esto. Lo hacen los managers en entrevistas.
- Decisión final de contratación: siempre humana, después de múltiples entrevistas.
- Manejo de referrals: los referidos pasan al sistema para scoring pero nunca son "descartables". Se evalúan con bias positivo a favor.
- Búsquedas sensibles (posiciones de liderazgo, altos salarios): se procesan con el sistema pero HR revisa cada CV individualmente igual.
Recomendaciones si estás pensando en algo similar
No vendas el proyecto como "IA reemplaza HR". Es el peor framing posible, interna y externamente. El framing correcto es "IA libera a HR del trabajo tedioso para hacer mejor el trabajo importante", que además es literalmente lo que pasa.
Calibrá contra casos reales ya decididos. Si no tenés un dataset de 100+ decisiones humanas previas, no tenés con qué medir calidad y el sistema es una caja negra.
El humano decide siempre. No solo por razones legales. Por razones prácticas: el sistema va a equivocarse en casos que ningún humano se hubiera equivocado, y si no hay un humano mirando, te enterás tarde.
Transparencia interna. El equipo de HR tiene que entender qué hace el sistema, por qué, y cómo intervenir cuando algo se ve mal. Si es una caja negra para ellos, se lo van a resistir o lo van a usar mal.
El proyecto en total fueron cuatro semanas de trabajo (dos de ingeniería, dos de calibración) más una semana de onboarding con el equipo. El cliente reporta que no volverían atrás, y que lo más valioso no fueron las 11 horas semanales sino el tiempo de respuesta a candidatos, que mejoró su marca empleadora de manera tangible.