Abra un navegador. Escriba la dirección de la aplicación. Pida la tabla de clientes. La base de datos se la entrega.
Sin usuario. Sin contraseña. Y no solo para mirar: también para modificar. Eso ocurría, hasta el 15 de abril de 2025, en los sitios creados con una plataforma llamada Lovable.
Quedó anotado el 29 de mayo de 2025 en el catálogo público de vulnerabilidades que mantiene el instituto de estándares del gobierno de Estados Unidos, con el número CVE-2025-48757. El registro es acotado y conviene decirlo desde el principio: se refiere a esa plataforma y a esas versiones. Ahí, una política insuficiente de seguridad a nivel de fila permitía a atacantes remotos no autenticados leer o escribir en tablas arbitrarias de la base de datos de los sitios generados con ella.
Traducimos. La seguridad a nivel de fila —en inglés row-level security— es la regla que decide qué renglones de una tabla ve cada usuario: la que impide que el cliente A vea la factura del cliente B. No autenticado significa sin usuario y sin contraseña. Tablas arbitrarias significa cualquiera de ellas.
Quien abrió el registro lo puntuó en 9,3 sobre 10 en la escala pública que mide gravedad. El catálogo declara que su propia evaluación todavía no está hecha.
El registro clasifica la falla en una sola categoría, la 863 del catálogo internacional de debilidades de software: autorización incorrecta. Es decir, no un error de escritura del programa, sino un permiso mal dado.
Y la ficha trae una segunda frase, dentro del mismo campo de descripción: Lovable disputa el registro, porque —dice— cada cliente de la plataforma acepta una responsabilidad sobre proteger los datos de su aplicación.
No nos interesa arbitrar si Lovable tiene razón. Nos interesa lo que pasa si la tiene: la responsabilidad no se queda arriba, en la plataforma. Baja hasta quien la contrató.
Vibe coding: la etiqueta, en una línea
A la práctica se le dice vibe coding: alguien describe en lenguaje corriente la aplicación que necesita y un modelo de inteligencia artificial escribe el software. En una tarde, sin programadores y sin presupuesto. Operaciones arma un tablero de despachos. Recursos humanos, un formulario para postulantes.
La etiqueta importa poco. Importa que el resultado no es una presentación: es una aplicación viva, con dirección web y con una base de datos detrás.
Lo que encontraron no fue código feo
En un trabajo publicado el 29 de octubre de 2025, la firma de seguridad Escape reporta haber revisado más de 5.600 aplicaciones abiertas al público, dentro de un total de 14.600 elementos conectados a internet: aplicaciones, servicios, servidores y esquemas de base de datos. Cuenta más de 2.000 fallas, más de 400 claves de acceso filtradas y 175 casos de datos personales expuestos, incluidos datos de cuentas bancarias.
El desglose fino —2.038 fallas de criticidad alta, concentradas en 1.400 aplicaciones— aparece solo en la página del informe, que no muestra fecha de publicación; la consultamos el 20 de agosto de 2026.
Aclaremos ya lo que esos números no son. Son aplicaciones publicadas en internet abierto, en buena parte de aficionados y de proyectos pequeños. No son una medición de lo que ocurre dentro de su empresa, y no vamos a usarlos como si lo fueran.
Lo importante tampoco es el conteo. Es una frase de ese mismo trabajo del 29 de octubre de 2025: la mayoría de las fallas estaban expuestas sin autenticación. No hacía falta entrar. Ya se estaba adentro.
Los tipos de falla que enumeran son tres, y ninguno es de estilo de programación: claves de la base de datos recuperables desde el navegador del visitante, interfaces de conexión mal configuradas y ausencia de seguridad a nivel de fila. Lo que quedaba a la vista eran llaves de servicio de Supabase, el servicio de base de datos al que se conectan varias de estas plataformas: credenciales de administración, no de usuario final.
En septiembre de 2025, el equipo de investigación de Wiz encontró cuatro patrones. La clave de acceso viaja escrita dentro de la página, así que el visitante puede leerla. El control de quién ve qué está permisivo o apagado, así que un cliente puede terminar viendo los datos de otro. La puerta la cuida el navegador del visitante y no el servidor: quien sepa mirar, entra. Y herramientas internas —tableros de administración, ambientes de prueba— quedaron publicadas en internet, sin ninguna puerta.
Una precisión sobre la cifra de Wiz, del 18 de septiembre de 2025. En el cuerpo del informe se afirma que 1 de cada 5 organizaciones construye sobre estas plataformas. El titular, en cambio, habla de riesgos en el 20% de las aplicaciones. Es la misma cifra contada de dos maneras distintas, y solo la primera es la que el texto respalda.
Nada de esto es un problema de calidad de software. Es un problema de quién puede ver qué dato, y de quién autorizó ese permiso. Eso no lo decide un programador. Lo decide usted.
Y hay algo que ninguna de esas dos firmas puede hacer por usted. Un escaneo alcanza lo que está publicado y es alcanzable desde afuera. No le va a decir qué aplicación armó operaciones el mes pasado para uso interno, ni de quién son los datos que toca, ni con qué finalidad se recogieron. Eso no lo encuentra una herramienta: lo levanta un inventario.
El contrapeso, porque el argumento fácil aquí sería mentir
No le vamos a decir que el código escrito por una máquina sea más inseguro que el escrito por una persona. La evidencia no lo sostiene.
Maximilian Schreiber y Pascal Tippe analizaron 7.703 archivos públicos atribuidos a herramientas de inteligencia artificial y reportan que el 87,9% no contiene fallas identificables en el catálogo internacional de debilidades de software conocidas. Se publicó el 30 de octubre de 2025 en arXiv, el repositorio donde se difunden trabajos antes de la revisión por pares. Lo decimos porque en julio rechazamos otra cifra por ese mismo motivo: este dato juega en contra de nuestro propio argumento y, aun así, no lo vamos a presentar como más sólido de lo que es.
El promedio, además, esconde un rango: los mismos autores reportan entre 16,18% y 18,50% de archivos con fallas en Python, frente a entre 2,50% y 7,14% en TypeScript.
Ese dato y el de Escape no se contradicen: no miden lo mismo. Uno mira archivos sueltos en un repositorio. El otro, aplicaciones desplegadas y alcanzables desde internet. Un archivo sin defectos no es una aplicación bien configurada. El riesgo del que hablamos no nace en la línea de código: nace en el permiso.
Lo que la ley ecuatoriana ya le exige, con artículo y con plazo
Usted no necesita esperar una norma internacional para tener una obligación. La Ley Orgánica de Protección de Datos Personales, publicada el 26 de mayo de 2021, ya se la impone.
El artículo 4 define al responsable del tratamiento como quien decide sobre la finalidad y el tratamiento de los datos personales. No dice el que programó. No dice el proveedor. Dice el que decide. Ese es usted, o el directorio que preside.
El artículo 47 lista quince obligaciones de ese responsable; la número 12 le manda registrar y mantener actualizado el Registro Nacional de Protección de Datos Personales. El artículo 51 detalla qué se reporta a la Autoridad y se mantiene al día: la identificación de la base de datos o del tratamiento, la finalidad, la naturaleza de los datos, los destinatarios —incluidos encargados y terceros—, las medidas de seguridad y el tiempo de conservación.
Léalo pensando en el tablero que armó operaciones el mes pasado. Si esa aplicación trata datos de personas, es un tratamiento: entra en lo que el artículo 51 manda reportar y mantener actualizado. Es nuestra lectura del artículo, no su literal, y así se la damos. Lo que no admite lectura es lo otro: nadie reporta la finalidad, los destinatarios ni el tiempo de conservación de una base de datos cuya existencia desconoce.
Aquí hace falta una distinción que casi nadie hace, y que cambia lo que le toca a usted. Una cosa es el Registro Nacional del artículo 51, que se reporta a la Autoridad y no depende del tamaño de la empresa. Otra es el registro interno de actividades de tratamiento, que no está en la Ley sino en el artículo 38 de su Reglamento General, y que obliga solo al responsable "que cuente con cien o más trabajadores".
Si usted tiene menos de cien, ese registro interno no se lo exige el Reglamento, y no vamos a decirle que sí para vendérselo. Lo que sí se le exige, sin umbral alguno, es reportar al Registro Nacional lo que el artículo 51 enumera. Y hay algo que ninguna de las dos normas necesita imponerle, porque se lo va a imponer el calendario.
Y está el artículo 43, que es el que aprieta.
La ley pide notificar tan pronto sea posible y, como máximo, en el término de cinco días desde que se tuvo constancia del hecho, salvo que sea improbable que la vulneración implique un riesgo para los derechos y las libertades de las personas. Si se pasa ese término, la notificación debe ir acompañada de los motivos de la demora. Y término, en la técnica legal ecuatoriana, se cuenta en días hábiles.
Hay un segundo reloj que casi nunca se cita: el encargado del tratamiento tiene dos días de término para avisarle a usted.
Cinco días para explicar qué se expuso, de quién y desde qué aplicación. Ese inventario existe antes del incidente, o no existe cuando se lo pidan.
Lo que piden las normas técnicas, y hasta dónde llegan
OWASP —la fundación que publica los estándares abiertos de seguridad de software más usados del mundo— dedica el Apéndice C de su estándar de verificación de seguridad para inteligencia artificial a los controles para usar herramientas que generan código. Lo consultamos en el repositorio del estándar el 20 de agosto de 2026. Son catorce grupos de control.
Tres se discuten en un directorio, no en ingeniería.
El primero pide un documento escrito que diga cuándo se pueden usar estas herramientas, cuáles están aprobadas, qué usos quedan prohibidos y qué datos se permiten cargar en ellas.
El segundo pide que los programas automáticos corran con identidades propias y acotadas, y que no puedan aprobar, publicar ni desplegar su propio trabajo. El estándar es explícito en algo que a un directorio le suena conocido: la política sola no basta, el sistema tiene que impedirlo.
El tercero pide que cada pieza de software entregada deje constancia de dónde salió: qué modelo la escribió, en qué versión, con qué herramienta y qué persona intervino.
Qué aplicación existe. Con qué credencial se conecta. Qué rastro deja. Ninguno de los tres habla de calidad de código. Hay un cuarto grupo que sí mira el código y sus fallas, y no lo desarrollamos aquí: eso se resuelve en ingeniería, y este texto trata de lo que se decide antes.
El documento NIST SP 800-218A, de julio de 2024, dice expresamente que se dirige también a los adquirentes de sistemas de inteligencia artificial, no solo a quien fabrica modelos. El vacío no es de destinatario, es de alcance: el propio texto declara que el despliegue y la operación quedan fuera, y que sus prácticas no distinguen entre código humano y código generado por máquina. No cubre el momento en que la aplicación ya está corriendo. Ese momento, en Ecuador, lo cubre la ley.
Un paréntesis de honestidad, porque aquí se cita todo
No sabemos cuántas de estas aplicaciones viven dentro de su empresa. Nadie lo sabe: no existe una sola medición pública de prevalencia dentro de organizaciones de América Latina, y no vamos a inventarla para vender un servicio.
Los números de Escape y de Wiz no son suyos, y ya lo dijimos arriba. Escape, además, publica dos denominadores distintos en sus propias páginas: por eso escribimos 5.600 revisadas y hallazgos concentrados en 1.400, y no la resta cómoda. Tampoco publica su definición de "criticidad alta", así que no sabemos con qué criterio contó las 2.038. Wiz no divulga tamaño de muestra, así que su 20% no es auditable. Y el estudio del 87,9% tiene su sesgo: el 91,5% del código analizado sale de una sola herramienta.
Del registro CVE-2025-48757, dos advertencias. La puntuación de 9,3 sobre 10 no la puso el instituto de estándares, sino la organización que abrió el registro; el instituto declara que su propia evaluación aún no está provista. Y la disputa del proveedor consta dentro del texto oficial. No la escondemos: es, justamente, nuestro argumento.
Tres precisiones de método, porque prometimos que aquí se cita todo. El texto del CVE y el de NIST los leímos a través de un recuperador que extrae el contenido, no descargando el archivo original: nuestro entorno bloqueó ambas descargas. El Apéndice C de OWASP no lleva fecha en el propio documento y lo leímos de la rama viva del repositorio, así que puede cambiar sin aviso; por eso citamos el día en que lo leímos. Y el texto de la ley ecuatoriana sí lo contrastamos contra tres copias publicadas en línea —dos de entidades públicas ecuatorianas y una de la procuraduría de una universidad—, que coinciden literalmente; el artículo 51 solo pudo cotejarse contra dos, porque la tercera copia se interrumpe antes.
Tampoco tenemos un caso. No existe hoy una brecha corporativa con empresa identificada, notificación regulatoria y daño cuantificado que se atribuya a código generado por inteligencia artificial. No la hay, y no vamos a insinuarla con condicionales. Más aún: esa ausencia es evidencia en contra de una prevalencia alta de incidentes, no prueba de que estemos ciegos. Usar el silencio como confirmación volvería infalsable nuestra tesis, y una tesis infalsable no es análisis: es campaña de miedo. Como escribimos en julio, un número que no se puede auditar no mejora por repetirlo, por famoso que se vuelva.
Lo que afirmamos es más pequeño y más firme: existe un mecanismo documentado y existe una obligación legal con plazo. Ninguna de las dos cosas depende de que haya ocurrido un desastre.
Un apunte más, sin cifras: el modelo a veces inventa nombres de componentes de software —piezas ya hechas que los programas descargan y reutilizan— y hay quien registra esos nombres inventados para colarse dentro. A eso le dicen slopsquatting. Las tasas que circulan están en revisión, así que no las damos.
Y dos precisiones para quien le prepare el expediente. El artículo 47 no crea un registro interno de operaciones de tratamiento, como a veces se lee por ahí: es una lista de quince obligaciones, y el registro de su numeral 12 es el Registro Nacional que se lleva ante la Autoridad. El registro interno de actividades del tratamiento está en el artículo 38 del Reglamento General, y aplica desde los cien trabajadores. Segunda: revisamos si la Ley había sido reformada o renumerada desde 2021 y no encontramos ley reformatoria ni codificación posterior; lo que sí hay son resoluciones de desarrollo de la Superintendencia, que no cambian estos artículos. Aun así, esto no es asesoría legal: si va a tomar una decisión con consecuencias, que su abogado lo confirme contra el texto oficial.
Tres preguntas para la próxima reunión de directorio
En julio cerramos preguntando qué inteligencia artificial corre hoy en la organización y quién la aprobó. Estas tres son la versión operativa de aquella.
¿Qué aplicaciones construidas con estas herramientas existen hoy, quién las pidió y a qué base de datos se conectan? Si la respuesta llega por correo y tarda dos semanas en armarse, esa es la respuesta.
¿Con qué credencial se conecta cada una, y qué alcanza a ver esa credencial? Una llave de administración dentro de una aplicación hecha para un solo equipo convierte un error menor en un incidente mayor. La pregunta no es si está bien hecha; es qué puede tocar si está mal hecha.
Si mañana la Autoridad pregunta qué se expuso, de quién y desde qué aplicación, ¿en cuántos días lo tenemos? La ley concede cinco de término. La respuesta honesta a esta pregunta ya le dice si el inventario existe.
El punto
Nada de esto evita el incidente. Un inventario no es un antivirus. Hace algo más modesto y más urgente: le permite responder en cinco días, que es lo que la ley le exige.
El proveedor lo dijo por contrato: la responsabilidad sobre los datos es de cada cliente. La ley ecuatoriana lo dice por su cuenta, y desde 2021: responsable es quien decide la finalidad, haya firmado lo que haya firmado. Las dos frases apuntan al mismo sillón, pero solo una de ellas obliga.
¿Y si la Autoridad llama el lunes?
