Reportaje tecnológico | 25 de octubre de 2026. Durante años, pedirle a un asistente de inteligencia artificial que construyera una página web significaba obtener código, una maqueta o instrucciones para publicarla después. ChatGPT Sites introduce un cambio relevante: permite describir, construir, previsualizar, alojar y compartir sitios web y aplicaciones ligeras dentro de un mismo flujo de trabajo. La combinación de generación de software, edición iterativa y despliegue administrado acerca la creación de herramientas a personas que no quieren administrar servidores, sin eliminar la necesidad de pruebas, permisos ni criterio técnico.

La sorpresa no está solo en que una IA pueda producir una interfaz convincente. Está en pasar de una conversación que propone un producto a una aplicación ejecutable con URL, controles de acceso y opciones de almacenamiento. Esa transición merece analizarse sin exageraciones: un despliegue real no equivale automáticamente a un sistema auditado, escalable o adecuado para cualquier carga de trabajo.

De la captura de pantalla a una aplicación que funciona

Una captura puede mostrar una magnífica interfaz sin que existan botones funcionales, datos persistentes ni servicios detrás. Una aplicación web, en cambio, debe responder a las acciones del visitante, procesar entradas, controlar errores y conservar información cuando así lo requiera. La documentación oficial para crear Sites describe precisamente un flujo de creación, revisión, corrección y publicación. Cada URL de despliegue de Sites representa un despliegue de producción, aunque el acceso siga limitado a su propietario mientras realiza pruebas.

Esto no significa que todo sitio creado deba hacerse público. Se puede guardar una versión sin desplegarla, revisar cambios en una vista previa y después publicar la versión elegida. Al compartir, el propietario decide quién puede visitarla según las opciones disponibles en su cuenta o espacio de trabajo. Las configuraciones administradas por una organización pueden imponer restricciones adicionales.

Qué es exactamente ChatGPT Sites y dónde encaja Codex

Sites es una capacidad de ChatGPT para crear y gestionar sitios web y aplicaciones interactivas mediante instrucciones en lenguaje natural. Se puede empezar describiendo un problema, aportando datos o documentos autorizados y especificando qué deben poder hacer los visitantes. El asistente genera un proyecto, presenta una vista previa y permite introducir modificaciones sucesivas.

Codex participa en el proceso de construcción y edición de software. Se pueden preparar y probar proyectos compatibles con herramientas de desarrollo y llevarlos a Sites para su publicación. No es correcto describir cada sitio como «un GPT ejecutándose dentro de un contenedor»: normalmente hay un frontend y, cuando el proyecto los necesita y la plataforma lo admite, servicios y almacenamiento para la aplicación. Las llamadas a modelos externos pueden ser una integración adicional, no una propiedad imprescindible de Sites.

La documentación diferencia además entre el trabajo de desarrollar un sitio y el consumo de recursos al alojarlo y ejecutarlo. Crear o editar utiliza capacidad de Codex; el alojamiento, almacenamiento y tráfico están sujetos a las condiciones y límites aplicables.

Cómo se crea un sitio desde cero

  1. Definir el objetivo. Por ejemplo: un panel para registrar solicitudes y consultar su estado, una biblioteca de recursos con buscador o una herramienta de aprendizaje.
  2. Especificar usuarios y acciones. ¿Quién entra? ¿Puede crear registros, buscar, editar o exportar? ¿Qué operaciones exigen iniciar sesión?
  3. Aportar información de partida. Documentos, datos de ejemplo, diseño de referencia y reglas de negocio, siempre con permisos para utilizarlos.
  4. Describir el aspecto visual. Jerarquía de títulos, colores, diseño adaptable, accesibilidad, estados vacíos y mensajes de error.
  5. Probar la vista previa. No limitarse a comprobar que la página se ve bien: hay que enviar formularios, cambiar valores y verificar qué persiste.
  6. Pedir correcciones concretas. Es más útil indicar el problema reproducible que decir simplemente «mejóralo».
  7. Guardar una versión y revisar el acceso. Antes de desplegar, comprobar secretos, datos visibles y audiencias.
  8. Desplegar y verificar la URL. Probar como visitante autorizado, también desde un móvil y tras recargar el navegador.

