← Volver al blog

¿Cuánto acceso necesita realmente tu asistente de IA?

Los debates recientes sobre agentes personales revelan por qué la autorización de cuentas, las acciones permitidas y los destinatarios necesitan controles separados, y dónde encajan OOMOL y OpenConnector.

OOMOL

Una mano controla una compuerta en un flujo de correo y mensajes salientes, mostrando los límites de acceso de la IA

Ilustración editorial generada por IA: leer información y enviar mensajes requieren permisos separados.

Pedirle a la IA que organice el correo, prepare reuniones y haga seguimiento del trabajo resulta cada vez más natural. La duda aparece al pulsar Autorizar. ¿Cuánto puede ver? ¿Qué puede hacer en tu nombre? ¿Puedes retirar ese acceso?

Un debate reciente puso estas preguntas en el centro. En una entrevista publicada por Business Insider el 9 de octubre, el CEO de XMTP Labs, Shane Mac, afirmó que su agente personal de finanzas publicó un informe en el Slack de su empresa. El artículo es un relato editado contado por el protagonista, no una auditoría técnica independiente.

La entrevista se compartió en r/technology de Reddit. Algunos comentaristas se opusieron a dar información sensible a la IA; otros cuestionaron por qué estaban conectadas las cuentas personales y de trabajo. Sus reacciones plantean una preocupación práctica: cuando un asistente puede leer información y enviar mensajes, ¿cómo controla el usuario a dónde va esa información?

El 12 de octubre, el video de TikTok de CNA también abordó si los usuarios dan demasiado acceso a los agentes. Su descripción se centra en si las personas entienden los permisos que conceden.

Estas fuentes no demuestran que todos los agentes vayan a fallar. Demuestran que los permisos forman parte del debate público sobre los asistentes personales. Para cualquiera que ponga la IA a trabajar, el acceso debe seguir a la tarea.

Organizar el correo y enviarlo requieren permisos distintos

Imagina pedirle a un asistente que cada mañana identifique los correos que necesitan respuesta, enumere los puntos clave y sugiera respuestas.

Eso requiere buscar y leer correo. Las respuestas sugeridas pueden aparecer en tu conversación para que las revises. Enviar mensajes automáticamente, eliminarlos o cambiar la configuración de reenvío deberían ser decisiones de autorización separadas.

Abrir todas las acciones desde el principio le da al asistente más capacidad de la que esta tarea necesita. Cambiar su prompt más adelante puede no cambiar el acceso real de la cuenta.

Empieza con tres preguntas:

  • ¿Qué puede leer? ¿Qué cuenta, qué periodo y qué materiales?
  • ¿Qué puede hacer? ¿Solo buscar y leer, o también enviar, editar y eliminar?
  • ¿Quién recibe el resultado? ¿Esta conversación o un destino personal específico?

Gestiona estas cuestiones por separado. La autorización de la aplicación de origen determina los datos accesibles. La capa de conexión puede restringir las acciones invocables. El flujo de trabajo del asistente aún debe definir parámetros y destinatarios.

Tres decisiones de acceso: qué leer, qué hacer y quién recibe el resultado; las aplicaciones de origen, los conectores y los flujos de trabajo tienen responsabilidades distintas

Configura las tres capas por separado. Esto es una guía de diseño de tareas; un solo interruptor no aplica todos los límites.

El acceso de solo lectura también necesita un destino claro

El acceso de solo lectura es un buen punto de partida: organiza información, deja que una persona la revise y añade acciones de forma gradual.

Leer también introduce información en el contexto de procesamiento del asistente. Aunque no pueda modificar los datos de origen, otra herramienta que sí pueda enviar mensajes podría llevar esa información a otro lugar.

Un resumen matutino personal puede quedarse inicialmente en tu conversación privada. Un resumen de equipo debería usar fuentes y destinos aprobados. Las finanzas personales, los horarios familiares y los mensajes de la empresa merecen conexiones y canales de salida planificados por separado.

Para los flujos de mensajería, especifica la cuenta y el destinatario, usa identificadores de destino estables cuando sea posible y muestra el contenido final para confirmación cuando sea necesario. Nombres de grupos, contactos o etiquetas de cuenta parecidos no deberían ser la única base para elegir un destino.

Esto pertenece al diseño del flujo de trabajo. El permiso para invocar una acción de envío de mensajes no determina automáticamente si cada contenido es apropiado para cada destinatario.

Dale al asistente capacidades que puedas explicar

OOMOL te permite aplicar estas decisiones a las conexiones de cuentas y al acceso a acciones. Su documentación de control de acceso distingue la autorización del proveedor, el acceso de la conexión y las acciones permitidas.

Un asistente que organiza correo puede usar una conexión limitada a acciones de búsqueda y lectura. Cuando necesite enviar en tu nombre, configura esa capacidad para la tarea de envío. Una misma cuenta puede tener varias conexiones con distintos ámbitos de acción y de acceso de miembros.

Los ámbitos de autorización que puedes seleccionar dependen del servicio de origen. Las acciones que puedes restringir dependen de las interfaces de la conexión actual. La visibilidad de registros individuales sigue dependiendo de los permisos de la aplicación de origen y de los parámetros de la solicitud.

Un detalle útil: las restricciones de acciones personalizadas de OOMOL desactivan Proxy y el punto de entrada dinámico call_tool. Así, las llamadas se mantienen dentro de las acciones permitidas explícitamente, en lugar de obtener otra ruta de propósito general más allá de la lista seleccionada. Comprueba este comportamiento junto con la configuración en la documentación.

Los equipos que necesiten ejecutar su propio servicio de conexión pueden usar OpenConnector, la vía de código abierto y autoalojada de OOMOL. Permite a los equipos gestionar credenciales de conexión, políticas de acciones y registros de ejecución en su propio entorno, exponiendo acciones de aplicaciones mediante interfaces como MCP y HTTP. La guía de autoalojamiento cubre la autenticación en tiempo de ejecución, las acciones permitidas y bloqueadas, y los registros de ejecución con datos sensibles ocultos.

Estas capacidades ayudan a establecer e inspeccionar los límites de acceso. Los datos de negocio que se devuelven al asistente aún requieren un tratamiento de datos sensibles. Los destinatarios, las comprobaciones de contenido y la confirmación de ejecución también deben abordarse en el flujo de trabajo del asistente o de la aplicación.

Empieza con una tarea pequeña y útil

La primera versión puede simplemente leer las reuniones de hoy y los correos relacionados, y luego poner los elementos importantes en tu conversación privada.

Cuando seleccione las cuentas correctas, encuentre los materiales correctos e identifique sus fuentes, considera añadir la creación de tareas o la mensajería. Cada acción añadida debería tener una tarea, una cuenta y un destino claros.

Ten claro qué revocar cuando necesites detenerte. Desconectar una cuenta, revocar las credenciales de llamada y cancelar tareas programadas son puntos de control distintos. No eliminan automáticamente la información ya enviada.

Para empezar, configura una conexión específica para la tarea en OOMOL Connections, restringe sus acciones permitidas con la guía de control de acceso y dale a tu asistente una petición clara:

Encuentra los correos a los que debo prestar atención hoy. Solo busca y lee; no envíes ni elimines nada. Muestra los resultados en esta conversación y conserva los enlaces a los correos originales.

Cuando las capacidades coinciden con la tarea, la autorización se entiende mejor y tienes una base más clara para añadir más después.