Paquete de UAT y go-live del proyecto con cliente (con IA)
Antes del corte a producción, monta pruebas de aceptación de usuario: ChatGPT convierte el alcance en guiones, un Brief UAT en Google Docs, log de defectos en Sheets y cadencia Gmail hasta el go/no-go.
Por DoAIWork · 8 de noviembre de 2026

En proyectos con cliente, la “UAT” muchas veces se convierte en una semana vaga en la que el cliente hace clic al azar y manda bugs por Slack. Así se lanza un viernes sin criterios de pass escritos, sin severidades y con un sponsor que creía que UAT era formación. Las pruebas de aceptación de usuario (UAT) son la ventana en la que usuarios de negocio demuestran que el entregable cumple criterios acordados: no es una demo sorpresa, no es la aceptación de hito para facturar una fase, y no es el hipercare post-lanzamiento.
Este playbook va después de entregar el candidato a release y antes del pase a producción. Combina ChatGPT para convertir el SOW en guiones ejecutables, un Brief UAT en Google Docs, un log de defectos en Google Sheets y tres correos en Gmail que cierran con un go/no-go explícito. Para el paquete de entrega, mira entrega del proyecto; para cambios de alcance durante UAT, usa solicitud de cambio.
Cuándo montar la UAT
Úsalo cuando:
- Staging (o entorno UAT acordado) refleja el RC que vais a publicar.
- Hay criterios de aceptación escritos (SOW, hito o especificación firmada).
- El cliente nombra un responsable UAT con agenda y poder de decidir go/no-go.
- Necesitáis trazabilidad antes de DNS, pagos o URLs públicas.
No lo uses si aún negociáis alcance o el cliente solo pide demo sin compromiso de pruebas.
Flujo completo
Paso 1 — Guiones desde criterios (ChatGPT)
Pega criterios en ChatGPT:
Eres QA lead en una semana UAT con cliente. Criterios: [pega SOW o hito]
Salida:
1) 12–25 casos en tabla: ID, rol, precondiciones, pasos, resultado esperado, prioridad (P0/P1/P2)
2) Cinco pruebas negativas (permisos, vacíos, bordes)
3) Fuera de alcance UAT (lista explícita)
Cada caso debe citar un criterio del documento.
Lleva la tabla al Brief UAT. Tú validas que un no técnico pueda ejecutarlos.
Paso 2 — Brief UAT de una página (Google Docs)
| Sección | Contenido |
|---|---|
| Cabecera | Proyecto, versión/build RC, fechas UAT (husos horarios) |
| Entornos | URLs, cuentas de prueba, reglas de reset de datos |
| Roles | Owner UAT, testers, tu contacto, escalado |
| Criterios de entrada | Qué debe estar listo el día 1 (smoke OK, contenido cargado) |
| Criterios de salida | P0=0 abierto; P1 con waiver o fix; go/no-go firmado |
| Severidades | P0 bloquea lanzamiento; P1 fix o waiver pre-go; P2 backlog |
| Guiones | Tabla completa generada con ChatGPT |
| Proceso defecto | Cómo loguear en Sheets y SLA de triaje |
| Reunión go/no-go | Agenda y regla de decisión |
Comparte en comentarios hasta acordar guiones; luego edición solo en el log.
Paso 3 — Log de defectos (Google Sheets)
Columnas: ID, Caso, Severidad, Pasos, Esperado, Actual, Captura, Estado, Responsable, Fecha retest.

Triage con ChatGPT (una fila, datos personales redactados):
Etiqueta HECHO vs SUPOSICIÓN. Defecto UAT: [pega].
Clasifica P0/P1/P2 según nuestro brief.
Propón: datos para reproducir, o texto de waiver si es cosmético.
No cierres defectos sin retest humano.
Paso 4 — Cadencia Gmail (tres correos)
- Kickoff UAT — Brief, URLs, invitaciones a testers, horario de soporte, enlace al log.
- Checkpoint mitad UAT — Recuento por severidad, bloqueantes, waivers candidatos, fecha go/no-go.
- Resultado go/no-go — GO o NO-GO explícito, waivers P1 firmados, siguiente paso (ventana de lanzamiento o retest).
Redacta en ChatGPT; envía tú desde Gmail con fechas y build reales.
Paso 5 — Reunión go/no-go (30 min)
Agenda: smoke en staging; revisión P0/P1 en Sheets; waivers y riesgos; decisión y responsable de comunicar.
Si es NO-GO, define retest acotado (P0/P1)—no repitas toda la batería salvo cambio de criterios.
Paso 6 — Puente a lanzamiento, hipercare o garantía
Con GO: confirma lanzamiento, contacto de rollback, monitor primera hora; P2 deferidos pasan a hipercare o backlog; anota inicio de garantía si el contrato lo define.
Con NO-GO: time-box de fixes y retest focalizado; NO-GO por escrito evita el “aprobamos por teléfono” posterior.
Errores habituales
- Sin criterios de salida — la UAT no termina nunca.
- Solo prueban desarrolladores — negocio no valida flujos reales.
- Slack como sistema de defectos — usa Sheets.
- Mezclar UAT con formación — sepáralo en el Brief.
- Go-live sin texto de waiver — P1 cosméticos acaban en guerra de garantía.
Checklist rápido
- Build RC congelado en el Brief
- Guiones trazan a criterios escritos
- Responsable UAT nombrado
- Sheets es la única entrada de defectos
- Tres correos enviados o programados
- Decisión go/no-go en el Doc
Más guías en guides para autónomos y pymes que entregan proyectos con IA—pruebas estructuradas sin fingir que el modelo firma por el cliente.
Guías relacionadas

Cuestionario post-discovery: tarea para el cliente con IA (Forms + Gmail)
Tras el recap post-llamada, envía un Google Forms breve—redactado con ChatGPT y entregado por Gmail—para que el cliente confirme por escrito antes de redactar el alcance.
Leer guía
Email de recap tras la llamada de discovery: redáctalo con IA el mismo día
Tras una llamada comercial o de discovery, envía el mismo día un recap que confirma decisiones, deja preguntas abiertas y fija un plan de acción compartido con ChatGPT, Google Docs y Gmail.
Leer guía
Brief antes de la llamada con el cliente: montarlo con IA en 10 minutos (Calendly)
Deja de improvisar en Zoom. Junta respuestas de Calendly, hilos de Gmail y notas sueltas en un brief de una página para escuchar mejor y presupuestar con criterio.
Leer guía