📄 GUÍA PARA RECURSOS EXTERNOS¶

Ecosistema IA BKM¶

Para qué sirve este documento¶

Esta guía es el punto de entrada obligatorio para cualquier persona o equipo externo que vaya a construir un sistema dentro del Ecosistema IA de BKM.

No es un manual técnico completo. Es el marco mínimo que todo recurso externo debe conocer y aceptar antes de empezar a trabajar. Su función es garantizar que lo que se construye es coherente con el ecosistema — independientemente de quién lo construya.

Antes de escribir una sola línea de código o configurar ningún sistema, el recurso externo debe haber leído este documento y haber confirmado al Responsable IA que lo ha entendido.

1️⃣ Qué es el Ecosistema IA de BKM¶

BKM tiene un ecosistema de inteligencia artificial gobernado: con un stack tecnológico de referencia, estándares de arquitectura, roles definidos y decisiones documentadas.

No es una colección de herramientas sueltas. Es un sistema coherente diseñado para crecer sin generar deuda técnica ni silos.

Tu trabajo como recurso externo es construir dentro de ese ecosistema, no crear algo paralelo a él.

Los documentos de referencia que debes conocer antes de empezar:

Documento	Por qué lo necesitas
Stack Tecnológico	Qué herramientas puedes usar y cuáles requieren aprobación previa
Plantilla de Arquitectura del proyecto	Qué debes construir exactamente — es tu especificación técnica
Marco de Operativa IA	Cómo se gestiona el sistema cuando esté en producción
Roles y Responsabilidades	Con quién te coordinas y quién aprueba qué

Todos están disponibles en: bkm-ecosistema-ia.pages.dev

2️⃣ Tu rol: Responsable Técnico Externo¶

Durante la construcción del proyecto, tu rol es el de Responsable Técnico Externo.

Tu función es construir lo que está definido en la Plantilla de Arquitectura aprobada, siguiendo los estándares del ecosistema, bajo la supervisión del Responsable IA de BKM.

Lo que decides tú:

Implementación técnica dentro del stack aprobado.
Estructura interna del código o configuración.
Soluciones a problemas técnicos dentro del alcance definido.

Lo que decide el Responsable IA:

Cualquier desviación respecto a la Plantilla de Arquitectura aprobada.
Incorporación de herramientas no previstas inicialmente.
Cambios en el flujo técnico o en los sistemas implicados.
Cualquier decisión con impacto en la arquitectura del ecosistema.

Lo que decide el Responsable Funcional:

Si el sistema hace lo que el área de negocio necesita.
Validación del prompt maestro si el sistema incluye un LLM.
Aprobación antes de activar el sistema en producción.

3️⃣ Stack tecnológico — qué puedes usar¶

El ecosistema tiene un stack de referencia. Antes de elegir cualquier herramienta, verifica que está en el stack o que ha sido aprobada por el Responsable IA.

Stack de referencia del Core IA:

Infraestructura: Google Cloud Platform (GCP)
Despliegue: Cloud Run
APIs: FastAPI (Python)
Gestión de conocimiento: LlamaIndex
Modelos LLM: vía Vertex AI (agnóstico de modelo)
Base de datos estructurada: BigQuery
Almacenamiento documental: Google Cloud Storage (GCS)

Stack de referencia de Operativa Ligera:

Automatización y orquestación: n8n
Asistentes LLM gestionados: SuperChat, Claude, ChatGPT Teams u equivalentes bajo contrato
Integraciones externas: Make (si está aprobado para el proyecto)

Regla crítica: si necesitas una herramienta que no está en el stack de referencia, comunícalo al Responsable IA antes de usarla. No después. El proceso de evaluación existe para proteger la coherencia del ecosistema, no para bloquear el trabajo.

4️⃣ Principio de Portabilidad Mínima¶

Todo lo que construyas debe poder extraerse y desplegarse en otro entorno si el ecosistema evoluciona.

