La regresión en IA es un problema de software

10 min de lectura

Al flujo de trabajo no le importan los mitos sobre la IA

Lo más curioso de muchas regresiones en IA no es el error en sí.

Es el vocabulario que surge alrededor del error.

Un agente que la semana pasada procesaba correos con facturas sin problemas empieza a actuar como un becario confundido con adicción a las capturas de pantalla, y profesionales con experiencia se ponen a debatir si el modelo está pasando por una fase emocional. Ese lenguaje se comprende. Pero también es un desastre silencioso. En el instante en que la conversación se vuelve mística, la cuestión de la responsabilidad real abandona la sala.

Un flujo con IA no se levantó de mal humor.

Algo cambió en un sistema.

El taller de IA no entrega software, porque el taller no es el sistema y el modelo no es el plano de control.

Un flujo con regresiones ya es un sistema de software

Esta es la trampa mental para muchos responsables de producto, directores de operaciones, fundadores y optimizadores de procesos. Describen el trabajo en términos de negocio: automatizar la gestión de facturas, reducir trabajo manual, conectar herramientas, ayudar a que el equipo avance más rápido, desplegar asistencia de IA. Todo es razonable.

Hasta que el flujo se vuelve importante.

Entonces la bandeja de entrada importa. Los archivos adjuntos importan. Los formatos de archivo importan. La estructura del correo importa. Los permisos importan. Las APIs de terceros importan. La lógica de reintentos importa. La diferencia entre descargar un documento y tomar una captura de pantalla pasa a importar muchísimo: lo primero alimenta el siguiente paso en un proceso controlado; lo segundo es una máscara cómica que finge ser una canalización de documentos.

Eso es software.

No porque la empresa venda software.

Sino porque la empresa ahora depende del comportamiento del software para sostener un proceso de negocio.

Por eso mismo tantas iniciativas de IA aparentemente «no técnicas» acaban tropezando con dolores técnicos. La organización cree que compró ingenio. Lo que compró en realidad fue una nueva dependencia operativa con piezas móviles, casos extremos, supuestos de integración y modos de fallo.

Y esa dependencia debe dividirse correctamente.

Usa el LLM donde exista ambigüedad real: resumir, redactar, clasificar entradas desordenadas, proponer opciones, ayudar a un humano a valorar una situación difusa.

No uses el LLM como sistema de control para un paso que debe ejecutarse de forma predecible.

Si la tarea es «descargar el adjunto, guardar el archivo, conservar los metadatos y pasar el objeto correcto al siguiente paso», eso es software ordinario. Debe gestionarse con código y herramientas deterministas. Ceder esa responsabilidad a un modelo probabilístico no es innovación. Es una confusión de categorías.

«Script First» no es lo mismo que especificación

Los equipos suelen reaccionar a las regresiones igual que ante el primer borrador decepcionante de un asistente humano: dar más feedback, repetir las instrucciones, añadir otra restricción, ampliar la habilidad, afinar la redacción, recordarle al agente lo que debería haber hecho.

A veces eso ayuda. Bien. Úsalo.

Pero no confundas «mejoramos el prompt» con «recuperamos el control del flujo de trabajo».

El control nace de expectativas explícitas que sobreviven a la memoria, a la rotación de personal, a los cambios de proveedores y a la siguiente ronda entusiasta de optimizaciones. Si el comportamiento previsto es «descargar el adjunto, guardarlo en el lugar correcto, conservar los metadatos y entregar el archivo al siguiente paso», ese comportamiento necesita algo más que una instrucción bien redactada. Necesita comprobaciones.

¿Puede el sistema distinguir entre una descarga de adjunto y una captura de pantalla?

¿Puede detectar que se produjo el tipo de artefacto incorrecto?

¿Puede hacer visible el fallo antes de que el siguiente paso acepte basura en silencio?

¿Puede alguien reproducir la ejecución y ver dónde divergió el comportamiento?

¿Puede el flujo recurrir a una alternativa segura en lugar de continuar con disparates decorativos?

Si la respuesta a esas preguntas es no, la regresión no debería sorprender a nadie. Lo único sorprendente es que el flujo se comportara bien durante tanto tiempo.

Esta es la parte que los no desarrolladores siguen entendiendo mal.

Ven a un LLM hacer algo impresionante una vez y asumen que el modelo es un sustituto general del software. No lo es. Es un componente probabilístico que puede ser útil dentro de un sistema diseñado por personas que entienden dónde es aceptable la probabilidad y dónde no.

El software ordinario no quedó obsoleto porque un modelo sepa narrar sus propias conjeturas con total seguridad.

Agentic coding no es ‘hazme X’. Allí ocurre el mismo error: se confunde a un colaborador probabilístico útil con un motor de ejecución determinista y luego la gente se sorprende cuando el flujo se desvía.

Hablar de estados de ánimo suele ocultar un vacío de responsabilidad

Sí, los proveedores cambian modelos. Sí, las APIs se transforman. Sí, las dependencias externas a veces sufren regresiones. Nada de eso exime de responsabilidad a la organización que las contrata.

Si tu proceso de negocio depende del modelo de un proveedor, la deriva del proveedor forma parte del diseño de tu sistema. Fingir lo contrario es superstición de gestión.

