De keyword a anuncio terminado: un pipeline de cinco fases y seis estados para hacerlo operable

La promesa de casi cualquier herramienta de creatividad con IA hoy es sencilla: introduces una keyword y, al final del proceso, tienes un vídeo publicitario. También es una de las promesas más fáciles de creerse sin comprobar qué hay detrás.

En cuanto intentas usar una de verdad, «automático» empieza a esconder demasiadas preguntas. ¿Qué ocurre si la keyword es muy específica, no devuelve resultados orgánicos y tampoco aparece nada en la biblioteca comercial? ¿El pipeline debe detenerse e indicar que no hay evidencia, o enviar un brief vacío a generar un vídeo que nadie ha validado? Y si, a mitad del recorrido, un canal queda fuera del alcance de tu cuenta y no devuelve datos, ¿significa «sin resultados» o «ni siquiera se pudo consultar»? Son situaciones opuestas y requieren respuestas distintas, aunque la mayoría de herramientas de un clic las reduzcan al mismo indicador de carga.

Un pipeline creativo diseñado para operar en producción, y no solo para una demo, no se gana su valor en el botón de «generar». Lo hace al mostrar con claridad el estado de cada fase. Esa transparencia determina si puedes mantenerlo funcionando y localizar el punto de rotura cuando no sale ningún resultado.

Antes de entrar en materia, una delimitación importante. Las fases de investigación de este pipeline consultan la biblioteca pública de anuncios y el centro creativo de cada plataforma, usando tu propia cuenta y datos que la plataforma publica para todos los anunciantes. No hay firmas ni mecanismos para sortear restricciones. El objetivo de este artículo es explicar cómo convertir esos datos públicos en decisiones y activos publicables, no cómo obtenerlos.

La base: un pipeline de cinco fases

Pasar de una keyword a un vídeo publicitario implica cinco fases ordenadas. No son pasos aislados: cada una consume la salida de la anterior y alimenta la siguiente.

1. Descubrimiento de demanda. Se parte del término de búsqueda del mercado, se explora contenido orgánico y se comprueba si el tema despierta interés real entre usuarios. El resultado es una señal procedente de contenido orgánico.

2. Validación comercial. Aquí se analizan dos señales comerciales. La primera es la oportunidad de la keyword: volumen de búsqueda, competencia y datos ligados a inversión. La segunda son los Top Ads con buen rendimiento en el centro creativo. Ambos tipos de activos han recibido inversión y validación del mercado, por lo que no equivalen al contenido orgánico.

3. Selección de creadores. Se buscan creadores de la biblioteca de influencers que encajen con el tema y el mercado.

4. Brief creativo. Se reúne la evidencia cualificada de las tres fases anteriores en una especificación estructurada que puede enviarse directamente a un modelo de generación. Aquí se fijan la estructura narrativa, la forma del gancho y el mercado objetivo.

5. Generación. El brief se entrega a un modelo de generación de vídeo para producir un anuncio nativo vertical en formato 9:16.

El peso del sistema recae en la cuarta fase. Las tres primeras recogen evidencia y la quinta consume presupuesto; el brief es el punto donde la evidencia se convierte en una decisión. Si la recopilación inicial es deficiente, el brief decide a partir de ruido y acabas generando un vídeo basado en ruido. La pantalla de carga no te mostrará eso. Solo se vuelve visible cuando expones el estado de cada fase.

Las tres primeras fases merecen un análisis propio. Cómo interpretar una curva de retención segundo a segundo, cómo convertir la oportunidad de una keyword en una cifra única de presupuesto y cómo cruzar la biblioteca de influencers con la de activos en vez de elegir perfiles por número de seguidores son los temas de otros tres artículos. Este se centra en los problemas adicionales que aparecen al conectarlas en una misma cadena.

Seis estados por fase: por qué «failed» debe dividirse en cuatro

Esta es la sección más importante del artículo.

La mayoría de pipelines asignan dos posibles resultados a cada fase: éxito o fallo. Puede funcionar con una o dos fases. Con cinco, deja de hacerlo, porque «fallo» mezcla cuatro situaciones que exigen acciones completamente distintas.

En este flujo, el resultado de cada fase pertenece a uno de estos seis estados:

• completed: la fase se ejecutó, obtuvo un resultado cualificado y puede continuar.

