🗄 Estrategia de Storage¶

Sistema de Decisión Asistida (SDA) — BKM¶

1. Propósito de este documento¶

Este documento define la estrategia de uso del Storage dentro del Sistema de Decisión Asistida (SDA) de BKM.

Su objetivo es establecer de forma clara y no ambigua:

qué es el Storage y qué rol cumple dentro del sistema,
qué tipo de información debe almacenarse en él,
qué tipo de información no debe almacenarse,
cómo se versiona la información,
cómo se relaciona el Storage con el Repo,
y cómo el Storage soporta trazabilidad, auditoría y memoria del sistema.

Este documento forma parte del gobierno del sistema y es de cumplimiento obligatorio para personas, procesos y agentes de IA.

2. Principio rector del Storage¶

El Storage es el sistema de registro operativo del SDA de BKM.

El Storage registra:

qué información se utilizó,
qué outputs se generaron,
qué evidencias respaldaron una decisión,
y qué decisiones humanas se tomaron.

El Storage:

no define el sistema,
no gobierna decisiones,
no sustituye al Repo.

3. Rol del Storage en el SDA¶

Dentro del SDA, el Storage actúa como:

memoria documental viva del sistema,
repositorio de inputs y outputs reales,
fuente de evidencias para decisiones,
soporte de trazabilidad histórica,
base para auditoría y revisión posterior.

Gracias al Storage, el sistema puede:

evolucionar sin perder contexto histórico,
desacoplar diseño (Repo) de ejecución (uso real),
y mantener responsabilidad y control en decisiones asistidas.

El Storage sigue siendo válido incluso si la IA no está activa.

4. Qué tipo de información vive en el Storage¶

4.1 Información asociada a decisiones¶

Para cada decisión asistida por el sistema, el Storage puede contener:

inputs reales utilizados para decidir,
outputs generados por IA u otros análisis,
snapshots de información relevante,
registros de decisiones humanas,
evidencias documentales o visuales,
históricos fechados.

Esta información constituye la memoria operativa de la decisión.

4.2 Información a nivel de sistema¶

A nivel global, el Storage puede contener:

resúmenes ejecutivos consolidados,
comparativas históricas entre decisiones,
informes de seguimiento,
outputs agregados de múltiples decisiones.

4.3 Eventos de gobierno reflejados en Storage¶

El Storage puede reflejar eventos relevantes de gobierno, como:

cambios de estado de decisiones (activación, congelación, retirada),
aplicación de mecanismos de stop o kill switch,
motivos, fechas y responsables asociados.

⚠️ Estos eventos no se gobiernan desde Storage.
El Storage solo conserva el registro operativo de lo ocurrido.

5. Qué NO debe vivir en el Storage¶

No deben almacenarse en el Storage:

documentos de gobierno del sistema,
principios, reglas o normas,
marco de decisiones,
playbooks y guías metodológicas,
plantillas oficiales,
prompts versionados,
definiciones de agentes o contratos de IA.

Toda esta información vive exclusivamente en el Repo, como fuente normativa.

6. Relación con la estructura física (GCS)¶

La estructura física y canónica de Google Cloud Storage (GCS) no se define en este documento.

La estructura oficial se define en el documento:

estructura_gcs.md
ubicado en /00_gobierno/

Dicho documento establece:

el bucket raíz del sistema,
la estructura de primer nivel,
el rol funcional de cada carpeta,
y las reglas de organización operativa.

Este documento (estrategia_storage.md) define el marco conceptual, mientras que estructura_gcs.md define la implementación estructural.

Ambos documentos son complementarios y obligatorios.

7. Versionado y naming en Storage¶

El Storage no utiliza control de versiones Git.

El versionado se gestiona mediante:

estructura de carpetas,
fechas explícitas en nombres de archivo,
convenciones de naming claras.

Ejemplo típico¶

outputs/ ├── 2026-01-08_output.md ├── 2026-01-15_output.md └── latest.md

Reglas obligatorias¶

Los documentos históricos no se sobrescriben.
Cada archivo debe ser temporalmente trazable.
latest.md representa el último output válido, sin eliminar el histórico.

8. Escritura y lectura en el Storage (visión general)¶

Las reglas detalladas de acceso y escritura se definen en:

reglas_escritura_gcs.md

A nivel estratégico:

las personas definen inputs y validan outputs,
la IA genera outputs bajo control,
el Storage preserva la memoria operativa.

9. Relación entre Repo y Storage¶

Repo	Storage
Diseño y gobierno	Ejecución y evidencia
Reglas y normas	Resultados y memoria
Plantillas	Documentos instanciados
Cambios controlados	Crecimiento continuo

Regla de precedencia¶

El Repo es la fuente de verdad normativa.
El Storage es la fuente de verdad operativa.
Nunca se duplican documentos entre ambos.

10. Ciclo de vida de un documento (resumen)¶

Se define una plantilla o regla en el Repo.
Se diseña una decisión en el Repo.
Se ejecuta la decisión en la práctica.
Inputs y outputs reales se almacenan en Storage.
Se registra la decisión humana.
El histórico queda preservado.
El diseño puede evolucionar sin perder trazabilidad.

11. Errores comunes que deben evitarse¶

Usar el Storage como un Drive sin estructura.
Guardar outputs en el Repo.
Duplicar documentos entre Repo y Storage.
Sobrescribir históricos.
Confundir diseño (norma) con ejecución (uso real).

12. Idea clave final¶

El Storage no hace al sistema más inteligente.
Lo hace más responsable, trazable y gobernable.

Esta estrategia garantiza que el SDA de BKM crezca con orden, claridad y control, incluso a medida que se automatiza.

✅ Estado del documento¶

Con este documento quedan cerrados y documentados:

el rol estratégico del Storage,
sus límites de uso,
su relación con el Repo,
y su encaje con decisiones, personas y agentes.

La estructura física se define y mantiene en estructura_gcs.md.