Desarrollo de aplicaciones de IA seguras

Módulo 1: Cómo fallan las aplicaciones de IA

No hay laboratorio; se trata de un análisis arquitectónico y debate guiado.

Modelo mental que debe tener el desarrollador sobre la superficie vulnerable del sistema.

Temas a tratar:

• Arquitecturas de modelos LLM, RAG y agentes vistas desde la perspectiva del programador
• Ciclo de vida de solicitudes y respuestas en funcionalidades basadas en IA
• Flujo de prompts: mensajes del sistema, desarrolladores, usuarios y herramientas
• Puntos de entrada (y reentradas) de datos no confiables hacia el modelo
• Límites de confianza que corresponden al control del programador frente a los externos
• Razones por las cuales los ataques en IA son semánticos y no sintácticos
• Conexión entre la lista OWASP LLM Top 10 y el código que escribe el desarrollador

Conclusión clave: Cada instancia en la que texto no confiable llega al modelo —o viceversa— constituye un límite de seguridad del cual depende directamente el programador.

Módulo 2: Inyección de prompts desde el punto de vista del desarrollador

Laboratorio: Lab 01 – 01-Prompt-Injection

Este es el equivalente a la inyección SQL en el ámbito de la IA; sin embargo, no existe una forma absoluta de evitarla.

Temas tratados:

• Tipos de inyección de prompts: directa e indirecta
• Instrucciones ocultas en documentos, páginas web o respuestas generadas por herramientas
• Técnicas de ‘jailbreak’ y confusión de roles del modelo
• Importancia de separar las instrucciones del modelo respecto a los datos externos
• Diseño defensivo de prompts: uso de delimitadores, estructura clara y reducción de permisos otorgados al modelo
• Por qué la prevención es parcial: enfoque de mitigación mediante aislamiento de funcionalidades

Ejercicios prácticos:

• Atacar su propio chatbot con intentos de inyección
• Burlar un filtro básico implementado en el sistema
• Rediseñar el prompt para minimizar la posibilidad de que se produzcan abusos

Módulo 3: Tratamiento de las respuestas del modelo como datos no confiables

Laboratorio: Lab 02 – 02-Output-Handling

Este es el tipo de vulnerabilidad que los desarrolladores subestiman con mayor frecuencia.

Temas tratados:

• Interpretación del resultado generado por el modelo como entrada no confiable para otras partes de la aplicación
• Manejo inseguro de salidas (LLM02): riesgos de XSS, SSRF y posibles ataques de tipo inyección SQL o ejecución de comandos
• Prohibición absoluta de usar funciones como eval(), exec() o renderizar directamente el texto generado por el modelo
• Generación estructurada de salidas y validación mediante esquemas definidos
• Codificación adecuada y uso de listas blancas para filtrar información segura
• Muestreo y representación segura del contenido en interfaces web o aplicaciones de interfaz gráfica

Ejercicios prácticos:

• Identificar y corregir un caso evidente de manejo inseguro de resultados del modelo
• Aplicar restricciones basadas en esquemas JSON para garantizar la coherencia en respuestas generadas

Módulo 4: Seguridad en pipelines RAG

Laboratorio: Lab 03 – 03-RAG-Security

Una de las superficies de ataque más críticas y nuevas; su diseño depende íntegramente del desarrollador.

Temas tratados:

• Amenazas asociadas a bases de datos vectoriales y al proceso de recuperación de información
• Sanitización previa de contenidos durante la ingestión inicial
• Determinación del origen documental y evaluación de niveles de confianza en los datos
• Limitaciones de ámbito de búsqueda y segregación basada en metadatos durante la recuperación
• Presencia potencial de instrucciones ocultas dentro del contenido devuelto (inyección indirecta)
• Riesgos vinculados a la fuga de información sensible mediante mecanismos de búsqueda automatizada

