📄 MARCO DE OPERATIVA IA¶

Ecosistema IA BKM¶

1️⃣ Propósito¶

Este documento define la forma mínima y ordenada de gestionar los sistemas IA en uso dentro de BKM.

Su objetivo es:

Evitar improvisación.
Asegurar responsables claros.
Mantener coherencia con la arquitectura.
No burocratizar innecesariamente.
Permitir que los departamentos actúen con agilidad dentro de límites claros.

2️⃣ Principio de Gobernanza Mínima Viable¶

En BKM aplicamos tres reglas simples:

Todo sistema IA en uso tiene un responsable identificado.
Todo sistema IA tiene reglas básicas de uso escritas.
Si el sistema escala o aumenta en criticidad, se revisa su arquitectura y su gobernanza.

Nada más.

3️⃣ Dos modos de operativa¶

El ecosistema distingue dos modos de gestión según el origen y el impacto del sistema.

Modo A — Gestión central¶

Aplica a sistemas del Core IA y a sistemas de Operativa Ligera con impacto transversal o medio-alto.

El Responsable IA tiene control directo sobre la arquitectura, el stack y la gobernanza. El Responsable Funcional valida el propósito y el impacto. Requiere documentación según el Marco de Arquitectura.

Modo B — Autonomía departamental¶

Aplica a sistemas en Laboratorio y en Operativa Ligera que cumplen todos los criterios de autonomía definidos en Roles y Responsabilidades.

El Propietario Departamental lidera el proyecto con autonomía. El Responsable IA mantiene visibilidad pero no valida previamente. Requiere únicamente registro básico de notificación.

La autonomía no exime de responsabilidad. Exime de proceso de validación central mientras el proyecto esté dentro de sus límites.

4️⃣ Qué debe documentarse por cada sistema IA en uso¶

Cada sistema activo requiere un registro formal según su modo de gestión.

Sistemas en Modo A — se documenta mediante la Ficha de Sistema Modo A. Recoge: responsables, usuarios autorizados, finalidad, límites de uso, herramientas implicadas, consideraciones de privacidad, métricas de seguimiento y criterios de escalado o cierre.

📄 Plantilla: Ficha Sistema Modo A — disponible en la sección de Operativa del repositorio. Esta ficha vive en Drive, no en el repositorio.

Sistemas en Modo B — se documenta mediante el Registro de Notificación Departamental. Recoge: propietario, objetivo, capa, usuarios, verificación de criterios de autonomía, plataforma utilizada, plazo de continuidad y señal de escalado.

📄 Plantilla: Ficha Sistema Modo B — disponible en la sección de Operativa del repositorio. Este registro vive en Drive, no en el repositorio.

5️⃣ Qué NO hacemos en esta fase¶

En el estado actual de madurez de BKM:

No realizamos auditorías formales mensuales.
No generamos reporting complejo.
No versionamos prompts con estructura pesada.
No creamos comités técnicos formales.

Si el ecosistema crece en impacto o número de sistemas, se revisará esta política.

6️⃣ Regla de Escalado¶

Un sistema bajo autonomía departamental debe notificarse al Responsable IA y migrar al Modo A si cumple alguna de estas condiciones:

Supera 10-15 usuarios activos fuera del departamento de origen.
Se vuelve parte del método o estándar oficial de BKM.
Se integra con CRM, ERP u otros sistemas core.
Genera automatizaciones que afectan a otros departamentos.
Afecta decisiones técnicas sin supervisión humana.
Maneja información sensible de clientes o de la empresa.

Un sistema en Modo A debe revisarse formalmente si:

Supera 15-20 usuarios activos.
Se vuelve obligatorio en el método.
Se integra con CRM o ERP.
Genera automatizaciones críticas.
Afecta decisiones técnicas sin supervisión humana.
Se detecta un incidente con datos personales — ver sección 8.

7️⃣ Principio de Simplicidad Estructural¶

La prioridad en esta fase no es sofisticación.

Es:

Orden mínimo.
Coherencia.
Responsabilidad clara.
Evolución progresiva.
Autonomía donde el impacto lo permite.

La burocracia excesiva bloquea la adopción. La ausencia total de reglas genera caos.

Este marco busca el equilibrio: más fricción donde más se arriesga, menos fricción donde el impacto es bajo y controlado.

8️⃣ Protocolo ante Incidentes con Datos Personales¶

(Aplica a sistemas en Modo A que traten datos personales)

Si se detecta que un sistema ha actuado de forma incorrecta sobre datos personales — ha recogido datos que no debía, los ha enviado a un destino no autorizado, los ha conservado más tiempo del previsto o ha tomado una decisión automatizada sin la supervisión requerida — se aplica el siguiente protocolo mínimo:

Detección y notificación inmediata al Responsable IA. Responsable: quien detecte el incidente. Plazo: sin demora.
Evaluación del alcance — el Responsable IA determina qué datos se han visto afectados, cuántas personas y qué impacto potencial tienen. Plazo: 24 horas.
Contención — si es posible, el sistema se pausa o se limita hasta entender el origen del problema.
Decisión sobre notificación — si el incidente podría constituir una brecha de datos personales con riesgo para las personas afectadas, el Responsable IA escala a Dirección para evaluar obligaciones legales de notificación.
Revisión formal del sistema — el sistema no vuelve a operar en las mismas condiciones hasta completar la revisión. Se actualiza su Ficha de Sistema Modo A con el incidente y las medidas adoptadas.

Este protocolo es el mínimo viable para una empresa en fase de construcción. Si el número de sistemas con datos personales crece, deberá formalizarse en un procedimiento más detallado.

9️⃣ Revisión de Cumplimiento en Revisiones Periódicas¶

Las revisiones periódicas de sistemas en Modo A deben incluir, para sistemas que traten datos personales, una verificación mínima de los siguientes puntos:

La base legal del tratamiento sigue siendo válida.
Los datos recogidos siguen siendo los mínimos necesarios para la finalidad declarada.
El grado de autonomía definido en la Plantilla de Arquitectura se corresponde con el funcionamiento real del sistema.
Los logs se retienen solo durante el plazo declarado.
No se han producido incidentes desde la última revisión. Si los ha habido, están documentados.

Esta verificación no requiere un proceso formal separado — se integra en la revisión periódica existente como un bloque adicional de cinco preguntas.

🔟 Revisión del Documento¶

Este documento debe revisarse:

Una vez al año.
O cuando el número de sistemas IA activos supere cinco.
O cuando cambie significativamente la dimensión del equipo.
O cuando el número de proyectos departamentales autónomos supere tres simultáneos.

Estado: Activo

Fecha: Marzo 2026 (actualizado con requisitos AEPD — IA Agéntica)

Responsable: Responsable IA BKM