ASILO se ocupa de qué puede hacer un sistema construido con asistencia de IA, quién puede
detenerlo y cómo se comprueba que respetó sus límites. Los requisitos siguientes son agnósticos:
no dependen de lenguaje, framework ni proveedor. Contratos TypeScript, validadores concretos y
numeraciones de anillos pertenecen a perfiles.
Lo que estos requisitos no prometen. Cumplirlos no hace a un sistema seguro, privado, libre de
alucinaciones ni conforme con OWASP, NIST, MITRE o ISO. Cada requisito nombra su riesgo residual.
Las referencias externas se usan para contrastar el diseño; ver marcos externos.
La salida de un modelo (texto, llamada a herramienta, código) se ejecuta o se guarda como si fuera una orden válida. Una inyección directa o indirecta la convierte en una acción del atacante.
Alcance
Todo punto donde contenido generado por un modelo, o datos externos que lee un modelo, pueden producir un efecto: escritura, llamada a herramienta, envío, ejecución de código, cambio de permisos.
Actor responsable
Owner técnico del sistema que integra el modelo.
Condición de aplicación
Siempre que exista al menos un punto de efecto alimentado por un modelo.
Formulación verificable
El sistema DEBE documentar sus fronteras de confianza y, para cada punto de efecto, el contrato que acepta (forma, valores permitidos, versión). La salida del modelo DEBE tratarse como dato no confiable: antes del efecto DEBE validarse contra el contrato y autorizarse contra los permisos de la persona o servicio que originó la petición. La validación de forma NO DEBE presentarse como autorización ni como verificación de veracidad. El modelo NO DEBERÍA recibir la lista de operaciones privilegiadas que no necesita.
Evidencia esperada
Diagrama o tabla de fronteras; contratos versionados; pruebas que muestren rechazo de salida mal formada y de salida bien formada pero no autorizada.
Excepción
Sistemas sin puntos de efecto (sólo muestran texto a una persona) registran esa condición; si cambia, el requisito aplica.
Riesgo residual
Una inyección puede producir una intención válida y autorizada que el atacante desea; ni el contrato ni la autorización detectan intención maliciosa dentro de lo permitido.
ASILO-R-002 — Modelo de capas declarado y dirección de dependencias¶
Campo
Contenido
Clase
Requisito agnóstico (la numeración y los nombres de anillos son de perfil) · deriva de ASILO-P-01
Estado
accepted — ASILO 0.1 (28-sep-2026)
Problema
Código de alto riesgo (secretos, efectos externos, dependencias de terceros) se mezcla con lógica que debería ser pura; nadie puede decir qué capa confía en cuál.
Alcance
Arquitectura de software de sistemas que aplican ASILO.
Actor responsable
Arquitecto o owner técnico.
Condición de aplicación
Sistemas con más de un módulo o paquete que declaran aplicar ASILO.
Formulación verificable
El sistema DEBE declarar su modelo de capas o anillos (nombre, contenido de cada capa y perfil de origen) y la regla de dependencia entre ellas. La regla de dependencia DEBERÍA comprobarse de forma automática en integración continua cuando el perfil lo permita. El método NO DEBE exigir una numeración ni un número de capas concretos.
Evidencia esperada
Documento del modelo; configuración y resultado de la comprobación automática; excepciones registradas.
Excepción
Sistemas de un solo módulo registran la condición.
Riesgo residual
Respetar la dirección de dependencias no impide fallos dentro de una capa; el compilador o el linter sólo prueban lo que comprueban.
Referencias externas
OWASP LLM03:2025 Supply Chain; OWASP ASI04 Agentic Supply Chain Vulnerabilities; NIST AI 600-1 Value Chain and Component Integration.
Requisito agnóstico (la interfaz concreta es de perfil) · deriva de ASILO-P-03
Estado
accepted — ASILO 0.1 (28-sep-2026)
Problema
Un agente recibe «todo el repo» o todo el historial: aumenta costo, confunde relaciones, expone datos que no necesitaba y amplía la superficie para instrucciones inyectadas o memoria envenenada.
Alcance
Cada tarea en la que un agente o modelo recibe contexto del sistema o de sus usuarios.
Actor responsable
Owner del sistema de agentes.
Condición de aplicación
Tareas con acceso a fuentes internas, datos personales o memoria persistente.
Formulación verificable
Cada tarea DEBE tener un presupuesto de contexto declarado con: fuentes permitidas, rutas excluidas, clasificación máxima de datos admitida, límite de tamaño y caducidad. Un presupuesto NO DEBE reutilizarse entre tareas distintas. Datos de las dos clasificaciones más altas de la escala de exposición (confidencial y crítico) NO DEBEN entrar a un modelo externo sin aprobación humana registrada o anonimización verificada. El contenido recuperado de fuentes externas DEBE tratarse como no confiable (ASILO-R-001).
Evidencia esperada
Presupuestos por tarea; registro de lo que efectivamente entró al contexto; aprobaciones.
Excepción
Tareas sin datos internos ni memoria (por ejemplo, redacción sobre texto aportado por la persona).
Riesgo residual
Un contexto mínimo puede seguir conteniendo instrucciones maliciosas o datos erróneos; anonimizar no garantiza que no haya reidentificación.
Referencias externas
OWASP LLM02:2025 Sensitive Information Disclosure, LLM07:2025 System Prompt Leakage, LLM08:2025 Vector and Embedding Weaknesses; OWASP ASI06 Memory & Context Poisoning; MITRE ATLAS AML.T0080 AI Agent Context Poisoning.
ASILO-R-004 — Permisos mínimos y revocables para agentes¶
Un agente hereda todos los permisos de quien lo lanza, o más; si se compromete o se desvía, su radio de daño es el de la cuenta completa.
Alcance
Agentes, subagentes y herramientas que ejecutan acciones.
Actor responsable
Owner del sistema de agentes.
Condición de aplicación
Cualquier agente con acceso a herramientas o datos.
Formulación verificable
Cada agente DEBE tener identidad propia y un alcance declarado antes de operar: operaciones permitidas, datos accesibles, límite de acciones y profundidad de delegación. El alcance NO DEBE ser más amplio que el de quien lo invoca. El alcance NO DEBE ampliarse en ejecución; cambiarlo DEBERÍA implicar una identidad nueva. El sistema DEBE poder revocar un agente y DEBERÍA comprobar la revocación antes de cada acción.
Evidencia esperada
Declaraciones de alcance versionadas; registro de concesiones; prueba de rechazo fuera de alcance; prueba de revocación.
Excepción
Ninguna para agentes con efectos externos.
Riesgo residual
Dentro de su alcance legítimo, un agente puede seguir causando daño; el alcance mínimo lo acota, no lo elimina.
Un efecto difícil de revertir (pago, borrado, cambio de permisos, publicación, decisión sobre una persona) ocurre sin que nadie lo vea; o, en el extremo contrario, se pide aprobación para todo y la persona aprueba sin leer.
Alcance
Efectos que el owner clasifique como críticos y decisiones en zona de ambigüedad.
Actor responsable
Owner del sistema (define el catálogo); persona aprobadora (decide).
Condición de aplicación
Cuando una acción pertenece al catálogo de efectos críticos o el sistema no puede decidir con sus reglas.
Formulación verificable
El sistema DEBE mantener un catálogo explícito de efectos críticos, que DEBE considerar al menos pagos o transferencias, borrado de datos, cambios de permisos, publicación o envío a terceros y decisiones que afecten a personas. Antes de ejecutar uno, DEBE obtener confirmación de una persona autorizada que vea lo que se aplicará (diff, destinatario, monto u objeto afectado). La confirmación DEBE registrarse con identidad, fecha y objeto aprobado, y NO DEBE poder reutilizarse para otra acción. Cuando las reglas no decidan, el caso DEBERÍA ir a revisión humana en vez de resolverse con un valor por defecto. El requisito NO DEBE presentarse como revisión humana de todas las acciones.
Evidencia esperada
Catálogo versionado; registros de aprobación; prueba de que la acción no se ejecuta sin aprobación; métrica de volumen de aprobaciones por persona.
Excepción
Una emergencia puede autorizar un efecto crítico sin revisión previa sólo si el owner lo definió de antemano y la revisión ocurre después, registrada.
Riesgo residual
La persona puede aprobar por cansancio, confianza excesiva o engaño; un agente puede presentar la acción de forma persuasiva. La revisión humana no garantiza una buena decisión.
Referencias externas
OWASP ASI09 Human-Agent Trust Exploitation; OWASP LLM06:2025 Excessive Agency; NIST AI 600-1 Human-AI Configuration (sesgo de automatización, dependencia excesiva).
Requisito agnóstico (las leyes aplicables son de perfil jurisdiccional) · deriva de ASILO-P-03
Estado
accepted — ASILO 0.1 (28-sep-2026)
Problema
Secretos o datos personales entran al prompt, a la memoria o a los registros; un modelo los revela o un tercero los recibe sin base.
Alcance
Datos personales, datos de menores, credenciales y datos confidenciales que el sistema trate.
Actor responsable
Owner del sistema; responsable de datos.
Condición de aplicación
Siempre que el sistema trate alguno de esos datos.
Formulación verificable
Cada conjunto de datos DEBE tener clasificación, propósito, base o consentimiento aplicable, retención, mecanismo de revocación y borrado, y owner. Credenciales y claves NO DEBEN entrar al contexto de un modelo; si hace falta actuar en nombre de alguien, se DEBERÍA usar una credencial de un solo uso y alcance mínimo. Los datos de menores DEBERÍAN tratarse como sensibles. Detectar y bloquear datos NO DEBE presentarse como anonimización.
Evidencia esperada
Inventario de datos; pruebas de que los secretos no llegan al modelo; política de retención; registro de accesos a la clasificación más alta.
Excepción
Ninguna para credenciales. Para datos personales, la que establezca la base legal aplicable, registrada.
Riesgo residual
Clasificación incompleta, inferencia de datos sensibles a partir de datos no sensibles y reidentificación. Este requisito no sustituye la revisión legal.
Referencias externas
OWASP LLM02:2025 Sensitive Information Disclosure; OWASP ASI03; NIST AI 600-1 Data Privacy.
Un agente en bucle o manipulado consume tokens, dinero o acciones sin límite; al detenerlo se pierde el estado o la evidencia de lo que hizo.
Alcance
Ejecuciones de agentes y llamadas a modelos con costo o efecto.
Actor responsable
Owner del sistema de agentes.
Condición de aplicación
Toda ejecución automatizada con costo o efectos.
Formulación verificable
Cada ejecución DEBE tener límites declarados de costo o tokens, número de acciones y tiempo. Al agotarse un límite, la ejecución DEBE detenerse o pasar a revisión humana, nunca continuar en silencio. El sistema DEBE tener un mecanismo de parada con responsable definido y probado en el entorno donde se afirma que funciona. Al detenerse, DEBE conservar el registro de lo ejecutado y DEBERÍA permitir reanudar sin repetir efectos ya aplicados.
Evidencia esperada
Límites por ejecución; registro de consumo; prueba de parada en el entorno declarado; prueba de reanudación.
Excepción
Ejecuciones puramente locales sin costo ni efectos externos.
Riesgo residual
Los límites no evitan el daño hecho antes de alcanzarlos; una parada probada en simulación no demuestra la parada en producción.
Se afirma que un sistema «no alucina», «resiste inyecciones» o «evita la complacencia» porque usa roles, un revisor o un filtro, sin haberlo medido; los errores que escapan no se registran.
Alcance
Sistemas que usan modelos para producir contenido, decisiones o acciones que otros usarán.
Actor responsable
Owner del sistema; responsable de aseguramiento.
Condición de aplicación
Antes de afirmar públicamente o ante un cliente que el sistema es apto para su propósito, y en cada cambio de modelo o configuración relevante.
Formulación verificable
El sistema DEBE tener un plan de evaluación que cubra, cuando apliquen: (a) confabulación o alucinación; (b) inyección de instrucciones directa e indirecta; (c) complacencia (sycophancy) ante presión de la persona o de otros agentes; (d) fallos entre agentes, si hay más de uno. Cada evaluación DEBE registrar modelo y versión, configuración, conjunto de casos, método, resultado y riesgo residual. Un documento del sistema NO DEBE afirmar que un riesgo de esta lista está eliminado o garantizado por un control, rol o arquitectura. Los errores que escapen a los controles DEBERÍAN registrarse en una bitácora y alimentar la evaluación siguiente. La edición 0.1 no fija umbrales numéricos.
Evidencia esperada
Plan de evaluación; resultados fechados y reproducibles; bitácora de incidentes; declaración de riesgo residual.
Excepción
Prototipos internos sin usuarios externos, marcados como tales; no pueden sostener afirmaciones públicas.
Riesgo residual
Una evaluación cubre los casos probados, no todos los posibles; los resultados cambian con el modelo. La complacencia, la confabulación y la inyección siguen siendo posibles tras cualquier control conocido.
Referencias externas
NIST AI 600-1 Confabulation, Information Integrity, Human-AI Configuration; OWASP LLM01:2025, LLM09:2025 Misinformation; OWASP ASI07 Insecure Inter-Agent Communication, ASI08; MITRE ATLAS AML.T0051, AML.T0062 Discover LLM Hallucinations. Investigación: Sharma et al. 2023 (arXiv:2310.13548); Kalai et al. 2025 (arXiv:2509.04664); Cemri et al. 2025 (arXiv:2503.13657); preprints sobre complacencia en debate multiagente arXiv:2509.23055 y arXiv:2605.12991.