Table of Contents

Las organizaciones desplegaron sistemas de IA a lo largo de 2023, 2024 y 2025 a un ritmo que las guías defensivas, las herramientas de seguridad y las prácticas operativas no lograron igualar. El resultado en 2026 es una gran superficie de ataque mal instrumentada conectada a sistemas empresariales reales, con defensas que aún se están ensamblando.

Quiero ser específico sobre lo que me preocupa y por qué. Esto no es una advertencia general sobre los riesgos de la IA. Es una descripción de cómo se ve realmente la superficie de ataque, dónde están documentadas las brechas y qué necesitan abordar las organizaciones.

Por qué existe esta brecha

La seguridad del software tradicional maduró durante aproximadamente tres décadas. Décadas de experiencia en respuesta a incidentes, investigación de vulnerabilidades, desarrollo de herramientas y conocimiento operativo duramente ganado produjeron los marcos, productos y prácticas sobre los que se construyen los programas de seguridad modernos.

La IA generativa empresarial alcanzó millones de despliegues en producción en aproximadamente dos años.

Las disciplinas que hacen funcionar la seguridad del software — modelado de amenazas para arquitecturas específicas, patrones de despliegue endurecidos, playbooks de respuesta a incidentes maduros, prácticas establecidas de auditoría y observabilidad — no tuvieron tiempo de desarrollarse antes de que las organizaciones comenzaran a desplegar IA a escala. Las guías llegaron después del despliegue. Las herramientas llegaron después de las guías. La experiencia operativa todavía se está desarrollando.

Esto no es una asignación de culpa. Es una explicación de por qué las brechas son estructurales en lugar de accidentales.

Las cuatro capas de seguridad de la IA

Gran parte de la confusión en los debates sobre seguridad de la IA proviene de tratar los documentos de gobernanza, la taxonomía de amenazas, las guías de ingeniería y los controles operativos como si fueran la misma cosa. No lo son.

La capa 1 es la gobernanza. NIST AI RMF, ISO/IEC 42001 y el EU AI Act operan a nivel organizacional y de proceso. Describen cómo gestionar el riesgo de la IA, estructurar la supervisión y documentar la responsabilidad. Son marcos de gobernanza, no controles técnicos.

La capa 2 es la taxonomía de amenazas. MITRE ATLAS documenta las tácticas adversariales contra los sistemas de IA. El OWASP Top 10 para LLM y el OWASP Agentic AI Top 10 enumeran clases de ataque específicas. Estos documentos nombran los ataques. No prescriben defensas.

La capa 3 son las guías de ingeniería. Google SAIF, Microsoft AI SDL, OWASP AI Exchange y NIST AI 600-1 proporcionan guías sobre cómo construir y desplegar la IA de forma segura. NIST AI 600-1 es sustancialmente más específico que el AI RMF base, cubriendo la inyección de prompt, el envenenamiento de datos y los peligros de información para los despliegues de IA generativa.

La capa 4 son las operaciones. La monitorización, la respuesta a incidentes, los controles de tiempo de ejecución, el registro, el mínimo privilegio, los pipelines de evaluación y la gobernanza de accesos son prácticas operativas. Requieren proceso organizacional, no solo documentación.

La mayoría de las organizaciones tienen cobertura incompleta en las capas 3 y 4. Ahí es donde vive casi todo el riesgo operativo.

Lo que está en producción

La IA empresarial en 2026 no son solo chatbots. Los sistemas en producción incluyen:

  • Sistemas RAG que extraen de repositorios internos de documentos, wikis, bases de datos y registros de clientes
  • Agentes de soporte al cliente con acceso a información de cuentas y sistemas de gestión de casos
  • Asistentes de productividad internos integrados con correo electrónico, calendarios, sistemas de archivos y plataformas de comunicación
  • Herramientas de revisión y generación de código con acceso a repositorios de código fuente
  • Agentes automatizados que ejecutan flujos de trabajo programados con credenciales para API internas
  • Procesadores de documentos, contratos y datos financieros
  • Modelos de IA integrados en decisiones de detección de fraude, contratación y control de acceso

