Salesforce y Anthropic anunciaron el 26 de agosto de 2026 Claudeforce, una alianza que lleva el razonamiento de Claude directamente al ecosistema Salesforce. Su primera materialización es Salesforce in Claude, un plugin con 37 habilidades comerciales preconfiguradas que permite trabajar desde Claude con cuentas, oportunidades, pipeline, actividades y otros datos empresariales sin necesidad de navegar continuamente por el CRM. Salesforce lo presenta como una nueva forma de combinar sus datos, flujos de trabajo, lógica de negocio y mecanismos de gobernanza con las capacidades de razonamiento de Claude.

Tecnológicamente, la propuesta es muy potente. Un comercial podría pedir a Claude que prepare una reunión, revise el estado de una oportunidad, detecte posibles riesgos de cierre o actualice determinados registros utilizando lenguaje natural. La diferencia frente al chatbot tradicional es importante: ya no hablamos únicamente de una inteligencia artificial a la que una persona copia información, sino de un agente que puede solicitar directamente al sistema empresarial los datos que necesita y, dependiendo de su configuración, realizar acciones sobre ellos.

Precisamente por eso Claudeforce plantea cuestiones importantes sobre RGPD, AI Act, minimización de datos y gobernanza de agentes. El hecho de que Salesforce controle técnicamente qué puede consultar Claude no significa automáticamente que cualquier tratamiento realizado con esos datos sea legítimo. Cuando conectamos un agente de IA con un CRM, aparecen dos capas diferentes que no deberíamos confundir: los permisos tecnológicos y las obligaciones legales relacionadas con el tratamiento de los datos.

¿Qué es Claudeforce y qué cambia respecto a usar Claude como chatbot?

Hasta ahora, una de las principales recomendaciones al introducir IA generativa en una empresa era vigilar qué información introducían los empleados en el prompt. Con Claudeforce ese modelo cambia porque Salesforce puede convertirse directamente en una fuente de contexto para Claude. La propia documentación de Salesforce explica que sus servidores MCP permiten exponer objetos, registros, consultas y determinadas acciones de Salesforce a clientes compatibles como Claude.

Esto significa que el usuario ya no necesita copiar manualmente una ficha de cliente para que la IA pueda trabajar con ella. Claude puede solicitarla a Salesforce a través de las herramientas que el administrador haya habilitado. Es una diferencia esencial, porque el control ya no depende únicamente del comportamiento del trabajador: depende también de cómo se haya diseñado la arquitectura, qué herramientas se hayan puesto a disposición del agente y qué información puede devolver cada una de ellas.

Salesforce ofrece distintos niveles de acceso mediante MCP. SObject Reads, por ejemplo, está orientado a lectura y consulta; mientras, SObject All permite crear, leer, actualizar, eliminar, consultar y recorrer relaciones entre los objetos de Salesforce. Todas estas operaciones siguen sujetas a los permisos del usuario autenticado, incluyendo seguridad a nivel de campo, permisos sobre objetos y reglas de compartición.

Esta arquitectura está bastante más cuidada que una simple conexión de un modelo lingüístico a una API, pero también crea una cuestión fundamental: que Claude pueda consultar legalmente un sistema desde el punto de vista técnico no significa que deba recibir todos los datos a los que ese usuario tiene acceso.

Un caso práctico: preparar una reunión comercial con Claude

Imaginemos que un comercial tiene dentro de una hora una reunión con uno de sus clientes. En lugar de entrar en Salesforce y recorrer manualmente la cuenta, las oportunidades abiertas, las últimas actividades y las incidencias registradas, podría pedir a Claude que prepare un resumen de la situación comercial y detecte los temas que debería abordar durante la reunión.

Salesforce ya documenta precisamente un ejemplo de este tipo mediante sus plantillas de prompts para MCP. Una de ellas genera un briefing ejecutivo de una cuenta utilizando oportunidades recientes, casos y otra información relacionada. Es un caso de uso muy razonable: la IA reduce el tiempo empleado en recopilar información dispersa y permite que el profesional dedique más tiempo a interpretar esa información y relacionarse con el cliente.

