📄 GUÍA DEL RESPONSABLE IA¶

Proceso completo desde la recepción de una idea hasta la entrega a producción¶

Ecosistema IA BKM¶

Para qué sirve este documento¶

Esta guía describe el proceso completo que sigue el Responsable IA desde que recibe una propuesta de proyecto hasta que el sistema está en producción y operado correctamente.

No es un manual técnico ni un catálogo de herramientas. Es una guía de navegación: qué hacer, en qué orden, qué documentos se producen en cada paso y qué criterios se aplican.

La Guía de Proyectos IA explica el proceso desde la perspectiva de quien propone una idea. Esta guía lo explica desde la perspectiva de quien tiene que evaluarla, aprobarla, construirla y entregarla.

FASE 1 — RECEPCIÓN Y EVALUACIÓN DE UNA PROPUESTA¶

¿Cuándo?

Cuando llega una idea o iniciativa de cualquier área de BKM — por email, en una reunión o a través del Agente de Alineación de Propuestas.

Paso 1.1 — Determinar el flujo aplicable¶

Antes de evaluar el contenido, determina si la propuesta puede ir por autonomía departamental (Flujo B) o requiere validación central (Flujo A).

Checklist de clasificación:

☐ ¿El sistema solo lo usará el departamento que lo propone?
☐ ¿No se conecta con CRM, ERP ni BigQuery?
☐ ¿No maneja datos sensibles de clientes ni información financiera?
☐ ¿No afecta al discurso oficial de BKM ni a su reputación?
☐ ¿La base de conocimiento es limitada y estable?
☐ ¿Hay un propietario identificado?

Si todas son ✓ → Flujo B. Confirma al Propietario Departamental que puede arrancar con registro básico de notificación. Archívalo en Drive y mantén visibilidad. El proceso para ti termina aquí — salvo que el proyecto escale.

Si alguna es ✗ → Flujo A. Continúa con el paso siguiente.

Paso 1.2 — Evaluar la propuesta con el Agente de Alineación¶

Si la propuesta llega en forma de documento o descripción, pásala por el Agente de Alineación de Propuestas. El agente genera un informe estructurado con:

Valor estratégico detectado.
Elementos bien enfocados y desalineaciones.
Flujo recomendado y capa propuesta.
Evaluación de privacidad y viabilidad técnica.

Revisa el informe antes de devolvérselo al emisor. El agente asiste — tú decides.

Paso 1.3 — Dar respuesta al emisor¶

Devuelve al emisor el encuadre de la propuesta:

Si va por Flujo B: confírmalo y explica los límites de autonomía.
Si va por Flujo A: explica el proceso de revisión trimestral y los próximos pasos.
Si la propuesta está fuera del alcance del Ecosistema IA (no es un sistema de IA): redirige al canal correcto con explicación clara.

Documentos producidos en esta fase: - Informe del Agente de Alineación (archivado en Drive si corresponde). - Email de respuesta al emisor.

FASE 2 — APROBACIÓN Y PRIORIZACIÓN¶

¿Cuándo?

Una vez clasificada como Flujo A, la propuesta entra en el backlog y espera la revisión trimestral — salvo que tenga urgencia real documentada.

Paso 2.1 — Solicitar la Tarjeta de Valor IA¶

Pide al emisor (Responsable Funcional propuesto) que complete la Tarjeta de Valor IA. Esta tarjeta recoge:

Palanca de negocio que mueve la iniciativa.
Urgencia real y motivo.
Complejidad, sistemas implicados y documentación disponible.
Dependencias con otras iniciativas.

Checklist de validación de la Tarjeta de Valor:

☐ ¿La descripción en una frase es clara y específica?
☐ ¿El impacto en negocio está cuantificado o al menos estimado?
☐ ¿La urgencia declarada es real (hay fecha o condición objetiva) o es urgencia percibida?
☐ ¿Los sistemas implicados están identificados correctamente?
☐ ¿Las dependencias con otras iniciativas están declaradas?

Si la tarjeta está incompleta en algún punto crítico, devuélvela con las preguntas concretas antes de incluirla en el backlog.

Paso 2.2 — Incluir en el backlog y preparar la revisión trimestral¶

Archiva la Tarjeta de Valor en Drive (04_Backlog_Iniciativas) y actualiza el Índice Operativo con el nuevo estado.

En la revisión trimestral con Dirección, presenta todas las tarjetas activas del backlog y propón una clasificación para cada una:

🟢 Construir ahora — entra en desarrollo activo.
🟡 Preparar para el siguiente ciclo — valor claro pero no es el momento.
⚪ Registrado sin fecha — queda en el backlog sin prioridad activa.

Criterio de decisión ante empate entre dos iniciativas:

¿Qué le cuesta más al negocio: no hacer A o no hacer B?

Urgencia real que no puede esperar al ciclo trimestral: si la iniciativa tiene una fecha objetiva que la hace bloqueante antes de la próxima revisión, puede activarse antes con justificación documentada.

Documentos producidos en esta fase: - Tarjeta de Valor completada en Drive. - Acta de revisión trimestral del backlog en Drive (04_Backlog_Iniciativas). - Índice Operativo actualizado.

FASE 3 — DISEÑO Y VALIDACIÓN DE ARQUITECTURA¶

¿Cuándo?

Cuando una iniciativa pasa a estado "Construir ahora". Antes de escribir una sola línea de código o configurar ningún sistema.

Paso 3.1 — Evaluación de herramientas externas (si aplica)¶

Si el proyecto usa herramientas fuera del stack de referencia, completa el proceso de evaluación antes de continuar.

Checklist de evaluación de herramienta externa:

☐ ¿Qué problema resuelve que no resuelve el stack actual?
☐ ¿Se evaluó alguna alternativa dentro del stack? ¿Por qué se descartó?
☐ ¿Qué coste tiene en integración, mantenimiento y gobernanza?
☐ ¿La lógica de negocio permanece portable si se cambia de herramienta?
☐ ¿Hay contrato explícito que garantice que los datos no se usan para entrenamiento (si aplica)?
☐ ¿Se han verificado las condiciones de transferencia internacional de datos?

Si el valor justifica el coste → se aprueba. Registra la decisión como ADR en el Log de Decisiones.

Si no lo justifica → no se aprueba. Registra la evaluación y el motivo igualmente.

Si el proyecto lo construye un recurso externo:

Antes de continuar con la Plantilla de Arquitectura, confirma que el recurso externo conoce el stack de referencia del ecosistema. Comparte con él la Guía para Recursos Externos (Sección 2 — Roles y Gobernanza) y obtén confirmación explícita de que la ha leído antes de arrancar cualquier trabajo técnico.

Si el recurso externo propone herramientas fuera del stack durante esta fase, aplica el proceso de evaluación antes de aprobarlas — no después de haberlas usado.

Paso 3.2 — Completar la Plantilla de Arquitectura¶

Completa la Plantilla de Arquitectura conjuntamente con el Responsable Funcional. Esta es la sesión de trabajo más importante del proceso — define exactamente qué se va a construir antes de construirlo.

Checklist de la Plantilla de Arquitectura:

☐ Propósito claro: qué hace, qué mejora y qué no hace.
☐ Nivel de criticidad evaluado.
☐ Capa correcta asignada con justificación.
☐ Todos los sistemas implicados listados con su rol.
☐ Flujo técnico descrito en menos de 10 líneas.
☐ Datos utilizados declarados con tipo.
☐ Si trata datos personales:
☐ Base legal del tratamiento declarada.
☐ Finalidad y plazo de retención definidos.
☐ Texto informativo al interesado definido (si el sistema interactúa con personas externas).
☐ Transferencias internacionales verificadas.
☐ Política de logs por componente definida.
☐ Si ejecuta acciones autónomas:
☐ Grado de autonomía declarado (Nivel 1, 2 o 3).
☐ Acciones autónomas permitidas listadas.
☐ Acciones que requieren aprobación humana listadas.
☐ Reversibilidad de acciones externas evaluada.
☐ Protocolo ante incidentes definido.
☐ Gobernanza: Responsable Funcional y Responsable IA identificados.
☐ Métricas de éxito y señales de fallo definidas.
☐ Riesgos identificados con mitigación (incluido riesgo para derechos de las personas si aplica).
☐ Decisiones pendientes antes del arranque listadas explícitamente.

Paso 3.3 — Validación y aprobación¶

Ambos responsables deben validar la plantilla antes de continuar.

Responsable Funcional: confirma que el sistema hace lo que el área necesita y no más.
Responsable IA: confirma que la solución es coherente con el stack y no genera deuda técnica ni riesgo de privacidad no gestionado.

Si hay puntos sin resolver, documéntalos como "decisiones pendientes" con responsable y plazo. La plantilla puede aprobarse con decisiones pendientes si son menores — no puede aprobarse si alguna es bloqueante para el arranque en producción.

