Qué es RAG para empresas: qué puede y qué no puede hacer con sus documentos

RAG puede encontrar fragmentos en los documentos de una empresa y preparar respuestas vinculadas a fuentes, pero no entrena el modelo ni sustituye la verdad, el control de acceso o la supervisión.

El lunes por la mañana, la responsable de recursos humanos pregunta al asistente interno durante cuánto tiempo deben conservarse los datos de los candidatos y recibe una respuesta convincente con un enlace a la política de la empresa; el único problema es que la versión encontrada dejó de estar vigente hace ocho meses. Este es el primer límite al explicar qué es RAG para empresas: una solución de este tipo puede haber hecho técnicamente todo lo que se le pidió —encontrar un fragmento semánticamente parecido, introducirlo en el contexto del modelo y redactar una respuesta fluida— y, aun así, no haber comprobado si el archivo es la última versión aprobada cuando el estado de la versión no figura de forma fiable en el índice.

RAG son las siglas de retrieval-augmented generation, o generación aumentada por recuperación: en el momento de responder se añade contexto externo recuperado; no se enseñan los documentos de la empresa incorporándolos a los pesos del modelo ni se crea una «capa de inteligencia» separada que sepa automáticamente qué documento es verdadero. Se parece más a una biblioteca con un bibliotecario muy rápido y un redactor con talento: el bibliotecario puede traer el volumen equivocado y, aun así, el redactor escribirá un párrafo convincente. El trabajo original sobre RAG distingue expresamente la memoria paramétrica del modelo de una fuente externa recuperada y no paramétrica.

La ventaja práctica es importante si los límites se exponen con honestidad: el sistema puede localizar fragmentos pertinentes en un conjunto de documentos gestionado, reunirlos en un contexto adecuado para la pregunta y preparar un borrador con una referencia comprobable a la fuente. El límite de responsabilidad también debe resultar visible para el usuario: la interfaz no puede dar a entender que la existencia de una fuente equivale a una aprobación jurídica, y comunicar errores o dudas debe ser tan fácil como formular una pregunta. No puede reparar documentación deficiente, garantizar la corrección factual, implantar por sí solo los permisos de acceso ni sustituir un flujo determinista y la aprobación humana cuando un error entraña un riesgo jurídico, financiero, de seguridad o para los derechos de las personas; este límite determina tanto la arquitectura como lo que tiene sentido medir en el piloto.

Por qué una política antigua puede recuperarse como si estuviera vigente

El incidente de la política antigua no empieza en el modelo de lenguaje, sino en la gestión documental: en la unidad compartida están «Datos_personales_final.docx», «Datos_personales_final2.docx» y un PDF aprobado, pero ninguno de los archivos tiene una fecha de entrada en vigor, un estado ni un identificador uniforme de la versión a la que sustituye. El índice ve tres candidatos con contenidos parecidos, y la búsqueda semántica puede puntuar mejor el documento antiguo porque su redacción coincide con mayor precisión con la pregunta. El modelo no ve la decisión tomada en una reunión de la organización si esa decisión no está en los datos, y llamar «final» a un archivo no es un mecanismo de gobernanza.

Las consecuencias son engañosas porque la respuesta puede parecer mejor que un resultado de búsqueda corriente: es breve, correcta desde el punto de vista gramatical y remite a un documento real, por lo que transmite la sensación de que la comprobación ya se ha realizado. El enlace a la fuente solo demuestra que un archivo concreto se ha mostrado o asociado a la respuesta; todavía no demuestra que cada afirmación se desprenda del fragmento citado, que el fragmento no se haya extraído de una sección de excepciones ni que el documento tenga autoridad. El perfil de IA generativa de NIST no considera que esta apariencia de fiabilidad sea un control de riesgos suficiente y subraya la gobernanza durante todo el ciclo de vida del sistema.

La solución consiste en definir el estado de publicación, la cadena de versiones y las reglas de prioridad, no en alargar el prompt: cada documento del índice necesita un responsable, fechas de inicio y fin de vigencia, estado, documento sustituido, departamento, nivel de confidencialidad y fecha límite de revisión; el filtro de recuperación debe excluir por defecto los borradores y las versiones derogadas; si las fuentes entran en conflicto, el sistema debe mostrarlo y abstenerse de fingir una única respuesta segura, mientras el responsable correspondiente recibe la tarea de ordenar el conjunto documental. RAG puede sacar el caos a la luz, pero no puede convertirlo en una política.

