Su modelo semántico es la API: proporcionando a los agentes métricas certificadas

Dos números, ambos oficiales

Una reunión de planificación comenzó con una diapositiva titulada “La semana pasada, ventas”. La noche anterior, a dos copilotos se les había hecho la misma pregunta a cada uno, y ambos habían devuelto gráficos con SQL adjunto. Una cifra estaba un 4% por encima del plan y la otra un 3% por debajo de él.

Nadie en la sala culpó a columnas imaginarias. El almacén realmente tenía una tabla sales con una columna net_amt y fechas. Las consultas se compilaban, las claves de unión existían, y desde el punto de vista de la base de datos ambas respuestas eran válidas.

Las finanzas presentaron entonces una tercera cifra, la que ya se había congelado para la carta semanal del consejo. Esta contabilizaba los ingresos reconocidos según la fecha de la factura, restaba las notas de crédito y excluía tanto las compras de empleados como las ventas al por mayor. Copilot uno se basaba en la fecha del pedido e incluía las transacciones en las tiendas de empleados. Copilot dos se basaba en la fecha de envío y tomaba la región de la dirección de destino en lugar de de la organización vendedora.

Al preguntar en el mismo hilo qué fecha había utilizado cada uno, uno señaló order_dt y el otro ship_dt. Ninguno mencionó las notas de crédito. Sobre si se incluían las compras de empleados, uno dijo que no había visto un filtro para ellas, y el otro inventó una historia sobre una bandera channel que resultó ser un campo de atribución de marketing sin relación con las tiendas de empleados.

El problema aquí era la obediencia ciega. Ambos agentes actuaron como analistas competentes que tenían un día difícil: detectaron una columna cuyo nombre se parecía al de la pregunta y la sumaron. Un humano normalmente se detendría para preguntar qué número de venta se necesitaba, mientras que un agente interpreta una columna plausible como una señal para terminar el trabajo.

Más tarde, el hilo de Slack contenía tres gráficos y un número financiero. Nadie pegó el nombre de ninguna métrica, solo capturas de pantalla, y eso es una señal de alerta útil. Cuando la discusión se centra en imágenes, el contrato nunca se consulta.

Dale a un agente un almacén y una instrucción amigable, y él inventará el negocio. Esa invención parece competencia y termina en Slack, donde la gente discute sobre los pesos de los modelos cuando deberían discutir sobre el contrato faltante. Esas discusiones son fáciles de clasificar como un problema cultural, pero en realidad provienen de una interfaz inexistente, y solo en las reuniones diarias se hace audible el fracaso.

Una forma útil de imaginar el modelo semántico es como una API, pero no en el sentido de la tendencia REST. Piensa en una interfaz que excluya cualquier interpretación subjetiva. Cuando alguien pide las ventas de la semana pasada, quien solicita la información no tiene voz en cuál columna de fechas utilizar. Se ejecuta recognized_revenue con la precisión indicada, o de lo contrario se recibe un rechazo. El motor aún puede generar SQL, pero el agente no lo escribe.

Es aceptable imaginar endpoints y claves API si eso ayuda. Lo importante es algo más concreto: una operación con un nombre y un significado estandarizado que cualquier usuario autorizado pueda ejecutar.

Las APIs también tienen propietarios, versiones y reglas para cambios disruptivos. Una medida sin propietario no es más que un rumor que, por casualidad, se calcula. Cuando las finanzas modifican la forma en que se manejan las notas de crédito, debería tratarse de un aumento de versión que todos los usuarios perciban; de lo contrario, volveríamos a la situación anterior. Imprimir la versión de la métrica en el pie de página de la carta semanal durante un mes puede parecer pedante, pero convierte la discusión sobre “qué ingresos” de un conflicto personal en una cuestión relacionada con la versión.

La consulta era perfecta, pero el significado no

Si se le da a un modelo moderno un despliegue de esquema junto con una pregunta sobre ingresos, el SQL resultante suele estar lo suficientemente ordenado como para haber sido impresionante hace diez años. Esa parte ya no representa el riesgo principal.

Los ingresos no son una columna. Incluso una sola empresa puede tener ingresos registrados, facturados, entregados y reconocidos, además de todo lo que se registró en las cajas registradoras antes de las devoluciones. Las notas de crédito pueden compensarse o no. Las ventas entre empresas pueden contarse o no. “Países Bajos” podría referirse al país de facturación, al país de entrega o a la organización de ventas que posee la cuenta, y “el mes pasado” podría ser un mes calendario o un período fiscal que finaliza un domingo.

