Tu equipo puede construir en días lo que antes tomaba semanas, y eso incluye introducir vulnerabilidades que antes tardaban semanas en aparecer. La velocidad de la construcción dirigida por IA es real, pero los nuevos vectores de ataque que introduce son igual de reales.

Prompt injection: el ataque que no ves venir

La inyección de prompt ocurre cuando input controlado por un usuario externo modifica las instrucciones que recibe el modelo. Si tu aplicación toma texto del usuario y lo concatena directamente en un system prompt, un atacante puede redirigir el comportamiento del modelo. La mitigación: separar arquitectónicamente las instrucciones del sistema del contenido del usuario.

Data leakage y exposición de contexto

Escenarios comunes: un agente que recibe documentos confidenciales y cuya respuesta es visible para otros usuarios; un sistema RAG que recupera fragmentos a los que el usuario no debería tener acceso; logs de requests al modelo que contienen PII. El DM debe auditar qué información entra al contexto del modelo en cada flujo.

«El modelo no sabe qué es confidencial. Solo sabe qué está en su contexto. La responsabilidad de esa frontera es del equipo que lo despliega.» — Delivery Master, SFD

Supply chain del modelo y dependencias de IA

Las librerías de agentes — LangChain, LlamaIndex, CrewAI — tienen historial de vulnerabilidades que se parchean en versiones menores sin mucho ruido. La práctica mínima: fijar versiones de todas las dependencias de IA, revisar changelogs de seguridad antes de actualizar y no usar modelos open-source sin revisión de procedencia cuando el feature procesa datos sensibles.

Lo que el DM debe revisar en código generado

El DM debe hacer una revisión de seguridad específica en: manejo de secretos (el modelo tiende a hardcodear valores de ejemplo), validación de inputs antes de que lleguen al modelo, manejo de errores que podría exponer información del sistema y permisos de los agentes autónomos. Deployar rápido sin revisar la seguridad no es FAST Delivery: es deuda de seguridad que se paga con intereses.

OWASP publicó el Top 10 para LLMs porque los equipos estaban integrando modelos en producción sin un marco común de riesgos. Si tu equipo construye features con IA, esta lista no es documentación académica: es lo que van a intentar explotar antes de que tu producto tenga suficientes usuarios para ser un objetivo.

Los riesgos de mayor probabilidad para equipos de desarrollo

LLM01 — Prompt Injection: El más prevalente. Hay dos variantes: directa (el usuario manipula el prompt) e indirecta (el modelo procesa contenido externo con instrucciones maliciosas). El control mínimo es nunca confiar en contenido externo como instrucción y separar el system prompt del user content.

LLM02 — Insecure Output Handling: El modelo produce un output que la aplicación ejecuta sin sanitización — por ejemplo, SQL ejecutado directamente o HTML inyectado en el DOM. El principio: tratar el output del modelo como untrusted input.

LLM06 — Sensitive Information Disclosure: El modelo revela en su respuesta información que estaba en su contexto. La mitigación requiere diseño cuidadoso de qué entra al contexto y output filtering antes de retornar respuestas.

«Cada riesgo del OWASP LLM Top 10 tiene un denominador común: asumir que el modelo se comportará como fue diseñado, con todos los inputs posibles.» — Equipo de Seguridad, SFD

Riesgos de arquitectura y supply chain

LLM05 — Supply Chain Vulnerabilities: Las dependencias de IA tienen una cadencia de vulnerabilidades más alta porque el ecosistema es joven. Política mínima: pinear versiones y suscribirse a los advisories de seguridad de cada dependencia. LLM08 — Excessive Agency: Agentes con demasiados permisos tomando acciones irreversibles sin confirmación humana. Si tu agente puede modificar registros o llamar APIs externas con consecuencias reales, necesita guardarraíles explícitos.

Controles mínimos no negociables antes de producción

Validación y sanitización de todo input que toca el modelo. Output filtering antes de retornar al usuario. Logging de las interacciones (sin PII). Rate limiting en endpoints que invocan el modelo. Revisión de permisos de los agentes aplicando mínimo privilegio. Estos cinco controles son la diferencia entre un incidente que descubres en tus logs y uno que descubres en las noticias.

Cuando la IA escribe el 60% de tu código, la pregunta ya no es si el sistema funciona — la pregunta es quién firma debajo. La adopción masiva de Copilot, Claude y Cursor ha acelerado la producción de software, pero ha abierto un vacío legal y operativo que la mayoría de los equipos prefiere ignorar hasta que llega una auditoría.

¿Quién es responsable cuando la IA introduce una vulnerabilidad?

La respuesta corta: la organización que desplegó el código. Los modelos de lenguaje no tienen personalidad jurídica. El equipo que integró, revisó y desplegó ese código es el responsable ante los marcos normativos. El problema se agrava porque los equipos con AI-TDA generan código a alta velocidad sin establecer quién revisó qué, cuándo y con qué criterio — trazabilidad cero.

Cómo establecer trazabilidad real en código generado por IA

El primer paso: tratar cada fragmento generado por IA como si viniera de un proveedor externo — revisión explícita, aprobación registrada y asociación a un requerimiento. En FAST Delivery, el Delivery Master firma la revisión de cada bloque de código, independientemente de si lo escribió un humano o un modelo. Las herramientas ayudan: commits con metadatos de origen, etiquetas en PRs que distingan código humano de asistido.

Qué dicen SOC 2, ISO 27001 y GDPR sobre código generado por IA

Ninguno prohíbe el uso de IA para escribir código. Pero todos exigen que los controles de acceso, integridad y trazabilidad se mantengan independientemente de cómo se produjo el software. SOC 2: el criterio CC8.1 exige revisión formal de cada cambio al sistema. ISO 27001: el control A.14.2 exige revisión de código y gestión de vulnerabilidades. GDPR: si el código procesa datos personales, debes demostrar medidas técnicas adecuadas. «Lo generó la IA» no es justificación válida.

«El código generado por IA hereda todas tus obligaciones de compliance — pero no hereda ninguno de tus controles. Eso tienes que construirlo tú.»

Un proceso de auditoría práctico para equipos ágiles

Cuatro pasos: (1) etiquetar cada PR con porcentaje estimado de código asistido por IA, (2) asignar un revisor humano con criterios de aceptación documentados, (3) ejecutar SAST antes del merge, (4) registrar evidencia de revisión en el sistema de tickets. En FAST Delivery, este proceso ocurre dentro de la semana de construcción — no como fase separada. El compliance no frena la velocidad cuando está diseñado desde el inicio — solo la frena cuando se añade después como parche.