Qué es la deuda técnica de un proyecto de IA

El problema no es la IA, es lo que se dejó a medias

La mayoría de los equipos que meten IA en un proceso de negocio no arrancan con un plan de arquitectura, arrancan con una fecha límite. Hay una campaña que lanzar, un competidor que ya lo hizo, un cliente que lo pidió en la última reunión. La presión casi nunca es técnica, es comercial, y la respuesta suele ser la misma: se conecta lo que haya que conectar, se escribe el prompt que funcione hoy y se sale a producción antes de que alguien pregunte por la arquitectura.

Un fabricante de empaques en México, con menos de ciento cincuenta empleados, automatizó la clasificación de fotos de control de calidad en menos de un mes, usando un modelo de visión conectado por API y un puñado de reglas escritas por el jefe de planta que impulsó el proyecto. Funcionó bien mientras la línea de producción no cambió. Cuando se agregó una línea de producto nueva, nadie en la empresa sabía qué reglas tocar ni por qué estaban escritas así, porque solo existían en la cabeza de una persona que ya no estaba a cargo del proyecto.

Ese patrón se repite en logística, en retail, en servicios financieros: se gana velocidad al principio y se pierde después, pero casi nunca se nombra el fenómeno. Se le llama “mala suerte”, “el proveedor que no entregó bien” o “falta de gente”, cuando en realidad es un costo acumulado que nadie registró el día que se generó.

Qué es la deuda técnica de un proyecto de IA

Antes de seguir, conviene ponerle nombre exacto a lo que describen los ejemplos anteriores, porque en la mayoría de las empresas este concepto no existe en el vocabulario de negocio, solo en el de ingeniería, y eso ya es parte del problema: si el directorio no tiene la palabra, no puede pedir que se gestione.

La comparación con una deuda financiera es literal, no una metáfora bonita. Cuando una empresa toma un préstamo para crecer más rápido de lo que le permitiría su caja, sabe que va a pagar una tasa a cambio de tiempo. La deuda técnica de un proyecto de IA funciona igual: se toma tiempo prestado del futuro para entregar algo hoy, y ese préstamo se cobra en horas de trabajo cada vez que hay que tocar el sistema. La diferencia es que la deuda financiera aparece en un estado de cuenta con un número, y la deuda técnica de IA casi nunca aparece en ningún documento. Vive en la cabeza de quien armó el flujo, en un prompt guardado en un chat, en una hoja de cálculo que alguien corrigió a mano una vez.

Tomar deuda a propósito no es un error

Lo primero que hay que sacarse de la cabeza es que tomar deuda técnica sea, en sí mismo, un error. No lo es. Toda empresa que saca un piloto de IA en semanas en lugar de meses está tomando deuda a propósito, y eso puede ser la decisión correcta: llegar antes al mercado, validar una hipótesis con datos reales antes de invertir en una arquitectura sólida, o responder a una ventana comercial que no vuelve a abrirse. El problema nunca es la deuda en sí. El problema es tomarla sin registrarla y sin plan de pago.

Una aseguradora mediana en Perú decidió lanzar un asistente para cotizar pólizas simples con IA generativa antes de terminar de definir su arquitectura de datos, porque el área comercial necesitaba mostrar algo en una feria del sector. La decisión fue correcta: la feria trajo clientes nuevos. El error no fue tomar el atajo, fue que nadie escribió en ningún lado qué se estaba dejando pendiente, así que seis meses después el equipo de datos tuvo que reconstruir desde cero qué reglas de negocio estaban metidas dentro del prompt, porque ninguna quedó documentada fuera de él.

Nombrar la deuda en el momento en que se toma cambia la conversación por completo. Deja de ser un descubrimiento doloroso seis meses después y pasa a ser una línea en un registro que alguien revisó y aceptó a propósito, con una fecha estimada para pagarla.

Las formas de deuda que casi nadie cuenta como tal

La deuda técnica de software tradicional ya tiene años de vocabulario: código duplicado, pruebas que faltan, dependencias sin actualizar. La deuda técnica de un proyecto de IA tiene formas propias que casi ningún equipo de negocio identifica como deuda, porque no se ven como “código”, se ven como decisiones operativas normales. Estas son las que más intereses generan sin que nadie las anote:

• Prompts sueltos que nadie versiona: viven en un chat, en un documento personal o en la memoria de quien los escribió, y cambian sin que quede registro de qué versión estaba en producción cuando algo salió mal.
• Automatizaciones que solo entiende quien las hizo: el flujo conecta varios sistemas con una lógica que nunca se explicó por escrito, así que la empresa depende de que esa persona siga contestando el teléfono.
• Datos que se arreglaron a mano una sola vez: alguien corrigió un archivo, una tabla o una respuesta del modelo para que la demo saliera bien, y ese arreglo puntual nunca se convirtió en una regla que se aplique de forma consistente.
• Cero evaluación automática de calidad: nadie mide con regularidad si las respuestas del modelo siguen siendo correctas, así que el deterioro se detecta por una queja de cliente, no por una alerta interna.
• Dependencia de una cuenta personal: la integración corre sobre la cuenta de un proveedor de IA que quedó a nombre de una sola persona, con su clave o su método de pago, y no de la empresa.