Ejercicios prácticos: contaminar deliberadamente un pipeline RAG con documentos malintencionados; posteriormente, implementar mecanismos de filtrado e inclusión limitada para mitigar los riesgos.

Módulo 5: Seguridad de agentes y herramientas asociadas

Laboratorio: Lab 04 – 04-Agent-Safety

En este nivel, un error básico puede traducirse en acciones autónomas peligrosas.

Temas tratados:

• Riesgos de excesivo poder ejecutivo otorgado al agente (LLM06) y abuso potencial de sus herramientas disponibles
• Implementación estricta del principio de mínimo privilegio en el contexto operativo del agente
• Utilización obligatoria de listas blancas y validación exhaustiva sobre cada argumento proporcionado a las herramientas
• Incorporación de controles humanos (approval gates) o supervisión intermitente en funcionalidades críticas
• Entorno controlado y sandboxing aplicado al entorno operativo asociado a las herramientas del agente
• Asignación de credenciales temporales, limitados en su vida útil y alcance permitido para el agente determinado
• Prevención de bucles infinitos o encadenamientos repetitivos no planificados entre tareas del agente<\/li>

Ejercicios prácticos:

• Limitar los permisos disponibles de un agente que, inicialmente, poseía accesos no restringidos
• Incorporar una lista blanca además de controles intermedios para autorizar o denegar solicitudes a ciertas herramientas críticas

Módulo 6: Claves API, gestión de identidad y control de costos

Laboratorio: Lab 05 – 05-Secrets-and-Cost

Fallas operativas muy comunes que generan efectos negativos en pocos minutos.

Temas tratados:

• Gestión adecuada de credenciales API y demás secretos sensibles (nunca deben colocarse dentro de prompts, el código fuente ni los registros informativos)
• Implementación obligatoria de mecanismos sólidos de autenticación y control de autorizaciones para funcionalidades basadas en IA
• Paso transparente del contexto identificativo propio del usuario hasta el nivel de acceso a herramientas o bases de datos usadas por los modelos LLM
• Control estricto contra gastos no deseados asociados al uso ilimitado de tokens o recursos computacionales
• Establecimiento adecuado de topes de frecuencia, límites temporales y máximas cuantificables por unidad de tiempo para cada consumo solicitado
• Mantenimiento seguro y filtrado de registros informáticos asegurando no mostrar secretos ni información sensible relacionada con identidades personales del usuario

Ejercicios prácticos:

• Eliminar por completo referencias a claves API dentro de códigos o prompts, asignando estas credenciales al entorno correcto de ejecución
• Establecer límites estrictos per user en el consumo de tokens y gasto financiero permitido durante la fase de operación del sistema

Módulo 7: Bibliotecas de protección (Guardrails)

Laboratorio: Lab 06 – 06-Guardrails

Decidir entre adquirir bibliotecas existentes o crear controles propios en el flujo operativo.

Temas tratados:

• Funciones y limitaciones principales de estas herramientas destinadas a protección anticipada de entradas/salidas
• Implementación de controles preventivos en el flujo inicial del sistema para detectar contenidos abusivos, información personal no deseada o instrucciones malintencionadas relacionadas con la entrada de datos
• Mecanismos posteriormente aplicados a las salidas generadas por los modelos: validación sintáctica y textual mediante reglas lógicas predefinidas, asimismo como filtros o verificaciones semánticas que eviten errores conceptuales no detectados previamente
• Determinación oportuna respecto a si corresponde incorporar estos controles o bien crear reglas propias dependiendo de la situación planteada
• Integración secuencial de diferentes sistemas de verificación combinándolos con métodos expuestos en módulos anteriores para mayor robustez operativa
• Evaluación objetiva respecto a impacto percibido sobre velocidad del procesamiento, número de falsos positivos generados y probabilidad real de errores de filtrado no previstos por los algoritmos expuestos

Ejercicios prácticos:

