El listón para crear una aplicación se ha derrumbado; el de tocar datos de usuarios, no

Los responsables de plataformas de comercio electrónico me han estado preguntando lo mismo últimamente: el lado de negocio puede construir tres herramientas internas con IA en una semana, mientras que el calendario de desarrollo de TI sigue programado para el próximo trimestre. ¿Dónde está exactamente el cuello de botella?

Nuestra respuesta es un solo diagnóstico: el listón para desarrollar se ha derrumbado; el de tocar datos de usuarios, no.

Detrás de esta frase hay dos cosas que están sucediendo simultáneamente.

Bolt.new fue creado por StackBlitz y se lanzó en silencio con un simple tweet en octubre de 2024. En cinco meses alcanzó los 40 millones de dólares en ARR. Sacra y Growth Unhinged lo siguen de cerca como el producto de más rápido crecimiento en la historia (solo superado por ChatGPT). Al cierre del año fiscal 2026, el CEO de StackBlitz, Eric Simons, reveló en LinkedIn que Bolt.new ya es utilizado por tres de cada cuatro empresas del Fortune 500, y que el ARR empresarial se multiplicó por 10 interanualmente (publicación oficial de Eric Simons, cierre del año fiscal 2026). Lovable, por su parte, es un equipo con sede en Estocolmo (fundado por Anton Osika). En noviembre de 2025 cerró una ronda Serie A de 200 millones de dólares con una valoración de 1.800 millones; a finales de diciembre de 2025, su Serie B la llevó a los 6.600 millones, casi cuadruplicando su valoración en seis meses (confirmado de forma cruzada por Forbes, CNBC, Bloomberg y TechCrunch). En junio de 2026, el ARR de Lovable superó los 500 millones de dólares (reportado por Forbes y replicado por TechCrunch el 09-06-2026). Ese mismo día, Forbes citó a cuatro fuentes cercanas que afirmaban que la empresa estaba levantando una nueva ronda con una valoración de 12.000 millones de dólares (aproximadamente el doble). Herramientas como estas han logrado que crear una aplicación pase de requerir un equipo de varias personas durante meses, a una sola persona en una tarde.

Pero mientras la barrera de desarrollo se derrumba, los cuellos de botella que de verdad cuestan caro y frenan a tu empresa siguen intactos: la evaluación de transferencias internacionales de datos bajo el RGPD (Reg. 2016/679) y la LOPDGDD (Ley Orgánica 3/2018), el cumplimiento del Esquema Nacional de Seguridad (ENS, RD 311/2022) o, en el sector privado, ISO 27001, la conformidad con el Reglamento de IA de la UE (Reg. 2024/1689) para sistemas de IA generativa o de alto riesgo, la aprobación de cambios (Change Advisory Board, CAB, según ITIL 4) y la conciliación y auditoría. Estos procesos no tienen casi nada que ver con el código en sí, pero cada uno consume semanas enteras. Los generadores de aplicaciones han derribado la primera puerta: el negocio ya puede crear sus propias apps. Pero la segunda puerta —quién tiene derecho a tocar los datos de producción, quién puede modificar transacciones críticas— no se ha movido ni un milímetro.

Y aquí surge una exposición al riesgo que la mayoría de los decisores aún no ha visto venir: quien sabe construir una aplicación no necesariamente tiene la autorización para que esa aplicación toque datos de forma legal.

Un escenario real que hemos acompañado (e-commerce, datos anonimizados): el equipo de operaciones de creadores de contenido de un minorista de muebles para el hogar utilizó Lovable para construir, en dos meses, 7 herramientas internas: emparejamiento de creadores, cálculo de comisiones, seguimiento de productos virales y atribución de devoluciones. Nadie avisó a la plataforma tecnológica central. A mitad de año, durante una auditoría de TI en la sombra, descubrieron que 4 de esas herramientas estaban leyendo tablas de pedidos con números de teléfono y direcciones de envío, y 2 habían exportado datos a nubes personales. Esta es una situación habitual que los equipos de plataforma de e-commerce encontraron al hacer inventario de activos desde la segunda mitad de 2025 — no es un caso aislado.

Un escenario real que hemos acompañado (operador de telecomunicaciones, datos anonimizados): durante una sesión de repaso interno en una filial regional de un operador de referencia en España, el gerente de proyectos del centro de marketing admitió que habían usado Bolt para crear una “herramienta rápida de consulta de perfiles de cliente” que, con solo ingresar un número de teléfono, extraía el historial de cambios de plan de los últimos 90 días, el historial de quejas y las tablas de campañas recomendadas — el departamento técnico nunca lo supo. Esto chocaba directamente contra las líneas rojas del RGPD (Art. 5 — minimización de datos, Art. 9 — categorías especiales, Art. 25 — protección desde el diseño) y de la LOPDGDD en cuanto a permisos de consulta de información personal; la AEPD ha impuesto sanciones reiteradas (multas en 2024 por valor superior a 50 millones de euros solo en el sector telco) por este patrón de accesos injustificados a datos de clientes.

Primero, veamos una imagen para entender la magnitud de esta brecha.

Dos umbrales: uno cae, otro se mantiene Alto Bajo 2020 2024 2026 Altura del umbral Umbral de desarrollo (escribir código) Generador de IA: una tarde Umbral de cumplimiento (exportación de datos / MLPS / registro algorítmico / aprobación de cambios / conciliación) Apenas se movió Exposición al riesgo Brecha entre umbrales = Personas que saben crear apps Quizás no cualificados para tocar datos Desarrollo rápido ≠ entrega rápida — la línea roja inmóvil encima es el cuello de botella

A continuación, lo desglosamos: qué problema resuelven estas herramientas y para quién, cómo cambia el rol del ingeniero, cómo son las aplicaciones en la sombra que están explotando en el e-commerce, cuáles son los verdaderos obstáculos regulatorios en industrias altamente reguladas, y cómo darle al negocio un canal de cumplimiento viable.

1. Primero, pongamos estas cinco herramientas en su lugar

Mucha gente mezcla todas estas herramientas bajo el mismo saco de “programación con IA”. Pero en realidad sirven a dos públicos muy distintos, y entender esa diferencia es lo que hace que todo lo demás tenga sentido.

Un grupo son “los que ya saben escribir código”. Lo que buscan es un editor de código más rápido: que entienda el contexto de tu repositorio, que haga cambios entre archivos, que ejecute tests automáticamente, que explique errores. Los representantes típicos de esta categoría son Cursor, Trae de ByteDance, Codex de OpenAI y GitHub Copilot. La premisa es que ya eres ingeniero; la herramienta solo te quita el trabajo repetitivo. De esto ya hablamos en el cuarto artículo de la serie, así que no me voy a extender aquí.

El otro grupo son “los que no saben escribir código”. Y ese es el protagonista de este artículo: los generadores de aplicaciones. Tú describes en una frase lo que quieres, y la herramienta te devuelve una aplicación funcional: frontend, backend, base de datos y despliegue, todo incluido. No asume que sepas programar.

De esta categoría vamos a ver cuatro generadores de aplicaciones. Y de los IDE con IA, voy a sacar a Trae aparte, porque toca un punto crítico para industrias altamente reguladas.

Bolt.new (de StackBlitz). En octubre de 2024, un tuit lo lanzó en silencio. Sacra y Growth Unhinged lo rastrearon como el producto de más rápido crecimiento en la historia, solo detrás de ChatGPT: superó el millón de dólares en ARR en la primera semana, llegó a 4 millones en un mes, a 20 millones en unos dos meses y a 40 millones en cinco meses, con unos 5 millones de usuarios registrados (según cifras públicas del CEO de StackBlitz). Su tecnología subyacente se llama WebContainers, que permite ejecutar un entorno Node.js completo dentro del navegador. Así, la IA puede manipular archivos, instalar paquetes y levantar servicios directamente, sin que tú tengas que configurar nada en local. Al cierre del año fiscal 2026, tres de cada cuatro empresas del Fortune 500 ya usaban Bolt.new, y su ARR empresarial se multiplicó por 10 interanualmente (publicación oficial de Eric Simons en LinkedIn al cierre del FY2026). StackBlitz cerró una ronda Serie B de 105,5 millones de dólares en enero de 2025, con una valoración de unos 700 millones (según Business Insider y otros medios). El uso típico es crear una app pequeña o una landing page que se puede abrir y probar al instante.

