Ponga una cerca a su agente de IA antes de que pueda enviar correos o gastar dinero

Creo que un agente de IA debe ganarse el acceso a su negocio, no recibirlo como un regalo de bienvenida. Si dirige una pequeña o mediana empresa, la atracción es comprensible: ayuda con correos electrónicos, registros, código rutinario y compras. Pero mi postura es simple. Antes de que un agente pueda actuar sobre sus sistemas, dele un patio cercado. Solo entonces considere entregarle las llaves.

No trataría esto como un argumento en contra de la IA. Lo veo como la diferencia entre probar una herramienta útil y dar a un proceso no probado autoridad sobre clientes, dinero y operaciones. Una demostración persuasiva no me diría lo suficiente sobre cómo maneja un agente una solicitud ambigua o una situación inesperada. Querría límites que se mantengan incluso cuando su juicio falle.

Mi primer paso sería un entorno aislado (sandbox) o una copia de pruebas: un lugar donde el agente pueda practicar sin contactar a clientes reales, modificar registros reales o realizar compras. Verificaría esa separación en lugar de asumirla. ¿Puede la cuenta de pruebas aún acceder a una bandeja de entrada real? ¿Están disponibles credenciales de pago reales? Si la cerca tiene una puerta hacia los sistemas reales, querría saber exactamente quién la controla.

A continuación, le daría al agente su propia cuenta, con solo los permisos que requiere su tarea actual. Nunca mi inicio de sesión de administrador. Un agente que redacta recordatorios de citas no tiene una razón obvia para alterar la configuración de nómina. También mantendría las contraseñas y otras credenciales fuera de su alcance a menos que sean esenciales para la tarea autorizada. El acceso separado me da algo específico para restringir o revocar.

Luego escribiría dos categorías: lo que puede hacer solo y lo que necesita la aprobación de una persona. Redactar un correo electrónico podría estar permitido; enviarlo podría requerir aprobación. Preparar una actualización de registro podría ser aceptable; eliminar registros podría no serlo. Haría que esas reglas fueran aplicables mediante permisos del sistema y pasos de aprobación siempre que sea posible, en lugar de depender solo de instrucciones para comportarse con cuidado.

Establecería límites de gasto, volumen y tiempo antes de comenzar el trabajo real. Eso significa un techo de compras, un tope en mensajes o cambios de registros y una ventana de operación definida. Los límites adecuados dependen del negocio y la tarea. Mi prueba sería práctica: si el agente repitiera la acción incorrecta hasta alcanzar el límite, ¿podríamos absorber y revertir el resultado cómodamente?

Mantendría un registro de sus acciones y lo leería detenidamente durante las primeras semanas. Querría ver qué cambió, qué envió, qué aprobaciones solicitó y dónde se detuvo. Para mí, el registro no es una casilla para marcar. Es cómo compararía el trabajo que creía haber delegado con el trabajo que realmente se está realizando.

También debe haber un botón de parada, y alguien debe saber que es responsable de presionarlo. Probaría que detener al agente realmente impide nuevas acciones, incluido el trabajo en cola. También planificaría cómo revocar su acceso y deshacer cambios cuando sea posible. Un procedimiento de emergencia no es mucho consuelo si nadie sabe dónde está.

Solo después de revisar trabajo real pero de bajo riesgo ampliaría los permisos, una responsabilidad a la vez. Buscaría un comportamiento consistente dentro de las reglas, no simplemente un resultado impresionante. En mi opinión, la posibilidad de que un agente cruce un límite es razón suficiente para establecer límites antes de la confianza, sin esperar un ejemplo aterrador. Mi consejo es empezar pequeño, observar de cerca y mantener el control. DevMojos ayuda a las empresas a adoptar agentes de IA de forma segura, con las cercas en su lugar primero.