Cómo escribir la descripción de puesto para un cargo de IA

El error de copiar una descripción de puesto de internet

Cada vez que una empresa necesita cubrir un cargo relacionado con IA, alguien en RRHH hace lo mismo: busca un ejemplo de “job description para especialista en IA” en internet, o le pide a un chatbot que redacte una versión “profesional”. El resultado casi siempre es el mismo documento genérico: una lista de tecnologías con nombres en inglés (LangChain, RAG, prompt engineering, automatización con n8n o Make), copiada de un ejemplo que ni el gerente que aprobó la vacante podría explicar por qué está ahí.

El problema no es que esas tecnologías sean irrelevantes. El problema es que la descripción de puesto las convierte en el filtro principal, y ese filtro atrae al perfil equivocado. Un candidato que lee esa JD entiende, correctamente, que lo que se valora es dominar herramientas, y responde con un CV lleno de certificaciones, cursos y proyectos donde “implementó IA” sin que se explique en ningún lado qué problema de negocio resolvió con eso.

El síntoma aparece en la primera ronda de entrevistas: llegan veinte o treinta candidatos que hablan con fluidez de agentes, modelos y frameworks, y al preguntarles “¿qué proceso cambiaste con esto, y con qué número lo mediste?”, la respuesta se vuelve vaga. Esto no es un problema de reclutamiento, es un problema de redacción, y se resuelve antes de publicar la vacante, no filtrando CVs después: si la JD nunca nombra el dolor de negocio ni el proceso a rediseñar, no hay forma de esperar que los candidatos entiendan que eso es lo que se les va a evaluar.

Qué es (y qué no) una descripción de puesto de IA bien escrita

Antes de entrar al cómo, vale la pena fijar qué es exactamente lo que se está redactando, porque la mayoría de los errores de esta guía nacen de confundir una descripción de puesto con un anuncio de tecnologías.

• No es una lista de tecnologías con las que el candidato debe tener experiencia previa, ordenadas según la moda del momento en LinkedIn.
• No es una copia de otra JD (de otra empresa, de un ejemplo genérico o de la respuesta de un chatbot) con el nombre del puesto y del área cambiados.
• No es un documento que redacta sistemas o tecnología en solitario, sin que el área de negocio afectada participe en definir cuál es el dolor real que se va a resolver.
• No es una lista de certificaciones de cursos de IA generativa o insignias de plataformas usada como filtro principal de entrada.
• No es un molde único que sirve igual para cualquier empresa: una JD de IA bien escrita cambia según el proceso específico que esa empresa necesita rediseñar.

Cada uno de estos errores tiene la misma raíz: se escribe la vacante pensando en la tecnología que se quiere usar, no en el resultado de negocio que se necesita. Invertir ese orden es el resto de esta guía.

Empieza por el problema de negocio, no por el título del cargo

El primer párrafo de una descripción de puesto es el que más trabajo hace y el que casi todos escriben peor. Ahí es donde se decide, antes de cualquier lista de responsabilidades o requisitos, qué tipo de candidato se va a sentir convocado a postular.

Qué debe contener el primer párrafo

• Nombra el dolor concreto: qué proceso no está funcionando hoy y qué le está costando a la empresa en tiempo, dinero o clientes, en vez de abrir con “buscamos un especialista en Inteligencia Artificial”.
• Dice qué proceso se va a rediseñar, con nombre propio: atención al cliente, cobranza, generación de contenido, gestión de inventario, lo que corresponda, nunca en abstracto.
• Aclara a quién le reporta esta persona y con quién va a trabajar, para que el candidato entienda desde la primera línea si el rol tiene mandato real sobre un proceso o es un puesto decorativo sin autoridad para cambiar nada.
• Usa la palabra “IA” como medio, no como fin: la tecnología es el cómo, el proceso rediseñado y el resultado de negocio son el qué.

El contraste entre un mal inicio y uno bueno

Un mal inicio dice: “Buscamos un especialista en Inteligencia Artificial con experiencia en LangChain, prompt engineering y automatización de procesos, para unirse a nuestro equipo de innovación”. Un buen inicio dice: “Nuestro proceso de atención por WhatsApp pierde leads por demora en la respuesta. Buscamos a alguien que rediseñe ese proceso, con o sin IA de por medio, y sea responsable de reducir ese tiempo de forma medible”. La diferencia no es de estilo, es de qué candidato atrae cada uno.

