Durante los dos últimos años, la unidad dominante del trabajo con inteligencia artificial ha sido el prompt. Escribe un prompt mejor y obtendrás una respuesta mejor. Aprende la formulación adecuada, los ejemplos adecuados, las restricciones adecuadas, el tono adecuado. La ingeniería de prompts se convirtió en la primera disciplina popular de la era de la inteligencia artificial generativa porque encajaba con la primera experiencia que la mayoría de las personas tuvo con estos sistemas: un humano, un modelo, una petición, una respuesta.
Esa fase está terminando. Un artículo reciente de Business Insider describe el auge de la “ingeniería de bucles”: la práctica de diseñar bucles que permiten a los agentes de inteligencia artificial seguir trabajando, comprobando, reintentando y coordinándose en lugar de esperar a que un humano emita manualmente cada instrucción. Los ejemplos son sobre todo técnicos: agentes de programación, agentes de revisión, subagentes, workflows automatizados. Pero el cambio es mucho más amplio que el desarrollo de software.
La unidad de valor de la inteligencia artificial se está desplazando de la respuesta al bucle. Y eso debería hacer que directivos, reguladores y consejos de administración prestaran atención. Porque en una empresa, un bucle no es simplemente un patrón de ingeniería. Es una estructura de gobernanza.
De prompts a bucles
Un prompt pide un output. Un bucle crea comportamiento.
Esa diferencia lo cambia todo. Un prompt puede estar equivocado y desaparecer. Un bucle puede estar equivocado y acumular efectos. Puede observar, actuar, recibir retroalimentación, ajustarse y repetir. Eso es exactamente lo que hace que los bucles sean poderosos. Y también lo que los vuelve peligrosos si las empresas no entienden qué están optimizando.
Ese es el verdadero significado del paso actual de la ingeniería de prompts a la ingeniería de bucles. Los ingenieros están descubriendo que el trabajo importante ya no consiste solo en formular mejores preguntas al modelo. Consiste en diseñar el sistema que invoca al modelo una y otra vez, evalúa los resultados y decide qué ocurre a continuación.
En desarrollo de software, eso puede significar que un agente de inteligencia artificial escriba código mientras otro lo revisa. En una empresa, puede significar que un sistema de inteligencia artificial optimice ventas, contratación, precios, compras, atención al cliente, crédito, seguros, logística o rendimiento interno.
En ese punto, la pregunta deja de ser técnica y pasa a ser institucional.
Todo bucle contiene política
Un bucle corporativo siempre contiene una teoría sobre lo que importa.
Si un bucle de atención al cliente optimiza la velocidad de resolución, puede aprender a cerrar tickets más rápido mientras deteriora silenciosamente la confianza. Si un bucle de ventas optimiza la conversión, puede aprender qué argumentos, descuentos o estímulos psicológicos mueven a los clientes con mayor eficacia. Si un bucle de contratación optimiza la retención, puede seleccionar conformidad. Si un bucle de precios optimiza el margen, puede producir resultados que parecen eficientes internamente y discriminatorios desde fuera.
Ninguno de esos fallos requiere un modelo malicioso: basta con un bucle mal gobernado. Por eso poner a un “human in the loop” ya no es suficiente. Demasiado a menudo, la expresión se utiliza como una especie de ritual tranquilizador: en algún lugar, de alguna manera, hay una persona involucrada. Pero ¿qué persona? ¿Con qué autoridad? ¿En qué punto del bucle? ¿Viendo qué información? ¿Capaz de detener qué acción? ¿Responsable de qué resultado?
Un humano validando a toda velocidad una optimización ejecutada a ritmo de máquina no es gobernanza: es responsabilidad legal con interfaz de usuario.
La gobernanza de la inteligencia artificial debe volverse continua
La mayor parte de la gobernanza de inteligencia artificial sigue asumiendo que la organización gobierna un objeto relativamente estático. Se evalúa un modelo. Se aprueba un caso de uso. Se clasifica un riesgo. Se crea un documento de cumplimiento. Se construye un cuadro de mando. El sistema entra en producción.
Pero un bucle de aprendizaje no es estático: cambia con el uso. Por eso los marcos de gobernanza más serios ya apuntan, implícita o explícitamente, hacia una gobernanza continua. El AI Risk Management Framework del NIST se estructura en torno a gobernar, mapear, medir y gestionar riesgos de inteligencia artificial. El Reglamento Europeo de inteligencia artificial exige monitorización posterior a la comercialización para sistemas de inteligencia artificial de alto riesgo, incluyendo la recopilación y análisis de datos de rendimiento a lo largo de todo su ciclo de vida. La norma ISO/IEC 42001, el estándar internacional para sistemas de gestión de inteligencia artificial, trata explícitamente de establecer, mantener y mejorar continuamente un sistema de gestión de inteligencia artificial.
La dirección está clara: la gobernanza de la inteligencia artificial no puede ser una lista de comprobación previa al lanzamiento.
Cuando la inteligencia artificial se convierte en un bucle, la pregunta crucial ya no es simplemente “¿se aprobó este sistema?”. Es: ¿qué está aprendiendo este bucle, a partir de qué datos, contra qué objetivo, bajo la autoridad de quién, dentro de qué restricciones y con qué derecho de apelación?
Es un tipo de gobernanza muy distinto.
El problema no es la autonomía. Es la adaptación
Gran parte de la conversación actual sobre inteligencia artificial empresarial está obsesionada con la autonomía. ¿Puede el agente hacer más cosas por sí mismo? ¿Puede utilizar más herramientas? ¿Puede ejecutar más tareas? ¿Puede funcionar durante más tiempo sin supervisión?
Son preguntas importantes, pero no son las más profundas. La cuestión real no es si un sistema de inteligencia artificial puede actuar. Es si la empresa puede gobernar lo que ese sistema aprende al actuar.
Una automatización que no aprende puede auditarse como un proceso. Un bucle de aprendizaje debe gobernarse como un sistema en evolución. Puede desviarse. Puede descubrir atajos. Puede optimizar una métrica mientras daña a la institución. Puede hacer que un departamento sea más eficiente mientras vuelve menos coherente a la empresa.
Este último punto es crítico. Un bucle puede optimizar soporte para ganar velocidad mientras otro optimiza retención para maximizar satisfacción a largo plazo. Uno puede optimizar compras para obtener el precio más bajo mientras otro optimiza resiliencia. Uno puede optimizar ventas para conversión mientras otro optimiza cumplimiento para reducir riesgos. Cada bucle puede parecer racional localmente. Juntos, pueden tirar de la empresa en direcciones opuestas.
El viejo problema del software empresarial era la integración: conseguir que los sistemas intercambiaran datos. El nuevo problema de la inteligencia artificial empresarial es la coherencia: conseguir que los sistemas de aprendizaje persigan objetivos compatibles.
Los consejos de administración necesitan entender los bucles
Los consejos de administración no necesitan revisar cada prompt. No necesitan entender cada arquitectura de modelo. Pero sí necesitan entender qué partes de la empresa se están volviendo autooptimizables, qué están optimizando esos sistemas y si esos objetivos están alineados con la estrategia, las obligaciones y los valores de la compañía.
Porque toda métrica es una decisión de gobernanza disfrazada de decisión técnica: optimizar costes, velocidad, crecimiento, retención, satisfacción, reducción del fraude, cumplimiento o margen no son conceptos neutrales. Cada elección codifica una teoría sobre para qué existe la empresa. Cuando esas elecciones se integran en sistemas adaptativos, se convierten en algo más que KPIs: se convierten en instrucciones operativas para la organización.
Por eso los bucles de aprendizaje corporativos deben estar en la agenda de los consejos de administración: no porque los consejos deban microgestionar la inteligencia artificial, sino porque los bucles de aprendizaje moldearán cada vez más el comportamiento de las empresas.
La gobernanza debe volverse ejecutable
La conclusión obvia es incómoda: las políticas escritas en documentos no bastan. Si los bucles van a observar, actuar, evaluar y mejorar, la gobernanza debe estar integrada en el propio bucle. El sistema debe saber qué puede hacer, qué debe registrar, cuándo debe escalar, qué restricciones son absolutas, cuáles son contextuales y qué decisiones requieren juicio humano.
En otras palabras, la gobernanza debe volverse ejecutable. Un bucle corporativo de inteligencia artificial debería tener un objetivo declarado, una función de recompensa visible, un perímetro operativo definido, una memoria auditable, permisos explícitos, resultados medibles, vías de escalado, condiciones de parada y un registro de cómo cambia su comportamiento con el tiempo.
Debería ser posible preguntar no sólo “¿qué respondió la inteligencia artificial?”, sino “¿qué ha aprendido a hacer este bucle?” Esa es la diferencia entre supervisar outputs y gobernar adaptación.
Los próximos fallos de la inteligencia artificial serán fallos de bucle
La próxima generación de fracasos en inteligencia artificial empresarial no vendrá principalmente de malos prompts: vendrá de bucles que funcionaron exactamente como fueron diseñados, optimizaron exactamente lo que se les pidió optimizar y enseñaron silenciosamente a la empresa a convertirse en algo que nunca eligió conscientemente ser.
Ese es el verdadero desafío de gobernanza. La carrera de los modelos hizo que la inteligencia artificial pareciera una cuestión de capacidad. La carrera de los agentes hizo que pareciera una cuestión de autonomía. La era de los bucles revelará que la inteligencia artificial empresarial es, en última instancia, una cuestión de control institucional.
¿Quién define el objetivo? ¿Quién posee la memoria? ¿Quién cambia la función de recompensa? ¿Quién detecta la deriva? ¿Quién puede detener el bucle? ¿Quién responde cuando la optimización funciona, pero la empresa se mueve en la dirección equivocada?
No son preguntas de ingeniería: son preguntas de gobernanza. Los bucles de aprendizaje corporativos no son simplemente el próximo truco en el desarrollo de inteligencia artificial. Son la maquinaria adaptativa de la empresa.
Y toda maquinaria adaptativa debe ser gobernada antes de que nos gobierne a nosotros.
(This article was previously published on Fast Company)
Al final el «loop» o el «prompt» es CASI lo mismo. Una de orquestadores…
Cuando le pido una tarea (o conjunto de ellas) a OPENCODE se pone en modo «loop» a gestionar el pedido. Cuando se lo pido a Claude (web gratuita) sospecho que internamente funciona de manera similar, es decir se construye su loop interno. Deepseek(web) también ha mejorado mucho, creo que internamente le han implementado las vueltas.
Por cierto no hay que confundir los COT con los loops, el primero es razonamiento más profundo el segundo es razonamiento + iteración. En esa iteración el workflow asociado a un LLM, realiza su COT comprueba, analiza repetidamente… es más similar a como funcionamos las personas. Es alucinante ver el proceso de algo sencillo y como lleva a cabo el proceso. Pero no es que el prompt haya muerto se ha sofisticado, todo parte de un prompt, de tener un agent.md, sus correspondientes skills (fichero md de habilidades) todo en lenguaje natural. El resultado al final es que esa iteración consigue una primera versión (es zero shot para mi) pero realmente puede haber unas cuantas vueltas… que hace lo que le pides en tu «prompt» inicial. Eso si cuanto mejor se planifiquen las «vueltas+prompt» mejor será el resultado. Lo que también sube es la exigencia del LLM usado, un 9B a una tarea mediana se bloquea con los loops… exige tener mejores modelos… ahora el problema tiene más factores a tener en cuenta (prompts, control de vueltas, agente.md, skills, tools,…)
Me da que también una componente de hype por parte de los fabricantes de LLM, que han visto que este tipo de herramientas agénticas hacen subir de manera significativa el número de tokens necesarios.
Al final, toda complejidad hace subir la factura en LLMs, y siempre necesitaras tener un control humano «decisor» de que la tarea cumplida tiene cierta calidad. Se supone que el que decide si es correcto, tiene que mirarlo y entender que se ha hecho… ese coste no te lo quitas,… en definitiva si hay hype es porque pasta detrás para los espabilados constructores de IAs… por muy gratuitos que sean los orquestadores…
Totalmente de acuerdo en que no hay que plantearlo como si el prompt desapareciese. El prompt sigue estando ahí, claro, pero deja de ser la unidad principal de valor. Antes la interacción terminaba, básicamente, en una respuesta; ahora el valor empieza a desplazarse hacia cómo se estructura el proceso: qué vueltas se dan, con qué herramientas, bajo qué restricciones, con qué criterios de validación y con qué intervención humana. En ese sentido, no es que el prompt haya muerto: es que se ha convertido en una pieza más dentro de una arquitectura mucho más amplia.
Y también coincido en la distinción entre cadena de razonamiento y loop. Una cosa es razonar mejor, y otra es diseñar un sistema que itera, comprueba, corrige, vuelve a intentar, consulta herramientas y se coordina con otros agentes o procesos. Ahí es donde aparece el problema de gobernanza: no en que el modelo “piense” más o menos, sino en quién define esas vueltas, qué se optimiza, qué se mide, cuándo se detiene el proceso y quién responde si el resultado es malo, sesgado, ineficiente o simplemente absurdo.
Sobre el coste, completamente: los loops consumen más tokens, más llamadas a herramientas, más contexto y más supervisión. Ahí hay, sin duda, incentivo comercial y bastante hype. Pero eso no invalida el cambio de fondo: una empresa no debería adoptar estos sistemas porque “son agentes” o porque el proveedor lo venda como magia, sino porque ha entendido muy bien qué proceso quiere automatizar, qué coste tiene cada iteración, qué riesgo introduce y dónde debe permanecer el criterio humano. La cuestión no es si hay loop o no hay loop, sino quién carajo gobierna ese loop y cómo.
“La cuestión no es si hay loop o no hay loop, sino quién carajo gobierna ese loop y cómo”
Como analista, mi lectura es que esto es simplemente buen diseño de sistemas de toda la vida: manejo de excepciones, validación y criterios de parada.
La tecnología cambia, pero los principios de la buena ingeniería (saber cuándo parar, quién es el responsable y cuánto cuesta cada iteración) siguen siendo los mismos. Solo que ahora se complica un poco la cosa.
Tienes toda la razón en el fondo del asunto: en un sistema de agentes, si no defines explícitamente las break conditions y el supervisor del flujo, el sistema puede entrar en un bucle de gasto de tokens infinito o ejecutar una acción catastrófica con total confianza.
El problema no es que la IA esté «pensando» o «decidiendo», sino que estamos ejecutando lógica probabilística sin las redes de seguridad deterministas que siempre hemos exigido en producción.
De hecho, no deja de ser la misma discusión que hemos tenido estos años: el peligro de tomarse al pie de la letra cualquier output de un LLM sin una supervisión real (humana o por reglas estrictas de código). Gobernar ese loop hoy significa, precisamente, recordar que la validación final no puede ser otro LLM alucinando, sino un criterio humano o una regla inquebrantable del sistema.
Vamos, como toda la vida… XDD