La filosofía Hamilton aplicada a sistemas con IA
Margaret Hamilton diseñó el software del Apollo 11 asumiendo que todo iba a fallar. Esa premisa, aplicada a sistemas con inteligencia artificial, cambia toda la arquitectura.
El software del Apollo 11, el que llevó a tres humanos a la Luna y los trajo de vuelta, lo diseñó Margaret Hamilton bajo una premisa que sigue siendo el patrón oro de los sistemas críticos, asumir que algo va a fallar y diseñar el sistema para que la falla no destruya la operación.
Esa premisa, aplicada a sistemas con inteligencia artificial, cambia toda la arquitectura. Y casi nadie la está aplicando.
El problema con la IA contemporánea
Los modelos de lenguaje fallan de formas raras. Alucinaciones, contradicciones internas, sensibilidad a la forma del prompt, sesgos heredados, datos desactualizados, errores que el modelo mismo no detecta como errores. Y cada modelo tiene su propio patrón de fallas.
Lo razonable, sabiendo eso, sería diseñar sistemas que asuman estos fallos y los manejen. Lo que se hace en cambio es desplegar un envoltorio sobre un solo modelo, mandar la respuesta directo al usuario, y esperar que no se equivoque. Cuando se equivoca, la responsabilidad es del usuario.
Cinco capas Hamilton
En cualquier sistema que construimos sobre IRIS, hay cinco capas que se activan en orden ante una falla:
- Detección automática. El sistema reconoce que algo está mal antes de devolver una respuesta.
- Auto-sanación. El sistema intenta resolver el error solo, reintentando, cambiando de modelo, ajustando el prompt.
- Escalación técnica. Si la auto-sanación falla, escala a Claude Code o al flujo técnico para diagnóstico automático.
- Alerta crítica. Si la escalación técnica no resuelve, alerta por WhatsApp o email a quien tiene que estar al tanto.
- Intervención humana. Solo si las cuatro capas anteriores fallaron, llega a Carlos. La intervención humana es el último recurso, no el primero.
Por qué importa para el cliente
Un sistema con cinco capas Hamilton tiene una propiedad rara, no falla silenciosamente. Cuando algo se rompe, lo sabés. Cuando algo se arregla solo, también te enterás. Y cuando llegás vos al teclado a resolver, llegás con todo el contexto de lo que las capas anteriores intentaron.
Eso significa que el sistema no es solo "más estable". Es auditable. Cada respuesta que da el sistema viene con su rastro, qué modelos consultó, qué verificaciones pasó, qué auto-correcciones aplicó. Para una empresa que paga consecuencias por las decisiones que toma con apoyo del sistema, eso es lo único que justifica confiar.
No diseñamos para que no falle. Diseñamos para que la falla no destruya la operación. Esa diferencia es Hamilton.