# Ficha de especificación de un agente > Quince campos que se llenan antes de construir nada, ocho casos de prueba y la condición de apagado. Incluye la columna que más se olvida: qué NO debe hacer. - Autor: César Medina - Publicado: 2026-09-05 - Tema: Agentes que trabajan solos - Plantilla: https://docs.google.com/spreadsheets/d/1WC-ueI_p2tOeQ5cJ_TPnQhOqbF0u9FJMl21_9hqdOBc/copy - Palabras clave: especificación de un agente, documentar agente IA, casos de prueba agente Un agente falla casi siempre por lo que nadie escribió que no debía hacer. Esta ficha son quince campos que se llenan antes de construir nada, ocho casos de prueba y una condición de apagado, todo en una hoja que cabe en una pantalla. > **Puntos clave** > > - «Qué hace exactamente» tiene que caber en una frase con un solo verbo. Si necesitas dos, son dos agentes. > - Tres de los ocho casos de prueba miden abstención, no acierto. > - La condición de apagado se escribe el primer día, cuando todavía no hay nadie defendiendo el proyecto. ## ¿Por qué llenar una ficha antes de construir? Porque el trabajo de escribirla es el que descubre que el caso no está definido. La mitad de los campos se contestan solos; los que cuestan son justo los que importan: | Campo | Qué revela cuando cuesta llenarlo | |---|---| | Qué hace exactamente | Que en realidad son tres tareas y hay que partirlas | | Qué NO debe hacer | Que nadie había pensado los límites | | Criterio de éxito | Que no hay forma de saber si funciona | | Qué pasa si no está seguro | Que el agente va a adivinar en producción | | Cuándo se apaga | Que el proyecto no tiene salida prevista | El campo de la segunda fila es el que más se salta. Una ficha que dice «clasifica correos de soporte» sin añadir «no responde al cliente, no cierra tickets, no escribe al CRM» está delegando esos límites al modelo, y el modelo no tiene por qué conocerlos. ## ¿Qué distingue estos casos de prueba de una demostración? Que tres de los ocho miden que el agente se calle. El caso 4 le da una entrada de tres palabras, el 5 una respuesta automática de vacaciones y el 6 un correo con datos de tarjeta. En los tres, la salida correcta es abstenerse o no repetir el dato sensible. Un agente que acierta en los cinco casos normales y falla en esos tres funciona en la demostración y produce incidentes en producción. Casi todas las pruebas miden si el agente puede resolver la tarea, y lo que acaba causando problemas es que no sepa cuándo no debe intentarlo. Los ocho casos se corren de nuevo **cada vez que cambies el prompt, el modelo o la versión**. Un cambio de modelo que sube el promedio puede romper un caso concreto, y sin la lista no hay forma de enterarse hasta que se queja alguien. ## ¿Qué va en la bitácora? Una fila por revisión: cuántos casos se miraron, cuántos acertó, cuál fue la falla más común y qué se cambió. Es lo que convierte la supervisión en algo que se puede auditar, y lo que permite decidir con datos si el agente sigue o se retira. El campo de costo mensual también se llena desde el principio, con el volumen y el precio por operación a la vista. Un agente barato por operación y con mucho volumen puede salir más caro que la persona a la que reemplaza, y ese cálculo es mejor hacerlo antes. ## ¿Cuándo no hace falta un agente? Cuando la tarea tiene reglas fijas y no requiere interpretar nada. Si el criterio se puede escribir como una condición, una automatización normal lo hace más barato, más rápido y sin variabilidad. Antes de llenar esta ficha conviene pasar el caso por la [matriz de priorización de casos de uso de IA](/recursos/plantillas/plantilla-priorizacion-casos-de-uso-ia), que además te dice si el dato que necesita está en condiciones. ## Preguntas frecuentes ### ¿Qué es lo que más se olvida al especificar un agente? Los límites. Casi todas las fichas describen qué debe hacer el agente y casi ninguna escribe qué no debe hacer. Ese vacío es donde aparecen los incidentes: el agente que responde al cliente cuando solo debía clasificar, o el que cierra un ticket que nadie le pidió cerrar. ### ¿Por qué escribir la condición de apagado desde el primer día? Porque después de seis meses de operación nadie quiere ser quien lo apaga. Con un umbral escrito antes de arrancar, retirarlo deja de ser una decisión política y se convierte en aplicar una regla que ya estaba acordada. ### ¿Cuántos casos de prueba hacen falta? La plantilla trae ocho y esa cifra funciona bien. Lo importante no es el número sino que al menos tres midan abstención: qué hace el agente con una entrada ambigua, con una que no le corresponde y con una que trae datos sensibles. Eso es lo que separa una prueba de una demostración. ## Preguntas frecuentes ### ¿Qué es lo que más se olvida al especificar un agente? Los límites. Casi todas las fichas describen qué debe hacer el agente y casi ninguna escribe qué no debe hacer. Ese vacío es donde aparecen los incidentes: el agente que responde al cliente cuando solo debía clasificar, o el que cierra un ticket que nadie le pidió cerrar. ### ¿Por qué escribir la condición de apagado desde el primer día? Porque después de seis meses de operación nadie quiere ser quien lo apaga. Con un umbral escrito antes de arrancar, retirarlo deja de ser una decisión política y se convierte en aplicar una regla que ya estaba acordada. ### ¿Cuántos casos de prueba hacen falta? La plantilla trae ocho y esa cifra funciona bien. Lo importante no es el número sino que al menos tres midan abstención: qué hace el agente con una entrada ambigua, con una que no le corresponde y con una que trae datos sensibles. Eso es lo que separa una prueba de una demostración. --- Fuente: https://c2suite.com/recursos/plantillas/plantilla-especificacion-de-un-agente Puedes citar y resumir este contenido atribuyéndolo a C2Suite y enlazando a la URL de origen.