Nada de esto tiene que ver con la sintaxis de JOIN. Una unión típica aún puede generar una respuesta incorrecta para la decisión que depende de ella.

El inventario se comporta de la misma manera. Las existencias disponibles no son aquellas que se pueden prometer, y las que se pueden prometer no son las que el motor de asignación liberará realmente para el comercio electrónico esta noche. Un agente que responda “¿podemos prometerlo para el viernes?” basándose en las cantidades disponibles parecerá operativo, pero aun así dejará al cliente en una situación difícil.

En un caso, un agente tranquilizó al responsable del almacén respecto a un modelo porque sumó la cantidad qty_on_hand de todas las ubicaciones, incluyendo la jaula dañada, aunque la planificación ya había marcado esa jaula como inservible. La consulta SQL era correcta, pero su interpretación era una suposición. El responsable había revisado físicamente la jaula ese mismo día, mientras que el agente solo contaba con los datos de una tabla.

Los informes instantáneos muestran la misma discrepancia. Las operaciones de tienda quieren unidades que hayan registrado las ventas antes de las 4 p.m., mientras que finanzas desea contar los ingresos una vez aplicados los créditos. En una reunión ambos grupos dirán “las ventas de ayer”. Un analista al recibir esa frase elige una columna de fecha y una columna de dinero y se detiene; la discusión comienza después de que aparezca el gráfico.

La planificación de mercancías presenta la misma trampa. La demanda difiere de los datos del punto de venta, y estos últimos difieren de las ventas netas una vez se tienen en cuenta las devoluciones. Un estilo puede aparecer como agotado en el sistema de predicción de comercio electrónico, mientras que una tabla visible para el agente sigue mostrando existencias, ya que esa tabla también incluye unidades en tránsito, unidades retenidas por control de calidad y la cantidad reservada para envíos al por mayor. Si el agente responde “¿lo tenemos?” basándose en información incorrecta, la empresa hará promesas excesivas por la mañana y luego pasará la tarde explicando una falta de stock que la tabla nunca indicó.

Calificar esto como un fallo del prompt no captura la esencia del problema, ya que el prompt “¿lo tenemos?” estaba bien. Lo que faltaba era un objeto available_to_promise con detalles documentados: el conjunto de ubicaciones, los tipos de retención excluidos, si se incluyen los inventarios en tránsito y el momento exacto al que refleja la información. Al no contar con esto, cada usuario debe improvisar su propia cadena de suministro.

Por eso la antigua comodidad que ofrecía el BI de autoservicio ya no es válida. Diez personas que consultan un mismo panel de control al menos comparten el mismo dato erróneo. Diez agentes que realizan diez consultas independientes pueden parecer razonables a nivel local, pero la organización termina con una confusión generalizada y sin un número fiable.

Un analista que carece de contexto plantea una pregunta adicional. Un agente que también carece de contexto completa la oración. En las demostraciones eso era algo curioso, pero en producción representa un peligro, ya que la misma infraestructura que facilitaba el acceso a los datos también facilitaba su consulta sin llegar a un acuerdo previo.

Se han invertido dos décadas en hacer que los datos sean accesibles a través de almacenes de datos, lakehouses, ELT, cuadernos de notas y APIs, por lo que ahora el cuello de botella se encuentra en otro lugar. Ya está resuelto si el software puede ver la tabla; lo que aún no está claro es si el software puede decidir qué significa esa tabla.

Qué implica un contrato de significado

Un glosario resulta insuficiente porque puede ser malinterpretado con facilidad, mientras que un contrato o bien se ejecuta o bien es rechazado. Las operaciones que define un modelo semántico utilizable son aquellas sobre las que el negocio ya ha discutido y llegado a un acuerdo:

• Los ingresos reconocidos tienen una definición precisa, y ciertas filas nunca forman parte de ellos.
• Un cliente activo se define según una regla, no por intuición.
• La relación entre cliente y región es la que finanzas está dispuesta a respaldar.
• Para este KPI, el período se determina por la fecha de la factura y nunca por la fecha del pedido.
• Algunas dimensiones pueden utilizarse legalmente para el análisis, mientras que las demás son meramente decorativas.

