Por qué la confianza y la soberanía de la IA son ya decisiones de producto

Durante años, la confianza en la IA fue una diapositiva en la presentación. Un párrafo en la web. Un logo en el pie de página cuando por fin llegó la auditoría SOC 2. Compras preguntaba por disponibilidad y ubicación del almacenamiento, y la IA era un detalle de implementación sobre el que nadie tenía preguntas.

Esa fase terminó. Las preguntas que ahora aterrizan en el escritorio de cada proveedor de IA B2B son específicas, técnicas y cada vez más obligatorias. Qué modelos. Entrenados con qué. Alojados dónde. Auditados por quién. Responsabilidad nombrada de quién. La mayoría de los proveedores no tiene respuesta porque trataron esto como comunicación, y la comunicación no responde preguntas técnicas.

Este texto es un argumento para tratar la confianza, la soberanía y la ética de la IA como decisiones de producto. Cosas que se integran en el sistema, no cosas que se escriben alrededor de él. Usaré el trust stack que hemos lanzado recientemente en corial.app, uno de nuestros productos de portfolio, como ejemplo práctico. La cuestión no es qué hizo corial. La cuestión es por qué hay que hacerlo y qué significa realmente hacerlo.

Qué significa "confianza en la IA" hoy, en concreto

Hasta hace poco, "confianza en la IA" era lo bastante vago como para no ser refutable. Una página decía que el proveedor se comprometía con una IA responsable. No había nada en la página que se pudiera comprobar.

Eso cambió porque cambió el lector. El lector de las páginas de confianza de un proveedor de IA hoy es un contacto de compras del lado del comprador al que le han pedido completar una evaluación de riesgo de proveedor específicamente para herramientas de IA. Lee buscando compromisos concretos.

En concreto, "confianza en la IA" significa hoy cinco cosas.

Política de datos de entrenamiento. Con qué se entrenó el modelo. Qué queda excluido. Qué hace el uso posterior del proveedor con esos datos. Si los prompts del cliente se usan para entrenamiento, en cualquier momento, en cualquier parte de la pipeline.

Región de inferencia. Dónde corre físicamente el modelo. Qué país, qué proveedor, bajo qué marco contractual. Cláusulas Contractuales Tipo, decisión de adecuación o exclusivamente en la región.

Derechos de auditoría. Evaluaciones independientes de terceros. Stanford Foundation Model Transparency Index 2025 para la documentación del modelo. MLCommons AILuminate v1.0 para seguridad. La auditoría no tiene que ser favorecedora. Tiene que existir y estar citada.

Divulgación de subprocesadores. La lista de cada proveedor posterior que toque datos del cliente. Cambios notificados con 30 días de antelación. Trabajo estándar del artículo 28 del RGPD, ahora aplicado a los proveedores de modelos.

Responsabilidad nombrada. Quién firma la carta. Quién responde si se incumple. En etapas pequeñas de empresa, la firma del fundador es la señal más fuerte. En etapas mayores, un comité con nombres concretos.

Un proveedor que puede responder esas cinco preguntas por escrito es un proveedor con el que compras puede firmar. Uno que no puede es uno con el que no se firma, por bueno que sea el producto.

Por qué la soberanía es un trade-off, no una marca

La soberanía europea es la pregunta con los bordes más afilados en este terreno, porque la mayoría de las respuestas de los proveedores no son honestas.

La primera respuesta deshonesta es "somos soberanos UE". Suele querer decir que el proveedor ha decidido correr solo sobre proveedores de modelos exclusivamente europeos. El trade-off que no menciona es que eso le deja fuera de los modelos frontera de EE. UU. Mistral, la opción totalmente europea más sólida, obtuvo 15/100 en el Stanford Foundation Model Transparency Index 2025. La brecha de capacidades no es un error de redondeo. Es real, medible y problema del cliente si el proveedor finge lo contrario.

La segunda respuesta deshonesta es "por defecto vamos a nubes de EE. UU. y nuestro DPA lo cubre". Es cierto hasta que un equipo de compras con una evaluación de riesgo de IA real pregunta en qué región corre físicamente la inferencia. Las Cláusulas Contractuales Tipo son base legal para la transferencia. No son sustituto de una respuesta regional.

