Proteger la IA y defenderse de ella son dos problemas totalmente distintos

El término "seguridad de IA" se utiliza para dos problemas que no tienen casi nada en común. Uno consiste en proteger los sistemas que utilizan un modelo. El otro radica en defenderse de atacantes que emplean modelos para sus ofensivas. Los atacantes son distintos, los controles son distintos, los responsables son distintos y, cada vez más, los presupuestos también lo son. Los equipos que confunden ambos conceptos acaban comprando la solución equivocada y luego se preguntan por qué no resolvió nada.

El resto de esta serie se apoya en esta distinción, así que conviene aclararla con total precisión desde el principio.

El problema

Un equipo de plataforma despliega un asistente interno. Lee la cola de incidencias, busca en la wiki corporativa y tiene permisos para abrir solicitudes de cambio. Alguien formula la pregunta evidente: ¿es seguro? El departamento de compras regresa con tres proveedores. Uno vende una pasarela que inspecciona prompts y salidas de modelos. Otro vende seguridad de correo que etiqueta mensajes generados por IA. El tercero vende una plataforma de gobernanza que mapea tus modelos con marcos normativos. Los tres se anuncian como seguridad de IA, pero solo uno de ellos tiene que ver con el asistente.

La misma confusión ocurre en el sentido opuesto. Un equipo de finanzas transfiere $180,000 a un atacante que clonó el estilo de redacción de un proveedor con tanta precisión que nadie cuestionó la petición. La revisión posterior al incidente recomienda "controles de seguridad de IA". Los controles que realmente habrían evitado el fraude son la verificación estricta de pagos y la autenticación resistente al phishing, mecanismos que no guardan relación alguna con los modelos que la empresa tenga en producción.

Por qué cambia con la IA

Ambos problemas solo se parecen porque comparten las mismas siglas. Si los separas, apenas queda nada en común.

Proteger la IA es un problema de aplicaciones y de infraestructura. El activo que proteges es un sistema que tú has construido o que tú operas. El adversario es cualquiera que pueda alcanzar sus entradas, lo que en la práctica significa cualquiera capaz de colocar texto frente al modelo: una página web que el sistema resume, un documento que procesa o el resultado de una herramienta que consulta. El documento OWASP Top 10 for LLM Applications 2026 es la lista de referencia en este ámbito, y sus apartados describen fallos que ocurren dentro de tu propia infraestructura: inyección de prompts en LLM01, divulgación de información sensible en LLM02, atribuciones excesivas en LLM03 o consumo ilimitado en LLM06 [1]. Son problemas de diseño y de permisos que se corrigen modificando lo que tu sistema puede hacer.

La IA como arma es un problema de operaciones de seguridad. El activo en juego es tu personal y tu dinero. El adversario está fuera y el modelo le pertenece a él. Nada en tu arquitectura altera la capacidad del atacante. Lo que ha cambiado es la economía a su favor, porque generar un engaño convincente y adaptado a una víctima concreta ha dejado de ser costoso.

El Centro de Denuncias de Delitos en Internet (IC3) del FBI registró este cambio con notable claridad en 2025. Las denuncias por phishing y suplantación cayeron ligeramente, pasando de 193,407 a 191,561. Sin embargo, las pérdidas económicas declaradas en esa misma categoría se dispararon de $70,013,036 a $215,843,126 [2]. Hablamos de cerca de un 1% menos de denuncias con aproximadamente el triple de dinero sustraído. En ese mismo informe, el compromiso del correo corporativo (BEC) acumuló $3,046,598,558 en 24,768 denuncias, con una media cercana a los $123,000 por incidente [2].

El volumen dejó de ser un indicador fiable del riesgo. Si tus métricas siguen contando mensajes bloqueados, estás midiendo lo que se ha abaratado para el atacante y pasando por alto lo que se ha vuelto mucho más destructivo.

Fíjate en lo que este segundo problema no necesita. No interviene ningún modelo propio. Podrías no desplegar nada, prohibir cualquier asistente en toda la empresa y tu nivel de exposición frente a este riesgo seguiría siendo el mismo.

Lo que realmente funciona

Deja de tratar esto como una sola partida presupuestaria y asigna cada mitad al equipo con capacidad real para actuar.

Para proteger la IA, los controles son los habituales aplicados a un nuevo componente: limita los permisos de las herramientas vinculadas al modelo, aísla el entorno de inferencia, fija cuotas a su consumo y mantén un registro de auditoría de cada acción ejecutada. La gran mayoría de estos controles son deterministas y se pueden forzar desde la infraestructura. Unos pocos, como clasificar un prompt como malicioso, son probabilísticos y deben situarse siempre detrás de las barreras deterministas.

