El radar
El equipo que construye Sidekick, el workspace de IA de Zapier, cuenta cómo rediseñó tres veces su sistema de permisos antes de entender qué pregunta merece interrumpirte y cuál no.
Cualquier IA que actúa en vez de solo responder enfrenta el mismo problema: si pregunta antes de cada acción, terminas aprobando todo por reflejo y la pregunta deja de servir como protección. Si nunca pregunta, todo funciona bien hasta que un día borra la carpeta equivocada, y esa sola sorpresa basta para que dejes de confiar en ella. Zapier identificó que la pregunta correcta no es "¿debería preguntar?" sino "¿qué decisiones son tuyas y cuáles son de la IA?". La frecuencia de interrupciones es una consecuencia de esa respuesta, no el punto de partida. Este artículo documenta cómo Sidekick pasó por tres rediseños completos de su sistema de permisos tratando de resolver esto.
La primera versión de Sidekick dividía sus herramientas en dos grupos: las que leen datos corrían solas, y cualquier acción que cambiara algo —escribir un archivo, editar un documento, mover o borrar cosas— mostraba una tarjeta con tres opciones: Bloquear, Una vez o Siempre. El diseño alcanzó para lanzar, pero los problemas aparecieron rápido. La solicitud de aprobación solo existía en la pestaña del navegador abierta en ese momento, así que si la cerrabas, la pregunta desaparecía sin que pudieras responderla desde otro lugar como Slack. Además, elegir "Siempre" no servía de nada porque Sidekick olvidaba esa elección al refrescar la página. El equipo solucionó esto guardando las aprobaciones en sus servidores, de modo que pudieras responder desde cualquier lugar donde usaras Sidekick.
Más allá de dónde vivían las aprobaciones, el contenido de las preguntas también fallaba. Si una acción fallaba, Sidekick podía pedir la misma aprobación una y otra vez. Las solicitudes a veces quedaban escondidas dentro de secciones colapsadas de la conversación, invisibles para ti. Y Sidekick pedía permiso incluso para pasos inofensivos como leer un archivo, lo que hacía que las preguntas importantes se perdieran entre las rutinarias. Los botones "Una vez", "Este chat" y "Siempre" tampoco daban información suficiente para decidir con criterio, así que los reescribieron para decir exactamente qué se estaba permitiendo, por ejemplo "Permitir editar archivos en este chat". En retrospectiva, preguntar fue barato de construir, pero difícil de hacer significativo.
Meses después apareció un problema más profundo: Sidekick tenía dos sistemas separados decidiendo qué necesitaba tu aprobación, uno para sus habilidades integradas y otro para los programas pequeños que escribe para trabajar con tus apps, como Slack. Como se construyeron en momentos distintos, a veces daban respuestas diferentes para el mismo tipo de acción, lo que hacía a Sidekick impredecible. El problema de fondo era que cada regla estaba atada a una herramienta, así que la pregunta real era "¿puedo usar la herramienta de escritura?" en vez de lo que a ti te importa: qué recurso está en juego, como una cuenta de Slack, una carpeta o un documento específico. La solución fue reconstruir el sistema alrededor del recurso protegido: ahora las reglas se adhieren al archivo, la app conectada, el sitio web o la automatización misma, y un mismo conjunto de reglas aplica sin importar cómo intente actuar Sidekick. Puedes decir "nunca cambies nada en esta carpeta" o "solo envía mensajes de Slack a mí", y eso se mantiene sin importar el camino que tome el agente.
Junto con el cambio de enfoque, el equipo hizo las reglas predecibles con una jerarquía fija: si alguna regla dice "nunca", esa gana; si no, y una regla dice "preguntar primero", Sidekick pregunta; solo si nada lo bloquea, actúa sin preguntar. La misma situación produce siempre la misma respuesta, así que no tienes que adivinar qué hará el agente. También agregaron una barrera que consideran importante: el agente no puede proponer una regla general del tipo "permitir toda ejecución de código", incluso si el usuario la aprobaría con un clic, porque ese solo clic otorgaría permisos de forma silenciosa y erosionaría la confianza que el sistema existe para proteger. El resultado era correcto pero difícil de entender para algunos usuarios, aunque al menos una persona construyó buena parte de su negocio sobre Sidekick justamente porque los permisos eran deterministas.
Una tarjeta de permiso sin detalles es peor que no preguntar, porque te entrega una decisión sin darte lo necesario para tomarla. Por un tiempo, la tarjeta para "cambiar mis permisos" —la solicitud de mayor riesgo que puede hacer el agente— mostraba la regla propuesta como un bloque de JSON crudo. La reemplazaron por filas legibles con una etiqueta de Permitir, Preguntar primero o Denegar, el alcance de la regla, una línea de "Solo cuando" y nombres de cuenta en vez de identificadores técnicos. El agente escribe una etiqueta amigable para cada regla, pero el alcance real siempre aparece debajo, para que una etiqueta no pueda esconder lo que realmente se está otorgando. El botón "Permitir y configurar" también falló al inicio porque solo dejaba una nota para el agente, que a menudo la olvidaba, y la gente terminaba respondiendo la misma pregunta de nuevo; la solución final abre un chat lateral que configura el permiso sin bloquear la conversación principal.
El chat está diseñado para intercambiar mensajes, lo que lo vuelve un mal lugar para detenerse a revisar una acción con cuidado: el detalle queda enterrado en una burbuja de texto que nadie lee, o la interrupción es tan marcada que aprobar se siente como llenar un formulario. Por eso Sidekick dejó de mostrar solicitudes de aprobación, preguntas y planes propuestos como mensajes dentro de la conversación. Ahora viven en un panel adosado a la caja donde escribes, visible y sin mezclarse con los mensajes, lo que además permitió que la revisión funcionara incluso cuando editas un documento sin conversación al lado. El equipo decidió que ese panel no debía exigir configuración previa antes de que Sidekick empezara a trabajar —eso se sentía como un peaje— sino mantenerse discreto y abrirse solo cuando hay algo que revisar. También agregaron una bandeja de entrada accesible desde cualquier parte de Sidekick, para que una aprobación pendiente nunca quede esperando sin que la veas.
Un ingeniero del equipo argumentó que estaban empujando cuesta arriba: las reglas estrictas protegían bien, pero la mayoría de la gente prefiere describir permisos en lenguaje simple, no escribir reglas formales. Construyó un prototipo de "modo automático" donde una IA revisora lee tus reglas escritas en tu propio idioma y decide en tu nombre si una acción es aceptable, reconociendo el costo de confiarle más decisiones a un modelo. El equipo se dividió, y esa división es la parte más útil de la historia: unos defendían la predictibilidad como el punto central del producto, otros sostenían que la experiencia cotidiana ya era casi intolerable para gente no técnica. El diseño final mantiene ambas posturas: tus reglas siguen siendo el piso duro que Sidekick siempre revisa primero, y la IA revisora solo entra en juego cuando tus reglas no cubren una situación.
De ese diseño salieron dos modos: en Auto, una IA revisora evalúa cada acción no cubierta contra una guía de seguridad base y tus reglas, y te pregunta cuando no está segura; en YOLO ("dangerously skip permissions"), Sidekick permite todo lo que tus reglas no cubren, sin ningún chequeo de IA. Construyeron YOLO como un ajuste literal de "permitir todo" en vez de simplemente relajar la IA revisora, por tres razones: una revisora relajada podría igual saltarse una regla de "preguntar primero" o "nunca", seguiría costando una llamada de IA en cada acción, y sus respuestas podrían variar entre una vez y otra. Incluso en YOLO, tus reglas de "nunca" y "preguntar primero" siguen ganando, y Sidekick sigue teniendo que pedir permiso antes de cambiar sus propios permisos. Esto generó confusión real: un usuario de YOLO reportó que el modo le preguntaba algo, y tenía razón en sorprenderse, porque el agente estaba intentando editar sus propios permisos, uno de los casos que YOLO deliberadamente nunca se salta. El comportamiento era correcto, pero el nombre prometía algo que el sistema nunca iba a entregar.
La parte más difícil de todo el proceso fue redactar qué debía hacer la IA revisora cuando ninguna de tus reglas aplicaba y tenía que usar su propio juicio. La primera versión le decía que tuviera cuidado con cualquier cosa que llegara más allá de tus propios datos, pero eso la llevó a detenerse a pedir permiso incluso para una simple búsqueda en tus archivos, porque interpretó "buscar" como algo que salía de tu espacio. Nada estaba roto técnicamente; la instrucción era ambigua de una forma que no se podía ver hasta probarla con acciones reales. Lo resolvieron especificando explícitamente que leer tus propios datos está bien. La lección que sacan es que una regla escrita en lenguaje simple es parte del producto y necesita probarse contra acciones reales como cualquier otra funcionalidad.
En octubre, Zapier anunció a los usuarios de prueba que YOLO desaparecería: permitirse saltar toda aprobación resultó ser la forma equivocada para esta funcionalidad. El reemplazo, todavía en desarrollo, simplifica la idea: existe un único conjunto de reglas que aplica sin importar el modo, y cambiar de modo ya no cambia qué reglas están vigentes, solo qué pasa cuando ninguna regla cubre una acción. Ese criterio para los casos no cubiertos ahora se basa en dos ideas explícitas —qué tan fácil es deshacer una acción y en qué contexto ocurre— escritas como una instrucción concreta, lo que las hace comprobables, que fue justamente cómo detectaron el problema de la búsqueda de archivos. A diferencia de YOLO, el nuevo modo no implica renunciar a la protección: toda acción sigue revisándose contra tus reglas, y hay valores por defecto fijos, como pedir permiso siempre antes de enviar un mensaje hacia afuera de Sidekick, y nunca permitir aceptar términos legales o hacer pagos.
Preguntar por cada acción no protege nada si el volumen de preguntas te hace aprobar por reflejo; la frecuencia de interrupciones debe seguir a una decisión clara sobre qué es tuyo y qué es de la IA.
Atar las reglas de permiso al recurso en riesgo (un archivo, una cuenta, un documento) en vez de a la herramienta usada es lo que permite reglas como "nunca toques esta carpeta" que se sostienen sin importar cómo actúe el agente.
Una jerarquía fija de reglas (nunca gana sobre preguntar, preguntar gana sobre permitir) vuelve predecible el comportamiento de un agente, y esa predictibilidad puede ser más valiosa para el usuario que la comodidad.
Dejarle a una IA el juicio sobre casos no cubiertos por tus reglas (como en el modo Auto) ahorra fricción, pero la instrucción que guía ese juicio es tan parte del producto como el código y necesita probarse contra acciones reales.
Un modo que promete "saltar todo" (YOLO) genera expectativas que el sistema no puede cumplir en los bordes, como cambios a los propios permisos; nombrar mal una función puede romper la confianza aunque el comportamiento subyacente sea correcto.
Este resumen lo escribimos a partir de las notas oficiales del anuncio. Lo que no estaba ahí, no está aquí.
Tu pedido
Si varias personas la piden, entra al programa como un video animado de 5 a 8 minutos. No hace falta dejar correo ni nombre.
Más del radar
Flow
Si usás agentes o las integraciones de Airtable, Pinterest o Trello, revisá los breaking changes antes de actualizar. El resto son mejoras acumulativas en piezas y formularios de steps.
Flow
Los agentes ganan auditoría y control de ejecución, y varias piezas dejan de romperse por mandar body en requests GET.
En cola para una claseThe Quantum InsiderCipher
Un sistema de investigación de PSI, con un modelo no público de Anthropic, encontró la demostración de la conjetura Aaronson-Ambainis. El resultado acota cuándo un algoritmo cuántico necesita leer menos datos que uno clásico, algo relevante si investigas algoritmos cuánticos o sigues el papel de la IA en matemática.