Las organizaciones a menudo piensan que su rol está fijado: nosotros somos usuario, el proveedor es el proveedor, y ya está. Ese supuesto con frecuencia no es correcto, o es correcto hoy pero deja de serlo mañana. El rol que tiene una organización respecto a un sistema de IA no es una característica fija de la organización. Es el resultado de lo que ocurre con el sistema: quién lo crea, quién lo adapta, quién lo introduce en el mercado y bajo qué nombre. Si cambia uno de esos factores, es posible que también cambie el rol, y con ello las obligaciones correspondientes.
Eso hace que la clasificación no sea una fotografía fija en el tiempo. Un rol que se determinó correctamente en el momento de la adquisición puede ser incorrecto un año después, sin que internamente se haya decidido nada de forma consciente.
La clasificación depende de un número limitado de factores, pero esos factores no residen todos en la parte que utiliza el sistema. Es relevante, entre otras cosas, si un sistema se ha desarrollado internamente o se ha adquirido, si el sistema adquirido se utiliza sin modificaciones o se adapta, y si la adaptación afecta al perfil de riesgo del sistema. También es relevante bajo qué nombre se presenta un sistema hacia el exterior: un sistema que se revende o se sigue desarrollando bajo una marca propia puede implicar un rol distinto al de simplemente hacer funcionar un producto externo sin modificaciones. Para conocer la frontera precisa entre esas dos posiciones, es relevante la página sobre qué cambia cuando una organización adapta ella misma un modelo adquirido, y para la cuestión básica de cuál de los dos roles principales se aplica, existe la página que explica de qué depende exactamente la elección entre proveedor y usuario.
La clasificación no es, por tanto, algo que una organización determine una sola vez y luego archive. Es una clasificación que debe reevaluarse en cuanto cambien los hechos subyacentes.
Si el rol cambia, también cambia lo que se espera de una organización. Una parte que es puramente usuaria tiene obligaciones distintas a una parte que es (co)responsable de la creación de un sistema. Eso no afecta solo al papeleo. También afecta a dónde debe residir dentro de la organización la responsabilidad sobre un sistema, quién informa sobre él y qué nivel de supervisión es adecuado.
Ese cambio repercute en la pregunta de cuánto peso debe darse internamente a un sistema. Un cambio de rol puede llevar a que un sistema que antes se consideraba manejable deba volver a evaluarse en cuanto a su nivel de riesgo, una cuestión que se trata por separado en la página sobre qué significa un nivel de riesgo alto para la organización que utiliza o proporciona el sistema. A la inversa, un cambio de rol también puede hacer que un sistema quede precisamente fuera del ámbito de aplicación de determinadas obligaciones, o que entre justo dentro de él. Qué aplicaciones exactamente quedan fuera del alcance y cuáles no, se explica en la página sobre qué tipos de aplicaciones de IA quedan fuera del alcance de las obligaciones.
Los factores que provocan un cambio de rol suelen producirse en un nivel al que la dirección, el departamento jurídico o la gestión de riesgos no tienen visibilidad automática. Un equipo que ajusta (finetunea) un modelo adquirido con sus propios datos. Un departamento que traslada un producto de chatbot externo a los clientes bajo un nombre de producto propio. Una integración que combina un modelo de un proveedor con reglas propias y que a continuación ofrece esa combinación externamente. Ninguno de esos pasos pasa automáticamente por un registro central, y la lista de herramientas aprobadas de TI normalmente no registra este tipo de cambio, porque el cambio no se reconoce como una "nueva adquisición" sino como una adaptación de algo que ya estaba aprobado.
Esa es la razón por la que los cambios de rol a menudo solo se hacen visibles cuando algo sale mal, o cuando se pide rendición de cuentas desde fuera. La pregunta "¿cuál es nuestro rol en relación con este sistema?" se responde entonces con carácter retroactivo, en un momento en que el margen para adaptar algo es menor que si la pregunta se hubiera planteado antes.
Como la clasificación puede cambiar, la distinción entre lo que requiere atención en este momento y lo que debe reevaluarse más adelante es relevante para la planificación del trabajo de gobernanza. No todo lo que implica un cambio de rol requiere una acción inmediata; una parte puede planificarse. Qué parte es esa, y qué parte no puede esperar, se trata en la página sobre qué debe abordarse ahora y qué puede planificarse para más adelante. Para un resumen compacto de la propia cuestión de la clasificación, incluyendo los puntos de inflexión más importantes, existe la página que profundiza en las circunstancias exactas en las que cambia un rol.
La pregunta de qué rol tiene una organización respecto a un sistema de IA está estrechamente relacionada con otra pregunta que rara vez recibe la misma atención: qué parte del trabajo real dentro de la organización ya la realiza la IA, está previsto que la realice, o ya se está asumiendo sin que nadie lo haya registrado. Mientras que la pregunta del rol trata sobre la responsabilidad respecto a un sistema, el escáner de trabajo de FTE TO AI trata sobre la distribución de las propias tareas: por cada tarea se calcula qué parte puede asumir la IA, independientemente del rol que la organización adopte formalmente al respecto. Ambas preguntas están relacionadas, porque un cambio en la distribución de tareas suele ser el motivo de un cambio de rol.
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.