Cómo construimos un agente institucional que navega Excel con grep, no con embeddings

Cuando Marcelo, vicerrector de la UBO, nos contactó, ya habían intentado crear un agente institucional que los ayudara a tomar decisiones en base a sus datos: enchufaron Microsoft Copilot a su biblioteca de documentos y no funcionó. La pregunta era por qué, y qué camino alternativo existía.

La respuesta corta —y la tesis de este post— es que el problema nunca fue el modelo. Fue la arquitectura de cómo obtener la información. La mayoría de los agentes institucionales fallan por la misma razón: tratan al Excel como si fuera texto libre, cuando es un filesystem estructurado.

Qué es la UBO y qué necesitaban

La UBO es una universidad privada con presencia en Santiago. Como cualquier institución con varias décadas encima, su conocimiento operacional vive en planillas: mallas curriculares, indicadores de acreditación, calendarios, y varias decenas de fuentes más. Archivos Excel mantenidos por distintas áreas, con convenciones distintas, y actualizados a ritmos distintos.

Tres roles convergen sobre ese conocimiento:

Dirección — rector, vicerrectorías, decanaturas.
Coordinación Académica — gestión de carreras y mallas.
Administración — RRHH, finanzas, servicios generales.

Cada uno necesita respuestas rápidas a preguntas puntuales ("¿cuál es la carga docente de Pedagogía en Matemática este semestre?", "¿cuál es la retención de Medicina?") y cada uno tiene acceso legítimo a un subconjunto distinto de la información. Un agente institucional sirve si respeta esa asimetría. Si no, o bien filtra datos sensibles o bien es inútil.

Por qué Copilot no funcionó

No voy a especular sobre la implementación exacta, pero el patrón es conocido: Copilot sobre SharePoint hace retrieval semántico sobre el texto completo de los documentos, incluidos los Excel convertidos a una aproximación textual. Dos problemas duros:

Excel no es texto libre. Una fila es una tupla con tipos (nombre, identificador, jornada, contrato). Hacer similitud de embeddings sobre su representación textual funciona mal para preguntas exactas como "¿qué carga docente tiene María Sánchez?". El embedding cercano puede ser de otra persona con nombre parecido o de un documento genérico sobre carga docente. La respuesta sale confiada y equivocada.
Permisos gruesos. Copilot hereda los permisos de SharePoint, que suelen ser a nivel carpeta. Para un modelo de 3 perfiles con acceso a distintos archivos dentro del mismo directorio, no alcanza.

No es culpa de Copilot como producto. Es que la arquitectura de propósito general no encaja con los datos institucionales estructurados + control fino de acceso.

La apuesta: grep, no embeddings

El agente está construido sobre una decisión arquitectónica concreta: tratamos al Excel como un filesystem y dejamos que el agente lo navegue con grep y python, no con similitud vectorial.

En la ingesta, cada archivo Excel se transforma en una representación triple: la planilla original, un snapshot en markdown legible, y un schema JSON con tipos y headers. Esa representación vive en almacenamiento privado. Cuando un usuario hace una pregunta, el agente corre dentro de un sandbox efímero que monta —read-only, por sesión— los archivos que el perfil del usuario tiene permitido ver. Dentro de ese sandbox, el agente usa rg (ripgrep) y Python para buscar, filtrar, agregar y citar.

Upload / SharePoint  →  Pipeline de ingesta  →  Representación triple
                                                  ├── raw (Excel original)
                                                  ├── snapshots (markdown + csv)
                                                  └── schema.json
                                                        │
Pregunta  →  API  →  Sandbox efímero (rg + python + Claude Agent SDK)
                            │
                            ▼
                   Respuesta en streaming + citas

Esto resuelve los dos problemas de Copilot de raíz:

Retrieval exacto. El agente traduce la pregunta del usuario en un comando como rg "María Sánchez" <fuentes-acotadas-al-usuario> sobre la representación estructurada, y cita la celda exacta. Sin alucinación de nombres cercanos.
Aislamiento físico. El sandbox sólo monta los archivos que el perfil del usuario puede ver. Cruzar datos entre perfiles no requiere una política bien configurada — requiere que el sandbox monte archivos que no debería, lo cual es imposible por construcción.

Además, elimina toda una clase de complejidad operacional: no hay pipelines de embedding, no hay reindex cuando cambia un archivo, no hay vector store que mantener. Para un dataset de cientos de archivos (no millones), la complejidad de pgvector no se justifica.

Dos semanas después

Alexis y Bastián, del área de datos de la UBO, hicieron el trabajo de estructurar las fuentes que el agente iba a consumir: decidir qué archivos entran, quién los mantiene, a qué perfil responden. Sin ese trabajo, ningún chatbot —grep-first, RAG, o Copilot— habría servido.

Al cabo de dos semanas de construcción, le presentamos al rector un MVP funcional desde su celular. Inicio de sesión con dominio institucional, chat con respuestas citadas sobre datos reales, y la capacidad de preguntar cosas concretas como "¿cuál es la carga docente de Ingeniería Civil este semestre?" y recibir una tabla citada al archivo fuente.

Qué entregamos

La entrega completa fue de 6 semanas, dividida en tres fases:

Fase 1 — Núcleo funcional: inicio de sesión con dominio institucional, carga manual de archivos, pipeline de ingesta, chat con citas, historial de conversaciones. La versión que vio el rector.
Fase 2 — Integración institucional: SSO con Entra/Google, sincronización automática desde SharePoint, branding UBO, UI de administración, visor de fuentes.
Fase 3 — Cerrojo y traspaso: suite de validación con preguntas de oro, capacitación del equipo interno, traspaso final.

El traspaso fue literal: al cierre de la sexta semana, el repositorio, el dominio, y la plataforma que lo corre se transfirieron 100% a la UBO. La universidad se quedó con su propio software —auditable, operable, extensible— no con un producto SaaS al que tiene que adaptarse.

La importancia de los agentes en instituciones educativas

Es poco probable que exista una solución genérica para satisfacer la necesidad de la UBO. Las SaaS te entregan un producto genérico al que tu operación tiene que acomodarse. Por lo tanto, un agente adaptado al contexto universitario es sumamente importante para tomar decisiones basadas en los datos reales.

Emisso se encarga de desplegar agentes de IA en la operación de las empresas chilenas, entrena a tu equipo en lo que necesita y te entrega el agente funcionando.

Si tú también tienes datos institucionales atrapados en Excel y SharePoint —y ya probaste lo obvio sin éxito— escríbenos. La arquitectura grep-first no es para todo el mundo, pero cuando aplica, aplica bien.