Seguridad
Lo que rompe un cliente se queda en ese cliente
Construcción aparte, proceso aparte, token aparte, artefacto aparte. Y el código que escribe la IA nunca se ejecuta dentro de la plataforma: compila en un contenedor sin red y se sirve desde un proceso que solo alcanza lo que ya es público en tu web. Aquí está, pieza por pieza, cómo se sostiene y qué pasa cuando algo falla.
Las capas
Seis cosas que están en el código, no en una promesa
Cada una tiene su prueba, y la prueba consiste en intentar romperla: leer datos de otro cliente, compilar código que llame a otro servidor, marcar un pedido como pagado con un aviso falso. Lo que no aguanta el intento no se despliega.
-
Aislamiento en tres capas
Toda tabla lleva el cliente con clave ajena, el control de acceso filtra cada lectura y cada escritura, y Row-Level Security vuelve a filtrar dentro de la propia base de datos. Si una consulta se escapa de las dos primeras, la tercera devuelve cero filas, no las de otro.
-
Construcción en un contenedor sin red
El código que escribe la IA compila en un contenedor efímero: sin red, sin credenciales, con la raíz de solo lectura y un tiempo máximo. Si un cambio entra en bucle, se corta a los pocos minutos y no tumba a nadie. Y nadie instala dependencias a petición de un prompt.
-
El renderizador solo lee lo publicado: Ver cómo se publica
El proceso que sirve tu web lleva un token que solo alcanza el contenido publicado de tu cliente, corre sin una sola variable con un secreto, no escribe en disco y tiene un límite de tiempo por petición. Si el código hiciera algo raro, lo más lejos que llega es lo que ya es público en tu web.
-
Credenciales de pago cifradas: Ver la tienda virtual
Las claves de tu pasarela se guardan cifradas con AES-256-GCM, se enseñan una sola vez —después solo quedan los cuatro últimos caracteres como pista— y no salen del núcleo: ni al navegador ni al proceso que pinta tu tienda. Un aviso con la firma mal no marca nada como pagado, y queda apuntado.
-
Auditoría de todo, que nadie retoca
Quién publicó, quién revirtió, quién movió créditos, quién exportó envíos, quién entró en tu cuenta. Se escribe desde el servidor, y por la API no se crea, no se edita ni se borra, ni siendo nosotros. Lo de publicación y cobros se conserva doce meses como mínimo.
-
Copias, y dos versiones que no se borran
La base de datos y el almacén de ficheros tienen copia de seguridad, y los temas de todos los clientes se vuelcan aparte. La versión publicada de tu web y la anterior no se archivan nunca, pase lo que pase con la retención de tu plan: poder volver atrás no es un extra de pago.
Aislamiento
Tres capas, y la última vive dentro de la base de datos
El aislamiento entre clientes no se deja al código de la aplicación, porque un descuido ahí no es un fallo de estilo: es una fuga de datos. Por eso hay tres cierres, uno detrás de otro, y el primero que falle no es el último. Cada tabla lleva el cliente con clave ajena, el control de acceso filtra cada lectura y cada escritura, y Postgres vuelve a filtrar por su cuenta.
-
Negar por omisión
Sin el cliente activo puesto en la sesión, la base de datos no devuelve ninguna fila. Un descuido nuestro da una lista vacía, nunca los datos de otro.
-
También las tablas de dentro
El contenido de una página son sus bloques, y viven en sus propias tablas. Esas también llevan política: si no, una consulta directa las leería todas aunque la página estuviera cerrada.
-
Y no arranca si falta una
Al encender, la plataforma comprueba que cada tabla aislada tiene su política. Si falta una, no arranca. Un olvido no llega a producción esperando a que alguien lo note.
Lo que la IA no toca
Tres puertas, y las tres son código
Una lista blanca de carpetas que un prompt puede tocar, una lista negra por encima de cualquier configuración, y una marca por fichero que pone y quita el equipo. Gana la más restrictiva, y se comprueba dos veces: al guardar la versión y otra vez antes de compilar. El prompt es una instrucción; la puerta es código.
La IA puede cambiar
-
bloques/ · layouts/Cómo se ve cada pieza y cada página. Si el resultado no te gusta, lo descartas desde la previa y no llega a tu web. -
componentes/Las piezas auxiliares del tema y el aspecto de cada campo de formulario. Solo el aspecto: qué se pregunta y a dónde va, no. -
estilos.css · tema.jsonColores, tipografías y espaciado. El manifiesto es JSON declarativo: nada que se ejecute al construir. -
paginas/Las plantillas de entrada, categoría o producto, salvo las que el equipo haya bloqueado para ti.
La IA no toca nunca
-
comercio/Carrito, checkout, cuenta y pago. Lo que cobra vive en el núcleo, y a esta carpeta no llega ningún prompt. -
sistema/El <head> de SEO, la carga de datos y el contrato de props. Un rediseño no puede llevárselos por delante. -
Secretos y clavesEl proceso que sirve tu web no tiene ni una variable con un secreto. La IA no puede leer lo que no está. -
Otro clienteNi sus ficheros, ni su contenido, ni su saldo. Lo que se le manda al modelo sale solo de tu cliente.
Un componente que intente leer el disco, las variables de entorno o llamar a otro servidor no se construye, y el mensaje dice qué hay que cambiar. Si una propuesta toca lo prohibido, esa parte no se aplica, se te explica en tu idioma qué se hizo y qué no, y no se cobran créditos: si el modelo intentó algo que no debía, el que tiene que afinar somos nosotros.
El head es del sistema
Lo que le cuesta el negocio a tu web lo pinta el sistema, no el tema
Título, canónica, Open Graph y datos estructurados salen de sistema/, fuera del alcance de cualquier prompt. Y el envío de un formulario va al núcleo, no a la web: se valida allí contra el esquema, aunque el diseño diga otra cosa. Son las dos cosas que, si se rompen en un rediseño, no se notan hasta que deja de llegar gente.
- Un rediseño por IA no puede romper tu SEO: no llega al <head>
- Lo que está en noindex no entra en el sitemap, por definición y no por configuración
- Un formulario que no pinte un campo obligatorio no valida: es el mismo error que quitarlo
- Un envío solo se acepta si viene de un dominio tuyo, y lo que no esté declarado en el esquema se descarta
<title>Zapatillas Runner · Tienda San José</title><link rel="canonical" href="https://clinicasanjose.pe/tienda/zapatillas-runner"><meta property="og:image" content="…/zapatillas-runner-og.jpg"><script type="application/ld+json">{"@type":"Product","offers":{"price":"189.00","priceCurrency":"PEN"}}</script>Si algo sale mal
Qué pasa si se publica algo roto
No hace falta que lo notes tú, ni que nos escribas un domingo por la noche.
-
El enrutador lo cuenta
Si la versión recién publicada no arranca, o falla varias veces en sus primeros minutos, queda marcada. Una página que llega a medias también cuenta: es el fallo más corriente de un tema y no da un error visible.
5 fallos en 5 minutos
-
Vuelve sola a la anterior
El puntero regresa a la versión que estaba publicada antes. Como su artefacto ya existe, tarda lo que tarda una consulta: no se reconstruye nada.
sin intervención humana
-
Queda escrito en tu historial
Se crea una versión que documenta la vuelta, para que «seguir modificando» no parta de la rota. La fallida se queda con el motivo en su registro, para poder mirarlo.
origen: sistema
-
Y nos avisa a nosotros
El aviso sale una vez, no en bucle. Miramos el registro de la construcción y te contamos qué pasó en llano: qué hay que cambiar, no qué falló.
frontend.reversion-automatica
Y si el cambio falla antes de llegar ahí, ni siquiera se publica: una construcción fallida deja esa versión marcada con su registro de errores y no toca la que está en el aire. Un cambio tuyo nunca tira tu web.
En números
Lo que hay entre tu web y la del cliente de al lado
- capas de aislamiento entre clientes
- 3 capas de aislamiento entre clientes clave ajena · control de acceso · Row-Level Security
- credenciales en el proceso que sirve tu web
- 0 credenciales en el proceso que sirve tu web ni base de datos, ni pasarela, ni proveedor de IA
- comprobaciones de la política: al guardar la versión y antes de compilar
- 2 comprobaciones de la política: al guardar la versión y antes de compilar la misma regla escrita en un solo sitio del código
- contenedor efímero por construcción, sin red y sin credenciales
- 1 contenedor efímero por construcción, sin red y sin credenciales se crea, compila y se destruye
Preguntas
Lo que preguntan antes de confiar
¿La IA puede ver datos de otro cliente?
No. Lo que se le manda al modelo sale de tu cliente: tus ficheros de tema, el contrato de tipos y una muestra de tu contenido marcada como dato. Los ficheros de tema no se comparten entre clientes aunque su contenido coincida, y las tres capas de aislamiento —clave ajena, control de acceso y Row-Level Security— valen igual para una consulta que venga de la IA que para una del panel.
¿Quién puede entrar en mi cuenta?
Tus usuarios, con los roles que les des. Y nuestro equipo, solo para darte soporte: entra como tu usuario propietario durante una hora, con una banda permanente en pantalla y un registro de auditoría al entrar y al salir. Mientras está dentro no puede crear claves de API ni cambiar contraseñas. Un cambio que hagamos así queda con nuestro nombre, nunca con el tuyo.
¿Qué pasa si el código generado intenta hacer algo raro?
No se construye. Antes de compilar, un validador rechaza lo que un tema no necesita nunca: leer el disco, las variables de entorno, llamar a otro servidor, ejecutar código con eval, incrustar HTML sin sanear o cargar imágenes y guiones de fuera. Y si algo rodeara al validador, detrás están el contenedor sin red ni credenciales y el renderizador que solo lee su carpeta y solo alcanza lo publicado de tu cliente. Ninguna de las tres capas se da por suficiente.
¿Dónde están los datos de las tarjetas de mis compradores?
En tu pasarela —Culqi, Mercado Pago o Stripe—, no en Wixy: el pago ocurre en su página o en la del núcleo, nunca en el tema, y nosotros no guardamos números de tarjeta. Lo que guardamos son tus credenciales de pasarela, cifradas, y los avisos que la pasarela manda al núcleo. Un pedido pasa a pagado solo con lo que la pasarela ha confirmado con su firma; el mismo aviso dos veces cobra una, y un importe distinto al del pedido no marca nada y se audita.
¿Y los envíos de mis formularios?
Van al núcleo, nunca al proceso que pinta tu web, y solo se aceptan desde un dominio tuyo. La validación que cuenta es la del servidor, contra el esquema del formulario: lo que no esté declarado se descarta. Los adjuntos van a una carpeta privada, fuera de la biblioteca de medios, y se descargan con un enlace firmado que caduca en diez minutos. La IP del visitante se guarda solo si el formulario lo declara, y exportar o borrar envíos queda en la auditoría.
¿Y si la previa de mi web sin publicar se filtra en Google?
No puede. Una previa vive en un dominio aparte —nunca en el tuyo—, sale con la cabecera que le dice a los buscadores que no la indexen y pide un enlace firmado de corta duración para abrirse. Enseña contenido publicado por omisión: para ver borradores hace falta otro enlace firmado distinto, que se pide aparte. Y en tu dominio de producción no hay forma de pedir otra versión que la publicada.
¿Qué pasa si la web de otro cliente se cae o publica algo roto?
A tu web no le pasa nada. Cada cliente tiene su construcción, su proceso y su artefacto; un renderizador que se atasca se mata y se levanta otro, y afecta a ese cliente, nunca a los demás ni al panel. Y si el que publica algo roto eres tú, el enrutador lo detecta en los primeros minutos, vuelve solo a la versión anterior y lo deja escrito en tu historial.
Prueba a romperla. Vuelve como estaba en segundos.
Un sitio gratis en tunombre.wixy.app, con las mismas tres capas, el mismo sandbox y la misma auditoría que un plan de pago.