Paso 3.4 — Registrar el ADR si aplica¶

Si la decisión de arquitectura tiene impacto transversal o a largo plazo, registra un ADR en el Log de Decisiones. No todos los proyectos generan un ADR — solo los que toman decisiones que afectan al ecosistema más allá del proyecto concreto.

Criterios para registrar un ADR: - Se incorpora una herramienta externa al stack. - Se toma una decisión de capa que establece precedente. - Se define un patrón de integración que otros proyectos podrían reutilizar. - Se descarta una opción que podría volver a plantearse en el futuro.

Documentos producidos en esta fase: - Plantilla de Arquitectura completada en Drive (05_Arquitecturas_Aprobadas). - ADR en el repositorio (6_logs_decisiones/) si aplica.

FASE 4 — SUPERVISIÓN DURANTE LA CONSTRUCCIÓN¶

¿Cuándo?

Desde que arranca la construcción hasta que el sistema está listo para producción.

Paso 4.0 — Si el proyecto lo construye un recurso externo¶

Antes de que arranque la construcción, completa estos pasos previos:

Onboarding del recurso externo:

☐ El recurso externo ha recibido la Guía para Recursos Externos.
☐ Ha confirmado explícitamente que la ha leído y aceptado.
☐ Tiene acceso a la Plantilla de Arquitectura aprobada del proyecto.
☐ Tiene acceso al repositorio del ecosistema (bkm-ecosistema-ia.pages.dev) para consultar el stack y los estándares.
☐ El canal de comunicación durante la construcción está definido (quién es el interlocutor, con qué frecuencia se revisa el avance).

Identificar el Responsable Técnico de Servicio en producción:

☐ ¿Quién mantendrá el sistema cuando esté en producción? (puede ser el propio recurso externo si hay acuerdo de mantenimiento, el Responsable IA, o ambos según el sistema)
☐ Ese rol está identificado por nombre antes de arrancar la construcción. Un sistema sin Responsable Técnico de Servicio identificado no puede activarse.

Si alguno de estos puntos no está resuelto, la construcción no puede comenzar.

Paso 4.1 — Verificar que las decisiones pendientes están resueltas¶

Antes de arrancar la construcción, confirma que todas las decisiones marcadas como bloqueantes en la Plantilla de Arquitectura están resueltas. Si alguna sigue abierta, la construcción no puede comenzar en esa parte del sistema.

Paso 4.2 — Supervisar la coherencia durante el desarrollo¶

Durante la construcción, tu función no es ejecutar — es garantizar que lo que se construye corresponde a lo que se documentó.

Checklist de supervisión durante construcción:

☐ El flujo técnico implementado corresponde al documentado en la Plantilla de Arquitectura.
☐ Los sistemas implicados son los declarados — no se han añadido conexiones no documentadas.
☐ Si el sistema trata datos personales, la base legal y el texto informativo están implementados.
☐ Los logs están configurados según la política declarada (qué se registra, durante cuánto tiempo, quién accede).
☐ El grado de autonomía implementado corresponde al declarado.
☐ El prompt maestro (si aplica) está validado por el Responsable Funcional.
☐ Las pruebas de integración con sistemas externos están completas.

Si durante la construcción aparece una desviación relevante respecto a la Plantilla de Arquitectura — un sistema nuevo, un cambio de flujo, una integración no prevista — actualiza la plantilla antes de continuar. Una desviación no documentada es deuda técnica.

Paso 4.3 — Revisar periódicamente con el Responsable Funcional¶

Mantén al Responsable Funcional informado del avance y alineado con lo que se está construyendo. Es la persona que va a validar la utilidad del sistema antes de activarlo.

Frecuencia mínima: una revisión conjunta antes de la activación en producción.

FASE 5 — ACTIVACIÓN Y ENTREGA A PRODUCCIÓN¶

¿Cuándo?

Cuando el sistema está construido, probado y listo para operar con usuarios reales o datos reales.

Paso 5.1 — Checklist de activación¶

Antes de activar el sistema en producción, verifica que todos los puntos siguientes están cubiertos:

Técnico:

☐ Pruebas de integración con todos los sistemas externos completadas.
☐ Comportamiento del sistema ante casos de error verificado (fallo de webhook, fallo de API, respuesta inesperada).
☐ Logs configurados y accesibles.
☐ Sistema de alertas ante fallos configurado (si aplica).

Privacidad y seguridad (si el sistema trata datos personales):

