¿Es fiable el proveedor de IA que estás a punto de adoptar? SOC 2, ISO 42001 y qué preguntar antes de firmar

Cuando una pyme adopta la IA, casi nunca construye el modelo: adopta una herramienta — un copiloto para las ventas, una plataforma de agentes para la atención, un generador de contenidos. Y esa herramienta, en la gran mayoría de los casos, es un SaaS de terceros, a menudo estadounidense. Antes de firmar, la pregunta que hay que hacerse es una: «¿puedo fiarme de este proveedor?». La respuesta que te llegará, casi siempre, es la misma: «estamos certificados SOC 2 Type II». Suena tranquilizador. ¿Pero cierra de verdad la cuestión?

La respuesta honesta es no — no por sí sola. La SOC 2 dice algo útil, pero dice mucho menos de lo que la palabra «certificados» deja entender, y sobre todo lo que atañe específicamente a la IA dice casi nada. Vale la pena entenderlo antes de confiar a un proveedor un trozo de tu proceso — y tus datos.

Qué es de verdad la SOC 2 (y qué no es)

Primer equívoco que deshacer: la SOC 2 no es una ley. Es un atestado emitido por un auditor independiente según un esquema de la AICPA (el colegio de contadores estadounidenses), que mide los controles de un proveedor respecto a cinco Trust Services Criteria: seguridad (siempre dentro del perímetro), disponibilidad, integridad del procesamiento, confidencialidad y privacidad. Es una buena señal de higiene de seguridad, no un sello de conformidad europea.

Segundo punto, el que separa una señal verdadera de una de fachada: la SOC 2 existe en dos tipos, y la diferencia lo es todo.

• Type I — atestigua que los controles existen en un instante dado. Es una foto: el día de la auditoría estaban. Por sí sola, es una señal débil.
• Type II — atestigua que esos controles han funcionado de verdad a lo largo de una ventana de seis a doce meses. Es la película, no la foto: es el único de los dos que dice algo significativo sobre cómo trabaja el proveedor con el tiempo.

Si un proveedor te dice «tenemos la SOC 2» sin especificar, la primera pregunta es: ¿Type I o Type II?. Un Type I ondeado como garantía es, a menudo, un atajo de marketing. Exige el Type II — y el informe, no solo el atestado.

Las preguntas que hacer antes de firmar

Un informe SOC 2 no se «tiene» o «no se tiene»: se lee. Y la parte que cuenta para ti — la IA — está casi siempre escondida en los detalles del scope. Antes de firmar, estos son los controles que el proveedor debe superar, no la palabra «certificados»:

Las tres cosas que la SOC 2 no te dirá nunca

Aquí está el límite que ninguna cantidad de «Type II» colma. La SOC 2 nació para la seguridad y la fiabilidad de la infraestructura: servidores, accesos, continuidad. No se pensó para la IA, y de hecho en julio de 2026 la AICPA no ha publicado ningún criterio SOC 2 específico para la inteligencia artificial: los auditores aplican los criterios genéricos de 2017 usando el habitual juicio de seguridad informática (Schellman). Traducido: por impecable que sea el informe, hay cosas sobre la IA que no te dirá nunca.

• El sesgo del modelo — si las respuestas discriminan, la SOC 2 no lo mide.
• La explicabilidad — por qué el modelo ha decidido así, queda fuera del perímetro.
• El riesgo de alucinación y la integridad informativa — que el modelo invente con aplomo no es un control que una auditoría de seguridad intercepte.

«SOC 2 Type II compliant» no es una prueba de seguridad de la IA ni de madurez de gobernanza: eso es otro terreno completamente distinto. Confundir las dos cosas es el error más caro de esta fase — porque te hace sentir cubierto justo donde no lo estás.

El estándar correcto que pedir es otro: ISO/IEC 42001

Si la pregunta es «¿este proveedor gobierna la IA de forma madura?», el estándar que nombrar no es la SOC 2, sino la ISO/IEC 42001:2023, publicada en diciembre de 2023: el primer estándar certificable para un sistema de gestión de la IA. Donde la SOC 2 mira la infraestructura, la ISO 42001 mira la IA en cuanto tal — política de la IA y responsabilidad en manos de la dirección, un inventario de los sistemas de IA con clasificación del riesgo, evaluaciones de impacto, gobernanza de los datos de entrenamiento, controles sobre todo el ciclo de vida del modelo, gestión del sesgo y de las no conformidades.

