El error que nadie iba a notar

Hay un reporte de 237 páginas que el gobierno australiano le encargó a Deloitte por un equivalente a cientos de miles de dólares. El objetivo era revisar el sistema que aplica sanciones automáticas en su programa de bienestar social. Se publicó en el sitio del departamento a mediados de año y ahí estuvo, tranquilo, durante varias semanas.

Quien encontró el problema fue un investigador universitario que no tenía absolutamente nada que ver con el proyecto. Se topó con referencias a trabajos de colegas suyos que no existían, y con una cita textual atribuida a un juez federal que el juez jamás pronunció. La versión corregida que salió después incluyó una nota aclaratoria nueva: se había utilizado un sistema generativo para escribir el documento. La consultora terminó devolviendo la última exhibición del contrato.

Lo que me sigue dando vueltas en la cabeza no es el error técnico ni el escándalo de relaciones públicas. Es que las recomendaciones del reporte original no cambiaron. El análisis servía. Las conclusiones se sostuvieron frente al escrutinio. Lo que estaba podrido eran los cimientos de la justificación, y nadie —ni el analista que lo escribió, ni el socio que lo firmó, ni el burócrata que lo pagó, ni quien lo publicó en el sitio de gobierno— tuvo la capacidad de notarlo. Hizo falta un desconocido con un expertise muy específico, leyendo por su cuenta en su tiempo libre, para encender la alarma.

Y yo pensé, con toda honestidad: por ese documento pasaron más filtros de revisión formal que por cualquier cosa que yo haya entregado en mi vida.

Llevo meses intentando entender por qué se nos escapan estas cosas en las disciplinas estratégicas, y creo que la respuesta no tiene que ver con negligencia profesional. Tiene que ver con qué tipo de error estamos entrenados a atrapar.

El silencio de los entregables estratégicos

Los equipos de desarrollo de software llevan dos décadas construyendo maquinaria pesada de verificación: pruebas automatizadas, integración continua, revisión de código por pares, ambientes de staging donde nada es real todavía. No construyeron todo eso por una vocación romántica de rigor. Lo construyeron porque el código falla a gritos. No compila, tira el servidor de producción, o alguien te llama por celular a las dos de la mañana porque la pasarela de pagos se cayó.

Cuando el error se anuncia solo y cuesta dólares por minuto, terminas diseñando una infraestructura para atraparlo antes de que despierte al director general.

Una síntesis de investigación de usuarios, por el contrario, falla en absoluto silencio. Un análisis estratégico que parte de un supuesto comercial equivocado se ve exactamente igual a uno brillante: tiene la misma extensión, la misma tipografía impecable, el mismo tono de seguridad ejecutiva. Nadie te habla de madrugada para decirte que tu journey map tiene una falla lógica. Te enteras nueve meses después, cuando el producto sale al mercado y no tracciona. Y para entonces, el rastro está tan frío en la organización que ya nadie puede señalar en qué junta se tomó la decisión que lo rompió. Lo que suele ocurrir en su lugar es que un comité concluya, vagamente, que al proyecto “le faltó presupuesto de marketing”.

Nunca desarrollamos un músculo de verificación rigurosa para el Diseño estratégico porque, visto de cerca, teníamos algo que funcionaba bastante bien como filtro natural sin que nadie lo hubiera planeado: la lentitud.

Escribir un documento analítico deficiente costaba casi tanto tiempo humano como escribir uno bueno. En las tres semanas que tomaba redactarlo, alguien inevitablemente lo leía, lo cuestionaba o notaba los huecos en una revisión de estatus. Nuestro control de calidad era el reloj corporativo.

Ese seguro de vida se acabó hace poco más de un año. Producir cuarenta páginas altamente plausibles y estéticamente perfectas cuesta hoy once minutos. El volumen de trabajo que “se ve terminado” creció de golpe, pero la capacidad cognitiva de tu equipo para revisarlo se quedó exactamente donde estaba.

Lo que ya estás haciendo (y estás tirando a la basura)

Aquí está la parte que me fascina porque no le cuesta un dólar a nadie, pero revela la inmadurez operativa de cómo estamos usando la tecnología.