• Incorporar una capa de verificación en la entrada y salida para cualquier funcionalidad IA desarrollada en particular
• Medición efectiva acerca de errores detectados, riesgos permitidos e incidentes potencialmente inaceptables que no han sido mitigados por tales sistemas

Módulo 8: Prácticas de Red Teaming sobre la aplicación propia

Laboratorio: Lab 07 – 07-Red-Teaming

Preparar el sistema para operar con la seguridad más rigurosa posible, asumiendo que ya existen intentos de ataque en su contra.

Temas tratados:

• Diseño y creación propios de suites de pruebas destinadas específicamente a identificar formas abusivas o dañinas posibles del modelo IA en cuestión
• Programación automatizada enfocada en buscar patrones comunes asociados a inyecciones y rupturas de reglas de comportamiento definidas para el modelo LLM utilizado
• Pruebas retroactivas (regresión) periódicas con herramientas propias enfocadas en mantener la integridad continua frente a actualizaciones y modificaciones del código previamente probado
• Ejecución constante de verificaciones analíticas técnicas asociadas a IA mediante canales automatizados dentro del flujo de desarrollo continuo (CI)
• Inspección rigurosa respecto al origen exacto tanto de componentes programáticos internos como de todas sus dependencias, manteniendo versionado estricto y trazabilidad completa del software descargado
• Evaluación técnica final pre-lanzamiento compuesta por una lista específica enfocada exclusivamente en la seguridad de todo aquello asociado a aplicaciones de inteligencia artificial.

Ejercicios prácticos:

• Formulación y puesta en funcionamiento automatizada de conjuntos de verificaciones dedicados a detectar vulnerabilidades IA generadas por el propio entorno desarrollado
• Integración efectiva dentro del ciclo programático de integración continua para su activación periódica garantizando control preventivo.

Módulo 9: Evaluación técnica de la seguridad en IA mediante el modelo SAIS-100

No hay laboratorio asociado; se trata de un ejercicio evaluativo usando el programa maestro creado específicamente para este propósito.

Objetivo: transformar los conceptos trabajados previamente en una métrica mensurable objetiva que permita clasificaciones periódicas posteriores.

Temas tratados:

• El modelo conceptual hexagonal dedicado exclusivamente a la evaluación segura de IA compuesto por seis criterios técnicos relevantes, distinto del simple y genérico '¿es seguro el sistema?'/li>
• Seis categorías principales a valorar: Datos, Prompts, Agentes Operativos, Cadena de Suministro, Mecanismos Detectivos y Procedimientos de Gobernanza Técnica.
• Estructura total basada en un total máximo puntuable de 100 puntos, junto a ponderaciones estadísticas definidas para cada categoría descrita.
• Identificación clara entre rangos o zonas de seguridad permitida respectivas al valor alcanzado, así como excepciones que permitan saltar rangos completos basados en resultados percibidos en una categoría específica.
• Implementación práctica del modelo conceptual denominado 'Elephant Scale Secure AI Score (SAIS-100)', utilizable como guía estandarizada y repetición posible para múltiples análisis sucesivos.
• Aplicación cuantitativa de esta herramienta antes y después de realizar cambios mejoradores para evaluar exactamente qué tanto influyen en la fortaleza general del entorno tecnológico expuesto.

Ejercicios prácticos:

• Puntuación definitiva de aplicaciones maestras diseñadas según criterios propuestos con base en el escalado completo descrito previamente.
• Identificación y nombramiento del cambio principal que más incrementó la puntuación percibida respecto a condiciones preexistentes.

Observación final: Las tres categorías con mayor impacto en el resultado global coinciden justamente con límites de confianza previamente determinados bajo control exclusivo del programador; por tal motivo, dicha nota refleja íntegramente lo aprendido en todo el programa.

Proyecto Final

Los estudiantes deberán reforzar desde cero una aplicación IA deliberadamente vulnerable expuesta al inicio del módulo final indicado.

Dicho modelo de prueba contiene:

• Un prompt sin ningún tipo de restricción impuesta que permita intentos abusivos directamente sobre su lógica operativa
• Manejo inseguro y negligente respecto a las respuestas devueltas por el modelo asimilado.
• Pipeline RAG funcional pero sin limitaciones ni restricciones de alcance permitido en consulta documental activada.
• Agente integrado cuya autorización disponible resulta extremadamente amplia respecto a posibilidades operativas disponibles para el modelo asimilado.
• Inclusión deliberada de secretos valiosos inseridos dentro de flujos de prompts o incluso directamente insertados en archivos de código fuente.
• Ausencia casi total de límites de consumo establecidos para el uso general y gestión monetaria posible por parte del usuario final.

Tareas específicas que deberán implementar los alumnos tras revisión previa:

• Reestructuración integral sobre prompts implementados para garantizar límites claros y contención eficaz en uso futuro posible.
• Aplicación rigurosa de normas técnicas referentes a validación así como codificado adecuado respecto a cualquier respuesta generada por el modelo usado.
• Establecimiento de límites estrictos y escopos de búsqueda debidamente limitados para evitar desviaciones no esperadas dentro de flujos documentales recuperados por el sistema.
• Incorporación efectiva tanto del mínimo privilegio como controles intermedios enfocados en autorización segura aplicada sobre cualquier agente funcional asimilado al sistema.
• Eliminación plena de referencias a claves secretas introducidas arbitrariamente antes, junto con incorporación efectiva de topes de costo definidos estricta y racionalmente en cada uso posible derivado del entorno programático.
• Incorporación oportuna de conjuntos de controles propios destinados a protección preventiva y también automatizada enfocada en pruebas previas tipo red teaming.

Resultado final deseado: un entorno de funcionamiento robustecido según principios aprendidos y, paralelamente, una breve auto-evaluación comparativa entre funcionalidades desarrolladas frente a la lista oficial descrita previamente bajo el parámetro OWASP LLM Top 10.

Relación módulos/laboratorios prácticos

Cada laboratorio se ejecuta consecutivamente siguiendo la secuencia lógica indicada en su módulo correspondiente. El total es de 9 bloques teóricos pero solo 7 actividades de tipo práctico: el Módulo 1 implica únicamente explicaciones y debates arquitectónicos, y el 9 trata exclusivamente sobre ejercicios evaluativos basados en el programa maestro.

• Laboratorio 01: 01-Prompt-Injection. Ataque dirigido al chatbot creado por los alumnos y diseño posterior encaminado a contención de posibles inyecciones (Módulo 2).
• Laboratorio 02: 02-Output-Handling. Detección y solución eficaz respecto a casos detectados de manejo incorrecto referente a contenidos generados por el modelo (Módulo 3).
• Laboratorio 03: 03-RAG-Security. Introducción intencionada de información manipulada con intención dañina y protección oportuna respecto al flujo RAG existente (Módulo 4).
• Laboratorio 04: 04-Agent-Safety. Limitación efectiva sobre privilegios conferidos previamente a agentes operativos desarrollados sin restricciones asociadas (Módulo 5).
• Laboratorio 05: 05-Secrets-and-Cost. Remoción urgente de referencias relacionadas con claves API contenidas dentro del flujo general y adopción oportuna respecto a límites estrictos del consumo monetario (Módulo 6).
• Laboratorio 06: 06-Guardrails. Incorporación práctica de capas destinadas a protección segura sobre flujos iniciales y finales asimilados (Módulo 7).
• Laboratorio 07: 07-Red-Teaming. Elaboración propiamente dicha de paquetes automatizados destinados al análisis continuado y periódico mediante flujos CI sobre el entorno IA (Módulo 8).

El Módulo 1 no contempla ningún tipo específico de laboratorio, dado que es meramente orientativo respecto a arquitectura; asimismo el módulo noveno mencionado también carece de actividades prácticas propias, ya que solo abarca evaluación puntuativa basada en el programa maestro expuesto antes.