Resumen ejecutivo
El software tradicional es determinista: misma entrada, misma salida. La IA generativa no: misma entrada, salida probabilística. Y toda nuestra ingeniería de seguridad —validaciones, perímetros, pruebas— fue diseñada para el primer mundo. La propuesta de Rudy Pinochet es no pelear contra esa naturaleza sino contenerla: envolver el sistema no determinista con controles deterministas rigurosos. A eso le llama Guardrails Engineering, y lo construye reutilizando metodologías que la industria ya conoce —DDD, FDD, SDD, BDD y TDD— aplicadas al ciclo de vida de la IA. El resultado es una matriz concreta que mapea cada control contra los riesgos del OWASP Top 10 para LLM, y se alinea con ISO/IEC 42001 y NIST AI RMF sin inventar nada nuevo. Su tesis de cierre: la IA no sustituye la arquitectura de software — la hace más crítica.
1. El dilema: dos paradigmas incompatibles
La charla parte por nombrar con precisión el problema de fondo, que suele quedar implícito:
| Software tradicional (determinista) | IA generativa (probabilística) |
|---|---|
| Entrada A → Salida B: resultados predecibles y constantes. | Entrada A → salida probabilística: variabilidad inherente. |
| Control total: lógica basada en reglas explícitas y flujos rígidos. | Nuevas amenazas: fuga de datos, inyección de prompts, jailbreaks y deriva del modelo. |
| Seguridad perimetral: accesos y validaciones de entrada conocidas. | El riesgo está en la ausencia de una capa de control envolvente. |
La conclusión práctica es sutil pero decisiva: no se puede hacer determinista al modelo, pero sí se puede hacer determinista todo lo que lo rodea. Ahí es donde entra la propuesta.
2. Guardrails Engineering mediante XDD
La idea es reutilizar metodologías de desarrollo probadas —el conjunto que Pinochet agrupa bajo la sigla XDD— y ponerlas al servicio de blindar sistemas de IA en entornos corporativos. Cada una aporta una capa distinta:
- DDD · Diseño guiado por el dominio — delimita estrictamente el contexto de operación y aísla los datos sensibles.
- FDD · Desarrollo guiado por funcionalidades — despliegue modular y controlado, con banderas de funcionalidad que permiten desactivación inmediata.
- SDD · Guiado por especificación — contratos de datos rígidos entre el modelo y el resto del sistema.
- BDD y TDD · Guiados por comportamiento y por pruebas — escenarios de seguridad y evaluaciones automatizadas.
3. Aislamiento: contextos delimitados y radio de impacto
El aporte de DDD es el más elegante de la propuesta. Los bounded contexts —contextos delimitados— restringen el alcance de la IA: el modelo solo accede al dominio de información que se le asignó. Con eso, la escalación de privilegios deja de depender de un filtro y pasa a ser imposible por límite arquitectónico. No es que el modelo «no deba» consultar otra base: es que no puede.
Y FDD aporta el control operativo: capacidades de IA desplegadas de forma independiente, con feature flags que permiten activar o desactivar funciones en tiempo real. El objetivo explícito es reducir el radio de impacto ante anomalías — si algo se comporta de forma inesperada, se apaga esa función sin tumbar el sistema completo.
4. Blindaje en el ciclo de vida: SDD, BDD y TDD
La segunda mitad del marco ataca la calidad y la seguridad durante el desarrollo:
SDD impone contratos OpenAPI y esquemas JSON rígidos para eliminar el texto libre hacia el backend. Es una decisión de arquitectura con enorme retorno: si el modelo solo puede devolver estructuras validadas, buena parte de los ataques de manejo inseguro de salidas se cae por su propio peso.
BDD aporta escenarios de comportamiento —dado / cuando / entonces— escritos con orientación a ciberseguridad y mitigación de jailbreaks. Es decir: las pruebas de seguridad se expresan como comportamientos esperados, en un lenguaje que negocio y seguridad pueden leer igual.
TDD lleva las evaluaciones automatizadas al pipeline de integración continua para medir alucinaciones antes de producción. La consecuencia organizacional es la misma que en cualquier práctica madura de software: si no pasa las pruebas, no llega a producción.
5. La matriz: cada control contra su riesgo
Aquí está el entregable más accionable de la charla — el mapeo directo entre metodología y riesgo del OWASP Top 10 para aplicaciones con modelos de lenguaje:
| Riesgo OWASP LLM | Mitigación XDD |
|---|---|
| LLM01 · Inyección de prompts | BDD y TDD — evaluaciones de jailbreak automatizadas |
| LLM02 · Manejo inseguro de salidas | SDD — esquemas JSON rígidos |
| LLM06 · Agencia excesiva | DDD — contextos delimitados |
| LLM09 · Exceso de confianza | TDD y evaluaciones — medición de confiabilidad |
Y el marco encaja con la gobernanza sin fricción: ISO/IEC 42001 exige auditoría y trazabilidad, que se satisfacen con SDD y BDD; NIST AI RMF pide mapear y medir el riesgo, funciones que cubren DDD y las evaluaciones de TDD; y OWASP aporta la identificación técnica de vulnerabilidades. La síntesis de Pinochet: la arquitectura técnica actúa como el brazo ejecutor de las políticas de gobernanza corporativa — sin esa ejecución, la política es una declaración.
6. El caso práctico: un asistente de consultas financieras
El ejemplo compara dos versiones del mismo sistema y no deja lugar a dudas:
- El prompt del usuario llega directo al modelo, sin validación.
- El modelo tiene permisos totales sobre la base de datos financiera.
- Riesgo crítico de inyección indirecta y fuga de datos sensibles — sueldos, por ejemplo.
- Validación de entradas y salidas mediante controles BDD y SDD.
- Recuperación de documentos operando estrictamente dentro de un contexto delimitado.
- Validador de estructura y contratos rígidos en la salida, que además contienen las alucinaciones.
7. Cómo llevarlo a un proyecto real
La charla ordena el trabajo en cinco fases que calzan con cualquier ciclo de desarrollo existente: planificación (DDD, definir los contextos), especificación (SDD, fijar los contratos), desarrollo (TDD, las evaluaciones), construcción (FDD, despliegue modular con banderas) y auditoría (herramientas de análisis de código integradas al pipeline). Como resume el autor: «la integración de estas metodologías garantiza que la seguridad sea un componente intrínseco desde el diseño hasta el despliegue».
Y para empezar mañana, un plan de acción de cuatro pasos: auditar —identificar proyectos de IA que hoy operan sin contextos delimitados y evaluar su riesgo—; implementar —integrar el primer pipeline de pruebas BDD/TDD en el flujo de integración continua—; alinear —adoptar NIST AI RMF como lenguaje común entre seguridad y negocio—; y escalar —expandir los guardarraíles al resto de la organización de forma sostenible—.
8. Conclusiones
Tres ideas para llevarse. Primero, lo no determinista se contiene con lo determinista: no hay que domesticar el modelo, hay que rodearlo de contratos, límites y pruebas. Segundo, no hace falta inventar metodologías nuevas — DDD, SDD, BDD, TDD y FDD llevan décadas probadas, y aplicarlas a la IA es reciclaje inteligente, no innovación forzada. Tercero, la gobernanza necesita un brazo ejecutor: los marcos internacionales dicen qué hay que lograr, y esta arquitectura dice cómo.
Las dos frases con las que Pinochet cierra su charla resumen la postura completa: «la IA no sustituye la arquitectura de software; la hace más crítica» y «los guardarraíles no frenan la innovación, la hacen sostenible». Para equipos latinoamericanos que quieren llevar IA a producción en sectores regulados, esa es exactamente la conversación que hay que tener con el área de riesgo — y con esta matriz, se puede tener con evidencia.
Referencias
- Pinochet Maturana, R. (2026). Cómo abordar la IA a nivel empresarial y reducir amenazas durante su implementación: caso práctico [presentación]. I Congreso IA-LATAM. PDF de la charla.
- Pinochet Maturana, R. (2026). ¿Cómo implementar IA en una empresa sin exponer información sensible ni introducir nuevos riesgos? [video]. Canal de Comunidad IA LATAM en YouTube. youtube.com/watch?v=470ONMQEFYk.
- Marcos citados: ISO/IEC 42001 (sistema de gestión de IA) · NIST AI Risk Management Framework 1.0 · OWASP Top 10 para aplicaciones con LLM.
- Metodologías de desarrollo aplicadas: Domain-Driven Design · Feature-Driven Development · Specification-Driven Development · Behavior-Driven Development · Test-Driven Development.
Sobre el autor
Rudy Pinochet Maturana es presidente del Capítulo Santiago de ISACA y especialista en inteligencia artificial y ciberseguridad. Trabaja en la intersección entre arquitectura de software, gobernanza de IA y gestión de riesgo, con foco en llevar sistemas de inteligencia artificial a producción en entornos corporativos regulados. LinkedIn
Artículo elaborado por la Comunidad IA LATAM a partir de la presentación oficial y la transcripción del video de la charla. El caso práctico del asistente financiero es un ejemplo didáctico construido por el autor.