Por qué producción cambia el problema

Una capacidad se convierte en una obligación de servicio

Durante la exploración se puede preparar una entrada, observar el resultado y corregir el experimento. En operación, esa secuencia convive con trabajo pendiente, plazos y personas que no están participando en una prueba.

La pregunta cambia de «¿puede hacerlo?» a «¿qué podemos esperar de él?». La respuesta necesita describir el uso admitido y las condiciones de servicio. Qué entradas se aceptan, cuánto puede tardar el resultado y qué tratamiento recibe un trabajo que no se puede completar.

No hace falta prometer perfección. Hace falta que las expectativas sean compatibles con lo que el sistema puede sostener. Si una herramienta solo está atendida durante una franja horaria, su operación debe reflejarlo. Si requiere revisión antes de utilizar una salida, esa revisión forma parte del servicio.

La ingeniería de fiabilidad distingue entre indicadores de servicio y objetivos sobre esos indicadores. El libro de SRE de Google utiliza esa separación para relacionar medidas observables con el comportamiento que se quiere ofrecer. La idea resulta útil sin adoptar la escala ni la organización de Google.

En un sistema de IA, la disponibilidad de la aplicación tampoco describe toda la experiencia. Puede responder y producir resultados que ya no sirven para el trabajo. El compromiso necesita considerar la utilidad de la salida y el funcionamiento de las etapas que permiten utilizarla.

Definir ese compromiso evita que cada usuario invente su propia interpretación de «funciona». También permite decidir qué problemas requieren una intervención inmediata y cuáles pueden esperar sin comprometer el uso previsto.

El entorno deja de estar bajo control

En producción, la aplicación comparte espacio con sistemas y personas que siguen cambiando. Una fuente tarda más en responder, una entrada llega incompleta o un equipo modifica su forma de registrar información. Esas variaciones pasan a formar parte del problema.

Las dependencias pueden fallar de manera visible, pero también pueden seguir disponibles mientras cambian su comportamiento. Una integración devuelve datos válidos con un significado diferente. Una búsqueda encuentra documentos, aunque ya no incluya los que necesita una nueva clase de consulta.

La carga tampoco es solo un volumen total. Importa cuándo llega el trabajo, cuánto tarda cada caso y qué recursos comparten las operaciones. Una prueba distribuida durante el día puede no representar lo que sucede cuando varias solicitudes coinciden antes de un plazo.

El diseño debe identificar qué dependencias condicionan el compromiso de servicio y qué margen existe cuando dejan de cumplirlo. Algunas demoras permiten esperar. Otras obligan a limitar la entrada de trabajo o a comunicar que el resultado no llegará en las condiciones previstas.

No se trata de anticipar todas las combinaciones posibles. Se trata de evitar que las condiciones necesarias para operar permanezcan ocultas en la experiencia de quien construyó el prototipo. Lo que era evidente para esa persona tiene que convertirse en información que otros puedan consultar y utilizar.

Un servicio manejable hace visibles sus dependencias críticas. Esa visibilidad permite interpretar los problemas y evita atribuir al modelo cualquier cambio que se perciba en la calidad o en el tiempo de respuesta.

La versión es más que el modelo

El comportamiento de una aplicación de IA depende de una configuración conjunta. El modelo participa, pero también lo hacen las instrucciones, las herramientas, las fuentes y las reglas que conectan sus salidas con el resto del trabajo.

Por eso, registrar únicamente el nombre del modelo deja una descripción incompleta de lo que se está operando. Dos ejecuciones pueden usar la misma versión de inferencia y comportarse de forma distinta porque ha cambiado un documento de referencia, una función de integración o una condición de aceptación.

Conviene poder identificar qué conjunto de componentes estaba activo cuando se produjo un resultado relevante. No para conservar todos los datos indefinidamente, sino para disponer de la trazabilidad necesaria para interpretar un cambio o investigar una incidencia.

El trabajo Hidden Technical Debt in Machine Learning Systems, publicado en 2015, analizó riesgos de mantenimiento relacionados con dependencias de datos, configuración y cambios del entorno. Su objeto eran sistemas de aprendizaje automático, no los agentes actuales. La observación que interesa aquí es que la unidad que debe mantenerse excede al modelo.

Esto afecta a la forma de introducir mejoras. Una modificación pequeña en apariencia puede alterar una relación importante. Cambiar una descripción de herramienta puede modificar su uso; actualizar una fuente puede cambiar qué respuestas se consideran correctas.

La respuesta no debería ser congelar el sistema. Debería ser mantener una relación entre cambios, comprobaciones y decisiones de puesta en servicio. Una versión útil para operar es la que permite entender qué se ha cambiado y por qué se considera aceptable utilizarlo.

Continuar tiene más de una forma

