Usted lo creó con Lovable: ¿quién es responsable cuando filtra datos?

Un product manager necesita un panel interno. En lugar de abrir un ticket y esperar un trimestre a que ingeniería lo resuelva, abre Lovable, describe lo que quiere en lenguaje natural, lo conecta al Google Workspace de la empresa y publica una aplicación funcional esa misma tarde. Lee desde Drive, extrae algunas hojas de cálculo y envía un resumen semanal por correo. Funciona. Todos contentos.

Nadie hace la pregunta que importa seis meses después, cuando un revisor de seguridad o un regulador la plantea: ¿quién es responsable de cómo esa aplicación maneja los datos que toca?

La respuesta no es la plataforma que generó el código. Es la empresa que la desplegó. Este artículo explica por qué "lo construimos con IA" no es una defensa, qué falla específicamente en las aplicaciones creadas con IA y cómo obtener visibilidad antes de que la pregunta se plantee con enojo.

Qué significa realmente "aplicación creada con IA"

Una nueva categoría de herramientas —Lovable, Base44, Bolt.new, Cursor y una lista creciente de otras— permite a las personas crear y desplegar aplicaciones web reales a partir de instrucciones en lenguaje natural. A menudo se las llama plataformas de "vibe coding". El atractivo es evidente: una persona sin conocimientos de desarrollo puede producir algo que antes requería un equipo, y puede hacerlo en horas.

Estas aplicaciones no son juguetes. Se despliegan para usuarios reales y con frecuencia se conectan a sistemas reales de la empresa —Google Workspace, Salesforce, bases de datos internas— mediante concesiones OAuth ordinarias. Desde el punto de vista de los datos, una aplicación creada en una tarde con una instrucción y una aplicación desarrollada durante meses por un equipo de ingeniería son idénticas: ambas poseen un token de acceso y ambas pueden leer lo que ese token permite.

Esa simetría es el núcleo del problema. La velocidad que hace atractivos a los creadores con IA es la misma velocidad que permite que una aplicación alcance datos sensibles sin que nadie revise qué hace con esos datos.

Crear con IA no es lo mismo que estar seguro

Conviene ser precisos y justos aquí: una aplicación creada con Lovable o Base44 no es inherentemente insegura. Estas plataformas pueden producir aplicaciones perfectamente razonables, y muchas lo son. El riesgo no es que la IA escriba código deficiente. El riesgo es de gobernanza, y se manifiesta de tres maneras previsibles.

Quien la despliega rara vez lee el código. Toda la propuesta de valor del vibe coding es que no es necesario hacerlo. Así que la persona que publicó la aplicación a menudo no puede decir cómo se almacenan los datos, si se registran campos sensibles, adónde se envía la información o cuánto tiempo se conserva algo. La parte responsable tiene la menor visibilidad sobre aquello por lo que es responsable.

El acceso es amplio e invisible. Los creadores con IA solicitan los alcances ("scopes") que hacen que la demostración funcione, y "que funcione" a menudo significa acceso de lectura amplio. Un panel interno que solo necesitaba leer una carpeta puede terminar con acceso de lectura a todo Drive. Como la concesión ocurrió mediante una pantalla de consentimiento OAuth normal, nunca apareció en el radar de seguridad de nadie: es, por definición, TI en la sombra.

No existe una política documentada de manejo de datos. Pida la política de retención de un sistema de producción construido a mano y normalmente obtendrá una respuesta. Pida la política de retención de una aplicación que un colega generó el martes pasado y no habrá nada registrado. Bajo la legislación de protección de datos, "no sabemos cuánto tiempo conserva los datos" no es una respuesta neutral: es un hallazgo.

Por qué la empresa —y no la plataforma— es la responsable

Aquí está la parte que sorprende a la gente. Cuando una aplicación creada con IA maneja mal los datos, la responsabilidad legal y regulatoria recae sobre la organización que la desplegó, no sobre el creador de IA que la generó.

Este es el mismo cambio de responsabilidad que hoy está transformando el derecho de la IA en general. Bajo el Reglamento General de Protección de Datos (RGPD) de la UE, la entidad que determina los fines y medios del tratamiento de datos personales es el responsable del tratamiento, y este carga con las obligaciones —base lícita, minimización de datos, limitación del plazo de conservación y el deber de demostrar todo ello. Cuando su empresa despliega una aplicación que procesa datos de clientes, su empresa es el responsable del tratamiento. La plataforma creadora es, a lo sumo, una herramienta que usted utilizó.

