Un equipo que trabaja con inteligencia artificial de forma sostenida no está usando una herramienta: está operando un loop de cinco etapas —encuadre, ejecución asistida, verificación, captura y poda—. La distinción no es semántica. Explica por qué dos empresas con la misma licencia obtienen resultados incomparables, y por qué tantos despliegues se apagan solos a los tres meses sin que nadie tome la decisión de apagarlos. Este artículo describe las cinco etapas, la regla que decide qué tarea entra y las razones concretas por las que casi todos los equipos se detienen en la segunda.
Qué es el loop de trabajo con IA
El loop es el ciclo completo por el que pasa una tarea cuando un equipo trabaja con IA en serio. Se llama loop, y no proceso, porque no termina en la respuesta del modelo: termina cuando lo que funcionó queda disponible para la próxima vez y lo que no funcionó sale del flujo.
La versión que se ve en la mayoría de las empresas es mucho más corta: una persona pide algo, recibe un texto, lo pega y sigue. Eso no es un loop, es un atajo individual. Funciona para quien lo descubrió, no se puede auditar, no mejora con el tiempo y desaparece cuando esa persona cambia de puesto.
La diferencia práctica entre ambas es que el loop acumula: cada vuelta deja al equipo algo que no tenía. El atajo no deja nada.
Etapa 1 · Encuadre: qué tarea entra al loop
Una tarea entra al loop cuando cumple tres condiciones a la vez: es repetible —ocurre varias veces al mes, no una vez al año—, su resultado es comprobable por alguien en un tiempo razonable, y tiene un dueño identificable que responde por ella.
Las tres importan, pero la que más se salta es la tercera. Una tarea sin dueño no se verifica, y una tarea que no se verifica no está en el loop: está suelta.
El error de encuadre más común es empezar por la tarea más impresionante en lugar de por la más frecuente. La tarea impresionante se demuestra bien en una reunión y no cambia la semana de nadie; la frecuente y aburrida es la que devuelve horas. Un buen encuadre inicial suele parecer decepcionantemente pequeño, y esa es justamente la señal de que está bien elegido.
Etapa 2 · Ejecución asistida: qué parte se delega de verdad
En esta etapa la persona delega la parte mecánica y conserva el criterio. La IA redacta el primer borrador, extrae los datos de veinte documentos, propone la estructura o traduce el formato; la persona decide si eso responde al problema real.
Es la etapa que todo el mundo entiende y donde casi todo el mundo se queda. Es cómoda porque el beneficio es inmediato y visible: lo que tardaba cuarenta minutos tarda ocho. También es la etapa donde el beneficio es individual y no acumulativo —cada persona resuelve lo suyo a su manera— y donde aparece el primer riesgo serio: todo lo que el sistema lee para trabajar es entrada no confiable, y un documento ajeno puede traer instrucciones dirigidas al modelo[3].
Delegar la ejecución sin las etapas siguientes produce equipos rápidos y desiguales. Es mejor que nada, y es mucho menos de lo que parece cuando se mide a los tres meses.
Etapa 3 · Verificación: la etapa que decide si el loop vale la pena
Verificar es comprobar el resultado contra algo que no sea el propio sistema que lo produjo: la fuente original, un dato de la empresa, el criterio de la persona responsable. No es leer la respuesta y encontrarla convincente; una respuesta bien escrita y equivocada es exactamente el modo de fallo que hay que atrapar.
Esta es la etapa que separa a los equipos que sostienen el trabajo con IA de los que lo abandonan, y es la que casi nadie asigna. No tiene misterio técnico: tiene un coste, y ese coste hay que ponerlo en el presupuesto de la tarea, no descontarlo del entusiasmo.
Cuando la verificación no existe, pasa siempre lo mismo en este orden: primero todo va bien, después alguien detecta un error que llegó lejos, y a continuación el equipo deja de confiar en todo el flujo por un fallo puntual. La confianza se pierde de golpe y se recupera despacio.
Etapa 4 · Captura: de truco personal a activo del equipo
Capturar significa que la instrucción que funcionó queda escrita, versionada y disponible para todos, junto con lo que hay que comprobar en su resultado. Deja de ser el truco de alguien y pasa a ser una pieza del equipo.
Es la etapa que convierte el loop en algo que mejora en lugar de repetirse. La primera vez que se resuelve una tarea cuesta una hora de tanteo; a partir de la captura, cuesta la ejecución. Sin captura, cada persona nueva vuelve a pagar esa hora, y cada rotación borra lo aprendido.
Aquí es donde la obsesión por la ingeniería de prompts se ordena sola: lo que sostiene el resultado no es la técnica de redacción individual, sino que el encuadre bueno esté guardado donde el equipo lo encuentra. Un texto mediano compartido rinde más que uno excelente que vive en la cabeza de una persona.
Etapa 5 · Poda: qué sale del loop
Podar es sacar del flujo lo que dejó de compensar, y es parte del método, no un fracaso. Una tarea sale cuando el proceso cambió y ya no aplica, cuando la verificación empezó a costar más que la ejecución, o cuando el resultado dejó de usarse aunque se siga generando.
Esa última es la más silenciosa y la más cara: informes que nadie abre, resúmenes que nadie lee, correos que se generan por inercia. Cuestan dinero y, sobre todo, cuestan credibilidad, porque el equipo aprende que el flujo produce cosas que no importan.
Decir en voz alta que una tarea sale del loop es lo que mantiene la confianza en las que quedan. Un flujo del que nunca sale nada no es un flujo maduro: es uno que nadie está mirando.
La regla que ordena todo: el coste de verificar
La regla es una sola frase: si verificar el resultado cuesta más que hacer la tarea a mano, esa tarea no entra al loop. No es una recomendación de prudencia, es aritmética, y resuelve la mayoría de las discusiones sobre qué automatizar antes de tenerlas.
| Relación entre verificar y hacer | Qué hacer con la tarea |
|---|---|
| Verificar cuesta mucho menos que hacer | Entra al loop; es el caso ideal |
| Verificar cuesta algo menos que hacer | Entra, pero con el tiempo de verificación asignado por escrito |
| Verificar cuesta lo mismo que hacer | No entra todavía: primero hay que hacer el resultado más comprobable |
| Verificar cuesta más que hacer | No entra; automatizarla traslada el trabajo, no lo reduce |
La consecuencia interesante es que una tarea puede volverse elegible sin cambiar la IA: basta con hacer su resultado más fácil de comprobar —pedir que cite la fuente, que devuelva un formato fijo, que señale lo que no encontró—. Eso es exactamente lo que hacemos en nuestras propias plataformas, y la razón de que publiquemos cómo medimos la tasa de error y con qué método.
Los tres estados de una tarea
Una tarea dentro del loop está siempre en uno de tres estados, y conviene que el equipo sepa cuál:
- Manual: la hace una persona. Sigue siendo una respuesta legítima y para muchas tareas es la correcta.
- Asistida: la IA produce el borrador, una persona decide. Es donde vive la mayor parte del trabajo real de oficina.
- Delegada con compuerta: el sistema la ejecuta de principio a fin, pero las acciones irreversibles pasan por aprobación humana.
El error caro es saltar de manual a delegada sin pasar por asistida, porque se delega una tarea cuyo resultado nadie ha aprendido todavía a comprobar. Cuando la tarea implica que el sistema actúe sobre otros sistemas —escribir, enviar, mover registros—, la conversación deja de ser de productividad y pasa a ser de control: es el terreno de los seis controles que exigir a un agente en producción.
Por qué casi todos los equipos se detienen en la etapa 2
Porque las etapas 1, 3, 4 y 5 son trabajo de organización y la 2 es trabajo de herramienta. Comprar una licencia es una decisión; asignar quién verifica, dónde se guarda lo que funcionó y quién decide qué sale del flujo son cinco conversaciones incómodas con nombres propios.
Por eso los despliegues que fracasan rara vez fracasan por la tecnología. Fracasan porque nadie era dueño del flujo, porque la verificación no estaba en el tiempo de nadie, o porque lo aprendido nunca salió de la cabeza de dos personas entusiastas. La literatura de adopción organizacional lleva años describiendo el mismo patrón en otras tecnologías[5] [4], y el marco de gestión de riesgo de IA lo formaliza al poner el gobierno —quién responde de qué— antes que la medición[1].
En Innova y Cree operamos 12 plataformas con IA en producción, y el patrón se repite dentro: lo que sostiene el trabajo no es el modelo del mes, es que cada tarea tenga dueño, criterio de comprobación y un lugar donde se guarda lo que salió bien.
Cómo empezar el lunes
Con una sola tarea, no con un plan. Se elige la más frecuente y aburrida de las que cumplen las tres condiciones del encuadre, se le pone un dueño, se escribe en una línea qué significa que el resultado esté bien y se corre dos semanas midiendo dos cosas: cuánto se tardaba antes y cuánto se tarda en verificar ahora.
Al final de esas dos semanas hay una decisión honesta que tomar —sigue, se ajusta o sale— y, sobre todo, hay una instrucción guardada. Esa instrucción es el primer activo del loop. La segunda tarea entra cuando la primera ya se hace sin discutirla.
Empezar por diez tareas a la vez parece más ambicioso y produce el resultado contrario: cuando algo mejora, nadie sabe qué lo causó, y cuando algo falla, se culpa a la IA en general. Un loop que funciona con una tarea se extiende solo; diez loops que nadie verifica se apagan juntos.