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 implementa, con vocabularios distintos y un peso jurídico distinto. Esta nota compara los tres enfoques y propone una división práctica para el caso común de un modelo consumido a través de una API. Complementa Cómo hace Anthropic red teaming a Claude, y lo que te deja a ti, que examina el lado del proveedor en un caso publicado.
Antecedentes: el modelo de la nube, extendido 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 el vocabulario más 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 mediante API e incluye un sistema de seguridad que filtra entradas y salidas dañinas. La capa de aplicación es la interfaz que usa el usuario, con grounding, plugins y conectores de datos, y necesita su propio sistema de seguridad de aplicación. La capa de uso abarca la forma en que las personas aprovechan la capacidad, y Microsoft remite a los controles de identidad y acceso, a las políticas de uso aceptable y a la capacitación de los usuarios. [1]
La parte de cada capa que corresponde al cliente depende del tipo de implementación. La página indica que las responsabilidades varían entre SaaS, PaaS e IaaS, y recomienda empezar con ofertas SaaS como Copilot, pasar a servicios PaaS como Azure OpenAI Service solo cuando las capacidades listas para usar no sean suficientes, y reservar la creación de modelos personalizados a organizaciones con experiencia profunda. La página agrega 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 de los agentes, que distingue de un modelo simple 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. Agrega 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 del orquestador 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 las 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 fechada el 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 suministra la infraestructura y los modelos fundacionales, mientras que el usuario se encarga 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 administra el grounding, el filtrado de prompts y la protección de la propiedad intelectual. La entrada lo presenta como una propuesta que separa funciones, no como un estándar. [3]
Derecho: la Ley de IA de la UE reparte obligaciones por rol
La Ley de IA de la UE asigna deberes según el rol. De acuerdo con 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 lo manda desarrollar, y lo introduce en el mercado con su propio nombre. Las obligaciones del proveedor incluyen documentación técnica, 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 un cómputo de entrenamiento igual o superior a 10^25 operaciones de coma flotante, tienen deberes adicionales, entre ellos pruebas adversariales y 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 la supervisión del cumplimiento, incluidas las multas, a estos proveedores, 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 se convierte en proveedor solo en circunstancias excepcionales, como usar más de un tercio del cómputo de entrenamiento original, de modo que la mayor parte del fine-tuning no traslada el rol de proveedor. [4]
Los responsables del despliegue, es decir, las organizaciones que usan sistemas de IA, tienen un conjunto de deberes distinto. Un análisis de un despacho de abogados fechado el 24 de julio de 2026 enumera como deberes de los responsables del despliegue, a partir del 2 de agosto de 2026, la divulgación de deepfakes y el aviso 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 agrega que los responsables del despliegue deben garantizar la supervisión humana y el monitoreo, y reportar los incidentes graves una vez que los sistemas están en el mercado. [5]
El aplazamiento del Digital Omnibus
Los plazos para alto riesgo se movieron. 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 lo atribuye al Digital Omnibus sobre IA, que describe como en vigor desde julio de 2026. [5] El análisis de Norton Rose Fulbright reporta las mismas dos fechas e indica que el Omnibus se publicó en el diario oficial de la UE. [6] Por lo tanto, dos fuentes independientes coinciden en que el aplazamiento se adoptó y no solo se propuso. Estas dos fechas no modifican los deberes de los proveedores de modelos de uso general ni los deberes de transparencia mencionados arriba.
Cómo repartir el 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 la siguiente división. Las filas de Microsoft siguen las capas de plataforma y de aplicación descritas arriba; las filas sobre pruebas de riesgos de frontera, documentación del sistema y canales de divulgación reflejan los deberes 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.
| Área | Lado del proveedor | Tu lado |
|---|---|---|
| Comportamiento del modelo | Entrenamiento de seguridad y alineación del modelo | Prompt del sistema y salvaguardas de la aplicación |
| Pruebas de riesgo | 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 | Controles de seguridad de la aplicación sobre contenido, plugins y conectores |
| Documentación | System card y documentación para los desarrolladores posteriores | Leerla, y registrar qué modelo y qué versión implementaste |
| Datos y herramientas | Nada más allá del contrato de la API | Datos de RAG, herramientas, agentes y sus permisos |
| Salidas | Devuelve el texto generado | Manejo de la salida en las etapas siguientes: validación, escape, aprobación humana |
| Operaciones | Canal de divulgación de vulnerabilidades del modelo | Registros, monitoreo y respuesta a incidentes de la aplicación |
| Personas | Términos de la política de uso | Tu propia política de uso y la capacitación de los usuarios |
Dos áreas son compartidas en sentido estricto. La primera 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 lograr mediante los permisos de las herramientas y el acceso a los datos. La página de agentes de Microsoft describe la misma división, e indica a los clientes que traten como no confiables el contenido recuperado, las salidas de las herramientas y los mensajes de otros agentes, y que condicionen las acciones de alto impacto. [2] La segunda es la privacidad de los datos: el proveedor fija los términos de retención y de entrenamiento, y el responsable del despliegue decide, en primer lugar, qué datos entran en un prompt o en un índice de recuperación.
Recomendaciones
- Identifica primero el tipo de implementación (SaaS, PaaS o autoalojado) y anota qué filas de la división anterior le corresponden a la organización.
- Prueba directamente el lado del responsable del despliegue: el prompt del sistema, los datos de recuperación, los permisos de las herramientas y el manejo de las salidas. Las pruebas que el proveedor hace al modelo no los cubren.
- Antes de adoptar un modelo, lee la system card del proveedor y sus términos de retenció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 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.
- Para material de aprendizaje sobre marcos y red teaming, consulta el curso de FireAI University sobre marcos de seguridad de IA y red teaming.
Relevancia para FireAI
Una app o un agente local que llama a la API de un modelo es una app de la Mac, y sus destinos son visibles para FireAI. Actividad muestra qué apps se conectaron a internet, y las Reglas permiten a un usuario permitir o bloquear una app o un destino específico. Es un control del lado del responsable del despliegue, en una sola Mac. FireAI no inspecciona los prompts, no evalúa las salidas del modelo, no detecta la inyección de prompts ni determina si un proveedor cumple alguna obligación legal.
Limitaciones
- Las páginas de Microsoft son orientación del proveedor para productos de Azure, se describen a sí mismas como ilustrativas y no cambian los términos contractuales. El texto de la CSA es una propuesta de 2023.
- Esta nota no constituye asesoría legal. 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 manera distinta.
- Las fechas del Digital Omnibus provienen de la página del calendario de la Comisión y de un análisis de un despacho de abogados. Para esta nota no se revisó el texto del reglamento.
- La tabla de la API es una síntesis, y cada proveedor ubica algunas filas de forma distinta en sus términos.
Dónde entran FireAI y HisnLabs
Tu lado de la línea incluye lo que sale de la Mac. FireAI lo muestra y te deja decidir.
FireAI es el producto de HisnLabs: un firewall con IA que corre directamente en tu Mac. Te muestra, en lenguaje claro, cada conexión que hacen tus aplicaciones y te deja decidir qué sale de tu Mac; su IA funciona de manera local, así que tu tráfico nunca se envía a nosotros ni a nadie más. El equipo de investigación en seguridad de HisnLabs es el que mantiene esas decisiones confiables: cataloga qué dominios son simple telemetría y cuáles un servicio real, rastrea el país y la red detrás de cada conexión, y entrena el modelo local (la función FireAI Pilot) con patrones de tráfico reales, sin que nada de eso salga de tu Mac.
Puedes leer las decisiones técnicas detrás de FireAI, o probarlo durante 17 días, en FireAI, de HisnLabs.