# Automatizar procesos no documentados: el coste | Auspex > Un modelo, las mismas 70 tareas: 26% sin reglas descritas y 99% con ellas. Qué implica para automatizar procesos no documentados y qué hay que dejar por escrito. Source: https://auspex.company/es/blog/undocumented-process-agent-blindspot/ [Blog](/es/blog/) / Field Notes # Automatización de procesos no documentados: cuánto cuesta lo que nadie dejó por escrito Por: Andrew Maryasov · 25 ago 2026 · 10 min de lectura La automatización de procesos no documentados no fracasa por culpa de un modelo débil. En agosto de 2026, los autores del benchmark DiG-bench hicieron una comprobación directa: el mismo Gemini 3.1 Pro, en las mismas 70 tareas, ganó 18 de 70 cuando tenía que descubrir las reglas por su cuenta y 69 de 70 cuando simplemente le dieron una descripción breve de esas reglas: 26% frente a 99%. La diferencia entre el fracaso y un resultado casi perfecto no estaba en el modelo, ni en el harness agéntico, ni en el presupuesto, sino en que existiera un texto. Auspex analiza qué de todo esto se puede trasladar a los procesos de negocio y, sobre todo, qué hay que dejar por escrito: la descripción que funcionó en el experimento no se parece en nada al típico procedimiento. En la demo el piloto funciona a la perfección, en producción el agente empieza a hacer cosas raras y el equipo sale a buscar un modelo más potente. Un mes después, con el modelo nuevo, se repite lo mismo, solo que más caro. La tentación de explicarlo por la calidad del modelo es grande, porque esa explicación da un siguiente paso claro. Pero en agosto de 2026 salió un benchmark que midió un factor muy distinto. ## El experimento que midió el precio de una regla no escrita DiG-bench (Discovery in Games) se publicó el 12 de agosto de 2026. El trabajo estuvo a cargo del grupo de investigación Thinking About Thinking, en colaboración con Oxford, Princeton, el MIT, Inria y KAUST; entre los coautores están Jürgen Schmidhuber, Joshua Tenenbaum, Thomas Griffiths y Tri Dao. El diseño es este: 70 juegos de texto, cada uno con sus propias reglas de transformación. El jugador no conoce ni las reglas ni la condición de victoria: la única forma de averiguarlas es interactuar, es decir, hacer una jugada, ver qué ha cambiado y corregir la hipótesis. Los juegos se reparten en siete niveles de dificultad; los autores hicieron públicos 21 y mantuvieron 49 cerrados para garantizar mediciones justas. Además, señalan que estos juegos no existen en ningún otro lugar de internet, así que el modelo no pudo verlos durante el entrenamiento: la cuestión de la contaminación de datos aquí simplemente no se plantea. Los autores hicieron una ablación directa: tomaron Gemini 3.1 Pro y le dieron los mismos 70 juegos, pero esta vez con el texto de las reglas en la mano. > Giving Gemini access to the ground-truth rules of the game, specified in concise natural language, raises the win rate from 18/70 to 69/70 games. > > — DiG-bench: Discovery in Games, arXiv:2608.12593 La diferencia entre esas dos cifras fue un texto breve que, en el primer caso, simplemente no existía. Los autores formulan la conclusión sin suavizarla: la dificultad principal de su benchmark está precisamente en averiguar las reglas. ## Qué le dieron exactamente al modelo y qué no había en esa descripción Los autores caracterizan con mucha precisión la descripción que subió el resultado al 99%: resumía la dinámica del juego y la condición de victoria, pero no contenía nada relacionado con la política de comportamiento: ni estrategias, ni tácticas, ni secuencias de jugadas. > These rules summarized the dynamics of the game and the win condition; but they excluded any policy-related information like strategies, tactics or move sequences. > > — DiG-bench: Discovery in Games, arXiv:2608.12593 Al modelo no le explicaron cómo jugar. Le explicaron a qué está jugando y qué se considera ganar aquí. Cuando a una empresa le dicen «describid el proceso», suele escribir justo la parte que en el experimento se quitó. El resultado son unas instrucciones: primero llama, luego crea la oportunidad, después envía la propuesta comercial, a los tres días haz un recordatorio. Eso es una secuencia de jugadas. En cambio, la mecánica —qué objetos existen, en qué estados pueden estar, qué transiciones están permitidas y cuáles no— queda sin decir, porque dentro del equipo parece una obviedad que da vergüenza decir en voz alta. La mecánica del proceso son las respuestas a preguntas que en las reuniones no se hacen: - qué entidades existen (solicitud, cliente, oportunidad, devolución, reclamación) y qué distingue a una de otra - en qué estados puede estar cada una y qué transiciones entre estados están permitidas - qué no se debe hacer nunca, por muy razonable que parezca en un caso concreto - qué excepciones existen y por qué señal se reconocen: no «a veces es distinto», sino «si el cliente está en la lista de cuentas clave, la regla es otra» - de dónde sale la información que no está en el sistema y quién está autorizado a confirmarla La condición de éxito es un bloque aparte, y casi nunca se escribe: - qué resultado observable muestra que el paso se hizo correctamente - quién o qué lo verifica y en qué plazo - en qué se diferencia «se hizo mal» de «se hizo lo incorrecto», porque son eventos distintos con un coste distinto La descripción que funcionó en el experimento se parece más a las reglas de un juego de mesa que a una descripción de puesto. Responde a la pregunta «¿cómo funciona aquí el mundo y qué se considera ganar?», no a la pregunta «¿cómo gano yo?». La diferencia no es cosmética. Las instrucciones describen una sola ruta y no dicen nada de lo que queda fuera, por eso el agente que se sale de la ruta se queda sin referencias. La descripción de la mecánica, en cambio, marca los límites del campo: dentro de ellos el agente puede elegir su propio camino y, por definición, no puede salirse. ## Una herramienta mejor no lo compensa La reacción natural ante un piloto fallido es buscar un harness más potente: otro framework, una plataforma con memoria, un agente con planificador. Los autores del benchmark también pusieron a prueba esa hipótesis. Tomaron Prime Agent (Opus 5 dentro del producto Prime Agent), que poco antes había logrado un 95,5% en los juegos públicos de ARC-AGI-3, y lo probaron en los dos niveles más difíciles de DiG-bench. No hubo mejora frente al harness básico con el mismo Opus 5. La conclusión general está formulada con cautela, pero sin ambigüedad: los harness existentes aportan una mejora limitada justamente en la capacidad de descubrimiento. No conviene estirar este resultado: algo sí descubre el agente por su cuenta. Sin reglas, Gemini aun así ganó 18 juegos, y el modelo más fuerte del conjunto, Opus 5, 50 de 70. Si para cada juego se cuenta el mejor de todos los modelos evaluados, entre todos cubren 57 de 70, pero en los dos niveles superiores solo 9 de 20. Es decir, las reglas implícitas sí se descubren, solo que de forma poco fiable, y los fallos caen justo en los casos difíciles. Para la implantación, de aquí sale algo muy práctico. Donde las reglas no están escritas, el precio no es la licencia, sino la dispersión de los resultados: el agente resolverá diez solicitudes como corresponde y en la undécima hará algo que nadie esperaba. Y resultará que la regla que rompió de verdad no estaba registrada en ninguna parte, así que, formalmente, tampoco la rompió. ## Dónde termina la analogía El benchmark mide el descubrimiento de reglas mediante la experimentación activa en juegos de texto. Allí el jugador tiene un entorno de pruebas: una jugada fallida no cuesta nada y se pueden hacer cientos de intentos. Los autores, a propósito, no evalúan la eficiencia de los pasos para no penalizar la exploración. Un proceso de negocio funciona de otra manera. Aquí el experimento del agente es una llamada real a un cliente real, un descuento real y una factura real. No hay entorno de pruebas, y el coste de una hipótesis fallida no es cero. Por eso las cifras no se pueden trasladar literalmente: el 26% y el 99% son resultados de juegos de texto, no indicadores de la automatización de un equipo de ventas. La analogía funciona en un solo sentido y precisamente como analogía: si un modelo con un número ilimitado de intentos gratuitos ganó por su cuenta 18 juegos de 70, en un entorno donde cada intento cuesta dinero y la relación con el cliente hay todavía menos motivos para contar con que descubra las reglas solo. ## Cómo pasar la mecánica de la cabeza al texto La pregunta «cuéntame cómo lo haces» da como resultado unas instrucciones, es decir, esa misma secuencia de jugadas. La mecánica no se obtiene así de ninguna manera: quien lleva diez años ejecutando un proceso no ve sus propias reglas, porque para esa persona no son reglas, sino la forma en que funciona el mundo. Lo que funciona es otro tipo de preguntas, sobre los límites y las excepciones: - «¿Qué pasa si se hace al revés?»: la respuesta «bueno, es que nadie lo hace así» casi siempre esconde una regla no dicha - «¿Cuándo fue la última vez que te apartaste de las instrucciones y por qué?»: aquí aparecen tanto la excepción como la señal por la que se reconoció - «¿Qué error comete alguien nuevo en su primera semana?»: es una transición prohibida que no figura en ningún documento - «¿Cómo sabes que ha quedado bien hecho antes de que llegue el resultado?»: un criterio de éxito que normalmente solo existe como sensación - «¿Qué revisas antes de pulsar el botón?»: una condición previa oculta sin la cual el paso no tiene sentido El documento que resulta de una conversación así tiene tres partes: la lista de entidades y sus estados, la lista de transiciones prohibidas con sus motivos y el criterio de éxito con la descripción de quién lo verifica y cómo. Las estrategias, los trucos y los consejos de «cómo hacerlo mejor» no entran aquí: se escriben aparte y para las personas. Hay una forma sencilla de comprobar si la descripción está completa: dásela a una persona que no conozca el proceso y pídele que nombre una situación en la que el documento no indique qué hacer. Cada situación de esas es exactamente el punto donde el agente se pondrá a adivinar. ## Adónde va realmente el presupuesto de implantación El presupuesto de un piloto suele componerse de integraciones, prompts, pruebas y la suscripción al modelo. El trabajo de sacar a la luz las reglas implícitas no figura en él: o se omite con un «tenemos todo descrito», o se descubre después del lanzamiento, cuando ya cuesta un proyecto detenido. El volumen de este trabajo se mide en días o semanas, según cuántas excepciones haya acumulado el proceso, y es más honesto incluirlo en el plan que explicar después por qué el piloto no salió del entorno de pruebas. Auspex lo pone primero justamente porque es portable: la mecánica descrita se queda contigo sin importar qué modelo elijas dentro de un año ni si el modelo con el que empezaste sigue siquiera en el mercado. Este trabajo enlaza con la parte anterior del análisis. En el artículo «El negocio que se actualiza solo» se hablaba de por qué crecer sin contratar choca con la descripción del negocio que vive en la cabeza de los empleados. DiG-bench le pone precio a ese panorama: muestra cuánto cuesta esa misma brecha cuando en el proceso no se pone a una persona, sino a un agente, y por qué no sirve comprar un harness en lugar de la descripción. ## Por dónde empezar esta semana - abre el procedimiento del proceso que piensas darle al agente y busca en él la lista de acciones prohibidas: si solo hay una secuencia de pasos, no tienes una descripción de la mecánica - encuentra en ese mismo documento la frase que responde a la pregunta «¿en qué se nota que el paso se hizo correctamente?» - pregúntale a la persona que lleva el proceso cuándo fue la última vez que se apartó de las instrucciones y anota la señal por la que lo decidió Si después de esta revisión resulta que el proceso se sostiene en la memoria de dos empleados, el problema no es el modelo, y no tiene sentido cambiarlo. Con esa lista de discrepancias puedes venir a la auditoría de CRM y automatizaciones. En una sola reunión, Auspex revisa cuál de tus procesos está descrito lo suficiente como para dárselo a un agente y cuál hay que pasar primero a texto. La página del servicio está en los enlaces de abajo. Y un detalle que por lo general no se nota hasta el segundo proyecto: la descripción de la mecánica tiene que vivir en el lugar desde donde la lee el agente, no en una presentación para la dirección. Un documento que está aparte del sistema se desfasa de la realidad en más o menos un trimestre, y entonces tienes dos fuentes de verdad en lugar de una. Sigue leyendo - [El negocio que se actualiza solo: escalar sin contratar no empieza por los agentes](/es/blog/self-updating-business/) - [Tres señales de que un paso no hay que dárselo al agente](/es/blog/agent-handoff-decision/) - [Por qué la automatización no arraiga, y qué mitad conviene apagar](/es/blog/why-automations-get-abandoned/) - [Qué dejar por escrito en el contrato de desarrollo de un agente de IA](/es/blog/ai-agent-contract-what-to-write/) - [Auditoría de CRM y automatizaciones](/es/services/crm-audit/) Fuentes - [Battleday, Sandbrink, Whittington et al. — DiG-bench: Discovery in Games, arXiv:2608.12593, 12 de agosto de 2026 (fuente primaria, todas las cifras salen de aquí)](https://arxiv.org/abs/2608.12593) - [DiG-bench — sitio oficial del benchmark y tabla de clasificación](https://digbench.ai) - [DiG-bench — informe técnico y harness básico (GitHub)](https://github.com/discos-research/dig-bench) Andrew Maryasov fundador de Auspex Fundador de Auspex. Implanta CRM y automatiza procesos de negocio desde 2015: más de 1500 proyectos para más de 1200 empresas. [amaryasov.expert →](https://amaryasov.expert) ## Preguntas frecuentes ¿Qué es la automatización de procesos no documentados y por qué es más difícil que la habitual? Es la automatización de un proceso en el que buena parte de las reglas no está registrada en ningún lado y solo existe como experiencia de empleados concretos. La dificultad no está en la cantidad de pasos, sino en que el agente recibe una descripción incompleta y tiene que completar con conjeturas la parte que falta. El benchmark DiG-bench midió directamente cuánto pesa este factor: el mismo modelo, en las mismas 70 tareas, obtuvo 18 victorias de 70 sin la descripción de las reglas y 69 de 70 con ella. ¿De verdad un agente de IA no puede entender por sí solo un proceso no documentado? Puede, pero de forma poco fiable. En DiG-bench, Gemini 3.1 Pro ganó sin reglas 18 juegos de 70; el modelo más fuerte del conjunto, Opus 5, ganó 50 de 70, y los mejores resultados de todos los modelos evaluados suman 57 de 70. Sin embargo, en los dos niveles más difíciles esa suma cae a 9 de 20. La conclusión práctica es esta: en los casos simples el agente reconstruye las reglas, en los difíciles falla, y no puedes prever qué caso te va a tocar en producción. ¿Qué hay que dejar por escrito exactamente antes de implantar un agente de IA? Dos cosas que normalmente no están en el procedimiento: la mecánica y el criterio de éxito. La mecánica es la lista de entidades y sus estados, las transiciones permitidas y prohibidas, las excepciones con la señal que permite reconocerlas y las fuentes de datos fuera del sistema. El criterio de éxito es el resultado observable que muestra que el paso se hizo correctamente, y quién lo verifica. Es revelador que en el experimento de DiG-bench a Gemini 3.1 Pro se le diera justamente una descripción así —la dinámica y la condición de victoria— y que se excluyeran de ella a propósito las estrategias, las tácticas y las secuencias de jugadas. ¿Ayudará un modelo más potente o un mejor framework de agentes? Según los datos disponibles, no, si el problema está justamente en las reglas no escritas. Los autores de DiG-bench probaron Prime Agent, basado en Opus 5, que logró un 95,5% en los juegos públicos de ARC-AGI-3, y en los niveles más difíciles no mejoró frente al harness básico con el mismo modelo. Su conclusión: los harness existentes aportan una mejora limitada justamente en la capacidad de descubrir reglas nuevas. ¿Cuánto tiempo lleva describir un proceso antes de automatizarlo? Días o semanas, según cuántas excepciones haya acumulado el proceso y cuántas personas lo ejecuten de manera distinta. La primera sesión de trabajo con quienes lo ejecutan ya da una estimación precisa: la cantidad de excepciones que salen a flote en la primera hora de conversación predice bien el volumen total. Lo importante aquí no es la velocidad, sino que el resultado es portable: la mecánica descrita sigue vigente aunque cambie el modelo, la plataforma o el proveedor. ¿Se pueden trasladar el 26% y el 99% a tu propio negocio? No, y esto es importante. DiG-bench mide el descubrimiento de reglas mediante la experimentación en juegos de texto, donde un intento fallido no cuesta nada y se pueden hacer cientos. En un proceso de negocio no hay entorno de pruebas: el intento del agente es una llamada, un descuento o una factura reales. Por eso las cifras del benchmark son un argumento sobre la dirección, no un pronóstico del resultado: si con un número ilimitado de intentos gratuitos el modelo ganó por su cuenta solo 18 juegos de 70, allí donde cada intento cuesta dinero hay todavía menos motivos para contar con que descubra las reglas solo. ## Boletín de automatización empresarial 2–3 emails al mes: lo que de verdad funciona en CRM y automatización. Sin spam. Puedes darte de baja en un clic. [Auditoría CRM gratuita →](/es/contact/) ↳ AUDITORÍA GRATIS 30 min · gratis · ↓ ## ¿Listo para poner orden en tus ventas? Auditoría gratuita de procesos: 30 minutos, y recibirás: 1200+ empresas desde 2015 · puesta en marcha en 30 días (mediana) 01 Un mapa de dónde pierdes leads 02 Prioridades: qué automatizar primero 03 Un plan de implantación en 2–4 semanas Te llamaremos en 24 horas. El plan es tuyo, aunque no trabajemos juntos.