Cómo hacer un agente bibliotecario para mantener SOPs al día

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 necesita procedimientos vigentes para tratar excepciones, y el agente de postventa 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:

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:

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: 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:

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 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 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 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.