☐ Base legal del tratamiento confirmada y documentada.
☐ Texto informativo al interesado implementado y validado.
☐ Transferencias internacionales verificadas con garantías adecuadas.
☐ Política de retención de logs implementada.
☐ Condiciones contractuales del proveedor verificadas (uso de datos para entrenamiento, etc.).

Gobernanza:

☐ Responsable Funcional ha validado el sistema antes de activarlo.
☐ Usuarios autorizados identificados y notificados.
☐ Protocolo ante incidentes conocido por los responsables.
☐ Fecha de primera revisión periódica agendada.

Paso 5.2 — Completar y activar la Ficha de Sistema Modo A¶

La Ficha de Sistema Modo A es el registro operativo oficial del sistema desde que entra en producción. Se completa en este momento y vive en Drive (01_Sistemas_Activos).

La ficha recoge: responsables, usuarios autorizados, finalidad, límites de uso, herramientas implicadas, privacidad y autonomía, métricas de seguimiento, revisión periódica y criterios de escalado o cierre.

Si el sistema fue construido por un recurso externo, la ficha debe recoger adicionalmente:

Quién ejerce el rol de Responsable Técnico de Servicio en producción (nombre, si es interno o externo, y condiciones del acuerdo de mantenimiento si aplica).
Si el recurso externo que construyó el sistema ya no tiene acceso a los entornos de producción tras la entrega — o si mantiene acceso y bajo qué condiciones.

Esta información es crítica para que el ecosistema no dependa de una persona externa para operar un sistema en producción.

Paso 5.3 — Actualizar el Índice Operativo¶

Actualiza el Índice Operativo del repositorio con el nuevo sistema activo, su capa, su responsable funcional y el estado actual.

Paso 5.4 — Plan de supervisión en las primeras semanas¶

Los primeros días y semanas de operación son los de mayor riesgo. Define y ejecuta un plan de supervisión intensiva proporcional al nivel de criticidad del sistema.

Para sistemas de criticidad alta (interacción con clientes, datos personales):

Revisión de conversaciones o outputs cada 2-3 días durante las primeras 2 semanas.
Verificación de que los datos escritos en sistemas externos (CRM, etc.) son correctos.
Canal activo con el Responsable Funcional para detectar anomalías rápidamente.

Para sistemas de criticidad media o baja:

Revisión semanal durante el primer mes.

Documentos producidos en esta fase:

Ficha de Sistema Modo A en Drive (01_Sistemas_Activos).
Índice Operativo actualizado en el repositorio.

REFERENCIA RÁPIDA — DOCUMENTOS POR FASE¶

Fase	Documento	Dónde vive
1 — Recepción	Informe del Agente de Alineación	Drive (si se archiva)
2 — Priorización	Tarjeta de Valor IA completada	Drive — 04_Backlog_Iniciativas
2 — Priorización	Acta de revisión trimestral	Drive — 04_Backlog_Iniciativas
3 — Arquitectura	Evaluación de herramienta externa	ADR en repositorio — 6_logs_decisiones
3 — Arquitectura	Plantilla de Arquitectura completada	Drive — 05_Arquitecturas_Aprobadas
3 — Arquitectura	ADR (si aplica)	Repositorio — 6_logs_decisiones
5 — Producción	Ficha de Sistema Modo A	Drive — 01_Sistemas_Activos
Continuo	Índice Operativo	Repositorio — Sección 4

REFERENCIA RÁPIDA — SEÑALES DE ALERTA DURANTE EL PROCESO¶

Estas situaciones requieren parar y revisar antes de continuar:

Un sistema empieza a construirse sin Plantilla de Arquitectura aprobada.
La construcción se desvía del flujo documentado sin actualizar la plantilla.
Un sistema usa herramientas externas al stack sin evaluación registrada.
Un sistema que trata datos personales arranca en producción sin base legal confirmada.
Un sistema que interactúa con personas externas no las informa de que es automatizado.
Un sistema activo no tiene Ficha de Sistema Modo A en Drive.
Un sistema activo no tiene fecha de próxima revisión periódica definida.
Un recurso externo empieza a construir sin haber confirmado que ha leído la Guía para Recursos Externos.
Un recurso externo incorpora herramientas fuera del stack o conecta sistemas no declarados en la Plantilla de Arquitectura sin comunicarlo previamente.
El sistema llega a producción sin que esté identificado quién ejerce el rol de Responsable Técnico de Servicio.
El recurso externo entrega el trabajo sin la documentación técnica acordada.

Estado: Activo

Fecha: Marzo 2026

Responsable: Responsable IA BKM

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