Cómo entrevistar técnicamente a un candidato de IA si tú no eres técnico

El error que comete casi todo gerente al entrevistar IA sin ser técnico

La escena se repite en casi toda pyme que decide contratar su primer perfil de IA. El dueño o el gerente de Recursos Humanos se sienta frente a un candidato que, en los primeros cinco minutos, menciona “agentes”, “RAG”, “fine-tuning” y tres herramientas con nombre en inglés que nunca había escuchado. El entrevistador, que no domina ese vocabulario, siente que está frente a alguien que “sabe mucho”. Ahí empieza el error: confundir dominio de jerga con capacidad de resolver un problema real del negocio.

El mecanismo se agrava cuando el evaluador no tiene forma de verificar lo que escucha. La intimidación produce un sesgo silencioso: el gerente deja de preguntar por miedo a “quedar mal” o a no entender la respuesta, y termina asintiendo cuando debería estar pidiendo que le expliquen otra vez, más simple. Ese silencio es el que después se paga caro, porque nunca quedó registrado qué problema de negocio decía resolver el candidato.

Lo que ocurre después es previsible. Contratan a alguien que conecta herramientas con soltura, pero que nunca preguntó por qué el proceso fallaba antes de automatizarlo. A los tres meses no hay ningún número que haya cambiado: ni tiempo de respuesta, ni tasa de conversión, ni horas ahorradas. Solo hay una automatización suelta que nadie mide, porque en la entrevista nadie exigió que se hablara de resultados desde el día uno.

La buena noticia es que no necesitas volverte técnico para entrevistar bien. Necesitas otra habilidad, que ya es tuya por experiencia de negocio: preguntar por procesos y resultados, y exigir que cada respuesta técnica se traduzca a lenguaje que tú entiendas. Si el candidato no puede hacer esa traducción, el problema no es tuyo por no ser técnico. Es de él, por no entender realmente lo que hizo.

Qué es (y qué no) entrevistar a un candidato de IA sin ser técnico

Entrevistar sin ser técnico no es fingir que entiendes de modelos ni memorizar tres términos para no quedar expuesto. Es aplicar un criterio distinto, más cercano al que ya usas para evaluar a un gerente de operaciones o a un jefe de proyecto: pedir evidencia de procesos que mejoraron y de números que se movieron, y exigir que esa evidencia se explique en lenguaje de negocio, no de herramienta.

• No es memorizar términos técnicos para sonar creíble frente al candidato; si tú hablas en jerga prestada, pierdes la ventaja de detectar cuándo él también está fingiendo.
• No es pedir una prueba de código que tú no sabrás calificar; una prueba mal diseñada por alguien no técnico solo mide quién memorizó mejor la sintaxis, no quién resuelve procesos.
• No es usar certificaciones o cursos como filtro principal; un diplomado dice qué estudió, no qué problema de negocio resolvió con eso.
• No es delegar la decisión a la intuición (“me cayó bien”, “hablaba muy seguro”); la seguridad al hablar es la habilidad más fácil de entrenar y la más engañosa de evaluar sin método.
• No es evitar por completo el tema técnico y preguntar solo por soft skills; el objetivo es traducir lo técnico a negocio, no eliminarlo de la conversación.

El guion: las preguntas que exponen resultados, no vocabulario

Estas preguntas funcionan porque no se pueden responder solo con jerga. Obligan al candidato a describir un proceso real, una decisión y un número. Haz cada una despacio y no avances a la siguiente hasta que la respuesta te deje claro qué pasó antes, qué cambió y qué se movió.

“Cuéntame un proceso que rediseñaste y qué número cambió”

No preguntes “qué herramientas usas”. Pregunta por el proceso completo: cómo funcionaba antes, qué estaba mal, qué decidió cambiar y qué pasó después. Un candidato con criterio real describe el proceso en segundos, sin dudar, porque lo vivió. Uno que solo instaló una herramienta se queda en la parte técnica y no logra explicar el “antes” del negocio.

