La IA no debería vivir dentro de cada aplicación: una capa compartida para una suite SaaS

El caso práctico: varias aplicaciones, una misma preocupación

Los productos pueden resolver problemas diferentes —soporte, aprendizaje, administración, cobranza o contenido—, pero repiten necesidades técnicas:

Si cada producto implementa estas capacidades por separado, el costo no está solamente en el código duplicado. También se multiplican las superficies de riesgo y las decisiones difíciles de auditar.

La idea de separar aquello que cambia del resto del sistema no es nueva. Parnas explicó en 1972 que una buena modularización debe ocultar decisiones de diseño susceptibles de cambio. Aplicado a la IA, el proveedor, el modelo, el formato de una instrucción o la estrategia de recuperación de conocimiento son decisiones que no deberían propagarse por cada aplicación.

• Enviar una solicitud con contexto y propósito.
• Aplicar instrucciones y reglas autorizadas.
• Consultar únicamente las fuentes que corresponden al caso.
• Seleccionar un modelo adecuado sin exponer esa decisión a la aplicación.
• Registrar consumo, latencia, errores y calidad.
• Permitir que una persona revise o detenga decisiones sensibles.

La decisión de arquitectura

La arquitectura conceptual se organiza en cuatro responsabilidades:

Productos SaaS

Cada aplicación conoce a su usuario, su proceso y sus reglas funcionales. No envía un mensaje genérico al modelo; solicita una capacidad definida, por ejemplo clasificar, resumir, explicar, extraer o proponer.

El producto conserva la validación funcional y decide qué hacer con la respuesta. La IA no recibe autoridad automática para ejecutar una consecuencia de negocio.

Capa compartida de IA

Esta capa recibe la solicitud mediante contratos estables y concentra las preocupaciones comunes:

Su valor no consiste en agregar otra pieza tecnológica. Consiste en evitar que cada aplicación resuelva de forma distinta los mismos problemas.

• Catálogo de capacidades disponibles.
• Orquestación y selección de rutas.
• Identidad, permisos y límites de acceso.
• Políticas, evaluaciones y versiones.
• Trazabilidad, latencia, consumo y costo.
• Tratamiento de errores, cuotas y degradación controlada.

Modelos intercambiables

La capa puede comunicarse con servicios en la nube o con modelos locales, según el caso. Esto no significa que todos los modelos sean equivalentes ni que cambiar de proveedor sea automático.

Cada cambio debe superar evaluaciones funcionales, de seguridad, costo y rendimiento. La portabilidad útil no consiste en cambiar un nombre de modelo; consiste en conservar el contrato y volver a comprobar el resultado.

Conocimiento compartido y dirección humana

Las especificaciones, reglas, decisiones y repositorios autorizados forman una fuente común de conocimiento. Sin embargo, el acceso debe limitarse por producto y propósito. Compartir una capa no significa compartir indiscriminadamente todos los datos.

La dirección humana permanece fuera del modelo: define el objetivo, aprueba los criterios de aceptación, revisa excepciones y conserva la decisión final. La arquitectura permite delegar procesamiento, no responsabilidad.

Controles que deben diseñarse desde el inicio

Una capa común también concentra riesgo. Por eso requiere controles explícitos:

NIST recomienda gobernar los riesgos de IA generativa a lo largo de su ciclo de vida, con documentación, medición, monitoreo y responsabilidades claras. Centralizar estas prácticas facilita su aplicación coherente, pero no elimina la obligación de validarlas en cada producto.

• Contratos antes que prompts. La aplicación debe invocar una capacidad con entradas, salidas, restricciones y criterios verificables. El prompt es una implementación interna, no el contrato del producto.
• Mínimo privilegio para datos y herramientas. Cada capacidad accede solo a las fuentes y acciones necesarias. OWASP identifica la inyección de prompts, la divulgación de información sensible y la agencia excesiva entre los riesgos relevantes de las aplicaciones con modelos de lenguaje.
• Evaluación antes de cambiar modelos. Un conjunto de casos representativos permite comparar exactitud, consistencia, seguridad, latencia y costo antes de habilitar una nueva ruta.
• Observabilidad común. La telemetría debe relacionar cada solicitud con producto, capacidad, versión, modelo, tokens o consumo equivalente, latencia, error y resultado de la evaluación. Las convenciones de OpenTelemetry para IA generativa muestran por qué conviene instrumentar estas operaciones con atributos comunes.
• Intervención humana proporcional al impacto. No toda respuesta necesita aprobación, pero una recomendación informativa no debe tratarse igual que una acción que modifica datos, compromete dinero o afecta a una persona.
• Degradación segura. Si el modelo no responde, excede una cuota o no alcanza el nivel mínimo de confianza, la aplicación debe conservar una ruta conocida: reintentar de forma controlada, pedir revisión o continuar sin IA cuando sea posible.

Qué se gana y qué no debe prometerse

Una capa compartida puede reducir duplicación, facilitar el control del consumo y permitir que nuevos productos reutilicen capacidades existentes. También hace más visible qué decisiones pertenecen al producto, cuáles a la plataforma y cuáles siguen siendo humanas.

Sin embargo, esta arquitectura no garantiza por sí sola mejores respuestas, menores costos ni independencia total de proveedores. Es un diseño conceptual que debe comprobarse mediante prototipos, pruebas de seguridad, evaluaciones comparables y observación del uso real.

El resultado esperado no es “tener IA en todas las aplicaciones”. Es construir una capacidad reutilizable que pueda evolucionar sin obligar a reconstruir cada producto.

Conclusión accionable

Antes de conectar el siguiente producto directamente con un modelo, conviene responder cuatro preguntas:

Si esas respuestas viven dentro de cada aplicación, la suite crecerá con dependencias difíciles de gobernar. Si se convierten en una capacidad compartida, la IA deja de ser una colección de integraciones aisladas y empieza a funcionar como arquitectura.

La ventaja no está en usar más modelos. Está en diseñar un sistema donde podamos cambiar la inteligencia sin perder el control del producto.

• ¿Qué capacidad de negocio estamos solicitando?
• ¿Qué contrato estable debe consumir la aplicación?
• ¿Qué datos, herramientas y decisiones puede utilizar esa capacidad?
• ¿Cómo comprobaremos calidad, seguridad, costo y posibilidad de cambio?