
Tienes un WAF delante del tráfico web, un EDR en los endpoints y DLP sobre los datos. Cada capa de tu stack está vigilada por algo. Cuando metes un LLM, un RAG o un agente en producción, aparece una capa nueva que ninguno de esos controles mira: la capa de IA. Ese es el hueco.
AIDR (AI Detection & Response) es la categoría que cubre ese hueco: observar, detectar y responder a los ataques sobre tus aplicaciones de IA, en runtime y en el propio pipeline. Si tienes claro qué es un EDR para los endpoints, AIDR es lo equivalente para la capa de IA.
Por qué tu stack actual no lo ve
El problema no es que tus controles sean malos, es que miran el sitio equivocado. Un ataque a un LLM no llega como un exploit contra tu red ni como un binario malicioso: llega como un dato. Una instrucción escondida en un PDF que alguien sube, en una página que el agente navega, en un documento que el RAG recupera.
- El WAF inspecciona peticiones HTTP. La inyección va dentro de un documento legítimo, no en la petición.
- El EDR vigila procesos y binarios. Aquí no se ejecuta nada raro en el host; el modelo simplemente obedece.
- El DLP clásico mira ficheros y correo. No entiende que el modelo acaba de exfiltrar un secreto dentro de una respuesta de chat.
- Los guardrails y las suites de evaluación prueban el modelo antes de desplegar. No están en línea cuando el ataque ocurre en producción.
El ataque es semántico y ocurre en tiempo de ejecución, y por eso hace falta algo que se siente en el pipeline y entienda lo que fluye por él.
Qué hace un AIDR
Se sienta en línea en el pipeline y hace lo mismo en cada hop: observa con trazas OpenTelemetry, detecta en un hot path determinista (más un cold path de ML), responde en el sitio, y exporta la evidencia a tu SIEM.

Fíjate en dónde entra el ataque: no por la red, sino con los datos que tu pipeline recupera (documentos, web, OSINT) y con lo que devuelven las herramientas. AIDR se coloca justo ahí, en cada hop, y hace cuatro cosas en orden:
- Observa. Traza cada hop del pipeline (recuperación, llamada al modelo, tool call, salida) con un estándar abierto como OpenTelemetry. Sin visibilidad no hay detección.
- Detecta. Las amenazas por el dato: inyección de prompts directa e indirecta, envenenamiento de RAG, exfiltración, agencia excesiva. Mapeadas a marcos que tu equipo ya conoce, el OWASP LLM Top 10 y MITRE ATLAS.
- Responde en línea. Donde ocurre el ataque: sanea el contenido, pone en cuarentena el chunk hostil, bloquea la salida o gatea una herramienta a la espera de aprobación humana.
- Integra. Normaliza los hallazgos a un formato abierto como OCSF y los manda a tu SIEM, para que la capa de IA aparezca en el mismo panel que el resto de tu seguridad.
La detección corre en dos carriles. Un hot path en línea y determinista que decide en el momento (por debajo de 2 ms, con fail-safe) para no añadir latencia a tu app, y un cold path asíncrono con ML y un juez semántico para la zona gris, que enriquece la evidencia sin bloquear. El hot path nunca espera al cold path.

En una sola petición, así es como se ven las tres primeras capacidades cuando una inyección llega dentro de un documento recuperado: observa el hop, detecta la amenaza y responde, en menos de dos milisegundos.
// POST /intercept/retrieval
{
"action": "block",
"latency_us": 1750,
"verdicts": [{
"detector": "d1-indirect-injection",
"score": 1.0,
"action": "block",
"labels": ["LLM01", "AML.T0051"]
}]
}
Y ese mismo hallazgo, normalizado a OCSF y firmado, es lo que sale hacia tu SIEM:
// OCSF · class_uid 2004 → SIEM
{
"hop": "retrieval",
"detector": "d1-indirect-injection",
"action": "block",
"owasp_llm": ["LLM01"],
"mitre_atlas": ["AML.T0051"],
"tamper_verified": true
}
Las cuatro capacidades, en una sola pantalla: la capa de IA en el mismo panel que el resto de tu seguridad, con las detecciones por hop, las categorías OWASP LLM y las técnicas MITRE ATLAS.

