📄 ROLES Y RESPONSABILIDADES¶

Ecosistema IA BKM¶

1️⃣ Objetivo del Documento¶

Definir claramente:

Quién decide
Quién construye
Quién supervisa
Quién mantiene
Quién puede experimentar
Quién puede desarrollar con autonomía departamental

El ecosistema IA no es solo tecnología. Es gobernanza organizativa.

2️⃣ Principios Organizativos¶

Cada sistema IA debe tener un responsable asignado.
Ninguna herramienta puede operar sin propietario.
La velocidad no puede comprometer la estructura.
Las decisiones estratégicas no se delegan en automatizaciones.
La IA apoya al negocio, no lo sustituye.
La gobernanza es proporcional al impacto. No todo requiere el mismo nivel de control.
Los departamentos funcionales pueden desarrollar proyectos de bajo impacto con autonomía, dentro de los límites definidos en este documento.

3️⃣ Roles del Ecosistema IA¶

👤 3.1 Responsable IA (IA Lead)¶

Perfil: Responsable técnico-estratégico del ecosistema IA.

Responsabilidades:

Definir y mantener el stack tecnológico.
Validar la ubicación de cada proyecto en su capa.
Aprobar proyectos en el Core IA y migraciones desde capas inferiores.
Evaluar y aprobar herramientas externas al stack de referencia.
Supervisar privacidad y seguridad de todos los sistemas.
Definir estándares técnicos y arquitectónicos.
Asegurar la coherencia global del ecosistema.
Mantener visibilidad sobre todos los proyectos activos, incluidos los de autonomía departamental.
Activar el proceso de validación cuando un proyecto departamental supera sus límites de autonomía.

No es responsable de: - Uso diario del CRM. - Gestión comercial. - Operativa financiera. - El desarrollo técnico de proyectos departamentales autónomos, salvo que escalen.

👔 3.2 Responsable Funcional de Sistema¶

Cada sistema IA del Core IA o de Operativa Ligera con impacto transversal debe tener un responsable funcional designado por el área correspondiente.

Responsabilidades:

Definir el objetivo del sistema.
Validar su utilidad para el negocio.
Detectar errores funcionales.
Priorizar mejoras.
Confirmar impacto en negocio.
Colaborar con el Responsable IA en la validación de la Plantilla de Arquitectura.

El Responsable Funcional decide "qué debe hacer el sistema". El Responsable IA decide "cómo se construye".

🏢 3.3 Propietario Departamental IA¶

Perfil: Miembro de un departamento funcional que lidera un proyecto IA dentro de los límites de autonomía departamental definidos en este documento.

No es un rol técnico. Es un rol de responsabilidad y notificación.

Responsabilidades:

Identificar la necesidad que el proyecto quiere resolver.
Asegurarse de que el proyecto cumple los criterios de autonomía departamental antes de iniciarlo.
Notificar al Responsable IA de la existencia del proyecto mediante registro básico.
Mantener el proyecto dentro de los límites que justifican su autonomía.
Detectar y notificar al Responsable IA si el proyecto empieza a superar esos límites.
Garantizar que hay un propietario identificado en todo momento.
Asegurar que el proyecto tiene un plazo o criterio de continuidad definido.

Límites de su autonomía:

El Propietario Departamental puede desarrollar proyectos que cumplan todas estas condiciones:

Se ubican en la capa Laboratorio o en la capa Operativa Ligera.
No se integran con sistemas core del negocio (CRM, ERP, BigQuery, GCS).
No gestionan datos sensibles de clientes o de la empresa.
No afectan a la reputación ni al discurso oficial de BKM.
El único usuario es el propio departamento.
No requieren mantenimiento técnico especializado fuera del alcance del departamento.

Si alguna de estas condiciones deja de cumplirse, el proyecto deja de estar dentro del ámbito de autonomía departamental y debe notificarse al Responsable IA para iniciar el proceso de validación estándar.

🧑‍💻 3.4 Responsable Técnico Externo (cuando aplica)¶

Perfil: Persona o equipo externo a BKM contratado para construir un sistema concreto dentro del Ecosistema IA. Puede ser un freelance, una agencia o un estudio técnico, con modelo variable según el proyecto.

No forma parte del equipo interno de BKM. Opera bajo supervisión directa del Responsable IA durante la construcción.

Responsabilidades:

Leer y aceptar la Guía para Recursos Externos antes de iniciar el trabajo.
Construir el sistema según lo definido en la Plantilla de Arquitectura aprobada.
Usar exclusivamente el stack de referencia o herramientas aprobadas explícitamente por el Responsable IA.
Comunicar al Responsable IA cualquier desviación respecto a la Plantilla de Arquitectura antes de implementarla.
Aplicar el Principio de Portabilidad Mínima.
Entregar la documentación técnica acordada antes de dar el trabajo por cerrado.
No activar el sistema en producción sin validación del Responsable IA y del Responsable Funcional.

Límites de su autonomía:

No puede incorporar herramientas fuera del stack sin aprobación previa.
No puede conectar sistemas no declarados en la Plantilla de Arquitectura.
No puede modificar el prompt maestro sin validación del Responsable Funcional.
No puede subcontratar parte del trabajo sin comunicarlo al Responsable IA.

Referencia obligatoria: → Guía para Recursos Externos — Sección 2, Roles y Gobernanza.