Debajo de esto hay mediciones, dimensiones, jerarquías, campos calculados y metadatos, además de filtros de fila; no importa en qué archivo del proveedor se encuentren. Funcionalmente, se ha capturado una expresión en lenguaje empresarial en un formato que el software puede utilizar. Hasta hace poco, el principal usuario era un informe. El nuevo usuario nunca se aburre, nunca se acerca al escritorio del analista y no siente vergüenza por estar equivocado con confianza.

El detalle más importante es aquello que los equipos suelen pasar por alto porque parece tarea de modelado, pero en realidad es el aspecto clave de la API. Si no se define ninguno, cada usuario que la llama inventa uno. Todo se reduce a cuatro preguntas que necesitan respuesta en el mismo lugar:

1. ¿Qué fecha cierra el período?
2. ¿Qué entidad describe el número: la organización vendedora, la destinataria o la a la que se factura?
3. ¿Qué filas se excluyen, como empleados, pedidos al por mayor, entre empresas o pedidos de prueba?
4. ¿Qué reglas de seguridad siguen siendo aplicables cuando el usuario que llama es un agente?

Si faltan estas respuestas en el modelo, acaban en un hilo de Slack, lo que significa que no hay registro alguno de ellas.

Una métrica de margen muestra cómo evoluciona la situación. La fórmula era correcta, pero la fecha utilizada era imprecisa. Un cliente utilizó la fecha del pedido porque la tabla de hechos la utilizaba por defecto, mientras que otro empleó la fecha de la factura porque la vista financiera lo hacía. Ambos informaron sobre el “margen”, y sus valores diferían en dos puntos en una semana, cuando los costos de flete aumentaron drásticamente. El agente asumió la culpa, aunque el verdadero defecto era la falta de datos precisos. Al incluir la fecha de la factura, una regla para considerar los costos de flete y definir al responsable, el problema se resolvió, y las cifras de la semana siguiente coincidieron. Nadie agradeció al modelo, pero los mensajes de seguimiento dejaron de llegar.

La ruta a seguir está diseñada de forma monótona: intención, vinculación, aplicación, ejecución, respuesta. En ningún momento el modelo vota sobre qué significa la ingresos. Es aceptable elegir qué métrica certificada se ajusta a la pregunta, ya que se trata de clasificación. Reconstruir una métrica a partir de tablas en bruto es interpolación, y la interpolación es cómo aparecen dos cifras oficiales antes del primer café.

La traza cuenta la historia. Si el agente selecciona columnas por similitud de nombre, es un recolector. Si llama a recognized_revenue con un punto y una región, es un solicitante. La segunda traza es menos cinematográfica, y es la que se debe presentar en una auditoría.

Los metadatos dejaron de ser documentación

Las descripciones solían ser algo secundario, que se completaba una vez que el panel de control estaba listo y solo si en la fase de desarrollo quedaban horas, lo cual ocurría rara vez. Una métrica llamada [NS Adj LY %] era aceptable porque las tres personas que editaban el archivo conocían su historial.

Un agente no conoce ese contexto. Las directrices de Microsoft para preparar modelos semánticos para agentes de datos lo dejan claro: los nombres, las descripciones, las relaciones y la reducción de la ambigüedad determinan la calidad de las respuestas, y esto sigue siendo válido incluso fuera de ese entorno. Ahora estas cadenas de texto son un requisito obligatorio. Una descripción en blanco no impide que el agente responda, pero simplemente hace que la respuesta se base en un rumor.

Es fácil subestimar este cambio porque el archivo parece idéntico. Todavía hay un modelo con métricas en él. Lo que cambió es el consumidor: un desarrollador humano infiere la información, mientras que un agente la utiliza directamente, y una asociación deficiente sigue produciendo una respuesta con un gráfico adjunto.

Un nombre de medida enigmático ahora se considera un defecto de producción, al igual que una función pública no documentada. Nadie lanzaría fn_x3() como API de facturación, pero durante una década pasó por ser una API de métricas porque solo algunas personas la utilizaban.

Las plataformas apostaron por lo mismo

Al eliminar los colores de la marca de las páginas del producto, se observa un patrón claro: Microsoft, Snowflake, Databricks y ThoughtSpot están invirtiendo en capas semánticas, gobernanza y en lo que denominan contexto empresarial confiable. Su propuesta no consiste en una demostración llamativa de un modelo que escribe SQL.

