Le pedí a la IA que revisara lo que nuestro sitio dice de nosotros

Una línea de nuestro sitio anterior decía que el portal de un cliente había reducido las llamadas a la mesa de ayuda en más de la mitad. Era específica y era halagadora. También era imposible de rastrear.

Antes de relanzar base22.com, les di a agentes de IA acceso de solo lectura a nuestros registros y una sola tarea: revisar todo lo que nuestro sitio dice de nosotros. Rastrearon esa línea a lo largo de diez años de nuestros propios documentos. En 2015 apareció en una postulación a una conferencia como un beneficio que el proyecto anticipaba. Para 2017, nuestra descripción estándar del proyecto decía que el cliente lo había logrado, todavía sin un número. Cuando llegó a nuestro sitio, decía "50%+".

Nadie mintió. Lo copiamos hasta que sonó cierto. Ya no está, junto con todas las demás afirmaciones que no pudimos comprobar.

Esa verificación es la parte de la reconstrucción de nuestro sitio de la que estoy más orgulloso, y solo fue posible por la forma en que reconstruimos el sitio.

Un sitio que el software no podía leer

Desde 2019 habíamos reconstruido nuestro sitio dos veces sobre WordPress, cada vez con un tema y un constructor de páginas nuevos. Las dos veces sobrevivió el problema de fondo: el contenido era el diseño. 133 de nuestras 136 páginas eran composiciones del constructor de páginas, y más de 700 widgets dentro de ellas solo funcionaban mientras un tema en particular siguiera instalado.

Una persona puede vivir con eso. Un agente de IA no. No puede cambiar con seguridad una oración enredada con estilos y marcado de plugins, y no puede verificar una afirmación que no puede encontrar con certeza.

Nueve semanas, construido con agentes

Así que empezamos de nuevo con Payload CMS y Next.js, y lo construimos como hoy construimos software: agentes de IA para programación escribieron la mayor parte del código, y nuestros ingenieros revisaron cada cambio antes de publicarlo. Nueve semanas después del primer commit, el 30 de septiembre, base22.com hizo el cambio.

Cada pieza de contenido es ahora un registro estructurado en lugar de un diseño. Un caso de estudio tiene un reto, un enfoque y un impacto; un artículo tiene un cuerpo, autores y temas. Inglés y español son dos idiomas del mismo registro, no dos copias que se van separando. Esa estructura es lo que permite que un agente trabaje en el sitio con seguridad, y también lo hizo más rápido para todos los demás. Medido con el mismo contenido el día antes del lanzamiento (mediana de 15 páginas):

La accesibilidad no es una calificación que se alcanza una vez. Cada cambio pasa ahora por una revisión automática de WCAG 2.2 AA, y un cambio que falla no se puede publicar. También conservamos cada URL que tenía el sitio anterior, con 3,032 redirecciones que se prueban en cada cambio, para que los enlaces que la gente creó hacia nosotros durante años sigan llegando a la página correcta.

Revisándonos a nosotros mismos

La reconstrucción les dio a los agentes un sitio que podían leer. La verificación les dio una razón para leerlo.

Recibieron acceso de solo lectura a los registros que podían probar o desmentir lo que decíamos: nuestra plataforma de operaciones, que guarda nuestro trabajo registrado desde 2009; nuestro archivo de propuestas; las wikis de proyectos; y copias archivadas de nuestros sitios anteriores. Podían leerlo todo y no podían cambiar nada. Luego cruzaron 134 proyectos anteriores de 22 clientes contra el trabajo que realmente registramos:

Después revisaron cada cifra destacada del sitio anterior. El número de la mesa de ayuda no fue el único que no sobrevivió.

Lo que reemplazó esas cifras es menos llamativo y más útil: números con fecha y fuente. Los resultados de un programa público se le atribuyen a ese programa. El premio de un cliente se presenta como del cliente, logrado con nuestra ayuda. Si nos preguntas de dónde salió un número, podemos mostrarte el registro. Y nada de lo que encontraron los agentes se publicó hasta que una persona lo aprobó.

El día del lanzamiento

Los agentes no se detuvieron en el lanzamiento. Unas horas después de salir en vivo, uno de ellos estaba leyendo los registros del servidor y encontró errores que nadie en nuestro equipo había notado. Los rastreó hasta imágenes faltantes en 12 artículos y encontró la causa: un paso de la migración de contenido había borrado registros de imágenes duplicados a los que esos artículos todavía apuntaban. Revisó cada imagen rota contra la publicación original, reparó los artículos y publicó una corrección de código esa misma tarde, con un reporte de qué falló, por qué y qué cambió.

Ese es el esquema al que le confío nuestra cara pública. Los agentes trabajan con permisos de editor, nunca de administrador. Cada cambio que hacen queda versionado, se puede revertir y pasa las mismas revisiones que el de cualquier otra persona. Todo lo que dice algo nuevo sobre nosotros, ya sea una afirmación, una cifra o la descripción de una imagen, lo aprueba una persona antes de publicarse.

Si estás planeando tu propia migración

No necesitas cambiar de plataforma para empezar. Ya sea que uses HCL DX, Liferay, Contentful o Payload, tres cosas aplican igual:

1. Separa el contenido del diseño. Los agentes pueden trabajar con seguridad sobre campos, no sobre el marcado de un constructor de páginas.
2. Dales a los agentes roles, no llaves. Permisos de editor, nunca de administrador, y cada cambio versionado.
3. Apunta la IA a tus registros antes que a tus lectores. El acceso de solo lectura a datos reales convierte a la IA de redactora en verificadora.

Ahora vamos más lejos y llevaremos la creación de contenido a donde nuestra gente ya trabaja. Pronto escribiré sobre eso.

Si estás evaluando una migración de plataforma, o te preguntas qué diría tu propio sitio después de una verificación, Agenda una llamada.