Por qué ninguna aplicación de IA debería empezar de cero

En este artículo, Ricardo Pla Pons explica cómo unas bases de IA compartidas y una entrega asistida por IA pueden reducir el trabajo repetido en las aplicaciones empresariales. A partir de la experiencia con el AI Hub de Mimacom, muestra cómo este enfoque puede acortar el time to value, reforzar la gestión y mejorar el caso de negocio de un abanico más amplio de casos de uso.

Puntos clave

• Tratar cada caso de uso de IA como un proyecto independiente genera costes técnicos, de gestión y de mantenimiento repetidos.
• Unas bases compartidas dan ventaja a las nuevas aplicaciones, mientras que la entrega asistida por IA acelera el trabajo restante.
• Una entrega más rápida pone soluciones funcionales en manos de los usuarios antes, lo que acorta tanto el time to market como el time to value.
• Mimacom desarrolló 13 aplicaciones en seis meses, ahorró 113 horas semanales y redujo el esfuerzo de entrega en un 66 % en cinco proyectos.

Los proyectos de IA suelen empezar con las mismas preguntas fundamentales: ¿qué modelos puede usar la aplicación? ¿Cómo accederá a los datos de la empresa? ¿Quién puede utilizarla? ¿Cómo se supervisará la actividad? ¿Cómo controlará la organización el coste, el riesgo y la calidad?

Estas preguntas son necesarias, pero responderlas por separado para cada aplicación genera una carga de entrega considerable. Los equipos dedican tiempo a reconstruir las mismas bases, la entrega se ralentiza y los casos de uso más pequeños pueden volverse difíciles de justificar, incluso cuando responden a una necesidad operativa clara.

La verdadera oportunidad va más allá de construir aplicaciones de IA individuales con mayor rapidez. Consiste en crear un modelo de entrega en el que cada nueva aplicación se beneficie del trabajo ya realizado, mientras la IA acelera el diseño y la construcción de la propia solución. En Mimacom hemos puesto estos principios en práctica con nuestro propio AI Hub, que reúne esas dos ventajas mediante bases reutilizables y una entrega de software asistida por IA.

En las siguientes secciones, analizo dónde aparece el esfuerzo repetido dentro del proceso de entrega y cómo el modelo del AI Hub puede acortar el camino desde la idea hasta un valor medible. Al final, tendrás una forma más clara de evaluar si tu enfoque actual está preparado para escalar o si simplemente está generando una serie de casos de uso aislados.

El trabajo oculto detrás de una aplicación de IA

Cuando alguien imagina una aplicación de IA, normalmente piensa en la parte visible: un copiloto, una herramienta de búsqueda inteligente o un workflow automatizado. Sin embargo, la aplicación visible es solo la capa superior del sistema.

Antes de poder usarla de forma segura y fiable, los equipos deben decidir dónde se ejecutará, a qué datos podrá acceder y cómo se autenticará a los usuarios. También deben establecer la seguridad y la gestión, el enrutamiento de modelos, la recuperación y la memoria, la observabilidad y las operaciones de prompts o agentes.

Los equipos de ingeniería saben bien que esto no son detalles secundarios. Determinan si una aplicación puede superar la fase de prototipo y funcionar en un entorno de negocio real. Además, suponen una parte importante del trabajo que se realiza antes de que los usuarios perciban cualquier beneficio.

La mayoría de los usuarios nunca verán este trabajo. Solo apreciarán si la aplicación les da una respuesta útil, completa una tarea o les ayuda a tomar una mejor decisión. Sin embargo, desde una perspectiva de negocio, ya se está invirtiendo tiempo y presupuesto antes de que la aplicación empiece a resolver el problema para el que fue creada.

Por qué los proyectos independientes generan costes repetidos

Este trabajo oculto resulta especialmente costoso cuando cada caso de uso de IA se trata como un proyecto aislado. Un equipo puede establecer un método para conectar los modelos con los datos internos, mientras otro crea sus propios controles de acceso y un tercero diseña un enfoque distinto para supervisar la calidad, el uso y el coste.

Cada proyecto puede resolver su problema inmediato, pero la organización paga varias veces por un trabajo similar. El conocimiento queda dentro de equipos de entrega concretos en lugar de convertirse en una capacidad organizativa capaz de sostener futuras aplicaciones.

Esta repetición también puede generar incoherencias. Las aplicaciones pueden usar controles de seguridad, patrones de integración, herramientas de supervisión o procesos de gestión distintos, incluso cuando operan dentro de la misma organización y dependen de capacidades técnicas similares.

