Un agente IA no tiene que empezar haciendo cosas delicadas. De hecho, casi siempre es mejor que no lo haga.
En una empresa de Donostia - San Sebastián, Gipuzkoa o Euskadi, el primer agente útil suele ser bastante modesto: lee una solicitud, consulta una fuente aprobada, prepara una respuesta, rellena un borrador o avisa a la persona adecuada. La diferencia entre un piloto razonable y un susto está en decidir dónde se para el agente y cuándo entra una persona.
Este artículo propone una forma sencilla de diseñarlo antes de tocar herramientas. Al final tienes una plantilla descargable para definir tarea, permisos, revisión humana y métricas con tu equipo.
El error habitual: pedirle demasiado al agente
Muchas conversaciones sobre agentes IA empiezan por la herramienta. Si se conecta a Slack. Si puede usar el CRM. Si llama a una API. Si responde por email. Todo eso importa, pero llega después.
La primera decisión debería ser más incómoda: qué trabajo exacto puede hacer el agente sin meterse en un lío.
Un agente para atención al cliente, por ejemplo, no necesita cerrar reclamaciones desde el primer día. Puede clasificar el caso, buscar la política aplicable y preparar una respuesta para revisión. Un agente comercial no tiene que mandar propuestas automáticamente. Puede resumir el lead, detectar señales de encaje y sugerir el siguiente paso. Un agente interno no tiene que modificar el ERP. Puede preparar el cambio y pedir aprobación.
Ese punto medio no es falta de ambición. Es diseño operativo.
Qué debe quedar escrito antes de automatizar
Antes de montar el flujo, conviene dejar por escrito seis cosas.
- La tarea exacta. No "ayudar a ventas", sino "leer una solicitud entrante, resumir necesidad, detectar si encaja con servicios de IA aplicada y proponer prioridad".
- Las fuentes permitidas. Documentación interna, CRM, web, base de conocimiento, histórico de tickets o una carpeta concreta. Si no está en la lista, el agente no lo usa.
- Las acciones permitidas. Leer, resumir, clasificar, crear borradores, abrir tareas o notificar. En el primer piloto, mejor evitar acciones irreversibles.
- Los límites. Qué casos debe rechazar, qué información no puede mostrar y cuándo debe parar.
- La revisión humana. Quién aprueba, en qué punto y con qué criterio.
- Las métricas. Tiempo ahorrado, errores detectados, casos escalados, aceptación de borradores y satisfacción del equipo.
Parece burocracia. En realidad ahorra semanas. Cuando esto no se define, el piloto se convierte en una sucesión de excepciones.
Un ejemplo sencillo: agente para solicitudes comerciales
Imagina una pyme B2B de Gipuzkoa que recibe consultas por formulario, email y LinkedIn. El equipo quiere responder antes, pero no quiere que una IA prometa nada raro.
Un primer agente podría hacer solo esto:
- Leer el texto de la solicitud.
- Extraer empresa, cargo, necesidad, plazo y señales de urgencia.
- Comparar la solicitud con una lista corta de servicios aprobados.
- Proponer una prioridad: alta, media o baja.
- Redactar un borrador de respuesta.
- Crear una tarea para que una persona revise y envíe.
No manda emails. No cambia importes. No inventa disponibilidad. No decide si el lead merece una reunión sin revisión. Aun así, puede quitar mucho trabajo repetitivo y mejorar la velocidad de respuesta.
Dónde poner la revisión humana
La revisión no tiene por qué estar al final de todo. A veces conviene ponerla antes.
Si el agente va a leer datos sensibles, revisión antes de darle acceso. Si va a redactar comunicaciones externas, revisión antes de enviar. Si va a crear tareas internas de bajo riesgo, quizá basta con revisar una muestra diaria. Si va a tocar sistemas de negocio, la aprobación debe ser explícita.
La pregunta práctica es esta: qué error aceptarías detectar después y qué error necesitas bloquear antes. No todos los fallos pesan igual.
Señales de que el piloto está listo para escalar
Un agente puede responder bonito y no estar listo. Para escalar, mira señales más terrenales:
- El equipo entiende cuándo usarlo y cuándo no.
- Los borradores se aceptan con pocos cambios.
- Las escaladas son claras y no dependen de una persona concreta.
- Los permisos se pueden explicar sin abrir una hoja enorme.
- El coste por uso tiene sentido frente al tiempo ahorrado.
- Los errores se registran y se corrigen en el proceso, no solo en el prompt.
Si esas piezas no están, escalar solo hará más grande el desorden.
Descarga el how-to básico
La plantilla resume el diseño en una hoja de trabajo: tarea, entradas, fuentes, permisos, puntos de revisión, acciones bloqueadas y métricas para decidir si el piloto merece pasar a producción.
Descarga el how-to básico
Plantilla breve para definir tareas, permisos, herramientas, puntos de revisión y métricas antes de poner un agente IA en marcha.
Cómo lo trabajamos en Umintia
En Umintia solemos empezar por un caso pequeño y medible. Un agente para cualificar leads, preparar respuestas de soporte, ordenar incidencias, consultar documentación interna o asistir a operaciones. Primero se define el flujo. Luego se elige la herramienta.
Si tu empresa está en Donostia - San Sebastián, Gipuzkoa o Euskadi y quiere probar agentes IA sin abrir permisos de más, podemos revisar contigo un primer caso y convertirlo en piloto seguro.