- ai-implementation
- ai-maintenance
- ai-cost
- production-ai
- software-ownership
Análisis completo
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.
¿Qué es la «pregunta del mes 18» para las funcionalidades de IA?
Antes de comprometerse a construir una funcionalidad basada en IA, pregunta: ¿quién mantiene esta funcionalidad en el mes 18, y tiene la organización el presupuesto y la experiencia para apoyarle? Esta pregunta existe porque las funcionalidades de IA tienen requisitos de mantenimiento continuos — revisiones de prompts cuando el comportamiento del modelo cambia, migraciones forzadas cuando los modelos se deprecan, monitorización proactiva de la calidad — que el software tradicional no tiene. La mayoría de los equipos evalúan las funcionalidades de IA en base a capacidad y coste de construcción, tratando el mantenimiento como algo secundario. La pregunta del mes 18 revela el compromiso que realmente se está asumiendo.
¿Por qué las funcionalidades de IA requieren mantenimiento continuo cuando el software tradicional no lo requiere?
El software tradicional es determinista: los mismos inputs siempre producen los mismos outputs. Las funcionalidades basadas en IA no lo son. El comportamiento de los modelos de lenguaje es sensible a la redacción de los prompts y cambia a medida que los modelos se actualizan — por lo que los prompts que funcionaban hoy pueden producir resultados diferentes tras una actualización del modelo, incluso cuando el nombre del modelo sigue siendo el mismo. Los modelos también se deprecan en ciclos definidos, requiriendo migraciones forzadas. Y los fallos de IA son a menudo sutiles en lugar de visibles, requiriendo monitorización proactiva de la calidad que el software tradicional no necesita.
¿Hay casos de uso de IA donde la carga de mantenimiento es menor?
Sí. La carga de mantenimiento es menor para: flujos de trabajo únicos o por lotes donde un humano revisa cada resultado antes de actuar (la desviación de los prompts la detecta el editor, no un sistema de monitorización); herramientas internas donde la variabilidad del comportamiento es aceptable (una búsqueda con IA que ocasionalmente muestra resultados menos relevantes es molesta, no un riesgo de producción); y usos experimentales con tiempo limitado con criterios de evaluación definidos y un punto de decisión para continuar o detener. El argumento de mantenimiento se aplica con más fuerza a las funcionalidades de IA persistentes y de cara al cliente que se ejecutan en producción sin revisión humana de los resultados individuales.