Cómo preparar los requisitos de un proyecto de agente de IA para una empresa

Define tarea, fuentes, acciones, límites, supervisión y criterios de aceptación antes de pedir una propuesta.

Equipo enginerIT· 3 min de lectura

Un encargo útil especifica qué puede leer, preparar y ejecutar el agente

Solicitar “un agente de IA para automatizar administración” no define qué hará el sistema ni cómo se sabrá si funciona. Un brief útil describe una tarea, el proceso actual, las fuentes y el límite de responsabilidad. Esta información permite comparar propuestas sobre el mismo problema y evita estimaciones basadas en una demostración desconectada del trabajo diario.

Elige una tarea acotada y frecuente

Identifica quién la realiza, cuándo empieza y qué entrega al final. Describe volumen y variaciones con datos que la empresa pueda comprobar. Evita combinar atención, ventas y administración en un solo agente si los procesos tienen fuentes y decisiones distintas.

Describe entradas reales y su diversidad

Incluye correos, formularios, documentos o mensajes que llegan y cómo se identifican. Usa ejemplos anonimizados y autorizados. Señala los casos que faltan datos o mezclan varias solicitudes; no presentes solo ejemplos limpios.

Identifica fuentes de verdad y acceso

Especifica CRM, ERP, repositorio u otra fuente que mantiene cada dato y quién puede conceder acceso. Distingue lectura, búsqueda, escritura y acciones externas. No des por válida una integración hasta comprobar documentación, permisos y límites del sistema.

Dibuja qué puede preparar y qué puede ejecutar

Separa extracción, borrador, recomendación y cambio definitivo. Indica qué paso requiere aprobación humana y cómo se registra. Un requisito como “que lo haga todo” no permite diseñar controles ni evaluar el riesgo.

Enumera excepciones y reglas para detenerse

Incluye homónimos, duplicados, datos caducados, importes o solicitudes ambiguas. Define cuándo el agente pregunta, crea una tarea o se abstiene de actuar. Si no hay una respuesta operativa para una excepción, esa parte del proceso aún necesita diseño.

Define criterios de aceptación medibles

Acordad calidad de extracción, respuesta correcta, excepciones, tiempo de revisión y errores que no son aceptables. Usa una muestra representativa y un periodo. No fijes un porcentaje de éxito sin medir el proceso actual y el coste de cada error.

Asigna propietario y operación posterior

Nombra quién mantendrá datos, reglas, permisos, pruebas y atención de incidencias. Define quién puede pausar el flujo y cómo retoma el trabajo pendiente. Una solución sin responsable de operación no está lista para desplegarse.

Pide una propuesta con supuestos explícitos

La propuesta debe mostrar sistemas, dependencias, límites, costes por componente y plan de verificación. Separa lo confirmado de lo que requiere descubrimiento. Si el proveedor promete compatibilidad o resultados sin revisar el entorno, solicita evidencia y alcance concreto.

Define condiciones para detener el piloto

Además de criterios de éxito, establece señales que obligan a pausar: una acción fuera del alcance, una fuente equivocada o una aprobación que el sistema no puede demostrar. Asigna a una persona la decisión de detener y describe cómo se atienden las tareas en curso. Un umbral de calidad sin una respuesta operativa al fallo deja al equipo sin un plan cuando la prueba sale mal.

Escribe el brief para una única tarea e incluye cinco entradas reales anonimizadas.

Compara después dos propuestas y revisa si describen la misma fuente, acción, excepción y responsable de mantenimiento.

Cuéntanos qué necesitas →