El problema aparece cuando pasamos de preguntarnos qué puede hacer Claude a preguntarnos qué datos necesita realmente para hacerlo. Para preparar esa reunión puede resultar necesario conocer el nombre del contacto, su cargo, las oportunidades relacionadas con su empresa o determinadas conversaciones anteriores. Probablemente no sea necesario proporcionar al modelo decenas de miles de contactos de otros clientes, información financiera que no guarda relación con la reunión o campos personales que no aportan nada a esa finalidad.

Éste es el punto en el que la productividad deja de ser únicamente una cuestión tecnológica y entra de lleno la protección de datos.

Los permisos de Salesforce no sustituyen a la legitimación del tratamiento

Uno de los argumentos centrales de Claudeforce es que Claude trabaja utilizando los permisos y reglas de negocio ya existentes en Salesforce. La web oficial lo explica claramente: Claude puede ver aquello que el usuario está autorizado a ver y puede realizar las acciones que ese usuario está autorizado a ejecutar. Salesforce presenta esto como una ventaja porque evita construir desde cero otro modelo de permisos específico para la IA.

Desde el punto de vista de identidad, autenticación y control de acceso tiene sentido. Sin embargo, los permisos de un CRM y la legitimación prevista por el RGPD responden a preguntas diferentes.

Un director comercial puede necesitar legítimamente acceso a 50.000 contactos porque es responsable de todo el departamento. Eso no significa que un agente de inteligencia artificial tenga que poder procesar automáticamente esos 50.000 contactos para resolver cualquier petición que formule ese director. El permiso de Salesforce responde a “¿puede este usuario consultar este registro?”, mientras que el RGPD obliga además a preguntarnos “¿para qué se van a tratar estos datos, con qué base jurídica y qué información es realmente necesaria para esa finalidad?”.

Por eso, no considero suficiente trasladar automáticamente todos los permisos humanos al agente. Un ser humano autorizado para consultar miles de registros no dispone de la misma capacidad para analizarlos, correlacionarlos y actuar sobre ellos que un sistema automatizado capaz de ejecutar consultas y operaciones en segundos. El mismo permiso puede generar un riesgo muy diferente cuando quien lo utiliza es un agente de IA.

RGPD y minimización: filtrar antes de que el dato llegue a Claude

El principio de minimización del RGPD adquiere aquí una importancia enorme. La AEPD recuerda que la protección de datos por defecto exige limitar el tratamiento a los datos personales que sean necesarios para las finalidades definidas, reduciendo tanto la cantidad de datos como la extensión del tratamiento, su accesibilidad y el tiempo durante el que se conservan.

Además, en julio de 2026 la Agencia publicó una nota técnica específicamente dedicada a analizar cómo deben aplicarse los principios de calidad, exactitud y minimización cuando se utilizan sistemas de inteligencia artificial. No se trata, por tanto, de trasladar mecánicamente los antiguos permisos del CRM a una nueva herramienta, sino de revisar qué tratamiento estamos construyendo realmente alrededor de esa IA.

Aquí aparece una regla de diseño que considero especialmente importante para cualquier integración de este tipo: los datos que Claude no necesita no deberían llegar a Claude. No basta con permitir que el agente acceda al CRM completo y añadir después una instrucción que le indique que ignore determinados registros. Si esos datos ya se han recuperado y proporcionado al modelo para su procesamiento, el tratamiento ya se ha producido.

La minimización debe aplicarse antes de esa recuperación. Salesforce permite limitar las operaciones mediante servidores MCP más restringidos y también expone Flows y APIs como herramientas MCP personalizadas, lo que permite construir accesos más acotados que un servidor genérico con capacidad sobre todos los objetos.

Una implementación correctamente diseñada podría hacer que Claude sólo tuviera disponible una herramienta específica para obtener la información necesaria para preparar una reunión, en lugar de proporcionar acceso genérico al conjunto de objetos de Salesforce. La diferencia no está sólo en la seguridad: es una aplicación directa del principio de privacidad desde el diseño.

