EN CONVERSACIÓN / Inteligencia
Entrevista a Mateo Llorvés, consultor de ia aplicada a medios: inteligencia para decidir, no solo para producir
Mateo Llorvés, consultor de ia aplicada a medios, sitúa la conversación en una tensión muy concreta: un equipo que compra IA antes de decidir qué problema quiere resolver. La IA entra en la planificación y en los procesos de agencia. El reto consiste en convertir capacidad técnica en preguntas mejores, aprendizaje y decisiones que puedan explicarse. Recorremos las decisiones, los límites y las preguntas que aparecen cuando esas ideas llegan al trabajo cotidiano.

¿Cuál sería un mal punto de partida para incorporar IA a una agencia de medios?
Empezar por una lista de herramientas sin haber identificado los problemas. La IA exige mejores preguntas. ¿Dónde perdemos tiempo? ¿Qué información nos cuesta conectar? ¿Qué decisión necesita más contexto? Si no respondemos eso, podemos llenar la organización de pruebas interesantes que no cambian la calidad del trabajo ni la experiencia del cliente.
¿Cómo distingues una demostración llamativa de una aplicación útil?
Pidiéndole que funcione dentro de un proceso real, con datos imperfectos y personas que necesitan entender el resultado. Una demostración suele enseñar el mejor caso. Una aplicación útil debe explicar también qué sucede cuando falla y quién revisa. El valor aparece cuando mejora una tarea concreta de forma consistente y con un coste razonable de supervisión.
¿Qué le pedirías a una recomendación de medios generada con IA?
Que permita rastrear los datos utilizados, las hipótesis y las limitaciones. Una respuesta bien redactada puede transmitir más seguridad de la que merece. El equipo debería poder cuestionarla y contrastarla con otras evidencias. Si no sabemos por qué se propone una decisión, resulta difícil defenderla, aprender de ella o corregirla después.
¿Cómo cambia la formación de los perfiles júnior?
Tenemos que enseñar a formular problemas, verificar información y conectar disciplinas. Las herramientas pueden acelerar tareas que antes servían para aprender, así que hace falta diseñar otras formas de adquirir ese criterio. No bastaría con enseñar instrucciones eficaces. También conviene explicar cuándo una respuesta aparentemente buena está omitiendo algo importante.
¿Qué prueba pequeña recomendarías para empezar a aprender?
Una tarea acotada, repetible y con resultados que un equipo pueda revisar. Por ejemplo, organizar documentación interna autorizada para preparar una reunión. Definiría primero cómo evaluaremos calidad, tiempo y errores. Es mejor aprender con un uso concreto y ampliar desde ahí que intentar transformar de golpe un proceso que todavía no entendemos bien.
Llevemos esta conversación a una situación concreta. ¿Por dónde empezarías?
Pensemos en un equipo que compra IA antes de decidir qué problema quiere resolver. Mi primer paso sería comparar un flujo actual y uno asistido sobre el mismo encargo. No empezaría por una presentación de soluciones. Necesitamos acordar qué problema estamos intentando resolver y qué parte depende realmente del equipo. Esa conversación inicial evita invertir el presupuesto en una respuesta vistosa que no cambia la situación de partida.
¿Qué tendría que ocurrir para que consideraras que la decisión ha funcionado?
Buscaría tiempo de revisión, coste de errores y calidad de una entrega aceptada. Esa señal debe acordarse antes de poner el proyecto en marcha, junto con un periodo razonable para observarla. También conservaría lo que contradiga nuestra hipótesis. Un resultado útil no es necesariamente un resultado favorable: puede enseñarnos que debemos cambiar el enfoque antes de invertir más.
¿Dónde se suele torcer el proceso cuando aparece la presión por entregar?
En medir el ahorro solo por lo rápido que aparece el primer borrador. Es tentador porque ofrece una sensación inmediata de avance. Pero desplaza la pregunta que daba sentido al encargo. Cuando aparece esa presión, volvería al acuerdo inicial y explicaría qué se gana y qué se pierde con cada atajo. Las renuncias deben ser decisiones conscientes, no accidentes del calendario.
Con un presupuesto reducido, ¿qué protegerías y a qué renunciarías?
Protegería la posibilidad de comparar un flujo actual y uno asistido sobre el mismo encargo. Reduciría el número de entregables antes de quitar el tiempo necesario para entender y comprobar la idea. Una versión pequeña puede ser muy exigente si tiene un objetivo claro. Prefiero probar una decisión completa en un entorno acotado que repartir el esfuerzo entre muchas ejecuciones a medio resolver.
¿Qué conversación debería mantener la dirección con el equipo antes de dar luz verde?
Le pediría que explicara qué prioridad tiene el proyecto, quién puede tomar decisiones y qué límites no son negociables. En este caso, el objetivo sería tiempo de revisión, coste de errores y calidad de una entrega aceptada. Si cada persona interpreta el éxito de una manera distinta, la revisión final se convierte en una discusión de preferencias que ya no puede resolverse con el trabajo entregado.
¿Qué papel darías a la tecnología sin dejar que decida el rumbo del trabajo?
La utilizaría para comparar alternativas y reducir tareas repetitivas, pero mantendría a una persona responsable de revisar lo que cambia. El riesgo de medir el ahorro solo por lo rápido que aparece el primer borrador también puede automatizarse. Antes de incorporar otra herramienta comprobaría qué información utiliza, qué errores produce y si el equipo puede continuar cuando esa herramienta deja de funcionar.
Para alguien que quiera aplicar esta reflexión mañana, ¿cuál sería una primera acción concreta?
Elegiría un proyecto abierto y escribiría una página con el problema, la decisión pendiente y la evidencia que falta. A partir de ahí propondría comparar un flujo actual y uno asistido sobre el mismo encargo. No hace falta transformar toda la organización de una vez. Hace falta que esa primera prueba deje un aprendizaje que otra persona pueda entender, discutir y utilizar en el siguiente encargo.



