Se entra una sola vez, para toda la organización. Llega hasta donde alcance la letra de tu organización, e implántalo en tu modo.
Por qué existe
Decide quién decide, antes del primer despliegue. El fallo más común en la adopción de IA no es técnico; es la difusión silenciosa de la responsabilidad, en la que todo el mundo dio por hecho que respondía otro —el proveedor, el departamento de informática o el propio modelo— y no respondía nadie. La responsabilidad que no se fija a una persona concreta emigra, y emigra hacia quien no puede responder de ella. Fíjala antes de que se mueva.
Qué hacer
Cartografía las partes interesadas de cada sistema de IA antes de asignar responsabilidades. Enumera quién tiene algo en juego en el sistema: dentro de la organización, el responsable de negocio, quienes lo operan, seguridad, privacidad, asesoría jurídica, recursos humanos y compras; fuera de ella, el proveedor, los clientes y las personas a las que el sistema afecta, los organismos que supervisan tu sector y —cuando el alcance del sistema es amplio— las comunidades a las que llegan sus salidas, incluidas las preocupaciones de inclusión, de desinformación y de coste ambiental. Las cartografías por una razón: para que ninguna parte afectada se descubra por primera vez durante un incidente.
Nombra una sola persona responsable por sistema de IA, y que sea de negocio, no de tecnología. Cada sistema de IA de tu inventario lleva una persona con nombre —la propietaria de la IA— que responde de para qué sirve el sistema, de si sus resultados son justos con las personas a las que afectan y de cuándo una persona debe intervenir en sus decisiones. Esta persona es dueña del propósito, no de la fontanería. Un sistema sin propietario nombrado no es un simple hueco administrativo: trátalo como uno de tus principales indicadores de riesgo, porque es la condición previa de todos los demás fallos de este dominio.
Separa a quien quiere el sistema en marcha de quien certifica que es seguro ponerlo en marcha. Mantén a la persona propietaria de la IA (la responsabilidad de negocio que se acaba de describir) separada de la propietaria de la tecnología, responsable de la solidez técnica del sistema, de su resiliencia y de su mantenimiento en el tiempo. En las organizaciones pequeñas la tentación es fundir ambas en una sola cabeza. Resístela: la fusión esconde un conflicto de interés justo en el momento en que más importa, la decisión de puesta en marcha, donde las ganas de lanzar y el deber de no aprobar se sientan en la misma silla.
Escala los roles a tu tamaño: combina sombreros, nunca los elimines. En una organización mediana una sola persona puede ostentar legítimamente varios de estos roles; en una grande se separan en funciones dedicadas: una dirección de gobierno, propietarios por sistema, una dirección de tecnología, una revisión de seguridad independiente. Lo que este marco fija es el conjunto de responsabilidades, no la plantilla. Toda responsabilidad debe existir y estar asignada, aunque varias las lleve la misma persona; lo que nunca puede pasar es que una de ellas no la tenga nadie.
Pon por escrito que la rendición de cuentas no se delega en el proveedor. Comprar un modelo o un servicio a un tercero transfiere trabajo; no transfiere la responsabilidad por el impacto de ese sistema sobre tus clientes, tu personal y tus obligaciones. Escríbelo en la política y en la matriz de responsabilidades, porque en su ausencia «lo hizo el modelo del proveedor» se convierte en la defensa por defecto, y es una defensa que fracasa ante cualquier organismo supervisor y ante cualquier tribunal.
Dale a la función de seguridad un papel independiente de cuestionamiento. Asigna, a una función separada del equipo que construye o compra el sistema, el deber permanente de cuestionarlo: modelar cómo se le podría atacar, probarlo de forma adversaria y evaluar su impacto sobre los derechos de las personas antes de su puesta en marcha. Quien construye no puede ser quien le lleve la contraria; la independencia aquí no es desconfianza hacia los compañeros, es la garantía estructural de que a alguien se le paga por encontrar los problemas antes de que lo haga un atacante o un organismo supervisor.
Controles
Baseline2 controles
Control 9
Designa un Responsable de IA para cada sistema del inventario.
BaselinePreventivotodos los rolestoda la organización
Qué es
Una persona que rinde cuentas por sistema, con la situación de sistema sin responsable seguida como indicador clave de riesgo.
Cómo implantarlo · Contenido mínimo
Responsable por sistema: nombre y cargo de un responsable de negocio, no de un técnico ni del proveedor
De qué responde: el propósito del sistema, la equidad de sus resultados y cuándo debe intervenir una persona
Suplente nombrado para ausencias
Fecha de asignación y aceptación por escrito del responsable
Indicador clave de riesgo: número de sistemas sin responsable, comunicado mensualmente a la dirección
Reasignación cuando el responsable se marcha o cambia de puesto
Cómo arrancar
Añade una columna «responsable de IA» al inventario, rellénala para todos los sistemas y pide a cada persona nombrada que lo confirme por escrito.
Evidencia
El inventario con los responsables cumplimentados y el histórico del indicador de sistemas sin responsable.
Modo: ligero / estándar / completo
ligero
El propietario-gerente nombra al responsable de cada herramienta en la hoja del inventario y asume él mismo cualquier sistema sin asignar.
estándar
Los responsables de negocio asumen sus sistemas y quien lidera la IA comunica a la dirección cuántos quedan sin responsable.
completo
La titularidad es un campo obligatorio del registro de configuración y el recuento sin responsable alimenta automáticamente el cuadro de riesgos.
Control 10
Define la vía de escalado para las decisiones y los incidentes de IA.
BaselineCorrectivotodos los rolestoda la organización
Qué es
Todas las personas que operan o supervisan IA saben adónde se dirige una inquietud y quién puede detener un sistema.
Cómo implantarlo · Estructura mínima
Qué escalar: resultados dañinos o erróneos, exposición de datos, sospecha de mal uso, quejas, incumplimiento de líneas rojas
Primer contacto: el responsable de IA del sistema; siguiente nivel: directivo o comité designado
Quién puede suspender o detener un sistema y en qué plazo (p. ej. en el mismo día)
Canal de contacto y tiempo de respuesta esperado en cada nivel
Cómo se registra cada escalado y su resultado
Resumen de una página enviado a todas las personas que operan o supervisan IA
Cómo arrancar
Escribe una página que responda a «¿a quién se lo digo y quién puede apagarlo?» y envíala a todas las personas que usan o supervisan IA.
Evidencia
La vía de escalado publicada y el registro de escalados atendidos.
Modo: ligero / estándar / completo
ligero
Toda incidencia va directamente al propietario-gerente, que puede apagar cualquier herramienta; un buzón compartido las registra.
estándar
Los responsables de IA atienden el primer nivel y escalan a quien lidera la IA, que tiene autoridad para suspender.
completo
Los escalados siguen el proceso de gestión de incidentes, con niveles, tiempos de respuesta y una autoridad de suspensión documentada.
Enhanced3 controles
Control 11
Mantén un mapa de partes interesadas por sistema de IA, que abarque a las partes internas y externas.
EnhancedPreventivotodos los rolestoda la organización
Qué es
Se revisa cuando cambia el alcance o la difusión del sistema.
Cómo implantarlo · Contenido mínimo
Partes internas: responsable de negocio, operadores, seguridad, privacidad, jurídico, RR. HH., compras
Partes externas: proveedor, clientes y personas afectadas, reguladores del sector
Alcance más amplio si procede: comunidades afectadas, inclusión, desinformación y coste ambiental
Para cada parte: cómo le afecta el sistema y cuál es su principal preocupación
Cómo se consulta o informa a cada parte, y el contacto
Fecha de revisión, y revisión siempre que cambie el alcance o la difusión del sistema
Cómo arrancar
Para el sistema que afecta a más personas, celebra una sesión de 30 minutos con su responsable de IA y enumera a todos los que, dentro y fuera de la organización, tienen interés en él.
Evidencia
Los mapas de partes interesadas fechados y su historial de revisiones.
Modo: ligero / estándar / completo
ligero
El responsable de IA mantiene una tabla breve por sistema en la hoja del inventario.
estándar
Se usa una plantilla común y el mapa se revisa en cada aprobación y cambio de alcance.
completo
Los mapas se guardan con la ficha del sistema, los revisa la función de gobierno y sirven para planificar la consulta en los sistemas de alto riesgo.
Control 12
Mantén una matriz de responsabilidades a lo largo del ciclo de vida de la IA.
EnhancedPreventivotodos los rolestoda la organización
Qué es
Para cada etapa, desde la solicitud hasta la retirada, registra quién se encarga de hacer el trabajo, quién rinde cuentas del resultado, a quién hay que consultar y a quién hay que informar; esto es lo que hace visible la dilución de responsabilidades antes de que cause daño.
Cómo implantarlo · Estructura mínima
Filas: cada etapa del ciclo de vida — solicitud, evaluación, aprobación, despliegue, seguimiento, retirada
Columnas: Responsable de IA, responsable técnico, seguridad, privacidad, jurídico, RR. HH., compras, proveedor, comité o dirección
Cada celda: responsable de ejecutar, quien rinde cuentas, consultado o informado
Una sola persona que rinde cuentas por etapa; ninguna etapa sin ella
Línea explícita: la responsabilidad por el impacto sigue en la organización, nunca en el proveedor
Versión, aprobación y revisión siempre que cambien los roles o el ciclo de vida
Cómo arrancar
Redacta la matriz en una página para las seis etapas del ciclo de vida y contrástala con el último sistema que pusiste en producción.
Evidencia
La matriz aprobada y su historial de versiones.
Modo: ligero / estándar / completo
ligero
Una tabla de una página en la que una misma persona puede figurar en varias columnas, pero cada celda que necesita un nombre lo tiene.
estándar
Quien lidera la IA mantiene la matriz y la dirección la aprueba.
completo
La función de gobierno mantiene la matriz por tipo de sistema, vinculada a las descripciones de puesto y revisada en auditorías internas.
Control 13
Documenta cómo escalan los roles en tu organización.
EnhancedPreventivotodos los rolestoda la organización
Qué es
Qué responsabilidades se concentran hoy en qué personas y qué hará que se separen a medida que crezcas.
Cómo implantarlo · Contenido mínimo
Cada responsabilidad: Responsable de IA, responsable técnico, responsable de gobierno, revisor de seguridad independiente, privacidad, autoridad de escalado
Titular actual de cada una, indicando cuáles recaen en la misma persona
Combinaciones no permitidas aunque la organización sea pequeña (p. ej. Responsable de IA y responsable técnico del mismo sistema)
Disparadores para separar roles (p. ej. plantilla, número de sistemas de IA, primer sistema de alto riesgo)
Confirmación de que ninguna responsabilidad queda sin titular
Fecha de revisión, como mínimo anual
Cómo arrancar
Enumera cada responsabilidad y anota su titular actual; marca las que no tengan titular y asígnalas.
Evidencia
El documento de escalado de roles, fechado y aprobado por la dirección.
Modo: ligero / estándar / completo
ligero
Una tabla de media página que mantiene el propietario-gerente y actualiza cuando alguien entra o sale.
estándar
Quien lidera la IA la mantiene y la dirección la revisa cada año.
completo
La función de gobierno la mantiene con RR. HH., vinculada al organigrama y a las descripciones de puesto.
Advanced1 controles
Control 14
Separa el desarrollo de la aprobación de seguridad.
AdvancedPreventivotodos los rolestoda la organización
Qué es
La persona o el equipo que certifica que un sistema es seguro para su lanzamiento es organizativamente independiente de quien lo desarrolló o lo adquirió.
Cómo implantarlo · Reglas mínimas
La aprobación de seguridad la emite una persona o equipo ajeno a la línea jerárquica de quienes construyeron o adquirieron el sistema
Quien construye o compra no puede aprobar la seguridad de su propio sistema
Antes de la puesta en producción, el revisor modela ataques, hace pruebas adversarias y evalúa el impacto en los derechos de las personas
El revisor puede denegar la aprobación; anularla exige una decisión registrada del comité o del consejo
Conflictos de interés declarados y registrados en cada aprobación
Cómo arrancar
Designa la función que dará la aprobación de seguridad y confirma por escrito que no depende de quienes construyen o compran IA.
Evidencia
Los registros de aprobación que muestran la independencia del revisor y sus conclusiones.
Modo: ligero / estándar / completo
ligero
Encarga una revisión externa en cada puesta en producción, ya que a este tamaño la separación interna no es posible.
estándar
El equipo de seguridad, separado de desarrollo y de compras, aprueba cada puesta en producción.
completo
Una función de seguridad de IA dedicada e independiente, que reporta fuera de la línea tecnológica, aprueba y solo el consejo puede anularla.
Evidencia
Los mapas de partes interesadas; la matriz de responsabilidades; la asignación de propietarios en el inventario; las descripciones de los roles; la declaración escrita de no delegación; la evidencia de la revisión independiente de seguridad.