Un ejemplo de petición útil sería: «Crea un sitio web de seguimiento de tareas para un pequeño equipo. Cada tarea debe tener descripción, responsable, estado y fecha. Añade filtros, validación de formularios, acceso limitado y almacenamiento persistente. Muéstrame una vista previa y guarda una versión sin publicarla todavía». La claridad del encargo ayuda a evaluar el resultado.

Ejemplo práctico: un asistente con memoria aprobada por el usuario

Imaginemos una aplicación personal de IA que puede recordar preferencias, pero que no registra silenciosamente todo lo que observa. Es un ejemplo de diseño de producto que puede construirse con Sites, siempre que la implementación elegida disponga de las funciones necesarias.

Conversación con el usuario
          |
   Detección de posible preferencia
          |
   Propuesta visible de memoria
          |
    Aprobar o rechazar
          |
  Guardar registro autorizado
          |
 Consulta posterior con auditoría

Si alguien escribe «prefiero respuestas técnicas breves», la aplicación puede mostrar una propuesta exacta: «Recordar: prefiere respuestas técnicas breves». Hasta que la persona la apruebe, no debería tratarla como memoria permanente. Tras autorizarla, la preferencia se conserva y aparece en un listado consultable.

Para comprobar que existe persistencia, no basta con que el mensaje siga visible en pantalla. Una prueba útil es aprobar la memoria, recargar la aplicación, volver a entrar y formular una pregunta que requiera consultar ese registro. También debe ser posible revocarlo o borrarlo si el producto promete control del usuario. Esta prueba demuestra el funcionamiento de esa implementación, no de todas las aplicaciones Sites.

Frontend, backend, base de datos y modelo de IA: cuatro cosas distintas

Frontend es la interfaz que aparece en el navegador: menús, tarjetas, campos, indicadores y diseño adaptable. Backend es el código del servidor que ejecuta reglas y responde a peticiones. Base de datos almacena registros entre visitas. Modelo de IA procesa entradas para generar resultados, y puede ser interno o un servicio externo cuando se dispone de una integración autorizada.

Una aplicación puede funcionar sin modelo de IA. Otra puede utilizarlo pero no tener almacenamiento. Una tercera puede necesitar una base de datos y controles de identidad para separar la información de distintos usuarios. La arquitectura debe responder a los requisitos, no al afán de añadir tecnologías.

En algunas implementaciones puede aparecer una base de datos D1 u otro servicio administrado; eso no significa que todos los Sites utilicen exactamente el mismo motor o que una captura demuestre su configuración interna. La documentación oficial indica que los Sites pueden utilizar almacenamiento persistente y que existen límites por sitio. Conviene revisar la configuración efectiva del proyecto antes de afirmar qué base o infraestructura utiliza.

Secretos del servidor y conexiones con servicios externos

Si una aplicación llama a una API de IA o a otro proveedor de pago, puede necesitar un token. Ese token no debe escribirse en el JavaScript descargado al navegador, incluirse en la URL pública ni copiarse en un repositorio. Debe utilizarse el sistema de secretos del entorno y una ruta del servidor autorizada que haga la petición.

El esquema recomendable es: navegador → endpoint del backend → proveedor externo. El servidor aplica validación, autenticación, límites de uso y control de errores. Un secreto de servidor no impide por sí solo el abuso de una API: también deben controlarse permisos, costes y volumen de peticiones.

La inferencia de IA no necesita ejecutarse en la misma máquina que sirve el frontend. Una aplicación puede estar alojada en Sites y consultar un modelo externo mediante una conexión segura. La latencia, disponibilidad, privacidad de los datos y costes de esa comunicación forman parte del diseño.

Diseño, accesibilidad y experiencia de usuario

Las herramientas de generación de software permiten conseguir interfaces cuidadas con rapidez, pero el diseño profesional requiere pruebas con contenido real y escenarios adversos. Un panel debe seguir siendo comprensible sin datos, con cientos de filas, con errores y desde una pantalla pequeña. Debe permitir navegación mediante teclado, etiquetas accesibles en formularios, contraste adecuado, avisos que puedan interpretarse y confirmación de acciones importantes.

La iteración a partir de capturas puede ayudar a corregir proporciones, tipografía y distribución, pero no debería sustituir una revisión funcional. Una aplicación bonita que pierde datos cuando el visitante recarga no ha superado una prueba esencial.

¿Cuándo conviene usar Sites y cuándo otra infraestructura?

