De ejecutor a orquestador: cómo la IA está reescribiendo el trabajo del colaborador individual

Por Victor Hoang · Actualizado el 22 de septiembre de 2026

El rol de orquestador es en lo que se convierte el trabajo de un colaborador individual cuando los agentes de IA asumen una parte creciente de la ejecución. En lugar de producir directamente el resultado, la persona define el problema, redacta el brief, decide qué traspasar y verifica el resultado. Cambia "hacer el trabajo" por "responder por un trabajo que hizo alguien, o algo, más".

Eso suena a ascenso. En la práctica es un trabajo distinto, con un conjunto de habilidades más exigente, y a la mayoría de los ICs no los han formado para él.

Datos clave

• El 36% de los líderes espera que sus equipos estén gestionando agentes de IA dentro de cinco años, y el 67% de los líderes dice que ya conoce los agentes, frente al 40% de los empleados. Fuente: Microsoft, "The 2025 Annual Work Trend Index"
• En un estudio controlado con 758 consultores de BCG, quienes usaron GPT-4 en tareas dentro de la frontera de capacidad de la IA completaron un 12.2% más de tareas, trabajaron un 25% más rápido y produjeron un trabajo calificado con una calidad 40% superior a la de un grupo de control sin IA. Fuente: Harvard Business School AI Institute, "Navigating the Jagged Technological Frontier"
• En las tareas fuera de esa frontera, los mismos consultores que usaron IA tuvieron unos 19 puntos porcentuales menos de probabilidad de producir una recomendación correcta que el grupo de control, que alcanzó por sí solo un 84.5% de acierto. Fuente: Karim Lakhani, HBS, on the jagged frontier study
• El 95% de los pilotos de IA generativa en empresas no produjo ningún impacto medible en el estado de resultados, según el Project NANDA del MIT. Fuente: Fortune, reporting on MIT Project NANDA
• Un mayor esfuerzo de verificación reduce de forma medible el "sesgo de automatización", la tendencia a aceptar sin escrutinio el resultado de un sistema automatizado, incluso cuando es incorrecto. Fuente: Microsoft Research, "Overreliance on AI: Literature Review"

El trabajo no se encogió, se movió

La Frontier Firm y el auge del agent boss ya explica cómo se ve esto a nivel organizacional: el término de Microsoft para las empresas donde los agentes de IA trabajan dentro de los flujos de trabajo diarios y donde cada trabajador termina creando agentes, delegándoles tareas y gestionándolos como antes un manager gestionaba personas. Ese artículo trata de la cultura y del organigrama. Este trata de lo que le pasa a su trabajo concreto cuando eso se vuelve cierto para usted en particular.

Si escribe código, redacta textos, construye modelos o atiende tickets de soporte, una parte real del acto físico de producir ese trabajo es ahora algo que un agente puede intentar. No a la perfección, no para todo, pero sí para una porción creciente. La parte de su trabajo que antes era "conocer el dominio y producir el resultado" se está dividiendo en dos habilidades separadas: conocer el dominio y dirigir a un agente que produce un primer borrador del resultado.

El error es suponer que la segunda habilidad es una versión reducida de la primera, algo que se aprende usando una interfaz de chat durante unas semanas. No lo es. Especificar una tarea con la precisión suficiente para que un agente la ejecute bien, y luego detectar en qué falló, recurre a una parte distinta de su experiencia que la de hacer la tarea usted mismo. Los equipos humano-agente funcionan bien cuando las personas entienden esa diferencia, y mal cuando todos suponen que la competencia para hacer el trabajo se traslada automáticamente a la competencia para dirigirlo. Topologías de equipo para equipos de humanos y agentes lleva ese cambio un nivel más arriba, a dónde se ubica realmente un agente dentro de la estructura de un equipo y no solo dentro de la lista de tareas de una persona.

Qué significa realmente "orquestador"

Dos cambios definen el rol, y son fáciles de enunciar y difíciles de vivir.

De producir a especificar

