1. Empezar por el problema, no por la solución
Empieza por lo que alguien no conseguía hacer. Quién sufría el problema, con qué frecuencia y qué hacía que la situación fuera cara o arriesgada. Sin ese encuadre, tu interlocutor no puede valorar ni la dificultad del proyecto ni la pertinencia de tus decisiones. Suele bastar una frase: «Los equipos de soporte reabrían manualmente casos ya resueltos porque nada permitía recuperar un histórico repartido en tres sistemas».
Después indica quién formuló la petición y cómo se definió el éxito al principio. Muchos proyectos de IA fracasan precisamente porque ese punto queda implícito; demostrar que lo planteaste de forma explícita ya es una señal de madurez profesional.
2. Nombrar las restricciones reales
Las restricciones son lo que convierte un ejercicio en un proyecto. Explican por qué la solución evidente no era viable y, por tanto, por qué tus decisiones merecen atención.
- Datos: disponibilidad, calidad, derechos de uso, confidencialidad, volumen, actualización.
- Latencia: el tiempo de respuesta aceptable para el uso real, no para la demostración.
- Coste: presupuesto por consulta o por mes, y quién lo asume.
- Calidad: nivel de error tolerable y qué ocurre cuando el sistema se equivoca.
- Organización: equipo disponible, competencias internas, capacidad de mantener la solución después de ti.
- Cumplimiento: sector regulado, trazabilidad, alojamiento, datos personales.
3. Explicar las decisiones, no enumerarlas
Aquí es donde la mayoría de los candidatos cae en la recitación del stack. La regla es sencilla: cada tecnología mencionada debe ir seguida de inmediato del motivo que la hizo elegir en ese contexto concreto. «Usamos una base vectorial» no aporta nada; «los documentos se actualizaban a diario y el reentrenamiento quedaba descartado, así que optamos por recuperación en vez de fine-tuning» muestra tu razonamiento.
Versión stack
«Hicimos un RAG con Python, LangChain, una base vectorial y un modelo propietario para la generación, desplegado en Kubernetes con un pipeline de ingesta por lotes y monitorización».
Versión decisiones
«Los documentos se revisaban cada semana, con versiones simultáneas del mismo texto. El fine-tuning quedaba descartado: el corpus cambiaba demasiado rápido. Optamos por recuperación, invirtiendo primero en la segmentación y en los metadatos de versión, porque ahí estaba el origen de las respuestas incoherentes. Para la generación elegimos el modelo más pequeño que alcanzaba nuestro umbral de calidad, con una etapa de reranking: el coste por consulta debía ser compatible con un uso diario de un centenar de personas».
Ambas versiones describen el mismo proyecto. La segunda permite evaluar un razonamiento; la primera solo permite marcar palabras clave.
4. Asumir los arbitrajes
Un proyecto sin arbitrajes suena a ejercicio académico. Cita al menos una opción que consideraste en serio y descartaste, y explica por qué: plazo, coste, una competencia que el equipo no tenía, una dependencia demasiado arriesgada. Di también qué aceptaste degradar —cobertura funcional, latencia, exhaustividad— y a cambio de qué.
Por último, distingue lo que decidiste tú de lo que decidió el equipo o impuso el contexto. Esa honestidad nunca debilita una candidatura: se verifica con una sola pregunta de seguimiento, y su ausencia también.
5. Mostrar cómo evaluaste
La evaluación es lo que separa con más claridad un prototipo de un sistema explotable, y suele ser la parte más débil de las presentaciones. Espera preguntas precisas.
- ¿Quién definió qué era una buena respuesta y sobre qué muestra?
- ¿Cómo sabías que un cambio mejoraba el sistema en lugar de desplazar el problema?
- ¿Tenías un conjunto de evaluación estable o juzgabas caso por caso?
- ¿Cómo detectabas una regresión tras cambiar de modelo, de prompt o de índice?
- ¿Qué hacías con los casos ambiguos, esos en los que incluso una persona duda?
Si el proyecto no tenía un dispositivo de evaluación, dilo, explica cómo trabajaste sin él y qué harías distinto hoy. Es más creíble que una evaluación reconstruida a posteriori.
6. Contar el paso a producción
Muchos proyectos de IA nunca salieron de la demostración, y los equipos técnicos lo saben. Si el tuyo llegó a producción, es una baza importante: describe el despliegue, la supervisión implantada, qué se rompió y qué aprendiste. Si se detuvo antes, dilo con claridad y explica por qué: una parada lúcida se cuenta muy bien.
- Qué se supervisaba una vez en servicio y quién lo hacía.
- Comportamiento previsto ante un fallo: repliegue, mensaje, escalado a una persona.
- Salvaguardas: filtrado, límites de uso, alcance deliberadamente reducido.
- Qué no sabía hacer el sistema y cómo se gestionaba ese límite desde producto.
7. Terminar por el impacto, sin cifras inventadas
Cierra con lo que cambió para las personas implicadas. Si dispones de cifras reales y comunicables, cítalas junto con su método de medición. Si no, describe la naturaleza del resultado: un uso que se volvió diario, una tarea que desapareció, una decisión tomada antes, un alcance asumido por el equipo interno. Una cifra aproximada que no puedes defender cuesta más que una descripción cualitativa honesta.
Un último reflejo útil: termina conectando el proyecto con la necesidad de la empresa. «Lo que me interesa aquí es que estáis exactamente donde estábamos nosotros: el prototipo funciona y la cuestión pasa a ser la fiabilidad y el coste». Esa frase convierte un relato en una candidatura.
Antes de presentar tu proyecto
Siete puntos, uno por etapa. El punto que no puedas cubrir es el que debes preparar primero.
- Puedo enunciar el problema en una frase, desde el punto de vista de quien lo sufría.
- Cito al menos dos restricciones reales que dieron forma a la solución.
- Cada tecnología que menciono está justificada por una razón de contexto.
- Puedo nombrar una opción descartada y explicar por qué.
- Sé decir cómo se evaluaba la calidad y quién lo hacía.
- Puedo describir el estado real: en producción, detenido o todavía en prototipo.
- Describo el impacto sin dar cifras que no podría defender.
Para recordar
- La estructura: problema → restricciones → decisiones → arbitrajes → evaluación → producción → impacto.
- Una tecnología solo tiene valor en el relato si la decisión que la eligió es explícita.
- Las opciones descartadas demuestran el nivel mejor que las funcionalidades entregadas.
- La evaluación es el punto más discriminante y el más olvidado.
- Vale más un resultado cualitativo honesto que una cifra inverificable.
- AI Engineering
- Evaluación
- Cloud y producción