{"id":4173,"date":"2026-08-12T04:12:06","date_gmt":"2026-08-12T04:12:06","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/08\/12\/como-la-industria-tecnologica-olvido-dos-de-sus-mejores-ideas\/"},"modified":"2026-08-12T04:12:06","modified_gmt":"2026-08-12T04:12:06","slug":"como-la-industria-tecnologica-olvido-dos-de-sus-mejores-ideas","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/08\/12\/como-la-industria-tecnologica-olvido-dos-de-sus-mejores-ideas\/","title":{"rendered":"C\u00f3mo la industria tecnol\u00f3gica olvid\u00f3 dos de sus mejores ideas"},"content":{"rendered":"
\n
\n

Generalmente, solemos contar el progreso tecnol\u00f3gico como una historia de acumulaci\u00f3n: cada generaci\u00f3n hereda todo lo que aprendi\u00f3 la anterior, le a\u00f1ade unas cuantas cosas nuevas, y seguimos avanzando.<\/p>\n

Pero la realidad es bastante menos ordenada. En ocasiones, una tecnolog\u00eda no desaparece porque haya demostrado ser mala o porque haya sido superada por otra mejor, sino simplemente porque cambia la arquitectura que la rodea, porque los incentivos se desplazan, o porque un nuevo paradigma consigue atraer toda la atenci\u00f3n. Y a\u00f1os despu\u00e9s, alguien descubre que, por el camino, hab\u00edamos dejado atr\u00e1s algo que resultaba ser bastante valioso.<\/p>\n

El hormig\u00f3n romano es un buen ejemplo. Los investigadores que estudian construcciones de la \u00e9poca han conseguido reconstruir t\u00e9cnicas que proporcionaban al material una durabilidad extraordinaria y que, aparentemente, permit\u00edan incluso que algunas grietas se reparasen mediante reacciones en las que interven\u00edan fragmentos de cal<\/a>. No hablamos de un conocimiento que alguien hubiese demostrado err\u00f3neo: simplemente dej\u00f3 de formar parte de la pr\u00e1ctica habitual de la construcci\u00f3n, y tuvimos que recuperarlo siglos despu\u00e9s recurriendo a la arqueolog\u00eda y a la ciencia de materiales<\/a>. Investigadores del MIT han explicado c\u00f3mo una t\u00e9cnica de mezcla en caliente, el llamado hot mixing<\/em>, podr\u00eda estar detr\u00e1s de esas propiedades<\/a>.<\/p>\n

\u00bfPodr\u00eda estar ocurriendo algo parecido con la inteligencia artificial aplicada a la empresa? Mi impresi\u00f3n es que s\u00ed. Y que, de hecho, la industria no es que no haya sido capaz de inventar la arquitectura adecuada, sino que ha ido desplazando progresivamente fuera del centro dos ideas que en su momento fueron enormemente importantes: la orientaci\u00f3n a objetos persistentes y el aprendizaje por refuerzo.<\/p>\n

La primera cosa que olvidamos: los objetos est\u00e1n hechos para vivir<\/h3>\n

La programaci\u00f3n orientada a objetos nunca consisti\u00f3 simplemente en hablar de clases, m\u00e9todos o herencia. Su intuici\u00f3n fundamental era mucho m\u00e1s interesante: un objeto combina identidad, estado y comportamiento. Representa algo que existe, que recuerda en qu\u00e9 estado se encuentra, y que sabe qu\u00e9 operaciones pueden modificarlo.<\/p>\n

Para el software<\/em> empresarial, esa idea result\u00f3 especialmente adecuada. Un cliente, un contrato, una cuenta, un pedido o una reclamaci\u00f3n de seguros no eran simplemente una fila en una base de datos: eran entidades con identidad, relaciones, estado y comportamientos posibles.<\/p>\n

Hasta que lleg\u00f3 la nube y, casi sin darnos cuenta, algo cambi\u00f3: los sistemas cloud-native<\/em> se dise\u00f1an habitualmente para ser stateless<\/em>, sin estado. La computaci\u00f3n no debe depender de la m\u00e1quina concreta que atiende una petici\u00f3n, porque esa m\u00e1quina puede desaparecer, ser sustituida o pasar de pronto a estar acompa\u00f1ada por cientos de instancias id\u00e9nticas. AWS recomienda expl\u00edcitamente eliminar el estado de los componentes individuales<\/a>, precisamente para poder escalar horizontalmente y recuperarse de los fallos, mientras Microsoft describe los datos de una sesi\u00f3n web como informaci\u00f3n ef\u00edmera que debe almacenarse en una cach\u00e9 o una base de datos externa, y no confiarse al proceso de la aplicaci\u00f3n<\/a>.<\/p>\n

Como decisi\u00f3n de ingenier\u00eda, tiene todo el sentido del mundo. Pero conceptualmente supone tambi\u00e9n una renuncia bastante importante. El objeto puede seguir estando en el c\u00f3digo fuente, pero su estado duradero ya no vive junto a su comportamiento. Est\u00e1 repartido entre bases de datos, cach\u00e9s, almacenes de objetos, colas, flujos de eventos y sistemas de orquestaci\u00f3n. Cada petici\u00f3n debe reconstruir una parte suficiente de la realidad de ese objeto para poder hacer algo \u00fatil con \u00e9l y, una vez terminada la operaci\u00f3n, devolver su estado a una infraestructura externa antes de que la computaci\u00f3n que lo utiliz\u00f3 desaparezca.<\/p>\n

Con eso no eliminamos la orientaci\u00f3n a objetos, simplemente debilitamos una de sus propiedades m\u00e1s profundas. Y, con el tiempo, nos dedicamos a compensarlo con object-relational mappers<\/em>, almacenes de sesi\u00f3n, event sourcing<\/em>, message brokers<\/em>, cach\u00e9s distribuidas, motores de workflow<\/em> y una aut\u00e9ntica monta\u00f1a de glue code<\/em>. Ninguna de esas tecnolog\u00edas es absurda: todas resuelven problemas reales derivados de la escala y de la distribuci\u00f3n. Pero si las vemos en conjunto cuentan una historia bastante clara: la persistencia dej\u00f3 de ser una propiedad natural del objeto computacional para convertirse en un problema de ingenier\u00eda construido a su alrededor.<\/p>\n

\u00bfQu\u00e9 tiene eso que ver con la inteligencia artificial empresarial? Much\u00edsimo. Un sistema de inteligencia artificial que act\u00faa sobre una compa\u00f1\u00eda necesita bastante m\u00e1s que acceso a documentos y APIs. Necesita entidades persistentes cuya identidad, estado, relaciones, permisos y transiciones v\u00e1lidas se mantengan coherentes a lo largo del tiempo. Un cliente tiene que seguir siendo el mismo cliente independientemente de cu\u00e1ntas interacciones tengan lugar. Un proceso debe sobrevivir a las interrupciones. Un contrato debe mantener sus restricciones. Y un agente tiene que saber no solo qu\u00e9 se dijo anteriormente en una conversaci\u00f3n, sino qu\u00e9 cambi\u00f3 como consecuencia de ella en el mundo operativo de la compa\u00f1\u00eda.<\/p>\n

Hoy tendemos a llamar a todo eso \u00abmemoria\u00bb. Pero la memoria no es un modelo de objetos. La memoria puede recuperar fragmentos del pasado. Un modelo de objetos define qu\u00e9 existe y de qu\u00e9 manera puede cambiar. Anthropic, por ejemplo, present\u00f3 como un avance importante la posibilidad de que Claude utilizase conversaciones que se extend\u00edan durante semanas o meses<\/a>. Y para un chatbot<\/em>, obviamente, lo era. Pero visto desde la perspectiva del software<\/em> empresarial, el supuesto gran avance suena m\u00e1s bien modesto.<\/p>\n

Un cliente, un contrato, una reclamaci\u00f3n o un proceso comercial de nueve meses no deber\u00edan mantener su coherencia durante un mes<\/a>, deber\u00edan mantenerla mientras existan. El modelo no necesita conservar permanentemente cada token<\/em> anterior dentro de su contexto activo: lo que necesita es que el sistema que hay debajo mantenga una identidad y un estado persistentes, y reconstruya el contexto relevante cada vez que la inteligencia tenga que actuar. Un mes de memoria puede ser fant\u00e1stico para un chatbot<\/em>. Para el software<\/em> empresarial, es simplemente una fecha de caducidad.<\/p>\n

Nos hemos construido, por tanto, sistemas con una inteligencia extraordinaria en la parte superior y una realidad operativa completamente fragmentada por debajo.<\/p>\n

Pero no es lo \u00fanico que hemos ido dejando atr\u00e1s.<\/p>\n

Lo segundo que olvidamos: aprender de los resultados<\/h3>\n

La otra gran idea desplazada es el aprendizaje por refuerzo. El AlphaGo de DeepMind<\/a> combinaba redes neuronales profundas con aprendizaje por refuerzo para derrotar a algunos de los mejores jugadores de Go del mundo. Despu\u00e9s, AlphaZero fue bastante m\u00e1s all\u00e1: aprendi\u00f3 ajedrez, shogi y Go mediante autoaprendizaje, sin copiar partidas humanas, y MuZero aprendi\u00f3 a planificar sin que se le proporcionasen de antemano las reglas que gobernaban su entorno<\/a>.<\/p>\n

Aquellos sistemas demostraron algo bastante m\u00e1s importante que la simple capacidad de jugar bien. Demostraron c\u00f3mo la inteligencia pod\u00eda surgir de un ciclo repetido: actuar, observar el resultado, compararlo con un objetivo, y ajustar el comportamiento. Eso no es simplemente reconocimiento de patrones: es aprender de las consecuencias.<\/p>\n

Y entonces lleg\u00f3 el transformer<\/em>. En 2017, el famos\u00edsimo art\u00edculo \u00abAttention Is All You Need<\/a>\u00ab<\/em> present\u00f3 una arquitectura extremadamente paralelizable y extraordinariamente eficiente para procesar secuencias que termin\u00f3 convirti\u00e9ndose en la base de la actual oleada de inteligencia artificial generativa, y transformando completamente el procesamiento del lenguaje natural.<\/p>\n

El problema, obviamente, no es que los transformers<\/em> fuesen una mala idea. Todo lo contrario: son uno de los avances m\u00e1s importantes de la historia reciente de la computaci\u00f3n. El problema es lo que ocurri\u00f3 con el centro de gravedad de la industria.<\/p>\n

La predicci\u00f3n se convirti\u00f3 en el paradigma dominante. El aprendizaje por refuerzo no desapareci\u00f3, pero fue desplaz\u00e1ndose hacia la periferia: ajuste de modelos, alineamiento, rob\u00f3tica o algunos problemas concretos de optimizaci\u00f3n. Mientras tanto, aquella idea bastante m\u00e1s ambiciosa seg\u00fan la cual un sistema desplegado deb\u00eda mejorar continuamente conectando sus acciones con sus resultados reales pas\u00f3 a un segundo plano frente a la espectacular capacidad de generar lenguaje.<\/p>\n

Nos hicimos extraordinariamente buenos generando respuestas plausibles y, curiosamente, sorprendentemente tolerantes con sistemas que no tienen la menor idea de si esas respuestas sirvieron para algo. Y ah\u00ed est\u00e1, en mi opini\u00f3n, una de las grandes contradicciones de la inteligencia artificial empresarial. Las compa\u00f1\u00edas no necesitan simplemente sistemas capaces de generar lenguaje. Necesitan sistemas capaces de aprender de las consecuencias de lo que hacen.<\/p>\n

Por qu\u00e9 estas dos p\u00e9rdidas se refuerzan mutuamente<\/h3>\n

Porque una compa\u00f1\u00eda no es un prompt<\/em>, ni tampoco una sesi\u00f3n de chat<\/em>. Es un sistema cambiante formado por clientes, contratos, productos, empleados, permisos, procesos, restricciones y resultados. Si queremos que una inteligencia artificial mejore ese sistema, necesitamos dos cosas:<\/p>\n