¿Qué controles necesita una app hecha con IA antes de lanzar?
Por Oleksii Skurikhin · Delivery Manager
- Publicado el
- 8 min de lectura
Averigüe el nivel de su app según quién la abre, qué guarda y si mueve dinero, y haga los controles de ese nivel. Cada control dice qué debería ver al terminar y la trampa que lo falsea.
Puntos clave
- Los controles que necesita una app dependen de quién puede abrirla, qué datos guarda y si mueve dinero. Su nivel es el más alto de las tres respuestas.
- Nivel 1: código en un repositorio privado en línea y solo claves de prueba. El nivel 2 añade inicio de sesión en cada página, claves fuera del código y una copia restaurada con su último registro.
- El nivel 3 añade la revisión de 60 minutos, las siete comprobaciones entre portátil y servidor sobre la app real y una alerta que llegue a un teléfono que alguien lea.
- Con pagos, deje que los clientes escriban la tarjeta solo en la página del proveedor y marque un pedido como pagado solo tras un webhook verificado, nunca en una página de «gracias».
- Haga los controles del siguiente nivel antes del evento que le hace subir de nivel: el primer enlace externo, los pagos reales o los primeros registros reales de clientes.
Los controles de seguridad que necesita una app hecha con vibe coding dependen de tres datos: quién puede abrirla, qué datos guarda y si mueve dinero. Responda a las tres preguntas, averigüe su nivel y haga los controles de ese nivel y los de todos los niveles inferiores.
¿Qué nivel tiene su app?
El nivel de una app es la respuesta más alta de las tres: quién puede abrirla, qué guarda y si cobra pagos. Una herramienta de equipo con datos de la empresa es de nivel 2. Una página pública de registro que recoge correos electrónicos es de nivel 3, y una app que cobra pagos es de nivel 4.
Rellene la hoja antes de seguir leyendo. Cópiela en una nota y elija una respuesta por línea; el número entre paréntesis es su nivel. Su nivel es el número más grande que haya elegido. Usted hace los controles de ese nivel y los de todos los niveles con un número menor.
QUIÉN PUEDE ABRIRLA: SOLO YO (1) | MI EQUIPO (2) | CUALQUIERA EN INTERNET (3)
DATOS QUE GUARDA: NINGUNO O INVENTADOS (1) | DATOS DE LA EMPRESA (2) | CORREOS O ARCHIVOS DE PERSONAS (3) | DATOS DE SALUD, DINERO O IDENTIDAD (4)
DINERO: NINGUNO (1) | COBRA PAGOS (4)
MI NIVEL = EL NÚMERO MÁS GRANDE DE ARRIBA:
Nivel 1: un proyecto de prueba que solo usted abre
Un proyecto de prueba necesita una sola cosa: una vía de vuelta atrás. Guarde el código en Git, una herramienta que registra cada cambio que usted guarda con un commit, y súbalo a un repositorio privado en línea. Así, un portátil perdido o una mala edición de la IA no acaban con el proyecto.
- Listo cuando: el historial del repositorio en línea muestra un commit de hoy y usted puede abrir la versión de ayer de un archivo.
- Trampa: borrar una clave de un archivo no la saca del historial. Una clave es la cadena secreta que permite a su app usar un servicio de pago o privado. Trate como expuesta cualquier clave que alguna vez se haya guardado en un archivo, y use solo claves de prueba en el nivel 1.
Ocultar el archivo más tarde tampoco sirve. El 29 de octubre de 2026 hicimos commit de un archivo .env con una clave de demostración en un repositorio de pruebas (git 2.50.1). Después añadimos .env a .gitignore, el archivo que le dice a Git qué debe dejar fuera. Git siguió rastreando .env, porque ya estaba incluido en un commit. Solo git rm --cached .env detuvo el rastreo.
Incluso entonces, al mostrar el primer commit se imprimió la clave de demostración: se queda en el historial hasta que este se reescribe. En un segundo repositorio de pruebas, donde .env estaba en .gitignore antes del primer commit, Git nunca lo registró. Por eso, incluya .env en .gitignore antes de su primer commit y sustituya cualquier clave que alguna vez haya estado en un commit.
Nivel 2: una herramienta que usa su equipo
Una herramienta de equipo guarda datos de la empresa. Se aplican tres controles: un inicio de sesión en cada página, las claves fuera del código y una copia de seguridad que usted haya restaurado.
- Inicio de sesión. Listo cuando: en una ventana privada del navegador, sin haber iniciado sesión, pega la dirección de una página interna y llega a la página de inicio de sesión. Con la sesión iniciada como un compañero, cambia el número de registro en la dirección y no puede abrir el registro de otro compañero. Trampa: solo la primera página pide iniciar sesión.
- Claves. Listo cuando: cada clave está en los ajustes de su alojamiento, el servicio que ejecuta su app. Una búsqueda en el código de los primeros caracteres de la clave no encuentra nada. Trampa: buscar solo en el código del servidor. Busque también en la parte de la app que se ejecuta en el navegador, y trate como pública una clave que encuentre ahí.
- Copia de seguridad. Listo cuando: restaura la última copia de seguridad en una copia nueva y separada de la app, inicia sesión en ella y encuentra el registro más reciente que recuerda haber creado. Trampa: una copia de seguridad que nadie ha restaurado es una suposición. Una copia guardada en la misma cuenta que la app se pierde con esa cuenta.
Nivel 3: una app en la que se registran desconocidos
Una app pública suma desconocidos y sus datos. Antes del lanzamiento, haga las cinco comprobaciones de nuestra revisión de 60 minutos y las siete comprobaciones entre el portátil y el servidor, y después configure una alerta.
- Alerta. Listo cuando: un monitor abre la dirección de su app con una periodicidad fija. Cuando lo apunta una vez a una dirección equivocada, llega un mensaje a un teléfono que alguien lee. Trampa: la alerta va a una bandeja de entrada que nadie abre.
Nivel 4: dinero o datos que podrían perjudicar a personas
El nivel 4 se divide en dos. Con pagos, el riesgo es perder dinero; con datos de salud, dinero o identidad, el riesgo es dañar a personas.
- Página de pago. La guía de seguridad y cumplimiento de PCI de Stripe dice que una empresa que maneja datos de tarjetas directamente puede tener que cumplir más de 300 controles de seguridad. También dice que las integraciones de bajo riesgo de Stripe envían los datos de pago directamente a Stripe sin pasar por sus servidores. Listo cuando: se completa un pago de prueba y el número de tarjeta se escribe solo en la página del proveedor. Trampa: un formulario de tarjeta propio que se parece al del proveedor.
- Eventos de pago. Un webhook es un mensaje que el proveedor de pagos envía a su app cuando ocurre algo. La documentación de webhooks de Stripe dice que hay que verificar que los eventos vienen de Stripe antes de actuar sobre ellos. Sin esa comprobación, dice Stripe, un atacante podría enviar eventos falsos que desencadenen acciones como conceder acceso a una cuenta. Listo cuando: un pedido pasa a «pagado» solo tras el evento verificado, nunca porque el cliente llegó a una página de «gracias». Trampa: la página de «gracias» marca el pedido como pagado.
- Datos sensibles. Listo cuando: tiene una lista escrita de cada tipo de usuario, cada tabla o almacén de archivos, y si ese usuario puede leerlo o escribirlo. Junto a cada línea está el resultado de probarlo sin sesión iniciada y como otro usuario. Trampa: la comprobación cubre las pantallas, no las peticiones de datos que hay detrás. Los contratos inteligentes tienen sus propias comprobaciones antes de mainnet.
Para encontrar dónde hace su código ambas cosas, pegue esto en su herramienta de programación con IA, trabajando sobre una copia del proyecto. Su respuesta es una lista de pistas: abra cada archivo y línea que nombre antes de marcar la comprobación.
Lea este proyecto sin cambiar nada. Dígame dónde escribe un cliente el número de tarjeta: en la página propia del proveedor de pagos o en un formulario de nuestro código. Después busque el código que marca un pedido como pagado y dígame si se ejecuta solo tras un evento verificado del proveedor, o también cuando el cliente llega a la página de «gracias». Indique el archivo y la línea de cada respuesta.Suba de nivel antes del evento, no después
El paso al siguiente nivel es un evento que usted controla, así que haga los controles del siguiente nivel antes de que ocurra:
- el día en que envíe el enlace a alguien ajeno al equipo;
- el día en que cambie los pagos del modo de prueba al modo real;
- el día en que cargue los registros del primer cliente real.
Imagine a un fundador cuya herramienta de reservas del equipo está en el nivel 2. Mañana el primer cliente externo recibe el enlace. Hoy el fundador busca claves en el código y restaura la última copia de seguridad en una copia. Después hace la revisión de 60 minutos y los controles de despliegue, y apunta la alerta a una dirección equivocada una vez.

