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
- Agente revisor: un agente evaluador separado revisa el resultado del agente primario (ver abajo)
- Revisión humana graduada por riesgo donde el coste del error es alto: ver puertas de validación graduadas por riesgo para la asignación HITL / HOTL / HOOTL
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.
El agente revisor es el predeterminado de producción
Para el trabajo no trivial, empareja al generador con un agente evaluador separado: contexto diferente, a veces un modelo diferente. El patrón es ahora el predeterminado de producción para la revisión de código (CodeRabbit, Graphite Diamond, Greptile, GitHub Copilot review) y está siendo adoptado en atención al cliente (revisión de tono + política), procesamiento de documentos y otros dominios de tareas discretas.
Por qué importa: los humanos que califican resultados rápidamente son evaluadores poco fiables del resultado incorrecto presentado con confianza. Los agentes revisores, ejecutados en contextos diferentes, afloran lo que los humanos cansados pasan por alto. La investigación PoLL ("Panel de jueces LLM") encuentra que los jurados de modelos más pequeños suelen superar a un solo juez grande (Verga et al., 2024), y a menor coste.
Estructura de coste: un agente revisor separado en cada artefacto aproximadamente duplica el gasto en inferencia por tarea. En el Peldaño 5, ahora se considera que vale la pena: la matemática del coste por unidad fusionada funciona porque la revisión humana a escala no funciona.
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.
Modos de fallo y recuperación en alta madurez
La caja de herramientas maneja los modos de fallo conocidos. En la madurez Tier 3 / Peldaño 5, tres preocupaciones adicionales se vuelven dominantes: dos nuevos modos de fallo (sicofancia, casos extremos subjetivos) y un patrón de respuesta (recalibración vs depuración) que distingue la práctica de alta madurez de la de baja madurez. Ninguno se detecta con pruebas o monitoreo; los ingenieros necesitan reconocerlos.
Sicofancia: una preocupación estructural
Los LLM defienden de manera fiable posiciones erróneas con confianza. Esto se mide en múltiples estudios (Sharma et al., 2023; Wen et al., 2024; OpenAI sobre alucinaciones, 2025). Wen et al. encontraron que el RLHF hace a los modelos mejores para convencer a los humanos de que tienen razón sin hacerlos mejores en tener razón (tasa de falsos positivos +24% en QA, +18% en programación).
La literatura está genuinamente en desacuerdo sobre si la sicofancia es una corrección de entrenamiento tratable o un artefacto estructural del RLHF.
La postura del marco: tratar la sicofancia como una preocupación estructural a efectos de ingeniería, independientemente de la trayectoria del entrenamiento.
Construye salvaguardas de proceso (señal externa, agente revisor, recuperación de verdad fundamental, pruebas ejecutables) en cada bucle. No confíes en la confianza del modelo como señal de corrección.
Si el entrenamiento lo mejora más adelante, las salvaguardas siguen siendo infraestructura útil. Si no, las salvaguardas son esenciales.
Casos extremos subjetivos
En baja madurez, los casos extremos son técnicos: las pruebas no los detectan, el monitoreo los muestra como anomalías, la corrección está en el código. En mayor madurez, el caso extremo dominante cambia: es subjetivo. Un usuario reporta que la IA hizo algo mal, pero las pruebas pasan, el monitoreo está en verde, y el fallo es cualitativo.
Ejemplos:
- Ingeniería: un PR es técnicamente correcto pero el agente tomó un camino de implementación equivocado; el usuario nota "esto no es lo que quería decir"
- Atención al cliente: un ticket resuelto por IA tiene hechos correctos pero el tono no encaja con el estado emocional del cliente
- Finanzas: una transacción está correctamente categorizada por la regla pero la regla en sí tergiversa la intención del negocio
- Contenido / marketing: el copy es gramatical y conforme a la spec pero pierde la voz de la marca
La recuperación es conversación, no parcheo. Habla con el usuario. Entiende qué estaba tratando de lograr realmente. Actualiza la spec o el contexto, no el código.
Este modo de fallo está bien documentado pero poco nombrado. Las fuentes de profesionales lo referencian bajo distinto vocabulario: el problema del 70% de Addy Osmani (el último 30% es trabajo humano), la investigación de UX de NN/g, el PAIR Guidebook. El marco lo nombra explícitamente porque la respuesta operacional difiere estructuralmente de la corrección de un error técnico.
Recalibración vs depuración
Cuando la IA está equivocada, hay dos respuestas posibles:
Corregir el artefacto (código, respuesta, documento) que produjo el agente. Trata el fallo como un problema de código.
Reconstruir la comprensión del agente mediante contexto fresco, spec re-articulada, lluvia de ideas multi-perspectiva. Trata el fallo como un problema de spec o de contexto.
Son operacionalmente distintas.
La literatura sobre la autocorrección intrínseca es unánime: un modelo que se ha comprometido con una dirección equivocada no se dará cuenta de manera fiable por sí solo; la reflexión en la misma ventana de contexto después de una respuesta incorrecta agrava el error en lugar de corregirlo (Huang et al., 2023; Kamoi et al., 2024). Cemri et al. (Why Do Multi-Agent LLM Systems Fail?, 2025) encontraron que el 41,8% de los fallos multiagente son problemas de especificación o diseño que necesitan re-especificación, no reintento.
Heurística práctica: si la misma spec produce el mismo resultado erróneo en dos ejecuciones frescas, depura la spec, no el artefacto. La mayoría de los fallos no triviales en alta madurez son problemas de recalibración disfrazados de problemas de depuración.
Ver Laboratorio de IA § Protocolo de estado bloqueado para el patrón operacional.
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.
Espejo: fiabilidad y madurez del código
Esta página aborda el resultado de la IA como entrada a los sistemas. La madurez del código aborda lo inverso: el código como entrada a los agentes de IA. La misma incertidumbre, reflejada. Los dos problemas comparten la misma solución de fondo: sensores rápidos, intención documentada, validación conductual de extremo a extremo.
← Volver al inicio · El Laboratorio de IA · Madurez del código · Estándares de ejecución con IA · El Marco de Referencia