Tengo una app hecha con IA: qué revisar antes de depender de ella

Respuesta corta: puede funcionar y aun así no ser realmente tuya

Se puede construir una herramienta útil para un negocio con ayuda de la IA, y muchas veces funciona. El problema no es que funcione, sino que nadie haya comprobado lo que no se ve: dónde está alojada, quién tiene acceso, qué ocurre con los datos de las personas que la usan, si hay copias de seguridad y cómo se corrige un fallo sin romper otra cosa. La IA responde a lo que le pides, y quien no es del oficio no sabe qué pedir. Antes de depender de una aplicación hecha con IA conviene poder contestar ocho preguntas, que se detallan más abajo y no exigen saber programar: dónde vive, cuánto cuesta cada mes, quién tiene el código, quién tiene acceso, dónde están las claves, si hay copias que se hayan probado, qué datos de personas guarda y qué pasa si falla. Si hay alguna que no sabes responder, esa es la primera tarea, antes de añadir una función más. Este texto parte de un caso que vimos hace poco y de una idea sencilla: construir se ha abaratado muchísimo, pero responsabilizarse de lo construido no. Si todavía estás probando una idea, por qué validar una app antes de desarrollarla explica cómo hacerlo sin gastar de más.

Que una aplicación funcione el día que la pruebas no significa que sepas qué pasaría el día que falle. Esa diferencia es lo que conviene revisar.

Qué encontramos al revisar una app hecha con IA

Hace poco vimos el código de una aplicación que una persona sin formación técnica había construido con asistentes de programación como ChatGPT y Codex. No era un juguete: gestionaba cobros, el acceso de los usuarios, el seguimiento de su actividad y varias conexiones con servicios externos. Funcionaba, y construirla ya era un logro. Pero al abrirla aparecieron cosas que su propietaria no podía haber visto, porque nadie le había dicho que había que mirarlas. Es un solo caso, no una estadística, y por eso omitimos cualquier dato que permita identificarlo. Lo que sigue es lo que encontramos, traducido a lenguaje corriente.

Más que cualquier fallo concreto, llamaba la atención que no hubiera ninguna información sobre qué había, dónde estaba y cuánto costaba. Sin eso, ni siquiera se puede decidir qué arreglar primero.

• No había información básica sobre la aplicación: su propietaria no sabía dónde estaba desplegada, cuánto pagaba ni qué servicios tenía contratados, y hubo que rastrear esas herramientas una a una. No se puede cuidar ni presupuestar lo que no se sabe que existe.
• La aplicación vivía solo dentro de la herramienta con la que se creó, sin repositorio propio, sin historial de versiones, sin un entorno donde probar los cambios antes de publicarlos y sin comprobaciones automáticas antes de cada publicación. Si un cambio salía mal no había vuelta atrás, y el negocio dependía de una plataforma que no controlaba.
• La estructura no seguía un patrón claro: todo estaba disperso, con archivos de más de seiscientas líneas casi ilegibles. Así, cualquier arreglo puede romper otra cosa, y a quien tenga que mantenerla, sea una persona o una IA, le cuesta mucho más entenderla.
• Se había reconstruido a mano parte de lo que un marco de desarrollo habitual, en este caso Next.js, ya trae resuelto. El efecto es más código propio que mantener y menos partido a lo que ofrece de serie la herramienta adecuada.
• Los datos se consultaban de dos maneras a la vez, con definiciones preparadas que no se usaban y consultas escritas a mano; había además rutas incorrectas y componentes mal planteados, como partes enteras preparadas para el navegador cuando solo una pequeña porción lo necesitaba. Es el tipo de desorden que hace la aplicación más pesada y más difícil de mejorar.
• Había unos siete errores identificados, y su propietaria intentaba corregirlos sin poder valorar si cada arreglo era bueno, de modo que arreglar un fallo podía mover otras piezas sin que nadie lo supiera.

Lo que la IA no te cuenta al crear una app: lo que no sabes que no sabes