¿Qué ocurre cuando unos registros pueden utilizarse y otros no?

Una base Salesforce puede contener información sometida a situaciones jurídicas diferentes. Puede haber tratamientos basados en la ejecución de un contrato, interés legítimo, consentimiento u otras bases jurídicas previstas por el RGPD. También puede haber personas que hayan ejercido determinados derechos, registros sometidos a restricciones específicas o información cuya utilización esté permitida para una finalidad pero no para otra.

Por eso sería demasiado simplista resolver el problema añadiendo al CRM un campo denominado “Autoriza IA: Sí/No”. El tratamiento mediante inteligencia artificial no constituye por sí mismo una única finalidad jurídica y el consentimiento tampoco es la única base posible. Lo importante es determinar si ese dato concreto puede utilizarse para esa finalidad concreta y limitar técnicamente el acceso del agente en consecuencia.

La base de datos no tiene por qué dividirse físicamente en dos. Lo que debería existir es una capa lógica que determine qué registros y campos puede recuperar el agente para cada operación. Si una información no debe intervenir en determinado tratamiento, la solución correcta es impedir que la herramienta utilizada por Claude pueda devolverla, no esperar que el modelo la reciba y posteriormente decida no utilizarla.

Esta distinción será especialmente importante en organizaciones que ya poseen grandes cantidades de datos acumulados durante años. Una cosa es que un registro exista legítimamente en Salesforce y otra que todas las nuevas herramientas conectadas al CRM puedan utilizarlo automáticamente para nuevas finalidades.

¿Hay que anonimizar los datos antes de enviarlos a Claude?

No necesariamente. La anonimización no es obligatoria en cualquier uso empresarial de inteligencia artificial. Si Claude tiene que preparar una reunión con una persona determinada, por ejemplo, saber quién es esa persona forma parte del propio objetivo de la tarea.

Sin embargo, cuando la identidad no sea necesaria, eliminar identificadores o reducir la información personal puede ser una medida de minimización muy relevante. Para analizar tendencias comerciales, tasas de abandono, duración de ciclos de venta o comportamiento agregado de determinados segmentos, no es necesario facilitar al modelo nombres completos, correos electrónicos, teléfonos o direcciones.

La pregunta adecuada vuelve a ser la misma: ¿necesita Claude este dato para conseguir el resultado que estamos buscando? Si la respuesta es no, existen buenos motivos técnicos y jurídicos para evitar que llegue al modelo.

Claudeforce y la transferencia de datos fuera de Europa

La residencia y el recorrido de los datos constituyen otra cuestión que una empresa europea debería revisar antes de desplegar Salesforce in Claude. Aquí conviene diferenciar claramente conceptos que suelen mezclarse en las comunicaciones comerciales.

Salesforce anuncia Zero Data Retention para Sonnet, Opus y Haiku dentro de Claudeforce. Sin embargo, en la misma página oficial explica que está trabajando con Anthropic en controles empresariales adicionales relacionados, entre otras cuestiones, con dónde se almacenan los datos y quién puede acceder a ellos.

Retención cero y residencia europea no significan lo mismo. Es posible que un dato sea procesado fuera del Espacio Económico Europeo y posteriormente eliminado sin que exista almacenamiento permanente en el sistema de inferencia. La ausencia de retención no elimina por sí misma la existencia de una transferencia internacional.

Anthropic informa actualmente de que, en sus productos comerciales, puede procesar datos mediante infraestructura situada en Estados Unidos, Europa, Asia y Australia y que, por defecto, el almacenamiento de datos permanece en Estados Unidos salvo que exista otro acuerdo.

Esto no permite afirmar automáticamente que Salesforce in Claude vaya a almacenar en Estados Unidos todos los datos recuperados desde Salesforce, porque una integración empresarial concreta puede estar sometida a arquitectura y condiciones contractuales específicas. Precisamente por eso, una organización europea debería solicitar la información correspondiente antes del despliegue y no extrapolar las garantías de un producto o arquitectura a otro diferente.

