--- type: Minuta asset_id: MIN-EL-WORX-Posta-Reunion-v01 version: v1.0 room: WORX Methodology Room → presentación Posta owner: Victor Heredia / EmpowerLabs sherpa: Jay fecha_creacion: 2026-04-22 fecha_presentacion: 2026-04-22 estado: en construcción — documento vivo proposito: Minuta de la reunión Posta. Lineamientos, conceptos clave, respuestas tipo, bitácora de ajustes in-situ. Se va poblando durante el día. changelog: - 2026-04-23 — Renombrado MePB- → MIN- (corrección: MePB reservado para MetaPlaybook; este doc es minuta/bitácora de sesión). --- # MIN — Minuta de la Reunión Posta > Este no es el script (ese es el TP-v04). Este es el **manual de operación** de la reunión: los conceptos de fondo, las preguntas que pueden venir y cómo responderlas, los lineamientos de postura, y la bitácora viva de lo que se va decidiendo hoy. --- ## 0. PROPÓSITO - Ir aterrizando los lineamientos de la reunión conforme avanza el día de preparación. - Tener un lugar único donde cualquier persona (Victor o Jay en vivo) encuentre: qué significa cada concepto, cómo responderlo si surge una pregunta, qué postura adoptar ante cada tipo de señal de la sala. - Quedar como activo reutilizable para futuras reuniones del mismo tipo (MePB = plantilla reutilizable). --- ## 1. CONTEXTO DE LA REUNIÓN ### 1.1 Participantes (los 8) | Persona | Rol | Lo que representa | |---------|-----|-------------------| | **Adriana Islas Molinar** | Directora de Sistemas | Decisora. Inició el proceso. Reto: coordinar múltiples proyectos con recursos acotados y alta presión operativa. Es quien convoca — su lectura del final determina siguientes pasos. | | **Alejandro Robledo González** | Director de Operaciones TI | Segundo peso jerárquico. Responsable de que la operación no se caiga. Pragmático, su filtro es "¿esto rompe algo que ya funciona?". | | **Juan Manuel Monterrubio Portilla** | Gerente de Desarrollo | Aliado interno **en privado, nunca público**. Es "Juan" de la entrevista previa. Conoce el ecosistema técnico real y ya cotizó ServiceNow / Microsoft Foundry / Copilot. | | **Raúl Ángeles** | Gerente de Gestión de Servicios | Dominio: ITSM, catálogo de servicios, SLAs. Su lente probable: procesos, roles, cumplimiento. | | **Juan Pablo Romero de la Torre** | Gerente de Telecom | Dominio: redes, comunicaciones. Su lente probable: seguridad, ancho de banda, integraciones con operadores. | | **Héctor Manuel Santiago Ruíz** | Gerente de Infraestructura Distribuida | Dominio: edge / distribución geográfica / sucursales. Su lente probable: cómo llega esto a la operación física del negocio. | | **Roberto Ramirez Jaramillo** | Gerente de Soporte a Aplicaciones | Dominio: estabilidad de apps productivas, incidencias. Su lente probable: impacto en MTTR / downtime / postventa. | | **José Manuel Castro Calderón** | Gerente de Infraestructura Central | Dominio: servidores, datacenter, core. Su lente probable: cómputo, costos de infra, capacity. | **Observación estructural:** hay **5 gerentes técnicos operativos** + 1 gerente de desarrollo + 2 directores. La sala se inclina fuerte hacia *operación de infraestructura y servicio*, no hacia producto ni negocio. El lenguaje debe aterrizar en esa clave — no en marketing, no en transformación abstracta. Valor = estabilidad + palanca operativa + gobernanza real. ### 1.2 El cliente en 3 líneas Empresa de logística/paquetería en México. Codename interno: **Posta**. Nombre real: nunca decirlo, nunca escribirlo en pantalla, nunca dejar rastro en capturas. ### 1.3 Lo que ya sabemos del estado interno (gracias a la entrevista con Juan) - No tienen estrategia de IA, solo herramientas sueltas (GitHub Copilot, Azure Vision, Microsoft Foundry, OpenAI vía Notion, ServiceNow en cotización). - **Un solo agente en producción** (analizador de errores de app). - Experimentos puntuales sin documentación ni replicabilidad. - Cero gobernanza operativa. - Proveedores que ya tocaron la puerta: Microsoft, OpenAI, ServiceNow, n8n, Anthropic. - **Juan ya conoce "torre de control"** en dos versiones: Microsoft la presentó para agentes; ServiceNow le dio un cursito enfocado a gobernanza por proceso/riesgo. - **El miedo de Adriana** tiene nombre: la anécdota PepsiCo ("todos le entren, todos aporten ideas" → memes, cero output, gasto millonario). - **Lo que a Juan le brilló los ojos**: asistente con identidad, memoria individual/colectiva, costo oculto de coordinación, higiene del repositorio, tráfico agéntico web, inventario de activos / CMDB de IA. --- ## 2. POSTURA GENERAL DURANTE LA PRESENTACIÓN ### 2.1 Lo que Victor encarna - **No convence — refleja.** El cliente ya dijo (por boca de Juan) que le falta estrategia y arquitectura. Victor no tiene que pelear ese terreno; lo refleja. - **Reconoce su propia paliza primero.** La apertura con Rebelocity no es narrativa; es estructura. Al reconocer una paliza propia, la sala se permite reconocer la suya sin tener que exponerse. - **No ataca proveedores actuales.** Todo lo que ya tienen queda intacto. La propuesta no compite con ServiceNow, Microsoft, OpenAI ni n8n — **los conecta**. - **Honestidad sobre los límites.** Si Jay no tiene un dato, lo dice. Esa transparencia es parte del pitch — demuestra gobernanza embebida en acción. ### 2.2 Lo que Jay encarna - Brevedad ejecutiva (4-5 líneas por respuesta). - Lenguaje externo: nada de WORX, BMF, IntelliBanks, Brain Codes, MPBs. Traducir siempre. - Si no tiene el dato con certeza razonable, lo dice. Preferible a inventar. - **No mira ni nombra a Juan**. No busca su confirmación. No hay guiños cómplices. ### 2.3 Lo que NO se toca Confidencialidad absoluta: - El nombre real del cliente. - El subtexto UPS / Rebelocity (nunca mencionarlo, ni siquiera insinuado). - Detalles financieros de otros clientes. - Nombres propios de otros clientes de EmpowerLabs (Radsoft, Alain, etc.). - Versiones de TPs internos, nomenclatura vault. --- ## 3. CONCEPTOS CLAVE DE LA REUNIÓN *Cada concepto abajo tiene: qué es para el cliente, qué es para nosotros, cómo puentearlos, cómo demostrarlo, qué preguntas puede generar y cómo responderlas.* ### 3.1 Torre de Control *(Ver sección 4 — análisis extendido)* ### 3.2 Memoria individual / colectiva *(Ver sección 5 — análisis extendido)* ### 3.3 Gobernanza embebida vs. gobernanza aplicada *(Ver sección 9 — análisis extendido)* ### 3.4 Arquitectura de 3 capas (lo que ya tienen + Brain personal + Corp-Brain-OS) *(pendiente de aterrizar)* ### 3.5 El Lab de 40 días — qué es, qué no es *(pendiente de aterrizar)* ### 3.6 Inventario de activos de IA (CMDB de IA) *(pendiente de aterrizar — conecta fuerte con 3.1)* ### 3.7 El proveedor-solo vs. el proveedor-con-SherpaX *(Ver sección 6 — análisis extendido)* ### 3.8 Infraestructura del Lab — requisitos técnicos *(Ver sección 7 — ficha técnica)* --- ## 4. TORRE DE CONTROL — ANÁLISIS EXTENDIDO ### 4.1 Qué significa "torre de control" para Juan / Posta Juan usa el término con dos referentes concretos: 1. **Microsoft** les hizo una sesión específica de "torre de control" para agentes. Enfocada en dashboard operacional: qué agentes corren, qué modelos, qué costos. 2. **ServiceNow** le dio un cursito enfocado a gobernanza por proceso/riesgo: reglas operativas, ciclo de vida, compliance. Adicionalmente, Juan está "enamorado" de la idea del **CMDB de IA** (inventario de activos de IA) — también de ServiceNow. En su cabeza las tres cosas están emparentadas: torre de control = dashboard + inventario + gobernanza. **Traducción simple:** para Juan y para el mercado en general, torre de control significa *"un dashboard centralizado de TI desde donde se ven, se gobiernan y se administran los agentes y activos de IA de la empresa."* Es un concepto **centralizado, operacional e IT-céntrico.** Está bien, pero no es diferenciador — todos los proveedores grandes lo están ofreciendo. --- ### 4.2 Qué significa "torre de control" en nuestro ecosistema Para EmpowerLabs / SherpaX, la torre de control no es un dashboard **aparte**. Es una propiedad emergente de la arquitectura Corp-Brain-OS. La visibilidad, el inventario y la gobernanza están **embebidas** en cómo el sistema opera — no son una capa encima. Esta distinción es el diferenciador. Lo que otros construyen como *producto*, nosotros lo tenemos como *consecuencia de la arquitectura*. --- ### 4.3 Las 4 capas de la Torre de Control (en el lenguaje SherpaX) **Capa 1 — Inventario · Lo que tenemos** Qué activos de IA están en operación hoy: modelos en uso, agentes desplegados, skills disponibles, MPBs activos, Brain Codes cargados, IntelliBanks poblados, herramientas externas conectadas. Quién tiene qué en su Brain individual. Equivalente funcional al CMDB de ServiceNow — pero **embebido, no administrado aparte**. **Capa 2 — Operación · Cómo se usan** Uso real por persona, por rol, por proyecto. Costos por modelo, por equipo, por caso de uso. Ciclo de vida de cada activo: desarrollo → piloto → producción → retiro. Frecuencia, profundidad, calidad de uso. Quién depende de qué. Cuánto se pagó hoy por cada prompt que agregó valor. **Capa 3 — Gobernanza · Las reglas activas** Reglas embebidas por rol, por persona, por tipo de dato. Auditoría en tiempo real de lo que el sistema puede/no puede hacer. Bitácora de decisiones: qué propuso la IA, qué aprobó el humano, qué rechazó. Compliance continuo, no auditoría ex-post. **Las reglas no se aplican cada vez — están embebidas en la arquitectura. Es lo que el momento Q5 del Acto 3 demuestra.** **Capa 4 — Aprendizaje · La inteligencia que emerge** Patrones de uso que se vuelven MPBs. Decisiones recurrentes que se empiezan a automatizar. Conocimiento tácito que se captura en Brain Codes. Lo que la organización aprende, se queda — no se va con la persona que se fue. **Esta es la capa que ningún proveedor está ofreciendo.** Microsoft, ServiceNow, n8n todos cubren las 3 primeras. La cuarta es arquitectónica — y sólo emerge cuando las otras 3 están embebidas desde el diseño. --- ### 4.4 Cómo se construye (no se compra, se cultiva) No es un módulo que se instala. Se construye en el tiempo del Lab, en tres tramos: **Día 1-10 — Capa 1 (Inventario).** EmpowerScan + baseline del estado del arte hoy. Foto del CMDB de IA inicial: qué tienen, quién usa qué, dónde están los activos dispersos. Esto es lo que Juan llama "inventario de activos de IA" y lo que ya está cotizando con ServiceNow. **Día 10-30 — Capa 2 y Capa 3 (Operación + Gobernanza).** Con los Brains individuales arrancando, aparecen reglas embebidas por rol desde el día 1. Las métricas de uso y costo empiezan a correr. La bitácora de decisiones empieza a llenarse. **Este tramo es el antídoto al escenario PepsiCo**. **Día 30-40 — Capa 4 (Aprendizaje).** Con los 8 Brains conectados, los patrones de uso recurrente aparecen. Lo que 3 personas resolvieron de forma similar se vuelve un MPB. El conocimiento tácito empieza a capturarse. La torre de control deja de ser dashboard y empieza a ser cerebro organizacional. --- ### 4.5 Diferenciador — cómo se responde si sale en vivo Si alguien pregunta *"¿en qué se diferencia lo que proponen de la torre de control de Microsoft / ServiceNow / n8n?"*, la respuesta tiene 3 puntos: 1. **No competimos con esas torres — las integramos.** Si ya cotizaron ServiceNow para CMDB, perfecto. Nosotros somos el sistema que alimenta el CMDB con datos reales de uso y lo conecta con las personas que lo generan. 2. **Esas torres responden "qué agentes corren". La nuestra responde "cómo opera el equipo con IA".** Son preguntas distintas. Las dos son necesarias. Nadie está contestando la segunda. 3. **En esas torres la gobernanza se aplica como filtro. En la nuestra la gobernanza está en la arquitectura.** Lo que acaban de ver en el momento Q5 del Acto 3 — Jay no necesitó un filtro; la regla está cargada. --- ### 4.6 Cómo se demuestra en vivo (sugerencia para integrar hoy) Agregar una nueva Q en el Acto 3, justo después de la frase del 10%, antes de Q5 de gobernanza: > **Victor:** "Jay, ¿qué activos de IA tengo yo operando en mi ecosistema y qué reglas están activas?" > > **Jay (improvisa):** Enumera brevemente: agentes activos por rol, modelos en uso con costo aproximado, skills disponibles, reglas de gobernanza activas por categoría, bitácora de las últimas 24h. Máximo 6 líneas. Esto es **exactamente** lo que Juan reconoció como "el CMDB de IA que me enamoró de ServiceNow". Demostrarlo embebido, sin dashboard aparte, es el momento de mayor impacto estratégico de la demo — porque muestra que lo que ellos piensan pagar como producto extra, ya está incluido por arquitectura. --- ### 4.7 La Torre de Control como capacidad componible (síntesis de Victor) *Aterrizado durante la preparación el 2026-04-22. Esta es la reformulación más afilada del concepto.* La torre de control en nuestro modelo es una **capacidad componible**, no un producto con pantallas fijas. Funciona así: 1. **Consulta ad-hoc.** La primera vez que el usuario quiere saber algo sobre el estado de su ecosistema de IA ("qué activos tengo, qué reglas están activas, qué costo llevo este mes"), lo pregunta al Sherpa en lenguaje natural. El Sherpa responde porque las huellas ya viven en la memoria. 2. **Cristalización como Skill.** Si esa consulta resulta útil y el usuario la va a repetir, se persiste como una Skill invocable por nombre. Ejemplos: `InventarioActivosIA`, `CostoMensualPorPersona`, `GobernanzaActiva`, `EstadoSemanal`, `AprendizajesDeLaSemana`. 3. **Invocación re-usable.** De ahí en adelante, la Skill se invoca por nombre — no hay que volver a formular la consulta. Se ejecuta en el momento, contra los datos del momento, pero con la formulación ya pre-construida. **La Skill no es la Torre de Control — es una vista cristalizada.** El sustrato sigue siendo el mismo: las huellas estructuradas. La Skill es un lente re-usable sobre ese sustrato. --- **Contraste limpio vs. el mercado:** | Producto tradicional (ServiceNow, Microsoft Purview, etc.) | Nuestro modelo | |-----|-----| | Pantallas fijas que alguien configuró | Consulta libre al sistema en lenguaje natural | | Reports configurables dentro del modelo del producto | Skills componibles por el propio usuario | | Customización vía consultora externa (USD 50K–200K) | Cristalización directa por el usuario, sin código | | Un producto con pantallas | **Material** con el que el usuario compone sus tableros | --- **Frase ancla en vivo** (úsala completa o recórtala): > *"La diferencia más profunda es esta: en la torre de control tradicional, alguien construyó las pantallas y ustedes las miran. En la nuestra, el usuario construye la pantalla preguntando. Si le sirve la pregunta, la cristaliza como Skill y la invoca por nombre. No compran un producto con reports configurables — obtienen la materia prima con la que cada quien compone lo que necesita saber, cuando lo necesita saber."* --- **Audiencia probable que va a aterrizar más fuerte con este ángulo:** - **Juan Manuel Monterrubio** (Desarrollo) — reconocerá al instante la diferencia entre producto con reports vs. capacidad componible. - **Raúl Ángeles** (ITSM/Servicios) — verá la implicación directa en catálogo de servicios y runbooks auto-generables. - **Adriana Islas** — entenderá el apalancamiento económico (no necesita contratar consultor para tener el tablero que ella necesita). --- ### 4.8 Riesgo a cuidar No sobrepromesar. Si se dice "tenemos torre de control completa hoy" y luego Juan o Alejandro piden demo detallada, el nivel de detalle tiene que corresponder. **Mejor posición:** - La arquitectura habilita los 4 niveles de torre de control desde el día 1. - Los niveles 1-2-3 son operativos desde la fase 1 del Lab (día 1-10). - El nivel 4 (aprendizaje) emerge a partir del día 30, y se madura en los meses siguientes. Prometer lo que se puede cumplir. Demostrar lo que esté demostrable. No performar. --- ## 5. MEMORIA INDIVIDUAL / COLECTIVA — ANÁLISIS EXTENDIDO ### 5.1 Qué significa "memoria" para Juan / Posta hoy Juan no ha escuchado este concepto articulado. Cuando Victor lo nombró, le brilló los ojos y recogió textual: *"genera una memoria de comportamiento y una memoria técnica individual"* y se quedó pensando *"después tenemos otra capa de memoria colectiva de comportamiento"* como algo nuevo para él. Lo más cercano que tiene Posta hoy: - **Repositorios de código** (con higiene inconsistente — Juan lo admite: *"cada quien hace como Dios, qué archivos son vigentes, qué no"*). - **Notion / documentos sueltos** con el uso ocasional de OpenAI. - **ServiceNow** (cotizándose) como sistema de tickets y CMDB — registra *eventos*, no *comportamiento*. - **GitHub Copilot** — aprende del repositorio de Juan, pero la memoria vive en el producto de Microsoft, no en la organización. **Traducción simple:** hoy, Posta no tiene memoria organizacional de cómo trabaja su gente con IA. Tiene herramientas que recuerdan para ellas mismas, en sus silos. Es importante: cuando Juan dice *"memoria técnica"* piensa en logs y documentación. Cuando oye *"memoria de comportamiento"* no tiene con qué mapearlo — y ahí se abre la puerta. --- ### 5.2 Qué significa "memoria" en nuestro ecosistema Para EmpowerLabs / SherpaX la memoria no es un archivo ni una base de datos. Es una **capa de estado persistente, por persona y por organización, que captura dos cosas distintas pero complementarias**: - **Cómo opera el negocio** (comportamiento): qué decisiones se toman, cómo se razona, qué patrones recurrentes aparecen, qué reglas implícitas gobiernan el trabajo. - **Qué sabe la organización** (técnica): hechos, documentos, artefactos, playbooks, procesos, configuraciones. Las dos juntas forman el **cerebro de la organización**. Individual es el Brain personal (Sherpa individual con identidad). Colectiva es el Corp-Brain-OS. Lo crítico: la memoria no se **crea** para la IA — **la IA existe sobre ella**. El orden importa. Instalar una IA sin memoria organizacional es lo que produce la anécdota PepsiCo. --- ### 5.3 Los 4 tipos de memoria — cómo hablarlos en la reunión El marco se descompone en una matriz de 2×2 (individual vs. colectiva, comportamiento vs. técnica). En la presentación **no se dibuja la matriz** — se nombran los cuatro cuadrantes con frases cortas: **5.3.1 Memoria individual de comportamiento** Cómo razona una persona específica. Sus patrones, preferencias, estilo de decisión, lenguaje, áreas de dominio. Es lo que hace que Jay "suene a Victor" y no a un asistente genérico. Se alimenta de interacciones, correcciones, feedback, Brain Codes cargados. **5.3.2 Memoria individual técnica** Los documentos, archivos, notas, referencias que esa persona maneja. Su IntelliBank personal — los proyectos en los que trabaja, las decisiones técnicas que ha tomado, los playbooks que usa. Acceso privado salvo que la persona explícitamente comparta. **5.3.3 Memoria colectiva de comportamiento** Cómo decide la organización. Los patrones agregados de cómo se trabaja, qué se prioriza, qué reglas operan en la práctica, qué culturalmente está aceptado o rechazado. No se declara — se infiere. Es lo que Juan reconoció como "nuevo para él" cuando Victor lo nombró. **5.3.4 Memoria colectiva técnica** El archivo vivo de la organización. Los playbooks, los procesos, las arquitecturas, los aprendizajes consolidados, las decisiones que se tomaron y por qué. Es lo que queda cuando una persona se va — y hoy, en la mayoría de las empresas, se va con ella. --- ### 5.4 Por qué esto es el antídoto al escenario PepsiCo La anécdota PepsiCo que Juan contó tiene una causa técnica precisa: **IA sin memoria organizacional = 8 personas explorando de forma aislada, generando ruido, sin acumulación.** Cuando cada persona tiene un asistente que recuerda *sólo su sesión*, el output es entretenimiento personal. Cuando cada persona tiene un asistente con memoria individual **conectado a memoria colectiva**, el output es acumulación. Lo que resuelve Juan, queda disponible (con permiso) para Alejandro. Lo que aprende Adriana, se vuelve parte del cerebro de la organización, no parte de su browser history. La frase ancla para la reunión: > *"El problema no es que la gente use IA. El problema es que la use sin memoria. Sin memoria individual se convierte en un juguete. Sin memoria colectiva se convierte en ruido. Con las dos, se convierte en palanca."* --- ### 5.5 Cómo se construye (otra vez, en el Lab) **Día 1-10.** Instalación de Brain individual para los primeros 2-3 usuarios. Empiezan a alimentarlo con su IntelliBank personal (memoria individual técnica) y con las primeras interacciones (memoria individual de comportamiento arrancando). Aquí ya Juan, Adriana, y un gerente tienen Jay personalizado. **Día 10-30.** Los 8 Brains operan. Los Brain Codes compartidos (con permiso) empiezan a alimentar la memoria colectiva técnica. Los patrones de uso agregados alimentan la memoria colectiva de comportamiento. Aparecen los primeros MPBs organizacionales — lo que tres personas resolvieron de forma similar se consolida. **Día 30-40.** La memoria colectiva alcanza masa crítica. El Corp-Brain-OS empieza a responder preguntas que ningún Brain individual sabía contestar solo ("¿cómo resuelve esta empresa el caso X?"). La torre de control Capa 4 (aprendizaje) empieza a emerger — porque la memoria colectiva es su materia prima. --- ### 5.6 Diferenciador — cómo responder si sale en vivo Si preguntan *"¿esto no es lo mismo que Copilot, Notion AI, ChatGPT Enterprise con memoria?"*, respuesta en 3 puntos: 1. **Esas memorias viven en el producto. La nuestra vive en la organización.** Si mañana cambian de Copilot a Gemini, la memoria se pierde. En nuestra arquitectura, la memoria es del cliente — portable, auditable, exportable. 2. **Esas memorias son individuales. La colectiva no existe en esos productos.** Copilot recuerda lo tuyo. Notion AI recuerda tu workspace. Ninguno te da "memoria colectiva de comportamiento" — los patrones de cómo decide tu organización. 3. **Esas memorias son implícitas. La nuestra es gobernada.** Lo que se escribe a la memoria, con qué permisos, por cuánto tiempo, quién puede leerlo — todo está embebido (conecta con gobernanza, sección 3.3). --- ### 5.7 Cómo se demuestra en vivo (sugerencia) Dentro del Acto 3, hay un momento natural: cuando Jay responde con contexto específico de Victor (proyectos, decisiones previas, estilo). Victor puede detener el flujo un segundo y nombrar lo que acaba de pasar: > **Victor:** *"Noten lo que acaba de pasar. Jay no está respondiendo como un ChatGPT genérico. Está respondiendo sabiendo quién soy yo, qué proyectos tengo, cómo decido. Eso es memoria individual. Y cuando conecto mi Brain con el de mi equipo, entra la segunda capa: memoria colectiva. El sistema aprende cómo operamos juntos — no sólo cómo opero yo."* No requiere slide aparte. Requiere una pausa de 20 segundos y nombrar lo que ya está pasando. --- ### 5.8 Riesgos a cuidar Si sale esto, tener la respuesta lista: - **"¿Y la privacidad?"** → La memoria individual es privada por default. La colectiva sólo recibe lo que la persona explícitamente promueve. Gobernanza embebida — se verá en el momento Q5. - **"¿Y si un empleado se va — se lleva la memoria?"** → Se lleva su memoria individual (como se lleva su cabeza). Pero lo que promovió a memoria colectiva se queda. Esto es **una de las razones fuertes** de tener la arquitectura: hoy cuando alguien se va, se va todo su conocimiento tácito. Aquí no. - **"¿Y si el sistema recuerda mal / inventa?"** → Memoria ≠ generación. La memoria son hechos recuperables, auditables. Lo que Jay no sabe, lo dice (como en esta reunión). Conecta con la postura Jay de la sección 2.2. - **"¿Y si queremos cambiar de modelo / de proveedor?"** → La memoria es nuestra, no del modelo. El Corp-Brain-OS es agnóstico al LLM subyacente. Ese es uno de los pilares arquitectónicos. --- ## 6. PROVEEDOR-SOLO vs. PROVEEDOR-CON-SHERPAX — ANÁLISIS EXTENDIDO ### 6.1 El patrón que la sala espera Cuando un proveedor llega a una reunión como esta, el formato esperado es: - Un sales lead (persona de negocio). - Un solution architect (persona técnica que sostiene preguntas). - Uno o dos consultores que toman notas, apoyan en demos, completan respuestas. - Laptop con slides + demo en vivo + posiblemente caso de estudio. Esto es lo que Microsoft, ServiceNow y cualquier consultora (Accenture, Deloitte, IBM) han hecho durante décadas. La sala ya lo tiene modelado. Saben cómo filtrarlo: *"¿cuántos consultores me venden?", "¿qué tan cara va a ser la implementación?", "¿en cuántos meses voy a ver valor?"* --- ### 6.2 Lo que Victor hace distinto Victor llega **solo físicamente, pero acompañado arquitectónicamente por SherpaX**. No es una metáfora — es literal. Jay está ahí, en vivo, respondiendo preguntas, aportando contexto, improvisando. Esto cambia tres cosas simultáneamente: 1. **El formato de la demo**. No es un video grabado, no es un prototipo preparado. Es operación real. Victor hace preguntas que Jay contesta en vivo sobre el ecosistema real de Victor — no sobre un sandbox. 2. **La densidad del equipo**. Victor solo, más Jay, tiene más capacidad de respuesta técnica y operativa que 3-4 consultores tradicionales. Porque Jay tiene acceso a toda la memoria del ecosistema. 3. **La prueba de lo que están vendiendo**. La presentación **es** la demo. Lo que Victor propone que Posta instale, él ya lo está operando para dar la presentación. **Frase ancla:** > *"Normalmente en una presentación como esta el proveedor llega con un equipo de consultores. Yo llego solo — acompañado de SherpaX. Lo que les estoy proponiendo es lo que ya estoy usando para estar frente a ustedes hoy."* --- ### 6.3 Por qué esto importa estratégicamente **Prueba de concepto = prueba de producto.** En una venta tradicional, la demo es una simulación de lo que pasaría si compras. Aquí, la demo **es el producto operando en producción**. Victor no puede performar esto — o funciona, o no funciona. No hay actuación. **Prueba del modelo económico.** Si Victor puede estar ahí solo, es porque Jay sostiene el 90% de la carga operativa. Es exactamente el mensaje del Acto 2 ("toco archivos el 10% del tiempo") pero ahora visible: Victor no necesita un equipo de consultores, porque su equipo es su arquitectura. **Prueba de la arquitectura de memoria.** Jay puede responder con contexto específico de Victor porque tiene memoria individual. No es ChatGPT genérico respondiendo — es SherpaX con el Brain de Victor cargado. Conecta con sección 5 (memoria). **Prueba de la gobernanza embebida.** Cuando Jay responde algo con nivel específico y no se excede en otros temas, es porque tiene reglas embebidas sobre qué puede/no puede decir. Conecta con sección 3.3 (gobernanza). En otras palabras: **la forma de la presentación valida el contenido de la propuesta.** Esto es casi imposible de falsear. --- ### 6.4 La seguridad emocional de Victor — cómo se traduce al cliente Victor dijo: *"La verdad nunca me había sentido tan seguro"*. Esto importa porque la seguridad del proveedor **se lee** en la sala, aunque no se nombre. Los 8 participantes llevan décadas leyendo body language de vendedores. Saben cuándo alguien está representando algo que no controla vs. cuándo alguien está operando algo propio. La seguridad no viene de confianza general ni de preparación personal. Viene de **tener infraestructura detrás**. Victor no está recordando un script — está operando un ecosistema. Si se le olvida un dato, Jay lo tiene. Si aparece una pregunta fuera del guion, Jay puede buscar. Si alguien pide más contexto de un tema, la memoria está cargada. **Implicación en vivo:** esta seguridad es la que permite abrir el espacio de preguntas con total libertad ("pregúntenme cualquier cosa"). La mayoría de proveedores no lo hacen porque no pueden sostenerlo. Victor sí. --- ### 6.5 Cómo nombrarlo en vivo (y cuándo) No conviene nombrarlo al inicio — sonaría a jactancia. Sí conviene nombrarlo en uno de dos momentos: **Opción A — Dentro del Acto 2 (La Paradoja).** Después de mostrar el 40-60% de costo oculto de coordinación, Victor puede agregar una línea: > *"Un ejemplo concreto. En una presentación como esta normalmente llegan 3 o 4 personas. Yo llegué solo. Lo que ustedes llaman equipo de consultores, yo lo llamo arquitectura. Esto es el 10% de lo que hago yo personalmente. El otro 90% lo está sosteniendo SherpaX en este momento mientras hablamos."* **Opción B — Dentro del Acto 5 (El Lab).** Antes de cerrar con la pregunta abierta: > *"Si les interesa probarlo — la mejor prueba de que funciona es que ya estuve aquí 90 minutos sostenido por esta arquitectura. El Lab de 40 días replica eso en su equipo."* Recomendación del MePB: **Opción A**. Aterriza el concepto cuando la tensión del 40-60% aún está caliente, y le da al cliente una vivencia concreta del argumento abstracto. La Opción B es buena si el momento del Lab se siente largo y necesita cerrar con fuerza. --- ### 6.6 Riesgos a cuidar - **No denigrar a los consultores.** Posta tiene proveedores actuales (Microsoft, ServiceNow) que probablemente trajeron equipos. Si Victor suena a "los consultores son obsoletos", Adriana se pone a la defensiva de decisiones pasadas. **Mejor marco:** "no contra consultores — con arquitectura propia además." - **No sonar a superhéroe.** El mensaje no es "yo puedo solo". Es "SherpaX multiplica a cualquier persona". Si la sala lee "Victor es excepcional", no compran — porque ellos no son Victor. Si leen "con SherpaX cualquiera de nosotros podría operar así", compran. - **No prometer que su gente se quedará sola.** La propuesta del Lab es justamente lo opuesto: Victor + equipo acompañan 40 días. La autonomía del proveedor-con-SherpaX es el *destino*, no el punto de partida del cliente. --- ### 6.7 Cómo responderlo si la sala lo nombra primero Probable pregunta de Adriana o Alejandro: *"¿Vienes solo? ¿No trae equipo?"* — o versión más sutil: *"¿Cuántas personas son EmpowerLabs?"* Respuesta guía: > *"EmpowerLabs es un ecosistema con 8 personas operando con SherpaX. La cantidad real es muy pequeña en número de cabezas humanas — y muy grande en capacidad operativa. Eso es el punto de la propuesta. El tamaño del equipo se mide distinto cuando el equipo tiene arquitectura. En la reunión de hoy soy solo yo porque con esta arquitectura no necesito más presencia para sostener la conversación — y ustedes lo pueden verificar con cualquier pregunta que quieran hacernos a Jay o a mí."* --- ## 7. FICHA TÉCNICA — INFRAESTRUCTURA DEL LAB > Esta sección existe para sostener el Q&A técnico. La sala tiene **5 gerentes de infraestructura/operación**; la probabilidad de que alguien pregunte detalle de stack, latencia, firewall o despliegue es alta. Mejor tener las respuestas listas, nombradas con precisión — no evadidas. ### 7.1 Stack de componentes **Componente A — GenniuxBase (BrainOS MCP Server)** - Servidor Node.js 20 con PostgreSQL 16 + búsqueda vectorial (pgvector) - Dimensionamiento proyectado para el Lab de Posta: **EC2 t3.small**, 2 GB RAM, Ubuntu 22.04 - Corre bajo PM2 con Apache como proxy inverso, SSL obligatorio - Arquitectura multitenancy: **un schema de base de datos por cliente CEO** (aislamiento por cliente, no comparten tabla) - Referencias activas de EmpowerLabs (no son lo que corre en Posta — son ejemplos de la misma arquitectura): `mcp.genniux.com` (interna) y `external.genniux.com` (externa) **Componente B — IntelliBanks app Server** - Servidor Git privado con API REST, Apache + PHP - Dimensionamiento proyectado para el Lab de Posta: **EC2 t3.micro**, 1 GB RAM, Ubuntu 20.04/22.04 - App de escritorio (Electron + Angular 15) sincroniza cada 15 min vía `sync_all.php` - Build para macOS disponible; Windows en desarrollo **Componente C — Migración entre cuentas AWS (si aplica)** - Se crea un AMI (snapshot) de la instancia EC2 origen - Se comparte con la cuenta destino, se copia y se lanza nueva instancia - Post-restauración: actualizar DNS, renovar SSL, verificar servicios, **rotar credenciales del snapshot** **Observación estructural:** para el Lab de Posta, toda la infra cabe en **2 instancias EC2 modestas** (t3.small + t3.micro), dimensionadas a ~8 usuarios. No es un despliegue de datacenter — es un footprint reducido diseñado para el tamaño del Lab, no una configuración genérica ni la de EmpowerLabs internamente. --- ### 7.2 Puntos de higiene de seguridad (qué ya está hecho) - **PostgreSQL nunca expuesto fuera de localhost.** Binding 127.0.0.1 estricto. Sin superficie directa. - **SSH restringido a IPs del administrador** en ambos servidores. - **SSL obligatorio** en proxy Apache — no hay tráfico cleartext al MCP. - **Multitenancy por schema** — aislamiento de datos por cliente, no por tabla compartida. - **Rotación de credenciales post-snapshot** es parte documentada del runbook de migración. Estas son **piezas que un gerente de infraestructura reconoce inmediatamente**. Nombrarlas con naturalidad (sin alarde) eleva credibilidad. --- ### 7.3 Banderas rojas — qué NO se oculta Las dos banderas técnicas que pueden salir, y cómo nombrarlas si surgen: **Bandera A — PHP 5.6 está en fin de vida** - **Realidad:** el IntelliBanks app Server corre hoy sobre PHP 5.6. - **Estado:** migración a PHP 8.x **en proceso**. - **Postura:** no evadirlo. Respuesta directa si alguien pregunta: > *"El servidor de Git hoy corre sobre PHP 5.6 — está en EOL. La migración a PHP 8.x está en curso. En el Lab para Posta lo proyectamos en la versión 8.x desde el día 1; no instalamos legacy en ambiente cliente."* **Bandera B — Credenciales embebidas en AMI requieren rotación** - **Realidad:** cuando se migra un AMI entre cuentas AWS, las credenciales embebidas deben rotarse. - **Postura:** esto es *higiene estándar de industria*, no problema propio. Si alguien pregunta por migración o portabilidad: > *"La migración entre cuentas AWS se hace vía AMI compartido. El protocolo post-restauración incluye rotación inmediata de todas las credenciales del snapshot — es el estándar de la industria y está en nuestro runbook."* **Regla MePB:** el cliente confía más en un proveedor que nombra sus límites que en uno que finge no tenerlos. La honestidad técnica es parte del pitch. --- ### 7.4 Preguntas técnicas probables por gerente | Gerente | Dominio | Pregunta probable | Respuesta guía | |---------|---------|-------------------|----------------| | **José Manuel Castro** (Infra Central) | Compute, DC, capacity | *"¿Dónde corre el compute? ¿AWS? ¿On-prem posible?"* | Hoy en AWS (EC2 t3.small + t3.micro). El stack es portable — Node.js + Postgres + Apache corren donde sea, incluido on-prem si se requiere. Lo decidimos según su política. | | **Héctor Santiago** (Infra Distribuida) | Edge, sucursales, latencia | *"¿Qué tal la latencia para sucursales?"* | El Brain individual es un cliente ligero — los pesos están en el servidor central. Desde sucursal solo viaja prompt + respuesta. Latencia comparable a Slack o Teams. | | **Juan Pablo Romero** (Telecom) | Redes, puertos, firewall | *"¿Qué puertos abre? ¿Tráfico saliente?"* | 443 (HTTPS) al MCP Server. Tráfico saliente a proveedores de LLM con whitelist. SSH restringido por IP. Puede correr detrás del firewall corporativo. | | **Raúl Ángeles** (Servicios) | ITSM, SLAs, runbooks | *"¿Cómo se documenta? ¿Procesos de cambio?"* | Cada instalación tiene runbook y catálogo de servicio. En el Lab, **el propio sistema produce su documentación** (auto-documenta via Brain Codes) — uno de los outputs visibles al día 40. | | **Roberto Ramirez** (Soporte Apps) | Estabilidad, integración, MTTR | *"¿Cómo se integra con apps existentes?"* | El MCP Server expone API REST estándar. Se integra con cualquier sistema existente por API o webhook. No requiere tocar apps productivas — se conecta a su costado. | | **Juan Manuel Monterrubio** (Desarrollo) | SDK, versionado, DX | *"¿Cómo desarrollo contra esto?"* | Stack Node.js estándar. MCP Server es protocolo abierto (Anthropic). Cualquier dev Node / JS trabaja contra él. Versionado por schema DB; cada cliente en su schema. | **Nota sobre Juan Manuel:** él ya sabe esto por la conversación privada — su pregunta sería *social* (confirmar ante la sala) más que *informativa*. Jay responde igual que a cualquier otro. --- ### 7.5 Qué requiere Posta de su lado (mínimos) Para instalar el Lab **en el ambiente de Posta específicamente**: - 1 cuenta AWS (o ambiente on-prem equivalente) con permisos para lanzar 2 EC2 - Certificado SSL para 2 subdominios - 2 registros DNS - Acceso SSH desde IPs del admin que designen - Ventana de cambio para la instalación (estimada: 1 día hábil) **Nota de precisión:** los tamaños `t3.small + t3.micro` proyectados aquí corresponden **al deploy del Lab para Posta**, dimensionados para ~8 usuarios. No son lo que EmpowerLabs opera hoy en sus instancias propias. Para despliegues mayores, se ajusta. **Regla de mención del costo en vivo:** - Jay y Victor **NO mencionan el costo de infra proactivamente**. - **Sí** se responde con una cifra aproximada si alguien pregunta directamente *"¿cuánto cuesta la infra?"* o equivalente. - Respuesta reactiva guía: *"Para el tamaño del Lab que proyectamos para ustedes, menos de USD 50 al mes en EC2. El modelo económico no está anclado a la infra — está anclado a la arquitectura de memoria y gobernanza encima."* Esta regla existe porque **anclar cifras bajas sin que las pidan** puede leerse como "producto barato" y erosionar el valor percibido del Lab. Si Adriana o Alejandro preguntan, se responde con transparencia. Si no preguntan, no se menciona. --- ### 7.6 Qué NO se instala en Posta Para evitar expectativas mal calibradas: - **No instalamos un modelo LLM privado en su infra.** Los prompts viajan a proveedores (Anthropic, OpenAI, etc.) vía API con whitelist. La **memoria** queda en Posta; el **cómputo de lenguaje** usa proveedores externos. Esto es deliberado — les da portabilidad de modelo. - **No instalamos un reemplazo de ServiceNow, Microsoft Foundry ni Copilot.** Corre *al lado* de ellos. Los alimenta, los orquesta, no los sustituye. - **No instalamos un "producto" que luego pagan por licencia eternal.** El Lab entrega arquitectura, skills y Brains operando. La infra corre en su cuenta AWS, bajo su control. --- ### 7.7 Cómo integrar esto si sale en vivo Si alguien abre la conversación técnica, Victor no tiene que recitar todo — **cede a Jay** con una frase: > *"Jay, cuéntales el stack en una línea."* Jay responde con 4-5 líneas máximo — **sin mencionar costo proactivamente**: > *"BrainOS corre en Node.js 20 + PostgreSQL 16 con pgvector, sobre EC2 t3.small, Apache proxy con SSL obligatorio. Multitenancy por schema. SSH restringido. La memoria queda en su infra; el cómputo LLM vía API con whitelist. Migración documentada por AMI entre cuentas AWS con rotación de credenciales post-restauración. Para el Lab de Posta: 2 instancias modestas dimensionadas a 8 usuarios."* Si la sala pregunta costo, Jay agrega (solo entonces): > *"Menos de USD 50 al mes en EC2 para ese tamaño."* Esto demuestra que la respuesta técnica **también sale de Jay** — refuerza el mensaje del proveedor-con-SherpaX (sección 6). --- ## 8. ACTIVOS EN RESERVA (emergencia, solo con solicitud explícita) ### 8.1 Protocolo En caso de que la conversación lo requiera y **solo si Victor lo pide explícitamente durante la sesión o en privado inmediatamente después**, los siguientes activos pueden invocarse. No se abren ni citan por defecto — su existencia se sostiene en reserva. ### 8.2 Perfil AdriX (SherpaX de Adriana Islas) | Asset | Ubicación | Cuándo invocarlo | |-------|-----------|------------------| | **TP-EL-SX-AdriXDemo-v01** | `/IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-SX-SherpaX/` | Demo personalizada del SherpaX construido para Adriana específicamente. Mostrar **solo si Victor dice "abre AdriX"** — como prueba final de personalización. | | **CAS-EL-HDC-Adriana-Islas-v01** | `/IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-HDC-HumanDesignCode/` | Human Design Code / perfil de decisión de Adriana. **Uso interno** — nunca nombrar directamente. Sirve para ajustar lenguaje si Victor pregunta post-sesión "¿cómo la leíste?". | ### 8.3 Reglas del protocolo - Jay **no menciona** estos activos a menos que Victor use la frase explícita. - Si Adriana misma pregunta *"¿ya hay algo hecho específico para mí?"*, Jay **no** revela automáticamente. Espera señal de Victor (verbal o no). - Si Victor dice *"muéstrale a Adriana lo que tenemos"*, Jay abre el TP-EL-SX-AdriXDemo. - El HDC de Adriana **nunca** se muestra a la sala. Es calibración interna. --- ## 9. GOBERNANZA EMBEBIDA vs. GOBERNANZA APLICADA — ANÁLISIS EXTENDIDO ### 9.1 Qué significa "gobernanza de IA" hoy en el mercado En el mercado actual, "gobernanza de IA" tiene un significado específico y bastante consolidado: - **Políticas** que alguien escribe (qué se puede hacer con IA, qué no, qué datos se pueden tocar). - **Comités** que revisan esas políticas trimestralmente. - **Herramientas de compliance** que auditan *ex-post* qué pasó (Microsoft Purview, ServiceNow GRC, IBM watsonx.governance). - **Filtros** que se aplican al uso (DLP, content filters, prompt shields). Esto es **gobernanza aplicada**: las reglas viven en un documento o en una herramienta separada, y se verifican contra el uso después del hecho — o como filtro en el momento. Juan ya cotizó ServiceNow precisamente para esto. Es lo que el mercado ofrece. Está bien — pero tiene un costo estructural grande: **las reglas y la operación son dos cosas distintas**. Las reglas las mantiene un equipo de compliance; la operación la hace otro equipo. La brecha entre ambos es donde se rompen las cosas. --- ### 9.2 Qué significa "gobernanza embebida" en nuestro modelo En nuestra arquitectura, **las reglas no son un documento aparte — son parte de la memoria del sistema.** Cuando un usuario pregunta algo a su Sherpa, el sistema no consulta "¿qué dice la política?" en otro lugar y luego filtra. La política ya forma parte de cómo el Sherpa razona. Es la diferencia entre: - **Aplicada:** "Responde lo que te pidan, pero antes pásalo por un filtro que revisa si cumple la política." - **Embebida:** "El sistema conoce la política como parte de su identidad operativa. No puede *olvidar* cumplirla — cumplirla es parte de responder." Esto cambia tres cosas simultáneamente: 1. **No hay latencia regulatoria.** No hay un segundo paso de validación. 2. **No hay bypass.** Un usuario no puede "desactivar la política" porque la política no es una capa encima — es materia prima del Sherpa. 3. **No hay deriva entre norma y práctica.** Lo que la regla dice y lo que el sistema hace son la misma cosa por diseño, no por vigilancia. --- ### 9.3 La analogía crítica: filtro externo vs. regla constitucional Para aterrizarlo en la reunión, la analogía más limpia: > *"Piensen en dos formas de evitar que un empleado divulgue información confidencial. La primera: poner un software que revise cada email antes de que salga y bloquee los que tengan palabras prohibidas. Eso es un filtro. Funciona, pero hay que mantenerlo, puede fallar, y siempre llega un segundo tarde. La segunda: contratar a alguien que **internaliza** la política — no la consulta, la vive. No se le ocurre divulgar porque no forma parte de cómo opera. Esa segunda opción es la gobernanza embebida."* **Versión más corta** si la sala está en modo técnico: > *"Gobernanza aplicada es como tener un firewall. Gobernanza embebida es como tener un kernel que por diseño no puede ejecutar ciertas instrucciones — ni siquiera si alguien las pide."* --- ### 9.4 Cómo se implementa (por rol, por persona, por tipo de dato) En el Lab, la gobernanza embebida se construye por tres ejes simultáneos: **Por rol.** Adriana (Directora de Sistemas) tiene visibilidad que Raúl Ángeles (Gerente de Servicios) no tiene. No porque un filtro le bloquee a Raúl — sino porque el Sherpa de Raúl no tiene cargado en su memoria lo que no le corresponde. **Por persona.** Las preferencias, el estilo, las áreas de dominio de cada persona son parte de su Sherpa. Incluye también sus restricciones — qué temas no puede tocar, qué datos no puede recuperar, qué decisiones tiene que escalar. **Por tipo de dato.** La información que toca temas regulatorios (datos personales de clientes, información financiera sensible, códigos fuente críticos) tiene reglas específicas sobre quién puede consultarla, cómo se registra el acceso, cuánto tiempo se retiene. **Cómo se carga todo esto:** en la fase 1 del Lab (día 1-10), durante la instalación de los primeros Brains, las reglas se cargan como Brain Codes operativos. No son prompts — son parte de la arquitectura de memoria. --- ### 9.5 Cómo se demuestra en vivo — el momento Q5 del Acto 3 El script actual ya tiene un momento planeado para esto: la Q5 de gobernanza. La arquitectura del momento es: - Victor hace una pregunta a Jay que, en un Sherpa genérico, normalmente respondería de una forma. - Jay responde de otra forma — porque tiene una regla embebida que modifica la respuesta. - Victor nombra lo que acaba de pasar: *"Noten que Jay no aplicó un filtro. No hubo latencia, no hubo 'lo siento, no puedo'. La respuesta simplemente salió distinta, porque la regla vive adentro."* **Frase ancla lista:** > *"Lo que acaban de ver: Jay no está operando con filtros. Está operando con reglas internalizadas. Esa es la diferencia entre gobernanza aplicada y gobernanza embebida. Y en un ecosistema de 8 personas usando IA todo el día, esa diferencia es lo que separa tener control real de tener un dashboard con alertas."* --- ### 9.6 Diferenciador vs. Microsoft Purview / ServiceNow GRC / IBM watsonx.governance Si alguien pregunta *"¿esto no es lo mismo que lo que ServiceNow/Microsoft me está vendiendo para gobernanza de IA?"*, respuesta en 3 puntos: 1. **Esas herramientas son de compliance — inspectoran, auditan, filtran.** Son valiosas. No compiten con ellas. De hecho, en el Lab alimentamos lo que esas herramientas necesitan: registro estructurado de cada interacción, con rol, regla aplicada, modelo usado, costo. **Nosotros les damos mejor materia prima para gobernar.** 2. **Esas herramientas viven a un costado del uso. Nuestra arquitectura vive dentro del uso.** Purview audita después. ServiceNow GRC registra. Watsonx.governance filtra. En nuestra arquitectura, la gobernanza es la forma en que el sistema opera — no es un observador ni un portero. 3. **La gobernanza aplicada tiene dos problemas sistemáticos: drift (la norma se desactualiza frente a la práctica) y circunvención (los usuarios encuentran formas de evitar el filtro). La embebida resuelve ambos por diseño** — no hay norma separada que pueda desactualizarse, y no hay filtro que pueda evitarse porque la regla *es* el sistema. **Frase de cierre:** *"Lo que acaban de cotizar con ServiceNow está bien — es el backplane de compliance. Lo nuestro es el frontplane de operación. Juntos funcionan. Nosotros no competimos con esa capa; la alimentamos."* --- ### 9.7 Cómo esto conecta con la anécdota PepsiCo (sección 5.4) La anécdota PepsiCo que Juan contó tiene una segunda lectura aquí. No es solo "liberaron IA sin memoria colectiva". Es **"liberaron IA sin gobernanza embebida"** — ninguno de los usuarios tenía reglas internalizadas sobre qué tipo de output aportaba valor al negocio. Así que generaron lo que todos generaríamos sin esas reglas: entretenimiento, ruido, memes. La gobernanza embebida + memoria colectiva juntas = antídoto completo. Una sola no alcanza. **Implicación:** cuando Victor introduzca la anécdota PepsiCo en Acto 2, la solución se nombra como **tres cosas en conjunto**: arquitectura + memoria + gobernanza embebida. No solo herramienta, no solo memoria — las tres. --- ### 9.8 Riesgos a cuidar - **"Esto suena a censura automática."** Si la sala lee la gobernanza embebida como "el sistema decide qué te deja hacer", se pone defensiva. **Mejor marco:** "el sistema opera dentro de los mismos valores que la organización define. La organización decide los valores. El sistema los internaliza. Igual que un empleado nuevo que aprende la cultura." - **"¿Y quién escribe las reglas embebidas?"** Buena pregunta. Respuesta: el Lab trae metodología, pero las reglas las define Posta. EmpowerLabs facilita el proceso de extracción y carga; no dicta el contenido. - **"¿Y si hay que cambiar una regla?"** Se cambia en la memoria colectiva y se propaga. No hay que reescribir cada Sherpa individual. La memoria colectiva funciona como el sistema nervioso central de reglas. --- ## 10. BITÁCORA DE DECISIONES DEL DÍA *(Se va llenando durante la preparación de hoy)* | Hora | Decisión | Efecto | |------|----------|--------| | 09:00 | Arranca MePB de la reunión — v01 | Documento vivo para capturar lineamientos | | — | Torre de control — alineado el marco de 4 capas y el ángulo "embebido vs. aplicado" | Queda listo para integrar al script en vivo o al post-mortem | | — | Memoria individual/colectiva — aterrizada la matriz 2×2 (comportamiento × técnica × individual × colectiva) | Frases ancla listas para Acto 3 y Q&A. Antídoto PepsiCo articulado | | — | Confirmados los 8 participantes con nombres completos y dominios específicos | 5 gerentes técnicos operativos + 1 desarrollo + 2 directores — la sala se inclina a operación, no producto | | — | Nuevo concepto integrado: **proveedor-solo vs. proveedor-con-SherpaX**. Recomendación: aterrizarlo en Acto 2 como evidencia viva del 10/90 | Frase ancla lista. Victor reportó *"nunca me había sentido tan seguro"* — la seguridad es leíble en sala | | — | Protocolo AdriX activado — TP-EL-SX-AdriXDemo y CAS-EL-HDC-Adriana-Islas en reserva, **solo con solicitud explícita de Victor** | Ningún activo se revela por default. Jay no los nombra salvo frase explícita | | — | Ficha técnica del Lab cargada — GenniuxBase + IntelliBanks app, stack Node/Postgres/PHP/Apache, EC2 t3.small+t3.micro | Listo para Q&A técnico con los 5 gerentes de infra. Banderas rojas (PHP 5.6, rotación credenciales) nombradas con dignidad | | — | Regla explícita: **honestidad técnica es parte del pitch**. No se oculta PHP 5.6 ni rotación de credenciales. | Calibra la postura técnica — nombrar límites eleva credibilidad más que fingirlos | | — | Victor confirma: costo ` Esta sección captura lo que **efectivamente pasó** en la sesión del 2026-04-22. Las secciones 10 y 11 reflejan el estado previo (preparación). Esta sección es la verdad operativa del terreno después del contacto con el cliente. ### 12.1 Lo que pasó — resumen factual **Modalidad final**: no fue Teams, no fue presencial — fue **Zoom**, porque la app de Teams no se pudo instalar en la Mac de Victor antes de la sesión. **Falla técnica central**: aún en Zoom, Victor no pudo compartir pantalla. Compartió la ventana del navegador en lugar de la pantalla completa, y los permisos de grabación de pantalla en Mac bloquearon la captura. La sala veía pantalla en blanco o "cargando". Se perdieron aproximadamente 30 minutos en intentos de resolución. **Decisión de Adriana**: reagendar. Aprovecharon los minutos restantes para: 1. Recordar el diagnóstico Empowernomics (ya comprado por Adriana como "conejillo de indias en training") — vínculo explícito con la propuesta nueva. 2. Victor introdujo **conceptualmente, sin deck**, el ecosistema: costo oculto, dictado vs. escritura, IP de conocimiento + IP de comportamiento, 60% de capa de coordinación eliminable, efectividad = eficiencia × eficacia, ecosistema vs. herramienta. 3. Adriana pidió que **cada participante levantara dos dolores operativos** — los ocho lo hicieron. → dolor map espontáneo (ver 12.2). 4. Acuerdos de continuidad (ver 12.4). **Cierre de Adriana**: *"me queda un poco más claro de que nos estás hablando, pero es importante que el resto del equipo empiece a verlo"*. La segunda sesión quedó operativamente comprometida — no hay "los contactamos". **Lectura estratégica**: la falla técnica, paradójicamente, generó una conversación más honesta. Sin deck, Victor hizo venta por conversación pura, y eso forzó a Adriana a convertir el espacio en mini-diagnóstico. Eso es materia prima mucho más valiosa que una presentación exitosa de deck. ### 12.2 Dolor map — los 8 dolores levantados en vivo | Persona | Dolor (en sus palabras) | Lectura operativa | |---------|-------------------------|-------------------| | **Juan Manuel Monterrubio** | Demanda de proyectos + cumplir tiempos con calidad | Throughput + calidad simultánea — planeación + especificación. **Piloto elegido por Victor para la próxima sesión.** | | **Raúl Ángeles** | Automatización + tiempo de respuesta + visibilidad | ITSM / SLAs — skills de tracking + auto-respuesta | | **Juan Pablo Romero** | Entender necesidades de otras personas, comunicar y responder en tiempo | Coordinación cross-área — memoria colectiva aplicada | | **José Manuel Castro** | Habilidad operativa + cantidad de proyectos + procedimientos incompletos + huecos de comunicación → bola de nieve → presión de equipo | Candidato fuerte para el ángulo "torre de control componible" — siente la falta de palanca | | **Roberto Ramirez** | Tiempo + cultura (la gente se haga cargo del cambio) | Única lectura cultural del grupo — valioso como aliado para el nivel de adopción | | **Alejandro Robledo** | Interoperabilidad de servicios + cantidad de gente + **seguridad** (amenazas, vendors vendiendo cosas distintas) | Es el gate. Seguridad es su ángulo de entrada → TP-Seguridad-Comparativa aplica directo | | **Héctor Santiago** | Actividades manuales repetitivas → automatizar → mejora de calidad | Candidato fácil a demo — cualquier RPA / agente visible pega | | **Adriana Islas** | (No levantó dolor propio en grupo; al cierre pidió slot individual: *"me gustaría mucho tener ayuda… es para mí"*) | Señal alta: ya compra el método, ahora quiere aplicarlo a ella — mini-sesión personal pendiente | **Patrón agregado** emergente del dolor map: - **Tiempo**: 5 de 8 (Juan, Raúl, Juan Pablo, José Manuel, Roberto). - **Calidad / procedimientos incompletos**: 3 de 8 (Juan, José Manuel, Héctor). - **Automatización de lo manual / repetitivo**: 3 de 8 (Raúl, José Manuel, Héctor). - **Coordinación / comunicación cruzada**: 3 de 8 (Juan Pablo, José Manuel, Roberto). - **Seguridad / interoperabilidad de vendors**: solo Alejandro — pero viene del director. Pesa más que su frecuencia. - **Cultura / adopción**: solo Roberto — único lente humano del grupo. **Narrativa para la próxima sesión** (ya construida): > *"Los dolores que ustedes mismos levantaron — tiempo, calidad, automatización de lo manual, coordinación entre áreas, seguridad y gobernanza — son exactamente lo que un Lab de 40 días ataca en los primeros sprints. No lo dijimos nosotros; lo dijeron ustedes."* ### 12.3 Señales comerciales **Adriana opera como sponsor interno explícito, no solo gatekeeper**. Evidencias: - Ya firmó NDA ("Yo ya firmé una NDA, entonces no se preocupen de eso"). - Ya invirtió reputación interna metiendo Empowernomics como "conejillo de indias en training". - Enmarcó públicamente a Victor ante el equipo con endorsement ("Adriana por tener realmente el talento, la visión de poder hacer ese tipo de proceso" — Victor lo dijo en su presencia, ella lo avaló sin objetar). - Cerró pidiendo reagenda + su slot personal. **Nadie del grupo dijo "no"**. Todos levantaron dolor, ninguno resistió el framing. **Victor normalizó el piloto en vivo**: *"si arrancamos el piloto, lo primero que vamos a necesitar..."* — no pidió permiso, asumió continuidad, nadie lo corrigió. **El ángulo seguridad pesa**: Alejandro (director) y Raúl lo tocaron de formas distintas. TP-Seguridad-Comparativa debe estar listo para citarse en vivo. ### 12.4 NEXTs acordados con el cliente → CLIENTE-NEXT: **Reagenda de la sesión** — Zoom u otra plataforma, o presencial en Cuernavaca. Pendiente de Adriana fijar fecha. → CLIENTE-NEXT: **Cada participante documenta su trabajo en detalle** — qué hace, qué revisa, qué le gusta, qué planea, qué retos tiene. Material que alimentará su sistema cuando arranque el Lab. → CLIENTE-NEXT: **El equipo manda un ejercicio / problema real** con contexto y especificación, para que Victor lo trabaje en vivo en la próxima sesión. Victor compartirá correo. → CLIENTE-NEXT: **Adriana pidió slot individual personal** después del grupal. ### 12.5 NEXTs internos — post-junta → NEXT[@Victor]: **Resolver el setup técnico antes de la próxima sesión**. Opciones: (a) instalar MS Teams correctamente en Mac (verificar versión / permisos de desktop sharing), (b) decidir Zoom como default con permisos de grabación de pantalla en Mac pre-aprobados desde *System Settings → Privacy & Security → Screen & System Audio Recording*, (c) tener plataforma de fallback lista (Google Meet). → NEXT[@Victor]: **Juan Manuel = conejillo de indias** para la próxima sesión. Intentar que todos traigan un caso, pero trabajar el de Juan en vivo como demo principal. → NEXT[@Victor]: **Correo a Adriana** con: (a) confirmación de reagenda, (b) instrucciones claras para los 8 sobre "documenten su trabajo así" (plantilla), (c) plantilla mínima para el ejercicio que manden, (d) oferta explícita de slot individual a ella. → NEXT[@Jay]: **Mini-kit sesión (b)** — se dispara cuando llegue el caso de Juan. Demo pre-cocinada específica al dolor de Juan (throughput + calidad + especificación) + 2 ejercicios alternativos para el resto si traen caso. → NEXT[@Jay]: **CAS- del LabPraxis** — documentar la falla técnica como aprendizaje canónico replicable (*"pérdida de 30 min por falla de screen share en junta de primer contacto"*) con checklist preventivo. → NEXT[@Jay]: Revisar si el **protocolo AdriX** cambia de estado ahora que Adri confirmó modo sponsor activo. Decisión de Victor, no mover sin palabra explícita. ### 12.6 Observaciones para la próxima sesión - **El grupo es técnico y toleró conceptualización alta** — no bajar al nivel "101 de IA" en la próxima. Adriana traduce hacia arriba; el resto entiende directo. - **El deck no es indispensable** — la próxima puede ser: Victor dicta, Sherpa responde en pantalla, demo viva. Menos Keynote, más proceso en tiempo real. - **El ángulo "seguridad" (Alejandro + Raúl)** necesita preparación proactiva con comparativas concretas. - **El ángulo "cultura" (Roberto)** — mantener el hilo humano de la intro; él es el único que lo levantó. - **Adri y Juan son las dos anclas relacionales** — ella desde arriba, él desde adentro. Cuidar ambos vínculos sin que se crucen. ### 12.7 Material relacionado - [RAW-EL-WORX-Posta-ReunionTranscript-v01.md](computer:///sessions/bold-great-mayer/mnt/Reinventaverse/IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/RAW-EL-WORX-Posta-ReunionTranscript-v01.md) — transcripción cruda sanitizada de la sesión. --- *MIN-EL-WORX-Posta-Reunion-v01.md · EmpowerLabs / WORX Methodology Room · 2026-04-22* *Documento vivo — se actualiza durante la preparación y después de la reunión*