“Explícame ese proyecto como si yo fuera el dueño de la empresa”

Esta pregunta es la prueba de fuego. Le pides al candidato que repita la misma historia, pero sin ninguna palabra técnica. Si la explicación se vuelve más clara y más corta, es buena señal: entendió el problema de negocio detrás de la solución. Si se enreda, repite términos o te pide “dejarlo en técnico porque es más preciso”, es señal de que nunca tradujo su propio trabajo para nadie, ni siquiera para sí mismo.

“¿Qué NO automatizarías y por qué?”

Esta pregunta separa a quien piensa en procesos de quien piensa en herramientas. Un perfil con criterio te va a hablar de riesgo, de decisiones que necesitan supervisión humana, de procesos donde el costo del error es demasiado alto para dejarlo en manos de un modelo sin control. Quien solo sabe conectar herramientas responde que “se puede automatizar casi todo”, porque nunca se detuvo a evaluar el costo de un error.

“Cuéntame algo que salió mal”

Todo perfil con experiencia real tiene una historia de algo que falló. Lo que te interesa no es el error en sí, sino qué hizo después: cómo lo detectó, a quién avisó, qué cambió en el proceso para que no volviera a pasar. Un candidato que no tiene ninguna historia de fallo, o que la cuenta como culpa de otro, es una señal de alerta mayor que cualquier vacío técnico.

Cómo distinguir la duda honesta del humo

No toda incertidumbre es mala señal. Al contrario: un candidato que dice “no lo sé” y explica cómo lo averiguaría suele tener más criterio que uno que responde todo con seguridad absoluta. El problema no es la duda, es qué hace la persona con ella.

La duda honesta suena así: “no manejo ese caso específico, pero lo que haría es revisar el proceso actual con el equipo, entender dónde se pierde tiempo o dinero, y probar primero con la versión más simple antes de complicar la solución”. Es una respuesta que no tiene el dato exacto, pero sí tiene método.

El humo suena distinto: respuestas largas, llenas de nombres de herramientas y conceptos, que en realidad no dicen nada verificable. La forma más simple de detectarlo es pedir un ejemplo concreto después de cada afirmación general. “Mencionaste que optimizas procesos con IA, cuéntame el último proceso que optimizaste, con nombre y número”. Quien tiene el caso real lo cuenta de inmediato. Quien no lo tiene, cambia de tema o se va a otra generalidad.

Cómo detectar a quien se esconde detrás de la jerga

Hablar en técnico no es malo. Lo que es una señal débil es hablar en técnico sin poder explicar el impacto en el negocio. Un candidato que menciona “agentes”, “embeddings” o alguna herramienta de automatización y no puede decirte, en la misma frase, qué proceso de la empresa mejoró con eso, está mostrando exactamente el perfil que este tipo de entrevista debe filtrar: el que sabe instalar herramientas pero no entiende para qué sirven dentro de una operación real.

Este es el contraste que más conviene tener en mente: el “automatizador que cobra por conectar herramientas” contra el profesional que piensa como gerente de operaciones. El primero factura por integraciones y flujos, sin preguntarse si el proceso que está automatizando debería existir en esa forma. El segundo empieza preguntando por el dolor del negocio, prioriza por retorno, y a veces su mejor recomendación es no automatizar nada todavía.

Si te interesa entender ese recorrido completo, de alguien que solo conecta herramientas a alguien que gestiona resultados de negocio, hay dos recursos que profundizan justo en eso: /recursos/roadmap-ia-de-automatizador-a-gerente-ia y /contenido/de-automatizador-a-gerente-ia. Vale la pena revisarlos antes de escribir la descripción del puesto que vas a entrevistar.

Qué mirar primero: negocio y procesos, las herramientas van después

Un buen perfil de IA se parece más a un gerente de operaciones que a un ingeniero. Traduce entre dirección y técnica, prioriza por dolor y retorno, y sabe decir que no cuando automatizar algo todavía no tiene sentido. Por eso, en la entrevista, el orden de peso importa: primero negocio y procesos, después las herramientas.

