De preguntas sin respuesta a mejor documentación: revisión semanal de brechas de conocimiento
Flujo semanal de 30 minutos para diagnosticar preguntas sin respuesta, asignar responsables, corregir la fuente adecuada y volver a probar.
Es fácil atribuir una pregunta sin respuesta a un mal prompt. Cuando la misma duda aparece varias veces, la señal es distinta: la empresa no está entregando de forma fiable el conocimiento que las personas necesitan para trabajar.
La respuesta útil no consiste en subir archivos al azar. Consiste en revisar una cola pequeña y distinguir entre conocimiento ausente, problemas de recuperación, permisos incorrectos, fuentes antiguas y preguntas ambiguas. El resultado debe ser un backlog de mejoras concretas con responsable, no un panel que nadie atiende.
Esta guía ofrece a operaciones, RR. HH., soporte, cumplimiento y responsables de conocimiento un flujo semanal práctico. Está pensado para una pyme: treinta minutos, pocas prioridades, responsables claros y una prueba antes de cerrar cada elemento.
Qué es una brecha de conocimiento
Existe una brecha de conocimiento cuando una persona necesita información para completar una tarea real, pero el sistema de conocimiento aprobado no puede ofrecer una respuesta fiable. La causa puede ser:
- La política o el procedimiento nunca se documentó.
- El documento correcto existe, pero no está conectado o indexado.
- Hay dos versiones contradictorias y nadie sabe cuál es la vigente.
- Los permisos ocultan la fuente a una persona que debería consultarla.
- La respuesta cita un documento que no respalda la afirmación.
- La pregunta plantea una excepción que el procedimiento actual no cubre.
- La persona usa un lenguaje que la fuente o el sistema de recuperación no interpreta bien.
La diferencia importa. Redactar una página nueva no corrige un permiso erróneo. Volver a indexar una carpeta no resuelve dos políticas contradictorias. Una buena revisión diagnostica el problema en su propietario antes de elegir la solución.
Para entender el marco general, consulta calidad de respuesta, fuentes y brechas de conocimiento. La definición de brecha de conocimiento ayuda a que todo el equipo use el mismo vocabulario.
Por qué revisar las brechas cada semana
Knowledge-Centered Service, mantenido por el Consortium for Service Innovation, considera que el conocimiento debe responder a la demanda: las solicitudes reales revelan lo que las personas necesitan y el uso forma parte de la revisión. El marco AI RMF de NIST también plantea una gestión continua e iterativa y la incorporación periódica de feedback evaluado. La guía de Microsoft para RAG añade un matiz técnico importante: hacen falta preguntas representativas y feedback humano para saber si una respuesta débil falló en la recuperación, en la generación o en otro componente.
Estas ideas permiten aplicar una regla sencilla: no adivines qué documentar después. Parte de preguntas reales, diagnostica el fallo, corrige el propietario más pequeño y vuelve a probar.
La frecuencia semanal permite detectar patrones cuando el contexto todavía está fresco y sigue siendo asumible para una pyme. Los equipos de alto riesgo pueden atender antes los casos urgentes; la revisión semanal gestiona la cola normal.
Flujo semanal de 30 minutos
1. Agrupa preguntas repetidas
Reúne las preguntas sin respuesta, las respuestas de baja confianza, las citas ausentes y el feedback negativo de la semana anterior. Fusiona variantes que representan el mismo trabajo.
“¿Dónde está el formulario de permiso parental?” y “¿Qué documento inicia el permiso parental?” pueden pertenecer a una misma brecha. “¿Puede mi responsable ver un adjunto médico?” es una pregunta distinta sobre permisos y no debe fusionarse solo porque también menciona un permiso laboral.
Conserva la redacción original. Refleja el lenguaje que usa la plantilla y servirá como prueba realista después.
2. Revisa la respuesta y sus fuentes
Lee la respuesta intentada, los fragmentos citados y el comentario de la persona. Después comprueba si existe una fuente autorizada.
Clasifica el fallo antes de editar:
| Fallo | Acción mínima útil |
|---|---|
| No existe una fuente aprobada | Redactar o aprobar el procedimiento ausente |
| La fuente existe, pero no aparece | Conectarla o ingerirla |
| Se recupera una versión equivocada | Archivar, etiquetar o sustituir la fuente antigua |
| La fuente correcta está oculta | Corregir la regla de acceso en su propietario |
| La cita no respalda la respuesta | Mejorar recuperación, ranking o comportamiento de respuesta |
| La pregunta es ambigua | Añadir contexto a la pregunta y respuesta esperadas |
| Una excepción válida no está documentada | Actualizar la política propietaria con la excepción |
Así se evita que el equipo de documentación se convierta en el destino de cualquier fallo de IA.
3. Prioriza por impacto operativo
Una brecha merece prioridad cuando se repite, afecta a muchas personas, bloquea un proceso frecuente, crea exposición legal o de seguridad, o hace que los clientes reciban respuestas incoherentes.
No inventes una puntuación precisa cuando los datos no la permiten. Basta con ordenar una cola corta:
- Brechas de seguridad, legales, financieras, de privacidad o control de acceso.
- Brechas repetidas que bloquean trabajo activo.
- Preguntas de onboarding o que generan muchas interrupciones.
- Mejoras útiles con propietario conocido.
- Dudas puntuales que pueden esperar a reunir más evidencia.
El número de apariciones ayuda, pero el impacto puede pesar más que la frecuencia. Una pregunta poco común sobre borrado de datos de clientes puede importar más que diez preguntas sobre una plantilla de oficina.
4. Asigna un responsable y una fecha
Cada brecha aceptada necesita una persona responsable de decidir qué cambia. No tiene por qué ser quien redacte el documento final. RR. HH. es propietario de la norma de permisos; TI puede corregir la carpeta; una persona responsable de conocimiento puede editar la página.
Añade una fecha, una nota interna breve y la respuesta o resultado esperado. Si nadie identifica al propietario, esa ausencia también es un problema operativo que conviene escalar.
5. Aplica la corrección duradera más pequeña
Prefiere modificar la fuente autorizada existente. Solo tiene sentido crear una página cuando ninguna fuente actual cubre la misma intención.
Una buena corrección puede ser:
- añadir una excepción ausente a la política aprobada;
- sustituir un archivo obsoleto;
- enlazar la carpeta correcta;
- corregir un tipo de documento o un rol;
- crear un procedimiento breve desde una resolución de soporte repetida;
- registrar que la empresa todavía no tiene una respuesta aprobada.
El objetivo no es producir más documentación. Es reducir la distancia entre una pregunta real y una respuesta fiable.
6. Repite la pregunta exacta y una variante
Formula de nuevo la pregunta original con los mismos permisos. Después prueba una redacción cercana. Comprueba que:
- la persona correcta puede acceder a la respuesta;
- la respuesta utiliza la fuente aprobada;
- la cita respalda la afirmación material;
- la fuente antigua no vuelve a aparecer;
- el sistema reconoce que no sabe cuando sigue faltando evidencia.
Microsoft recomienda preguntas de evaluación representativas y actualizadas porque un sistema RAG contiene varios componentes que interactúan. Una única formulación correcta no demuestra que la brecha esté cerrada.
7. Cierra con evidencia
Registra qué cambió, qué fuente es ahora propietaria de la respuesta, quién lo verificó y cuál fue el resultado de la prueba. Descarta de forma explícita duplicados y preguntas irrelevantes para que no vuelvan a la cola sin explicación.
Una brecha cerrada debe dejar evidencia recuperable de la mejora. “Documentación actualizada” es demasiado vago. “Sustituida la política de permisos de 2024; probadas dos preguntas con una cuenta de empleado; verificada la cláusula citada” sí resulta útil.
Ejemplo práctico
Tres personas recién incorporadas preguntan cómo solicitar equipamiento para teletrabajo. El asistente no encuentra ninguna fuente.
La persona revisora busca primero en los documentos conectados. No existe un procedimiento aprobado, aunque operaciones confirma el proceso actual en un mensaje privado. Por tanto, la brecha es conocimiento no documentado, no un fallo de recuperación.
Operaciones asume la responsabilidad. El equipo añade una sección breve al manual de onboarding con el canal de solicitud, el límite de aprobación, el plazo previsto y la vía para excepciones. El manual actualizado sustituye a la versión anterior. Después se repiten las tres preguntas originales con una cuenta normal de empleado y se revisa la sección citada.
Solo entonces se cierra la brecha. La corrección mejora el onboarding, reduce interrupciones futuras y deja una única fuente autorizada.
Cómo ayuda Polp
El flujo actual de Polp puede detectar brechas a partir de respuestas de baja confianza, ausencia de fuentes o feedback negativo. Los administradores de empresa pueden revisar las brechas, asignar responsables, definir prioridad y fecha, añadir notas y una respuesta esperada, enlazar o subir una fuente y resolver, descartar o reabrir cada elemento.
El flujo no decide la verdad por la empresa. Convierte la señal en una tarea y mantiene juntos la fuente, el responsable y la resolución. Empieza con la guía de primeros pasos de Polp y prueba unas pocas preguntas reales antes de ampliar el conjunto documental.
Si quieres probar este ciclo con documentos y permisos representativos de tu empresa, solicita una demo de Polp.
Checklist para una empresa pequeña
Cada revisión semanal debe terminar con:
- una lista deduplicada de preguntas reales;
- un tipo de fallo diagnosticado;
- una cola ordenada;
- un responsable y una fecha para cada brecha aceptada;
- la corrección mínima en la fuente autorizada;
- una prueba con los permisos previstos;
- evidencia para cerrar o descartar el elemento.
Una base de conocimiento mejora gracias a este ciclo. El mejor backlog no es el más largo, sino el que convierte de forma repetida preguntas reales en conocimiento más claro, vigente y respetuoso con los permisos.