Cómo evaluar el portafolio de un candidato de IA

El error de juzgar el portafolio por la demo

En la mayoría de procesos de selección para un puesto de IA pasa lo mismo: el candidato comparte pantalla, abre un chatbot que responde en dos segundos, muestra un agente que redacta un correo o arma un reporte solo, y el comité asiente. Nadie pregunta qué pasó antes de esa demo ni qué pasó después. La reunión termina y alguien dice “se ve que sabe” sin haber verificado absolutamente nada.

El problema no es la demo en sí. El problema es que RRHH, y hasta dirección, terminan evaluando lo único que pueden juzgar sin conocimiento técnico profundo: qué tan pulida se ve la pantalla. Eso invierte el criterio completo. Se premia la puesta en escena, no el diagnóstico que esa persona hizo antes de construir nada, ni el seguimiento que le dio después.

Esto abre la puerta a un perfil muy específico: el que en un fin de semana arma una automatización vistosa conectando un par de herramientas con un modelo de lenguaje, la presenta como si fuera un proyecto de meses, y nunca menciona si esa automatización sigue viva, si alguien la usa hoy, o si movió algo real en el negocio. Es una demo, no un caso de negocio.

La pregunta que casi nadie hace, y que cambia todo, es simple: “¿qué problema de negocio resolvió con esto, y cómo lo sabe?”. Si el candidato no tiene una respuesta con un número, un antes y un después, y el nombre de un proceso concreto, lo que tienes enfrente es una demo, no un portafolio.

Qué es evaluar un portafolio de IA (y qué no)

Evaluar un portafolio no es hacer un inventario de tecnologías mencionadas. Es una auditoría de evidencia: cada proyecto que el candidato presenta debería sostenerse solo si le quitas la tecnología de encima y preguntas “¿qué cambió en el negocio?”. Si la respuesta se desinfla sin la palabra IA, el proyecto nunca fue sobre negocio.

Esto significa que el filtro no pasa por el candidato que domina más herramientas ni por el que tiene el portafolio más largo. Pasa por el que puede sostener, caso por caso, una historia completa de negocio, con nombres de proceso, no solo nombres de modelos.

• No es contar cuántas herramientas, modelos o frameworks menciona en su CV o su portafolio.
• No es premiar el proyecto más complejo técnicamente sin preguntar antes si resolvió algo.
• No es aceptar el relato del propio candidato sobre su impacto sin pedir un dato o una referencia.
• No es juzgar por qué tan “profesional” se ve el video, el deck o la interfaz de la demo.
• No es confundir el número de certificaciones con evidencia de resultados reales en una empresa.

El contexto completo que debe traer cada caso

Un portafolio de IA que vale algo no se lee en una lista de bullets con nombres de herramientas. Se lee como un caso de negocio, y un caso de negocio necesita cuatro piezas de contexto. Si al candidato le falta una, pídesela antes de seguir avanzando en el proceso.

Sector y tamaño de la empresa

Sin esto no puedes calibrar nada. No es lo mismo automatizar la atención al cliente de una startup de doce personas que de una aseguradora con cuatrocientos empleados y un área legal encima de cada cambio. Pide sector, tamaño aproximado y país; no hace falta el nombre de la empresa si hay confidencialidad de por medio.

El problema de negocio antes de la IA

Pide que describa el dolor en términos de negocio, no de tecnología: “el equipo de cobranza tardaba tres días en conciliar pagos” dice más que “construimos un pipeline con un modelo de lenguaje”. Si el candidato solo puede describir el problema en términos técnicos, es una señal de que nunca conversó de cerca con el área afectada.

Qué hizo la persona, en concreto

Pide el verbo exacto: ¿diagnosticó el proceso?, ¿decidió qué automatizar y qué no?, ¿construyó el flujo?, ¿lo probó con usuarios reales?, ¿lo sostuvo en producción después del lanzamiento? Un portafolio sólido separa estas etapas con precisión; uno débil las mezcla todas bajo un genérico “lideré el proyecto”.

El número que se movió

