¿Dejarías que una IA aplicara ella sola un cambio que afecta directamente a tu proyecto? No que te lo proponga y lo revises tú. Que lo ejecute ella sin que nadie le dé al botón.
Los más espabilados del lugar dirán que ya lo hacen así y que les va muy bien.
¿Le cuentan a sus clientes que publican cambios en su web sin revisar antes? ¿O que tocan campañas de Google Ads sin supervisar?
Espero que no o van a tener una relación bastante corta con ellos 😅
Quien tiene permiso para tocar, tiene permiso para romper.
La solución a no liarla no pasa por no usar IA, sino por dos cosas:
Entender que gran parte del trabajo profesional es aportar criterio y responsabilidad. Y OpenAI o Anthropic no van a salir a hacerse cargo de tus liadas. Te lo vas a comer tú.
Separar lo que no es determinista (la IA, que razona distinto cada vez y por eso te da resultados distintos para la misma pregunta) de lo que sí es determinista (un script, que hace siempre lo mismo: para una misma entrada, genera una salida idéntica lo ejecutes cuando lo ejecutes).
Hace poco estaba revisando la medición de una cuenta con ayuda de un modelo. GA4 por un lado, los logs del server-side GTM en BigQuery por otro y los datos de conversión que la plataforma de anuncios decía estar registrando por otro. Tres fuentes que casi nunca cuadran del todo. Bueno, no cuadran. Punto.
Y salió algo interesante.
El modelo cruzó los eventos server-side con lo que llegaba a GA4 y a la plataforma de anuncios. Me marcó una discrepancia de estas que te pueden estropear el próximo informe: desde un cambio de consentimiento reciente, un buen puñado de conversiones se estaba contando dos veces. El skill que estaba usando me proponía una solución clara y concisa: el problema estaba en un disparador de GTM concreto, el arreglo era tocar un parámetro en el contenedor y dejar de duplicar.
Lo leí y pensé “esto es oro”. Tenía sentido, tenía evidencia y tenía hasta el cambio exacto listo para aplicar en producción.
Y ahí llegó el momento tenso. Ese momento en el que el protagonista de la película ha tenido una idea. Una idea brillante a la vez que terrible. Mira hacia atrás a sus amigos y sopesa lo que pensarán si lo hace.
El modelo, zalamero, me decía: “¿Quieres que aplique los cambios?”.
Porque una cosa es tener el diagnóstico en pantalla y otra bien distinta es lo que viene después: ¿le doy al botón y dejo que el agente publique ese cambio en el contenedor de tracking, o abro yo los datos, lo compruebo y lo aplico a mano?
La respuesta a esta pregunta es todo el post.
Si dejas que un agente decida y ejecute cambios en producción en el mismo contexto, sea una cuenta de Google Ads o el contenedor que mide tus conversiones, no has montado una automatización: has mezclado criterio, permiso y ejecución en una sola caja negra.
Y esa caja negra puede salir cara. Vete tú a saber lo que hay dentro.
Ojo, no porque los agentes sean inútiles. Todo lo contrario. Acaba de cruzarme tres fuentes y enseñarme en un minuto una discrepancia que yo habría tardado media mañana en cazar a mano. Para analizar datos, detectar anomalías, cruzar señales y documentar hipótesis son potentísimos.
El problema aparece cuando le das también la mano que toca la cuenta.
Pausar una campaña, cambiar un presupuesto, añadir negativas, modificar pujas, tocar etiquetas, reordenar assets o publicar un cambio en producción no pertenece a la misma categoría que “revísame este informe y dime qué huele raro”.
Una cosa es pensar. Otra es autorizar. Otra es ejecutar.
La arquitectura que más sentido tiene ahora mismo para agentes aplicados a PPC/SEM, tracking o cambios SEO complejos es bastante aburrida. Por eso me gusta.
Primero, un agente no determinista analiza.
Mira datos de Google Ads, Microsoft Ads, GA4, CRM, márgenes, histórico de conversiones, incidencias de tracking y lo que toque. Detecta anomalías, propone oportunidades, documenta el razonamiento y prepara un change set. Es decir: “he visto esto, creo que deberíamos hacer esto otro, esta es la evidencia y estas son las acciones exactas que propongo”.
Segundo, una persona con experiencia autoriza.
No “revisa por encima”. No pulsa aceptar porque el resumen parece razonable. Autoriza una acción concreta en una cuenta concreta, con un cliente concreto, en un momento concreto.
Tercero, una capa determinista ejecuta.
Un script, una llamada CLI o un wrapper de API hace exactamente lo aprobado. Nada más.
Ese orden parece una obviedad hasta que miras cómo se venden muchos agentes: “conecta tus herramientas, dale un objetivo y deja que trabaje”. Muy bonito en una demo. Bastante menos bonito cuando el objetivo toca presupuesto real, datos de cliente o una cuenta con cinco años de aprendizaje acumulado.
El human in the loop (HiTL, en el argot) se suele explicar como si fuera una pausa educada para tranquilizar a la audiencia.
“No te preocupes, hay un humano en medio”.
Vale. ¿Haciendo qué?
Porque no es lo mismo que el humano lea un resumen que autorizar una operación con responsabilidad real. Si el agente dice “conviene bajar presupuesto en estas campañas”, el consultor no valida solo si la frase suena plausible. Valida si esa acción tiene sentido ahora.
¿Está la cuenta en fase de aprendizaje?
¿Hay una promo activa que no aparece en el dato histórico?
¿El tracking está limpio o acabas de cambiar el consentimiento?
¿Hay margen suficiente para dar más peso a esa línea de producto?
¿El cliente ha aceptado sacrificar volumen para ganar rentabilidad?
¿La anomalía es de campaña o viene de una caída técnica en la landing?
Ahí hay criterio. Criterio de cuenta, de negocio, de relación con cliente y de riesgo. Y responsabilidad ante lo que pueda pasar.
Un agente puede preparar muy bien la conversación. Puede traer evidencias, ordenar hipótesis, sugerir acciones y dejarte el trabajo más masticado. Pero la autorización no es un trámite. Es la frontera de responsabilidad.
Una vez tomada la decisión, no quiero que otro razonamiento generativo vuelva a decidir qué hacer con la cuenta.
Quiero una acción estrecha.
Algo de este estilo:
Pausa estos IDs de anuncio.
Añade estas keywords negativas exactas.
Aplica estos 12 redirects 301 exactos, solo si la URL de destino responde 200.
Cambia este presupuesto de 80 a 65 euros diarios, solo si el presupuesto actual sigue siendo 80.
Actualiza el robots.txt solo en estas reglas, guardando antes una copia del fichero actual.
Crea esta etiqueta con este nombre.
Exporta este informe y guárdalo con este identificador.
Aplica este cambio solo en estas campañas o en estas URLs, y solo si pasan estas validaciones.
La gracia está en que cada operación sea pequeña, explícita y fácil de comprobar.
Si una acción aprobada se traduce en un comando estrecho y conciso, puedes hacer cosas nada lucidas y muy útiles: dry-run (testear sin aplicar cambios), validación de inputs (revisar lo que se va a ejecutar), límites máximos, allowlist de cuentas (dónde se aplicará el cambio), logs con antes/después, confirmación humana, rollback cuando aplique y auditoría posterior.
Eso no mola tanto como un vídeo de “mi agente gestiona campañas mientras duermo”. Pero a mí me da bastante más tranquilidad. Y, francamente, prefiero dormir a tener que levantarme a explicar por qué un LLM ha entendido “optimiza inversión” como “mueve dinero en tres campañas que nadie quería tocar”.
Y explicárselo a otra persona ya ni te cuento lo poco que me apetece.
Se habla mucho de poner guardrails alrededor del agente. Bien. Hay que ponerlos.
Pero los guardrails no viven en el aire. Funcionan mejor cuando la superficie permitida es pequeña.
Si la herramienta que le das al agente se llama “gestiona esta cuenta de Ads”, el permiso que estás dando es enorme. El modelo puede intentar llegar al objetivo por demasiados caminos: cambiar presupuesto, tocar pujas, pausar, crear, renombrar, etiquetar, consultar, exportar, mezclar cuentas, interpretar estados y actuar sobre elementos que quizá no debería ni ver.
Si la herramienta se llama “pausa estos ad_group_ad IDs en esta cuenta, con dry-run obligatorio y límite de 20 IDs”, el problema cambia de tamaño. Y lo mismo si en vez de “gestióname el SEO on-page del site” le das “cambia el canonical de estas 30 URLs concretas, con diff previo obligatorio y sin tocar ninguna otra”.
Ahí sí puedes razonar.
Puedes validar que los IDs pertenecen a la cuenta correcta. Puedes bloquear cuentas no permitidas. Puedes exigir que el change set venga firmado por una persona. Puedes guardar input y output. Puedes impedir cambios fuera de horario. Puedes cortar si el número de entidades supera un umbral. Puedes pedir segunda confirmación si el impacto estimado pasa de cierto presupuesto.
No hace falta convertir cada flujo en una tesis doctoral. Hace falta que el agente no tenga más grados de libertad de los necesarios.
Aquí es donde soy prudente con algunas integraciones tipo MCP demasiado genéricas.
MCP me parece útil. Lo uso mentalmente como categoría de herramienta: conectar un agente con datos, APIs y sistemas reales. Bien diseñado, te evita pegotes y hace el trabajo más ordenado.
El riesgo aparece cuando el servidor expone una superficie demasiado amplia y el agente puede “hacer cosas” sin que el sistema le obligue a traducir la intención en operaciones pequeñas.
En pruebas, eso es cómodo. En producción, cómodo no siempre es bueno.
Un wrapper aburrido con cinco comandos puede ser menos sexy que un conector universal, pero también es más barato en tokens, más fácil de auditar y más sencillo de explicar a un cliente si algo falla.
Además, reduce un problema que se suele infravalorar: el agente no solo necesita acceso. Necesita contexto, jerarquía y límites. Más conectores no significan más entendimiento. A veces solo significan más formas de equivocarte con confianza.
Si tuviera que convertir esta tesis en una lista mínima para un equipo, escribiría esto antes de conectar nada serio:
Qué puede pensar el agente: análisis, anomalías, explicación, propuesta, priorización.
Qué puede proponer: change sets con entidades concretas, justificación, impacto esperado y riesgos.
Quién puede autorizar: persona, rol, cuenta, umbral económico y condiciones.
Qué ejecuta el sistema determinista: comandos concretos, scopes, límites, dry-run y rollback.
Qué se registra: input, output, versión del workflow, usuario que autorizó, hora, cuenta afectada y resultado.
Qué no se permite nunca: cambios fuera de scope, cuentas no autorizadas, acciones destructivas sin confirmación y herramientas demasiado amplias para el caso.
No hace falta empezar con un framework enorme. De hecho, muchas veces es peor. Empieza por una operación estrecha y repetible.
Por ejemplo: detectar términos de búsqueda candidatos a negativa, generar propuesta, revisión humana y ejecución determinista de negativas exactas aprobadas.
O, en SEO, detectar páginas que han pasado a noindex sin que nadie lo pidiera, generar la explicación con evidencia, pedir autorización y solo entonces ejecutar el cambio exacto aprobado sobre esas URLs.
O detectar campañas con gasto anómalo, generar explicación, pedir autorización y solo entonces aplicar una etiqueta o exportar un informe. Ni siquiera hace falta que la primera versión cambie presupuestos. A veces el primer buen sistema solo etiqueta, avisa y documenta.
Eso ya tiene valor.
La parte difícil de todo esto no es añadir un botón de aprobar.
La parte difícil es decidir qué parte del sistema tiene permiso para pensar, qué parte tiene permiso para aprobar y qué parte tiene permiso para tocar producción.
Esa decisión es organizativa, técnica y comercial a la vez.
Organizativa, porque alguien firma el riesgo.
Técnica, porque la superficie de herramientas define lo que puede pasar.
Comercial, porque si vendes “autonomía” y en realidad operas con cinco confirmaciones humanas, no tienes un problema de IA. Tienes un problema de expectativas.
Me gusta la IA aplicada precisamente porque permite hacer cosas útiles con datos, contexto y criterio. Pero cuanto más cerca está de producción, menos me interesa el discurso de autonomía total y más me interesa el diseño del sistema.
El agente puede pensar. El consultor puede decidir. El script puede ejecutar.
Si esa arquitectura te parece demasiado aburrida, probablemente vas por buen camino. Las cosas que protegen presupuestos, cuentas y clientes suelen tener poco glamour. También suelen ser las que funcionan cuando la demo se acaba.
Sin posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.