Prompt & Product
EN ES
Patrones de UX

Publica ediciones de IA en las que los usuarios confían: un contrato de cinco partes

Un editor de IA de confianza es un contrato de la app anfitriona: delimitar la lectura, preguntar por defecto, nombrar las acciones que siempre piden confirmación, detener las acciones irreversibles y hacer que el deshacer sea nativo.

AutorPrompt & Product — Redacción
Publicado10 octubre 2026
Lectura4 MIN
Illustration: Ship AI edits users trust: five-part contract

La barra lateral es la interfaz, no el modelo

Estás a punto de permitir que una IA edite un documento que tu equipo posee. La extensión de Claude para Google Workspace alcanzó la beta pública el 6 de octubre. La pregunta útil es qué puede mostrar, probar y hacer cumplir la app anfitriona antes de que el archivo cambie. Un modelo puede generar un párrafo verosímil; la app anfitriona decide si ese párrafo puede entrar en el archivo, quién puede verlo y cómo el usuario lo recupera.

Los diseñadores suelen tratar el modelo como el producto. El modelo es el motor; la app anfitriona es el contrato. Si el asistente puede leer una hoja de cálculo, el usuario necesita saber si también puede leer el correo que la explica. Si puede reescribir una diapositiva, el usuario necesita saber si también puede compartir el archivo. La respuesta debe ser visible antes de la primera edición, para que el usuario pueda detener al asistente antes de que cambie nada. Una página de ajustes a posteriori no cumple esa función. El límite debe formar parte del momento de edición.

Cinco pruebas convierten a un agente en coeditor

Un editor integrado de confianza debe superar cinco verificaciones antes de tocar contenido propiedad del usuario. Cada verificación es lo suficientemente pequeña como para probarla en un minuto, y cada una protege contra un tipo diferente de pérdida para el usuario. Aplicarlas en el orden en que el usuario se encuentra con ellas: lo que el asistente puede ver, cómo pregunta, qué siempre pregunta, qué no puede hacer y cómo el usuario se recupera.

  • Lectura delimitada: la barra lateral solo lee el archivo abierto y los conectores habilitados, no los otros archivos de Drive, el correo ni el calendario del usuario.
  • Modo de pregunta por defecto: preguntar antes de editar es el modo predeterminado, y aceptar todas las ediciones es el otro modo.
  • Acciones que siempre piden confirmación: Claude requiere aprobación antes de insertar una imagen desde una dirección web, añadir un enlace o eliminar el acceso de una persona.
  • Detenciones firmes: no puede compartir el archivo, otorgar acceso, cambiar la propiedad, crear menús ni crear automatizaciones programadas.
  • Deshacer nativo: cada edición aparece en el historial de versiones de Google con el nombre del usuario, lo que hace que el deshacer de Claude sea equivalente al deshacer propio del usuario.

El alcance mantiene al asistente dentro del archivo. Ese límite es lo que hace legible el resto del contrato. Si el usuario puede decir que el asistente está en el archivo, no en la cuenta, puede razonar sobre el riesgo sin auditar todo el espacio de trabajo. El asistente se convierte en una herramienta con una sala conocida, no en un proceso en segundo plano con un alcance desconocido.

La pregunta por defecto convierte la velocidad en una elección. El modo seguro debe ser el estado inicial, y un modo más rápido debe ser optativo. Ese orden importa porque un usuario siempre puede elegir más velocidad, pero no puede volver fácilmente a la cautela después de una mala edición. El modo predeterminado es la primera promesa que hace el producto.

La confirmación obligatoria captura ediciones que crean nuevas dependencias. Una imagen nueva puede romperse cuando su fuente cambia. Un enlace nuevo puede apuntar a un lugar que el usuario nunca eligió. Un cambio de acceso nuevo puede bloquear a un compañero fuera de un archivo que aún necesita. Esos son problemas de permisos, y la confianza del modelo no los resuelve. La pausa es el diseño.

Las detenciones firmes mantienen la propiedad con el usuario. El usuario debe decidir quién puede acceder al archivo y qué puede hacer el archivo después de que el usuario se vaya. Un asistente que puede editar texto pero no puede cambiar quién puede entrar al archivo ni programar sus propias acciones se mantiene dentro del control del usuario. El límite es visible incluso cuando el asistente está inactivo.

El deshacer hace que la recuperación sea normal. La confianza sobrevive a la primera mala edición solo si el usuario puede revertirla sin un ticket de soporte. Una ruta de recuperación que se siente como el comportamiento de edición normal de la app anfitriona es más fácil de confiar que un flujo especial de recuperación de IA. El usuario no debería necesitar recordar que el cambio vino del asistente; el deshacer simplemente debería funcionar.

La superficie de edición es donde se gana la confianza

En Google Docs, Claude puede proponer cambios de texto como tarjetas que el usuario acepta o rechaza una a la vez. Ese patrón convierte una salida del modelo en un objeto revisable: el cambio es visible, con un nombre, un límite y una salida. El usuario no tiene que imaginar qué cambió. La tarjeta es el punto de decisión donde se construye la confianza.

Reproduce ese patrón en la superficie de edición. Muestra el cambio propuesto antes de que forme parte del archivo. Mantén visibles el cursor, la selección y la propiedad del usuario. Convierte la acción del asistente en una tarjeta, un diff o una entrada del historial de versiones, no en un cambio invisible. Si el usuario puede rechazar una tarjeta, puede rechazar la siguiente; si no puede, la función se ha convertido en un escritor descontrolado.

Publicidad