Arquitectura de Contexto: el trabajo que apareció mientras discutíamos si la IA nos iba a quitar el trabajo

A estas alturas, el escenario probablemente ya es familiar para muchos de ustedes: Alguien del equipo comparte pantalla, muestra lo que le pidió al modelo —tres líneas, a veces dos, sin mucho contexto— y luego enseña el resultado, seguido de un: “¿ves? Está súper genérico”.

La reacción inmediata obviamente es simplemente corregir la instrucción. “Prompt engineering” le dicen. Ponle un rol específico, añádele restricciones de formato, define el tono. Y funciona, más o menos, para salir del paso una tarde. La persona se va contenta con su instrucción mejorada y, a la semana siguiente, vuelve con exactamente el mismo problema en otra tarea. Tratando el síntoma más visible y fácil de explicar, que casualmente también era el menos importante de todos.

Lo que he tardado demasiado en darme cuenta es que casi nadie —y me incluyo, en mis primeros meses experimentando— tiene idea de qué está haciendo realmente la máquina. No me refiero al sentido técnico de pesos probabilísticos y transformers; eso no le importa a nadie en la operación diaria y no tendría por qué. Me refiero al sentido más básico y mundano: qué información alcanza a ver el modelo cuando le pides que resuelva un problema de negocio.

La respuesta suele incomodar a los directivos que acaban de pagar licencias carísimas: no ve absolutamente nada.

El modelo no sabe cómo se llaman tus usuarios. No sabe que el año pasado tu equipo ya intentó ese flujo de onboarding y se cayó a pedazos. No sabe que el Director de Tecnología vetó permanentemente cualquier iniciativa que toque el core bancario. No sabe qué significa “un entregable bien hecho” en tu empresa. La máquina ve exactamente lo que le pusiste enfrente en esa pequeña caja de texto y nada más.

Y aquí está la parte que me reacomodó la cabeza cuando la entendí: donde no hay información, el modelo no se detiene a preguntar. Simplemente rellena los vacíos. Y siempre rellena hacia lo más probable, que es lo más común, que es el promedio de todo lo que se ha escrito en internet sobre problemas vagamente parecidos al tuyo. Cada hueco de contexto que dejaste tácito se resolvió solo, apuntando en la dirección de la mediocridad estadística, y te lo entregaron empaquetado con buen formato y un tono aplastantemente seguro.

Eso vuelve la queja de “está genérico” bastante más interesante de lo que suena. El resultado salió genérico porque la única materia prima disponible en esa interacción era genérica. Lo que estamos viendo cuando el entregable de la IA nos decepciona es, en realidad, un retrato exacto y doloroso de cuánto de nuestro conocimiento organizacional está sin escribir.

Nombrar el trabajo para poder cobrarlo

A esta capa de curaduría le he empezado a llamar Arquitectura de Contexto. Y quiero ser brutalmente honesto sobre por qué me importa ponerle un nombre: porque llevo un año viendo a Diseñadores hacer este trabajo a ciegas, en las sombras, sin vocabulario para defenderlo en una junta directiva ni para justificar su impacto en dólares.

La definición corta de este oficio es organizar el conocimiento tácito de una organización para que un sistema pueda producir trabajo con el criterio propio de esa empresa. El activo que resulta de esto es un contexto operable —conocimiento que antes vivía secuestrado en la cabeza de un líder senior y ahora está estructurado en un estado donde se puede usar de forma repetible—.

Si este proceso te suena familiar es porque lo es. Durante veinte años organizamos contenido para que un humano pudiera navegar una pantalla y a eso le llamamos arquitectura de información. El músculo analítico es idéntico: entender un dominio complejo, encontrar su estructura, decidir qué entra, qué se queda fuera y nombrarlo de manera que otro lo pueda utilizar sin fricción. Lo que cambió es quién consume esa estructura. Ahora hay un segundo lector en la sala, uno que procesa a otra velocidad y que, sobre todo, no levanta la mano cuando algo no le hace sentido.