Tiempo de respuesta, tasa de error, horas liberadas, ingresos retenidos, costo evitado. No hace falta una cifra exacta y auditada en la entrevista (eso se valida después, con permiso, contactando una referencia), pero sí una magnitud y una unidad. “Mejoramos la experiencia” no es un número; “bajamos el tiempo de conciliación de tres días a medio día” sí lo es.

Demo vistosa versus resultado de negocio real

La demo vistosa y el resultado de negocio no son opuestos automáticos. Un buen proyecto puede tener las dos cosas. Pero cuando solo hay una, casi siempre sobrevive la demo y desaparece el resultado. Aprende a distinguirlas en la conversación, no solo en la pantalla.

• Habla en presente de la herramienta y en condicional del impacto: “el agente responde en segundos” pero “esto debería reducir bastante el tiempo de respuesta”.
• No menciona quién usa el sistema hoy, ni desde cuándo, ni con qué frecuencia lo hace.
• No puede nombrar quién en el negocio, no en tecnología, pidió o validó el proyecto.
• El proyecto ya no existe o nadie lo mantiene, y aun así el candidato lo presenta como logro vigente.
• Cambia de tema hacia el modelo o la arquitectura en cuanto le preguntas por el número concreto.

El resultado de negocio real suena distinto. Aparece con un verbo de negocio (redujo, liberó, retuvo, evitó), una unidad de medida y, casi siempre, una anécdota de fricción real: un gerente que dudaba del proyecto, un dato que no cuadraba al principio, una decisión que hubo que negociar con el área antes de lanzar.

Lo que hizo la persona, no lo que hizo su equipo

En un porcentaje alto de portafolios de IA, el caso que se presenta como logro individual fue en realidad un esfuerzo de equipo, o directamente el trabajo de otra persona a la que el candidato acompañó de cerca. No siempre es deshonestidad; a veces es solo que nadie le pidió antes separar su aporte del de sus compañeros.

Tu trabajo en la entrevista es aislar esa variable con preguntas puntuales, no acusatorias, y observar si la respuesta llega rápida y específica o se vuelve vaga y genérica.

• “¿Qué decisión tomaste tú solo en este proyecto que, si la hubieras tomado distinto, habría cambiado el resultado?”: obliga a nombrar una decisión propia, no una compartida.
• “¿Qué parte del proyecto no salió bien al principio, y cómo la corregiste?”: un portafolio sin errores propios suele ser un portafolio ajeno bien contado.
• “¿Quién más estaba en el equipo y qué hacía cada uno?”: si no puede nombrar roles distintos al suyo con precisión, probablemente no estuvo tan cerca del proceso como dice.
• “Si te pidiera hacer esto mismo mañana, en otra empresa y sin ese equipo, ¿qué parte podrías replicar solo?”: separa la habilidad de la persona del contexto que la rodeaba.

Esto importa el doble en IA porque el mercado está lleno de perfiles que aprendieron a conectar dos o tres herramientas con un modelo de lenguaje y arman una demo convincente en un fin de semana, sin haber gestionado nunca un proceso completo ni sostenido una conversación difícil con un área de negocio. Ese es exactamente el perfil de automatizador que estas evaluaciones deben filtrar. 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 ROI, y sabe decir que no a un proyecto que no vale la pena así el modelo detrás sea impresionante. Si te interesa el recorrido completo de esa transición, en el sitio está documentado en “/recursos/roadmap-ia-de-automatizador-a-gerente-ia” y en “/contenido/de-automatizador-a-gerente-ia”.

Pedir permiso para contactar la referencia del caso

Todo caso que el candidato presente como logro propio debería venir con una pregunta de seguimiento inmediata: “¿me das permiso para contactar a alguien del negocio, no de tecnología, que pueda confirmar esto?”. No es falta de confianza. Es el mismo estándar que usarías para verificar cualquier cifra que te trae un proveedor antes de firmar un contrato.

