La propuesta de Atlan para crear valor de IA con contexto empresarial desplaza la atención más allá de los modelos

Atlan cuestiona el enfoque centrado en los modelos para la IA empresarial y sostiene que incluso los sistemas capaces carecen de la comprensión del negocio necesaria para realizar trabajo útil. Crear valor de IA con contexto empresarial, tema de un artículo de MIT Technology Review Insights del 28 de octubre, somete esa afirmación a escrutinio. La cuestión es si las organizaciones necesitan otra capa de infraestructura, una mejor gestión del conocimiento existente o ambas cosas.

El argumento llega con un contexto comercial propio. El artículo procede de la división de contenido personalizado de MIT Technology Review, no de su redacción editorial. Los materiales de la conferencia de Atlan identifican la investigación asociada como producida junto con la empresa. Esa relación importa al evaluar un diagnóstico que también respalda el posicionamiento de producto del proveedor.

Work IQ de Microsoft ofrece una comparación útil: otro proveedor está organizando su estrategia de IA empresarial en torno al contexto de negocio. La tensión central va más allá de la competencia entre proveedores. Las organizaciones quieren una IA capaz de realizar trabajo, pero sus definiciones, permisos y reglas operativas suelen requerir interpretación humana. Comprar acceso a un modelo no resuelve esas cuestiones.

Crear valor de IA con contexto empresarial va más allá del modelo

El análisis sobre contexto empresarial del 28 de octubre presenta un problema conocido de implementación a través de la perspectiva preferida de Atlan. Las herramientas de IA pueden responder con rapidez mientras malinterpretan el negocio al que sirven. La cofundadora de Atlan, Prukalpa Sankar, sostiene que la infraestructura de contexto puede ayudar a cerrar esa brecha.

Una capa de contexto es una infraestructura que proporciona a los sistemas de IA definiciones de negocio, relaciones, políticas y otra información necesaria para interpretar los datos de la empresa. El concepto importa porque encontrar información y comprender su significado empresarial son tareas distintas. Un documento puede contener una respuesta sin establecer si esa respuesta sigue siendo autorizada.

La novedad es un argumento comercial más explícito sobre el origen del valor de la IA empresarial, no un avance técnico recién verificado.

Esta distinción mantiene la noticia en proporción. El artículo no establece que la infraestructura de contexto, por sí sola, genere mejores retornos financieros. Propone una explicación para implementaciones decepcionantes y una dirección para abordarlas. Los compradores deberían evaluar la explicación por separado de cualquier implementación concreta.

Pensemos en un flujo de trabajo de ventas ilustrativo. Un asistente encuentra un registro de cliente, resume conversaciones recientes y redacta una recomendación de renovación. Cada documento recuperado podría ser preciso de forma individual. Aun así, la recomendación puede fallar si el asistente confunde la entidad de facturación con su empresa matriz o pasa por alto una excepción aprobada.

Un modelo mejor podría reconocer la ambigüedad y plantear una pregunta útil. Una definición empresarial mantenida podría resolver la ambigüedad antes de que comience la generación. Estos enfoques se complementan, pero abordan partes diferentes del fallo. Tratar cada error como un problema del modelo oculta esa distinción.

Por tanto, crear valor de IA con contexto empresarial cambia la conversación de compra. En lugar de preguntar únicamente qué sistema produce la respuesta más sólida, los compradores deben preguntarse qué hace válida una respuesta dentro de su organización. Eso incluye quién aprobó la regla subyacente y cuándo cambió por última vez.

La relación de publicación también merece atención. El evento de investigación sobre contexto de Atlan promovió el acceso anticipado a investigación producida en asociación con la empresa. Esto respalda tratar el argumento como una contribución al debate respaldada por un proveedor. No justifica desestimar el problema subyacente.

La implicación práctica es más limitada que la amplia narrativa comercial. El contexto es una fuente creíble de fallos de IA empresarial, pero su importancia debe establecerse para cada flujo de trabajo. Las organizaciones siguen necesitando evidencia que conecte la intervención propuesta con una mejora medible. Sin esa conexión, el contexto se convierte en otra explicación difícil de comprobar.

Los responsables de negocio heredan el problema de fiabilidad de la IA

El argumento del contexto presiona tanto a los responsables de negocio como a los equipos tecnológicos. Si un asistente malinterpreta una política aprobada, cambiar el modelo podría ayudar. Si los departamentos discrepan sobre la política misma, la organización debe resolver ese desacuerdo antes de que el software pueda aplicarla de manera consistente.