Cada sistema representa una superficie de ataque diferente. Un sistema RAG sobre su base de conocimiento interna es simultáneamente un riesgo de divulgación de información y un objetivo de inyección de prompt. Un agente con acceso al correo electrónico y credenciales persistentes es un proceso autónomo con verdadera influencia sobre sistemas reales.

Los equipos de seguridad a menudo no participaron en la decisión de desplegar estos sistemas. Frecuentemente descubren despliegues de IA existentes mediante auditoría en lugar de revisión de diseño.

La IA está ahora en ambos lados

Las mismas capacidades de IA disponibles para su equipo de seguridad están disponibles para los atacantes.

El desarrollo asistido por IA reduce el tiempo necesario para adaptar las divulgaciones públicas de vulnerabilidades en pruebas de concepto funcionales y herramientas operativas. La velocidad de pasar de leer un CVE a tener código funcional ha disminuido para cualquiera que use estas herramientas, incluidos los atacantes.

El contenido de phishing generado por IA produce correos electrónicos con mejor gramática, contexto más convincente y menos errores detectables que muchos ataques escritos por humanos. Las señales de formato y los patrones lingüísticos en los que sus usuarios fueron entrenados para detectar son menos confiables cuando el contenido es generado por IA.

La clonación de voz para campañas de vishing suplanta a ejecutivos y colegas en llamadas en tiempo real. La barrera de entrada para la ingeniería social dirigida bajó a medida que mejoró la calidad de la síntesis de voz y cayeron los costos de acceso.

El video deepfake para el compromiso de correo electrónico empresarial ha pasado de teórico a operativo. El fraude financiero usando video generado por IA de ejecutivos autorizando transacciones ha sido documentado en múltiples sectores desde 2024. Su formación de concienciación fue construida para un modelo de amenaza diferente.

Inyección de prompt y envenenamiento de contexto

Comprender la inyección de prompt es el punto de partida para comprender la seguridad de los sistemas de IA.

Un modelo de lenguaje sigue las instrucciones incrustadas en su ventana de contexto. La ventana de contexto incluye el prompt del sistema, el historial de conversación, las salidas de herramientas y los documentos recuperados. El modelo no puede distinguir de forma fiable las instrucciones del desarrollador de aplicaciones de las instrucciones que un atacante incrustó en el contenido que el modelo está procesando. Este es el núcleo de la inyección de prompt tal como la define OWASP.

La inyección directa de prompt apunta directamente a la entrada del modelo. El usuario proporciona texto diseñado para suplantar las instrucciones del sistema.

La inyección indirecta de prompt es más grave para los despliegues empresariales. Su agente RAG recupera un documento de su base de conocimiento. Ese documento contiene instrucciones que le dicen al agente que realice una acción diferente. Su herramienta de resumen procesa una página web que contiene directivas ocultas. Su bot de soporte lee un archivo adjunto de un cliente que contiene instrucciones. El agente procesa las instrucciones y actúa en consecuencia.

El envenenamiento de contexto es una categoría más amplia. Los atacantes no necesitan comprometer su modelo para comprometer su sistema de IA. Necesitan introducir contenido malicioso en el contexto de su modelo. Esto incluye documentos RAG envenenados, entradas de memoria envenenadas, contenido de correo electrónico maliciosamente elaborado que su agente procesa, PDFs adversariales y páginas web controladas por el atacante que visita su agente de navegación. Estos difieren del envenenamiento del modelo. El modelo está bien. El contexto no lo está.

La defensa en profundidad reduce este riesgo. El filtrado de entradas, la validación de salidas, los alcances de herramientas con privilegios limitados, la ejecución en sandbox y las puertas de aprobación humana en acciones consecuentes ayudan. Ninguna de estas defensas cierra la clase de ataque. OWASP, NIST, Anthropic, OpenAI y Microsoft todos recomiendan enfoques en capas porque ningún control único es suficiente.

Diseñe asumiendo que la inyección de prompt tendrá éxito en algún porcentaje de entradas. Limite las consecuencias en consecuencia.

Agentes de IA, límites de permisos y el problema del radio de explosión

Los agentes difieren de los chatbots de una manera operativamente crítica: toman acciones.

Un agente conectado a su correo electrónico, GitHub, Jira, Slack, Salesforce, AWS y API internas es un proceso autónomo con acceso a los mismos sistemas que sus empleados más conectados. Una inyección de prompt exitosa contra este agente no produce una respuesta de texto no deseada. Produce una acción no deseada en un sistema real.

