El framework de tres preguntas que aplicamos antes de recomendar cualquier proyecto de integración
Un estudio del MIT publicado en 2025 encontró que el 95% de los pilotos de IA generativa en empresas no logran entregar un retorno medible. Otro dato, de la Universidad Di Tella, ubica en 71% la proporción de proyectos de sistemas que fracasan en cumplir su objetivo original. Los números varían según quién los mida, pero la conclusión de fondo se repite en cada consultoría que hemos hecho: la mayoría de estos proyectos no fracasan por un problema de código. Fracasan porque nadie hizo las preguntas correctas antes de empezar a escribirlo.
En nuestra experiencia, cuando un cliente nos trae una propuesta de integración, ya viene con el entusiasmo técnico resuelto. Alguien identificó dos sistemas que deberían hablarse, encontró la API o el conector, y armó un plan de sprints. Lo que casi nunca viene resuelto es la parte que decide si el proyecto va a sobrevivir su primer año en producción.
Por eso, antes de poner un solo consultor a trabajar, pasamos cada propuesta por tres preguntas. Si una integración no puede responderlas con claridad, no la recomendamos, sin importar qué tan elegante sea la arquitectura propuesta.
Dueño: qué decisión de negocio se vuelve posible, y quién responde por ella.
Riesgo: qué pasa si esto falla en producción, y si podemos contenerlo.
Continuidad: quién lo va a mantener cuando el consultor ya no esté.
Qué decisión de negocio se vuelve posible gracias a esto, y quién es su dueño
La mayoría de las propuestas de integración se justifican con una palabra, eficiencia. Es una respuesta que suena bien y no dice nada. La pregunta real es más incómoda, quién en la organización va a tomar una decisión distinta, más rápida o mejor informada, el día que esta integración esté funcionando, y esa persona sabe que este proyecto existe.
Cuando la respuesta es un departamento entero o "todos los que necesiten el dato", es una señal de alerta. Las integraciones que sobreviven tienen un dueño concreto, alguien que pidió el resultado, que va a usarlo la primera semana, y que va a notar si deja de funcionar. Las que no lo tienen se convierten en el sistema que nadie reclama cuando algo se rompe, y que tampoco nadie defiende cuando llega el momento de recortar presupuesto.
Qué pasa si esto falla en producción, y podemos contenerlo
Esta pregunta se volvió más urgente con la llegada de agentes de IA que ya no solo leen datos, sino que ejecutan acciones sobre sistemas críticos. No preguntamos si el proyecto puede fallar, todos pueden. Preguntamos qué tan grande es el radio de la explosión cuando eso pase, y si existe una forma de apagarlo sin apagar todo lo demás.
En la práctica, esto significa exigir respuestas concretas antes de aprobar el diseño, no después del primer incidente:
Reintentos seguros: ¿existe un mecanismo de reintento que no duplique una transacción?
Interruptor manual: ¿hay un punto donde alguien pueda cortar el flujo sin tocar código?
Validación de datos: ¿el sistema que recibe los datos distingue una actualización legítima de una corrupta?
Un cliente del sector financiero con el que trabajamos quería conectar un agente de IA directamente a su sistema de conciliación contable, sin capa intermedia. La pregunta del radio de explosión fue suficiente para rediseñar el proyecto con una zona de contención donde el agente propone cambios pero un proceso separado los aplica. El proyecto tardó tres semanas más. También evitó ser la razón por la que alguien tuvo que explicarle al directorio por qué la conciliación de marzo no cuadraba.
Quién va a mantener esto dentro de dos años, cuando el consultor ya no esté
Esta es la pregunta que menos le gusta escuchar a quien está entusiasmado con lanzar el proyecto, y la que más dinero ahorra a mediano plazo. Una integración bien construida pero sin dueño técnico interno se convierte, con el tiempo, en la pieza que nadie se atreve a tocar. Es la definición práctica de deuda técnica, no el código mal escrito, sino el conocimiento que se fue con la persona que lo escribió.
Antes de avanzar, pedimos que el cliente pueda nombrar a la persona o el equipo que va a heredar esto, y confirmamos que exista documentación suficiente para que esa persona no dependa de nosotros para entenderlo. Si la respuesta es "ya veremos" o "lo va a mantener el mismo proveedor para siempre", replanteamos el alcance. Un proyecto que solo funciona mientras el consultor original sigue disponible no es una integración, es una dependencia con forma de proyecto.
Podríamos haber construido una lista de cuarenta puntos de verificación, y de hecho existen frameworks de arquitectura empresarial que lo hacen. Preferimos tres preguntas porque cualquier persona en una reunión, técnica o no, puede hacerlas y notar cuando la respuesta es vaga. Cuando el dueño de negocio no está claro, el riesgo de falla no está contenido, o nadie va a mantener lo que se construye, no hace falta un comité de arquitectura para saber que el proyecto necesita más trabajo antes de empezar.
La próxima vez que alguien en tu organización proponga conectar dos sistemas, o sumar un agente de IA a un proceso existente, prueba con estas tres preguntas antes de aprobar el primer sprint. En más de un caso, la respuesta más útil que puede dar un proyecto de integración es todavía no.
Comentarios
Publicar un comentario