Dentro de un experimento de gestión con Claude en el rol de responsable de equipo, el modelo llegó a tomar la decisión de despedir a un empleado tras registrar 17 retrasos en 23 turnos. La ejecución no fue automática: el proceso requirió intervención humana para completarse. Es, hasta donde se ha hecho público, el primer caso en el que un modelo de lenguaje no propone ni recomienda, sino que emite una decisión laboral sobre una persona concreta.
Conviene poner el marco antes que el titular, porque el titular se presta a leerse peor de lo que es: hablamos de un experimento acotado, con supervisión humana en el punto final, no de una política implantada ni de una función disponible en ningún producto.
Diecisiete de veintitrés: el tipo de dato que una máquina resuelve sin dudar
El detalle que hace que este caso sea interesante, y no simplemente escandaloso, es la naturaleza del criterio. Diecisiete retrasos en veintitrés turnos es un dato numérico, verificable y sin ambigüedad. No hace falta interpretar una actitud, valorar un conflicto entre compañeros ni ponderar si alguien «encaja en el equipo». Es un contador contra un umbral.
Y ahí está justamente el punto ciego. Un modelo resuelve muy bien la parte que ya era fácil: comprobar que un número supera un límite. Lo que no aparece en ese cálculo es todo lo que un responsable humano sí tiene delante cuando abre esa conversación. Si esos retrasos coinciden con una enfermedad, con un cambio de turno mal comunicado, con un problema de transporte temporal o con una situación personal que la persona no ha querido registrar en ningún sistema. El expediente dice diecisiete; el contexto puede decir cualquier otra cosa, y el contexto casi nunca está en los datos que ve el modelo.
Esto no es un defecto de Claude ni de ningún modelo en particular. Es una propiedad de cualquier sistema que decide sobre lo que puede medir: hace visible lo cuantificable y borra lo demás. La diferencia es que, cuando el sistema redacta la decisión con lenguaje natural y tono profesional, el resultado parece un juicio ponderado aunque siga siendo una comparación aritmética.
Que hiciera falta un humano para ejecutarlo no es un tecnicismo
La parte del caso que más se va a citar mal es la de la intervención humana. Se leerá como una nota al pie tranquilizadora, cuando en realidad es la línea que separa dos mundos completamente distintos.
Un sistema que propone una decisión y espera aprobación reparte la responsabilidad de una forma conocida: alguien firma, y ese alguien responde. Un sistema que ejecuta por su cuenta rompe esa cadena y deja un hueco incómodo, porque en cualquier marco laboral serio el despido es un acto con consecuencias jurídicas y necesita un responsable identificable. En el caso que nos ocupa, la cadena se mantuvo intacta.
Un agente que propone reparte la responsabilidad; uno que ejecuta la disuelve. Toda la diferencia está en quién firma.
El riesgo real, y por eso merece la pena hablar de ello ahora, no es que un modelo despida a nadie mañana. Es la aprobación automática por costumbre: el humano que revisa cien decisiones bien fundamentadas y, hacia la ciento uno, ya solo pulsa aceptar. La supervisión existe sobre el papel y ha dejado de existir en la práctica. Ese deslizamiento no lo provoca la tecnología, lo provoca la rutina.
El salto es de ejecutar tareas a evaluar personas
Hasta ahora, casi todo lo que hemos visto en producción va en la dirección de la ejecución: agentes que escriben código, procesan documentos, clasifican correos, revisan infraestructura o publican contenido. El objeto sobre el que actúan es un archivo, un registro o un sistema. Aquí el objeto es una persona, y el resultado afecta a su empleo.
Esa frontera se cruza en muchos más sitios de los que parece, y casi siempre sin ceremonia. Un modelo que filtra currículums está evaluando personas. Uno que puntúa la calidad de atención de un agente de soporte, también. Uno que decide qué cliente entra en una lista de riesgo, igual. La diferencia con este caso es solo de visibilidad: el despido es la versión que se nota, no la única que ocurre.
Qué se lleva de aquí quien automatiza para clientes
Si construyes automatizaciones por encargo, este caso te toca antes de lo que crees, aunque nunca te acerques a recursos humanos. La lección práctica no está en el despido, está en la clasificación de tus flujos según qué consecuencia tienen.
Hay automatizaciones cuyo peor escenario es un texto mal escrito que alguien corrige en dos minutos, y ahí el modelo puede actuar solo con toda tranquilidad. Y hay otras cuyo peor escenario es una consecuencia irreversible para un tercero: cancelar un acceso, marcar a un cliente, enviar una comunicación con efecto contractual. Ese segundo grupo necesita un paso de aprobación explícito, aunque ralentice el proceso y aunque el cliente pregunte por qué no se hace todo automático.
Una nota final sobre el propio caso: por ahora se sustenta en una única cobertura y no ha sido detallado en un informe público, así que los contornos del experimento —duración, tamaño del equipo, qué datos veía exactamente el modelo— siguen sin conocerse. Lo que sí está claro es la dirección: la conversación ha pasado de qué pueden hacer los agentes a sobre quién pueden decidir, y esa segunda pregunta se responde con procesos, no con modelos.
