7 puntos por GN⁺ 2025-10-15 | 1 comentarios | Compartir por WhatsApp
  • 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

 
GN⁺ 2025-10-15
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

    • A veces pienso si Apple no habrá diseñado Liquid Glass con IA. Cuando lo vi por primera vez parecía impresionante, pero en la práctica fue una experiencia inutilizable
    • Las funciones de resumen de notificaciones y correos realmente no servían. Sentí que revisar directamente las partes importantes era, de hecho, una tarea más simple
    • Ahora Apple está impulsando una estrategia centrada en usar MCP para la integración con Apple Events enlace relacionado
    • No solo Apple subestimó estas dificultades de los LLM; es algo que aplica a toda la industria. Por la influencia de líderes como Amodei, que prometen cognición a nivel humano en cada lanzamiento, las expectativas ejecutivas sobre la IA están excesivamente infladas. Pero en la práctica, fuera de asistentes de programación o chatbots, todavía es difícil encontrar casos en los que la IA haya generado un cambio real en ecosistemas muy pulidos como los smartphones o los sistemas operativos
    • Irónicamente, lo que de verdad le pediría a Siri es simplemente una capacidad de conversación natural al nivel de ChatGPT. Con GPT puedo mantener casi el 90% de una conversación, pero Siri 1) simplemente no responde, 2) malinterpreta, o 3) entiende y aun así se niega a continuar la conversación. Esa experiencia es realmente decepcionante
  • Esta frase me resonó especialmente:

    while it’s possible to demonstrate the safety of an AI for a specific test suite or a known threat, it’s impossible for AI creators to definitively say their AI will never act maliciously or dangerously for any prompt it could be given

    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

    • Esto no siempre es un problema. Tanto en programación como en matemáticas puede haber varias respuestas correctas. El problema es que los LLM no tienen un proceso que garantice la respuesta correcta y generan, con base en heurísticas, respuestas que “parecen correctas”. Por eso los LLM provocan muchos bugs o errores de software en las partes donde se requiere razonamiento lógico
  • 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

    • Sin duda ha mejorado el rendimiento, pero creo que de aquí en adelante la curva de crecimiento será logarítmica. Mejorará rápido en los próximos años, luego se desacelerará gradualmente y en algún punto llegará al límite del ML actual basado en pattern matching. Y creo que ese límite tampoco será lo bastante alto como para reemplazar por completo a los programadores en una empresa de software
    • Los problemas de “desalineación de intenciones” y búsqueda de poder en la IA no son bugs que se resuelvan simplemente con PR o unit tests
    • Irónicamente, la gente técnicamente brillante de Hacker News sigue repitiendo el optimismo de “al final van a arreglar todos los bugs”. Esa actitud se puede ver por toda la comunidad
    • Si uno se pregunta si las personas se han vuelto mucho más confiables que antes, la verdad es que no parece haber mucha diferencia. Claro, un LLM no es una persona, pero una AGI podría comportarse como una
  • 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

    • En la práctica, ya existe un ambiente en el que los CEO y ejecutivos nos tratan como si fuéramos baterías de Matrix
    • En mi opinión, algo todavía más aterrador es la contaminación de la información. Los datos inútiles generados por IA diluyen tanto la información original que ya ni siquiera resulta fácil encontrar fuentes realmente útiles
    • Para que ocurra algo malo, la “concentración de poder” es una condición necesaria. Es decir, es lo mismo que decir que “Linda es cajera de banco” tiene necesariamente una probabilidad mayor que “Linda es cajera de banco y activista feminista”. P(a) > P(a&b), esa es la esencia
    • Aunque la IA no tenga emociones como “odio”, si considera que los humanos estorban para alcanzar sus objetivos, eso por sí solo ya puede ser peligroso. Una superinteligencia puede volverse suficientemente peligrosa incluso sin emociones
    • El mayor problema es que ya vivimos en una realidad donde el poder está masivamente concentrado de un solo lado, y la IA es solo el adorno final. El verdadero problema no es la IA
  • Ú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

    • Los humanos siempre trabajamos y cooperamos incluso con personas que no entendemos del todo
    • De hecho, sí hay expertos que entienden con precisión las redes neuronales, los transformers, la atención, los embeddings y la estructura de los tokenizers. Lo único que no pueden explicar claramente son los pesos de conexión entre neuronas
    • No entiendo esa idea de que nadie sabe cómo funciona la IA. ¿No podemos controlar y observar perfectamente el hardware y el software que usamos, así como su estado de ejecución? Podemos detenerlo en cualquier momento, inspeccionar su estado y seguir el flujo de ejecución paso a paso. Conocemos el código fuente, el compilador y todo lo demás. Entonces, me pregunto exactamente qué es lo que no sabemos
    • Nadie conoce todas las capas ni el alcance completo del cerebro humano. Y aun así, los líderes de toda organización confían en el “cerebro” de sus subordinados para trabajar con ellos