La pregunta no es si el proveedor cambió algo. La pregunta es qué construyó tu organización alrededor de esa posibilidad.

¿Definió alguien el contrato operativo?

¿Decidió alguien qué no debe cambiar nunca en silencio?

¿Puso alguien monitorización sobre las salidas críticas?

¿Dejó alguien margen para reversiones, planes de contingencia, intervención manual o puertas de aprobación?

¿Reunió alguien en la misma sala la intención de producto, el conocimiento del proceso y el criterio de software?

Ese último punto pesa más de lo que la mayoría de los equipos quiere admitir. Muchas iniciativas de IA las lideran personas que ven el valor de negocio, las asesoran personas que hablan con soltura de herramientas y las implementa alguien en algún lugar del stack a quien se le pide que lo haga funcionar. Lo que falta es el perfil senior transversal capaz de traducir todo eso en un sistema duradero y no en una racha de ejecuciones con suerte.

Las rachas de suerte no son fiabilidad.

Son tiempo prestado.

La pregunta equivocada suena inteligente durante cinco minutos

La pregunta equivocada es:

«¿Empeoró el modelo?»

No es una pregunta inútil. Simplemente se queda muy corta.

Mantiene la atención sobre el componente más de moda del stack mientras ignora todo lo demás que debía salir bien para que el flujo funcionara de forma fiable.

Las preguntas mejores son más incómodas y, por tanto, mucho más útiles:

• ¿Qué resultado exacto se esperaba?
• ¿Dónde se definió esa expectativa?
• ¿Qué paso habría detectado el artefacto erróneo de inmediato?
• ¿Qué cambió en el sistema circundante?
• ¿Qué fallos son tolerables y cuáles constituyen incidentes de negocio?
• ¿Quién asume la corrección cuando la causa cruza los límites de prompts, herramientas, flujos e integración?

Son preguntas de software disfrazadas de preguntas sobre flujos de trabajo.

Ese es el punto central. Gran parte de la adopción moderna de IA es trabajo de software con traje de negocios. La vestimenta confunde a los compradores. El impacto del fallo no perdona.

Y una de las preguntas de software es brutalmente sencilla:

¿Debería este paso estar a cargo de un LLM?

Para pasos de control deterministas, la respuesta suele ser no.

Usa el modelo para interpretar. Usa software para ejecutar.

La estrategia de producto sigue necesitando disciplina de desarrollo

Hay una razón por la que este patrón aparece ahora en círculos de producto y no solo entre desarrolladores. Quienes lideran producto y operaciones están cada vez más cerca de los problemas reales del proceso. Detectan fricciones antes. Ven el desperdicio antes. Identifican una oportunidad valiosa de automatización antes de que se invite a un equipo técnico.

Esa es una buena noticia.

La mala noticia es que la cercanía al proceso puede generar una falsa sensación de seguridad. Como el dolor es visible, el sistema empieza a parecer fácil de entender. Como la IA produce demos impresionantes con rapidez, la implementación parece ligera. Como las personas implicadas son inteligentes y reflexivas, la disciplina ausente parece un detalle que se puede resolver más tarde.

Ese «más tarde» es donde se incuban las regresiones.

Un buen estratega de producto identifica dónde ayuda la automatización. Un buen desarrollador logra que el sistema sobreviva al contacto con la realidad. El mercado insiste en fingir que esos roles son separables en cuanto las herramientas de IA son lo bastante buenas.

Es una falacia.

Cuanto más crítico se vuelve el flujo, más necesita la empresa unir ambas perspectivas mediante alguien capaz de asumir la unión entre ambas.

En esa unión es donde la mayoría de los proyectos de IA fracasan en silencio. La gente de producto ve la fricción. Los desarrolladores ven los modos de fallo. Solo los no desarrolladores tienden a creer que el modelo elimina la necesidad del diseño de software convencional. No lo hace. Solo hace que ese error de comprensión resulte mucho más caro, mucho más rápido.

Lo que hacen los equipos serios

Dejan de preguntarse si el modelo es caprichoso y empiezan a diseñar para la deriva.

Definen las salidas críticas en términos concretos.

Añaden comprobaciones pequeñas e implacables alrededor de los pasos que importan.

Trasladan el comportamiento determinista fuera del modelo y hacia el software convencional siempre que es posible.

Registran suficiente información para reproducir fallos sin recurrir a leyendas urbanas.

Deciden qué comportamiento corresponde a los prompts y cuál a código o herramientas.

Tratan los cambios de proveedores como un riesgo operativo normal, no como una afrenta personal del universo.

Le dan a alguien la autoridad de decir: «No, este flujo aún no es lo bastante estable para confiarle dinero, clientes o cumplimiento normativo».

Y dejan de clasificar los problemas de entrega de IA bajo etiquetas motivacionales como adopción, capacitación o experimentación en cuanto el flujo ha entrado en la realidad operativa.

Ese cambio puede parecer incómodamente sobrio tras la euforia de las primeras pruebas exitosas.

Mejor así.

La sobriedad suele ser lo que separa una demo deslumbrante de un sistema que el departamento financiero puede asumir.