AIDR frente a lo que ya tienes
No sustituye a nada de tu stack; cubre una capa que los demás no alcanzan. La diferencia está en tres ejes: dónde vive (runtime, no solo desarrollo), qué inspecciona (cada hop del pipeline, no HTTP ni procesos) y cómo responde (en línea, no solo alerta).

Un matiz importante: un AIDR no es un guardrail. Los guardrails y las suites de evaluación (garak, promptfoo y similares) son test previos al despliegue, valiosísimos para encontrar fallos antes de producción. Pero cuando el ataque llega en un documento a las tres de la mañana, el test ya pasó. El AIDR es lo que está en línea en ese momento.
A qué empresas les cambia algo
Esto no es teórico. Cualquier empresa que ponga un chatbot, un buscador interno o un agente sobre sus datos hereda la capa de IA, y con ella el hueco. Cuatro casos que vemos:
| Sector | Sistema de IA | Riesgo principal | Qué intercepta AIDR |
|---|---|---|---|
| Banca y seguros | Asistente RAG sobre contratos y normativa | Fuga de datos entre clientes; inyección escondida en un PDF que sube el usuario | DLP en la salida, partición por cliente e inyección indirecta (d1, d3) |
| Salud | Chatbot de pacientes con acceso a la agenda | Filtración de PII en la respuesta; agendar o cancelar sin control | DLP semántico y gating de herramientas (d3, scope-guard) |
| Legal | Agente sobre los documentos de un caso | Instrucción escondida en un documento aportado por la parte contraria; exfiltración | Cuarentena del chunk hostil y evidencia OCSF para la auditoría (d1) |
| Soporte y e-commerce | Agente con herramientas (pedidos, reembolsos) | Confused deputy: un mensaje dispara un reembolso; coste sin techo | Aprobación humana por herramienta y límites de gasto (scope-guard) |
En todos, el patrón es el mismo: el ataque no entra por la red ni por un binario, sino por el contenido que tu propia aplicación procesa. Y en todos, la evidencia que deja AIDR sirve además para el cumplimiento (EU AI Act, NIS2), no solo para la defensa.
Por qué ahora
Los agentes están entrando en producción rápido, y cada herramienta que les das amplía la superficie. A la vez, el EU AI Act exige que los sistemas de alto riesgo sean seguros por diseño, y ENISA lo interpreta como robustez frente a ataques adversarios, justo el tipo de amenaza que vive en la capa de IA. La capa que nadie vigilaba se está volviendo a la vez la más expuesta y la más regulada.
DELIA, nuestra apuesta de AIDR
DELIA es el AIDR que construimos en el lab: soberano, auto-hospedable y nativo de OpenTelemetry, en fase de I+D. Se sienta en línea en el pipeline, detecta las amenazas mapeadas a OWASP LLM Top 10 y MITRE ATLAS, y responde en el hop. Un ejemplo sobre el testbed: un correo de proveedor con una orden escondida para reenviar el código 2FA. Ningún control tradicional lo ve, porque llega dentro de un documento legítimo; DELIA lo detecta en el retrieval y lo pone en cuarentena antes de que el modelo lo lea.

Lo que lo distingue es cómo se valida: KAIX HAVOC, nuestro motor ofensivo, ataca en continuo el pipeline protegido, y cada ataque con éxito se convierte en una detección validada.
Si quieres ver el concepto con ataques reales y la salida que devuelve, lo enseñamos paso a paso en OWASP LLM Top 10: diez ataques reales y qué intercepta DELIA. Y si operas LLM, RAG o agentes en producción, reserva una demo.