Cómo validar un asistente de IA en seis semanas sin confundirlo con producción

Seis semanas pueden bastar para responder una pregunta útil: si un asistente acotado mejora un flujo real bajo condiciones controladas. No bastan para prometer que cualquier empresa tendrá una solución completa, integrada y preparada para toda su plantilla.

Esta hoja de ruta termina en una decisión, no en una demo: pasar a producción, iterar con cambios, resolver una dependencia o cerrar el piloto.

Qué significa «validar en seis semanas»

El objetivo es construir y evaluar una primera versión de bajo alcance. Puede responder sobre un conjunto documental, preparar un borrador, clasificar solicitudes o guiar a una persona dentro de un proceso. Debe quedar fuera todo lo que no sea necesario para comprobar la hipótesis principal.

El calendario es orientativo. Si la privacidad, la seguridad, la contratación o la integración necesitan más tiempo, no se acortan ocultándolas: se reduce el alcance o se mueve la fecha.

Condiciones previas

Antes de iniciar la semana uno, confirma estas cinco condiciones:

• Un propietario operativo puede definir calidad y cambiar el flujo.
• Hay entre cinco y diez usuarios representativos disponibles para probar.
• Las fuentes iniciales tienen propietario, permiso y versiones identificadas.
• El piloto no necesita ejecutar acciones irreversibles para demostrar valor.
• Existe capacidad técnica y de negocio para revisar resultados cada semana.

Si faltan dos o más, el trabajo inicial no es construir el asistente. Es delimitar el caso y preparar el entorno con la checklist de 20 preguntas.

Semana 1: delimitar el flujo y conservar la línea base

El equipo observa el trabajo actual antes de diseñar la interfaz. Documenta quién inicia el flujo, qué información consulta, qué salida necesita, qué excepciones aparecen y quién responde por el resultado.

1. Redactar el problema sin mencionar todavía el asistente.
2. Delimitar inicio, final, usuarios y casos fuera de alcance.
3. Medir la línea base: tiempo, espera, correcciones, volumen o calidad, según el problema.
4. Identificar daños posibles, reversibilidad y puntos de aprobación.
5. Definir la hipótesis y el cambio mínimo que justificaría continuar.

Entregable: ficha del flujo, línea base y decisión que tomará el piloto.
Puerta de salida: si no existe problema observable, propietario o forma de comparar, el calendario se detiene.

Semana 2: preparar conocimiento, permisos y evaluación

La segunda semana no consiste en cargar todos los documentos disponibles. Consiste en elegir el conocimiento autorizado y representativo para el alcance.

Registra para cada fuente su propietario, versión, fecha de vigencia, permisos, fragmentación o estructura y mecanismo de actualización. Separa contenido normativo, material de referencia y conversaciones históricas; no merecen la misma confianza.

En paralelo, crea el conjunto de evaluación:

• casos frecuentes que el asistente debe resolver;
• casos difíciles que exigen combinar información;
• preguntas sin evidencia suficiente;
• contenido conflictivo u obsoleto;
• solicitudes que deben rechazarse o escalarse;
• criterios de revisión y respuesta de referencia cuando exista.

Reserva una parte del conjunto para la evaluación final. Si todo se utiliza para ajustar el prototipo, el resultado medirá memoria del equipo, no generalización al trabajo real.

Entregable: inventario de fuentes, matriz de permisos y conjunto de evaluación versionado.
Puerta de salida: no se ingiere una fuente sin propietario, permiso o criterio de vigencia.

Semanas 3 y 4: construir el sistema mínimo evaluable

La primera versión necesita menos funciones y más trazabilidad. Una arquitectura típica separa interfaz, orquestación, recuperación de conocimiento, modelo, controles y registros. El modelo no debe recibir acceso directo a todo ni decidir por sí solo qué puede ejecutar.

Durante estas dos semanas:

1. Implementa el flujo principal y una salida segura para lo que no puede resolver.
2. Añade citas o evidencia cuando la respuesta dependa de fuentes internas.
3. Aplica permisos y filtros antes de recuperar contenido, no después de generar la respuesta.
4. Registra versión de fuentes, instrucciones, modelo, latencia, coste y correcciones.
5. Ejecuta evaluaciones frecuentes y conserva regresiones; una mejora media no debe esconder un fallo grave.

El objetivo no es «resolver el 80 %» por decreto. Ese porcentaje no significa nada si los casos restantes incluyen errores peligrosos o si la revisión cuesta más que el proceso anterior. Define cobertura y umbrales según el flujo.

Entregable: prototipo trazable y resultados de evaluación por tipo de caso.
Puerta de salida: no pasa a usuarios si falla controles básicos, expone información indebida o no reconoce los casos que debe escalar.

Semana 5: probar con usuarios y trabajo representativo

Entre cinco y diez usuarios realizan tareas reales o reproducidas en un entorno controlado. El equipo observa, no solo pregunta si les ha gustado.

Conviene registrar:

• si encuentran el asistente en el momento adecuado del flujo;
• qué casos intentan resolver y cuáles abandonan;
• respuestas aceptadas, corregidas, rechazadas o escaladas;
• tiempo de producción y tiempo de revisión;
• errores de fuentes, permisos o experiencia;
• confianza mal calibrada: aceptar sin revisar o revisar todo por igual.

Una encuesta positiva demuestra interés. La repetición, la incorporación al flujo y la reducción de trabajo neto aportan evidencia de adopción y valor más sólida. La guía de OpenAI Academy sobre evidencia recomienda distinguir señales medidas, observadas, reportadas, estimadas, planificadas y desconocidas.

Entregable: informe de uso, fallos, correcciones y efecto sobre el proceso.
Puerta de salida: si el usuario necesita revisar todo o el asistente desplaza trabajo a otra función, se rediseña antes de ampliar.

Semana 6: corregir y tomar la decisión de producción

La última semana incorpora solo mejoras críticas y repite la evaluación reservada. Después, negocio, tecnología y riesgo revisan la evidencia juntos.

La salida puede ser una de cuatro:

• Pasar a producción limitada: la evidencia cumple y existe plan operativo.
• Iterar: el valor parece real, pero un fallo acotado requiere otra versión.
• Secuenciar: una dependencia de datos, permisos, integración o proceso debe resolverse primero.
• Cerrar: el enfoque no mejora el flujo o el coste y el riesgo no se justifican.

Lo que falta entre un piloto y producción

Una solución en producción necesita requisitos que quizá solo se simularon durante el piloto:

• autenticación e identidad del sistema;
• permisos por usuario y fuente;
• evaluación de cambios de modelo, instrucciones y documentos;
• monitorización de calidad, latencia, coste e incidentes;
• disponibilidad, continuidad, copias y recuperación;
• soporte, propietario y frecuencia de revisión;
• privacidad, seguridad, contrato y obligaciones regulatorias aplicables;
• formación y comunicación para usuarios y personas afectadas.

Para asistentes que interactúan directamente con personas, revisa si aplican las obligaciones de transparencia del artículo 50 del AI Act desde el 2 de agosto de 2026. La Comisión Europea distingue proveedor y desplegador y ofrece ejemplos; el análisis concreto depende de cómo se desarrolla, comercializa y usa el sistema.

Cuándo no recomendamos este calendario

No recomendamos comprometer seis semanas cuando el caso afecta derechos o decisiones de alto impacto, necesita integraciones aún no autorizadas, depende de conocimiento sin propietario, exige contratación compleja o pretende reemplazar de inmediato una operación crítica. En esas situaciones puede mantenerse un sprint de descubrimiento, pero no presentarlo como calendario de implantación.

Preguntas frecuentes