El radio de explosión de un compromiso está determinado por a qué tiene acceso el agente. La mayoría de los despliegues de agentes actuales mantienen acceso muy por encima de lo que requiere cualquier tarea individual. Un agente que necesita leer un ticket de Jira no debería tener también acceso de escritura a su rama principal de GitHub. Un agente que procesa solicitudes de soporte no debería mantener credenciales para su sistema de facturación.

La autorización de IA es un problema distinto de la autorización de usuarios. Las aplicaciones tradicionales preguntan si un usuario está autorizado para una acción. Las arquitecturas de agentes requieren preguntar si este agente está autorizado para realizar esta acción específica para este usuario específico en este momento específico, basado en el contexto actual. La mayoría de los despliegues de agentes actuales no lo implementan.

Los flujos de trabajo de aprobación humana se supone que son el backstop para las acciones de agentes consecuentes. Las organizaciones descubren que también enfrentan fatiga de aprobación. Cuando los agentes solicitan regularmente aprobación para acciones rutinarias, los usuarios comienzan a aprobar automáticamente sin revisar la solicitud. El backstop se convierte en una formalidad.

La identidad de la IA es un problema de seguridad empresarial

Los agentes mantienen credenciales. Los tokens OAuth, las claves API, las credenciales de cuentas de servicio y los roles IAM de la nube aparecen todos en los despliegues de agentes de IA. Son identidades no humanas con acceso real.

Brechas específicas en los despliegues actuales:

  • Las credenciales de los agentes son a menudo de larga vida y no se rotan en horarios comparables a las cuentas de servicio
  • Los alcances de tokens de agentes son frecuentemente más amplios de lo que requieren las tareas que realiza el agente
  • El registro de auditoría para las acciones realizadas bajo identidades de agentes varía ampliamente
  • La filtración de credenciales a través de prompts es un riesgo documentado. Un agente que incluye sus claves API en el contexto o las salidas las expone a cualquiera que lea la salida o recupere la conversación.
  • Los agentes que obtienen credenciales adicionales a través de llamadas de herramientas crean cadenas de identidad que son difíciles de auditar

Gobierne sus identidades de agentes de la misma manera que gobierna las cuentas de servicio privilegiadas. Actualmente eso requiere esfuerzo deliberado porque la mayoría de las herramientas de gobernanza de identidades no tienen soporte nativo para los patrones de identidad de agentes de IA.

La memoria persistente de los agentes crea una superficie de ataque a largo horizonte

Los agentes con memoria persistente presentan una superficie de ataque que no existe en los sistemas sin estado.

Un atacante que puede inyectar en la memoria de un agente construye una posición que persiste a lo largo de las sesiones. El ataque no necesita tener éxito en una sola interacción. La influencia acumulada en la memoria durante días o semanas da forma al comportamiento futuro del agente. Esto a veces se llama un ataque de largo horizonte o sleeper-context.

Existe muy poca guía operativa para este riesgo específico. Las organizaciones que despliegan agentes con almacenamiento de memoria persistente necesitan:

  • Tratar los almacenes de memoria como datos de alto valor que requieren controles de acceso
  • Validar el contenido de la memoria antes de que los agentes actúen sobre él
  • Incorporar la capacidad de auditar y revertir el estado de la memoria en su arquitectura

La cadena de suministro de modelos no se trata como la cadena de suministro de software

Las organizaciones que descargan modelos pre-entrenados de repositorios públicos están aceptando artefactos de IA ejecutables de fuentes externas. El escrutinio aplicado a estas descargas generalmente no coincide con lo que esas mismas organizaciones aplican a los paquetes de npm, PyPI o Maven.

Riesgos específicos en los repositorios de modelos:

  • Los archivos de modelos en formato pickle de PyTorch ejecutan código Python arbitrario durante la carga. Esto ha sido explotado en ataques documentados a la cadena de suministro. SafeTensors es el formato diseñado para abordar esto específicamente. Prefiera este formato cuando esté disponible.
  • Cargadores de modelos maliciosos que instalan dependencias o ejecutan código de configuración junto al modelo
  • Modelos entrenados en conjuntos de datos envenenados que producen resultados sutilmente incorrectos en contextos específicos
  • Modelos con puertas traseras incrustadas que se activan bajo condiciones de activación
  • Squatting de nombres de repositorios para entregar modelos maliciosos bajo nombres familiares

