El problema real no es la falta de competencias
Buena parte de quienes dudan en mencionar la IA en su CV han hecho algo real: identificar un caso de uso, probar una herramienta con datos de su ámbito, escribir criterios de aceptación, animar un piloto o explicar a un equipo por qué una respuesta generada no debía enviarse tal cual. Ese trabajo existe. Simplemente se describe de una manera que lo vuelve invisible.
Por tanto, esta guía no trata de aparentar experiencia. Es justo lo contrario: hacer visible y verificable una contribución real, formulándola con la precisión que usarías para cualquier otra parte de tu trabajo.
Quien selecciona o dirige un equipo técnico no comprueba si conoces el vocabulario. Quiere saber qué hiciste, en qué condiciones y qué sigue siendo cierto cuando se retira el entusiasmo.
Siete niveles de experiencia que conviene separar
«Competencias de IA» abarca realidades muy desiguales. Distinguirlas permite situarse con honestidad y evitar tanto la infravaloración como la promesa excesiva.
- Haber usado un asistente conversacional: uso individual, sin efecto organizativo demostrable. Es un punto de partida, no una competencia que reivindicar por sí sola.
- Haber automatizado un tratamiento o una cadena de tareas: hay un resultado concreto, pero su alcance y robustez determinan qué se puede decir de él.
- Haber encuadrado un caso de uso: problema, usuarios, alcance, datos, riesgos, criterios. Es una competencia profesional transferible y escasa.
- Haber contribuido a un producto con un componente de IA: especificación, arbitrajes, seguimiento, participación en decisiones de producto.
- Haber definido o probado criterios de evaluación: conjunto de casos, qué es una buena respuesta, umbrales, revisión de salidas. Suele ser la contribución más buscada y la menos reivindicada.
- Haber participado en la adopción o la gobernanza: reglas de uso, formación, marco de cumplimiento, seguimiento del uso real.
- Haber trabajado con un equipo de Data o AI Engineering: colaboración regular, lenguaje común, decisiones compartidas, sin sustituir a quienes desarrollan.
Estos niveles no forman una escala lineal de valor: encuadrar un caso de uso difícil vale a menudo más, en un puesto de producto o consultoría, que haber montado una automatización. Sobre todo forman una rejilla de precisión. Decir cuál ocupas realmente ya es una señal de seriedad.
Pasar de una formulación débil a una demostrable
El método cabe en seis elementos. Una buena formulación no siempre los contiene todos, pero una formulación débil no suele contener ninguno.
- 1
El contexto
Dónde, con quién, con qué restricciones. «En una dirección jurídica de quince personas, sobre documentos contractuales no estructurados» sitúa de inmediato el nivel de dificultad.
- 2
El problema
Qué no funcionaba antes, expresado desde el trabajo real: tiempo perdido, decisiones retrasadas, información imposible de encontrar, tareas repetitivas de bajo valor.
- 3
Tu responsabilidad personal
Lo que hiciste tú, distinto de lo que hizo el equipo. Es el punto que más se difumina y el que se indaga sistemáticamente en entrevista.
- 4
El enfoque
Cómo lo abordaste: encuadre, recogida de casos reales, definición de criterios, pruebas, piloto, acompañamiento. Describe el método, no la tecnología.
- 5
El resultado
Qué cambió, de forma observable. Un resultado modesto y verificable vale más que un porcentaje impresionante que no podrás justificar.
- 6
Los límites
Lo que la solución no cubría, lo que se abandonó, lo que sigue abierto. Es lo que distingue a quien trabajó de verdad en el tema de quien lo leyó.
Si no tienes una cifra fiable, no la inventes. «El tiempo de preparación bajó de forma clara, aunque no lo medimos formalmente» es una frase aceptable y nadie puede volverla contra ti.
Tres ejemplos antes / después
Las versiones «antes» son deliberadamente típicas: aparecen tal cual en muchos CV. Las situaciones descritas son escenarios pedagógicos, para adaptar a tu experiencia real.
Producto / Product Owner
Antes
«Pilotaje de un proyecto de IA. Uso diario de ChatGPT y herramientas de IA.»
Después
«En una funcionalidad de asistencia a la redacción para un equipo de soporte de treinta personas, encuadré el alcance con el equipo técnico: tres tipos de solicitudes tratadas, fuentes autorizadas, comportamiento esperado ante la duda (proponer una plantilla vacía en lugar de una respuesta incierta) y prohibición de cualquier compromiso comercial en la propuesta. Construí el conjunto de ochenta casos reales anonimizados usado para validar cada versión. La funcionalidad se usa a diario en ese alcance reducido; la extensión a solicitudes complejas se descartó tras las pruebas, por falta de fuentes fiables.»
Business Analyst / consultoría
Antes
«Experiencia en IA generativa. Acompañamiento de la transformación con IA del cliente.»
Después
«Para una dirección financiera, instruí cuatro casos de uso candidatos y recomendé quedarse solo con uno. Para cada uno documenté los datos realmente disponibles, los derechos de acceso, la frecuencia de actualización y la consecuencia de un error. Dos se descartaron porque los datos no eran explotables tal cual, y un tercero porque la ganancia esperada no justificaba la carga de control. El caso retenido se especificó con criterios de aceptación evaluables, probados sobre expedientes reales con los equipos de negocio.»
UX / proyecto y transformación
Antes
«Diseño de experiencias de IA. Sensibilización de los equipos en herramientas de IA.»
Después
«Realicé ocho entrevistas con usuarios de un asistente interno para entender por qué el uso caía a las dos semanas. El problema no era la calidad de las respuestas, sino la imposibilidad de comprobar su origen. Diseñé y probé una presentación de las fuentes y un mecanismo de aviso, y después definí con el equipo de producto qué debía hacer el sistema cuando no estaba seguro. También redacté las reglas de uso difundidas a los equipos, distinguiendo las tareas en las que la revisión humana seguía siendo obligatoria.»
En los tres casos, la versión «después» no reivindica ninguna competencia técnica. Y sin embargo es mucho más difícil de escribir para alguien que no hizo el trabajo: eso es justamente lo que la hace creíble.
Adaptar el mensaje según el soporte
El fondo es el mismo; cambian el formato y el nivel de detalle.
CV
De dos a cuatro líneas por experiencia, centradas en responsabilidad y resultado. Nada de una sección «competencias de IA» con una lista de herramientas: no demuestra nada e invita a preguntas que no querrás responder. Si insistes en una línea de competencias, formúlala por capacidades: «encuadre de casos de uso de IA, definición de criterios de evaluación, conducción de pilotos».
Perfil TalentAI
Hay más espacio que en un CV: describe el tipo de problemas que sabes tratar, el contexto en el que intervienes y el nivel real de tu práctica. Un perfil que dice con claridad «no desarrollo; encuadro, pruebo y hago adoptar» resulta más útil a las empresas que uno que deja una duda flotando.
Perfil profesional público
En un perfil público, lo que importa es la coherencia entre el titular y el contenido. Un titular que anuncia experiencia técnica sobre una experiencia que describe encuadre produce una impresión negativa inmediata. Un titular honesto — tu profesión, con el ámbito de IA en el que intervienes — se sostiene mucho mejor. Evita también copiar una fórmula de moda: envejece rápido y te vuelve intercambiable.
Entrevista
Aquí es donde la precisión rinde. Prepara dos situaciones que puedas contar durante cinco minutos con detalles concretos: lo que descubriste por el camino, la decisión difícil, lo que se abandonó. Prepara también la frase que delimita tu alcance: «no diseñé el sistema; definí qué debía hacer, con qué datos y cómo comprobaríamos que lo hacía». Esa frase cierra el tema en lugar de abrirlo.
Portfolio o caso práctico
Un portfolio solo es pertinente si puedes mostrar algo sin vulnerar una confidencialidad: un documento de encuadre anonimizado y reconstruido, una rejilla de criterios de evaluación, un protocolo de pruebas, un retorno de experiencia estructurado. No es obligatorio para un perfil no técnico, y un mal portfolio perjudica más de lo que ayuda. En cambio, un ejercicio de encuadre resuelto con limpieza en una entrevista sustituye con ventaja a cualquier documento.
Lo que conviene no reivindicar
Algunas formulaciones producen el efecto contrario al buscado. Atraen preguntas técnicas precisas y la distancia se nota enseguida.
- «AI Engineer» tras unas cuantas automatizaciones: el título te compromete con una práctica de ingeniería que no tendrás que demostrar una vez, sino en cada conversación.
- «Experto en LLM» tras un uso regular de un asistente: la experiencia sobre modelos supone poder hablar de evaluación, coste y límites, no de uso.
- «Experto en RAG» o «especialista en agentes» sin experiencia demostrable: son temas de ingeniería; reivindicarlos sin haber construido ni evaluado se desmonta con una pregunta.
- Un dominio técnico no verificable: herramientas citadas sin contexto, tecnologías listadas sin realización asociada.
- Una cifra que no puedes explicar: de dónde sale, cómo se midió, en qué periodo.
- Una contribución colectiva presentada en primera persona del singular: es el error más fácil de detectar y el más caro.
Una regla lo simplifica todo: no reivindiques nada que no pudieras defender durante diez minutos ante alguien que se dedica a ello a diario.
Asumir un posicionamiento no técnico
Detrás de estas dudas hay una inquietud legítima: temer que, sin competencia técnica, la candidatura no pese. En la práctica, a las organizaciones que despliegan sistemas de IA rara vez les faltan personas capaces de construir; les faltan personas capaces de decir qué hay que construir, para quién, con qué datos y en qué condiciones el resultado será aceptable.
Formular con claridad ese posicionamiento — qué sabes hacer, qué no haces y con quién trabajas bien — es más eficaz que inflar un barniz técnico. Además es lo que permite incorporarse a un equipo sin tener que sostener un papel que no se puede sostener.
Las pruebas que conviene reunir
Antes de reescribir tu CV o tu perfil, reúne lo que podrías mostrar o contar con detalle de verdad.
- El contexto preciso de al menos dos situaciones: organización, usuarios, restricción principal.
- Lo que produjiste personalmente: documento de encuadre, conjunto de casos, criterios, protocolo de pruebas, plan de adopción.
- Las decisiones a las que contribuiste y las que no tomaste.
- Uno o dos casos límite que hubieras identificado.
- El resultado observable, por modesto que sea, y cómo se constató.
- Lo que no funcionó y qué aprendiste de ello.
- Las personas con las que trabajaste y lo que podrían confirmar.
- Lo que no sabes hacer, dicho sin incomodidad.
Para recordar
- El objetivo no es parecer experto, sino hacer verificable lo que realmente sabes hacer.
- «Usar un asistente» y «encuadrar un caso de uso» son niveles muy distintos: hay que nombrarlos por separado.
- Una formulación sólida contiene contexto, problema, responsabilidad personal, enfoque, resultado y límites.
- Contar lo que no funcionó refuerza la credibilidad en lugar de debilitarla.
- Los títulos técnicos no demostrables — AI Engineer, experto en LLM, experto en RAG — se vuelven contra quien los usa.
- Las pruebas se reúnen antes de la entrevista: casos, criterios, documentos, decisiones, opiniones de usuarios.
- Cultura de IA
- AI Product
- Adopción