- Muchas personas entienden mal la diferencia entre el software convencional y la inteligencia artificial
- El público general tiende a malinterpretar los riesgos de la IA con el concepto de “bug” del software tradicional, lo que genera una confianza equivocada sobre cómo resolver los problemas
- Los errores de la IA provienen de los datos de entrenamiento, no del código y, por su enorme escala, los humanos no pueden identificar qué datos causaron el problema
- A diferencia del software convencional, no se pueden encontrar, “corregir” ni “reproducir” bugs, y el comportamiento de la IA es no determinista, por lo que pequeños cambios en la entrada pueden alterar el resultado
- El desarrollo basado en especificaciones es casi imposible, y las capacidades o riesgos de la IA no pueden predecirse de antemano; a veces se descubren después funciones ocultas no intencionales
- Por eso, la forma tradicional de pensar en TI de que “si hay un problema, se arregla” actúa como una confusión fatal en el debate sobre la seguridad de la IA
Los límites del conocimiento sobre el software convencional
- Muchas personas del público y también gerentes tienen la convicción de que, frente a los riesgos del software, “el código con problemas (bugs) se puede corregir”
- Durante mucho tiempo, la industria del software ha logrado instalar con éxito la idea de que los bugs en el código pueden causar daños en el mundo real
- En el software convencional existen bugs, pero incluso si es complejo, es un ámbito en el que se pueden corregir
- Sin embargo, ese enfoque y esa forma de pensar no aplican a la IA, lo que provoca confusión y malentendidos
Diferencias de percepción entre expertos y no expertos
- El software convencional y el software de IA difieren de forma esencial tanto en su funcionamiento como en la forma en que surgen los problemas
- Los expertos dan por obvia esta brecha y no la explican, mientras que los principiantes no logran identificarla por sí mismos
- Como resultado, ambas partes tienen dificultades para comunicarse entre sí
Creencias del software convencional mal aplicadas a la IA
-
1. Las vulnerabilidades del software surgen por errores en el código
- En el software convencional, los bugs suelen originarse por errores al escribir el código
- Pero en la IA, las vulnerabilidades y la imprevisibilidad provienen casi siempre de los datos de entrenamiento
- Por ejemplo, en conjuntos de datos como FineWeb, es imposible que una persona revise por completo miles de millones de palabras de datos
- Debido al enorme volumen de datos con que aprende la IA, es difícil entender por completo qué aprendió y casi imposible identificar los factores de riesgo
-
2. Se pueden encontrar bugs analizando el código
- En el software tradicional, es posible analizar el código y rastrear lógicamente la causa de un bug
- En la IA, los problemas surgen por la influencia combinada de los datos de entrenamiento, así que en la práctica es imposible encontrar la causa en los datos
- Los investigadores suelen intentar mitigar el problema reentrenando la IA o agregando más datos, pero es difícil descubrir la causa directa mediante un rastreo lógico
- La causa de los bugs en la IA ni siquiera la conocen con precisión los propios desarrolladores
-
3. Si corriges un bug, no vuelve a aparecer
- En el software, cuando se corrige un bug detectado, ese bug ya no se reproduce exactamente de la misma forma
- Pero en la IA, incluso después de “corregir” un “bug”, el mismo comportamiento problemático puede reaparecer con entradas no probadas
- No se puede tener la certeza de haber eliminado por completo un comportamiento anómalo de la IA
-
4. La misma entrada siempre produce el mismo resultado
- El software convencional siempre devuelve la misma salida ante la misma entrada
- Técnicamente la IA también, pero cambios extremadamente pequeños en la entrada (como signos de puntuación) pueden cambiar por completo el resultado
- De hecho, varias grandes empresas de IA diseñan sus sistemas para que incluso con el mismo prompt produzcan salidas ligeramente distintas, con el fin de que parezcan menos mecánicos
-
5. Si das requisitos claros, puedes satisfacerlos
- En el software convencional, si defines especificaciones y requisitos claros, existe una forma de cumplirlos
- Pero en la IA, los diseñadores no pueden controlar ni garantizar con claridad el comportamiento general que desean
- Dentro de un rango limitado (por ejemplo, hablar en inglés o escribir código) puede haber cierto control explícito, pero no hay forma de garantizar todos los comportamientos (por ejemplo, no fomentar delitos)
- Después del lanzamiento de un servicio de IA, a veces se descubren por casualidad capacidades ocultas o riesgos que ni los desarrolladores conocían
- Es imposible garantizar y predecir por completo la seguridad de la IA
Hacia dónde avanzar
- El conocimiento mal generalizado del software distorsiona la confianza en la IA y la evaluación de sus riesgos
- Es importante compartir ampliamente con colegas cómo funciona la IA, cuáles son sus límites y en qué se diferencia del software convencional
- Hay que explicar las diferencias estructurales propias de la IA que no son muy conocidas y transmitir que un enfoque simple de “parchar bugs” no funciona
La brecha de comprensión entre expertos y principiantes
- Si al leer este texto te enteraste por primera vez de la diferencia fundamental entre la IA y el software convencional, compártelo con tus conocidos
- Si ya conocías esta diferencia, vale la pena hablar del tema con gente común o no especializada al menos una vez
- En realidad, no hay tantas personas que sepan que ambos son esencialmente distintos
1 comentarios
Opinión de Hacker News
Si quieres entender qué dificultades hay realmente para aprovechar bien los LLM, conviene ver el caso de Apple. Hace un año hizo un gran anuncio de Apple Intelligence y enfatizó los flujos de trabajo de agentes basados en LLM, pero desde entonces solo añadió algunas herramientas menores como creación de emojis, resúmenes de notificaciones y corrección de documentos. Incluso la función de resumen de notificaciones estuvo durante un tiempo “fuera de control” y tuvieron que retirarla artículo relacionado. En el evento del iPhone de este año también redujeron bastante el marketing de IA. Parece probable que la directiva de Apple subestimara lo difícil que es implementar los LLM con el nivel de acabado y control propio de Apple
Esta frase me resonó especialmente:
Al aplicar enfoques como MCP, este fenómeno de aumento del riesgo potencial se vuelve exponencial enlace a MCP
Siento que falta la premisa más importante. En el software tradicional no siempre se cumple, pero en IA es todavía más crucial: que “la misma entrada debe producir la misma salida”. Esto es indispensable para la confiabilidad en procesos de automatización
A menudo se dice que los bugs de IA se deben a problemas de datos, pero no es del todo cierto. Aunque la arquitectura del LLM o los datos de entrenamiento parezcan estar bien, los LLM son inherentemente no deterministas, así que por diseño algorítmico no siempre dan la misma respuesta a la misma pregunta. Según el escenario, el resultado cambia cada vez como si lanzaran los dados
Honestamente, me parece más acertada la idea de que “con el tiempo se irán corrigiendo todos los bugs y la confiabilidad de la IA aumentará”. Esta tecnología es completamente nueva, y la postura frecuente en HN de que “no determinista = basura” también es exagerada si consideramos que en los últimos dos años la confiabilidad de los LLM ha mejorado unas 10 veces
Hay que ser más cautelosos con la idea de que “todo comportamiento incorrecto de un sistema de IA proviene de los datos de entrenamiento”. Incluso si los datos y el proceso de entrenamiento fueran perfectos, la estructura del modelo de IA puede seguir produciendo errores
Me gustaría que se explicara con más claridad en qué situaciones aparecen los “bugs de IA”. Estoy de acuerdo en que no se debe delegar en un LLM la toma de decisiones en tiempo real y sin supervisión. Por ejemplo, creo que todavía es demasiado pronto para que la IA controle los semáforos de una ciudad. Pero desde la perspectiva de un ingeniero, el tema de los bugs de IA se discute sobre todo en “agentes de programación”, y como en casi todos esos ámbitos hay supervisión, estas preocupaciones no se aplican de forma tan directa
Es importante hacer entender que “la IA a veces funciona sorprendentemente bien y a veces decepciona, y nunca lo sabrás sin hacer pruebas”. Aun así, es imposible probar todos los casos. Si los clientes entienden eso, terminarán exigiendo alcance y control sobre las pruebas, y los proveedores se concentrarán en entornos verificables (por ejemplo, escribir código) o en áreas donde la precisión no importa (texto, generación de memes). Si apoyas la IA, conocer este punto a fondo es una ventaja realmente valiosa. En cambio, a la gente no le interesan los bugs de la IA, ni las especificaciones, ni el colapso del modelo tradicional de programación; pero si la IA influye en elecciones o provoca despidos masivos, entonces aparecerá una enorme hostilidad y exigencias de regulación. Si eso ocurre, la industria resistirá con las tácticas de exención de responsabilidad y evasión regulatoria que ha ido perfeccionando (disclaimers, exclusiones contractuales, cláusulas de arbitraje, etc.), y al final creo que, tras las secuelas de unos pocos accidentes grandes y fortuitos, podrían quedar en riesgo tanto el crecimiento de la industria como la inversión generacional en ella
El verdadero peligro con la IA es el “poder concentrado”. Es una preocupación más realista que imaginar una IA con emociones humanas tratándonos como baterías de Matrix
Últimamente he estado tratando de hacerle entender a la gente que “nadie sabe exactamente cómo funciona la IA”. Quiero enfatizar que construir algo y conocer su principio no son lo mismo. Con los humanos pasa igual