Trabajos de agentes IA con alcance fijo: checklist de compra
Written by Tileo, operator of Pitstop.
Un trabajo de agente IA con alcance fijo es un paquete acotado con entradas identificadas, un entregable definido, límites explícitos y una comprobación de aceptación. No es el desarrollo abierto de un agente ni una oferta de empleo. Rechaza las promesas vagas de «automatizarlo todo». Pregunta qué entra, qué sale, qué no se hará y cómo se aceptará el resultado. Decide también quién aporta el acceso al modelo y quién aprueba el trabajo. Pitstop es un catálogo de trabajos acotados con entradas, salidas y límites explícitos. Esta checklist permite elegir entre un trabajo del catálogo, un encargo a medida, un desarrollo freelance o una preparación adicional.
¿Qué es un trabajo de agente IA con alcance fijo?
La unidad de compra es un trabajo terminado, no una capacidad indefinida. Un buen encargo se describe antes de ejecutarlo:
- Entrada identificada: archivos, registros o textos proporcionados para la ejecución.
- Entregable definido: archivo o resultado estructurado que se devuelve.
- Límites explícitos: acciones, fuentes, formatos y decisiones excluidos.
- Comprobación de aceptación: condiciones observables para aprobar o rechazar.
- Responsable humano: persona autorizada para aprobar, rechazar o pedir una corrección.
Pitstop describe cada máquina como un flujo acotado con entradas, salidas y límites explícitos, cuyo resultado puede aprobar una persona en su página pública. «Aplicar IA a nuestras operaciones» no es un trabajo. «Convertir este lote en este formato, marcar estas excepciones y detenerse» sí puede serlo.
Un alcance fijo no implica que el tema sea sencillo. Significa que la entrega se puede inspeccionar. El comprador puede identificar el paquete, comprobarlo y cerrar la ejecución sin convertir el encargo en un producto de software.
¿En qué se diferencia de contratar a un ingeniero de IA o freelance?
La diferencia está en la forma de la compra. Un trabajo acotado compra un entregable a partir de entradas concretas. Un desarrollo compra trabajo dirigido a un sistema, integración o capacidad continua. Una oferta de empleo compra el tiempo y el rol de una persona. Las tres vías pueden ser válidas, pero necesitan briefs distintos.
| Vía de compra | Qué se define primero | Resultado adecuado | Pregunta antes de aprobar |
|---|---|---|---|
| Trabajo de catálogo | Entrada, salida y límites publicados | Un entregable inspeccionable | ¿Coincide la ficha con la solicitud? |
| Trabajo fijo a medida | Contrato de entrada y entregable | Una entrega acotada | ¿Se puede comprobar la aceptación? |
| Desarrollo freelance | Requisitos, interfaces, propiedad y mantenimiento | Herramienta o flujo continuo | ¿Quién lo opera y modifica? |
| Puesto de trabajo | Responsabilidades y encaje organizativo | Contribución continua | ¿Es un rol y no un paquete? |
No metas una operación continua en una compra puntual. Si hacen falta conexiones activas, supervisión, gestión de excepciones, reglas cambiantes o mantenimiento, defínelo como desarrollo. La guía de automatización de flujos con IA explica esa categoría. Si aún eliges tipo de producto, consulta herramientas de IA agéntica.
Algunos proveedores usan la expresión «Fixed-Scope Pilots», como Essens Software. La palabra «piloto» no basta. El brief aún debe fijar entradas, entregable, límites y aceptación.
¿Qué entradas y entregables debe fijar el brief?
Empieza por ambos lados de la entrega. Nombra el tipo exacto de entrada y de salida. «Documentos a cambio de conclusiones» obliga a inventar el trabajo durante la ejecución.
Para las entradas, registra:
- Tipos de archivo o estructura de registros aceptados.
- Campos obligatorios.
- Límite del lote o ejecución.
- Idioma o variante cubierta.
- Tratamiento de material ilegible, ausente o contradictorio.
- Material que no debe enviarse, incluidas las claves del modelo.
Para el entregable, indica formato, secciones o columnas obligatorias y marcas de revisión. Una hoja debe nombrar sus columnas. Un informe debe nombrar sus secciones. Una comparación debe explicar cómo cada cambio remite al material aportado. El catálogo de Pitstop muestra ejemplos como un lote PDF o imagen convertido en CSV con indicadores, y una transcripción convertida en DOCX.
La propiedad necesita una línea clara. Indica quién posee el material, quién puede acceder durante la ejecución, quién recibe el entregable y quién puede conservarlo tras la aceptación. Si no hay acuerdo, pausa la solicitud. Una promesa general de confidencialidad no sustituye instrucciones concretas.
¿Cómo se redactan las pruebas de aceptación y los límites?
Una prueba debe ser observable en el entregable y la entrada acordada. No puede depender de si la salida «parece inteligente». Da a una persona controles concretos:
- Presencia: existen todas las secciones, campos y archivos requeridos.
- Forma: el entregable abre en el formato acordado y sigue el esquema.
- Trazabilidad: cuando se exige, las afirmaciones o cambios remiten al material aportado.
- Excepciones: los elementos inciertos o sin respaldo llevan la marca acordada.
- Límite: el entregable cubre el lote acordado y nada más.
- Aprobación: una persona identificada registra aceptación o rechazo.
Patrón de brief:
> Dada [entrada identificada], producir [entregable y formato]. Incluir [campos o secciones]. Marcar [excepciones]. No [acciones excluidas]. El trabajo se acepta cuando [controles observables] se cumplen. [persona o rol] da la aprobación final.
Dedica una sección a los límites. Di si el trabajo puede buscar fuera de las fuentes aportadas, alterar originales, contactar personas, publicar, iniciar pagos o escribir en un sistema activo. «Usar el criterio» no autoriza esas acciones. El límite indica dónde detenerse y qué no afirma hacer el entregable.
Evita objetivos porcentuales si el conjunto y el método de medición no forman parte del brief. «Exacto» no es una prueba independiente. Nombra los registros que se comprueban, el valor esperado y el tratamiento de excepciones.
¿Cuándo importa BYOK?
BYOK significa aportar tus propias claves. Importa cuando el comprador suministra el acceso al modelo. El brief debe decir quién lo aporta, dónde se ejecuta el trabajo y si las credenciales entran en el ejecutor.
Nunca pegues una clave de modelo en un mensaje de solicitud normal. Pitstop afirma que la clave LLM del comprador sigue siendo suya y que la conexión usa OAuth sin pegar claves API en su página de inicio. Para cualquier proveedor, pregunta el método exacto. La etiqueta BYOK no resuelve por sí sola la seguridad.
Separa cuatro elementos:
- Acceso al modelo y titular de la cuenta.
- Acceso al ejecutor y método de autorización.
- Datos de entrada y uso permitido.
- Entregables terminados y destino.
BYOK no define alcance, aceptación ni propiedad. Solo responde a una parte del diseño de acceso.
¿Qué debe conservar aprobación humana?
El entregable final debe tener una persona aprobadora. También debe existir un punto de aprobación antes de enviar, publicar, pagar, borrar, firmar o cambiar un registro activo.
La tarea del revisor debe ser concreta:
- Comparar el entregable con la checklist de aceptación.
- Inspeccionar marcas de revisión y elementos sin respaldo.
- Confirmar que no ocurrieron acciones excluidas.
- Aceptar, rechazar citando fallos o pedir una corrección dentro del alcance.
No escribas solo «humano en el circuito». Nombra a la persona o rol, lo que ve y la decisión que toma. Pitstop dice que los resultados de sus máquinas admiten aprobación humana en su página de inicio. Para comparar grados de independencia, consulta agentes IA autónomos. Un brief acotado conserva un límite de decisión humana sin importar la etiqueta del sistema.
Checklist antes de solicitar el trabajo
- ¿Podemos nombrar un entregable y su formato?
- ¿Tenemos las entradas en la forma acordada?
- ¿Está claro el límite de ejecución?
- ¿Están escritas las acciones excluidas?
- ¿Puede una persona realizar cada comprobación?
- ¿Se han definido las marcas de excepción?
- ¿Se documentan los accesos al modelo y al ejecutor?
- ¿Se asignan el tratamiento de entradas y la propiedad del entregable?
- ¿Hay una persona para la aprobación final?
- ¿La solicitud termina con la entrega?
Si todo está claro, compáralo con el catálogo. Si el entregable está claro pero faltan formato o límites, redacta un encargo a medida. Si necesitas una herramienta mantenida o un flujo continuo, plantea un desarrollo. Si faltan entregable, entradas o responsable, no envíes datos todavía.
Solicitar un trabajo de IA acotado
Preguntas frecuentes
¿Puede ser remoto un trabajo de agente IA con alcance fijo?
Sí. «Remoto» describe dónde ocurre. «Alcance fijo» describe el paquete. La solicitud aún necesita entradas, entregable, límites, aceptación y responsable.
¿Cómo debe tratarse el precio?
Pide precio para el límite de entrada, entregable, aceptación y política de corrección exactos. Confirma qué ocurre si falla la ejecución o la entrada no coincide con la forma acordada. Compara presupuestos solo si cubren el mismo paquete. Pitstop dice que los créditos se liquidan solo tras el éxito y se reembolsan automáticamente tras el fallo en su página de inicio. Comprueba las condiciones de la vía elegida.
¿Basta un prompt?
No. Puede ser una instrucción del trabajo. El brief también necesita entradas, formato, límites, aceptación, acceso, propiedad y aprobación humana.
¿Cuándo conviene contratar a un freelance?
Plantea un desarrollo cuando el resultado sea una herramienta o flujo continuo con conexiones activas, operación, requisitos cambiantes o mantenimiento. Mantén explícitos entregables y propiedad.
¿Puede acotarse la automatización de informes?
Sí, si fuentes, formato, secciones, marcas, lote y prueba son fijos. La recogida recurrente o distribución activa pertenece a un brief de flujo o desarrollo. Consulta automatización de informes.
¿Cómo rechazo una propuesta vaga?
Pregunta: ¿qué aportamos?, ¿qué entregable vuelve?, ¿qué no hará el ejecutor? y ¿cómo lo aceptará nuestro revisor? Si queda una respuesta indefinida, el trabajo no está listo.