Cómo usar la IA para encontrar trabajo

Cómo usar la IA para encontrar trabajo consiste en dejar que un workflow haga la parte repetitiva de la búsqueda: encontrar vacantes reales, identificar a la persona que de verdad contrata y redactar un primer mensaje concreto, mientras la decisión de enviarlo sigue siendo tuya. El workflow AI Job Hunter, construido para el taller de 4Geeks, hace exactamente eso en 13 nodos de n8n: entra un formulario de candidato y sale un borrador en Gmail. Esta es la versión que funciona a septiembre de 2026, nodo por nodo, con los errores que la rompieron la primera vez.

Esto no es un ranking de "herramientas de IA para buscar empleo". Pedirle a ChatGPT que reescriba una carta de presentación no resuelve los dos pasos que mueven una candidatura: una vacante viva y una persona con nombre. El workflow de abajo es una tubería de datos con un punto de control humano.

¿Qué significa usar la IA para encontrar trabajo?

La mayoría de las candidaturas mueren en los mismos dos sitios. El candidato pasa horas en portales leyendo ofertas caducadas o que no encajan, y las pocas que envía acaban en un formulario que nadie lee. Un mensaje que llega por su nombre a un reclutador o a la persona que lidera el equipo, y que menciona algo real del puesto, recibe otro tipo de atención. Encontrar a esa persona y escribir ese mensaje lleva unos veinte minutos por vacante, y casi nadie lo hace.

Usar IA aquí significa atacar esos dos cuellos de botella, no disparar candidaturas. El workflow saca las vacantes de Google for Jobs a través de una API, así que las ofertas son reales y están vivas. Le pide a Apollo el reclutador, la persona de talent acquisition o el hiring manager de esa empresa y revela un correo de trabajo verificado. Después le entrega a Claude la vacante, el contacto y el perfil del candidato con reglas estrictas, y recibe un mensaje de 80 a 120 palabras que cita la descripción del puesto y la conecta con un logro concreto.

Lo que no hace, a propósito, es enviar nada. Ahí se equivoca mucha gente cuando piensa en "la IA que aplica a ofertas por ti". El valor no está en que un modelo escriba por ti. Está en una tubería de datos reales con un punto de control humano al final. Para la parte manual de la búsqueda (portfolio, red de contactos y entrevistas) los tips para encontrar trabajo siguen siendo el punto de partida.

¿Qué hace el workflow AI Job Hunter, nodo por nodo?

El workflow corre en n8n, gratis o autoalojado. Cada fila es un nodo real con la configuración que acabó funcionando.

Cuentas necesarias: n8n, RapidAPI con la API JSearch de OpenWeb Ninja (se recomienda plan de pago), Apollo.io con master API key (plan de pago), la API de Anthropic (pago por uso), Google Sheets y Gmail por OAuth, y un espacio de Slack para las alertas.

¿Cómo se recoge el perfil del candidato? (nodos 1 y 2)

El formulario pide seis cosas: nombre, rol objetivo, país como código ISO (co, mx, ar, cl, es), habilidades clave separadas por comas, años de experiencia y un logro concreto. Ese último campo importa más de lo que parece. Sin un logro específico, el modelo no tiene nada real que conectar con la vacante y el mensaje se va hacia el elogio genérico.

El nodo 2 es un Set que renombra las etiquetas largas del formulario a variables cortas: candidate_name, target_role, country_code, skills, years_experience y achievement. El fallo más común de todo el workflow vive aquí. El texto de cada campo en el nodo 2 tiene que coincidir exactamente con la etiqueta del formulario, acentos incluidos. Un solo desajuste produce un "undefined" tres o cuatro nodos más adelante, donde cuesta mucho más rastrearlo.

¿Cómo encuentra el workflow vacantes reales? (nodos 3 y 4)

El nodo 3 es un HTTP Request a JSearch:

GET https://jsearch.p.rapidapi.com/search-v2
query = $json.target_role
country = $json.country_code
language = es
num_pages = 1