Lovable (fundada en Estocolmo, Suecia, por Anton Osika, con raíces en el proyecto open source GPT Engineer). Su propuesta va de “una frase a una aplicación completa y desplegable”, posicionándose más cerca de la aplicación de negocio full-stack que Bolt. En noviembre de 2025, cerró una ronda Serie A de $200M con una valoración de $1.8B; a finales de diciembre de 2025, una Serie B de $330M elevó su valoración a $6.6B — casi cuadruplicando su valor en seis meses. En junio de 2026, su ARR superó los $500M (reportado por Forbes el 2026-06-05, con cobertura simultánea de TechCrunch). El mismo día, Forbes citó a cuatro fuentes cercanas afirmando que la empresa estaba en conversaciones para una nueva ronda de financiación con una valoración de aproximadamente $12B (casi el doble; Forbes/Rashi Shrivastava). Entre sus clientes empresariales ya figuran Workday, Asana y NVIDIA (resumen de ARR.club 2026).

Vercel v0. Lanzado en octubre de 2023, el 3 de febrero de 2026 pasó oficialmente de v0.dev a v0.app, evolucionando de un generador de componentes de UI a un generador de aplicaciones full-stack (runtime en sandbox + integración con GitHub + integración con bases de datos Snowflake/AWS). En marzo de 2026, Vercel reportó oficialmente más de 6 millones de desarrolladores usuarios y aproximadamente 80 000 equipos activos mensuales (los analistas de la competencia estiman un ARR de unos 42 millones de dólares, según el resumen de Taskade de marzo de 2026).

Replit Agent 4. Lanzado el 13 de marzo de 2026, es la actualización más importante en la historia de Replit. Tres cosas cambiaron a la vez: ① Design Mode se convirtió en Infinite Design Canvas, permitiendo diseñar y modificar código simultáneamente; ② la colaboración pasó del modelo fork-and-merge a “mismo proyecto, tareas multi-hilo” — múltiples sub-agentes ejecutan en paralelo y un sub-agente de resolución de conflictos fusiona automáticamente los resultados. Dato oficial: Agent 4 resuelve automáticamente el 90% de los conflictos de fusión (reportado por AlphaSignal en 2026, confirmado en el changelog oficial de Replit de marzo de 2026); ③ la planificación y la ejecución ya no son secuenciales: se puede planificar mientras se ejecuta. En el mismo período, Replit cerró una ronda Serie D con una valoración cercana a los $9 mil millones (reportado por Atal Upadhyay en 2026; corroborado por múltiples fuentes como TechCrunch y Bloomberg). Replit nació como un entorno de programación en línea, por lo que la colaboración y el hosting son parte de su ADN. Con Agent 4, “varias personas trabajando juntas en un producto” se ha comprimido a una velocidad cercana a la del trabajo individual.

Lo que estos cuatro tienen en común: reducir el costo de “crear una aplicación” de equipo-mes a individuo-hora.

Hablemos de Trae por separado, porque para empresas de telecomunicaciones, finanzas y comercio electrónico representa un riesgo de proveedor muy concreto. Trae tiene la forma de un IDE (editor de código), pero en la práctica es un entorno de desarrollo atado a los servidores de ByteDance. Para una empresa, no debe tratarse como un “IDE normal”, sino como una “herramienta de transferencia internacional de datos” y someterse a una evaluación de acceso bajo el RGPD Art. 46 (SCC / cláusulas contractuales tipo) y la LOPDGDD. ByteDance lo lanzó en enero de 2025, compitiendo directamente con Cursor, con una estrategia de ofrecer gratis modelos de gama alta como Claude y GPT-4o. En 12 meses alcanzó los 6 millones de usuarios registrados, 1,6 millones de usuarios activos mensuales y generó en total unos 100.000 millones de líneas de código (recopilación de la encuesta de OpenAI Tools Hub, mayo de 2026). Pero en julio de 2025, el investigador de seguridad segmentationf4u1t publicó el proyecto telemetry_research, demostrando que incluso si desactivas la telemetría en la configuración, Trae sigue transmitiendo datos en segundo plano a servidores de ByteDance como mon-va.byteoversea.com — incluyendo información de hardware, versión del sistema operativo, identificadores persistentes de dispositivo y máquina, y datos de actividad del proyecto; un solo lote de telemetría puede alcanzar los 53.606 bytes, y unos 7 minutos de uso normal generan más de 500 llamadas y aproximadamente 26 MB de datos (datos de primera mano de GitHub segmentationf4u1t/trae_telemetry_research, reportado por The Register/Cybernews el 28 de julio de 2025).

La respuesta posterior de ByteDance merece ser documentada. En la actualización del 2026-08-01, Cybernews escribió: el comunicado oficial de ByteDance admite que el interruptor de telemetría en la configuración del IDE solo controla la telemetría de la parte del framework de VS Code; la recopilación de datos de otras herramientas de Trae no se ve afectada por este interruptor — dicho en cristiano: creías que lo habías desactivado, pero no fue así. Tras contactar directamente al equipo de Trae, los investigadores confirmaron que un Privacy Mode independiente está planeado para lanzarse alrededor de agosto de 2026. Mientras tanto, el “token-based paywall” de Trae en febrero de 2026 rompió la promesa de “forever free”, lo que llevó a muchos desarrolladores que lo habían integrado en entornos de producción a reevaluar su uso (según el resumen de la encuesta de OpenAI Tools Hub de mayo de 2026).

Para desarrolladores individuales, el Claude gratuito es bastante atractivo. Para ti, que tomas decisiones, esto es un problema típico de cumplimiento en la transferencia internacional de datos: tus ingenieros están alimentando código de la empresa, y posiblemente configuraciones e interfaces, a una herramienta que puede enviar datos a los servidores de ByteDance. En industrias como telecomunicaciones y finanzas, sujetas al RGPD, la LOPDGDD y la supervisión de la AEPD (que en 2024 elevó el importe total de sanciones por encima de los 50 millones de euros solo en el sector digital), este simple paso ya es suficiente para desencadenar un incidente de cumplimiento: el RGPD Art. 83 prevé multas de hasta el 4 % del volumen de negocio anual mundial o 20 millones de euros, lo que sea superior. La sección 4 profundizará en este tema.

2. El desarrollo reescrito: de “escribir código” a “revisar, orquestar y custodiar”

Los generadores de aplicaciones suelen malinterpretarse como “ya no necesitaremos ingenieros”. Esa lectura va en la dirección equivocada.

La formulación correcta es esta: lo que cambian es el centro de gravedad del trabajo del ingeniero, no la existencia del puesto. Cuando la IA y el personal de negocio pueden producir código y aplicaciones, el valor del ingeniero se desplaza de “escribir yo mismo” a tres tareas: revisar si lo producido es correcto, orquestarlo en sistemas fiables, y custodiar la seguridad y la calidad.

Estas tres tareas son más escasas que “escribir código”, y también más valiosas. Gente capaz de escribir un componente de React hay en abundancia; gente capaz de juzgar si una aplicación promocional generada por IA puede salir a producción tocando datos de pedidos, si su autenticación es real o simulada, o si está enviando logs a servicios fuera del país — eso escasea mucho más.

Conviene aquí hacer una distinción por niveles, porque demasiadas empresas caen en los extremos: o se le confía todo al generador, o se prohíbe todo de plano. Ambos extremos salen caros.

