Los requerimientos de agentes de IA son las especificaciones estructuradas de negocio que definen qué debe hacer un agente de IA, para quién y por qué — antes de escribir una sola línea de código.

En un estudio controlado sobre 21 prototipos de agentes de IA, el 80% fueron abandonados antes de completarse. La razón no fue incapacidad técnica, sino una falta fundamental de valor de negocio o de acceso a datos.

“Puedes hacer prompting a tu IA, pero no puedes hacer prompting a la sala.”

El nuevo cuello de botella

Vivimos en una era donde los modelos de lenguaje generan miles de líneas de código funcional en segundos. El acto técnico de construir software ha dejado de ser la restricción principal. En su lugar, ha emergido un nuevo cuello de botella: definir qué construir.

Mientras el costo de generar código tiende a cero, el costo del esfuerzo mal dirigido aumenta. El Shadow AI —la adopción fragmentada de herramientas de IA por departamentos sin supervisión central— se expande, pero las organizaciones que cruzan el abismo entre el experimento y el ROI son aquellas que se enfocan en el elemento humano de la elicitación de requerimientos.

El trabajo real ya no está en la sintaxis del código, sino en el matiz de la sala de juntas.

La trampa del «caballo más rápido»

La famosa analogía de Henry Ford aplica perfectamente aquí: si le preguntas a tus clientes qué quieren, te pedirán una versión más rápida de lo que ya tienen. En el contexto de la IA, esto lleva al vibe coding: crear versiones digitales de procesos manuales ineficientes sin cuestionar su valor subyacente.

Como la IA está entrenada en el promedio del conocimiento humano, por defecto produce soluciones genéricas. Para ir más allá del promedio y lograr un salto en rendimiento, los humanos deben cerrar la brecha entre la intención de negocio y la ejecución técnica.

Esto requiere mover a los pensadores más estratégicos «río arriba»: en lugar de enfocarse en el output, deben enfocarse en la elicitación de requerimientos de stakeholders, tomadores de decisiones y usuarios finales. El nuevo foso competitivo de una empresa no es su acceso a un modelo de IA —todos lo tienen— sino su capacidad para entender y mapear su propia lógica de negocio interna.

El marco VAD: Value, Architecture, Design

Para pasar del Shadow AI fragmentado a sistemas gobernados y soberanos, las organizaciones necesitan una metodología repetible. El marco VAD (Value, Architecture, Design) propone tres etapas:

1. Value: identificar el resultado

Antes de discutir modelos o integraciones, el primer paso es cuantificar el resultado de negocio. Cuatro preguntas fundamentales:

  • ¿De quién es este problema? Debes poder nombrar una persona o departamento específico que siente la fricción.
  • ¿Cómo se ve ganar? Define el resultado concreto: ¿es una respuesta más rápida, un proceso más seguro, un output más consistente?
  • ¿Qué haría que se negaran a usarlo? Identificar puntos de fricción temprano evita desarrollar shelfware (software que nadie usa).
  • ¿Cambia una decisión? Los agentes de mayor valor no solo mueven datos: inclinan al usuario hacia una mejor decisión, más rápida.

2. Architecture: construir la base soberana

Una vez claro el valor, el foco se desplaza a la arquitectura subyacente. Aquí las organizaciones deciden entre una integración SaaS frágil y un sistema soberano de agentes de IA, donde los datos, la memoria y el razonamiento permanecen bajo control de la empresa.

La fase de arquitectura define cómo el agente interactúa con los sistemas de registro (CRM, ERP) y dónde se almacena el estado persistente. Esta etapa es crítica para pasar auditorías de procurement y seguridad, moviendo al agente de un «demo genial» a infraestructura de producción.

3. Design: elicitar la experiencia de usuario

Solo después de asegurar el valor y la arquitectura se pasa al diseño. No se trata solo de la interfaz visual, sino del modelo de interacción: ¿cómo se comunica el agente? ¿Cómo maneja errores? Siguiendo esta secuencia, las empresas evitan el error común de diseñar una solución para un problema que no existe o que no vale la pena resolver.

Por qué el user story mapping es el nuevo foso

Una de las herramientas más efectivas para la elicitación de requerimientos de agentes de IA es el mapeo de historias de usuario (user story mapping). Aunque parezca una reliquia del product management tradicional, es en realidad la forma más eficiente de empaquetar contexto para una IA.

Los modelos de lenguaje están altamente optimizados para el reconocimiento de patrones y han sido entrenados en millones de ejemplos de historias de usuario estructuradas (Persona, Necesidad, Por qué). Al crear un story map que desglosa un proceso en su columna vertebral —por ejemplo: contactar, triage, resolver y cerrar un caso de soporte— se genera una hoja de ruta coherente para el desarrollo.

Cuando estas historias se documentan en un formato estándar y se almacenan en un repositorio compartido, funcionan como la fuente de verdad para la IA. Esto permite encadenar agentes en un sistema coherente. Si le das a una IA un prompt genérico como «construye un agente de soporte», los resultados serán mediocres. Si le proporcionas un archivo Markdown con un story map detallado y criterios de aceptación específicos, la IA generará una especificación significativamente más precisa y operativamente relevante.

Sigue explorando estos temas en el blog de DojoFullStack. En nuestros artículos profundizamos en agentes de código, automatización inteligente y las mejores prácticas para desarrollar software con IA en el ecosistema LATAM.