La IA empresarial convierte una propiedad descuidada del conocimiento en un problema operativo.

Un desarrollador de IA puede conectar un repositorio de documentos sin tener autoridad para decidir qué política sustituye a otra. Un equipo de seguridad puede aplicar restricciones de acceso sin decidir cómo define finanzas a un cliente. Estas responsabilidades se cruzan, pero no pertenecen a la misma persona.

Esto crea una carga de implementación distinta a la de instalar una interfaz conversacional. Alguien debe identificar fuentes autorizadas, asignar responsables, documentar excepciones y mantener esas decisiones. El trabajo puede revelar desacuerdos que los empleados antes resolvían mediante conversaciones informales. La automatización hace más difícil dejar esos desacuerdos sin resolver.

Para los responsables financieros, la presión se refiere a la coherencia. Un asistente que responde a una pregunta sobre ingresos necesita la definición contable adecuada, el período de reporte y el alcance organizativo. Una explicación fluida no compensa la elección de la métrica equivocada. El responsable de negocio debe hacer que la interpretación prevista esté disponible y pueda revisarse.

Para los responsables de servicio, la presión se refiere a la aplicabilidad. Un agente, es decir, un sistema de IA que selecciona pasos o utiliza herramientas para completar trabajo, necesita circunstancias relevantes del cliente. Una política de reembolso válida puede variar según el contrato o la región. Recuperar la política general es solo una parte de la decisión.

Estos ejemplos son ilustrativos, no resultados de clientes reportados. Muestran por qué la propiedad del contexto se vuelve decisiva cuando el software pasa de redactar lenguaje a recomendar acciones. Un resumen equivocado genera trabajo de corrección. Una acción equivocada también puede crear una obligación que otro equipo debe deshacer.

Los equipos de compras afrontan un desafío relacionado. Una plataforma de contexto puede prometer definiciones comunes, pero el contrato no puede garantizar que los departamentos coincidan en ellas. Los compradores deben distinguir las responsabilidades del proveedor de las responsabilidades organizativas. De lo contrario, una compra de infraestructura puede ocultar una decisión operativa sin terminar.

Los trabajadores del conocimiento experimentan el mismo problema a menor escala. Un archivo consultable ayuda a localizar material, mientras que una base de conocimiento autorizada establece qué material debe orientar el trabajo. La distinción entre conocimiento personal y de equipo se vuelve relevante cuando el recuerdo individual alimenta decisiones compartidas.

La respuesta a corto plazo debe seguir el fallo que se aborda. La falta de material fuente exige una mejor cobertura. Las definiciones conflictivas requieren propiedad y resolución. El razonamiento incorrecto exige cambios en el modelo o la aplicación. Combinar estas categorías en una única puntuación de precisión puede ocultar dónde se necesita intervenir.

Con el tiempo, la presión se desplaza hacia el mantenimiento. El contexto de negocio cambia cuando cambian los productos, contratos, equipos y políticas. Una implementación que funciona bien en el lanzamiento puede volverse poco fiable sin ninguna actualización del modelo. Por tanto, el argumento del contexto también es una afirmación sobre la responsabilidad operativa continua.

Microsoft muestra por qué el contexto se está convirtiendo en una cuestión de plataforma

Microsoft ofrece una comparación concreta porque también describe el contexto empresarial como infraestructura compartida. En su explicación del 11 de junio sobre el uso interno de Work IQ, la empresa explica cómo la información organizativa respalda respuestas de IA más relevantes. Presenta el contexto como parte del entorno que rodea a los asistentes.

Microsoft afirma que Work IQ se nutre de señales del entorno de trabajo y respeta los permisos existentes. Sus ejemplos internos incluyen conectar información de reuniones con participantes y aplicar circunstancias de empleados a orientaciones. Estos son ejemplos reportados por la empresa, no mediciones independientes de retornos empresariales. Sin embargo, muestran a un proveedor abordando el mismo problema general.

La cuestión competitiva es dónde debe residir la comprensión del negocio y hasta qué punto puede reutilizarse.

El enfoque de inteligencia en el entorno de trabajo de Microsoft describe un contexto que se desarrolla dentro de su entorno laboral. El argumento de Atlan se centra en proporcionar comprensión del negocio entre sistemas. Estas posiciones generan preguntas distintas para los compradores, incluso cuando ambos proveedores emplean un lenguaje similar.

