Un modelo que usted adquiere y utiliza sin modificar es una situación distinta a un modelo que usted ajusta (finetuning), reentrena con datos propios, o combina con otros sistemas. La pregunta que corresponde no es si eso está permitido, sino qué cambia en su rol. Esta página describe de qué depende esa clasificación. El contenido normativo actual se encuentra en otro lugar; aquí se trata del mecanismo que determina cuándo algo cambia y qué hace usted internamente con ello.
Si la modificación de un modelo cambia su rol depende de una serie de factores que debe establecer por situación, no de un límite fijo que sea igual para cada modelo.
Estos factores actúan conjuntamente. Ninguno de estos puntos es decisivo por sí solo; la combinación determina si la modificación cambia su posición.
Si la modificación es suficientemente sustancial, por lo general no cambia solo la calificación del modelo, sino también lo que se espera de la organización: otra documentación, otra responsabilidad interna, posiblemente otra parte a la que se puede exigir cuentas sobre el conjunto. Ese mecanismo, y la distinción entre una parte que solo utiliza un modelo y una parte que colabora en su configuración, está desarrollado en la página que describe la distinción entre proveedor y usuario. Cuándo exactamente una modificación es suficientemente sustancial como para hacer bascular ese rol es una pregunta que debe responderse por separado para cada sistema; el mecanismo general que subyace a ello se encuentra en la página sobre el momento en que cambia su rol.
Las consecuencias de ese vuelco dependen, a su vez, del nivel de riesgo que reciba el modelo modificado. Un modelo modificado que cae dentro de una categoría de alto riesgo conlleva obligaciones distintas de un modelo modificado que queda fuera de ella. Lo que significa en la práctica un nivel de riesgo alto para los procesos internos y la supervisión se describe en la página sobre las consecuencias de un nivel de riesgo alto para su organización. A la inversa, también es posible que una modificación mantenga precisamente a un sistema fuera de la categoría más severa, o que el ámbito de aplicación simplemente no esté sujeto a la normativa; qué aplicaciones quedan fuera del ámbito de aplicación y por qué se describe en la página sobre las aplicaciones que quedan fuera del ámbito de aplicación.
Las modificaciones a los modelos suelen ocurrir cerca del trabajo mismo: un equipo que ajusta (finetuning) un modelo externo con sus propios documentos, un desarrollador que conecta dos sistemas entre sí, un departamento que alimenta un chatbot con bases de conocimiento internas. Son precisamente esas modificaciones las que no pasan por un proceso de adquisición centralizado y, por tanto, no aparecen automáticamente en una lista de TI. Quien quiera saber si, y dónde, esto ocurre dentro de la organización, debe preguntarlo — y eso solo funciona si la pregunta no está vinculada a una sanción. Un equipo que ha modificado un modelo sin pedir permiso para ello no lo comunicará si la respuesta conlleva una sanción.
Dado que la clasificación de las modificaciones no es fija sino que se determina por situación, no basta con establecer una sola vez qué rol tiene un modelo. Las modificaciones que se realizan después de la evaluación inicial deben pasar de nuevo por las mismas preguntas. Una política que apoye esto debe describir en lenguaje sencillo cuándo debe notificarse una modificación y a quién; cómo mantener legible esa política, en lugar de que sea un texto que nadie consulta, se describe en la página sobre una política de IA que realmente se lee. Además, es importante que las decisiones sobre modificaciones — quién dio su aprobación, sobre la base de qué ponderación, con qué nivel de riesgo como resultado — queden registradas en un lugar donde puedan encontrarse. Cómo se ve ese registro en la práctica se describe en la página sobre una lista de decisiones de supervisión.
La clasificación de un modelo modificado determina qué obligaciones son aplicables, pero no dice nada sobre lo que el modelo hace en la práctica con el trabajo mismo. Para esa pregunta — qué parte de una tarea es asumida por la IA, qué parte queda a cargo de un empleado, y qué desplaza una modificación en ello — se necesita una mirada distinta a una evaluación de riesgos. El escáner de trabajo de FTE TO AI calcula, por tarea, qué parte del trabajo puede ser asumida por la IA, independientemente de la pregunta de qué normas de gobernanza son aplicables al modelo.
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.