Existe un tercer camino, el que hemos construido en corial. La residencia UE se ofrece como tier por inquilino. El enrutamiento por defecto va por EE. UU. bajo CCT. El tier UE es opcional, con un sobrecoste de alrededor del diez por ciento repercutido al coste, y enruta el cien por cien de las llamadas de IA a través de Google Cloud Vertex AI EU. Bélgica, Países Bajos, Fráncfort, París, Madrid, Finlandia según el modelo. Claude servido en Vertex AI EU bajo licencia. Gemini directamente en Vertex AI EU. Mismos nombres de modelo, mismas capacidades, ninguna excepción.

El mecanismo es a propósito poco vistoso. Un booleano en el registro del inquilino. El admin pega las credenciales de Google Cloud una vez y marca una casilla por cliente. Sin despliegue de código, sin reinicio.

La decisión interesante no es la ingeniería. Es la negativa a decidir por el cliente. Un proveedor soberanía-como-marca decide de antemano que el cliente prefiere inferencia UE incluso a costa de capacidades. Un proveedor por-defecto-EE.UU. decide de antemano que al cliente le da igual. Ambas son paternalistas. El movimiento honesto es exponer el trade-off y dejar que el cliente elija.

La Ley de IA de la UE, ya en vigor, hace esta conversación más difícil de evitar. La mayoría de las herramientas de IA B2B, incluida corial, caen en la categoría de riesgo limitado. Riesgo limitado no significa sin obligaciones. Significa obligaciones de transparencia, documentación del lado del proveedor y un rastro de papel claro del comportamiento del modelo. Un trust stack es la forma práctica de ese rastro.

La argumentación completa está en corial.app/blog/eu-residency-as-a-tier-not-a-brand. La versión de arriba es la versión corta.

Por qué la ética de la IA importa en B2B, en la forma en que la lee compras

Hay ya mil ensayos sobre ética de la IA. La mayoría dirigidos a investigadores de política pública y comités de ética. Están bien escritos, a menudo por gente que conoce el tema mucho mejor que yo, y no causan impacto en una decisión de compra B2B.

La versión que causa impacto es más corta y se lee distinto. En B2B, la ética de la IA es riesgo de proveedor.

Un modelo que alucina escribiendo un email a un cliente es un pasivo comercial. Un modelo entrenado con datos cuestionables es un pasivo legal. Un algoritmo de ranking sesgado en una herramienta de ventas B2B es un pasivo reputacional. Los equipos de compras empiezan a ponerle precio del mismo modo que siempre han puesto precio a las prácticas laborales, el cumplimiento medioambiental y la divulgación de subproveedores para bienes físicos.

Por eso el encuadre más útil que he encontrado para la sección de ética de un trust stack no es filosófico. Es el formato de la Responsible Procurement Charter que los grandes grupos cosméticos con los que trabajé durante quince años llevan enviando a sus proveedores desde principios de los 2000.

La carta de proveedor es una forma conocida. L'Oréal, Unilever, Henkel la envían. Cubre prácticas laborales, origen geográfico, derechos de auditoría, divulgación de subproveedores, una auditoría social anual y un firmante nombrado en el proveedor. Compras la lee rápido porque el formato es fijo y los verbos son duros.

Ese formato se traslada a la IA casi línea por línea. Prácticas laborales pasan a ser política de datos de entrenamiento. Origen geográfico pasa a ser región de inferencia. Derechos de auditoría pasan a ser evaluaciones independientes de terceros. Divulgación de subproveedores pasa a ser lista de subprocesadores. La auditoría social anual pasa a ser refirma anual de la carta más revisión trimestral de la ficha del modelo. El firmante nombrado pasa a ser firmado por el fundador.

Los verbos son lo que más cuenta. Compras lee "no hará". No lee "aspira a". Una carta que dice "el proveedor no entrenará con datos del cliente" es un compromiso duro. Una carta que dice "el proveedor aspira a minimizar el uso de datos del cliente para entrenamiento" es lenguaje de preferencia y no sobrevive a una revisión de proveedor.

La Responsible AI Charter de corial está escrita en ese formato. Cinco a siete líneas "no hará" en la sección de exclusiones. Firmada por el fundador. "Diseñada en alineación con ISO/IEC 42001:2023" en lugar de "certificada ISO 42001", porque la auditoría no ha ocurrido y mentir sobre ello haría más daño que la brecha. La argumentación completa está en corial.app/blog/responsible-procurement-charter-for-ai.