Si las correcciones de la IA siguen rompiendo la app mientras trabaja un nivel, responda a sus cinco preguntas. Ayudan a decidir si seguir dando instrucciones o pasar el trabajo a otra persona. Cuando su agente de programación con IA diga que todas las pruebas pasan, compruebe que realmente las ejecutó: pida el comando de las pruebas y su salida completa.
Hasta dónde llegan estos controles
Los controles por niveles de arriba son un consejo nuestro, no un estándar, y por sí solos no hacen segura una app. La ley de privacidad, las normas de pago con tarjeta y una revisión de seguridad profesional quedan fuera de ellos. Recurra a un ingeniero antes del día en que una app llegue al nivel 4, y siempre que un control de los anteriores muestre algo que usted no pueda explicar.
Compruebe hoy
Rellene la hoja, haga un control de su nivel y anote lo que vio en la pantalla. Un resultado escrito es la prueba de que el control se hizo; una línea vacía le dice qué hacer a continuación.
Siguiente paso
Fuentes
- Documentación de Stripe, guía de seguridad y cumplimiento de PCI, consultada el 28 de octubre de 2026.
- Documentación de Stripe, webhooks, consultada el 28 de octubre de 2026.
Sobre el autor

Categoría:Desarrollo de softwarePublicación y despliegue
Volver al blog

