📄 MARCO DE ARQUITECTURA IA¶

Ecosistema IA BKM¶

Propósito¶

Este documento establece el estándar normativo que regula el diseño arquitectónico de los proyectos IA en BKM.

Define cuándo es obligatorio documentar la arquitectura antes de construir, quién la valida y cómo se integra ese proceso en el flujo de aprobación del ecosistema.

Su objetivo es garantizar que ningún sistema con impacto real en el negocio se construya sin haber sido pensado primero.

1️⃣ Cuándo es obligatorio documentar arquitectura¶

La cumplimentación de la Plantilla de Arquitectura es obligatoria antes de iniciar cualquier proyecto IA que cumpla al menos una de estas condiciones:

Integra más de un sistema (CRM, ERP, BigQuery, GCS, APIs externas, etc.)
Tiene memoria persistente entre sesiones o usuarios.
Afecta a más de un rol o área de la empresa.
Está previsto que se mantenga activo en el tiempo con impacto transversal.
Está clasificado en la capa Core IA.
Ha superado los criterios de migración desde Laboratorio u Operativa Ligera.
Incorpora una herramienta externa al stack de referencia en el Core IA.
Incorpora IA agéntica a un proceso que ya existía y que trata datos personales.

Este último punto merece atención específica: cuando se añade un agente o sistema de automatización con LLM a un proceso preexistente — por ejemplo, automatizar con n8n un flujo que antes hacía una persona — el tratamiento de datos cambia aunque el proceso parezca el mismo. El agente puede acceder a más datos, retenerlos en logs intermedios, enviarlos a servicios externos o tomar decisiones que antes eran humanas. La Plantilla de Arquitectura debe documentar no solo el sistema nuevo sino el impacto sobre el tratamiento completo en el que se integra.

2️⃣ Cuándo no es obligatorio¶

No se requiere Plantilla de Arquitectura completa para:

Proyectos bajo autonomía departamental que cumplen todos los criterios definidos en Roles y Responsabilidades.
Experimentos en la capa Laboratorio que no afectan a sistemas en producción ni a otros departamentos.
Automatizaciones puntuales y reversibles en Operativa Ligera de bajo impacto y sin integración con sistemas core.
Pruebas de concepto con plazo definido y sin usuarios fuera del departamento de origen.

En estos casos se aplica el Modo B del Marco de Operativa IA: registro básico de notificación al Responsable IA, propietario identificado y plazo definido.

Si cualquiera de estos proyectos supera sus límites de autonomía, la obligación de completar la Plantilla de Arquitectura se activa de forma inmediata y el proyecto pasa al Flujo A de aprobación.

3️⃣ Quién valida la plantilla¶

En proyectos con validación central (Flujo A):

La plantilla cumplimentada debe ser revisada y aprobada por dos roles:

Responsable Funcional Valida que el propósito, el impacto esperado y las métricas de evaluación reflejan la necesidad real del negocio. Confirma que el sistema hace lo que el área necesita y no más.

Responsable IA Valida la coherencia arquitectónica: capa correcta, sistemas adecuados, privacidad de datos, coherencia con el Stack Tecnológico. Si el proyecto incorpora herramientas externas al stack de referencia, verifica que han superado el proceso de evaluación.

Ambas validaciones son necesarias. Una sola no es suficiente.

En proyectos bajo autonomía departamental (Flujo B):

No hay validación previa de la Plantilla de Arquitectura. El Responsable IA recibe el registro básico de notificación y confirma que el proyecto está dentro de los límites de autonomía. Si no lo está, lo redirige al Flujo A.

4️⃣ Qué ocurre si un proyecto empieza sin plantilla cuando debería tenerla¶

Un proyecto que debía documentar arquitectura y no lo ha hecho se considera fuera del estándar del Ecosistema IA.

Las consecuencias son:

No puede clasificarse en la capa Core IA hasta completar la plantilla y obtener validación.
Si ya está en producción, debe completarse de forma retroactiva antes de la siguiente revisión periódica.
Si no se completa en el plazo de revisión, el Responsable IA puede suspender el desarrollo hasta que se regularice.