El resultado principal del orquestador ya no es el entregable. Es el brief: el planteamiento del problema, las restricciones, los ejemplos de cómo se ve "terminado" y los límites de lo que el agente puede decidir por sí solo. Si el brief está mal, el resultado está mal, sin importar lo capaz que sea el modelo subyacente. Es la misma disciplina que la ingeniería de prompts, pero ampliada de una instrucción ingeniosa y puntual a una especificación duradera y reutilizable que tiene que funcionar la quinta vez y la quincuagésima, no solo la primera.

De hacer a revisar, con consecuencias reales

Revisar el resultado de un agente no es lo mismo que revisar el trabajo de un colega junior, y tratarlo así es uno de los modos de fallo más comunes. Un colega junior que no sabe algo suele decirlo, o produce algo visiblemente tosco. Un modelo capaz produce resultados seguros, bien formateados y de apariencia plausible, sean correctos o no, una brecha conocida en el sector como alucinación de la IA. El orquestador tiene que aportar el escepticismo que el propio artefacto no señalará.

Las cuatro competencias clave del rol de orquestador

1. Descomposición de problemas

Antes de entregarle una tarea a un agente, hay que dividirla en piezas lo bastante pequeñas y bien definidas como para poder comprobar qué es "correcto" y qué es "incorrecto". Una petición vaga como "mejorar este proceso" no se puede delegar a nada, ni a una persona ni a un agente. Una versión descompuesta, "identificar los tres pasos de este proceso con el tiempo de ciclo más largo y redactar una propuesta para reducir cada uno un 20%", sí. Esta era una habilidad de gestión de proyectos que practicaban sobre todo líderes y managers. Ahora es una expectativa básica para cualquiera cuyo trabajo incluya dirigir workflows agénticos.

2. Establecer el contexto

Un agente solo sabe lo que hay en su brief, en su entrenamiento y en lo que pueda recuperar. No conoce la historia política de por qué se rechazó la versión anterior de este documento, ni qué parte interesada tiene realmente poder de veto, ni que "conciso" significa algo específico en esta empresa porque el CEO odia los memorandos largos. Establecer el contexto es la práctica de externalizar el conocimiento tácito que normalmente aplicaría sin pensar, para que el agente no produzca un trabajo técnicamente correcto que falla por razones que no tenía forma de conocer. Gestionar agentes de IA como parte del equipo aborda esta misma disciplina de definición del alcance como una tarea operativa continua y no como un brief único: estándares de calidad, traspasos y rutas de escalamiento que siguen funcionando después de la primera tarea.

3. Fijar el estándar de calidad

"Suficientemente bueno" es un juicio, y hay que emitirlo antes de que empiece el trabajo, no después, o el proceso de revisión se convierte en una discusión con uno mismo sobre una meta que se mueve. Fijar el estándar significa definir qué evidencia, formato, tono y nivel de rigor debe cumplir el resultado, y hacerlo con la suficiente explicitud para que una segunda persona (o una segunda ejecución del agente) pueda comprobar el trabajo contra el mismo criterio. Los equipos que se saltan este paso tienden a revisar todo en exceso por ansiedad o a revisar todo de menos por cansancio, y ambos modos de fallo aparecen en el tipo de producción de bajo esfuerzo y alto volumen que algunos equipos han empezado a llamar workslop.

4. Saber cuándo hacerlo usted mismo

Esta es la competencia que recibe menos atención y la que más importa. El estudio de campo de BCG y Harvard Business School encontró que los consultores que usaban IA rindieron drásticamente mejor en tareas dentro de la frontera de capacidad del modelo y notablemente peor en tareas fuera de ella, y que la frontera misma es irregular: dos tareas que a un humano le parecen igual de difíciles pueden quedar en lados opuestos. Los investigadores también hallaron que los profesionales se dividían en patrones de uso distintos. Aproximadamente un tercio actuó como "centauros", trazando una línea clara entre el trabajo que le traspasaban a la IA y el que se reservaban, preservando su propio juicio en la mitad más difícil. Un grupo mucho mayor mezcló la IA en todo sin distinción. Saber ante qué categoría de tarea se está, y tener la disciplina de reservarse las piezas difíciles, ambiguas y de alto riesgo, es la decisión más difícil del rol de orquestador, porque el agente intentará la tarea de cualquier modo y rara vez avisa de que le queda grande.