Para una organización concentrada en un entorno de software concreto, el contexto incorporado allí puede ofrecer un punto de partida natural. Los documentos, identidades y registros de colaboración existentes ya están cerca. El comprador aún debe establecer qué fuentes están cubiertas y si la interpretación resultante se aplica más allá de ese entorno.

Para una organización que utiliza varios sistemas empresariales, la reutilización cobra más importancia. Una definición mantenida para un asistente financiero no debería divergir silenciosamente de la definición utilizada por un asistente de operaciones. El contexto compartido promete reducir esa duplicación. Que lo consiga depende de los detalles de integración y gobernanza.

No se trata de una simple competencia entre arquitectura centralizada y distribuida. Una arquitectura es la disposición de los componentes y sus responsabilidades. Un servicio central puede distribuir definiciones desactualizadas, mientras que un contexto específico de una aplicación puede seguir siendo preciso dentro de un alcance limitado. La ubicación por sí sola no determina la calidad.

La comparación más útil se refiere al cambio. Cuando cambia una definición, ¿qué aplicaciones reciben la actualización? Cuando se revoca el acceso, ¿qué representaciones almacenadas dejan de exponer la información? Cuando se cuestiona una respuesta, ¿pueden los revisores reconstruir la fuente y la regla utilizadas? Estas preguntas conectan el diseño de la plataforma con las consecuencias operativas.

La portabilidad también merece atención. Los compradores deberían preguntar si las definiciones aprobadas pueden trasladarse entre herramientas sin perder propiedad, historial de versiones o restricciones de acceso. Exportar texto es más fácil que preservar su autoridad. Una migración que conserva las palabras pero pierde la aplicabilidad puede recrear el problema original.

Por tanto, la comparación entre proveedores respalda una conclusión más amplia sin demostrar que el enfoque de ninguno sea superior. El contexto se está convirtiendo en una responsabilidad de plataforma porque varias aplicaciones necesitan la misma comprensión del negocio. Esto crea una oportunidad para infraestructura compartida, junto con el riesgo de que muchas aplicaciones dependan de un error común.

Para los compradores, la respuesta útil es examinar un flujo de trabajo que cruce una frontera organizativa real. Una demostración limitada a una colección ordenada de documentos deja sin respuesta la cuestión central. La evidencia relevante es si el contexto se mantiene coherente cuando la información se mueve entre departamentos, aplicaciones y responsables de decisión.

La evidencia sobre recuperación respalda una afirmación más limitada

La generación aumentada por recuperación, o RAG, recupera información relevante y la proporciona a un modelo antes de que este responda. Es una forma consolidada de conectar las respuestas generadas con conocimiento externo. Sus limitaciones ayudan a explicar por qué el argumento del contexto empresarial atrae atención.

La investigación de Anthropic de septiembre de 2024 ofrece un ejemplo técnico. Su método de Contextual Retrieval añade información explicativa a fragmentos de documentos antes de indexarlos. El objetivo es preservar el significado que puede perderse cuando un pasaje se separa de su documento original.

Anthropic informó de una reducción del 49% en los fallos de recuperación al combinar sus técnicas contextuales, y de una reducción del 67% al añadir reranking. El reranking es un segundo paso de selección que reordena el material recuperado según su relevancia. Estos fueron resultados de las evaluaciones de la empresa, no mediciones de retornos financieros empresariales.

Una mejor recuperación respalda el argumento del contexto, pero no demuestra que sea necesaria una plataforma integral de contexto empresarial.

La investigación sobre recuperación contextual aborda un fallo específico: un sistema pasa por alto información relevante porque un fragmento carece de significado circundante. Esto es más limitado que resolver políticas corporativas contradictorias. También es más limitado que determinar si un usuario tiene autoridad para realizar una acción.

La distinción importa para las decisiones de compra. Si un asistente de soporte no encuentra respuestas porque los fragmentos de documentos carecen de detalles identificativos, conviene investigar cambios en la recuperación. Si encuentra el pasaje correcto pero lo aplica de forma incorrecta, el fallo ocurre en otro punto. Una propuesta amplia de infraestructura debería explicar qué fallo aborda.

Un ejemplo ilustrativo de contrato deja más clara la separación. Un pasaje indica que un cliente cumple los requisitos para una excepción, pero el nombre del cliente aparece en una página anterior. Preservar esa relación puede mejorar la recuperación. Determinar si la excepción sigue vigente requiere información adicional sobre fechas, enmiendas y autoridad.

