Software creado con IA: 6 revisiones antes de usarlo
Has creado una aplicación con IA y la demostración funciona: guarda solicitudes, muestra un panel y envía un correo. Antes de usarla en tu empresa, conviene comprobar qué sucede con usuarios, datos e incidencias reales. El objetivo de revisar el software creado con IA es decidir qué puede ponerse en marcha, qué necesita correcciones y quién se ocupará de mantenerlo.
Estas seis revisiones te ayudarán a pedir evidencias concretas a quien evalúe el proyecto. El alcance debe adaptarse a la información que maneja y al impacto de un fallo; esta lista no constituye una auditoría completa ni garantiza seguridad absoluta.
1. Comprueba las reglas del trabajo, además de las pantallas
Prepara una lista breve de operaciones imprescindibles y escribe el resultado esperado de cada una. Incluye errores, cancelaciones y pasos fuera de orden.
Ejemplo hipotético: una empresa ha creado una aplicación para aprobar gastos. Un empleado presenta una solicitud, su responsable la revisa y administración prepara el reembolso. Hay que comprobar qué ocurre si el empleado cambia el importe después de la aprobación, envía dos veces la misma solicitud o intenta aprobar su propio gasto. El equipo debe decidir esas reglas antes de programar las respuestas.
Evidencia que pedir: una relación de casos probados, resultado obtenido y fallos pendientes, identificando la versión revisada.
2. Prueba los permisos con cuentas diferentes
Ocultar un botón no demuestra que una acción esté protegida. OWASP recomienda comprobar la autorización en cada petición y aplicar el mínimo privilegio.
En el ejemplo de gastos, prueba con cuentas separadas de empleado, responsable y administración. Un empleado no debería consultar solicitudes ajenas modificando el identificador de un enlace. También debe comprobarse qué ocurre al retirar un permiso o desactivar una cuenta.
Evidencia que pedir: una matriz de roles y operaciones, acompañada de pruebas de acceso permitido y denegado en el servidor.
3. Revisa claves, componentes y acceso al proyecto
Solicita un inventario de librerías, versiones y servicios externos. Comprueba quién controla el repositorio, el alojamiento y las cuentas necesarias para operar. Una aplicación puede funcionar hoy y depender de una cuenta personal que la empresa no administra.
Las claves de API y contraseñas requieren almacenamiento y acceso controlados. La guía de gestión de secretos de OWASP aborda su protección, rotación y revocación. Si una clave se ha expuesto, borrarla del archivo no basta: hay que invalidarla y sustituirla.
Evidencia que pedir: inventario técnico, revisión de dependencias y procedimiento para entregar o retirar accesos. No envíes claves ni bases de datos de clientes por un formulario de contacto.
4. Distingue una integración real de una simulación
Un mensaje de «enviado» puede aparecer aunque el correo o la conexión con el CRM no estén completos. Sigue una operación hasta el sistema de destino y verifica el registro que realmente se ha creado.
Usa un entorno de pruebas o datos de prueba autorizados. Comprueba la respuesta ante una credencial caducada, un servicio no disponible y una operación repetida. Si conectas CRM y ERP, define también qué sistema manda sobre cada dato.
Evidencia que pedir: resultados verificables en origen y destino, junto con un procedimiento para atender operaciones que quedan a medias.
5. Ensaya cómo recuperar el servicio y los datos
Antes de incorporar información real, acuerda cuántos datos sería aceptable perder y cuánto tiempo podría estar parada la aplicación. Esas necesidades sirven para dimensionar las copias y el procedimiento de recuperación.
Pide una restauración en un entorno separado. Comprueba que recupera los registros y los archivos necesarios, y cuánto tarda. Volver a una versión anterior del código no deshace por sí solo los cambios realizados en la base de datos.
Evidencia que pedir: fecha del ensayo, datos recuperados, duración y responsable de ejecutar la recuperación.
6. Define quién mantiene la aplicación después del estreno
Acuerda quién recibe los avisos de error, actualiza componentes y revisa nuevas versiones. Prueba con un volumen de datos y usuarios simultáneos representativo de tu negocio, fijando antes tiempos de respuesta aceptables.
El marco SSDF del NIST plantea prácticas de desarrollo seguro a lo largo del ciclo de vida del software. Una revisión inicial debe acompañarse de continuidad técnica.
Qué debería quedar documentado
- Instrucciones para instalar y desplegar la versión revisada.
- Pruebas realizadas, riesgos pendientes y funciones excluidas del alcance.
- Responsables de soporte, copias, actualizaciones y cuentas del servicio.
- Un procedimiento para detener una operación problemática y recuperar el trabajo.
Cómo decidir si está lista para utilizarse
Si fallan permisos, integridad de datos o recuperación, resuelve esos puntos antes de abrir la aplicación al uso previsto. Si las comprobaciones acordadas pasan y los riesgos restantes son aceptables para la empresa, puede plantearse un piloto acotado, con personas responsables y criterios para detenerlo.
Para concretar una evaluación técnica más amplia, OWASP ASVS ofrece requisitos de verificación de seguridad de aplicaciones. La selección y profundidad de las pruebas dependen del proyecto.
En Serboweb podemos revisar tu software creado con IA y valorar qué partes aprovechar, corregir o completar. Describe qué has creado, quién lo utilizará y qué operación necesitas poner en marcha. Tras el diagnóstico se concreta el alcance, incluido el desarrollo a medida que pudiera hacer falta.