---
title: "Cómo hacer un agente bibliotecario para mantener SOPs al día"
description: "Un playbook para organizar la documentación operativa, detectar SOPs desactualizados y proponer cambios que una persona revisa antes de publicar."
author: "Carlos García"
published: 2026-10-11
updated: 2026-10-11
language: es
human_url: "https://kiia.cloud/es/blog/como-hacer-agente-bibliotecario-sops/"
---

> **En 60 segundos:** Construí un agente bibliotecario que mantenga visible la diferencia entre evidencia, propuesta y SOP publicado. Primero declarás qué sistema manda para cada tipo de documento y quién es su owner. Después organizás el second brain por procesos, reglas, excepciones y responsables; guardás las reglas operativas como datos editables, no dentro del prompt; y conectás señales de cambio como tickets resueltos, modificaciones de sistemas o fechas de revisión. El agente encuentra contradicciones y prepara un diff con fuentes, impacto y nivel de confianza. Una persona aprueba el contenido exacto antes de que reemplace la versión vigente. Empezá con un proceso recurrente y medí cobertura de cambios, cola de revisión, contradicciones abiertas y correcciones humanas. El objetivo es ayudar al equipo a mantener su memoria operativa, no convertir al modelo en dueño del proceso.

En un equipo de operaciones, una persona aprende que cierto pedido excepcional ya no se procesa como dice el manual. Lo resuelve, avisa por chat y sigue trabajando. Meses después, otra persona encuentra el SOP antiguo, ejecuta los pasos publicados y descubre demasiado tarde que el sistema cambió.

En una distribuidora puede pasar algo parecido: el procedimiento dice que una aprobación ocurre por correo, pero el equipo ya la registra en el ERP. La práctica real, la política aprobada y el documento publicado empiezan a contar historias distintas.

Un agente bibliotecario sirve para cerrar ese ciclo. No escribe la política de la empresa ni decide cuál versión “suena mejor”. Observa fuentes autorizadas, relaciona evidencia con el SOP afectado, propone una modificación y lleva esa propuesta al responsable correcto. El resultado final sigue siendo una decisión humana y auditable.

Esta nota continúa la serie “Cómo hacer un agente X”. El [agente de pedidos](/es/blog/como-hacer-agente-pedidos-intake-despacho/) necesita procedimientos vigentes para tratar excepciones, y el [agente de postventa](/es/blog/como-hacer-agente-postventa-whatsapp/) necesita conocimiento aprobado para responder. El bibliotecario trabaja detrás de ambos: mantiene las instrucciones revisables sin asumir su autoridad operativa.

## 1. Definí el trabajo y el punto de parada

“Mantener la documentación al día” es demasiado amplio para construirlo. El primer contrato puede expresarse como una transición observable:

```text
señal de cambio
  -> SOP y owner identificados
  -> evidencia reunida + contradicciones visibles
  -> propuesta de cambio
  -> aprobación o rechazo humano
  -> versión publicada + registro de decisión
```

El agente puede leer, comparar, clasificar y redactar. No debería publicar silenciosamente ni convertir una conversación aislada en política. Su trabajo termina en uno de estos estados:

- propuesta pendiente, con revisor y fecha;
- propuesta aprobada y publicada por el flujo autorizado;
- propuesta rechazada, con motivo;
- evidencia insuficiente, asignada al owner del proceso; o
- conflicto entre fuentes que necesita una decisión.

“El documento fue actualizado” tampoco basta. El registro debe decir qué cambió, por qué, qué fuentes se consultaron, quién aprobó y qué versión quedó vigente.

## 2. Declarale qué fuente manda para cada cosa

El agente no puede resolver contradicciones si todas las carpetas, chats y sistemas tienen la misma autoridad. Antes de conectarlo, construí un registro de fuentes.

| Contenido | Fuente autorizada | Evidencia secundaria | Regla cuando difieren |
| --- | --- | --- | --- |
| SOP publicado | Biblioteca documental o repositorio declarado | Copias exportadas, PDF enviado por chat | La copia no reemplaza la versión publicada |
| Política y límites | Registro aprobado por el área responsable | Mensajes, minutas, tickets | Escalar al owner; no inferir una regla nueva |
| Secuencia real del sistema | Configuración, API o manual vigente del sistema | Capturas y grabaciones | Marcar el SOP como posiblemente desactualizado |
| Excepciones resueltas | Sistema de casos o tickets | Chat interno | Proponer una excepción solo con caso y resolución trazables |
| Responsables | Directorio o matriz operativa aprobada | Firma del documento | Pedir reasignación si el owner ya no es válido |
| Regla de cumplimiento | Área legal, seguridad, calidad o regulación aplicable | Resúmenes internos | Bloquear publicación hasta revisión especializada |

