En el desarrollo de software con inteligencia artificial, la IA escribe el código rápido, pero la responsabilidad de que funcione sigue siendo de una persona. En el proyecto de un concesionario de carros usados en Barranquilla, la mayor parte del código la escribió un agente de IA y las pruebas las hice yo, con una regla simple: ninguna función avanza hasta que alguien la use como la usaría el cliente. Esa regla encontró cuatro fallas que el código, leído en papel, no tenía. Una de ellas habría sido un problema legal.
La regla: usar cada función como la usaría el cliente
No probé el software leyendo el código ni confiando en que “se ve bien”. Me senté a usarlo como lo haría el dueño del concesionario: desde el celular, escribiendo mal la clave a propósito, intentando recuperar la cuenta, entrando como un visitante cualquiera. Probar así, con la cabeza del cliente puesta, es lo que separa un software que parece terminado de uno que de verdad lo está.
Aquí van las cuatro cosas que aparecieron. Ninguna se veía en el código. Todas se vieron al usarlo.
Problema 1: el bloqueo de cuenta llegaba un intento tarde
El panel debía bloquear la cuenta al quinto intento fallido de contraseña, una medida básica contra quien prueba claves a la fuerza (OWASP la recomienda). Lo probé escribiendo mal la clave una y otra vez, y el bloqueo llegó al séptimo intento, no al quinto.
La causa era de orden: el sistema revisaba el límite antes de contar el intento, no después. Un detalle invisible leyendo el código y obvio al usarlo. Dos intentos de más no suenan a mucho, pero en seguridad el margen es justo lo que no quieres regalar.
Problema 2: el enlace de recuperar contraseña no llevaba a ningún lado
La recuperación de contraseña fallaba de una forma silenciosa. El correo llegaba bien, pero el enlace mandaba a la página de inicio en vez de a la pantalla para escribir la clave nueva. En la práctica, nadie habría podido recuperar su cuenta.
Había dos causas, una en la configuración y otra en la protección de rutas. Las dos se corrigieron el mismo día. Lo importante del caso es que un correo que “llega bien” no significa que el proceso funcione. Solo probándolo de punta a punta, hasta escribir una clave nueva y volver a entrar, se ve dónde se rompe.
Problema 3: un visitante sin cuenta podía leer datos del dueño del carro
Este fue el más serio. Pedí una prueba explícita: entrar al sitio como un visitante cualquiera, sin cuenta, e intentar leer los datos del dueño de cada carro. Se podía.
El nombre y el teléfono del propietario estaban ocultos en la pantalla, pero no en la base de datos. Cualquiera que supiera mirar podía sacarlos. Es el tipo de falla que OWASP llama control de acceso roto, y en Colombia no es solo un descuido técnico: datos personales expuestos son un incumplimiento de la Ley 1581 de 2012 de protección de datos, que vigila la Superintendencia de Industria y Comercio.
Se cerró con permisos por columna, para que la base no entregue esos campos a quien no debe, y se volvió a probar. Ahora el visitante recibe “permiso denegado”. Que los datos no se vean en pantalla nunca es suficiente; tienen que estar protegidos en la base.
Problema 4: unas claves de prueba en el repositorio
El cuarto fue un descuido mío. Subí al repositorio unos archivos temporales con claves. En vez de suponer que no pasaba nada, pedí una auditoría: revisar cada archivo y cada versión del historial, y clasificar cada clave una por una.
Resultaron ser claves de prueba, iguales en todas las instalaciones y sin riesgo real. Pero eso lo sé porque se revisó, no porque lo asumí. Quedaron excluidas del repositorio para siempre. La diferencia entre “creo que no era nada” y “verifiqué que no era nada” es toda la diferencia cuando hablamos de la seguridad de un cliente.
Lo que la IA acelera y lo que no
La inteligencia artificial acelera la escritura del código. No acelera la responsabilidad.
Las cuatro fallas de arriba las escribió un agente de IA que, en su lógica, hizo lo pedido. El bloqueo existía, el correo se enviaba, la pantalla ocultaba los datos. Sobre el papel, todo correcto. Lo que ningún agente hizo por sí solo fue sentarse a usar el software con la desconfianza de quien quiere romperlo. Eso lo hace una persona, y es justo lo que hace que el software sea confiable.
Esta forma de trabajar, pedir el plan antes del código y probar cada paso, es la misma que me dejó entregar el software de ese concesionario cinco días antes de la fecha.
Qué preguntar a quien desarrolla tu software con IA
Si vas a contratar desarrollo de software y te dicen que lo hacen con inteligencia artificial, estas preguntas te dicen si lo hacen bien:
| Pregunta | Respuesta que buscas |
|---|---|
| ¿Quién prueba lo que escribe la IA? | Una persona, usando el sistema como el cliente, no solo revisando el código |
| ¿Probaron la seguridad con un usuario sin cuenta? | Sí, intentando leer datos que no debería ver |
| ¿Mis datos están protegidos en la base o solo ocultos en pantalla? | Protegidos en la base, con permisos por columna |
| ¿Cumple la Ley 1581 de protección de datos? | Sí, y saben explicarte cómo |
Un “lo hace la IA, no te preocupes” es exactamente la respuesta que no quieres. La IA no se preocupa. Alguien tiene que hacerlo.
Así trabajamos en SedeOps
En SedeOps desarrollamos software e inteligencia artificial para concesionarios y negocios en Colombia, y ninguna función llega a tus clientes sin que una persona la pruebe como la usarían ellos. Si quieres un software que no solo funcione el día de la demo, escríbenos por WhatsApp y lo hablamos. También puedes ver qué hacemos en SedeOps o contarnos tu caso.
Sobre el autor. Alexander García es fundador de SedeOps, agencia de desarrollo de software e inteligencia artificial en Barranquilla, Colombia. Puedes seguirlo en LinkedIn.
Escrito por Alexander García con apoyo de herramientas de IA, revisado y verificado por el autor.