Problema
Un agente puede escribir SQL correcto y responder mal porque “cliente activo”, “ingreso” o “conversión” significan cosas distintas según el equipo. Más acceso a datos amplifica la ambigüedad.
Finanzas llama ingreso a lo facturado. Producto mira MRR reconocido. Ventas incluye contratos firmados. Las tres cifras pueden vivir en tablas impecables y producir respuestas incompatibles a la pregunta “¿cuánto crecimos?”. El problema no es recuperar datos. Es decidir qué definición gobierna cada conversación.
Tesis
El contexto de negocio debe gobernarse como código: definiciones versionadas, fuentes confiables, ejemplos, owners, tests y revisión antes de cambiar el significado que consume el agente.
“Como código” no significa encerrar el conocimiento en YAML. Significa aplicar propiedades que el software lleva décadas usando para controlar cambio: diff, owner, test, revisión, historial y rollback.
La frontera útil: el data agent no necesita acceso a toda la empresa. Necesita una ruta defendible desde la pregunta hasta una definición y una fuente.
Framework
LangChain plantea un agent data stack con modelos semánticos, fuentes confiables, guías y endorsements. La unidad de calidad no es solo la tabla; es la ruta documentada desde una pregunta hasta una interpretación aprobada.
Esa ruta tiene cinco capas:
- Término: qué significa la métrica, para quién y durante qué periodo.
- Cálculo: fórmula, filtros, moneda, zona horaria y tratamiento de excepciones.
- Fuente: tabla o modelo autorizado, con frescura esperada.
- Uso: preguntas para las que la definición es válida y preguntas para las que no.
- Confianza: owner, fecha de revisión y evidencia de reconciliación.
Los ejemplos importan tanto como la definición. “Cliente activo” puede excluir pruebas, cuentas internas y morosos. Un agente aprende el borde con casos positivos y negativos, no con una frase elegante.
Señal medible: porcentaje de métricas usadas por agentes con definición, owner y test semántico.
Por que importa ahora
Los agentes multiplican el volumen de preguntas que un equipo de datos puede atender. Sin contratos semánticos, también multiplican respuestas plausibles pero incompatibles.
La escala cambia el trabajo del equipo de datos. Ya no responde cada petición manualmente; mejora el sistema que responde. Eso desplaza esfuerzo desde producir consultas hacia mantener definiciones, observar preguntas fallidas y resolver conflictos entre fuentes.
También convierte una modificación semántica en release. Si Finanzas cambia la definición de churn, el equipo debe saber qué dashboards, agentes y decisiones consumen esa métrica. Un cambio sin análisis de impacto es una migración silenciosa del negocio.
Anti-ejemplo
“Le dimos acceso al warehouse y al catálogo.” Acceso describe dónde están los datos, no qué significan ni cuál fuente manda cuando discrepan.
Otro error es añadir una capa semántica sin proceso de desacuerdo. Cuando dos owners reclaman definiciones distintas, el agente no debe elegir la más reciente ni mezclar ambas. Debe mostrar el conflicto y pedir contexto.
Protocolo (3 pasos)
- Define términos críticos. Incluye fórmula, owner, alcance y excepciones.
- Versiona contexto. Revisa cambios mediante diff y pruebas.
- Evalúa preguntas reales. Comprueba interpretación, consulta y explicación final.
Incluye en la suite preguntas ambiguas: “¿quiénes son nuestros mejores clientes?” o “¿estamos creciendo?”. La respuesta madura no siempre es una cifra. A veces es una pregunta de aclaración con opciones bien definidas.
| Capa | Artefacto | Test |
|---|---|---|
| semántica | definición | caso límite |
| confianza | fuente aprobada | reconciliación |
| uso | guía | respuesta evaluada |
Relacionado
- Data Contracts para equipos de IA: sin ellos no hay escala
- Context Supply Chain: la cadena de suministro que decide si tu IA sabe trabajar
Fuentes consultadas
Proximo paso
Escoge las diez métricas que más consulta el negocio y conviértelas en contratos revisables. Luego prueba al agente con excepciones, no solo con preguntas felices.