Cómo construimos Vaton: arquitectura de una plataforma de marketing con IA

Construir una plataforma de estrategia de marketing con IA no consiste en conectar un modelo a una caja de texto. El reto real es conseguir que varios procesos entiendan un negocio, investiguen su mercado, conserven el contexto correcto y produzcan decisiones que una persona pueda verificar y ejecutar.

Ese es el problema técnico y de producto detrás de Vaton. En la introducción a Vaton explicamos qué hace la plataforma para agencias y pequeños negocios. Aquí muestro el otro lado desde mi trabajo como cofundador y desarrollador, sin revelar prompts propietarios, pipelines internos ni decisiones sensibles de infraestructura.

Resumen técnico

• Una estrategia necesita varios procesos coordinados, no una sola respuesta de IA.
• Cada proyecto debe conservar contexto, datos, permisos e historial separados.
• Los resultados deben ser estructurados, editables, trazables y verificables.
• Ahorrar tiempo exige conectar investigación, estrategia, planeación y ejecución.
• Calidad, velocidad y costo deben administrarse por tarea.
• La automatización necesita estados claros y aprobaciones configurables.

Una estrategia de marketing no es una sola respuesta de IA

Una estrategia SEO o de contenidos puede requerir entender el negocio, identificar públicos, investigar competidores, clasificar intención de búsqueda, organizar temas, priorizar acciones, crear estructuras y revisar consistencia.

Cada tarea utiliza información distinta y produce resultados que afectan a la siguiente. Por eso, el problema se parece más a una orquestación de procesos de IA que a la generación de texto.

No basta con obtener una respuesta convincente. El sistema tiene que entregar el contexto adecuado a cada etapa, respetar dependencias, conservar resultados intermedios y evitar contradicciones. Una recomendación de contenido, por ejemplo, no debería ignorar una restricción comercial aprobada durante el onboarding.

Construir contexto útil y actualizable

Un modelo puede redactar con seguridad aunque no comprenda suficientemente bien a una empresa. Eso funciona en una demostración, pero es peligroso en un producto estratégico: una recomendación puede sonar profesional y seguir siendo irrelevante.

Vaton necesita trabajar con capas de contexto, entre ellas:

• identidad, posicionamiento y propuesta de valor;
• productos, servicios y mercados;
• públicos, competidores y objetivos;
• restricciones y afirmaciones permitidas;
• sitio y contenidos existentes;
• investigación y decisiones anteriores.

Además, ese contexto cambia. Una empresa puede lanzar un servicio, retirar una oferta o dirigirse a otro segmento. La arquitectura debe permitir actualizaciones sin perder la continuidad ni obligar al usuario a comenzar de nuevo.

El reto no es almacenar más texto, sino seleccionar la información que corresponde a cada tarea y distinguir hechos, hipótesis, recomendaciones y decisiones aprobadas.

Multiproyecto significa aislamiento, no solo organización

Para una agencia, administrar varios clientes puede parecer una cuestión de carpetas. En una aplicación con IA, implica garantizar que cada ejecución utilice únicamente el contexto autorizado del proyecto activo.

El aislamiento afecta:

• datos y archivos;
• investigaciones y estrategias;
• instrucciones y contenidos;
• integraciones y credenciales;
• permisos y aprobaciones;
• historial y registros de actividad.

Al cambiar de cuenta, la plataforma también debe cambiar por completo los competidores, el tono, los objetivos y las fuentes disponibles. Una recomendación que mezcla información entre clientes es un fallo de calidad y también un riesgo de seguridad.

Por eso, el aislamiento y el control de acceso deben formar parte del modelo del sistema desde el inicio, no añadirse al final como una capa visual.

La IA debe producir trabajo verificable

Existe una diferencia importante entre una salida que parece correcta y una que puede utilizarse profesionalmente. Un texto fluido todavía puede contener suposiciones no confirmadas, temas irrelevantes, prioridades incorrectas o afirmaciones demasiado generales.

Cada resultado debería permitir responder:

• ¿qué información del proyecto se utilizó?;
• ¿qué evidencia o supuesto sostiene la recomendación?;
• ¿qué objetivo intenta resolver?;
• ¿cómo se relaciona con el resto de la estrategia?;
• ¿qué debería hacer el usuario después?;
• ¿necesita revisión antes de ejecutarse?

La supervisión humana sigue siendo esencial para decisiones estratégicas. El propósito de la IA es reducir el trabajo repetitivo para que la persona revise lo que realmente requiere criterio.

Reducir tiempo exige rediseñar el proceso completo

El objetivo de ahorrar hasta un 90 % del tiempo de preparación en determinados flujos SEO no proviene de escribir más rápido. Proviene de reducir una cadena de tareas: recopilar información, ordenar datos, repetir investigaciones, clasificar oportunidades, preparar entregables y transformar análisis en planes.

Automatizar un solo paso rara vez cambia la operación. La investigación debe alimentar la estrategia; la estrategia, la planeación; y la planeación, la ejecución.

Técnicamente, esto implica mantener estados, dependencias y resultados intermedios. También exige evitar trabajo innecesario: si una investigación sigue vigente, el sistema no debería repetirla completa cada vez que se solicita un artículo.

La reducción real depende del alcance, la información disponible, las aprobaciones y las integraciones de cada proyecto. El objetivo es evitar que el usuario reconstruya el mismo contexto, no eliminar la revisión profesional.

Resultados editables, estructurados y reutilizables

Una estrategia no debería quedar atrapada dentro de una conversación. Debe poder revisarse, modificarse y alimentar otras partes del proyecto.

Una investigación puede apoyar varias decisiones. Una decisión aprobada puede actualizar un plan. Un plan puede producir múltiples briefs o contenidos. Para conservar esa relación, el sistema necesita distinguir entre:

• información proporcionada por el usuario;
• datos obtenidos durante la investigación;
• recomendaciones generadas;
• decisiones aprobadas;
• contenido listo para utilizar;
• elementos pendientes de revisión.

Esta estructura permite corregir un elemento sin rehacer manualmente todo lo que lo rodea. También hace visible qué cambió, quién lo aprobó y qué entregables podrían quedar desactualizados.

Publicar en sitios reales añade otra capa

Generar contenido no equivale a publicarlo. Un sitio puede usar un CMS, un repositorio o una estructura personalizada. Las rutas, imágenes, plantillas, metadatos y flujos de revisión varían incluso entre proyectos con el mismo framework.

Una integración de publicación necesita conocer el contrato de cada sitio:

• dónde se almacenan los artículos y las imágenes;
• qué formato y campos son obligatorios;
• qué convenciones de nombres existen;
• qué validaciones debe pasar el contenido;
• quién revisa y aprueba;
• si el destino permite borradores o publicación directa.

El reto es diseñar adaptadores flexibles sin convertir cada nuevo sitio en una integración completamente personalizada. Este mismo artículo es un buen ejemplo: para incorporarlo fue necesario respetar colecciones bilingües, frontmatter, rutas, imágenes y metadatos del proyecto.

Automatización configurable y estados comprensibles

No todas las cuentas aceptan el mismo nivel de autonomía. Una puede permitir publicación automática; otra puede exigir revisión interna, aprobación del cliente o validación legal.

Por eso, cada acción importante necesita un estado visible, por ejemplo:

• pendiente;
• en proceso;
• lista para revisión;
• aprobada o rechazada;
• publicada;
• con error.

La interfaz debe mostrar qué ocurre, qué terminó y qué requiere atención. Sin esa claridad, un proceso largo se siente impredecible aunque la infraestructura funcione correctamente.

Los errores de IA no se resuelven solo con prompts

Los prompts importan, pero son una pieza del sistema. La calidad también depende de los datos disponibles, la selección de contexto, la secuencia de tareas, las restricciones, la validación, el modelo elegido, la recuperación ante errores y la revisión humana.

Un prompt puede funcionar en varias pruebas y fallar cuando cambia la industria, el idioma, el volumen de información o la claridad de los datos de entrada. La plataforma debe detectar faltantes, manejar incertidumbre y evitar presentar hipótesis como hechos.

Esto requiere evaluaciones sobre el flujo completo, no únicamente sobre respuestas aisladas.