Para cada fuente guardá alcance, ubicación, owner, audiencia, permisos, versión o fecha de vigencia y política de retención. El sistema publicado puede ser SharePoint, un wiki, un repositorio u otra biblioteca: importa el contrato, no la marca.

Chats y reuniones son sensores útiles. Pueden indicar que la práctica cambió, pero no deberían ascender por sí solos a fuente normativa. Si alguien escribe “desde hoy lo hacemos de otra forma”, el agente abre una propuesta y solicita evidencia; no reescribe el SOP.

## 3. Estructurá el second brain para recuperar decisiones

Una carpeta llena de archivos no es todavía un second brain operativo. El agente necesita encontrar la unidad correcta sin mezclar un procedimiento publicado con un borrador o una excepción local.

Usá una estructura con cuatro capas:

1. **Procesos.** Objetivo, alcance, evento de inicio, resultado esperado, sistemas implicados y SOPs relacionados.
2. **Reglas.** Condiciones explícitas que gobiernan una decisión: quién puede aprobar, qué campos son obligatorios o qué transición está permitida.
3. **Excepciones.** Situaciones que salen del camino ordinario, evidencia requerida, responsable y condición para volver al flujo.
4. **Responsables.** Owner del proceso, owner de cada SOP, revisores delegados y equipo que ejecuta.

Cada SOP debería llevar metadatos mínimos:

```yaml
sop_id: OPS-ORDER-014
status: published
owner: operations-order-management
reviewers: [finance, warehouse]
audience: order-operations
systems: [erp, warehouse-management]
effective_from: 2026-09-01
review_by: 2026-12-01
supersedes: OPS-ORDER-014@6
related_rules: [RULE-CREDIT-03, RULE-STOCK-08]
```

Los nombres son ilustrativos. Adaptalos al vocabulario actual del equipo. Lo importante es conservar IDs estables y distinguir `draft`, `pending_review`, `published`, `superseded` y `retired`. El buscador que usan personas y agentes debería devolver por defecto la versión publicada aplicable a su audiencia, sin ocultar que existe una propuesta pendiente.

El patrón se parece al [second brain para expedientes](/es/blog/second-brain-litigio-agentes-expedientes/): separar archivo, índice, estado y permisos evita depender de que el modelo “recuerde” dónde estaba cada cosa.

## 4. Sacá las reglas operativas del prompt

Un prompt puede explicar el rol del agente: comparar fuentes, no publicar sin aprobación, mostrar evidencia y detenerse ante conflictos. No debería contener la lista viva de aprobadores, plazos, estados del ERP o condiciones de excepción.

Guardá esas reglas en un registro editable por el equipo, con esquema y control de versiones. Por ejemplo:

| Campo | Ejemplo | Quién lo edita |
| --- | --- | --- |
| `rule_id` | `RULE-STOCK-08` | Owner de operaciones |
| `applies_to` | Pedidos locales con stock confirmado | Owner del proceso |
| `condition` | El ERP devuelve reserva válida | Operaciones y sistemas |
| `required_evidence` | ID de reserva y hora de consulta | Operaciones |
| `approver_role` | Supervisor de almacén | Responsable del área |
| `effective_from` / `expires_at` | Ventana de vigencia | Owner de la regla |
| `fallback` | Crear excepción de stock | Owner del proceso |

El agente consulta la versión vigente en cada ejecución y conserva el ID utilizado. Un cambio de regla pasa por su propio flujo de revisión. Así el equipo puede corregir una política sin desplegar código ni editar instrucciones ocultas, y una auditoría puede reconstruir qué regla produjo cada propuesta.

No conviertas texto libre en un motor de decisiones sin controles. Los campos que bloquean o habilitan acciones deben validarse con tipos, valores permitidos y fechas. El modelo puede explicar una regla o localizar la sección afectada; la capa determinista decide si esa regla está vigente y quién puede aprobarla.

## 5. Dale herramientas estrechas y permisos separados

El agente necesita operaciones limitadas, no una credencial personal con acceso a todo el conocimiento de la empresa:

1. **Índice documental.** Busca solo en colecciones y audiencias permitidas; devuelve fragmento, ID, versión, estado y fecha de revisión.
2. **Registro de reglas.** Lee reglas vigentes y propone cambios estructurados. No modifica la versión publicada directamente.
3. **Lectura de señales.** Consulta eventos autorizados de tickets, cambios de sistemas, releases o incidencias. Debe poder enlazar cada señal con su fuente original.
4. **Bandeja de revisión.** Crea una propuesta con diff, evidencia, impacto, preguntas abiertas y revisor. Devuelve un ID y conserva cada decisión.
5. **Publicador controlado.** Solo acepta una propuesta aprobada, verifica que el contenido y la versión base no cambiaron, publica una nueva versión y relee el resultado.

