Crear una aplicación interna ya no exige empezar con un proyecto de seis meses. Un equipo puede describir un flujo, pedir ayuda a un asistente de programación, conectar una base de datos y tener una primera versión útil en días. Ese cambio es positivo: acerca el desarrollo a personas que conocen muy bien el problema, aunque no se dediquen profesionalmente al software.
Pero una demostración que funciona y una aplicación preparada para el uso diario no son exactamente lo mismo. La diferencia se ve incluso en las herramientas de los propios desarrolladores. El 9 de junio de 2026, GitHub amplió su validación de seguridad al código creado por agentes de programación de terceros: análisis de vulnerabilidades con CodeQL, comprobación de nuevas dependencias y búsqueda de claves o tokens expuestos. Y el 18 de septiembre anunció mejoras en la revisión de código de Copilot, entre ellas el uso de herramientas de consola para validar cambios.
Son funciones de un proveedor concreto, no una garantía universal. Sin embargo, apuntan a una conclusión razonable: producir código con IA puede acelerar el trabajo, pero no elimina la necesidad de comprobar cómo se comporta el sistema con usuarios, datos y fallos reales.
Si has creado una aplicación con IA para tu empresa, este artículo te ayudará a decidir qué puedes revisar internamente, qué conviene corregir antes de ponerla en producción y cuándo tiene sentido pedir una revisión técnica acotada.
Antes de revisar: define qué significa «usar la aplicación de verdad»
Una herramienta para una sola persona, con datos poco sensibles y sin integraciones, no necesita el mismo nivel de control que un portal para clientes. La revisión debe ser proporcional al daño que produciría un error, no a lo sofisticada que parezca la interfaz.
Empieza por describir cuatro cosas: quién la utilizará, qué datos tratará, qué acciones podrá ejecutar y de qué sistemas dependerá. Después añade una pregunta incómoda, pero muy práctica: ¿qué pasa si deja de funcionar durante una hora, un día o una semana?
Imaginemos una aplicación interna para registrar solicitudes de vacaciones. Si la usan cinco personas y el dato definitivo sigue estando en una hoja controlada, una versión sencilla puede ser suficiente. Si la aplicación calcula saldos, aprueba ausencias, notifica a responsables y escribe directamente en el sistema de personal, ya hay permisos, trazabilidad, integridad de datos y continuidad que revisar.
Tip técnico: prepara un inventario de una página con usuarios, roles, datos, integraciones, entorno de alojamiento y responsable. Si no puedes explicar el sistema sin abrir el código, todavía falta documentación operativa.
1. Los permisos deben comprobarse en el servidor
Ocultar un botón no impide que alguien invoque la acción que había detrás. Una aplicación puede mostrar correctamente un menú distinto a cada perfil y, al mismo tiempo, aceptar una petición directa de un usuario sin autorización. Por eso hay que comprobar los permisos en el servidor o en la capa que ejecuta la operación, no solo en la pantalla.
La revisión más útil no empieza con una larga lista de vulnerabilidades teóricas. Empieza con los roles reales: administrador, responsable, empleado, cliente o proveedor. Para cada uno, se comprueba qué puede consultar, crear, modificar, exportar y borrar. También hay que probar los cruces entre cuentas: un usuario no debería poder acceder al registro de otro cambiando un identificador en la dirección o en una petición.
Conviene revisar además el alta y la baja. ¿Quién crea cuentas? ¿Qué sucede cuando una persona deja la empresa? ¿Hay sesiones que permanecen abiertas indefinidamente? ¿Una cuenta desactivada conserva acceso mediante un enlace antiguo o un token?
Tip técnico: crea una matriz sencilla de roles y acciones. Después ejecuta las pruebas con una cuenta por rol, incluida una cuenta sin permisos. Probar solo como administrador oculta buena parte de los problemas de autorización.
2. Las credenciales no pueden vivir dentro de la aplicación
Las aplicaciones creadas rápidamente suelen necesitar claves para enviar correos, consultar un modelo, acceder a un ERP o conectarse a una base de datos. El riesgo aparece cuando esas claves terminan en el repositorio, en el código que descarga el navegador, en una captura o en un registro de errores.
GitHub explica en su documentación de secret scanning que puede detectar credenciales y otros secretos conocidos dentro de repositorios. Es una red de seguridad valiosa, pero encontrar una clave no sustituye a diseñar bien su almacenamiento y su ciclo de vida.
La configuración sensible debería estar fuera del código y separada por entornos. Desarrollo, pruebas y producción no tendrían que compartir las mismas credenciales ni, salvo una razón justificada, los mismos datos. Las claves deben tener el permiso mínimo necesario, poder rotarse y pertenecer a una cuenta controlada por la empresa, no a la cuenta personal de quien montó el prototipo.
Si una clave ya se ha publicado, borrarla de la última versión del código no basta: puede seguir en el historial. La respuesta prudente es revocarla, generar otra y revisar los accesos asociados.
Tip técnico: busca patrones de secretos en el repositorio y en el código servido al navegador. Revisa también archivos de configuración, historiales, copias comprimidas y registros. Si aparece una credencial real, trátala como expuesta aunque el repositorio sea privado.
3. La base de datos necesita reglas, no solo formularios
Un formulario puede exigir un correo válido o impedir una fecha imposible, pero esas comprobaciones de interfaz no protegen por sí solas la información. Los datos también pueden llegar por una API, una importación o una petición manipulada. Las reglas importantes deben existir en el lado que guarda la información.
Revisar una aplicación implica buscar identificadores únicos, relaciones obligatorias, formatos coherentes y operaciones que deban completarse juntas. Si el sistema crea un pedido y descuenta existencias, no debería dejar la mitad del proceso hecha cuando falla el segundo paso.
También importa cómo cambia el esquema. Una modificación generada deprisa puede funcionar con una base vacía y fallar al aplicarse sobre datos reales. Antes de migrar, conviene ensayar con una copia anonimizada o un conjunto representativo y definir cómo se vuelve atrás si algo no sale bien.
Tip técnico: prueba entradas repetidas, vacías, demasiado largas y simultáneas. Dos personas pulsando «aprobar» casi a la vez revelan errores que rara vez aparecen durante una demostración individual.
4. Una copia no sirve hasta que se ha probado la recuperación
Que el proveedor indique que realiza copias no responde a todas las preguntas. Hay que saber qué se copia, cada cuánto, cuánto tiempo se conserva, quién puede recuperarlo y cuánto tardaría el proceso. También conviene confirmar si la base de datos, los archivos adjuntos y la configuración están incluidos.
La diferencia entre tener copias y poder recuperar el servicio solo se demuestra restaurando. No hace falta convertir cada herramienta interna en un sistema de alta disponibilidad, pero sí acordar un objetivo razonable. En una aplicación auxiliar quizá sea aceptable perder las últimas horas y recuperarla al día siguiente. En un proceso que bloquea pedidos, ese margen puede ser demasiado amplio.
La prueba debe realizarse en un entorno separado y terminar con una comprobación funcional: iniciar sesión, abrir registros, descargar un documento y ejecutar el flujo crítico. Restaurar archivos sin verificar la aplicación deja la mitad del trabajo sin comprobar.
Tip técnico: anota la fecha de la última restauración probada, el tiempo empleado y los pasos manuales. Una instrucción de recuperación corta y actualizada vale más que una copia cuya ruta solo conoce una persona.
5. Las integraciones fallan de formas normales
Correo, pagos, almacenamiento, CRM, ERP y modelos de IA pueden responder tarde, limitar peticiones o cambiar. Una aplicación preparada para producción no presupone que todas las llamadas externas terminarán bien a la primera.
La revisión debe localizar tiempos máximos de espera, reintentos y tratamiento de duplicados. Si una respuesta tarda, no conviene que el usuario pulse varias veces y cree varios pedidos. Para operaciones sensibles se utiliza una clave de idempotencia o un identificador único que permita reconocer el mismo intento. Cuando el proveedor responde con un error temporal, el sistema puede reintentar con pausas crecientes; cuando el dato es incorrecto, repetir no arregla nada y la incidencia debe quedar visible.
También hace falta saber quién se entera del fallo. Guardar el error en un registro que nadie consulta equivale, en la práctica, a no avisar. Este punto conecta con el mantenimiento de automatizaciones cuando cambian proveedores o APIs: la continuidad no depende solo del código inicial, sino de detectar y atender las excepciones.
Tip técnico: simula una clave caducada, un límite de peticiones y una respuesta lenta. Comprueba qué ve el usuario, qué queda registrado y si repetir la operación genera duplicados.
6. Pruebas y observabilidad: comprobar lo que importa
No todas las líneas necesitan el mismo nivel de prueba. La prioridad son los recorridos que sostienen el proceso: entrar, crear un registro, aprobarlo, cobrar, enviar, exportar o recuperar. Una pequeña batería automática sobre esos flujos da más confianza que muchas pruebas superficiales.
Después están los controles automáticos: análisis del código, dependencias con vulnerabilidades conocidas y detección de secretos. La validación que GitHub aplica al código generado por agentes combina precisamente esas capas. Aun así, un análisis automático no sabe si el rol comercial puede ver un margen que solo corresponde a dirección, ni si una factura se registra dos veces por una regla de negocio mal planteada.
El Secure Software Development Framework de NIST presenta la seguridad como prácticas que se integran en el ciclo de desarrollo, no como una inspección aislada al final. En una pyme, esa idea puede aplicarse sin burocracia: cambios versionados, una revisión antes de desplegar, dependencias actualizadas, copias probadas y una forma de detectar errores.
La observabilidad debe ser útil y proporcionada. Registra el tipo de operación, su resultado y un identificador de seguimiento, pero evita volcar contraseñas, tokens, documentos completos o datos personales innecesarios. Define una alerta para los fallos relevantes y un responsable que pueda actuar.
Tip técnico: construye una prueba de humo que tarde pocos minutos y recorra el flujo principal tras cada despliegue. Añade una comprobación de salud para base de datos y servicios externos, sin exponer detalles sensibles al público.
Qué puede incluir una revisión técnica acotada
Una revisión útil necesita un perímetro claro. Para una aplicación interna pequeña, podría abarcar el repositorio y la configuración, los roles, el tratamiento de credenciales, el modelo de datos, las copias, las integraciones y dos o tres recorridos críticos. El resultado debería ser una lista priorizada de hallazgos: qué corregir antes de usarla, qué mejorar después y qué riesgo se puede aceptar de forma consciente.
También debe indicar sus límites. Una revisión acotada no equivale automáticamente a una auditoría completa, una prueba de intrusión, una certificación, una revisión jurídica o una garantía de ausencia de errores. Si alguno de esos trabajos es necesario, se define y presupuesta por separado.
En The Black Box Lab podemos estudiar una revisión técnica y la estabilización de software con un alcance acordado. Puede terminar en un informe y una sesión de entrega, o incluir correcciones concretas si ambas partes las delimitan. La decisión depende del estado de la aplicación, de lo que haga y del nivel de riesgo asumible.
Cuándo puedes resolverlo internamente
Un servicio externo no siempre compensa. Si la aplicación la usa una sola persona, no contiene información delicada, no modifica sistemas centrales y existe una alternativa manual sencilla, una lista interna y unas horas de prueba pueden ser suficientes. También puede bastar la revisión de alguien del equipo con experiencia en desarrollo que no haya participado en la construcción.
Pedir ayuda empieza a tener más sentido cuando hay varios roles, datos de clientes o empleados, acceso desde Internet, cobros, decisiones automáticas, integraciones que escriben en otros sistemas o una fecha de puesta en marcha difícil de revertir. Otro indicador es la concentración de conocimiento: si solo una persona sabe desplegar, recuperar o renovar credenciales, la aplicación tiene una dependencia operativa aunque el código sea correcto.
La pregunta no es si la IA «programa bien» o «programa mal». La calidad depende del contexto, de las instrucciones, de la arquitectura y de la verificación. Una solución interna sencilla puede ser exactamente lo que la empresa necesita; prepararla para producción consiste en conocer sus límites y comprobar los riesgos relevantes.
Conserva la velocidad, añade una comprobación independiente
La IA permite llegar antes a una primera versión. Sería un error renunciar a esa ventaja; también lo sería confundir velocidad de construcción con preparación operativa. Permisos comprobados en el servidor, secretos fuera del código, reglas de datos, restauraciones ensayadas, integraciones tolerantes a fallos y pruebas de los recorridos críticos forman una base razonable.
Si quieres valorar una revisión concreta, cuéntanos para qué sirve la aplicación, cuántas personas y roles la utilizarán, qué datos maneja, dónde está alojada, con qué sistemas se integra y en qué fase se encuentra. No envíes contraseñas ni claves. Con esa información podremos decirte si basta una comprobación interna, qué alcance tendría una revisión técnica y qué quedaría expresamente fuera.
Fuentes
- GitHub: Security validation for third-party coding agents, 9 de junio de 2026.
- GitHub Copilot weekly releases, semana del 14 de septiembre, 18 de septiembre de 2026.
- GitHub Docs: About secret scanning.
- NIST SP 800-218: Secure Software Development Framework, versión 1.1.
Deja una respuesta