Cómo publicarla y dónde quedan los datos
El proceso completo, en lenguaje llano: qué es esta aplicación, qué pasa cuando alguien la usa, dónde queda cada dato, y por qué no hay una base de datos en el servidor.
Qué es exactamente esto
Es una aplicación web que se instala en el teléfono como cualquier app, funciona sin internet, y no tiene servidor propio ni base de datos. Todo el programa —los documentos, el asistente, el autodiagnóstico, el generador— son archivos que se descargan una vez al dispositivo y desde ahí funcionan solos.
La comparación que suele aclararlo: es más parecida a una calculadora que a una red social. La calculadora no manda sus cuentas a ninguna parte ni necesita una cuenta de usuario. Hace su trabajo en el aparato. Esta aplicación funciona igual.
| Lo que muchos suponen | Lo que realmente es |
|---|---|
| Hay un servidor con una base de datos | No hay base de datos. Cloudflare solo entrega archivos, como una biblioteca entrega libros. |
| Cada iglesia necesita una cuenta o un espacio propio | No hay cuentas ni usuarios. Cada iglesia configura sus datos en su propio dispositivo. |
| Los formularios que se llenan se guardan en la nube | Los formularios se imprimen. Los de casos reales van en papel, firmados, bajo llave. |
| Hay que mantener y respaldar un sistema | No hay nada que mantener. Sin base de datos no hay respaldos, ni claves, ni caídas. |
Dónde queda cada dato
Esta es la respuesta directa a su pregunta. Hay cuatro tipos de información en juego, y cada uno vive en un lugar distinto. Ninguno vive en un servidor.
El estatuto modelo, las fichas, la guía de consejería. Son textos de estudio: no hay nada confidencial en ellos y están pensados para ser leídos. Cloudflare los sirve rápido en todo Chile, gratis.
El nombre de la iglesia, el Encargado de Protección, los teléfonos, si tiene colegio o radio. Cuando usted lo escribe en el generador, queda guardado en el almacenamiento del navegador de ese computador. No viaja por la red. Si abre la aplicación en otro equipo, aparece vacía.
Consecuencia práctica que conviene saber: llene el generador una vez, imprima los documentos, y guarde el PDF. El PDF es su respaldo, no el navegador.
Así el consejo puede llenarlo en varias sesiones sin perder lo avanzado. El informe final se imprime. El botón «Borrar respuestas» las elimina del dispositivo.
El registro de un relato de abuso, la ficha de un voluntario, un acta de medidas cautelares. La aplicación no los recibe ni los guarda: los imprime en blanco para que se completen a mano.
Esto es deliberado, y la Parte 4 explica por qué es la decisión correcta y no una limitación.
El proceso de publicación, paso a paso
Toma unos quince minutos y no requiere conocimientos técnicos. Necesita una cuenta gratuita de Cloudflare y la carpeta site descomprimida.
Cree la cuenta en Cloudflare
Entre a dash.cloudflare.com/sign-up con un correo institucional de la iglesia, no personal: la cuenta debe sobrevivir a la persona que la creó. Es gratuita y no pide tarjeta.
Abra Workers & Pages y cree un proyecto de Pages
En el menú lateral, Workers & Pages, botón Create, pestaña Pages, y elija Upload assets — subir archivos directamente. No elija la opción de conectar con Git: esa es para proyectos con código en repositorio.
Póngale nombre al proyecto
Algo como proteccion-iglesia. Ese nombre define la dirección web: proteccion-iglesia.pages.dev. Use minúsculas y guiones, sin tildes ni espacios.
Descomprima el zip y suba el contenido de la carpeta
Esto es lo único donde se equivoca la gente. Descomprima el archivo, abra la carpeta site, y arrastre lo que está dentro: los archivos index.html, ui.js, la carpeta _ds y el resto. No arrastre la carpeta site cerrada.
Si al terminar la dirección muestra una lista de archivos en vez de la portada, fue esto: subió la carpeta en lugar de su contenido. Borre y repita.
Publique y pruebe
Botón Deploy site. En menos de un minuto Cloudflare le entrega la dirección. Ábrala y compruebe cuatro cosas: que la portada se ve bien, que el buscador encuentra algo, que el asistente avanza al responder, y que en el celular aparece la opción de instalar.
Complete el generador y guarde los PDF
Antes de dar la dirección a nadie: abra el generador, ponga los datos reales de la iglesia, genere e imprima en PDF. Guarde esos PDF en el archivo de la iglesia. Ese es el respaldo real de su configuración.
Restrinja el acceso a lo que no es público
Opcional pero recomendable. En Zero Trust > Access > Applications puede exigir un correo autorizado para entrar. Es gratuito hasta cincuenta personas y no requiere base de datos: Cloudflare envía un código al correo y con eso se entra.
Mi recomendación: deje públicos la portada, el material de la congregación y el asistente —son las páginas que alguien en crisis necesita alcanzar sin trámite— y restrinja el resto.
Cuando haya cambios, vuelva a subir
Para actualizar: Create deployment en el mismo proyecto y suba los archivos nuevos. Cloudflare guarda las versiones anteriores, así que si algo sale mal puede volver a la anterior con un clic. Los dispositivos que ya tienen la app instalada reciben la versión nueva la próxima vez que abran con internet.
Por qué no hay base de datos
Cloudflare ofrece bases de datos, y sería técnicamente sencillo guardar los formularios ahí, con un espacio separado por iglesia. La recomendación es no hacerlo, y las razones no son técnicas.
Lo que se estaría creando
Una base de datos de relatos de abuso sexual de menores identificados, con nombres, fechas y palabras textuales. En la Ley 21.719, que entra en plena vigencia el 1 de diciembre de 2026, eso es dato sensible en su forma más estricta. Obliga a designar un responsable de datos, registrar los tratamientos, notificar brechas en plazo, garantizar los derechos de acceso y supresión, y sostener medidas de seguridad demostrables ante fiscalización.
Una filtración de esa base no es un incidente técnico. Es la revictimización de un niño, y el fin de la iglesia como institución de confianza.
Y la ganancia sería mínima
- El volumen no lo justifica. Una iglesia de doscientas personas maneja quizá un caso al año. Eso no necesita base de datos: necesita una carpeta cerrada.
- El papel firmado vale más ante un tribunal. Un registro manuscrito con firma y fecha tiene mejor valor probatorio que un registro digital sin cadena de custodia.
- El problema de quién administra no se resuelve con permisos. ¿Quién tendría la clave del sistema? ¿Y si el reporte es sobre esa persona? Un archivo físico con dos custodios resuelve eso mejor que cualquier configuración de accesos.
- Nadie tiene que mantenerlo. Sin base de datos no hay respaldos que revisar, claves que rotar, ni un sistema que se cae el día que se necesita.
La pregunta correcta no es dónde guardar los datos, sino si conviene tenerlos. El dato que no existe no se filtra.
Lo único que sí valdría la pena, más adelante
Si en algún momento la iglesia crece hasta que el control manual no dé, hay un caso legítimo: el registro de capacitación y el estado de las verificaciones de voluntarios. Quién se capacitó, cuándo vence, si su certificado de antecedentes está vigente. Son datos administrativos de adultos que consintieron, no relatos de víctimas, y una base de datos ahí sí tiene sentido.
Pero es una segunda etapa, no se necesita para operar, y conviene abordarla cuando exista la necesidad concreta y no antes.
Si quiere distribuirla a muchas iglesias
Aquí es donde la ausencia de base de datos pasa de ser una decisión defensiva a ser la ventaja del diseño.
Un solo despliegue sirve a todas. Publica una vez, comparte la dirección, y cada iglesia entra, completa el generador con sus datos y obtiene su propio estatuto. Sin cuentas que crear, sin espacios que administrar, sin costo por iglesia que se suma.
Y lo más importante para usted: no queda como custodio de los datos de nadie. Si mil iglesias usan esto y una tiene un caso, usted no tiene ese caso en su servidor. Ninguna responsabilidad de custodia, ninguna obligación de notificación, ninguna exposición. Con un modelo de tenant por iglesia, usted sería el responsable legal de datos sensibles de mil congregaciones.
| Sin base de datos | Con tenant por iglesia | |
|---|---|---|
| Costo | Cero, en cualquier escala | Crece con el número de iglesias |
| Administración | Ninguna | Cuentas, claves, respaldos, soporte |
| Responsabilidad de datos | De cada iglesia, sobre su propio papel | Suya, sobre datos sensibles de todas |
| Si hay una filtración | No hay nada que filtrar | Notificación, sanciones, daño a las víctimas |
| Funciona sin internet | Sí, completo | No |
| Qué pierde | Estadísticas agregadas entre iglesias | — |
Lo único que se pierde son las estadísticas agregadas. Y para un proyecto cuyo propósito es proteger a niños, esa es una pérdida barata.
Guía técnica del proyecto. Revisar junto al resto del cuerpo de documentos.