Skip to main content

Debuggear personalización con IA — cómo hacerlo

Un score de Einstein se ve mal, un campo de copy generado está en blanco, o un agente responde con seguridad e incorrectamente. El diagnóstico siempre es el mismo: averiguá qué superficie produjo el valor, y después bajá hasta la capa donde realmente se rompe. El playbook para debuggear personalización con IA.

Cómo hacerlo·Actualizado 2026-06-01·Escrito por Lira · Editado por German Medina

Un valor está mal, en blanco, o es sorprendente, y una superficie de IA lo produjo. Una persona de Einstein se ve rara para un contacto que conocés bien. Un campo de subject line generado está vacío para media audiencia. Un agente de Agentforce afirmó con seguridad algo falso sobre un cliente. El instinto es culpar a "la IA" — pero cada una de las tres superficies falla en una capa distinta, así que el primer paso de diagnóstico siempre es el mismo: ¿qué superficie produjo este valor, y qué lee realmente esa superficie?

Paso 0 — ¿Qué superficie es esta?

[ Score / persona de Einstein ]  → lee la historia de engagement de tu tenant
[ Campo de copy generado ]       → una llamada a un modelo externo escribió (o falló) un DE
[ Respuesta / acción de agente ] → Agentforce leyó el perfil unificado de Data Cloud

Cada superficie tiene una capa distinta para bajar. Nombrá la superficie primero; después seguí el camino correspondiente de abajo.

El score de Einstein se ve mal

Una persona de Engagement Scoring, una hora de STO, o una elección de Content Selection que no coincide con lo que esperarías.

  1. ¿Hay suficiente historia por debajo? La causa más común es una historia de engagement delgada — una Business Unit nueva, un programa de bajo volumen, o un contacto con casi ningún envío. El modelo extrapola de poco y reporta un score seguro igual. Chequeá el volumen antes que nada. (Ver gotchas — gotcha 1.)
  2. ¿El modelo está leyendo la data que pensás? Confirmá que la feature está scopeada a la Business Unit correcta y que el engagement del que aprende es el engagement que querés decir — no una BU de prueba, no un patrón de envío que cambió el mes pasado.
  3. ¿El patrón de envío recién cambió? Un modelo entrenado con una cadencia puntúa raro justo después de un cambio grande (un programa nuevo, un cambio de frecuencia). Re-aprende; el transitorio es esperado.

Si la historia es adecuada, la BU es la correcta, y el patrón es estable, el score probablemente te está diciendo algo cierto que contradice tu intuición — que es el punto de tenerlo.

El campo de copy generado está en blanco o mal

Un campo que un modelo externo debía poblar está vacío, deformado, o viejo. Esto es un bug de flujo de data, debuggeado como cualquier blanco de AMPscript — caminá las capas.

[ Llamada al modelo externo (Script Activity) ]
        ↓ escribe
[ Campo del Data Extension ]
        ↓ Lookup en render time
[ Output del email / CloudPage ]
  1. ¿El valor está en el DE? Mirá la fila para un SubscriberKey afectado.
    • En blanco también en el DE — la llamada al modelo falló o nunca corrió para este contacto. Chequeá el log del Script Activity: un status no-200, un timeout, un error de rate-limit a mitad de la corrida (el clásico envío personalizado a medias — gotcha 9). Si escribiste un fallback ante falla, esto debería mostrar el fallback, no blanco; si está realmente en blanco, falta el camino de falla.
    • Correcto en el DE — la generación funcionó; el bug está en la capa de render/Lookup. La key del Lookup o el nombre del DE está mal, o se está leyendo el campo antes de que corra la Automation que lo llena.
  2. ¿Está mal en vez de en blanco? Un modelo no determinístico produjo un mal output que ningún spot check atrapó (gotcha 8). Por eso la generación va antes de tiempo con validación y, para copy visible al cliente, aprobación humana — así un mal output se atrapa en el DE, antes del envío, no en un inbox.
  3. ¿Terminó la corrida? Un rate limit devolviendo errores a mitad deja a los primeros N contactos personalizados y al resto en blanco. El síntoma es "en blanco para todos a partir de cierto punto". Throttleá y reintentá las filas sin llenar.

El agente respondió con seguridad y mal

Un agente de Agentforce afirmó algo falso sobre un cliente, o tomó una acción sobre el equivocado. El agente rara vez es el bug — el modelo por debajo normalmente sí.

  1. ¿Un analista humano podría sacar esto bien del perfil unificado? Hacele la misma pregunta al perfil de Data Cloud a mano. Si un humano tampoco puede sacar una respuesta coherente, el bug es el modelo de datos, no el agente — la identidad no resolvió, una relación no está modelada, un objeto no está documentado. El agente heredó el hueco. (Ver los gotchas de arquitectura de Data Cloud.)
  2. ¿La identidad resuelve correctamente? Dos clientes fusionados, o uno partido, produce un agente seguro y equivocado sobre quién está discutiendo. Chequeá la resolución antes de culpar al razonamiento.
  3. Para una acción equivocada: rastreá la aprobación y el audit trail de la acción (gotcha 5). Un agente que actuó sin una puerta es un bug de gobernanza, no de modelo — el fix es el guardrail, no el prompt.

Referencia rápida

| Síntoma | Superficie | Lo primero a chequear | |---|---|---| | Persona / score se ve raro | Einstein | Volumen de historia de engagement bajo el modelo | | Campo de copy en blanco para algunos contactos | Modelo externo | Log del Script Activity — rate limit / camino de falla | | Campo de copy en blanco solo en render | Modelo externo | Key del Lookup / nombre del DE / orden de la Automation | | Campo de copy mal, no en blanco | Modelo externo | Validación + aprobación antes de escribir el DE | | Agente seguro y equivocado | Agentforce | ¿Un humano puede responderlo desde el perfil? | | Agente actuó mal | Agentforce | Puerta de aprobación de la acción + audit trail |

Relacionado