¿Quién responde cuando un algoritmo influye en una contratación, ascenso o despido?

Una candidata queda fuera del proceso porque una plataforma le asigna una puntuación baja. Un empleado no recibe el ascenso porque un modelo estima que su perfil no se parece al de quienes tuvieron éxito antes. Una supervisora acepta la recomendación porque el sistema fue comprado por la empresa, validado por el proveedor y presentado como una herramienta objetiva. Cuando la persona afectada pregunta quién tomó la decisión, comienza una cadena conocida: Recursos Humanos señala al algoritmo; la dirección, al proveedor; el proveedor, a los datos y a la configuración del cliente.

Esa cadena tiene un problema elemental: un sistema no puede asumir responsabilidad moral, laboral ni jurídica. Puede ordenar solicitudes, producir una predicción o recomendar una acción, pero no explica por sí solo qué objetivo era legítimo, qué errores eran aceptables ni quién debía detener el proceso. La responsabilidad no desaparece al automatizar una decisión; se distribuye entre más actores y, por eso mismo, necesita hacerse explícita.

El reto no consiste en encontrar a una sola persona culpable de todo. Consiste en impedir que las responsabilidades fragmentadas se conviertan en irresponsabilidad organizada. Para ello conviene distinguir quién define el propósito, quién construye o configura el sistema, quién controla sus resultados, quién decide en cada caso y quién puede reparar el daño.

La decisión empieza antes de que el algoritmo produzca una puntuación

La frase “lo decidió el algoritmo” oculta varias decisiones humanas previas. Alguien eligió qué problema resolver, qué población observar, qué resultado considerar deseable y qué datos usar como sustitutos de capacidades difíciles de medir. También se decidió cuánto costaría un falso positivo, cuánto un falso negativo y qué parte del proceso quedaría abierta a revisión.

En contratación, por ejemplo, “probabilidad de buen desempeño” no es una cualidad que aparezca intacta dentro de una base de datos. Debe traducirse a indicadores: permanencia, evaluación del jefe, ventas, velocidad, asistencia u otra variable disponible. Esa traducción incorpora una teoría del trabajo, aunque nadie la llame así. Si el desempeño histórico estuvo condicionado por oportunidades desiguales, estilos de dirección o evaluaciones sesgadas, el modelo puede aprender ese pasado y presentarlo como pronóstico.

La revisión de Köchling y Wehner sobre discriminación algorítmica en selección y desarrollo de personal muestra que el riesgo no se limita a una tecnología concreta. Puede aparecer en los datos, en las variables, en el diseño del modelo y en la forma de aplicar sus resultados. La evidencia no permite afirmar que toda herramienta algorítmica discrimine, pero sí invalida la idea de que automatizar vuelve neutral una decisión.

Cathy O’Neil popularizó una advertencia relacionada en Weapons of Math Destruction: los modelos adquieren especial poder cuando son opacos, operan a escala y afectan oportunidades importantes. El libro no ofrece una norma técnica para auditar sistemas de empleo, pero aporta una pregunta útil: ¿la persona evaluada puede comprender, cuestionar y corregir una decisión que influye en su vida?

Cuatro responsabilidades que no deben confundirse

Para evitar la búsqueda tardía de un único culpable, una organización puede separar cuatro responsabilidades desde el diseño y la compra.

1. Responsabilidad por el propósito

Corresponde a la dirección y al área que encarga el sistema. Deben justificar por qué hace falta automatizar, qué beneficio concreto se busca y qué usos quedan prohibidos. No basta con decir que la herramienta ahorra tiempo. También debe comprobarse si el objetivo es compatible con la dignidad, la igualdad de oportunidades y las obligaciones laborales de la organización.

Esta responsabilidad incluye decidir si una aplicación merece existir. Un modelo técnicamente preciso puede ser improcedente si intenta inferir rasgos íntimos, emociones o intenciones con evidencia insuficiente, o si su uso crea una vigilancia desproporcionada. Comprar una función disponible no equivale a tener una razón legítima para usarla.

2. Responsabilidad por el sistema

El proveedor debe documentar el funcionamiento relevante, las poblaciones y condiciones de validación, los datos utilizados, las métricas, las limitaciones conocidas, los cambios de versión y los mecanismos de supervisión. La organización compradora, sin embargo, no puede delegar en el contrato toda su responsabilidad. Debe evaluar si esa evidencia corresponde a su contexto, población, idioma y proceso de trabajo.