Dos detalles costaron tiempo real en la construcción original. La versión de la URL importa, porque la v1 está deprecada para muchas cuentas de RapidAPI y devuelve errores que parecen de autenticación. Y la autenticación tiene que ser Custom Auth de n8n, no Header Auth, porque JSearch necesita dos cabeceras (X-RapidAPI-Key y X-RapidAPI-Host) y Header Auth solo admite una.

El nodo 4 es un Code. Los resultados reales vienen anidados en data.jobs, no en data, y se descartan las vacantes sin web de empresa porque Apollo necesita el dominio en el paso siguiente:

const jobs = ($input.first().json.data && $input.first().json.data.jobs) || [];
const profile = $('Build Candidate Profile').first().json;
 
return jobs
  .filter(j => j.employer_name && j.job_apply_link && j.employer_website)
  .slice(0, 5)
  .map(j => ({ json: {
    job_title: j.job_title,
    company: j.employer_name,
    company_domain: j.employer_website || '',
    job_description: (j.job_description || '').slice(0, 800),
    job_apply_link: j.job_apply_link,
    candidate_name: profile.candidate_name,
    target_role: profile.target_role,
    skills: profile.skills,
    years_experience: profile.years_experience,
    achievement: profile.achievement
  }}));

La descripción se corta a 800 caracteres a propósito. Es suficiente para que el modelo encuentre algo específico y mantiene el prompt corto y barato.

¿Cómo se localiza a la persona que contrata? (nodos 5 a 7)

El nodo 5 llama a la búsqueda de personas de Apollo. El endpoint antiguo, /mixed_people/search, está deprecado; el que funciona es POST https://api.apollo.io/api/v1/mixed_people/api_search. El body pide personas con los cargos Recruiter, Talent Acquisition o Hiring Manager en el dominio de la empresa, cinco por página.

El dominio tiene que ir limpio. Si llega como https://www.empresa.com, Apollo no protesta: ignora el filtro en silencio y devuelve gente de empresas que no tienen nada que ver. La construcción quita el protocolo y el www con un replace de una línea antes de enviarlo. El segundo fallo silencioso es el tipo de clave: con una API key normal Apollo también devuelve resultados genéricos en lugar de filtrar por dominio. Solo una master API key, generada en Settings, Integrations, API, filtra bien.

El nodo 6 es una segunda llamada, POST /api/v1/people/match, porque la búsqueda devuelve nombre, cargo y empresa pero no el correo. Revelar el correo consume un crédito de Apollo por contacto, y la petición pone reveal_personal_emails en false para que solo devuelva direcciones de trabajo.

El nodo 7 es un Code que combina por índice. El nombre y el cargo salen del nodo 5, el correo del nodo 6 y la vacante del nodo 4. Ningún nodo lo tiene todo, así que el código recorre los tres arrays en paralelo y construye un registro por vacante con contact_name, contact_title, contact_linkedin y contact_email.

¿Cómo consigue Claude que el mensaje no suene genérico? (nodo 8)

El nodo 8 hace un POST a https://api.anthropic.com/v1/messages con el modelo claude-sonnet-4-6 y max_tokens en 400. La calidad del resultado sale casi por completo del system prompt, que es una lista de restricciones y no un brief creativo:

Eres un asistente que ayuda a un candidato a contactar directamente a la
persona que probablemente esté a cargo de la contratación para una vacante
específica. Redacta un mensaje corto (80-120 palabras), natural y
específico, nunca genérico.
Reglas: 1) Menciona algo específico y real de la descripción del puesto.
2) Conecta ese requisito con un logro o habilidad concreta del candidato.
3) Tono seguro pero humilde, conversacional, sin clichés de LinkedIn.
4) Cierra con una pregunta abierta de bajo compromiso, nunca 'contrátame'.
5) Nunca inventes datos. 6) Español neutro latinoamericano.