• empty: la fase se ejecutó, el canal estaba disponible, pero no devolvió ningún resultado cualificado. Se buscó y no se encontró nada.

• skipped: desactivaste tú mismo la fase al configurar su cuota en 0, así que nunca llegó a ejecutarse.

• unavailable: la fase debía ejecutarse, pero no pudo. El canal está fuera de lo que puede cubrir tu cuenta —por ejemplo, la oportunidad de keyword solo incluye algunos idiomas de mercado— o una dependencia no estaba disponible temporalmente.

• blocked: la evidencia previa no es suficiente y una puerta la ha detenido deliberadamente. No ha fallado por sí sola: no recibió los datos que necesitaba de una fase anterior.

• ready: un estado intermedio exclusivo de la generación. El preflight ha pasado, pero aún no has ordenado el envío. Puede producir el vídeo y espera tu confirmación.

No se trata de acumular seis etiquetas. El problema aparece en cuanto empty, skipped, unavailable y blocked se reducen a un único «failed»: el pipeline deja de ser operable. Los cuatro significan «esta vez no habrá vídeo», pero cada uno te pide algo diferente.

• empty indica un problema de datos. Puede que el mercado no tenga volumen o que la keyword sea demasiado específica. La respuesta es cambiar el término o relajar el umbral, sin tocar una línea de código.

• skipped refleja una decisión tuya. No hay que hacer nada, pero debe seguir diferenciado de empty; de lo contrario, puedes perder media jornada depurando una fase que nunca estuvo activada.

• unavailable apunta a un problema de canal o configuración. Conviene revisar la cobertura de la cuenta o reintentar, no ajustar la keyword.

• blocked es un problema aguas arriba. Esta capa funciona correctamente; alguna fase anterior no aportó resultados. Hay que volver al estado empty que lo originó, no pelearse con la capa bloqueada.

Un «failed» opaco bloquea las cuatro rutas y te obliga a adivinar. Por eso un pipeline que entrega un resultado sin exponer su estado no se puede operar durante mucho tiempo. Cada vez que algo falla, necesitas reproducir toda la ejecución para entender qué ocurrió.

El embudo de evidencia: las señales orgánicas y comerciales no se suman

El descubrimiento de demanda no termina al «encontrar unos cuantos» resultados. Los datos brutos deben pasar por un embudo que contabilice cada nivel: cuántos resultados llegaron, cuántos quedaron fuera de la ventana temporal, cuántos estaban en otro idioma, cuántos no trataban realmente del tema, cuántos tenían demasiado pocas visualizaciones para servir de muestra y cuántos terminaron cualificando. Cuando esta fase devuelve empty, el embudo permite identificar dónde se agotó la evidencia. No encontrar nada, encontrar mucho pero caducado, o tener contenido que no alcanza el mínimo de muestra son tres vacíos distintos y requieren tres acciones distintas. Sin ese embudo, empty no es más que un array vacío y ni siquiera sabes cómo ha llegado a estarlo.

Pero hay una regla aún más relevante que contar: las señales de contenido orgánico y las señales comerciales se contabilizan por separado; nunca se suman en una única «puntuación de evidencia». Un Top Ad es un activo en el que alguien ha invertido dinero real y que la plataforma ha considerado eficaz. Diez vídeos orgánicos, por mucho interés que generen, solo demuestran que la gente está dispuesta a verlos gratis. Una suma ponderada puede permitir que diez vídeos orgánicos ahoguen un Top Ad por volumen, aunque ese Top Ad tenga un valor comercial mucho mayor. El enfoque correcto es agrupar primero y ordenar después. Las señales comerciales tienen prioridad; si no existen, se recurre al contenido orgánico cualificado; y solo si tampoco lo hay, a los creadores. Las capas se ordenan por credibilidad, no por cantidad.

La misma regla se aplica al analizar un vídeo individual. En una pieza orgánica, los likes y los comentarios son un tipo de señal; los compartidos y los guardados son otro. Compartir y guardar son acciones más cercanas a una intención comercial, el gesto de «merece la pena conservarlo o pasarlo a otra persona», y deben pesar más que la interacción básica al ordenar resultados. El volumen de interacción indica que el contenido se puede ver. Los compartidos y guardados indican que quizá pueda vender. Incluso dentro de un mismo vídeo, son lecturas diferentes.