Qué apps se pueden dar al generador, cuáles nunca Baja complejidad ←────────────→ Alta complejidad Sensibilidad de datos: baja ↑ alta ↓ Entrégalo al generador con confianza Landing pages, páginas de campaña Paneles internos sin datos sensibles (sin login, solo lectura) Prototipo / demo Requiere: datos anonimizados + canal de cumplimiento Pruébalo, pero el equipo de ingeniería toma el relevo Herramientas internas de operaciones (tocan pedidos / inventario) Puesto de trabajo del gestor de cuentas Backend de autoservicio B2B Requiere: prototipo del generador, reescritura por ingeniería para producción El generador construye, la gobernanza atrapa Frontend de base de conocimiento de atención al cliente Páginas de consulta con datos personales Portales internos con login (identidad de usuario + niveles de permiso) Requiere: autenticación, auditoría, MLPS — sin excepciones Nunca se lo des al generador Sistemas de trading / pago / liquidación Motor de riesgo / antifraude Contabilidad central / reportes regulatorios Requiere: equipo de ingeniería profesional, controlado de extremo a extremo Criterio: eje x = complejidad lógica, eje y = si toca dinero o datos personales

Lo que este gráfico quiere transmitir se resume en una frase: el eje horizontal mide la complejidad lógica de la aplicación; el vertical, si toca dinero o datos personales. En la celda inferior derecha (alta complejidad + alta sensibilidad), por muy listo que sea el generador de aplicaciones, no le toca entrar. Una landing page promocional se la puedes dejar a Lovable sin problema; tu pasarela de pagos — ahí solo es cuestión de tiempo que algo falle.

Grábate esa línea roja, y luego mira lo que está pasando en el comercio electrónico.

3. El verdadero dolor del comercio electrónico: las aplicaciones fantasma se topan con los datos de pedidos

Alejemos un momento la cámara y veamos primero una cifra que Gartner publicó en el segundo semestre de 2025: para finales de 2026, el 40% de las aplicaciones empresariales incorporarán agentes de IA específicos para tareas, frente a menos del 5% en 2025 (predicción oficial de Gartner, replicada por Process Excellence Network el 27-08-2025). Acompañando esto hay otro dato aún más llamativo: Gartner reporta que entre el Q1 2024 y el Q2 2025, las consultas empresariales sobre sistemas multi-agente crecieron un 1445% — es el tema de más rápido crecimiento en la unidad de asesoría en IA de Gartner, sin excepción (fuentes consolidadas: RAPIDCLAW, Hendricks.ai, Arion Research).

Traduzcamos estas dos cifras al lenguaje del comercio electrónico: el 40% de las aplicaciones empresariales ejecutarán agentes de IA, acompañado de otro dato—las consultas sobre sistemas multi-agente empresariales han crecido un +1445% (según el incremento en consultoría de IA de Gartner, no en despliegues, pero la señal direccional es clara): los agentes de IA han pasado de “ayudar a escribir código” a “varios agentes colaborando entre sí para completar flujos de negocio completos”. Cuando los agentes de IA comienzan a implementarse en aplicaciones empresariales, accediendo a datos, ejecutando procesos y registrando logs, la naturaleza del generador de aplicaciones evoluciona de “herramienta” a “sistema”.

Informe de 2025 de la firma de investigación UpGuard (State of Shadow AI, cubierto por Cybersecurity Dive) arroja dos cifras que llaman más la atención que el 40% de Gartner: más del 80% de los empleados usan herramientas de IA no aprobadas en el trabajo, y casi el 90% dentro de los propios equipos de seguridad lo hace también. Otro dato: cerca de la mitad de los empleados admite haber pegado información confidencial de la empresa directamente en estas herramientas no autorizadas. Mimecast da un 51%, Teramind un 49% — cifras consistentes. Gartner, por su parte, señala que el 69% de las organizaciones sospecha o confirma que sus empleados usan herramientas de IA prohibidas, mientras que solo el 37% cuenta con una política formal de uso de IA (según The Hacker News).

Traduzcamos estas cifras al lenguaje del e-commerce: tus equipos de operaciones, marketing y planificación de campañas están usando herramientas como Bolt, Lovable o v0 para construir sus propias aplicaciones. Configuradores de reglas promocionales, paneles de selección de influencers, miniprogramas de consulta de inventario, herramientas de gestión de tickets postventa. Son rápidas, útiles y resuelven problemas reales. También, casi todas, pasan por alto por completo TI y la gobernanza de datos.

1S 2026: cuatro cifras muestran la urgencia 5% Aplicaciones empresariales 2025 con agentes de IA integrados 40% Pronóstico 2026 Gartner 2025-08 +1445% Consultas empresariales Multi-agente 2024T1→2025T2 80%+ Empleados que usan herramientas de IA no aprobadas (UpGuard 2025) ~50% Empleados que pegan datos confidenciales en esas herramientas Aplicaciones empresariales con agentes + empleados usando IA a escondidas = las apps en la sombra seguirán creciendo Ventana de los decisores: 3-6 meses Aviso de Gartner: define ya tu estrategia de agentes de IA o los competidores más rápidos te dejarán atrás Los datos son representativos; las metodologías varían, la dirección es coherente

Un caso real que hemos acompañado (e-commerce, datos anonimizados): desde la segunda mitad de 2025, al hacer inventario de shadow IT en 4 empresas medianas de e-commerce (equipos de plataforma de 50 a 200 personas), ninguna salió limpia. El caso más típico fue una tienda de artículos para el hogar: en dos meses, el equipo de creadores de contenido se armó 7 herramientas internas con Lovable, 4 de ellas leían tablas de pedidos en curso (con teléfono y dirección de envío), y 2 exportaban datos a nubes personales. El día del inventario, el responsable de seguridad soltó: “Por poco no dejamos que el inventario siguiera adelante — teníamos miedo de que lo que encontráramos nadie quisiera asumirlo.”

A esto se le puede llamar “shadow IT de datos”. Durante más de una década, el shadow IT que nos dolía era el de los departamentos de negocio comprando su propio SaaS (ventas con su CRM, marketing con su herramienta de emailing). Ahora el shadow IT son aplicaciones que los propios departamentos construyen. Se usa una herramienta no aprobada — y peor aún: se genera un sistema nuevo que toca datos sensibles y que tampoco figura en el inventario de activos de TI.

La diferencia está en la escala: comprar un SaaS es conectar un sistema externo; usar un generador de aplicaciones es hacer crecer, dentro de tu empresa, un montón de sistemas nuevos de la nada, cada uno con sus interfaces de datos, cada uno potencialmente accesible desde internet. En un año, una empresa de e-commerce puede acumular más de cien aplicaciones así, y ninguna aparece en el inventario de TI.

Esto no se puede tapar. El 80% que menciona UpGuard ya demuestra que la prohibición no funciona. La gente va a buscar la herramienta más cómoda para sacar el trabajo adelante; eso es naturaleza humana, y también es el KPI. Así que no preguntes “cómo hacemos para que el negocio no use generadores”, la pregunta correcta es “cómo hacemos para que los usen de forma segura”. La sección cuatro habla de los requisitos de cumplimiento, y la quinta, de cómo habilitar los canales.

4. ¿Cuáles son los requisitos de cumplimiento? No los trates como un test

Esta es la sección que más merece la pena aclarar en este artículo, y también la más fácil de escribir mal.

Mucha gente que viene de empresas de internet, cuando habla de “control de calidad”, asume automáticamente que se refiere a las pruebas automatizadas del CI/CD: correr unit tests, integración, regresión, y si la luz está en verde, se despliega. Los equipos técnicos de e-commerce que gestionan picos de tráfico conocen bien este flujo.

Pero en telecomunicaciones, banca, manufactura regulada y e-commerce, “verificación” va mucho más allá de los tests. Los cuellos de botella reales son varias etapas que casi no tienen relación con el código en sí, pero que consumen semanas cada una. Reducir esto a “pruebas” es un sesgo de internet, y puede llevar a los decisores a subestimar gravemente los plazos de entrega.

Vamos una por una.

Evaluación de la transferencia internacional de datos.[^1] Si tu aplicación utiliza servicios de IA en el extranjero (muchos generadores funcionan con OpenAI o Anthropic en el backend, o con modelos europeos como Mistral AI / Aleph Alpha), o si tus ingenieros usan herramientas como Trae, un IDE que puede enviar datos fuera del EEE, y esos datos incluyen información personal o categorías especiales, se activan los requisitos de exportación de datos del RGPD (Art. 44-50) y la LOPDGDD. Completar una evaluación formal de impacto (Transfer Impact Assessment, TIA) o firmar Cláusulas Contractuales Tipo (SCC) puede llevar desde uno o dos meses hasta más de seis meses — la AEPD resolvió en 2024 (procedimiento EDPB Schrems II post) que las SCC por sí solas no bastan para transferencias a países sin decisión de adecuación y exige medidas suplementarias. El hallazgo de que Trae seguía transmitiendo datos incluso con la telemetría desactivada demuestra que, aunque creas que no se están enviando, en realidad sí se envían. Este tipo de herramientas no deberían ni siquiera entrar en el entorno de desarrollo en sectores altamente regulados: la AEPD ha reiterado que el responsable del tratamiento responde aunque el tratamiento lo ejecute un proveedor (RGPD Art. 28).

