Generalmente, solemos contar el progreso tecnológico como una historia de acumulación: cada generación hereda todo lo que aprendió la anterior, le añade unas cuantas cosas nuevas, y seguimos avanzando.
Pero la realidad es bastante menos ordenada. En ocasiones, una tecnología 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ón. Y años después, alguien descubre que, por el camino, habíamos dejado atrás algo que resultaba ser bastante valioso.
El hormigón romano es un buen ejemplo. Los investigadores que estudian construcciones de la época han conseguido reconstruir técnicas que proporcionaban al material una durabilidad extraordinaria y que, aparentemente, permitían incluso que algunas grietas se reparasen mediante reacciones en las que intervenían fragmentos de cal. No hablamos de un conocimiento que alguien hubiese demostrado erróneo: simplemente dejó de formar parte de la práctica habitual de la construcción, y tuvimos que recuperarlo siglos después recurriendo a la arqueología y a la ciencia de materiales. Investigadores del MIT han explicado cómo una técnica de mezcla en caliente, el llamado hot mixing, podría estar detrás de esas propiedades.
¿Podría estar ocurriendo algo parecido con la inteligencia artificial aplicada a la empresa? Mi impresión es que sí. 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ón a objetos persistentes y el aprendizaje por refuerzo.
La primera cosa que olvidamos: los objetos están hechos para vivir
La programación orientada a objetos nunca consistió simplemente en hablar de clases, métodos o herencia. Su intuición fundamental era mucho más interesante: un objeto combina identidad, estado y comportamiento. Representa algo que existe, que recuerda en qué estado se encuentra, y que sabe qué operaciones pueden modificarlo.
Para el software empresarial, esa idea resultó especialmente adecuada. Un cliente, un contrato, una cuenta, un pedido o una reclamación de seguros no eran simplemente una fila en una base de datos: eran entidades con identidad, relaciones, estado y comportamientos posibles.
Hasta que llegó la nube y, casi sin darnos cuenta, algo cambió: los sistemas cloud-native se diseñan habitualmente para ser stateless, sin estado. La computación no debe depender de la máquina concreta que atiende una petición, porque esa máquina puede desaparecer, ser sustituida o pasar de pronto a estar acompañada por cientos de instancias idénticas. AWS recomienda explícitamente eliminar el estado de los componentes individuales, precisamente para poder escalar horizontalmente y recuperarse de los fallos, mientras Microsoft describe los datos de una sesión web como información efímera que debe almacenarse en una caché o una base de datos externa, y no confiarse al proceso de la aplicación.
Como decisión de ingeniería, tiene todo el sentido del mundo. Pero conceptualmente supone también una renuncia bastante importante. El objeto puede seguir estando en el código fuente, pero su estado duradero ya no vive junto a su comportamiento. Está repartido entre bases de datos, cachés, almacenes de objetos, colas, flujos de eventos y sistemas de orquestación. Cada petición debe reconstruir una parte suficiente de la realidad de ese objeto para poder hacer algo útil con él y, una vez terminada la operación, devolver su estado a una infraestructura externa antes de que la computación que lo utilizó desaparezca.
Con eso no eliminamos la orientación a objetos, simplemente debilitamos una de sus propiedades más profundas. Y, con el tiempo, nos dedicamos a compensarlo con object-relational mappers, almacenes de sesión, event sourcing, message brokers, cachés distribuidas, motores de workflow y una auténtica montaña de glue code. Ninguna de esas tecnologías es absurda: todas resuelven problemas reales derivados de la escala y de la distribución. Pero si las vemos en conjunto cuentan una historia bastante clara: la persistencia dejó de ser una propiedad natural del objeto computacional para convertirse en un problema de ingeniería construido a su alrededor.
¿Qué tiene eso que ver con la inteligencia artificial empresarial? Muchísimo. Un sistema de inteligencia artificial que actúa sobre una compañía necesita bastante más que acceso a documentos y APIs. Necesita entidades persistentes cuya identidad, estado, relaciones, permisos y transiciones válidas se mantengan coherentes a lo largo del tiempo. Un cliente tiene que seguir siendo el mismo cliente independientemente de cuántas 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é se dijo anteriormente en una conversación, sino qué cambió como consecuencia de ella en el mundo operativo de la compañía.
Hoy tendemos a llamar a todo eso «memoria». Pero la memoria no es un modelo de objetos. La memoria puede recuperar fragmentos del pasado. Un modelo de objetos define qué existe y de qué manera puede cambiar. Anthropic, por ejemplo, presentó como un avance importante la posibilidad de que Claude utilizase conversaciones que se extendían durante semanas o meses. Y para un chatbot, obviamente, lo era. Pero visto desde la perspectiva del software empresarial, el supuesto gran avance suena más bien modesto.
Un cliente, un contrato, una reclamación o un proceso comercial de nueve meses no deberían mantener su coherencia durante un mes, deberían mantenerla mientras existan. El modelo no necesita conservar permanentemente cada token 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ástico para un chatbot. Para el software empresarial, es simplemente una fecha de caducidad.
Nos hemos construido, por tanto, sistemas con una inteligencia extraordinaria en la parte superior y una realidad operativa completamente fragmentada por debajo.
Pero no es lo único que hemos ido dejando atrás.
Lo segundo que olvidamos: aprender de los resultados
La otra gran idea desplazada es el aprendizaje por refuerzo. El AlphaGo de DeepMind combinaba redes neuronales profundas con aprendizaje por refuerzo para derrotar a algunos de los mejores jugadores de Go del mundo. Después, AlphaZero fue bastante más allá: aprendió ajedrez, shogi y Go mediante autoaprendizaje, sin copiar partidas humanas, y MuZero aprendió a planificar sin que se le proporcionasen de antemano las reglas que gobernaban su entorno.
Aquellos sistemas demostraron algo bastante más importante que la simple capacidad de jugar bien. Demostraron cómo la inteligencia podía 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.
Y entonces llegó el transformer. En 2017, el famosísimo artículo «Attention Is All You Need« presentó una arquitectura extremadamente paralelizable y extraordinariamente eficiente para procesar secuencias que terminó convirtiéndose en la base de la actual oleada de inteligencia artificial generativa, y transformando completamente el procesamiento del lenguaje natural.
El problema, obviamente, no es que los transformers fuesen una mala idea. Todo lo contrario: son uno de los avances más importantes de la historia reciente de la computación. El problema es lo que ocurrió con el centro de gravedad de la industria.
La predicción se convirtió en el paradigma dominante. El aprendizaje por refuerzo no desapareció, pero fue desplazándose hacia la periferia: ajuste de modelos, alineamiento, robótica o algunos problemas concretos de optimización. Mientras tanto, aquella idea bastante más ambiciosa según la cual un sistema desplegado debía mejorar continuamente conectando sus acciones con sus resultados reales pasó a un segundo plano frente a la espectacular capacidad de generar lenguaje.
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í está, en mi opinión, una de las grandes contradicciones de la inteligencia artificial empresarial. Las compañías no necesitan simplemente sistemas capaces de generar lenguaje. Necesitan sistemas capaces de aprender de las consecuencias de lo que hacen.
Por qué estas dos pérdidas se refuerzan mutuamente
Porque una compañía no es un prompt, ni tampoco una sesión de chat. 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:
- Por un lado, un mundo persistente en el que pueda actuar: entidades que mantengan su identidad, procesos que conserven su estado y relaciones que sigan siendo coherentes a lo largo del tiempo.
- Y por otro, necesitamos un mecanismo para que aprenda qué consiguen sus acciones: objetivos, observaciones, feedback, resultados y capacidad para modificar su comportamiento futuro.
Si eliminamos lo primero, representar adecuadamente una compañía se vuelve extremadamente complicado. Si eliminamos lo segundo, optimizarla de manera continua se vuelve directamente imposible.
Eso explica, seguramente, por qué tanta inteligencia artificial empresarial sigue pareciendo una interfaz muy sofisticada colocada encima de un runtime que no existe. Puede hablar maravillosamente bien sobre la organización, pero no puede vivir dentro de ella de una manera persistente, con estado, y orientada a resultados.
También explica por qué tantos despliegues siguen teniendo un fuerte componente artesanal. Son las personas las que tienen que reconstruir el contexto, conectar los sistemas, definir los permisos, explicar los objetos de negocio, medir los resultados y rediseñar el ciclo para cada caso de uso. El modelo aporta la inteligencia, sí, pero la arquitectura necesaria para convertir esa inteligencia en una capacidad organizativa que se acumula y mejora con el tiempo seguimos montándola prácticamente a mano.
El resultado es una industria brillantísima a la hora de hacer demostraciones y, paradójicamente, bastante mala a la hora de acumular aprendizaje.
La arquitectura que necesitamos ahora
La siguiente arquitectura de inteligencia artificial empresarial tendrá necesariamente que recuperar esas dos ideas a la vez. Necesitará objetos cuya identidad, estado, relaciones, permisos y comportamiento persistan de manera natural, aunque la ejecución vaya saltando de una máquina a otra y el sistema pase de gestionar diez interacciones a gestionar diez millones.
Y necesitará aprendizaje por refuerzo no simplemente como una técnica utilizada antes del despliegue, sino como un mecanismo operativo: acciones que generen evidencias estructuradas, evidencias que puedan conectarse con resultados de negocio, y resultados que permitan mejorar las acciones siguientes.
Los objetos persistentes proporcionarían a la inteligencia artificial un mundo empresarial estable sobre el que actuar. El aprendizaje por refuerzo le permitiría mejorar su comportamiento dentro de ese mundo. Y la combinación de ambas cosas podría transformar el software: dejaríamos de tener sistemas que simplemente registran lo que hizo una compañía, para pasar a tener sistemas que ayudan a esa compañía a aprender qué es lo que funciona.
Puede que el próximo gran salto de la inteligencia artificial empresarial no venga, después de todo, de otra capacidad espectacular de un nuevo modelo. Puede que consista simplemente en recuperar dos principios que la industria entendió perfectamente en su momento, pero que después permitió que se separasen y se perdiesen por caminos diferentes: objetos que viven, y sistemas que aprenden de las consecuencias.
(This article was previously published on Fast Company)
