Seleccionar controles que actúen sobre el riesgo
Una medida tiene sentido cuando puedes explicar qué parte del escenario modifica, quién la mantiene y cómo comprobarás su funcionamiento.
Objetivo: Relacionar controles propuestos con los riesgos, los impactos y las condiciones del servicio, evitando una selección basada solo en etiquetas.
Conservar el hilo de la decisión
Parte de la respuesta que has propuesto en 6.1. La selección de controles debe mantener esa relación.
En el ejemplo de Tech Server IIT Spain proponemos una prueba delimitada del clasificador: registrar su salida sin aplicarla como prioridad operativa. El objetivo inmediato es limitar la influencia de una propuesta insuficiente mientras obtenemos información. El servicio seguirá atendiendo tickets mediante el proceso convencional que corresponda, cuya capacidad también debe revisarse.
El escenario sigue siendo R-001 / USO-004: una prioridad insuficiente, si se aplica sin una corrección eficaz, podría retrasar la atención. IMP-001 mantiene visible la posible prolongación de la interrupción del trabajo. No se ha confirmado una demora real ni una causa técnica concreta.
Seleccionar controles significa decidir qué medidas hacen viable la respuesta elegida. Un control puede ser técnico, organizativo o una combinación. Antes de añadir una medida, explica cómo se relaciona con el escenario. Así podrás detectar también controles que duplican trabajo sin aportar una protección adicional relevante.
Localizar dónde actúa cada medida
Descompón la secuencia que podría llevar de la salida de IA al perjuicio.
Secuencia del caso: el sistema propone una prioridad insuficiente; la propuesta influye en la prioridad aplicada; no se corrige a tiempo; se demora la atención; la persona sigue sin poder trabajar con normalidad.
Una medida puede intervenir antes de que se aplique la salida, detectar una discrepancia, permitir una corrección o limitar las consecuencias de una demora. Estas funciones son categorías didácticas para analizar el ejemplo, no una clasificación obligatoria de controles de la norma.
Separar la propuesta de la prioridad operativa actúa sobre su aplicación. Dar criterios e información a un revisor pretende mejorar la detección y la corrección. Registrar versiones y decisiones permite investigar lo sucedido. Una vía de escalado y un proceso alternativo pretenden limitar las consecuencias.
Los registros no detienen por sí mismos una prioridad incorrecta. Una regla de revisión tampoco ayuda si no hay nadie con capacidad para aplicarla. El conjunto debe cubrir la secuencia relevante sin prometer una eliminación total del riesgo.
Cuatro controles propuestos para el ejercicio
Los identificadores CT-001 a CT-004 pertenecen al caso didáctico. No son referencias oficiales del anexo A.
CT-001 · Separar propuesta y decisión
Durante la prueba delimitada, impedir que la salida de IA escriba o modifique la prioridad operativa. Precisar los permisos y las interfaces afectados.
Comprobación: seguir una salida hasta el sistema de tickets y verificar que no modifica la prioridad real. Revisar también vías indirectas de aplicación.
CT-002 · Validación con capacidad real
Para el uso futuro que se autorice, definir los criterios de revisión, la información disponible, la posibilidad de cuestionar la propuesta y la capacidad de atención. Durante la prueba, revisar también el triaje convencional.
Comprobación: observar revisiones con casos definidos, incluida una discrepancia relevante. Registrar corrección, escalado y límites de interpretación.
CT-003 · Registro suficiente y protegido
Relacionar propuesta, versión, decisión aplicada y momentos relevantes, con datos adecuados a la finalidad. Definir acceso, conservación y protección de los registros.
Comprobación: reconstruir un caso sin depender de recuerdos ni recopilar información personal innecesaria.
CT-004 · Continuidad y escalado
Definir cómo sostener la atención, quién puede activar el proceso alternativo y qué situaciones requieren una respuesta inmediata o revisar el uso.
Comprobación: ensayar el cambio de proceso y confirmar que los tickets mantienen responsable, prioridad y seguimiento.
Son propuestas sujetas al alcance, los requisitos aplicables y la aprobación que corresponda. Su implantación y eficacia están pendientes. No atribuyas al caso configuraciones, responsables nombrados ni pruebas realizadas que no se han aportado.
Utilizar los anexos A y B con criterio
Primero identifica las necesidades del caso; después comprueba si has dejado alguna sin atender.
El tratamiento combina la elección de una respuesta, la determinación de controles necesarios y su contraste con el anexo A. También considera controles adicionales y la orientación de implantación del anexo B. La declaración de aplicabilidad conserva las razones de inclusión y exclusión. Esta secuencia se relaciona con el apartado 6.1.3 de ISO/IEC 42001:2023.
El anexo A reúne 38 controles en nueve grupos, de A.2 a A.10. Los apartados de objetivos y de introducción no son controles adicionales. El anexo B desarrolla orientación para implantarlos. Ambos deben consultarse en la edición autorizada cuando se comprueban requisitos; las preguntas de esta lección son una ayuda didáctica.
Revisar las 38 referencias evita seleccionar solo las que resultan familiares. No significa que todas deban implantarse de la misma manera en cualquier organización. El alcance, el papel de la organización, los riesgos, los impactos y los requisitos aplicables fundamentan la decisión. El coste o la falta de experiencia pueden condicionar el plan, pero no convierten por sí solos una necesidad en una exclusión.
Comprobación en dos direcciones: desde cada riesgo y requisito hacia las medidas que lo atienden; desde cada referencia del anexo A hacia una decisión razonada. Si queda una necesidad sin cubrir, diseña o añade controles. Si queda una referencia sin revisar, conserva el pendiente.
Recorrer los nueve grupos del anexo A
No hace falta memorizar códigos. Aprende qué preguntas abre cada grupo y a qué parte del caso afectan.
Este mapa contiene las 38 referencias y utiliza rótulos didácticos abreviados. Las preguntas aplican el razonamiento al clasificador de tickets. No son el texto del control ni una lista universal de evidencias obligatorias. El desarrollo de cada ámbito continúa en el resto del curso.
A.2 · Políticas · 3 controles
Conecta los compromisos de IA con las reglas que el equipo utiliza para trabajar. En Tech Server IIT Spain interesa detectar contradicciones entre rapidez, calidad de atención y revisión de prioridades.
| Referencia y tema | Pregunta de trabajo |
|---|---|
| A.2.2 · Política de IA | ¿Qué compromiso impide que la rapidez oculte tickets que necesitan atención? |
| A.2.3 · Coherencia entre políticas | ¿Son compatibles las reglas de IA, soporte, seguridad y protección de datos? |
| A.2.4 · Revisión de políticas | ¿Qué cambio del clasificador obligaría a reconsiderar los compromisos? |
Evidencia que podrías preparar: Política contextualizada y ejemplo de cómo se comunica al equipo. Su existencia y adecuación tendrían que comprobarse.
A.3 · Organización interna · 2 controles
Aclara quién puede decidir, ejecutar, cuestionar y escalar. La existencia de un organigrama no demuestra que esas funciones estén cubiertas durante todos los turnos.
| Referencia y tema | Pregunta de trabajo |
|---|---|
| A.3.2 · Funciones y responsabilidades | ¿Quién puede detener la prueba, corregir una prioridad o autorizar el siguiente uso? |
| A.3.3 · Comunicación de inquietudes | ¿Puede un técnico advertir de una prioridad dudosa y obtener respuesta? |
Evidencia que podrías preparar: Asignación de funciones y comprobación de cobertura por turno. Su existencia y adecuación tendrían que comprobarse.
A.4 · Recursos · 5 controles
Haz visibles datos, herramientas, infraestructura y personas de los que depende el uso. Una revisión humana necesita capacidad y competencia, además de un nombre en una ficha.
| Referencia y tema | Pregunta de trabajo |
|---|---|
| A.4.2 · Inventario de recursos | ¿Qué dependencias necesita la prueba para seguir siendo viable? |
| A.4.3 · Recursos de datos | ¿Qué conjuntos de tickets y etiquetas necesita el ejercicio? |
| A.4.4 · Herramientas | ¿Qué componentes generan, muestran y aplican la propuesta? |
| A.4.5 · Infraestructura | ¿Puede mantenerse el triaje si falla la conexión con el clasificador? |
| A.4.6 · Personas y competencias | ¿Hay personas con criterio y tiempo para revisar tickets difíciles? |
Evidencia que podrías preparar: Mapa de recursos enlazado con USO-004 y sus responsables. Su existencia y adecuación tendrían que comprobarse.
A.5 · Impactos · 4 controles
Examina las consecuencias potenciales para personas, colectivos y sociedad. Conserva por separado las hipótesis del caso y los daños que realmente se hayan comprobado.
| Referencia y tema | Pregunta de trabajo |
|---|---|
| A.5.2 · Proceso de evaluación de impactos | ¿Cuándo y cómo se revisan los posibles efectos de cambiar la prioridad? |
| A.5.3 · Registro de impactos | ¿Puede reconstruirse por qué IMP-001 sigue siendo potencial? |
| A.5.4 · Personas y colectivos | ¿A quién perjudicaría más la misma demora y por qué? |
| A.5.5 · Efectos sociales | ¿El uso extendido podría crear patrones de exclusión en la atención? |
Evidencia que podrías preparar: Método, participantes y desencadenantes de la evaluación. Su existencia y adecuación tendrían que comprobarse.
A.6 · Ciclo de vida · 9 controles
Revisa cómo se define, construye, valida, despliega y mantiene el sistema. Consumir un servicio externo no elimina la necesidad de controlar su integración y su operación.
| Referencia y tema | Pregunta de trabajo |
|---|---|
| A.6.1.2 · Objetivos de desarrollo | ¿Qué resultados responsables guían un desarrollo o adaptación del clasificador? |
| A.6.1.3 · Proceso de desarrollo | ¿Cómo se revisan las decisiones de diseño que pueden alterar prioridades? |
| A.6.2.2 · Requisitos del sistema | ¿Qué debe hacer el clasificador y qué comportamiento quedaría fuera de lo permitido? |
| A.6.2.3 · Registro del diseño | ¿Puede entenderse por qué se eligió una determinada integración? |
| A.6.2.4 · Verificación y validación | ¿Se cumple lo especificado y resulta adecuado para la situación de soporte? |
| A.6.2.5 · Despliegue | ¿Qué condiciones deben cumplirse antes de cambiar la forma de uso? |
| A.6.2.6 · Operación y seguimiento | ¿Quién detectaría una desviación durante el servicio y qué haría? |
| A.6.2.7 · Documentación técnica | ¿Qué necesita conocer cada destinatario para operar o revisar el sistema? |
| A.6.2.8 · Registro de eventos | ¿Podemos reconstruir propuesta, versión, decisión y momentos relevantes? |
Evidencia que podrías preparar: Objetivos de desarrollo vinculados a riesgos y criterios de evaluación. Su existencia y adecuación tendrían que comprobarse.
A.7 · Datos · 5 controles
Relaciona las decisiones sobre datos con el uso previsto. Para el clasificador importa saber qué tickets se utilizan, cómo se preparan y qué situaciones quedan fuera de las pruebas.
| Referencia y tema | Pregunta de trabajo |
|---|---|
| A.7.2 · Datos para desarrollo | ¿Se usan tickets para desarrollar o mejorar el sistema y quién lo hace? |
| A.7.3 · Obtención de datos | ¿De dónde llegan los tickets del ejercicio y bajo qué condiciones pueden utilizarse? |
| A.7.4 · Calidad de datos | ¿Los datos permiten probar casos urgentes y detectar etiquetas dudosas? |
| A.7.5 · Trazabilidad de datos | ¿Puede relacionarse un caso de prueba con su origen y transformaciones? |
| A.7.6 · Preparación de datos | ¿Limpiar o recortar el texto elimina pistas útiles de urgencia? |
Evidencia que podrías preparar: Procesos y responsabilidades de los conjuntos usados en ese trabajo. Su existencia y adecuación tendrían que comprobarse.
A.8 · Información a las partes interesadas · 4 controles
Piensa qué necesita saber cada destinatario y cómo puede comunicar un problema. Publicar un aviso genérico no permite necesariamente comprender o cuestionar una prioridad.
| Referencia y tema | Pregunta de trabajo |
|---|---|
| A.8.2 · Información al usuario | ¿Comprende el técnico qué propone la IA y cómo cuestionarlo? |
| A.8.3 · Avisos desde el exterior | ¿Cómo puede una persona afectada comunicar una priorización inadecuada? |
| A.8.4 · Comunicación de incidentes | ¿Quién comunica un incidente, a quién y según qué criterios aplicables? |
| A.8.5 · Información a interesados | ¿Qué información sobre el uso necesita cada parte interesada? |
Evidencia que podrías preparar: Instrucciones contextualizadas y prueba de comprensión. Su existencia y adecuación tendrían que comprobarse.
A.9 · Uso · 3 controles
Delimita la finalidad, las condiciones permitidas y las prácticas del equipo. El mismo clasificador puede tener efectos distintos como apoyo experimental o como decisor operativo.
| Referencia y tema | Pregunta de trabajo |
|---|---|
| A.9.2 · Proceso de uso responsable | ¿Cómo se evita copiar sin revisión una propuesta durante la prueba? |
| A.9.3 · Objetivos de uso | ¿Cómo se equilibra la mejora del servicio con la atención de casos difíciles? |
| A.9.4 · Finalidad prevista | ¿Está permitida la recomendación experimental, la aplicación operativa o ambas? |
Evidencia que podrías preparar: Procedimiento de uso y observación de las prácticas reales. Su existencia y adecuación tendrían que comprobarse.
A.10 · Terceros y clientes · 3 controles
Estudia el reparto real de tareas y obligaciones. Un contrato puede asignar una ejecución al proveedor sin resolver cómo Tech Server IIT Spain comprueba el resultado.
| Referencia y tema | Pregunta de trabajo |
|---|---|
| A.10.2 · Reparto con terceros | ¿Quién responde de cambios, incidencias, registros y continuidad? |
| A.10.3 · Proveedores | ¿Qué información y condiciones necesitamos exigir y revisar al proveedor? |
| A.10.4 · Clientes | ¿Qué expectativas y responsabilidades deben acordarse con los clientes del servicio? |
Evidencia que podrías preparar: Matriz de responsabilidades contrastada con acuerdos y capacidades. Su existencia y adecuación tendrían que comprobarse.
Relacionar las medidas propias con las referencias
La relación suele ser de varios a varios: una medida puede contribuir a varios controles y un control requerir varias medidas.
| Medida del caso | Referencias para orientar el contraste | Límite de la relación |
|---|---|---|
| CT-001 · Separar propuesta y prioridad | A.9.4, finalidad prevista; A.6.2.4, verificación y validación. | La separación concreta una condición de uso. No cubre por sí sola toda la validación ni todo el control del uso. |
| CT-002 · Revisión con capacidad | A.3.2, funciones; A.4.6, personas; A.9.2, proceso de uso. | Se necesitan autoridad, competencia, capacidad y práctica real. Una firma no demuestra esa combinación. |
| CT-003 · Registro suficiente | A.6.2.8, eventos; relación complementaria con A.6.2.6, seguimiento. | Tener registros no demuestra que se revisen ni que alguien actúe. El diseño debe cubrir finalidad y protección. |
| CT-004 · Continuidad y escalado | A.6.2.6, operación y seguimiento; relación parcial. | La continuidad propuesta se mantiene explícita aunque el catálogo no describa literalmente el mecanismo elegido. |
Por ejemplo, CT-003 necesita decidir qué eventos observar, cómo enlazarlos y cómo protegerlos. Si la medida no permite reconstruir la decisión aplicada, su nombre no basta. Si recopila información innecesaria, habrá que rediseñarla. Conserva CT-003 como identificador interno y enlázalo con la referencia, las acciones y las evidencias.
El objetivo de esta comparación es detectar huecos. No hay que forzar una correspondencia para que todo parezca cubierto ni borrar una medida necesaria porque no tenga un título idéntico en el catálogo.
Buscar huecos, dependencias y efectos adicionales
Comprueba si una medida sigue funcionando cuando otra parte del servicio cambia.
CT-001 puede impedir la aplicación automática y, aun así, quedar una práctica manual que copie la propuesta sin cuestionarla. CT-002 puede estar bien diseñado y fallar durante un pico de trabajo. CT-003 puede permitir reconstruir un incidente pero dejar fuera la versión utilizada. CT-004 puede existir sin capacidad suficiente para sostener la alternativa.
Revisa quién aporta información, quién ejecuta la medida, qué sistema necesita y qué ocurre cuando esa dependencia no está disponible. Una certificación del proveedor o una funcionalidad anunciada no sustituyen esta comprobación del proceso concreto.
Valora además los nuevos efectos: sobrecarga del equipo, esperas adicionales, barreras para pedir ayuda o exposición de datos. Reducir un riesgo de la salida de IA no justifica ignorar un perjuicio introducido por la respuesta elegida.
El mapa anterior orienta la comparación. En 6.3 registraremos decisiones y razones en una plantilla que abarca las 38 referencias y las medidas adicionales necesarias.
Comparar los otros usos de Tech Server IIT Spain
Una misma familia de medidas necesita una adaptación al escenario.
En R-002 / USO-003, el chatbot podría dar una respuesta basada en contenido no aplicable. Una validación útil revisaría vigencia, ámbito y contexto de la información, además de si alguien siguió la instrucción. La revisión del orden de prioridad de un ticket no cubre ese problema.
En R-003 / USO-001, un defecto en una propuesta de código podría afectar al servicio si se incorpora y despliega sin detectarlo. Importan la revisión técnica, las pruebas pertinentes y el proceso de despliegue; el mero aviso «código generado por IA» no acredita protección.
En R-004 / USO-002, una instrucción inapropiada en un borrador de respuesta podría generar trabajo adicional si se envía y se sigue. Separa borrador, mensaje enviado y actuación del destinatario antes de elegir una medida.
Estos escenarios son extensiones didácticas. Si no están dentro del alcance de tu SGIA, registra la situación y el paso de revisión correspondiente. No copies controles de un uso a otro sin justificar su relación con el riesgo y el impacto.
Actividad: preparar tu ficha
Formula medidas para R-001, recorre los nueve grupos del anexo A y detecta al menos dos necesidades que no quedarían resueltas solo con CT-001 a CT-004.
Orientación para revisar tu propuesta
Una selección coherente diferencia la aplicación de la salida, la capacidad real de revisión, la trazabilidad y la continuidad. Puedes proponer otra combinación si explicas cómo actúa sobre el escenario. Revisa especialmente las vías manuales que podrían eludir CT-001, las dependencias del revisor y los efectos de la alternativa. La inclusión en la ficha no demuestra implantación ni eficacia.
Comprueba tu criterio
Explica tus decisiones antes de consultar las orientaciones.
Responde primero con tus palabras. Abre cada orientación después de tu intento.
¿Por qué un registro de decisiones no sustituye a una medida que impide aplicar una salida?
El registro permite investigar y revisar; no necesariamente evita que una prioridad insuficiente se aplique. Debes distinguir la función de cada medida y cubrir los puntos relevantes del escenario.
¿Qué hace que una validación humana sea un control operativo?
Criterios, información, capacidad y autoridad para decidir o escalar, además de evidencia de funcionamiento en las condiciones relevantes. La mera presencia de una firma no basta.
¿Puedes reutilizar el mismo control para el chatbot y el clasificador?
Puedes aprovechar una capacidad común, pero necesitas adaptar la medida al riesgo y al uso. Vigencia del contenido y prioridad del ticket son problemas distintos; su evidencia de eficacia también puede ser distinta.
Lo que te llevas: Cada control propuesto tiene una razón, un punto de actuación, dependencias y una comprobación pendiente de concretar o realizar.
Audio complementario · Bloque A
La empresa ficticia del curso se llama ahora Tech Server IIT Spain. Los audios ya publicados utilizan su nombre anterior, TechServe IT; se trata del mismo caso. La ampliación del anexo A y de la plantilla se desarrolla en las lecciones escritas 6.2 y 6.3.
013. Tratamiento de riesgos de IA: elegir respuestas y controles
Repaso de las lecciones 6.1 y 6.2. Puedes escucharlo después de estudiar el bloque y volver a la actividad que necesites revisar.
Escuchar el capítulo 013 en iVoox (nueva pestaña)
La escucha es opcional. El contenido escrito permite completar el bloque sin escuchar el audio. Lee las precisiones siguientes al interpretar los ejemplos.
Precisiones para interpretar el bloque A
- El servidor caído y la cadena de consecuencias son ejemplos hipotéticos. En Tech Server IIT Spain solo se ha aportado la discrepancia entre la prioridad propuesta y la urgencia apreciada por el evaluador; no se han comprobado aplicación real, demora ni daño.
- Un control puede ser técnico, organizativo o combinado. Implantarlo también puede requerir definir criterios, responsabilidades, procedimientos y formación; las acciones no se limitan a trabajo físico.
- Las cuatro alternativas de tratamiento organizan nuestro ejercicio. No constituyen una clasificación literal y exhaustiva de ISO/IEC 42001.
- Hay que evaluar qué riesgo permanece tras el tratamiento. La aceptación necesita aprobación de la dirección designada y evidencia de la decisión; el apartado 6.1.3 no prescribe una firma concreta como único mecanismo.
Referencias y alcance del material
Contenido didáctico de José Manuel Hernández Agudo. Caso Tech Server IIT Spain: ficticio. NIST se utiliza como referencia complementaria voluntaria; no sustituye ISO/IEC 42001. Las propuestas, estados y comprobaciones no describen una implantación real.
- ISO/IEC 42001:2023, ficha oficial (nueva pestaña)
- Vista previa publicada de ISO/IEC 42001:2023, apartado 6.1.3 (nueva pestaña)
- NIST AI RMF, funciones y categorías (nueva pestaña)
- BSI: estructura de los grupos de controles (nueva pestaña)
- NYCE: mapa público de referencias (nueva pestaña)
Este material no reproduce el texto de la norma ni acredita conformidad. Para comprobar requisitos concretos utiliza el texto normativo autorizado y las obligaciones aplicables al caso.