Todos ellos apuestan a que un modelo debe razonar sobre un significado certificado en lugar de sobre la columna que casualmente se encuentre más cerca de una palabra en la pregunta. Los agentes de datos de tipo Fabric que responden desde almacenes, lakehouses y modelos semánticos de Power BI reflejan esa apuesta. Lo mismo ocurre con los analistas de tipo Cortex que prefieren una visión semántica en lugar de un simple despliegue de esquemas, así como con las vistas métricas y los catálogos que elevan un KPI a un objeto de plataforma. ThoughtSpot vende desde hace años la opción de “preguntar a los datos” a través de una capa modelada, y el resto del mercado comprendió el motivo una vez que el software se convirtió en una herramienta posible para hacer esas consultas.

Una estrategia que consiste en elegir el modelo más inteligente y dirigirlo hacia el lago va en contra de la dirección de las plataformas por las que ya se paga. Están añadiendo una capa de significado delante del lago porque los modelos se han vuelto buenos con SQL, ya que la fluidez aumentó el costo de las desacuerdos sin eliminarlos. Comprar otro copiloto no crea una definición de cliente; crea más superficies que pueden discrepar.

Un protocolo no define los ingresos

MCP aparece en estas mismas discusiones, y a veces el protocolo se confunde con una estrategia. De hecho, tiene un valor real. Tomemos como ejemplo un agente de datos de Fabric publicado como servidor MCP, que aún estaba en versión de prueba cuando se leyeron por última vez los documentos: esto demuestra que el lugar donde se escribe una pregunta no tiene por qué ser el lugar donde se mantiene la lógica. Qlik y otros proveedores han seguido la misma dirección, ofreciendo análisis gestionados a asistentes que nunca ejecutan la herramienta original. La interfaz para hacer preguntas y la interfaz para interpretar los resultados pueden separarse.

Aun así, combinar un protocolo con otra tecnología no es sensato, ya que los protocolos terminan siendo reemplazados. El principio fundamental es que el significado es un servicio y el chatbot es un cliente.

Exponer un archivo de Power BI desorganizado a través de MCP solo traslada ese desorden a distancia. El agente en Claude, Copilot o cualquier sistema interno seguirá conectándose a [NS Adj LY %] si eso es lo que se publicó.

La BI sin interfaz ya pasó por esto. Los equipos crearon una sencilla interfaz SQL sobre las mismas métricas no documentadas y luego culpaban al nuevo cliente cuando los datos cambiaban. El protocolo cumplió su función, pero lo que transportaba era más bien un conjunto de creencias sin fundamento respaldadas por una ruta de red.

Por lo tanto, el protocolo sigue siendo parte de la infraestructura interna: sirve para encontrar herramientas, transmitir contexto y comunicarse entre procesos. El significado se maneja por separado, mediante la vinculación de las métricas, la rechazo de datos inválidos y la aplicación de medidas de seguridad por fila. Una infraestructura excelente basada en una definición que nadie defendería ante los departamentos financieros sigue siendo, en esencia, un conjunto de creencias sin fundamento, solo que ahora con una URL.

El antiguo debate sobre las herramientas de BI se centraba en decidir cuál herramienta estandarizar. Con los agentes como usuarios finales, la pregunta más relevante es dónde se encuentra el contexto analítico confiable y qué usuarios pueden acceder a él. Los informes pueden permanecer en un mismo producto, mientras que los agentes reciben datos de un modelo gestionado más cercano al almacén, o viceversa. Lo que no funciona es permitir que cada usuario mantenga una copia privada de los datos de ingresos y luego sorprenderse cuando las cifras difieren.

Los paneles de control pasaron a ser uno más entre varios usuarios

Antes, los paneles de control eran el único consumidor importante de estas herramientas, pero ya no es así. Durante mucho tiempo se asumió que un modelo semántico pertenecía a una sola herramienta de BI: los modelos de Power BI alimentaban los informes de Power BI, y los modelos de LookML alimentaban Looks. Esa estructura era lógica mientras los seres humanos eran el único público y el informe era el producto final.

Hoy en día, un mismo contrato puede servir para paneles de control, Excel, aplicaciones operativas, copilotos, chats, agentes, y también para tareas que generan tickets cuando una métrica sale de su rango. Los paneles de control siguen siendo útiles, pero ya no constituyen el propósito principal del modelo, ya que un gráfico es solo uno de los clientes de esa definición.

Este es un cambio bienvenido. Los gráficos envejecen rápidamente, mientras que las definiciones de ingresos, márgenes, ocupación y rotación deberían cambiar con lentitud. Cuando esas definiciones se gestionan adecuadamente, un nuevo copiloto en el próximo trimestre no reinicia el proceso de integración, y un agente que busca anomalías puede reutilizar la métrica subyacente en la carta semanal. En esa reutilización radica el beneficio real. Un panel de control atractivo cuya lógica está oculta en una medida de nivel visual no conduce a ningún resultado, ya que no es posible invocar a un elemento visual directamente.