La manera correcta de tenerlas juntas es pensarlas como dos capas distintas, no como alternativas (BARR Advisory): la SOC 2 es el suelo de la seguridad, la ISO 42001 es la planta de la gobernanza de la IA por encima. La mejor práctica es tener ambas; si un proveedor te muestra solo la SOC 2 y habla de «IA responsable», la pregunta siguiente es natural: ¿y en la ISO 42001 en qué punto estáis?.

Ojo con los atajos: la «SOC for AI»

En la red circula la idea de una «SOC for AI», un supuesto esquema específico para la IA. Vale la pena saberlo para no caer en ello: no consta publicada por la AICPA — su página oficial sobre los servicios SOC no la enumera, y las fuentes que hablan de ella remiten a contenidos sin autor y sin enlace a una fuente primaria. Trátala como un rumor no confirmado, no como un requisito que exigir ni del que presumir. En esta área, donde las reglas todavía se están formando, la prudencia es pedir los estándares que existen de verdad — no los del nombre más tranquilizador.

En España la SOC 2 no sustituye nada

Un punto que demasiadas presentaciones comerciales dejan en la vaguedad: en España y en Europa la SOC 2 no tiene fuerza de ley. No es un requisito europeo y no sustituye nada de lo que te piden el RGPD y el EU AI Act (Comp AI). Un proveedor con una SOC 2 excelente puede aun así no bastar, si tu uso de esa herramienta requiere una evaluación de impacto relativa a la protección de datos.

¿Dónde cuenta de verdad, entonces? Como un input, uno entre muchos, en el paso de evaluación del riesgo-proveedor de tu EIPD: cuando la herramienta es un SaaS estadounidense, la SOC 2 es una evidencia útil sobre la seguridad del tratamiento (en la lógica del artículo 32 del RGPD). Pero queda subordinada al análisis RGPD y AI Act, no lo reemplaza. Es exactamente la posición que le damos en nuestro overlay de cumplimiento: la diligencia sobre el proveedor es una pieza del bloque de gobernanza que acompaña a cada caso de uso, nunca un sustituto del análisis que cuenta.

Qué hacer ahora, en la práctica

No hace falta convertirse en auditor. Para una pyme que está eligiendo una herramienta de IA, la diligencia razonable es corta y concreta:

• Exige el Type II, y el informe. Un atestado Type I ondeado como garantía es una señal débil; pide el informe Type II y léelo, no te quedes en la declaración.
• Verifica que el scope nombre la IA. Si el perímetro habla solo de la «Plataforma» y no de las funciones de IA/agentes, el informe no cubre justamente la parte que te interesa.
• Pide la lista de los subproveedores y el destino de tus datos. Qué proveedor de modelo hay detrás, si tus datos alimentan el entrenamiento, y con qué garantías — puesto por escrito en el contrato.
• Pide la ISO 42001, no solo la SOC 2. Si el proveedor vende «IA responsable», el estándar que lo demuestra es ese — o al menos un camino hacia él.
• Haz que todo confluya en la EIPD, donde la SOC 2 vale como uno de los elementos de seguridad del tratamiento, no como el veredicto final.

Antes incluso de evaluar a un proveedor concreto, conviene saber qué proceso quieres automatizar y con qué controles alrededor: es de ahí de donde desciende qué pedir al proveedor. Nuestra evaluación de AI-readiness ayuda a poner en orden los procesos correctos y los controles que exigir; si estás justamente eligiendo entre hacerlo en casa y comprar, el artículo sobre comprar o construir encuadra la decisión aguas arriba, y los controles que hacen defendible un caso de uso completan el cuadro aguas abajo.

Hemos convertido el primer paso en una evaluación autoservicio y gratuita: unas pocas preguntas y una indicación sobre por dónde empezar, con qué controles — y qué preguntas al proveedor — alrededor del primer flujo. Haz la evaluación de AI-readiness — luego, si tiene sentido, hablamos.

Este artículo tiene fines puramente orientativos y no constituye asesoramiento legal ni una evaluación de conformidad. La SOC 2 es un atestado de la AICPA (no una ley europea) sobre los Trust Services Criteria de 2017; la distinción Type I / Type II, la ausencia — en julio de 2026 — de criterios SOC 2 específicos para la IA por parte de la AICPA, y el papel de la ISO/IEC 42001:2023 como estándar certificable de gestión de la IA reflejan fuentes del sector actualizadas a esa fecha y deben reverificarse sobre el texto vigente. Para las obligaciones concretas de tu empresa remítete al RGPD, al texto del EU AI Act, a las indicaciones de la autoridad de control competente y a un apoyo legal cualificado.