La mayoría de los equipos comienza a construir sistemas de IA eligiendo un modelo, esbozando una capa de recuperación y conectando una API. El alcance viene después — generalmente escrito en un README tras el primer sprint.
Ese orden está al revés. La primera pregunta que debe responder tu sistema no es un detalle de documentación. Es la decisión estructural sobre la que descansa cada elección posterior.
Qué significa realmente la "primera pregunta"
Todo sistema de IA se construye para responder algo. No una categoría de cosas — una cosa específica, formulada con precisión.
Para un sistema de ventas, la primera pregunta podría ser: "¿Cuál de estas 200 cuentas tiene más probabilidad de responder a un contacto esta semana?" O podría ser: "¿Qué objeción es más probable que plantee este prospecto en una segunda llamada?" Suenan relacionadas. No lo están. Requieren datos distintos, lógica de recuperación distinta y formatos de salida distintos.
La primera pregunta es aquella que el sistema debe responder correctamente antes de que cualquier otra salida tenga valor. Todo lo demás es consecuencia de ella.
La mayoría de los equipos nunca escribe esa oración antes de empezar a construir.
Cómo se propaga el error
Aquí hay un patrón real de antes/después.
Antes: Un equipo que construía un sistema de inteligencia de ventas definió su primera pregunta de forma vaga como "ayudar a los representantes a entender sus cuentas". Construyeron una capa de recuperación que extraía notas del CRM, datos de LinkedIn y noticias recientes. Construyeron una capa de resumen encima. Los representantes recibían resúmenes de cuentas.
Seis meses después, el sistema no se estaba usando. Los representantes decían que los resúmenes eran "interesantes pero no accionables". El equipo agregó más fuentes de datos. El uso se mantuvo estable.
El problema real: el sistema estaba respondiendo la primera pregunta equivocada. Los representantes no necesitaban entender las cuentas — necesitaban saber a qué cuenta llamar hoy y por qué. Esa es una pregunta de priorización, no de resumen. Requiere señales de recencia, etapa del pipeline y datos de capacidad del representante. Nada de eso estaba en la capa de recuperación.
La reconstrucción tomó ocho semanas. El modelo de datos cambió. La lógica de recuperación cambió. La estructura del prompt cambió.
Después: Un equipo diferente comenzó con un documento de alcance de una página antes de tocar la infraestructura. Su primera pregunta declarada: "Dado el pipeline abierto de un representante y los últimos 30 días de actividad de cuentas, ¿a cuáles tres cuentas debería contactar hoy?"
Esa oración forzó decisiones inmediatas:
- ¿Qué cuenta como "actividad de cuenta"? (Definir las fuentes de datos.)
- ¿Qué significa "debería contactar"? (Definir la lógica de puntuación.)
- ¿Cuál es el formato de salida? (Una lista ordenada con una razón de una línea por cuenta — no un resumen.)
La capa de recuperación se delimitó a esas entradas desde el primer día. El prompt se escribió para producir una lista ordenada, no prosa. El sistema salió en vivo en cuatro semanas y tuvo un 80% de uso activo semanal entre el equipo de representantes durante el primer mes.
La misma categoría de sistema. Una primera pregunta diferente. Una construcción completamente diferente.
El patrón de falla en cascada
Cuando la primera pregunta es incorrecta o está indefinida, se producen tres modos de falla:
- Datos mal enrutados. La capa de ingesta extrae todo lo que parece relevante. Los costos de almacenamiento crecen. La relación señal-ruido cae. El sistema recupera contexto que es técnicamente relacionado pero operacionalmente inútil.
- Recuperación incorrecta. La búsqueda semántica optimizada para la consulta equivocada devuelve resultados que parecen plausibles pero no responden lo que el usuario realmente necesita. El sistema parece que funciona. No funciona.
- Reconstrucciones costosas. El modelo de datos, el índice de recuperación y la estructura del prompt están todos acoplados a la primera pregunta. Cambia la pregunta y cambias los tres. Los equipos que omiten el alcance lo pagan en reconstrucciones, no en el sprint inicial.
El ejercicio de alcance de una página
Antes de definir cualquier infraestructura, DK1.AI realiza un ejercicio de alcance con un único resultado: una sola oración que declara la primera pregunta que el sistema debe responder.
El ejercicio tiene cuatro pasos:
- Nombra al usuario y el momento. ¿Quién usa el sistema y en qué punto de su flujo de trabajo? No "representantes de ventas" — "un ejecutivo de cuenta que tiene 90 minutos antes de su primera llamada del día".
- Nombra la decisión. ¿Qué decisión necesita tomar el usuario en ese momento? No "entender la cuenta" — "decidir si llamar a esta cuenta hoy o esperar".
- Nombra la salida. ¿Cómo se ve una respuesta correcta? No "un resumen" — "un sí/no con una razón de una oración".
- Nombra la condición de falla. ¿Qué cuesta una respuesta incorrecta? Si la respuesta es "no mucho", probablemente la primera pregunta no es la correcta.
Esas cuatro respuestas se colapsan en una oración. Esa oración se convierte en el criterio de aceptación para cada decisión de construcción posterior.
Esto no es un taller de descubrimiento. Es una sesión de trabajo de 60 minutos con las personas que usarán el sistema. El resultado es un documento, no una presentación.
Dónde aplica esto DK1.AI
AI Brand Presence comienza con el mismo ejercicio — definiendo la pregunta específica que un comprador le hace a un sistema de IA sobre tu empresa antes de construir cualquier contenido o arquitectura de recuperación. La primera pregunta que hace un comprador determina qué señales importan. Equivocarse en eso significa construir presencia en el lugar equivocado para la consulta equivocada.
El patrón se aplica en cada sistema que construimos. Alcance primero. Infraestructura después.
Si estás a punto de iniciar una construcción de IA — o llevas seis meses y el uso es plano — la primera pregunta vale una hora antes de que cualquier otra cosa avance.