Una IA que escribe código hace lo que le pides. Si le pides que los usuarios puedan entrar y pagar, lo hace. Lo que no suele hacer, salvo que alguien se lo pida, es avisarte de lo que no preguntaste: que conviene guardar el código en un sitio propio, que hay que probar las copias de seguridad, que las claves no se pegan en una conversación o que cada servicio contratado genera un coste mensual. Quien no conoce el oficio no puede pedir lo que ignora que existe. Ese es el verdadero desnivel. No se trata de que el código escrito por una IA sea peor o mejor que el de una persona, y generalizar sería injusto. Se trata de que un proyecto con ayuda profesional suele tener a alguien que revisa, pregunta y avisa, y uno hecho en solitario con IA no, salvo que se busque. Hay datos que apuntan en esa dirección, aunque conviene leerlos con cuidado. Un estudio de la empresa de seguridad Veracode, con más de cien modelos y ochenta tareas de programación, encontró fallos de seguridad en el 45 % de los casos probados. Es un comunicado de una compañía que vende productos de seguridad y trata de tareas cortas, así que no mide lo que ocurre en una aplicación completa. Por otro lado, el control de acceso roto, el fallo que permite a un usuario ver o hacer lo que no le corresponde, encabeza el OWASP Top 10:2025 y, según los datos que recoge esa organización, apareció en todas las aplicaciones probadas. No es un problema exclusivo de la IA. Lo que cambia es quién está en condiciones de detectarlo. Un ejemplo ilustrativo, no real: en una plataforma con usuarios, alguien cambia un número en la dirección de su propio perfil y ve el perfil de otra persona, con su correo y sus pagos. La aplicación funciona perfectamente, y ese fallo solo lo encuentra quien sabe buscarlo.

El riesgo no es que la IA escriba mal. Es que quien recibe el resultado no tenga forma de saber qué le falta.

Qué revisar en una app hecha con IA (1 de 2): quién la controla

Las ocho comprobaciones se pueden contestar sin saber programar. Las cuatro primeras tratan de control: qué es tuyo y de qué dependes. Cada una incluye dónde empezar a mirar; si no consigues contestarla, pregunta a quien te ayudó a montarla o pide ayuda.

Si la cuenta, el código o el alojamiento están a nombre de otra persona o dentro de una herramienta que no controlas, el primer paso no es mejorar la aplicación, sino asegurarte de que es tuya.

• ¿Dónde vive la aplicación? El alojamiento es el servicio donde se ejecuta. Debes saber cuál es, a nombre de quién está la cuenta y quién más puede entrar; si la cuenta es de otra persona, la aplicación no es del todo tuya. Dónde mirarlo: en tu correo, los mensajes de alta o de factura de los servicios de alojamiento, y en el panel de tu dominio, que indica a dónde apunta.
• ¿Cuánto pagas al mes, en total? Suma alojamiento, base de datos, dominio, correo, pagos y servicios de IA. Los que cobran por uso pueden crecer con el número de usuarios. Dónde mirarlo: los extractos de la tarjeta y del banco de los últimos meses; apunta cada cargo recurrente y a qué servicio corresponde.
• ¿Tienes el código en un sitio propio y con historial? Un repositorio es una carpeta en línea que guarda cada versión del código. Sin él no puedes volver a la versión anterior si un cambio falla, ni cambiar de proveedor, ni dar acceso a alguien para que lo revise. Dónde mirarlo: pregunta a quien lo creó y mira si la herramienta ofrece exportar el código; si no encuentras nada, apúntalo como pendiente.
• ¿Quién tiene acceso y con qué permisos? Cuenta las personas, las herramientas y las conexiones con otros servicios, y retira el acceso a quien ya no deba tenerlo: cada acceso es una puerta más. Dónde mirarlo: la sección de usuarios o miembros de cada servicio y las invitaciones antiguas en tu correo.

Qué revisar en una app hecha con IA (2 de 2): qué pasa si falla

Las cuatro siguientes no miran cómo funciona la aplicación cuando todo va bien, sino qué ocurre cuando algo falla. Son las que más separan una herramienta de negocio de un prototipo.

La pregunta que más dice de una aplicación es qué harías si se rompiera mañana. Si no hay respuesta, falta una pieza importante.

• ¿Dónde están las claves? Una clave es una contraseña que usa un programa para hablar con otro: con la pasarela de pago, con el correo o con la IA. No deben estar escritas dentro del código ni pegadas en conversaciones con la IA, y si alguna ha acabado ahí conviene cambiarla. Dónde mirarlo: no necesitas leer el código; pregunta a quien lo montó o lo revise dónde se guardan, y recuerda si alguna vez pegaste una en una conversación.
• ¿Hay copias de seguridad y se han probado? Una copia que nunca se ha restaurado es una suposición. Dónde mirarlo: el panel del servicio de base de datos o de alojamiento, si ofrece copias; pregunta cuándo se hizo la última y pide que se pruebe a restaurarla sin tocar la versión que usan tus clientes.
• ¿Qué datos de personas guarda y quién los ve? Nombres, correos, historial de actividad, datos de cobro. La siguiente sección explica por qué esto no es un detalle. Dónde mirarlo: repasa los formularios y pantallas de registro, pagos y seguimiento; casi todo lo que un usuario escribe o genera queda guardado, así que haz una lista.
• ¿Qué pasa si falla? Quién se entera primero (tú o tus usuarios), cómo se vuelve a una versión anterior, quién lo arregla y cuánto tiempo puede estar parada sin dañar al negocio. Dónde mirarlo: pregúntate cómo te enterarías hoy de una caída, si por un aviso o por el mensaje de un usuario enfadado; si es lo segundo, hay trabajo pendiente.

