---
title: "Architect: arquitectura de marketing con IA y modelo operativo"
description: "La arquitectura de marketing con IA conecta flujos de trabajo, conocimiento, tecnología, gobernanza, roles, medición y titularidad antes de la implantación."
url: "https://kodokalabs.com/es/framework-marketing-ia/arquitectura-y-modelo-operativo/"
language: es
published: 2026-08-07
updated: 2026-09-14
---

# Architect: arquitectura de marketing con IA y modelo operativo

## Architect: diseñar el modelo operativo del marketing con IA

Architect es la segunda fase del [kōdōkalabs Transformation System](../ai-marketing-framework.md). Convierte los hallazgos validados de Diagnose en un modelo operativo de destino, especificaciones de flujos de trabajo, controles de gobernanza, requisitos de conocimiento, decisiones de tecnología, un diseño de [medición](./ai-marketing-measurement-and-value-realization.md) y un backlog de implantación.

## Resumen ejecutivo

Architect existe porque la mayoría de las organizaciones que fracasan en la transformación del marketing con IA no fracasan en Diagnose. Fracasan en el trecho que va de saber qué falla a construir algo que funcione de verdad. Ese trecho se llena con configuración de herramientas cuando debería llenarse con diseño: decisiones explícitas sobre modelo operativo, capacidad de decisión, responsabilidad sobre los flujos de trabajo, arquitectura del conocimiento, integración tecnológica, gobernanza, medición y traspaso de la titularidad. La arquitectura es infraestructura de decisiones, no una presentación. Esta página explica las ocho capas de diseño que componen una arquitectura completa, cómo se reparten en ella las responsabilidades entre personas e IA, qué debe entregar Architect antes de que pueda empezar Build y los fallos que convierten la arquitectura en un costoso ejercicio de documentación que nadie utiliza.

## Ideas clave

- La arquitectura es un conjunto de decisiones de diseño explícitas, no un diagrama del estado futuro.
- Ocho capas conectadas abarcan desde el alcance del negocio hasta el traspaso de la titularidad: omitir una deja una laguna que Build descubrirá por las malas.
- Cada decisión relevante se documenta con su justificación, no solo con su conclusión.
- Existe una Minimum Viable Architecture para pilotos controlados: no todas las organizaciones necesitan documentación a escala corporativa desde el primer día.
- Architect es distinto de la metodología de entrega [Strategic Architecture](../../en/methodology/ai-marketing-strategic-architecture.md) (véase la [metodología](../../en/methodology.md)), que especifica cada línea de trabajo dentro del modelo operativo que define Architect.

## ¿Qué es la fase Architect?

Architect toma lo que Diagnose ha establecido como evidencia y lo convierte en un diseño. Si Diagnose responde a «qué es cierto de nuestra situación actual», Architect responde a «cómo debería ser la situación de destino, con el detalle suficiente para poder construirla, gobernarla, medirla y, con el tiempo, gestionarla con el propio equipo del cliente». El resultado no es una declaración de visión. Es un conjunto de decisiones documentadas e interconectadas que Build puede implantar directamente.

## Por qué la arquitectura va antes que la automatización

Con frecuencia, las organizaciones pasan del [diagnóstico](./ai-marketing-diagnosis-and-readiness-assessment.md) directamente a configurar herramientas y se saltan por completo el paso del diseño. El resultado es un patrón reconocible: automatizaciones desconectadas que resuelven cada una un problema muy concreto sin encajar en un conjunto coherente, responsabilidades poco claras sobre quién se ocupa de qué cuando algo falla, insumos de conocimiento débiles porque nadie diseñó qué debería saber realmente el sistema de IA, revisiones inconsistentes porque la gobernanza no se incorporó desde el principio y métricas que se añaden después del despliegue porque la medición no formaba parte del diseño original.
La arquitectura cierra esa brecha al hacer explícitas las relaciones entre estas piezas antes de la implantación y no cuando algo ya ha salido mal en producción.

## Lo que Architect necesita de Diagnose

