La adopción de la IA suele empezar con un caso de negocio sencillo. Un asistente de programación ayuda a los desarrolladores a trabajar más rápido. Un agente se encarga del trabajo operativo repetitivo. Un modelo resume documentos que antes llevaban horas de revisión a los empleados.
Un servicio de decisión clasifica solicitudes o elige qué flujo de trabajo debe ejecutarse a continuación. Cada uso puede tener sentido por sí mismo.
Las cuentas también pueden resultar atractivas. Una empresa puede sacar adelante más trabajo con el mismo equipo, reducir el esfuerzo repetitivo y evitar construir capacidades que un servicio de IA puede ofrecer de inmediato.
Apoyo esa dirección.
Pero, a medida que la IA pasa de ayudar a las personas a formar parte de cómo funciona la propia empresa, creo que otra consideración merece la misma atención:
¿Cuánta de la capacidad de la empresa sigue perteneciendo a la empresa?
Esto no es un argumento contra los proveedores externos de IA. Las empresas modernas ya dependen en gran medida de plataformas en la nube, productos SaaS, bases de datos, servicios de pago y muchas otras tecnologías externas.
La diferencia es que la IA empieza a entrar en ámbitos que históricamente contenían criterio humano, conocimiento de ingeniería y lógica de aplicación. Eso puede crear una forma de dependencia más profunda que el simple consumo de otro servicio tecnológico.
El riesgo rara vez aparece el primer día. Se desarrolla poco a poco, a medida que la tecnología tiene éxito.
La eficiencia puede convertirse en dependencia sin que nadie lo note
Piensa en el desarrollo de software. Una empresa introduce agentes de programación porque mejoran la productividad. Los desarrolladores los usan para generar código, investigar fallos, escribir pruebas, revisar cambios y entender partes del sistema que no conocen.
Al principio, el agente es claramente un asistente. La capacidad de ingeniería sigue dentro de la organización. Pero imagina esa misma empresa varios años después. Ahora los agentes realizan buena parte del trabajo rutinario de implementación.
Los equipos se reducen. Algunos puestos júnior desaparecen. La documentación recibe menos atención porque el agente puede inspeccionar el repositorio cuando hace falta.
Los ingenieros se acostumbran a pedir al modelo que les explique los sistemas que no conocen, en lugar de construir ese conocimiento por sí mismos. Ninguna de esas decisiones es necesariamente equivocada. Por separado, cada una puede ser racional.
Pero, en conjunto, plantean una pregunta importante:
Si esa capacidad de IA dejara de estar disponible, se encareciera mucho o dejara de ajustarse a las necesidades de la empresa, ¿cuánto de ese trabajo podría seguir haciendo la organización por su cuenta y con confianza?
Ahí es donde la eficiencia empieza a convertirse en un problema de arquitectura.
Accessible text alternative for this figure
Cinco etapas en orden. Uno, asistente de IA: ayuda a una persona a realizar su trabajo. Dos, flujo de trabajo integrado: la IA pasa a formar parte de un proceso de negocio repetible. Tres, capacidad operativa: los sistemas y los equipos esperan que la IA esté disponible. Cuatro, dependencia estructural: cambiar la capa de IA exige migración, evaluación o adaptación organizativa. Cinco, dependencia gestionada de forma deliberada: la organización conserva el conocimiento, la evaluación, el respaldo y la capacidad de cambiar de proveedor. El objetivo es una dependencia gestionada, no huir de la IA. Es un análisis de TechiesJournal.
Ya hemos visto una cara de este problema
En una Perspectiva anterior de TechiesJournal, Si la IA hace el trabajo júnior, ¿quién formará a la próxima generación de profesionales?, analicé el efecto de automatizar el trabajo con el que tradicionalmente las personas adquirían experiencia.
La preocupación no era que el trabajo júnior tuviera que seguir siendo manual para siempre. Era que las organizaciones deberían entender qué más desaparece cuando desaparece ese trabajo. Las tareas rutinarias a menudo hacen algo más que producir un resultado inmediato.
Enseñan a las personas cómo se comportan los sistemas. Las exponen a los errores. Forjan el criterio. Forman a los ingenieros sénior, analistas y especialistas que una organización necesitará más adelante.
La dependencia de la IA conlleva un riesgo paralelo. Cuando transferimos trabajo a la IA, también podemos ir transfiriendo poco a poco parte del conocimiento necesario para hacer ese trabajo. La ganancia inmediata de productividad es visible. La capacidad que se está perdiendo es mucho más difícil de ver.
Eso hace que esto sea algo más que un debate sobre la plantilla. Se convierte en una cuestión de resiliencia operativa.
La dependencia se vuelve más profunda cuando la IA entra en el software
Los agentes de programación siguen siendo relativamente fáciles de entender porque un ingeniero humano sigue visiblemente involucrado. La IA orientada a decisiones cambia la situación. Tradicionalmente, muchas decisiones del software se representan directamente en la lógica de la aplicación.
Por ejemplo:
Una transacción por encima de cierto umbral requiere una revisión adicional. Una solicitud de una categoría de clientes sigue un flujo de trabajo concreto. Una combinación particular de condiciones produce una acción específica. La empresa es dueña de esas reglas.
Puede inspeccionarlas, probarlas, cambiarlas y ejecutarlas sin preguntar a un servicio de inteligencia externo qué hacer. Ese modelo empieza a ampliarse.
Jev, de TypeSafe, por ejemplo, se está desarrollando específicamente como un modelo de decisión rápido para usarse dentro del software. En lugar de generar textos largos, recibe un estado y produce decisiones estructuradas con probabilidades.
OpenAI también ha presentado su Decisions API en versión preliminar limitada, diseñada para tareas como la clasificación, el enrutamiento y la elección de la siguiente acción de una aplicación entre posibilidades predefinidas.
Estas tecnologías son interesantes precisamente porque pueden hacer que el software sea más adaptable. Pero también cambian la naturaleza de la dependencia.
Si una aplicación le pregunta a un modelo externo:
¿Qué camino debe seguir esta solicitud?
el modelo ya no solo ayuda a un empleado. Se ha convertido en parte del comportamiento de la aplicación. Eso merece otra forma de pensar la arquitectura.
| Dimensión | Lógica de aplicación determinista | Capacidad de decisión asistida por IA |
|---|---|---|
| Comportamiento | Reglas explícitas definen el camino esperado | Un modelo ayuda a elegir entre los resultados permitidos |
| Propiedad | La lógica reside principalmente en el código de la empresa | La empresa es dueña del flujo de trabajo, pero parte del comportamiento puede depender de un modelo externo |
| Pruebas | Normalmente se pueden verificar reglas y resultados exactos | Puede que las evaluaciones tengan que probar el comportamiento en casos representativos |
| Cambio de proveedor | A menudo, una sustitución de la implementación | Puede requerir comparar el comportamiento y volver a validar |
| Respaldo (fallback) | Un camino determinista conocido | Requiere un respaldo o una escalada diseñados a propósito |
| Uso más adecuado | Reglas estables con condiciones claras | Situaciones en las que la incertidumbre o el criterio aportan un valor real |
Sustituir la API puede no sustituir la capacidad
Es tentador pensar que esto se resuelve poniendo al proveedor detrás de una interfaz. Es una buena práctica de ingeniería, pero puede no ser suficiente. Imagina que una organización usa un modelo de decisión durante varios años.
Con el tiempo, construye:
- prompts o definiciones de decisiones
- conjuntos de datos de evaluación
- umbrales de confianza
- reglas de escalada
- monitorización
- gestión de excepciones
- procesos de negocio basados en el comportamiento del modelo.
Ahora, otro proveedor resulta más atractivo. La integración con la API puede ser fácil de sustituir. El comportamiento quizá no. El nuevo modelo puede clasificar los casos límite de otra manera.
Las puntuaciones de confianza pueden comportarse de otro modo. Puede que haya que recalibrar los umbrales. Puede que los usuarios de negocio tengan que validar los nuevos resultados. Los flujos de trabajo regulados pueden requerir una nueva aprobación.
Eso significa que cambiar de proveedor puede parecerse menos a sustituir una biblioteca de software y más a cambiar parte del sistema de decisión. Por tanto, la dependencia no es necesariamente la API. Es todo lo que la organización ha construido en torno al comportamiento de esa IA.
El precio es solo una de las formas en que puede aflorar la dependencia
Sería demasiado simplista suponer que los proveedores de IA subirán los precios continuamente una vez que las empresas dependan de ellos. No hay base para hacer esa afirmación general, y la competencia puede empujar los precios tanto a la baja como al alza.
La cuestión más importante es que el precio unitario y la dependencia total son cosas distintas.
Un modelo puede abaratarse mientras la empresa gasta más en total.
¿Por qué?
Porque empieza a usar la IA en más sitios. Un desarrollador usa un agente para cada tarea de programación. La atención al cliente pasa a estar asistida por agentes. La búsqueda interna usa modelos.
El análisis de seguridad usa modelos. Los flujos de trabajo de negocio empiezan a llamar a servicios de decisión. Una interacción con la IA se convierte en miles o millones de interacciones automatizadas.
TypeSafe lo dice explícitamente al explicar el nombre Jev: una mayor eficiencia puede liberar una demanda mucho mayor de inteligencia de máquinas. Eso es positivo desde el punto de vista comercial cuando el uso adicional crea valor.
Pero significa que las organizaciones no deberían planificar la economía de la IA solo en función del precio actual por token. La pregunta más importante es qué parte del negocio acabará dependiendo de comprar continuamente inteligencia externa.
Diseñar la dependencia de forma deliberada
Esta es una forma de pensar habitual en arquitectura. Los arquitectos empresariales llevan décadas gestionando la dependencia mediante la portabilidad, la abstracción de servicios, la recuperación ante desastres, la propiedad de los datos, los estándares abiertos y la planificación de salida. La IA merece la misma disciplina.
Pero hay un elemento adicional que importa, porque la IA puede sustituir el conocimiento además de la tecnología. Si una empresa traslada una base de datos de una nube a otra, sus ingenieros siguen entendiendo de bases de datos.
Si cambia de plataforma SaaS de nóminas, su equipo de recursos humanos sigue entendiendo de nóminas.
Pero si la organización deja poco a poco de desarrollar una capacidad porque la realiza un sistema de IA, la empresa puede acabar perdiendo parte de la experiencia necesaria para sustituir ese sistema.
La dependencia tecnológica y la dependencia de capacidades pueden desarrollarse a la vez.
Eso no significa que las empresas deban construirlo todo por su cuenta. La mayoría de las organizaciones no deberían construir modelos de frontera ni reproducir productos que los proveedores especializados pueden ofrecer de forma mucho más eficiente.
El objetivo es más sencillo:
Usar inteligencia externa sin ceder más control del necesario sobre la capacidad que la rodea.
Eso significa mantener varias cosas bajo el control de la organización.
Accessible text alternative for this figure
Seis cosas que una organización debería mantener bajo su control. Uno, contexto de negocio: datos, políticas, terminología y conocimiento del dominio. Dos, evaluación: saber qué es un buen resultado con cualquier modelo. Tres, límites de decisión: mantener reglas deterministas donde basten. Cuatro, comportamiento de respaldo: definir qué pasa cuando la IA no está disponible o no tiene certeza. Cinco, experiencia interna: entender el trabajo lo bastante bien para evaluar la IA. Seis, límites con el proveedor: evitar supuestos propios de un proveedor por todas partes. El principio central es usar inteligencia externa sin ceder más control del necesario sobre la capacidad que la rodea. Es un análisis de TechiesJournal.
Contexto de negocio
Los datos, las políticas, la terminología y el conocimiento del dominio de la empresa no deberían existir solo dentro de una implementación específica de un proveedor.
Evaluación
La organización debería saber qué es un resultado «bueno» con independencia del modelo que esté usando en cada momento. Si se introduce otro modelo, la empresa debería poder probarlo frente a sus propias expectativas.
Límites de decisión
Donde las reglas deterministas sean suficientes, deberían seguir siendo deterministas. La IA debería usarse donde el criterio o la incertidumbre aporten un valor real, y no para sustituir una lógica de negocio sencilla solo porque puede hacerlo.
Comportamiento de respaldo
Los flujos de trabajo importantes deberían definir qué ocurre si el servicio de IA no está disponible, no tiene certeza o funciona fuera de sus condiciones de operación aprobadas.
Experiencia interna
Los empleados deberían seguir entendiendo la capacidad de negocio y técnica lo bastante bien como para evaluar lo que hace la IA.
Límites con el proveedor
La arquitectura de las aplicaciones debería evitar repartir por todas partes, sin necesidad, supuestos propios de un proveedor. Nada de esto elimina la dependencia. Lo que hace es que la dependencia sea gestionable.
La planificación de salida debe empezar antes de que la salida sea necesaria
Esto puede sonar prematuro cuando una implementación de IA funciona bien. Pero es precisamente cuando resulta más fácil. Gartner planteó hace poco una idea relacionada al hablar de la ingeniería desplegada en el cliente por parte del proveedor (forward-deployed engineering) para la IA agéntica.
Su preocupación es que las organizaciones pueden lograr avances rápidos al principio, pero no llegar a desarrollar suficiente capacidad interna para mantener y hacer evolucionar el sistema resultante de forma independiente.
Su recomendación incluye la transferencia de conocimiento, la propiedad y una estrategia de salida desde el principio, en lugar de esperar a que la relación sea difícil de cambiar. Creo que ese principio va más allá de la ingeniería desplegada en el cliente.
Antes de que una organización convierta un servicio de IA externo en parte de una capacidad crítica, debería entender:
- ¿Qué tendríamos que cambiar si este servicio no estuviera disponible?
- ¿Qué conocimiento necesitaríamos internamente?
- ¿Qué habría que volver a validar?
- ¿Qué datos y qué evaluaciones controlamos?
- ¿Podría otro modelo desempeñar este papel?
- ¿Qué seguiría funcionando mientras lo cambiamos?
No son preguntas que haya que hacerse porque esperemos que el proveedor falle. Son preguntas que hay que hacerse porque una arquitectura responsable da por hecho que la tecnología cambia.
El costo debe medirse más allá del consumo
Esto también cambia mi forma de pensar sobre el FinOps de la IA. Los tokens, las llamadas al modelo, el tiempo de ejecución de los agentes y el uso de herramientas siguen importando. Pero el panorama económico es más amplio.
Una organización madura puede acabar necesitando entender:
Costo de operación
¿Cuánto cuesta hoy este flujo de trabajo de IA?
Valor
¿Qué trabajo o resultado de negocio produce ese gasto?
Costo de cambio
¿Cuánto costaría trasladar la capacidad a otro lugar?
Costo en capacidades
¿Qué habilidades internas se están debilitando porque la IA hace el trabajo? Esos dos últimos son más difíciles de llevar a un panel. Aun así, a largo plazo pueden importar más que una pequeña diferencia en el precio de los tokens.
Perspectiva
La primera etapa de la adopción de la IA en las empresas giró en gran medida en torno a la capacidad. ¿Puede el modelo escribir código útil? ¿Puede entender documentos? ¿Puede el agente completar la tarea?
¿Puede el modelo de decisión mejorar el flujo de trabajo?
La siguiente etapa requiere otra consideración:
¿Qué le ocurre a la organización a medida que estos sistemas pasan a formar parte del trabajo diario?
Un sistema de IA que funciona bien se usará, naturalmente, cada vez más. Los equipos diseñarán procesos en torno a él. Los empleados aprenderán a confiar en él. El software empezará a dar por hecho que está disponible.
Eso no es un fracaso. Así es como se ve una adopción tecnológica exitosa. Pero el éxito crea dependencia.
La responsabilidad de la arquitectura no es eliminar esa dependencia. Es asegurarse de que la organización la entiende y conserva el control suficiente para adaptarse cuando cambien la tecnología, la economía o las necesidades del negocio.
Para mí, el principio es sencillo:
Usa la IA donde cree valor. Deja que elimine el trabajo innecesario. Deja que mejore las decisiones. Pero conserva el conocimiento, la evaluación, la arquitectura y el control operativo necesarios para cambiar la forma en que se suministra esa inteligencia.
La distinción importante no es entre las empresas que dependen de la IA y las que no. Probablemente, la mayoría de las organizaciones serias dependerán de ella. La distinción estará entre la dependencia que surgió por accidente y la dependencia que se diseñó de forma deliberada.
Lecturas relacionadas: Construir sistemas agénticos: de tu primer agente a un sistema fiable trata los límites y la fiabilidad a medida que aumenta la autonomía de los agentes, y Jev explicado: por qué este modelo de IA toma decisiones en lugar de escribir respuestas (en inglés) explica el modelo de decisión del que hemos hablado.
Fuentes y lecturas adicionales
Revisión de fuentes: 5 de octubre de 2026.
- TypeSafe AI — Introducing System One Models & Jev. Presentación de TypeSafe de su modelo de decisión en acceso anticipado y del razonamiento detrás de diseñar una IA específicamente para decisiones estructuradas en el software. Publicado el 15 de septiembre de 2026. Las cifras de rendimiento de la fuente las comunica el propio proveedor.
- OpenAI — DevDay 2026 Recap: Decisions API. Descripción de OpenAI de la Decisions API para clasificación, enrutamiento y selección de acciones entre opciones predefinidas, en versión preliminar limitada a 29 de septiembre de 2026. La disponibilidad puede haber cambiado desde entonces.
- Gartner — Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028. Análisis de Gartner sobre la ingeniería de IA desplegada en el cliente, con énfasis en la transferencia de conocimiento, la propiedad, la capacidad interna y la planificación de salida. La previsión se refiere a la ingeniería desplegada en el cliente por parte del proveedor, no a toda la IA empresarial.
- TechiesJournal — Si la IA hace el trabajo júnior, ¿quién formará a la próxima generación de profesionales?. Perspectiva de autor anterior sobre lo que las organizaciones corren el riesgo de perder cuando la IA automatiza un trabajo que antes desarrollaba la futura capacidad profesional.
- TechiesJournal — Construir sistemas agénticos: de tu primer agente a un sistema fiable. Análisis práctico de los límites, la fiabilidad y las consideraciones operativas a medida que aumenta la autonomía de los agentes.