Esquema Nacional de Seguridad (ENS) y, en el sector privado, ISO 27001.[^2] El Real Decreto 311/2022 (ENS, categoría obligatoria para el sector público español) establece tres Categorías: Básica, Media y Alta. Una aplicación orientada al público con datos personales cae típicamente en Categoría Media o Alta, lo que implica auditoría formal, certificación de conformidad y evaluación continua. En el sector privado, donde el ENS no es directamente obligatorio, la norma de facto es ISO/IEC 27001 con su SGSI, complementada por el Esquema Nacional de Ciberseguridad (Real Decreto 311/2022 — transposición NIS2). El proceso completo —categorización, declaración de conformidad, auditoría y certificación— suele tardar de tres a seis meses. Esto es un requisito legal para el sector público y un requisito de mercado para el privado (licitaciones, contratos con la Administración). Que tu aplicación de IA se haya desarrollado rápido no te exime de cumplir con esta normativa.

Reglamento de IA de la UE (EU AI Act, Reg. 2024/1689) y evaluación de conformidad.[^3] Si tu aplicación está dirigida al público y utiliza IA generativa (por ejemplo, para generar automáticamente descripciones de productos, respuestas automáticas de atención al cliente o recomendaciones personalizadas con contenido generado por IA), te aplica el Reglamento de IA de la UE: la AEPD es la autoridad competente para la supervisión de los sistemas de IA de alto riesgo en materia de datos personales. Las prohibiciones del Art. 5 entraron en vigor el 2 de febrero de 2025; el resto de obligaciones (incluida la evaluación de conformidad para sistemas de alto riesgo del Anexo III) se aplican plenamente desde el 2 de agosto de 2026. Lanzar la aplicación sin haber completado la evaluación de conformidad obligatoria o sin notificar incidentes graves es una infracción grave: las sanciones pueden alcanzar 15 millones de euros o el 3 % del volumen de negocio anual mundial.

Aprobación de cambios (CAB) y plan de reversión.[^4] En los sistemas centrales de banca y telecomunicaciones en España, cada despliegue debe pasar por la aprobación del Change Advisory Board según ITIL 4 Change Enablement: evaluación de impacto, plan de reversión y confirmación de la ventana de mantenimiento. En entidades sujetas al Banco de España (Circular 4/2020 sobre riesgos operativos y tecnológicos) y a la CNMV, este proceso es supervisado directamente; las entidades significativas bajo la transposición de NIS2 (Real Decreto-ley 7/2025 y desarrollo normativo posterior) deben documentar cambios sobre sistemas esenciales con la misma profundidad. Este proceso consume tiempo de calendario, no tiempo de máquina; si no se llega a la ventana, se espera a la semana siguiente.

Conciliación y auditoría.[^5] En las campañas de picos de ventas del comercio electrónico o en la liquidación y compensación financiera, tras el despliegue hay que conciliar con los fondos y con los sistemas upstream, y contar con registros de auditoría que permitan rastrear cada operación. El RGPD Art. 30 (registro de actividades de tratamiento) y el Art. 5.2 (responsabilidad proactiva — accountability) son el marco general; en el sector financiero español, la Circular 1/2024 de la CNMV y las directrices de la EBA sobre governance de TIC imponen trazabilidad reforzada. Las aplicaciones generadas por IA suelen ir desnudas en este aspecto: funcionan, pero no tienen conciliación diseñada, y ante una discrepancia contable no hay forma de rastrear el origen.

Si ponemos todo esto sobre la mesa, surge una conclusión contraintuitiva: los generadores de aplicaciones aceleran el paso de “idea” a “prototipo funcional” en un orden de magnitud, pero del “prototipo funcional” al “despliegue conforme” no ahorran ni un minuto. Esos controles siguen tardando lo mismo que antes.

Esa es la línea roja que no se movió en el gráfico de la primera sección. La barrera del desarrollo se ha derrumbado, y lo que se ahorra es el tiempo de los ingenieros escribiendo código; la barrera del cumplimiento no se ha movido, y las evaluaciones, certificaciones y aprobaciones siguen llevando los mismos días. El mayor error de los decisores es creer que la aceleración de lo primero arrastra automáticamente a lo segundo. No es así.

5. Dale al negocio un carril de cumplimiento, no lo dejes crecer sin control

Ya que no se puede bloquear, hay que darle un cauce: es una de las pocas vías viables para gobernar el shadow IT.

Dos caminos para el shadow IT: si no puedes bloquearlo, dale un canal Hoy: crecimiento salvaje Operaciones crea apps con Lovable por su cuenta ↓ nadie lo sabe Toca pedidos / teléfonos / direcciones ↓ sin registro Datos exportados a nubes personales ↓ sin escaneo Solo se descubre tras una brecha Cientos de apps en ejecución, ninguna en el inventario Con gobernanza: un canal rápido La empresa facilita un generador sancionado ↓ auto-registro (5 minutos) Datos escalonados: solo anonimizados / de prueba ↓ escaneo de seguridad automático Toca datos sensibles → evaluación de exportación + MLPS ↓ al inventario Auditable, desconectable, trazable El negocio sigue siendo rápido, pero cada app está en la lista

Para construir ese cauce, hay cuatro pasos.

Primer paso: la empresa proporciona su propio generador evaluado y seguro. En lugar de que las operaciones salgan a usar cualquier Lovable externo, la empresa debería adquirir o construir internamente una versión que cumpla con la normativa de seguridad (ENS Categoría Media/Alta si opera con datos de Administraciones Públicas, o ISO 27001 con SGSI maduro en el sector privado) y que aloje los datos en territorio del EEE bajo un proveedor con decisión de adecuación o SCC firmadas, ofreciéndola a través de un portal interno. Si al equipo de negocio le resulta cómodo usarla, no buscará alternativas externas — esto es la “válvula de escape” además de la “barrera”. Microsoft FY26 ofrece un modelo de referencia: EY desplegó Copilot para 150,000 empleados y logró un 15% de ganancia en productividad; Atos lo implementó para 56,000 empleados en 54 países, gestionando 19,000 agentes de IA bajo un plano de control unificado de identidad, seguridad, cumplimiento y gobernanza de agentes (blog de revisión de Microsoft FY26, 2026-07-28; comunicado oficial de Atos, 2026-06-09; ambas son declaraciones conjuntas de proveedor y cliente). En España, Telefónica ha desplegado un modelo equivalente: su programa interno AI Assistant (anunciado en 2024) opera sobre infraestructura Microsoft Azure con residencia en la UE y un plano de control propio que integra seguridad, cumplimiento y gobierno de IA — un caso válido de canal autorizado (sanctioned channel). Lo que EY, Atos y Telefónica tienen en común: integraron las herramientas de IA en el plano de control de seguridad y cumplimiento a nivel empresarial — ejemplos vivos de un canal autorizado. En España, se puede comparar con la Guía de cumplimiento para aplicaciones de IA en el sector financiero del Instituto Nacional de Ciberseguridad (INCIBE), o con los canales de cumplimiento que el Banco de España está promoviendo para entidades supervisadas — la vía de localización ya está en marcha; lo que falta es incorporarla como un proceso obligatorio dentro de la empresa.

Segundo paso: registro obligatorio. Quién creó la aplicación, qué datos lee y a qué usuarios está dirigida: todo va a una tabla de registro. El registro debe ser ligero: un formulario de cinco minutos, no un proceso que tarde dos meses, porque si no, nadie lo llena y volvemos a las sombras. El objetivo del registro no es aprobar cada aplicación, sino tener un inventario.