(Como apunte, «tratar la correlación como causalidad y la frecuencia como eficacia» es el error que más le gusta cometer a un modelo en la fase de atribución. Por eso el prompt debe obligarlo a ofrecer un contraejemplo. Es la misma disciplina de prompting que obliga al modelo a seguir cuestionando un patrón que acaba de detectar en el artículo sobre fingerprinting. Allí se aborda la evidencia contraria en ingeniería inversa; aquí, el contraejemplo en atribución publicitaria. El mecanismo es el mismo.)

Dos formas de «ready»: el preflight de plataforma no es evidencia de investigación

Justo antes de generar hay dos juicios muy fáciles de fusionar, y no deben fusionarse: «la plataforma puede producir un vídeo» y «este vídeo concreto debería producirse» son puertas distintas.

La primera es la disponibilidad del preflight de plataforma: ¿el servicio de generación está operativo?, ¿hay cuota suficiente?, ¿el prompt está permitido? Son comprobaciones de infraestructura. La segunda es la disponibilidad de evidencia de investigación: ¿hay al menos una pieza primaria de evidencia cualificada entre los datos recopilados? Es una comprobación de contenido. Ambas puertas deben superarse antes del envío; si falla cualquiera de ellas, el estado es blocked.

La tentación de unirlas es comprensible, porque ambas parecen responder a «¿podemos generar?». Pero al hacerlo aparece el tipo de fallo más caro: la plataforma funciona, hay cuota de sobra, el prompt es válido, el preflight pasa y, aun así, se genera un vídeo construido sobre cero evidencia. Cuesta más que un fallo limpio porque parece un éxito y podrías llegar a invertir en él. Al separar las dos puertas, ese caso queda correctamente en blocked y deja claro que falta evidencia, no cuota. «Poder producir» nunca equivale a «deber producir», y expresarlo todo en una sola condición es el error de diseño más habitual en pipelines de este tipo.

El brief solo lee evidencia cualificada: el copy de competidores se investiga, no se pasa al prompt

El brief creativo es el punto del flujo que más exige al modelo de texto y también donde la disciplina de desensibilización puede desviarse con mayor facilidad.

Su función consiste en extraer la estructura validada de la evidencia cualificada. Qué gancho se repite en los Top Ads, en qué segundo alcanza su máximo la curva de retención o qué esqueleto utilizan los mejores contenidos orgánicos dentro de la secuencia «plantear el problema, demostrar el resultado, llamada a la acción». Después, sintetiza esas estructuras en una especificación para generación.

Hay una restricción estricta: el texto bruto de los activos de competidores solo se utiliza para identificar estructuras y nunca entra en el prompt final de generación. Los nombres de marca, cantidades de proveedores, cuotas, precios y afirmaciones de rendimiento presentes en el gancho de un competidor son afirmaciones específicas de ese competidor, no estructuras. Se conservan intactos en los resultados de investigación para que puedas revisarlos y rastrear qué activo inspiró una idea, pero se excluyen explícitamente al construir el prompt de generación. El modelo recibe algo como «crea un vídeo para mi producto con este esqueleto narrativo y esta forma de gancho», no «copia esta frase».

La razón de imponer esta restricción merece el esfuerzo: si viertes directamente el copy de un competidor en el prompt, el vídeo puede salir con su marca y su promesa de precio. En el mejor de los casos tendrás un activo con riesgo legal; en el peor, plagio directo. Si alimentas al modelo solo con la estructura, eliminando las afirmaciones, obtendrás un vídeo que reutiliza una estructura validada para contar tu propia historia. Mantén fiel la investigación y limpia la entrada de generación. Es el mismo lote de evidencia, pero con dos usos y dos lecturas.

La instrucción «extrae las estructuras realmente validadas de un conjunto de evidencias, excluye activamente las afirmaciones de competidores y aporta un contraejemplo para cada “estructura eficaz”» evalúa precisamente la capacidad de razonar bien y de cuestionarse a sí mismo. Es la misma división de responsabilidades que en lo que un modelo debe y no debe hacer en ingeniería inversa: el modelo destaca al generar hipótesis, pero es débil verificando hechos; esa verificación debe volver a tu evidencia y tus pruebas.