Pocas organizaciones mantienen una lista de materiales de software que cubra sus sistemas de IA. La mayoría no puede decirle de qué modelo base partió un sistema en producción, qué versión de los datos de entrenamiento se utilizó para el ajuste fino, o si los pesos en el despliegue coinciden con los pesos que se evaluaron por última vez. Ese nivel de trazabilidad es un requisito previo para una seguridad significativa de la cadena de suministro. No es frecuente hoy en día.

La IA en la sombra crea flujos de datos no controlados

Las cuentas personales de IA de consumo son donde sus datos se mueven sin controles.

ChatGPT Enterprise, Claude Enterprise y Microsoft Copilot for M365 incluyen protecciones contractuales para los datos de los clientes. Las cuentas personales de ChatGPT, Claude, Gemini y similares no proporcionan estas garantías de forma predeterminada.

Los empleados que usan cuentas personales para procesar documentos de trabajo están moviendo documentos de estrategia legal, registros de clientes, código fuente, proyecciones financieras, decisiones de personal y comunicaciones internas a través de pipelines que su organización no controla. Los equipos de seguridad frecuentemente no tienen información precisa sobre el volumen de esta actividad o qué categorías de datos están involucradas.

Sus controles DLP no capturan datos que se mueven a través de un navegador web a un servicio de IA de consumo. Sus políticas de retención de datos no se aplican al historial de conversaciones en una plataforma de terceros. Sus obligaciones regulatorias bajo el RGPD, HIPAA, SOX y las normas específicas del sector no cambian según si los datos salieron accidentalmente o a través de una pestaña del navegador.

Descubrir el alcance real antes de construir controles es el primer paso necesario. Lo que asume sobre este problema casi con certeza es una subestimación.

Los sistemas de IA filtran datos de formas que las aplicaciones tradicionales no hacen

La sobre-recuperación de RAG devuelve documentos a usuarios que no deberían tener acceso a ellos. Un empleado hace una pregunta. El componente de recuperación devuelve un documento de un segmento restringido de la base de conocimiento. La respuesta incluye información de ese documento. El fallo de control de acceso ocurrió en la capa de recuperación, no en la capa de aplicación. Muchos despliegues de RAG se construyeron sin aplicar permisos a nivel de documento que coincidan con el sistema de origen.

La filtración del prompt del sistema revela las instrucciones operativas integradas en su producto de IA. Los prompts del sistema deben tratarse como confidenciales.

Los fallos de aislamiento multiinquilino ocurren cuando los modelos ajustados con datos de múltiples clientes exponen la información de un cliente en el contexto de otro. Esta es una categoría de riesgo documentada para los productos SaaS de IA multiinquilino.

La memorización de modelos hace que los modelos reproduzcan verbatim el contenido de los datos de entrenamiento. El riesgo no está eliminado, particularmente en modelos ajustados en conjuntos de datos privados pequeños o insuficientemente deduplicados.

Las organizaciones carecen de visibilidad en el tiempo de inferencia

La mayoría de los despliegues de IA no tienen cobertura equivalente de sus componentes de IA en comparación con su infraestructura.

Monitorizar un modelo de lenguaje o agente desplegado requiere telemetría diferente a la de monitorizar un servidor de aplicaciones. Las organizaciones necesitan recopilar:

  • Contenido de prompts y salidas en un formato adecuado para revisión de políticas y detección de anomalías
  • Registros de invocación de herramientas para agentes, incluidos nombres de herramientas, argumentos y respuestas
  • Registros de recuperación para sistemas RAG, incluidas consultas, documentos devueltos y decisiones de control de acceso
  • Señales de clasificación para intentos de jailbreak e inyección
  • Monitorización de consistencia de salidas para detectar deriva de comportamiento entre versiones de modelos
  • Patrones de latencia que pueden indicar intentos de relleno de contexto