Una demostración comercial no sustituye una validación. Tampoco basta una cifra global de precisión: dos sistemas con igual promedio pueden distribuir sus errores de manera distinta entre grupos y producir consecuencias muy diferentes. La evidencia debe relacionar el rendimiento técnico con el uso real y con el daño que cada tipo de error puede causar.

3. Responsabilidad por la decisión concreta

Recursos Humanos y la persona con autoridad formal deben saber cuándo pueden aceptar, cuestionar o rechazar una recomendación. “Humano en el circuito” no es una garantía si esa persona carece de tiempo, información, competencia o libertad para discrepar. Un clic de confirmación puede ser una formalidad que legitima automáticamente lo que propone el sistema.

La revisión humana debe ser significativa: acceso a los factores relevantes, conocimiento de las limitaciones, posibilidad real de pedir información adicional y obligación de dejar constancia cuando el caso se aparta de lo esperado. También necesita controles contra el sesgo de automatización, la tendencia a conceder más autoridad a una salida porque parece matemática.

4. Responsabilidad por el control y la reparación

Una función independiente —auditoría, cumplimiento, riesgo, ética o un comité con autoridad efectiva— debe revisar el sistema durante todo su ciclo de vida. Su tarea no termina al autorizar la compra. Los datos cambian, la población cambia, el proveedor actualiza el producto y los usuarios encuentran usos que el diseño original no anticipó.

Quien resulte afectado necesita una vía comprensible para saber que intervino un sistema automatizado, solicitar revisión, aportar contexto y corregir datos. Debe existir además una respuesta definida: rectificar una decisión, repetir una evaluación, suspender el uso, reparar un perjuicio o escalar el caso. Una apelación sin plazo, autoridad ni remedio posible es solo un formulario.

La regulación ofrece un piso, no un sistema de gobierno completo

El Reglamento de Inteligencia Artificial de la Unión Europea clasifica como de alto riesgo determinados sistemas usados en empleo, gestión de trabajadores y acceso al autoempleo, incluidos algunos destinados a selección, decisiones que afectan condiciones laborales, promoción o terminación. Esa clasificación activa obligaciones sobre gestión de riesgos, datos, documentación, registros, transparencia, supervisión humana, precisión y robustez. Su alcance y calendario de aplicación deben revisarse para cada caso; citar el reglamento no demuestra automáticamente cumplimiento.

El marco de gestión de riesgos de IA del NIST aporta otra perspectiva. Organiza el trabajo alrededor de cuatro funciones —gobernar, mapear, medir y gestionar— y subraya que la gestión de riesgos es continua y sociotécnica. El marco es voluntario y no reemplaza la ley, pero ayuda a evitar una auditoría reducida a probar el modelo una vez.

La investigación de Raji y sus colegas sobre auditoría algorítmica interna propone precisamente integrar controles a lo largo del ciclo de desarrollo. Su aporte importante no es una lista universal, sino la idea de que la rendición de cuentas requiere estructuras institucionales, documentación y puntos de intervención. Una auditoría tardía no puede corregir con facilidad un objetivo mal definido o datos cuya procedencia nunca se registró.

Una matriz sencilla para repartir la responsabilidad

Antes de desplegar un sistema para contratar, ascender, evaluar o despedir, la organización puede responder por escrito seis preguntas. Cada respuesta debe nombrar una función y una persona responsable, no “la empresa” en abstracto.

1. ¿Quién aprueba el propósito? Define el problema, el uso permitido, los usos prohibidos y el criterio para decidir que la automatización no aporta suficiente valor.
2. ¿Quién demuestra la idoneidad? Reúne la evidencia técnica y contextual, comprueba el rendimiento por grupos pertinentes y documenta los límites.
3. ¿Quién posee los datos? Responde por procedencia, calidad, actualización, pertinencia, acceso y corrección.
4. ¿Quién toma la decisión individual? Tiene autoridad y recursos para apartarse de la recomendación, explica el criterio y registra el resultado.
5. ¿Quién vigila el sistema? Revisa errores, quejas, cambios, usos inesperados y señales de impacto desigual, con capacidad para suspenderlo.
6. ¿Quién repara? Atiende a la persona afectada, corrige datos o decisiones y garantiza que el aprendizaje modifique el proceso.

