Reglas de seguridad para agentes de IA que publican en cientos de cuentas
Reglas para agentes de IA que publican en muchas cuentas: API oficiales, claves acotadas, textos variados, envío escalonado, límites por red y plan de freno.
Un agente de IA que publica en cientos de cuentas se mantiene seguro si sigue un puñado de reglas: publicar solo a través de las API oficiales de cada red, tener la clave con los permisos mínimos que necesita, no enviar nunca el mismo texto a varias cuentas, espaciar los envíos entre cuentas, respetar los límites y las políticas de cada red, y contar con una forma de frenar una tanda rápido. La mayoría de estas reglas deberían imponerlas la plataforma y los permisos de las claves, con las instrucciones del agente como segunda capa y no como la única.
A continuación está el reglamento que recomendamos, escrito para que puedas pegar casi todo directamente en la skill de un agente. Cada regla viene con su motivo, porque un agente que entiende el porqué maneja mejor los casos límite que uno que sigue una instrucción a secas.
¿Por qué los agentes necesitan sus propias reglas de seguridad?
Una persona que programa publicaciones se equivoca de una en una. Un agente se equivoca en lote. Si las instrucciones tienen un error, ese error cae en todas las cuentas de la tanda. La escala multiplica por igual el buen trabajo y el malo.
Además, las redes dicen claramente que el volumen y la repetición son señales que vigilan. La política de spam de Meta abarca publicar con una frecuencia muy alta, sea de forma manual o automatizada, y el contenido repetitivo. Las políticas de YouTube sobre spam, prácticas engañosas y estafas abarcan el contenido repetitivo y no segmentado. Son políticas sobre el comportamiento, no sobre si apretó el botón una persona o un software.
El reglamento
Regla 1: solo API oficiales
El agente publica a través de una plataforma que usa la API oficial de cada red. Nada de automatizar el navegador, compartir inicios de sesión ni usar endpoints no oficiales. Shager publica solo a través de las API oficiales de las redes, así que esta regla se cumple por la elección de la plataforma, no por la disciplina del agente.
Por qué: los métodos no oficiales violan los términos de servicio, ponen en riesgo la propia cuenta y fallan de forma impredecible.
Regla 2: claves con el mínimo privilegio
Empieza cada agente con read y write. Agrega publish solo cuando una persona haya decidido que ese agente puede programar. Usa claves separadas por cliente o por agente, para que revocar una no lo detenga todo.
Por qué: una clave que no puede publicar convierte una mala instrucción en un mal borrador, que no hace daño. Nuestro artículo sobre claves de API, permisos y auditoría explica la configuración.
Regla 3: primero borrador, después programación
Cada tanda crea borradores. Programar es un paso aparte, después de la revisión o de la aprobación del cliente.
Por qué: crea un punto de control natural sin frenar el trabajo de producción del agente. El razonamiento completo está en aprobación humana para publicaciones de agentes.
Regla 4: un texto distinto para cada cuenta
Cuando una publicación va a muchas cuentas, usa per_channel para darle a cada cuenta su propio texto y, cuando corresponda, su propio primer comentario. Mantén fijas las afirmaciones y las ofertas; varía la apertura, los detalles locales, la redacción y la llamada a la acción.
Por qué: el mismo texto en muchas cuentas en el mismo momento es exactamente lo que parece contenido repetitivo visto desde afuera. Nuestra guía de variación de textos por cuenta muestra cómo hacerlo sin salirse de la marca.
Regla 5: escalonar los envíos
No envíes a todas las cuentas en el mismo segundo. stagger_seconds de Shager define un rango de espera aleatoria entre cuentas, con un valor por defecto de [30, 90] segundos. Para grupos grandes o clientes delicados, amplíalo.
Por qué: repartir los envíos en el tiempo es como publicaría un equipo real en muchas páginas, y reduce las ráfagas que parecen automatizadas.
Regla 6: conocer los límites duros de cada red
Algunos límites son públicos. Instagram, por ejemplo, documenta que las cuentas tienen un límite de 100 publicaciones por API en un período móvil de 24 horas. En condiciones normales, tu agente nunca debería acercarse a límites así; si lo hace, el plan está mal. Los archivos también tienen restricciones de formato. Al subir un video para Reels, Shorts o historias, pasa width, height y duration_ms a upload_media_from_url para que se pueda validar antes de armar cualquier publicación.
Por qué: una publicación rechazada al momento del envío desperdicia un espacio, y los fallos repetidos son ruido que no quieres en la cuenta de un cliente.
Regla 7: dejar que la plataforma revise antes de enviar
Shager revisa cada publicación según las reglas de la red de destino antes del envío. El agente debe tratar un error de validación como información: leer el código y el mensaje de error, corregir la publicación y volver a intentarlo una vez. Si falla dos veces, se detiene e informa.
Por qué: un agente que reintenta a ciegas puede convertir un problema en decenas de llamadas fallidas.
Regla 8: respetar el límite de la propia API
La API de Shager permite 120 solicitudes por minuto por clave. Una tanda bien diseñada usa la segmentación por grupos y per_channel en un solo create_post en lugar de una llamada por cuenta, así que rara vez se acerca al límite.
Por qué: agrupar es más rápido y mantiene la tanda dentro de los límites sin bucles de espera en la lógica del agente.
Regla 9: tener un plan de freno
Antes de una tanda grande, ten claro cómo detenerla. list_posts muestra lo que está programado, y el label de la tanda te dice qué publicaciones le pertenecen; cancel_post retira cada una antes de su hora de envío. Una persona también puede revocar la clave en el panel de agentes, lo que corta cualquier llamada posterior de ese agente.
Por qué: el momento de diseñar el botón de freno es antes de necesitarlo.
Regla 10: llevar un registro de auditoría y leerlo
Cada llamada de un agente queda registrada en el registro de auditoría del panel de agentes. Alguien debería revisarlo cada semana, no solo después de un incidente.
Por qué: los desvíos en el comportamiento del agente aparecen en el registro antes de aparecer en público.
El reglamento como texto de skill
Esta es una versión condensada para poner en una skill o en un prompt de sistema:
SAFETY RULES (always apply)
1. Create drafts only unless the instructions explicitly say to schedule
an approved post.
2. When targeting more than one account, always use per_channel with a
distinct caption for each account. Never send identical captions.
3. Use stagger_seconds of at least [30, 90]; use [60, 180] for groups
larger than 20 accounts.
4. For video, always pass width, height and duration_ms on upload.
5. Never state a price, discount, date or claim that is not in the brief.
6. On a validation error, fix and retry once. On a second error, stop and
report the error code and message.
7. Label every post in a run with the same label so the run can be listed
and cancelled as a group.
8. Never call schedule_post on a post that has not been approved.
Los umbrales de la regla 3 son una sugerencia nuestra, no una regla de las redes. Elige valores que se ajusten a tus clientes y mantenlos constantes.
¿Cómo es una tanda grande segura?
whoamipara confirmar que los permisos de la clave coinciden con la tarea.list_groupsylist_channelspara determinar exactamente qué cuentas entran, e informar la cantidad antes de hacer cualquier otra cosa.upload_media_from_urlcon las dimensiones y la duración completas.create_postcongroup_ids,per_channel,first_comment,stagger_secondsy unlabelpara la tanda, como borrador.request_approval, o pasar el trabajo a un revisor humano.- Después de la aprobación,
schedule_postpara cada publicación aprobada. - Pasada la hora de envío,
get_postsobre una muestra para confirmar la entrega, e informar cualquier fallo.
El paso 2 es el que los equipos se saltan y después lamentan. Un agente que anuncia "esta tanda apunta a 212 cuentas en 3 grupos" le da a una persona la oportunidad de decir "ese no es el grupo" antes de que exista un solo borrador.
Preguntas frecuentes
¿Publicar a través de un agente es más riesgoso que hacerlo a mano?
El riesgo es distinto, no necesariamente mayor. Un agente repite los errores a escala, mientras que una persona comete errores dispersos. Con claves acotadas, tandas que empiezan como borrador y textos variados, una tanda de un agente puede ser más consistente que el trabajo manual en muchas cuentas.
¿Cuál es el valor por defecto más seguro para stagger_seconds?
El valor por defecto de Shager es de 30 a 90 segundos entre cuentas. Ninguna red publica un espaciado ideal, así que amplíalo para grupos grandes y juzga por los resultados más que por una regla general.
¿Puedo frenar una tanda programada después de que empezó?
Sí. Las publicaciones que todavía no se enviaron se pueden retirar con cancel_post, y la etiqueta compartida de la tanda hace que sea fácil identificarlas en list_posts. Revocar la clave corta cualquier llamada posterior.
Para entender cómo tratan las plataformas la publicación de alto volumen, lee cómo evitar bloqueos por spam al publicar a escala y luego copia el reglamento de arriba en la skill de tu agente antes de su próxima tanda.