Separá lectura, propuesta, aprobación y publicación como permisos distintos. La persona que revisa necesita ver el diff exacto, no solo un resumen del agente. Si cambia una frase, una fuente, un adjunto o la versión base, la aprobación anterior deja de aplicar.

Aplicá mínimo privilegio también a los revisores. Un owner de almacén puede aprobar su procedimiento sin obtener acceso a documentación de recursos humanos o contratos. Evitá indexar secretos, credenciales, PII innecesaria o contenido fuera de la audiencia del agente.

## 6. Diseñá la propuesta antes que la escritura

La unidad de trabajo es una propuesta de cambio, no un documento reescrito completo. Un payload revisable puede incluir:

```text
proposal_id
sop_id + base_version
sections_affected
before / after diff
reason_code
source_ids + timestamps
conflicts_found
impact_area
confidence + unknowns
owner + required_reviewers
```

Usá códigos de motivo estables: cambio de sistema, política modificada, excepción repetida, fecha de revisión vencida, responsable inválido o contradicción documental. La confianza puede ordenar la cola; no sustituye la aprobación.

El ciclo mínimo es:

1. Deduplicar la señal y localizar el SOP aplicable.
2. Releer la versión publicada, sus reglas y propuestas abiertas.
3. Recuperar la evidencia con permisos y fechas.
4. Preparar un diff pequeño; dejar preguntas explícitas cuando falta información.
5. Enrutar al owner y a revisores adicionales según las reglas.
6. Aprobar, solicitar cambios o rechazar sobre el payload exacto.
7. Verificar que la versión base siga vigente.
8. Publicar por la interfaz autorizada y releer la nueva versión.
9. Notificar a la audiencia afectada y conservar el registro de decisión.

Si dos personas editan el mismo SOP, el control de versión debe bloquear una publicación construida sobre una base vencida. El agente regenera el diff; no fusiona silenciosamente decisiones humanas.

## 7. Detectá obsolescencia con señales, no con adivinanzas

La fecha de revisión es una señal, no una prueba automática de que el contenido está mal. Combiná varias detecciones:

| Señal | Qué compara el agente | Salida segura |
| --- | --- | --- |
| Revisión vencida | `review_by` frente a la fecha actual | Tarea para el owner, sin cambiar el SOP |
| Contradicción | Dos instrucciones publicadas aplicables a la misma condición | Bloqueo o advertencia con ambas fuentes |
| Cambio de sistema | Campos, pantallas, estados o permisos vigentes frente al procedimiento | Propuesta sobre los pasos afectados |
| Excepción resuelta | Casos trazables repetidos frente a las excepciones documentadas | Candidato a regla o excepción; no publicación automática |
| Enlace o owner inválido | Destino inaccesible o responsable ausente | Reparación administrativa para revisión |
| Diferencia entre práctica y documento | Evidencia operativa autorizada frente al SOP | Pregunta al owner; la práctica no gana por frecuencia |

Las reglas de caducidad deben depender del riesgo y del ritmo de cambio del proceso. No inventes un calendario universal. Un procedimiento afectado por un cambio de ERP puede necesitar revisión inmediata; otro estable puede seguir su ciclo acordado.

Conservá también negativos útiles: “sin evidencia suficiente”, “dos fuentes autorizadas en conflicto” o “owner no encontrado”. Forzar una conclusión convierte la falta de documentación en una instrucción falsa.

## 8. Mantené a una persona como dueña de cada SOP

El agente apoya cuatro trabajos que consumen tiempo: inventariar, comparar, preparar cambios y perseguir revisiones. La responsabilidad sigue repartida entre personas concretas:

| Rol | Responsabilidad |
| --- | --- |
| Owner del proceso | Define la política y resuelve contradicciones de negocio |
| Owner del SOP | Mantiene alcance, vigencia, audiencia y revisores |
| Revisor especializado | Valida efectos en seguridad, legal, finanzas, calidad o sistemas |
| Equipo ejecutor | Reporta fricción y evidencia de que el procedimiento no coincide con la operación |
| Administrador del agente | Mantiene conectores, permisos, evaluaciones y respuesta a incidentes |

Un documento sin owner es una excepción abierta. No la resuelvas asignándosela al agente. Si el equipo no sabe quién puede aprobar una regla, el problema es de gobierno y debe quedar visible.

El [NIST AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/) propone definir roles y responsabilidades para la supervisión humana de sistemas de IA. Acá eso significa nombrar quién revisa cada tipo de cambio, qué evidencia necesita y cómo detiene o revierte una publicación.

