Cómo construir un motor de contenido con IA en Make para tus RRSS

Un motor de contenido con IA en Make es un sistema automatizado que convierte briefs estructurados en borradores listos para revisión o publicación, de forma repetible y sin intervención manual en los pasos intermedios. La principal diferencia radicá en convertir una automatización que funciona como infraestructura: produce con consistencia de voz, se adapta a múltiples formatos desde una sola fuente y mantiene al equipo enfocado en las decisiones que sí requieren criterio. El diferencial no está en la IA cómo ayuda, sino en la arquitectura que la rodea.

<<<Cómo los equipos de marketing pueden automatizar sus RRSS con Make>>>

De usar IA aislada a tenerla como un motor de contenido

Hay una diferencia operativa significativa entre un equipo que usa IA para escribir y un equipo que tiene un motor de contenido con IA.

En el primer caso, alguien abre ChatGPT, escribe un prompt desde cero, copia el resultado, lo pega en el documento y empieza a editar. Funciona para una pieza ocasional. No escala cuando hay quince publicaciones semanales entre posts, newsletters y descripciones de producto.

En el segundo caso, el proceso completo —desde el brief hasta la entrega del borrador al editor o la publicación directa— corre de forma automática cada vez que un ítem alcanza el estado correcto en el sistema de gestión del equipo. No hay prompts redactados a mano, no hay copiar y pegar, no hay notificaciones manuales.

La distinción clave es la siguiente: la IA resuelve la generación; Make resuelve la orquestación. Sin la capa de orquestación, la IA sigue siendo una herramienta de uso individual. Con ella, se convierte en un componente de un sistema productivo.

Este artículo se centra en cómo diseñar ese sistema: qué decisiones tomar en cada capa, cómo construir el flujo base en Make y, sobre todo, cómo lograr que el contenido generado sea consistente con la voz de marca en lugar de texto genérico.

Arquitectura del motor: las cuatro capas de decisión

Un motor de contenido bien diseñado no es una automatización lineal simple. Tiene cuatro capas, cada una con decisiones de diseño propias.

Capa 1: Fuente de brief

Es el punto de entrada de todo el sistema. Puede ser un tablero en monday.com, una base de datos en Notion, un formulario de Google Forms o cualquier herramienta donde el equipo ya registre sus ideas de contenido.

La decisión de diseño en esta capa es qué campos debe tener el brief para que la IA produzca un borrador útil sin intervención adicional. Como mínimo: tipo de pieza, canal de destino, tema central, audiencia objetivo, tono deseado y longitud aproximada. Cuanto más estructurado esté el brief, menos trabajo correctivo habrá después.

Make actúa aquí como oyente: monitorea la fuente de datos y dispara el flujo cuando un ítem alcanza un estado específico, por ejemplo, "Listo para producción". Nada corre hasta que ese estado se activa, lo que mantiene el control editorial en manos del equipo.

Capa 2: Orquestador (Make)

Make toma los datos del brief, los convierte en variables y los distribuye a los pasos siguientes. Esta capa incluye la lógica del flujo: qué hacer si el canal es LinkedIn versus si es un artículo de blog, qué sucede si la respuesta de la API falla, a quién notificar según el tipo de pieza.

El componente central aquí es el módulo Router de Make, que permite bifurcar el flujo según condiciones. Un solo brief puede derivar hacia distintas rutas: una para generar un post de LinkedIn, otra para generar el subject line de un email, otra para adaptar el mismo contenido a una descripción de producto.

Capa 3: Generación con LLM

Esta capa es la API del modelo de lenguaje. Make envía el prompt estructurado mediante un módulo HTTP y recibe el borrador como texto. El modelo puede ser GPT-4o, Claude o cualquier otro accesible por API REST.

La decisión crítica en esta capa no es qué modelo usar, sino cómo está construido el prompt. Este punto merece una sección propia y se desarrolla más adelante.

Capa 4: Distribución

El borrador generado llega a su destino: un documento de Google Docs, un borrador en HubSpot, un draft en WordPress, o simplemente una notificación con el texto adjunto en Slack para que el editor lo revise.

La decisión de diseño aquí es si el flujo incluye publicación directa o un paso de revisión humana intermedio. No hay una respuesta universal: depende del tipo de contenido, el riesgo editorial y la madurez del sistema. Lo recomendable es empezar con revisión humana obligatoria y habilitar la publicación directa solo para formatos de bajo riesgo una vez que el motor demuestre consistencia.

<<<Del brief a la publicación: flujo automatizado end-to-end con Make e IA>>>

Flujo base en Make: los cinco pasos esenciales

Sin entrar en el paso a paso detallado que ya cubre la documentación de Make, estos son los cinco módulos que estructuran el flujo base:

1. Trigger — Watch Items (monday.com) o Watch Database Items (Notion) activado por cambio de estado.
2. Construcción del prompt — módulo de texto o Set Variable donde se arma el prompt dinámico con las variables del brief.
3. Llamada HTTP a la API del LLM — POST al endpoint del modelo con el prompt como body.
4. Bifurcación por canal — Router que dirige el output según el tipo de pieza.
5. Entrega — Crear documento en Google Docs, crear borrador en HubSpot, o enviar notificación en Slack con el texto generado.

La potencia real aparece cuando se añade lógica condicional entre los pasos: reintentos automáticos si la API falla, rutas distintas según el canal, acumulación de múltiples piezas en un solo documento de revisión semanal.

Prompts que producen voz de marca, no texto genérico

Este es el diferenciador real entre un motor de contenido y una automatización que genera texto mediocre de forma masiva. La calidad del output depende, casi en su totalidad, de la calidad del prompt.

System prompt: el contrato permanente con el modelo

El system prompt es la instrucción que se envía en cada llamada a la API y que define el comportamiento base del modelo. No cambia con cada brief: es el marco estable que establece quién es la marca, cómo habla y qué no hace.

Un system prompt efectivo para un motor de contenido incluye:

• Rol y contexto: "Sos redactor de contenido B2B para [marca]. Tu audiencia son directores de operaciones y marketing de empresas medianas."
• Voz de marca: tres a cinco atributos concretos con ejemplos de qué significa cada uno. No "profesional y cercano", sino "directo sin ser frío, técnico sin jerga innecesaria, orientado a consecuencias prácticas".
• Lo que no debe aparecer: frases de relleno, metáforas gastadas, llamadas a la acción genéricas, tecnicismos sin contexto.
• Formato de respuesta esperado: si el output debe incluir título, subtítulo, cuerpo y CTA por separado, especificarlo con etiquetas o delimitadores claros para que Make pueda parsear cada parte de forma independiente.

Few-shot prompting: mostrar, no solo describir

Las instrucciones en lenguaje natural tienen límites. Lo que el modelo entiende mejor es el ejemplo directo. El few-shot prompting consiste en incluir en el prompt dos o tres ejemplos del output esperado, tomados de piezas reales del equipo que sí representan la voz de marca.

Con dos o tres ejemplos bien elegidos, el modelo calibra su output de forma notablemente más precisa que con cualquier descripción abstracta de estilo.

Variables dinámicas: el brief como input estructurado

El prompt no debe ser estático. En Make, cada campo del brief se convierte en una variable que se inyecta en el prompt en el momento de la ejecución. El resultado es un prompt que cambia con cada ítem pero mantiene siempre la misma estructura y el mismo system prompt.

Un ejemplo de prompt dinámico sería:

Redactá un para sobre el siguiente tema: . Audiencia: . Tono: . Extensión: palabras. Incluí el siguiente ángulo: .

El campo angulo_editorial es especialmente importante: es donde el equipo introduce el criterio que la IA no puede deducir por sí sola —la perspectiva original, el dato concreto, el caso de uso específico que hace que la pieza no sea intercambiable con cualquier otra sobre el mismo tema.

Qué no delegar a la IA: el límite operativo del motor

Un motor de contenido bien diseñado acelera la producción. No reemplaza el juicio editorial. Hay tres tipos de decisiones que deben permanecer del lado humano, sin excepción.

• Ángulos originales. La IA genera texto a partir de patrones. No tiene acceso al contexto del mercado de la empresa, a las conversaciones internas del equipo comercial, a lo que dijo un cliente en una llamada la semana pasada. El ángulo que hace que una pieza sea relevante y diferente lo define siempre una persona, antes de activar el motor.

• Decisiones editoriales de fondo. Qué temas cubrir, cuándo publicar sobre ciertos asuntos, qué evitar por razones de posicionamiento o sensibilidad de mercado: son decisiones estratégicas que no pueden automatizarse sin riesgo.

• Fact-checking. Los LLMs actuales pueden confundir datos, fechas o atribuciones. Cualquier pieza que incluya estadísticas, nombres propios, referencias a productos o afirmaciones técnicas específicas requiere verificación antes de publicarse.

Este proceso automatizado esta pensado para eliminar fricción operativa, no para reducir el estándar de calidad. Usado correctamente, libera al equipo del trabajo repetitivo y le permite concentrar su tiempo en lo que sí requiere criterio: definir qué vale la pena decir y cómo decirlo de forma que importe.

Siguiente paso

Si el equipo ya trabaja con monday.com o Notion como tablero de gestión de contenido, el flujo base en Make puede estar operativo en menos tiempo del que parece. El punto de partida no es la automatización completa: es un primer escenario que conecte el tablero con la API de un LLM y entregue el borrador en Google Docs.

Desde ahí, el motor se extiende de forma incremental: se añaden canales, se refina el system prompt con ejemplos reales, se habilita la publicación directa para los formatos que ya demostraron consistencia.