Tercer paso: clasificar y derivar según el nivel de datos. Usa la matriz de la sección dos. Lo que solo toca datos anonimizados o de prueba se aprueba automáticamente; en cuanto se solicita acceso a pedidos reales o información personal, se activa automáticamente la revisión previa de transferencia transfronteriza de datos y la evaluación de seguridad de nivel (equivalente a una evaluación de cumplimiento de seguridad de la información). El proceso sigue la sensibilidad de los datos, no un enfoque único para todas las aplicaciones.

Cuarto paso: escaneo de seguridad automático. Las aplicaciones generadas por IA presentan una tasa de vulnerabilidades significativamente mayor que el código escrito por humanos. El informe de CodeRabbit de 2026 actualizó esta cifra: el número de problemas (incluyendo bugs de lógica y corrección) en código asistido por IA es 1,7 veces mayor que en código escrito tradicionalmente (métrica propia de CodeRabbit, con sesgo comercial; corroborado por el webinar conjunto con DORA de febrero de 2026 y la evaluación comparativa de Kunal Ganglani de 2026). El informe de Veracode de 2025 sobre seguridad en código GenAI es aún más contundente: en su muestra evaluada, aproximadamente el 45% del código generado por IA contiene vulnerabilidades de nivel OWASP Top 10 (la tasa de fallos en código Java generado supera el 70%; métrica propia de Veracode, con sesgo comercial). Un análisis empírico a gran escala de repositorios públicos de GitHub (arXiv:2510.26103) respalda la misma dirección. Por lo tanto, el escaneo es un paso obligatorio, no opcional, para aplicaciones generadas por IA. Integra SAST, escaneo de dependencias y escaneo de secretos en el pipeline de publicación del generador: solo se libera si todo pasa en verde. CodeRabbit, en junio de 2026, fue confirmado empíricamente como la herramienta de revisión de código con IA más instalada en GitHub/GitLab, con más de 15.000 clientes de pago y 6 millones de repositorios revisados. Incluso Jensen Huang, CEO de NVIDIA, lo respaldó públicamente: “Toda NVIDIA usa CodeRabbit”. Considerarlo como una referencia de línea base para el control de calidad de código con IA a nivel empresarial es razonable.

Estos cuatro pasos apenas redujeron la velocidad del lado de negocio, pero cada aplicación quedó registrada en una lista auditable, y las que tocaban datos sensibles fueron detenidas para pasar por una evaluación formal. Eso es gobernanza, no freno.

Aquí conviene aclarar una cifra que se ha citado mal. En el borrador original aparecía un “45 % de adopción de IA en la sombra”, pero esa atribución es incorrecta. El 45 % es la tasa de defectos en código generado por IA según el informe de Veracode, no una tasa de adopción de herramientas; la adopción de IA en la sombra se mide con el 80 %+ de UpGuard. Son dos métricas que hablan de cosas completamente distintas, no las mezcle.

6. Cuándo no usar generadores de aplicaciones

No son una bala de plata. Hay cuatro usos indebidos típicos, y los hemos visto todos en clientes a los que hemos prestado servicio.

Para transacciones críticas o control de riesgos. Este es el más peligroso. Algunos piensan: “si el generador es tan potente, probemos con la pasarela de pagos”. En la matriz anterior, la esquina inferior derecha es zona roja: lógica compleja y manejo de dinero, entregárselo al generador equivale a poner el sistema central en manos de un becario que no rinde cuentas. Si ocurre un incidente de fondos, no hay conciliación, ni auditoría, ni plan de reversión.

Default AI-generated code is safe. CodeRabbit’s 1.7x and Veracode’s 45% figures already answer that. Between an AI-generated app that “looks like it works” and one that “works safely” lies an entire discipline of security engineering. Treating AI-generated applications with lower security standards than human-written ones is just a recipe for creating more vulnerabilities at a faster pace.

Using a foreign content generator to process personal information without a data-export assessment. This is especially common in e-commerce: a marketing campaign creates a C-facing event page, the backend calls OpenAI to generate copy, and the user’s phone number is incidentally sent to a foreign service. This is a violation of the Personal Information Protection Law (PAPL) — a data security incident, not a technical bug.

Making an IDE with data-export capabilities, like Trae, the default for all company engineers. Free high-end models are a strong lure, and engineers will install them on their own. Once your core code, configurations, or interfaces are on servers owned by ByteDance (or any other foreign entity), it’s too late to undo. Introducing such tools into the development environment requires a risk assessment with input from security and legal teams, not just a decision by the technical staff.

7. La vista desde cuatro sectores: qué aplicaciones son aceptables y cuáles están vedadas

Este capítulo se centra en cuatro sectores en los que hemos acompañado a empresas a través de retos reales: comercio electrónico, finanzas, telecomunicaciones y manufactura. Los escenarios de administración pública y sanidad, fuertemente regulados, se abordarán en un artículo aparte.

Comercio electrónico. Los puntos más propensos a fallar son el “configurador de reglas promocionales”, el “panel de selección de productos para creadores de contenido” y el “miniprograma de consulta de inventario”: parecen herramientas simples, pero en realidad están leyendo tablas anchas de pedidos que contienen números de teléfono y direcciones. Este tipo de aplicaciones debe registrarse obligatoriamente en el canal sancionado de la sección 3; al tocar datos reales, se activa automáticamente la evaluación de cumplimiento de protección de datos y la evaluación de transferencia internacional de datos bajo el RGPD. Hemos visto de primera mano cómo el equipo de operaciones de un retailer español del vertical hogar (referencia comparable a El Corte Inglés en catálogo y a Inditex en escala) creó 7 herramientas internas en 2 meses, de las cuales 4 estaban leyendo tablas anchas de pedidos — esto no es un caso aislado y lo hemos reproducido en proyectos con Glovo y con marketplaces regionales.

Finanzas. La línea roja es “sistemas de transacción / pagos / liquidación y compensación / gestión de riesgos / antifraude / reportes regulatorios”. El generador es adecuado para el puesto de trabajo del gestor de clientes, el configurador de campañas de marketing y el front-end de reportes de conciliación. Bajo ninguna circunstancia debe usarse para el motor de gestión de riesgos o las reglas antifraude — el multiplicador de 1.7 veces en bugs lógicos de CodeRabbit (métrica propia de CodeRabbit, con sesgo comercial) en el contexto financiero amplifica el riesgo de capital. Caso anonimizado: una de las entidades del Ibex 35 del sector bancario comenzó a finales de 2025 a usar programación con IA para la generación auxiliar de reportes regulatorios; el resultado fue que el script de reporte bajo los criterios del Banco de España y de la EBA contenía 3 campos con definiciones incorrectas, lo que llevó a un requerimiento supervisor formal — una de las causas raíz fue que el “código que parece correcto” generado por IA no fue revisado por nadie. BBVA y CaixaBank, por su parte, han publicado marcos internos de adopción de IA generativa en 2024-2025 que reservan explícitamente el código regulatorio y el de gestión de riesgos a equipos profesionales con revisión humana obligatoria.

Telecomunicaciones / Operadores. Hemos acompañado a operadores regionales (en la órbita de Telefónica / Vodafone España / Orange España) cuyas filiales provinciales han utilizado Bolt para construir un “acceso rápido al perfil del cliente” — introduciendo un número de móvil se recuperan los últimos 90 días de planes, reclamaciones y recomendaciones — lo que choca directamente con las restricciones de acceso a datos personales bajo el RGPD Art. 5/9/25 y la LOPDGDD. En el entorno de un operador, el generador puede utilizarse para construir un “panel del gestor de cuentas”, un “front-end para la base de conocimiento de atención al cliente” o una “configuración de campañas de marketing”, pero jamás debe tocar facturación, generación de recibos o consulta de detalle de llamadas — son el núcleo crítico del negocio; un solo error acaba en los titulares. La AEPD en 2024 ya ha sancionado a operadores por accesos injustificados a datos de clientes con perfiles similares al aquí descrito.

