Tu chatbot ya redacta respuestas. Tu asistente ya recomienda qué hacer. El siguiente paso obvio es que también pueda mandar el correo que esa recomendación implica — una confirmación, un recordatorio, un seguimiento. El problema es que ninguna herramienta de correo se construyó pensando en que quien aprieta "enviar" sea un modelo de lenguaje, no una persona.
Conectar cualquier API de correo a un agente es técnicamente trivial y es exactamente el problema. Sin controles de por medio, un agente con acceso a una API de envío puede mandar el correo equivocado, a la persona equivocada, las veces equivocadas — y nadie se entera hasta que el cliente contesta molesto o el dominio queda marcado como spam.
MailDog no le da a un agente "acceso a la cuenta de correo". Le da una herramienta con forma explícita: parámetros definidos, límites incorporados, y puntos de control que tú decides antes de que exista un solo envío.
Un agente que procesa correo entrante y responde de forma autónoma puede ser manipulado por el contenido de ese mismo correo — alguien le escribe algo diseñado para que el agente "obedezca" una instrucción escondida en el mensaje. Es la misma familia de riesgo que la inyección de instrucciones en cualquier sistema de IA con herramientas. La defensa no es prometer que nunca va a pasar: es diseñar la herramienta para que, si pasa, el daño tenga un techo — por eso los límites de envío, la lista blanca y la aprobación humana no son opcionales en el diseño, son la razón de ser del producto.
Esta pieza está en construcción activa, no es un producto terminado en catálogo. Lo que ya existe es la base sobre la que se apoya: aislamiento real por negocio, un contrato de envío propio (no atado a un proveedor concreto) y el vocabulario de eventos necesario para que un agente sepa qué pasó con lo que mandó. Si tu producto ya tiene un agente o un chatbot que necesita esta capacidad, escríbenos — el acceso anticipado se está dando primero a quien tiene el caso de uso real enfrente.