• Capacidad de priorizar por dolor y ROI: pregunta qué haría primero si tuviera tres procesos para mejorar y un mes de tiempo; el candidato con criterio prioriza por impacto, no por lo técnicamente más interesante.
• Traducción constante entre dirección y técnica: si en toda la entrevista nunca deja de usar jerga sin traducirla, así se va a comunicar contigo cada semana durante meses.
• Saber decir que no: pregúntale por un proyecto que rechazó o pausó porque no tenía sentido de negocio; quien nunca ha dicho que no a una automatización probablemente nunca evaluó el retorno.
• Evidencia de seguimiento, no solo de entrega: pregunta cómo midió si el cambio funcionó después de implementado; entregar no es lo mismo que confirmar un resultado.
• Credenciales técnicas, al final y relativizadas: pregunta por cursos o certificaciones solo después de agotar lo anterior, y trátalas como complemento, nunca como filtro principal.

Cómo se ve en la práctica

Una distribuidora mediana de insumos industriales, unas 70 personas, en Perú, necesitaba su primer perfil de IA para ordenar cotizaciones, seguimiento de clientes y reportes que hasta entonces se armaban a mano cada fin de mes. El gerente general, sin ningún background técnico, llegó a la etapa final con dos candidatos.

El primero hablaba con mucha fluidez de agentes, flujos, integraciones y modelos. Cada respuesta sonaba impecable y el gerente salió de esa entrevista con la sensación de haber hablado con un experto. El segundo candidato respondía más simple: contaba que en su trabajo anterior el equipo de ventas perdía cotizaciones porque nadie llevaba seguimiento ordenado, que propuso centralizar esa información en un solo lugar, automatizar solo el recordatorio de seguimiento, y que en cuatro meses el equipo recuperó cotizaciones que antes se perdían por falta de contacto.

El gerente, siguiendo el guion de preguntas de negocio, le pidió al primer candidato que explicara su proyecto “como si yo fuera el dueño de la empresa”. La respuesta volvió a llenarse de términos técnicos y terminó con un “es difícil de explicar sin tecnicismos”. Al segundo candidato le hizo la misma pregunta y la respuesta fue prácticamente la misma que ya había dado, solo que aún más corta.

Contrataron al segundo. A los tres meses, el proceso de seguimiento de cotizaciones había mejorado de forma medible: menos cotizaciones sin respuesta, menos reclamos por “nadie me avisó”. El primer candidato, según supo después el gerente por una referencia cruzada, fue contratado por otra empresa de la zona para “automatizar todo el área comercial” y seis meses después ya no estaba en ese puesto.

Mi criterio

Cómo saber si lo hiciste bien

No hay examen técnico que reemplace este chequeo simple: si terminaste la entrevista y puedes describir, en un párrafo, qué proceso de negocio resolvió antes el candidato y qué número movió, hiciste bien tu trabajo aunque no entiendas cómo funciona el modelo por dentro.

• Puedo repetir, en mis palabras, un proceso concreto que el candidato mejoró, con un antes y un después claros.
• El candidato tradujo cada término técnico a una consecuencia de negocio, sin que yo tuviera que pedírselo dos veces.
• Escuché al menos una historia de algo que salió mal y cómo se corrigió, no solo éxitos perfectos.
• El candidato priorizó o descartó algo cuando le pregunté qué no automatizaría, en vez de decir que “todo se puede”.
• Mis notas de la entrevista hablan de procesos y resultados, no de cuántas herramientas o siglas mencionó.

Si marcaste las cinco, confía en tu criterio de negocio: es exactamente el criterio que este puesto necesita todos los días, mucho más que el tuyo sobre arquitectura de modelos. Si no marcaste ni la mitad, no es que necesites un curso técnico urgente. Necesitas repetir la entrevista con alguien que sí sepa explicarte su trabajo en el idioma en que tú tomas decisiones.