📄 GUÍA PARA RECURSOS INTERNOS¶

Construcción de sistemas IA con equipo propio¶

Ecosistema IA BKM¶

Para qué sirve este documento¶

Esta guía aplica cuando alguien del equipo interno de BKM es quien va a construir el sistema definido en la Plantilla de Arquitectura aprobada.

No es un manual técnico. Es la definición de rol, criterios de trabajo y estándar de entrega para quien construye desde dentro.

El hecho de ser equipo interno no cambia los estándares. Cambia el contexto de coordinación — no los criterios de calidad, disciplina arquitectónica ni requisitos de documentación.

Antes de escribir una sola línea de código o configurar ningún sistema, el constructor interno debe haber leído este documento y estar alineado con el Responsable IA.

1️⃣ Tu rol durante la construcción: Constructor Técnico Interno¶

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

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.

Nota sobre acumulación de roles: es habitual que una misma persona ejerza más de uno de estos roles en proyectos internos. Cuando eso ocurra, los criterios de cada rol se aplican igualmente — aunque sea la misma persona quien los ejerce en momentos distintos del proceso. Los roles no desaparecen por solaparse.

2️⃣ Antes de empezar¶

No puede comenzar la construcción si:

La Plantilla de Arquitectura no está aprobada por el Responsable IA y el Responsable Funcional. Es la especificación técnica del trabajo — no hay construcción sin ella.
Hay decisiones marcadas como bloqueantes en la plantilla que siguen abiertas.
El rol de Responsable Técnico de Servicio en producción no está identificado por nombre. Si será el propio constructor, debe quedar declarado explícitamente antes de arrancar.

Lo que debes tener disponible antes de empezar:

La Plantilla de Arquitectura aprobada del proyecto.
Acceso al repositorio del ecosistema (bkm-ecosistema-ia.pages.dev) para consultar el stack y los estándares vigentes.
Canal de comunicación definido con el Responsable IA para reportar desviaciones durante la construcción.

3️⃣ Disciplina arquitectónica durante la construcción¶

Esta es la diferencia más crítica respecto a la construcción informal: la Plantilla de Arquitectura aprobada es el documento de referencia durante todo el proceso, no solo al principio.

Reglas de obligado cumplimiento:

Cualquier desviación respecto a la plantilla — un sistema nuevo, un cambio de flujo, una integración no prevista — se comunica al Responsable IA antes de implementarla, no después.
Una desviación no comunicada es deuda técnica que el ecosistema hereda.
Si durante la construcción se identifica que la plantilla no recoge correctamente cómo debe funcionar el sistema, se actualiza la plantilla — no se adapta la construcción en silencio.

Lo que no puedes hacer sin aprobación explícita del Responsable IA:

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.

4️⃣ Privacidad y seguridad¶

Si el sistema trata datos personales, estas reglas son obligatorias. Ser recurso interno no reduce la exigencia.

Nunca uses datos reales de clientes o de la empresa para pruebas. Usa datos sintéticos o anonimizados.
Los datos personales solo fluyen por los sistemas declarados en la Plantilla de Arquitectura. Si durante la construcción ves que es necesario incorporar un sistema intermedio, comunícalo al Responsable IA antes de hacerlo.
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, para y comunícalo al Responsable IA antes de continuar.

5️⃣ Documentación que debes producir¶

Este es el punto donde la construcción interna falla con más frecuencia. Sin contrato de entrega, la documentación se omite o se deja para después. No hay "después" — la documentación forma parte del trabajo.

La documentación no se produce al final: se construye a lo largo del trabajo y debe estar completa cuando el sistema se activa en producción.

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 necesarias — sin valores reales).

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).

Criterio práctico: hazte esta pregunta antes de dar el trabajo por terminado: "¿Podría el Responsable IA o cualquier otro miembro del equipo entender, mantener y operar lo que he construido sin necesitar mi ayuda?" Si la respuesta es no, el trabajo no está terminado.

6️⃣ Principio de Portabilidad Mínima¶

Aplica igual que para recursos externos. Lo que construyas debe poder entenderse, mantenerse y migrarse 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.

7️⃣ Criterio de "terminado"¶

El trabajo está terminado cuando se cumplen todos estos criterios:

☐ El sistema funciona según el flujo definido en la Plantilla de Arquitectura.
☐ No hay desviaciones respecto a la plantilla que no estén documentadas y aprobadas por el Responsable IA.
☐ La documentación técnica está producida y accesible.
☐ 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.
☐ La Ficha de Sistema Modo A está completada en Drive (01_Sistemas_Activos).
☐ El Índice Operativo está actualizado en el repositorio.
☐ La primera revisión periódica está agendada.

Si alguno de estos puntos no está cubierto, el sistema no está en producción — está en construcción con acceso a producción, que es peor.

Estado: Activo

Fecha: Abril 2026

Responsable: Responsable IA BKM

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