El diagnóstico que nadie quiere escuchar
Cuando un CIO de banca me dice "queremos explorar la IA agéntica", la primera pregunta que hago no es sobre la tecnología. Es: ¿qué proceso te quita el sueño? No el más innovador, ni el que tiene el deck de PowerPoint más bonito. El que más le castiga al equipo operativo cada día. El que genera más reclamaciones. El que tiene más colas invisibles.
La selección errónea del caso de uso es la causa número uno de fracaso en proyectos de agentes en producción. Los equipos eligen el proceso más "cool" para el demo, no el proceso donde el ROI es medible en 6 semanas. El resultado: un piloto impresionante en el laboratorio y cero adopción en el negocio.
El corolario: si el ROI no es medible en 6 semanas, el alcance del proyecto debe redefinirse. No es una cuestión de ambición. Es una cuestión de supervivencia del proyecto en la primera revisión del comité de inversión.
SmartOps: lo que "90% de reducción de MTTA" significa en la práctica
El servicio SmartOps de GFT opera con agentes en producción en el Top-5 de entidades bancarias y aseguradoras españolas. El dato más citado: reducción del MTTA del 90%, de 10 minutos a menos de 1 minuto. Vale la pena entender qué hay detrás.
Un incidente de operaciones en una entidad financiera sigue un flujo clásico: alerta → triaje → asignación → diagnóstico → resolución → cierre. En el modelo tradicional, entre la alerta y el inicio del diagnóstico real pueden pasar fácilmente 8-12 minutos: el operador recibe la alerta, la interpreta, accede a los sistemas de monitorización, cruza con el histórico de incidencias similares y decide a quién escalar. Ese tiempo no es trabajo, es coordinación.
El agente de SmartOps hace ese triaje en segundos: correlaciona la alerta con el histórico, recupera los runbooks relevantes, ejecuta los checks de diagnóstico automáticos y presenta al operador un contexto completo con la causa probable y las opciones de resolución. El operador toma la decisión. El agente ejecuta la acción aprobada. El MTTA baja al 90% sin eliminar al humano — desplazándolo de las tareas de búsqueda y correlación a la decisión real.
(10 min → <1 min)
españolas en producción
proceso al primer ROI
El conocimiento de dominio que no se puede improvisar
AWS proporciona la infraestructura: Amazon Bedrock AgentCore para la memoria persistente de estado de los expedientes, Amazon Bedrock como runtime de los modelos, SageMaker con Deep Learning Containers para los modelos propios dentro de la VPC del cliente. GFT aporta algo que no está en ningún catálogo de servicios cloud: el conocimiento regulatorio codificado en el diseño del sistema.
La circular DCS del Banco de España, las certificaciones de obra en financiación promotora, el cumplimiento normativo DDRA/ENS en seguros — no son restricciones que se añaden al final para pasar la auditoría. Son requisitos de diseño desde el día 1. Un agente que aprueba automáticamente pagos sin considerar el reglamento de poderes interno será bloqueado por el departamento legal antes de llegar a producción. Un modelo de scoring que usa datos de clientes sin trazabilidad suficiente para el CISO nunca saldrá del piloto.
La diferencia entre un integrador tecnológico y un partner de negocio en sectores regulados es exactamente esa: saber que la circular de provisiones del Banco de España puede estar codificada en un bloque COBOL sin documentar, y diseñar el proceso de análisis para encontrarla antes de que la omisión genere un incumplimiento en producción.
El patrón que fracasa: construir un agente técnicamente sólido y luego intentar "encajarlo" en los requisitos regulatorios. El patrón que funciona: diseñar el marco de gobernanza y auditoría desde la arquitectura, de forma que el comité de riesgos reciba un documento de trazabilidad ReAct completo antes de la primera revisión, no después.
La metodología en cuatro pasos — y el orden importa
-
Selección del proceso por "dolor" No empezar por el proceso más innovador, sino por el que más castiga al equipo operativo. El criterio: ¿qué tarea genera más reclamaciones, más horas de espera burocrática o más rotación en el equipo? Ese es el primer agente. La adopción interna está asegurada porque los propios usuarios quieren que desaparezca el problema.
-
Definición del KPI de negocio el día 1 Antes de escribir una línea de código, el indicador de éxito debe ser medible, tener un valor actual documentado y un objetivo alcanzable en 6-8 semanas. MTTA, tiempo de tramitación, coste por operación, tasa de error en revisión manual. Si el KPI no existe o no es medible, el proyecto no tiene condiciones de producción — sólo tiene condiciones de demo.
-
Human-in-the-loop gradual desde el diseño En sectores regulados, el agente empieza en modo "asistente": propone, el humano aprueba. La confianza se construye con datos de las primeras semanas. La autonomía supervisada se amplía cuando el comité de riesgos tiene evidencia de tasa de error, no cuando el equipo técnico declara que el modelo "funciona bien". Este orden no es negociable si se quiere aprobación regulatoria real.
-
Pack de gobernanza y auditoría listo para el comité La trazabilidad ReAct de cada decisión del agente, los marcos de responsabilidad legal y los logs de auditoría no son un entregable del proyecto. Son una precondición para que el proyecto exista en producción. Prepararlos antes de la primera revisión del comité de riesgos y cumplimiento elimina el bloqueo más frecuente en proyectos de agentes en entidades financieras.
El ecosistema técnico: por qué AWS + GFT
Amazon Bedrock AgentCore resuelve el problema de estado persistente en agentes de larga duración. Un expediente de siniestro, una operación de crédito promotor o un incidente de operaciones crítico puede estar activo durante días o semanas con múltiples actores involucrados. Mantener el contexto completo entre sesiones sin que nadie tenga que reintroducir el historial es la diferencia entre un agente que funciona en producción y uno que funciona en un demo de 15 minutos.
Kiro como IDE agéntico spec-driven cambia el cuello de botella en proyectos de modernización. El problema históricamente no era escribir código moderno — era documentar qué hace el código antiguo. Kiro genera primero las especificaciones (requisitos con criterios de aceptación, diseño, plan de tareas) y luego propone la implementación contra esas specs. En proyectos de modernización de mainframe, esas specs son la documentación funcional que el proyecto nunca logró producir manualmente.
Los Deep Learning Containers de SageMaker son la respuesta al CISO que pregunta "¿los datos del cliente salen de nuestro entorno?". El modelo corre dentro de la VPC del cliente, el tráfico a Bedrock usa VPC endpoints privados y nunca sale a internet. Esa arquitectura convierte una pregunta de bloqueo en una respuesta de diseño.
Lo que separa producción real de un piloto bien presentado
La diferencia entre llevar un agente a producción en el Top-5 de la banca española y tener un piloto en el laboratorio no es la calidad del modelo. Es la acumulación de decisiones de diseño correctas en los puntos donde los proyectos habitualmente fracasan: la selección del caso de uso, el KPI medible desde el día 1, el human-in-the-loop diseñado antes de que el comité lo exija y la gobernanza preparada para la auditoría, no construida después de ella.
El conocimiento de dominio regulatorio — DCS, DORA, ENS, DDRA — no se aprende en un sprint. Se acumula en proyectos reales en producción. Esa es la barrera de entrada que protege a los clientes de los integradores que venden tecnología sin entender el negocio que tienen que transformar.