Para los ataques facilitados por IA, los controles radican en la identidad y en los procesos. La autenticación resistente al phishing elimina las credenciales como objetivo vulnerable. La verificación fuera de banda para pagos y cambios de cuentas bancarias anula el pago fraudulento como objetivo. Ambos mecanismos son deterministas y funcionan sin importar lo impecable que sea la redacción del atacante. Disponer de detección que califique los mensajes entrantes según su intención o anomalía de estilo aporta valor, pero debe colocarse en último lugar, ya que es la única capa que pierde eficacia de manera imperceptible a medida que el atacante perfecciona sus modelos. Ambas listas apenas comparten elementos, y por eso mismo necesitan responsables independientes.

La asignación de responsabilidades debe reflejar esta división, y definirla por escrito suele ser el paso más productivo de todos. Los sistemas construidos con modelos pertenecen a seguridad de aplicaciones, mientras que la infraestructura determina dónde corren y qué pueden tocar. Los ataques entrantes asistidos por IA corresponden a operaciones de seguridad y a los administradores del correo. La gobernanza y el reporte supervisan ambos lados sin asumir la gestión operativa directa de ninguno. En la mayoría de empresas se trata de equipos distintos, con herramientas distintas y rotaciones de guardia distintas, motivo por el que un único concepto de "seguridad de IA" en el presupuesto suele inflar un área y dejar la otra desatendida.

Existe una coincidencia honesta entre ambos mundos. Ambas amenazas se ven agravadas por la misma costumbre organizativa de aprobar algo simplemente porque parece plausible y llegó a través de un canal familiar. En el primer caso se trata de una llamada a una herramienta que el modelo tuvo permiso para ejecutar. En el segundo caso es una orden de pago que se le pidió autorizar a un empleado. El control adecuado en ambos escenarios es una verificación independiente que no dependa de que el mensaje o la petición parezcan sospechosos a simple vista.

Lo que no funciona

El primer error consiste en comprar una herramienta y creer que cubre ambos problemas. Una pasarela que inspecciona los prompts de tu asistente no evita el fraude con una factura de proveedor, y el filtrado del correo no protege contra un agente con credenciales de escritura en tu base de datos. Ambos productos pueden ser excelentes, pero ninguno es universal.

Otro error habitual es confiar en la formación de concienciación como respuesta al segundo problema. Enseñar a detectar faltas de ortografía, saludos genéricos o enlaces sospechosos instruye sobre errores que un modelo de lenguaje elimina sin esfuerzo alguno. Mantener esa formación solo porque es el mecanismo del que ya dispones no significa que funcione.

Asignar ambos retos al responsable del último proyecto de IA tampoco da resultado. El personal que construye aplicaciones con modelos y el equipo que defiende el buzón de correo son grupos distintos con herramientas distintas y guardias distintas. Poner ambos problemas sobre la misma mesa garantiza que uno de los dos quede desatendido.

Lo mismo ocurre si esperas a que los distintos marcos metodológicos se fusionen. No van a converger porque describen realidades diferentes. El listado de OWASP clasifica vulnerabilidades en los sistemas que tú desarrollas, mientras que la inteligencia sobre amenazas de fraude con IA documenta ataques dirigidos contra tu organización. Ambos enfoques son útiles y ninguno sustituye al otro.

Por dónde empezar

• Define por escrito quién lidera cada frente: seguridad de aplicaciones e infraestructura para los sistemas creados con modelos; operaciones de seguridad para los ataques entrantes asistidos por IA. Si ambos roles recaen en la misma persona, ya tienes el primer problema identificado.
• Pregunta a cualquier proveedor cuál de los dos problemas aborda su producto. La respuesta suele ser rápida y directa, y una contestación evasiva te dirá todo lo que necesitas saber.
• Revisa las métricas de phishing de tu empresa. Si solo contabilizan el volumen de correos, añade una medición de pérdidas por incidente. La divergencia registrada en el informe IC3 [2] es el argumento más sólido para justificar este cambio.
• Haz un inventario de todo lo que tus modelos pueden alcanzar, algo mucho más prioritario que analizar lo que pueden decir. Credenciales, salidas a la red y permisos de escritura son la parte del primer problema que la infraestructura puede solucionar de verdad, y casi siempre es el punto que nadie ha documentado.
• Verifica cualquier transferencia o pago bancario fuera de banda mediante un proceso estructurado que no dependa de que alguien perciba un detalle extraño en un mensaje.

El resto de esta serie mantiene esta separación. Algunos artículos se centran en proteger lo que construyes y operas, mientras que otros analizan los ataques que llegan a tu bandeja de entrada. Saber con exactitud qué parte estás evaluando y para cuál tienes presupuesto supone la mayor parte del trabajo.

Fuentes

1. OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Project, published 3 August 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
2. 2025 Internet Crime Report, FBI Internet Crime Complaint Center: https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf