Preparar, no confirmar: la regla para asistentes que tocan datos de clientes

Un asistente que trabaja dentro de tu app debe preparar, no confirmar: abre la pantalla correcta, rellena el formulario delante del cliente y señala el botón. El cliente pulsa lo que guarda, envía o borra. Ese clic hace que los errores del asistente sean baratos y visibles, y deja la responsabilidad de la cuenta en manos de quien es su dueño.

La regla es fácil de enunciar y más difícil de aplicar, porque no todo cambio es una confirmación. Este artículo explica por qué importa y te da una prueba para trazar el límite en tu propio producto.

El asistente se va a equivocar a veces: que equivocarse salga barato

Un modelo de lenguaje que elige una acción y sus argumentos acierta la mayoría de las veces. “La mayoría de las veces” es un buen estándar para una respuesta y uno malo para un cambio en la cuenta de alguien.

Los errores casi nunca son espectaculares. Imagina que tu app permite invitar a compañeros y cambiar de plan. El modelo lee “añade a Jon, el de marketing” y en el espacio de trabajo hay dos Jon. Lee “pásanos al plan grande” y elige el que está por encima del correcto. Copia un email con una errata que venía en el propio mensaje del cliente.

Si el asistente preparó el cambio, cada uno de esos errores queda en un formulario delante del cliente. Lee “Jon Pérez”, ve que no es ese Jon y lo corrige antes de que pase nada. Si el asistente confirmó el cambio, la invitación ya llegó a la bandeja equivocada y la tarjeta ya se cobró por el plan que no era. Te enteras cuando el cliente te escribe, que es justo el trabajo de soporte que el asistente debía quitarte.

Preparar convierte un error que ocurrió en un error que el cliente detectó. Mismo modelo, mismo fallo, una semana muy distinta para ti.

La regla viene tanto de mi trabajo de día como de aside. De día llevo las integraciones de ecommerce de un SaaS, donde un fallo de sincronización no se queda en un fallo: acaba siendo un problema contable para el cliente. Eso te enseña a pensarte dos veces todo lo que no se puede deshacer, y es la costumbre que metí en aside: el asistente prepara, la persona confirma.

Lo que hace tu asistente sigue siendo responsabilidad tuya

Hay una segunda razón, y no es técnica. Cuando un asistente dentro de tu producto hace algo, tu cliente ve que lo hace tu producto.

Al menos un tribunal ya lo ha visto así. En Moffatt v. Air Canada, un tribunal de Columbia Británica declaró a la aerolínea responsable de la información errónea que su chatbot le dio a un cliente, y rechazó la idea de que el chatbot respondiera por sus propias palabras. Aquel caso trataba de una respuesta. Una acción que cambia una cuenta sube lo que está en juego, no lo baja.

Además, tus clientes todavía no se fían del todo de la IA. Un estudio global de 2025 de KPMG y la Universidad de Melbourne, con más de 48.000 personas encuestadas en 47 países, encontró que solo el 46 % está dispuesto a confiar en sistemas de IA. Un asistente que pide un clic antes de que algo se aplique le da a la otra mitad un motivo para probarlo: en su cuenta no pasa nada que no haya visto y aprobado.

¿Basta con decirle al modelo que pregunte antes de guardar?

No. El atajo tentador es darle al modelo el poder de guardar y pedirle, en sus instrucciones, que pregunte antes. No lo hagas.

En julio de 2025, un agente de IA para programar borró una base de datos de producción durante un congelación de código, después de que su usuario le hubiera dicho que no hiciera cambios sin permiso. Era una herramienta para desarrolladores, no un asistente de cara al cliente, pero la lección se traslada: una instrucción es algo que el modelo sopesa. No es una garantía.

La garantía tiene que vivir en tu código. Si la función que el asistente puede llamar nunca pulsa el botón de enviar, ninguna redacción, ningún cliente confundido y ningún mal día del modelo pueden hacer que envíe. El Top 10 de OWASP para aplicaciones con LLM llama a este riesgo “Excessive Agency” (agencia excesiva), y una de las mitigaciones que recomienda es justo esta: exigir que una persona apruebe las acciones de alto impacto antes de ejecutarlas.

¿Qué acciones no debería completar nunca un asistente por su cuenta?

Un asistente nunca debería completar por su cuenta una acción que sale de la cuenta, cuesta dinero o elimina algo: esas las prepara, y la persona pulsa. Eso sí, no todo cambio necesita un botón de confirmar. Si haces que el cliente pulse “guardar” después de cada campo que rellena el asistente, has reconstruido el formulario con pasos de más. El límite tiene que ver con las consecuencias, no con si cambian datos.

Hazte cuatro preguntas sobre cada acción:

1. ¿Sale de la cuenta? Un email, una invitación, un mensaje a un cliente, una llamada a un webhook. Una vez enviado, no hay vuelta atrás.
2. ¿Cuesta dinero? Un cambio de plan, un usuario más, un complemento de pago.
3. ¿Elimina algo? Borrar un proyecto, revocar un acceso, cancelar una suscripción.
4. ¿La persona puede deshacerlo en la misma pantalla, ahora mismo? Un interruptor, un umbral, una notificación, una preferencia de visualización.

Un “sí” a cualquiera de las tres primeras significa que el asistente prepara y la persona pulsa. Un “sí” solo a la cuarta significa que el cambio puede aplicarse a medida que se rellena. Si las cuatro son «no», prepáralo igualmente: ante la duda, pulsa la persona.

