Recommended resources
The freely available resources this lesson will direct you to.
Hola. En la lección anterior trazaste un mapa de quién puede impulsar, decidir, influir y trabajar con el piloto de clasificación y resumen de consultas de acceso con revisión humana. Ese mapa indica a quién preguntar; ahora necesitas saber qué comprobar con cada persona antes de recomendar un despliegue.
Durante unos 40 minutos aprenderás a evaluar la preparación de un cliente en cinco dimensiones: personas, procesos, datos, tecnología y gobernanza. El resultado no será una nota abstracta de «madurez en IA», sino un diagnóstico útil para decidir qué puede probarse, qué falta verificar y qué debe resolverse antes de utilizar consultas reales.
La preparación depende del caso de uso
Una organización puede tener buenas herramientas digitales y, aun así, no estar preparada para este piloto. Tal vez los agentes puedan acceder a los tickets, pero nadie haya acordado cómo corregir un resumen que omite una excepción. O quizá exista una política general de privacidad, pero no esté claro si los datos de las consultas pueden enviarse al servicio de IA propuesto.
Por eso conviene formular la evaluación de manera concreta: «¿Está este cliente preparado para probar esta asistencia, con estos usuarios, estos datos y este proceso de revisión?» La respuesta puede ser distinta para un piloto limitado y para un despliegue general.
El siguiente esquema muestra seis áreas de preparación. Para esta lección, reúne ética dentro de las decisiones de gobernanza, sin restarle importancia; usa estrategia como contexto —el caso de uso que se quiere probar— y examina por separado las otras cinco dimensiones operativas.
La lectura siguiente ofrece una forma práctica de inspeccionar varias de esas dimensiones. Está orientada a empresas pequeñas y medianas, pero sus preguntas sobre fuentes, conexiones y reglas son aprovechables en clientes de otros tamaños.
AI readiness checklist: 5 steps for SMBs
Lee la lista de preparación de AWS para identificar qué evidencias pedir, no para escoger una tecnología concreta.
En «1. Evaluate your data environment», empieza donde se explica que los datos pueden estar repartidos entre sistemas y lee el inventario hasta la frase sobre la frecuencia de actualización. Fíjate en fuente, responsable y sistema de referencia. Después, en «3. Review technology stack and integration capabilities», lee las conexiones, desde la comprobación de las herramientas actuales hasta la capacidad de consultar los datos necesarios. Por último, en «4. Analyze governance, compliance, and ethical frameworks», lee las reglas, desde la necesidad de reglas escritas hasta el tratamiento de información sensible. Distingue en tu lectura «poder conectar» de «tener permiso para usar».
Personas y procesos: ¿cabe la asistencia en el trabajo real?
El mapa de grupos de interés te ayuda a empezar por personas, pero tener nombres en el mapa no demuestra preparación. Debes comprobar si hay tiempo, capacidades y disposición para participar. En nuestro piloto, la pregunta no es solo «¿saben usar una interfaz?», sino «¿pueden reconocer un resumen incompleto, corregirlo y comunicar el fallo sin que la tarea se vuelva inviable?».
Hablar únicamente con quienes se ofrecen voluntarios puede ocultar obstáculos de otros turnos o funciones. Contrasta el punto de vista del responsable del proceso con el de agentes que gestionan consultas habituales y excepcionales. Pregunta por su carga de trabajo, sus preocupaciones y el apoyo que necesitarían. Una inquietud razonable ante los errores de la IA es información para diseñar el piloto, no una etiqueta de «resistencia».
En procesos, parte del flujo que analizaste anteriormente: entrada de la consulta, clasificación, comprobación de antecedentes, preparación de respuesta y cierre. Localiza dónde aparecería la sugerencia de IA y observa qué ocurre después. Si un agente debe revisar el resumen antes de usarlo, ¿en qué momento lo hará?, ¿dónde verá la consulta original?, ¿cómo corregirá una categoría equivocada?, ¿qué consultas seguirán el recorrido habitual? La revisión humana solo es una salvaguarda creíble cuando tiene tiempo, información y una acción de corrección definida.
Esta guía institucional propone actividades concretas para examinar gestión, personas, procesos y tecnología. Su contexto es el sector público; no hace falta trasladar al cliente toda su estructura organizativa para aprovechar sus preguntas.
AI PLAYBOOK FOR THE U.S. FEDERAL GOVERNMENT
Lee las actividades de la fase de preparación del documento de ACT-IAC como una lista de comprobaciones posibles para un piloto, no como un organigrama obligatorio.
En «Key Activities» (pp. 29–30 del PDF), recorre las subsecciones «Management», «People», «Process» y «Technology». Empieza en la viñeta actividades clave, sobre autoridad de supervisión, y termina en la necesidad de identificar interfaces e integraciones, justo antes de «Acquisition». Presta especial atención a las preocupaciones y capacidades de los usuarios, al proceso actual y a quién supervisaría la solución.
Las dos dimensiones se condicionan mutuamente. Una formación bien diseñada no resolverá un proceso que exige revisar cien sugerencias sin reservar tiempo para ello. A la inversa, un flujo cuidadosamente dibujado fallará si los agentes no saben cuándo desconfiar de una clasificación o a quién comunicar un problema.
Datos y tecnología: disponible no significa utilizable
Para evaluar datos, empieza por identificar qué necesitaría leer la asistencia y de dónde saldría. En el caso propuesto podrían ser el texto de la consulta, categorías anteriores y documentación de ayuda. Para cada fuente comprueba: quién responde por ella, qué versión es la válida, si su contenido está suficientemente completo y actualizado, si representa tanto casos corrientes como excepciones y si está autorizado su uso en el piloto.
Esta última comprobación es distinta de las demás. Poder exportar tickets no autoriza a copiarlos en una herramienta de IA. Del mismo modo, tener muchos tickets no garantiza que sus categorías sean fiables: si los agentes han clasificado de maneras diferentes la misma incidencia, esa inconsistencia afectará a la evaluación del piloto.
El vídeo siguiente aclara una parte útil de este trabajo: descubrir las fuentes, clasificar su contenido y establecer reglas sobre su tratamiento. Habla específicamente de gobernanza de datos, que es una parte —no la totalidad— de la gobernanza del piloto.
Data Governance Explained in 5 Minutes
En «Data Governance Explained in 5 Minutes», de IBM Technology, observa cómo pasar de «tenemos datos» a «sabemos cuáles son y cómo podemos tratarlos».
Mira descubrir y clasificar: la analogía doméstica introduce la localización de fuentes y la clasificación de información. Continúa con políticas y reglas, especialmente el ejemplo de ocultar datos identificativos. Finalmente, en los metadatos, observa por qué conocer el origen y la definición de un dato facilita encontrarlo y usarlo correctamente.
La dimensión de tecnología responde a otra pregunta: ¿puede la solución funcionar de forma controlada dentro del entorno de trabajo? Pide al equipo técnico que confirme si existe una vía autorizada para obtener las consultas necesarias, dónde aparecería la sugerencia para el agente, cómo se controlaría el acceso y quién atendería los fallos. No necesitas diseñar aún la arquitectura: necesitas identificar dependencias y comprobar si alguien puede validarlas.
Piensa en una diferencia práctica. «El sistema de tickets permite integraciones» es una pista, no una prueba de preparación. Faltaría saber si esta integración puede recibir estos datos, con los permisos adecuados, y si el agente podrá consultar el original al revisar la sugerencia. Si no se conoce la respuesta, regístrala como pendiente de verificación, no como «sí» ni como «no».
Gobernanza: quién decide y qué límites rigen el piloto
Gobernanza une decisiones que ninguna herramienta resuelve por sí sola. Debe quedar claro quién autoriza el alcance y los datos, quién responde por el resultado del proceso, quién aprueba las condiciones de uso y quién puede pausar el piloto ante un problema. El mapa de grupos de interés ofrece candidatos, pero en esta fase hay que confirmar su autoridad efectiva.
Para el caso de consultas de acceso, las reglas mínimas deberían precisar qué información puede utilizarse, qué debe revisar una persona antes de actuar, cómo se notifican las sugerencias erróneas y quién decide si una incidencia exige detener la prueba. También hay que comprobar con las funciones competentes los requisitos aplicables de privacidad, seguridad y conservación de información. No presupongas que una autorización general para usar IA cubre cualquier tipo de consulta.
Hay una relación importante entre gobernanza y adopción. Si se comunica a los agentes que «siempre habrá revisión humana», pero nadie define qué revisar ni les permite corregir la salida, la promesa no generará confianza. Una regla útil debe poder aplicarse en el flujo de trabajo y tener una persona responsable de mantenerla.
Convertir las cinco dimensiones en un diagnóstico
Tu entrega como gestor o gestora de adopción puede ser una ficha breve por dimensión. Para evitar conclusiones optimistas basadas en impresiones, separa evidencia, estado y siguiente paso. Una escala sencilla basta:
- Verificado: hay evidencia suficiente para el alcance propuesto.
- Condicionado: se ha identificado una carencia y una vía concreta para resolverla.
- No verificado: aún falta información; no equivale a que la capacidad exista.
- Bloqueado: hay un impedimento conocido que exige cambiar o detener el alcance.
Supongamos estas observaciones hipotéticas para el piloto de consultas; no describen a un cliente real:
| Dimensión | Evidencia disponible y estado | Qué harías a continuación |
|---|---|---|
| Personas | La supervisión ofrece tiempo a algunos agentes, pero aún no se ha contrastado con otros turnos. Condicionado. | Acordar una muestra de participantes y confirmar tiempo de revisión y apoyo. |
| Procesos | Se conoce el recorrido habitual; no está definido cómo corregir una clasificación ni cómo tratar excepciones. Condicionado. | Documentar ambos recorridos con agentes y responsable del proceso. |
| Datos | Se ha localizado el sistema de tickets; se desconocen la calidad de las categorías y la autorización de uso. No verificado. | Revisar una muestra permitida y confirmar condiciones con las funciones responsables. |
| Tecnología | Se sabe que el sistema admite integraciones, pero esta conexión y sus permisos no se han probado. No verificado. | Solicitar una validación técnica limitada, inicialmente sin consultas reales. |
| Gobernanza | Existe patrocinio, pero no consta quién aprueba los datos ni quién puede detener la prueba. Condicionado. | Confirmar autoridad, reglas de revisión y procedimiento de incidencias. |
La tabla no invita a calcular una media. Cuatro dimensiones «verificadas» no compensan un uso de datos no autorizado. En el ejemplo, la recomendación razonable sería continuar el diseño y las comprobaciones sin incorporar consultas reales al servicio de IA hasta confirmar su uso permitido y las condiciones de control. Si resulta útil validar la interacción entretanto, se podrían emplear ejemplos ficticios adecuados para esa prueba.
Un buen diagnóstico termina con una decisión proporcionada al alcance: avanzar, avanzar bajo condiciones explícitas, reducir el piloto o aplazarlo. Debe indicar qué evidencia cambiaría la decisión y quién puede obtenerla. Así la evaluación deja de ser una lista de deseos y se convierte en una conversación de trabajo con el cliente.
Para cerrar
Evaluar la preparación de un cliente significa comprobar si las personas pueden participar, el proceso admite una revisión real, los datos son aptos y utilizables, la tecnología puede sostener el flujo y la gobernanza fija decisiones y límites claros. Registra tanto lo comprobado como lo desconocido: una incógnita importante no es un detalle administrativo.
En la próxima lección usarás este diagnóstico para formular una hipótesis de valor y criterios de éxito medibles. Saber qué puede probarse de forma responsable es el paso previo para decidir qué resultado merece medirse.