El 21 de julio de 2026, CDO LATAM realizó el webinar “Más allá del RAG: Context Engineering para una IA que entiende el negocio”, con el auspicio de Bluetab. La conversación examinó por qué numerosas soluciones de inteligencia artificial generativa funcionan en ambientes controlados, pero pierden precisión, utilidad o confianza cuando deben operar a escala empresarial.
El encuentro reunió a líderes de datos, analítica e inteligencia artificial con experiencia en la implementación de soluciones dentro de organizaciones complejas. La discusión abordó las diferencias entre RAG y Context Engineering, el papel del conocimiento organizacional, la calidad de los datos, la participación del negocio, la vigencia del contexto y los requisitos para llevar un piloto a producción.
Moderadora:
- Nancy Cubillos, Asociada de CDO LATAM.
Panelistas:
- Nelson Felipe Medina Lalinde, Jefe de CRM y Fidelización (CDO) en Corferias, Generadores de Oportunidades y Progreso.
- Renato Chavez Girao, Executive COO para Perú y Colombia en Bluetab, an IBM Company.
- Aldo Valadez, Chief Data, Analytics, Automation & AI Officer en Sigma Foods.
RAG permite acceder a la información, pero no explica cómo funciona el negocio
Renato Chavez situó la evolución de la inteligencia artificial empresarial en varias etapas. Las primeras inquietudes estuvieron relacionadas con la eficiencia de los modelos, la seguridad de la información y la posibilidad de utilizar datos corporativos sin exponerlos. Una vez atendidos esos aspectos, las organizaciones comenzaron a plantearse una dificultad distinta: cómo lograr que los modelos comprendieran su información y su operación.
Las arquitecturas de generación aumentada por recuperación, conocidas como RAG, surgieron como una alternativa para conectar los modelos de lenguaje con documentos, archivos y otras fuentes corporativas. Esta arquitectura permite que una solución consulte información interna antes de elaborar una respuesta.
Sin embargo, acceder a documentos no equivale a comprender una organización. Los procesos empresariales también dependen de reglas, excepciones, prioridades, relaciones funcionales, criterios de decisión y flujos de trabajo que no siempre aparecen en una base de datos o un repositorio documental.
Renato definió el Context Engineering como una disciplina orientada a diseñar, construir y mantener el contexto que necesita una solución de inteligencia artificial para tomar decisiones relacionadas con el negocio. RAG y Context Engineering no fueron presentados como enfoques excluyentes, sino como capacidades complementarias.
Para explicar la diferencia, comparó la incorporación de una solución de IA con el ingreso de un analista financiero. Un profesional recién contratado puede leer manuales y documentos durante su proceso de incorporación, pero su conocimiento inicial no será equivalente al de alguien que lleva años dentro de la empresa. El segundo conoce las particularidades de los procesos, las excepciones, las personas involucradas y los criterios que la organización aplica en situaciones concretas.
El mismo problema aparece en la inteligencia artificial. Un modelo puede acceder a la documentación y ofrecer respuestas técnicamente correctas, pero todavía carecer del conocimiento necesario para actuar como un experto dentro de la organización.
El principal obstáculo no siempre es tecnológico
Aldo Valadez sostuvo que muchos de los problemas actuales no provienen de la capacidad de los modelos, sino de la forma en que las organizaciones gestionan su conocimiento. Las reglas de negocio suelen permanecer en la memoria de las personas y no siempre están documentadas en un formato que una solución de inteligencia artificial pueda utilizar.
La dificultad aumenta en compañías con presencia en varios países, múltiples unidades de negocio o diferentes líneas de productos. Una misma métrica puede tener definiciones o excepciones distintas según el mercado, el área o la operación que la utilice.
En estas condiciones, una demostración puede funcionar correctamente porque se construye sobre un conjunto limitado de datos y reglas. Cuando la solución pasa a producción, aparecen respuestas que pueden ser técnicamente consistentes, pero poco útiles para el negocio.
Aldo planteó dos preguntas que las organizaciones deberían resolver antes de desarrollar un producto analítico. La primera es si el negocio comprende sus propias reglas y las tiene documentadas. La segunda es si los datos necesarios existen y están preparados para alimentar la solución.
Renato compartió una experiencia relacionada con la modernización de procesos y sistemas heredados en una entidad financiera. El equipo comenzó por las tareas técnicas, como la conversión de código y el modelamiento, pero luego identificó que el mayor desafío estaba en comprender el proceso que debía transformarse.
Parte de la documentación estaba desactualizada, almacenada en ubicaciones incorrectas o guardada en correos personales. Durante las reuniones también aparecían reglas y excepciones que solo conocían determinados usuarios. El conocimiento existía, pero se encontraba disperso, sin estructura o dependía por completo del juicio de expertos.
El contexto convierte una respuesta genérica en una respuesta útil
Nelson Felipe Medina presentó un caso de uso de Corferias para explicar cómo el contexto modifica el alcance de una solución de inteligencia artificial.
La organización administra un portafolio de más de 65 ferias y eventos, con interacciones dirigidas a expositores y visitantes. Estas personas utilizan WhatsApp, chat, correo electrónico y telefonía para resolver preguntas relacionadas con cada feria.
Una solución que solo consulte información pública puede responder fechas, horarios, ubicaciones y otros datos generales. Su utilidad permanece limitada a información que el usuario también podría encontrar en los sitios oficiales.
Con una arquitectura RAG, reglas de negocio, gobierno de datos y conocimiento contextual, la solución puede ofrecer una respuesta más específica. Además de identificar la feria consultada, puede considerar el cargo de la persona, la empresa a la que pertenece, su sector y los productos que ofrece o busca.
Con estos elementos, la IA puede recomendar otras ferias relevantes dentro del portafolio o identificar expositores que respondan mejor a las necesidades de un visitante profesional. El contexto permite pasar de una consulta informativa a una interacción relacionada con el perfil y el objetivo de cada usuario.
El caso también mostró la necesidad de diseñar soluciones capaces de operar a gran escala. Corferias recibe más de dos millones de visitantes en sus diferentes eventos, por lo que el modelo debe mantener la calidad de las respuestas ante un volumen elevado de interacciones.
Tener más datos no garantiza mejores respuestas
Los panelistas coincidieron en que las empresas han invertido durante años en sistemas CRM, plataformas empresariales, data warehouses, data lakes y otras tecnologías para capturar y almacenar información. El desafío ya no se limita a disponer de grandes volúmenes de datos.
Felipe señaló que el valor depende de la capacidad de esos datos para producir contexto. Las organizaciones encuentran información fragmentada, distintas definiciones para un mismo concepto y criterios diferentes sobre las fuentes que deben utilizarse para responder una pregunta de negocio.
Una solución de IA puede procesar información incorrecta y generar una respuesta coherente con esa fuente. El problema, en ese caso, no se encuentra necesariamente en el modelo, sino en los datos que recibió.
Renato explicó que algunas organizaciones atribuyeron respuestas equivocadas a alucinaciones del modelo. Al revisar las fuentes, el equipo comprobó que la solución había respondido de acuerdo con la información disponible. Los datos corporativos eran los que contenían errores, duplicidades o versiones desactualizadas.
La confianza en la información requiere responsables definidos, criterios de calidad, metadatos, linaje y documentación funcional. También exige identificar cuáles son las fuentes oficiales y quién debe responder por su mantenimiento.
La inteligencia artificial puede apoyar el perfilamiento y la evaluación de la calidad de los datos, pero no sustituye la estructura de gobierno que determina cómo se definen, administran y actualizan.
El contexto también tiene fecha de caducidad
Aldo incorporó otra dificultad al análisis. Las reglas, definiciones y prioridades de una organización cambian, por lo que el contexto no puede considerarse un activo permanente una vez documentado.
Una definición válida hoy puede perder vigencia debido a cambios regulatorios, nuevas condiciones comerciales, modificaciones operativas o decisiones internas. Una solución que conserve reglas antiguas puede responder con seguridad y, al mismo tiempo, orientar una decisión equivocada.
Para reducir este riesgo, propuso mantener el contexto en una capa independiente de los programas, documentos estáticos, productos analíticos y repositorios de datos. Esta estructura puede adoptar la forma de una capa semántica, una ontología u otro mecanismo que conecte definiciones, relaciones y reglas con las distintas soluciones de la empresa.
El panel también examinó un modelo federado de gestión. Bajo este enfoque, una función central define estándares y estructuras comunes, mientras que cada área de negocio asume la responsabilidad de mantener actualizados sus datos, vocabulario y reglas.
El gobierno del contexto no se limita a identificar al propietario de un dato. También debe establecer fechas de revisión, mecanismos de actualización y criterios para determinar cuándo una definición dejó de ser válida.
Aldo propuso que cada iniciativa de inteligencia artificial evalúe al menos el dominio de negocio involucrado, el propietario del dato, las reglas de calidad aplicables, el diccionario de datos y el linaje de la información. Estos componentes reducen la posibilidad de que el modelo consuma definiciones antiguas o fuentes sin trazabilidad.
La gestión del conocimiento amplía el alcance del gobierno de datos
Renato advirtió que el contexto no está compuesto únicamente por datos. También incorpora conocimiento organizacional, procedimientos y flujos de trabajo.
Las empresas necesitan establecer cómo se capturará ese conocimiento, quién lo actualizará y qué mecanismos permitirán mantenerlo vigente. Depender de una persona que revise manualmente cada modificación puede convertirse en un nuevo cuello de botella.
Los procedimientos de actualización deben integrarse en los flujos de trabajo y, cuando sea posible, contar con mecanismos automáticos. La tecnología necesaria existe, pero su adopción requiere liderazgo y una cultura que reconozca el contexto como parte de la infraestructura empresarial de inteligencia artificial.
El modelo de lenguaje ya posee capacidades generales. Lo que desconoce es la forma particular en que opera cada organización. Construir, gobernar y mantener ese conocimiento representa uno de los principales trabajos internos para obtener respuestas confiables.
El negocio debe participar como codiseñador
Felipe y Aldo coincidieron en que las soluciones no pueden desarrollarse únicamente dentro de las áreas técnicas.
Felipe sostuvo que el equipo técnico puede asumir un papel importante en la organización y formalización de la documentación, pero debe hacerlo junto con las áreas funcionales. El negocio conoce los cambios del mercado, las particularidades del sector y la evolución de los usuarios que una solución debe atender.
Una herramienta puede contar con una arquitectura sólida y un desarrollo técnico correcto, pero fracasar si no responde al problema que motivó su creación. También puede perder vigencia si no incorpora nuevas fuentes, perfiles o condiciones que el negocio detecta durante la operación.
Aldo cuestionó la práctica de incorporar al negocio solo como validador final. Su participación debe comenzar antes de escribir código y abarcar la definición del vocabulario, las métricas, los responsables, las excepciones y los criterios que orientarán el comportamiento de la solución.
Cuando el equipo técnico intenta completar por su cuenta las reglas que el negocio no articuló, el producto hereda esa ambigüedad. La participación temprana también favorece la adopción, porque las áreas usuarias intervienen en las decisiones que determinan el resultado final.
Escalar un piloto exige industrializar el contexto
Los pilotos suelen desarrollarse en ambientes controlados, con un alcance limitado y supervisión cercana. En ese escenario, el contexto puede prepararse manualmente para cada caso.
Aldo explicó que este trabajo artesanal no puede reproducirse cuando una organización necesita atender decenas o cientos de casos de uso. La producción requiere estructuras capaces de reutilizar definiciones, reglas y relaciones en diferentes soluciones.
Las capas semánticas y las ontologías pueden permitir esa reutilización. En lugar de construir el contexto desde cero para cada iniciativa, la empresa mantiene componentes comunes que pueden ser consumidos por agentes, modelos, tableros y otros productos analíticos.
Felipe añadió que la industrialización también requiere gobierno de datos, seguridad, monitoreo continuo y controles permanentes de calidad. Una solución empresarial no puede depender solo del desempeño inicial del modelo.
Renato recomendó iniciar con talleres que permitan identificar los casos de uso de las distintas áreas, compararlos y seleccionar aquellos que pueden construir una base para futuras implementaciones. El objetivo no debe ser ejecutar simultáneamente todas las ideas disponibles, sino establecer una secuencia que permita aprender y ampliar capacidades.
Para representar los componentes de una solución, utilizó la analogía de un viaje. El modelo de lenguaje funciona como el motor del vehículo, los datos como el combustible y RAG como el sistema que proporciona una ruta. El Context Engineering incorpora las condiciones que cambian durante el trayecto, como restricciones, tráfico o clima. El destino representa el objetivo de negocio.
La solución solo puede evaluarse en función de su capacidad para llegar a ese objetivo.
El impacto operativo debe orientar la medición
El panel señaló que cada caso de uso debe comenzar con indicadores definidos. Estos pueden relacionarse con ventas, ahorro, productividad, eficiencia u otros resultados asociados con el problema seleccionado.
La evaluación económica no debe considerar únicamente los ahorros previstos. También debe incluir el costo de los modelos de lenguaje, la tokenización, la infraestructura y la operación de los agentes o componentes que forman la solución.
La calidad de una respuesta es relevante, pero no determina por sí sola el éxito de una iniciativa. Una solución puede responder correctamente y no generar un cambio significativo en la operación.
Renato propuso medir el resultado según el impacto en el negocio y su relación con los indicadores establecidos antes de iniciar la implementación. Esta comparación permite determinar si el contexto incorporado contribuye realmente al propósito de la solución.
La personalización también requiere protección de datos
Durante las preguntas del público, la conversación abordó el uso de datos personales para construir respuestas más contextualizadas.
Felipe explicó que una organización necesita contar con las autorizaciones correspondientes para utilizar información personal y realizar acciones dirigidas a cada usuario. En el caso de Corferias, disponer de esa autorización permite pasar del análisis interno a comunicaciones segmentadas relacionadas con las necesidades de visitantes o expositores.
Sin autorización, la información puede permanecer restringida a determinados fines analíticos y no necesariamente puede utilizarse para establecer interacciones proactivas. La construcción de contexto debe considerar, por tanto, las condiciones bajo las cuales los datos fueron obtenidos y pueden ser utilizados.
Cómo comenzar una iniciativa de Context Engineering
Las recomendaciones finales del panel convergieron en varios frentes. Las organizaciones deben ordenar y gobernar su información, documentar el conocimiento que permanece en las personas e involucrar al negocio durante el diseño.
También deben seleccionar casos de uso concretos, definir los indicadores antes de desarrollar la solución y establecer qué iniciativas no se ejecutarán. La disponibilidad de recursos, tiempo y presupuesto obliga a priorizar los problemas con mayor impacto.
El proceso no requiere esperar a que cada componente alcance un estado perfecto. Los equipos pueden avanzar mediante pruebas controladas y ciclos de retroalimentación, siempre que mantengan criterios de calidad, seguridad y gobierno.
La preparación de una empresa para utilizar inteligencia artificial no depende solo del tamaño o la capacidad de sus modelos. También depende de qué tan estructurado, actualizado y gobernado se encuentra el conocimiento que esos modelos utilizarán.
Conclusión
El Context Engineering amplía el alcance de RAG al incorporar reglas, procesos, excepciones, vocabulario y conocimiento organizacional. Su desarrollo requiere datos confiables, participación temprana del negocio y mecanismos que mantengan el contexto vigente.
El paso de un piloto a una solución empresarial exige industrializar y reutilizar ese contexto, controlar su calidad y medir el resultado según el impacto operativo. La capacidad del modelo importa, pero su utilidad depende del conocimiento del negocio que la organización pueda estructurar y gobernar.
Recurso complementario
Aldo Valadez compartió con CDO LATAM la presentación “IA Empresarial: El Contexto como Ventaja Competitiva”, que sintetiza los principales temas abordados durante el webinar.
El documento reúne las diferencias entre RAG y Context Engineering, los obstáculos que enfrentan las organizaciones para contextualizar sus soluciones de inteligencia artificial, el caso presentado por Corferias y las recomendaciones para pasar de un piloto a una implementación empresarial.