El coste no se limita a las horas de desarrollo. Las revisiones técnicas repetidas pueden ralentizar las aprobaciones, la infraestructura independiente puede aumentar el esfuerzo de mantenimiento y los controles distintos pueden dificultar la supervisión. Un prototipo exitoso también puede necesitar un rediseño considerable antes de poder usarse a mayor escala.

Esto no significa que toda aplicación de IA deba usar una arquitectura idéntica. Un asistente orientado al cliente, una herramienta de búsqueda interna y un agente autónomo pueden tener usuarios, requisitos de datos y perfiles de riesgo muy distintos.

Por tanto, el objetivo no es estandarizarlo todo. Es identificar las capacidades que no necesitan reinventarse cada vez, sin dejar de adaptar cada aplicación al workflow y a la necesidad de negocio a la que responde.

Una base compartida da ventaja a cada aplicación

Esta es la idea detrás del AI Hub. El AI Hub es el modelo operativo de Mimacom para la entrega de software nativo de IA. Combina bases técnicas compartidas, una plataforma reutilizable, prácticas de desarrollo asistidas por IA y un portafolio creciente de aplicaciones de negocio dentro de un único enfoque de entrega.

En lugar de abordar cada aplicación como un entorno técnico nuevo, el Hub integra las capacidades comunes en un modelo de entrega compartido. El modelo tiene cuatro capas conectadas: bases, plataforma, agentes y copilotos, y soluciones. Las capas inferiores aportan capacidades técnicas reutilizables, mientras que las superiores las aplican a workflows y necesidades de usuario específicos.

Las bases cubren áreas como la infraestructura, los datos, la seguridad, la gestión, la identidad y el acceso. La plataforma aporta capacidades como los gateways de modelos, la recuperación, la memoria, la observabilidad y las operaciones de prompts y agentes.

Las capas superiores utilizan estas capacidades para crear agentes de código, agentes de dominio, copilotos integrados y productos de IA personalizados. Cada aplicación sigue resolviendo un problema de negocio específico, pero ya no necesita partir de una arquitectura en blanco.

Esto reduce el trabajo de configuración inicial, pero la reutilización es solo una fuente de eficiencia. El AI Hub también aplica la IA directamente a lo largo de toda la entrega de software: apoya actividades como la definición del alcance, la programación, las pruebas y la iteración.

Los equipos integran la IA en el producto final y la utilizan para construirlo de forma más eficiente. Las bases reutilizables reducen el trabajo que debe repetirse, mientras que la entrega asistida por IA reduce el tiempo necesario para el trabajo restante.

Juntas, estas ventajas acortan el time to market, ya que ayudan a los equipos a lanzar soluciones funcionales antes. Y, más importante aún, acortan el time to value, porque los usuarios pueden empezar a probar la aplicación, detectar mejoras y generar beneficios medibles antes en el ciclo de inversión.

Piénsalo así: muchos nos alegramos cuando la IA significó que ya no tendríamos que pasar horas escribiendo código boilerplate. El AI Hub aplica esa misma lógica a todo el proceso de entrega y extiende las ganancias de eficiencia más allá de la programación.

Sin embargo, el objetivo no es la velocidad por sí misma. Es llegar antes a evidencia útil. Una aplicación funcional en manos de los usuarios muestra si el problema es lo bastante importante, si la solución propuesta encaja en el workflow y si se justifica seguir invirtiendo.

El efecto portafolio

La mejor prueba de este modelo procede de nuestro propio uso interno. En seis meses, Mimacom construyó un portafolio de aplicaciones empresariales para distintas áreas operativas de la empresa, entre ellas ventas, gestión del talento, entrega de proyectos, gestión de la demanda, preventa y procesos con proveedores.

Nueve aplicaciones ya están en producción, dos están en acceso anticipado y otras dos se han definido como la siguiente oleada. Cada aplicación responde a una necesidad de negocio específica y, a la vez, se apoya en una base compartida.

El valor de esta base de IA compartida se hace más evidente a medida que crece el portafolio. La primera aplicación puede requerir nuevas capacidades, patrones de entrega o decisiones de gestión, mientras que la siguiente puede beneficiarse de ese trabajo.

Con el tiempo, los equipos desarrollan una comprensión más sólida de cómo conectar datos, gestionar el acceso a los modelos, supervisar el rendimiento y llevar las aplicaciones a producción. Cada proyecto conserva su propio propósito y requisitos, pero ya no necesita resolver cada problema de base de forma independiente.

El resultado es una ventaja acumulativa. Las inversiones anteriores siguen aportando valor a las nuevas aplicaciones en lugar de quedar encerradas en un único proyecto, lo que aumenta el retorno de las bases ya existentes.

Cómo cambia la economía de los casos de uso pequeños

