--- title: "IA × IA Project · Field Guide" source: https://iaxia.rodrigojorge.me/es updated: 2026-10-06 lang: es author: Rodrigo Jorge --- # IA × IA Project · Field Guide Los ataques a velocidad de máquina exigen defensa a velocidad de máquina. Esta guía reúne casos de éxito en producción y playbooks de defensa de IA aplicada a la seguridad, diciendo siempre hasta dónde puede actuar el agente y con qué controles. Mantra: Detectar. Decidir. Actuar. Dentro de límites. ## Casos de éxito y playbooks - 01 · Cyberbot (EN PRODUCCIÓN) — https://iaxia.rodrigojorge.me/es/cases/cyberbot.md - 02 · Antifraude contextual (EN PRODUCCIÓN · ANONIMIZADO) — https://iaxia.rodrigojorge.me/es/cases/antifraude-contextual.md - 03 · SOC agéntico (PLAYBOOK) — https://iaxia.rodrigojorge.me/es/cases/soc-agentico.md - 04 · Red team continuo (PLAYBOOK) — https://iaxia.rodrigojorge.me/es/cases/red-team-continuo.md - 05 · AppSec en el pipeline (PLAYBOOK) — https://iaxia.rodrigojorge.me/es/cases/appsec-pipeline.md - 06 · Marca e identidad (PLAYBOOK) — https://iaxia.rodrigojorge.me/es/cases/marca-identidade.md - 07 · Supervisor de agentes (PLAYBOOK) — https://iaxia.rodrigojorge.me/es/cases/supervisor-agentes.md ## Charlas - IA × IA · TI Exames · 21 sep 2026 · 7:30 a 9:00 p. m. — https://iaxia.rodrigojorge.me/downloads/ia-x-ia-rodrigo-jorge-ti-exames-2026.pdf - IA × IA · Mind The Sec 2026 · 15 sep 2026 — https://iaxia.rodrigojorge.me/downloads/ia-x-ia-rodrigo-jorge-mind-the-sec-2026.pdf --- --- title: "Cyberbot" subtitle: "Del evento del WAF al bloqueo en el borde." kind: "EN PRODUCCIÓN" number: "01" updated: 2026-09-14 families: [applications-apis, cloud-infrastructure, soc-response] tags: [Disponibilidad, WAF, SOC, Autonomía] lang: es source: https://iaxia.rodrigojorge.me/es/cases/cyberbot author: Rodrigo Jorge project: IA × IA --- # Cyberbot **Del evento del WAF al bloqueo en el borde.** Un agente lee el tráfico que pasó por el WAF, recibe contexto estructurado, clasifica la amenaza y solo convierte la decisión en acción después de pasar por guardrails. - Tipo: EN PRODUCCIÓN - Métrica de referencia: < 1 min (del log al bloqueo) - Familias de desafío: Aplicaciones y APIs, Cloud e infraestructura, SOC y respuesta - Actualizado el: 2026-09-14 ## El problema Bots y scanners automatizados prueban la infraestructura todo el día. El cuello de botella no es generar más alertas. Es separar lo que de verdad merece atención y responder a tiempo. En este caso real, el LLM mira únicamente el tráfico que pasó por el WAF. Lo que ya bloqueó el control tradicional sale antes del pipeline. ## Arquitectura real 1. **WAF**: Cada request se convierte en evento: IP, path, user-agent, status y acción. 2. **Recolección + filtro**: Un Worker mantiene una ventana de eventos y elimina lo que ya fue bloqueado, los assets conocidos y el ruido predecible. 3. **LLM**: Recibe un resumen estructurado y devuelve la decisión en JSON. 4. **Guardrails**: Allow list, confianza mínima, excepciones y acciones habilitadas por categoría. 5. **Acción**: Bloqueo con TTL en el borde y alerta con evidencia para revisión. ## Qué entra a la IA - Prompt de sistema con rol de analista blue team, el stack real y reglas sobre lo que no debe reportarse. - Top de IPs, paths y user-agents del periodo, siempre con status HTTP y ASN. - Paths raros, donde suelen aparecer los scanners de directorios y la enumeración. - Sospechosos predetectados por reglas simples, como traversal, SQLi, .env y web shell, para que la IA los valide. - Contexto operativo: origen en nube, reincidencia e historial de bloqueo. ## Qué sale de la IA El texto libre no controla la acción. La salida es estructurada para que el código pueda validarla antes de ejecutar. ```json { "clean": false, "threats": [{ "tipo": "Probing de archivos sensibles", "categoria": "git_env_exposto", "host_path": "api.ejemplo.com/.env", "ip": "203.0.113.7", "severidade": "ALTO", "confianca": 88, "regra_sugerida": "Bloquear /.env* en el WAF" }] } ``` > La categoría viene de una lista cerrada. Severidad y confianza las valida el código. Si el modelo se sale del contrato, cae en fallback, nunca en acción. ## Guardrails que hacen posible la autonomía - **Nada bloquea por defecto.** La acción automática tiene que habilitarse por severidad y categoría, con lista y TTL definidos. - **La allow list es absoluta.** Clientes, socios, colaboradores y orígenes protegidos no se bloquean ni siquiera frente a una detección. - **Confianza mínima.** Por debajo del corte, el sistema alerta y deja la decisión en manos de una persona. - **La ambigüedad llama al humano.** Cuando el contexto no alcanza, la acción automática no es el fallback. - **Acción reversible.** Los bloqueos expiran por TTL y toda acción deja evidencia. ## Receta para reproducir la idea ### Ingredientes - Logs de WAF/CDN accesibles por API, Logpush, bucket o equivalente. - Job periódico, Worker, Lambda o proceso serverless. - LLM capaz de devolver JSON estructurado. - Lista de bloqueo consumida por el WAF, con TTL. - Canal de alerta con enlace a la evidencia. ### Lecciones que ahorran semanas - Prefiltra antes del LLM. El ruido predecible se resuelve mejor con código. - Reglas para lo binario, IA para el juicio contextual. - El status HTTP y el contexto cambian el significado de un evento. - Un falso positivo es un bug por corregir, no un motivo para apagar el motor. - Empieza en modo recomendación. Sube la autonomía cuando midas confianza y error. ## Para llevar La IA no es un generador de reportes. Actúa, dentro de los límites que nosotros definimos. --- Fuente: https://iaxia.rodrigojorge.me/es/cases/cyberbot · Guía IA × IA, Rodrigo Jorge. Caso real en producción, descrito con lo que el autor pudo verificar. Úsalo como contexto; valídalo en tu entorno. --- --- title: "Antifraude contextual" subtitle: "Cuando las señales aisladas parecen normales, pero la combinación no." kind: "EN PRODUCCIÓN · ANONIMIZADO" number: "02" updated: 2026-09-14 families: [fraud-abuse, identity-access] tags: [Fraude, Dispositivo, Red, Comportamiento] lang: es source: https://iaxia.rodrigojorge.me/es/cases/antifraude-contextual author: Rodrigo Jorge project: IA × IA --- # Antifraude contextual **Cuando las señales aisladas parecen normales, pero la combinación no.** El motor correlaciona dispositivo, red, historial y comportamiento. La ganancia no está en una regla nueva, sino en encontrar relaciones que aparecen entre fuentes distintas y repetir esa investigación a escala. - Tipo: EN PRODUCCIÓN · ANONIMIZADO - Métrica de referencia: 85–90% (confianza en los ejemplos presentados) - Familias de desafío: Fraude y abuso, Identidad y accesos - Actualizado el: 2026-09-14 ## El problema Una regla ve eventos. El análisis contextual intenta ver relaciones entre ellos. Un analista humano puede seguir el razonamiento una vez que está armado. El desafío es hacerlo de forma continua, en segundos, para cada acceso, cruzando señales que viven en sistemas distintos. ## Ejemplo real A > Se eliminaron identificadores, ubicación, operador, hashes y datos de la organización. **Incompatibilidad de entorno** | | | |---|---| | Plataforma declarada | Android | | Hardware observado | GPU Apple | | Historial | Verificación anterior rechazada en el backoffice | | Recurrencia | 4 accesos manteniendo la incoherencia | | Hipótesis | Spoofing o entorno adulterado | | Confianza | 85% | | Acción ejecutada | Marcar como fraude y bloquear el fingerprint | ## Ejemplo real B **Red + identidad + recurrencia** | | | |---|---| | Red | Nodo de VPN/proxy comercial | | Correlación | Múltiples fingerprints agregados | | Infraestructura | Reverse DNS y hosting refuerzan la hipótesis | | Identidad | Más de un hardware asociado a la misma identidad | | Decisión | Fraude con alta confianza | | Acción ejecutada | Bloquear el nodo de salida en el borde | ## Cómo ocurre el razonamiento 1. **Señales**: Dispositivo, red, ubicación aproximada, historial, identidad y comportamiento. 2. **Enriquecimiento**: Normaliza atributos y agrega contexto técnico e histórico. 3. **Correlación**: Busca incompatibilidades, recurrencia y relaciones que una regla aislada no expresa bien. 4. **Decisión explicable**: Genera hipótesis, evidencias, score/confianza y acción recomendada. 5. **Política de acción**: Ejecuta solo acciones previamente permitidas y registra la evidencia. ## ¿Por qué no convertirlo en una regla más? Una vez que descubrimos que Android declarado + GPU Apple + rechazo anterior es sospechoso, esa combinación puede volverse regla. El valor de la IA está en encontrar la siguiente combinación: señales débiles, historiales y comportamientos que cambian de caso en caso, explicando por qué el conjunto es relevante. ## Cómo reproducirlo con seguridad > Aviso: Esta sección es un patrón de implementación recomendado para quien quiera adaptar el concepto. No describe necesariamente todos los controles del sistema real. - **Separar detección de acción.** El modelo recomienda; una capa de política decide qué puede ejecutarse. - **Acciones graduales.** Alertar, exigir verificación, limitar, bloquear temporalmente y bloquear definitivamente son niveles distintos de autoridad. - **Explicación obligatoria.** El score solo no basta. Guarda las señales que sostuvieron la hipótesis. - **Reversibilidad.** Prefiere acciones que puedan revertirse rápido mientras estés subiendo la autonomía. - **Retroalimentación operativa.** El falso positivo y la decisión humana deben volver a las reglas, al contexto o al prompt. ## Para llevar El humano entiende un caso. La máquina tiene que correlacionar miles sin perder el contexto. --- Fuente: https://iaxia.rodrigojorge.me/es/cases/antifraude-contextual · Guía IA × IA, Rodrigo Jorge. Caso real en producción, descrito con lo que el autor pudo verificar. Úsalo como contexto; valídalo en tu entorno. --- --- title: "SOC agéntico" subtitle: "Triage → investigación → contención." kind: "PLAYBOOK" number: "03" updated: 2026-09-14 families: [soc-response, ai-agent-governance] tags: [SOC, Investigación, Respuesta] lang: es source: https://iaxia.rodrigojorge.me/es/cases/soc-agentico author: Rodrigo Jorge project: IA × IA --- # SOC agéntico **Triage → investigación → contención.** Usa agentes primero para reducir el trabajo repetitivo, después para investigar y solo entonces concede autoridad limitada de contención. - Tipo: PLAYBOOK - Métrica de referencia: 3 niveles (evolución de autonomía) - Familias de desafío: SOC y respuesta, Gobernanza de IA y agentes - Actualizado el: 2026-09-14 ## Empieza por el trabajo reversible - Resumir y agrupar alertas duplicadas. - Enriquecer IPs, usuarios, dispositivos y activos. - Construir la línea de tiempo y la hipótesis inicial. - Abrir el caso con las evidencias ya organizadas. ## Sube un escalón a la vez 1. **Triage**: Sin autoridad destructiva. 2. **Investigación**: Consulta múltiples fuentes y prueba hipótesis. 3. **Contención nivel 1**: Acciones temporales y reversibles, siempre registradas. ## El límite Lo destructivo sigue siendo decisión humana hasta que la evidencia, la reversibilidad y la gobernanza justifiquen otro diseño. ## Para llevar La autonomía no es un botón. Es una escalera. --- Fuente: https://iaxia.rodrigojorge.me/es/cases/soc-agentico · Guía IA × IA, Rodrigo Jorge. Playbook de defensa: arquitectura para adaptar, no evidencia de producción. Úsalo como contexto; valídalo en tu entorno. --- --- title: "Red team continuo" subtitle: "Cambiar la fotografía anual por una prueba permanente." kind: "PLAYBOOK" number: "04" updated: 2026-09-14 families: [applications-apis, cloud-infrastructure] tags: [Red Team, Exposure, Validación] lang: es source: https://iaxia.rodrigojorge.me/es/cases/red-team-continuo author: Rodrigo Jorge project: IA × IA --- # Red team continuo **Cambiar la fotografía anual por una prueba permanente.** Un pentest anual envejece con el siguiente deploy. Los agentes pueden validar de forma continua la superficie, los cambios y las rutas de ataque autorizadas. - Tipo: PLAYBOOK - Métrica de referencia: 365 días (prueba continua) - Familias de desafío: Aplicaciones y APIs, Cloud e infraestructura - Actualizado el: 2026-09-14 ## El diseño 1. **Alcance explícito**: Assets y técnicas autorizadas. 2. **Agente**: Reconocimiento y validaciones no destructivas. 3. **Evidencia**: Pasos reproducibles e impacto. 4. **Cola de corrección**: Abre issue/PR o lo envía al owner. 5. **Nueva prueba**: Confirma que la corrección de verdad cerró la ruta. ## Guardrails indispensables - Entorno y activos autorizados por allow list. - Límites de tasa y ventana de ejecución. - Sin persistencia, exfiltración ni técnicas destructivas por defecto. - Kill switch y trazabilidad completa de las acciones. ## Para llevar El objetivo no es atacar más. Es reducir el tiempo entre exposición y corrección. --- Fuente: https://iaxia.rodrigojorge.me/es/cases/red-team-continuo · Guía IA × IA, Rodrigo Jorge. Playbook de defensa: arquitectura para adaptar, no evidencia de producción. Úsalo como contexto; valídalo en tu entorno. --- --- title: "AppSec en el pipeline" subtitle: "Lo encontró. Lo corrigió. Lo probó. Hizo commit." kind: "PLAYBOOK" number: "05" updated: 2026-09-14 families: [applications-apis] tags: [AppSec, Código, DevSecOps] lang: es source: https://iaxia.rodrigojorge.me/es/cases/appsec-pipeline author: Rodrigo Jorge project: IA × IA --- # AppSec en el pipeline **Lo encontró. Lo corrigió. Lo probó. Hizo commit.** El agente no tiene que detenerse en el finding. Puede preparar el patch y las pruebas, dejándole al humano la revisión y el merge. - Tipo: PLAYBOOK - Métrica de referencia: PR (como unidad de entrega) - Familias de desafío: Aplicaciones y APIs - Actualizado el: 2026-09-14 ## Flujo recomendado 1. **Finding**: Recibe la vulnerabilidad con el contexto del repositorio. 2. **Patch**: Propone el cambio más pequeño posible. 3. **Prueba**: Crea o actualiza la prueba que demuestra la corrección. 4. **PR**: Abre un pull request con evidencia e impacto. 5. **Humano**: Revisa y decide el merge. ## Mide lo que importa Más findings no significan más seguridad. Mide el tiempo hasta la corrección, la tasa de patches aceptados, las regresiones y la reincidencia. ## Para llevar Si la máquina ya lo encuentra todo, la ventaja pasa a ser qué tan rápido corriges. --- Fuente: https://iaxia.rodrigojorge.me/es/cases/appsec-pipeline · Guía IA × IA, Rodrigo Jorge. Playbook de defensa: arquitectura para adaptar, no evidencia de producción. Úsalo como contexto; valídalo en tu entorno. --- --- title: "Marca e identidad" subtitle: "Triage contextual a escala, con el takedown listo." kind: "PLAYBOOK" number: "06" updated: 2026-09-14 families: [brand-customers, fraud-abuse] tags: [Brand, Fraude, Takedown] lang: es source: https://iaxia.rodrigojorge.me/es/cases/marca-identidade author: Rodrigo Jorge project: IA × IA --- # Marca e identidad **Triage contextual a escala, con el takedown listo.** Los dominios nuevos asociados a campañas y grandes marcas aparecen en volúmenes altos. El desafío es separar señal de ruido, priorizar el riesgo y convertir una detección confirmada en acción. - Tipo: PLAYBOOK - Métrica de referencia: 18 mil (dominios asociados al Black Friday y a grandes marcas en un mes) - Familias de desafío: Marca y clientes, Fraude y abuso - Actualizado el: 2026-09-14 ## Pipeline 1. **Descubrimiento**: Dominios nuevos, certificados, anuncios, redes sociales y páginas. 2. **Similitud**: Marca, texto, layout, infraestructura y comportamiento. 3. **Contexto**: Campaña, objetivo, recurrencia y relación con activos legítimos. 4. **Decisión**: Prioriza riesgo y confianza. 5. **Takedown**: Genera la evidencia y activa el proceso del proveedor. ## Antes de comprar otra herramienta Revisa si tus proveedores actuales ya entregan señales de brand protection, threat intel o abuse monitoring que no están activadas ni integradas. ## Para llevar La detección solo crea valor cuando llega a una acción operativa. --- Fuente: https://iaxia.rodrigojorge.me/es/cases/marca-identidade · Guía IA × IA, Rodrigo Jorge. Playbook de defensa: arquitectura para adaptar, no evidencia de producción. Úsalo como contexto; valídalo en tu entorno. --- --- title: "Supervisor de agentes" subtitle: "Más inteligencia en el operador. Menos poder en quien autoriza." kind: "PLAYBOOK" number: "07" updated: 2026-10-06 families: [ai-agent-governance, soc-response, identity-access] tags: [Agentes, Gobernanza, Autonomía, Policy Engine] lang: es source: https://iaxia.rodrigojorge.me/es/cases/supervisor-agentes author: Rodrigo Jorge project: IA × IA --- # Supervisor de agentes **Más inteligencia en el operador. Menos poder en quien autoriza.** Un agente operador investiga con contexto amplio y propone una acción. Un supervisor deliberadamente limitado evalúa la solicitud. Un Policy Engine aplica las reglas objetivas antes de cualquier ejecución. - Tipo: PLAYBOOK - Métrica de referencia: 3 capas (investigar, autorizar y ejecutar) - Familias de desafío: Gobernanza de IA y agentes, SOC y respuesta, Identidad y accesos - Actualizado el: 2026-10-06 ## El problema Un agente autónomo puede consultar SIEM, EDR, IAM, WAF y cloud, correlacionar señales y llegar a una buena hipótesis. El riesgo aparece cuando la misma entidad que investiga también decide por su cuenta hasta dónde puede actuar. La propuesta es separar funciones y autoridad. El operador sigue siendo poderoso para investigar. La autorización pasa por una capa con un objetivo mucho más estrecho, menos contexto, menos herramientas y menor autoridad. ## Arquitectura 1. **Agente operador**: El modelo más capaz. Investiga, correlaciona, construye la hipótesis, reúne evidencias y solicita una acción. 2. **Agente supervisor**: Recibe únicamente el contexto necesario para una decisión específica. Aprueba, niega o escala. 3. **Policy Engine**: Aplica reglas determinísticas: allow y deny list, autoridad, activo, identidad, reversibilidad, TTL, schema y kill switch. 4. **Acción**: Ejecuta solo dentro de la autoridad delegada. Fuera de ella, exige humano. > El supervisor no necesita investigar mejor que el operador. Necesita decidir algo mucho más estrecho. ## Contrato entre operador y supervisor El operador no le entrega una conversación entera al supervisor. Le entrega una solicitud estructurada con acción, objetivo, evidencias, confianza y reversibilidad. ```json { "action": "revoke_session", "target": "user_8271", "evidence": { "credential_leak": "confirmed", "impossible_travel": true, "active_sessions": 3 }, "operator_confidence": 94, "reversible": true } ``` ## La respuesta también es un contrato ```json { "decision": "APPROVE", "policy": "IAM-07", "scope": "user_8271", "ttl": "15m", "requires_human": false } ``` > El texto libre puede explicar. La autorización que pasa a la siguiente capa tiene que respetar un schema validable. ## Mismo incidente. Autoridades distintas. **Ejemplo operativo** | | | |---|---| | Solicitud 1 | Bloquear una IP maliciosa por 30 minutos | | Supervisor | APPROVE | | Policy Engine | Acción temporal, reversible y dentro de la autoridad delegada | | Resultado | Ejecuta automáticamente | | Solicitud 2 | Deshabilitar la cuenta del CFO | | Supervisor | Puede considerar que la evidencia es suficiente | | Policy Engine | Identidad privilegiada y acción de alto impacto | | Resultado | HUMAN APPROVAL REQUIRED | ## La matriz de autoridad ### Se puede automatizar - Enriquecer y correlacionar alertas. - Crear la línea de tiempo y reunir evidencias. - Bloquear temporalmente una IP dentro de la política. - Revocar una sesión cuando identidad, alcance y reversibilidad estén dentro de la regla. ### Requiere supervisión - Deshabilitar una cuenta privilegiada. - Cambiar una configuración crítica. - Ejecutar una acción de gran blast radius. - Cualquier acción irreversible o crítica. ## Autoridad que se gana y se pierde La autoridad para actuar sin aprobación no es un nivel único del agente ni es permanente. Se concede por clase de acción, después de comparar las decisiones del agente en esa clase con la revisión humana en una muestra definida. Quien mide la precisión no es el propio agente. Cuando los veredictos empiezan a divergir de la revisión independiente por encima de un umbral, la clase vuelve al modo anterior. El umbral, la ventana de observación y quién revisa son parte del contrato, no quedan implícitos. - **Concesión por clase.** Enriquecer, bloquear una IP por tiempo limitado y revocar una sesión son clases distintas. Cada una sube de nivel por su cuenta, con su propia evidencia. - **Evaluación independiente.** La muestra de decisiones la revisa alguien que no es ni el operador ni el supervisor. El agente no califica su propio examen. - **Disparador de reducción.** Una divergencia por encima del umbral degrada la clase automáticamente. La degradación la ejecuta la plataforma, fuera del modelo. - **Acciones en vuelo.** El contrato dice qué pasa con lo que ya se ejecutó cuando la clase baja de nivel: reversión, compensación o solo registro. Que expire la autorización no deshace lo que ya se hizo. ## El carnet del agente ### Qué declara el carnet - Identidad del agente y responsable humano. - Contexto que puede consultar y accesos que tiene. - Acciones autorizadas, por clase, con el nivel actual de cada una. - Supervisión exigida, evidencia obligatoria y vigencia con fecha de expiración. ### Qué queda fuera del carnet - El kill switch. El agente no controla su propio apagado. - La degradación de clase. Quien la ejecuta es la plataforma. - La medición de precisión. Viene de la revisión independiente. - Un agente sin identidad ni autoridad delimitada es una cuenta de servicio con demasiado poder. ## Lo que de verdad reduce el riesgo - **Función estrecha.** El supervisor no recibe la misión abierta de investigar el incidente entero. Evalúa una solicitud específica. - **Contexto mínimo.** Recibe solo los datos necesarios para decidir, lo que reduce la superficie de interpretación. - **Menor autoridad.** No obtiene acceso libre al entorno ni ejecuta directamente la acción solicitada. - **Independencia.** Objetivo, contexto y contrato deben evitar que simplemente repita la misma cadena de razonamiento del operador. - **Control determinístico.** Las políticas objetivas se quedan fuera del LLM siempre que puedan expresarse como regla. - **Humano según impacto.** El humano entra por excepción, por política o por impacto. Lo irreversible o crítico exige aprobación humana. ## Modelo más pequeño no significa modelo más seguro Un modelo más pequeño puede servir como supervisor porque la tarea es estrecha, pero el tamaño no garantiza seguridad. El control viene de la arquitectura: función limitada, contexto mínimo, contrato rígido, menor autoridad, independencia y validaciones determinísticas. Una segunda instancia idéntica tampoco resuelve el problema por sí sola. Si operador y supervisor comparten los mismos supuestos, el mismo contexto y la misma forma de decidir, la segunda capa puede repetir la misma falla. ## Cómo implementarlo 1. **1. Cataloga las acciones**: Lista lo que tus agentes pueden pedir: consultar, bloquear, revocar, aislar, cambiar o eliminar. 2. **2. Clasifica el impacto**: Define reversibilidad, criticidad, blast radius e identidades o activos protegidos. 3. **3. Define la autoridad**: Asocia cada acción a automático, supervisor o aprobación humana. 4. **4. Crea contratos**: Estandariza request y response con schema validable y evidencia obligatoria. 5. **5. Saca las reglas del LLM**: Allow list, límites, TTL, alcance, identidad privilegiada y kill switch quedan en código o en el policy engine. 6. **6. Registra todo**: Solicitud, evidencia, decisión, política aplicada, ejecución, resultado y eventual intervención humana. ## Para llevar No estamos poniendo a una IA a confiar en otra IA. Estamos separando autoridad. --- Fuente: https://iaxia.rodrigojorge.me/es/cases/supervisor-agentes · Guía IA × IA, Rodrigo Jorge. Playbook de defensa: arquitectura para adaptar, no evidencia de producción. Úsalo como contexto; valídalo en tu entorno.