En muchas organizaciones existe una lista fija de aplicaciones que "quedarían fuera del ámbito". Una sugerencia de texto en un procesador de textos, un filtro de spam, un chatbot que solo responde en base a una FAQ fija. La suposición es que estas aplicaciones son demasiado pequeñas, demasiado antiguas o demasiado inocuas como para caer bajo la gobernanza. Esa suposición a veces es correcta. No siempre es correcta, y rara vez lo sigue siendo con el tiempo.
Que algo quede fuera del ámbito no es una característica de la tecnología. Es una clasificación que se deriva de lo que hace el sistema, para quién, y con qué efecto si algo sale mal. La misma sugerencia de texto que hoy queda fuera del ámbito porque solo propone una palabra a un empleado, puede caer dentro del ámbito mañana en cuanto redacte y envíe correos automáticamente sin intervención.
Tres factores determinan conjuntamente si una aplicación cae dentro o fuera del ámbito.
El primero es la función: ¿toma el sistema una decisión, o solo proporciona información que evalúa una persona? Una herramienta que clasifica a candidatos está más cerca del ámbito que una herramienta que solo hace que los currículums sean consultables. En qué punto exacto de ese espectro se sitúa una aplicación y por qué, puede leerlo en el análisis de qué significa un nivel de riesgo alto para su organización.
El segundo es el papel de la propia organización. Quien compra un sistema y lo usa sin modificarlo se encuentra en una posición distinta a quien lo construye, entrena o adapta él mismo. Esa misma aplicación puede quedar fuera del ámbito para una organización y no para otra, únicamente en función de quién asume qué responsabilidad. Esta distinción se desarrolla en la pregunta de si usted es proveedor o usuario, y cambia en cuanto alguien en la organización adapta o vuelve a entrenar un modelo, como se describe en qué cambia cuando usted mismo adapta un modelo.
El tercer factor es el tiempo. Un sistema que ahora queda fuera del ámbito puede dejar de estarlo un año después, no porque las normas hayan cambiado, sino porque el uso cambió. Un chatbot que empezó como fuente de información puede convertirse en un sistema que gestiona quejas. El papel de un equipo o departamento respecto a ese sistema se desplaza entonces también, y cuándo ocurre eso está descrito en cuándo cambia su papel y de qué depende eso.
La consecuencia de estos tres factores es que "fuera del ámbito" nunca es un estatus permanente. Es una fotografía del momento que debe revisarse en cuanto cambia la función de un sistema, en cuanto la organización adquiere un papel distinto respecto a ese sistema, o en cuanto el uso se amplía hacia algo que no estaba previsto en el momento de la adquisición.
Es precisamente aquí donde la IA en la sombra distorsiona la clasificación. Una aplicación que en la lista de TI figura como "fuera del ámbito" puede usarse en la práctica de una manera que ya no corresponde a esa clasificación. Un equipo que utiliza un modelo de lenguaje para redactar borradores de comunicación con clientes quizá también lo use para enviar respuestas definitivas sin informar de ello. La clasificación sobre el papel y el uso en la práctica se desvían entonces, y quien solo mira las licencias adquiridas no ve esa diferencia.
La única manera de tener visión sobre esto es preguntar. No a un sistema, sino a las personas que lo usan. Eso solo funciona si preguntar no equivale a rendir cuentas: quien teme las consecuencias adapta su respuesta o no la da. Una clasificación que se basa exclusivamente en las licencias adquiridas pasa por alto, por tanto, de forma sistemática las aplicaciones surgidas del uso práctico, y esas son precisamente, a menudo, las aplicaciones de las que ya nadie sabe si siguen fuera del ámbito o si ya están muy dentro de él.
La pregunta "¿esto queda fuera del ámbito?" no puede responderse, por tanto, de forma aislada de la pregunta de qué ocurre exactamente, quién decide sobre ello, y desde cuándo es así esa situación. Un inventario que registre estos tres factores por aplicación produce una clasificación que corresponde a la situación real en lugar de a la suposición con la que un sistema fue adquirido en su momento. Qué requiere atención ya ahora y qué puede planificarse con calma depende de los mismos factores y se aborda en la distinción entre lo que debe hacerse ahora y lo que puede planificarse.
En cuanto queda claro qué aplicaciones caen dentro del ámbito y qué papel desempeña su organización en ellas, surge una pregunta de seguimiento que no trata de gobernanza sino de trabajo: ¿qué parte de una tarea asume realmente esa aplicación, y qué parte sigue siendo trabajo humano? Esa pregunta no la responde el escáner de gobernanza. Para eso está pensado el escáner de trabajo de FTE TO AI, que calcula por tarea qué parte del trabajo puede asumir la IA, ofreciendo así una imagen del esfuerzo que se esconde detrás de la clasificación.
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.