Pide explícitamente el contacto de alguien del área que sufría el dolor (el gerente de cobranza, el jefe de atención al cliente, el director financiero), no del compañero de equipo técnico que solo puede confirmar que el código funcionaba. La referencia útil es la que puede decirte si el número que mencionó el candidato coincide con lo que el negocio realmente vivió.

• Pide el permiso antes de avanzar a la siguiente etapa, no después de hacer una oferta de trabajo.
• Pregúntale a la referencia qué cambió en su día a día, no si el candidato “es bueno” en general.
• Confirma la magnitud del número, aunque sea aproximada, y compárala con lo que dijo el candidato en la entrevista.
• Pregunta si el sistema sigue en uso hoy; un proyecto abandonado a los tres meses cuenta una historia muy distinta a una sostenida durante años.

Si el candidato se niega a dar una referencia de negocio, pone excusas de confidencialidad que no resisten un acuerdo simple de no divulgar nombres, o solo puede ofrecerte referencias técnicas, trátalo como una señal de alerta seria, no como un detalle menor. Un caso real, con permiso del cliente o del jefe de área, casi siempre se puede verificar sin exponer información sensible; basta con preguntar sector, magnitud y proceso, sin pedir cifras exactas de facturación ni nombres de contratos.

Cómo se ve esto en la práctica

Una empresa de servicios financieros mediana, unas 150 personas, en Colombia, abrió la búsqueda de un “Gerente de IA” para liderar la adopción interna. Uno de los finalistas llegó con un portafolio impecable en apariencia: un agente que redactaba minutas de comité, un chatbot de atención por WhatsApp, un panel de indicadores generado automáticamente, todo mostrado en video con una edición cuidada.

En la primera entrevista el comité quedó impresionado y casi avanzó directo a la oferta. Antes de firmar nada, RRHH pidió, siguiendo el mismo criterio de esta página, que el candidato explicara un caso con contexto completo: sector del cliente, problema de negocio antes del proyecto, qué hizo él en concreto y qué número se movió después. El candidato no pudo nombrar un solo número. Cada proyecto se describía en términos de la tecnología usada, algo como “integramos un modelo de lenguaje con nuestro CRM”, nunca en términos del negocio que lo recibió.

Cuando le pidieron permiso para contactar a un responsable de negocio de cualquiera de esos casos, ofreció en cambio el contacto de un excompañero de equipo técnico. Esa combinación, cero números y cero referencia de negocio, fue la señal que cerró el proceso con ese candidato, a pesar de lo pulido de sus demos.

La empresa terminó contratando a otra persona con un portafolio visualmente mucho más modesto: dos casos, con menos brillo técnico, pero cada uno con un número concreto (bajó de tres días a medio día el tiempo de conciliación de pagos en un caso, redujo en un tercio las llamadas repetidas al call center en otro) y con el nombre del gerente de finanzas dispuesto a confirmar el dato en una llamada corta. Ese candidato, además, describía sus propios errores sin que se lo pidieran dos veces.

Mi criterio

Cómo saber si evaluaste bien el portafolio

No necesitas ser técnico para evaluar bien un portafolio de IA. Necesitas disciplina para no dejarte llevar por la demo y exigir, caso por caso, la misma evidencia que le pedirías a cualquier proveedor antes de firmar un contrato.

• Cada caso tiene sector, tamaño y problema de negocio explícitos, no solo el nombre de la tecnología usada.
• El candidato puede nombrar un número o una magnitud de cambio, con antes y después, aunque sea aproximado.
• Puede separar lo que hizo él de lo que hizo su equipo, con al menos una decisión y un error propios.
• Dio permiso, sin resistencia, para contactar a alguien del negocio que confirme el caso.
• Explica el impacto en el negocio antes que la arquitectura técnica cuando le preguntas “¿y esto para qué sirvió?”.

Si un candidato cumple estas cinco condiciones en al menos un caso de su portafolio, tienes evidencia real con la que trabajar. Si ningún caso las cumple, no importa cuántas herramientas mencione ni qué tan bien editado esté el video: no tienes un portafolio, tienes un show, y ese perfil no es el que necesitas para que la IA mueva algo de verdad en tu operación.