Ingresa tu correo institucional y tu clave de acceso.
Documento confidencial · Uso interno BanBif
Un taller para acordar cómo clasificamos, priorizamos y gobernamos nuestras aplicaciones — cuando no podemos gestionar todo y la IA cambia las reglas.
Dos preguntas para abrir la conversación — y los objetivos que buscamos alcanzar al final del taller.
¿Creen que el enfoque fue correcto — y por qué?
El sistema dependía del conocimiento de personas específicas. Un cambio, una salida o una incidencia podía paralizar un proceso crítico. Se había convertido en un sistema personalizado que solo algunos sabían configurar.
Al despersonalizar una aplicación que cumple una función bancaria común, logramos actualizar bajo el modelo de evolución estándar del fabricante. Las iniciativas clave del banco ya no compiten por algo que el mercado ya entrega.
Una aplicación de funcionalidad común, bien gestionada, nos permite concentrarnos en iniciativas de mayor valor al negocio. Cuando las personalizamos, acumulamos deuda técnica cada vez más costosa de pagar.
Solo por nombrar…
Esto no es un problema de personas — es un problema de cómo distribuimos nuestra capacidad.
Consensuar que TI debe enfocarse en las capacidades que realmente nos diferencian, y liberar deuda en las capacidades comunes para reasignar esa capacidad a lo diferenciador.
Aprobar el modelo de clasificación de aplicaciones junto con las reglas que lo definen, los modelos de aprovisionamiento y las posturas de modernización.
Reflexionar sobre el impacto del modelo en otros procesos clave, como la priorización de iniciativas, y definir próximos pasos.
Validar y aprobar la propuesta de aplicaciones que deben hibernarse e iniciar su modernización o apagado, según la clasificación.
La IA en sus formas modernas — GenAI, LLM, IA agéntica, negocios autónomos — llegó e impactará drásticamente cómo hacemos negocio y cómo producimos y operamos el software. El contexto nos obliga a tomar acción hoy.
El banco digital automatizó procesos. El banco agéntico los ejecuta de forma autónoma, tomando decisiones en tiempo real.
de todos los flujos de trabajo empresariales serán ejecutados por agentes de IA para 2030.
Gartner, 2025de las organizaciones ha llegado a despliegue industrial de IA agéntica; la mayoría sigue en pilotos desconectados.
NTT DATA, 2026La ventaja ya no está en el proceso — está en cómo decidimos y actuamos en tiempo real. Mantener los sistemas heredados ya no es una estrategia segura: las arquitecturas monolíticas frenan la innovación, limitan el potencial de la IA y generan deuda técnica creciente con cada cambio.
Gartner, G00838384, Oct 2025de los ingenieros ya usa agentes de IA de forma habitual en su trabajo.
Gartner SW Eng. Survey, 2026mayor velocidad de entrega en equipos que aplican IA en todo el SDLC (vs 35% de uso limitado).
Gartner AI in SW Eng., 2025mejora de productividad con flujos agénticos en el ciclo completo, proyectado al 2028.
Gartner, Strategic Planningadoptó IA para acelerar entrega por presión competitiva — no por elección interna.
Gartner Top Trends, 2025La competencia ya tomó la decisión. ¿Y nosotros?
Pasaremos de escribir código línea a línea a definir, calibrar y gobernar a los Ingenieros Sintéticos y las Agencias que escalan su trabajo.
El cuello de botella ya no será el código — se desplazará hacia la especificación.
Las capacidades fundacionales sostienen a los agentes; los agentes forman Individuos Sintéticos; los Individuos Sintéticos se coordinan en Agencias; y las Agencias colaboran en Salas de Co-Creación. Pasaremos de ciclos por semanas/meses/PI a ciclos de días u horas.
Humanos y agentes colaboran alrededor de objetivos compartidos. No es un chat — es un entorno de ejecución estructurado.
Agencia de Desarrollo · Agencia de Seguridad. Varios Individuos Sintéticos coordinados y agrupados según su especialidad.
Developer Sintético / Arquitecto Sintético — representa un rol completo. Colabora con humanos, acumula contexto, no descansa.
Ejecuta tareas especializadas. Tiene Skills, Intent y Guardrails. Se coordina con otros agentes. Escala masivamente.
Spec-Driven Development (SDD) no es una metodología de productividad; es el mecanismo que hace posible que los agentes construyan software útil y seguro. Y cambia fundamentalmente el rol del negocio.
"Si no puedes escribir la spec, no entiendes el requerimiento lo suficiente para construirlo. Dos horas de spec bien hecha evitan veinte horas de refactoring."
Gartner, Spec-Driven Development for Agentic Coding, 2026
El negocio ya no escribirá funcionalidades en un Documento Funcional. Definirá especificaciones: qué proceso queremos, cuáles son los criterios de aceptación, qué no debe hacer el sistema.
El código más peligroso no es el que tiene errores — es el que hace exactamente lo que se le pidió, pero lo que se pidió estaba mal definido. Una spec de calidad tiene cuatro componentes.
El qué y el para qué. Estado futuro deseado, KPIs medibles y límites del alcance. El negocio define el problema — no la solución.
Historias de usuario medibles. Los criterios dicen cuándo el agente terminó bien — y cuándo debe detenerse.
Qué puede y no puede usar el agente. Previene tecnologías no autorizadas o dependencias vulnerables.
Políticas, reglas de arquitectura y cumplimiento regulatorio. El agente no puede ignorarlas.
"Quiero mejorar el proceso de aprobación de créditos para que sea más rápido y el cliente tenga mejor experiencia."
La misma tecnología que multiplica la productividad expande nuestra superficie de ataque. Para un banco de relación, donde la confianza es el activo más crítico, esto es un aspecto relevante.
de pen testing logrados en 3 semanas con Claude Mythos.
Palo Alto · Project Glasswingde las vulnerabilidades encontradas por IA fueron convertidas en ataques funcionales de forma automática.
Palo Alto · Grupo IF, 2026antes de que estas capacidades estén en manos de atacantes en código abierto.
Palo Alto · Grupo IF, 2026cubiertas en un solo Patch Wednesday usando Mythos (vs < 5 CVEs/mes en un ciclo normal).
Palo Alto · Grupo IF, 2026promedio para detectar y contener una brecha.
IBM Cost of a Data Breach, 2024del código moderno es open source — principal vector de ataque.
Synopsys OSSRA Report, 2024Tenemos cobertura total sobre nuestras 61 Joyas de la Corona. Pero el 77% de nuestros servidores en producción no está en alcance. Las vulnerabilidades acumulan meses abiertos.
cobertura sobre 61 activos críticos "Joyas de la Corona".
cobertura de servidores en producción (189 / 820).
vulnerabilidades mitigadas con virtual patch (de 811 al cierre de Jun 26).
vulnerabilidades pendientes de remediación.
vulnerabilidades por obsolescencia — sistemas que ya no reciben parches.
promedio de vulnerabilidad abierta por línea de producto.
El 100% de cobertura sobre nuestras 61 Joyas de la Corona solo protege lo que decidimos llamar crítico. Si la lista está mal definida, protegemos lo irrelevante y dejamos expuesto lo que sí sostiene el negocio.
Si "Joya de la Corona" se define por antigüedad, visibilidad política o costumbre — y no por el impacto real en la operación — protegemos activos que no son tan importantes y podríamos estar dejando expuesto lo que sí sostiene el negocio.
Parte de las capacidades de negocio que sostienen la promesa de valor del banco. Un activo es joya si su falla detiene una capacidad crítica hoy — no porque siempre lo fue.
El 100% de cobertura de análisis de vulnerabilidades no dice nada sobre qué tan bien elegidas están esas 61 joyas. Antes de invertir más en protegerlas, aseguremos que la lista refleja lo que realmente sostiene el negocio.
El portafolio creció y cada vez es más difícil sostener una agenda de modernización continua; la IA agudiza el problema. Antes de acordar un modelo para elegir, necesitamos un diagnóstico honesto del estado actual.
El portafolio creció más rápido que nuestra capacidad de gestionarlo y modernizarlo. Cada recurso en sistemas obsoletos es un recurso que no va a diferenciación ni a adoptar IA.
Considerando un umbral de corte de 2.3 en la Matriz TIME. Si el umbral se moviera al punto medio (2.5), pasaríamos a 62% en zona de obsolescencia.
Hay patrones claros de obsolescencia: on-premise + desarrollo propio y enlatado + alta personalización. ¿Estas aplicaciones soportan capacidades diferenciadoras que sustenten la dedicación de TI?
¿Estamos de acuerdo en que TI debe liberar capacidad de lo común y no diferenciador para concentrarla en lo que nos transforma y prepara para el futuro?
El error más común es dejar aplicaciones en un limbo no gestionado: ni se mantienen bien, ni se planifica su baja. Esto acumula deuda técnica silenciosa que consume presupuesto sin generar valor.
Decisión de no continuar inversiones — la aplicación se usa como está. Permite acordar dejar de invertir en aplicaciones específicas.
Capacidades no diferenciadoras, on-premise, con alto nivel de deuda técnica. → Evaluar SaaS.
Capacidades diferenciadoras que no cumplieron la expectativa y de alto costo. → Evaluar alternativas.
Sistemas con alta personalización y alto grado de vulnerabilidades. → Evaluar estandarización y adopción.
Cómo influye el tipo de banco que somos, qué clasificaciones planteamos según prácticas de industria y qué implicancias tiene cada una.
No hay una clasificación universal. Lo que diferencia a un banco de relación multi-especialista es distinto a lo que diferencia a un banco de volumen.
Un edificio tiene capas que cambian a distintas velocidades — el terreno nunca cambia, la estructura dura 100 años, los muebles se reemplazan cada semana. Aplicarles la misma política es un error de diseño. Las aplicaciones funcionan igual.
Diferencia en volumen y costo. La mayoría de sus capacidades son de Registro estandarizado.
Diferencia en profundidad de relación, velocidad de respuesta y especialización. ¿Cuáles son las capacidades que sostienen esas promesas?
Diferencia en la capacidad de conectar ecosistemas en una sola plataforma. La tecnología debe hacerlo posible: ¿qué capacidades priorizamos?
Toca una pestaña para ver su política, aprovisionamiento y señales de alerta
Procesos comunes a todos los bancos: regulatorios, operacionales, de eficiencia. La mayoría del portafolio. El banco configura y adopta — no se desarrolla nada que el fabricante ya resuelve.
Adoptar, mínima customización.
Si el negocio pide algo distinto → ¿realmente diferencia al banco o es un deseable?
Capacidades que sostienen la ventaja competitiva. Procesos únicos del modelo de relación del banco. El core lo mantiene el vendor; la diferenciación la mantenemos nosotros.
Adaptar con criterio, proteger.
Si el negocio no puede clarificar su necesidad → no está listo para construir.
PoCs, MVPs, experimentos. Nuevos negocios, nuevos modelos de negocio, nuevas fuentes de ingreso. Rápido, iterativo, acepta el fracaso.
Construir rápido, medir, escalar o descartar.
Si el negocio no puede definir cómo va a medir el éxito o el fracaso de la iniciativa.
El error más frecuente: tratar aplicaciones de Registro como si fueran de Diferenciación, acumulando customización que nadie puede mantener. "En Registro, los vendors SaaS ofrecen innovación en sus releases trimestrales — customizar es perder acceso a ese flujo." — Gartner
Los números confirman lo que intuíamos — pero también revelan algo que no esperábamos.
Registro y Diferenciación tienen prácticamente el mismo porcentaje: 39% vs 38%. Pero Registro tiene más aplicaciones, así que mejorar ahí implica descuidar lo que nos diferencia.
El único tipo sin obsolescencia es Innovación, con 100% de adopción cloud. La nube mejora nuestra gestión de deuda técnica; pero, ¿estamos dispuestos a incrementar el gasto para lograrlo?
Algunos sistemas tienen módulos de Registro y módulos de Diferenciación. Son excepciones válidas, no errores del modelo. Debemos identificarlas y consensuar el tratamiento según lo que el negocio necesita.
¿Adoptamos el modelo de Clasificación por Ritmo de Cambio como marco oficial del banco?
Los criterios y el método de mapeo — para discusión y aplicación en el ejercicio posterior.
Un deportivo y un camión de carga tienen los mismos componentes genéricos. Pero lo que los diferencia depende de su propuesta de valor.
¿Todos los bancos del mercado necesitan esta capacidad de la misma manera?
¿La capacidad nos distingue de la competencia?
¿Exploramos un modelo de negocio nuevo o no probado?
¿Hay fabricantes de mercado que lo resuelven bien? ¿Customizar genera ventaja real — o solo preferencia local?
¿El negocio puede describir con precisión qué lo hace único? ¿Perderlo afectaría nuestra propuesta de valor con el cliente?
¿Podemos aceptar periodos de maduración mayores (ej. 6 meses)? ¿Budget y tiempo están acotados y acordados desde el inicio?
Una capacidad puede moverse entre capas cuando cambia la estrategia o el contexto de mercado. Lo que hoy diferencia, mañana puede ser estándar (→ Registro). Lo que hoy es Innovación, si escala, puede convertirse en Diferenciación. Revisión periódica sugerida.
2 grupos. Buscamos consenso explícito y vinculante para la priorización del siguiente ciclo. El ejercicio permitirá validar las reglas propuestas.
Conclusiones, compromisos y colaterales. Reglas de gestión · Asignación y atención · Hibernación · Cierre.
Clasificar el portafolio no libera capacidad por sí solo — solo la libera si cambia dónde ponemos a nuestra gente, donde está el valor.
¿Qué acciones debemos tomar para asignar nuestro tiempo y esfuerzo a lo diferenciador / innovador y liberarnos de la carga de lo común?
¿La clasificación de aplicaciones impacta la definición de valor? Valor Diferenciación > Valor Registro.
¿Una iniciativa sobre una aplicación de Registro puede tener Prioridad 1 en el ejercicio de priorización?
¿Qué hacemos con las iniciativas de personalización que hoy siguen llegando a los SoR — las rechazamos?
¿Debemos empezar a valorar la adopción de las aplicaciones de Diferenciación, partiendo de las de mayor costo?
¿Asignamos una capacidad fija y acotada (ej. un squad pequeño) para atender Registro, alineada a su política?
¿Quién tiene la potestad de rechazar una iniciativa de personalización sobre un SoR?
¿Acordamos tratar esto como Próximo Paso, a revisar y calibrar junto con la VMO, ATO y Portafolio?
Tenemos urgencias de modernización y de desarrollar capacidades diferenciadoras. Hibernación es una decisión de foco y prioridad — la lista es una propuesta para discusión.
Acelerar la migración pendiente a la plataforma de UBA.
Evaluar alternativas de aprovisionamiento o de canales alternos.
Frenar las personalizaciones, evaluar alternativas y despersonalizar para adoptar.
Frenar personalizaciones y lock-in con el fabricante. Evaluar alternativas de modernización sostenibles.
Hibernar hasta tener una definición de estrategia y hoja de ruta en la capacidad de Fraude.
Evaluar baja formal y consolidación en la plataforma BPM.
Evaluar sinergias y posible migración a Workvivo. Evaluar alternativas para la funcionalidad residual.
Las definiciones que gobiernan cómo clasificamos, aprovisionamos, priorizamos e hibernamos. Toca cada una para expandirla.