Antes de automatizar, dibuja el límite
La pregunta que casi nadie hace antes de dar acceso a una IA a sus herramientas, y las tres respuestas que hay que tener por escrito.
Casi todas las conversaciones sobre automatizar con IA empiezan por la misma pregunta: qué puede hacer el sistema. Es la pregunta equivocada, o al menos la segunda.
La primera es qué no debe hacer nunca.
Suena a matiz, pero cambia el resultado entero. Un agente que puede leer tu CRM, redactar respuestas y enviarlas es útil. El mismo agente, sin límites escritos, también puede contestar a un cliente enfadado con una promesa que tu empresa no piensa cumplir. La capacidad es idéntica. Lo que cambia es el perímetro.
El problema no es que fallen
Todos los sistemas fallan. Un agente que acierta el 95 % de las veces se equivoca una de cada veinte, y eso no es un defecto que se arregle con un modelo mejor: es una propiedad del sistema con la que hay que diseñar.
Lo grave no es el error. Lo grave es el error silencioso y caro: el que nadie ve hasta que el cliente llama, y para el que no existe registro de por qué ocurrió.
He visto más de una automatización funcionando durante meses con un fallo constante que nadie detectó, simplemente porque nunca se definió qué aspecto tenía «funcionar bien».
Las tres preguntas
Antes de conectar una IA a una herramienta real, conviene tener por escrito la respuesta a tres cosas. No en la cabeza: escritas, donde tu equipo pueda leerlas.
1. ¿Qué decide solo?
Las acciones reversibles y de bajo impacto. Clasificar un correo entrante, etiquetar un documento, preparar un borrador, consultar un dato. Si algo sale mal, se corrige sin consecuencias.
La prueba es sencilla: ¿te importaría que se equivocase diez veces esta semana? Si la respuesta es que no pasa nada, puede decidirlo solo.
2. ¿Qué pasa por una persona?
Todo lo que toca dinero, compromisos o reputación. Enviar una propuesta, confirmar un precio, cerrar una incidencia, responder a una reclamación.
Aquí el agente no se detiene: prepara el trabajo y espera. La diferencia con no automatizar es enorme, porque el 90 % del esfuerzo ya está hecho cuando llega a la persona. Lo único que queda es el criterio, que es justamente lo que no se delega.
3. ¿Qué no toca jamás?
La lista corta y explícita. Borrar registros, modificar permisos, escribir en sistemas contables, comunicarse con terceros sin supervisión.
No basta con no programarlo: hay que quitarle el acceso. Un permiso que no existe no se puede usar por error, y un agente al que le das una herramienta acabará usándola tarde o temprano en un caso que no habías previsto.
Qué pasa cuando algo se rompe
La cuarta pregunta, que casi nadie se hace: ¿qué hace el sistema a las tres de la mañana cuando una integración deja de responder?
Hay dos respuestas posibles. Una es que se detenga, avise y espere. La otra es que siga adelante con datos incompletos.
La segunda es la que produce los desastres, y es la que ocurre por defecto cuando nadie decidió la primera.
Un fallo previsto es un incidente: molesto, acotado, resuelto por la mañana. Un fallo imprevisto es una crisis, y la diferencia entre ambos no está en el fallo, sino en si alguien lo pensó antes.
Por dónde empezar
Si estás valorando automatizar algo, prueba esto antes de mirar herramientas: coge el proceso que más tiempo te come y escribe las cuatro respuestas en un folio. Qué decide solo, qué pasa por un humano, qué no toca nunca, qué hace al fallar.
Si puedes contestar las cuatro, el proceso está listo para automatizarse y la parte técnica será la más fácil.
Si no puedes, acabas de descubrir algo más valioso que cualquier automatización: ese proceso tampoco está claro para las personas que lo ejecutan hoy.
¿Tienes un proceso que encaje con esto? Cuéntamelo: hola@naltion.dev