Manufactura. Los sistemas MES/ERP, su integración, las pruebas conjuntas, el control de calidad y el reporting son sistemas críticos; el generador solo puede usarse para tareas periféricas, como paneles de planta, consultas de rutas de proceso o demos de OEE de equipos. Lo que nunca debe tocarse: el algoritmo central de planificación de producción, las reglas de decisión de calidad y las interfaces de conciliación con el ERP upstream. Caso anonimizado: un proveedor de autopartes del cluster industrial de Barcelona / Vigo (hay varios casos públicos similares de recall de SEAT, Renault España y Stellantis; los detalles se basan en avisos públicos de recall y en proyectos en los que he participado, para ilustrar la lógica de decisión, sin apuntar a ninguna empresa en particular) pidió a TI que usara Bolt para crear un “panel frontal del modelo de IA para control de calidad”. La intención era solo mostrar imágenes de muestreo y resultados de clasificación, pero al renderizar el frontend, el umbral de confianza crudo de la inferencia del modelo de IA quedó hardcodeado en el cliente. Un empleado de operaciones, sin querer, cambió el valor de 0.85 a 0.6, y en tres días más de 200 piezas que debían marcarse como “defectuosas” se etiquetaron como “conforme” y fluyeron a la línea de producción downstream. El resultado fue un recall de tres lotes. El error más común en un fabricante mediano es delegar también el “frontend del modelo de IA de control de calidad” al generador — porque la consecuencia de una regla de calidad mal aplicada es un recall, y un error se convierte en un aviso público ante la AEMPS o el Ministerio de Industria.

8. Implicaciones para quienes toman decisiones

Lección 1: Primero dibuja un mapa de capas de aplicaciones, luego habla de comprar herramientas. Saca la matriz de la sección 2 y coloca las aplicaciones que ya tienes y las que planeas desarrollar según su complejidad y sensibilidad de datos. Verás de inmediato qué áreas están en zona verde, donde puedes delegar con confianza en los generadores para acelerar el trabajo, y cuáles están en zona roja, donde ni se te ocurra tocar. Este simple diagrama frenará un montón de propuestas impulsivas tipo “reconstruyamos el sistema central con un generador”, y a la vez le dará justificación legítima a las partes que sí deben acelerarse.

Lección 2: Trata la transferencia internacional de datos y el cumplimiento de seguridad (ENS / ISO 27001) como requisitos de entrada, no como parches posteriores. Antes de comprar cualquier herramienta de IA que vaya a tocar código o datos, pásala por estos dos filtros. El problema con herramientas como Trae no es “si funcionan”, sino “si funcionan dentro de tu entorno regulatorio”. Esta decisión hay que tomarla por adelantado; equivocarse cuesta caro: remediación, sanciones de la AEPD (hasta el 4% del volumen de negocio anual mundial), incluso retirar la herramienta. En la práctica: integra la compra de herramientas de IA en un proceso de aprobación conjunto con seguridad y legal, y define dos listas claras: una de herramientas “permitidas en el entorno de desarrollo” y otra de las que requieren “aprobación caso por caso”.

Lección 3: Dale al área de negocio un canal de cumplimiento, o las aplicaciones fantasma solo aumentarán. Ese 80% de la sección 3 demuestra que bloquear no funciona. En lugar de esperar a que estalle un incidente para hacer inventario, mejor construye ya el canal de la sección 5: generadores autorizados (sanctioned), registro ligero, enrutamiento según tipo de datos y escaneo automático. Deja que el negocio avance rápido, pero que cada herramienta esté en el registro. Así conviertes la sombra de TI (shadow IT) de un punto ciego sin supervisión a un activo auditable.

Lección 4: Cambia la métrica, o todo el presupuesto se irá en herramientas y el cuello de botella seguirá ahí. Esto va dirigido a la alta dirección. Hoy en día, muchos consejos de administración miden el éxito de la transformación con IA según “cuántas licencias de IA se han comprado” o “cuánto ha mejorado la velocidad de desarrollo”. Esta métrica tiene una consecuencia: el presupuesto se va íntegro a comprar herramientas, mientras que los procesos que de verdad frenan la entrega (el equipo de evaluación de transferencia de datos, el de cumplimiento de seguridad, la ingeniería de seguridad, la conciliación y auditoría) se quedan sin fondos ni personal. Resultado: un montón de herramientas acumuladas, pero la entrega sigue siendo lenta. Para curar la enfermedad del “sé lo que hay que hacer pero no puedo moverme”, hay que cambiar la métrica desde arriba. Añade indicadores como “cuántas aplicaciones están cubiertas por el canal de cumplimiento”, “las aplicaciones fantasma han bajado de N a M”, “el ciclo desde el prototipo hasta el lanzamiento con cumplimiento normativo para las aplicaciones críticas”. Cuando cambia la métrica, el presupuesto fluye hacia donde de verdad estrangula el proceso.

Autoevaluación inversa (sé honesto al responder): ¿Cuántas aplicaciones construidas por las propias unidades de negocio con IA están corriendo ahora mismo en tu empresa? ¿Puedes dar una cifra? ¿Cuántas de esas aplicaciones tocan pedidos, números de teléfono o direcciones? El IDE de IA que instalaste por defecto para tus ingenieros, ¿a dónde envía los datos? ¿Lo has comprobado? Los indicadores que usas para medir el impacto de la IA, ¿están premiando “comprar herramientas” o “entregar más rápido”? Si en alguna de estas cuatro preguntas tu respuesta te hace sentir incómodo, entonces el riesgo del que habla este artículo ya está ocurriendo en tu empresa.

Esta es la quinta entrega de una serie de 18 artículos sobre la transformación de la ingeniería de software en la era de la IA. Ya hemos visto cómo los generadores de aplicaciones y los IDE con IA han derrumbado la barrera de entrada para “crear una aplicación”, y por qué la barrera de tocar datos no se derrumba con la misma facilidad.

El próximo artículo (el número 6) aborda una dirección opuesta que se está convirtiendo en consenso en la industria: desarrollo dirigido por especificaciones (Spec-Driven Development). Por qué GitHub Spec Kit, Claude Code, AWS Kiro y AGENTS.md de OpenAI están convergiendo en la misma idea: “primero fijar los requisitos por escrito en un documento, y luego dejar que la IA trabaje”. En la sección anterior explicamos que la tasa de vulnerabilidades en el código generado por IA es más alta que en el código escrito por humanos; el desarrollo dirigido por especificaciones es precisamente uno de los métodos para tratar este problema: convertir requisitos vagos y verbales en especificaciones verificables para que la IA pueda ser supervisada.


Nota sobre la serie: Esta serie seguirá de cerca la evolución de las herramientas de programación con IA, las estructuras organizativas y los paradigmas de ingeniería de software. Síguenos para recibir actualizaciones continuas.


¿Quieres aplicar estas conclusiones en tu empresa?

Cuando los generadores de aplicaciones entran en una organización, los problemas concretos que realmente hay que resolver suelen ser: qué aplicaciones y datos pueden ser generados de forma autónoma por el negocio, cuáles deben quedar bajo el control de TI, hasta qué punto hay que reforzar los procesos de validación existentes, y con qué métricas se debe evaluar el piloto.

Actualmente ofrecemos tres modalidades de colaboración:

  • Formación interna: Diseña la selección del generador de aplicaciones, sus límites de uso, los canales de cumplimiento y los mecanismos de gobernanza a partir de proyectos reales de tu empresa.
  • Consultoría específica: Enfocada en una decisión concreta, como “¿habilitamos un generador de aplicaciones autorizado para las áreas de negocio?” o la priorización de acciones correctivas tras el inventario de aplicaciones no autorizadas (shadow apps).
  • Sesiones para directivos y conferencias del sector: Centradas en herramientas de programación con IA, gobernanza de aplicaciones no autorizadas, transformación de IA empresarial y gobernanza organizacional.

El artículo ofrece un marco general, pero la implementación concreta requiere rediseñarse según los límites de datos, los requisitos regulatorios, la madurez de ingeniería y los flujos de entrega existentes de cada empresa. Para colaboraciones, contacta a coach@iaiuse.com.

Lectura recomendada: Metodología del Letrero v1.0 (Aprende IA Poco a Poco 187), que presenta de forma sistemática el marco de 7 pasos para la transformación de IA empresarial.