En esa situación, la interfaz de respuesta debe mostrar no solo el nombre del documento, sino también la versión, su estado de vigencia, el fragmento y una advertencia sobre el conflicto; el registro debe conservar qué candidatos se encontraron y por qué se eligió uno, de forma que el error pueda reproducirse después de un cambio en el índice. Si más adelante el sistema empieza a dar otra respuesta, el equipo debe poder determinar si cambió el documento, la fragmentación, la configuración de búsqueda o el modelo; sin esta trazabilidad, un incidente de calidad se convierte en una conjetura sobre el «comportamiento de la IA» en lugar de ser un defecto corregible del sistema.

¿Qué es RAG para empresas y cómo funciona?

El flujo de RAG empieza con la ingestión de datos, no con la ventana del chat: los archivos se recogen de repositorios definidos y se extraen el texto, las tablas y la estructura disponible, mientras que los documentos escaneados necesitan reconocimiento óptico de caracteres u OCR; después, el contenido se divide en fragmentos con sentido y cada uno conserva el enlace al documento, la página, la sección y los metadatos de gobernanza. Las directrices de Microsoft describen la fragmentación como una elección que influye en la utilidad de la búsqueda: un fragmento demasiado pequeño pierde la idea, uno demasiado grande incorpora mucho ruido y una división ciega por un número fijo de caracteres puede cortar una tabla o una condición de excepción.

Durante la indexación se crea para cada fragmento una representación apta para la búsqueda, normalmente combinando la búsqueda por palabras clave con una comparación semántica mediante vectores numéricos; cuando el usuario plantea una pregunta, el sistema puede transformarla en varias consultas, aplicar filtros de departamento, fecha y acceso, recuperar candidatos y reordenarlos; solo entonces los fragmentos seleccionados entran en la ventana de contexto del modelo junto con el encargo de responder a partir de las pruebas disponibles, indicar las fuentes y decir que no hay pruebas suficientes cuando corresponda. En ese momento no se «aprende para siempre» nada; el contexto pertenece a esa solicitud concreta.

La última fase es la generación, en la que un modelo de lenguaje previamente entrenado convierte los fragmentos en una respuesta comprensible; por ello, también puede parafrasear mal, unir fuentes incompatibles o añadir un detalle verosímil procedente de su conocimiento general. El resultado debe conservar el vínculo entre el fragmento y la afirmación, no solo una lista decorativa de fuentes al final de la respuesta; si la pregunta exige una acción —por ejemplo, cambiar un precio en el CRM—, no se debe permitir que el modelo la ejecute libremente: el código de la aplicación, los permisos y un paso de aprobación comprueban la solicitud estructurada de uso de una herramienta. La recuperación ayuda a encontrar fundamento; no concede permiso para actuar.

En la práctica funciona bien la recuperación híbrida, en la que un código de producto o un número de política exactos se buscan como palabras clave y el sentido de la pregunta se compara semánticamente; a continuación, la reordenación selecciona los fragmentos que mejor responden a la pregunta completa. Esta secuencia debe probarse con abreviaturas reales, códigos mal escritos, variaciones gramaticales y documentos multilingües, porque una pregunta de demostración suele ser demasiado limpia. Si el fragmento necesario no aparece entre los candidatos, la elocuencia del modelo generativo no puede recuperarlo, de modo que el error de búsqueda debe corregirse antes de reformular el prompt.

Para qué usos documentales resulta adecuado RAG