Escribe responsabilidades por resultado, no por herramienta

La sección de responsabilidades es donde más rápido se cuela el error de listar herramientas. Es tentador escribir “diseñar flujos de automatización en n8n” porque suena concreto y verificable. El problema es que describe un método, no un resultado, y un método nombrado con esa precisión ya le está diciendo al candidato exactamente qué inventar en su CV para calzar.

El contraste entre una responsabilidad y una herramienta

• Mal: “Diseñar y mantener flujos de automatización en n8n o Make”. Bien: “Reducir el tiempo de respuesta al cliente identificando en qué parte del proceso se pierden los leads y qué cambio, con o sin automatización, lo resuelve”.
• Mal: “Implementar soluciones de IA generativa para el equipo de marketing”. Bien: “Aumentar la producción de contenido del equipo de marketing sin sacrificar la revisión de calidad, midiendo el tiempo por pieza antes y después”.
• Mal: “Administrar agentes conversacionales y prompts”. Bien: “Ser responsable de que el canal de atención automatizada resuelva las consultas frecuentes sin perder el tono de la marca, con seguimiento semanal de satisfacción”.
• Mal: “Dar soporte técnico a integraciones de APIs de modelos de lenguaje”. Bien: “Sostener en producción cualquier sistema que se implemente, y ser el punto de escalamiento cuando algo falle, sin depender de un proveedor externo para resolverlo”.

Escribir así obliga a quien redacta la vacante a tener claro, antes de publicarla, cuál es el resultado esperado. Si esa claridad no existe todavía, ese es el primer problema por resolver, antes de seguir escribiendo la JD.

Qué es un requisito real y qué es un “nice to have” de moda

No todos los requisitos de una JD pesan igual, y el error común es tratarlos como si pesaran lo mismo: una certificación de una plataforma de IA termina al mismo nivel que la capacidad de leer un proceso de negocio y encontrar dónde se pierde el dinero. Es un error de jerarquía, no solo de redacción.

Requisitos que sí deberían filtrar

• Evidencia de resultados de negocio previos: qué proceso resolvió y qué número movió, sin importar si esa evidencia viene de un rol formal de IA o de operaciones, ventas o finanzas.
• Capacidad de diagnóstico: demostró antes que sabe hacer las preguntas correctas antes de proponer una solución, en vez de llegar con la respuesta ya decidida.
• Criterio para priorizar por dolor y por retorno, no por lo técnicamente interesante de construir.

Lo que va después, y relativizado

• Experiencia con una herramienta o framework específico (LangChain, n8n, una plataforma de agentes en particular): es aprendible en semanas por alguien con criterio, y casi nunca vale la pena descartar a un buen candidato solo por no haberla usado antes.
• Certificaciones y cursos de IA generativa: indican interés y disciplina de aprendizaje, no capacidad demostrada de resolver un problema real.
• Años de experiencia en “IA” como categoría: es una métrica casi vacía en un campo que cambia cada pocos meses; importa más qué hizo en ese tiempo que cuánto tiempo lleva.

Cuando estos dos grupos se invierten (herramientas primero, criterio de negocio después o ausente), la descripción de puesto termina filtrando exactamente al revés de lo que la empresa necesita.

El perfil de competencias: lidera con criterio de negocio, no con jerga técnica

Un buen perfil para un cargo de IA se parece más a un gerente de operaciones que a un ingeniero. Traduce entre dirección y equipo técnico, prioriza por dolor y por retorno, y sabe decir que no a un proyecto técnicamente atractivo que no resuelve nada relevante para el negocio. Esa es la persona que la descripción de puesto debería estar buscando, y el orden en que se presentan las competencias en la JD comunica, sin decirlo de forma explícita, cuál es esa prioridad real.

Hay una señal a tener presente: hablar todo el tiempo en jerga técnica (agentes, modelos, frameworks) sin aterrizarlo en impacto de negocio no es señal fuerte de competencia, es señal débil. El perfil que colecciona herramientas y cobra por conectarlas, sin preguntar qué proceso resuelve, es justo el que una JD bien escrita debe dejar afuera desde el primer párrafo, no descubrir en la tercera entrevista.