Sobre esta serie

“La transformación de la ingeniería de software en la era de la IA” es una serie de investigación dirigida a CIO, CDO, CTO y responsables de transformación digital en sectores como telecomunicaciones, finanzas, manufactura y comercio electrónico. Consta de 18 artículos que abordan cómo las herramientas de programación con IA, los generadores de aplicaciones y la gobernanza de aplicaciones no autorizadas impactan los flujos de entrega de software, la estructura organizacional, los mecanismos de gobernanza y las métricas de gestión.

Serie que da seguimiento continuo a papers académicos, materiales de proveedores e informes del sector. El repositorio de investigación acumula más de 200 documentos, y cada conclusión clave lleva marcado su nivel de evidencia, distinguiendo entre hechos verificados, afirmaciones de proveedores, observaciones del sector y razonamiento del autor.

Cuento con casi 8 años de experiencia en consultoría para grandes empresas y análisis de negocio. Trabajé en IBM, donde participé en proyectos para los sectores de telecomunicaciones, finanzas, seguros y manufactura. Posteriormente, seguí en la primera línea de desarrollo de productos para operadores, productos de internet y aplicaciones de IA, ocupándome de análisis de requisitos, diseño de producto e implementación entre equipos.

Las conclusiones de esta serie sobre selección de herramientas, límites de uso de generadores de apps, diseño de canales de cumplimiento y gobernanza organizativa provienen de esa experiencia práctica, y se contrastan con investigación pública y casos del sector. Todo el contenido relacionado con proyectos concretos ha sido anonimizado; algunos escenarios del sector son ejercicios de razonamiento sobre problemas típicos, y las fuentes correspondientes figuran en las referencias al final.

Detrás de esta cuenta hay en realidad un equipo pequeño: yo y 1 o 2 colaboradores de largo recorrido, cada uno encargado de la investigación sobre herramientas de programación con IA, el análisis de casos de gobernanza organizativa y las conversaciones de coaching. La mayoría de los proyectos en los que “acompañamos a empresas a sortear dificultades” los entregamos juntos. Los límites de cumplimiento de los clientes y los nombres de personas siguen sin mencionarse; el anonimato se mantiene para dejar espacio a futuros colaboradores.


Fuentes de referencia (todas verificadas, con nivel de evidencia y postura indicados en cada una)

  • Eric Simons, CEO de StackBlitz (LinkedIn, cierre del año fiscal 2026). Bolt.new es utilizado por tres cuartas partes de las empresas Fortune 500, y su ARR empresarial creció 10 veces año contra año. Declaración directa de la compañía (perspectiva del proveedor). https://www.linkedin.com/posts/eric-simons-a464a664_a-growth-update-ase-close-out-our-fiscal-activity-7425263313049026560-5tdV

  • Sacra / Growth Unhinged (2025). Seguimiento del crecimiento del ARR de Bolt.new (de aproximadamente 5 meses a 40 millones de dólares de ARR, cerca de 5 millones de usuarios, el segundo crecimiento más rápido en la historia después de ChatGPT). Investigación y seguimiento de primera mano. https://sacra.com/c/bolt-new/ y https://www.growthunhinged.com/p/boltnew-growth-journey

  • Taskade (2026-03) / Business Insider. StackBlitz ronda B de enero 2025 por $105,5M, valoración aproximada de $700M; Bolt V2 lanza Bolt Cloud. Reportes consolidados de la industria.

  • Forbes / Rashi Shrivastava (2026-06-05). Lovable está en conversaciones para una nueva ronda de financiación con una valoración de $12B; ARR supera los $500M (confirmado por TechCrunch el 2026-06-09). Cobertura de primer nivel en la industria. https://www.forbes.com/sites/rashishrivastava/2026/06/05/ai-coding-startup-lovable-in-talks-to-raise-funding-at-a-12-billion-valuation

  • CNBC / Bloomberg (2025-12) / TechCrunch (2025-11). Lovable ronda B por $330M con valoración de $6,6B; ronda A por $200M con valoración de $1,8B. Reportes del sector.

  • ARR.club (2026-07). Curva de crecimiento del ARR de Lovable: $17M (2025-02) → $100M (2025-07) → $200M (2025-11) → $400M (2026-02) → $500M (2026-06); clientes empresariales incluyen Workday, Asana y NVIDIA. Seguimiento del sector.

  • Vercel (2026-02-03, blog oficial “Introducing the new v0”). v0 pasó de v0.dev a v0.app, evolucionando de un generador de componentes UI a un generador de aplicaciones full-stack (runtime en sandbox + GitHub + integración con Snowflake/AWS). Declaración directa del proveedor. https://vercel.com/blog/introducing-the-new-v0

  • Taskade (2026-03) / Vercel. En marzo de 2026, v0 superó los 6M de usuarios, con aproximadamente 80.000 equipos activos mensuales y un ARR estimado de unos $42M. Estimación combinada del sector.

  • Replit (2026-03-13 official changelog + official blog “What’s changed from Agent 3 to Agent 4”). Agent 4 released 2026-03-11; Infinite Design Canvas; fork-and-merge collaboration replaced with multi-threaded tasks within the same project + automatic conflict resolution (90% resolved automatically). First-party vendor statement. https://docs.replit.com/updates/2026/03/13/changelog

  • AlphaSignal (2026). Detailed coverage of Replit Agent 4 automatically resolving 90% of merge conflicts. Industry coverage. https://alphasignal.ai/news/replit-s-agent-4-resolves-90-of-team-merge-conflicts-automatically

