Una routine en Grok Bot no es “otro chatbot que manda recordatorios”. Es trabajo de pie: un Bot se activa por horario o por evento, prepara el resultado en herramientas reales y solo te interrumpe cuando algo exige juicio —enviar, publicar, gastar, mutar un CRM o tocar producción. Este playbook de confianza de ARTDEPARTMENT cierra la mini-serie: después de qué es Grok Bot y de cómo usarlo en SEO, contenido y Ads, acá el foco es qué automatizar y qué dejar con aprobación.
El marco de gobernanza del stack ya está en el checklist de IA en el stack de marketing 2026. Esta nota baja al detalle operativo de routines, skills, computadora compartida y puertas humanas —sin inventar incidentes de seguridad ni métricas de “X% más eficiencia”. El producto documenta approvals, Auto Review y el límite de la computadora compartida; nosotros aterrizamos eso a un playbook de marketing.
¿Qué es una routine en Grok Bot?
Según el FAQ oficial y la guía de skills and routines, la distinción es limpia:
- Un skill describe cómo hacer una tarea: pasos, inputs, reglas de decisión, validación, output y límites de seguridad.
- Una routine asigna ese workflow a un Bot y le dice cuándo correr —en un schedule o, donde esté soportado, después de un evento.
La overview lo enmarca en el producto: teammates con computadora cloud, trabajo en background y handoffs que terminan en herramientas reales. Designing Grok Bot muestra routines en la UI del Bot (briefing matutino, limpieza de inbox, update semanal) y deja claro el cambio de paradigma: el trabajo ya no empieza solo con un prompt tuyo; puede empezar por un horario, un evento u otro Bot. El anuncio de lanzamiento insiste en lo mismo: el Bot sigue cuando cerrás la laptop y vuelve cuando necesita aprobación.
Para marketing, la lectura útil no es “automatizar todo el stack”. Es standing work con freno escrito: el Bot acumula ritmo; vos conservás voz, legal y presupuesto.
¿En qué se diferencia un skill de una routine?
La confusión más cara es tratar “skill” y “routine” como sinónimos. No lo son.
Un skill es el manual reutilizable del proceso. Vive a nivel de cuenta/capacidades: varios Bots pueden necesitar el mismo “cómo” (research matutino, triage de Search Console, armado de variantes RSA). La documentación pide que el skill nombre cuándo usarlo, inputs y accesos, secuencia, cómo validar, qué devolver y qué requiere aprobación.
Una routine es el compromiso de calendario (o de evento) de un Bot concreto: dueño, zona horaria, fuente de inputs, resultado esperado, frontera de aprobación y qué hacer si la fuente falta. La guía oficial recomienda: probar el skill en una tarea real una vez; corregir; recién entonces crear la routine; usar Test run con inputs seguros porque un test run hace trabajo real.
En la práctica de equipo:
- Corrés el flujo a mano con el Bot (o con Teach a task, donde esté disponible).
- Guardás el skill con reglas de fallo y límites de aprobación.
- Creás la routine solo cuando retries y casos de dato faltante están definidos.
- Pausás la routine si cambia el sistema fuente o el workflow esperado.
Skills = cómo. Routines = cuándo. Mezclarlos produce routines frágiles que “corren solas” sin criterio de parada.
¿Cómo se ve el flujo con puerta de aprobación?
Pensá cuatro momentos, no un interruptor mágico:
- Routine fire — schedule o evento activa al Bot.
- Do the work — lee fuentes, prepara drafts, escribe en tools / archivos.
- Approval gate — se detiene ante acciones consecuentes.
- Continue / stop — Allow once, Deny o (con cuidado) Always allow para reglas estrechas.
*Esquema didáctico ARTDEPARTMENT: la routine acelera preparación; la puerta humana decide envío, publish, spend y cambios de producción.*
Ese patrón no es invento de agencia: la página de approvals, security, and privacy pide fronteras explícitas en el propio pedido (enviar, publicar, comprar, borrar, cambiar permisos, tocar producción, aceptar términos legales). Una aprobación controla la acción propuesta; no deshace lo ya hecho. Auto Review evalúa acciones riesgosas antes de correrlas y puede exigir aprobación o denegar; las reglas Require Approval ganan sobre Always Allow (security).
¿Por qué importa la computadora compartida?
Todos los Bots de tu cuenta usan una computadora cloud: archivos, sesiones de browser y logins son compartidos. La overview y el FAQ son explícitos: la computadora es por usuario, no por Bot; no uses Bots distintos como frontera de seguridad. Entre usuarios la aislación es estricta; dentro de tu roster, no.
Para un equipo de marketing o agencia eso implica gobernanza concreta:
- No mezclar credenciales de clientes “porque son Bots distintos”.
- Cerrar sesión en un servicio cuando ya no debe estar disponible.
- Limpiar archivos sensibles de
/workspaceal cerrar un proyecto. - Pausar o borrar routines relacionadas al retirar acceso.
- Recordar que borrar un Bot no borra archivos ni sesiones de la computadora compartida (approvals).
En ARTDEPARTMENT tratamos standing watches con cuidado precisamente por esto: el compounding de contexto es valioso; el compounding de logins cruzados es deuda. Las puertas de aprobación importan tanto como el schedule.
Operativamente eso se traduce en pocas reglas escritas, no en un teatro de compliance:
- Un Bot de research SEO no “necesita” la sesión de Ads del cliente en el mismo browser si el trabajo del día es un digest de GSC.
- Cuando un proyecto termina, la checklist de salida incluye pausar routines, cerrar sesiones y limpiar
/workspace—borrar el Bot del roster no alcanza. - Los standing watches que mantenemos son de lectura y preparación (anomalías, digests, notas). Lo que toca marca, legal o dinero pasa por aprobación explícita, aunque el Bot ya “sepa” hacerlo.
¿Cuándo debe frenar el Bot y pedir aprobación?
La documentación lista categorías sensibles. En marketing las traduces así:
Zona roja (siempre con aprobación o takeover humano):
- Enviar email, mensajes o invitaciones hacia afuera.
- Publicar contenido (CMS live, redes, landings comerciales).
- Comprar, pagar o cambiar presupuesto / pujas de Ads.
- Mutar CRM (crear secuencias, marcar deals, borrar contactos).
- Borrar u overwrite de datos.
- Cambiar permisos o producción.
- Ingresar passwords, 2FA, CAPTCHAs o confirmaciones de pago —takeover del computer, no chat (approvals).
Zona ámbar (draft sí; go-live no):
- Crear borradores en CMS.
- Proponer negativas de Ads o variantes RSA.
- Armar briefs / outlines / notas de SERP.
- Triage de Search Console o inventarios de URLs.
Zona verde (candidata a routine sin fricción alta):
- Digests internos en el hilo del Bot.
- Watchlists y anomalías reportadas como lista, sin acción externa.
- Compilaciones de fuentes ya autorizadas (exports que vos dejaste).
La frontera más fuerte sigue siendo la del pedido: “Reconciliá datos y recomendá; no cambies la campaña ni escribas a la agencia; pedí aprobación mostrando valor actual, propuesto e impacto esperado” —ejemplo del espíritu de la doc de approvals. Auto Review complementa; no reemplaza least privilege ni reglas Require Approval estrechas (“require approval before sending any external email”). Evitá “allow everything in the browser”.
¿Qué routines sí conviene a un equipo de marketing?
Candidatas sanas: preparan y dejan revisión humana. Tres patrones que encajan con el playbook de la parte 2:
Morning digest (horario)
Cada día laboral a una hora fija (timezone del settings del Bot): resumen de inbox / Slack / tickets priorizados, links a drafts listos, y cero envíos. Entregable: lista en el transcript. Si una fuente falta, reportar fallo —no inventar con datos viejos (política de no-data de la guía de skills/routines).
GSC anomaly watch (horario o evento)
Routine que revisa exports o vistas de Search Console y arma una lista priorizada: caídas abruptas, CTR raro, cobertura rota. Entregable: triage de 5 ítems. El humano decide si es indexación, canibalización o cambio de intent. Encaja con el mapa de qué es el SEO y con el how-to de cómo posicionar una página —el Bot señala; no “optimiza solo”.
Competitor SERP note (horario semanal)
Una vez por semana: nota narrativa de SERP para un cluster acordado (quién aparece, ángulo, formato). Sin “copiá el H2 del #1”. Alimenta briefs; no publica.
Pre-publish checklist (horario o on-demand)
Antes de un go-live humano, una routine puede recorrer el draft y devolver una lista: claims sin URL primaria, internos rotos o genéricos, title/meta demasiado largos, H1 que no responde la query, riesgos YMYL. Entregable = checklist con “pass / fail / needs human”. No cambia el estado del CMS a published.
Handoff SEO ↔ Ads (semanal)
Una routine que cruza (con exports que vos proveés) search terms caros o vacíos con el calendario editorial: “no escribir vanity sobre query X”; “considerar durable sobre query Y”. Encaja con SEO o Google Ads y con tipos de campañas de Google Ads. El humano aprueba negativas y prioriza URLs.
Otras routines útiles con el mismo espíritu: inventario de URLs candidatas a fusión, watchlist de landings comerciales con copy desactualizado, digest de creatividades en revisión —siempre con freno de envío/publish/spend.
¿Qué routines son mala idea el día uno?
Malas candidatas (aunque el producto *pueda* ejecutarlas):
- Auto-publish de posts sin review. Google prioriza contenido people-first y trata la producción masiva sin valor como abuso a escala. La guía de contenido útil y la de contenido con IA dejan el “por qué”: si el motivo es manipular rankings, estás del lado search-engine-first. Una routine que publica 20 URLs “porque hay tokens” es riesgo de spam, no productividad.
- Auto-spend en Ads (subir presupuestos, cambiar pujas, pausar campañas enteras) sin checklist de tracking ni aprobación. Velocidad de pauta sin hipótesis quema presupuesto y aprendizaje.
- Outreach automático a clientes o leads sin aprobación por mensaje. El FAQ y approvals listan envíos como frontera sensible.
- Mutaciones de CRM o producción “porque el digest lo sugirió”.
- Mezclar draft y go-live en la misma routine. Separá preparación de publicación: draft en CMS sí; live solo con humano.
- Listeners de evento demasiado amplios. “Cada mensaje nuevo en #general” genera ruido, consume usage y sube la chance de actuar sobre input irrelevante —la guía de skills/routines pide matching rules estrechas.
- Always allow amplio en browser. Auto Review es model-based; la doc de approvals desaconseja reglas tipo “permití todo en el browser”. Preferí Require Approval estrecho sobre Always Allow amplio.
Si el horizonte es “modelos más grandes + Search”, el marco sigue siendo el de qué implica GPT‑6 Astra para SEO y marketing: la herramienta nueva no sustituye intención ni E‑E‑A‑T. El post de Search Central sobre cómo ve Google el contenido con IA refuerza la misma línea: automatización útil no está prohibida; usarla para engañar al ranking, sí.
¿Cómo diseñar una routine de confianza (checklist corto)?
Adaptá el espíritu de skills and routines y use cases:
- Job + sistemas fuente + formato de output + fronteras en la descripción del Bot.
- Una tarea real con scope seguro.
- Corregí hasta que el resultado sea reviewable.
- Guardá skill (incluye qué requiere aprobación).
- Segunda prueba con otro input.
- Routine solo con política de dato faltante / stale y retries sensatos.
- Acciones externas consecuentes detrás de aprobación.
- Re-test después de cambios de website, connector o formato de fuente.
- Pausá la routine cuando el workflow cambie.
- Bitácora humana de qué se aprobó y por qué (sin bitácora no hay compounding de criterio).
Plantilla de pedido para crear o ajustar una routine:
Dueño: [Bot / rol]. Trigger: [días + hora + timezone / evento]. Fuentes: [URLs / exports / connectors]. Entregable: [digest / lista / draft en archivo]. Restricciones: no inventar métricas; no enviar; no publicar; no cambiar presupuestos. Si falta la fuente: reportar fallo y parar. Pedí aprobación antes de [acción X].
¿Qué sigue siendo del humano después de las routines?
Después de schedules y eventos, el humano sigue siendo dueño de tres capas que no se “rutinizan” bien:
- Voz de marca — tono, promesas, lo que no decimos. El Bot propone variantes; vos firmás el mensaje. Una routine puede generar tres leads de email; no debería decidir cuál se parece a la marca bajo presión de un deadline.
- Legal / compliance / YMYL — claims, disclaimers, datos de terceros, términos. Takeover en passwords y pagos. Si el tema toca salud, finanzas o legal, el listón de review sube: más fuentes primarias, menos velocidad.
- Spend y go-live — presupuesto Ads, publish CMS, envíos externos, mutaciones de CRM. Ahí viven reputación y dinero; no el “ahorro de cinco clics”.
Hay una cuarta capa silenciosa: criterio de prioridad. Una routine puede traer veinte anomalías de GSC; solo un humano (o un rol con contexto de negocio) decide cuáles importan esta semana frente a un lanzamiento, una migración o una campaña de pauta. Sin esa capa, el digest se convierte en otra bandeja de ruido.
Eso es coherente con el checklist IA 2026 y con el playbook de tres carriles de la parte 2: el Bot acelera insumos; la puerta humana decide. También encaja con la pregunta “Who / How / Why” de Google sobre contenido: si alguien preguntaría cómo se produjo el texto, la transparencia de proceso ayuda —sin convertir cada post en un disclaimer legal (people-first).
¿Cómo lo operamos en ARTDEPARTMENT?
Somos un estudio de diseño y marketing que usa IA en el día a día. Con Grok Bot el patrón que nos interesa en routines es conservador a propósito:
- Standing watches (GSC, digests, SERP notes) con entregable = lista o draft, no acción externa.
- Approval gates explícitos en send / publish / spend.
- Bots por rol para acumular contexto, sin tratar el roster como aislamiento de seguridad (computadora compartida).
- Sin métricas inventadas ni partnership con xAI; sin agent names internos en público.
- CTAs solo a landings comerciales reales del sitio —nunca “talleres”.
Si el dolor es orgánico, mirá SEO y posicionamiento web. Si es pauta, Google Ads. Si necesitás orquestación continua, el marco liviano está en qué es un growth partner.
Resumen práctico
- Skill = cómo; routine = cuándo (schedule / evento) —docs oficiales.
- Flujo sano: fire → work → approval gate → continue/stop.
- Computadora compartida: no uses Bots como frontera de seguridad.
- Buenas routines: morning digest, GSC anomaly watch, SERP note —preparan.
- Malas routines día uno: auto-publish sin review, auto-spend Ads, outreach sin aprobación.
- Pedidos con dueño, trigger, fuentes, entregable, no-data policy y freno explícito.
- Humano conserva voz, legal y spend.
- Serie completa: qué es Grok Bot → SEO / contenido / Ads → esta nota. Gobernanza: checklist IA 2026.
Fuentes primarias: overview, FAQ, skills and routines, approvals, security, and privacy, security, Introducing Grok Bot, Designing Grok Bot, people-first, gen AI content, spam policies.