Todos en Diseño conocemos el baile del ida y vuelta. Le pides algo al modelo de IA, te devuelve una estructura genérica, y le explicas que en tu empresa eso no se puede porque el equipo legal bloqueó esa iniciativa el año pasado. Te devuelve otra opción, y le aclaras que el usuario principal del que hablan no es el que descarga la app por primera vez, sino el que renueva su póliza cada seis meses. Le corriges una recomendación de interfaz que simplemente no aplica con tu infraestructura actual.

Te toma veinte minutos, a veces cuarenta, pelear con el prompt hasta que sale un documento o una estructura utilizable.

Esa fricción constante se siente como tiempo perdido. Por eso todo el mundo en LinkedIn está obsesionado con venderte cursos para “escribir mejores prompts” y eliminar el ida y vuelta. A mí me parece que es urgente verlo al revés. En esos veinte minutos de frustración, acabas de declarar el contexto real de tu organización y aplicaste tus criterios de aceptación de negocio, uno por uno, en voz alta y bajo presión. Hiciste el verdadero trabajo de Diseño.

Y al cerrar la ventana del navegador, tiraste todo ese conocimiento íntegro a la basura, listo para volver a teclearlo mañana desde cero.

Hace poco le puse nombre a esta fuga de capital, como ya escribí antes, el antídoto es empezar a construir tu Arquitectura de Contexto. La manera menos heroica de arrancar es un ejercicio que te tomará exactamente cinco minutos.

Al terminar tu próxima sesión larga de trabajo con un modelo de IA, antes de cerrar la pestaña, abre un bloc de notas y escribe dos listas rápidas.

La primera: todo lo que tuviste que explicarle sobre tu organización para que dejara de inventar tonterías. Quién es el usuario que de verdad deja dinero, qué reglas de negocio son inamovibles, qué proyectos ya se intentaron hace dos años y fracasaron.

La segunda: todo lo que tuviste que corregirle para que el resultado te pareciera profesionalmente aceptable. No lo que estaba mal en abstracto, sino lo que estaba mal para tu estándar.

El hallazgo incómodo

La primera lista es tu materia prima estratégica. La segunda es tu verdadero criterio de aceptación, ese que probablemente nunca habías documentado y que hasta hoy vivía exclusivamente como un instinto en tu cabeza.

Si pegas esas dos listas al inicio de tu siguiente sesión de trabajo, vas a ver de inmediato cómo la fricción desaparece. Pero si haces esto tres o cuatro veces, va a pasar algo mucho más interesante: las listas empezarán a estabilizarse. Los patrones se repiten. Ahí es donde esta práctica deja de ser una nota personal para sobrevivir el día a día, y se convierte en un activo de infraestructura para tu equipo.

Y cuando tú y alguien más de tu equipo comparen sus respectivas listas, va a aparecer el hallazgo verdaderamente incómodo: no van a coincidir.

Se darán cuenta de que no estaban de acuerdo en qué significa “un buen análisis” o “una restricción válida”, y que nunca había existido un mecanismo para hacer visible esa divergencia. Ese desacuerdo no lo trajo la inteligencia artificial a tu oficina. Estaba ahí desde hace años, oculto, resolviéndose en juntas eternas por puro cansancio o por el peso del organigrama. Lo único nuevo es que ahora hay una herramienta que se toma tus instrucciones de manera literal y expone tus vacíos.

Cuando alguien me pregunta en el LAD qué diablos va a hacer un Diseñador cuando la máquina ensamble las pantallas y redacte los reportes de investigación, esta es mi respuesta menos elegante y la que más defiendo: alguien va a tener que ser capaz de mirar un entregable impecable, plausible y bien formateado, y tener la autoridad técnica para decir que está mal.

Esa persona necesita saber exactamente contra qué lo está comparando. Y en la mayoría de los equipos de LatAm, nadie ha escrito ese “contra qué” en ninguna parte.

Si haces el ejercicio de las dos listas esta semana, déjamelo en los comentarios o escríbeme directamente. Estoy juntando las experiencias de suficientes líderes de Diseño para ver si el patrón de fricción es el que sospecho. Lo que salga de ahí, lo publicaré pronto.

Felices trazos.