El panorama legal más amplio de 2026 apunta en la misma dirección. Los tribunales han comenzado a tratar a la empresa que usa un sistema de IA como responsable de su comportamiento —el litigio *Mobley v. Workday* en Estados Unidos avanzó bajo una teoría de agencia y posteriormente obtuvo la certificación condicional de una acción colectiva a nivel nacional. En Alemania, el OLG Hamm abordó la responsabilidad por lo que un sistema de IA les dice a los clientes y señaló que un descargo genérico de "sin garantía" no protege, por sí solo, a la empresa que despliega el sistema. La Ley de IA de la UE añade obligaciones específicas para los desplegadores, con sanciones significativas para usos de alto riesgo. Analizamos este cambio en profundidad en nuestro panorama sobre quién es responsable cuando un agente de IA filtra datos.

El hilo común: desplegar una aplicación creada con IA es una decisión que tomó su organización, y la ley trata las decisiones como portadoras de responsabilidad. El hecho de que una IA haya escrito el código no cambia nada respecto de quién decidió conectarla a los datos de la empresa.

El punto ciego, en concreto

Al unir las piezas aparece un patrón de fallo específico y frecuente:

• Un empleado sin conocimientos técnicos crea una aplicación con un creador de IA.
• La aplicación se conecta a Google Workspace mediante OAuth y se le conceden alcances amplios.
• Accede a datos personales de clientes o empleados —contactos, contenido de correos, archivos.
• Nadie revisó el manejo de datos, y no hay política de retención registrada.
• Seguridad no tiene entrada de inventario para la aplicación, porque nunca pasó por una revisión.

Cada paso es individualmente razonable. Juntos producen una aplicación que procesa datos personales, de la que su empresa es legalmente responsable, y que su equipo de seguridad no sabe que existe. Esa es la brecha que un auditor sondea y que una filtración explota.

Cómo cerrar la brecha

La solución no es prohibir los creadores con IA —esa carrera ya está perdida, y la ganancia de productividad es real. La solución es visibilidad y evidencia: saber qué aplicaciones creadas con IA están conectadas, saber a qué puede acceder cada una, y poder demostrar que las gobernó.

Eso es exactamente lo que hace 8200.dev. Descubre las aplicaciones OAuth conectadas a su Google Workspace y señala las que provienen de creadores con IA —Lovable, Base44, Bolt.new, Cursor y similares— a partir de sus firmas de nombre de aplicación y host de redirección, y del patrón revelador de una aplicación no verificada, creada recientemente, que ya posee alcances amplios. Para cada una, usted ve la plataforma creadora, los alcances exactos concedidos, quién la autorizó y una puntuación de riesgo, presentados en una vista dedicada de Aplicaciones Creadas con IA junto con el resto de sus agentes de IA y aplicaciones OAuth.

Cuando una aplicación creada con IA puede acceder a información personal identificable de clientes, o posee acceso amplio sin una política de retención documentada, genera un hallazgo específico —así la brecha se convierte en una tarea con un responsable en lugar de una sorpresa en una auditoría. Y cada aplicación creada con IA puede registrarse en el AI Agent Registry, de modo que incluso las que ningún conector alcanza aparecen en un inventario completo. Puede ver el conjunto completo de funciones aquí.

El objetivo no es frenar a sus equipos. Es asegurarse de que, cuando llegue la pregunta —de un regulador, un auditor o una revisión de seguridad de un cliente—, usted pueda responderla. No "lo construimos con IA, así que es problema de la plataforma", lo cual no es una defensa, sino "aquí está la aplicación, aquí está exactamente a qué puede acceder, y aquí está la evidencia de que la revisamos". Para una mirada más profunda sobre lo que hoy exigen los revisores, consulte qué exigen los auditores en materia de gobernanza de IA en 2026.

Crear con IA es rápido. Ser responsable de lo que se creó no es opcional. Ambas cosas se reconcilian con una sola cosa: saber a qué puede acceder realmente lo que su organización ha creado con IA.

Empiece por ver qué está ya conectado a su Workspace. Puede mapear sus aplicaciones creadas con IA, puntuar su acceso y generar su primera evidencia en el nivel gratuito —vea los planes y comience gratis.

*Este artículo es información general, no asesoría legal. Consulte con un asesor legal calificado para obtener orientación específica para su organización.*