Esto significa en la práctica: - Los prompts, la lógica de agentes y las reglas de negocio deben estar en archivos propios — no enterrados en configuraciones propietarias de una plataforma. - El código de backend debe estar documentado y ser mantenible por otro desarrollador. - Las integraciones entre sistemas deben estar documentadas con suficiente detalle para que puedan rehacerse si cambia alguna de las partes.

Lo que puede estar acoplado a la infraestructura: - Cómputo, almacenamiento, gestión de identidades y acceso a modelos LLM.

Antes de entregar, hazte esta pregunta: "¿Podría otro desarrollador entender, mantener y migrar lo que he construido en un plazo razonable sin necesitar mi ayuda?" Si la respuesta es no, el trabajo no está terminado.

5️⃣ Qué documentación debes producir¶

Al entregar el trabajo, el Responsable IA necesita que el sistema sea operable sin depender de ti. Eso requiere documentación mínima:

Para sistemas del Core IA: - Descripción técnica del flujo implementado (cómo funciona, qué hace cada componente). - Variables de entorno y configuración necesaria para desplegar o reproducir el sistema. - Instrucciones de despliegue en Cloud Run o el entorno definido. - Política de logs: qué se registra, dónde y durante cuánto tiempo. - Descripción de los puntos de integración con sistemas externos (webhooks, APIs, credenciales).

Para sistemas de Operativa Ligera: - Descripción del flujo en n8n, SuperChat u otra herramienta usada. - Instrucciones para exportar o replicar la configuración. - Variables y credenciales necesarias (sin incluir los valores reales — solo qué se necesita).

Toda esta documentación se entrega al Responsable IA antes de dar el trabajo por cerrado. No hay entrega sin documentación.

6️⃣ Privacidad y seguridad — lo que no es negociable¶

Si el sistema que construyes trata datos personales, estas reglas son obligatorias:

Nunca uses datos reales de clientes para pruebas. Usa datos sintéticos o anonimizados.
Los datos personales solo fluyen por los sistemas declarados en la Plantilla de Arquitectura. Si necesitas añadir un sistema intermedio, comunícalo al Responsable IA antes.
Los logs deben configurarse para retener solo lo declarado en la Plantilla de Arquitectura. No registres más de lo necesario.
Si el sistema interactúa directamente con personas externas (leads, clientes), debe identificarse como sistema automatizado en el primer contacto. Sin excepciones.
Si detectas durante la construcción que el sistema podría estar recogiendo datos no previstos en la Plantilla de Arquitectura, comunícalo al Responsable IA antes de continuar.

7️⃣ Cómo trabajamos juntos¶

Canal de comunicación: el canal principal contigo durante el proyecto es el Responsable IA. Para decisiones funcionales (qué debe hacer el sistema), el Responsable IA te conectará con el Responsable Funcional cuando sea necesario.

Frecuencia mínima de sincronización: al menos una revisión conjunta antes de activar el sistema en producción. Para proyectos de más de cuatro semanas, una revisión intermedia de avance.

Desviaciones respecto a la Plantilla de Arquitectura: cualquier desviación — por pequeña que sea — se comunica al Responsable IA antes de implementarla, no después. Una desviación no comunicada es deuda técnica que BKM hereda.

Criterio de entrega: el trabajo está terminado cuando: - El sistema funciona según el flujo definido en la Plantilla de Arquitectura. - La documentación técnica está entregada. - El Responsable Funcional ha validado que el sistema hace lo que necesita. - El Responsable IA ha verificado que la implementación es coherente con el ecosistema.

8️⃣ Lo que no puedes hacer sin aprobación explícita¶

Incorporar herramientas fuera del stack de referencia.
Conectar el sistema con sistemas no declarados en la Plantilla de Arquitectura (CRM, ERP, BigQuery, APIs externas).
Modificar el prompt maestro de un sistema con LLM sin validación del Responsable Funcional.
Activar el sistema en producción con usuarios o datos reales antes de la validación final.
Subcontatar parte del trabajo a terceros sin comunicarlo al Responsable IA.

Estado: Activo

Fecha: Marzo 2026

Responsable: Responsable IA BKM

Ubicación en el ecosistema: Sección 2 — Roles y gobernanza