Skip to main content

Someone wanted to learn this too, so Grasp built them a personal learning path.

You can keep exploring this one or create your own

Prácticas formativas por rol para el uso seguro y supervisado de la IA

Hola. En la lección anterior diseñaste una secuencia para explicar a cada grupo qué cambiará con el piloto de IA, cuándo podrá participar y dónde pedir ayuda. Una comunicación clara prepara el terreno, pero no demuestra que alguien sepa utilizar la herramienta sin introducir datos indebidos, aceptar un error convincente o enviar un borrador sin revisar.

Ahora convertirás ese mensaje en prácticas formativas por rol. Trabajaremos con el mismo piloto: un asistente que propone borradores de respuesta a consultas habituales, pero no los envía. El objetivo es diseñar formación que permita a cada persona hacer tres cosas observables: usar el asistente para una tarea autorizada, verificar lo que produce y supervisar su uso con capacidad real de corregir o detener un problema.


Formar para una tarea, no para «saber de IA»

Una demostración genérica puede enseñar dónde está el botón de generar, pero no responde a las preguntas decisivas del trabajo diario: «¿Para qué consultas sirve?», «¿Con qué información puedo trabajar?» y «¿Qué hago si el borrador inventa una promesa?». Esas respuestas dependen de la tarea y de la responsabilidad de quien utiliza la herramienta.

En The People Factor, la guía publicada en GOV.UK distingue entre dar acceso a una herramienta y conseguir un uso seguro y de calidad. Lee sus recomendaciones pensando en cómo transformar un riesgo concreto en algo que una persona pueda practicar, no solo recordar.

The People Factor: A human-centred approach to scaling AI tools (HTML) - GOV.UK

Lee esta guía de GOV.UK para identificar qué capacidades deben enseñarse después de habilitar el acceso y qué condiciones hacen efectiva la revisión humana.

En «Phase 3: Optimise», lee el apartado «Aim» y la lista «Types of actions which may be required by users»: comienza en uso seguro. Después, en «Step 3. Develop an effective training, support and feedback offer», lee desde la frase que empieza «This step aims to provide users with the skills» hasta el final del ejemplo sobre seminarios breves, en formación y apoyo. Fíjate especialmente en los tres requisitos que enumera para que una persona pueda revisar resultados de IA con eficacia.

La idea central es sencilla, aunque exigente: «revisión humana» no es una salvaguarda suficiente por sí sola. Quien revisa necesita conocimientos para detectar fallos, tiempo para hacerlo y autoridad para cuestionar el resultado o el modo en que se usa la herramienta. Si durante un turno no hay tiempo para comprobar un borrador, añadir «revisar siempre» a una diapositiva no arregla el diseño del trabajo.

Por eso, antes de crear un tutorial, concreta cuatro elementos para cada rol:

  1. Tarea permitida: qué puede hacer con el asistente y qué queda fuera del piloto.
  2. Entrada permitida: qué información puede introducir, según las reglas aprobadas para esa herramienta y ese entorno.
  3. Comprobación exigida: contra qué fuente o criterio debe contrastar el resultado.
  4. Decisión y escalado: qué puede aprobar, corregir, descartar o comunicar, y a quién.

Esta definición procede del caso de uso y de las reglas validadas en el despliegue. La formación enseña a aplicarlas; no debe inventar una política de datos ni ampliar por su cuenta el alcance del piloto.


La práctica base: usar, verificar y decidir

Imagina una consulta ficticia sobre un pedido retrasado. Para la práctica dispones de una instrucción de servicio también ficticia: «Las incidencias de retraso requieren revisión por la persona responsable; la guía no garantiza compensaciones». No hay datos de un cliente real.

