Antes de elegir un agente de inteligencia artificial, una PYME gana al hacer la lista de lo que quedará en manos humanas. Este ejercicio, más útil que la lista de lo que se quiere confiar a la máquina, fija el perímetro, el presupuesto y la manera de juzgar el proyecto.
- Haga primero la lista de tareas que no debe automatizar.
- Empiece con una sola tarea, un canal de entrada y un resultado esperado.
- Automatice solo tareas frecuentes, con reglas estables y errores que se puedan detectar.
- Supervise el agente con registros, pruebas periódicas y un contrato que precise datos y propiedad.
Un perímetro demasiado amplio hace imposible probar al agente
El escenario se repite a menudo. Un dirigente asiste a una demostración e imagina un asistente que respondería correos electrónicos, calificaría prospectos, actualizaría el CRM (el software de gestión de la relación con el cliente), daría seguimiento a los presupuestos y resumiría las reuniones. En el papel, es un proyecto. En la práctica, son cinco oficios, cada uno con sus propias fuentes de información.
El primer obstáculo es la prueba. Un agente se valida con casos concretos: llega tal solicitud, esto es lo que debe hacer. Para una sola tarea, unas decenas de casos reales cubren la mayoría de las situaciones. Para cinco, las combinaciones se multiplican, y a menudo son los casos en el límite los que plantean problemas. Un cliente escribe para hacer un pedido y quejarse de una entrega en el mismo mensaje: ¿quién se encarga, el tratamiento de pedidos o el servicio al cliente?
Cada acceso adicional, ya sea al correo, al CRM o a la facturación, representa también una puerta más que asegurar. Es mejor comenzar con una tarea, un canal de entrada y un resultado esperado, y luego ampliar una vez que este primer perímetro se sostiene.
Tres criterios para clasificar una tarea
El primer criterio es la frecuencia. Una tarea que se repite dos veces al mes casi nunca justifica un agente, porque el tiempo dedicado a construirlo, probarlo y mantenerlo supera lo que hará ganar. Una tarea que se repite varias veces al día cambia la ecuación y proporciona suficientes casos para probar antes del lanzamiento.
El segundo es la estabilidad de las reglas. Basta con preguntar a la persona que realiza la tarea hoy si puede explicar en una página cómo decide. Si la respuesta comienza con «depende» y continúa con diez minutos de excepciones, la regla aún no existe, y el agente reproducirá esa ambigüedad.
El tercero es el costo de un error. La cuestión no es si el agente se equivocará, sino qué sucede cuando se equivoca. Un correo mal clasificado cuesta unos minutos. Un precio incorrecto anunciado a un cliente o una cita registrada en el día equivocado cuestan mucho más y no siempre se pueden recuperar. Si el error puede detectarse antes de salir de la empresa, la automatización es viable. De lo contrario, el agente prepara y un humano valida el envío.
Cuando el agente se dirige directamente al público, se añade una obligación legal. El artículo 50 del reglamento europeo sobre IA, aplicable desde el 2 de agosto de 2026, impone que las personas sepan que están interactuando con una IA, salvo que sea evidente en el contexto.
Elegir la herramienta y luego supervisar al agente
Para tareas comunes, como la toma de citas, la clasificación de una bandeja de entrada o el acta de una reunión, ya existen softwares mantenidos por su editor y facturados mensualmente. El reflejo razonable es probar uno con casos reales durante unas semanas. La solución a medida se justifica cuando la tarea depende de herramientas que el mercado no sabe conectar, cuando las reglas forman parte del saber hacer de la empresa, o cuando los datos no pueden confiarse a una plataforma externa.
Un proveedor que procesa datos personales para la empresa es un subcontratista según el RGPD. El artículo 28 prevé que este tratamiento esté «regido por un contrato u otro acto jurídico». Este contrato debe solicitarse antes de cualquier conexión, así como saber qué pasaría si el editor cambiara sus precios o cerrara el servicio.
Una vez que el agente está en servicio, cada solicitud procesada debe dejar un rastro, y una revisión semanal de este registro durante el primer mes muestra rápidamente dónde el agente duda. Los proveedores de modelos también actualizan sus versiones, y un agente puede cambiar de comportamiento sin que se haya modificado nada. Conservar una serie de casos reales anonimizados y reproducirlos tras cada cambio permite verificarlo. Finalmente, el contrato debe precisar a quién pertenecen el código, las instrucciones y los escenarios de automatización, y la documentación debe permitir que otro proveedor retome el agente.