Esto aplica también a proyectos que empezaron bajo autonomía departamental y superaron sus límites sin notificar al Responsable IA.

5️⃣ Flujos de aprobación¶

Flujo A — Validación central¶

Para proyectos en Core IA, proyectos transversales y proyectos que han superado los límites de autonomía departamental.

Tarjeta de Valor IA — evaluar impacto, urgencia, complejidad y dependencias.
Determinar el flujo — verificar si requiere validación central o puede ir por Flujo B.
Evaluación de herramientas (si aplica) — si el proyecto usa herramientas externas al stack de referencia, completar el proceso de evaluación del Stack Tecnológico antes de continuar.
Plantilla de Arquitectura — cumplimentar conjuntamente entre Responsable Funcional y Responsable IA.
Validación y aprobación — ambos responsables revisan y aprueban.
Registro — si tiene impacto transversal o a largo plazo, entrada en el Log de Decisiones.
Inicio de construcción.

Flujo B — Autonomía departamental¶

Para proyectos en Laboratorio y Operativa Ligera que cumplen todos los criterios de autonomía departamental.

Verificación de criterios — el Propietario Departamental confirma que el proyecto cumple todos los límites de autonomía definidos en Roles y Responsabilidades.
Registro básico de notificación — notificar al Responsable IA: nombre, objetivo, capa, propietario, plazo y señal de escalado.
Confirmación del Responsable IA — confirma recepción y que el proyecto está dentro de los límites. Si no lo está, redirige al Flujo A.
Inicio del proyecto bajo responsabilidad del Propietario Departamental.
Monitorización continua — el Propietario Departamental notifica al Responsable IA si el proyecto supera sus límites en cualquier momento.

6️⃣ Dónde vive la documentación de cada proyecto¶

Cada tipo de documento de proyecto tiene un lugar único y definido en el ecosistema. No existe una sección de proyectos en el repositorio — la documentación se distribuye según su naturaleza entre el repositorio y Drive.

Documento	Dónde vive
Tarjeta de Valor completada	Drive — 04_Backlog_Iniciativas
Plantilla de Arquitectura completada	Drive — 05_Arquitecturas_Aprobadas
Ficha de Sistema Modo A	Drive — 01_Sistemas_Activos
Registro de Notificación Modo B	Drive — 03_Proyectos_Departamentales
ADRs — decisiones arquitectónicas	Repositorio — Sección 7
Prompts maestros de sistemas con LLM	Repositorio — Sección 5 (Agentes)
Índice de estado actual del ecosistema	Repositorio — Sección 4 (Índice Operativo)

El repositorio contiene estándares, marcos, plantillas en blanco y decisiones arquitectónicas. Drive contiene los registros operativos vivos — las instancias concretas de esos documentos.

7️⃣ Relación con otros documentos del ecosistema¶

Documento Fundacional — establece el principio de que todo sistema con cierta complejidad debe diseñarse antes de construirse.
Stack Tecnológico — define el stack de referencia y el proceso de evaluación de herramientas externas.
Roles y Gobernanza — define los roles, los criterios de autonomía departamental y los dos flujos de aprobación.
Tarjeta de Valor IA — paso previo obligatorio en el Flujo A. En el Flujo B puede omitirse si el proyecto es suficientemente simple.
Marco de Operativa IA — define los dos modos de gestión (central y departamental) y qué documentación mínima requiere cada uno.
Log de Decisiones — registra decisiones con impacto transversal. Los proyectos del Flujo B no generan ADR salvo que escalen al Flujo A.

8️⃣ Revisión de este documento¶

Este marco debe revisarse:

Una vez al año, en la revisión general del ecosistema.
O cuando el número de proyectos activos supere cinco.
O cuando la experiencia acumulada con proyectos departamentales autónomos indique que los criterios de autonomía necesitan ajuste.

Estado: Activo
Fecha: Marzo 2026
Responsable: Responsable IA BKM
Ubicación en el ecosistema: Sección 3 — Marco de Arquitectura