Las organizaciones que construyen sobre un modelo de lenguaje alojado reciben del proveedor un modelo con entrenamiento de seguridad y una plataforma, y siguen siendo responsables de la aplicación que lo rodea. Microsoft, la Cloud Security Alliance y la Ley de IA de la UE reparten el trabajo entre el proveedor del modelo y la parte que lo despliega, con un vocabulario distinto y un peso jurídico distinto. Esta nota compara los tres enfoques y propone un reparto práctico para el caso habitual de un modelo consumido a través de una API. Complementa How Anthropic red-teams Claude, and what it leaves to you, que examina el lado del proveedor en un caso publicado.
Contexto: el modelo de la nube, ampliado a la IA
El modelo de responsabilidad compartida de la nube asigna cada control al proveedor o al cliente según el tipo de servicio: software como servicio (SaaS), plataforma como servicio (PaaS) o infraestructura como servicio (IaaS). Tanto Microsoft como la Cloud Security Alliance (CSA) extienden esa idea a la IA generativa. La extensión cambia más el vocabulario que la lógica: cuanto más abajo en la pila construye un cliente, más controles le corresponden.
Modelos de los proveedores
Microsoft: plataforma, aplicación y uso
El modelo de responsabilidad compartida de IA de Microsoft describe una aplicación con IA en tres capas: la plataforma de IA, la aplicación de IA y el uso de la IA. La capa de plataforma ofrece el modelo a través de API e incluye un sistema de seguridad que filtra entradas y salidas dañinas. La capa de aplicación es la interfaz que utiliza el usuario, con grounding, plugins y conectores de datos, y necesita su propio sistema de seguridad de la aplicación. La capa de uso abarca cómo las personas utilizan la capacidad, y Microsoft remite a los controles de identidad y acceso, las políticas de uso aceptable y la formación de los usuarios. [1]
La parte de cada capa que corresponde al cliente depende del tipo de despliegue. La página indica que las responsabilidades varían entre SaaS, PaaS e IaaS, y recomienda empezar por ofertas SaaS como Copilot, pasar a servicios PaaS como Azure OpenAI Service solo cuando las capacidades estándar no encajen, y reservar la construcción de modelos propios para organizaciones con una gran experiencia. La página añade que la orientación es ilustrativa, se usa en un sentido de gobernanza y no modifica ningún acuerdo con Microsoft. [1]
Microsoft: la extensión a los agentes
Una segunda página de Microsoft trata los agentes, que distingue de un modelo sin más porque un agente actúa sin que una persona apruebe cada paso, planifica e itera, conserva memoria, tiene su propia identidad y puede combinarse con otros agentes. Añade tres capas: la orquestación del agente, las herramientas y acciones, y la memoria y el estado. En su matriz de responsabilidades, en el caso PaaS el cliente conserva las instrucciones y el alcance del agente, los permisos por herramienta y la aprobación humana de las acciones de alto impacto, mientras que el runtime y la plataforma de orquestación corresponden a Microsoft. [2]
La página enumera las responsabilidades que el cliente conserva siempre: los datos, la identidad y el mínimo privilegio, la autorización de acciones, la supervisión humana, y el uso aceptable y la gobernanza. También afirma que la autonomía nunca reduce la rendición de cuentas. [2]
Cloud Security Alliance: una propuesta de 2023
En una entrada de blog del 28 de julio de 2023, un fellow de la CSA propuso un modelo con tres partes: el proveedor del servicio de IA, el usuario del servicio de IA que construye una aplicación y la empresa o el usuario final de esa aplicación. Según la propuesta, un proveedor IaaS aporta la infraestructura y los modelos fundacionales, mientras que el usuario se ocupa del entrenamiento, la validación de datos, el filtrado de prompts y la seguridad de la aplicación; en el caso PaaS, el usuario aporta el contexto y la seguridad de la aplicación; en el caso SaaS, el usuario gestiona el grounding, el filtrado de prompts y la protección de la propiedad intelectual. La entrada lo presenta como una propuesta que separa obligaciones, no como un estándar. [3]
El derecho: la Ley de IA de la UE reparte obligaciones por función
La Ley de IA de la UE asigna obligaciones según la función. Según las preguntas frecuentes de las directrices de la Comisión Europea, el proveedor de un modelo de IA de uso general es la entidad que desarrolla el modelo, o encarga su desarrollo, y lo introduce en el mercado con su propio nombre. Las obligaciones del proveedor incluyen la documentación técnica, la documentación para los desarrolladores posteriores sobre capacidades y limitaciones, una política de cumplimiento de los derechos de autor y un resumen público del contenido de entrenamiento. Estas obligaciones se aplican desde el 2 de agosto de 2025. Los modelos que se presume que conllevan riesgo sistémico, con 10^25 operaciones de coma flotante o más de cómputo de entrenamiento, tienen obligaciones adicionales, entre ellas las pruebas adversarias y las salvaguardas de ciberseguridad. [4]
Las mismas preguntas frecuentes fijan el 2 de agosto de 2026 como la fecha a partir de la cual se aplica a estos proveedores el régimen sancionador, multas incluidas, y el 2 de agosto de 2027 como plazo para los modelos introducidos en el mercado antes del 2 de agosto de 2025. También indican que un desarrollador posterior que modifica un modelo solo se convierte en proveedor en circunstancias excepcionales, como usar más de un tercio del cómputo de entrenamiento original, de modo que la mayor parte del ajuste fino no traslada la función de proveedor. [4]
Los responsables del despliegue, es decir, las organizaciones que usan sistemas de IA, tienen un conjunto de obligaciones distinto. Un análisis de un bufete fechado el 24 de julio de 2026 enumera como obligaciones del responsable del despliegue, desde el 2 de agosto de 2026, la divulgación de las ultrasuplantaciones (deepfakes) y la información a las personas sobre el reconocimiento de emociones y la categorización biométrica. Para los sistemas de alto riesgo enumera una supervisión humana competente, la notificación a las personas de que se usa IA y la consulta a los trabajadores. [6] La página del calendario de la Comisión añade que los responsables del despliegue deben garantizar la supervisión humana y el seguimiento, y notificar los incidentes graves una vez que los sistemas están en el mercado. [5]
El aplazamiento del Digital Omnibus
Los plazos para el alto riesgo han cambiado. La página del calendario de la Comisión indica el 2 de diciembre de 2027 para los sistemas de alto riesgo en ámbitos sensibles como la biometría, el empleo y la aplicación de la ley, y el 2 de agosto de 2028 para los sistemas de alto riesgo integrados en productos regulados, y atribuye el cambio al Digital Omnibus sobre IA, que describe como en vigor desde julio de 2026. [5] El análisis de Norton Rose Fulbright recoge las mismas dos fechas y afirma que el Omnibus se ha publicado en el diario oficial de la UE. [6] Por tanto, dos fuentes independientes coinciden en que el aplazamiento se adoptó y no solo se propuso. Estas dos fechas no modifican las obligaciones de los proveedores de modelos de uso general ni las obligaciones de transparencia mencionadas.
Reparto del trabajo cuando un modelo se usa a través de una API
Para el caso PaaS, en el que una aplicación llama a un modelo alojado, las fuentes respaldan el reparto siguiente. Las filas de Microsoft siguen las capas de plataforma y aplicación descritas más arriba; las filas sobre pruebas de riesgos de frontera, documentación del sistema y canales de divulgación reflejan las obligaciones del proveedor en las directrices de la UE y las prácticas que publican los proveedores de modelos. La tabla es una síntesis de FireAI, no un texto de ninguna de las fuentes.
| Ámbito | Lado del proveedor | Tu lado |
|---|---|---|
| Comportamiento del modelo | Entrenamiento de seguridad y alineamiento del modelo | Prompt de sistema y salvaguardas de la aplicación |
| Pruebas de riesgos | Pruebas de riesgos de frontera del propio modelo | Pruebas de tu aplicación, incluidos sus prompts, datos y herramientas |
| Plataforma | Seguridad de la plataforma y filtros básicos de entrada y salida | Comprobaciones de seguridad de la aplicación sobre contenido, plugins y conectores |
| Documentación | System card y documentación para desarrolladores posteriores | Leerla y registrar qué modelo y qué versión has desplegado |
| Datos y herramientas | Nada más allá del contrato de la API | Datos de RAG, herramientas, agentes y sus permisos |
| Salidas | Devuelve texto generado | Tratamiento posterior de la salida: validación, escape, aprobación humana |
| Operaciones | Canal de divulgación de vulnerabilidades del modelo | Registro, monitorización y respuesta a incidentes de la aplicación |
| Personas | Condiciones de la política de uso | Tu propia política de uso y la formación de los usuarios |
Dos ámbitos son compartidos en sentido estricto. El primero es la inyección de prompts: el proveedor entrena el modelo para resistir instrucciones inyectadas, y el responsable del despliegue limita lo que una instrucción inyectada puede conseguir mediante los permisos de las herramientas y el acceso a los datos. La página de Microsoft sobre agentes describe el mismo reparto e indica a los clientes que traten como no fiables el contenido recuperado, las salidas de las herramientas y los mensajes de otros agentes, y que sometan a control las acciones de alto impacto. [2] El segundo es la privacidad de los datos: el proveedor fija las condiciones de conservación y entrenamiento, y el responsable del despliegue decide qué datos entran en un prompt o en un índice de recuperación.
Recomendaciones
- Identifica primero el tipo de despliegue (SaaS, PaaS o autoalojado) y anota qué filas del reparto anterior corresponden a la organización.
- Prueba directamente el lado del responsable del despliegue: el prompt de sistema, los datos de recuperación, los permisos de las herramientas y el tratamiento de la salida. Las pruebas del proveedor sobre el modelo no los cubren.
- Antes de adoptar un modelo, lee la system card del proveedor y sus condiciones de conservación de datos y de entrenamiento, y localiza su canal de divulgación de vulnerabilidades.
- Limita lo que puede hacer una instrucción inyectada: herramientas con el mínimo privilegio, acceso a datos acotado y aprobación humana para las acciones irreversibles.
- Decide qué datos pueden entrar en los prompts y conserva registros suficientes para reconstruir un incidente.
- Como material de aprendizaje sobre marcos y red teaming, consulta el curso de FireAI University sobre marcos de seguridad de IA y red teaming.
Relación con FireAI
Una app o un agente local que llama a la API de un modelo es una app del Mac, y sus destinos son visibles para FireAI. Actividad enumera qué apps se conectaron, y Reglas permite a un usuario permitir o bloquear una app o un destino concreto. Es un control en el lado del responsable del despliegue, en un único Mac. FireAI no inspecciona los prompts, no evalúa la salida del modelo, no detecta la inyección de prompts ni valora si un proveedor cumple alguna obligación legal.
Limitaciones
- Las páginas de Microsoft son orientaciones del proveedor para productos de Azure, se describen a sí mismas como ilustrativas y no modifican las condiciones contractuales. El texto de la CSA es una propuesta de 2023.
- Esta nota no constituye asesoramiento jurídico. Que una organización sea proveedor, responsable del despliegue u operador de alto riesgo según la Ley de IA de la UE depende de hechos que esta nota no evalúa, y las autoridades nacionales pueden interpretar la Ley de forma distinta.
- Las fechas del Digital Omnibus proceden de la página del calendario de la Comisión y de un análisis de un bufete. Para esta nota no se revisó el texto del propio reglamento.
- La tabla de la API es una síntesis, y algunos proveedores sitúan ciertas filas de otra manera en sus condiciones.
El papel de FireAI y de HisnLabs
Tu lado de la línea incluye lo que sale del Mac. FireAI lo muestra y te deja decidir.
FireAI es el propio producto de HisnLabs: un cortafuegos con IA integrada para Mac. Muestra, en lenguaje claro, cada conexión que hacen tus aplicaciones y te deja decidir qué sale de tu Mac; su IA funciona en el propio equipo, así que tu tráfico nunca se envía a HisnLabs ni a nadie más. El equipo de investigación en seguridad de HisnLabs es quien mantiene esas decisiones fiables: cataloga qué dominios son simple telemetría frente a un servicio real, sigue el país y la red detrás de una conexión, y entrena el modelo local (la función FireAI Pilot) con tráfico real, sin que nada salga de tu Mac.
Puedes leer las decisiones técnicas detrás de esto, o probar FireAI durante 17 días, en FireAI, de HisnLabs.