Los mejores candidatos son preguntas cuya respuesta ya se encuentra en muchos documentos gestionados, pero localizarla lleva demasiado tiempo a una persona: procedimientos internos, manuales de producto, instrucciones técnicas, documentación de calidad, explicaciones de plantillas contractuales y bases de conocimiento de atención al cliente. Aquí la tarea de RAG no consiste en inventar una decisión nueva, sino en encontrar el apartado pertinente, combinar algunos fragmentos compatibles y preparar un borrador. Una buena pregunta sería «¿en qué instrucción se describe este error y qué pasos de comprobación indica?», no «¿cómo debe actuar la empresa ante cualquier emergencia?». También resulta útil como capa de exploración documental antes del trabajo humano: un jefe de proyecto puede localizar condiciones de entrega en los contratos; una persona de compras, menciones a requisitos; y un técnico de servicio, soluciones anteriores para un equipo parecido. En estos casos la respuesta debe abrir el punto exacto de la fuente para que el usuario compruebe el contexto, y el sistema debe registrar la consulta, los fragmentos encontrados y la versión utilizada. Así RAG funciona como herramienta de navegación y borrador, no como un emisor anónimo de dictámenes cuyo razonamiento no pueda reconstruirse después.

Son malos candidatos las tareas sin una base documental estable, que exigen aritmética precisa o ejecutar reglas, o en las que un solo error desencadena automáticamente una acción irreversible. El cálculo de nóminas, la concesión de accesos, la ejecución de pagos y el control de un plazo jurídico se rigen por código y reglas de negocio comprobables; RAG puede encontrar la explicación de un procedimiento, pero no sustituye el motor de cálculo ni la cadena de autorizaciones. Si el objetivo real es conectar sistemas y trasladar datos de forma previsible, debe valorarse la automatización de procesos de negocio en vez de convertir una respuesta generativa en el interruptor central del proceso.

La idoneidad también depende de que exista un responsable: cada conjunto documental necesita una persona que apruebe las fuentes, resuelva los conflictos y decida qué debe retirarse del índice, y cada caso de uso, un equipo que revise los errores y modifique el conjunto de pruebas. Si nadie asume ese trabajo, al cabo de unos meses el piloto se convierte en un espejo de documentos antiguos aunque el modelo no haya cambiado. Por eso, una guía de soporte sencilla pero bien gobernada es un primer proyecto mejor que conectar toda la unidad compartida de la empresa en una sola tarde.

Qué puede hacer RAG con los documentos de la empresa en el trabajo diario

RAG puede reducir el tiempo que un empleado dedica a adivinar la carpeta y las palabras clave correctas, porque la búsqueda semántica encuentra un fragmento incluso cuando las palabras de la pregunta no coinciden con la terminología del documento. Puede combinar en una respuesta varias fuentes compatibles, explicar una instrucción compleja con un lenguaje más sencillo, preparar el borrador de un correo o un informe e indicar de qué páginas procede cada afirmación importante. File Search de OpenAI y la arquitectura de búsqueda de Microsoft son ejemplos concretos de herramientas, pero elegir un producto no elimina la necesidad de definir el estado de los documentos, los filtros y las comprobaciones de calidad propios. El sistema también puede descubrir problemas documentales que una navegación corriente por carpetas oculta: dos instrucciones contradictorias aparecen para una misma pregunta, preguntas frecuentes se quedan sin fuente o un departamento domina los resultados porque sus archivos están mejor estructurados. Estos casos solo aportan valor si no quedan ocultos detrás de una respuesta uniforme; una fuente no encontrada y un conflicto deben convertirse en acontecimientos medibles que vea el responsable del documento. Así, el registro de calidad de RAG también se convierte en una lista de tareas de gestión del conocimiento, no solo en un gráfico del rendimiento del modelo.

Otra posibilidad real es adaptar la presentación a la función y al contexto: un técnico recibe una instrucción detallada con códigos y un agente de atención al cliente, una explicación más breve, siempre que ambos tengan permiso para ver las mismas fuentes. Cambia la presentación, no la verdad, y cada función debe conservar el mismo estado de la fuente y la misma prohibición de inventar lo que falta. Nuestro trabajo en soluciones de IA para empresas comienza por delimitar este caso de uso y su riesgo, no por una demostración del modelo, porque un buen prototipo prueba una mejora concreta del trabajo con sus documentos y, al mismo tiempo, muestra en qué preguntas el sistema debe decir «no lo sé».

