Context engineering: cómo preparar tus datos para que la IA entienda tu negocio

Preguntas a un agente de IA por qué han bajado las ventas y recibes una explicación convincente. Después descubres que ha comparado meses incompletos, mezclado pedidos con facturas y utilizado una nota comercial antigua. El texto puede estar bien escrito mientras la respuesta conduce a una decisión equivocada.

Context engineering, o ingeniería del contexto, consiste en preparar la información que el modelo necesita para resolver una tarea: qué datos recibe, qué significan, de dónde proceden y qué límites debe respetar. Para una empresa que trabaja con Snowflake y dbt, parte de ese trabajo empieza en su plataforma de datos.

El 26 de octubre de 2026, dbt publicó un experimento que compara distintas formas de proporcionar contexto a un agente. Lo utilizamos como punto de partida para esta guía del 2 de noviembre, dirigida a equipos que quieren conectar IA con datos de negocio sin perder la capacidad de comprobar las respuestas.

Qué nos enseña el experimento reciente de dbt

dbt comparó cuatro maneras de preparar un informe de reuniones: transcripciones completas recuperadas desde Gong, las mismas transcripciones desde el warehouse, resúmenes breves del proveedor y resúmenes elaborados para la tarea. Ejecutó cada variante 20 veces, con 80 sesiones en total.

Los resúmenes preparados para el ejercicio redujeron el coste medio un 48,5 % y el tiempo un 43,2 % frente al control. También conservaron más información que los resúmenes breves, pero obtuvieron cero aciertos en la categoría de decisiones. El resultado muestra un compromiso entre coste, velocidad y detalle, no una mejora universal.

Son cifras del experimento de dbt, no resultados de Nubita ni una previsión de ahorro para otros proyectos. Además, conviene medir el coste de construir y actualizar los resúmenes en una implantación real. Nuestra lectura es que hay que evaluar qué información se conserva antes de celebrar una reducción del contexto. Consultar el experimento, su metodología y sus límites.

Qué información necesita la IA para responder bien

Imagina la pregunta «¿por qué hemos vendido menos en octubre?». Antes de pedir una explicación, el sistema debe resolver varias cuestiones:

• Definición: si ventas significa pedidos, facturación o ingresos netos, y cómo se tratan impuestos, devoluciones y anulaciones.
• Periodo: qué fechas se comparan, con qué zona horaria y si ambos periodos están cerrados.
• Cobertura: qué tiendas, canales y monedas se incluyen y si falta alguna carga.
• Evidencia: qué consulta respalda la cifra y qué documentos apoyan una posible explicación.
• Acceso: qué información puede consultar la persona que hace la pregunta.

Una instrucción como «actúa como un analista experto» orienta el comportamiento, pero deja sin resolver esas condiciones. Recuperar muchos documentos tampoco basta: una política de precios de hace dos años puede ser relevante por sus palabras y estar fuera de vigencia.

Cómo se relaciona con prompting, RAG y la capa semántica

Estas piezas resuelven partes diferentes del problema. El prompting indica la tarea y el formato esperado. Un sistema RAG recupera información para acompañar la petición. La ingeniería del contexto abarca la selección, preparación y actualización de esa información, junto con las herramientas y restricciones que intervienen en la respuesta.

La capa semántica aporta definiciones compartidas para las métricas y sus relaciones. En Snowflake, las vistas semánticas permiten representar conceptos de negocio en la base de datos. Pueden ayudar a que distintas aplicaciones consulten las mismas definiciones; su configuración no demuestra por sí sola que una explicación comercial sea cierta. Documentación de vistas semánticas de Snowflake.

Los documentos aportan otro tipo de evidencia: incidencias, acuerdos o cambios operativos. Relacionarlos con una caída de ventas requiere comprobar fechas y alcance. Que dos hechos coincidan no prueba que uno haya causado el otro.

Una arquitectura posible con S3, Snowflake, dbt y Airflow

Para empezar, proponemos aprovechar las responsabilidades que ya tiene cada componente del stack:

1. S3 conserva los originales: archivos de entrada o documentos autorizados, con identificadores y versiones que permitan volver a la fuente.
2. Snowflake organiza los datos: tablas de negocio y registros documentales relacionados por claves estables, con acceso controlado.
3. dbt prepara los modelos: transforma los datos, documenta reglas y ejecuta comprobaciones antes de exponer resultados al consumidor.
4. Airflow coordina el proceso: espera a las cargas y validaciones necesarias y actualiza el contexto cuando corresponde.
5. La aplicación recupera evidencia: aplica los permisos del usuario, selecciona información pertinente y entrega al modelo un contexto acotado.

Es una propuesta de diseño. Estas herramientas no quedan conectadas automáticamente y el patrón no exige utilizarlas todas. Un primer piloto puede trabajar con una tabla agregada y unos pocos documentos revisados. La búsqueda vectorial se añade cuando el tipo de preguntas y el volumen lo justifican.

dbt dispone también del paquete dbt_context_engineering, presentado en septiembre, para preparar texto destinado a agentes. Es una opción que conviene evaluar junto con los modelos propios; antes de incorporarlo, revisa su versión, sus requisitos y las funciones que realmente necesitas. Presentación y alcance del paquete.

