Reconstruido en 18 días · Parte 5 de 6
El día del lanzamiento empieza el trabajo: un sitio web con un agente de IA de guardia
Después de lanzarse, la mayoría de los sitios quedan solos hasta que algo se rompe. Cómo debería ser el cuidado de un sitio cada día, semana y mes, y por qué un agente de IA puede hacer gran parte una vez que las reglas están escritas y un ingeniero revisa el trabajo.
La mayoría de los sitios web reciben su última revisión cuidadosa el día del lanzamiento. El equipo celebra, sale la factura y el sitio queda solo hasta que algo se rompe. Para entonces han pasado semanas o meses y nadie recuerda cómo se veía "funcionando".
Hace poco lanzamos un sitio de directorio y reseñas, reconstruido en 18 días. El día que salió en vivo, un agente de IA entró de guardia en él, con un ingeniero que define sus reglas y revisa su trabajo. Este artículo trata de esa segunda parte: qué implica cuidar un sitio, y por qué las reglas escritas son lo que hace que valga la pena confiarle eso a un agente.
Por qué el lanzamiento es el comienzo
Un sitio se deteriora aunque nadie haga nada mal. Contamos cómo pasa en un sitio web nunca está terminado. Un sitio de directorio y reseñas se deteriora más rápido que la mayoría, porque lo que describe vive en otra parte: las empresas que lista cambian sus ofertas, sus páginas y sus condiciones cuando quieren. Una reseña que era correcta el mes pasado puede estar mal hoy, y quien la leyó y confió en ella es quien paga.
Así que la pregunta después del lanzamiento no es "¿el sitio está listo?". Es "¿quién se da cuenta cuando deja de estar bien, y qué tan rápido?".
La rutina, por escrito
El agente trabaja con una rutina escrita. Nada en ella depende de que alguien se acuerde.
Cada día. Cuando una empresa listada cambia algo que toca el dinero del lector, el cambio entra en la página ese mismo día, con su fuente. Cuando un lector pide una corrección, se verifica contra la fuente; si tiene razón, se corrige la página y la corrección queda registrada en una página pública de correcciones. Si un build falla, se revisa el mismo día.
Cada semana. Algunas noticias, como pide el plan del dueño. El build rechaza cualquier noticia sin fuente, así que el agente no puede publicar una ni por error. Una guía escrita o actualizada, tomada de la lista de "revisión pendiente" del inventario. Una revisión de enlaces en todo el sitio, hecha despacio a propósito para que nunca parezca un ataque. Y una vigilancia de los avisos de seguridad de todo lo que usa el sitio.
Cada mes. Las páginas prioritarias se vuelven a leer contra los sitios de las propias empresas. Se actualizan los datos de cada empresa y las fechas en que se revisaron sus fuentes.
Un inventario que dice qué leer después
Detrás de la rutina hay un inventario de contenido. Cada página tiene una fecha de próxima revisión y un estado: al día, revisión pendiente, desactualizada, vacía o segunda etapa (planeada para después). El agente no decide qué mirar por ánimo ni por lo que sea más fácil. Lee la lista.
Esa lista también es la respuesta cuando el dueño pregunta "¿cómo está el sitio?". No una sensación: cuántas páginas están al día, cuáles toca revisar y cuáles esperan datos que todavía no podemos respaldar con una fuente.
Seguridad: el mismo día, no en el próximo sprint
Mientras construíamos el sitio salió un aviso de seguridad crítico para el framework sobre el que corre. El sitio se movió fuera de la versión afectada y el arreglo estuvo en vivo ese mismo día. No hubo nada ingenioso en eso. Pasó porque alguien estaba mirando, y porque las revisiones del sitio podían mostrar que la actualización no había roto nada.
Ese es el estándar después del lanzamiento también. Un aviso se lee el día que aparece, y la respuesta es "actualizado hoy" o una razón por escrito de por qué no aplica.
Por qué las reglas escritas hacen confiable a un agente
Un agente de IA librado a su propio criterio llena los vacíos con algo que suena creíble. En un sitio de reseñas, un dato creíble que no es cierto es lo peor que puede publicar. Al agente de este sitio se le confía el trabajo por la razón contraria: trabaja dentro de reglas que no puede esquivar con argumentos.
- Nunca inventar un dato. Cada dato sobre una empresa sale de las propias páginas de esa empresa, con la fuente y la fecha en que se revisó. Una página que necesita un dato que nadie puede respaldar se retiene, no se adivina. Cómo se escribe así está en escribe solo lo que puedes respaldar.
- El build hace cumplir lo más importante. Una noticia sin fuente no se publica. Esa regla no depende de las buenas intenciones de nadie.
- Los errores son públicos y se corrigen contra la fuente. Una página de correcciones le dice al lector que el sitio prefiere tener razón a parecer que la tiene.
- Una persona define las reglas y revisa el trabajo. El ingeniero lee lo que hizo el agente, cambia las reglas cuando resultan equivocadas y se encarga de lo que las reglas no cubren.
Es el mismo principio de contenido con IA que no inventa, aplicado a un sitio entero en lugar de un solo artículo. Para una empresa más pequeña, la versión semanal está en cómo mantener tu sitio trabajando cada semana.
Qué esperar de quien cuida tu sitio
Sea una persona, una agencia o un agente con un ingeniero detrás, deberías poder obtener respuestas claras a estas preguntas:
Pregúntale a quien cuida tu sitio
- ¿La rutina está escrita? ¿Qué pasa cada día, cada semana y cada mes?
- ¿Qué páginas toca revisar, y cuándo se revisó cada una por última vez?
- Cuando sale un aviso de seguridad de lo que usa mi sitio, ¿qué tan rápido se atiende y quién decide?
- ¿De dónde sale cada dato de mi sitio, y cómo se corrige uno equivocado?
- ¿Los enlaces rotos los encuentra una revisión periódica, o mis clientes?
- ¿Quién lee lo que publica una herramienta automática, antes o justo después de que sale?
Si las respuestas son vagas, tu sitio lo está cuidando la suerte. Escribimos más sobre cómo decidir qué viene después de construir en después del primer mes. La historia completa de este lanzamiento, de la auditoría a la salida en vivo, está en el caso de estudio.
Este artículo se basa en un proyecto real. Datos del cliente reservados; las cifras describen nuestro propio trabajo, verificadas contra los registros del proyecto.
Leer el caso de estudio completo →