Muchos problemas operativos son fáciles de identificar, pero difíciles de justificar como proyectos de software independientes. Una tarea puede llevarle 45 minutos a un empleado, una revisión puede requerir varias horas o un proceso de generación de informes puede depender de copiar información entre hojas de cálculo.

La ineficiencia es real, pero el retorno esperado puede no justificar un proyecto de desarrollo tradicional con infraestructura propia, integraciones, revisiones de seguridad y mantenimiento continuo. Por eso, las oportunidades más pequeñas se quedan en el backlog, aunque afecten al trabajo diario.

Las bases compartidas y la entrega asistida por IA cambian ese cálculo. Cuando bajan el coste y el esfuerzo necesarios para llegar a una aplicación funcional, resulta viable probar un abanico más amplio de casos de uso.

Los resultados del portafolio del AI Hub muestran lo que esto puede significar en la práctica:

Por separado, estas mejoras pueden parecer cambios menores en procesos concretos, pero, con un uso habitual, contribuyen a ahorrar 113 horas semanales en workflows seleccionados de talento, perfiles y procesos.

El valor va más allá de reducir el tiempo dedicado a cada tarea. Los empleados reciben la información antes, las revisiones avanzan más rápido y las personas cualificadas dedican menos tiempo a buscar, copiar o comprobar información manualmente.

El mismo modelo de entrega también cambia qué ideas merece la pena investigar. No todos los casos de uso resultarán valiosos, pero reducir el coste de probarlos permite llegar a esa conclusión a partir de evidencia, no de suposiciones.

La gestión debería acelerar la entrega

Dicho esto, es imposible defender la velocidad de forma creíble sin reconocer la necesidad de control. A medida que avanza la transformación hacia la IA, la gestión se ha convertido en una de las principales preocupaciones en torno a la IA empresarial. La presión por ir más rápido es real, pero también lo son las preguntas sobre el acceso a los datos, el comportamiento de los modelos, la rendición de cuentas, el coste y el riesgo regulatorio.

Por eso la gestión debe situarse en el centro del modelo de entrega, y no aparecer como una comprobación final una vez que la aplicación ya está construida. Cuando cada proyecto establece sus propios controles y procesos de revisión, la organización repite un trabajo que podría haberse abordado antes. Añadir la gestión solo cuando el prototipo ya está terminado también puede provocar retrasos, un rediseño extenso o una solución que no pueda pasar a producción.

Por eso la gestión debe situarse en el centro del modelo de entrega, y no aparecer como una comprobación final una vez que la aplicación ya está construida.

Ricardo Pla Pons, AI BU Director, Mimacom

Una base compartida ofrece un enfoque más práctico. En el AI Hub de Mimacom, la seguridad, la gestión, la identidad, el acceso y la observabilidad se sitúan por debajo de la capa de aplicación, lo que permite que estos requisitos den forma a la entrega desde el principio, en lugar de añadirse más adelante.

Esto no convierte cada aprobación en algo automático ni iguala todos los riesgos. Sí crea un punto de partida más coherente, que ayuda a los equipos a probar ideas dentro de límites definidos, mientras los especialistas mantienen la supervisión de las capacidades que requieren control centralizado.

Los prototipos exitosos tienen entonces un camino más claro hacia producción, porque los requisitos operativos y de gestión fundamentales ya se han tenido en cuenta. Bien planteada, la gestión favorece la velocidad al reducir la incertidumbre y evitar el retrabajo evitable.

¿Tu modelo de entrega de IA está preparado para escalar?

Una empresa puede construir varias aplicaciones de IA exitosas sin contar con un modelo de entrega repetible. El problema suele aparecer cuando crece la demanda y los equipos empiezan a resolver, otra vez, las mismas preguntas sobre datos, acceso, gestión y supervisión.

En ese momento, la verdadera prueba es si cada proyecto refuerza la capacidad de la organización para entregar el siguiente. Las bases compartidas pueden eliminar el trabajo de configuración repetido, mientras que la entrega asistida por IA puede acelerar el trabajo restante. El AI Hub de Mimacom reúne ambos elementos. En cinco proyectos, un trabajo estimado tradicionalmente en 3.360 horas se completó en 1.146 horas, una reducción del 66 %.

Al final, la primera prueba de un modelo de entrega de IA escalable es sencilla: ¿cada nueva aplicación empieza repitiendo el mismo trabajo, o se beneficia de las capacidades y el conocimiento que la organización ya ha construido?

El objetivo no es estandarizar todas las aplicaciones. Es dejar de reconstruir lo que no necesita ser único, para que cada nuevo caso de uso llegue antes al valor.