🧑‍💻 3.5 Responsable Técnico de Servicio¶

En la fase actual del ecosistema, el mantenimiento técnico de los sistemas en producción recae en el Responsable IA, que asume también esta función dado el tamaño del equipo y el número de sistemas activos.

Esto incluye: * Verificar que los servicios activos están operativos. * Revisar logs periódicamente. * Gestionar despliegues de actualizaciones. * Coordinar la resolución de incidencias técnicas.

Excepción — recurso externo con acuerdo de mantenimiento: Si el sistema fue construido por un recurso externo y existe un acuerdo explícito de mantenimiento con ese externo, las responsabilidades técnicas de servicio pueden recaer total o parcialmente en él. En ese caso, la Ficha de Sistema Modo A debe recoger quién ejerce este rol, bajo qué condiciones y qué accesos mantiene al entorno de producción tras la entrega.

Esta separación se revisará si el número de sistemas activos crece de forma que haga inviable que el Responsable IA asuma también el mantenimiento técnico.

🧪 3.6 Responsable de Experimentación¶

Cuando se realicen pruebas en la Capa Experimental:

Debe estar identificado quién lidera la prueba.
Debe existir un objetivo claro.
Debe definirse criterio de éxito.
Debe decidirse si migra o se elimina.

No se permiten experimentos indefinidos.

Puede coincidir con el Propietario Departamental si el experimento es iniciativa de un departamento funcional.

4️⃣ Responsabilidad por Capas¶

🟢 Core IA¶

Responsable principal: IA Lead Responsable funcional: Dirección correspondiente Desarrollo departamental autónomo: No permitido

Requiere: - Plantilla de Arquitectura validada. - Control de acceso. - Registro estructurado. - Plan de mantenimiento. - Aprobación del Responsable IA antes de iniciar.

🟡 Infraestructura Operativa Ligera¶

Responsable principal: Responsable IA (proyectos transversales) / Propietario Departamental (proyectos autónomos) Responsable funcional: Área correspondiente Desarrollo departamental autónomo: Permitido dentro de los límites definidos

Requiere siempre: - Propietario identificado. - Registro básico notificado al Responsable IA. - Criterio de continuidad o plazo definido.

Requiere adicionalmente si es transversal o de impacto medio-alto: - Validación del Responsable IA. - Backup mínimo. - Revisión periódica.

🔵 Infraestructura Experimental (Laboratorio)¶

Responsable principal: Quien lidera la prueba (puede ser Propietario Departamental) Supervisión: IA Lead (ligera — visibilidad, no validación previa) Desarrollo departamental autónomo: Permitido

Requiere: - Objetivo claro. - Plazo definido. - Notificación básica al Responsable IA. - Decisión formal de continuidad o cierre al finalizar el plazo.

5️⃣ Flujos de Aprobación¶

El ecosistema distingue dos flujos según el tipo de proyecto.

Flujo A — Proyectos con validación central (Core IA y proyectos transversales)¶

Tarjeta de Valor IA — evaluar impacto, urgencia y complejidad.
Determinar si requiere validación central o puede ir por flujo departamental.
Asignar Responsable Funcional y Responsable IA.
Completar Plantilla de Arquitectura conjuntamente.
Validación y aprobación de ambos responsables.
Registro en Log de Decisiones si tiene impacto transversal.
Inicio de construcción.

Flujo B — Proyectos con autonomía departamental (Laboratorio y Operativa Ligera de bajo impacto)¶

El Propietario Departamental verifica que el proyecto cumple todos los criterios de autonomía.
Notificación básica al Responsable IA: nombre del proyecto, objetivo, capa, propietario y plazo.
El Responsable IA confirma recepción y que el proyecto está dentro de los límites de autonomía. Si detecta que no lo está, redirige al Flujo A.
Inicio del proyecto bajo responsabilidad del Propietario Departamental.
El Propietario Departamental notifica al Responsable IA si el proyecto supera sus límites en cualquier momento.

Este flujo no requiere Plantilla de Arquitectura completa. Requiere únicamente el registro básico de notificación.

6️⃣ Principio de Migración¶

Si un sistema en Laboratorio u Operativa Ligera:

Aumenta en impacto o criticidad.
Se vuelve transversal a más de un departamento.
Maneja información sensible.
Afecta reputación o discurso oficial.
Requiere integración con sistemas core.

Debe migrarse formalmente al nivel de gobernanza correspondiente.

Si el proyecto estaba en autonomía departamental, la migración activa automáticamente el Flujo A y la intervención del Responsable IA.

La migración no es opcional.

7️⃣ Principio de Control¶

Ningún agente IA puede:

Tomar decisiones estratégicas autónomas.
Modificar sistemas core sin validación.
Operar sin responsable identificado.
Mantenerse activo sin revisión periódica.

Esto aplica también a proyectos desarrollados con autonomía departamental. La autonomía en el desarrollo no exime de la responsabilidad en la operación.

🎯 Conclusión¶

El ecosistema IA BKM requiere:

Claridad tecnológica.
Claridad organizativa.
Responsables definidos en todo proyecto.
Gobernanza proporcional al impacto.
Autonomía departamental donde el impacto lo permite.
Control central donde el impacto lo exige.

La IA no se gestiona sola. Se gobierna — con más o menos fricción según lo que esté en juego.

Estado: Activo
Fecha: Marzo 2026
Responsable: Responsable IA BKM