Ingeniería para la fiabilidad
Cómo construir sistemas fiables a partir de componentes no fiables – y por qué esto no es tan nuevo como parece.
La incomodidad
Cada desarrollador conoce este contrato:
Misma entrada → misma lógica → mismo resultado. Siempre.
La IA rompe este contrato. El mismo prompt, el mismo modelo, la misma entrada pueden producir resultados diferentes en ejecuciones consecutivas. Para los ingenieros formados en sistemas deterministas, esto parece fundamentalmente defectuoso.
La resistencia no es puramente intelectual. Es emocional. Los ingenieros construyen su identidad en torno a la calidad de su trabajo, en torno al control sobre el comportamiento del sistema. Cuando un componente produce resultados inconsistentes, no solo desafía una suposición técnica. Desafía el sentido de dominio que hace que el trabajo sea significativo. Reconocer esto es el primer paso para superarlo.
No está roto. Es un tipo diferente de sistema. Y requiere un tipo diferente de ingeniería de fiabilidad.
Ya lo haces
La incomodidad es real, pero el problema no es nuevo. Los desarrolladores ya trabajan con componentes no fiables a diario:
- Las redes fallan. Reintenta. Añade tiempos de espera. Diseña para el fallo parcial.
- Las APIs de terceros cambian. Versiona. Escribe pruebas de contrato. Añade alternativas.
- Existen condiciones de carrera. Usas bloqueos, colas e idempotencia.
- Los usuarios proporcionan entradas basura. Validas, saneas y rechazas.
Ninguno de estos sistemas es determinista a nivel de componente. Son fiables a nivel de sistema – porque diseñaste la fiabilidad en torno a partes no fiables.
La IA es el mismo patrón. El modelo es un componente no fiable. Tu trabajo es construir un sistema fiable a su alrededor.
El reencuadre
El software tradicional pregunta: ¿Funciona?
Los sistemas de IA preguntan: ¿Con qué frecuencia funciona?
Este no es un estándar más bajo. Es uno más honesto. El software tradicional también falla – simplemente falla de maneras que hemos aprendido a ocultar (manejo de errores, reintentos, degradación elegante). La IA hace visible la no fiabilidad en lugar de enterrarla.
La fiabilidad no es "siempre da la misma respuesta". La fiabilidad es "el sistema funciona consistentemente dentro de límites aceptables". Los límites son tuyos para definir.
La caja de herramientas
El cambio de sistemas deterministas a probabilísticos requiere prácticas de ingeniería específicas. Ninguna es exótica – es la misma disciplina que ya aplicas a los sistemas distribuidos, aplicada a un nuevo tipo de componente.
La evaluación reemplaza las pruebas unitarias
En el software tradicional, las pruebas verifican resultados exactos. En los sistemas de IA, evalúas distribuciones.
Cada sistema de IA debe tener:
- Un conjunto de datos de evaluación que represente el comportamiento esperado
- Ejecuciones de evaluación automatizadas en cada cambio
- Verificaciones de regresión que detecten degradación
Esto cumple el mismo rol que un conjunto de pruebas. Sin él, los sistemas de IA se degradan silenciosamente – no porque el código haya cambiado, sino porque el modelo lo hizo.
Los guardarraíles reemplazan la confianza
El resultado de un LLM casi nunca debe confiarse directamente. El modelo proporciona razonamiento. El sistema proporciona fiabilidad.
Los sistemas de producción deben incluir capas de validación:
- Salidas estructuradas o esquemas que apliquen el formato
- Reglas de negocio deterministas que anulen el juicio del modelo donde sea apropiado
- Validación de salida que detecte alucinaciones e infracciones de restricciones
- Bucles de reintento y reparación para fallos recuperables
- Revisión humana donde el costo del error es alto
Los guardarraíles no son una admisión de que la IA es mala. Son la ingeniería que hace que la IA sea útil.
Los pasos más pequeños reemplazan los prompts grandes
Los prompts grandes que intentan resolver todo son frágiles. Combinan demasiados modos de fallo en una sola llamada.
Los sistemas de IA fiables descomponen las tareas:
- Clasificar la entrada
- Recuperar contexto relevante
- Generar la salida
- Validar estructura y calidad
- Reparar si es necesario
Cada paso puede evaluarse, monitorizarse y mejorarse de forma independiente. Las unidades de razonamiento más pequeñas aumentan la fiabilidad por la misma razón que las funciones pequeñas son más fiables que las monolíticas.
La observabilidad reemplaza los supuestos
Los sistemas de IA en producción deben exponer:
- Registros de prompts – qué entró
- Respuestas del modelo – qué salió
- Puntuaciones de evaluación – qué tan bueno fue
- Casos de fallo – qué salió mal
- Métricas de costo y latencia – qué cuesta
No puedes mejorar lo que no puedes ver. Y los sistemas de IA fallan de maneras invisibles sin instrumentación – la salida parece plausible pero es incorrecta.
El versionado reemplaza la estabilidad
Los modelos de IA evolucionan continuamente. Una actualización de modelo puede cambiar el comportamiento de maneras que ningún cambio de código explicaría.
Las prácticas de ingeniería deben incluir:
- Versionado de modelos – fija la versión del modelo en producción. Actualiza deliberadamente.
- Versionado de prompts – trata los prompts como código. Rastrea los cambios. Revisa las diferencias.
- Evaluación al actualizar – ejecuta tu conjunto de evaluación antes y después de cada cambio de modelo, del mismo modo que ejecutas pruebas antes de desplegar una nueva dependencia.
- Iteración rápida – cuando algo se rompe, itera rápido. La corrección suele estar en el prompt, los guardarraíles o la evaluación – no en el modelo.
Trata los cambios de modelo como actualizaciones de dependencias. Ya sabes cómo gestionarlas.
El cambio de rol
En este modelo, los ingenieros no están principalmente escribiendo lógica. Están diseñando sistemas que supervisan la inteligencia. Esto es, estructuralmente, gestión: especificar la intención a un ejecutor imperfecto, evaluar el resultado en lugar de controlar el proceso, e iterar sobre tu propia comunicación cuando el resultado no coincide con la intención. Los gestores siempre han operado en un mundo probabilístico. Los ingenieros se están uniendo a ellos.
- •Escribir lógica de negocio
- •Implementar algoritmos conocidos
- •Depurar línea por línea
- •Optimizar rutas de ejecución
- •Diseñar prompts e interfaces de herramientas
- •Construir capas de validación y evaluación
- •Diseñar bucles de reintento y corrección
- •Monitorizar el rendimiento a nivel de sistema
Esto no es una degradación. Es un cambio a un nivel más alto de abstracción, el mismo cambio que ocurrió cuando los ingenieros pasaron de assembly a lenguajes de alto nivel, o de bare metal a infraestructura cloud. Cada transición parecía una pérdida de control. Cada una fue en realidad una ganancia de apalancamiento.
El principio central
No programamos la inteligencia. Diseñamos entornos donde la inteligencia funciona de manera fiable.
La no fiabilidad no es el problema. Es la naturaleza del componente. La ingeniería es lo que convierte un componente no fiable en un sistema fiable.
Esto no es nuevo. Es lo que los ingenieros siempre han hecho.
← Volver al inicio · El Laboratorio de IA · Estándares de ejecución con IA · El Marco de Referencia