Un sistema empresarial debe poder incorporar capacidades de inteligencia artificial cuando aporten valor, y debe poder funcionar sin ellas cuando no lo aporten o cuando el proveedor cambie las condiciones. Estar preparado y ser dependiente son cosas distintas, y confundirlas al comprar traslada al sistema toda la volatilidad de un mercado que cambia varias veces al año.
La distinción tiene una traducción práctica: si el proveedor del modelo dejara de prestar servicio mañana, ¿qué dejaría de funcionar? Si la respuesta es «una funcionalidad», el sistema está preparado. Si es «el sistema», es dependiente.
API-first en serio. Cada función expuesta mediante un contrato documentado y versionado, no solo una interfaz de usuario. Es lo que permite que cualquier capacidad futura —de IA o no— se conecte sin abrir el sistema en canal.
Datos accesibles y estructurados. Con una fuente de verdad clara y posibilidad de exportación con relaciones, no un volcado plano. Sin esto, ninguna capa superior puede construirse.
Permisos resueltos en el dato. No en la pantalla. Es la condición para que un asistente o un agente pueda consultar sin convertirse en un agujero, por las razones que desarrollamos en la IA también puede filtrar secretos [enlace interno].
Trazabilidad de fábrica. Registro de qué cambió, quién lo hizo y cuándo. Es irrecuperable hacia atrás y es requisito normativo creciente.
Modelo de eventos. Que el sistema pueda notificar cuando algo ocurre, en lugar de obligar a consultar periódicamente. Es lo que hace posible cualquier automatización posterior sin degradar el rendimiento.
Configurabilidad de las reglas de negocio. Que los criterios se puedan cambiar sin desplegar código. Cuando las reglas están escritas en algún sitio legible, se pueden auditar, comparar y sustituir.
Los seis son buenas propiedades de arquitectura con independencia de la IA. Ese es justamente el argumento: un sistema bien construido ya está preparado, y uno que necesita adaptaciones extraordinarias para incorporar IA tenía un problema previo.
Señal | Qué implica | Riesgo |
|---|---|---|
La funcionalidad principal requiere el modelo | Sin proveedor no hay producto | Continuidad del negocio |
No hay comportamiento alternativo definido | Ante fallo del modelo, el sistema se detiene | Operativa diaria |
Las reglas viven en prompts no versionados | No se pueden auditar ni comparar | Cumplimiento y calidad |
El coste escala con el uso sin techo | Un pico de actividad dispara la factura | Presupuesto |
La segunda fila es la más frecuente y la más fácil de corregir en el diseño: definir qué hace el sistema cuando el modelo no responde. Puede ser encolar, degradar a una regla simple o escalar a una persona. Cualquiera de las tres es mejor que detenerse, y ninguna se decide sola.
Seis preguntas concretas para cualquier proveedor, sea o no un producto «de IA»:
Las seis se responden en una reunión y filtran más que cualquier comparativa de funcionalidades.
El argumento financiero es directo. Un sistema que cumple los seis requisitos tiene tres propiedades que se valoran en cualquier operación corporativa: se puede integrar con lo que venga, se puede auditar y otro equipo puede hacerse cargo de él.
Un sistema dependiente, en cambio, traslada al comprador la volatilidad del mercado de modelos: precios que cambian, versiones que se retiran y proveedores que, según la previsión de Gartner de 2025, en buena parte no seguirán en el mercado —la firma estimaba que de los miles de proveedores que se presentan como especialistas en agentes solo unos 130 lo eran realmente.
Comprar hoy un sistema dependiente es comprar la exposición completa a ese mercado.
Cuando se discuta una compra de software, hay una forma de plantearlo que ordena la decisión sin entrar en detalles técnicos: queremos un sistema al que se le pueda añadir IA, no un sistema de IA.
El primero es una inversión con vida útil de años cuyas capacidades crecerán con el mercado. El segundo es una apuesta sobre qué proveedor y qué modelo dominarán dentro de tres años, y esa apuesta no la debería hacer una empresa cuyo negocio es otro.
Que puede incorporar capacidades de inteligencia artificial cuando aporten valor y seguir funcionando sin ellas. La prueba es directa: si el proveedor del modelo dejara de prestar servicio mañana, un sistema preparado perdería una funcionalidad y uno dependiente dejaría de operar.
Seis: API documentada y versionada para todas sus funciones, datos accesibles y exportables con sus relaciones, permisos resueltos a nivel de dato y no de interfaz, trazabilidad de fábrica, modelo de eventos que notifique en lugar de obligar a consultar, y reglas de negocio configurables sin desplegar código.
Cuando la funcionalidad principal requiere el modelo para existir, cuando no hay comportamiento alternativo definido ante un fallo del proveedor, cuando las reglas viven en prompts no versionados que no se pueden auditar, y cuando el coste escala con el uso sin ningún techo.
Si todas las funciones están disponibles por API documentada, si los datos se pueden exportar con su estructura, si los permisos se resuelven en el dato o en la interfaz, qué se registra de cada cambio, qué ocurre si falla el proveedor de modelo y si se puede usar un proveedor propio.
No, y ese es el argumento: son buenas propiedades de arquitectura con independencia de la IA. Un sistema bien construido ya está preparado, y uno que necesita adaptaciones extraordinarias para incorporar inteligencia artificial tenía un problema de diseño previo.
Porque traslada al comprador toda la volatilidad de un mercado que cambia varias veces al año en precios, capacidades y disponibilidad. Gartner estimaba en 2025 que de los miles de proveedores que se anuncian como especialistas en agentes solo alrededor de 130 lo eran realmente.
¿Vas a comprar software este año? Evaluamos si lo que estás a punto de firmar está preparado para lo que viene o te ata a un proveedor concreto. Criterio técnico independiente, sin presentarnos como candidatos. Hablemos → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
