El momento más peligroso de un proyecto de IA no es cuando eliges el modelo. Es cuando alguien marca una casilla que dice “permitir escribir”.
Pasa en treinta segundos y en mitad de otra tarea. Estás montando el agente, le has dado acceso de lectura al CRM, funciona bien, y entonces surge lo obvio: “ya que está, que actualice él la ficha”. Un clic. Después “ya que está, que mande él el email”. Otro clic. Y en algún punto de esa cadena de “ya que está”, un sistema que solo leía ha pasado a poder cambiar el estado de un cliente, mover dinero o dar un acceso.
Nadie tomó esa decisión. Se fue acumulando.
Un permiso no es una funcionalidad: es una apuesta
Cuando le das a un modelo la capacidad de ejecutar una acción, estás afirmando algo muy concreto: si se equivoca en esa acción, puedo asumir la consecuencia. Ese es el cálculo entero. Todo lo demás es ruido.
Y conviene decirlo sin adornos: un modelo de lenguaje no falla como falla el software normal. El software roto falla igual siempre, y por eso lo cazas. Un modelo acierta el 98% de las veces y el 2% restante hace algo perfectamente razonable y perfectamente equivocado, con un tono impecable. No hay excepción, no hay stack trace, no hay alarma. Hay una acción bien redactada que no debería haber ocurrido.
Con lectura, eso te da una respuesta mala. Con escritura, te da un problema con cliente delante.
Lo que no delego nunca a un modelo
Tengo una lista corta y no la negocio. Cuatro cosas las decide código determinista, siempre:
Accesos. Quién entra en un producto, en una comunidad o en un panel. Un acceso mal dado no se deshace: la persona ya vio lo que hay dentro, ya descargó lo que quería. Y un acceso mal quitado es un cliente que pagó y está fuera, escribiendo enfadado. Ambos errores son caros y ninguno de los dos se recupera pidiendo perdón. La regla de acceso es una condición: pago activo, plan X, fecha dentro de rango. Eso es un if, no una inferencia.
Cobros. Cualquier cosa que mueva dinero. Cobrar, reembolsar, aplicar un descuento, cambiar el importe de una suscripción. Aquí la asimetría es brutal: el beneficio de automatizarlo con un modelo es ahorrarte una condición en código, y el coste de un fallo es un cargo indebido y una disputa. No compensa ni de lejos.
Precios. Ni fijarlos, ni negociarlos, ni “adaptarlos al perfil del cliente”. El precio es una decisión de negocio con consecuencias legales y de marca. Un modelo que improvisa un descuento en un chat te acaba de crear un compromiso que tendrás que honrar.
Identidad. Quién es alguien. La verificación de una persona nunca sale de una conversación, por convincente que suene. Sale de un token, de una sesión, de un dato comprobado contra tu base de datos.
Lo que sí delego sin dramas: redactar, resumir, clasificar, proponer, extraer, traducir, priorizar. Todo lo que produce una recomendación que alguien (o algo determinista) valida después. La diferencia no es la dificultad de la tarea. Es si la salida es una sugerencia o un hecho consumado.
Los dos permisos que la gente subestima
Hay dos que se cuelan casi siempre porque no parecen peligrosos.
El primero es hablar en nombre de la empresa sin revisión. Un agente que responde en el WhatsApp de atención al cliente no está “escribiendo texto”: está creando compromisos. Si promete un plazo de entrega, ese es el plazo. Si dice que hay devolución a los 60 días, tu política acaba de cambiar por la cara. El daño no está en el sistema, está en lo que has prometido.
El segundo es buscar información fuera y actuar con ella. Si un agente lee un correo, una web o un ticket y luego ejecuta acciones, cualquiera que pueda escribir en esa entrada puede intentar darle instrucciones. No hace falta ser un genio: basta con meter una frase dentro de un mensaje de soporte. El agente no distingue entre “esto son datos” y “esto son órdenes” salvo que tú lo separes explícitamente. Cuanto más permiso tenga, más interesante es como objetivo.
Cómo lo decido en un proyecto
No empiezo por la lista de herramientas que le doy al agente. Empiezo por una tabla de dos columnas: qué puede hacer y qué pasa si se equivoca haciéndolo.
Luego aplico tres filtros. ¿Es reversible? Si no puedo deshacerlo en un minuto y sin llamar a nadie, no lo ejecuta el modelo solo. ¿Alguien lo va a ver? Una acción sin registro es una acción que nunca sabrás que ocurrió; todo lo que el agente haga deja rastro con su entrada, su salida y su hora. ¿Está acotado? Acceso mínimo, no acceso cómodo: solo los registros de este cliente, solo este rango de importes, solo estas operaciones. La cuenta de administrador con la que probaste el lunes no es la cuenta con la que se despliega.
Y para lo que no pasa los filtros, existe el mejor patrón de todos: el agente prepara, el humano aprueba. El modelo redacta el reembolso, monta la ficha, propone el descuento. Otro sistema o una persona pulsa. Sigue ahorrando casi todo el trabajo y no delega ninguna de las cuatro decisiones de la lista. Sobre cómo se estructura eso dentro de un proceso real escribí en agentes de IA para negocios, y sobre el caso concreto de accesos y cobros, en pagos fallidos y acceso al producto.
El criterio que te llevas: los permisos de un agente no los decide quien lo configura, los decide quien asume la pérdida. Si esas dos personas no son la misma, tienes un problema de gobierno antes que un problema técnico. Y si alguna vez dudas, hazte la pregunta corta: ¿me vale que esto pase el 2% de las veces?