La primera parte de la práctica consiste en usar el asistente para la tarea autorizada: solicitar un borrador general basado en esa instrucción. El ejemplo permite enseñar a delimitar la petición: indicar la finalidad, aportar únicamente el contexto permitido y pedir que no se añadan hechos o promesas que no figuren en la fuente. Si no se sabe si una información está autorizada para introducirse, no se utiliza mientras se obtiene una respuesta del responsable competente.

Supongamos que el borrador generado dice:

«Le garantizamos una compensación y resolveremos su caso hoy».

Suena atento, pero falla en dos puntos comprobables: promete una compensación que la guía no garantiza y fija un plazo que la guía no establece. La segunda parte de la práctica es verificar: localizar ambas afirmaciones, compararlas con la instrucción vigente y corregir o descartar el texto. No basta con preguntar al propio asistente si su respuesta es correcta; hace falta contrastarla con una fuente o con una persona autorizada.

La tercera parte es decidir. En este piloto, la persona que atiende la consulta no debe enviar el borrador tal como está. Puede preparar una versión ajustada a la guía y seguir el proceso de revisión correspondiente; si la consulta exige decidir sobre una compensación, debe derivarla. También debe saber comunicar un fallo recurrente por el canal de incidencias sin copiar datos de clientes en un espacio no autorizado.

Este caso condensa una secuencia formativa reutilizable: una demostración breve, una práctica con información ficticia, un resultado deliberadamente imperfecto y una decisión justificada. La evidencia de aprendizaje no es «ha visto el vídeo», sino «ha identificado el error, ha consultado la fuente y ha elegido una acción permitida».


Cambiar la práctica cuando cambia el rol

Las tres capacidades —usar, verificar y supervisar— son comunes, pero no se enseñan con idéntico escenario ni se evalúan con la misma decisión. Tu experiencia diseñando materiales didácticos resulta útil aquí: la unidad formativa no es una lista de funciones de la herramienta, sino una situación de trabajo con una actuación observable.

Personal que atiende consultas durante un turno

Necesita una práctica breve, realizable en el tiempo y el dispositivo disponibles. Puede trabajar con una consulta ficticia similar a las que recibe, una guía vigente fácil de localizar y dos borradores: uno aceptable tras revisión y otro con una promesa inventada.

La actuación esperada es que seleccione una tarea incluida en el piloto, use solo la información permitida, compruebe el borrador antes de enviarlo y sepa no enviarlo cuando falte tiempo o información para revisarlo. La guía de apoyo podría caber en una pantalla: tarea admitida, fuente de contraste, señales de alerta y canal de ayuda. No sustituye a la práctica, pero permite repetirla durante el trabajo.

Personal de oficina que prepara respuestas o materiales

Puede disponer de más tiempo para trabajar con documentos, pero también encontrarse con textos más largos y afirmaciones difíciles de detectar a simple vista. Su práctica puede consistir en transformar una guía autorizada en un borrador y marcar, frase por frase, qué afirmaciones están respaldadas, cuáles requieren confirmación y cuáles deben eliminarse.

Aquí conviene incluir un ejemplo de sesgo o suposición injustificada: un borrador que atribuye una intención o una necesidad a una persona sin que la consulta lo indique. La verificación no se limita a cifras y fechas; también comprueba tono, trato equitativo y adecuación al destinatario.

Mandos y responsables del piloto

No necesitan aprender solamente a generar mejores borradores. Su práctica debe situarlos ante un conjunto de respuestas revisadas: varias contienen el mismo error y el equipo comunica que no dispone de tiempo suficiente para comprobarlas. Su decisión ya no es corregir una frase, sino determinar si el uso puede continuar en las condiciones previstas, qué apoyo hace falta y qué incidencia debe escalarse.

La evidencia esperada es que sepan distinguir un error aislado de una señal repetida, reservar tiempo real para la revisión y respaldar a quien detiene un envío inseguro. No deben premiar únicamente la rapidez o el volumen de uso si eso empuja al equipo a omitir comprobaciones.

