Qué documentos sirven de verdad para alimentar un copilot interno

Muchas empresas se plantean un copilot interno como si el problema principal fuera elegir modelo o proveedor. En la práctica, el resultado depende mucho más de otra cosa: qué documentación existe, en qué estado está y hasta qué punto se puede recuperar con contexto suficiente. Un copilot no mejora por tener “muchos documentos”; mejora cuando la base documental responde bien a preguntas reales de trabajo.

La cuestión clave no es cuántos archivos podéis indexar, sino cuántos de ellos ayudan a contestar con seguridad, trazabilidad y contexto. Si la documentación está duplicada, desactualizada o sin dueño, el copilot puede sonar convincente y aun así responder mal. Por eso la preparación documental suele ser una parte más importante del proyecto que la propia interfaz conversacional.

¿Qué documentos funcionan bien con un copilot?

Funcionan especialmente bien los documentos orientados a procesos, criterio y contexto operativo. Es decir, materiales que ya ayudan a una persona nueva o a un equipo transversal a entender cómo hacer algo, cuándo aplica una excepción y dónde mirar si hay dudas.

Este tipo de documentación funciona porque contiene reglas, contexto y lenguaje de negocio. No obliga al sistema a improvisar. Le permite recuperar piezas concretas y apoyarse en ellas para responder.

Documentos que generan problemas

También hay documentación que parece abundante pero aporta poco. No porque sea inútil en sí misma, sino porque está mal preparada para un sistema que debe recuperar, citar y responder con criterio.

• Presentaciones antiguas con mensajes comerciales pero poca instrucción operativa.
• PDFs escaneados sin texto recuperable o con tablas ilegibles.
• Versiones duplicadas de la misma política repartidas entre carpetas y correos.
• Documentos sin fecha ni owner claro, donde nadie puede confirmar cuál es la versión vigente.
• Notas sueltas o actas poco estructuradas que mezclan decisiones, hipótesis y comentarios informales.

El problema no es solo técnico. Es de confianza. Si un usuario no puede distinguir entre una política vigente y un borrador perdido en SharePoint, el copilot tampoco debería actuar como si ambas fuentes valieran lo mismo.

Cómo preparar la documentación para el copilot

La preparación útil suele ser menos espectacular y más disciplinada de lo que se imagina. No empieza por “subir todo”, sino por ordenar qué fuentes merecen entrar primero y bajo qué reglas.

1. 1Selecciona un conjunto inicial de documentos con alto valor operativo y bajo riesgo: políticas, procedimientos, guías de soporte o manuales internos.
2. 2Elimina duplicados evidentes y define cuál es la versión vigente de cada documento relevante.
3. 3Añade contexto mínimo: fecha de revisión, owner, área responsable y, si aplica, ámbito de uso.
4. 4Separa documentación normativa de contenido orientativo o borradores.
5. 5Prueba preguntas reales con usuarios reales antes de ampliar el corpus.

Este trabajo encaja muy bien con una base de conocimiento preparada para IA y con una revisión de permisos y gobierno si el copilot va a operar sobre información sensible.

Una taxonomía mínima mejora más que mil documentos extra

Muchas empresas intentan compensar una mala base documental con volumen. Es un error. Un copilot suele mejorar más cuando existe una taxonomía mínima y consistente que cuando simplemente aumentan los archivos indexados. Etiquetar por proceso, área, tipo de documento, vigencia y criticidad ya permite recuperar mejor, filtrar mejor y gobernar mejor.

Checklist rápida para decidir qué entra y qué no entra en el corpus

Además, esta checklist obliga a tomar una decisión útil sobre cada fuente: entra ahora, se transforma antes de entrar o se queda fuera del piloto. Esa claridad reduce mucho la tentación de indexar por volumen en vez de por valor.

Gobierno, permisos y responsabilidades

Un copilot interno no solo necesita encontrar documentos; necesita encontrarlos con la política de acceso correcta. Si un usuario no debería ver cierta información en su flujo normal, el asistente tampoco debería exponerla por un atajo conversacional. Por eso los permisos y el gobierno no son una fase posterior: son parte del diseño del caso.

• Define qué repositorios entran en el alcance inicial y cuáles no.
• Aclara quién es responsable de la vigencia del contenido por área.
• Decide cómo se tratarán borradores, plantillas internas o documentación caducada.
• Asegura trazabilidad suficiente para que el usuario pueda verificar la fuente cuando la respuesta sea sensible.

Si el corpus incluye contratos, datos personales o documentación sensible, conviene revisar también el encaje con RGPD y copilots con RAG antes de ampliar el uso a toda la compañía.

Qué no conviene hacer

• Indexar todo el repositorio documental como primer paso sin criterio de utilidad ni riesgo.
• Pensar que un buen prompt compensará una documentación pobre, desactualizada o contradictoria.
• Mezclar fuentes normativas, comerciales y borradores sin una jerarquía clara.
• Lanzar a toda la empresa antes de validar un conjunto pequeño de preguntas de alto valor.
• Medir el proyecto solo por número de respuestas generadas y no por fiabilidad, tiempo ahorrado y reducción de dependencia interna.

El error más frecuente: confundir alimentar con entrenar

Uno de los malentendidos más comunes es pensar que preparar documentos para un copilot equivale a entrenar un modelo desde cero. En la mayoría de proyectos empresariales no ocurre eso. Lo que haces es organizar, conectar y recuperar mejor el conocimiento existente para que el sistema pueda responder con base documental. Por eso el trabajo principal no es “enseñar IA”, sino gobernar conocimiento.

Ese enfoque es el que suele funcionar en los casos de uso de copilots en empresa: primero se delimita el conocimiento y el flujo, luego se prueba con usuarios, y solo después se escala.

Secuencia prudente para un piloto útil

1. 1Empieza con un caso donde las preguntas sean repetitivas y la documentación ya tenga cierta calidad.
2. 2Limita el corpus inicial a unas pocas fuentes confiables y con owner conocido.
3. 3Valida respuestas con usuarios que realmente hagan ese trabajo cada día.
4. 4Mide tiempo de resolución, tasa de escalado y necesidad de corrección manual.
5. 5Amplía a nuevas áreas solo cuando el primer perímetro funciona de forma estable.

Esa secuencia también ayuda a diseñar expectativas realistas. Un buen piloto no intenta responder cualquier pregunta de la empresa; intenta resolver muy bien un conjunto concreto de consultas donde el conocimiento ya existe y donde la respuesta puede verificarse. Esa disciplina es la que luego permite ampliar sin degradar confianza.

Si el objetivo es convertir esa base documental en una capacidad sostenible, el siguiente paso natural suele ser una solución de copilot RAG para empresa apoyada por cierto gobierno del dato y calidad.

Preguntas frecuentes sobre documentación para un copilot interno

¿Hace falta tener toda la documentación perfecta antes de empezar?

No. Hace falta empezar por un subconjunto útil, vigente y gobernado. La perfección total es irreal; el perímetro controlado sí es viable.

¿Qué pesa más: cantidad de documentos o calidad?

La calidad y la gobernanza pesan mucho más. Mil documentos dudosos suelen rendir peor que cien bien seleccionados.

¿Sirven los PDFs y presentaciones existentes?

A veces sí, pero solo si el contenido es recuperable, vigente y suficientemente explícito. Muchos materiales corporativos se parecen más a soporte comercial que a base de conocimiento operativa.

¿Cuál es la mejor señal de que el corpus inicial está bien elegido?

Que responde con solvencia a preguntas reales de trabajo y reduce dependencia de expertos para tareas repetitivas sin comprometer seguridad ni contexto.