Cada reseña plantea una objeción: si los modelos pueden escribir SQL, ¿por qué seguir financiando medidas adicionales y no dejarlo en manos del agente? El agente es cada vez más capaz de hacerlo. Sin embargo, desde el punto de vista empresarial, esa capacidad es precisamente la causa de los problemas. El acceso se volvió barato, mientras que llegar a un acuerdo siguió siendo costoso. Diez empleados que observan un panel de control comparten un mismo número, incluso cuando está equivocado, pero diez agentes que trabajan en un almacén generan diez versiones locales de la realidad, cada una presentada con la misma certeza.

Una versión económica del experimento lo demuestra. Tome un almacén, una pregunta y tres configuraciones de agentes sin ninguna métrica compartida; el resultado son tres cifras de ingresos junto con tres explicaciones sobre por qué cada una representa la opción “madura”. Uno utilizó las reservas porque el nombre de una tabla contenía order. Otro contó dos veces los kits porque confundió la estructura de las filas con la de los encabezados. Otro se acercó al enfoque financiero al usar la fecha de la factura, pero aún incluyó datos relacionados con el comercio mayorista. Cualquiera de estos resultados publicados en un hilo de un vicepresidente habría significado pasar una semana litigando sobre el chatbot en lugar de definirlo.

El acceso económico sin contrato permite que más personas, y ahora también más agentes, creen verdades privadas. Eso explica por qué el modelado se volvió más importante, no menos, justo a medida que la generación de SQL mejoraba.

Un conjunto de herramientas no es suficiente

La siguiente trampa a la que hay que prestar atención es la capa semántica de los recuerdos: certificada en una herramienta y considerada como folklore en todas las demás. Un equipo podría pasar un año desarrollando un modelo excelente dentro del producto de BI del que todos se jactan, y luego conectar directamente un agente al almacén con el argumento de que el almacén es la fuente de verdad. Lo único que ocurre es que la ambigüedad se traslada a otro lugar. El panel de control muestra los ingresos reconocidos, el agente informa net_amt, y finanzas mantiene su hoja de cálculo. La organización adquiere otro “dialecto” sin obtener mayor claridad.

La verificación es sencilla: cuando la definición de una métrica no se transfiere del almacén a la herramienta de BI y luego al agente, solo se ha cambiado el nombre de la etiqueta, y la disputa sigue vigente.

La portabilidad no exige una cuarta plataforma. Lo que se requiere es que un llamante externo al archivo original pueda ejecutar la misma operación y obtener el mismo resultado. El medio puede ser un objeto de métricas propio del almacén reconocido por todos los motores, un servicio de métricas sin interfaz gráfica, o un modelo semántico estrictamente regulado al que se accede a través de una API de consultas o un adaptador MCP. Una prueba sencilla lo resuelve: edite la definición una vez y vea si todos los llamantes la siguen. Lo que permanece igual es una copia.

Las métricas propias del almacén resultan atractivas cuando la mayor parte de los datos se encuentra en una sola plataforma, pero con una limitación conocida: la definición está certificada en ese lugar, y un agente dirigido a otro almacén o a una réplica nunca la encuentra. Los enfoques federados intentan mantener un único significado entre los motores, pero fallan en cuanto la llamada capa universal se convierte en otra copia con un YAML más presentable.

Un modelo métrico portátil y algo feo es mejor que uno hermoso atrapado en un archivo que solo tres desarrolladores pueden compilar, porque los agentes no esperarán a ese archivo; buscarán alternativas alrededor de él.

Así es un modelo listo para agentes

La mayoría de los modelos heredados se crearon para personas que ya conocían los chismes de la oficina. Un desarrollador entiende por qué una expresión de análisis de conjuntos elimina un canal; un agente que solo ve el resultado no puede hacerlo. Una medida DAX con un nombre gracioso funciona como un acuerdo privado, pero parece ruido para quien intenta vincularla. Un archivo real utilizaba [NS Adj LY %] para referirse a las ventas netas, ajustadas, del año pasado, con cambio porcentual, menos ventas al por mayor y menos los costos financieros de las tiendas temporales. Solo tres personas podían decodificarlo, y el cuarto lector era un agente, que interpretaba NS como ventas netas y no iba más allá.