La forma de impartir estas prácticas también cambia. Una demostración corta y una tarjeta consultable pueden encajar en un turno; un taller con documentos puede funcionar para personal de oficina; una revisión de casos y decisiones suele ser más pertinente para mandos. Lo constante es el criterio de éxito: cada participante debe mostrar qué haría ante un resultado dudoso.


Enseñar límites de datos, sesgos y fiabilidad sin quedarse en advertencias

Una formación sobre seguridad puede fracasar de dos maneras: ignorar los riesgos o enumerarlos sin explicar qué hacer. El vídeo Use AI Responsibly, de Grow with Google, ofrece ejemplos de resultados sesgados y de exposición de información personal. Úsalo como punto de partida para redactar instrucciones aplicables al piloto, no como sustituto de las reglas aprobadas por la organización.

Use AI Responsibly | Google AI Essentials

Mira «Use AI Responsibly», de Grow with Google, para reconocer dos riesgos que deben aparecer en las prácticas: las suposiciones sesgadas en los resultados y la divulgación indebida de información al escribir una petición.

En sesgos y resultados, observa el ejemplo de imágenes de directivos y piensa cómo trasladar la comprobación de estereotipos a un borrador de respuesta. Después, en privacidad y seguridad, fíjate en el riesgo de incluir detalles personales o confidenciales para obtener una respuesta más personalizada. Para nuestro piloto, la regla práctica es trabajar en formación con casos ficticios y utilizar datos reales solo en el entorno, con el alcance y bajo las condiciones expresamente autorizadas.

En una práctica bien diseñada, cada advertencia se convierte en una acción:

  • Frente a una afirmación inventada, la persona señala la frase, busca respaldo en la fuente vigente y no la conserva si no lo encuentra.
  • Frente a una suposición sesgada, comprueba si hay evidencia para atribuir una característica o intención; si no la hay, reformula sin esa atribución y comunica patrones repetidos.
  • Frente a datos no autorizados, detiene la entrada antes de enviarla al asistente y consulta el procedimiento aplicable. Si ya se han introducido por error, utiliza el canal de incidencias definido, sin redistribuirlos al pedir ayuda.
  • Frente a una tarea fuera de alcance, no intenta «mejorar el prompt» para forzarla. Usa el proceso habitual o solicita que se evalúe ese nuevo uso por los responsables del piloto.

La imagen siguiente reúne principios de IA responsable y distingue los principios de los medios necesarios para llevarlos a la práctica. Es útil como recordatorio de por qué una buena sesión formativa no reemplaza reglas, procesos y gobernanza.

Seis principios de IA responsable —privacidad y seguridad, fiabilidad y seguridad, equidad, transparencia, responsabilidad e inclusión— junto con cuatro bloques para aplicarlos: gobernanza, reglas, formación y prácticas, y herramientas y procesos.

Por ejemplo, enseñar a no introducir información no autorizada es una práctica formativa; definir qué información está autorizada es una decisión de gobernanza que debe existir antes. Del mismo modo, pedir que alguien detecte errores exige ofrecerle una fuente de contraste y un modo de detener o escalar el trabajo.


Supervisar no siempre significa lo mismo

En nuestro asistente de borradores, hay una decisión humana antes de cada envío. Esa pausa es una característica importante del piloto. Otras soluciones pueden ejecutar acciones mientras una persona observa y tiene capacidad de detenerlas; no conviene confundir ambas formas de supervisión.

El vídeo de IBM Technology sitúa estas posibilidades en un continuo y muestra mecanismos operativos, como las puertas de aprobación y las colas de incidencias. No necesitas adoptar toda su terminología para diseñar la formación; sí necesitas precisar en qué momento interviene la persona y qué puede hacer.

What is Human In The Loop with AI? How HITL Shapes AI Systems

Mira «What is Human In The Loop with AI? How HITL Shapes AI Systems», de IBM Technology, para distinguir la aprobación humana previa de la vigilancia de un sistema que ya está actuando.