Hay una intuición peligrosa que conviene desmontar de inmediato, porque es la responsable de que la mayoría de los corporativos lo hagan mal en su primer intento. La reacción natural al descubrir la importancia del contexto es aventar todo al asador: pegar el documento de requerimientos completo, subir las transcripciones de cinco entrevistas, inyectar todo el repositorio de Confluence “por si acaso”.

Pero los modelos se degradan rápidamente conforme el contexto crece. La información enterrada a la mitad de un texto larguísimo se usa peor que la que está al principio o al final, como ya escribí en El Pizarrón Saturado. Más contexto empeora el resultado con una regularidad deprimente.

Esto significa que el trabajo real de Diseño está en decidir con pinzas qué merece entrar. Es curaduría bajo restricción estricta, con consecuencias directas en la viabilidad del resultado. Cualquiera que haya defendido por qué una funcionalidad específica no debe entrar al MVP ya sabe hacer esto; la diferencia es que ahora quien sufre las consecuencias de tu falta de criterio no es el usuario final, es la herramienta que tu equipo va a intentar usar cuarenta veces esta misma semana.

Las cinco cosas que tu organización asume que todos saben

En los proyectos y equipos regionales que he acompañado, la información que urge sacar a la luz y declarar explícitamente casi siempre cae en cinco cubetas. Revisa cuántas de estas están documentadas en tu empresa hoy:

1. El mundo: Qué es exactamente este negocio, cuáles son los márgenes que lo mantienen vivo y quién es el usuario real. Lo que es obvio para quien lleva tres años en la silla es completamente invisible para el sistema.

2. El criterio: Cómo se toman las decisiones aquí. Qué iniciativas se aprueban rápido, cuáles requieren pasar por tres comités, qué está vetado históricamente y por quién. Esto rara vez está en el manual de bienvenida.

3. La memoria: Qué se investigó hace dos años, qué se intentó, qué falló rotundamente y por qué. El famoso cementerio de iniciativas que todos en el pasillo conocen de oídas pero nadie documentó jamás.

4. El estándar: Cómo se ve algo “bien hecho” en tu equipo, con ejemplos concretos de lo que se acepta y lo que se rechaza. Los ejemplos rechazados suelen enseñar mucho más que los exitosos.

5. La aceptación: Quién tiene la autoridad real para validar, y contra qué métricas se mide el éxito. Sin esto, el resto del contexto no sirve, porque nadie en el sistema sabe cuándo un entregable está verdaderamente listo.

Si miras la lista con cuidado, notarás algo fundamental: no hay una sola viñeta ahí que requiera que aprendas a programar.

La “memoria” es investigación y síntesis pura. El “criterio” se levanta facilitando un buen taller con stakeholders. El “estándar” es la base de la crítica de Diseño. La “aceptación” es simplemente gobernanza. La caja de herramientas para construir este contexto ya la tienes dominada. Lo que cambió es el destino de esos artefactos; dejaron de ser PDFs que hacemos para aplaudirnos entre nosotros y que nadie más vuelve a abrir.

Ahí está el argumento de valor real, y es exactamente el que yo llevaría a una junta de presupuesto. Escribir buenas instrucciones aisladas es un esfuerzo que no escala: vive en el historial de chat de un empleado y se muere el día que esa persona cambia de trabajo. En cambio, una capa de contexto curada y declarada explícitamente es utilizada por el equipo completo, mejora con la fricción del uso diario y se convierte en propiedad intelectual de la empresa. Deja de ser productividad individual efímera y se vuelve infraestructura de negocio.

Esa es la verdadera madurez operativa en esta nueva etapa. Dejar de tratar a la inteligencia artificial como magia negra que adivina tus intenciones, y empezar a tratarla como un motor que requiere combustible estratégico de alta calidad.

Alguien en tu empresa va a terminar decidiendo con qué información trabaja tu organización todos los días. La única pregunta que queda sobre la mesa es si esa decisión la va a tomar alguien con criterio, o si vamos a dejar que el promedio estadístico decida por nosotros.

Felices trazos.