Datos personales y cobros en una app hecha con IA: no se delegan

El Reglamento general de protección de datos no distingue entre un programa escrito por una persona y uno escrito por una IA. Quien decide para qué se usan los datos de las personas es la responsable del tratamiento, y esa responsabilidad es tuya aunque no hayas escrito una sola línea de código. Dos artículos importan aquí. El artículo 32 exige medidas de seguridad adecuadas al riesgo, entre ellas la capacidad de restaurar el acceso a los datos tras un incidente, que es una razón de peso para probar las copias. Y el artículo 33 obliga, ante una violación de la seguridad, a notificarla a la autoridad de control sin dilación indebida y, si es posible, en un máximo de 72 horas desde que se tiene constancia, salvo que sea improbable que suponga un riesgo para las personas. Si no sabes dónde están los datos, ni quién accede, ni si te enterarías de una fuga, cumplir con esto es muy difícil. Para los cobros, la pregunta sencilla es si los datos de la tarjeta pasan por tu aplicación o los gestiona directamente la pasarela de pago. Lo más prudente es lo segundo, pero conviene confirmarlo y no darlo por hecho. Los textos que debe tener una web que recoge datos de personas se resumen en textos legales de una web. Esta sección es informativa, no asesoramiento jurídico, y ante cualquier duda conviene consultarlo con un profesional.

Quien responde ante los usuarios y ante la autoridad de protección de datos eres tú, no la herramienta que escribió el código.

Revisión técnica de una aplicación hecha con IA: cuándo merece la pena y qué incluye

No hace falta revisar una prueba hecha para uso propio. Sí conviene hacerlo cuando la aplicación cobra dinero, guarda datos de terceros, la usan clientes a diario, aparece el mismo tipo de error una y otra vez o los arreglos que intentas dejan otras cosas rotas. Elegir quién la revisa, una persona independiente o un estudio, se plantea en freelance o agencia para tu proyecto IT. Una revisión útil no es una lista interminable de defectos. Debe dejarte un informe que priorice y que puedas leer sin ser técnica. Suele cubrir los seis puntos de la lista. El plazo depende del tamaño, de la documentación y de los accesos que se faciliten. Como referencia, Wavect, una empresa que ofrece este servicio, indica de forma orientativa desde unos días laborables hasta unas dos semanas, y aclara que es su estimación propia y no un estándar del sector.

El resultado de una buena revisión no es un «tu aplicación está mal». Es saber qué es urgente, qué puede esperar y qué decisión tomar.

• Acceso y seguridad: quién puede ver o hacer qué, y si un usuario puede llegar a datos de otro.
• Datos y copias: dónde están, cómo se protegen y si se pueden recuperar.
• Despliegue y costes: dónde se ejecuta, qué se paga y qué depende de cuentas ajenas.
• Estructura del código: si se puede mantener y si cada arreglo es seguro.
• Errores conocidos: cuáles son, qué gravedad tienen y en qué orden conviene arreglarlos.
• Qué se puede dejar tal cual y qué no.

Qué hacer con una app hecha con IA: mantener, mejorar por partes o reconstruir

Con el informe delante se decide entre tres caminos, y reconstruir de cero no es siempre el más sensato ni el más barato. Se mantiene cuando lo encontrado es menor y el negocio puede vivir con ello. Se mejora por partes cuando conviene ordenar un área cada vez, empezando por lo que toca dinero y datos, sin parar el servicio. Y se reconstruye cuando la base impide avanzar o cada cambio rompe algo, y compensa rehacerla con una estructura clara, usando como guía lo que la aplicación actual ya sabe de cómo debe comportarse el negocio. Un orden razonable, que planteamos como criterio general y no como lo que se hizo en este caso, es empezar por asegurar lo que es tuyo: cuentas a tu nombre, código en un repositorio propio, accesos revisados y copias probadas. Es rápido, barato y reduce el riesgo de golpe. Después se corrigen los errores que afectan a cobros o a datos, y solo entonces se ordena la estructura o se decide si rehacerla. Tocar el código antes de asegurar lo anterior es empezar por lo menos urgente. Si lo que necesitas es algo bastante común, quizá no haga falta ni arreglar ni rehacer: software a medida o estándar: cómo decidir ayuda a ver cuándo un programa que ya existe te sirve. Y si decides reconstruir, las referencias generales de inversión y plazo están en cuánto cuesta un software a medida y cuánto tarda desarrollar un software a medida.