Architect parte del Decision Package de Diagnose: el registro de evidencias, el perfil de madurez, la cartera de oportunidades priorizada y la decisión explícita sobre qué merece un diseño. Si falta alguno de estos elementos o está incompleto, lo primero que debe hacer Architect es volver a Diagnose para resolver esa carencia concreta y no diseñar sobre una suposición. Una arquitectura construida sobre un diagnóstico incompleto suele dar un diseño muy bien documentado para el problema equivocado.

## Las ocho capas de la arquitectura de marketing con IA

![Diagrama de la arquitectura de marketing con IA en ocho capas apiladas, desde el resultado de negocio y el alcance hasta la capacitación y el traspaso de la responsabilidad](https://kodokalabs.com/assets/media/2026/08/kodokalabs-framework-architect-phase-eight-layer-ai-marketing-architecture.webp)

La **Architecture Decision Stack** de kōdōkalabs organiza el trabajo de diseño en ocho capas conectadas. Es una metodología propia de kōdōkalabs, no un framework de arquitectura estandarizado externamente. En cada capa, el trabajo de diseño especifica los insumos necesarios, las decisiones de diseño propiamente dichas, los resultados, quién las aprueba y de qué depende Build en esa capa.

### Resultado de negocio y alcance

¿A qué resultado de negocio debe servir esta arquitectura y qué queda expresamente fuera de su alcance? Un diseño sin límites de alcance claros tiende a expandirse hasta intentar resolver a la vez todos los problemas que sacó a la luz Diagnose, lo que por lo general significa que no resuelve bien ninguno.

### Modelo operativo y capacidad de decisión

¿Quién decide qué, a qué nivel y con qué autoridad? Esta capa define la estructura organizativa dentro de la cual opera el resto de la arquitectura: sin ella, las capas siguientes no tienen un responsable claro.

### Flujos de trabajo y responsabilidad entre personas e IA

¿Qué flujos de trabajo concretos se rediseñan y cómo se reparte la responsabilidad entre el criterio humano y la asistencia de la IA en cada uno? En la sección específica de más abajo se explica el modelo que aplica esta capa.

### Arquitectura del conocimiento y de los datos

¿A qué conocimiento necesita acceder el sistema, con qué estructura, con qué controles de acceso y cómo se mantiene actualizado? Esta capa determina si el trabajo asistido por IA del sistema resultante será fiable o producirá, con total aplomo, errores que suenan verosímiles.

### Arquitectura de tecnología y de integración

¿Qué [herramientas](../../en/tools.md) y sistemas intervienen, cómo se conectan entre sí y qué limitaciones técnicas se derivan de ello? La arquitectura trata las herramientas concretas como componentes sustituibles al servicio del diseño, y no al revés.

### Gobernanza, privacidad, seguridad y controles de calidad

¿Qué requisitos de revisión, clasificaciones de riesgo y controles de calidad se aplican a este flujo de trabajo y en qué punto del proceso se producen? Véase «Gobernanza desde el diseño» más abajo.

### Diseño de la medición y del valor

¿Cómo se medirá realmente el rendimiento de este flujo de trabajo cuando esté en funcionamiento y frente a qué punto de partida? La medición que se diseña después de la implantación tiende a medir lo que es cómodo de medir y no lo que de verdad importa.

### Capacitación, documentación y traspaso de la titularidad

¿Qué necesita saber y saber hacer el equipo del cliente para manejar este sistema con autonomía y qué documentación hace posible ese traspaso? Esta capa conecta el diseño de Architect con la fase [Enable](./ai-marketing-enablement-and-capability-transfer.md) que sigue a Build.

## Cómo se diseñan las responsabilidades de las personas y de la IA

En la capa de flujos de trabajo y responsabilidad entre personas e IA, Architect aplica el [Human + AI Execution Model](../ai-marketing-framework.md) y la lógica de revisión basada en el riesgo establecidos antes en el kōdōkalabs Transformation System: el trabajo se reparte entre las categorías de responsabilidad humana, asistido por IA, ejecutado por IA bajo supervisión y prohibido o restringido en función del riesgo, la reversibilidad, la sensibilidad de los datos, la exposición de la marca y las consecuencias financieras, y no de lo que sea técnicamente posible automatizar. Que una tarea se pueda automatizar no hace que automatizarla sea la decisión de diseño correcta; eso depende del perfil de riesgo que Architect evalúe para cada flujo de trabajo concreto.

## Requisitos de la arquitectura de los flujos de trabajo

Cada especificación de flujo de trabajo que se elabora durante Architect incluye: desencadenantes (qué lo pone en marcha), insumos (qué necesita para funcionar), pasos (la secuencia real de trabajo), responsables (quién responde en cada paso), sistemas (qué herramientas intervienen), conocimiento (de qué información se nutre el flujo de trabajo), excepciones (qué ocurre cuando no se aplica el camino habitual), aprobaciones (dónde se exige validación humana), resultados (lo que produce el flujo de trabajo), evidencias (cómo se verifican la calidad y la exactitud) y métricas (cómo se mide el rendimiento). Una especificación a la que le falte cualquiera de estos campos está incompleta, por detallado que sea el resto. Las excepciones y las aprobaciones son los campos que más se omiten y cuya ausencia más problemas da cuando el flujo de trabajo llega al uso real.

## Arquitectura del conocimiento y del contexto

Esta capa decide de qué base de conocimiento estructurada se nutrirán los flujos de trabajo rediseñados, quién se encarga de mantenerla actualizada, qué controles de acceso se aplican y cómo se resuelven las lagunas o los conflictos en ese conocimiento. Una arquitectura de flujos de trabajo puede estar muy bien diseñada sobre el papel y fracasar en la práctica si la capa de conocimiento que tiene debajo está incompleta, desactualizada o estructurada de una forma de la que los sistemas de IA no pueden recuperar información con fiabilidad.

## Gobernanza desde el diseño

La gobernanza se incorpora a la arquitectura en el momento en que se especifica cada flujo de trabajo y no se añade después como una revisión de cumplimiento. Es decir, la clasificación de riesgo de cada flujo de trabajo, el nivel de revisión exigido y su punto de aprobación se definen como parte de su especificación, de acuerdo con el Marketing AI Governance Control Stack, y no se descubren más tarde, cuando el área jurídica o de seguridad pregunta cómo trata un riesgo concreto un flujo de trabajo que ya está construido.

## Medición antes de la implantación

Cada especificación de flujo de trabajo incluye cómo se medirá su rendimiento antes de que se construya, con conexión directa con el punto de partida establecido en Diagnose. Diseñar la medición después de la implantación suele dar métricas elegidas porque son fáciles de extraer del sistema que haya a mano, y no métricas que respondan de verdad a si el flujo de trabajo crea el valor para el que fue diseñado: un problema que la fase Measure da por evitado en Architect.

## Entregables de la arquitectura

Architect necesita un conjunto concreto de entregables antes de que pueda empezar Build: un modelo operativo de destino, especificaciones de flujos de trabajo para cada flujo rediseñado, una matriz de responsabilidades, un mapa del conocimiento, un plano de integración, una matriz de gobernanza, un plan de medición, un backlog de implantación priorizado, un alcance de piloto definido, un plan de documentación y un plan de transferencia de capacidades. Cada entregable tiene una persona concreta que lo aprueba: una arquitectura no se considera completa cuando está escrita, sino cuando la aprueban las personas que responderán de lo que produzca.
El backlog de implantación priorizado merece una atención especial porque es donde la arquitectura se conecta con la secuencia. No todos los flujos de trabajo especificados en la arquitectura tienen que construirse a la vez: el backlog ordena los flujos rediseñados combinando valor, riesgo, dependencias y grado de preparación, y da a Build un punto de partida defendible en lugar de una lista sin distinciones de todo lo que abarca la arquitectura. Un backlog que no distingue «esto primero» de «esto en algún momento» suele dar una [fase Build](./build-an-ai-marketing-system-with-governed-workflows.md) que se atasca por intentar hacerlo todo a la vez o que elige un punto de partida arbitrario, desconectado de la prioridad real.

## Revisión de la arquitectura y puntos de aprobación

Antes de que empiece Build, la arquitectura pasa por la revisión de los roles con interés en lo que se diseña: el patrocinador ejecutivo confirma que el diseño sigue sirviendo al resultado de negocio original; los responsables de gobernanza confirman que la clasificación de riesgos y los requisitos de revisión son adecuados; las personas que gestionan los flujos de trabajo y acabarán operando el sistema confirman que su equipo puede manejar de verdad el diseño, y no solo que es técnicamente elegante; y una persona con la aprobación final da el visto bueno al paquete completo. Omitir cualquiera de estas revisiones suele hacer que las inquietudes de la perspectiva omitida afloren más tarde, durante Build, cuando atenderlas sale más caro.
Estas revisiones se ordenan de forma deliberada y no se resuelven en una sola reunión de aprobación conjunta. Si la revisión de gobernanza precede a la de quienes gestionan los flujos de trabajo, las inquietudes de riesgo y de cumplimiento se atienden mientras el diseño aún es flexible, y no cuando quienes lo van a operar ya se han hecho a una versión que la gobernanza exige después cambiar. Si la revisión de quienes gestionan los flujos de trabajo se hace antes de la aprobación final, la persona que aprueba firma un diseño ya confirmado como realmente manejable y no solo correcto en teoría.

## Criterios de salida de Architect

Architect se da por terminada cuando cada una de las ocho capas tiene decisiones documentadas con responsables de aprobación con nombre, el Architecture Decision Record recoge la justificación de cada decisión relevante, existen especificaciones para todos los flujos de trabajo incluidos en el alcance y Build tiene todo lo que necesita para empezar la implantación sin tener que tomar decisiones de diseño sobre la marcha. Si Build se encuentra tomando por primera vez una decisión de diseño a mitad de la implantación, es señal de que Architect no estaba realmente terminada.
Esto no significa que haya que anticipar todos los casos límite posibles antes de que empiece Build: una Minimum Viable Architecture para un piloto controlado es una forma legítima de cumplir los criterios de salida con un nivel de detalle más ligero. Lo que sí significa es que las decisiones que se hayan tomado, por mínimo que sea su alcance, están completas y documentadas para ese alcance, y no a medio especificar y a la espera de que Build las complete de manera informal.

## Fallos habituales de la arquitectura

- **Diseño guiado por la herramienta:** diseñar en torno a las capacidades de una herramienta concreta y no en torno al resultado de negocio y a los requisitos de los flujos de trabajo, para después justificar a posteriori la elección. Es el camino más directo de vuelta al patrón que Architect existe para evitar: el mismo enfoque que empieza por la herramienta, que Diagnose debía cortar, reaparece una fase más tarde bajo el nombre de «arquitectura».
- **Titularidad sin definir:** un diseño que especifica lo que debería ocurrir sin especificar quién responde cuando no ocurre. Las lagunas de titularidad suelen ser invisibles en el propio documento de arquitectura y solo se ven la primera vez que un flujo de trabajo da un resultado inesperado y nadie es claramente la persona que lo resuelve.
- **Sobreingeniería:** construir documentación y gobernanza a escala corporativa para un flujo de trabajo que solo necesitaba una Minimum Viable Architecture para un piloto controlado. La sobreingeniería tiende a ralentizar la entrega sin reducir el riesgo en proporción, porque la documentación añadida rara vez cubre escenarios que la versión más ligera no habría detectado.
- **Falta de gestión de excepciones:** una especificación que cubre con detalle el camino habitual pero no aborda nunca qué ocurre cuando algo queda fuera de él. En la práctica, una parte considerable del volumen real de un flujo de trabajo suelen ser excepciones y no el camino feliz documentado. Una arquitectura que solo especifica el camino feliz deja sin diseñar justo los casos de mayor fricción.
- **Movimiento oculto de datos:** conocimiento o datos que circulan entre sistemas de maneras que la arquitectura no documenta y que, por tanto, la revisión de gobernanza no puede evaluar. Es especialmente habitual con herramientas de IA que envían contexto a una API de terceros como parte de su funcionamiento normal, de una forma que la especificación del flujo de trabajo nunca menciona expresamente.
- **Evidencias débiles:** decisiones de diseño justificadas por afirmación y no por las evidencias que Diagnose produjo de verdad. Una decisión de diseño que no se puede rastrear hasta un hallazgo de Diagnose, o hasta una hipótesis claramente señalada y pendiente de validar, es una decisión tomada por preferencia de quien diseña y no por evidencias.
- **Sin punto de partida de medición:** pasar a Build sin haber definido cómo se medirá el rendimiento del flujo de trabajo resultante, lo que da de forma fiable el mismo problema de métricas a posteriori que Diagnose se diseñó para evitar a escala de la organización.
- **Un diseño que el equipo del cliente no puede manejar:** una arquitectura técnicamente sólida pero que da por hecho un nivel de sofisticación técnica continuada que el equipo real del cliente no tiene y que Enable no se ha dimensionado para construir. Un diseño elegante que nadie del lado del cliente puede mantener de forma autónoma no es una arquitectura lograda según el estándar de kōdōkalabs, por bien que funcione el primer día.

## De Architect a Build

Architect entrega a Build el conjunto completo de entregables: modelo operativo de destino, especificaciones de flujos de trabajo, matriz de responsabilidades, mapa del conocimiento, plano de integración, matriz de gobernanza, plan de medición, backlog priorizado, definición del piloto, plan de documentación y plan de transferencia de capacidades. Build implanta lo que Architect ha especificado. No es el lugar donde se toman por primera vez las decisiones de diseño que faltan.

## Preguntas frecuentes sobre la fase Architect

### ¿Qué hay que diseñar antes de construir un sistema de marketing con IA?

Las ocho capas de la Architecture Decision Stack: resultado de negocio y alcance, modelo operativo y capacidad de decisión, flujos de trabajo y responsabilidad entre personas e IA, arquitectura del conocimiento y de los datos, arquitectura de tecnología y de integración, gobernanza y controles de calidad, diseño de la medición y del valor, y capacitación, documentación y traspaso de la titularidad.

### ¿Qué diferencia hay entre Architect y Strategic Architecture?

Architect define el modelo operativo de destino de todo el alcance de la transformación. Strategic Architecture es el método de entrega repetible que utiliza kōdōkalabs para especificar una línea de trabajo, un flujo de trabajo o un sistema de contenidos concreto dentro de ese modelo operativo ya aprobado: de alcance más reducido y aplicado de forma repetida durante Build.

### ¿Hace falta de verdad la arquitectura completa de ocho capas?

Las ocho capas se aplican en cierta medida a toda arquitectura, pero la profundidad varía: una Minimum Viable Architecture para un piloto controlado documenta cada capa con un nivel de detalle más ligero que el que exigiría un rediseño del modelo operativo de toda la empresa. Es una cuestión de [escala](./scale-ai-marketing-workflows.md).

### ¿Quién aprueba la arquitectura?

El patrocinador ejecutivo, los responsables de gobernanza que correspondan, las personas que gestionan los flujos de trabajo y operarán el resultado y una persona con la aprobación final: véase «Revisión de la arquitectura y puntos de aprobación» más arriba.

### ¿Qué pasa si Architect descubre una laguna de Diagnose?

Lo correcto es volver a Diagnose para esa área concreta y no diseñar sobre una suposición: una arquitectura construida sobre evidencias incompletas suele dar un diseño muy bien documentado para el problema equivocado.

### ¿Se puede avanzar en Architect antes de tener la gobernanza completamente aprobada?

La gobernanza es una de las ocho capas, no un añadido opcional: la clasificación de riesgo de un flujo de trabajo y sus requisitos de revisión forman parte de su especificación y no son una aprobación aparte que se pide cuando el diseño ya está terminado.

### ¿Cuánto dura la fase Architect?

Depende mucho del alcance: la arquitectura de un piloto de un solo flujo de trabajo y el rediseño del modelo operativo de toda la empresa exigen niveles de esfuerzo de diseño sensiblemente distintos, y esa es parte de la razón de que exista la Minimum Viable Architecture como una opción definida y más ligera.

## ¿Listo para diseñar el modelo operativo de su marketing con IA?

Si está cansado de estrategias fragmentadas y centradas en palabras clave, es hora de construir una base que resista los cambios de algoritmo. Empecemos por el plano que garantiza una ejecución de alto retorno. [Póngase en contacto con nosotros](#contact)