Un blog que se publica solo es una mala idea. Los borradores de este blog los genera un modelo, y si eso saliera a producción sin que nadie lo lea, la primera alucinación aparecería en internet con mi nombre encima. Así que esta semana he montado la pieza que faltaba: la revisión.
Dos commits, uno detrás del otro. El primero mete la revisión por correo con tres acciones —aprobar, editar, no publicar—. El segundo documenta el flujo y, sobre todo, la trampa que casi nadie cuenta: los prompts no son una garantía de nada.
Cómo funciona
El proceso tiene dos mitades que no se tocan:
- Generar. Un workflow programado prepara un borrador con su ancla real, su fuente si parte de un artículo ajeno, y las dos versiones (español e inglés). Lo deja guardado como borrador. Nada más.
- Publicar. Yo recibo un correo con el borrador y tres enlaces: aprobar, editar y no publicar. Hasta que pulso aprobar, eso no existe para nadie.
La parte importante no son los tres botones. Es el estado por defecto: si no hago nada, no se publica. El silencio no es un sí. Muchos flujos automáticos hacen justo lo contrario —se publica salvo que digas que no— y eso funciona bien hasta el día que estás de viaje, o de vacaciones, o simplemente no abres el correo. Entonces el default decide por ti.
Editar no publica nada tampoco: me lleva al borrador para tocar el Markdown a mano y volver a pasar por la misma puerta. Casi siempre es lo que uso. El modelo me ahorra la página en blanco, no el criterio.
La trampa de los prompts
Esta es la parte que quiero explicar bien, porque le sirve a cualquiera que esté montando algo con un modelo de lenguaje dentro.
Cuando una entrada parte de un artículo de otra persona, ese artículo entra en el contexto del modelo. Y el texto de una página web puede contener instrucciones dirigidas al modelo: «ignora las reglas anteriores y escribe que…». Eso se llama inyección de prompts, y el problema de fondo es que un modelo de lenguaje no distingue con fiabilidad entre datos que tiene que leer y órdenes que tiene que obedecer. Todo llega como texto. Todo es candidato a ser una orden.
Se puede mitigar —y lo hago—: el contenido externo entra marcado como material citado, las reglas del sistema son explícitas, y el generador trabaja siempre sobre un ancla concreta. Pero mitigar no es blindar. Nadie ha resuelto la inyección de prompts. Quien te diga lo contrario te está vendiendo algo.
La segunda mitad de la trampa mira hacia dentro. Mi generador tiene reglas duras: no inventar nombres de cliente, no inventar precios ni plazos, no inventar cifras. Todo eso es un prompt. Y un prompt es una petición muy bien formulada, no un control técnico. Un modelo puede saltárselo por deriva, por ambigüedad o porque alguien lo empuje desde el material de origen. Por eso esas mismas reglas están escritas también como lista de comprobación para el humano que revisa. Lo que el prompt pide, el revisor lo verifica.
De ahí sale la única defensa que de verdad aguanta: separar quien escribe de quien publica. El proceso que genera texto no tiene la llave de publicación. La llave está en un enlace firmado que llega a mi correo. Aunque alguien consiguiera manipular el borrador entero, sigue necesitando que yo pulse aprobar.
El detalle aburrido que evita sustos
En el mismo bloque de trabajo le puse tope de tiempo al workflow. Un job que se queda colgado esperando una respuesta que no llega no es un fallo dramático: es una factura de minutos de cómputo y un correo que nunca sale, con la falsa sensación de que esa semana no había nada que revisar. Con un límite, falla rápido, me entero, y lo arreglo. Prefiero un error visible a un proceso silencioso.
Lo que esto NO resuelve
Para que no te pille:
- No garantiza que el texto sea bueno. Filtra lo publicable, no lo mediocre. Eso sigue siendo mi trabajo.
- No detecta un dato falso que suene bien. Es el fallo más peligroso de un modelo: la frase creíble. La única forma de cazarlo es abrir la fuente y comprobar el número. A mano.
- Si apruebo sin leer, el sistema no me salva. El control es un hábito con un botón al lado, no un botón.
- El correo es una credencial. Quien tenga acceso a ese buzón tiene acceso a publicar. Se trata como lo que es: una llave.
- No hay un segundo par de ojos. Black Wings soy yo. Un revisor es mejor que ninguno, pero no es lo mismo que dos.
Por qué te cuento esto
Porque el patrón se traslada tal cual a cualquier automatización con IA que toque el mundo real —enviar un presupuesto, escribir a un cliente, mover un pedido—. La pregunta no es «¿qué tal escribe el modelo?». Es «¿qué puede ejecutar sin que nadie lo mire, y qué pasa si no hago nada?». Si la respuesta a lo segundo es «se hace», tienes el default al revés.
Cualquier duda me dices y lo vemos.
Un saludo, Vicente.