En el trabajo cotidiano, la mayor ventaja aparece cuando la persona ve qué ha hecho el sistema por ella y qué queda por comprobar. El borrador de respuesta puede destacar las afirmaciones con fundamento incompleto, proponer documentos relacionados y permitir comunicar una versión equivocada con una sola acción; esta información de retorno vale más que un simple icono de pulgar. La corrección debe vincularse a la pregunta, el fragmento y el tipo de error, para que el equipo distinga una fuente no encontrada de una redacción torpe o una regla de negocio errónea y elija la solución adecuada.

Qué no puede hacer RAG, por convincente que resulte la respuesta

RAG no puede garantizar la verdad, porque el error puede surgir antes, durante o después de la generación: la fuente puede contener un dato equivocado, la recuperación puede elegir un fragmento irrelevante, el contexto puede perder una excepción y el modelo puede combinar mal dos párrafos correctos. Una cita reduce el riesgo de confianza ciega solo si el usuario puede abrir el punto exacto y comprobar que la afirmación se desprende realmente de él; un enlace a un PDF auténtico no es un sello de calidad, del mismo modo que la bibliografía de un informe equivocado no vuelve correcto el resultado.

Tampoco puede implantar por sí solo el control de acceso: si la capa de búsqueda no filtra los documentos por la identidad verificada del usuario y sus permisos antes de recuperarlos, un fragmento que este no puede ver puede llegar al modelo; añadir más tarde al prompt «no reveles información secreta» no corrige ese error de arquitectura. Las directrices de Microsoft sobre el acceso a documentos contemplan datos de permisos y filtros de seguridad en la propia ruta de búsqueda; ocultar un botón en la interfaz no protege nada si la consulta puede ejecutarse por otra vía.

RAG tampoco vuelve seguro un contenido que no es de confianza: un documento, una página web o un correo pueden contener una instrucción que intente alterar el comportamiento del sistema —una inyección de prompts—, y OWASP la señala como un riesgo independiente que una simple prohibición en el prompt del sistema no resuelve por completo. Por eso, el contenido externo debe tratarse como datos, no como órdenes; las llamadas a herramientas han de estar estrictamente permitidas y validadas, mientras que una acción de alto riesgo debe seguir sometida a una regla determinista y a aprobación humana. El modelo puede proponer; el sistema concede las facultades.

La lista de límites también debe incluir la disponibilidad y la continuidad operativa: si el índice de búsqueda no está disponible, un sistema seguro no finge que sigue contando con las fuentes de la empresa, sino que pasa claramente a un estado de error o a un modo restringido; de lo contrario, el usuario no puede distinguir una respuesta basada en fuentes de una improvisación libre del modelo. También deben preverse límites de costes y solicitudes, una parada de emergencia y la restauración de la configuración anterior; un producto RAG es una cadena de varios servicios y cada fallo silencioso puede cambiar el significado de la respuesta aunque la ventana del chat siga funcionando.

Preparación de los documentos: OCR, metadatos y gestión de versiones

El volumen de una carpeta documental no indica que esté preparada: un contrato escaneado con una página torcida, una tabla sin encabezado legible, un PDF con el texto en un orden incorrecto o una foto con poco contraste pueden resultar comprensibles para una persona y, sin embargo, perder un número, la relación entre columnas o los límites de un párrafo en la extracción mediante OCR. La descripción de las limitaciones de OCR de Microsoft relaciona expresamente el resultado con la calidad del escaneo, la resolución, el contraste, la iluminación, el giro y las características del texto. Por eso, los documentos representativos deben revisarse después de la extracción, comparando el texto, las tablas, las referencias de página y los campos esenciales con el original en lugar de confiar en que un archivo «se ha procesado correctamente».

Los metadatos aportan al fragmento el contexto de la organización: tipo de documento, unidad, producto, idioma, responsable, aprobador, confidencialidad, fecha de entrada en vigor y estado de versión permiten acotar la consulta antes de valorar la similitud semántica. Sin ellos, el buscador compara frases, pero no sabe que una instrucción de almacén solo se aplica a Lituania o que el anexo de un contrato ha sido sustituido por otro más reciente. Los campos más importantes deben proceder de un sistema fiable o ser comprobados por una persona; una conjetura generada sobre el estado de un documento no puede convertirse en el filtro que determine la respuesta siguiente.