Ejemplo: un contexto pequeño para explicar las ventas

El siguiente JSON contiene datos ficticios. Ilustra un contrato entre la plataforma y la aplicación, no una API estándar de Snowflake o dbt. Los importes y la variación deben calcularse y validarse antes de llamar al modelo.

{
  "metrica": "ventas_netas_eur",
  "definicion": "Importe sin IVA, descontadas devoluciones; excluye anulados",
  "periodo_anterior": "2026-09-01/2026-09-30",
  "periodo_actual": "2026-10-01/2026-10-31",
  "periodos_cerrados": true,
  "ventas_anterior": 120000,
  "ventas_actual": 108000,
  "variacion_pct": -10,
  "fuente_datos": "demo.mart_ventas_mensuales",
  "calculado_en": "2026-11-02T07:00:00Z",
  "evidencias": [
    {
      "documento_id": "demo-incidencia-42",
      "fecha": "2026-10-15",
      "extracto": "Dos tiendas notificaron retrasos de entrega."
    }
  ]
}

Con ese contexto, una respuesta aceptable sería: «Las ventas netas pasaron de 120.000 a 108.000 euros, un descenso del 10 %. Existe una incidencia de entregas del 15 de octubre, pero falta evidencia para cuantificar su impacto o atribuirle la caída».

La aplicación podría mostrar el resultado de la consulta y la referencia a demo-incidencia-42 para revisarlos. Una respuesta que afirmase «las ventas cayeron por los retrasos» estaría excediendo la evidencia disponible. El campo periodos_cerrados tampoco acredita nada por sí solo: el pipeline debe comprobarlo contra el calendario de cierre y la cobertura de las cargas.

Qué comprobar en dbt antes de servir ese contexto

En este ejemplo, revisaríamos la unicidad de la combinación de mes y ámbito comercial, los identificadores obligatorios y las relaciones entre documentos y entidades. Los data tests de dbt permiten expresar comprobaciones sobre los modelos. También hacen falta reglas propias para detectar una moneda inesperada, un periodo incompleto o una carga ausente. Guía de data tests de dbt.

Documenta quién mantiene la definición de ventas y cómo se aprueban sus cambios. Conserva la fecha de cálculo, los filtros aplicados y la versión de la definición. Si una validación crítica falla, el flujo debe detener la respuesta o indicar que los datos están pendientes de revisión; incluir un aviso en una tabla no obliga al agente a respetarlo.

Permisos y documentos: dos controles que deben estar fuera del prompt

La recuperación debe filtrar los datos según la identidad del usuario antes de enviarlos al modelo. Un rol de servicio con acceso amplio no representa automáticamente los permisos de cada persona. Tampoco un campo como «confidencial» impide una lectura: las restricciones deben aplicarse en la base de datos y en la aplicación.

Los documentos recuperados son contenido de entrada. Pueden incluir errores o instrucciones maliciosas, por ejemplo una nota que pida ignorar las reglas y revelar otros registros. Mantén sus extractos separados de las instrucciones del sistema, limita las herramientas disponibles y controla las acciones en el código. Una frase en el prompt no sustituye estos controles.

Revisa además qué proveedor procesa los datos, qué se guarda en historiales y logs y cuánto tiempo se conserva. Entrega al modelo solo la información necesaria para la pregunta y evita registrar documentos sensibles completos para depurar una respuesta.

Cómo medir si mejora: preguntas reales y respuestas comprobables

Empieza con un conjunto pequeño de preguntas revisadas por negocio. Incluye una consulta numérica, una comparación temporal, una pregunta sin evidencia suficiente y una petición que el usuario no tenga permiso para resolver. Añade documentos desactualizados o contradictorios para comprobar cómo responde el sistema.

• Exactitud: compara importes y periodos con consultas de referencia.
• Trazabilidad: verifica que las fuentes existen y respaldan lo que la respuesta afirma.
• Límites: comprueba que solicita aclaraciones o reconoce la falta de evidencia cuando corresponde.
• Operación: mide latencia, coste por respuesta y coste de preparar y refrescar el contexto.

Compara variantes con las mismas preguntas, datos, permisos y modelo, repitiendo los casos. Cambiar simultáneamente el modelo, la recuperación y el resumen impide saber qué produjo la mejora. Guarda también ejemplos de fallos: una media favorable puede ocultar una respuesta inaceptable.

Por dónde empezar en tu empresa

Escoge una decisión concreta, como revisar las ventas mensuales de un canal. Acuerda una definición, prepara sus datos y reúne evidencia autorizada. Construye la recuperación y las validaciones alrededor de esa pregunta antes de ampliar el alcance.

Si quieres llevar ese contexto a una aplicación, puedes continuar con nuestra guía de Cortex Agent SDK con Python. Para coordinar tareas con IA, consulta el artículo sobre Airflow AI Provider 1.0.

En Nubita podemos ayudarte a revisar esas bases mediante nuestra consultoría de datos y a diseñar su integración en Nubita Data Platform. El primer entregable útil es una respuesta que puedas contrastar con tus datos y sus fuentes.

Fuentes revisadas el 2 de noviembre de 2026. El ejemplo es ilustrativo y no representa una implantación ni resultados medidos por Nubita.