Una auditoría de código generado con IA es una revisión técnica independiente de una aplicación construida con herramientas como Lovable, Cursor, v0, Bolt, Replit o Claude Code, orientada a responder tres preguntas concretas: qué está roto, cómo de grave es, y qué cuesta arreglarlo. No es una revisión de estilo ni un informe académico: es el equivalente a la inspección técnica de un edificio que ya está en pie y que va a recibir gente dentro.
El motivo por el que este servicio existe es reciente. Hasta 2024, quien no sabía programar no tenía aplicación. Desde 2025, cualquiera puede tener una aplicación funcionando en un fin de semana, y muchas lo están: aplicaciones que facturan, que guardan datos de clientes reales y que nadie con formación en ingeniería ha mirado nunca. Funcionar y estar bien construido son dos cosas distintas, y la diferencia entre ambas no se ve desde fuera hasta que algo se rompe.
Esta guía la firma Miguel Quílez, director de Hiberus Booster, la unidad del grupo Hiberus hiperespecializada en inteligencia artificial. Hiberus es la primera consultora tecnológica española de capital privado, con más de 4.000 profesionales. El contenido procede de revisiones reales sobre aplicaciones construidas con asistentes de IA y de marcos de referencia como OWASP Top 10, OWASP ASVS y las guías de la Agencia Española de Protección de Datos.
¿Qué es exactamente una auditoría de código generado con IA?
Es una revisión estructurada que atraviesa cinco capas de la aplicación, en este orden, porque cada una condiciona a la siguiente:
| Capa | Pregunta que responde | Fallo típico que aparece |
|---|---|---|
| Seguridad | ¿Puede alguien ver o cambiar datos que no son suyos? | Reglas de acceso a la base de datos desactivadas o mal escritas |
| Datos y privacidad | ¿Dónde están los datos, quién los toca y qué dice el RGPD de eso? | Datos personales en servidores fuera de la UE sin base legal documentada |
| Arquitectura | ¿Aguanta diez veces más uso del que tiene hoy? | Consultas que crecen con el número de usuarios en lugar de mantenerse planas |
| Mantenibilidad | ¿Puede otro equipo trabajar sobre esto sin reescribirlo? | Lógica de negocio duplicada en cinco sitios que ya no coinciden entre sí |
| Operación | Si se cae un martes a las tres, ¿cuánto tardas en enterarte? | Sin copias de seguridad verificadas, sin registro de errores, sin límite de gasto |
El orden importa. Un problema de arquitectura cuesta dinero; un problema de seguridad cuesta clientes y, desde el RGPD, puede costar una sanción. Por eso una auditoría seria empieza siempre por lo que puede explotar, no por lo que está feo.
Los siete fallos que aparecen casi siempre
No son fallos de las herramientas. Son fallos de lo que las herramientas no te piden que decidas. Un asistente de IA optimiza para que veas algo funcionando cuanto antes, y lo que se sacrifica para conseguirlo es siempre lo mismo.
1. La base de datos abierta de par en par
Es el más frecuente y el más grave. Las plataformas modernas (Supabase, Firebase) permiten que el navegador hable directamente con la base de datos, y protegen los datos con reglas por fila. Si esas reglas están desactivadas —lo habitual mientras se construye, porque estorban— cualquiera que abra las herramientas de desarrollo del navegador puede leer la tabla entera de clientes. No hace falta ser un atacante sofisticado: hace falta curiosidad.
2. Claves y credenciales viajando al navegador
La clave de la pasarela de pago, la del servicio de correo o la del propio modelo de IA acaban con frecuencia en el código que se descarga al navegador del usuario. Cualquiera puede leerlas y usarlas. En el caso de una clave de IA, el coste es literal: se factura a tu tarjeta hasta que lo detectas.
3. Validación solo en el formulario
La aplicación comprueba que el precio sea positivo, que el rol sea «usuario» y que el descuento no pase del 10%… en el formulario. Quien envíe la petición sin pasar por el formulario —lo que se hace con una línea de comando— se salta todas esas comprobaciones. La regla del oficio es vieja y no ha cambiado: toda validación que importa se repite en el servidor.
4. Autorización confundida con autenticación
La aplicación sabe quién eres (has iniciado sesión) pero no comprueba si eso que pides es tuyo. Cambiar un número en la dirección de la página —de /factura/1043 a /factura/1044— y ver la factura de otro cliente es el resultado. Está en el top 1 de la lista de OWASP desde hace años y sigue apareciendo en la mayoría de revisiones.
5. Sin límites: ni de peticiones, ni de gasto
Nada impide que alguien llame diez mil veces a tu formulario de registro, o a la función que consulta el modelo de IA. Sin límite de peticiones tienes una puerta abierta al abuso; sin límite de gasto en el proveedor, tienes una factura sorpresa a fin de mes que puede ser de cuatro cifras.
6. Copias de seguridad que nadie ha restaurado nunca
Tener copias activadas no es tener copias. Una copia de seguridad que nunca se ha restaurado es una hipótesis, no un plan. En una revisión, la pregunta no es «¿tienes backups?» sino «¿cuándo restauraste el último y cuánto tardaste?».
7. RGPD tratado como un texto legal en el pie de página
La política de privacidad se generó con IA y menciona servicios que la aplicación no usa, mientras omite los que sí. No hay registro de actividades de tratamiento, no está claro dónde se alojan los datos, y no hay forma de atender una solicitud de borrado sin entrar a mano en la base de datos. Si tratas datos de clientes europeos, esto no es un detalle de formato.
¿Cuándo tiene sentido auditar, y cuándo no?
No toda aplicación hecha con IA necesita una revisión. La pregunta útil no es cómo se construyó, sino qué pasa si falla.
Tiene sentido auditar cuando:
- Guarda datos personales de clientes reales, y no solo los tuyos.
- Cobra dinero, o va a cobrarlo en los próximos meses.
- Se la vas a enseñar a un inversor, a un cliente grande o a un comité de compras.
- Va a pasar de una decena de usuarios a unos cuantos cientos.
- Vas a contratar a alguien para que siga trabajando sobre ella.
- Es la herramienta con la que trabaja tu equipo cada día y ya no puedes permitirte que se caiga.
No merece la pena todavía cuando es un prototipo interno con datos ficticios, cuando lo usáis tres personas de la misma empresa, o cuando aún estás comprobando si la idea interesa a alguien. En esa fase el riesgo real es construir algo que nadie quiere, no construirlo mal. Auditar antes de tener usuarios es pagar por una respuesta a una pregunta que aún no te has hecho.
¿Cuánto tarda y cuánto cuesta en España?
Una revisión de una aplicación pequeña o mediana —el tamaño habitual de lo construido con estas herramientas— ocupa entre cinco y diez días laborables. No es un rango arbitrario: cinco días bastan para recorrer las cinco capas y entregar el diagnóstico; diez permiten además dejar el plan de remediación priorizado y volver a comprobar los arreglos.
| Alcance | Duración | Qué entrega | Orden de precio |
|---|---|---|---|
| Inspección | 5 días | Informe con hallazgos, gravedad y coste estimado de cada arreglo | Desde 1.590 € + IVA |
| Inspección con acompañamiento | 10 días | Lo anterior, más revisión de RGPD, plan priorizado y una reinspección tras los arreglos | Desde 2.900 € + IVA |
| Acompañamiento continuo | Mensual | Revisión periódica según evoluciona la aplicación | Desde 590 €/mes |
Una advertencia sobre el mercado: quien te audita y quien te arregla no deberían ser la misma persona sin que lo sepas. El incentivo es evidente —cuantos más fallos encuentre, más te factura después—. En nuestro caso, la inspección no incluye ejecutar los arreglos precisamente por eso: el informe vale para llevárselo a quien tú quieras, incluido tu propio equipo.
¿Qué recibes al terminar?
Un informe sirve si un no técnico puede tomar decisiones con él y un técnico puede ejecutarlas. Eso significa, como mínimo:
- Un veredicto en una frase: si la aplicación puede seguir en producción tal cual, si necesita arreglos urgentes, o si conviene replantearla.
- Cada hallazgo con su gravedad, y la gravedad explicada en consecuencias reales, no en una puntuación abstracta: qué puede pasar, a quién afecta, y con qué facilidad.
- Prueba de cada hallazgo: la línea de código, la captura o la petición que lo demuestra. Un hallazgo sin prueba es una opinión.
- Estimación de esfuerzo por arreglo, para que puedas priorizar por relación entre riesgo y coste en vez de por orden de aparición.
- Qué está bien. Un informe que solo enumera problemas es un informe de venta, no un diagnóstico.
Auditoría, test de intrusión y revisión de código: no son lo mismo
Los tres términos se usan como sinónimos y no lo son. La diferencia práctica está en desde dónde se mira:
| Servicio | Desde dónde mira | Para qué sirve |
|---|---|---|
| Test de intrusión | Desde fuera, sin ver el código | Demostrar que un atacante puede entrar por una vía concreta |
| Revisión de código | Desde dentro, línea a línea | Encontrar defectos de implementación y mala calidad |
| Auditoría de aplicación | Desde dentro y desde fuera, más el contexto de negocio | Decidir qué hacer con la aplicación: mantenerla, arreglarla o rehacerla |
Para una aplicación construida con IA, empezar por un test de intrusión suele ser desperdiciar dinero: encontrará una puerta abierta cuando hay siete, porque su trabajo es demostrar una vía de entrada, no inventariar todas. La auditoría es la que da el mapa completo.
Lo que puedes comprobar tú mismo esta tarde
Antes de contratar nada, hay cuatro comprobaciones que no requieren ser técnico y que descartan o confirman los fallos más graves:
- Crea dos cuentas de prueba distintas. Desde la segunda, intenta llegar a los datos de la primera cambiando números en la barra de direcciones. Si lo consigues, tienes el fallo número 4.
- Entra en el panel de tu base de datos y busca si la protección por filas está activada en cada tabla. Si alguna dice que está desactivada, tienes el fallo número 1.
- Comprueba el límite de gasto en el panel del proveedor de IA y en el de tu alojamiento. Si no hay ninguno configurado, tienes el fallo número 5.
- Pide una restauración de la última copia de seguridad a un entorno de prueba. Si nadie sabe cómo hacerlo, tienes el fallo número 6.
Estas cuatro comprobaciones no sustituyen una revisión, pero orientan: si tres de las cuatro salen mal, la conversación ya no es si auditar, sino cuándo.
Preguntas frecuentes
¿Qué es una auditoría de código generado con IA?
Es una revisión técnica independiente de una aplicación construida con herramientas como Lovable, Cursor, v0 o Replit, que atraviesa cinco capas —seguridad, datos y privacidad, arquitectura, mantenibilidad y operación— y responde a tres preguntas: qué está roto, cómo de grave es y qué cuesta arreglarlo. No revisa el estilo del código, sino el riesgo real de la aplicación en producción.
¿Cuánto cuesta auditar una aplicación hecha con IA en España?
Una inspección de cinco días sobre una aplicación pequeña o mediana parte de 1.590 euros más IVA. La modalidad de diez días, que añade la revisión de cumplimiento RGPD, el plan de remediación priorizado y una reinspección tras los arreglos, parte de 2.900 euros más IVA. El acompañamiento continuo se factura mensualmente desde 590 euros al mes.
¿Cuáles son los fallos más frecuentes en aplicaciones hechas con IA?
Siete se repiten en casi todas las revisiones: reglas de acceso a la base de datos desactivadas, claves y credenciales expuestas en el navegador, validación que solo existe en el formulario, autorización confundida con autenticación, ausencia de límites de peticiones y de gasto, copias de seguridad nunca restauradas, y cumplimiento RGPD tratado como un texto en el pie de página. Ninguno impide que la aplicación funcione, y por eso se descubren tarde.
¿Cuándo debo auditar mi aplicación y cuándo no hace falta?
Tiene sentido auditar cuando la aplicación guarda datos personales de clientes reales, cobra dinero, va a enseñarse a un inversor o a un cliente grande, va a multiplicar sus usuarios, o va a pasar a manos de otro equipo. No compensa todavía si es un prototipo interno con datos ficticios o si aún estás comprobando si la idea interesa: en esa fase el riesgo es construir algo que nadie quiere, no construirlo mal.
¿En qué se diferencia una auditoría de un test de intrusión?
El test de intrusión mira desde fuera, sin ver el código, y sirve para demostrar que un atacante puede entrar por una vía concreta. La auditoría mira desde dentro y desde fuera, e incluye el contexto de negocio para decidir qué hacer con la aplicación. Para una app hecha con IA, empezar por un test de intrusión suele ser desperdiciar dinero: encontrará una puerta abierta cuando hay siete.
¿Cuánto tarda una auditoría de una aplicación pequeña?
Entre cinco y diez días laborables. Cinco días bastan para recorrer las cinco capas y entregar el diagnóstico con los hallazgos priorizados. Diez días permiten además dejar el plan de remediación detallado y volver a comprobar los arreglos una vez ejecutados.
¿Quién audita debería arreglar también los fallos?
No sin que lo sepas. El incentivo es evidente: cuantos más fallos encuentre, más factura después. Por eso conviene que la inspección se contrate por separado de la ejecución de los arreglos, de forma que el informe se pueda llevar a cualquier equipo, incluido el propio.
¿Puedo comprobar yo mismo si mi aplicación tiene problemas graves?
Cuatro comprobaciones no requieren ser técnico: crear dos cuentas y tratar de acceder a los datos de una desde la otra cambiando números en la barra de direcciones; revisar si la protección por filas está activada en cada tabla de la base de datos; comprobar que hay un límite de gasto configurado en el proveedor de IA y en el alojamiento; y pedir una restauración de la última copia de seguridad. Si tres de las cuatro salen mal, la conversación ya no es si auditar, sino cuándo.
Que un ingeniero mire tu código antes que un atacante
Cuéntanos qué has construido y con qué herramienta. Te decimos en 24 horas si tiene sentido inspeccionarlo, y qué encontraríamos probablemente. La primera conversación no cuesta nada.
✓ ¡Recibido!
Gracias. Un especialista de Hiberus Booster te contacta en menos de 24 horas.
