Ya hemos hablado de la deuda técnica en general y de cómo se acumula en la automatización de una empresa: en qué es la deuda técnica en automatización tratamos los atajos genéricos sin documentar, y en qué es la deuda de automatización hablamos de lo contrario, el coste de no automatizar todavía. Este artículo se centra en una tercera cosa, más específica y menos comentada: la deuda técnica que se acumula dentro de un sistema construido sobre modelos de lenguaje, con formas de deterioro que no existen en la automatización tradicional porque dependen de cómo funcionan realmente estos modelos.
En qué se diferencia de la deuda técnica "de siempre"
Una automatización clásica, basada en reglas fijas, falla de forma predecible: si algo se rompe, suele ser por un cambio de formato o de sistema externo, y el fallo es visible. Un sistema basado en modelos de lenguaje puede degradarse de forma silenciosa, sin ningún error visible, porque el propio comportamiento del modelo puede cambiar tras una actualización del proveedor, o porque las instrucciones que gobiernan al agente han crecido de forma desordenada hasta volverse contradictorias entre sí. Es un tipo de fragilidad distinto, y por eso necesita un vocabulario propio.
Deuda de prompt
El conjunto de instrucciones que gobierna a un agente de IA rara vez nace perfecto y se queda quieto. Cada excepción que aparece en producción suele resolverse añadiendo una línea más a las instrucciones: "si el cliente pregunta por X, responde así", "si aparece la palabra Y, no hagas Z". Con el tiempo, ese conjunto de instrucciones crece hasta convertirse en un documento largo, con reglas que se contradicen entre sí y que nadie recuerda por qué se añadieron. Es el equivalente, en un sistema de IA, al código lleno de parches sin documentar de la deuda técnica clásica, pero con un agravante: una instrucción mal redactada no falla con un error visible, cambia sutilmente el comportamiento del agente en casos que nadie está probando activamente.
Deuda de dependencia de modelo
Muchos sistemas de IA quedan construidos alrededor de un modelo concreto de un proveedor concreto, con su forma particular de responder a determinadas instrucciones. Si ese proveedor actualiza el modelo, lo retira o cambia sutilmente su comportamiento —algo que ocurre con más frecuencia de la que se reconoce—, todo lo que se ajustó específicamente a las peculiaridades del modelo anterior puede dejar de funcionar igual de bien, sin ningún aviso previo por parte del proveedor. Cuanto más ajustado esté un sistema a los detalles concretos de un único modelo, mayor es esta deuda, algo relacionado con lo que tratamos en cómo elegir el modelo de IA para tu caso de uso: elegir bien de partida no elimina esta deuda, pero sí la hace más gestionable.
Deuda de evaluación
En el desarrollo de software tradicional, un conjunto de pruebas automáticas avisa cuando un cambio rompe algo. La mayoría de sistemas de IA construidos con prisa no tienen ningún equivalente: nadie comprueba, de forma sistemática, si las respuestas del agente siguen siendo correctas después de cambiar una instrucción, de actualizar el modelo o de ampliar el proceso a un caso nuevo. Esta es, probablemente, la deuda más peligrosa de las cinco, porque su ausencia no se nota hasta que un cliente o un empleado detecta un error que llevaba semanas produciéndose sin que nadie lo supiera.
Deuda de conocimiento
Muchos agentes de IA responden apoyándose en una base documental propia de la empresa (lo que técnicamente se conoce como RAG, recuperación de información antes de generar la respuesta). Esa base de conocimiento no se actualiza sola: si cambian los precios, las políticas o los procedimientos y nadie revisa los documentos que alimentan al agente, este sigue citando la información antigua con la misma seguridad y el mismo tono convincente que si fuera correcta, lo que la hace más difícil de detectar que un simple error humano.
Deuda de permisos
Con el tiempo, un agente de IA suele acumular accesos a más sistemas y más datos de los que necesitaba en su diseño original, cada vez que alguien añade "ya que estamos, que también pueda consultar esto otro". Nadie suele revisar después si esos permisos siguen siendo necesarios. El riesgo no es solo de seguridad: un agente con más acceso del necesario tiene más superficie donde un fallo de instrucciones o una respuesta mal calibrada puede causar un daño mayor del que el proceso original justificaba.
Cómo saber si ya la tienes acumulada
Algunas señales concretas: nadie en la empresa podría explicar de memoria por qué una instrucción concreta del agente existe; no hay ningún registro de cuándo se actualizó por última vez la base documental que usa el sistema; el comportamiento del agente ha cambiado en algún momento sin que nadie modificara nada a propósito; y no existe ninguna lista de qué sistemas y datos puede tocar cada agente en producción.
Cómo empezar a pagarla sin frenar el negocio
No hace falta resolver las cinco a la vez. Empieza por documentar y limpiar las instrucciones del agente que más se toca, elimina las reglas contradictorias y anota por qué se mantiene cada una. Crea un proceso mínimo, aunque sea manual, para revisar la base de conocimiento cada pocos meses. Define un conjunto pequeño de casos de prueba que compruebes cada vez que cambies algo relevante, aunque no sea un sistema de evaluación sofisticado. Y haz una auditoría puntual de qué accesos tiene cada agente, recortando lo que ya no se usa.
Conclusión
La deuda técnica de un sistema de IA basado en modelos de lenguaje tiene formas propias que no existen en la automatización tradicional: instrucciones que crecen sin control, dependencia de un modelo concreto, ausencia de evaluación, conocimiento desactualizado y permisos que nadie recorta. Ignorarla no la elimina, solo la vuelve más cara de corregir cuando por fin se nota. En MG Solutions auditamos estos cinco frentes en los sistemas de IA de nuestros clientes. Reserva una primera reunión si tienes agentes en producción que nadie ha revisado a fondo desde que se lanzaron.