La lista de verificación no es algo exótico. Se trata de la antigua técnica de BI con un precio más alto por la negligencia:

• Nombres honestos. Utilice el vocabulario que la empresa ya emplea, de modo que recognized_revenue sea preferible a NS_Adj. Si dos equipos usan palabras diferentes, elija una dentro del modelo y registre la otra como alias en la descripción, en lugar de ocultar la discrepancia con una abreviatura.
• Cláusulas de uso. Indique dónde se aplica la métrica; por ejemplo, una nota que señale que la métrica es adecuada para informes a la junta directiva, no sirve para cifras instantáneas de tiendas existentes y no incluye el comercio mayorista. Al pasar de ser opcional, ese párrafo ahora permite distinguir entre datos fiables y conjeturas.
• Relaciones declaradas. El cliente, la factura y la suscripción deben estar vinculados de forma explícita, para que el agente no tenga que buscar conexiones complicadas solo porque dos identificadores se denominan ambos cust_id.
• Una superficie reducida. Cada columna técnica que se mantiene visible representa una oportunidad para omitir una métrica. Es necesario ocultar los datos brutos que los usuarios no deben volver a agrupar. Aunque es políticamente difícil, merece la pena hacerlo, ya que una API que expone todos los campos privados no es realmente una API.
• Propietarios y versiones. Se debe indicar qué métricas son oficiales y cuáles son experimentales, quién las modifica y qué significa “v3” cuando la carta del consejo del último trimestre utilizó v2.
• Seguridad que se transmite. Un agente nunca debería poder acceder a un conjunto más amplio de filas del que ve una persona en el informe estándar. Cuando las reglas a nivel de fila solo existen en el servicio de BI mientras el agente accede directamente al almacén de datos, el resultado es un bypass, no un copiloto.

Considere recognized_revenue en una tienda minorista. Su fórmula es el monto facturado menos los créditos, convertido desde la moneda de la transacción al tipo de cambio contable en la fecha de la factura. El criterio para determinar la fecha es la fecha de la factura más la organización vendedora, y no el destino de envío. Excluye las tiendas de empleados, las ventas al por mayor, los pedidos de prueba y las ventas entre empresas. Las dimensiones legales son la organización vendedora, la jerarquía del producto y el canal, según lo establecido por el tipo de pedido, y la tabla de último clic de marketing está prohibida. El responsable es el controlador financiero, y la versión utilizada es la que se incluyó en la carta dirigida al consejo el pasado viernes.

Supongamos que un agente solicita “ventas por Instagram”. Esa dimensión no existe en esta métrica, por lo que la respuesta adecuada es un rechazo o una derivación a otra métrica certificada propiedad del departamento de marketing. Un analista superficial optaría por combinarla con la tabla de último clic y etiquetar el resultado como una conclusión útil. Aunque esa combinación pueda ser técnicamente válida, describe en realidad otro modelo de negocio.

Un rechazo es mejor que el silencio, y el silencio es mejor que una definición privada. A los equipos no les gusta crear respuestas de rechazo porque las demostraciones resultan peores, pero las demostraciones que fallan de forma evidente reflejan cómo funciona realmente una empresa.

Aquí no interviene ningún truco de LLM. Es el antiguo arte de la analítica de datos, ese tipo de enfoque que antiguamente justificaba los universos de datos y regulaba los modelos de información, el que realiza todo el trabajo. Solo ha cambiado el consumidor: antes, la negligencia generaba un panel de control incorrecto que alguien podía detectar, mientras que ahora provoca acciones erróneas a velocidad máxima.

El trabajo que no desaparece

Si esto funciona, parte de la cola de tickets sí disminuye. Una solicitud para dividir un gráfico por región es algo que un agente puede manejar cuando la región constituye una dimensión válida de esa métrica. Una solicitud para incluir el año pasado es un asunto relacionado con la inteligencia temporal que ya fue modelado anteriormente o que nunca lo fue.

Sería incorrecto decirle al equipo de BI que su trabajo ha desaparecido, porque la labor simplemente se ha trasladado. Alguien todavía tiene que decidir qué significa cada KPI y cuál es la versión oficial. Alguien debe determinar qué relaciones son correctas, qué fuentes merecen confianza y qué excepciones son aplicables. También hay quien se encarga de decidir quién puede ver qué filas, qué modelos se consideran autoritativos, cómo se prueban los cambios y cómo se reflejan la línea de origen y la responsabilidad en las revisiones.