Por tanto, un sistema puede recuperar información con precisión y aun así producir una recomendación empresarial equivocada. A la inversa, un flujo de trabajo con fuentes limitadas y mantenidas podría funcionar adecuadamente sin un extenso servicio de contexto compartido. La intervención apropiada depende de la tarea real, sus requisitos de información y las consecuencias de sus fallos.

La creación de valor de IA con contexto empresarial debería evaluarse mediante esta cadena de dependencias. La cobertura de las fuentes afecta a lo que el sistema puede encontrar. La interpretación de las fuentes afecta a lo que comprende. Las reglas de decisión afectan a lo que recomienda. Los controles de acción afectan a lo que puede ejecutar. La mejora en una parte no demuestra automáticamente una mejora en todo el proceso.

Este razonamiento también cambia cómo deben interpretarse las demostraciones. Una respuesta correcta prueba que una configuración concreta resolvió una pregunta concreta bajo condiciones concretas. No demuestra fiabilidad general en todos los departamentos. Los compradores necesitan evidencia que incluya entradas ambiguas, políticas modificadas y fuentes contradictorias.

El argumento técnico más sólido identificará el fallo original, la intervención de contexto y la diferencia resultante. Mantener comparables el modelo y la tarea ayuda a aislar qué cambió. Informar por separado del éxito de recuperación y de la precisión de las decisiones facilita interpretar el resultado y evita que una mejora limitada se convierta en una afirmación más amplia.

Más contexto puede propagar más lejos una respuesta equivocada

El argumento escéptico parte de un problema sencillo: el contexto empresarial puede ser incorrecto. Una definición compartida podría estar desactualizada, ser incompleta o estar en disputa. Proporcionarla de manera consistente puede hacer que las respuestas coincidan sin dejar de ser incorrectas. La coincidencia es evidencia útil de consistencia, pero no evidencia suficiente de verdad.

Una capa de contexto puede distribuir autoridad sin demostrar que dicha autoridad esté justificada.

Esto importa cuando las organizaciones convierten conocimiento informal en reglas mantenidas. Los empleados con experiencia a veces saben cuándo un proceso documentado no se ajusta a una situación. Codificar ese criterio exige decidir qué excepciones son legítimas. Extraer automáticamente una afirmación de una conversación no resuelve si debería convertirse en política.

Un participante de una reunión podría describir una solución temporal. Otro empleado podría repetir una práctica desactualizada. Un documento de proyecto podría registrar una propuesta abandonada. Cada fuente aporta información, pero cada una conlleva un grado distinto de autoridad. Tratarlas como equivalentes crea un problema de gobernanza antes de que comience la generación.

También existe una limitación a nivel de modelo. El perfil de riesgos de IA generativa de NIST describe la confabulación, es decir, contenido falso o erróneo generado con seguridad, como un riesgo característico. También señala que las explicaciones y citas generadas pueden inducir a error a los usuarios. El material fuente relevante no elimina la necesidad de evaluar las respuestas.

El análisis de NIST respalda una interpretación cautelosa de la tesis del contexto. Una mejor información puede abordar el conocimiento faltante sin garantizar un razonamiento correcto. Un sistema podría aplicar mal una regla válida o exagerar una inferencia incierta. La calidad del contexto y la fiabilidad de las respuestas requieren un escrutinio relacionado, pero distinto.

Los permisos crean otro punto de presión. La capacidad de un empleado para leer un documento no autoriza necesariamente a un sistema automatizado a actuar sobre su contenido. Un servicio de contexto necesita una relación clara con los controles que rigen las acciones posteriores. De lo contrario, información precisa puede respaldar una decisión no autorizada.

El argumento financiero también sigue siendo incierto. Mantener definiciones, resolver disputas, comprobar permisos y revisar fallos consume tiempo del personal. Parte de ese trabajo puede mejorar procesos existentes más allá de la IA. Los compradores deberían tenerlo en cuenta al evaluar la economía de la implementación.

Una organización podría lograr mejores respuestas mientras aumenta el trabajo total necesario para producirlas. Otra podría reducir lo suficiente el esfuerzo de revisión como para justificar un mantenimiento considerable. La comparación significativa incluye todo el flujo de trabajo, en lugar de la velocidad visible de generación. Este es un requisito analítico, no un resultado informado por el artículo fuente.