La actualización también forma parte del producto y no es un trabajo de importación que se haga una sola vez: hay que saber cuánto tarda un cambio aprobado en llegar al índice, cómo se elimina un fragmento retirado, qué sucede si cambia la dirección de un archivo y si el sistema sigue mostrando la versión antigua cuando se produce un fallo. Las directrices de Microsoft sobre índices distinguen las actualizaciones incrementales de la reindexación, por lo que cada fuente necesita un método documentado de sincronización y control de errores; antes de un proyecto RAG conviene ordenar un único flujo documental autorizado. De lo contrario, una recuperación rápida solo acelera las consecuencias de una gobernanza confusa.

Antes de la primera indexación resulta útil preparar una muestra de documentos: se eligen tipos de archivo, antigüedades, idiomas, tablas, escaneos y niveles de acceso distintos, y para cada uno se comprueban el texto extraído, los límites de los fragmentos, los metadatos y el enlace a la fuente. La proporción de errores no debe comprimirse en una única media, porque el coste de perder una coma en una instrucción y el de perder un importe en un contrato son diferentes. La muestra permite decidir qué formatos se aceptan automáticamente, cuáles necesitan revisión humana y cuáles no deben indexarse todavía; a menudo, este trabajo mejora más la calidad que cambiar de modelo de lenguaje.

Permisos de acceso, privacidad y elección del despliegue

Una arquitectura segura empieza por la identidad: quién pregunta, a qué organización y departamento pertenece, qué clases de documentos puede ver y si esos permisos se comprueban en cada solicitud de recuperación. El filtro de permisos debe funcionar antes de que los fragmentos entren en el contexto del modelo, mientras que los registros deben evitar copias innecesarias de preguntas, respuestas y fragmentos sensibles completos; también hay que probar los casos límite: un empleado cambia de función, un documento pasa a estar restringido, se revoca un acceso o un cliente intenta encontrar contenido de otro. «El chat obliga a iniciar sesión» no es un criterio de aceptación suficiente.

La pregunta «¿mis datos acabarán entrenando el modelo?» no tiene una respuesta universal honesta si no se especifican el proveedor, el producto, la cuenta y los ajustes. Los materiales de OpenAI sobre sus productos empresariales y la API establecen que, por defecto, los datos de los productos empresariales correspondientes no se utilizan para entrenar los modelos, mientras que la documentación sobre controles de datos de la API describe por separado la conservación, la supervisión de usos indebidos y las excepciones de determinados endpoints; Anthropic también distingue el tratamiento en productos comerciales, el consentimiento deliberado para mejorar sus modelos y las condiciones de conservación. Por tanto, el contrato y el diseño técnico deben comprobar el servicio concreto en vez de confiar en la expresión «API empresarial».

El despliegue en una región de la UE o en infraestructura propia puede ayudar a cumplir determinados requisitos de ubicación, control o integración de datos, pero no demuestra por sí solo el cumplimiento del RGPD ni la seguridad. Sigue siendo necesario definir la finalidad y la base jurídica del tratamiento, la minimización de datos, los plazos de conservación, los subencargados, la eliminación, el proceso de incidentes y la auditoría de accesos; los principios del RGPD se aplican a toda la cadena, no solo al país donde está el servidor del modelo. En algunos casos, la decisión correcta es no incluir determinados documentos en RAG o eliminar antes de indexarlos los campos que la respuesta no necesita.

El modelo de amenazas debe comprobar no solo a un empleado curioso, sino también una sincronización errónea de grupos, un enlace compartido, una función de administrador, una caché guardada y un documento con una instrucción maliciosa; los usuarios de prueba deben cubrir cada función y cada combinación de funciones prohibida, intentando preguntar de forma directa, con sinónimos y mediante una solicitud indirecta de resumen. El resultado no debe mostrar el fragmento, el nombre del documento ni un detalle secreto que pueda deducirse de la respuesta; después de cambiar los permisos, la prueba se repite, porque el filtro que ayer era seguro puede permanecer en la caché. Estas comprobaciones son criterios de aceptación, no un adorno para una auditoría de seguridad posterior.

