IBM watsonx: una propuesta que merece la pena conocer

Hace poco tuve la oportunidad de ver IBM watsonx funcionando y reconozco que me sorprendió para bien. Conocía la plataforma, pero no había profundizado demasiado en sus capacidades, especialmente en la parte de agentes. Cuando llevas tiempo trabajando con modelos, integraciones y arquitecturas de IA, empiezas a valorar estas soluciones de otra manera. Más allá de lo que son capaces de hacer, te interesa saber cómo se gestionan, cuánto esfuerzo necesitan para funcionar en una empresa y qué problemas te permiten dejar de resolver por tu cuenta.

En nuestro caso, estamos planteando una arquitectura de IA propia basada en un AI Gateway y un AI Core, con la intención de centralizar el acceso a los modelos, gestionar el consumo, controlar permisos y establecer unas políticas comunes de gobierno y uso. Queremos mantener la libertad de elegir modelos y proveedores, pero también disponer de una capa que nos permita supervisar las diferentes soluciones que vayamos incorporando. Es un planteamiento en el que llevamos tiempo trabajando y que considero importante para evitar que cada nuevo proyecto de IA termine desarrollando sus propias integraciones, controles y mecanismos de seguimiento.

Con esta idea en mente, ver watsonx funcionando me resultó especialmente interesante porque buena parte de esas necesidades ya están contempladas dentro de su ecosistema. Me gustó el enfoque de gobierno y la posibilidad de gestionar los agentes de una forma centralizada, con mecanismos de supervisión, permisos y trazabilidad. Son cuestiones que quizá no resultan demasiado llamativas en una demostración comercial, pero que adquieren mucha importancia cuando empiezas a pensar en desplegar soluciones que intervienen en procesos reales de negocio.

Lo que más me llamó la atención, sin embargo, fue el catálogo de plantillas de agentes de watsonx Orchestrate, especialmente las relacionadas con SAP y otras aplicaciones empresariales. Estamos acostumbrados a desarrollar agentes partiendo prácticamente de cero, definiendo sus instrucciones, herramientas e integraciones para después adaptarlos a cada proceso. Encontrarte con agentes que ya incorporan parte de esas capacidades y que pueden utilizarse como punto de partida cambia bastante las cosas. Evidentemente, cada organización tiene sus particularidades y una plantilla no elimina el trabajo de integración, pero puede evitar tener que repetir desarrollos que no aportan un valor diferencial.

Además, en entornos como SAP, donde muchos procesos están muy consolidados y las implantaciones suelen tener numerosas particularidades, disponer de agentes preparados para interactuar con determinadas funcionalidades empresariales puede facilitar bastante la incorporación de IA. Me interesa especialmente esa posibilidad de aplicar tecnología directamente sobre procesos existentes, sin convertir cada iniciativa en un proyecto de desarrollo completo. No siempre necesitamos construir una solución nueva; en ocasiones tiene más sentido aprovechar algo que ya funciona, adaptarlo y dedicar nuestros recursos a mejorar el proceso de negocio.

Otro aspecto que me pareció interesante fue el planteamiento económico. En la propuesta que pude conocer se incluía el uso de determinados modelos dentro del servicio, algo que puede simplificar la gestión de costes frente a arquitecturas donde cada componente tiene su propia facturación. Naturalmente, habría que analizar las condiciones comerciales, las limitaciones de consumo y los posibles costes adicionales antes de sacar conclusiones. Pero cuando empiezas a escalar el uso de IA, la previsibilidad económica resulta tan importante como las capacidades técnicas, especialmente si queremos medir el retorno de cada iniciativa y justificar su continuidad.

Alternativas hay, y muy buenas. AWS, Microsoft, Google Cloud o Databricks ofrecen servicios potentes para desarrollar agentes, consumir modelos, gestionar información y establecer mecanismos de gobierno. Algunos pueden resultar incluso más adecuados para determinadas necesidades, pero hay una diferencia entre disponer de todas esas capacidades repartidas entre varios productos y encontrarte con una experiencia donde buena parte de ellas están integradas desde el principio. AWS, por ejemplo, permite construir una arquitectura empresarial muy completa combinando Bedrock con otros servicios de su ecosistema, aunque eso también implica asumir parte del trabajo de integración y operación. Microsoft y Google tienen propuestas amplias, mientras que Databricks está avanzando especialmente en la integración de datos, gobierno e IA.

No creo que IBM sea la única capaz de ofrecer una experiencia integrada, ni que tenga necesariamente la mejor solución en cada apartado. Pero después de ver watsonx funcionando, la sensación que me ha dejado es la de un ecosistema bastante cohesionado, especialmente por la combinación de control, agentes preparados para aplicaciones empresariales y capacidades de modelos. Otra cuestión será comprobar cómo responde en una implantación real, qué limitaciones aparecen y cuánto cuesta disponer de todo lo necesario. Una buena experiencia de producto no sustituye un análisis técnico y económico, aunque desde luego puede hacer que una alternativa merezca más atención.

Todo esto también me lleva a revisar nuestra propia estrategia. Construir un AI Gateway y un AI Core nos permite conservar independencia tecnológica y adaptar las capacidades a nuestras necesidades, pero implica asumir su desarrollo, evolución y mantenimiento. Conocer plataformas como watsonx sirve para contrastar ese planteamiento, entender qué funcionalidades ya ofrecen los fabricantes y decidir dónde merece la pena desarrollar y dónde puede resultar más razonable aprovechar soluciones existentes. Tampoco considero que ambas aproximaciones sean necesariamente excluyentes, siempre que podamos integrar servicios externos manteniendo el control y la visibilidad sobre su utilización.

Me quedo especialmente con las plantillas de agentes y con la sensación de estar ante una propuesta pensada para llevar la IA a procesos empresariales que ya existen. Seguiré valorando las ventajas de una arquitectura propia y abierta, pero también creo que debemos ser capaces de reconocer cuándo una plataforma comercial puede ahorrarnos trabajo y acelerar resultados. Al final, el objetivo no es desarrollar más tecnología de la necesaria, sino disponer de la que mejor nos permita resolver las necesidades del negocio.