Crear valor de IA con contexto empresarial también exige aceptar límites. Cuando un conflicto de políticas sigue sin resolverse, un asistente útil debería exponerlo. Cuando la autoridad no está clara, debería derivar la decisión de manera adecuada. Un sistema que siempre produce una respuesta segura puede ocultar precisamente la incertidumbre organizativa que la infraestructura de contexto debería revelar.

Por tanto, la posición escéptica no exige rechazar la inversión en contexto. Exige una afirmación más específica sobre lo que dicha inversión cambia. Un proveedor debería identificar qué errores se vuelven menos frecuentes, qué responsabilidades siguen correspondiendo al cliente y qué modos de fallo persisten. Eso hace que la propuesta sea comprobable.

La próxima evidencia debería conectar el contexto con el trabajo completado

Durante los próximos meses, las señales más útiles se referirán a evidencia de implementación, más que a nuevo vocabulario. El debate de octubre establece una proposición clara: la comprensión empresarial merece mayor atención junto con la capacidad del modelo. El siguiente paso es determinar dónde esa proposición produce beneficios medibles.

La tesis del contexto se fortalece cuando el conocimiento empresarial mantenido mejora el trabajo completado en condiciones cambiantes.

La primera señal es una comparación documentada dentro de un flujo de trabajo real. Los compradores deberían buscar resultados que muestren qué ocurrió antes y después de una intervención de contexto definida. La comparación debería incluir errores de fuente, errores de decisión, correcciones humanas y tareas completadas. Un resultado que aísle la mejora reforzaría el argumento.

Una demostración que ofrezca solo respuestas exitosas seleccionadas dejaría intacta la incertidumbre central. También lo haría una comparación que cambie simultáneamente el modelo, la interfaz, la colección de fuentes y el proceso de revisión. Tales cambios podrían mejorar el producto, pero harían difícil separar la contribución del contexto empresarial.

La siguiente señal es un comportamiento fiable después de un cambio empresarial. Una política revisada, un permiso revocado o un cliente renombrado crean un punto de observación útil. ¿Adopta el sistema el cambio en las aplicaciones afectadas? ¿Conserva suficiente historial para explicar respuestas anteriores? Un comportamiento consistente respaldaría el argumento a favor de una infraestructura compartida.

Las contradicciones persistentes debilitarían ese argumento. Si cada aplicación sigue necesitando reparación manual, la capa común propuesta no ha eliminado el mantenimiento duplicado. Si la información desactualizada sobrevive en almacenes derivados, la organización necesita entender cómo se propagan las correcciones. La calidad de la configuración inicial no puede responder a esas preguntas.

La señal final es la carga operativa total. Las organizaciones deberían examinar si los revisores dedican menos tiempo a corregir resultados después de considerar el mantenimiento del contexto. También deberían seguir si los casos no resueltos llegan a las personas adecuadas. Una reducción del trabajo de revisión visible significa poco si el trabajo oculto de preparación crece más rápido.

Estas señales no dependen de que gane un proveedor concreto. Microsoft, Atlan y los desarrolladores de aplicaciones pueden aportar evidencia mediante enfoques distintos. La distinción útil está entre las afirmaciones sobre capacidades disponibles y las observaciones sobre uso sostenido. Los compradores necesitan ambas, pero no deberían confundirlas.

Para los trabajadores del conocimiento, la relevancia inmediata es práctica. Un asistente que sabe dónde reside la información puede ahorrar tiempo de búsqueda. Un asistente que entiende qué información es aplicable puede respaldar una decisión. El valor de esa comprensión adicional depende de que los usuarios puedan inspeccionarla, cuestionarla y mantenerla.

Empiece con un flujo de trabajo en el que una respuesta incorrecta genere retrabajo identificable. Revise los fallos con las personas responsables de la política subyacente, en lugar de tratar cada corrección como un problema de prompting. Separe la información faltante de las definiciones contradictorias, los errores de razonamiento y las acciones inapropiadas. Después, examine si la inversión de contexto propuesta aborda esos fallos específicos. Para el trabajo individual, un sistema de conocimiento personal mantenido puede ayudar a organizar material relevante, mientras que las decisiones compartidas siguen requiriendo autoridad compartida. Crear valor de IA con contexto empresarial se convierte en una propuesta creíble cuando esa distinción resiste la implementación. Pida al próximo proveedor que muestre cómo su sistema gestiona una regla modificada, una fuente en disputa y una decisión que debería dejar sin resolver.