Cómo medir la recuperación, la fundamentación en las fuentes y la corrección

Una única «precisión» para un sistema RAG se parece a una sola nota media para un hospital: el número puede parecer bueno mientras una clase crítica de errores queda oculta. Primero se mide por separado la recuperación: si el fragmento necesario apareció entre un número definido de resultados superiores y si otros fragmentos innecesarios lo desplazaron. Después se miden la pertinencia del contexto para la pregunta, la fundamentación de la respuesta en los fragmentos aportados, la corrección factual frente a un patrón aprobado, la correspondencia de cada referencia con la afirmación concreta y la capacidad del sistema para abstenerse cuando no existe una fuente o las fuentes se contradicen.

La documentación de Microsoft sobre evaluadores de RAG separa estas dimensiones, y el trabajo de investigación ARES distingue de forma parecida la pertinencia del contexto, la fundamentación de la respuesta y la pertinencia de la propia respuesta. Por eso, en el conjunto práctico de pruebas, cada pregunta real necesita no solo una «respuesta correcta», sino también la fuente obligatoria, las formulaciones admisibles, las afirmaciones prohibidas, la función del usuario, la versión del documento y la conducta esperada cuando no haya pruebas suficientes. Una parte de los ejemplos procede de preguntas frecuentes; otra, de excepciones costosas y trampas deliberadas.

El umbral de aceptación debe fijarse para cada dimensión y clase de riesgo antes de ver los resultados; de lo contrario, después de la demostración el equipo elegirá el indicador que mejor aspecto tenga. Las mediciones del piloto también deben conservar la distribución de errores por tipo de documento, departamento, idioma y clase de pregunta, porque la media general puede ocultar que los manuales funcionan bien y las tablas de los contratos, mal. Un evaluador automático basado en otro modelo ayuda a ampliar la comprobación, pero una persona debe revisar una muestra y las respuestas críticas deben compararse con una fuente autorizada, no con la confianza de otro modelo.

Después del lanzamiento deben medirse las mismas dimensiones con una muestra controlada de producción y registros que protejan la privacidad; un cambio en el conjunto documental, el algoritmo de fragmentación, el modelo de vectores, la reordenación o el modelo generativo puede mejorar un grupo de preguntas y empeorar otro. Por eso, cada versión necesita una prueba de regresión y una referencia comparable con reglas de evaluación invariables para todo el conjunto de pruebas. La alerta no debe activarse solo cuando baja el indicador general, sino también cuando aparece un error crítico, como un fragmento no autorizado o una respuesta inventada donde se esperaba abstención.

RAG, búsqueda, contexto largo, ajuste del modelo y agentes

La búsqueda corriente a texto completo es mejor cuando el usuario conoce el nombre, el código o la frase exactos y necesita un documento, no una respuesta redactada; resulta más barata, previsible y fácil de auditar. La búsqueda semántica ayuda con sinónimos y preguntas imprecisas, pero la generación solo debe añadirse donde un resumen aporte valor real. RAG no es obligatorio para todos los buscadores empresariales: a veces el producto correcto es una buena página de búsqueda con filtros, vista previa del fragmento y estado de la versión, porque el usuario extrae su propia conclusión del documento completo.

Introducir todo el documento en una ventana de contexto larga puede ser sencillo para un material pequeño y estable, pero en un corpus grande aumentan el coste, el ruido y el riesgo de que un párrafo importante se pierda entre contenido irrelevante. El ajuste adicional del modelo o fine-tuning puede reforzar el formato, el estilo o el comportamiento de una tarea concreta, pero no es una forma cómoda de almacenar precios, políticas e instrucciones que cambian con frecuencia, porque actualizar y citar la fuente resulta menos transparente. RAG permite modificar el conjunto documental al margen del entrenamiento de los pesos del modelo, aunque esa flexibilidad exige gestionar el índice, las versiones y la calidad de recuperación.

