Los datos de SAP ya pueden salir de SAP. Los agentes necesitan que el significado viaje con ellos
En una semana, SAP, Databricks y Google abrieron caminos nuevos a los datos y la semántica de SAP para agentes de IA. Resuelven cuatro problemas distintos y solo algunas piezas están en GA.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
Durante veinte años, sacar datos de SAP significó extraerlos: un pipeline que copiaba tablas a un data warehouse, las despojaba del contexto de negocio que las hacía significativas y dejaba la gobernanza en la frontera. Un campo llamado NETWR llegaba al data warehouse; el conocimiento de que es un valor neto de pedido en moneda del documento, y a qué documentos aplica, se quedaba en SAP.
Eso era tolerable para dashboards creados por personas que conocían SAP. Falla con los agentes, que leen los campos de forma literal y a escala. En la última semana de octubre, tres proveedores anunciaron respuestas distintas a ese problema, y ayuda separarlas.
Qué se anunció
SAP, en TechEd Berlin, el 29 de octubre, detalló nuevas capacidades de SAP Business Data Cloud. Completó la adquisición de Dremio y ahora ofrece SQL federado entre lakehouses y bases de datos como SQL Server, Oracle, MongoDB y Postgres sin mover datos, además de Apache Iceberg nativo y un catálogo universal impulsado por Apache Polaris. Completó la adquisición de Reltio, y SAP Reltio está en disponibilidad general (GA) en SAP Business Data Cloud para datos maestros multidominio con resolución de entidades basada en IA. Y presentó Ontology Manager, una forma asistida por IA de construir vistas específicas de dominio del SAP Knowledge Graph, que conecta entidades de negocio, relaciones y reglas. El propio ejemplo de SAP es una vista para un agente de cobros que abarca clientes, facturas, condiciones de pago y riesgo crediticio.
Databricks, el 30 de octubre, describió la siguiente fase de SAP Databricks dentro de SAP Business Data Cloud. SAP Databricks y SAP Business Data Cloud Connect están disponibles hoy. Genie, Lakeflow, Unity Gateway y Lakebase dentro de SAP Databricks están planificados, igual que una integración bidireccional entre Genie de Databricks y Joule de SAP.
Google, el 29 de octubre, puso en disponibilidad general (GA) el soporte ampliado de modelos semánticos en Knowledge Catalog. Ingiere definiciones de negocio de Looker, BigQuery, dbt MetricFlow, Snowflake, Databricks y, a través de SAP Business Data Cloud, Core Schema Notation de SAP. Cuando dos herramientas definen la misma métrica de forma distinta, ambas aparecen con su procedencia para que los responsables de datos puedan conciliarlas. Google cita benchmarks internos de casi cuatro veces más precisión de los agentes y hasta un 75 por ciento menos tokens; son cifras de Google con metodología no divulgada.
Cuatro problemas, no uno
Es tentador clasificar todo esto bajo ‘capa semántica’. Los anuncios abordan cuatro formas distintas en que un agente falla con datos empresariales.
| Falla del agente a la que responde | Estado | |
|---|---|---|
| Federación y acceso sin copia (Dremio, Iceberg, SAP Business Data Cloud Connect) | No puede llegar a los datos o lee una copia obsoleta | Entregado por SAP; adiciones de Databricks planificadas |
| Resolución de entidades (SAP Reltio) | Trata dos registros de un mismo cliente como dos clientes | Disponibilidad general (GA) |
| Significado de negocio (CSN en Knowledge Catalog, Ontology Manager) | Usa la definición equivocada de una métrica o relación | Soporte del catálogo en GA; Ontology Manager recién presentado |
| Actuar en la aplicación (Genie y Joule) | Puede responder, pero no actuar donde vive el proceso | Planificado |
Un agente puede tener acceso perfecto y aun así contar dos veces a un cliente. Puede resolver clientes correctamente y aun así calcular el margen con una definición que finanzas abandonó el año pasado. Cada fila necesita su propio responsable y su propia prueba, y por eso sostuvimos que el contexto de un agente necesita una especificación con significado, evidencia y frescura como propiedades separadas.
La pregunta que sigue
Cuando escribimos en octubre sobre agentes que leen las definiciones de negocio donde viven, la pregunta abierta era cuál definición prevalece. La respuesta de Google, mostrar ambas con su procedencia, es honesta e incompleta: expone el conflicto y deja la decisión a un responsable.
La posición de SAP es distinta y, para los clientes de SAP, persuasiva. El ERP es donde se registran las transacciones, así que debería ser donde se define el significado de esas transacciones, y los agentes deberían leer ese significado en lugar de reconstruirlo. Es coherente con la apuesta de SAP de que los agentes más valiosos se quedan dentro del sistema transaccional.
Para los equipos de arquitectura, la secuencia práctica se desprende de la tabla. Deben decidir quién es dueño de cada definición crítica antes de comprar un catálogo. Deben tratar la resolución de entidades como un programa de calidad de datos, no como una función de IA. Y deben planificar en torno a lo que está en disponibilidad general hoy; Genie dentro de SAP y la integración de Genie y Joule siguen en el roadmap.