## 9. Empezá con un alcance que se pueda revisar

Elegí un proceso recurrente, una colección documental, una familia de reglas y un equipo owner. Un buen primer caso tiene cambios observables, historial de versiones y suficientes ejemplos recientes para probar contradicciones y propuestas. Evitá empezar por políticas legales, seguridad crítica o procesos sin responsable.

Durante la primera fase, trabajá en modo sombra: el agente indexa, detecta y redacta, pero ninguna propuesta altera la versión publicada. Revisá con el equipo si eligió el SOP correcto, si las fuentes justifican el cambio, si el diff es mínimo y si llegó a la persona adecuada.

Después podés habilitar el flujo de aprobación y publicación controlada. Mantené la revisión humana para cada cambio. La autonomía inicial está en recopilar evidencia, crear la propuesta y enrutarla; no en decidir política.

Medí señales que el equipo pueda auditar:

| Señal | Definición local |
| --- | --- |
| Cobertura de cambios | Señales elegibles que terminaron en propuesta, decisión o cierre justificado / señales elegibles revisadas |
| Calidad de propuesta | Propuestas aprobadas sin cambios, editadas, rechazadas o cerradas por falta de evidencia |
| Cola de revisión | Propuestas abiertas por antigüedad, owner y motivo de bloqueo |
| Documentación en conflicto | Contradicciones abiertas, resueltas y reabiertas por proceso |
| Vigencia | SOPs dentro del ciclo acordado y SOPs vencidos con owner asignado |
| Fallos de control | Publicaciones sin aprobación, sobre una versión vencida o fuera de audiencia; el objetivo operativo es que no ocurran |

Tomá una línea base antes del piloto y conservá conteos y denominadores. No conviertas propuestas producidas en una métrica de éxito: un agente que genera cambios innecesarios solo crea otra bandeja de trabajo.

## 10. Reconocé cuándo no construirlo

No construyas el agente todavía si el equipo no puede declarar cuál copia está vigente, nadie puede aprobar cambios, los sistemas no conservan versiones o el acceso documental no respeta audiencias. Tampoco conviene si la documentación contiene PII o secretos mezclados sin clasificación, o si casi todas las decisiones dependen de contexto oral imposible de verificar.

Primero nombrá owners, consolidá duplicados, definí estados y agregá un flujo manual de propuesta y aprobación. El agente amplifica ese contrato; no lo reemplaza.

Mantené el alcance en apoyo al equipo. El bibliotecario no evalúa el desempeño de personas, no convierte excepciones en sanciones y no borra versiones históricas. Su valor está en que una decisión operativa tenga una ruta visible hasta la instrucción publicada.

## Fuentes y vigencia

Fuentes oficiales revisadas el **11 de octubre de 2026**. El control CM-3 de [NIST SP 800-53 Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) describe un ciclo de proponer, revisar, aprobar o rechazar, documentar, implementar y supervisar cambios controlados; lo usamos como referencia de diseño, no como requisito regulatorio general. La documentación de [Microsoft sobre versionado y aprobación de contenido](https://learn.microsoft.com/en-us/sharepoint/governance/versioning-content-approval-and-check-out-planning) confirma que una biblioteca puede conservar versiones y mantener un borrador pendiente hasta su aprobación; SharePoint es un ejemplo de capacidad, no una recomendación obligatoria. Las reglas y obligaciones aplicables a cada empresa deben validarse con sus responsables.

Kiia puede mapear las fuentes, los owners y el flujo de aprobación de un proceso antes de conectar un agente. Traé SOPs vigentes, cambios recientes y excepciones anonimizadas: con eso se puede identificar un primer alcance seguro y una línea base real.

## Preguntas frecuentes

### ¿El agente bibliotecario puede actualizar un SOP por su cuenta?

No en el alcance inicial. El agente reúne evidencia, señala la sección afectada y prepara un cambio exacto. El owner del SOP o su revisor delegado aprueba o rechaza esa versión antes de publicarla. La aprobación vence si cambia el contenido propuesto.

### ¿Dónde deberían vivir los SOPs?

En el sistema que el equipo declare como fuente publicada, con historial de versiones, permisos y un owner claro. Tickets, chats, grabaciones y manuales de proveedor pueden aportar evidencia, pero no deberían convertirse automáticamente en instrucciones vigentes.

### ¿Cómo saber si el agente está funcionando?

Observá si los cambios relevantes terminan en propuestas trazables, cuánto permanece cada propuesta en revisión, qué contradicciones o documentos vencidos siguen abiertos y cuántas correcciones hacen los revisores. Definí una línea base propia antes de fijar objetivos; no uses un benchmark genérico.