NecesidadValor potencial de SitesQué revisar
Prototipo interactivoConstruir y compartir rápidamentePersistencia, funciones reales y alcance
Dashboard o herramienta internaIteración con datos y usuariosIdentidad, permisos y auditoría
App educativaExperiencia visual y formulariosAccesibilidad y contenidos
Aplicación con API externaFrontend y rutas de servicioSecretos, límites, gastos y fallos
Sistema empresarial críticoPuede servir para validar el productoRequisitos de cumplimiento, disponibilidad y arquitectura

Una arquitectura propia puede seguir siendo adecuada cuando se necesita control especializado de red, servicios de larga duración, requisitos regulatorios o una plataforma de ejecución no compatible. Sites no elimina el valor de DevOps ni convierte en innecesarias las revisiones de seguridad.

Privacidad: desplegado no significa público

Una de las distinciones más relevantes es entre desplegar y compartir. La documentación de Sites indica que una URL desplegada es una implementación de producción, pero un sitio nuevo permanece limitado inicialmente a su propietario y, en entornos gestionados, a administradores autorizados. Publicar para otras personas exige revisar las opciones de Share y el público elegido.

Antes de abrir el acceso, inspecciona registros, documentos incrustados, mensajes de ejemplo, permisos de aplicaciones conectadas y datos de prueba. Si el sitio permite a visitantes usar sus propias aplicaciones conectadas, el diseño debe respetar las cuentas y autorizaciones individuales. Nunca interpretes una etiqueta visual «private workspace» como prueba suficiente de todos los controles efectivos.

Costes, cuotas y límites

Según el Centro de ayuda oficial, Sites está disponible en determinadas suscripciones y espacios de trabajo. La construcción y edición consumen uso de Codex, mientras que el alojamiento y la ejecución tienen sus propios límites de uso y almacenamiento. Las condiciones pueden cambiar y los costes de una API de terceros no quedan necesariamente cubiertos por la suscripción a ChatGPT.

Antes de usarlo para un servicio comercial conviene consultar la disponibilidad del plan, las restricciones de publicación, los límites de base de datos y archivos, las políticas de retención y las condiciones de servicios conectados.

Pruebas imprescindibles antes de compartir

  1. Enviar un formulario válido e inválido y comprobar los mensajes.
  2. Recargar tras guardar datos y verificar su persistencia.
  3. Probar usuarios autorizados y no autorizados.
  4. Revisar posibles filtraciones entre cuentas.
  5. Forzar fallos de una API externa y controlar el estado de error.
  6. Inspeccionar que los secretos no aparecen en HTML, JavaScript, logs públicos ni respuestas.
  7. Comprobar el diseño móvil, accesibilidad y navegación con teclado.
  8. Validar costes, límites y protección frente a peticiones repetidas.
  9. Guardar una versión recuperable antes de desplegar cambios importantes.
  10. Verificar el acceso con la identidad real de un visitante previsto.

Qué cambia para desarrolladores, equipos y creadores

El valor de Sites reside en reducir la distancia entre idear, programar, probar y compartir. Un responsable de operaciones puede describir un panel; una docente puede preparar una práctica; un equipo de producto puede crear una herramienta interna. Los desarrolladores siguen aportando conocimiento esencial para definir permisos, datos, arquitectura, dependencias y pruebas.

La IA puede acelerar la producción de código, pero no puede convertir una especificación incompleta en una garantía absoluta de funcionamiento. Los mejores resultados nacen de instrucciones claras, pruebas reproducibles, revisiones frecuentes y una decisión consciente sobre quién podrá acceder a la aplicación.

Conclusión: el avance está en cerrar el ciclo

ChatGPT Sites no es solo otra herramienta que dibuja páginas. Su aportación consiste en ofrecer un flujo integrado para crear una aplicación real, corregirla y desplegarla con una URL administrada. Es un paso relevante hacia herramientas web más accesibles, siempre que distingamos las demostraciones visuales de la funcionalidad probada y los prototipos de los sistemas que merecen confianza.

La pregunta para evaluar cualquier proyecto no debería ser «¿lo ha creado una IA?», sino «¿funciona, protege los datos, respeta los permisos, puede mantenerse y cumple lo que promete?». Esa sigue siendo la prueba decisiva.

Documentación y fuentes oficiales