Cómo hacer el briefing a un estudio de desarrollo para que tu PoC de IA arranque rápido
Cuando un PoC de IA de dos semanas se retrasa, el tiempo perdido casi nunca está en el trabajo con el modelo. Está en la primera semana, y la mayor parte recae en el lado del comprador: esperar un archivo de muestra, una credencial de API o la respuesta a "quién es realmente el dueño de este proceso". La velocidad del estudio importa, pero tú controlas la variable que importa más: lo que llevas a la primera llamada.
La solución no es un documento de requisitos más largo. Es uno más corto: una sola página que responda a las seis preguntas que cualquier estudio competente va a hacer de todos modos.
El brief de una página
Si puedes rellenar estos seis puntos, un estudio puede volver con un alcance y un precio reales en días en lugar de semanas:
Responsable del flujo de trabajo. Nombra a la persona que hace o supervisa el trabajo a diario y puede responder "¿este resultado es correcto?" en cuestión de horas. No el patrocinador ejecutivo, no el contacto de IT.
Recorrido del proceso actual. De cinco a diez pasos en formato disparador → acción → resultado. Dónde empieza, quién interviene y dónde acaba el resultado.
Datos de muestra. Veinte ejemplos anonimizados valen más que cualquier documento de especificaciones. Correos reales, PDFs reales, filas reales — con nombres y números de cuenta sustituidos, no eliminados.
Estado de sistemas y accesos. Qué sistemas toca el flujo, si tienen API y — con honestidad — quién debe aprobar las credenciales y cuánto suele tardar.
Una métrica de éxito. Un único número que te convencería: "el 80% de los tickets bien clasificados", "el borrador del informe en 10 minutos en vez de 3 horas".
La decisión tras la demo. Qué se decide cuando termina el PoC — integrar, ampliar o parar — y quién toma esa decisión.
Los datos de muestra merecen el énfasis. Un estudio puede dimensionar el trabajo sin documentación completa; no puede dimensionarlo con datos invisibles. Veinte ejemplos reales exponen el caos de formatos, los casos límite y la dificultad real — que es en lo que tiene que basarse un precio honesto.
Qué no escribir
El error más común en un briefing es sobreespecificar la solución y subespecificar el problema. Deja fuera esto:
Diseños de solución. "Construir un pipeline RAG con capa de agentes" encierra al equipo en tu suposición antes de que nadie haya visto los datos.
Elecciones de modelo. Qué LLM usar es una decisión de ingeniería, tomada según tus restricciones de precisión, coste y residencia de datos — y revisada a medida que los modelos cambian.
Listas de funcionalidades. Un PoC tiene un flujo de trabajo y una métrica. Una lista de deseos con diez funcionalidades es un backlog de MVP disfrazado de PoC.
Estás comprando criterio, no tecleo. Describe el problema con precisión y deja que la propuesta te muestre cómo piensa el estudio.
Resuelve la seguridad y el NDA pronto
La revisión de seguridad es el asesino silencioso más común de la primera semana. Secuénciala antes del kickoff, no durante:
Firma un NDA mutuo antes de compartir muestras. Cualquier estudio serio tiene uno preparado; una semana de idas y venidas legales por un NDA estándar es una mala señal de proceso en cualquiera de los dos lados.
Pon por escrito las reglas de datos. Qué puede salir de tu red, qué campos deben enmascararse y cuánto tiempo puede el proveedor retener datos y registros — bajo GDPR o APPI, según dónde operes.
Nombra a la persona que aprueba la revisión de seguridad, y arranca esa revisión en paralelo a la conversación comercial, no después.
Señales de alarma en las respuestas de los proveedores
El brief también es una sonda. Envía la misma página a dos o tres estudios y observa cómo responden:
Ninguna pregunta de vuelta. Un estudio que lee "clasificar facturas de proveedores" y se pone a proponer no ha entendido el problema. La respuesta correcta a un buen brief son mejores preguntas.
Un presupuesto fijo instantáneo sin ver los datos. Quien pone precio a un flujo de IA antes de mirar las muestras está poniendo precio a una plantilla, no a tu problema.
Negarse a criterios de aceptación. Si un proveedor no se compromete con una definición de "hecho" medible, el PoC no puede fallar — lo que también significa que no puede demostrar nada. Este es el argumento central a favor de un PoC de pago frente a un piloto gratuito.
Respuestas vagas sobre quién hace el trabajo. Pregunta si el ingeniero que dimensiona el proyecto es el mismo que lo construye. Los briefs que pasan por un comercial, un analista y un subcontratista pierden exactamente el detalle que escribiste para transmitir.
Qué cubre una buena primera llamada
Cuando el brief existe, la primera llamada deja de ser teatro de descubrimiento y se convierte en una sesión de trabajo:
Un recorrido en vivo del proceso real — pantalla compartida, no diapositivas.
Un primer vistazo a los datos de muestra, con el ingeniero que construiría el PoC presente.
Una propuesta de recorte de alcance: qué entra en el PoC y qué queda explícitamente fuera.
Un borrador de la métrica de éxito y cómo se medirá en la demo.
Logística: cadencia de demos (la semanal funciona), plan de accesos, fechas y un rango de precio — como referencia, nuestros paquetes van de una auditoría de 1 semana a un sprint de MVP de 4 semanas.
Si sales de la primera llamada sin que nadie haya discrepado en nada, el alcance no se discutió con suficiente concreción.
Una plantilla de brief para copiar y pegar
```markdown
Brief de PoC de IA — [nombre del flujo de trabajo]
Responsable del flujo: [nombre, rol — la persona que puede juzgar si el resultado es correcto]
El problema en una frase: [qué duele, con qué frecuencia, quién lo sufre]
Proceso actual (5-10 pasos)
1. Disparador: [qué inicia el proceso]
2. [paso — quién hace qué, en qué sistema]
3. Resultado: [qué se produce, dónde acaba]
Datos de muestra
Adjunto: [20+ ejemplos anonimizados — formatos y cantidad]
No se puede compartir: [qué y por qué — propuesta: sustitutos anonimizados]
Sistemas y accesos
Sistemas implicados: [nombres, versiones]
Estado de la API: [existe / desconocido / requiere aprobación de <quién>]
Entorno de pruebas: [disponible / requiere montaje — plazo estimado]
Éxito
Métrica: [un número, con la línea base actual]
Decisión tras la demo: [integrar / ampliar / parar — decide <quién>]
Restricciones
NDA / revisión de seguridad: [estado, quién aprueba]
Calendario: [fecha límite o ventana presupuestaria, si la hay]
```
Qué pasa después
Con este brief en la mano, la conversación de alcance se comprime. Un estudio puede volver en días con un alcance por escrito, criterios de aceptación y un precio, y el sprint en sí empieza con los datos en lugar de con una caza de documentos.
Antes del kickoff, repasa la checklist para un PoC de DX — profundiza en la preparación de datos y la configuración del entorno. El brief te da un arranque rápido; la checklist mantiene honestas las dos semanas.