Reglas personalizadas de dots: cómo funcionan

Las reglas personalizadas definen tres cosas sobre cada acción soportada: si tu dot puede hacerla sola, si necesita tu aprobación, o si tenés que hacerla vos. Se configuran desde Customize → Custom rules, y no pueden desactivar las protecciones de seguridad de OpenAI.

Los cuatro comportamientos

Cada regla se escribe describiendo la acción y eligiendo uno de estos comportamientos:

Comportamiento	Qué significa
Tomar la acción sin preguntar	El dot actúa solo, sin consultarte
Tomar la acción si está pre-aprobada	Actúa solo cuando vos pediste explícitamente esa acción
Preguntar antes de actuar	El dot te consulta cada vez
Derivar a vos	El dot no la hace: te la deja para que la completes

Cómo se escribe una regla que sirve

El error más común es escribir reglas vagas. «No hagas cosas riesgosas» no le dice nada al dot. Una regla útil nombra una acción concreta y un comportamiento concreto.

Ejemplos que funcionan:

• «Nunca enviar emails» → bloquear explícitamente.
• «Puede leer mi calendario sin preguntar» → sin preguntar.
• «Antes de publicar cualquier cosa, preguntarme» → preguntar antes.
• «Los pagos los hago yo» → derivar.

La distinción clave: pre-aprobado no es permiso permanente

Es el punto que más se malinterpreta. Que aprobés un mensaje no le da a tu dot permiso continuo para contactar gente en tu nombre.

Si querés autorizar algo de antemano, tenés que ser específico. Para un mensaje futuro, la regla debería incluir:

• A quién va dirigido.
• Qué debe decir.
• Cuándo o bajo qué condiciones debe enviarse.

Cualquier aprobación anticipada queda limitada exactamente a lo que autorizaste, y nada más.

Lo que tus reglas NO pueden hacer

Es tan importante como lo que sí pueden. Las reglas personalizadas no pueden:

• Anular los requisitos de seguridad básicos. Cambiar una contraseña siempre queda en tus manos, sin excepción.
• Modificar Auto-review. El sistema de revisión previa a la acción es independiente de tus reglas.
• Levantar las restricciones de la investigación proactiva. En segundo plano el dot solo lee, y eso no se configura.
• Convertirse en permisos de acción. Una regla define comportamiento sobre acciones soportadas; no habilita capacidades nuevas.

El orden de las capas

Entender el orden evita frustraciones:

1. Requisitos de seguridad de OpenAI — siempre se aplican, no se desactivan.
2. Reglas integradas del dot — definen el comportamiento por defecto de acciones que necesitan confirmación, aprobación previa o ninguna.
3. Tus reglas personalizadas — se apoyan encima de las dos anteriores y las ajustan dentro de lo permitido.

Si una regla tuya parece «no funcionar», casi siempre es porque está chocando con las capas 1 o 2.

Errores frecuentes

Error	Por qué duele
Escribir reglas vagas	No son evaluables; el dot cae en el comportamiento por defecto
Definir reglas después de conectar apps	La ventana de exposición ya existió
Autorizar «en general»	Una aprobación genérica no cubre casos concretos
Dejar todo bloqueado por miedo	El dot queda inútil: no puede hacer nada sin vos
No revisar la vista de actividad	No hay forma de saber si las reglas están funcionando

Un punto de partida razonable

Si no sabés por dónde empezar:

• Lecturas: sin preguntar. Que pueda consultar tus datos es la base de que sirva.
• Todo lo que sale hacia afuera: preguntar antes. Mensajes, publicaciones, envíos.
• Credenciales y pagos: derivar a vos. Es lo que OpenAI hace igual por diseño.
• Borrado de datos e instalación de software: preguntar antes. Pueden requerir aprobación cada vez.

Después de tu primer encargo real, ajustá. Las reglas se escriben mejor sabiendo cómo trabaja el dot en la práctica que en abstracto.