El software, no el modelo, decide si un agente de IA arruina tu Excel: así lo prueba un fork open source

Por Zendoric · 23 de septiembre de 2026.

Paper Instruments, una startup poco conocida hasta ahora, ha publicado Paper Office: tres paquetes de Python de código abierto —paper-docx, paper-pptx y paper-xlsx— que extienden las librerías estándar python-docx, python-pptx y OpenPyxl para que los agentes de IA editen documentos de Word, PowerPoint y Excel sin destrozarlos por dentro. Según el propio informe de la compañía, con cinco modelos y 61 tareas de edición sobre archivos ya existentes, Paper Office elevó la tasa de éxito al 92,5% de los intentos, frente al 80,7% de las librerías originales sin ayuda y al 69,5% obtenido con el kit de skills oficial de Anthropic para Office.

Ese último dato es el que más llama la atención: el complemento oficial de Anthropic para trabajar con archivos de Office rindió peor que no usar ningún complemento en absoluto. Conviene leerlo con cautela — es una cifra publicada por una empresa que compite directamente en este terreno con su propio producto —, pero el patrón de fondo que describe Paper Instruments es consistente y técnicamente verificable: cuando la librería no sabe hacer algo, el modelo improvisa, y esa improvisación sale cara.

Los archivos .docx, .pptx y .xlsx no son texto plano: son archivos ZIP que contienen múltiples fragmentos XML enlazados entre sí (el estándar Office Open XML, u OOXML). Cambiar una palabra visible puede exigir tocar varias piezas a la vez — el enlace entre un comentario y su hilo de respuestas, la caché de un gráfico, el rango de una tabla dinámica. Las librerías estándar, sin actualizaciones importantes en años, no cubren muchos de esos casos. Cuando el agente topa con una operación que la librería no soporta, recurre a escribir código que edita directamente el ZIP interno del archivo — y ahí, según Paper Instruments, se cuelan la mayoría de los errores silenciosos: un hilo de comentarios que pierde el enlace, una fórmula que deja de recalcularse, un gráfico que sigue apuntando a datos antiguos.

El dato que ilustra el mecanismo: los agentes recurrieron a editar el ZIP interno del archivo en el 78,7% de los intentos sin ningún paquete de ayuda, en el 50,5% con las skills de Anthropic, y en solo el 1,6% con Paper Office. La mejora no vino de modelos más listos — se probaron Opus 5, GLM 5.3 Flash, GPT 5.6 Sol, Grok 4.6 y DeepSeek v4.1 Flash, con ganancias en 12 de las 15 combinaciones de modelo y formato — sino de un software que resuelve por el agente la parte mecánica y arriesgada de la edición: localizar el objeto correcto, aplicar el cambio, y comprobar que todo lo demás sigue intacto tras guardar.

Paper Instruments enmarca el problema como el motivo por el que los agentes de IA todavía penetran poco en el trabajo diario de consultores, abogados, banqueros y operadores: no editan los documentos existentes como lo haría una persona, y el resultado —una diapositiva, una hoja de cálculo, un contrato— cae en un valle inquietante que no sirve para enseñarlo a un cliente. Es lo que la compañía llama «brownfield knowledge work»: no crear documentos desde cero, sino tocar los que ya existen, con su historial, sus plantillas heredadas y sus dependencias, sin dejar rastro del error.

Aquí está la lectura que nos interesa. En los últimos meses hemos visto converger la calidad bruta de los modelos de frontera, que compiten hoy en un margen estrecho en los benchmarks que de verdad miden algo. Cuando el modelo deja de ser la variable que más discrimina, la batalla se traslada un piso más abajo: a la fontanería. Ya lo vimos con el reposicionamiento de Google y Microsoft en torno a los estándares de integración de agentes, y lo volvemos a ver aquí, en miniatura: quien construye el software que evita que un agente destroce un Excel de verdad gana más terreno práctico que quien simplemente entrena un modelo un poco mejor.

Esto confirma además algo que ya defendimos en ediciones anteriores: en los dominios donde equivocarse sale caro — un contrato mal editado, una hoja de cálculo que llega a un consejo de administración con una celda desincronizada — la respuesta de producto no es «más inteligencia», es arquitectura defensiva: validar antes de tocar, preservar lo que no se pidió cambiar, y negarse explícitamente cuando la operación no se puede hacer con garantías. Paper Office lo institucionaliza con recibos de edición, diffs de paquete y una capa de «certificación» que recalcula fórmulas con LibreOffice para confirmar que el resultado cuadra. Es ingeniería poco vistosa, pero es exactamente el tipo de trabajo que separa una demo de un producto que un despacho de abogados o un banco de inversión se atreve a poner en manos de un agente sin supervisión constante.

Conviene poner el hallazgo en su tamaño real: es un estudio de una startup pequeña sobre su propio producto —que además desarrolla un harness de agentes, Feather, donde Paper Office viene integrado por defecto—, con 61 tareas y sin revisión independiente todavía. No es la prueba de que el problema esté resuelto, y habrá que ver si otros desarrolladores lo adoptan o lo replican con datos propios. Pero la tendencia de fondo —que el software de bajo nivel, no solo el modelo, determina si un agente puede trabajar de forma fiable sobre documentos reales— probablemente se generalizará, con o sin Paper Instruments.

Si de verdad queremos que los agentes liberen a los profesionales del trabajo mecánico para dedicarse al criterio y a la relación con el cliente —la promesa de fondo de esta transición—, primero hace falta que no rompan lo que tocan. Eso es un requisito de ingeniería antes que de inteligencia, y esta semana alguien lo ha dejado por escrito con números.