Artículo · Visión y estrategia
El operating model con IA: quién es dueño de qué cuando ejecutan los agentes
El operating model con IA no es el mismo modelo con una herramienta nueva encima. Cuando parte del trabajo lo ejecutan agentes, cambian cuatro cosas de raíz: quién es dueño de qué, cómo se decide y se escala, dónde viven los controles y alrededor de qué se organiza la gente. Este artículo trata la versión organizativa de ese cambio (personas, responsabilidades y gobierno), no la técnica de codificarlo, que es un trabajo distinto.
Aviso de entrada para no confundir dos cosas que suenan igual: aquí hablo del modelo operativo como diseño de la organización. La idea de convertir ese modelo en definiciones que un agente ejecuta directamente la desarrollo en el modelo operativo como código. Son capas complementarias: una decide quién responde de qué, la otra hace ejecutable lo que se decide. Este texto se queda en la primera.
El problema que el modelo tradicional no resuelve
En una organización clásica, el trabajo se reparte por tareas y por departamentos. Una persona hace su parte, la pasa a la siguiente, y la responsabilidad del conjunto queda difusa: si un pedido tarda, la culpa se reparte entre ventas, almacén y facturación, y nadie responde del proceso entero.
Ese reparto por tareas funcionaba mientras las tareas las hacían personas que se coordinaban por hábito y correo. En el momento en que un agente ejecuta un proceso de punta a punta, la difusión de responsabilidad deja de ser tolerable. El agente no “sabe” a quién preguntar cuando algo no encaja. Necesita reglas explícitas y un responsable que las fije. La ambigüedad que la organización toleraba se vuelve un fallo operativo.
Quién es dueño de qué
El cambio central del operating model con IA es separar cuatro propiedades que antes vivían mezcladas. En los despliegues que acompaño, obligo a nombrar un responsable para cada una, y son personas o funciones distintas.
| Propiedad | Qué incluye | Quién suele ser dueño |
|---|---|---|
| Proceso | Las reglas de negocio, las excepciones, el límite entre agente y persona | Un dueño de proceso, del lado del negocio |
| Resultado | Que el proceso cumpla su función y sus métricas | El responsable de la función (finanzas, operaciones, servicio) |
| Sistema | Que los agentes funcionen, se mantengan y pasen sus evaluaciones | El operador técnico, interno o contratado |
| Datos | Qué se puede leer y escribir, con qué permisos y bajo qué normativa | El dueño del dato y el responsable de cumplimiento |
La confusión más cara que veo es juntar proceso y sistema en la misma persona. Son trabajos opuestos: el dueño del proceso conoce el negocio y decide las reglas, y el operador técnico mantiene la máquina que las ejecuta. Cuando una sola persona carga con ambos, o se descuida el negocio o se descuida el sistema, y normalmente los dos.
La propiedad del proceso es la que más empresas olvidan asignar, porque antes no existía: el proceso vivía repartido. Esa figura nueva, la del dueño de un proceso que ahora ejecutan agentes, es uno de los roles que gana peso con este cambio, y la describo con detalle en agentes y futuro del trabajo.
Cómo se decide y se escala
Con agentes en la operación, las decisiones se ordenan en tres planos, y conviene no mezclarlos.
Decisión de negocio. Qué puede hacer el agente solo, qué escala a una persona, qué está prohibido. La toma el dueño del proceso. No es una decisión técnica: es dónde pones el límite del riesgo que aceptas, y de las importantes.
Decisión de excepción. El caso concreto que el agente no supo resolver y escaló. Lo resuelve la persona designada para esa clase de caso, con el contexto que el sistema le prepara. Cada excepción es, además, una señal: si un tipo de caso escala mucho, falta una regla que alguien debe decidir.
Decisión de escala. Cuándo un proceso que funciona en un equipo se extiende a otros, o cuándo se relaja el control humano porque los datos demuestran fiabilidad. Esta la toma la dirección, con evidencia de la operación delante, no por intuición.
Separar estos tres planos evita el error habitual: que un problema de negocio se trate como un fallo técnico, o que una decisión de riesgo la tome por defecto quien mantiene el sistema porque nadie más la ha asumido.
Dónde viven los controles
En el modelo tradicional, el control es la supervisión de un jefe y la revisión posterior. Con agentes, el control tiene que estar en el propio diseño del proceso, no en la vigilancia humana constante, porque un agente puede repetir un error a una escala que ninguna persona alcanza.
Los controles viven en tres sitios: en los permisos (qué puede leer y escribir cada agente, qué tiene prohibido), en las evaluaciones (la medición de calidad antes de dar trabajo real y de forma continua) y en las trazas (el registro de cada acción, para poder auditar qué pasó y por qué). Ninguno es opcional en un proceso que toca dinero o clientes. El marco completo de gobierno, con quién responde de cada control, lo trato en gobernanza de agentes.
Lo relevante para el operating model es que estos controles crean trabajo nuevo de supervisión que hay que asignar a alguien. No se supervisa como se supervisaba a un equipo humano. Se revisan muestras, se leen trazas y se ajustan umbrales. Es una función, no un gesto de buena voluntad.
El organigrama se redibuja alrededor de procesos
La consecuencia estructural es la más profunda y la más lenta. Cuando el trabajo se organiza por tareas repartidas entre departamentos, el organigrama refleja esa división. Cuando una parte del trabajo la ejecutan agentes de punta a punta, la unidad natural deja de ser la tarea y pasa a ser el proceso completo, con su dueño, su resultado y sus controles.
Eso no significa disolver los departamentos de un día para otro. Significa que aparecen responsables de proceso que cruzan las fronteras departamentales antiguas, porque un proceso como el del pedido al cobro atraviesa ventas, almacén y finanzas. La organización empieza a tener dos ejes: el funcional de siempre y el de los procesos operados por agentes. Gestionar esa doble estructura sin que se pisen es parte del rediseño.
Este rediseño es lo que distingue a una empresa que solo usa IA de una que ha cambiado su forma de operar. El marco completo está en organización AI-first. Y el terreno concreto donde estos procesos se despliegan primero lo trato en agentes de IA en operaciones. Para situar todo dentro de la adopción general, el punto de entrada es el artículo pilar sobre agentes de IA para empresas.
Preguntas frecuentes
¿Qué es el operating model con IA?
Es el diseño de cómo funciona la organización cuando parte del trabajo lo ejecutan agentes: quién es dueño del proceso, del resultado, del sistema y de los datos; cómo se decide y se escala; dónde viven los controles; y alrededor de qué se organiza la gente. Es diseño organizativo, no una herramienta.
¿En qué se diferencia del modelo operativo como código?
Este trata la capa organizativa: personas, responsabilidades y gobierno. El modelo operativo como código trata de convertir esas reglas y excepciones en definiciones que un agente ejecuta directamente. Uno decide quién responde de qué, el otro hace ejecutable lo decidido. Se complementan.
¿Quién debería ser dueño de un proceso operado por agentes?
Alguien del lado del negocio que entienda las reglas y el riesgo, no el equipo técnico que mantiene el sistema. Juntar ambas propiedades en una persona es el error más caro: son trabajos opuestos y uno de los dos se descuida. El dueño del proceso fija las reglas. El operador técnico ejecuta y mantiene.
¿Hay que reorganizar toda la empresa a la vez?
No, y hacerlo sería temerario. El organigrama se redibuja proceso a proceso: aparece un dueño para el primer proceso operado por agentes, luego para el siguiente, y la estructura por procesos convive con la funcional durante años. El cambio se mide en años porque avanza por evidencia, no por decreto.