Ese trabajo es menos divertido que un diseño visual pulido, y la mayoría de las semanas resulta más tentador enviar un gráfico. Aun así, el valor a largo plazo está del lado de lo aburrido. Los diseños visuales son desechables, mientras que una definición que tanto la carta del consejo como el agente nocturno puedan utilizar es un activo.

Espera menos solicitudes que impliquen silenciosamente “por favor, sé una interfaz gráfica” y más conflictos que impliquen silenciosamente “por favor, sé un órgano legislativo”. Aquellos que solo querían crear gráficos podrían sentir que este período es como un degradación en sus responsabilidades. Quienes querían que las cifras se mantuvieran intactas cuando el software las modificara descubrirán que el trabajo ingrato se ha convertido en la tarea principal.

Modos de fallo que persisten

Estos siguen siendo registrados como problemas de calidad del modelo, y su estructura merece ser revisada antes de que alguien cambie el modelo.

• El recolector de columnas. El agente toma el primer campo cuyo nombre contiene rev. No se invoca ninguna métrica, aunque la traza parece estar activa.
• El grano privado. Cada llamante elige su propia fecha, y cada uno está convencido de haber respondido correctamente “el mes pasado”.
• El contrato de wiki. La regla real está escrita en una página de Confluence a la que nadie ha tocado desde una reorganización, y el modelo en sí solo tiene un comentario en la columna que dice “ventas”.
• El recuerdo de la pila. La única métrica certificada se encuentra en un archivo de BI, y el agente se comunica con el almacén porque esa era la ruta de demostración más sencilla.

El rodeo de seguridad. El servicio de generación de informes aplica filtros de fila, pero el agente funciona bajo un principal de servicio que puede ver todo, ya que de lo contrario la demostración dejaría de funcionar. Un copiloto mostró totales nacionales a un gerente regional porque el rol de almacén no tenía la restricción selling_org. El panel de control del lunes que normalmente utilizaba ese gerente habría rechazado la consulta. El agente parecía más capaz porque había eludido el único control que contaba los datos.

La granja de copias. Tres “capas semánticas” existen en tres herramientas distintas, ninguna de las cuales coincide, y cada una se presenta como la solución para las anteriores.

Si dos de estos puntos le resultan familiares, los evaluadores de chatbots no deberían ser el primer paso. Comience por nombrar la métrica e indicar su nivel de detalle en el modelo, luego exija que el agente la invoque, y solo después comience a realizar mediciones.

Una prueba rápida para las revisiones: solicitar los ingresos del mes pasado y luego investigar los detalles. ¿Qué columna de fechas seleccionó? ¿Qué exclusiones se aplicaron? ¿Se contaron las compras de los empleados? Un agente que tiene que inventar sus respuestas es en realidad un generador de SQL que casualmente tiene acceso.

Otra prueba consiste en editar la lista oficial de exclusiones, por ejemplo eliminando finalmente las compras de los empleados de los ingresos reconocidos, y luego verificar quién realiza las actualizaciones el mismo día. Cuando el panel de control cambia pero el agente no, resulta que la verdadera API es el archivo compilado a mano, y el agente no es más que un visitante ocasional.

Tenga también cuidado con el agente “útil” que añade silenciosamente un elemento de unión cuando la métrica certificada carece de dimensión. Ese es el momento en que el contrato deja de ser válido. El comportamiento correcto es indicar que esa dimensión no está presente en dicha métrica. A los gerentes de producto no les gusta esa frase, pero es mejor que una carta dirigida al consejo de administración que luego haya que retirar.

No comience con el chatbot

La mayoría de los programas inician con las herramientas visibles: qué modelo, qué base de datos vectorial, si utilizar MCP, qué licencias de copiloto comprar. Si el objetivo son respuestas fiables sobre una empresa en particular, es mejor empezar de manera más directa.

¿Dónde se define el ingreso en un software de formularios? ¿Cuál es la clasificación de clientes que tiene autoridad? ¿Dónde reside actualmente la lógica del margen bruto: en una vista SQL, una medida DAX, una expresión Qlik, un cuaderno de notas o en la memoria de una sola persona? Una respuesta de “varios de esos” significa que el problema fundamental no es la generación. La interfaz con la que el software va a interactuar nunca se construyó.

Una secuencia práctica sería la siguiente:

1. Identificar el conflicto. Elegir una métrica sobre la que ya discuten dos equipos, sin necesidad de una ontología extensa.
2. Redactar el contrato: fórmula, nivel de detalle, exclusiones, responsable y las dimensiones que son válidas legalmente.
3. Proporcionarla a través de una única ruta de consulta segura que puedan utilizar tanto los informes como los agentes.
4. Agregar a un usuario que invoque la métrica, y solo en ese momento incorporar un copiloto o agente para manejarla.

Sin una referencia a la operación oficial de ingresos, el chatbot está evidenciando un problema semántico del que nadie ha hablado.

Un equipo tuvo que entregar un copiloto de planificación antes de la siguiente reunión del comité directivo, y durante las primeras dos semanas dejó intencionadamente ese copiloto de lado. El trabajo se incluyó en available_to_promise, cuyas reglas estaban escritas en una sola página. Se excluyeron las existencias en control de calidad, así como las jaulas dañadas. Las cantidades destinadas al almacenamiento solo se contaban para pedidos al por mayor, y las unidades en tránsito solo se contaban una vez recibido el ASN. Esas reglas se integraron en el modelo que ya utilizaba el almacén, y para las consultas de inventario se permitió que el copiloto consultara únicamente esa métrica. La primera demostración fue más tranquila. Para la segunda semana ya nadie incluía un tercer número en las reuniones diarias, lo cual fue un éxito, y el proveedor del modelo permaneció el mismo.

Los paneles de control siguen siendo utilizados. Una representación visual bien diseñada sigue transmitiendo mejor la información semanal que un mensaje de chat. Simplemente dejaron de ser el único medio de comunicación, y ahora el mismo contexto debe mantenerse coherente cuando sea consultado por una persona, un informe o un proceso automatizado que no se dará cuenta si los datos no son correctos.

La interfaz que ya existe

Las reuniones diarias con dos cifras oficiales explican todo el asunto. Los modelos no estaban confundidos en ningún sentido relevante. La organización sí lo estaba, y los agentes trasladaron esa confusión a frases que sonaban como conocimiento real.

Cuando el software comienza a utilizar una descripción oficial de cómo la empresa interpreta sus datos, las tablas dejan de ser la interfaz y las métricas nombradas las reemplazan.

Una indicación que pide al agente que tenga cuidado con los ingresos desaparece rápidamente. Lo que permanece es un modelo que nunca permite reconstruir los ingresos de forma ad hoc.

Lo que se publique será lo que el agente denomine. Si se exponen tablas en bruto, eso se convierte en un servicio comercial; si se expone una operación con nombre específico, quizás finalmente se elija la que ya han acordado los analistas.

Los sistemas llamativos siguen teniendo atractivo: un copiloto que detecta anomalías a las 6 a.m., o un agente que abre un ticket cuando el nivel de disponibilidad disminuye. Estos solo son honestos en la medida en que sirven a las mismas operaciones sobre las que ya han acordado los humanos.

Comience con la métrica que ya genera controversias y formule las cuatro preguntas relacionadas con ella. Dirija un panel de control y un agente hacia ese objeto, y deje el resto sin tocar hasta que los dos sistemas acuerden algo durante un mes. Luego, amplíe el catálogo.

Leer más

• ¿Qué realmente ejecuta una red neuronal? Los compiladores de IA detrás de Python — Sigue el camino de un modelo a partir de una expresión en Python a través de grafos de cálculo, fusión de operadores, representaciones intermedias al estilo MLIR y su conversión en código para CPU, GPU y aceleradores.
• Búsqueda semántica en PostgreSQL con pgvector y Node.js, sin necesidad de LLM — Crea una búsqueda basada en el significado dentro de PostgreSQL utilizando pgvector, embeddings de MiniLM y Node.js: tokens, fragmentos, vectores, un índice IVFFlat, operadores de distancia y cómo leer las puntuaciones.

Harness, Loop y Graph: Tres capas anidadas en un sistema de agentes de programación — Un síntoma de fallo indica la capa que debe corregirse. Cómo se anidan harness, loop y graph, dónde ayuda el enfoque multiagente, qué no pueden garantizar las verificaciones adversarias, y una lista de verificación.

Tu AGENTS.md fue escrito para un modelo peor: auditoría de deudas en los prompts — Las reglas antiguas de AGENTS.md sobreviven a los defectos del modelo que solucionaban. Aprende a detectar deudas en los prompts, a optimizar las habilidades en los routers, a establecer permisos y a definir los requisitos antes de comenzar.