Habilidad antigua del IC frente a su equivalente de orquestación

La producción directa construye el entregable; la orquestación define la tarea, delega la ejecución y verifica el resultado.

Por qué es genuinamente más difícil de lo que parece

Es tentador tratar la orquestación como estrictamente menos trabajo que hacer la tarea usted mismo. A veces lo es. Pero tres cosas la convierten en una habilidad más difícil de construir bien, no más fácil, y el mismo techo que limita a cuántas personas puede supervisar bien un manager limita cuántos agentes puede dirigir realmente un orquestador sin que la revisión se vuelva superficial; el tramo de control cuando los agentes hacen el trabajo trata ese techo directamente.

La frontera se mueve y no está señalizada

Nada en la pantalla le dice si la tarea que acaba de traspasar queda dentro o fuera de la frontera real de capacidad del modelo. La caída de 19 puntos en acierto del estudio de BCG en tareas fuera de la frontera les ocurrió a consultores que, en promedio, eran buenos en su trabajo y usaban un modelo de punta. El fallo no fue una brecha de habilidad para usar la IA. Fue un error de categoría: tratar una tarea que parecía rutinaria como si estuviera dentro de la frontera cuando no lo estaba. Desarrollar el juicio para detectarlo en su propio dominio exige práctica deliberada, no familiaridad con la herramienta.

La verificación es una carga cognitiva distinta de la producción

Producir trabajo lo mantiene dentro del problema todo el tiempo; usted nota las inconsistencias a medida que ocurren porque construye la cosa pieza por pieza. Revisar el resultado terminado de otro, humano o agente, implica reconstruir esa misma comprensión desde fuera, a menudo más rápido de lo que la construyó la primera vez. Eso es un esfuerzo cognitivo real, y saltárselo es justo la forma en que se cuelan errores que suenan convincentes. Verificar no es "menos trabajo que hacerlo". Es un trabajo distinto, y tratarlo como la opción ligera es como la orquestación sale mal en silencio.

La mayoría de las organizaciones no ha construido la habilidad a propósito

El Project NANDA del MIT encontró que la mayoría de los pilotos de IA generativa en empresas nunca produjo un retorno financiero medible, y un hilo común en los fracasos no fue el modelo, sino la ausencia del ciclo de aprendizaje organizacional necesario para usarlo bien: responsables claros, rediseño de workflows y personas que realmente supieran dirigir la herramienta y no solo acceder a ella. Las competencias del orquestador descritas arriba son ese ciclo faltante, aplicado al nivel del trabajo de una persona. Las empresas que tratan el cambio como "démosle la herramienta a la gente y que se las arregle" se saltan la formación en una habilidad nueva y esperan que la antigua se transfiera gratis.

El riesgo: convertirse en revisor de un trabajo que ya no se entiende

Hay un modo de fallo específico que conviene nombrar con claridad: un IC que delega tanta ejecución, durante tanto tiempo, que su propia fluidez práctica en el trabajo de fondo se erosiona en silencio, mientras su cargo sigue diciendo que responde por él.

Esta es la versión práctica e individual del sesgo de automatización, la tendencia bien documentada a aceptar el resultado de un sistema automatizado con menos escrutinio del que merece, sobre todo cuando ha acertado las veces suficientes como para ganarse la confianza. La investigación revisada por Microsoft encontró que un esfuerzo de verificación mayor y deliberado es una de las pocas intervenciones que lo reducen de forma fiable. Es un hábito específico y aprendible, no un rasgo de personalidad, y necesita un nombre dentro de los equipos: alguien tiene que asumir explícitamente la tarea de volver a comprobar el trabajo, en lugar de suponer que un rol llamado "revisor" lo hará suceder.