Calidad, velocidad y costo compiten entre sí

En un prototipo puede ser aceptable ejecutar siempre el proceso más avanzado. En un producto real, cada tarea tiene un costo y un tiempo de respuesta que afectan la experiencia y la capacidad de escalar.

El modelo más potente no es necesario para todas las operaciones, y la respuesta más rápida no siempre tiene la profundidad suficiente. Parte de la arquitectura consiste en asignar el proceso adecuado a cada tarea, reutilizar resultados válidos y mostrar progreso mientras se completan trabajos largos.

La optimización no busca la respuesta más barata en cualquier circunstancia, sino la calidad necesaria con una latencia y un costo sostenibles.

Observabilidad y trazabilidad

En un sistema tradicional, una ejecución suele fallar de manera explícita. En uno basado en IA, puede terminar técnicamente bien y producir un resultado deficiente. Por eso, la observabilidad debe cubrir tanto la ejecución como la calidad de la salida.

Necesitamos poder analizar qué contexto recibió cada proceso, dónde apareció una contradicción, qué modificó el usuario, qué versión produjo el resultado y qué acciones fueron aprobadas.

La trazabilidad ayuda a depurar y mejorar el producto. También genera confianza: una agencia debe poder relacionar una recomendación con la información de su cliente sin necesitar acceso a los mecanismos internos del sistema.

Seguridad y permisos desde el diseño

Al conectar sitios, repositorios y cuentas de clientes, la seguridad deja de ser un detalle. Vaton debe aplicar principios como permisos mínimos, separación por proyecto, protección de credenciales, registro de acciones, controles para publicar y revocación de accesos.

La automatización solo es útil cuando el usuario conserva control sobre sus datos y canales. Una integración capaz de publicar necesita límites más claros que una herramienta que únicamente prepara un borrador.

Ser cofundador y desarrollador exige trabajar en dos niveles

Mi trabajo en Vaton alterna entre producto y arquitectura. Como cofundador, tengo que decidir qué problema vale la pena resolver y qué función debería priorizarse. Como desarrollador, debo convertir esas decisiones en sistemas consistentes.

Una decisión pequeña de interfaz puede cambiar el modelo de estados o permisos. Una solución técnica elegante puede fracasar si obliga a la persona usuaria a comprender conceptos innecesarios. Construir el producto exige equilibrar ambos lados continuamente.

La beta también desarrolla el sistema

La beta no sirve solo para encontrar errores visuales. Nos permite observar cómo una agencia prepara una estrategia, presenta resultados, corrige un entregable y aprueba contenido.

Los primeros usuarios ayudan a identificar qué tareas consumen más tiempo, qué datos ya tienen, qué resultados necesitan editar, qué integraciones importan y qué nivel de automatización consideran seguro.

En una aplicación con IA no basta con que una salida sea técnicamente correcta. Tiene que integrarse en el trabajo real de la persona que la revisará y utilizará.

Preguntas frecuentes sobre la arquitectura de Vaton

¿Por qué una estrategia no puede generarse con un solo prompt?

Porque combina tareas dependientes —contexto, investigación, priorización, planeación y validación— que necesitan información y controles distintos.

¿Cuál es el principal reto de una plataforma multiproyecto con IA?

Mantener el contexto, los datos, los permisos y el historial de cada proyecto completamente aislados mientras se coordinan procesos reutilizables.

¿Los errores de IA se resuelven únicamente con mejores prompts?

No. La calidad también depende de los datos, la selección de contexto, la secuencia de tareas, la validación, la observabilidad y la revisión humana.

¿Por qué Vaton mantiene aprobaciones humanas?

Porque una respuesta puede parecer correcta y aun así contener supuestos o prioridades incorrectas. Los puntos de aprobación permiten adaptar la automatización al riesgo de cada proyecto.

Construir Vaton significa transformar una tecnología flexible y variable en una herramienta clara, controlable y útil. La arquitectura existe para que agencias y negocios puedan investigar, decidir y ejecutar con menos fricción. Para conocer la experiencia que esa infraestructura busca ofrecer, vuelve a qué es Vaton y cómo ayuda a sus usuarios.