Qué modelo encaja en cada fase

El modelo de texto de este flujo no realiza una única tarea. Asume cuatro trabajos con requisitos muy distintos, además de la generación final de imagen y vídeo. Si utilizas un único modelo para todo, gastarás de más en las tareas por lotes o perderás precisión en el brief.

La capa del brief es la que merece una prueba independiente. Es la única fase donde cambiar de modelo modifica el resultado de forma visible. La prueba es concreta y es el único punto de este artículo que debes ejecutar por tu cuenta.

1. Toma de una ejecución del pipeline que haya terminado correctamente un conjunto de evidencia cualificada: ganchos de Top Ads, puntos destacados de curvas de retención, perfiles de creadores, oportunidad de keyword y algunas piezas orgánicas ganadoras.

2. Usa el mismo prompt de brief —reglas: emplear únicamente la estructura del activo; excluir explícitamente nombres de marca, precios, cuotas y afirmaciones de rendimiento; ofrecer una hipótesis de contraejemplo por cada «estructura eficaz»— y envíalo por separado a claude-opus-5 y gpt-5.6-sol.

3. Evalúa solo dos aspectos: si filtra al prompt de generación afirmaciones específicas del competidor —si las filtra, ha fallado— y si, cuando afirma que «esta estructura funciona», aporta un contraejemplo o confunde frecuencia con eficacia.

4. El desempeño en esos dos criterios debe determinar tu elección. Define directamente si el vídeo generado «copió el guion de un competidor» o «reutilizó una estructura validada».

Una sola ronda basta para ver la diferencia con más claridad que cualquier benchmark. La capa de extracción de campos por lotes, Sonnet, apenas requiere selección: sirve cualquiera que funcione. Y Kimi se elige para contexto largo porque evita que tengas que construir tu propio sistema de recuperación por fragmentos.

Generación de vídeo: enviar, esperar el estado final y conservar el task_id si hay timeout

Generar no es «hacer una llamada y recibir un vídeo». La generación de vídeo es un trabajo lento: lo envías, entra en una cola y debes consultar su estado hasta que alcance uno terminal para conocer el resultado. Esta fase tiene tres finales que deben mantenerse separados.

• Devolver tras el envío. El trabajo entra en cola, recibes un task_id y el estado es processing. Puedes continuar con otra cosa en lugar de esperar.

• Esperar al estado terminal. Consulta el estado hasta obtener completed o failed. Ese es el resultado que buscabas.

• Timeout en el límite. Si asignas un presupuesto de tiempo al polling y se agota antes de recibir un resultado, no debes descartar la tarea como fallida. Lo correcto es conservar el task_id, marcarla como «timeout, sin terminar» y permitir reanudar la espera más tarde con ese identificador, en vez de reenviarla. Reenviarla implica pagar una segunda vez.

El tercer caso es el más fácil de implementar mal. Muchas soluciones equiparan «el polling agotó el tiempo» con «la tarea falló», por lo que descartan un trabajo que sigue renderizando y simplemente tarda más de lo previsto. Distinguir entre «la tarea ha fallado» y «he dejado de esperar por ahora» es el núcleo de esta fase. Lo primero es un estado terminal. Lo segundo solo indica que interrumpiste la espera en esta ocasión. La tarea y su identificador siguen existiendo: retómala.

No generes cuando todo está vacío: saber cuándo no ejecutar es lo más valioso

Si juntas todas las restricciones anteriores, llegas a la regla más contraintuitiva y valiosa de este pipeline: cuando toda la evidencia está vacía, no envíes la generación.

Descubrimiento de demanda empty, validación comercial empty, selección de creadores empty. No existe una sola pieza primaria de evidencia cualificada en ninguno de los tres caminos. El brief queda en blocked, falla la puerta de disponibilidad de investigación del preflight de generación, todo el flujo se detiene en blocked y no se genera ni un solo fotograma.

Puede sonar a «no hizo nada», pero es la decisión más difícil de implementar correctamente y la que más dinero ahorra. Un pipeline que solo sabe avanzar, ante evidencia completamente vacía, recurrirá a un brief genérico, generará un vídeo que no conecta con nadie e informará de «éxito». Parece que ha funcionado. En realidad, ha gastado el coste de una generación sin información alguna y te ha dado una señal de éxito falsa.