En niveles de supervisión, atiende a la diferencia entre detener el proceso para pedir aprobación y permitir que funcione con posibilidad de intervención. Luego, en controles operativos, observa los ejemplos de puertas de aprobación y colas para casos que requieren atención humana. Relaciónalos con el piloto: el borrador espera revisión antes de enviarse y los fallos repetidos deben llegar a quien pueda actuar sobre el sistema.

Esto permite repartir dos responsabilidades que suelen mezclarse:

La persona usuaria revisa cada resultado que va a utilizar. Comprueba hechos, límites de la tarea, datos y adecuación de la respuesta. Debe poder corregir, descartar y derivar el caso.

Quien supervisa el piloto observa si el proceso completo sigue siendo seguro y útil. Revisa incidencias y patrones de calidad, escucha a los equipos y decide con los responsables correspondientes si hacen falta cambios, apoyo adicional o una pausa. Para ello necesita señales comprensibles, no solo un recuento de cuántas veces se abrió el asistente.

La formación debe preparar ambos niveles. Si la persona usuaria detecta reiteradamente compensaciones inventadas pero nadie recoge esa señal, la supervisión falla. Si el mando recibe estadísticas de uso pero no sabe que el equipo está enviando respuestas sin tiempo para revisarlas, también falla. El circuito debe permitir detectar, comunicar, decidir y confirmar qué se ha hecho, con las responsabilidades de soporte y escalado ya definidas en el piloto.


Una ficha de práctica que puedas incorporar al playbook

Para que el diseño sea reutilizable entre clientes sin convertirlo en una formación genérica, conserva la estructura de la práctica y adapta su contenido a cada solución. Una ficha breve puede recoger:

Campo Qué debe quedar especificado
Rol y situación Quién practica, en qué tarea realista y con qué limitaciones de tiempo, acceso o dispositivo.
Alcance y materiales Uso permitido; reglas vigentes; caso y datos ficticios; fuente fiable para comprobar la salida.
Acciones observables Qué hará para usar el asistente, verificar el resultado y aprobarlo, descartarlo o escalarlo.
Fallo introducido Error, dato indebido, suposición injustificada o tarea fuera de alcance que debe reconocer.
Criterio de logro y apoyo Qué conducta demostrará; dónde encontrará ayuda y qué ocurrirá si todavía no puede realizarla con seguridad.

Para el personal que atiende consultas, por ejemplo, el criterio no sería «ha completado 15 minutos de formación». Sería: «ante un borrador que garantiza una compensación no prevista, identifica la promesa, la contrasta con la guía y evita enviarla». Para un mando, sería: «ante errores repetidos y falta de tiempo de revisión, identifica el riesgo y activa la decisión y el escalado previstos».

Puedes combinar una demostración, práctica guiada y una guía de consulta posterior. Si alguien no alcanza el criterio, ofrece una explicación o práctica más ajustada y vuelve a observar la conducta; asistir no equivale a estar preparado para el uso autónomo. También hay que comprobar que el entorno permite aplicar lo aprendido: acceso correcto, fuente disponible, tiempo de revisión y canal de ayuda operativo.


La formación por rol funciona cuando enseña decisiones dentro de un flujo de trabajo, no solo características de una herramienta. En el piloto, todas las personas deben conocer el uso autorizado, verificar los borradores contra una fuente fiable y saber cuándo no utilizarlos. La supervisión añade otra pregunta: ¿tienen las personas conocimientos, tiempo y autoridad para intervenir, y llega lo que detectan a quien puede resolverlo?

En la próxima lección prepararás la sesión de lanzamiento. Podrás utilizar estas prácticas para construir una demostración y una actividad guiada que presenten expectativas realistas, comprueben la preparación de los participantes y hagan visibles los canales de ayuda desde el primer día.

Can't find a good explanation? Sign up and we'll make it for you

Sign up