También es importante recordar que una transferencia de datos personales a Estados Unidos no es automáticamente ilegal. A fecha de publicación de este artículo, la Comisión Europea sigue reconociendo como adecuado a Estados Unidos para las organizaciones comerciales adheridas al EU-US Data Privacy Framework, además de existir otros mecanismos previstos por el RGPD cuando resulten aplicables.

La cuestión para una empresa no debería reducirse, por tanto, a preguntar dónde está alojada su instancia de Salesforce. Necesita conocer el flujo completo del dato: qué información sale del CRM, quién la recibe, dónde se procesa, qué se conserva, qué logs se generan, qué subencargados intervienen y qué mecanismo jurídico ampara cualquier transferencia internacional que se produzca.

¿Cumple Claudeforce el RGPD?

Preguntar si Claudeforce “cumple el RGPD” resulta demasiado genérico. Salesforce y Anthropic pueden proporcionar mecanismos técnicos, contratos, controles de seguridad, gestión de permisos y determinadas garantías para construir un tratamiento conforme. Pero no pueden decidir en nombre de la empresa para qué va a utilizar Claude sus datos, cuál es la base jurídica de cada tratamiento ni qué información es estrictamente necesaria.

La responsabilidad de la organización que despliega el sistema sigue existiendo. Una empresa puede utilizar una infraestructura técnicamente excelente, con cifrado, trazabilidad, controles de acceso y mecanismos legales de transferencia internacional, y aun así incumplir el RGPD si utiliza más información de la necesaria o desarrolla un tratamiento para una finalidad que no puede justificar.

Ésta es probablemente una de las ideas más importantes para entender la llegada de agentes empresariales como Claudeforce: cumplir el RGPD no es una característica que venga activada dentro de la licencia del software. Es el resultado de cómo se diseña, documenta y gobierna el tratamiento.

¿Y qué exige el AI Act a una integración como Claudeforce?

El AI Act introduce otra capa regulatoria, pero conviene no confundirla con el RGPD. Que Claude procese nombres, correos electrónicos o información comercial no convierte automáticamente a Claudeforce en un sistema de IA de alto riesgo. La clasificación depende en gran medida del uso concreto que la organización haga del sistema.

No es lo mismo utilizar Claude para resumir una oportunidad comercial que emplearlo para evaluar empleados, seleccionar candidatos o realizar otras actividades incluidas entre determinados usos de alto riesgo. Según el calendario vigente tras la reforma del AI Act de julio de 2026, las obligaciones correspondientes a los sistemas de alto riesgo incluidos en el Anexo III se aplicarán desde el 2 de diciembre de 2027. El AI Act, sin embargo, ya es aplicable en términos generales desde el 2 de agosto de 2026 y existen otras obligaciones que ya han entrado en vigor, entre ellas las relacionadas con alfabetización en IA y determinados requisitos de transparencia.

La Comisión recuerda, además, que los sistemas destinados a interactuar directamente con personas físicas están sometidos en determinados casos a obligaciones de transparencia para que la persona conozca que está interactuando con una IA. Por tanto, la clasificación y obligaciones de Claudeforce no pueden determinarse simplemente mirando el nombre del producto: hay que analizar cada caso de uso que la organización construya sobre él.

La AEPD también publicó en febrero de 2026 orientaciones específicas sobre inteligencia artificial agéntica desde la perspectiva de protección de datos. Su publicación resulta especialmente relevante para sistemas como Claudeforce porque aborda precisamente el aumento del riesgo que aparece cuando una IA deja de limitarse a responder y adquiere capacidad para consultar información de su entorno y ejecutar acciones de forma autónoma.

El gran problema: un agente no debería heredar automáticamente todo el poder de un humano

Salesforce presenta como ventaja que Claude pueda trabajar directamente con el sistema de permisos existente. Desde el punto de vista de despliegue y experiencia de usuario es comprensible: reduce muchísimo la complejidad inicial.

Sin embargo, creo que precisamente aquí existe uno de los debates más interesantes que abre Claudeforce. Los permisos empresariales se diseñaron históricamente pensando en personas y aplicaciones deterministas, no necesariamente en agentes capaces de consultar, interpretar, correlacionar y modificar grandes cantidades de información mediante lenguaje natural.

