Lo que el usuario nunca te dijo: diseñar AI para señales implícitas

En el post anterior mostré cómo dos enfoques arquitectónicos sobre las mismas fuentes de datos producen productos completamente distintos. RAG tradicional versus knowledge engine basado en artefactos. La conclusión: la decisión es arquitectónica, no técnica, y se toma antes de escribir código.

Ese ejemplo asumía algo que en producción casi nunca es cierto: que toda la información relevante sobre el usuario está declarada. El cliente dijo "soy intolerante a la lactosa", el sistema lo sabe, listo.

En la realidad, los usuarios casi nunca declaran lo que necesitás saber. Lo demuestran con comportamiento.

Y ahí aparece la pregunta más interesante de toda la arquitectura de un feature con AI: ¿qué hace el sistema con lo que el usuario nunca le dijo?

El Setup

Volvé al asistente de Starbucks del post anterior. Mismo dominio, mismo catálogo, mismas tiendas. Pero ahora una situación distinta:

El cliente abrió la app 9 veces en los últimos 2 meses. En 7 de esas 9 visitas pidió bebidas sin lactosa, leche de almendra, leche de avena, leche de coco. Nunca dijo "soy intolerante a la lactosa". Nunca marcó un dietary flag. No hay nada en su perfil que lo declare.

Hoy abre la app y escribe:

"Qué me recomendás para esta tarde, algo dulce."

El sistema tiene la información. El comportamiento está en el historial de pedidos. Pero el flag dietario está vacío.

¿Qué tiene que hacer el asistente?

Tres opciones, ninguna trivial

Opción 1: Ignorar lo no declarado. El sistema asume que si el usuario no marcó intolerancia, no la tiene. Recomienda el frappuccino caramel con leche entera. El cliente, que viene esquivando lactosa hace meses, lo ignora. Confianza tibia: el AI "no me entiende".

Opción 2: Asumir silenciosamente. El sistema infiere del historial y solo recomienda bebidas sin lactosa, sin decir nada. El cliente recibe recomendaciones que coinciden con su preferencia, pero nunca entiende por qué. Si un día le aparece una opción con lactosa, no sabe si fue olvido del sistema o cambio de criterio. Confianza frágil: el AI "a veces sabe, a veces no".

Opción 3: Inferir y volver explícito. El sistema detecta el patrón, prioriza opciones sin lactosa marcándolas como tales, y en algún momento le pregunta al usuario si quiere declarar la preferencia. Si responde que sí, se guarda. Si no responde o dice que no, el sistema sigue infiriendo pero no insiste. Confianza sólida: el AI "me entiende y me explica por qué".

La mayoría de los productos con AI están en la opción 1 o la 2. La opción 3 es la que querés. Y la opción 3 no se construye con un prompt mejor.

El Problema Arquitectónico

La opción 3 requiere que algo exista en el dominio que en la opción 1 y 2 no existe: un artefacto que represente lo que el sistema sabe sobre el usuario sin que el usuario lo haya declarado.

En el post anterior teníamos CustomerProfile. Era un artefacto plano, con flags declarados:

interface CustomerProfile {
  user_id: string
  dietary_flags: string[]      // ["lactose_intolerant", "vegan"]
  // ...
}

Para que la opción 3 sea posible, necesitamos un artefacto distinto, separado, con otra naturaleza:

interface InferredPreferences {
  user_id: string
  signals: {
    name: string                 // "lactose_avoidance"
    confidence: number           // 0.0 - 1.0
    evidence_count: number       // 7 de los últimos 9 pedidos
    first_observed: string       // ISO date
    last_observed: string        // ISO date
    declared: boolean            // false hasta que el usuario confirme
    asked_count: number          // cuántas veces ya le preguntamos
    last_asked: string | null
  }[]
  refresh_policy: "after_each_transaction"
}

Notá la separación. CustomerProfile.dietary_flags es lo declarado. InferredPreferences.signals es lo inferido. Son dos cosas distintas y el sistema las trata distinto.

Esa separación parece pedante, pero es la decisión arquitectónica que hace posible todo lo demás.

Lo que Cambia Cuando el Artefacto Existe

Una vez que InferredPreferences existe en el dominio, la consulta del usuario tiene un comportamiento radicalmente distinto.

Cuando llega "qué me recomendás para esta tarde, algo dulce", el sistema corre una query tipada que usa los dos artefactos en simultáneo:

{
  "ask": "Recomendá hasta 3 bebidas dulces, priorizando coincidencia con preferencias inferidas de alta confianza, marcando explícitamente qué señal del usuario está cumpliendo cada recomendación",
  "filter": {
    "user_id": "cliente_123",
    "producto.tags.contains": "dulce",
    "tienda.proximidad_usuario_metros": { "<=": 2000 },
    "tienda.skus_activos.contains": "{producto.sku}"
  },
  "ranking": {
    "primary": "matches_inferred_signals(confidence > 0.7)",
    "secondary": "rating_promedio"
  },
  "shape": [{
    "nombre": "string",
    "tamaño_recomendado": "string",
    "señal_cumplida": "string | null",
    "confianza_señal": "number | null"
  }]
}

Y la respuesta no es solo una lista de bebidas. Es una lista anotada con el contexto de por qué cada una fue elegida:

"Te recomiendo: — Iced almond milk latte (sin lactosa · dulce) — Oat milk caramel macchiato (sin lactosa · dulce) — Strawberry açaí refresher (sin lácteos · dulce) Veo que en tus últimos pedidos elegiste opciones sin lactosa. ¿Querés que las marque siempre como prioridad? Sí / No / Más tarde"

Tres cosas pasaron en esa respuesta que sin el artefacto no podrían pasar:

1. El sistema priorizó con razón verificable. No "creo que querés sin lactosa". Lo afirma porque el artefacto tiene confidence: 0.78 y evidence_count: 7.
2. La UI etiquetó "sin lactosa" como atributo de cada recomendación. No como afirmación general, como propiedad del producto que coincide con una señal específica del usuario.
3. El sistema preguntó en el momento correcto. No la primera vez. No cada vez. Cuando la confianza pasó un umbral y todavía no había preguntado.

Si el usuario responde "sí", declared: true y CustomerProfile.dietary_flags suma lactose_intolerant. La señal se "promueve" de inferida a declarada. Si responde "no", la señal queda anulada. Si ignora, el sistema sigue usando la inferencia pero no vuelve a preguntar por un rato definido.

El Punto Más Profundo

Todo lo que acabás de leer son decisiones arquitectónicas que se ven como decisiones de UX.

• ¿Cuándo el sistema infiere y cuándo solo usa lo declarado? Política sobre el artefacto.
• ¿Con qué umbral de confianza el sistema actúa silenciosamente versus pregunta? Threshold definido en el dominio.
• ¿Cómo se etiquetan las recomendaciones para que el usuario entienda por qué el sistema las eligió? Shape de la respuesta de la query.
• ¿Cuántas veces y con qué espaciado se pregunta? Política del artefacto, no copy del modal.

Ninguna de estas decisiones se toma en el momento de diseñar el modal de "¿sos intolerante a la lactosa?". Se toman antes, cuando alguien decide qué entidades existen en el dominio y qué políticas las gobiernan.

Si esas decisiones no las toma alguien, las toma el modelo en query time, probabilísticamente, distinto cada vez. Y ahí es donde la confianza del usuario empieza a degradarse sin que nadie sepa exactamente por qué.

Cómo se Traslada Esto a B2B SaaS

Pensá en cualquier producto B2B SaaS. Cada producto hace inferencias sobre sus usuarios y entidades todo el tiempo, declarándolas o no:

• Un CRM infiere qué leads están "calientes" basado en comportamiento (open rates, clicks, replies). Casi nunca lo expone como artefacto separado. Lo mete en un score opaco.
• Un PM tool infiere qué proyectos están "en riesgo" basado en velocity, comments, missed dates. La inferencia existe, pero no como entidad consultable con confianza explícita.
• Un soporte tool infiere qué tickets son "urgentes" basado en lenguaje, historial del cliente, criticidad del componente. Se refleja en una prioridad calculada, sin separar señal de declaración.

Cuando agregás AI a estos productos, esas inferencias se vuelven críticas. El AI no puede recomendar acciones inteligentes si trata las inferencias del producto igual que los datos declarados. Y no puede explicarle al usuario por qué tomó una decisión si no tiene un artefacto que separe "lo que sabemos porque nos lo dijeron" de "lo que inferimos por su comportamiento".

La arquitectura te da dos opciones:

Camino A: las inferencias viven implícitas en queries y modelos. El AI las regenera cada vez. Inconsistente, opaco, no auditable.

Camino B: las inferencias viven como artefactos tipados con confianza explícita y políticas de actualización. El AI las consulta. La UI las representa. El usuario puede declarar, anular, o ignorar.

Para B2B SaaS, donde los usuarios necesitan entender por qué el sistema les recomendó algo, para auditoría, compliance, o simplemente confianza profesional, gana el Camino B. Casi siempre.

Qué Hacer al Respecto

Si estás construyendo o auditando un feature con AI en B2B SaaS, además de los pasos del post anterior:

1. Listá las inferencias que tu producto ya hace implícitamente sobre usuarios y entidades. Toda app las hace. Empezar por verlas explícitas es la mitad del trabajo.
2. Para cada inferencia, decidí: ¿debería ser un artefacto consultable con confianza, o se queda como cálculo implícito?
3. Para cada artefacto, definí: refresh policy, threshold para acción silenciosa, threshold para pedir declaración, política de re-pregunta cuando el usuario ignora.
4. Diseñá la UX como consecuencia de esos thresholds, no al revés.

El producto que sabe distinguir entre lo que el usuario declaró y lo que el sistema inferió, con confianza explícita, es el producto en el que los usuarios confían lo suficiente para usarlo todos los días.

El que mezcla las dos cosas, o peor, el que infiere silenciosamente sin separar, es el producto al que los usuarios le agradecen las recomendaciones cuando aciertan, y lo abandonan cuando no.

La diferencia no es el modelo. Es el artefacto que decidiste, o no decidiste, agregar al dominio.

Si estás trabajando un feature con AI en tu producto B2B SaaS y querés pensar estas decisiones, qué inferencias debería volver explícitas tu sistema, con qué umbrales, con qué UX, antes o después de comprometerte con un approach, ese es el trabajo que hago. Hablemos →