Atal Upadhyay (2026-03-19). Replit anunció en la misma semana una ronda Serie D de $400M con valoración de $9 mil millones (se triplicó en seis meses). Información compilada de reportes de la industria. https://atalupadhyay.wordpress.com/2026/03/19/replit-agent-4-replit-just-changed-everything

  • Cybernews (actualizado el 01/08/2026) | The Register (28/07/2025) | segmentationf4u1t (investigación original en GitHub). Trae continúa transmitiendo hardware, ID de dispositivo y datos de actividad de proyectos a los servidores de ByteDance incluso cuando el usuario desactiva la telemetría; un solo lote de datos puede alcanzar los 53.606 bytes, llegando a generar alrededor de 26 MB en500+ solicitudes durante 7 minutos ByteDance confirmó oficialmente que el interruptor solo controla la parte del framework de VS Code; el Privacy Mode está programado para lanzarse alrededor de agosto de 2026; en febrero de 2026 Trae canceló su plan “forever free” para adoptar un sistema de pago por tokens (token-based paywall). Investigación de seguridad de primer nivel, reportajes de la industria y declaraciones del fabricante, todo incluido: https://cybernews.com/security/bytedance-ai-coding-tool-trae-data-collection, https://www.theregister.com/software/2025/07/28/bytedance-ai-ide-trae-telemetry-continues-even-after-opt-out/ y https://github.com/segmentationf4u1t/trae_telemetry_research.

  • OpenAI Tools Hub / Jim Liu (2026-05-18). Trae alcanzó 6M de registros en 12 meses, 1.6M de usuarios activos mensuales y 100B líneas de código generadas en total; el paywall de tokens de febrero rompió con el “forever free”. Investigación integral (postura de analista).

  • Gartner (citado por Process Excellence Network, 2025-08-27 / DevOpsDigest / UC Today). Para finales de 2026, el 40% de las aplicaciones empresariales incorporarán agentes de IA específicos para tareas (menos del 5% en 2025); para 2035, la IA agéntica representará aproximadamente el 30% del mercado de software empresarial ($450 mil millones). Documento de pronóstico oficial. https://www.processexcellencenetwork.com/ai/news/gartner-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026

  • Gartner (citado por RapidClaw / Hendricks.ai / Arion Research, 2025-2026). Entre el primer trimestre de 2024 y el segundo de 2025, las consultas empresariales sobre sistemas multi-agente crecieron un 1445% —el tema de mayor crecimiento en la práctica de asesoría en IA de Gartner. Investigación de primer nivel / fuente secundaria.

  • Microsoft (publicación retrospectiva del año fiscal 2026, 28 de julio de 2026). EY implementó Copilot para 150.000 empleados, logrando un aumento del 15% en productividad, y ahora lo está expandiendo a 400.000 empleados a nivel global; Atos desplegó Copilot para 56.000 empleados en 54 países y gestiona 19.000 agentes de IA bajo un panel de control unificado. Declaraciones directas del proveedor y del cliente (perspectiva del fabricante y del integrador). https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation

  • Atos Group (2026-06-09, comunicado oficial). Atos y Microsoft amplían su colaboración para desplegar Copilot E7 (Frontier Suite) entre 56.000 empleados, unificando el plano de control de Entra/Defender/Intune/Purview/Agent 365 y operando 19.000 agentes. Declaración directa de la compañía. https://www.atosgroup.com/en/press/atos-group-and-microsoft-expand-strategic-collaboration-scale-secure-agentic-ai-across-atos

  • UpGuard / Cybersecurity Dive (2025). Más del 80% de los empleados y casi el 90% de los responsables de seguridad utilizan herramientas de IA no aprobadas; aproximadamente la mitad de los empleados han pegado datos confidenciales en estas herramientas (informes similares de Mimecast y Teramind coinciden en cifras comparables, lo que refuerza los hallazgos). Investigación de primera mano + cobertura del sector. https://www.cybersecuritydive.com/news/shadow-ai-employee-trust-upguard/805280/

  • Gartner (citado por The Hacker News, mayo de 2026). El 69% de las organizaciones sospecha o confirma que sus empleados usan herramientas de IA prohibidas; solo el 37% cuenta con políticas de uso de IA. Cobertura del sector citando a Gartner.

  • CodeRabbit (seminario web conjunto con DORA de febrero de 2026 + evaluación comparativa de Kunal Ganglani en junio de 2026). El número de problemas en el código generado con asistencia de IA (incluidos errores de lógica y de corrección) es aproximadamente 1,7 veces mayor que el del código escrito manualmente de forma tradicional; CodeRabbit es la herramienta de revisión de código con IA más instalada en GitHub/GitLab, con más de 15 000 clientes de pago y más de 6 millones de repositorios revisados; el CEO de NVIDIA, Jensen Huang, la ha respaldado públicamente. Investigación de primer nivel / datos del proveedor / evaluación comparativa del sector. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report

  • Veracode (Informe de Seguridad de Código GenAI 2025). Aproximadamente el 45% de las muestras de código generado por IA contienen vulnerabilidades del Top 10 de OWASP (la tasa de fallos en código Java generado supera el 70%). Investigación de primera mano. https://www.veracode.com/blog/genai-code-security-report/ (Nota: el borrador original interpretó erróneamente este “45%” como la tasa de adopción de IA en la sombra, lo cual era incorrecto y ha sido corregido — el 45% se refiere a la tasa de defectos en el código generado por IA, no a la adopción de herramientas; la tasa de adopción de IA en la sombra se encuentra en el informe de UpGuard, con más del 80%).

  • arXiv:2510.26103. Vulnerabilidades de seguridad en código generado por IA: un análisis a gran escala de repositorios públicos de GitHub. (Estudio empírico de primera mano sobre vulnerabilidades de seguridad en código generado por IA).

Nota metodológica sobre los datos: todas las cifras cuantitativas de este artículo citan su fuente; algunos números que los fabricantes no han divulgado de primera mano o que no han sido verificados de forma independiente (como la ronda de financiación de $12 mil millones de Lovable, aún en conversaciones, o el recuento exacto de los 19,000 agentes de Atos) se han tratado con cautela. Los casos de clientes han sido anonimizados (equipo de operaciones de comercio electrónico, centro de marketing de una filial regional de operador de telecomunicaciones, etc.) y provienen de escenarios reales observados durante mi acompañamiento en la entrega de proyectos; no se refieren a empresas concretas. Los requisitos regulatorios (transferencia internacional de datos bajo RGPD/LOPDGDD, cumplimiento del ENS o ISO 27001, evaluación de conformidad del Reglamento de IA de la UE) se basan en la normativa vigente; su aplicación concreta varía según el negocio y el tipo de datos, por lo que se recomienda consultar con el equipo legal o de cumplimiento antes de implementar cualquier medida.

[^1]: La transferencia internacional de datos personales fuera del EEE se rige por el RGPD Art. 44-50 y la LOPDGDD Título V. Mecanismos válidos: (a) decisión de adecuación de la Comisión Europea, (b) garantías adecuadas — entre ellas las Cláusulas Contractuales Tipo (SCC, Decisión 2021/914), las Normas Corporativas Vinculantes (BCR), o códigos de conducta / certificación, (c) excepciones específicas del Art. 49 (consentimiento explícito, ejecución de contrato, etc.). Tras Schrems II (C-311/18, 2020), las SCC por sí solas no bastan si el país receptor no ofrece protección esencialmente equivalente: el responsable debe realizar y documentar una Transfer Impact Assessment (TIA) y aplicar medidas suplementarias (cifrado, seudonimización, contractual). La AEPD ha publicado en 2024 una guía operativa al respecto y supervisa caso por caso.

[^2]: El Real Decreto 311/2022 aprueba el Esquema Nacional de Seguridad (ENS) — obligatorio para el sector público español y sus proveedores; el sector privado se rige típicamente por ISO/IEC 27001 (certificación de SGSI) o por el ENS cuando opera como proveedor del sector público. El ENS estructura las medidas en tres Categorías (Básica, Media, Alta), con auditoría formal y declaración / Certificación de Conformidad según la categoría. La transposición de NIS2 (Real Decreto-ley 7/2025 y normativa de desarrollo) extiende obligaciones de ciberseguridad a entidades esenciales e importantes en sectores críticos (energía, transporte, banca, salud, infraestructura digital). En el sector financiero, la Circular 4/2020 del Banco de España y las directrices EBA sobre riesgo TIC complementan este marco.

[^3]: El Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo (Reglamento de IA o EU AI Act) establece un marco horizontal para la IA en la UE. En España, la AEPD es la autoridad competente para la supervisión de los sistemas de IA de alto riesgo que tratan datos personales (junto con la AESIA — Agencia Española de Supervisión de la Inteligencia Artificial, creada por el RD 729/2023, competente en los demás aspectos). Distinción clave: las prohibiciones del Art. 5 (sistemas de IA de riesgo inaceptable, p. ej. identificación biométrica masiva en espacios públicos) entraron en vigor el 2 de febrero de 2025; la transparencia y los sistemas de IA generativa (Art. 50 — marcado de contenido sintético) aplican desde el 2 de agosto de 2025; el resto de obligaciones, incluida la evaluación de conformidad para sistemas de alto riesgo del Anexo III, se aplican plenamente desde el 2 de agosto de 2026. Sanciones: hasta 35 millones de euros o el 7 % del volumen de negocio anual mundial por incumplir las prohibiciones del Art. 5; hasta 15 millones o el 3 % por incumplir el resto de obligaciones.

[^4]: El marco general de gestión de cambios se refiere a ITIL 4 Change Enablement; la referencia más reciente para el sector financiero en España son la Circular 4/2020 del Banco de España sobre gobierno de los riesgos operativos y tecnológicos, las directrices de la EBA sobre gobernanza de TIC y seguridad (EBA/GL/2019/04 y desarrollo posterior), y la supervisión de la CNMV sobre transformación digital de entidades de valores; para el sector de seguros, la normativa de la DGSFP sobre gobierno de TIC y externalización (Directiva (UE) 2016/2340 — DORA en preparación).

[^5]: Registro de transacciones: la fuente real es la Ley 34/2002 (LSSI-CE) y la Ley 56/2007 de Medidas de Impulso de la Sociedad de la Información, junto con el RGPD Art. 30 (registro de actividades de tratamiento) para datos personales. Conservación de logs de auditoría: el ENS Categoría Media / Alta exige conservar registros durante ≥ 2 años para Categoría Media y ≥ 5 años para Categoría Alta (RD 311/2022 Anexo II); en el sector financiero, la Circular 4/2020 del Banco de España y las directrices EBA sobre riesgo TIC suelen requerir ≥ 5 años para sistemas críticos — los plazos del ENS son el mínimo legal, no el valor recomendado.