Cuando una parte del sistema falla, no siempre conviene intentar mantener el mismo comportamiento a cualquier precio. La continuidad puede consistir en ofrecer un servicio más limitado, conservar trabajo pendiente o detener una función hasta recuperar las condiciones necesarias.

Esa elección debe responder al uso. Una aplicación puede seguir preparando borradores mientras una fuente auxiliar está temporalmente fuera de servicio, si hace visible la limitación y el resultado sigue siendo útil. Otra debe detenerse porque esa fuente determina una condición imprescindible para actuar.

Degradar el servicio no debería significar sustituir silenciosamente información comprobada por una respuesta plausible. La reducción de capacidad necesita ser reconocible para quien utiliza el resultado y coherente con los compromisos que siguen vigentes.

La alternativa manual también requiere diseño. Si se propone como vía de continuidad, hay que saber quién la realiza, qué información recibe y qué volumen puede asumir. Llamar «manual» a una salida no crea la capacidad operativa para atenderla.

Recuperar la normalidad plantea otra decisión. El trabajo acumulado puede contener solicitudes que ya no tienen sentido, decisiones caducadas o acciones que se realizaron por otra vía. Reanudar todo sin revisar esas condiciones puede introducir problemas nuevos.

También hay que distinguir volver a una versión anterior de deshacer sus efectos. Restaurar una configuración no elimina automáticamente los cambios que esa versión produjo fuera de la aplicación. La recuperación del servicio y la corrección del trabajo afectado pueden requerir acciones diferentes.

La continuidad se diseña mejor cuando se define qué se preserva en cada situación: la información, la capacidad de revisar, el orden del trabajo o un resultado mínimo. Esa definición permite reducir el servicio sin perder el control sobre lo que sigue ocurriendo.

Operar consume capacidad de la organización

El coste de un sistema no termina en la infraestructura ni en las llamadas al modelo. También incluye el tiempo necesario para atender incidencias, revisar resultados, mantener fuentes y adaptar integraciones cuando cambia el trabajo.

Estas actividades no son necesariamente señales de una mala solución. Algunas forman parte de cualquier servicio útil. La cuestión es si están previstas, si existe capacidad para realizarlas y si el valor obtenido justifica esa dedicación.

Una automatización puede reducir trabajo repetitivo y crear una nueva necesidad de supervisión. Para entender su aportación hay que observar ambas cosas. Si el seguimiento depende siempre de la persona que desarrolló el sistema, puede existir una dependencia operativa que la entrega inicial no hizo visible.

La propiedad del servicio debería ser reconocible. Alguien decide sobre el alcance, alguien atiende su funcionamiento y alguien puede autorizar cambios. En un equipo pequeño, varias responsabilidades pueden recaer en la misma persona; lo importante es que no desaparezcan por falta de una estructura formal.

La documentación debe servir a esas funciones. Una descripción extensa de componentes puede resultar menos útil que saber cómo reconocer una interrupción, dónde consultar el estado y quién toma la siguiente decisión. La información técnica sigue siendo necesaria, pero debe conectarse con la acción que permite realizar.

También conviene que el coste de operación pueda revisarse. El uso puede crecer, cambiar de perfil o requerir más intervención de la prevista. Mantener la solución exige volver a examinar si su alcance y sus compromisos siguen siendo adecuados, en lugar de tratar el diseño inicial como una decisión permanente.

El rigor debe ser proporcional a la dependencia

Pensar en producción no obliga a construir una infraestructura compleja para cualquier aplicación. Una ayuda interna de bajo impacto puede operar con controles sencillos si sus límites son claros y las personas pueden trabajar cuando no está disponible.

El criterio no debería ser copiar la arquitectura de un servicio mucho mayor. Debería ser relacionar el esfuerzo de ingeniería con las consecuencias de una interrupción, la dificultad de recuperar el trabajo y la dependencia que se está creando.

Esa proporcionalidad afecta tanto a los controles como a las promesas. No tiene sentido ofrecer continuidad permanente si la organización no puede atenderla. Tampoco conviene imponer un procedimiento de cambio tan pesado que una herramienta modesta deje de poder mantenerse.

El alcance puede ampliarse de forma gradual. Una primera operación limitada permite comprobar necesidades reales y ajustar el servicio antes de que otras actividades dependan de él. Pero el carácter limitado debe ser visible; utilizarlo como un servicio general mientras se lo denomina «piloto» no reduce sus consecuencias.

La salida de producción también forma parte del ciclo de vida. Una solución puede dejar de aportar valor, ser sustituida o necesitar una pausa. Retirarla requiere conocer qué trabajo depende de ella, qué información debe conservarse y cómo se trasladará la actividad.

Producción introduce así una responsabilidad sobre la evolución completa del sistema. La ingeniería no termina cuando una capacidad se vuelve accesible. Continúa mientras esa capacidad sostiene trabajo que la organización necesita realizar.