¿Puede una IA publicar en tu web por error? Lo que nos negamos a construir
No. Y no porque tengamos cuidado, que eso no vale nada, sino por tres decisiones que están en el software. Crear contenido crea un borrador en todas las plataformas que admitimos. Publicar, despublicar, programar, los menús y las redirecciones son un permiso aparte que empieza sin marcar. Y un asistente conectado no puede pedir ese permiso: la petición se descarta antes de que llegues a ver una pantalla de aprobación, así que la única forma de que se marque es que lo marques tú. Lo que sigue es el arreglo entero, incluidas las partes que decidimos no construir.
·
Esta es la pregunta que decide si alguien puede usar un programa así en un negocio de verdad, y merece una respuesta más larga que una frase tranquilizadora. Una promesa vale lo que valga aquello que tendría que fallar para romperla.
La casilla que empieza sin marcar, y que nadie puede marcar por ti
Cuando conectas ChatGPT o Claude, se te enseña una lista de permisos con casillas. Una de ellas es "cambiar lo que ven los visitantes", y cubre publicar, despublicar, programar, editar una página que ya es pública, los menús y las redirecciones. Empieza sin marcar. Con ella sin marcar, un asistente puede leer tu web, escribir borradores, cambiar borradores, poner imágenes en tu biblioteca y proponer un cambio por lotes, y no puede alterar ni una sola cosa que un visitante vaya a notar.
Lo que convierte eso en una promesa y no en un valor por defecto es más pequeño y menos visible. Un cliente no puede pedir ese permiso. Un cliente de IA pide los permisos que quiere al conectarse, y nosotros quitamos el de publicación de lo que haya pedido, siempre, por todas las vías que un cliente puede usar. El motivo es exacto: un permiso que el cliente ha pedido se muestra en la lista de "podrá hacer" de la pantalla de aprobación, donde no hay casilla que desmarcar, así que dejar la casilla sin marcar dejaría de bastar, y ya habíamos prometido que bastaba.
El único sitio donde se lee antes de escribir
Editar contenido es el caso incómodo, porque la misma petición es inofensiva o no según sobre qué caiga. Cambiar un borrador que nadie ve es escribir; cambiar una página que alguien está leyendo es cambiar lo que ven los visitantes. Así que una edición pide el permiso de escritura, y pide además el de publicación cuando el elemento ya es público, lo que obliga a leer primero el elemento para averiguarlo, comparando su estado con la palabra propia de esa plataforma para lo publicado. Si no se puede saber en qué estado está, la respuesta es no. Una negativa que quizá sobraba es mucho mejor resultado que una edición que quizá era pública.
El único acto irreversible de todas las plataformas, y la protección que lleva
Ghost es donde esto deja de ser teórico. Una publicación de Ghost tiene miembros, y publicar una entrada puede enviársela por correo a todos ellos. Es el único acto de todos nuestros adaptadores que no se puede deshacer —un correo no se des-envía— y merecía una protección bien hecha en lugar de cuidado.
- Nada puede construir esa petición. Cada petición a Ghost se revisa buscando las palancas que provocan un correo —la moderna, en la dirección, y las antiguas, en el cuerpo— y una petición que lleve cualquiera de ellas lanza un error en lugar de fallar con educación. Se supone que nada del software puede construir una petición así, de modo que llegar a esa comprobación significa un fallo nuestro, y se trata como tal: la operación se para, no se cobra nada y queda escrito en el registro.
- Una entrada preparada para enviarse no se publica ni se programa. Si Ghost informa de que una entrada es solo para correo, o de que ya lleva un boletín asociado, la dejamos en paz. Enviarla es decisión tuya, tomada en Ghost, donde ves a quién le llega.
- Una entrada ya enviada es intocable, y "enviado" no es un destino. La única forma de producir ese estado es enviar el correo, así que se queda en la lista de estados de los que Ghost informa y se rechaza como estado al que mover una entrada.
Cuatro cosas que hemos decidido no construir
Cada una fue una decisión con fecha, no una función a medias. Están aquí porque lo que una herramienta se niega a hacer dice más de ella que lo que ofrece.
- Nada de acciones administrativas; solo lecturas administrativas. Un asistente puede informar de qué está instalado, qué necesita actualizarse y quién tiene cuenta. No puede instalar, actualizar, activar, desactivar, cambiar un ajuste ni crear un usuario. Fue la decisión de Rafael, tomada después de que le enseñáramos qué podía hacerle cada escalón de más a una web en vivo, y es la única capacidad que podría haber tumbado la web de alguien.
- Nada de automatizar el navegador, nunca. Cuando una plataforma no tiene forma admitida de hacer algo, la respuesta es que no se puede. Manejar las pantallas de administración de alguien con un navegador sin ventana rellenaría muchísimas casillas grises de nuestras tablas y se rompería la primera vez que una plataforma cambiara un botón, en la web en vivo de alguien y sin que nada quedara registrado.
- Ningún cambio por lotes sin que lo apruebe una persona. Un trabajo por lotes prepara una vista previa, enumera todas las páginas que va a tocar y espera. La aprobación es humana y se da en tu propia cuenta: no es un argumento de confirmación que pueda rellenar un asistente, que es una barrera solo de nombre.
- Nada de diseño, plantillas ni maquetación. Ni siquiera donde una API lo permitiría. Las palabras de una página se pueden revisar; una maquetación cambiada se descubre mirando tu propia web, y eso no quiere descubrirlo nadie.
Qué pasa cuando algo sí sale adelante
Todo lo que hace un asistente queda escrito —qué se pidió, qué web se tocó y qué contestó— y ese registro es de solo lectura en tu cuenta. Un trabajo por lotes se puede deshacer. Una publicación se puede devolver a borrador, que es exactamente como comprobamos que publicar funciona: publicar nuestro propio borrador, mirarlo y devolverlo. Y si quieres el permiso fuera, quita la conexión desde tu cuenta o desde ChatGPT o Claude, y no se podrá volver a pedir nada a tu web hasta que la vuelvas a añadir.
Límite honesto: hay una cosa de este arreglo que deberías saber en vez de darla por buena. El permiso de cambiar lo que ven los visitantes se separó del permiso general de escritura cuando ya había conexiones hechas, así que una conexión anterior a esa separación hay que quitarla y volver a añadirla para que publicar funcione siquiera, y en esa pantalla de aprobación la casilla sigue empezando sin marcar. Los borradores siguen funcionando sin volver a conectar nada. Preferimos contarlo a que alguien lo descubra.
Lo que nos preguntan sobre esto
- ¿Y si le digo yo al asistente que publique algo?
- Entonces lo publica, si concediste ese permiso al conectarlo. La idea no es que publicar sea imposible: es que nunca ocurre como efecto secundario de otra cosa que pediste.
- ¿Puede un asistente borrar mi contenido?
- No hay ninguna herramienta que borre contenido. Como mucho puede mover algo a un estado que los visitantes no ven, en una plataforma que lo tenga. Las entradas de menú y las redirecciones sí se pueden quitar, y las dos cosas piden el permiso de cambiar lo que ven los visitantes.
- ¿Usáis alguna vez la contraseña de mi web?
- En casi todas las plataformas no hay contraseña de por medio: un token o una contraseña de aplicación, revocables por separado. La excepción es Drupal, porque su autenticación básica usa la contraseña real de una cuenta, y por eso la página de configuración dice que crees una cuenta para esto en vez de usar la tuya.