Strategic Architecture: especificar el trabajo de marketing asistido por IA antes de ejecutarlo
La Strategic Architecture es el método de trabajo con el que kōdōkalabs convierte un problema de negocio aprobado en una especificación de ejecución explícita, que recoge audiencia, resultado esperado, evidencias, alcance, flujo de trabajo, responsabilidad humana, límites de la IA, gobernanza, medición y criterios de aceptación.
Resumen ejecutivo
La Strategic Architecture existe porque el trabajo asistido por IA que arranca sin haber explicitado antes el resultado buscado, la audiencia, las evidencias, los límites y los criterios de aceptación suele parecer completo sin responder a la pregunta correcta: el resultado llega pulido y seguro de sí mismo, y las lagunas solo salen a la luz cuando alguien intenta usarlo para lo que realmente se necesitaba. La Strategic Architecture es el método reproducible de kōdōkalabs para cerrar esa brecha: una especificación de doce campos que se redacta y se revisa antes de empezar a ejecutar, y no se reconstruye a posteriori para justificar lo que ya se ha producido. Esta página distingue la Strategic Architecture de la fase Architect del framework, recorre los doce campos de la especificación y explica cómo se definen las evidencias, el reparto de responsabilidades entre personas e IA y los criterios de aceptación antes de redactar la primera línea.
Ideas clave
- La Strategic Architecture es un método reproducible para especificar un único frente de trabajo, distinto de la fase Architect del framework, que define el modelo operativo objetivo del conjunto de la organización.
- Una especificación de doce campos recoge resultado, audiencia, evidencias, alcance, flujo de trabajo, responsabilidades, gobernanza, formato, medición y criterios de aceptación antes de que empiece la ejecución.
- Un prompt no es arquitectura: un buen prompt sin una especificación definida sigue produciendo resultados que no se pueden revisar ni atribuir a nadie.
- El Assumption Register y el Source Resolution Plan hacen que los supuestos ocultos y las lagunas de evidencia sean visibles y revisables, en lugar de descubrirse cuando ya es tarde.
- La Strategic Architecture termina en una puerta explícita de revisión y aprobación antes de pasar al Agentic Drafting.
¿Qué es la Strategic Architecture?
La Strategic Architecture parte de un problema de negocio aprobado, ya priorizado y ya vinculado a un resultado definido, y lo convierte en una especificación lo bastante detallada como para que la investigación, el diseño del flujo de trabajo, la ejecución asistida por IA, la revisión humana y la medición partan de una base común y explícita, y no de las ideas que cada persona tiene sobre lo que es «bueno». Es el método que kōdōkalabs utiliza para especificar un frente de trabajo cada vez, y que aplica de forma repetida a todo el trabajo asistido por IA que entrega.
Strategic Architecture frente a la fase Architect
La Strategic Architecture y la fase Architect del kōdōkalabs Transformation System están relacionadas, pero son cosas distintas, y confundirlas suele producir una de dos cosas: una especificación sobredimensionada para un frente de trabajo pequeño o un modelo operativo infradefinido para toda una organización.
| Fase Architect | Metodología de Strategic Architecture | |
|---|---|---|
| Alcance | El modelo operativo objetivo de la organización, para el conjunto de los flujos de trabajo | Un frente de trabajo o un entregable concreto |
| Frecuencia | Una vez por cada gran iniciativa de transformación | Se repite con cada trabajo asistido por IA |
| Resultado | Modelo operativo objetivo, pila de controles de gobernanza, arquitectura de flujos de trabajo | Una especificación de doce campos para una única ejecución |
| Pregunta a la que responde | ¿Cómo debe funcionar nuestra función de marketing? | ¿Qué estamos produciendo exactamente y cómo sabemos que es correcto? |
Architect define el modelo operativo dentro del cual funcionará un conjunto de flujos de trabajo; la Strategic Architecture es el método reproducible para especificar un frente de trabajo de modo que funcione correctamente dentro de ese modelo. Una sola fase Architect suele producir el modelo operativo objetivo sobre el que después se redactarán decenas o cientos de especificaciones de Strategic Architecture.
Esta distinción aclara también quién es responsable de qué. Architect es normalmente un ejercicio de nivel directivo, en el que patrocinadores ejecutivos, responsables de gobernanza y responsables de flujos de trabajo deciden cómo debe funcionar el marketing como sistema. La Strategic Architecture, en cambio, es una disciplina de nivel operativo que aplica quien especifica cada trabajo: una persona responsable de estrategia de contenidos que especifica una guía de referencia, una responsable de campañas que especifica una secuencia de lanzamiento o un responsable de crecimiento que especifica un informe de medición. Si se trata la Strategic Architecture como algo reservado a la dirección, la entrega se ralentiza hasta casi detenerse; si se trata Architect como algo que cada profesional puede improvisar por su cuenta, se acaban teniendo flujos de trabajo que, puestos uno junto a otro, no forman un modelo operativo coherente.
Por qué los prompts no sustituyen a la arquitectura
Un prompt bien construido puede dar un buen resultado puntual, pero por sí solo no recoge las decisiones de fondo que hacen que ese resultado sea revisable y reproducible: en qué evidencias debía apoyarse, qué quedaba expresamente fuera de alcance, quién responde de comprobarlo, qué motivaría que una persona aprobadora lo rechazase y cómo se medirá su rendimiento una vez publicado. Sin una especificación detrás, un prompt que funcionó una vez es difícil de reproducir con fiabilidad, difícil de traspasar a otra persona y difícil de defender cuando alguien pregunta por qué se incluyó una afirmación o un enfoque concretos. La Strategic Architecture hace explícito y revisable el razonamiento que hay detrás del prompt, en lugar de dejarlo implícito en la cabeza de quien lo escribió.
Los doce campos de una especificación de Strategic Architecture
Toda especificación de Strategic Architecture de kōdōkalabs cubre doce campos obligatorios.
| N.º | Campo | Qué recoge |
|---|---|---|
| 1 | Decisión o resultado de negocio | Qué decisión debe respaldar o facilitar este trabajo |
| 2 | Audiencia y contexto de uso | Quién consumirá el resultado y en qué contexto |
| 3 | Planteamiento del problema | El problema concreto que aborda este trabajo |
| 4 | Alcance y exclusiones | Qué entra en el alcance y, de forma explícita, qué no |
| 5 | Evidencias aprobadas y jerarquía de fuentes | Qué fuentes se permiten y en qué orden de prioridad |
| 6 | Entidades, terminología y referencias al framework | Nomenclatura obligatoria, definiciones y referencias canónicas al framework |
| 7 | Flujo de trabajo y dependencias | La secuencia de pasos y de qué depende cada uno |
| 8 | Reparto de responsabilidades entre personas e IA | Quién o qué hace cada parte del trabajo |
| 9 | Restricciones de gobernanza, privacidad, seguridad y propiedad intelectual | Normas y límites aplicables |
| 10 | Requisitos de resultado y formato | Estructura, extensión y formato exigidos |
| 11 | Medición y observabilidad | Cómo se seguirá el rendimiento una vez publicado |
| 12 | Criterios de aceptación, personas aprobadoras y traspaso | Qué significa «terminado y correcto» y quién lo confirma |
Cada campo existe porque su ausencia tiene un modo de fallo previsible: sin audiencia definida, el trabajo se dirige a nadie en particular; sin exclusiones definidas, el alcance se desborda y se descubre en plena ejecución; sin criterios de aceptación definidos, las discusiones de aprobación se basan en preferencias subjetivas y no en estándares acordados.
Cómo se planifican las evidencias y las fuentes
Antes de empezar a ejecutar, la Strategic Architecture exige un Source Resolution Plan explícito: qué fuente hace falta, qué tipo de fuente se prefiere, quién se encarga de obtenerla, qué grado de actualidad necesita, qué uso está permitido, dónde se ubicarán la cita o la evidencia en el resultado final y, algo decisivo, un registro honesto de cualquier laguna que siga sin resolverse. Este plan no avala el scraping sin control, el acceso no autorizado a sistemas o datos, ni tratar como evidencia por sí misma un resumen no verificado de resultados de búsqueda generado por un sistema de IA: toda fuente del plan remite a algo que una persona puede comprobar de verdad.
Junto al Source Resolution Plan, kōdōkalabs mantiene para cada especificación un Assumption Register: cada supuesto formulado durante la planificación, su origen, el grado de confianza que lo respalda, la consecuencia si resulta ser erróneo, quién responde de validarlo, cuándo se validó o se validará y su estado actual (abierto, validado o rechazado). Hacer explícitos y revisables los supuestos, en lugar de dejarlos enterrados en el razonamiento de un prompt, es una de las formas más directas con que la Strategic Architecture reduce el riesgo de resultados erróneos presentados con total seguridad.
Cómo se definen las responsabilidades de personas e IA
El campo ocho de la especificación, el reparto de responsabilidades entre personas e IA, asigna de forma explícita cada paso del flujo de trabajo: si lo redacta un sistema de IA o una persona y, redacte quien redacte, quién lo revisa y qué debe comprobar. Este reparto se decide durante la Strategic Architecture, antes de la ejecución, precisamente para que quien revisa no tenga que adivinar de qué debe responder una vez hecho el trabajo.
| Tipo de responsabilidad | Ejemplo |
|---|---|
| Redactado por IA, revisado por una persona | Primer borrador de contenido revisado en cuanto a exactitud y encaje con la marca antes de publicarse |
| Redactado por una persona | Posicionamiento estratégico o redacción con implicaciones legales |
| Investigación asistida por IA, verificada por una persona | Recopilación de fuentes contrastada con la jerarquía de fuentes aprobada |
| Decisión exclusivamente humana | Aprobación final y visto bueno para publicar |
Cómo influyen el riesgo y la gobernanza en la especificación
El campo nueve de la especificación vincula cada trabajo asistido por IA con los requisitos de gobernanza que ya le son aplicables: la clasificación de riesgo, los requisitos de revisión, las consideraciones de privacidad y las restricciones de propiedad intelectual que se establecieron en Architect y se aplican en Build. La Strategic Architecture no inventa nuevas normas de gobernanza: aplica el marco de gobernanza que la organización ya tiene al frente de trabajo concreto que se especifica, y lo hace explícito en lugar de darlo por supuesto.
Cómo se redactan los criterios de aceptación
El campo doce, los criterios de aceptación, es donde se evitan por adelantado las discrepancias subjetivas en el momento de la revisión: define desde el principio qué significan «correcto» y «completo» para ese trabajo concreto, con varios tipos de criterio.
| Tipo de criterio | Qué comprueba |
|---|---|
| Factual | Las afirmaciones son exactas y se pueden rastrear hasta una fuente aprobada |
| Funcional | El resultado hace realmente lo que se especificó |
| De marca | El tono, la terminología y el posicionamiento se ajustan a los estándares aprobados |
| De accesibilidad | El resultado cumple los requisitos de accesibilidad aplicables |
| De gobernanza | El resultado cumple la clasificación de riesgo y el proceso de revisión aplicables |
| De medición | Están implantados el seguimiento y la observabilidad necesarios |
| De titularidad | Una persona con nombre responde del resultado final |
Unos criterios de aceptación formulados solo como «¿queda bien?» invitan a discrepancias basadas en preferencias personales y no en estándares acordados: los criterios anteriores están redactados para poder comprobarse, no solo para sentirse.
Resultados de la Strategic Architecture
Una especificación de Strategic Architecture terminada produce: el propio documento de especificación de doce campos, un Assumption Register completo, un Source Resolution Plan completo y la aprobación explícita de quienes deben validar la especificación, que confirma que está lista para ejecutarse. Estos resultados pasan a ser la referencia común sobre la que trabajan el Agentic Drafting, la Pilot Review y, finalmente, la medición.
Puertas de revisión y aprobación
Antes de empezar a ejecutar, la especificación pasa por una puerta de revisión en la que las personas aprobadoras asignadas confirman que los doce campos están completos, que los puntos abiertos del Assumption Register tienen un plan de validación, que las lagunas del Source Resolution Plan son aceptables o están resueltas y que los criterios de aceptación son lo bastante concretos como para comprobarse de forma objetiva más adelante. No se empieza a trabajar sobre una especificación sin aprobar. Esta puerta existe precisamente para detectar la ambigüedad cuando aún es barato corregirla, y no cuando la ejecución ya ha consumido tiempo y recursos.
Fallos habituales de la Strategic Architecture
- Objetivos vagos: una especificación que enuncia una dirección general, sin una decisión o un resultado de negocio concretos y comprobables.
- Supuestos ocultos: avanzar sobre supuestos no declarados que nunca llegan al Assumption Register y, por tanto, nunca se comprueban.
- Descripciones genéricas del ICP: un campo de audiencia tan amplio que no condiciona en nada cómo debe escribirse el trabajo.
- Briefs que parten de las palabras clave, sin finalidad de negocio: especificaciones construidas en torno a términos de búsqueda y no a la decisión de negocio que el contenido debe respaldar.
- Lagunas de evidencia disimuladas: tratar como resuelto un punto abierto del Source Resolution Plan en lugar de señalarlo con honestidad.
- Exclusiones sin definir: ningún límite de alcance explícito, lo que invita a que el alcance se desborde y solo se descubra en plena ejecución.
- Arquitectura escrita después de la ejecución: reconstruir una especificación a posteriori para justificar un trabajo ya producido, lo que anula todo el sentido de especificar antes.
- Criterios de aceptación basados solo en preferencias subjetivas: «mejóralo» en lugar de criterios comprobables de tipo factual, funcional, de marca, de accesibilidad, de gobernanza y de medición.
Cómo conduce la Strategic Architecture al Agentic Drafting
Cuando una especificación supera su puerta de revisión y aprobación, pasa a ser la entrada directa del Agentic Drafting: el método de kōdōkalabs para ejecutar trabajo asistido por IA a partir de una especificación aprobada, con el reparto de responsabilidades entre personas e IA, las fuentes de evidencia y los criterios de aceptación ya definidos y no improvisados durante la ejecución.
Preguntas frecuentes sobre la Strategic Architecture
¿Cómo convierte kōdōkalabs un problema de negocio en trabajo de marketing asistido por IA?
Mediante la Strategic Architecture: una especificación de doce campos que recoge resultado, audiencia, evidencias, alcance, flujo de trabajo, responsabilidades, gobernanza, formato, medición y criterios de aceptación, y que se revisa y aprueba antes de empezar a ejecutar.
¿En qué se diferencia la Strategic Architecture de la fase Architect?
Architect define el modelo operativo objetivo de la organización en su conjunto y se aplica una vez por cada gran iniciativa de transformación. La Strategic Architecture es un método reproducible para especificar un frente de trabajo cada vez, y se aplica a cada trabajo asistido por IA. Véase la tabla comparativa más arriba.
¿Por qué no basta con un buen prompt?
Un prompt puede producir un buen resultado puntual sin recoger las decisiones de fondo (fuentes de evidencia, exclusiones, responsabilidades, criterios de aceptación) que hacen que el trabajo sea revisable, reproducible y defendible.
¿Cuáles son los doce campos de la especificación?
Decisión de negocio, audiencia y contexto de uso, planteamiento del problema, alcance y exclusiones, evidencias y fuentes aprobadas, entidades y terminología, flujo de trabajo y dependencias, responsabilidades de personas e IA, restricciones de gobernanza, requisitos de resultado, plan de medición y criterios de aceptación con sus personas aprobadoras. Véase la tabla completa más arriba.
¿Cómo se gestionan las evidencias y las fuentes?
Mediante un Source Resolution Plan que especifica las fuentes necesarias, su titularidad, su actualidad y el uso permitido, y que excluye expresamente como evidencia el scraping sin control, el acceso no autorizado y los resúmenes de resultados de búsqueda sin verificar.
¿Cómo se reparten las responsabilidades entre personas e IA?
De forma explícita, paso a paso y antes de la ejecución: véase «Cómo se definen las responsabilidades de personas e IA» más arriba.
¿Qué pasa si un supuesto de la especificación resulta ser erróneo?
El Assumption Register registra de antemano su consecuencia y quién responde de validarlo, de modo que un supuesto erróneo se detecta mediante un paso de validación definido y no por sorpresa tras la publicación.
¿Cómo se redactan criterios de aceptación que se puedan comprobar en lugar de discutir?
Con siete tipos de criterio comprobables (factual, funcional, de marca, de accesibilidad, de gobernanza, de medición y de titularidad) en lugar de un único juicio subjetivo sobre la calidad.
¿Qué ocurre cuando se aprueba una especificación?
Pasa a ser la entrada directa del Agentic Drafting, el método de kōdōkalabs para ejecutar trabajo asistido por IA a partir de una especificación aprobada.
¿Todo trabajo necesita una especificación completa de doce campos?
La profundidad de la documentación puede escalar con el riesgo y la complejidad del trabajo, pero conviene considerar los doce campos de forma explícita: incluso una especificación breve gana al confirmar que ninguna de las doce áreas se ha omitido sin querer.
¿Listo para diseñar la arquitectura de su crecimiento?
Si está cansado de estrategias fragmentadas y centradas en palabras clave, es el momento de construir una base que resista los cambios de algoritmo. Empecemos por el plano que garantiza una ejecución de alto ROI.Póngase en contacto con nosotros