La mitad del valor de un pipeline está en su capacidad para generar. La otra mitad, en saber cuándo no debe hacerlo. Lo primero es capacidad; lo segundo, disciplina. Y esa disciplina depende de los seis estados definidos antes. Sin distinguir entre empty y blocked, no dispones de una señal limpia de «todo vacío» sobre la que basar la decisión de no enviar.

Una sola clave para análisis y generación

El diseño del pipeline ya está resuelto. Lo que queda es una fricción puramente de ingeniería, precisamente el punto donde suele atascarse la mayoría.

Los modelos necesarios pertenecen a dos tipos de proveedores. Las capas de texto —leer evidencia, extraer campos, redactar el brief y realizar atribución— proceden de varios proveedores, mientras que la capa de generación pertenece a un servicio independiente de imagen y vídeo. Puedes integrar un SDK, un esquema de autenticación y un formato de errores para cada capa. O, como hace la mayoría, conformarte con un modelo para todo, gastar de más en los procesos por lotes, perder precisión en el brief y añadir después una plataforma de vídeo aparte. Para ahorrar trabajo de integración, rebajas todo el pipeline un nivel de calidad.

AIReiter elimina esa capa. Una clave, una interfaz compatible con OpenAI y las cuatro capas de texto detrás, cambiando solo el campo model del cuerpo de la solicitud. La generación de imagen y vídeo está en el mismo sitio y usa la misma clave, así que, cuando el brief esté listo, puedes probar a generarlo directamente en /chat.

# Write the brief: the reasoning tier
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "messages": [{"role": "user", "content": "<brief prompt + qualified evidence bundle>"}]
  }'

# Extract fields in bulk: change the model field, leave the rest
#   "model": "claude-sonnet-5"
# Stage attribution:      "model": "gpt-5.6-sol"
# Read long evidence at once: "model": "kimi-k3"

Si ya utilizas el SDK de OpenAI, apunta base_url a https://aireiter.com/api/v1 y no cambies nada más. Con el SDK de Anthropic, usa POST /api/v1/messages con la misma clave.

El precio encaja con la estructura de costes de este pipeline. La fase con más llamadas es la extracción de campos por lotes: decenas o cientos de activos, una llamada por cada uno, y la mayor parte del coste de texto. Claude, con un 30% de descuento, encaja justo ahí: Sonnet ejecuta el lote y Opus itera el brief, cubriendo ambas capas de Claude. La atribución se ejecuta con GPT-5.6 a mitad de precio. La lectura de evidencia extensa usa Kimi K3 con la misma clave. La generación es una partida de coste separada, facturada por ejecución, pero solo se activa cuando la puerta de evidencia pasa y realmente conviene crear un vídeo. La regla de «no enviar cuando todo está vacío» también ahorra dinero de generación.

• Obtener una clave API

• Pruébalo sin registrarte: introduce manualmente un conjunto de evidencia cualificada en el prompt del brief y comprueba si filtra nombres de marca y precios de competidores a la entrada de generación; cuando mantenga el comportamiento, automatízalo.

Conclusión

En el recorrido «de keyword a anuncio terminado», la ingeniería importante no está en el «anuncio terminado». Está en el tramo intermedio que transforma datos públicos en evidencia cualificada y, después, en un brief limpio.

Que ese tramo pueda operarse depende de tres factores. El resultado de cada fase debe encajar en seis estados, no en «éxito o fallo», para que empty, skipped, unavailable y blocked indiquen cada uno un siguiente paso claro. La evidencia debe agruparse y jerarquizarse, no sumarse, para evitar que el volumen de señales débiles oculte una señal fuerte. Y «puede producirse» debe separarse de «debería producirse» en dos puertas distintas, de modo que una evidencia totalmente vacía se detenga antes de la generación.

El modelo es una herramienta que realiza trabajo dentro de este flujo, no quien dirige el proceso. Lee evidencia, extrae campos, redacta el brief, explica la atribución y un modelo de generación crea el vídeo al final. Lo que determina «¿debemos continuar?» son siempre los estados y las puertas, no la confianza del modelo. Si montas este diseño y conectas las cuatro capas de texto y la generación en el sitio con una sola clave, el pipeline podrá funcionar de verdad desde la keyword hasta el anuncio terminado.