Tarea	Lo que hace el asistente	Quién pulsa
Invitar a un compañero	Abre el diálogo de invitación, rellena email y rol, señala Enviar invitación	El cliente
Cambiar de plan	Abre facturación, selecciona el plan, señala Confirmar	El cliente
Borrar un proyecto	Abre los ajustes del proyecto, señala Borrar	El cliente
Conectar un webhook de Slack	Abre la integración, pega la URL, señala Guardar	El cliente
Fijar un umbral de alertas que se guarda solo	Rellena el campo; el ajuste queda guardado	Nadie: rellenarlo es el cambio, y el panel lo dice
Renombrar el borrador de un informe	Escribe el nombre en el editor	Nadie, si el editor guarda los borradores mientras escribes

Las dos últimas filas son configuración que en tu app ya se guarda sola. El cliente hace lo mismo a mano sin paso de confirmación, así que el asistente no añade uno. Dice qué cambió, y el cliente puede deshacerlo en el mismo sitio.

Cómo se ve “preparar” en código

Este es el cambio de plan como una acción registrada en aside. Es un ejemplo ilustrativo: imagina que tu página de facturación tiene un selector de plan nativo y un botón de confirmar. Cada elemento lleva un atributo data-aside, para que la función nunca dependa de clases ni de textos.

const actions = [{
  name: 'change_plan',
  description: 'Abre la página de facturación y selecciona el plan que pidió el usuario. '
    + 'No cambia el plan: el usuario revisa el nuevo precio y pulsa Confirmar.',
  inputSchema: {
    type: 'object',
    properties: {
      plan: { type: 'string', enum: ['starter', 'team', 'business'], description: 'El plan al que pasar' },
    },
    required: ['plan'],
  },
  label: 'cambiar mi plan',
  run: async ({ plan }, aside) => {
    aside.navigate('/settings/billing');
    await aside.fill(await aside.waitFor('[data-aside="billing-plan"]'), plan);
    aside.highlight('[data-aside="billing-confirm"]', 12000);
    return { filled: { plan }, next: 'el usuario revisa el nuevo precio y pulsa Confirmar' };
  },
}];

if (window.aside) window.aside.register(actions);
else window.addEventListener('aside:ready', () => window.aside.register(actions), { once: true });

Tres cosas la convierten en una acción que prepara:

• Nunca llama a aside.press sobre el botón de confirmar. press es para pasos inofensivos, como abrir una pestaña o un diálogo. El botón que cambia el plan recibe highlight, un anillo alrededor durante doce segundos, y lo pulsa el cliente.
• La descripción dice lo que no hace. El modelo la lee, así que le dice al cliente “revisa el precio y pulsa Confirmar” en vez de “listo, ya cambié tu plan”.
• Lo que devuelve dice lo que falta. next es lo que el modelo lee después de ejecutar la acción, así que la conversación sigue desde lo que de verdad pasó.

Para el umbral que se guarda solo, cambia la descripción y nada más:

{
  name: 'set_alert_threshold',
  description: 'Fija el umbral de tasa de errores en la página de ajustes de Alertas. '
    + 'Este ajuste se guarda solo al cambiar: rellenarlo es el cambio.',
  inputSchema: {
    type: 'object',
    properties: { percent: { type: 'number', description: 'Tasa de errores, de 1 a 50' } },
    required: ['percent'],
  },
  run: async ({ percent }, aside) => {
    if (percent < 1 || percent > 50) throw new Error('El umbral debe estar entre el 1 y el 50 por ciento.');
    aside.navigate('/settings/alerts');
    await aside.fill(await aside.waitFor('[data-aside="alerts-threshold"]'), percent);
    return {
      filled: { percent },
      card: { type: 'action', title: 'Umbral de alertas', fields: [{ label: 'Tasa de errores', value: `${percent}%` }], confirmed: true },
    };
  },
}

La card le muestra al cliente qué cambió, y confirmed: true le dice que ya está guardado. El throw es la validación en el borde: un valor que tu formulario rechazaría nunca llega al campo, y el modelo recibe una frase que puede repetir.

¿El clic de confirmar es solo fricción?

No: es el paso que lleva la decisión. Es tentador ver el paso de confirmar como lo que quitarías si confiaras más en el modelo. Míralo desde el lado del cliente. Antes, invitar a un compañero significaba encontrar los ajustes, encontrar la página del equipo, encontrar el botón de invitar, escribir, elegir un rol y enviar. Ahora significa pedirlo, ver cómo se rellena el formulario y pulsar un botón que tiene delante.

Ese último clic es el único paso que queda, y es el que lleva la decisión. También le da al cliente un momento de control, que para alguien que no se fía del todo de la IA pesa más que cualquier ahorro de tiempo.

Lo que sí sería fricción es pedirle que confirme los pasos que no importan: aprobar cada campo, escribir “sí” en el chat, pulsar guardar en un ajuste que ya se guarda solo. La regla también elimina eso. Un clic, en el punto sin retorno, y en ningún otro sitio.

Empieza por tu tarea más arriesgada

Si estás decidiendo qué acciones construir primero, haz una lista de las tareas que tus clientes te piden que hagas a mano y pasa cada una por las cuatro preguntas. Las tareas que envían, cobran o borran son donde la regla se gana su sitio: el asistente hace todo hasta el botón, y tú dejas de hacerlo en una llamada.

Para el montaje completo (qué funciones exponer, cómo marcar tus controles y qué no automatizar nunca), lee Cómo dejar que un asistente actúe en tu app sin darle las llaves. Para convertir uno de tus artículos de ayuda en una acción paso a paso, mira Del artículo de ayuda a la acción.