Sin embargo, aunque muchas personas han aprovechado la investigación profunda en un contexto individual —para buscar y sintetizar información en línea—, pocas se han beneficiado de ella en un contexto empresarial. No es porque no resulte útil —todo lo contrario—, sino por preocupaciones más amplias sobre la confiabilidad, las fuentes de datos dispares o la capacidad del modelo para procesar grandes volúmenes de contexto, como cantidades enormes de archivos de distintos tipos.
Nuestra experiencia creando herramientas empresariales de investigación profunda durante los últimos 12 meses demuestra que una ingeniería cuidadosa permite mitigar cada vez más esas preocupaciones. En este blog analizamos los principales obstáculos para crear aplicaciones empresariales eficaces de investigación profunda, cómo los superaríamos y cómo creemos que evolucionará el sector durante 2026.
El límite de ejecución aumentó drásticamente. La llegada de gpt-5 en agosto de 2025 marcó un punto de inflexión para la IA empresarial. En nuestros sistemas de producción, incluida una plataforma de descubrimiento de dianas terapéuticas para una de las farmacéuticas más grandes del mundo, vimos que las alucinaciones de fuentes cayeron del 3-4 % a prácticamente cero. Luego, en diciembre, gpt-5.2 amplió aún más la longitud efectiva del contexto. El resultado práctico: ahora podemos pasar de cientos a miles de fuentes por ejecución de investigación sin sacrificar la confiabilidad. El cuello de botella volvió a estar donde corresponde: en sus datos, sus evaluaciones y el diseño de su programa, no en la capacidad del modelo.
Estrategia de datos: accesibles es mejor que unificados. Es comprensible que se tienda a tratar la IA empresarial como un problema de integración de datos, pero suele ser contraproducente. La unificación total es lenta, genera disputas internas y obliga a comprometerse antes de saber qué preguntas importan realmente. La opción pragmática en 2026 es una conectividad dispersa. Haga que los datos sean accesibles mediante anclas de alta señal —especificaciones, políticas, SKU y cláusulas contractuales— en lugar de esperar años para unificarlo todo. Los modelos de vanguardia ahora pueden hacer “uniones flexibles” entre sistemas durante la inferencia y vincular términos relacionados sin mapeos formales. Así conserva la rapidez de implementación y la flexibilidad para agregar fuentes más adelante.
La orientación evita los desvíos. Los datos empresariales no son la web. Son dispersos, están llenos de convenciones locales y, a menudo, existe exactamente una fuente correcta para un dato determinado. Sin orientación, los modelos tienden a encadenar consultas interminables para encontrar una fuente más, consumiendo tiempo y agotando la paciencia del usuario. Una capa semántica ligera —mapas hash, búsquedas de entidades y grafos simples de relaciones— ofrece al sistema vías rápidas y económicas para llegar con eficiencia al contexto correcto. Piense en los consejos que un colega experimentado le da a alguien nuevo: “guarda estos sitios en favoritos; si tienes problemas con AWS, habla con Ross”. No tiene que ser complicado. Solo tiene que ayudar al sistema a encontrar rápidamente lo que necesita.
Mecánicas (se ejecutan en cada consulta): calidad de las citas, uso correcto de herramientas, latencia y costo. Son sus salvaguardas: rutinarias, pero esenciales.
Analíticas (se ejecutan periódicamente): ¿el sistema elige las herramientas correctas, sigue líneas de investigación sensatas, selecciona fuentes confiables y sabe cuándo detenerse? Normalmente se califican con un LLM como juez y ejemplos etiquetados.
De usuario (continuas): tasas de finalización de tareas, comentarios cualitativos de usuarios avanzados y análisis de uso. La prueba definitiva. ¿Creamos algo que las personas consideran útil?
El ROI proviene de los problemas difíciles, no de los seguros. Tras los informes que afirman que la mayoría de los proyectos empresariales de IA no logran ROI, se agotó la tolerancia hacia las demostraciones impresionantes que nunca se implementan. Los ejecutivos quieren pruebas, y las quieren pronto. Paradójicamente, esa presión puede llevar a los equipos a tomar decisiones equivocadas. La tentación es comenzar con tareas de bajo riesgo porque son fáciles de implementar y difícilmente generarán resistencia. Pero estos casos de uso rara vez producen un impacto suficiente para justificar una inversión continua. Los sistemas empresariales de investigación profunda están bien posicionados para demostrar valor porque abordan trabajos que ya son costosos: flujos complejos y críticos donde el costo de mantener el statu quo es evidente. Los casos de uso más sólidos que hemos visto incluyen la generación de RFP y propuestas, el análisis del panorama científico y la investigación de inversiones: ámbitos donde el impacto se mide en tasas de éxito, rutas más rápidas hacia los ensayos y rapidez para alcanzar una convicción, no solo en horas ahorradas.
El cambio en la UX: de conversar a delegar, y de respuestas a entregables. Creemos que este será uno de los cambios en la experiencia del usuario que definirán 2026. Al observar las implementaciones con mayor adopción reciente, destacan un par de aspectos. A medida que aumentó la confiabilidad de estos sistemas, los usuarios comenzaron a tratarlos menos como chatbots a los que consultar y más como analistas en quienes delegar. Dos factores lo hacen posible: permitir que los equipos personalicen plantillas y criterios de detención según sus flujos específicos, y que exporten directamente al formato que realmente necesitan —un memorando, una presentación, un informe, etc.—, en vez de pedirles que armen un entregable final a partir de un chat. Cuando ambos factores están presentes, el sistema deja de ser una herramienta de consulta y se convierte en la forma de hacer el trabajo.
El año pasado escribimos sobre llevar la investigación profunda a las empresas. Tomamos el paradigma de investigación profunda centrado en la web, popularizado inicialmente por OpenAI, y lo ampliamos a las fuentes de datos privadas de las empresas sin perder la procedencia ni el control. También señalamos que los sistemas de investigación profunda no debían considerarse una ruptura con los sistemas RAG más clásicos, sino una evolución de ellos.
De cara a 2026, lo que cambió no es tanto la idea de la investigación profunda como el límite de lo que puede ejecutarse.
Cuando empezamos a crear estos sistemas a principios de 2025, los modelos de vanguardia incluían o1, gpt-4o y claude-3.5-sonnet —realmente hemos avanzado mucho en solo 12 meses—, y modelos como o3 y gemini-2.5-pro impulsaron grandes avances durante los primeros meses del año. Fueron excelentes para su momento y permitían crear aplicaciones robustas de investigación profunda, hasta cierto punto. Ese punto solía situarse en unos pocos cientos de fuentes. Después había que depurar el contexto de manera bastante agresiva o pagar el precio con una respuesta que perdía información, incumplía las instrucciones o directamente alucinaba.
Si ha creado estos sistemas, reconocerá algunos de estos tipos de fallas.
Para ilustrarlo: a mediados de 2025 comenzamos a crear una solución empresarial de investigación profunda con una de las farmacéuticas más grandes del mundo. Es un sistema para acelerar el descubrimiento de dianas terapéuticas, proceso en el que se buscan genes, hormonas u otros elementos del cuerpo humano sobre los que se pueda actuar para tratar una afección. En ese momento, el modelo más potente disponible era o3. Aunque ofrecía un rendimiento sólido, el 3-4 % de las respuestas generadas por este modelo contenía fuentes que no se le habían proporcionado mediante llamadas a herramientas desde las fuentes de datos privadas del cliente. Mitigamos el problema con comprobaciones posteriores de citas, que marcaban las secciones de las respuestas que no estaban respaldadas por el contexto proporcionado. Esto funcionó bien para generar confianza entre las partes interesadas durante la etapa inicial de prueba de concepto del proyecto y nos ayudó a avanzar con rapidez. Sin embargo, seguimos esforzándonos por reducir esos errores, mitigar las limitaciones de los modelos y atender las solicitudes de las partes interesadas de agregar más fuentes al sistema.
Un punto de inflexión clave para crear soluciones de vanguardia de investigación profunda —y soluciones con agentes en general— llegó con la aparición de gpt-5 en agosto. Al cambiar de o3 a gpt-5, nuestras evaluaciones mostraron que la tasa de alucinación de fuentes cayó inmediatamente al 0 %.
Para precisar esta métrica: registra estrictamente si el modelo cita un ID de documento o una URL que no estaba presente en el contexto recuperado. En la era de o3 —y antes—, los modelos a veces inventaban nombres plausibles de archivos o artículos para llenar vacíos de conocimiento. gpt-5 nos permitió eliminar prácticamente este problema específico.
Cabe señalar que esto es distinto de los errores de fidelidad —citar el documento correcto, pero interpretar mal el texto—, que siguen siendo un desafío que gestionamos mediante las comprobaciones posteriores mencionadas antes.
Esto abrió enormes posibilidades. A partir de entonces, comenzamos a probar el sistema para determinar hasta dónde podíamos llevarlo con la nueva generación de modelos. Descubrimos que podíamos multiplicar aproximadamente por diez el número de fuentes consideradas en una ejecución de investigación profunda —hasta unas 3000-5000—. El límite final no fue un deterioro del seguimiento de instrucciones, sino el rendimiento con contextos largos: la longitud efectiva del contexto de los modelos suele ser mucho menor que la anunciada, sobre todo con datos farmacéuticos densos.
Esta restricción se alivió parcialmente con el lanzamiento de gpt-5.2 a mediados de diciembre. Nuestros parámetros internos para contextos largos indicaron una mejora considerable del rendimiento efectivo con contextos extensos, lo que nos permitió llevar aún más lejos nuestros sistemas de vanguardia de investigación profunda. Esto resultó útil porque nos permitió aumentar la cantidad de tokens que pueden enviarse directamente al modelo que genera el resultado para el usuario y, así, ofrecer una respuesta más completa. Aun así, nos gustaría que la longitud efectiva del contexto de los modelos de vanguardia siga aumentando durante 2026.
Ante estos avances en la capacidad bruta de los modelos, los cuellos de botella para crear sistemas eficaces de investigación profunda han vuelto, en muchos sentidos, al lugar donde siempre debieron estar: sus datos, sus evaluaciones y la forma de implementar el programa de investigación profunda en su empresa. Cada uno de estos pasos exige decisiones pragmáticas sobre qué genera un impacto real en la creación de un sistema de investigación profunda.
El resto de este artículo explica cómo abordamos esas decisiones.
Puede ser tentador tratar los proyectos de investigación empresarial como un problema de integración de datos. Unifique las fuentes, normalice el esquema y deje que los modelos trabajen sobre ellos.
Y, para ser claros, a veces esa es exactamente la decisión correcta. Si opera en un ámbito donde las entidades principales son estables, las consultas son repetibles y el objetivo final es industrializar el flujo de trabajo, la unificación puede generar beneficios reales. Los casos clásicos incluyen unir datos de clientes e ingresos, datos de precios de mercado o cualquier información que requiera informes confiables entre sistemas.
Sin embargo, en la práctica, los líderes innovadores actuales buscan algo distinto en los sistemas empresariales de investigación profunda.
Ante la creciente atención al ROI del gasto en IA, un objetivo clave para quienes toman decisiones es demostrar valor con rapidez dentro de la desordenada realidad operativa de la empresa. Y la unificación total de las fuentes de datos es una de las formas más lentas de llegar a esa primera prueba. Es un proceso pesado. Genera disputas internas. Y suele obligarlo a comprometerse con una dirección antes de saber qué preguntas importan realmente.
Por eso creemos que el punto de partida pragmático para crear sistemas de vanguardia de investigación profunda en 2026 suele ser este: haga que sus datos sean accesibles antes de embellecerlos.
Si existe una posibilidad realista de agregar más fuentes con el tiempo —como ocurre en la mayoría de las empresas—, se subestima el valor de las conexiones dispersas. Puede exponer decenas de fuentes mediante una interfaz de recuperación uniforme. El sistema seguirá funcionando y, lo que es fundamental, usted conservará la capacidad de entregar con rapidez. Cuando llegue el momento de agregar más fuentes, no tendrá que cambiarlo todo. Solo tiene que incorporar un conector nuevo, explicarle al sistema central qué es y cómo usarlo, y dejar que los modelos hagan el resto. Esto funciona porque los modelos de vanguardia actuales pueden realizar uniones flexibles entre dos o más fuentes de datos durante la inferencia, vinculando “ID de cliente” en un sistema con “Referencia del cliente” en otro, sin que nadie escriba un mapeo formal. No somos el único equipo que piensa así. No somos el único equipo que piensa así: el agente interno de datos de OpenAI está diseñado para que los modelos razonen sobre 70 000 conjuntos de datos heterogéneos, haciendo accesibles el contexto y las conexiones al consultar, en vez de exigir una unificación total por adelantado.
Conviene aclarar un matiz: una integración dispersa no tiene por qué ser superficial.
La integración dispersa funciona mejor cuando las conexiones creadas son significativas y se expresan de una forma que el sistema pueda aprovechar fácilmente. Una buena forma de concebirla es tratar ciertos datos como anclas: especificaciones, políticas, definiciones de productos, SKU, cláusulas contractuales y otros similares. No necesita unificar todos los conjuntos de datos para que estas anclas sean potentes; solo necesita un identificador estable con algunas conexiones de alta señal.
Por ejemplo, imagine que un modelo —o un usuario— busca una especificación. En un sistema básico, ahí termina la interacción. Se recupera la especificación, se resume y quizá se cita. Sin embargo, al diseñar estructuras de datos útiles, queremos convertir esa búsqueda en el inicio de una expansión controlada. Por ejemplo, podríamos vincular opcionalmente el registro de esa especificación con entregables históricos pertinentes. Aquí, “pertinente” puede significar varias cosas, pero normalmente dependería de la tarea que realiza el sistema. Podría incluir RFP que citaron la especificación, respuestas anteriores que ganaron propuestas relacionadas con ella, cambios en los que el equipo jurídico planteó objeciones y otros casos. Este enfoque puede mejorar enormemente la calidad y la latencia de las respuestas, pues presenta rápidamente al sistema de investigación profunda los hallazgos más importantes al momento de la consulta.
Esto plantea la siguiente pregunta: una vez que tiene un universo de fuentes de datos con conexiones dispersas y unas cuantas conexiones de alta señal, ¿cómo evita que el sistema de investigación profunda deambule como un niño en una dulcería y logra que navegue como un analista experimentado?
Las fuentes de datos empresariales no funcionan como la web. Son dispersas, están llenas de convenciones locales y, a menudo, tienen exactamente una fuente “correcta” para un dato determinado, si logra encontrarla. Además, los modelos actuales tienden a maximizar siempre la exhaustividad en las búsquedas y suelen encadenar consultas para encontrar una fuente más, consumiendo tiempo y agotando la paciencia del usuario. Esto puede mitigarse hasta cierto punto con instrucciones cuidadosas.
La solución más eficaz es una herramienta ligera que ayude al modelo a orientarse en el desordenado panorama de datos empresariales. Algunos equipos la llaman ontología. Otros la llaman capa semántica, servicio de búsqueda, grafo o repositorio de conceptos. El nombre realmente no importa.
Lo importante es que ofrezca al sistema vías rápidas y económicas para que el modelo pueda pasar eficientemente entre los fragmentos correctos de contexto, en vez de deambular durante lo que parece una eternidad.
Una metáfora sencilla es cuando alguien acaba de incorporarse a una empresa o proyecto y sus nuevos colegas le dicen: “Debes guardar estos sitios en favoritos; los usarás todo el tiempo” o “si alguna vez tienes un problema con AWS, habla con Ross; él te dará la información que necesitas”, y así sucesivamente. Del mismo modo, aquí solo intentamos ayudar al sistema de investigación profunda a encontrar rápidamente lo que necesita.
En la práctica, este sistema no tiene que ser complicado ni requerir mantenimiento manual. Las mejores implementaciones que hemos encontrado son generadas por LLM durante el proceso de incorporación —extraen entidades para completar automáticamente el grafo— o funcionan como accesos directos a sistemas de registro existentes, por ejemplo, mediante una consulta a la API de Salesforce. Algunos ejemplos comunes son:
Búsquedas en mapas hash, por ejemplo, consultar por nombre del producto y devolver su descripción.
Una búsqueda sencilla de relaciones “comunes”, por ejemplo, las enfermedades con las que este gen suele estar vinculado en nuestro grafo de relaciones causales entre genes.
Modelos de reconocimiento de entidades nombradas, principalmente útiles en áreas con problemas complejos de desambiguación, como la industria farmacéutica.
Para las relaciones de datos más complejas, los grafos RDF ligeros pueden ofrecer la solución más extensible para una ontología.
… y más
Con esto implementado, el sistema puede desplazarse eficientemente por sus fuentes de datos. La siguiente pregunta es sencilla: ¿cómo saber si hace lo correcto de manera consistente durante el uso real?
Ahora que sus datos son accesibles y la capa de navegación proporciona el mapa, el sistema tiene capacidad para realizar el trabajo. Pero, en un contexto empresarial, la capacidad no sirve de nada sin confiabilidad.
Aquí se encuentra el mayor cementerio de proyectos de IA. Muchos equipos han caído en la trampa de evaluar “por sensaciones”. Ejecutaban una consulta, leían el resultado, asentían con aprobación y lo implementaban. Este enfoque no funciona al crear un sistema de investigación profunda que podría recorrer autónomamente 5000 documentos para recomendar una decisión multimillonaria sobre la cadena de suministro.
El cambio importante es que ya no se evalúa un modelo, sino un sistema. La interpretación de preguntas, la planificación, las llamadas a herramientas, la interpretación, la depuración del contexto, el reordenamiento e incluso detalles de conectores aparentemente aburridos, como las marcas de tiempo, se reflejan en la experiencia del usuario.
Las evaluaciones estructuradas y repetibles nos ayudan a resolver estos problemas.
Al crear evaluaciones, podemos clasificarlas en términos generales en tres categorías, desde las mecánicas hasta las subjetivas.
Esta es la parte más parecida a las pruebas unitarias y donde los equipos suelen avanzar más rápido al principio. También suelen ser las más estables con el tiempo: una vez configuradas, pueden seguir generando beneficios durante toda la vida del proyecto.
Las “evaluaciones mecánicas” suelen ser comprobaciones que pueden ejecutarse en cada consulta sin intervención humana. Nos ayudan a confiar en que el sistema se comportará de forma predecible y segura con cargas de usuarios reales.
Algunos ejemplos son:
Calidad de las citas: ¿todas las citas apuntan a fragmentos que realmente se recuperaron? ¿Hay afirmaciones sin citar? ¿Hay afirmaciones que el material fuente no respalda? ¿Las citas son demasiado genéricas, por ejemplo, se cita un documento completo para una sola afirmación?
Uso correcto de herramientas: ¿el sistema usó todas las herramientas que afirmó haber usado? ¿Usó correctamente las herramientas de navegación? ¿Formateó incorrectamente alguna solicitud a una herramienta? ¿Reintentó la operación de forma razonable cuando recibió errores?
Presupuestos de latencia y costo: ¿se mantuvo dentro del tiempo objetivo hasta el primer token? ¿Superó la cantidad prevista de llamadas a herramientas o el presupuesto? ¿Consumió mucha latencia y capacidad de cómputo para obtener una mejora marginal?
Parece algo rutinario, pero son precisamente las pruebas que evitan que un sistema empresarial se deteriore.
Como ejemplo real, en el proyecto de investigación profunda para descubrir dianas terapéuticas usamos dos capas de comprobación de citas que se ejecutan en cada consulta. Primero, al generar una respuesta, indicamos al modelo que incluya citas frecuentes en el texto. La capacidad de los LLM para hacerlo de manera confiable también es relativamente reciente: surgió durante el primer semestre de 2025. Quienes hayan intentado hacerlo antes con volúmenes significativos de datos comprenderán el desafío que suponía. Así podemos realizar comprobaciones sencillas con expresiones regulares para detectar, por ejemplo, si se menciona el enlace de un artículo que no estaba entre las fuentes proporcionadas.
La segunda capa de comprobaciones se ejecuta después de transmitir la respuesta. Primero, la respuesta se divide en fragmentos. Luego se evalúa cada uno mientras el sistema busca, entre los datos recuperados, fuentes que respalden las afirmaciones hechas en ese fragmento. Si no se encuentra evidencia que la respalde, se marca como una posible alucinación.
Si las evaluaciones mecánicas son sus pruebas unitarias, las analíticas son su revisión de código.
Aquí entramos en un ámbito donde intentamos comprender si el sistema realiza bien el trabajo. Solemos querer saber si usa las herramientas correctas, sigue las líneas de investigación adecuadas, elige las fuentes más confiables o sabe cuándo detenerse, entre otras cosas.
En la práctica, suelen adoptar la forma de pares de pregunta y respuesta (P-R) para los que, por ejemplo, se conoce un orden razonable de llamadas a herramientas o la decisión correcta según la investigación obtenida con la primera herramienta. Es importante señalar que estos pares no tienen que corresponder uno a uno con la entrada y la salida del sistema completo de investigación profunda; también permiten probar subprocesos. Con estas etiquetas —generadas por una persona o por un modelo de etiquetado potente, aunque “potente” sea relativo— podemos usar un LLM como juez para calificar las ejecuciones de investigación y evaluar su rendimiento. Al seguir estas puntuaciones a lo largo del tiempo, podemos determinar si nuestros cambios mejoran el sistema en la dirección correcta o introducen regresiones de rendimiento.
Debido a su mayor costo en dinero y tiempo, estas ejecuciones suelen realizarse periódicamente, ya sea según un calendario establecido o antes de actualizar una versión.
También hay un valioso beneficio indirecto: este tipo de evaluaciones analíticas puede orientar directamente las mejoras de las conexiones dispersas que mencionamos antes. Si observa repetidamente que el modelo realiza el mismo salto de alta calidad —por ejemplo, “especificación → ejemplos históricos relevantes de RFP”— aunque hoy las personas no vinculen explícitamente esos entregables, esa información resulta útil. Puede convertir ese salto en una conexión o un atajo de primer nivel, para que las ejecuciones futuras se beneficien de una menor latencia y una mayor consistencia.
Aquí también se detecta uno de los problemas más costosos de los sistemas de investigación profunda: la tendencia a maximizar la exhaustividad de manera predeterminada. Un modelo siempre puede encontrar una fuente más. La pregunta es si debería hacerlo. Podemos ajustar el modelo para reforzar criterios de detención razonables: que el sistema reconozca cuándo es poco probable que recuperar más información cambie la conclusión y opte por entregar una respuesta bien fundamentada que atienda la pregunta del usuario.
Las evaluaciones mecánicas indican que el sistema es seguro. Las evaluaciones analíticas indican que es competente. Las evaluaciones de usuario indican si realmente es útil.
Esta es otra área donde muchos equipos tropiezan. Crean algo técnicamente impresionante que nadie quiere usar dos veces. En un contexto empresarial, esta es la diferencia entre una implementación exitosa y un proyecto de investigación costoso.
Las evaluaciones de usuario buscan esencialmente comprender si el sistema resuelve el problema correcto de la manera adecuada. Esto implica ir más allá de “¿dio la respuesta correcta?” y preguntar “¿me dio algo sobre lo que puedo actuar?”
En la práctica, las evaluaciones de usuario suelen adoptar varias formas:
Estudios de finalización de tareas: ¿los usuarios realmente pueden hacer su trabajo más rápido o mejor con el sistema? No se trata de si el modelo podría responder una pregunta, sino de si un usuario real obtuvo lo que necesitaba dentro de su flujo de trabajo real.
Ciclos de comentarios cualitativos: conversaciones estructuradas y periódicas con usuarios avanzados. ¿Qué consultas ejecutan repetidamente? ¿En qué punto pierden la confianza? ¿Cuándo se dan por vencidos y vuelven al método anterior? Estas sesiones suelen revelar fallas que nunca aparecen en los conjuntos de prueba, porque los usuarios hacen preguntas de maneras imprevistas o tienen estándares de calidad implícitos cuya existencia se desconocía.
Análisis de uso: ¿qué consultas vuelven a ejecutarse? ¿Qué respuestas se copian y usan en otros lugares? ¿En qué casos los usuarios hacen clic en el pulgar hacia abajo? Una caída del uso no siempre implica una falla —a veces los usuarios obtienen su respuesta y siguen adelante—, pero los patrones de cuándo y cómo abandonan las consultas revelan mucho sobre los puntos en que el sistema no cumple las expectativas.
En conjunto, estas evaluaciones permiten medir la utilidad sin hacer conjeturas y ayudan a detectar problemas antes de que comiencen a erosionar la confianza de los usuarios.
Sin embargo, incluso un sistema que obtiene una puntuación perfecta en precisión mecánica y encanta a sus primeros usuarios puede fallar la prueba definitiva: aumentar los ingresos de una empresa. La confiabilidad y la satisfacción del usuario son apenas requisitos previos para lograrlo. Para salvar la brecha entre un piloto exitoso y un activo empresarial transformador, debe mirar más allá del funcionamiento del sistema y centrarse en dónde se aplica.
Hemos explicado cómo hacer que sus datos funcionen para el sistema y, después, cómo hacer que el sistema funcione para sus usuarios. Ahora debemos hablar de cómo hacer que este sistema funcione para su empresa.
Recientemente, los líderes empresariales han prestado mucha atención a este tema, y con razón. Tras informes como la afirmación del MIT de que el 95 % de los proyectos empresariales de IA no logra ROI, se agotó la tolerancia hacia las demostraciones impresionantes que nunca se implementan. Los modelos están listos. Las arquitecturas están comprobadas. La pregunta ahora es: ¿realmente puede implementarlo de una manera que genere valor para su empresa?
La buena noticia es que los sistemas de vanguardia de investigación profunda creados con los principios anteriores están bien posicionados para superar este umbral. No intentan automatizarlo todo ni reemplazar funciones laborales completas. Intentan aumentar drásticamente la eficacia de sus mejores profesionales en el trabajo de alto valor que ya realizan.
Pero pasar de “funciona técnicamente” a “genera ROI” requiere varios elementos adicionales: decisiones organizacionales, de experiencia del usuario (UX) y de medición que determinan si se convertirá en una herramienta cotidiana o en una pestaña olvidada.
Según nuestra experiencia, son dos.
La tentación suele ser comenzar con tareas internas de bajo riesgo, como “resume esta reunión”. Aunque son seguras, rara vez demuestran suficiente valor para justificar el costo.
Los sistemas de investigación profunda funcionan mejor cuando se aplican a tareas grandes y difíciles: problemas costosos donde mejorar la calidad o la velocidad genera un aumento demostrable en los ingresos o una ventaja estratégica.
Observamos el mayor ROI cuando las empresas eligen puntos de entrada como:
Generación de propuestas complejas y RFP: los sistemas de investigación profunda pueden recuperar automáticamente los éxitos históricos más similares —y también las derrotas—, extraer las cláusulas que siempre generan cambios, encontrar las pruebas más sólidas para cada requisito y mucho más, antes de convertir todo ello en un posicionamiento sólido y coherente para la licitación. La métrica no es el tiempo ahorrado, sino la tasa de éxito, la conservación del margen y la reducción de sorpresas legales o comerciales en etapas avanzadas.
Análisis del panorama científico: en organizaciones con fuerte inversión en I&D —farmacéuticas, biotecnológicas y de semiconductores—, el punto de entrada consiste en condensar semanas de bibliografía y conocimiento interno en una línea de investigación práctica. Un sistema de investigación profunda puede analizar miles de artículos, patentes, informes internos, notas de laboratorio y revisiones de programas anteriores para identificar lo conocido y lo controvertido, y generar un panorama respaldado por evidencia. Así puede acelerar los ciclos de iteración, reducir las apuestas sin salida y, sobre todo, acortar el tiempo hasta el primer ensayo en seres humanos.
Inteligencia de mercado: para bancos y fondos de cobertura, el valor consiste en transformar investigaciones internas fragmentadas —notas, modelos, transcripciones y comentarios de corredores— junto con señales externas —presentaciones regulatorias, resultados, indicadores macroeconómicos y noticias— en apoyo de calidad para decisiones de inversión. Un sistema de investigación profunda puede crear y actualizar continuamente una perspectiva sobre una empresa, un tema o una cuestión macroeconómica; destacar los principales cambios desde la semana anterior, conciliar fuentes contradictorias y elaborar un memorando de inversión o un paquete de operación con procedencia completa.
El denominador común es que no son chats. Son flujos de trabajo complejos que suelen requerir consultores externos costosos o semanas del tiempo de personal sénior. Al aplicar un sistema de investigación profunda a estos problemas, el valor es innegable.
Este será uno de los cambios en la experiencia del usuario que definirán 2026.
Si su sistema de investigación profunda es simplemente un chatbot al que los usuarios consultan para encontrar cosas, pronto puede terminar usándose solo de vez en cuando. Sigue siendo una herramienta de consulta y, al final, los usuarios deben compilar los resultados para obtener el producto final que desean. Sin embargo, si se percibe como un analista siempre disponible al que se le puede asignar trabajo, puede transformar por completo el modelo operativo del equipo.
Estamos pasando de “conversar” —intercambios breves— a delegar: definir un alcance, una plantilla y un objetivo, y dejar que el sistema trabaje.
Tres cambios específicos lo hacen posible:
Resultados como entregables: el trabajo de alto valor rara vez vive en una ventana de chat; vive en documentos, memorandos y presentaciones. Los sistemas modernos de investigación profunda deberían omitir la fase de chat y generar directamente el entregable empresarial final. Cuando un usuario puede pedir un “memorando de inversión de tres páginas con nuestro formato corporativo” y recibir un archivo descargable en lugar de un flujo de texto, el tiempo para obtener valor disminuye drásticamente. Esto también suele extenderse a generaciones programadas: los usuarios pueden pedir que se generen automáticamente correos o informes con nuevos hallazgos y se distribuyan a las partes pertinentes a medida que surjan nuevos datos.
Optimización local mediante plantillas personalizadas: los modelos son lo bastante robustos para permitir que las unidades de negocio, o incluso usuarios individuales, adapten sus instrucciones y comportamientos sin afectar el sistema. Un informe de riesgos se ve distinto en Londres que en Nueva York. Al permitir que los equipos carguen o diseñen sus propias plantillas estructurales y definan sus criterios de detención —por ejemplo, “consulta siempre estas tres bases de datos internas”— o el formato de salida, los usuarios pueden obtener mucho más valor del sistema y crear algo que quieran usar cada vez más.
La confianza como interfaz: cuando un usuario delega una tarea que tarda más de 20 minutos, la confianza se convierte en una prioridad. No puede presentar una caja negra. La interfaz debe mostrar el razonamiento y las decisiones del sistema, indicar qué herramientas se están utilizando, generar citas y mucho más. A menudo descubrimos que la mejor UX para estos sistemas muestra de manera predeterminada hallazgos generales sobre el avance de la investigación y permite al usuario profundizar al expandir información adicional en una barra lateral o algo similar.
Imaginamos un futuro en el que cada empresa líder tenga un sistema personalizado de investigación profunda detrás de sus flujos de trabajo más críticos. Esto adoptará la forma de una serie de analistas siempre disponibles, capaces de recorrer de manera confiable miles de entregables internos y producir decisiones y resultados sobre los que las personas puedan actuar. A medida que los modelos de vanguardia elevan el límite de ejecución, el factor diferenciador pasa a ser lo fundamental: hacer accesibles sus datos, darle un mapa al sistema y convertir la confiabilidad en una práctica operativa mediante evaluaciones.
Las mejoras en la capacidad de los modelos que observamos durante el último año son la señal más clara del rumbo que esto está tomando. La oportunidad para los líderes en 2026 es actuar pronto. Elija un punto de entrada donde el valor sea evidente, genere confianza mediante la procedencia y las salvaguardas, y transforme su solución empresarial de investigación profunda: de un piloto a una capacidad acumulativa que la empresa use todos los días.