Anexo A: controles de referencia para tu SGIA
Una explicación paso a paso de las 38 referencias del Anexo A: qué significan, para qué sirven y cómo empezar a trabajarlas en tu organización.
Objetivo: que puedas comprender una medida, relacionarla con una necesidad y preparar una decisión que otra persona pueda revisar.
Antes de empezar: qué es un control
Piensa en una puerta que da a una escalera. Si existe la posibilidad de que un niño salga y se caiga, puedes cerrar la puerta, instalar un cierre adecuado o acompañarle. Cada medida actúa sobre una situación que quieres gestionar. En un SGIA, los controles cumplen una función parecida: ayudan a gestionar riesgos y a trabajar de acuerdo con las necesidades y compromisos de la organización.
Un control puede ser técnico, pero también una responsabilidad clara, una revisión humana, información útil o una regla de trabajo. La pregunta es qué necesidad atiende y si puede cumplir esa función en el contexto concreto. Escribir una regla es un primer paso; comprobar que se puede aplicar y que funciona requiere información adicional.
Qué encontrarás en esta guía
El Anexo A proporciona 38 controles de referencia agrupados en nueve ámbitos. Aquí explicamos cada referencia con lenguaje corriente y ejemplos propios. Los títulos están abreviados para facilitar el estudio; la explicación didáctica no sustituye la lectura del texto autorizado de la norma para contrastar requisitos y su guía de implementación.
No necesitas estudiar todo de una vez. Puedes leer un grupo, consultar una referencia concreta o recorrer el conjunto para preparar tu declaración de aplicabilidad. El tiempo orientativo de lectura y práctica es de 3–5 horas para la Guía del Anexo A y de 5–8 horas para la Guía del Anexo B, según la profundidad de tus respuestas. Son estimaciones de estudio, sin implantación real ni audios.
El caso del curso es Tech Server IIT Spain, una empresa ficticia. Los ejemplos de esta guía son propuestas: no describen controles implantados ni resultados ya observados. USO-004 identifica el clasificador de tickets; USO-003, el chatbot de soporte. R-001 e IMP-001 permiten relacionar el escenario de riesgo del clasificador con su impacto potencial, sin repetir toda su historia en cada ficha.
En soporte, un ticket es el registro de una solicitud de ayuda o de un problema. El clasificador es la herramienta que propone cómo ordenar esos casos; su criticidad expresa la importancia de atenderlos según sus consecuencias y el contexto. En el ejemplo, proponer una prioridad y aplicarla son actuaciones distintas.
Cómo decidir: delimita el uso y la actividad, identifica la necesidad, contrasta la referencia y justifica inclusión, exclusión fundada o pendiente. Después describe el estado real de la medida y la información que respalda ese estado.
Una medida puede ser necesaria y todavía no estar implantada. Una actividad del proveedor puede generar responsabilidades que debas gestionar. Si falta información para decidir, mantén el pendiente y concreta cómo obtenerla.
Dónde se trabaja cada grupo en el curso
Este mapa te indica dónde trabajar cada grupo de controles. Un grupo puede apoyarse en varios módulos: uno explica la idea y otro ayuda a aplicarla. Las referencias a módulos previstos apuntan a su descripción en el temario; su contenido todavía no está publicado.
| Grupo de controles | Módulo de referencia | Qué trabajar y dónde ampliar |
|---|---|---|
| A.2 · Políticas relacionadas con la IA | Módulo 3 · Política, liderazgo y gobierno | Define los compromisos y revisa su coherencia. La revisión por la dirección se ampliará en el módulo 12 (previsto). |
| A.3 · Organización interna | Módulo 3 · Política, liderazgo y gobierno Módulo 8 · Supervisión humana y transparencia | El módulo 3 organiza funciones y comunicación; el 8 concreta quién puede revisar, intervenir y escalar un caso. |
| A.4 · Recursos para los sistemas de IA | Módulo 4 · Inventario de sistemas y usos de IA | Empieza por el inventario y sus dependencias. Completa las personas y competencias con el módulo 3, y los datos con el 7. |
| A.5 · Evaluación de impactos | Módulo 5 · Riesgos e impactos Módulo 6 · Tratamiento de riesgos y selección de controles | El módulo 5 identifica afectados y efectos potenciales; el 6 utiliza esa información para proponer medidas y comprobarlas. |
| A.6 · Ciclo de vida del sistema de IA | Módulo 9 · Proveedores y ciclo de vida | El módulo 9 trabaja los puntos de decisión, la adquisición, los cambios y la retirada. Conecta con el inventario del 4, las comprobaciones de controles del 6 y los límites de actuación del 8. El seguimiento se ampliará en el módulo 10 (previsto). |
| A.7 · Datos para los sistemas de IA | Módulo 7 · Datos, privacidad y seguridad | Trabaja fuentes, condiciones de uso, calidad, protección, versiones y trazabilidad con la ficha FD-001. El módulo 4 ayuda a relacionar los datos con cada uso. |
| A.8 · Información para las partes interesadas | Módulo 8 · Supervisión humana y transparencia | Prepara información útil para el usuario y vías de revisión y desacuerdo. El módulo 2 identifica las partes interesadas; la comunicación de incidentes se ampliará en el 10 (previsto). |
| A.9 · Uso de los sistemas de IA | Módulo 8 · Supervisión humana y transparencia | Delimita lo permitido y cómo intervenir con SUP-001. Relaciona la finalidad del uso con el módulo 4 y los objetivos con el 3. |
| A.10 · Relaciones con terceros y clientes | Módulo 9 · Proveedores y ciclo de vida | El módulo 9 trabaja evaluación, acuerdos y seguimiento de proveedores con PROV-001. Conecta con el contexto y las partes interesadas del módulo 2 y con las dependencias registradas en el 4. |
La relación es una orientación de estudio. Cada explicación de esta guía desarrolla el control; el módulo enlazado aporta el contexto o la práctica señalados. La decisión sobre su aplicabilidad depende del alcance y de la necesidad concreta.
El módulo 6 es el punto de unión para los nueve grupos: en la lección 6.2 seleccionas medidas y en la 6.3 justificas su aplicabilidad con la plantilla Excel. Después puedes volver al módulo del tema para concretar la medida.
Más adelante, los módulos 11, 12 y 13, todavía previstos, ayudarán a auditar el conjunto, revisar decisiones de dirección e integrar el expediente del caso. Su función es comprobar y mejorar el SGIA completo.
Políticas relacionadas con la IA · A.2
Son los compromisos que orientan las decisiones. Su función es ayudar a actuar de manera coherente, también cuando una situación resulta incómoda.
A.2.2 · Política de IA
Una política es una declaración de los compromisos que guían las decisiones. Cuando hablamos de IA, explica para qué quiere utilizarla la organización, qué responsabilidades asume y qué principios deben respetarse. Tiene que servir cuando aparece una duda: ¿podemos poner en marcha esta herramienta?, ¿qué prioridad damos a la protección de las personas?, ¿quién debe revisar una decisión delicada?
Una política útil orienta el trabajo y permite preparar reglas más concretas. Por ejemplo, un compromiso de atención responsable puede convertirse en una regla que impida aplicar determinadas recomendaciones sin revisión. La organización necesita comunicar la política y mantenerla alineada con lo que hace. Un texto solemne que el equipo desconoce aporta poco a las decisiones diarias.
Un ejemplo cotidiano
En una comunidad de vecinos se acuerda que las zonas comunes deben poder utilizarlas todos. Ese compromiso guía después decisiones sobre obras, horarios y accesos. La política de IA cumple una función parecida: establece compromisos para tomar decisiones coherentes.
En Tech Server IIT Spain
Tech Server IIT Spain podría comprometerse a mejorar el triaje de tickets conservando una atención adecuada a quienes necesitan ayuda urgente. Habría que concretar cómo ese compromiso afecta a la revisión de prioridades y a los recursos del servicio.
Cómo empezar a aplicarlo
- Describe los usos de IA y los compromisos que deben orientar sus decisiones.
- Revisa el contenido con las funciones que lo aplicarán y con quien tiene autoridad para aprobarlo.
- Comunícalo con ejemplos de trabajo y establece cuándo se revisará.
Cómo comprobarlo
Conserva la versión aprobada y cómo se comunicó. Después plantea una decisión realista al equipo: la comprobación útil es observar si puede aplicar los compromisos, no solo localizar el archivo.
Un error habitual: Copiar una política genérica que promete responsabilidad pero no ayuda a decidir en el servicio concreto.
Ahora prueba tú
Si reducir el tiempo de triaje empeorase la atención a tickets urgentes, ¿qué compromiso de la política ayudaría a decidir?
Ver orientación después de responder
La respuesta debe identificar un compromiso concreto y su consecuencia operativa. Decir «ser responsables» sin explicar qué se revisa o cambia todavía resulta insuficiente.
En el curso: Módulo 3 · Política, liderazgo y gobiernoCompromisos de la política y decisiones coherentes con ellos.
Volver al índice de la guíaA.2.3 · Coherencia entre políticas
Una organización suele tener varias políticas: seguridad, protección de datos, calidad, recursos humanos o atención al cliente. La política de IA debe coordinarse con ellas para que una misma actividad no reciba instrucciones incompatibles. Si una regla permite enviar toda la información a una herramienta y otra restringe compartirla, el equipo necesita una decisión clara sobre esa contradicción.
La coherencia también requiere vocabulario, funciones y decisiones compatibles. No significa juntar todos los documentos en uno. Significa revisar las relaciones y resolver diferencias antes de que las personas tengan que improvisar. La IA suele atravesar varios procesos y hace especialmente visible esta necesidad de coordinación.
Un ejemplo cotidiano
Una familia no puede acordar a la vez «la puerta debe quedar cerrada» y «dejadla abierta para que entre el repartidor» sin explicar cómo resolver cada situación. Hace falta coordinar ambas instrucciones.
En Tech Server IIT Spain
Si se propone utilizar tickets para mejorar un clasificador externo, habría que contrastar la finalidad con las reglas de datos, los compromisos con el cliente y las condiciones del proveedor. Autorizar la herramienta no resuelve por sí solo el envío de información.
Cómo empezar a aplicarlo
- Identifica las políticas y compromisos que afectan al uso concreto.
- Compara instrucciones sobre datos, decisiones, acceso, atención y responsabilidades.
- Resuelve contradicciones con las funciones responsables y comunica la regla resultante.
Cómo comprobarlo
Un registro de la revisión puede mostrar qué conflicto se detectó y cómo se resolvió. Comprueba después que el equipo recibe una instrucción compatible y sabe aplicarla al caso.
Un error habitual: Dar por hecho que una política de IA permite saltarse condiciones ya establecidas por seguridad o por el servicio.
Ahora prueba tú
¿Qué revisarías antes de enviar tickets a una herramienta externa?
Ver orientación después de responder
Relaciona finalidad, contenido de los tickets, condiciones de acceso y compromisos pertinentes. La revisión debe producir una decisión explicable, manteniendo pendientes las condiciones desconocidas.
En el curso: Módulo 3 · Política, liderazgo y gobierno · Módulo 2 · Alcance y contexto del SGIACoherencia de los compromisos con el contexto y las necesidades.
Volver al índice de la guíaA.2.4 · Revisión de la política de IA
Las condiciones cambian. Una herramienta que antes solo redactaba borradores puede empezar a ejecutar acciones; pueden aparecer nuevos clientes, riesgos o requisitos. La política necesita revisarse para seguir orientando esas situaciones. Revisar significa comprobar su adecuación y decidir si requiere cambios, no cambiar una fecha en la portada.
Conviene acordar revisiones periódicas y también señales que las adelanten. Una incidencia relevante, una modificación del alcance o una nueva forma de uso pueden hacer necesario reconsiderar los compromisos. La revisión debe dejar visible quién participó, qué información se consideró y qué se decidió.
Un ejemplo cotidiano
Las normas de casa se revisan cuando un niño empieza a volver solo del colegio. El cambio de autonomía obliga a reconsiderar horarios, avisos y ayuda disponible, aunque antes todo funcionase.
En Tech Server IIT Spain
Si el clasificador pasa de una prueba a aplicar prioridades automáticamente, Tech Server IIT Spain tendría que revisar si los compromisos y reglas actuales siguen siendo adecuados. La decisión no se resuelve simplemente conservando la política anterior.
Cómo empezar a aplicarlo
- Establece quién revisará la política y con qué información.
- Identifica cambios y señales que obliguen a adelantar la revisión.
- Documenta la decisión, actualiza lo necesario y comunica las consecuencias.
Cómo comprobarlo
Conserva la revisión y sus razones. Una prueba práctica consiste en plantear un cambio de autonomía y comprobar si activa la revisión prevista, con una función capaz de asumirla.
Un error habitual: Revisar solo en una fecha fija aunque el uso de IA haya cambiado de manera importante.
Ahora prueba tú
¿Qué cambio del clasificador justificaría revisar la política antes de la fecha prevista?
Ver orientación después de responder
Un cambio que modifique efectos, responsabilidades o condiciones de uso puede justificarlo. Explica la relación; no todos los cambios de nombre o presentación tienen la misma relevancia.
En el curso: Módulo 3 · Política, liderazgo y gobierno · Módulo 12 · Revisión por la dirección y mejora (previsto)Revisión de compromisos y decisiones de mejora.
Volver al índice de la guíaOrganización interna · A.3
Necesitamos funciones claras y una vía para avisar de problemas. El reparto tiene que funcionar durante el servicio, incluso cuando falta la persona habitual.
A.3.2 · Funciones y responsabilidades
Cuando varias personas participan en un trabajo, tiene que quedar claro quién hace cada cosa y quién puede decidir. Si todos creen que otro revisará una respuesta de IA, puede acabar utilizándose sin que nadie la haya comprobado. Necesitamos distinguir quién utiliza el sistema, quién revisa resultados, quién modifica su configuración y quién autoriza decisiones relevantes.
Asignar una función exige dar capacidad para ejercerla. La persona necesita información, competencia, tiempo y autoridad. También hay que pensar en ausencias y turnos. Puede haber varias funciones en una misma persona, pero conviene distinguir sus decisiones y evitar que el reparto quede en expresiones vagas como «lo lleva informática».
Un ejemplo cotidiano
En un viaje en grupo alguien reserva el alojamiento, otra persona conduce y otra confirma la hora de salida. Si «alguien lo hará» sustituye a esas asignaciones, puede faltar la reserva aunque todos pensaran que estaba resuelta.
En Tech Server IIT Spain
Un técnico podría revisar una prioridad, mientras que otra función autorizaría modificar la regla del clasificador. Tech Server IIT Spain tendría que comprobar quién cubre cada decisión y qué ocurre cuando la persona habitual no está disponible.
Cómo empezar a aplicarlo
- Enumera las actuaciones y decisiones que necesita el uso de IA.
- Asigna funciones con autoridad y medios, confirmando que existen.
- Define sustitución, escalado y límites cuando falta cobertura.
Cómo comprobarlo
Una asignación de funciones ayuda a localizar responsables. Ensaya además una revisión urgente con ausencia del titular: observa si la alternativa puede intervenir dentro de sus límites.
Un error habitual: Nombrar a un responsable que no puede detener una actuación o no dispone de tiempo para revisarla.
Ahora prueba tú
¿Quién puede corregir una prioridad y quién puede cambiar el funcionamiento del clasificador?
Ver orientación después de responder
Separa ambas decisiones y sus límites. Identificar una persona no basta si no se comprueban la autoridad, los medios y la cobertura necesarios.
En el curso: Módulo 3 · Política, liderazgo y gobierno · Módulo 8 · Supervisión humana y transparenciaResponsabilidades, autoridad y capacidad real para intervenir.
Volver al índice de la guíaA.3.3 · Comunicación de inquietudes
Las personas que trabajan con una IA pueden detectar problemas antes de que aparezcan en un informe: una respuesta extraña, una regla confusa o una presión para aceptar recomendaciones dudosas. Hace falta un cauce para comunicar esas inquietudes y conseguir que alguien las revise. También debe quedar claro qué hacer cuando lo comunicado requiere atención urgente.
El cauce tiene que ser conocido y utilizable. Recibir mensajes sin respuesta puede hacer que el equipo deje de avisar. Conviene asignar recepción, evaluación y seguimiento, con protección adecuada de la información. Una inquietud es una señal que merece atención; no demuestra automáticamente un fallo ni debe descartarse por falta de pruebas completas.
Un ejemplo cotidiano
Si notas olor a gas, necesitas saber a quién avisar y cómo actuar. Un cartel con un teléfono que nadie atiende no ofrece la misma ayuda que una vía conocida con respuesta y alternativa.
En Tech Server IIT Spain
Un técnico que vea prioridades sospechosas debería poder comunicar el patrón y su contexto. El servicio revisaría los casos y los datos disponibles sin obligarle a demostrar por sí solo toda la causa del problema.
Cómo empezar a aplicarlo
- Define una vía de comunicación y explica qué situaciones admite.
- Asigna quién recibe, revisa y sigue lo comunicado.
- Ensaya el cauce y distingue la inquietud general de una urgencia operativa.
Cómo comprobarlo
Utiliza una comunicación de prueba y sigue su recorrido. El registro debe permitir conocer recepción, revisión y siguiente paso; la ausencia de avisos no acredita que todo funcione bien.
Un error habitual: Interpretar una duda del técnico como resistencia al cambio o pedirle que investigue todo antes de avisar.
Ahora prueba tú
¿Cómo sabría una persona que su advertencia se ha recibido y será revisada?
Ver orientación después de responder
Describe confirmación, función revisora y seguimiento. Evita prometer una respuesta o plazo que el servicio todavía no puede garantizar.
En el curso: Módulo 3 · Política, liderazgo y gobierno · Módulo 8 · Supervisión humana y transparenciaComunicación de inquietudes y vías de revisión de una decisión.
Volver al índice de la guíaRecursos para los sistemas de IA · A.4
Datos, herramientas, infraestructura y personas hacen posible el uso. Conocer esas dependencias ayuda a evitar medidas que solo podrían funcionar en condiciones ideales.
A.4.2 · Documentación de los recursos
Para gestionar una IA necesitamos saber de qué depende. Sus recursos pueden incluir datos, herramientas, infraestructura y personas. Documentarlos permite reconocer qué hace posible el servicio, quién mantiene cada elemento y qué limitaciones afectan al uso. No se trata de inventariar cualquier objeto de la empresa, sino de identificar las dependencias relevantes del sistema.
Esta visión ayuda cuando falta un recurso o se cambia una pieza. Si una prueba depende de una integración y de una persona con conocimiento específico, conviene tener ambas dependencias visibles. La documentación necesita mantenerse y relacionarse con el uso y la versión, para que no describa una configuración que ya dejó de existir.
Un ejemplo cotidiano
Antes de preparar una comida para veinte personas compruebas ingredientes, horno, utensilios y ayuda disponible. Tener la receta no garantiza disponer de los recursos para cocinarla.
En Tech Server IIT Spain
La prueba del clasificador podría depender de tickets sintéticos, etiquetas revisadas, una integración de prueba y personal de soporte. Registrar esas dependencias permitiría valorar qué cambia si falta el conjunto de datos o la persona revisora.
Cómo empezar a aplicarlo
- Describe el uso y las dependencias que necesita para funcionar.
- Identifica propiedad o responsabilidad, disponibilidad y limitaciones de cada recurso relevante.
- Actualiza el registro cuando cambie el sistema o sus condiciones.
Cómo comprobarlo
El inventario debe permitir reconstruir una configuración concreta. Contrástalo con una prueba o recorrido del servicio y verifica que las dependencias utilizadas coinciden con lo documentado.
Un error habitual: Listar únicamente ordenadores y olvidar datos, herramientas externas o capacidad humana.
Ahora prueba tú
Si la persona experta no estuviera disponible, ¿dónde quedaría visible esa dependencia?
Ver orientación después de responder
El registro de recursos debe relacionar la competencia con el uso y la alternativa existente. Si no hay alternativa, ese límite necesita quedar documentado.
En el curso: Módulo 4 · Inventario de sistemas y usos de IAInventario de las dependencias relevantes de cada uso.
Volver al índice de la guíaA.4.3 · Recursos de datos
Una IA puede necesitar datos para desarrollarse, probarse o utilizarse. Este control nos invita a identificar esos recursos y comprender su función: qué contienen, de dónde vienen, quién los mantiene y qué condiciones limitan su uso. Dos conjuntos llamados «tickets de soporte» pueden representar situaciones y periodos muy diferentes.
Documentar el recurso no equivale a afirmar que sus datos son buenos. Primero necesitamos reconocerlo; después podremos comprobar calidad, procedencia y preparación con los controles del grupo A.7. Es útil distinguir versiones, finalidades y limitaciones para evitar que un conjunto preparado para una prueba se utilice como si respaldase todo el servicio.
Un ejemplo cotidiano
Una lista de la compra de la semana pasada no describe lo que queda hoy en la despensa. Identificar el conjunto y su fecha ayuda a entender para qué información puede servir.
En Tech Server IIT Spain
Tech Server IIT Spain podría describir un conjunto sintético con tickets urgentes y no urgentes para ensayar el clasificador. Ese conjunto serviría para la prueba prevista; no demostraría la frecuencia real de errores del servicio.
Cómo empezar a aplicarlo
- Identifica los conjuntos o fuentes que utiliza cada actividad.
- Documenta finalidad, responsable, versión y limitaciones relevantes.
- Relaciona cada recurso con las condiciones de calidad, acceso y uso que habrá que comprobar.
Cómo comprobarlo
La ficha de datos debe permitir reconocer el conjunto exacto usado en una prueba y sus límites. Comprueba que otra persona pueda localizarlo e interpretar qué situaciones representa.
Un error habitual: Hablar de «los datos» como un recurso único, sin distinguir desarrollo, pruebas y operación.
Ahora prueba tú
¿Un conjunto sintético demuestra la tasa de error real del clasificador?
Ver orientación después de responder
Permite ensayar escenarios definidos. Para estimar una tasa operativa harían falta observaciones y un método de selección adecuados, con población y periodo claros.
En el curso: Módulo 4 · Inventario de sistemas y usos de IA · Módulo 7 · Datos, privacidad y seguridadIdentificación de los datos y condiciones para utilizarlos.
Volver al índice de la guíaA.4.4 · Recursos de herramientas
El servicio de IA suele apoyarse en varias herramientas: el modelo, la aplicación que lo presenta, las conexiones con otros sistemas y los componentes que revisan o registran resultados. Identificar estas piezas ayuda a comprender dónde se genera una propuesta, dónde se transforma y dónde podría producir efectos.
Esta distinción importa porque una capacidad no implica otra. Un chatbot puede redactar instrucciones sin tener acceso para ejecutarlas. Una pantalla puede mostrar una prioridad que otra integración aplica después. Conocer funciones, versiones y dependencias evita atribuir toda la actividad a «la IA» y permite revisar el componente adecuado cuando cambia el comportamiento.
Un ejemplo cotidiano
En una cocina el termómetro mide, el horno calienta y el temporizador avisa. Si confundes sus funciones, puedes creer que programar el aviso apagará el horno cuando no existe esa conexión.
En Tech Server IIT Spain
En el clasificador hay que distinguir quién propone la prioridad, quién la muestra al técnico y qué componente la escribiría en el sistema de tickets. Esa separación ayuda a localizar los puntos de revisión y autorización.
Cómo empezar a aplicarlo
- Describe las herramientas y conexiones que participan en el recorrido.
- Identifica función, versión, configuración y límites pertinentes.
- Comprueba qué capacidades y permisos existen realmente antes de atribuirlos al sistema.
Cómo comprobarlo
Un mapa de componentes y una prueba de recorrido permiten contrastar propuesta, presentación y aplicación. Conserva las versiones que intervienen para poder interpretar cambios posteriores.
Un error habitual: Suponer que una herramienta ejecuta acciones porque es capaz de explicar cómo realizarlas.
Ahora prueba tú
¿Qué componente convierte una recomendación de prioridad en un cambio efectivo del ticket?
Ver orientación después de responder
Localiza la conexión y los permisos reales. Si esa capacidad no se ha comprobado, describe la propuesta y mantén pendiente la posibilidad de aplicación.
En el curso: Módulo 4 · Inventario de sistemas y usos de IAHerramientas, componentes, versiones y conexiones del uso.
Volver al índice de la guíaA.4.5 · Recursos de sistema e infraestructura
La IA necesita un entorno técnico: capacidad de cálculo, almacenamiento, conexiones, servicios y otras piezas que permiten utilizarla. Comprender esos recursos ayuda a valorar disponibilidad, limitaciones y dependencia de infraestructura propia o externa. Un sistema adecuado en una prueba pequeña puede comportarse de otra manera cuando crece la demanda.
La revisión debe relacionarse con el uso concreto. Interesa saber qué necesita el servicio, qué puede soportar el entorno y cómo se actúa si una dependencia falla. Documentar infraestructura no obliga a poseerla: cuando la proporciona un tercero, siguen siendo relevantes las condiciones y la información que necesitamos para gestionar el servicio.
Un ejemplo cotidiano
Tener un buen electrodoméstico no basta si la instalación eléctrica no puede alimentarlo o si el enchufe falla. También necesitas prever qué harás mientras no puedas utilizarlo.
En Tech Server IIT Spain
Tech Server IIT Spain podría comprobar qué ocurre si se pierde la conexión con el clasificador. La atención de tickets necesitaría una alternativa viable, con funciones y recursos disponibles, sin asumir que el proveedor la resolverá inmediatamente.
Cómo empezar a aplicarlo
- Relaciona cada actividad con sus dependencias de cálculo, almacenamiento y conexión.
- Contrasta capacidad y disponibilidad con el uso y la demanda previstos.
- Prepara y ensaya una alternativa cuando falle una dependencia relevante.
Cómo comprobarlo
Conserva la descripción del entorno y los resultados de las comprobaciones pertinentes. Una prueba de indisponibilidad debe mostrar si la atención continúa y bajo qué límites.
Un error habitual: Considerar suficiente que el sistema responda una vez durante una demostración.
Ahora prueba tú
Si deja de llegar la prioridad propuesta, ¿cómo continúa el triaje?
Ver orientación después de responder
Describe una alternativa disponible y su capacidad. No conviertas una idea de contingencia todavía no probada en una garantía de continuidad.
En el curso: Módulo 4 · Inventario de sistemas y usos de IA · Módulo 9 · Proveedores y ciclo de vidaDependencias técnicas y puntos de revisión ante cambios.
Volver al índice de la guíaA.4.6 · Recursos humanos
La IA cambia tareas, pero sigue necesitando personas que comprendan su uso, sus límites y las decisiones que les corresponden. Los recursos humanos incluyen competencia, disponibilidad y capacidad para actuar. Una revisión puede fallar si el revisor desconoce el contexto, no tiene acceso a la información o recibe más casos de los que puede atender.
Conviene relacionar las competencias con funciones concretas y comprobar que se pueden ejercer durante la operación. La formación es una ayuda, pero asistir a un curso no demuestra por sí solo que alguien pueda resolver un caso. También hacen falta apoyo, cobertura y autoridad para cuestionar una recomendación cuando corresponda.
Un ejemplo cotidiano
Nombrar a alguien cocinero de una celebración no le proporciona experiencia, ingredientes ni tiempo. La tarea necesita una persona preparada y condiciones que permitan realizarla.
En Tech Server IIT Spain
El revisor de tickets necesitaría entender criticidad, conocer el servicio y disponer de tiempo para cuestionar una prioridad. Una carga de trabajo incompatible con la revisión dejaría el control en el papel.
Cómo empezar a aplicarlo
- Define qué conocimientos y capacidades necesita cada función.
- Contrasta formación, experiencia, tiempo, accesos y cobertura disponibles.
- Ensaya tareas representativas y prepara apoyo para las carencias detectadas.
Cómo comprobarlo
Una matriz de competencias puede organizar la información. Añade comprobaciones de tareas y cobertura: importa observar si la función puede revisar e intervenir, manteniendo visibles los límites.
Un error habitual: Dar por eficaz la revisión humana solo porque existe un nombre asignado o un certificado de formación.
Ahora prueba tú
¿Qué necesita un técnico para cuestionar de verdad una propuesta del clasificador?
Ver orientación después de responder
Relaciona competencia, información, tiempo, autoridad y cobertura con la tarea. La respuesta debe explicar cómo se comprueba cada condición pertinente.
En el curso: Módulo 3 · Política, liderazgo y gobierno · Módulo 8 · Supervisión humana y transparenciaCompetencia, disponibilidad y medios para revisar e intervenir.
Volver al índice de la guíaEvaluación de impactos · A.5
Miramos las consecuencias sobre personas, colectivos y sociedad. El contexto y la posibilidad de corregir un efecto importan tanto como un resultado agregado.
A.5.2 · Proceso de evaluación de impactos
Evaluar impactos significa estudiar cómo una IA puede afectar a personas, colectivos y sociedad. No se limita a preguntar si la herramienta se estropea o si ahorra dinero. También interesa si dificulta el acceso a un servicio, cambia las condiciones de trabajo o produce efectos que cuesta corregir.
Un proceso define cuándo se hace esa evaluación, quién participa, qué información se considera y cómo se utilizan sus conclusiones. El contexto importa: una misma demora puede tener consecuencias muy diferentes. La evaluación debe poder revisarse cuando cambia la finalidad, la configuración o la información disponible. Así los impactos influyen en las decisiones antes de quedar reducidos a una nota al final del proyecto.
Un ejemplo cotidiano
Antes de cambiar el horario de un autobús, se estudia quién depende de él para trabajar, ir al colegio o acudir a una cita. Que el nuevo horario sea cómodo para la mayoría no explica todas las consecuencias.
En Tech Server IIT Spain
Antes de aplicar prioridades del clasificador, el servicio estudiaría quién depende de la atención urgente, qué supondría una demora y qué posibilidades de revisión existen. Las conclusiones podrían modificar condiciones de uso y medidas.
Cómo empezar a aplicarlo
- Delimita uso, personas y contexto de la evaluación.
- Define participación, información, momentos de revisión y tratamiento de incertidumbres.
- Relaciona las conclusiones con decisiones y medidas que puedan revisarse.
Cómo comprobarlo
Conserva la evaluación y su vínculo con una decisión. Comprueba si un cambio relevante activa su revisión y si las conclusiones realmente se consideran al decidir.
Un error habitual: Reducir todos los impactos a pérdidas económicas o valorar una vez y olvidar los cambios posteriores.
Ahora prueba tú
¿Cuándo habría que volver a evaluar los efectos del clasificador?
Ver orientación después de responder
Explica qué cambio de uso, afectados o información alteraría la evaluación. Pasar de recomendación experimental a aplicación operativa es una situación que merece reconsideración.
En el curso: Módulo 5 · Riesgos e impactos · Módulo 6 · Tratamiento de riesgos y selección de controlesIdentificación de efectos y su relación con las medidas propuestas.
Volver al índice de la guíaA.5.3 · Documentación de la evaluación de impactos
Una evaluación necesita dejar un rastro que permita entender qué se estudió y por qué se llegó a una conclusión. Documentarla significa conservar ámbito, supuestos, información, resultados, limitaciones y decisiones pertinentes. No exige escribir muchas páginas: exige que otra persona pueda reconstruir lo importante.
El registro debe distinguir hechos de posibilidades. Un efecto potencial no puede presentarse como un daño observado, y una falta de información no debería desaparecer al redactar las conclusiones. Las versiones y las relaciones con riesgos y controles ayudan a comprender cómo evolucionó la evaluación y qué información sigue pendiente.
Un ejemplo cotidiano
Si un taller revisa una avería, su parte explica lo comprobado, lo sustituido y lo que falta probar. Una nota que diga «todo revisado» no permite comprender el diagnóstico ni repetir la comprobación.
En Tech Server IIT Spain
IMP-001 podría describir una prolongación de la interrupción del trabajo si una prioridad insuficiente se aplica. El registro mantendría visible que se trata de un efecto potencial y qué datos permitirían comprobar una demora real.
Cómo empezar a aplicarlo
- Registra ámbito, información considerada y participantes pertinentes.
- Separa efectos potenciales, resultados observados y limitaciones.
- Relaciona conclusiones, decisiones, riesgos y versiones para facilitar la revisión.
Cómo comprobarlo
Pide a otra persona que reconstruya la evaluación a partir del registro. Si necesita adivinar supuestos o no distingue lo observado de lo posible, falta información útil.
Un error habitual: Redactar una conclusión contundente que oculte la falta de datos o mezcle el caso didáctico con hechos reales.
Ahora prueba tú
¿Cómo dejarías claro que IMP-001 todavía es potencial?
Ver orientación después de responder
Explica el escenario condicionado y la evidencia disponible. Identifica qué aplicación, demora o consecuencia tendría que comprobarse antes de hablar de un efecto observado.
En el curso: Módulo 5 · Riesgos e impactos · Módulo 6 · Tratamiento de riesgos y selección de controlesRegistro de impactos, límites de información y decisiones.
Volver al índice de la guíaA.5.4 · Impactos sobre personas y colectivos
Las consecuencias de una IA pueden ser diferentes para cada persona o grupo. La evaluación debe mirar quién resulta afectado, qué necesita y qué capacidad tiene para comprender, cuestionar o corregir el resultado. Un promedio puede ocultar que una parte de los usuarios recibe una atención peor o sufre un perjuicio importante.
Conviene considerar dependencia del servicio, vulnerabilidad y posibilidades de recuperación, sin atribuir características o daños sin información. Escuchar a las personas afectadas puede revelar situaciones que un indicador general no muestra. La finalidad es mantener esos efectos visibles para decidir medidas proporcionadas al contexto.
Un ejemplo cotidiano
Una escalera puede resultar cómoda para muchas personas y bloquear el paso a alguien con movilidad reducida. El dato «la mayoría entra sin problemas» no resuelve la dificultad de esa persona.
En Tech Server IIT Spain
La misma demora de dos horas puede permitir a un trabajador hacer otra tarea y dejar a otro completamente detenido. El servicio debería estudiar esas diferencias al decidir cómo revisar la criticidad.
Cómo empezar a aplicarlo
- Identifica personas y colectivos afectados y su relación con el servicio.
- Estudia consecuencias, dependencia, posibilidad de revisión y recuperación.
- Conserva diferencias relevantes y relaciona medidas con necesidades concretas.
Cómo comprobarlo
La evaluación debe mostrar a quién se refiere cada consecuencia y qué información la respalda. Revisa si los indicadores agregados dejan fuera efectos específicos que requieren atención.
Un error habitual: Aceptar un perjuicio específico únicamente porque el resultado medio de productividad mejora.
Ahora prueba tú
¿Qué información necesitas para comparar el efecto de la misma demora en dos usuarios?
Ver orientación después de responder
Considera tarea interrumpida, alternativas, dependencia y recuperación. Evita asignar gravedad solo por la duración, sin comprender el contexto de cada persona.
En el curso: Módulo 5 · Riesgos e impactosPersonas afectadas, contexto y consecuencias potenciales.
Volver al índice de la guíaA.5.5 · Impactos sobre la sociedad
Algunos efectos se amplían cuando una IA se utiliza de forma repetida o en muchos lugares. Puede influir en acceso a servicios, distribución de oportunidades, confianza o condiciones del entorno social. Mirar estos impactos ayuda a reconocer consecuencias que no aparecen al revisar una interacción aislada.
La profundidad del estudio dependerá del uso y de su contexto. No hay que inventar grandes efectos sociales para una prueba pequeña, pero tampoco descartarlos porque cada decisión individual parezca poco relevante. Interesa estudiar acumulación, alcance y posibles patrones, dejando claro qué es una hipótesis y qué información existe para contrastarla.
Un ejemplo cotidiano
Que un autobús se retrase un día afecta a un viaje. Si una línea deja sistemáticamente sin conexión a un barrio, el efecto alcanza el acceso al trabajo y a otros servicios del conjunto de vecinos.
En Tech Server IIT Spain
Si un servicio extendido clasificase peor determinadas formas de expresar una urgencia, podría generar un patrón de atención desigual. Tech Server IIT Spain tendría que comprobar ese escenario antes de afirmar que existe o que está descartado.
Cómo empezar a aplicarlo
- Estudia alcance y repetición del uso, además del caso individual.
- Identifica posibles efectos acumulados o patrones pertinentes al contexto.
- Define información y seguimiento para contrastarlos y revisar decisiones.
Cómo comprobarlo
Conserva el razonamiento y los límites del análisis. Si se estudia un patrón, explica población, periodo y observaciones, sin extrapolar una muestra de prueba a toda la sociedad.
Un error habitual: Declarar impacto social positivo por la utilidad de la herramienta sin considerar su distribución y sus posibles efectos acumulados.
Ahora prueba tú
¿Qué diferencia hay entre un ticket mal clasificado y un patrón de atención desigual?
Ver orientación después de responder
El patrón necesita observaciones relacionadas y un método que permita estudiar distribución y repetición. Un caso puede motivar investigación, pero no demuestra por sí solo el patrón.
En el curso: Módulo 5 · Riesgos e impactosPunto de partida: identificar afectados y efectos más amplios con esta guía.
Volver al índice de la guíaCiclo de vida del sistema de IA · A.6
Un sistema se define, desarrolla o adapta, comprueba, pone en uso y mantiene. Cada etapa necesita decisiones y una relación clara con la anterior.
A.6.1.2 · Objetivos para un desarrollo responsable
Cuando una organización desarrolla o adapta un sistema de IA, necesita definir qué resultados pretende conseguir de forma responsable. La precisión técnica es una parte del trabajo; también importan uso previsto, consecuencias, límites y condiciones de intervención. Esos objetivos orientan decisiones de diseño y permiten valorar si el desarrollo cumple su finalidad.
Un objetivo necesita suficiente concreción para influir en el proyecto. «Que la IA sea buena» no permite comprobar nada. Es más útil identificar comportamientos y condiciones que se estudiarán, vinculándolos con necesidades, riesgos e impactos. Si la organización solo utiliza un producto, habrá que analizar sus actividades reales antes de atribuirle desarrollo o excluir responsabilidades.
Un ejemplo cotidiano
Al diseñar una bicicleta para un niño, el objetivo no es solo que avance deprisa. También importa que pueda frenar, manejarla y utilizarla en el entorno previsto. Esas necesidades influyen en el diseño.
En Tech Server IIT Spain
Si se adapta el clasificador, podrían fijarse objetivos sobre tratamiento de información insuficiente y atención de casos urgentes. Su definición debe responder al contexto y acompañarse de criterios de comprobación.
Cómo empezar a aplicarlo
- Confirma qué actividad de desarrollo o adaptación existe y quién la realiza.
- Define resultados responsables vinculados al uso, riesgos e impactos.
- Relaciona objetivos con decisiones y comprobaciones del desarrollo.
Cómo comprobarlo
Revisa si un objetivo ha influido en un requisito, una decisión de diseño y una prueba. La cadena permite comprobar su función; un lema aislado no la demuestra.
Un error habitual: Medir solo rapidez o precisión global y dejar fuera efectos relevantes del uso previsto.
Ahora prueba tú
¿Qué objetivo añadirías al de reducir el tiempo de clasificación?
Ver orientación después de responder
Propón un resultado ligado a una necesidad concreta y explica cómo se revisaría. No inventes un umbral universal: su justificación debe partir del contexto.
En el curso: Módulo 3 · Política, liderazgo y gobierno · Módulo 9 · Proveedores y ciclo de vidaObjetivos y puntos de decisión del ciclo de vida.
Volver al índice de la guíaA.6.1.3 · Proceso de desarrollo responsable
Un desarrollo responsable necesita una forma organizada de trabajar: actividades, decisiones, revisiones y funciones que permitan considerar consecuencias durante el proyecto. Si las comprobaciones aparecen solo al final, puede descubrirse demasiado tarde que una decisión de diseño dejó fuera un requisito importante.
El proceso debe adaptarse a la actividad realizada, incluyendo cambios y participación de terceros cuando corresponda. No exige una única metodología de proyectos. Puede integrarse con la que ya utiliza el equipo, siempre que queden claras las revisiones necesarias, sus entradas y las decisiones antes de seguir avanzando.
Un ejemplo cotidiano
Al reformar una casa se revisa el plano antes de levantar tabiques y la instalación antes de cerrar las paredes. Comprobarlo todo después de pintar sería más difícil y costoso.
En Tech Server IIT Spain
Una modificación del clasificador que cambie la forma de interpretar urgencias debería pasar por revisiones de necesidades, datos, pruebas y decisión de uso. La propuesta del desarrollador no basta para dar por adecuado el cambio.
Cómo empezar a aplicarlo
- Describe las actividades y decisiones de desarrollo que realmente se realizan.
- Integra revisiones de riesgos, impactos y requisitos en momentos útiles.
- Conserva decisiones, cambios y condiciones para avanzar o reconsiderar.
Cómo comprobarlo
Sigue un cambio representativo a través de sus revisiones. Comprueba quién pudo cuestionarlo, qué información utilizó y cómo quedó justificada la decisión siguiente.
Un error habitual: Añadir una casilla de «ética revisada» al final sin que sus conclusiones puedan modificar el desarrollo.
Ahora prueba tú
¿En qué momento revisarías un cambio que puede alterar prioridades?
Ver orientación después de responder
La revisión debe producirse cuando todavía pueda influir en el diseño y antes del uso que produzca efectos, según las actividades y decisiones pertinentes al caso.
En el curso: Módulo 9 · Proveedores y ciclo de vida · Módulo 6 · Tratamiento de riesgos y selección de controlesCiclo de vida y puntos de decisión en el módulo 9; selección de medidas en el módulo 6.
Volver al índice de la guíaA.6.2.2 · Requisitos del sistema de IA
Un requisito explica algo que el sistema debe cumplir en un contexto definido. Puede referirse a una función, un límite, una condición de calidad o una necesidad de operación. Definir requisitos permite que quienes construyen, compran, prueban y utilizan el sistema comprendan qué resultado se espera.
La redacción necesita ser suficientemente clara para contrastarla. «Entender todos los tickets» no dice qué se considera entender ni cómo se comprobará. Conviene incluir finalidad, situaciones relevantes, comportamiento ante incertidumbre y condiciones de interacción con personas u otros sistemas. Las necesidades pueden cambiar, pero sus modificaciones deben poder revisarse.
Un ejemplo cotidiano
Al encargar una mesa explicas medidas, peso que debe soportar y lugar donde se utilizará. Si solo pides «una mesa bonita», después será difícil decidir si sirve para la tarea.
En Tech Server IIT Spain
Un requisito del clasificador podría definir qué salida debe ofrecer cuando falta información para proponer criticidad, y qué revisión humana se solicita. Su formulación y criterio de prueba tendrían que justificarse.
Cómo empezar a aplicarlo
- Recoge necesidades del uso y condiciones relevantes de las partes implicadas.
- Expresa funciones y límites de manera contrastable, incluyendo casos de información insuficiente.
- Revisa coherencia, versiones y cambios antes de utilizarlos como base de pruebas.
Cómo comprobarlo
Cada requisito importante debe relacionarse con una comprobación y una necesidad. Comprueba que evaluadores distintos entiendan qué observar y que el resultado pueda documentarse.
Un error habitual: Confundir una intención general o una característica comercial con un requisito comprobable del servicio.
Ahora prueba tú
¿Cómo mejorarías «el clasificador debe acertar»?
Ver orientación después de responder
Delimita tarea, situaciones, criterio de evaluación y conducta cuando faltan datos. La cifra o regla elegida necesita una razón; escribir un porcentaje no garantiza un buen requisito.
En el curso: Módulo 4 · Inventario de sistemas y usos de IA · Módulo 9 · Proveedores y ciclo de vidaFinalidad y condiciones del uso; cambios y adquisición en el módulo 9.
Volver al índice de la guíaA.6.2.3 · Documentación del diseño y desarrollo
Documentar el diseño y el desarrollo permite comprender cómo se ha construido o adaptado el sistema y por qué se eligieron determinadas soluciones. Interesan componentes, datos, decisiones, configuraciones y limitaciones relevantes para revisar el uso. La documentación debe corresponder a una versión identificable.
No hace falta conservar cada conversación del proyecto sin criterio. Hace falta información suficiente para entender decisiones importantes y cambios. Si una pieza la desarrolla un tercero, se debe conocer qué información necesitamos y qué limitaciones existen para obtenerla. Que el equipo actual recuerde el diseño no garantiza que otra persona pueda revisarlo meses después.
Un ejemplo cotidiano
Un plano actualizado ayuda a localizar una tubería antes de perforar una pared. Un plano antiguo o el recuerdo de quien hizo la obra puede conducir a una decisión equivocada.
En Tech Server IIT Spain
El clasificador debería tener documentada la integración que muestra o aplica prioridades y sus límites. Si se cambia una configuración, la información debe permitir distinguir la versión de prueba de la que se utiliza después.
Cómo empezar a aplicarlo
- Identifica qué información permite comprender el diseño y las decisiones relevantes.
- Relaciona documentos, datos y configuración con versiones y cambios.
- Revisa que los destinatarios autorizados puedan localizar e interpretar la información.
Cómo comprobarlo
Pide a una persona distinta del autor que explique el recorrido del sistema usando la documentación. Detecta vacíos, versiones incoherentes y decisiones que solo se conocen de memoria.
Un error habitual: Conservar un dibujo inicial aunque la integración real haya cambiado, o recopilar documentos sin identificar su vigencia.
Ahora prueba tú
¿Qué necesitas para explicar por qué una prioridad pasó de propuesta a aplicada?
Ver orientación después de responder
Relaciona diseño de integración, configuración, versión y decisiones pertinentes. Distingue la documentación del diseño de los registros del evento concreto.
En el curso: Módulo 4 · Inventario de sistemas y usos de IA · Módulo 9 · Proveedores y ciclo de vidaVersiones y documentación del uso; gestión del ciclo de vida en el módulo 9.
Volver al índice de la guíaA.6.2.4 · Verificación y validación
Verificar consiste en comprobar si se cumple lo especificado. Validar consiste en comprobar si el sistema resulta adecuado para su uso previsto. Son preguntas relacionadas, pero diferentes. Una herramienta puede producir exactamente la salida diseñada y seguir siendo inadecuada para las personas o el entorno que deben utilizarla.
Las comprobaciones necesitan criterios, casos y condiciones definidas. También hay que distinguir una prueba preparada de una ejecutada y su resultado esperado del observado. No podemos presentar como eficacia demostrada una lista de casos que nadie ha ensayado. Los límites de las pruebas deben quedar visibles para no extender sus conclusiones a situaciones no estudiadas.
Un ejemplo cotidiano
Puedes comprobar que una llave tiene las medidas encargadas: eso es verificar lo especificado. Probar si abre la puerta concreta permite valorar su adecuación. Tener las medidas correctas no garantiza que sirva para cualquier cerradura.
En Tech Server IIT Spain
Verificar el clasificador podría incluir comprobar el formato exigido. Validarlo para soporte exigiría estudiar cómo trata escenarios relevantes y si la revisión propuesta es viable en el servicio.
Cómo empezar a aplicarlo
- Define qué requisito y qué uso se comprobarán, con criterios justificados.
- Prepara casos y condiciones representativos de esas preguntas.
- Ejecuta, registra resultados y límites, y revisa las desviaciones antes de decidir.
Cómo comprobarlo
Conserva casos, versión, condiciones, resultados y conclusión. La evidencia debe permitir saber qué se ensayó realmente y qué sigue fuera del alcance de la comprobación.
Un error habitual: Usar una demostración favorable como prueba de adecuación a todos los casos, o presentar resultados esperados como observados.
Ahora prueba tú
¿Cumplir el formato de salida demuestra que las prioridades son adecuadas?
Ver orientación después de responder
Demuestra una parte de lo especificado. La adecuación de las prioridades al contexto necesita comprobaciones adicionales con criterios y escenarios pertinentes.
En el curso: Módulo 6 · Tratamiento de riesgos y selección de controles · Módulo 9 · Proveedores y ciclo de vidaCriterios y pruebas de controles; ampliación al sistema en el módulo 9.
Volver al índice de la guíaA.6.2.5 · Despliegue del sistema
Desplegar es poner una versión del sistema en el entorno donde se utilizará. Ese paso puede cambiar las consecuencias: un ensayo sin efectos sobre usuarios no equivale a operar dentro del servicio. Es necesario revisar condiciones de puesta en uso, preparación de personas y entorno, comprobaciones y decisión autorizada.
El despliegue necesita contemplar qué ocurre si aparecen problemas y qué límites tendrá el uso inicial. No hay una única forma de hacerlo para todos los sistemas. Lo importante es que la decisión esté relacionada con la versión y con las evidencias disponibles, y que se conozcan pendientes que condicionan el siguiente paso.
Un ejemplo cotidiano
Antes de abrir un restaurante al público, no basta con haber probado una receta. Se comprueba la cocina, el personal, los suministros y qué hacer si algo falla durante el servicio.
En Tech Server IIT Spain
Para pasar del clasificador experimental al uso operativo, el equipo tendría que comprobar integración, reglas de revisión, cobertura y alternativas. La decisión describiría qué versión y qué forma de uso se autorizan.
Cómo empezar a aplicarlo
- Define el entorno y la forma de uso que se pretende iniciar.
- Revisa requisitos, pruebas, recursos, pendientes y respuesta ante problemas.
- Obtén la decisión de la función autorizada y conserva condiciones y versión.
Cómo comprobarlo
Un registro de puesta en uso debe relacionar evidencias y condiciones. Comprueba que el sistema efectivo y las reglas del equipo coinciden con lo autorizado.
Un error habitual: Pensar que una prueba técnica exitosa autoriza automáticamente el uso en producción.
Ahora prueba tú
¿Qué diferencia hay entre probar el clasificador y utilizar su prioridad en un ticket real?
Ver orientación después de responder
Describe el cambio de efectos y responsabilidades. La decisión necesita revisar condiciones y evidencia; no se resuelve copiando el resultado de la prueba.
En el curso: Módulo 9 · Proveedores y ciclo de vida · Módulo 8 · Supervisión humana y transparenciaDecisiones de puesta en uso y límites de actuación supervisada.
Volver al índice de la guíaA.6.2.6 · Operación y seguimiento
Una vez en uso, el sistema necesita atención. Sus entradas, usuarios, configuración o dependencias pueden cambiar y afectar al resultado. Operar y seguir el sistema implica conocer qué observar, quién revisa las señales y cómo se actúa cuando aparecen desviaciones o cambios relevantes.
El seguimiento debe servir para decidir. Un panel lleno de números aporta poco si nadie comprende qué significan o qué conducta corresponde a cada situación. Hay que relacionar observaciones con el contexto, distinguir problemas del sistema de limitaciones de medición y mantener la atención a los usuarios mientras se investiga.
Un ejemplo cotidiano
Un coche revisado antes de un viaje sigue necesitando observar temperatura, combustible y avisos durante la marcha. Mirar el cuadro sirve si sabes cuándo parar o pedir ayuda.
En Tech Server IIT Spain
El soporte podría revisar prioridades corregidas, casos fuera de ámbito y disponibilidad de la intervención humana. Las observaciones permitirían estudiar desviaciones sin atribuir automáticamente su causa al modelo.
Cómo empezar a aplicarlo
- Selecciona señales relevantes al uso y explica qué representan.
- Asigna revisión, criterios de actuación y alternativas de servicio.
- Relaciona resultados y cambios con nuevas comprobaciones o decisiones.
Cómo comprobarlo
Sigue una señal de prueba desde su detección hasta la decisión. Revisa si los registros permiten interpretar población, periodo, contexto y pendientes, además del valor observado.
Un error habitual: Dar por controlado el sistema porque existe un panel o porque no se han registrado incidentes.
Ahora prueba tú
¿Qué harías si aumentasen las prioridades corregidas por los técnicos?
Ver orientación después de responder
Comprobaría primero qué se cuenta y qué cambió en casos, uso o medición. Después revisaría escenarios y decisiones con la evidencia disponible, manteniendo la atención del servicio.
En el curso: Módulo 8 · Supervisión humana y transparencia · Módulo 10 · Seguimiento, medición e incidentes (previsto)Supervisión durante el uso y seguimiento previsto del servicio.
Volver al índice de la guíaA.6.2.7 · Documentación técnica
La documentación técnica ayuda a utilizar, operar y revisar el sistema. Debe describir la información pertinente sobre su funcionamiento, condiciones y límites de manera adecuada para sus destinatarios. El técnico que mantiene una integración puede necesitar detalles distintos de quien utiliza una recomendación.
Prepararla implica ordenar información, identificar versiones y facilitar acceso a quienes la necesitan. También importa que siga siendo válida cuando cambia el sistema. Un manual extenso y obsoleto puede inducir a errores; uno muy breve puede omitir un límite esencial. Hay que equilibrar utilidad, actualización y protección de la información.
Un ejemplo cotidiano
El manual de una lavadora te ayuda si corresponde a tu modelo y explica las funciones que utilizas. Una carpeta con instrucciones de cinco modelos antiguos puede confundirte aunque contenga muchas páginas.
En Tech Server IIT Spain
El soporte necesitaría conocer versión, finalidad, límites e integración del clasificador. Quien investigue una desviación podría requerir información adicional para reconstruir la configuración y sus dependencias.
Cómo empezar a aplicarlo
- Identifica destinatarios y decisiones que deben poder realizar.
- Prepara información suficiente, versionada y accesible según las condiciones de protección.
- Actualiza y comprueba la documentación tras cambios relevantes.
Cómo comprobarlo
Pide a una persona destinataria que realice una tarea representativa con la documentación disponible. Observa si localiza la versión correcta y reconoce sus límites.
Un error habitual: Acumular manuales sin distinguir versiones, o entregar la misma información técnica a cualquier destinatario.
Ahora prueba tú
¿Qué debe saber quien revisa una prioridad que podría estar mal?
Ver orientación después de responder
Necesita contexto, condiciones de uso y referencias para contrastarla. Los detalles se ajustarán a la revisión concreta, sin exponer información innecesaria.
En el curso: Módulo 4 · Inventario de sistemas y usos de IA · Módulo 9 · Proveedores y ciclo de vidaExpediente y versiones; documentación de proveedores, cambios y retirada en el módulo 9.
Volver al índice de la guíaA.6.2.8 · Registro de eventos
Un evento es algo que sucede durante la actividad del sistema: una entrada, una propuesta, una revisión, un cambio o una incidencia, según lo que resulte pertinente registrar. Los registros ayudan a reconstruir qué ocurrió, cuándo, con qué versión y bajo qué condiciones. Son útiles para investigar y comprobar decisiones.
Registrar no consiste en guardar todo por si acaso. Hay que definir qué información es necesaria, cómo se protege, quién puede consultarla y cuánto se conserva según las condiciones aplicables. Tampoco basta con activar una opción: hay que comprobar que los registros existen, son interpretables y permiten reconstruir el caso que queremos estudiar.
Un ejemplo cotidiano
Un recibo indica qué compraste, cuándo y por cuánto. Si solo apunta «compra realizada», puede demostrar que hubo una actividad, pero no ayudarte a resolver una discrepancia sobre un producto concreto.
En Tech Server IIT Spain
Para reconstruir una prioridad dudosa podrían hacer falta propuesta, versión, momento, revisión y decisión aplicada. El equipo definiría qué información es pertinente y cómo evitar registrar contenido sensible innecesario.
Cómo empezar a aplicarlo
- Define qué hechos deben poder reconstruirse y los datos necesarios.
- Establece generación, acceso, protección y conservación de los registros.
- Ensaya su recuperación e interpretación con un caso sintético.
Cómo comprobarlo
Recupera un caso y relaciona sus eventos sin adivinar la secuencia. Documenta datos faltantes y límites; una cadena incompleta no demuestra que lo que falta nunca ocurrió.
Un error habitual: Afirmar «tenemos logs» sin comprobar si permiten reconstruir la versión y la decisión relevantes.
Ahora prueba tú
Si una prioridad se corrigió, ¿qué necesitarías para reconstruir el recorrido?
Ver orientación después de responder
Identifica propuesta, contexto, revisión, decisión y momentos pertinentes. Selecciona información suficiente sin convertir el registro en una copia indiscriminada de datos personales.
En el curso: Módulo 7 · Datos, privacidad y seguridad · Módulo 10 · Seguimiento, medición e incidentes (previsto)Trazabilidad y protección de registros; seguimiento e incidentes previstos.
Volver al índice de la guíaDatos para los sistemas de IA · A.7
La procedencia, calidad y preparación de los datos influyen en lo que podemos concluir. Saber qué información utilizamos es una condición para revisarla.
A.7.2 · Datos para desarrollo y mejora
Los datos utilizados para desarrollar o mejorar una IA influyen en lo que el sistema aprende o en cómo se adapta. Hay que comprender su función, adecuación y condiciones. No todos los datos del servicio tienen esa finalidad: introducir un ticket para obtener una propuesta no demuestra que se utilice después para mejorar un modelo.
Por eso la primera tarea es conocer qué actividad se realiza, por quién y dentro de qué ámbito. Puede haber desarrollo propio, adaptación o uso de una herramienta cuyo proveedor gestiona determinadas actividades. Las decisiones de aplicabilidad necesitan hechos sobre esas relaciones. Desconocer el destino de los datos no permite concluir que la actividad no existe.
Un ejemplo cotidiano
Una academia puede utilizar exámenes para calificar a los alumnos o para preparar nuevos ejercicios. Aunque sean los mismos papeles, la finalidad cambia y conviene saber cuál se está utilizando.
En Tech Server IIT Spain
Tech Server IIT Spain tendría que comprobar si sus tickets se usan para desarrollar o mejorar el clasificador y qué parte interviene. Mientras falte esa información, la decisión sobre esta actividad seguiría pendiente.
Cómo empezar a aplicarlo
- Identifica qué actividades de desarrollo, adaptación o mejora utilizan datos.
- Comprueba finalidad, adecuación, condiciones y funciones propias o de terceros.
- Documenta la decisión de aplicabilidad y los cambios que obligarían a revisarla.
Cómo comprobarlo
Relaciona fuentes, usos y acuerdos con la actividad real. Una comprobación debe permitir distinguir datos de operación de los destinados a desarrollo, manteniendo las limitaciones de información.
Un error habitual: Excluir el control porque se compra una herramienta o afirmar que todo lo enviado sirve para entrenarla sin comprobarlo.
Ahora prueba tú
¿Cómo decidirías si este control es pertinente cuando desconoces qué hace el proveedor con los tickets?
Ver orientación después de responder
Mantén el pendiente, solicita la información pertinente y revisa el ámbito real. Una conclusión necesita evidencia sobre la actividad; la incertidumbre no es una exclusión.
En el curso: Módulo 7 · Datos, privacidad y seguridad · Módulo 9 · Proveedores y ciclo de vidaCondiciones de los datos; evaluación de proveedores y cambios en el módulo 9.
Volver al índice de la guíaA.7.3 · Obtención de los datos
Los datos llegan de algún lugar y bajo ciertas condiciones. Obtenerlos de forma organizada implica identificar procedencia, finalidad, permisos o condiciones pertinentes, forma de recogida y limitaciones conocidas. Que podamos acceder a una información no demuestra que podamos utilizarla para cualquier actividad.
También interesa conocer cómo se recogió. Un formulario puede omitir contexto o una exportación incluir solo determinados casos. Esas decisiones afectan a lo que los datos representan. Comprender la obtención ayuda a evitar usos incompatibles con sus condiciones y conclusiones que sobrepasen lo que el conjunto permite estudiar.
Un ejemplo cotidiano
Encontrar una fotografía en un álbum que alguien te ha prestado no significa que puedas publicarla. Además, la imagen muestra un momento concreto y no toda la historia de las personas fotografiadas.
En Tech Server IIT Spain
Para preparar pruebas, el equipo podría generar tickets sintéticos. Si quisiera utilizar casos reales, tendría que revisar origen, finalidad, condiciones de uso y protección, además de cómo se seleccionan.
Cómo empezar a aplicarlo
- Identifica fuentes, método de recogida y finalidad del conjunto.
- Revisa las condiciones que permiten obtener y utilizar la información.
- Registra selección, restricciones y limitaciones relevantes al uso previsto.
Cómo comprobarlo
Una ficha de procedencia debe permitir saber de dónde sale el conjunto y bajo qué condiciones se usa. Contrasta un caso concreto y verifica que su recorrido coincide con lo descrito.
Un error habitual: Considerar disponibles para cualquier uso todos los datos que pueden exportarse del sistema de tickets.
Ahora prueba tú
¿Qué cambia entre inventar tickets de prueba y reutilizar tickets reales?
Ver orientación después de responder
Cambian procedencia, condiciones, protección y representatividad. Los datos sintéticos permiten ensayar escenarios, pero no describen automáticamente lo que ocurre en el servicio.
En el curso: Módulo 7 · Datos, privacidad y seguridadFuentes y condiciones de obtención y uso de los datos.
Volver al índice de la guíaA.7.4 · Calidad de los datos
Los datos tienen calidad cuando resultan adecuados para la finalidad que deben cumplir. Esa calidad puede depender de exactitud, integridad, actualidad, coherencia y representación de situaciones relevantes. No hay que elegir criterios por costumbre: hay que relacionarlos con la tarea y las consecuencias de utilizar información inadecuada.
Un conjunto puede estar correctamente escrito y seguir dejando fuera casos importantes. También puede contener etiquetas discutibles o datos desactualizados. La revisión debe identificar esas limitaciones, corregir lo que proceda y explicar cómo afectan a las conclusiones. Mucha información no garantiza buena información para un uso concreto.
Un ejemplo cotidiano
Una agenda llena de teléfonos parece completa, pero sirve poco si muchos números están antiguos. Para llamar hoy importa la vigencia, además de que la agenda tenga muchas entradas.
En Tech Server IIT Spain
Para estudiar urgencias, el conjunto necesitaría casos pertinentes y etiquetas justificadas. Si solo contiene tickets fáciles, un resultado favorable no permite concluir que el clasificador atiende adecuadamente los difíciles.
Cómo empezar a aplicarlo
- Define qué características de calidad necesita la tarea.
- Comprueba datos y etiquetas con criterios, alcance y selección explicables.
- Registra correcciones y limitaciones que condicionan resultados o decisiones.
Cómo comprobarlo
Conserva criterios, conjunto revisado, hallazgos y tratamiento. Comprueba si las correcciones mejoran la adecuación y explica lo que sigue sin representarse.
Un error habitual: Confundir volumen de datos con calidad o ocultar problemas de etiquetas bajo un porcentaje global.
Ahora prueba tú
¿Qué revisarías si el conjunto de prueba contiene casi únicamente tickets sencillos?
Ver orientación después de responder
Examinaría su adecuación a los escenarios relevantes, la selección y las etiquetas. Añadir casos puede ayudar a ensayar necesidades, sin convertir la nueva selección en una muestra operativa representativa por defecto.
En el curso: Módulo 7 · Datos, privacidad y seguridadCriterios de calidad y comprobaciones de la ficha FD-001.
Volver al índice de la guíaA.7.5 · Procedencia y recorrido de los datos
Conocer la procedencia de un dato significa poder seguir de dónde viene y qué cambios relevantes ha sufrido antes de utilizarse. Este recorrido facilita interpretar resultados, investigar errores y valorar si el dato es adecuado. Puede incluir origen, versión, selección, transformaciones y responsables de actividades pertinentes.
La profundidad del registro depende del contexto. La finalidad no es conservar cada detalle sin utilidad, sino reconstruir lo necesario para revisar el uso. Si un resultado extraño procede de información recortada, necesita quedar visible ese paso. De otro modo podríamos atribuir al sistema un comportamiento cuya causa está en la preparación de la entrada.
Un ejemplo cotidiano
Para entender una mancha en una prenda, ayuda saber dónde se compró, cómo se lavó y qué producto se utilizó. Ver solo la prenda al final deja fuera posibles causas del resultado.
En Tech Server IIT Spain
Un ticket de prueba debería poder relacionarse con su versión original o sintética, las etiquetas y las transformaciones. Si se elimina una frase, esa modificación puede afectar a la interpretación de urgencia.
Cómo empezar a aplicarlo
- Identifica origen y versión de la información relevante.
- Registra selecciones y transformaciones que influyen en el uso.
- Comprueba que se puede seguir un caso hasta la entrada realmente utilizada.
Cómo comprobarlo
Reconstruye el recorrido de un caso y verifica la relación entre fuente, transformaciones y versión utilizada. Mantén protegida la información y registra los eslabones que no puedes confirmar.
Un error habitual: Guardar la salida del modelo sin conservar qué versión de datos la produjo.
Ahora prueba tú
Si una frase desapareció antes de la clasificación, ¿cómo podrías detectarlo?
Ver orientación después de responder
Necesitas comparar versiones y conocer la transformación realizada. Si no se conserva esa relación, la reconstrucción tiene un límite que debe documentarse.
En el curso: Módulo 7 · Datos, privacidad y seguridad · Módulo 4 · Inventario de sistemas y usos de IAProcedencia, versiones y relación de los datos con cada uso.
Volver al índice de la guíaA.7.6 · Preparación de los datos
Preparar datos incluye limpiar, ordenar, transformar o seleccionar información para que pueda utilizarse. Estas operaciones pueden ser necesarias, pero también cambiar significado y contexto. Una limpieza que elimina palabras, campos o casos puede quitar pistas esenciales para la tarea que queremos estudiar.
Hay que comprender y justificar los pasos, conservar las versiones pertinentes y comprobar sus efectos. La preparación debe coordinarse con calidad y procedencia. No basta con que el archivo final tenga el formato correcto; interesa saber si mantiene información necesaria y si las transformaciones introducen limitaciones para el uso previsto.
Un ejemplo cotidiano
Si resumes una receta y eliminas «apagar el fuego antes de añadir», el texto queda más corto pero cambia una instrucción importante. Recortar información puede alterar el resultado aunque la redacción final sea limpia.
En Tech Server IIT Spain
Si un proceso recorta tickets a las primeras líneas, podría eliminar una explicación de criticidad que aparezca después. El equipo tendría que comprobar ese efecto antes de dar por adecuada la preparación.
Cómo empezar a aplicarlo
- Describe las transformaciones y la necesidad de cada una.
- Comprueba su efecto sobre información relevante y situaciones difíciles.
- Conserva versiones y criterios para repetir o revisar la preparación.
Cómo comprobarlo
Compara entradas antes y después con casos pertinentes. Registra pérdidas, cambios y decisiones, de modo que otra persona pueda repetir y entender el proceso.
Un error habitual: Suponer que quitar texto siempre mejora los datos o revisar únicamente que el archivo pueda abrirse.
Ahora prueba tú
¿Qué comprobarías antes de recortar todas las descripciones de los tickets?
Ver orientación después de responder
Estudiaría dónde aparece la información relevante, qué escenarios podrían perderse y cómo cambia la clasificación. La comodidad técnica no justifica por sí sola la transformación.
En el curso: Módulo 7 · Datos, privacidad y seguridadPreparación, cambios y limitaciones del conjunto de datos.
Volver al índice de la guíaInformación para las partes interesadas · A.8
La información debe ayudar a decidir y a comunicar problemas. El contenido, el momento y el canal se ajustan a lo que necesita cada destinatario.
A.8.2 · Información para los usuarios
Quien utiliza una IA necesita información que le ayude a decidir qué hacer con su resultado. Puede necesitar conocer finalidad, capacidades, límites, condiciones y vías de ayuda. La información útil llega antes o durante la decisión pertinente y utiliza un lenguaje que el destinatario pueda comprender.
No se trata de entregar un manual enorme a todo el mundo. Se trata de organizar lo esencial por momentos y permitir ampliar lo relevante. Un aviso debería corresponder a las capacidades y a la atención disponibles. Si promete revisión humana, hay que comprobar qué significa esa revisión y cómo se solicita.
Un ejemplo cotidiano
El prospecto de un aparato puede ser extenso, pero la persona necesita encontrar qué botón usar, qué situaciones evitar y a quién acudir si falla. La información tiene que servir para la tarea.
En Tech Server IIT Spain
El técnico debería reconocer que la prioridad es una propuesta de IA y saber cuándo revisarla. El chatbot debería explicar su finalidad y ofrecer una vía de ayuda que el servicio pueda atender realmente.
Cómo empezar a aplicarlo
- Identifica las decisiones y dudas del usuario en cada momento.
- Redacta información clara sobre condiciones, límites y ayuda disponible.
- Comprueba comprensión y coherencia con el funcionamiento efectivo del servicio.
Cómo comprobarlo
Pide a una persona representativa que explique qué puede hacer y cómo pedir ayuda tras leer el aviso. Conserva mejoras y comprueba que el cauce ofrecido existe.
Un error habitual: Ocultar un límite importante al final de un texto extenso o anunciar una revisión que nadie puede asumir.
Ahora prueba tú
¿Qué debería comprender el técnico antes de utilizar una prioridad propuesta?
Ver orientación después de responder
Debe reconocer su naturaleza, las condiciones para aplicarla y cómo cuestionarla. La explicación se ajustará al uso autorizado, sin atribuir capacidades no comprobadas.
En el curso: Módulo 8 · Supervisión humana y transparenciaInformación comprensible sobre el uso, sus límites y la revisión.
Volver al índice de la guíaA.8.3 · Comunicación de problemas desde el exterior
Personas externas a la organización pueden detectar problemas que el seguimiento interno no muestra: clientes, usuarios u otras partes afectadas. Hace falta una vía para que comuniquen inquietudes sobre el sistema y para que la organización las reciba, valore y siga. Facilitar esa comunicación mejora la capacidad de conocer efectos reales.
El cauce tiene que poder encontrarse y utilizarse sin obligar a repetir innecesariamente toda la historia. Una comunicación puede describir un fallo, un desacuerdo o una necesidad no atendida. Conviene distinguirlos y conservar la información pertinente, evitando que la persona quede atrapada en la misma herramienta que está cuestionando.
Un ejemplo cotidiano
Una tienda que solo permite reclamar al contestador averiado dificulta conocer sus problemas. Una vía clara y una persona o función que revise la situación permiten atender lo que el sistema habitual no resuelve.
En Tech Server IIT Spain
Un cliente podría avisar de que su urgencia quedó infravalorada. El servicio recogería lo disponible, pediría lo adicional necesario y ofrecería revisión por un cauce real, sin mandarle a reformular el mismo ticket indefinidamente.
Cómo empezar a aplicarlo
- Define un cauce accesible para partes externas pertinentes.
- Asigna recepción, evaluación y respuesta o siguiente paso.
- Comprueba el recorrido y evita repetir información ya disponible.
Cómo comprobarlo
Ensaya una comunicación externa con información sintética. Comprueba acceso, recepción, revisión y continuidad de atención; que no lleguen quejas no demuestra eficacia.
Un error habitual: Interpretar toda queja como incidente probado o descartar un desacuerdo porque la salida de IA parece convincente.
Ahora prueba tú
¿Qué alternativa ofrecerías a una persona que cuestiona al chatbot?
Ver orientación después de responder
Una vía de reconsideración disponible y con límites claros. Debe utilizar lo ya recogido y no depender únicamente de volver a preguntar a la misma herramienta.
En el curso: Módulo 8 · Supervisión humana y transparenciaVías de desacuerdo y reconsideración sin repetir todo el caso.
Volver al índice de la guíaA.8.4 · Comunicación de incidentes
Un incidente puede necesitar comunicación a distintas personas o entidades. Organizarla significa definir qué situaciones se comunicarán, quién decide o realiza el aviso, qué información se necesita y qué requisitos condicionan destinatarios o tiempos. Esos requisitos dependen del caso, las responsabilidades y las obligaciones aplicables.
La información puede evolucionar durante la investigación. Conviene separar lo confirmado, lo provisional y lo pendiente, actualizando lo necesario sin inventar causas. Comunicar debe coordinarse con atención y respuesta: preparar el documento no puede convertirse en una excusa para retrasar una actuación operativa urgente.
Un ejemplo cotidiano
Si una tubería se rompe, puede haber que avisar a vecinos, mantenimiento y al seguro por motivos distintos. Cada aviso necesita información pertinente y un responsable; no se resuelve enviando lo mismo a cualquiera.
En Tech Server IIT Spain
Ante una consecuencia operativa confirmada del clasificador, el servicio revisaría a quién debe avisar y con qué información. Una discrepancia sobre una respuesta todavía no acredita por sí sola ese incidente ni fija obligaciones concretas.
Cómo empezar a aplicarlo
- Define criterios de comunicación y revisa requisitos aplicables al caso.
- Asigna funciones, destinatarios y contenido suficiente para cada aviso.
- Coordina comunicación, respuesta y actualizaciones conforme se confirmen hechos.
Cómo comprobarlo
Un ensayo sintético puede comprobar si las funciones identifican destinatarios y preparan un aviso coherente. Para valorar cumplimiento real serían necesarios los hechos y requisitos concretos de la situación.
Un error habitual: Aplicar a cualquier chatbot el mismo plazo o destinatario sin analizar obligaciones, o presentar una hipótesis como causa confirmada.
Ahora prueba tú
¿Qué comunicarías si sabes que hubo una interrupción pero todavía desconoces su causa?
Ver orientación después de responder
Los hechos confirmados y el estado de atención o investigación pertinente. La causa seguiría pendiente; el aviso no debería rellenarla con una explicación sin evidencia.
En el curso: Módulo 10 · Seguimiento, medición e incidentes (previsto) · Módulo 8 · Supervisión humana y transparenciaComunicación de incidentes prevista; revisión y escalado ya disponibles.
Volver al índice de la guíaA.8.5 · Información para las partes interesadas
Las partes interesadas son personas u organizaciones relacionadas con el sistema o afectadas por él: dirección, equipos, clientes, proveedores y otras, según el contexto. Cada una puede necesitar información distinta para comprender responsabilidades, condiciones, efectos o decisiones. Identificarlas permite preparar una comunicación proporcionada.
El criterio es la necesidad de cada destinatario y los requisitos pertinentes, con protección adecuada de la información. Compartir más datos no siempre informa mejor. La dirección puede necesitar límites y decisiones pendientes; soporte, instrucciones operativas; un cliente, condiciones y vías de atención. La comunicación debe mantener esas diferencias.
Un ejemplo cotidiano
Al organizar una excursión, los participantes necesitan horario y material; el conductor, ruta y puntos de recogida; quien contrata, condiciones del servicio. Todos están relacionados, pero no necesitan el mismo documento.
En Tech Server IIT Spain
Tech Server IIT Spain podría preparar información de uso para técnicos, seguimiento para dirección y condiciones de atención para clientes. Cada comunicación se relacionaría con sus necesidades y con datos que pueden compartirse.
Cómo empezar a aplicarlo
- Identifica partes interesadas y necesidades pertinentes de información.
- Selecciona contenido, momento y canal adecuados a cada destinatario.
- Revisa coherencia, comprensión y condiciones de acceso o protección.
Cómo comprobarlo
Un mapa de comunicaciones permite localizar responsabilidades. Comprueba con destinatarios si reciben lo que necesitan para decidir y si el contenido coincide con el estado real del sistema.
Un error habitual: Enviar un informe técnico completo a todos o confundir la publicidad de capacidades con información suficiente sobre límites.
Ahora prueba tú
¿Qué debería conocer dirección que quizá no necesita un usuario en su interacción?
Ver orientación después de responder
Puede necesitar recursos, riesgos, pendientes y decisiones que requieren autoridad. El usuario necesita información para su actuación concreta; los niveles se ajustan al contexto.
En el curso: Módulo 2 · Alcance y contexto del SGIA · Módulo 8 · Supervisión humana y transparenciaIdentificación de interesados e información útil según su necesidad.
Volver al índice de la guíaUso de los sistemas de IA · A.9
Concretamos para qué se utiliza la herramienta, con qué reglas y qué resultados se buscan. Una capacidad técnica no amplía por sí sola la autorización de uso.
A.9.2 · Proceso de uso responsable
Utilizar una IA responsablemente necesita una forma de trabajar que relacione personas, reglas y decisiones. El proceso explica cómo se emplea la herramienta, qué condiciones se comprueban, cuándo se revisa una salida y qué se hace ante una duda o desviación. Así la responsabilidad se concreta en actuaciones que pueden aprenderse y revisarse.
El proceso debe ajustarse a la tarea. Consultar información y ejecutar un cambio no generan las mismas consecuencias. También debe coordinarse con los demás controles: datos adecuados, recursos, información y supervisión. Si una regla necesita una revisión que nadie puede realizar, hay que resolver esa carencia o mantener el límite correspondiente.
Un ejemplo cotidiano
Utilizar una cocina con seguridad requiere acciones concretas: comprobar utensilios, atender el fuego y actuar si aparece un problema. El cartel «cocina responsablemente» no explica ese recorrido.
En Tech Server IIT Spain
Durante una prueba, el técnico podría contrastar la propuesta de prioridad con el contexto y registrar la decisión. Si falta información pertinente, mantendría pendiente la actuación en lugar de aceptar la propuesta por rapidez.
Cómo empezar a aplicarlo
- Describe el recorrido de uso y sus decisiones relevantes.
- Concreta condiciones, revisiones, funciones y actuación ante dudas.
- Ensaya el proceso con casos favorables y difíciles, registrando límites.
Cómo comprobarlo
Observa un recorrido completo de prueba. Comprueba si las reglas se pueden aplicar con los accesos y recursos reales y si la atención continúa cuando la IA no puede resolver.
Un error habitual: Redactar instrucciones ideales sin comprobar si caben en el trabajo cotidiano.
Ahora prueba tú
¿Qué haría el técnico cuando no puede confirmar que la prioridad propuesta es adecuada?
Ver orientación después de responder
Aplicaría la vía de revisión o atención definida y disponible, manteniendo el pendiente. La falta de información no se convierte en permiso para aceptar automáticamente la propuesta.
En el curso: Módulo 8 · Supervisión humana y transparencia · Módulo 9 · Proveedores y ciclo de vidaReglas de uso e intervención; decisiones del ciclo de vida en el módulo 9.
Volver al índice de la guíaA.9.3 · Objetivos del uso de IA
El uso de IA debe responder a objetivos organizacionales comprensibles. Conviene explicar qué mejora se busca y qué condiciones han de respetarse para considerar que esa mejora resulta útil. Ahorrar tiempo puede ser un objetivo, pero necesitamos relacionarlo con calidad, atención y consecuencias del servicio.
Los objetivos orientan seguimiento y decisiones sobre continuidad o cambios. No basta con que la herramienta produzca resultados atractivos en una demostración. Hay que estudiar su contribución al propósito acordado y reconocer costes o efectos que una medida aislada puede ocultar. Los criterios concretos se justifican según el contexto.
Un ejemplo cotidiano
Comprar un electrodoméstico para ahorrar trabajo tiene sentido si reduce esfuerzo sin hacer peor la tarea que necesitas. Que sea rápido no basta si después exige repetir todo a mano.
En Tech Server IIT Spain
El objetivo del clasificador podría ser apoyar un triaje más consistente y mejorar el flujo de atención. Se estudiaría junto con calidad de decisiones, carga de revisión y atención de los casos difíciles, sin presuponer el beneficio.
Cómo empezar a aplicarlo
- Describe el resultado de servicio que se busca y sus condiciones.
- Relaciona el objetivo con observaciones y criterios justificados.
- Revisa resultados y efectos para decidir continuidad, ajuste o nuevas comprobaciones.
Cómo comprobarlo
La evidencia debe permitir valorar el objetivo completo. Contrasta velocidad con calidad y capacidad de atención; explica periodo, población y límites de los datos utilizados.
Un error habitual: Tomar el número de tickets cerrados como demostración suficiente de que mejora el servicio.
Ahora prueba tú
¿Qué podría ocultar un indicador de clasificación más rápida?
Ver orientación después de responder
Errores, revisiones adicionales o esperas de casos difíciles. La respuesta debe relacionar esos posibles efectos con observaciones que permitan comprobarlos.
En el curso: Módulo 3 · Política, liderazgo y gobierno · Módulo 4 · Inventario de sistemas y usos de IAObjetivos de gestión y finalidad concreta del uso registrado.
Volver al índice de la guíaA.9.4 · Finalidad prevista
La finalidad prevista explica para qué se ha establecido el uso del sistema y bajo qué condiciones. Ayuda a reconocer actividades dentro de ámbito y situaciones que requieren reconsideración. Una herramienta capaz de redactar algo no queda autorizada automáticamente para aplicarlo ni para utilizarse en cualquier contexto.
Definir finalidad supone identificar tarea, destinatarios, entorno y límites relevantes. También hay que reconocer cambios: nuevas integraciones, otros usuarios o consecuencias distintas pueden convertir un uso aparentemente parecido en otro que necesita evaluación. Mantener el ámbito visible facilita que las personas sepan cuándo detenerse y pedir revisión.
Un ejemplo cotidiano
Una escalera pequeña puede servir para alcanzar una balda y resultar inadecuada para reparar el tejado. Que permita subir no significa que cualquier altura o tarea forme parte de su uso previsto.
En Tech Server IIT Spain
USO-004 podría estar limitado a recomendar prioridades en una prueba. Aplicarlas automáticamente a tickets operativos sería un cambio que exigiría revisar finalidad, riesgos, controles y decisiones autorizadas.
Cómo empezar a aplicarlo
- Describe tarea, destinatarios, entorno y condiciones del uso previsto.
- Aclara capacidades permitidas y límites que el equipo debe reconocer.
- Revisa cambios y usos fuera de ámbito antes de extender la actividad.
Cómo comprobarlo
Ensaya una solicitud fuera de ámbito y comprueba que se reconoce y recibe la alternativa prevista. Contrasta configuración y práctica con la finalidad documentada.
Un error habitual: Ampliar el uso porque la herramienta técnicamente puede hacerlo o porque alguien ya la ha utilizado así.
Ahora prueba tú
¿Puede una recomendación experimental convertirse sin más en una decisión aplicada?
Ver orientación después de responder
El cambio necesita revisar efectos, condiciones y autoridad. El éxito técnico de una demostración no sustituye esas decisiones.
En el curso: Módulo 4 · Inventario de sistemas y usos de IA · Módulo 8 · Supervisión humana y transparenciaFinalidad, condiciones de uso y límites del chatbot.
Volver al índice de la guíaRelaciones con terceros y clientes · A.10
El servicio puede depender de varias organizaciones. Necesitamos acordar funciones, información y seguimiento para que ninguna parte dé por hecho que otra resolverá lo pendiente.
A.10.2 · Reparto de responsabilidades con terceros
Cuando varias organizaciones participan en un sistema de IA, conviene aclarar quién realiza cada actividad y quién asume las decisiones correspondientes. Desarrollo, operación, datos, revisión, cambios e incidencias pueden repartirse de maneras diferentes. Necesitamos entender ese reparto para evitar vacíos o supuestos incompatibles.
El acuerdo debe reflejar actividades reales y permitir coordinarse. No basta con una cláusula genérica de responsabilidad ni con señalar a un proveedor cuando aparece un problema. La organización necesita conocer sus obligaciones y las dependencias que debe gestionar, incluyendo qué información recibirá y cómo se actúa si una parte no está disponible.
Un ejemplo cotidiano
En una reforma, el propietario, el albañil y el electricista tienen tareas distintas. Si todos creen que otro probará la instalación, la obra puede entregarse con una comprobación pendiente.
En Tech Server IIT Spain
Tech Server IIT Spain y el proveedor podrían repartirse mantenimiento del modelo, integración, revisión y gestión de registros. Habría que aclarar quién informa de cambios y quién atiende mientras se investiga una desviación.
Cómo empezar a aplicarlo
- Identifica organizaciones, actividades y decisiones que comparten el sistema.
- Acorda responsabilidades, información, límites y coordinación.
- Contrasta el reparto con un cambio o problema representativo.
Cómo comprobarlo
Utiliza acuerdos y un ensayo de coordinación para comprobar que cada parte conoce su función. Documenta vacíos y condiciones aún no confirmadas.
Un error habitual: Suponer que contratar IA traslada toda la responsabilidad del servicio o que el proveedor conoce automáticamente el contexto del cliente.
Ahora prueba tú
Si el proveedor cambia el modelo, ¿quién revisa los efectos sobre la atención?
Ver orientación después de responder
El reparto debe identificar avisos, evaluación y decisión. Que una parte cambie el componente no demuestra que otra haya revisado sus consecuencias en el uso concreto.
En el curso: Módulo 2 · Alcance y contexto del SGIA · Módulo 9 · Proveedores y ciclo de vidaDependencias y funciones; reparto de responsabilidades con terceros en el módulo 9.
Volver al índice de la guíaA.10.3 · Gestión de proveedores
Un proveedor de IA aporta un producto o servicio del que podemos depender. Gestionarlo significa estudiar si lo que ofrece y sus condiciones resultan adecuados al uso, definir lo que necesitamos acordar y mantener seguimiento durante la relación. La revisión debe considerar cambios y limitaciones, además de la compra inicial.
La organización puede necesitar información sobre funciones, datos, versiones, apoyo y manejo de problemas. La profundidad dependerá del contexto y de las responsabilidades. Si el proveedor no aporta una información necesaria, esa limitación debe influir en la evaluación y en las condiciones de uso; no se resuelve suponiendo que todo es adecuado por su reputación.
Un ejemplo cotidiano
Al contratar un transporte, no miras solo el precio. Necesitas saber qué recoge, cuándo, con qué condiciones y qué ocurre si falla. La relación sigue necesitando seguimiento después de firmar.
En Tech Server IIT Spain
Antes de depender del clasificador externo, el servicio revisaría condiciones de datos, cambios de versión, apoyo y registros disponibles. También definiría qué observaciones revisará durante el uso y cómo tratar información faltante.
Cómo empezar a aplicarlo
- Define necesidades y criterios pertinentes para evaluar al proveedor.
- Contrasta información y acuerdos con el uso previsto y sus riesgos.
- Mantén seguimiento de cambios, resultados y problemas de la relación.
Cómo comprobarlo
Conserva evaluación, condiciones acordadas y seguimiento. Comprueba una dependencia concreta: qué ocurre si cambia una versión o falta un registro necesario para revisar un caso.
Un error habitual: Elegir por precio o marca y no revisar condiciones que pueden afectar a datos, cambios o capacidad de atención.
Ahora prueba tú
¿Qué harías si falta información imprescindible sobre el destino de los tickets?
Ver orientación después de responder
Registraría la carencia y su efecto en la decisión, solicitaría comprobación y mantendría las condiciones o límites pertinentes. La ausencia de información no acredita ausencia de riesgo.
En el curso: Módulo 9 · Proveedores y ciclo de vida · Módulo 4 · Inventario de sistemas y usos de IAEvaluación y seguimiento del proveedor en el módulo 9; inventario de dependencias en el módulo 4.
Volver al índice de la guíaA.10.4 · Relaciones con clientes
Cuando ofrecemos productos o servicios con IA a clientes, hay que coordinar expectativas, información y responsabilidades. El cliente necesita comprender qué recibe, qué condiciones afectan al uso y cómo comunicar necesidades o problemas. La organización debe conocer también el contexto que resulte pertinente para prestar el servicio.
La relación requiere seguimiento cuando cambian finalidad, requisitos o condiciones. Prometer capacidades que no están comprobadas puede llevar al cliente a decisiones equivocadas. Conviene explicar límites de manera útil y revisar qué actuación corresponde a cada parte, incluyendo vías de atención y cambios que necesitan reconsideración.
Un ejemplo cotidiano
Al encargar un mueble, cliente y carpintero acuerdan medidas, uso y entrega. Si después se instala en otro lugar o cambia la carga que soportará, hay que revisar si lo acordado sigue siendo adecuado.
En Tech Server IIT Spain
El servicio debería aclarar cómo interviene el clasificador en la atención y qué responsabilidades conserva cada parte. Si un cliente comunica nuevas condiciones de criticidad, habría que revisar su efecto sobre reglas y decisiones.
Cómo empezar a aplicarlo
- Identifica necesidades, expectativas y condiciones pertinentes del cliente.
- Acuerda información, responsabilidades, límites y vías de comunicación.
- Revisa cambios y comprueba que la prestación coincide con lo acordado.
Cómo comprobarlo
Contrasta acuerdos, información al cliente y un recorrido de atención. Comprueba si un cambio de contexto llega a quienes pueden revisar el uso de IA y produce un siguiente paso claro.
Un error habitual: Presentar la IA como una garantía de resolución o considerar que el cliente debe adaptarse siempre a sus limitaciones.
Ahora prueba tú
¿Qué ocurre si el cliente necesita revisar cómo se priorizan sus casos?
Ver orientación después de responder
Debe haber una vía disponible y un reparto de decisiones claro. La revisión se vincula con el contexto y los requisitos, sin dar por hecho que cualquier petición queda aceptada o rechazada automáticamente.
En el curso: Módulo 2 · Alcance y contexto del SGIA · Módulo 9 · Proveedores y ciclo de vidaNecesidades de las partes interesadas y condiciones de la relación con terceros y clientes.
Volver al índice de la guíaUn ejemplo trabajado de principio a fin
Vamos a unir varias medidas en una decisión sencilla, conservando lo que todavía no sabemos.
En el supuesto didáctico, un clasificador propone prioridad baja para un ticket que el evaluador considera urgente. Lo que tenemos es una propuesta y una discrepancia en la revisión. No sabemos todavía si se aplicó la prioridad, si hubo una demora ni si una revisión humana evitaría el problema.
El escenario: si una prioridad insuficiente se aplica sin corrección eficaz, la atención podría demorarse. Para una persona que depende de ese servicio, esa demora podría prolongar la interrupción de su trabajo.
Decidir quién puede intervenir
A.3.2 ayuda a aclarar quién revisa una prioridad, quién puede corregirla y quién autoriza cambios de funcionamiento. A.4.6 ayuda a comprobar si esas funciones tienen competencia y capacidad.
Comprobar la propuesta y el recorrido
A.6.2.4 orienta el diseño de comprobaciones. A.6.2.8 ayuda a reconstruir lo ocurrido. A.9.4 mantiene visible si hablamos de una prueba o de aplicación operativa.
Una inclusión razonada de ejemplo
| Campo | Contenido del ejemplo |
|---|---|
| Referencia y ámbito | A.6.2.8, para los eventos pertinentes de USO-004 en la prueba delimitada. |
| Necesidad | Reconstruir propuesta, versión, revisión y decisión para investigar una prioridad dudosa. |
| Decisión propuesta | Incluir la medida en el ejercicio, por su relación con esa necesidad. Contrastar su contenido y guía antes de una decisión real. |
| Aplicación propuesta | Definir eventos y datos mínimos pertinentes; configurar su registro si existe capacidad y revisar acceso y conservación. |
| Función | Proponer la función técnica responsable y confirmar su autoridad y medios. No se inventa una persona asignada. |
| Estado | Propuesta didáctica. Implantación y eficacia pendientes de comprobación. |
| Evidencia que buscar | Configuración identificable y registros recuperados de un ensayo sintético ejecutado, con su versión y condiciones. |
| Comprobación propuesta | Comprobar que otra persona puede reconstruir un caso sin adivinar eventos, y documentar los datos faltantes. |
| Revisión | Reconsiderar si cambia la integración, el destino de los eventos, las condiciones de acceso o la forma de uso. |
Lo que todavía no podemos concluir: que el control funciona, que la prioridad aplicada fue incorrecta o que se produjo el impacto. La decisión propuesta prepara el siguiente paso; no aporta por sí sola los resultados de su ejecución.
Continúa el registro completo en la lección 6.3 y su plantilla de aplicabilidad. Evita mantener dos versiones distintas de la misma decisión.
Lleva tus decisiones al Excel de aplicabilidad
La guía te ayuda a entender cada control. El Excel te ayuda a conservar la razón de tus decisiones y el siguiente paso.
Imagina una libreta de trabajo con una página para cada medida que estás considerando. En ella escribes dónde la necesitas, por qué, qué harías y cómo comprobarías el resultado. El Excel organiza esa misma información en filas para que puedas revisarla, filtrarla y actualizarla.
Esta herramienta acompaña a la lección 6.3, dedicada a la declaración de aplicabilidad. Puedes empezar aquí después del módulo 5 y trabajar tus decisiones durante el módulo 6.
Plantilla en blanco: tu propio caso
Contiene las 38 referencias del Anexo A y cuatro filas para las medidas propias del ejercicio. Las decisiones empiezan pendientes. Utilízala para registrar tu análisis y añade filas cuando necesites distinguir usos.
Descargar la plantilla en blanco · ExcelEjemplo rellenado: aprende a razonar
Trabaja el clasificador de tickets de Tech Server IIT Spain, identificado como USO-004. Las 38 filas contienen ámbito, fundamento, trabajo propuesto y comprobaciones. Incluye también CT-001 a CT-004.
Descargar el ejemplo rellenado · ExcelQué encontrarás en las tres hojas
- Aplicabilidad: el registro de las 38 referencias y las cuatro medidas propias. En el ejemplo encontrarás 30 inclusiones propuestas y ocho decisiones pendientes de información.
- Guia: preguntas para pensar, evidencias que podrías preparar y enlaces al contenido del curso utilizado.
- Ejemplo: algunas filas desarrolladas paso a paso y una variante de exclusión que se mantiene separada de los hechos del caso central.
En la columna «Decisión» verás «Incluir» en las filas cuya inclusión se propone. Significa que el ejercicio razona la necesidad de esa medida. La columna de implantación y la de evidencia conservan lo que falta diseñar, obtener o comprobar. Las funciones responsables también requieren confirmación.
Cómo leer una fila sin perderte
Empieza por el ámbito: qué uso estás analizando. Lee después el fundamento: qué necesidad explica la decisión. Continúa con la medida y la función propuesta. Termina con la evidencia, la comprobación y la revisión: qué información necesitas, qué observarás y cuándo volverás a estudiar la decisión.
Ejemplo: A.6.2.8, registro de eventos. Para revisar una prioridad dudosa necesitamos reconstruir qué propuso la IA, qué decisión se aplicó y en qué momento. El ejercicio propone incluir el control y diseñar CT-003. La evidencia todavía no se ha aportado. La comprobación propuesta consiste en reconstruir un caso e identificar los tramos sin registro. Por eso una fila puede estar completamente escrita y seguir teniendo trabajo pendiente.
Tu primera práctica con el archivo
- Abre el ejemplo y busca A.6.2.8. Explica con tus palabras la relación entre necesidad, decisión y comprobación.
- Busca A.7.2. Comprueba por qué falta información sobre desarrollo o mejora y por qué el caso conserva «Pendiente».
- Guarda una copia de la plantilla en blanco. Delimita un uso y desarrolla una inclusión y una decisión pendiente.
- Escribe las evidencias que realmente tienes y las que necesitas obtener. Propón una función para el siguiente paso y confirma después su asignación.
- Vuelve a la lección 6.3 para revisar el catálogo completo y a la 6.4 para preparar las acciones necesarias.
Los desplegables ayudan a escribir estados consistentes. Los contadores resumen las decisiones de las 38 referencias iniciales; las cuatro medidas propias quedan fuera de ese recuento. Utiliza los filtros para localizar pendientes y conserva una versión de tu archivo al cambiar decisiones.
Trabaja con datos ficticios o referencias internas controladas. El ejemplo conserva la discrepancia didáctica de prioridad como dato aportado y mantiene sin confirmar la aplicación operativa, la demora y el daño. Para tu organización necesitarás completar el alcance, contrastar los requisitos y obtener las revisiones que correspondan.
Volver al índice de la guíaActividad final y orientación de revisión
Tu primera tarea consiste en explicar decisiones, no en llenar casillas a toda prisa.
- Elige USO-004 o un uso descrito con datos ficticios. Delimita finalidad, actividad y papel de la organización.
- Recorre los nueve grupos y anota qué necesitas saber antes de decidir.
- Desarrolla tres inclusiones que puedas relacionar con una necesidad concreta.
- Registra una decisión pendiente y la comprobación necesaria para resolverla.
- Estudia una posible exclusión como variante condicionada: identifica qué hechos la sustentarían y mantén esa variante separada del caso central.
Qué debe explicar cada respuesta
Referencia y ámbito; necesidad; decisión y justificación; medida propuesta; función con autoridad; estado; evidencia disponible o necesaria; siguiente comprobación; cambio que obliga a revisar.
Cómo revisar tu trabajo
- ¿Otra persona entiende por qué la medida sería necesaria?
- ¿La justificación utiliza hechos del caso y distingue supuestos?
- ¿Queda claro quién podría aplicar la medida y con qué capacidad?
- ¿La evidencia permite respaldar el estado declarado?
- ¿Se mantienen visibles las decisiones y comprobaciones pendientes?
Si una respuesta depende de algo que no has confirmado, conserva esa limitación. Es una información útil para gestionar el trabajo, no un hueco que haya que rellenar con una certeza inventada.
Resultado de la actividad: recorrido de las 38 referencias y cinco decisiones explicadas, relacionadas con tu expediente de tratamiento. Continúa en la guía del Anexo B para concretar las condiciones, actuaciones y comprobaciones de aplicación de tus controles seleccionados.
Palabras que conviene conocer
Si un término te hace perder el hilo, vuelve aquí. La definición breve ayuda a leer la guía; su aplicación concreta depende del contexto.
- SGIA
- Sistema de gestión de inteligencia artificial: la forma organizada de establecer políticas, objetivos, funciones, procesos y revisiones relacionados con la IA.
- Control
- Una medida que ayuda a mantener o modificar un riesgo. Puede ser una regla, una revisión, una configuración o una forma de trabajar.
- Riesgo
- El efecto de la incertidumbre sobre lo que queremos conseguir. En el curso lo estudiamos mediante escenarios y consecuencias, con sus condiciones y datos pendientes.
- Impacto
- Un efecto sobre personas, colectivos o sociedad que necesitamos identificar, evaluar y abordar en relación con el sistema de IA.
- Evidencia
- Información que permite respaldar una afirmación: por ejemplo, un registro de una comprobación. Hay que valorar su pertinencia y sus límites.
- Aplicabilidad
- Decisión sobre la necesidad de un control en el ámbito concreto. Necesita una justificación; no equivale a que la medida ya esté implantada.
- Declaración de aplicabilidad
- Registro que reúne los controles necesarios y las justificaciones de inclusión o exclusión. En el curso también mantenemos visibles las decisiones todavía pendientes.
- Implantación
- Puesta en práctica de una medida. Puede estar implantada y aun necesitar comprobaciones de funcionamiento o eficacia.
- Validación
- Comprobación de que el sistema resulta adecuado para el uso previsto, con criterios y condiciones identificados.
- Verificación
- Comprobación de que se cumple lo especificado. No responde por sí sola a todas las preguntas sobre adecuación al uso.
- Parte interesada
- Persona u organización que puede afectar, verse afectada o percibirse afectada por una decisión o actividad.
- Trazabilidad
- Posibilidad de seguir relaciones y reconstruir un recorrido: por ejemplo, desde una fuente de datos hasta una decisión y su revisión.