Este Playbook desarrolla esta transición de perfil en /recursos/roadmap-ia-de-automatizador-a-gerente-ia y en /contenido/de-automatizador-a-gerente-ia. Vale la pena revisarlos cuando el reto no es solo redactar la vacante, sino decidir qué perfil formar o promover dentro de la empresa.

• Capacidad de análisis de procesos: toma un proceso desordenado y describe, en lenguaje simple, dónde se pierde tiempo o dinero, antes de proponer una solución.
• Gestión y priorización: no trata todos los proyectos igual, distingue el que mueve una métrica real del que solo es interesante de construir.
• Traducción entre negocio y técnica: le explica a dirección, sin jerga, qué se va a hacer y por qué, y al equipo técnico, con precisión, qué necesita el negocio.
• Criterio para decir que no: rechaza pedidos técnicamente posibles pero sin retorno claro, en vez de ejecutar cualquier cosa solo por mantenerse ocupado.

Cómo se ve esto en la práctica

Una cadena de clínicas dentales de tamaño mediano, alrededor de quince sedes, en Perú, publicó una vacante para “especialista en Inteligencia Artificial” con una descripción típica: dominio de herramientas de automatización, experiencia con chatbots, conocimientos de prompt engineering, deseable certificación en alguna plataforma de agentes. En cuatro semanas recibieron más de sesenta postulaciones.

El proceso de entrevistas mostró un patrón incómodo: casi todos hablaban con fluidez de herramientas y mostraban proyectos personales de automatización, pero al preguntarles cuál era el proceso que más perdía pacientes hoy (el agendamiento de citas, con alto ausentismo y reprogramaciones manuales por WhatsApp) ninguno tenía una hipótesis propia, y la mayoría proponía instalar “un chatbot con IA” sin haber preguntado antes por qué la gente no llegaba.

La empresa pausó el proceso y reescribió la vacante. El nuevo primer párrafo nombraba el problema explícitamente: el ausentismo y la carga manual de reprogramación del equipo de recepción. Las responsabilidades se redactaron por resultado (“reducir el ausentismo y el tiempo de reprogramación”), no por herramienta, y los requisitos técnicos bajaron de posición: primero pedían experiencia analizando procesos y comunicando resultados a dirección, y solo después mencionaban IA, como medio y no como fin.

El tipo de candidato cambió por completo. Llegaron menos postulaciones, pero con perfiles de operaciones que preguntaban, antes de la primera entrevista, por datos de ausentismo y por el flujo de recordatorios actual. La persona contratada venía de mejora de procesos en otro rubro de servicios, sin certificaciones de IA en su CV, y en pocos meses rediseñó el flujo de recordatorios y confirmación de citas con automatización simple, con una reducción sostenida del ausentismo que ningún “especialista en prompt engineering” de la primera tanda había siquiera diagnosticado como el problema real.

Mi criterio

Cómo saber si escribiste bien la descripción de puesto

No hace falta esperar a la primera tanda de CVs para saber si la descripción de puesto está bien escrita. Se puede verificar antes de publicarla, releyéndola con esta lista.

• El primer párrafo nombra un dolor de negocio y un proceso concreto, no abre con el título del cargo ni con la palabra “Inteligencia Artificial” como si fuera el trabajo en sí.
• Cada responsabilidad está escrita como un resultado verificable, no como el nombre de una herramienta o un framework.
• Los requisitos que de verdad filtran (capacidad de análisis, evidencia de resultados de negocio, criterio de priorización) aparecen antes que las herramientas o certificaciones específicas.
• Alguien del área de negocio afectada, no solo sistemas o RRHH, revisó y aprobó la vacante antes de publicarla.
• Puedes imaginar, leyendo la JD en voz alta, que la persona que responda a ese anuncio va a preguntar primero por el proceso y los datos, no por qué plataforma van a usar.

Si al releer la vacante no puedes marcar las cinco, todavía estás a tiempo de reescribirla antes de publicarla, y ese tiempo se recupera muchas veces durante el proceso de selección, cuando el CV que llega ya viene alineado con lo que de verdad importa.