Cómo se ve el interés de esta deuda

El interés de la deuda técnica de IA casi nunca se ve como una factura. Se ve como tiempo, y el síntoma más claro es que cada cambio chico tarda más que el anterior. Una modificación que en el primer mes tomaba una tarde, al sexto mes toma una semana, y casi nadie relaciona ese enlentecimiento con las decisiones que se tomaron al principio, porque parece un problema de capacidad del equipo, no de deuda acumulada.

Estas son señales concretas de que ya se está pagando interés, aunque todavía nadie lo llame así:

• Cada cambio de reglas de negocio obliga a reescribir el prompt completo, no solo la parte que cambió, porque nadie separó la lógica del texto.
• El equipo evita tocar el flujo salvo que sea estrictamente necesario, porque nadie está seguro de qué más se rompe al modificarlo.
• Las incidencias se resuelven preguntándole a una persona específica, no revisando una documentación que no existe.
• El costo de operar el sistema sube mes a mes sin que el volumen de uso haya crecido en la misma proporción.
• Cada vez que esa persona clave sale de vacaciones o deja la empresa, el sistema entra en pausa hasta que vuelve o alguien más logra entenderlo desde cero.

Cómo registrar y pagar la deuda

La regla práctica es simple de enunciar y difícil de instalar como hábito: la deuda técnica se escribe en el momento en que se toma, no cuando ya duele. No hace falta una herramienta sofisticada, alcanza con un registro simple donde quede qué se dejó a medias, por qué se decidió así y qué pasaría si no se paga en un plazo razonable. Ese registro convierte una decisión invisible en una decisión de negocio que el directorio puede priorizar junto con cualquier otra inversión.

Pagar la deuda no significa parar todo para reescribir el sistema. Significa tratarla como cualquier otro pasivo: revisarla con una frecuencia fija, priorizar el pago de la parte que más intereses está generando (normalmente la que depende de una sola persona o de una cuenta personal) y decidir con datos, no con culpa, cuánto presupuesto se destina a pagarla frente a construir funciones nuevas. Quien quiera profundizar en cómo sostener esa disciplina en el tiempo puede revisar la guía de cómo mantener y actualizar un sistema de IA en producción, y quien todavía tiene automatizaciones sueltas sin integrar puede revisar la guía de cómo migrar automatizaciones sueltas a un sistema.

El registro de deuda también es el lugar correcto para anotar decisiones relacionadas, como cuándo se revisó por última vez si el modelo sigue rindiendo igual que el día que se lanzó, un fenómeno que tiene su propia entrada en este glosario bajo el nombre de deriva de modelo, y como cuánto está costando de verdad sostener el sistema en el tiempo, tal como lo explica la entrada de LLMOps y modelo de IA en producción.

Mi criterio

Cuándo hay que actuar y cuándo se puede esperar

No toda deuda técnica de IA exige acción inmediata, y tratar cada atajo como una emergencia agota al equipo tanto como ignorarla por completo. La pregunta útil no es si existe deuda, porque siempre existe, sino si ya está cobrando más de lo que la empresa puede permitirse pagar cada mes.

Señales de que la deuda ya está cobrando caro

• Ningún cambio de negocio se puede estimar en días, todos terminan tomando semanas sin explicación clara.
• Solo una o dos personas en la empresa pueden tocar el sistema sin romper algo.
• El sistema corre sobre credenciales o cuentas a nombre de una persona y no de la empresa.
• Nadie puede explicar por qué el modelo responde distinto hoy que hace unos meses.
• Cada incidente se resuelve improvisando, porque no existe ningún registro de cómo se resolvió la vez anterior.

Señales de que la deuda sigue bajo control

• Existe un registro, aunque sea simple, de qué atajos se tomaron y por qué.
• Más de una persona en el equipo puede explicar cómo funciona el flujo completo, no solo una.
• Las cuentas y credenciales del proveedor están a nombre de la empresa, no de un individuo.
• Hay alguna forma, aunque sea manual, de revisar con regularidad si las respuestas del modelo siguen siendo correctas.
• Cuando se agrega una funcionalidad nueva, el tiempo que toma es parecido al que tomó la anterior, no mayor.

El orden que evita que la deuda se acumule

El orden que sostengo para cualquier proyecto de IA es dolor, proceso, dato y recién al final herramienta. La deuda técnica aparece precisamente cuando ese orden se salta: se instala la herramienta antes de ordenar el dato, se ordena el dato antes de fijar el proceso, y el proceso se improvisa porque nadie terminó de nombrar el dolor real que se quería resolver. Cada paso que se salta no desaparece, se convierte en deuda que alguien va a tener que pagar más adelante, con intereses más altos que si se hubiera resuelto en su momento.

La empresa que gestiona bien su deuda técnica de IA no es la que nunca la tiene, es la que la ve venir, la anota y decide con datos cuándo pagarla. La que la ignora no evita el costo, solo lo pospone hasta que aparece en el peor momento posible: cuando hay que escalar, cuando la persona clave se va, o cuando un cliente nota que algo dejó de funcionar bien.