Un director comercial autorizado a consultar 50.000 contactos no puede analizar simultáneamente esos 50.000 registros, relacionar cientos de variables entre ellos y ejecutar acciones posteriores en cuestión de segundos. Un agente sí puede acercarse mucho más a esa capacidad. Por eso, aunque ambos utilicen las mismas credenciales y permisos, la superficie de riesgo no es necesariamente la misma.

En una arquitectura de agentes madura, los permisos del agente deberían ser como máximo equivalentes a los del humano que lo supervisa y, en muchos casos, considerablemente inferiores. El agente debería disponer únicamente de los datos y herramientas necesarios para las funciones que la organización haya decidido delegarle.

Cómo debería plantearse una implantación de Claudeforce en una empresa

La implantación no debería comenzar activando SObject All y comprobando después qué puede hacer Claude. La secuencia debería ser exactamente la contraria. Primero se define el caso de uso, después se identifica la información necesaria, se analiza la legitimación y los riesgos del tratamiento y, finalmente, se determina qué permisos y herramientas necesita el agente.

En la práctica, esto implica revisar como mínimo la finalidad del tratamiento, la base jurídica, los objetos y campos necesarios, las restricciones aplicables a determinados registros, la ubicación y flujo de los datos, las transferencias internacionales, el nivel de autonomía del agente, los logs y trazabilidad, los permisos de escritura y borrado y la necesidad de supervisión humana o de una evaluación de impacto.

Un agente destinado a preparar reuniones puede necesitar fundamentalmente permisos de lectura sobre información comercial relacionada con una cuenta. Otro dedicado a mantener actualizado el pipeline puede necesitar capacidad de modificación sobre determinados campos. Una herramienta que envíe comunicaciones a clientes introduce riesgos adicionales y probablemente requiera controles diferentes. No tiene sentido que todos ellos reciban el mismo nivel de acceso simplemente porque técnicamente pertenecen a la misma plataforma.

Esta forma de trabajar no pretende frenar la implantación de la inteligencia artificial. Al contrario: permite desplegarla de manera mucho más sostenible, porque convierte el control del dato y de las capacidades del agente en parte de la arquitectura y no en un problema que se intenta resolver después mediante instrucciones en el prompt.

Claudeforce no es el problema: el problema es cómo lo conectamos

Claudeforce me parece una muestra muy clara de hacia dónde está evolucionando la inteligencia artificial empresarial. Estamos pasando de sistemas que responden preguntas a sistemas que utilizan contexto empresarial, consultan aplicaciones y ejecutan acciones. El aumento de productividad potencial es considerable, especialmente en plataformas como Salesforce donde la información suele estar repartida entre cuentas, oportunidades, actividades, casos, informes y automatizaciones.

Pero cuanto mayor es la capacidad del agente, mayor debe ser también la calidad de su gobierno. Salesforce puede gestionar autenticación, permisos y reglas empresariales. Anthropic puede proporcionar el modelo de razonamiento. Ninguno de los dos puede determinar por la organización si para una tarea concreta Claude necesita conocer el teléfono de un cliente, revisar cinco años de comunicaciones o analizar otros 30.000 contactos que no guardan relación con la operación solicitada.

Por eso la pregunta importante antes de conectar Claudeforce no es simplemente “¿puede Claude acceder a Salesforce?”. La pregunta que debería responder cualquier organización es mucho más concreta:

¿Qué datos necesita Claude para esta finalidad, por qué podemos tratarlos y qué mecanismos garantizan que no reciba ninguno que no necesite?

Si esa respuesta existe antes de activar la integración, estaremos hablando de una implantación de inteligencia artificial con gobierno real. Si simplemente conectamos Claude a los mismos permisos que tiene el usuario y confiamos en que la plataforma haga el resto, tendremos una tecnología extraordinariamente potente, pero habremos confundido una vez más seguridad técnica con cumplimiento normativo.