Antes de comprometerte con una funcionalidad de IA, responde esto: ¿quién la mantiene en el mes 18?

La pregunta que tu equipo formula cuando evalúa la integración de IA es habitualmente una de estas: ¿Es esta IA lo suficientemente buena para hacer la tarea? ¿Cuánto costará construirla? ¿La encontrarán útil nuestros usuarios?

Son preguntas razonables. También son la segunda, tercera y cuarta pregunta. La primera pregunta, la que casi nadie hace antes de comprometerse, es esta: ¿Quién mantiene esta funcionalidad en el mes 18, y tenemos el presupuesto y la experiencia para darle lo que necesita?

Si no tienes una respuesta clara, no tienes un plan para añadir IA. Tienes un plan para asumir una nueva categoría de deuda técnica.

Por qué las funcionalidades de IA tienen una estructura de costes diferente

El software tradicional tiene una propiedad que hace que el mantenimiento a largo plazo sea relativamente predecible: el determinismo. Dados los mismos inputs, el mismo código produce los mismos outputs. Los errores son reproducibles. Una vez corregidos, permanecen corregidos. El coste de operar software tradicional tras la entrega es principalmente infraestructura y trabajo para nuevas funcionalidades y correcciones de errores. Estos costes están bien entendidos y cuentan con décadas de heurísticas de estimación.

Las funcionalidades basadas en IA rompen esta predictibilidad de cuatro formas específicas.

Mantenimiento de prompts

El comportamiento de los modelos de lenguaje es sensible a la redacción exacta de los prompts. Esta sensibilidad no es estática, cambia a medida que los modelos se actualizan. Un prompt que produce resultados de alta calidad consistentes hoy puede producir resultados notablemente diferentes tras la próxima actualización del modelo, incluso usando el mismo nombre de modelo. El proveedor considera esto normal. Tus usuarios lo consideran tu problema. Esto significa que las funcionalidades de IA requieren monitorización activa de la calidad de los resultados y revisión periódica de los prompts en respuesta a los cambios del modelo.

Ciclos de deprecación de modelos

Los proveedores de modelos de IA deprecan modelos en ciclos definidos. Cuando tu funcionalidad depende de un modelo deprecado, te enfrentas a una migración forzada: probar el nuevo modelo, revisar los prompts, validar la calidad de los resultados, redesplegar. Este no es un coste hipotético futuro, es uno programado, predecible desde el momento en que te comprometes con una funcionalidad dependiente de IA.

Monitorización del comportamiento

El software tradicional funciona o no funciona. Cuando no funciona, generalmente falla de forma visible. Las funcionalidades basadas en IA fallan de forma diferente: resultados sutilmente incorrectos, inconsistentemente incorrectos, o incorrectos de formas que los usuarios no notan ni reportan inmediatamente. No puedes confiar en los errores reportados por los usuarios para mantener la calidad. Necesitas monitorización proactiva de los resultados, alguien o algo que evalúe regularmente una muestra de los resultados de IA frente a un estándar definido.

Volatilidad de costes por escala de uso

Los costes de las API de IA son típicamente por token: cada input y output se mide. Un aumento de 10 veces en el número de interacciones de IA produce algo cercano a un aumento de 10 veces en los costes de infraestructura de IA. Esto crea una volatilidad presupuestaria para la que los presupuestos de software tradicional no preparan a los equipos.

Cuándo no aplica esto

Este argumento no es un caso contra el uso de IA. Es un caso contra comprometerse con funcionalidades de IA sin tener en cuenta sus requisitos específicos de mantenimiento. Se aplica con menos fuerza a: flujos de trabajo únicos o por lotes donde un humano revisa cada resultado antes de actuar (si la IA produce borradores para edición humana, la desviación de los prompts la detecta el editor); herramientas internas donde la variabilidad del comportamiento es aceptable; y usos experimentales con tiempo limitado con criterios de evaluación definidos y un punto de decisión integrado.

La mejor primera pregunta

Antes de evaluar si la IA es lo suficientemente capaz para hacer la tarea, responde esto con especificidad: Tras el lanzamiento de esta funcionalidad, ¿quién comprueba que funciona correctamente el mes que viene? ¿Y el siguiente? ¿Y cuando el proveedor del modelo lance una actualización que cambie su comportamiento?

Si la respuesta honesta es «ya nos ocuparemos de eso»: el coste de la funcionalidad en tu propuesta falta el elemento de mayor importe. Si la respuesta honesta es «nadie, porque asumimos que simplemente funcionará»: la funcionalidad probablemente funcionará bien los primeros meses, el período en que tu equipo aún presta atención y el modelo no ha sido actualizado. El mes 18 es una conversación diferente.

La pregunta no es si usar IA. La pregunta es si estás preparado para mantener una funcionalidad basada en IA al estándar de producción durante todo el período que pretendes usarla. La mayoría de las decisiones de añadir IA se toman sobre el primer compromiso ignorando silenciosamente el segundo.

Nombra al mantenedor antes de nombrar el modelo. Si no puedes nombrar al mantenedor, tienes más planificación por hacer.