Testing, seguridad y privacidad del código

Tests generados que sí sirven

Pedirle generame tests a secas produce tests que pasan con cualquier código (asserts tibios que no verifican nada). Para tests útiles:

• Pasale el comportamiento esperado, no solo el código: casos, bordes, errores.
• Pedí casos borde explícitos: vacíos, nulos, límites, concurrencia.
• Exigí que fallen primero contra un bug conocido (o rompé el código a propósito para comprobarlo).
• Revisá los asserts uno por uno: un test que no puede fallar es decoración.

El mejor uso es invertido: que la IA genere tests de tu especificación antes de generar la implementación, y que la implementación tenga que pasarlos.

Seguridad: segunda mirada, no auditoría

La IA es buena segunda mirada de seguridad: pedirle que revise un diff buscando inyección SQL, XSS, secretos hardcodeados, validaciones faltantes y manejo inseguro de errores encuentra problemas reales. Pero no es una auditoría: no garantiza ausencia de vulnerabilidades ni conoce tu modelo de amenazas.

Reglas de oro: nunca le pidas que genere código criptográfico original (usá librerías estándar), tratá sus afirmaciones de esto es seguro como opiniones a verificar, y en código sensible sumá revisión humana experta más herramientas de análisis estático.

Privacidad del código

Todo lo que pegás en un servicio externo de IA sale de tu red y se rige por las condiciones de ese proveedor (algunos entrenan con esos datos salvo exclusión explícita). En código propietario:

• Nunca subas secretos: claves API, tokens, certificados, contraseñas. Si ya pasó, rotalos.
• Minimiza el contexto sensible: pasá el módulo necesario, no el repositorio con datos de clientes.
• Revisá el contrato del proveedor: tiers empresariales suelen ofrecer retención cero y no entrenamiento.
• Para lo más sensible, IA local: sin salida de red, sin contrato que leer.

Fuentes

• OWASP Top 10 for LLM Applications (especificacion) · consultado 20/09/2026