Recommended resources
The freely available resources this lesson will direct you to.
¡Hola! En la lección anterior definiste pruebas, salvaguardas y criterios para decidir si un asistente que redacta borradores internos de soporte puede pasar de demostración a piloto. Hoy usarás esas condiciones para elaborar un plan de despliegue por fases: qué ocurrirá antes, durante y después del piloto; cuándo; de quién depende cada actividad; y qué evidencia permitirá avanzar.
El resultado no será solo un calendario. Será una propuesta que puedas discutir con un cliente sin confundir «tenemos una herramienta funcionando» con «estamos preparados para que la utilicen más personas». Calcula unos 40 minutos entre los recursos y el ejemplo desarrollado.
Del prototipo a un piloto con propósito
Conviene separar tres situaciones. La prueba de concepto comprueba si la idea puede funcionar en condiciones controladas. El piloto incorpora a un grupo pequeño de usuarios para observar si la solución resulta útil y gestionable en su trabajo. El despliegue ampliado incorpora más equipos, con capacidad de soporte y controles que puedan sostenerse. Cada situación exige evidencias distintas: una demostración técnica no prueba por sí sola la utilidad cotidiana ni la preparación para ampliar el uso.
AWS Prescriptive Guidance organiza el ciclo de una aplicación de IA generativa en desarrollo, preproducción y producción. No necesitas adoptar toda su infraestructura para planificar nuestro caso; sí resulta útil su principio de avanzar con configuraciones validadas y decisiones basadas en evidencia.
[PDF] AWS Prescriptive Guidance - Generative AI Lifecycle Operational ...
Lee la guía de AWS Prescriptive Guidance para distinguir las etapas del ciclo de vida y observar cómo plantea la decisión de pasar de una prueba de concepto a un piloto.
En «About the GLOE stages» (pp. 7-8), comienza donde el texto presenta las tres etapas y lee las etapas y actividades, incluidas «Development stage», «Preproduction» y «Production». Después, en «Advancing a generative AI PoC to preproduction» (pp. 41-43), lee la decisión de avance hasta el final de «Preparing for preproduction». Fíjate en la combinación de métricas, opiniones de usuarios, estabilidad y cambios pendientes; no hace falta profundizar en las herramientas de infraestructura que menciona.
Un piloto no es simplemente «activar la herramienta para menos personas». Debe poder responder una pregunta delimitada. En nuestro ejemplo: ¿puede un grupo de agentes de soporte preparar y revisar borradores internos con menos esfuerzo, sin perder calidad ni control sobre los datos? Esa pregunta determina a quién incluir, cuánto durará la prueba y qué habrá que medir antes de decidir.
El siguiente vídeo explica por qué el alcance, el punto de partida y las métricas deben fijarse antes de comenzar.
How to Setup a Successful Pilot Project
Mira «How to Setup a Successful Pilot Project», de Draegan Network, para situar el piloto como una prueba acotada antes de una iniciativa mayor.
Sigue la definición del piloto como iniciativa pequeña y temporal; después problema y alcance, donde se delimita qué debe averiguar la prueba. Termina con métricas y referencia: observa por qué medir el resultado exige conocer también la situación inicial.
Para este caso, el alcance propuesto será un solo uso —borradores internos para consultas de soporte—, 12 agentes de dos turnos y dos semanas de piloto. Mantener los dos turnos permite descubrir problemas de acceso o ayuda fuera del horario habitual, sin mezclar todavía funciones muy diferentes. La cifra y la duración son decisiones ilustrativas, no requisitos universales.
Haz visibles las dependencias antes de fijar las fechas
Una fecha aislada crea una expectativa; una dependencia explica qué tiene que estar listo para cumplirla. No tendría sentido anunciar el piloto para el lunes si el viernes aún no se han aprobado los permisos sobre datos, no hay responsable de revisar borradores o nadie puede atender incidencias en el segundo turno.
Para planificar, distingue entre:
- Actividad: trabajo que debe realizarse, como configurar accesos.
- Entregable: evidencia de que se realizó, como una lista de usuarios con permisos comprobados.
- Hito: momento previsto para revisar una entrega o tomar una decisión.
- Criterio de avance: condición comprobable para autorizar la fase siguiente.
La plantilla visual siguiente muestra una manera de reunir hitos, responsables, prioridades y fechas junto a un calendario tipo Gantt. Obsérvala como formato de seguimiento, no como un plan de IA listo para utilizar: una barra de duración o un porcentaje completado no demuestra que una salvaguarda funcione ni sustituye una aprobación.
En el caso de soporte, hay cuatro dependencias que merecen figurar por escrito desde el principio. Privacidad y seguridad deben aprobar qué consultas pueden procesarse, quién accede a ellas y cómo se conservan. El equipo técnico debe implementar y probar los controles que quedaron pendientes en la lección anterior. La persona responsable de soporte debe asegurar que cada borrador se revisa antes de responder al cliente. Y la coordinación de adopción debe contar con usuarios disponibles, orientación inicial y un canal de ayuda que funcione en ambos turnos. Si falta una de estas condiciones, se mueve la fecha del piloto: no se acorta silenciosamente la validación.
La planificación de software también necesita reservar tiempo para formar, evaluar y resolver incidencias, no únicamente para configurar la herramienta. El vídeo de TechnologyAdvice lo resume en unos pasajes breves:
How to Create a Software Implementation Plan
Mira estos fragmentos de «How to Create a Software Implementation Plan», de TechnologyAdvice, para conectar el calendario con la preparación de usuarios y el seguimiento posterior.
En el calendario, observa cómo descomponer fases en tareas con plazos y reservar tiempo para evaluación y resolución de problemas. En formación y ayuda, identifica dos trabajos que deben estar preparados antes del lanzamiento. Por último, el seguimiento sitúa la observación del uso y la recogida de comentarios después de activar la solución.
Un plan de ocho semanas para el asistente de soporte
La tabla propone un calendario relativo: «semana 1» significa la primera semana acordada con el cliente, no una fecha ya comprometida. Cada fila tiene una persona o función que responde de coordinar su entrega, aunque necesite colaboración de otras. Una aprobación de privacidad o una decisión de negocio corresponde a quien tenga autoridad para concederla; coordinarla no equivale a concedérsela.
| Fase y plazo previsto | Entrega principal | Dependencia para comenzar o terminar | Responsable de coordinar |
|---|---|---|---|
| 1. Preparación · semana 1 | Alcance del caso de uso, 12 participantes previstos, situación inicial y criterios de éxito acordados. | Patrocinio del cliente y disponibilidad de soporte para definir el proceso actual. | Gestor/a de adopción de IA. |
| 2. Acondicionamiento · semanas 2-3 | Controles de acceso y datos, revisión humana, tratamiento de fallos, canal de incidencias y repetición documentada de las pruebas. | Aprobaciones de privacidad y seguridad; trabajo del equipo técnico; revisión del proceso por soporte. | Responsable técnico/a de la solución. |
| 3. Piloto · semanas 4-5 | Uso limitado por los 12 agentes, registro de borradores revisados, tiempos e incidencias; reunión semanal de seguimiento. | Hito G1: autorización expresa del piloto tras comprobar las condiciones de entrada. | Responsable de soporte, con seguimiento del gestor/a de adopción. |
| 4. Decisión · final de semana 5 | Informe breve que compara los resultados con la situación inicial y recomienda ampliar, corregir y repetir, o detener. | Dos semanas de observación y evidencias suficientes para aplicar los criterios acordados. | Gestor/a de adopción; decide el patrocinador con las aprobaciones pertinentes. |
| 5. Ampliación gradual · semanas 6-7 | Primera incorporación de 15 agentes; revisión de incidencias antes de incorporar otros 15. | Hito G2: piloto aceptado. La segunda incorporación depende de que la primera mantenga los controles y el soporte previsto. | Responsable de soporte. |
| 6. Estabilización · semana 8 | Incidencias pendientes asignadas, materiales y procedimientos actualizados, seguimiento periódico y responsables de operación confirmados. | Resultados de la ampliación y capacidad para mantener revisión, ayuda y monitorización. | Responsable del servicio del cliente. |
La semana 1 requiere una situación inicial comparable. Por ejemplo, soporte puede medir el tiempo total de preparar y revisar respuestas para consultas de un tipo definido; medir solo el tiempo de generación del borrador favorecería artificialmente a la IA. Si se usan registros existentes, su acceso y tratamiento deben estar autorizados. Si aún no es posible, pueden emplearse casos simulados comparables para preparar el método, dejando claro que no prueban el ahorro en trabajo real.
Microsoft Learn describe el despliegue de una tecnología colaborativa mediante grupos de interés, perfiles de usuario, piloto, ayuda y medidas de uso. La tecnología del artículo no es nuestro asistente de IA: traslada su estructura de adopción, pero conserva las salvaguardas específicas de IA definidas para este caso.
Create a change management strategy - Microsoft Teams | Microsoft Learn
Lee esta guía de Microsoft Learn para comprobar qué trabajos de adopción deben tener sitio en el calendario, además de las tareas técnicas.
En «Identify key stakeholders, champions, and user profiles» y «User profiles», lee funciones y perfiles: presta atención a quién impulsa el uso y por qué conviene conocer la jornada de los usuarios. En «Design, launch, and manage your adoption campaign», empieza en «For your pilot phases these are the minimum steps for success» y lee mínimos del piloto, hasta la ampliación por grupos. Justo antes de «Measure & share success», revisa ejemplos de medidas. Distingue las señales de participación de la evidencia de que el trabajo mejora.
La guía ayuda a detectar una omisión frecuente: si las semanas 4 y 5 incluyen usuarios, también deben incluir explicación del alcance, instrucciones de uso, ayuda y recogida de comentarios. En esta fase basta con reservar esas entregas y sus responsables. En el siguiente módulo trabajarás su diseño con más detalle.
Los hitos son decisiones, no celebraciones del calendario
Un hito de avance debe permitir responder «sí», «todavía no» o «detener» con evidencias. Para nuestro plan, las condiciones pueden redactarse así:
G1 · Entrada al piloto, al final de la semana 3. Se autoriza únicamente si las pruebas acordadas en la lección anterior están documentadas y cumplen sus umbrales; no hay incumplimientos de las condiciones de bloqueo; los controles pendientes están implementados y comprobados; y privacidad, seguridad y soporte han aprobado lo que les corresponde. Deben existir accesos limitados, revisión humana efectiva, una vía de gestión manual y una forma de suspender el flujo. Si no hay autorización para tratar consultas reales, no se inicia un piloto con consultas reales. Puede continuarse con pruebas sintéticas, pero no presentarlas como evidencia de adopción en el trabajo cotidiano.
G2 · Decisión tras el piloto, al final de la semana 5. Antes de iniciarlo se habrá acordado qué muestra y qué medidas bastan. Como propuesta ilustrativa: durante la segunda semana, al menos 9 de los 12 agentes habrán creado y revisado al menos un borrador; en una muestra de 20 borradores revisados, al menos 18 serán aprovechables según la definición previa; y el tiempo total mediano de preparación y revisión en casos comparables será al menos un 20 % menor que la referencia inicial. No debe haber ningún incumplimiento grave de privacidad, promesas no autorizadas ni pérdida de revisión humana. Los números pueden renegociarse antes de empezar el piloto según el volumen real de consultas; cambiarlos después de ver resultados quitaría sentido a la decisión.
El informe de G2 debe incluir también lo que los números no explican: por qué alguien no utilizó la herramienta, cuánta corrección exigieron los borradores y si soporte pudo atender incidencias en ambos turnos. Uso no equivale a valor: muchos borradores generados pueden aumentar el trabajo si revisarlos cuesta demasiado. Si la muestra es insuficiente, la medida inicial no es comparable o aparece un problema grave, la salida razonable no es ampliar por inercia, sino corregir, prolongar la observación de forma justificada o detener.
Entre las dos incorporaciones de la fase 5 hay una tercera comprobación breve: G3 · continuidad de la ampliación. Antes de añadir el segundo grupo de 15, el responsable de soporte confirma que el primero puede usar la herramienta bajo las mismas reglas, que las incidencias graves están resueltas o contenidas y que hay capacidad de revisión y ayuda para más personas. Una incidencia crítica activa el procedimiento de suspensión acordado; no se compensa con una buena tasa de uso.
Así, el calendario sigue siendo útil cuando la realidad cambia. Si G1 se retrasa una semana, se desplazan el piloto y las decisiones posteriores. El plan conserva las dependencias y el tiempo necesario para observar resultados, en lugar de mantener una fecha de ampliación que ya no estaría justificada.
Cierre
Ya tienes los elementos de un plan de despliegue defendible: fases con entregas concretas, un piloto acotado, semanas previstas, responsables identificables, dependencias explícitas y decisiones de avance vinculadas a pruebas, uso, utilidad y seguridad. La regla central es sencilla: una fase termina cuando existe la evidencia necesaria para decidir, no solo cuando llega su fecha de cierre.
En la próxima lección comenzarás el módulo de gestión del cambio. Precisarás quién ejecuta, quién aprueba, a quién se consulta y a quién se informa en actividades como el lanzamiento, el soporte y el escalado de incidencias mediante una matriz RACI.