Una automatización ejecuta pasos definidos de antemano; un agente de IA puede elegir una herramienta y el paso siguiente, por lo que esa libertad exige límites más estrictos de permisos, validación y parada. RAG puede proporcionar información al agente, pero no derechos: si el modelo encuentra la política de vacaciones, todavía no puede aprobar una ausencia por sí solo ni cambiar el sistema de nóminas; una llamada estructurada a una función es solo una propuesta para la aplicación, que comprueba el esquema, la identidad, la acción permitida, los importes u otros límites y la aprobación humana necesaria. La comparación entre tecnologías empieza por el riesgo del proceso, no por el deseo de utilizar el nombre más reciente.

La elección puede formularse como una comprobación sencilla: si necesita encontrar y abrir un archivo, empiece por la búsqueda; si debe resumir varias fuentes cambiantes y citarlas, valore RAG; si debe respetar un formato estable o un comportamiento de clasificación, quizá convenga ajustar el modelo; si debe ejecutar una secuencia previsible de acciones, construya una automatización; añada un agente solo cuando el paso siguiente no pueda programarse con seguridad y el beneficio compense el riesgo adicional. Estos enfoques pueden combinarse, pero cada capa debe tener su propia tarea, medición y límite de parada; de lo contrario, la causa del error desaparece detrás de la palabra «IA».

Cómo crear un piloto limitado con preguntas reales

El piloto empieza con un conjunto documental, un grupo de usuarios y un límite de decisión, por ejemplo, los manuales de soporte técnico, donde el sistema solo encuentra fuentes y prepara un borrador de respuesta. Antes del desarrollo, el equipo reúne preguntas reales de los registros de búsqueda, los correos y las entrevistas con empleados, añade las fuentes correctas e incluye deliberadamente casos sin respuesta, antiguos, contradictorios y no autorizados. Para cada caso se define qué es aceptable: se ha encontrado el fragmento necesario, la afirmación se apoya en la fuente, la cita conduce al punto correcto, la respuesta es factualmente correcta y el sistema se abstiene de inventar información cuando faltan datos.

Los umbrales se fijan antes de la demostración y se separan por riesgo: en una pregunta informativa frecuente puede admitirse un borrador corregible, mientras que una pregunta sobre datos personales, un contrato, seguridad o un pago exige una comprobación más estricta y aprobación humana. En el piloto también se miden el tiempo de respuesta, el coste por solicitud, el funcionamiento de los filtros de acceso, el retraso de actualización del índice y la frecuencia con la que el empleado abre la fuente o corrige la respuesta. Si el sistema solo mejora los ejemplos de la demostración y no supera un conjunto de pruebas oculto de antemano, no se ha demostrado el resultado del producto; solo se ha demostrado que el equipo sabe preparar una demostración.

El desarrollo de nuestras soluciones de IA es a partir de 3.500 € y suele durar 3–8 semanas, mientras que un piloto funcional con sus propios datos puede entregarse en 2–3 semanas; estas cifras describen el precio inicial del servicio y el calendario general, no una oferta fija para un alcance desconocido. Al final del piloto no solo debe haber una ventana de chat, sino también un corpus documental versionado, preguntas de prueba, mediciones de calidad separadas, un registro de errores, comprobaciones de acceso y una decisión sobre lo que la solución no puede hacer. Conviene fijar las posteriores necesidades de integración con la misma claridad que en cualquier otro proyecto digital, siguiendo el principio descrito en el artículo sobre los 10 errores al encargar el desarrollo de una página web: los criterios de aceptación y los responsables se determinan antes de la implantación completa, no después de la primera pantalla impresionante.

El piloto solo continúa si alcanza los umbrales definidos de antemano en la parte del conjunto de pruebas que no ha visto, trata de forma segura las preguntas no autorizadas y las que no tienen respuesta, y aporta una mejora medible al trabajo de las personas. Si la recuperación no encuentra sistemáticamente la fuente correcta, primero se corrigen los documentos, los metadatos y el índice; si la fuente es correcta pero la generación la tergiversa, se cambia el contexto, el prompt o el modelo; si el error solo aparece en decisiones de alto riesgo, estas decisiones se dejan en manos de un sistema determinista y de una persona. Detener un piloto no es un fracaso: es una prueba obtenida a bajo coste de que, para ese proceso concreto, los límites de RAG importan más que el efecto de la demostración.