El MVP de IA funciona. ¿Qué falta para llevarlo a producción?
Lograr que un agente de IA funcione ya no es necesariamente la parte más difícil. El desafío aparece cuando tiene que conectarse con datos y sistemas reales, actuar dentro de procesos críticos y hacerlo con los niveles de seguridad, trazabilidad y control que exige una organización financiera.
La adopción de inteligencia artificial en servicios financieros está avanzando más rápido que su capacidad de escalarla. En 2026, KPMG encontró que el 59% de las organizaciones financieras relevadas ya obtiene valor de negocio de la IA, pero solo el 27% está logrando escalarla a nivel enterprise. La brecha ya no está solamente en experimentar: está en ejecutar.
Es una diferencia importante. Porque un MVP puede demostrar que una iniciativa tiene sentido. Pero producción exige responder una pregunta mucho más incómoda: ¿Está preparada la organización para dejar que esa IA opere realmente sobre sus datos, sistemas y procesos?
POC, MVP y producción no prueban lo mismo
Los términos POC y MVP se utilizan con distintos matices según la organización. Para esta conversación, la distinción que importa es qué estamos validando en cada etapa.
- Una POC permite comprobar factibilidad: si una tecnología, un modelo o un agente puede resolver determinado problema.
- Un MVP da un paso más. Prueba ese caso de uso en un contexto acotado, con datos más cercanos a la realidad y suficiente funcionalidad como para evaluar su utilidad.
Producción cambia la naturaleza del problema.
Ya no alcanza con que el agente funcione correctamente en determinados escenarios. Tiene que hacerlo de manera consistente dentro del ecosistema tecnológico y operativo de la organización.
- Tiene que acceder a información real.
- Conectarse con aplicaciones existentes.
- Utilizar APIs y herramientas.
- Respetar permisos.
- Manejar excepciones.
- Dejar trazabilidad.
- Escalar.
Y, si tiene capacidad de actuar, hacerlo dentro de límites que la organización pueda explicar y controlar.
Deloitte plantea justamente que pasar de pilotos de IA a sistemas productivos requiere una base enterprise consistente, con arquitectura, gobierno, gestión de datos y supervisión humana. Un piloto aislado no debería convertirse simplemente en el sistema de producción agregándole volumen.
Del MVP a producción: las siete preguntas que cambian la conversación
Cuando analizamos un caso desde COA, el salto a producción obliga a mirar al menos siete dimensiones. No son etapas independientes ni un checklist regulatorio: están conectadas entre sí.
1. Data: ¿puede confiar en los datos con los que opera?
Un agente es tan confiable como el contexto al que puede acceder.
Antes de pensar en autonomía hay que entender qué información necesita, dónde se encuentra, quién es responsable por ella, qué calidad tiene y bajo qué condiciones puede utilizarse. En una entidad financiera, esa información rara vez vive en un único lugar. Puede distribuirse entre data warehouses, core, sistemas satélite, documentos, data lakes y aplicaciones legacy. Esto convierte al gobierno del dato en parte de la arquitectura del agente, no en un proyecto separado.
2. Integración: ¿con qué ecosistema tiene que convivir?
El agente puede ser nuevo. Los sistemas con los que tiene que trabajar no.
El MVP puede haber resuelto una integración puntual. Producción obliga a preguntarse cómo interactuará con core bancario, APIs, sistemas de fraude, CRM, workflows internos, documentos, plataformas cloud y aplicaciones on-premise.
Este punto es especialmente relevante en organizaciones financieras porque los agentes no llegan a reemplazar mágicamente la arquitectura existente: la heredan.
La experiencia de COA en integración, datos y sistemas financieros críticos es precisamente una de las razones por las que la estrategia de la compañía no plantea Agentic AI como una capacidad aislada, sino como la combinación de Data + Integration + AI + Governance.
3. Identidad y acceso: ¿quién es el agente para nuestros sistemas?
Esta pregunta suele aparecer tarde. Mientras el agente solamente genera una respuesta, su identidad puede parecer una consideración técnica. Cuando empieza a consultar información sensible, utilizar herramientas o ejecutar una acción, deja de serlo.
¿Opera con una service account? ¿Hereda permisos del usuario? ¿Tiene identidad propia? ¿Puede acceder a todos los recursos disponibles para esa identidad o solo a un subconjunto? La identidad determina después qué puede consultar, qué puede ejecutar y, fundamentalmente, a quién se atribuye una acción.
4. Autonomía: ¿qué le estamos permitiendo hacer?
No es lo mismo leer que recomendar, recomendar que modificar y modificar que ejecutar. Cada salto aumenta el impacto potencial de una decisión del agente y cambia el nivel de control necesario. La pregunta correcta no es simplemente si queremos agentes autónomos. Es mucho más concreta: ¿Qué nivel de autonomía queremos permitir para este caso, sobre estos sistemas, bajo estas condiciones?
En algunos procesos, un agente podrá actuar de manera autónoma dentro de parámetros muy definidos. En otros deberá preparar una recomendación que una persona apruebe. Y habrá acciones que directamente deberían quedar fuera de su alcance.
La autonomía no debería aparecer como consecuencia accidental de las capacidades de la herramienta. Tiene que ser una decisión de diseño.
Ahí entran los guardrails. En Agentic AI, los guardrails son las reglas y mecanismos de control que definen qué puede hacer un agente, bajo qué condiciones y cuándo debe detenerse, solicitar autorización o escalar una decisión a una persona. No se trata solamente de evitar respuestas inadecuadas. En un entorno enterprise, pueden limitar qué herramientas puede utilizar, sobre qué datos puede actuar, qué operaciones están permitidas, bajo qué umbrales puede ejecutarlas y qué situaciones requieren intervención humana. Cuanta más autonomía se habilita, más explícitos tienen que ser esos límites.
5. Supervisión humana: ¿cuándo tiene que intervenir una persona?
Human-in-the-loop no significa agregar una aprobación manual a todo, significa definir dónde aporta control. ¿Qué decisiones requieren aprobación? ¿Qué ocurre frente a una excepción? ¿Cuándo debe escalarse un caso? ¿Quién interviene? ¿Qué sucede si la confianza del sistema cae por debajo de determinado nivel? Resolver mal esta capa puede generar dos extremos igualmente problemáticos: agentes con autonomía excesiva o automatizaciones tan intervenidas que eliminan gran parte del beneficio buscado.
6. Observabilidad: ¿podemos reconstruir lo que ocurrió?
En producción no alcanza con saber que el agente produjo una respuesta equivocada.
Hay que poder reconstruir qué información utilizó, qué herramientas consultó, qué acciones ejecutó, bajo qué identidad lo hizo, qué decisiones tomó el sistema y dónde intervino una persona. Logging, trazabilidad, evaluación y monitoreo dejan entonces de ser elementos técnicos secundarios. Son los mecanismos que permiten operar, mejorar y auditar el sistema.
7. Ownership y gobierno: ¿quién responde por el agente?
Cuando un agente atraviesa varias áreas, esta pregunta se vuelve particularmente difícil.
Data puede administrar los modelos. Tecnología, la infraestructura. Seguridad, los accesos. Negocio, el proceso. Risk o Compliance, determinados controles, pero alguien necesita responder por el caso completo.
El paso a producción exige definir ownership, responsabilidades, lifecycle, políticas y mecanismos de revisión. El framework de COA lo plantea como la evolución desde
Trusted Data → Responsible AI → Controlled Agents, incorporando desde calidad y acceso al dato hasta identidad, permisos, herramientas, guardrails, supervisión humana, observabilidad y accountability.
El riesgo de no resolverlo no es solamente tecnológico
Una organización puede tener varios MVP exitosos y, sin embargo, no estar construyendo una verdadera capacidad de IA.
Si cada iniciativa necesita resolver desde cero sus datos, integraciones, identidades, permisos, controles y mecanismos de monitoreo, el costo empieza a acumularse.
Aparecen integraciones caso por caso. Se multiplican las dependencias entre equipos. Las aprobaciones se vuelven más lentas. Cada nuevo agente incorpora una nueva combinación de riesgos y controles. Y una inversión que parecía destinada a generar productividad empieza a producir más complejidad.
El costo real es el tiempo que tarda la organización en transformar inversión en IA en capacidad operativa.
KPMG encontró en su Global AI Pulse Q3 2026 una diferencia significativa entre experimentar y capturar resultados: entre las organizaciones que ya reportan ROI consolidado, el 86% cuenta con una capa formal de gestión de IA a nivel transversal o enterprise. Entre las que permanecen en experimentación, esa proporción cae al 31%.
No significa que governance produzca por sí solo el retorno. Sí muestra algo relevante: a medida que la IA escala, la capacidad de gestionarla deja de ser accesoria.
En Perú, producir IA también significa integrarla a un sistema financiero que está cambiando
Este desafío adquiere especial relevancia para bancos, fintechs, cajas y aseguradoras peruanas. Durante 2026, la SBS avanzó con la implementación del Sistema de Finanzas Abiertas. La hoja de ruta contempla intercambio estandarizado de información mediante APIs y los lineamientos publicados en julio incorporan estructura de gobernanza, interoperabilidad, marco de confianza y estándares de seguridad.
La SBS también reglamentó en julio el modelo de Banking as a Service (BaaS), estableciendo condiciones, políticas y procedimientos para que las entidades puedan ofrecer servicios bajo este modelo preservando seguridad y protección de los usuarios.
Esto no implica que estas normas regulen específicamente Agentic AI. Sí muestra hacia dónde está evolucionando el entorno tecnológico financiero peruano: más APIs, más interoperabilidad, más actores conectados y más necesidad de administrar de manera explícita accesos, seguridad y responsabilidades.
En ese contexto, incorporar agentes capaces de consultar información, decidir o ejecutar acciones no puede analizarse únicamente como un proyecto de IA.
Es también un problema de arquitectura enterprise.
Entonces, ¿cuándo está un MVP realmente listo para producción?
No cuando responde mejor, no cuando la demo convence al management, y tampoco cuando terminó el desarrollo del agente. Está listo cuando la organización puede explicar cómo ese agente operará dentro del negocio real: sobre qué datos, conectado a qué sistemas, bajo qué identidad, con qué permisos, hasta dónde puede actuar, qué requiere supervisión, cómo se observa su comportamiento y quién responde por él.
Ese es el salto que separa una iniciativa prometedora de una capacidad que puede escalar.
En COA trabajamos ese espacio entre el MVP y la operación combinando Data, Integration, AI y Governance, especialmente en organizaciones financieras donde los agentes tienen que convivir con sistemas críticos, arquitecturas híbridas y requisitos de control enterprise. La propuesta no es empezar por una tecnología determinada, sino identificar primero qué necesita el caso para poder operar.
¿Qué tan preparada está tu organización para llevar IA a producción?
Un MVP exitoso demuestra que el caso puede funcionar, ahora ¿la organización tiene las capacidades necesarias para operarlo y escalarlo?
Realizá la Evaluación de Madurez de IA de COA y obtené un diagnóstico sobre las principales dimensiones que condicionan la adopción y escalabilidad de IA, junto con recomendaciones para avanzar.
¿Ya tenés un caso concreto?
Si estás llevando un MVP a producción, definiendo gobierno, integrando agentes con sistemas existentes o buscando escalar nuevas iniciativas, podemos conversar sobre el desafío.Preguntas frecuentes
¿Cuál es la diferencia entre una POC, un MVP y un sistema de IA en producción?
Una POC busca validar la factibilidad de una idea. Un MVP permite probar un caso de uso acotado con condiciones más cercanas a la realidad. Producción exige además que la solución pueda integrarse, operar, escalar, monitorearse y gobernarse dentro del entorno enterprise.
¿Qué necesita un agente de IA para pasar a producción?
Además del modelo o agente, normalmente requiere datos confiables, integración con sistemas y APIs, identidad y permisos, límites de autonomía, supervisión humana, observabilidad, trazabilidad y un owner claramente definido.
¿Por qué AI Governance se vuelve más importante al pasar a producción?
Porque el impacto potencial cambia cuando la IA deja de solamente generar contenido y comienza a consultar información sensible, recomendar decisiones, modificar datos o ejecutar acciones. A mayor autonomía, mayor necesidad de definir controles y accountability.
¿Agentic AI requiere reemplazar los sistemas legacy?
No necesariamente. En muchas organizaciones, el desafío consiste precisamente en integrar los agentes con cores, APIs, data platforms, documentos y aplicaciones existentes de manera controlada. Deloitte identifica la integración con sistemas legacy como uno de los obstáculos relevantes para llevar iniciativas agénticas a producción.