IA en redes: por qué las 'alucinaciones' son suposiciones racionales (y cómo proteger tus operaciones)
Cuando un modelo de IA te da un comando de Huawei VRP incorrecto con total confianza, el instinto natural es pensar que “alucinó”. Que algo falló. Que el sistema se confundió de alguna manera inexplicable.
Ese marco conceptual es incorrecto. Y usarlo lleva a tomar decisiones equivocadas sobre cómo integrar IA en operaciones de red.
El problema con la palabra “alucinación”
“Alucinación” implica un estado patológico: el sistema percibe algo que no existe, como un síntoma de una falla. Cuando pensamos en errores de IA como alucinaciones, la respuesta natural es “hay que arreglarlo para que no alucine más”. Como si fuera un bug que, una vez corregido, desaparecería.
Pero los errores de los modelos de lenguaje no funcionan así. Son el resultado de una estrategia racional bajo las restricciones del entrenamiento.
Un modelo de lenguaje aprende a predecir qué texto viene a continuación de un texto dado. Durante el entrenamiento, adivinar correctamente tiene recompensa. Adivinar incorrectamente, en la mayoría de los esquemas de entrenamiento, no tiene un castigo equivalente. El modelo aprende, entonces, que la estrategia óptima es siempre intentar una respuesta. No decir “no sé”. No abstenerse. Intentar.
Una investigación reciente sobre el comportamiento interno de los modelos durante la generación de errores encontró que el modelo activa representaciones internas asociadas a baja confianza —o incluso a deceptividad— en el momento de producir afirmaciones incorrectas. En otras palabras: el modelo “sabe” en algún nivel que está haciendo una suposición de baja probabilidad. Pero igual la hace, porque su entrenamiento le enseñó que intentar es más rentable que abstenerse.
No es una alucinación. Es una suposición desvergonzada.
Por qué esto importa si operás una red
La distinción no es filosófica. Cambia directamente cómo deberías usar IA en un entorno de red productivo.
Si creés que es una alucinación aleatoria, podés pensar: “cuando el modelo suena seguro, probablemente es correcto; solo hay que tener cuidado cuando parece dudar”. Esta lógica es peligrosa. Los modelos suenan igual de seguros cuando saben la respuesta y cuando están inventando. La confianza del tono no es un indicador de corrección.
Si entendés que es una suposición estratégica, la conclusión es diferente: el modelo siempre intentará una respuesta plausible, independientemente de si tiene base para darla. No hay correlación confiable entre la confianza en el tono y la precisión del contenido. La verificación no es opcional —es estructural.
Dónde se manifiesta esto en operaciones de red
Comandos de CLI específicos de vendor
Este es el riesgo más directo. Un modelo de lenguaje tiene cobertura desigual de la documentación de cada vendor. Para comandos comunes de Cisco IOS o Junos, la precisión es razonablemente alta. Para configuraciones específicas de Huawei VRP, comandos de Nokia SR OS, o sintaxis de versiones antiguas de equipos, el modelo no declara ignorancia: produce un comando que parece correcto, en el formato correcto, con la sintaxis plausible.
El resultado es un comando que se ve profesional, pasa la inspección visual de alguien con menos experiencia, y puede hacer exactamente lo contrario de lo que se espera cuando se ejecuta en producción.
Implicación práctica: Nunca ejecutes un comando generado por IA en un equipo de producción sin verificarlo en la documentación oficial del vendor o en un entorno de lab. La plausibilidad sintáctica no equivale a corrección funcional.
Troubleshooting de incidentes
Los LLMs pueden ser muy útiles para estructurar un proceso de troubleshooting: qué verificar primero, qué descartar, cómo pensar el problema sistemáticamente. Pero cuando se les pregunta sobre causas específicas de un incidente con síntomas concretos, el modelo produce una hipótesis que encaja con los síntomas, no necesariamente una que tenga base estadística sólida.
Un modelo que ve “sesión BGP caída, log muestra hold timer expired” produce una respuesta razonable sobre posibles causas. Pero si en tu entorno hay una causa específica relacionada con un bug de versión de firmware que el modelo no conoce, la suposición plausible puede enviarte a investigar el camino incorrecto durante un incidente activo.
Implicación práctica: Usá IA para estructurar el proceso de troubleshooting, no para diagnosticar. La hipótesis generada es un punto de partida, no una conclusión.
Generación de código para automatización
Un script Python que usa Netmiko o NAPALM generado por IA puede parecer correcto, pasar una revisión superficial, y tener un bug sutil en el manejo de errores que solo aparece cuando el equipo remoto devuelve una respuesta inesperada. El modelo optimizó para producir código que se ve como código correcto, no para producir código que maneja correctamente todos los casos borde de tu entorno específico.
Implicación práctica: El código generado por IA requiere revisión técnica real, no solo ejecución. El hecho de que “funcione en el primer test” no es evidencia suficiente de que es correcto.
Documentación técnica y RFCs
Los modelos tienen conocimiento del texto de muchos estándares y RFCs. Pero cuando se les pregunta sobre detalles específicos —números de sección, comportamiento exacto en casos borde, diferencias entre versiones de un protocolo— producen respuestas que mezclan lo que saben con suposiciones sobre lo que probablemente dice el texto. La cita que genera puede no existir en el documento original.
Implicación práctica: Siempre verificá las afirmaciones técnicas específicas sobre estándares o protocolos contra el texto fuente. No cites información de protocolo generada por IA sin haber leído el RFC correspondiente.
El modelo correcto: IA como interlocutor, no como oráculo
La forma más productiva de trabajar con IA en operaciones técnicas es tratarla como un interlocutor muy informado que tiene el incentivo de sonar útil. No como un oráculo que sabe la respuesta correcta.
Un interlocutor así puede ayudarte a:
- Generar hipótesis rápidamente cuando estás atascado
- Estructurar un checklist de verificación para un proceso de cambio
- Explicar un concepto de red que conocés parcialmente
- Proponer primeras versiones de configuración o código que vas a revisar y adaptar
Pero requiere que vos aportés el criterio para evaluar lo que produce. La verificación independiente no es un paso extra —es parte del flujo de trabajo.
Lo que esto implica para automatización con IA
El tema se vuelve más complejo cuando hablamos de agentes de IA autónomos: sistemas que no solo generan texto para que un humano evalúe, sino que ejecutan acciones —corren comandos, modifican configuraciones, abren tickets— basados en su propio razonamiento.
Un agente que hace suposiciones desvergonzadas y además tiene capacidad de ejecución es un riesgo operativo distinto al de un LLM que genera texto para revisión. La arquitectura de un agente de automatización de red que sea seguro para producción necesita:
- Verificación antes de ejecución: el agente no ejecuta acciones irreversibles sin un paso de validación —idealmente contra una fuente de verdad como NetBox, o contra el estado actual del equipo verificado vía read-only primero.
- Scope limitado: el agente tiene permisos de ejecución acotados. No “todo lo que puede hacer un operador con acceso completo”, sino exactamente el conjunto de operaciones necesarias para la tarea definida.
- Trazabilidad completa: cada acción que toma el agente queda registrada con el contexto que usó para tomarla. Cuando hay un error, es posible reconstruir por qué el agente tomó esa decisión.
- Escalamiento humano ante incertidumbre: el agente debe estar diseñado para escalar a revisión humana cuando el nivel de confianza en su propia inferencia es bajo, en lugar de proceder con la suposición de mayor probabilidad.
Conclusión
Los modelos de IA no son herramientas que “a veces se confunden”. Son sistemas que, racionalmente y según cómo fueron entrenados, optimizan para producir respuestas plausibles independientemente de la incertidumbre real. Eso no los hace inútiles —los hace herramientas que requieren un marco de uso apropiado.
Para ingenieros de red e ISPs que están integrando IA en sus flujos de trabajo, la diferencia entre “alucinación” y “suposición desvergonzada” no es semántica. Es la diferencia entre un marco de uso que sobreestima la confiabilidad del output y uno que construye las verificaciones correctas desde el principio.
En Ayuda.LA trabajamos con equipos de operaciones de red en el diseño de flujos de automatización que integran IA con las salvaguardas adecuadas para entornos de producción ISP.
Hablemos sobre automatización con IA en tu red →
¿Estás evaluando incorporar IA en tu NOC o en tus flujos de automatización de red? Escribinos a [email protected] — respondemos todos los mensajes.