Muchas organizaciones asumen que su rol está fijado: son usuarias de un sistema que un proveedor ha construido, y las obligaciones correspondientes son claras y permanentes. Esta suposición suele ser correcta, pero no siempre. El rol que tiene una organización con respecto a un sistema de IA no es una etiqueta fija. Es el resultado de lo que efectivamente ocurre con el sistema, y ese resultado puede cambiar sin que se firme un nuevo contrato o se realice una nueva compra.
La clasificación de un rol depende de una serie de elementos fácticos, no de cómo un proveedor denomina el sistema ni de cómo un departamento interno posiciona el sistema internamente. Es relevante, entre otras cosas, quién ha comercializado el sistema, quién lo utiliza efectivamente dentro de un proceso propio, y quién lo ha modificado después de su entrega. También cuenta bajo qué nombre se presenta el sistema al exterior, y si una organización distribuye el sistema a otros sin utilizarlo ella misma. Estos elementos determinan conjuntamente si una organización actúa como proveedor, como usuario, o como parte que se encuentra en una posición intermedia.
La razón por la que esto es relevante para la gobernanza es que el rol determina qué obligaciones corresponden a qué parte. Una organización que solo es usuaria tiene responsabilidades distintas a una organización que actúa de hecho como proveedor. Lo que se espera exactamente de cada rol se describe en otro lugar; aquí se trata del mecanismo que determina qué rol es aplicable, y de señalar el momento en que ese mecanismo produce un resultado distinto al anterior.
Un rol no está vinculado a un sistema durante toda su vida útil. Está vinculado a lo que efectivamente ocurre en un momento determinado. Esto significa que la misma organización puede encontrarse en un rol distinto para el mismo sistema en dos momentos diferentes. Algunas situaciones en las que esto ocurre: un equipo que ajusta mediante fine-tuning un modelo adquirido con datos propios, un departamento que reetiqueta un sistema y lo ofrece bajo su propio nombre a otros departamentos, o una organización que distribuye a un cliente o socio un sistema originalmente destinado al uso interno. En cada uno de estos casos, el rol efectivo se desplaza, aunque en el exterior cambie poco.
Lo que cambia en la práctica no es abstracto. Determina quién es responsable de la documentación, quién debe demostrar que un sistema hace lo que afirma hacer, y quién debe responder si algo sale mal. Más información sobre qué cambia exactamente cuando se modifica un modelo se describe en la página sobre modificaciones a un modelo. Este desplazamiento es uno de los ejemplos más claros de cómo un rol se modifica sin que le preceda una decisión consciente.
La razón por la que este tema es relevante no solo desde el punto de vista jurídico, sino también organizativo, es que un cambio de rol a menudo pasa desapercibido. Un equipo que ajusta un modelo piensa en una mejora técnica, no en un cambio de responsabilidad. Un departamento que traslada una herramienta a otro departamento piensa en la comodidad, no en un nuevo rol como proveedor. La gobernanza que solo observa lo que se ha adquirido pasa por alto estos desplazamientos de forma sistemática.
Esto se relaciona con la pregunta de qué aplicaciones caen exactamente dentro de una normativa y cuáles no; ese límite se trata en la página sobre el alcance de las aplicaciones. Un sistema que quedaba fuera del alcance en el momento de su adquisición puede entrar dentro del alcance en cuanto el rol de la organización cambie. Esto hace que no baste con evaluar una sola vez en el momento de la compra; la evaluación debe adaptarse a lo que efectivamente ocurre con un sistema.
También el nivel de riesgo de una aplicación puede modificarse con un cambio de rol. Lo que significa exactamente un nivel de riesgo alto para las obligaciones de una organización, y de qué depende esto, se explica en la página sobre las consecuencias de un nivel de riesgo alto. Una organización que, debido a un cambio de rol, pasa repentinamente a ser considerada proveedor de un sistema con un nivel de riesgo alto, asume responsabilidades distintas a las que tenía cuando solo era usuaria de ese mismo sistema.
Para detectar los cambios de rol antes de que se conviertan en un problema, una organización debe saber qué sistemas existen, quién los modifica, y quién los distribuye a quién. Esto requiere un inventario que vaya más allá de la lista aprobada por TI, y un lugar fijo donde se registren las decisiones sobre modificación, distribución y reetiquetado. Este lugar fijo, y las preguntas correspondientes, se describen en la página sobre un registro de decisiones de supervisión.
El Responsible AI Scan está diseñado para hacer visibles estos desplazamientos: qué sistemas están efectivamente en funcionamiento, quién los utiliza, quién los ha modificado, y qué rol se deriva de ello en este momento. La herramienta que da soporte a esto está en desarrollo; quien desee utilizarla puede inscribirse en la lista de espera.
Un cambio de rol no afecta solo a la gobernanza. Cuando un sistema pasa de ser una herramienta puntual a algo que asume estructuralmente una parte de una tarea, también cambia la cuestión de cuánto trabajo realiza en realidad ese sistema y cuánto sigue estando en manos de las personas. El escáner de trabajo de FTE TO AI calcula por tarea qué parte del trabajo puede ser asumida por la IA, y hace así visible dónde un cambio de rol en la gobernanza coincide con un desplazamiento efectivo en la distribución del trabajo.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.