El marco del economista David Autor sobre cómo interactúa la automatización con la experiencia traza aquí una línea útil: algunas herramientas eliminan la necesidad de experiencia y otras la multiplican, y cuál de las dos se obtiene depende de cómo se use la herramienta, no de la herramienta en sí. Un orquestador que sigue haciendo personalmente el 20% más difícil del trabajo, la parte en que el modelo se equivoca, usa la IA como multiplicador de fuerza de su propio juicio. Quien ha dejado de hacer cualquier parte de ese trabajo corre el riesgo de convertirse en revisor de un dominio que ya no practica, un lugar frágil desde el cual responder. El human-in-the-loop solo significa algo si el humano en cuestión conserva la autoridad para detectar lo que está mal.

Qué le hace esto a la antigüedad y a la satisfacción laboral

La antigüedad solía medirse, en parte, por cuánto trabajo podía producir alguien personalmente y con qué rapidez. Esa medida es cada vez más ruidosa: un analista junior con un workflow de agentes bien construido puede producir ahora un volumen de primeros borradores que antes le llevaba a una persona senior toda la semana. Lo que no se reemplaza con tanta facilidad es el juicio: saber qué 20% de una tarea vale la pena hacer con cuidado a mano, reconocer cuándo la respuesta segura de un agente es errónea en silencio y fijar un estándar de calidad lo bastante preciso como para que la diferencia sea siquiera verificable. Esa es justo la experiencia que, según Autor y Thompson, se multiplica en lugar de desaparecer, y es algo más difícil de poner en un currículum que "entregué X funcionalidades" o "redacté Y informes".

La satisfacción laboral sufre un golpe relacionado que conviene nombrar con honestidad. A mucha gente le gustaba hacer el trabajo en sí, no solo responder por su resultado: el oficio a nivel de la frase, el estado de flujo de construir algo de principio a fin, el rompecabezas del modelo. La orquestación conserva la toma de decisiones y le quita gran parte de lo que se sentía como flujo. Parte de esa satisfacción puede trasladarse a lo que queda (el encuadre, las decisiones de juicio, los momentos en que aflora un problema real), pero fingir que el intercambio es neutro para todos no es honesto. La seguridad psicológica importa aquí en particular porque admitir "extraño hacer esta parte yo mismo" no debería leerse como resistencia al cambio.

Cómo deben apoyar la transición los managers

Ninguna de las cuatro competencias anteriores aparece automáticamente solo porque alguien tenga acceso a un agente. Los managers que quieran que sus equipos las desarrollen de verdad deberían:

• Enseñar la descomposición de forma explícita, igual que el onboarding enseñaba antes a manejar una herramienta concreta. Revisen juntos algunos briefs reales y señalen dónde una petición vaga esconde tres decisiones distintas.
• Proteger tiempo para la verificación, no solo tiempo para producir más. Si un agente reduce a la mitad el tiempo de redacción y el tiempo ahorrado se absorbe por completo en más volumen, nadie está comprobando nada con más rigor.
• Redefinir cómo se ve la producción "senior" en su equipo, de forma explícita, para que nadie sea medido en silencio con un estándar de volumen que ya no refleja el valor. Esto es tanto trabajo de diseño organizacional y de evaluación como de habilidades; vea cómo construir una cultura lista para la IA para la versión más amplia de este cambio.
• Construir repeticiones deliberadas de juicio, no solo de uso de la herramienta. Dé a las personas práctica detectando errores plantados en los resultados de los agentes, igual que los pilotos se entrenan con fallos simulados y no solo vuelan cuando todo funciona.
• Decir en voz alta que este es un trabajo distinto, no una versión más rápida del anterior. Nombrar la brecha de habilidades con honestidad es lo que hace seguro admitir que aún no se ha cerrado, que es la condición previa para cerrarla de verdad.

Imagine la versión bien hecha de este rol: alguien que dedica menos tiempo a teclear el primer borrador y más a decidir qué significa "correcto" antes de que el borrador exista, y que puede decirle con exactitud qué parte del resultado respaldaría con su nombre y qué parte no ha revisado lo suficiente como para confiar en ella todavía. Es un trabajo más difícil de contratar y más difícil de formar, pero es el que realmente está disponible hoy, y fingir que es el mismo trabajo con un teclado más rápido es como los equipos acaban con resultados seguros, sin revisar y con nadie del todo responsable de detectar los errores.