La regla 5 es la que mantiene honesto el workflow: el modelo solo sabe lo que dicen el formulario y la vacante. La regla 4 cambia la tasa de respuesta más que cualquier truco de redacción, porque una pregunta de bajo compromiso se contesta más fácil que una petición. La regla 6 está fijada para el público del taller; cámbiala al idioma de tu mercado antes de ejecutarlo en otro sitio. El mensaje de usuario arma nombre, rol, vacante y contacto con los campos que produce el nodo 7.

¿Adónde va el resultado y por qué el correo nunca se envía solo? (nodos 9 a 13)

El nodo 9 une el mensaje redactado con el resto del registro y le pone una marca de tiempo generated_at. El nodo 10 añade una fila por ejecución a una hoja de Google Sheets con una pestaña llamada exactamente Workshop Results, con la operación appendOrUpdate y autoMapInputData para que las columnas casen por nombre y no por posición. Encabezados sugeridos: candidate_name, target_role, job_title, company, contact_name, contact_title, contact_email, drafted_message, generated_at.

El nodo 11 crea un borrador en Gmail con el asunto "Sobre la vacante de [puesto] en [empresa]" y el mensaje redactado como cuerpo. Nunca usa la operación de envío, y eso es una decisión de diseño, no un descuido. El mensaje va al correo real de una persona real. Enviarlo queda en manos de quien revisa el borrador, vuelve a leer la vacante y decide que el mensaje merece el tiempo de quien lo recibe.

Los nodos 12 y 13 están en una rama separada, sin conectar al flujo principal. El Error Trigger se dispara solo cuando cualquier nodo falla y publica en un canal de Slack el nombre del workflow, el último nodo ejecutado y el mensaje de error. Cuando JSearch cambia de versión o Apollo rechaza una clave, te enteras en Slack y no por una hoja de cálculo vacía.

Una regla más para demos en directo: no muestres el correo completo en pantalla. Nombre y cargo bastan para transmitir la idea sin exponer el dato personal de alguien que nunca aceptó que lo proyectaran delante de una sala.

¿Qué se rompe primero al reconstruirlo?

Estos son los fallos que aparecieron en la construcción original, en el orden en que probablemente te aparezcan a ti:

• Etiquetas del formulario que no coinciden exactamente con el nodo 2, que asoman como "undefined" mucho más adelante.
• JSearch v1 en lugar de search-v2, deprecada para muchas cuentas.
• Header Auth en n8n, que solo lleva una cabecera cuando JSearch necesita dos.
• Leer los resultados de data en lugar de data.jobs.
• El endpoint deprecado /mixed_people/search de Apollo.
• Un dominio enviado con https:// o www, que Apollo ignora sin error.
• Una clave normal de Apollo en vez de una master key, que devuelve empresas sin relación.
• Esperar el correo de la llamada de búsqueda, cuando solo llega en la llamada match.

Búsqueda manual o AI Job Hunter: ¿qué cambia de verdad?

El veredicto honesto: el workflow no te contrata, y quien prometa eso está vendiendo algo. Lo que hace es quitar las excusas para saltarse el paso que funciona, que es contactar a una persona real con un mensaje concreto. Para la parte humana de ese paso, hackea el reclutamiento es el complemento de este artículo.

¿Esto es ingeniería de IA de verdad?

Sí, y por eso se construye en un taller. Quita el envoltorio de búsqueda de empleo y te queda una tubería de datos: un disparador, dos APIs externas con sus manías, código determinista que limpia y combina, un modelo de lenguaje acotado por reglas explícitas, registro persistente, un punto de control humano y un canal de errores. Es la misma forma que tienen los agentes que las empresas están desplegando en 2026, y el tipo de trabajo que hace un ingeniero de inteligencia artificial.

Tu siguiente paso

Reconstruye los 13 nodos con tu propio perfil, ejecútalo para un rol y un país, y lee los cinco borradores antes de enviar ninguno. En el momento en que quieras añadir una segunda fuente de vacantes, puntuar candidaturas o enchufar otro modelo, ya estás haciendo ingeniería de IA. Un curso de inteligencia artificial aplicada enseña justo eso: conectar datos reales, APIs y modelos de lenguaje en sistemas que aguantan fuera de la demo.