Qué contiene de verdad un trust stack

Seis piezas. La mayoría poco vistosas. Ninguna es difícil una vez aceptas que son producto, no comunicación.

1. Responsible AI Charter. Firmada por el fundador, revisión anual. Formato de carta de proveedor. Verbos duros en la sección de exclusiones.

2. Página de confianza. Una URL. Índice de todo lo de abajo. La página que le pasas a un contacto de compras.

3. Ficha del modelo de IA. Cada modelo de la capa de enrutamiento nombrado. Evaluaciones independientes de terceros donde existan. Incluidas las malas. Esconderlas es peor que nombrarlas.

4. Lista de subprocesadores y DPA. Base del artículo 28 del RGPD. 30 días de aviso en cambios. Notificación de brecha del artículo 33 en 72 horas integrada.

5. Backbone de cumplimiento interno. No de cara al cliente. Documento de mapeo de controles, diagrama de arquitectura, nota de gobernanza documental, registro de auditoría. Es lo que ve el auditor.

6. Opción de enrutamiento regional. Si vendes en Europa y puedes soportar inferencia UE, ofrécela como tier opcional, no como marca. El cliente elige.

Esa es la forma de lo que entregamos en corial. La razón para escribirlo aquí: ninguna de estas piezas requiere una contratación de compliance ni una hoja de ruta de seis meses. El trabajo está en la disciplina. Escribir para el lector correcto. Mantener las partes poco favorecedoras. Negarse a los verbos que suavizan.

Por qué tratarlo como producto, no como comunicación

La versión-comunicación de la confianza en la IA es un párrafo en la página de about y un trust badge en el pie. Es barato y no hace nada.

La versión-producto es exigible internamente. La carta es algo contra lo que los ingenieros tienen que entregar. La ficha del modelo tiene que reflejar lo que realmente está este trimestre en la capa de enrutamiento. El tier de residencia es un booleano y una ruta de red real, no una diapositiva de ventas. La lista de subprocesadores se actualiza cuando cambia un proveedor, no cuando marketing se acuerda.

El cambio de comunicación a producto es también el cambio de "creemos en" a "no haremos". La creencia no es refutable. Un compromiso sí es comprobable. Compras solo compra lo segundo.

La otra razón por la que esto es producto y no comunicación: el régimen de la Ley de IA de la UE está ya vivo. Incluso las herramientas de IA B2B de riesgo limitado tienen obligaciones de transparencia. El rastro de papel tiene que existir. Si no lo has construido, el regulador lo nota, y cada vez más también el comprador.

Para nosotros en concreto, esto es también un movimiento de estudio. opencream lanza productos de portfolio, y corial es uno de ellos. El formato del trust stack se traslada al resto del portfolio. PlanPlate, Axiomly, TraXAgent recibirán las mismas seis piezas en el trimestre que viene. La forma de los artefactos es reutilizable. Los estándares no son negociables.

Si eres fundador de SaaS B2B leyendo esto y no tienes la mayoría de las seis piezas anteriores en una forma de cara al cliente, la brecha se cierra más rápido que el calendario que estás planeando. A los equipos de compras les han dicho que comprueben, y están comprobando.

Qué hacer ahora

Si eres fundador de SaaS B2B, el paso práctico es escribir una Responsible AI Charter este trimestre. Cinco a siete líneas "no hará", firmada por el fundador, revisión anual. A partir de ahí, la ficha del modelo, la lista de subprocesadores y la página de confianza salen solas. El tier de residencia es ingeniería, no papeleo, y merece la pena en cuanto vendas a Europa.

Si eres comprador leyendo páginas de confianza de proveedores, las preguntas que hay que hacer son las cinco de arriba. Política de datos de entrenamiento. Región de inferencia. Evaluaciones de auditoría independientes. Lista de subprocesadores. Firmante nombrado. Los proveedores que las contestan con claridad son proveedores con los que puedes firmar. Los que no, diga lo que diga el marketing, son un incidente futuro que solo espera ocurrir.

Esto ya no es infraestructura opcional. El comprador cambió. El regulador llegó. Los proveedores que traten la confianza en la IA como una decisión de producto cerrarán los contratos que pierdan los proveedores que la traten como comunicación.