Esta matriz puede complementarse con una separación entre responsable y consultado. El proveedor será consultado sobre el modelo, pero no debería decidir por sí solo si el riesgo residual es aceptable para los trabajadores de su cliente. Recursos Humanos conoce el proceso, pero necesita a tecnología, asuntos jurídicos, representantes de trabajadores y especialistas en igualdad cuando corresponda. La participación no diluye la autoridad: mejora la información con la que se ejerce.

Controles prácticos antes, durante y después

Antes del uso, conviene realizar una evaluación de impacto que describa afectados, beneficios, daños previsibles, alternativas menos intrusivas y condiciones de suspensión. Debe probarse el sistema con datos representativos del contexto de aplicación, verificar la accesibilidad y revisar si alguna variable funciona como sustituto problemático de características protegidas.

Durante el uso, hay que registrar versiones, entradas relevantes, salidas, intervención humana y resultado final. El registro no debe convertirse en recopilación ilimitada: debe respetar minimización, seguridad y plazos de conservación. También conviene muestrear decisiones, comparar patrones de error y observar no solo tasas agregadas, sino quejas, excepciones y casos cercanos al umbral.

Después de la decisión, la organización debe ofrecer explicación suficiente para que la persona pueda actuar. Explicar no significa revelar código fuente ni fabricar una historia simple sobre un modelo complejo. Significa comunicar qué función tuvo el sistema, qué información fue relevante, quién decidió, qué límites existen y cómo solicitar una revisión efectiva.

Hay además una prueba organizacional muy concreta: si nadie tiene autoridad para detener el sistema cuando aparecen dudas razonables, el gobierno es decorativo. Un protocolo serio define umbrales de pausa, responsables de investigación y condiciones para reanudar. La continuidad operativa no puede imponerse siempre sobre el derecho a revisar una decisión de alto impacto.

Preguntas que conviene hacer a un proveedor

• ¿Para qué usos y poblaciones se validó la herramienta, y cuáles quedan expresamente fuera?
• ¿Qué resultado predice, cómo se definió y qué evidencia relaciona esa variable con el trabajo real?
• ¿Cómo se distribuyen falsos positivos y falsos negativos, incluidos los grupos pertinentes?
• ¿Qué datos necesita, de dónde proceden y cómo puede una persona corregirlos?
• ¿Qué cambios del modelo o de las fuentes de datos se notifican al cliente?
• ¿Qué registros, explicaciones y herramientas ofrece para una revisión humana significativa?
• ¿Permite auditoría independiente, pruebas del cliente y suspensión sin perder acceso a la evidencia?

Una respuesta confidencial puede ser razonable para ciertos detalles comerciales, pero “es propietario” no debería cerrar toda conversación sobre rendimiento, límites y consecuencias. Si la organización no recibe información suficiente para gobernar el sistema, tampoco tiene información suficiente para confiarle decisiones importantes.

Lecturas y fuentes para profundizar

Köchling y Wehner ofrecen una revisión de la discriminación algorítmica en Recursos Humanos: https://doi.org/10.1007/s40685-020-00134-w. Raji y sus colegas desarrollan un marco de auditoría interna de extremo a extremo: https://doi.org/10.1145/3351095.3372873. El texto oficial del Reglamento (UE) 2024/1689 permite revisar las obligaciones aplicables, y el AI Risk Management Framework del NIST ofrece una guía voluntaria para organizar el riesgo durante el ciclo de vida.

Como lectura crítica complementaria, Weapons of Math Destruction, de Cathy O’Neil (Crown, 2016; ISBN 978-0-553-41881-1), ayuda a reconocer por qué opacidad, escala y daño pueden reforzarse entre sí. Conviene leerlo como marco de problemas y casos, no como sustituto de una evaluación jurídica o técnica específica.

La pregunta que devuelve la decisión a la organización

La cuestión decisiva no es si el algoritmo “se equivocó” aislado del sistema social que lo rodea. Es si la organización definió quién podía prevenir el error, detectarlo, cuestionarlo y repararlo. Cuando esas funciones tienen nombre, recursos y autoridad, la automatización puede ser examinada. Cuando quedan repartidas entre contratos, departamentos y pantallas, la frase “lo decidió el sistema” se convierte en una forma de abandonar la responsabilidad.

¿En tu organización está claro quién puede detener y revisar una decisión automatizada que afecta la trayectoria de una persona?

Elaborado por Ricardo Gaibor.

Este artículo fue elaborado por Ricardo Gaibor con ayuda de sistemas de inteligencia artificial en tareas de investigación, organización y edición. La selección, interpretación y responsabilidad editorial del contenido corresponden al autor.