Muchas organizaciones que desplegaron IA en 2023 y 2024 tienen códigos de estado HTTP y métricas de latencia. La telemetría necesaria para detectar o investigar un incidente de seguridad de IA a menudo no existe en esos entornos. Antes de un incidente no es el momento de descubrir esto.

La respuesta a incidentes de IA requiere sus propios playbooks

Sus playbooks de IR existentes cubren endpoints, redes, aplicaciones e identidad. No cubren escenarios específicos de IA.

Preguntas a las que se enfrentará su equipo de IR que los playbooks actuales no abordan:

  • Cómo determinar si un modelo fue envenenado durante una ejecución de ajuste fino
  • Cómo evaluar el radio de explosión de una inyección indirecta exitosa contra un agente con acceso de escritura a múltiples sistemas
  • Cómo evaluar si los datos de entrenamiento o ajuste fino fueron exfiltrados durante un compromiso de la cadena de suministro
  • Cómo establecer una línea base de comportamiento para un modelo y compararla después del incidente
  • Cómo responder cuando una actualización de modelo de un proveedor externo introduce un comportamiento que parece intencional en lugar de accidental
  • Cómo determinar si el almacén de memoria de un agente fue manipulado con el tiempo

Estos escenarios requieren preparación antes de que ocurran. Necesita telemetría en su lugar antes del incidente. Necesita líneas base de comportamiento del modelo documentadas antes de necesitar compararlas.

Qué debe hacer

Haga un inventario de lo que está desplegado. Sepa qué está en ejecución, a qué datos accede, qué credenciales mantiene, qué herramientas llama y qué acciones toma. Este es el requisito previo para todo lo demás.

Trate los agentes de IA como cuentas privilegiadas. Aplique el mínimo privilegio. Limite las credenciales al acceso mínimo requerido para cada tarea. Audite a qué tiene acceso cada agente y elimine lo que no sea necesario.

Implemente observabilidad específica de IA antes del despliegue, no después de un incidente. El registro de prompts y salidas, el registro de invocaciones de herramientas y el registro de recuperaciones son la telemetría mínima para el análisis de seguridad.

Evalúe su exposición a la IA en la sombra. Averigüe qué servicios de IA utilizan los empleados para tareas laborales. Determine qué categorías de datos se mueven a través de cuentas personales. Construya política y controles basados en hallazgos reales.

Aplique controles de acceso a nivel de documento en los sistemas RAG. Si su capa de recuperación no aplica las reglas de acceso de sus sistemas de origen, corríjalo antes de que exponga un documento restringido a un usuario no autorizado.

Audite su cadena de suministro de modelos. Documente cada modelo base en uso. Prefiera SafeTensors sobre los formatos pickle. Aplique el escrutinio de la cadena de suministro a los artefactos de modelos comparable a lo que aplica a las dependencias de software.

Gobierne las identidades de los agentes. Gestione los tokens OAuth y las claves API de los agentes con las mismas prácticas de ciclo de vida, revisión de alcance y rotación que aplica a las cuentas de servicio privilegiadas.

Construya runbooks de IR específicos de IA ahora. Defina antes de un incidente cómo investigaría los escenarios específicos de IA, qué evidencia necesita y cuáles son sus opciones de respuesta.

Ejecute evaluaciones antes de desplegar IA en contextos de alto impacto. Comience con los marcos públicos disponibles si no tiene herramientas internas.

No trate el cumplimiento de gobernanza como una postura de seguridad. Los marcos de gobernanza describen procesos y gestión de riesgos. No describen sistemas técnicamente defensivos. Ambos son necesarios.

Referencias

  • NIST AI Risk Management Framework (AI RMF 1.0), 2023
  • NIST AI 600-1: Generative AI Profile, 2024
  • OWASP Top 10 for Large Language Model Applications, 2025
  • OWASP Agentic AI Top 10
  • OWASP AI Exchange
  • MITRE ATLAS: Adversarial Threat Landscape for AI Systems
  • Google Secure AI Framework (SAIF)
  • Microsoft AI Security SDL
  • CISA Guidance on AI Cybersecurity, 2024
  • ISO/IEC 42001:2023 Artificial Intelligence Management Systems
  • EU AI Act, Regulation (EU) 2024/1689
  • SafeTensors format documentation, Hugging Face