Antes de decidir si se mejora o se rehace, asegura lo que es tuyo. Es lo más barato y reduce el riesgo desde el primer día.

Usar IA para construir sí tiene sentido, con estas reglas

Nada de lo anterior es un argumento contra construir con IA. Para probar una idea, montar una herramienta interna pequeña o entender qué necesitas antes de contratar, es una ayuda excelente. El problema aparece cuando el prototipo se convierte, sin que nadie lo decida, en el negocio. Para elegir herramientas con criterio puedes mirar herramientas de IA para pymes, y para introducirla en un proceso concreto, cómo implementar IA en tu empresa. Cuatro reglas evitan casi todos los problemas descritos, además de contestar desde el principio a las ocho preguntas anteriores.

Construir con IA es una buena forma de empezar. La decisión que merece atención es cuándo dejar de ser un prototipo.

• Guarda el código en un repositorio propio desde el primer día, a tu nombre, y no solo dentro de la herramienta con la que lo creas.
• Pide a la IA que te explique lo que ha hecho y qué no ha comprobado. No sustituye a una revisión, pero saca a la luz dudas que de otro modo no aparecerían.
• No metas datos reales de personas ni cobros hasta que alguien con experiencia haya mirado lo básico, y prueba los cambios en una copia antes de tocar lo que usan tus clientes.
• Decide de antemano el momento de revisar: cuando empieces a cobrar, cuando lleguen datos de terceros o cuando se pase de un número de usuarios que tú fijes.

Lo que cambia cuando cualquiera puede construir software

Durante décadas, hacer una aplicación exigía contratar a alguien, y esa persona, además de escribir código, preguntaba, avisaba y ponía límites. Ahora una profesional de cualquier sector puede tener una plataforma funcionando en semanas, y eso es una buena noticia: más gente resuelve sus problemas con tecnología. Lo que no ha cambiado es que hacer software siempre ha incluido un trabajo invisible: decidir dónde vive, cómo se protege, cómo se cambia sin romperlo y quién responde cuando falla. La IA ha abaratado la parte visible. La invisible sigue ahí, y alguien tiene que hacerla. Por eso revisar una aplicación así no debería ser una crítica a quien la construyó, sino devolverle algo que le faltaba: saber qué tenía. Con eso en la mano, las decisiones siguientes se pueden tomar con mucha más claridad.

Preguntas frecuentes sobre una app hecha con IA

Estas son las dudas que más se repiten cuando alguien descubre que su aplicación necesita más que funcionar.

• ¿Es seguro usar una app hecha con IA en mi negocio? Depende de lo que haga y de quién la haya revisado. Para un uso interno y sin datos sensibles, el riesgo es menor. Si cobra o guarda datos de personas, conviene que alguien con experiencia revise antes el acceso, los datos y las copias. Ningún texto, este incluido, puede darte un veredicto sobre tu aplicación sin verla.
• ¿Puedo seguir corrigiendo los errores con la IA? Para cambios pequeños y en una copia de prueba, sí. Es arriesgado hacerlo directamente sobre lo que usan tus clientes, sobre todo sin historial de versiones, porque no puedes valorar si el arreglo rompe otra cosa.
• ¿Hay que reconstruirla desde cero? No necesariamente. A veces basta con asegurar lo básico y corregir lo que afecta a cobros y datos, y otras veces compensa rehacerla por partes. La decisión se toma con la revisión delante, no antes.
• ¿Cuánto tarda una revisión y cuánto cuesta? El plazo y el precio dependen del tamaño, de la documentación y de los accesos; la referencia de plazo de la sección sobre revisión técnica es una estimación de otra empresa. No damos cifras sin ver el caso.
• ¿Qué necesita quien la revise? Acceso de solo lectura al código y a las cuentas de alojamiento, o capturas de ellas, una lista de los servicios contratados, una descripción de lo que hace la aplicación y los errores que ya conoces. No hace falta compartir contraseñas: lo normal es dar accesos limitados.
• ¿Puedes revisar mi aplicación? Sí. Cuéntanos qué has construido, con qué herramienta y qué datos maneja y te decimos si merece la pena una revisión y qué conviene mirar primero.