Un cliente nos preguntó hace poco qué haría falta para que su equipo pudiera hacerles preguntas a sus datos de Salesforce en lenguaje natural, desde las herramientas en las que ya trabaja. Hace cinco años, ese alcance habría empezado con una arquitectura de integración y una cifra con varios ceros.<\/p>\n
Con Salesforce MCP, la respuesta honesta hoy es que la parte de conectar es casi trivial. Lo que no es trivial es decidir a qué conectarlo.<\/p>\n
Ese giro es toda la historia, y es fácil perderla de vista entre los anuncios de producto.<\/p>\n
Qué cambió realmente<\/h2>\n
En abril de 2026, Salesforce puso los servidores MCP alojados en disponibilidad general<\/a> para toda org con Enterprise Edition o superior. Salesforce MCP estaba en piloto desde la primavera de 2025 y en beta desde octubre de ese año.<\/p>\n MCP son las siglas de Model Context Protocol. Es un estándar abierto<\/a> que define cómo los asistentes de IA se comunican con los sistemas que guardan datos reales. La forma útil de entenderlo no es como una función de Salesforce, sino como un enchufe común. Antes, cada herramienta de IA que quisiera llegar a tu CRM necesitaba su propia conexión a medida, construida y mantenida por separado. Con MCP, todas hablan el mismo idioma.<\/p>\n Un servidor MCP alojado es un punto de conexión que Salesforce opera por ti. Expone las partes de tu org que elijas (objetos concretos, flujos, acciones de Apex, consultas definidas) a cualquier cliente de IA que hable el protocolo. Salesforce se encarga del alojamiento, la autenticación y la aplicación de permisos. No hay nada que aprovisionar ni disponibilidad que administrar.<\/p>\n En términos prácticos: tu Salesforce se convierte en algo con lo que un asistente de IA puede conversar, desde la herramienta en la que tu equipo ya vive, sin que nadie tenga que construir antes un puente.<\/p>\n Vale la pena ser preciso sobre lo que desapareció, porque la diferencia no es gradual.<\/p>\n La versión anterior era un proyecto de desarrollo. Elegías un middleware o escribías tú mismo la integración. Creabas una cuenta de servicio y negociabas sus permisos con alguien de seguridad. Mapeabas campos. Manejabas reintentos, fallas y límites de llamadas. Escribías un manual de operación. Y después mantenías todo eso, que se rompía más o menos cada vez que algo cambiaba en el sistema de origen.<\/p>\n La versión nueva es una tarea de configuración. Habilitas un servidor en Setup, creas una external client app y conectas el cliente. Salesforce calcula menos de treinta minutos para todo el camino, y en nuestra experiencia no es marketing. Dejar funcionando la primera conexión lleva de verdad una tarde, incluida la lectura.<\/p>\n Eso significa que los meses de esfuerzo que antes se iban en construir la conexión ahora quedan libres para otra cosa. La pregunta es si los equipos los invierten en las decisiones, o si simplemente llegan más rápido a una posición peor.<\/p>\n Si vas a leer una sola sección de este artículo, que sea esta. Lo técnicamente interesante de MCP es la estandarización. Lo interesante por sus consecuencias<\/em> es un cambio más silencioso en cómo funciona el acceso.<\/p>\n Las integraciones tradicionales se ejecutan con una cuenta de servicio. Una sola identidad, casi siempre creada hace años, casi siempre con más permisos de los que nadie recuerda haber concedido, actuando en nombre de todos. Cuando esa integración escribe un registro, el historial de auditoría dice que lo hizo la integración. Si la integración puede ver todo, también puede verlo cualquier cosa que se conecte a través de ella.<\/p>\n Salesforce MCP no funciona así. Cada transacción se ejecuta como el usuario autenticado.<\/strong> Los permisos CRUD, la seguridad a nivel de campo y las reglas de uso compartido se aplican exactamente igual que ya se aplican a esa persona. El acceso se controla con OAuth y PKCE, y en este modelo no existen cuentas de servicio anónimas.<\/p>\n Actualización.<\/strong> Ese modelo está cambiando para los agentes que se conectan desde fuera de Salesforce. Salesforce anunció que los agentes externos, usen MCP o la API, se registrarán en la plataforma con su propia identidad y su propio permission set, más acotado, en lugar de actuar como la persona a la que ayudan, y que sus llamadas se medirán para facturarse. Lo central de esta sección se mantiene, y con más fuerza: lo que un asistente puede alcanzar pasa a ser una decisión explícita sobre una identidad con nombre, y no algo que hereda de quien pregunta. Salesforce explica el cambio en Understand AIforce Impact<\/a> (en inglés).<\/p>\n De ahí salen dos cosas, y las dos vale la pena decirlas en voz alta en tu próxima reunión interna.<\/p>\n La buena noticia.<\/strong> El asistente no puede ver nada que la persona que pregunta no pudiera ver ya. Tu modelo de permisos actual, ese que tus administradores llevan años afinando, es el que hace el trabajo. Si el agente actualiza un registro, el nombre de esa persona queda en el historial de auditoría. Nadie tiene que aprender un modelo de seguridad nuevo ni confiar en uno.<\/p>\n La noticia incómoda.<\/strong> Tu modelo de permisos ahora sostiene un peso que antes nunca tuvo del todo. Si un usuario tiene acceso de lectura a un campo que nadie sabía que podía leer, probablemente nunca lo notó, porque encontrarlo habría implicado navegar hasta un formato de página olvidado. Un asistente lo va a mostrar en un resumen la primera vez que sea relevante. El exceso de permisos que durante años fue teórico se vuelve visible en la primera semana.<\/p>\n Esto no es un argumento en contra de conectar nada. Es un argumento para revisar tus permission sets antes de hacerlo, y no después de que alguien pegue una respuesta sorprendente en un canal.<\/p>\n La otra cosa que conviene entender antes de definir el alcance es que “conectar la IA a Salesforce” no es una sola decisión. La plataforma trae varios servidores preconfigurados con capacidades deliberadamente distintas, y tú eliges.<\/p>\n Los servidores SObject preconfigurados<\/a> se dividen de la forma más lógica: Además de esos, puedes construir servidores personalizados que expongan exactamente lo que quieras:<\/p>\n También hay una propiedad de seguridad estructural que es fácil pasar por alto. El servidor define exactamente qué operaciones existen. Un asistente no puede llamar a algo que no se expuso de forma explícita, porque desde su punto de vista esa operación no existe. Eso es muy distinto de entregarle a algo una API key y un permission set y confiar en que se mantenga dentro de los límites. Salesforce además puso el acceso MCP detrás de su propio scope de OAuth, así que concederlo no da acceso a las APIs REST existentes.<\/p>\n Construimos un prototipo para una organización de formación y educación que quería ver cómo funcionaba esto con sus propios datos: una conexión de solo lectura a un sandbox y un cliente de IA haciendo preguntas sobre sus datos de Salesforce en lenguaje natural. Deliberadamente sin glamour. Tomó una tarde.<\/p>\n La demo no fue lo interesante. Lo interesante fue lo que preguntó la sala después de verlo funcionar, porque las preguntas fueron más agudas que las que suelen aparecer en esta etapa. Las cuatro vale la pena tomarlas prestadas.<\/p>\n “¿Qué puede ver exactamente, y cómo lo limitamos?”<\/strong> Surgió al cabo de un minuto, más o menos, y es la primera pregunta correcta. No qué puede hacer. Qué puede ver<\/em>. Todo lo demás se desprende de esa respuesta: qué objetos, qué campos, qué registros, y si esos límites los aplica la plataforma o solo están escritos en algún lado con la esperanza de que se cumplan.<\/p>\n “¿Cómo le enseñamos nuestro vocabulario?”<\/strong> Sus programas, sus etapas, su definición de quién cuenta como activo. Un modelo que entiende Salesforce de forma genérica no sabe qué quiere decir tu<\/em> organización con ninguna de esas palabras. Creemos que esta es la pregunta que mejor predice si un despliegue termina siendo útil, porque una respuesta técnicamente correcta expresada con el vocabulario equivocado sigue siendo una respuesta equivocada, y lo es de una manera difícil de notar. El mecanismo es inyectar tus definiciones como contexto, junto con las reglas sobre lo que el asistente nunca debe hacer.<\/p>\n “¿Podemos empezar en solo lectura?”<\/strong> Lo plantearon ellos mismos, antes de que lo sugiriéramos. Vale la pena anotarlo, porque se suele asumir que los clientes presionan por acceso de escritura mientras el partner frena. En nuestra experiencia muchas veces es al revés, y esa cautela está mejor informada de lo que la gente cree.<\/p>\n “¿A dónde van las respuestas?”<\/strong> La que no anticipamos. Una respuesta que se queda en una ventana de chat sirve exactamente una vez. La pregunta de fondo era sobre los resultados: si una respuesta puede terminar en un documento, en una hoja de cálculo, en un reporte que lee otra persona, o adjunta al registro del que salió. Es una pregunta justa, muchas veces marca la diferencia entre una demo que la gente disfruta y una herramienta que la gente usa, y cambia lo que decides construir.<\/p>\n Ninguna de estas preguntas es sobre el protocolo. Las cuatro son sobre alcance, lenguaje y flujo de trabajo, que es justamente el punto.<\/p>\n Esta es la parte que querríamos que un cliente escuchara antes de firmar nada.<\/p>\n El esfuerzo que antes se iba en construir y mantener una integración no se evaporó. Se movió hacia el principio, a decisiones que antes se tomaban de forma implícita y ahora hay que tomar de forma explícita:<\/p>\n Ninguna de estas preguntas es difícil. Pero son preguntas que un proyecto de middleware te permitía postergar seis meses. Ahora llegan el primer día, lo cual es mejor, pero solo si alguien está preparado para ellas.<\/p>\n Por eso los proyectos que salen mal rara vez son los que chocan con un muro técnico. Son aquellos en los que la conexión funcionó de inmediato, nadie había decidido qué se debía exponer, y el alcance creció por inercia hasta que alguien de la dirección hizo una pregunta incómoda.<\/p>\n Mientras terminábamos este artículo, Salesforce y Anthropic anunciaron Claudeforce<\/a> (26 de agosto de 2026). Vale la pena tratarlo directamente, porque es lo más grande que ha pasado en este espacio desde la disponibilidad general de abril, y porque refuerza el argumento anterior en lugar de contradecirlo.<\/p>\n Lo principal es Salesforce in Claude<\/strong>, un plugin con 37 habilidades de ventas ya construidas que cubren la preparación de reuniones, la revisión de la salud de una oportunidad y la revisión del pipeline. Un administrador lo conecta una vez, los permisos se administran de forma centralizada y todos los vendedores del equipo tienen acceso desde el primer día. Claude también pasa a ser un modelo de razonamiento dentro de la plataforma de agentes de Salesforce, y el modelo predeterminado en Slack. Sales Cloud in Claude abrió las solicitudes de beta en Dreamforce, el 15 de septiembre de 2026, después de un piloto que incluyó a Deloitte, GitLab y Legora. El acceso se solicita a través de AgentExchange y las solicitudes aprobadas reciben instrucciones de activación.<\/p>\n El detalle que conviene notar es cómo describe Salesforce la infraestructura de fondo. El anuncio le atribuye ese papel a AIforce<\/strong>, la capa que lleva los datos y los flujos de trabajo del negocio a cualquier agente, en palabras de la propia Salesforce, “through MCP servers, APIs, and CLI tools” (a través de servidores MCP, APIs y herramientas de línea de comandos). El protocolo del que trata este artículo es la base sobre la que funciona el producto empaquetado.<\/p>\n ¿Qué cambia, entonces?<\/strong> Para los equipos de ventas que trabajan dentro de Claude, buena parte de la configuración que describimos aquí ahora viene hecha. Es realmente útil y no vamos a fingir lo contrario. Si tu caso de uso es ventas y tu gente ya vive en Claude, la beta está abierta a solicitudes y vale la pena pedirla.<\/p>\n Lo que no cambia es todo aquello de lo que realmente trata este artículo.<\/strong> Las habilidades ya construidas cubren ventas, dentro de un cliente, en beta. Atención al cliente, finanzas, operaciones, tus objetos personalizados y tu propio vocabulario siguen siendo cosa tuya: te toca definirlos a ti. Y las decisiones son idénticas en ambos casos: qué objetos y campos deberían ser accesibles, si tus permission sets reflejan lo que la gente debería ver hoy, qué significan tus términos de negocio con la precisión suficiente para responder con ellos, y qué se queda en solo lectura. Esas cuatro, y las dos que solo importan cuando la escritura entra en juego, son las que trabajamos en guardrails de IA en Salesforce<\/a>.<\/p>\n Instalar un plugin no te exime de esas decisiones. Te lleva bastante más rápido al momento en que ya tendrías que haberlas tomado.<\/p>\n Si quieres averiguar cuánto vale Salesforce MCP en tu propia org sin comprometerte a nada, hay un camino de muy bajo riesgo.<\/p>\n Habilita el servidor Vas a aprender tres cosas rápido: si las respuestas son lo bastante buenas para ser útiles, dónde se desarman tus datos o tus definiciones cuando se les pregunta de frente, y qué casos de uso inventa la gente que nadie puso en el alcance original. En nuestra experiencia, lo tercero suele ser lo más valioso, y nunca coincide con el caso de negocio que se escribió antes.<\/p>\n Después, y solo después, plantea la conversación sobre el acceso de escritura. Escribimos aparte sobre por qué la base, no el modelo, decide si la IA funciona en una org de Salesforce<\/a>, y ese argumento se aplica aquí con más fuerza, no con menos, precisamente porque la barrera técnica ahora es muy baja.<\/p>\n La conversación sobre el alcance es la parte que vale la pena hacer bien, y es más corta de lo que la mayoría espera. Te diremos con honestidad si tu org está lista y qué conectaríamos primero.<\/p>\n Hablemos →<\/a><\/p>\n<\/div>\n Hay una versión de este momento que sale mal, y no se parece a un incidente de seguridad. Se parece a una docena de equipos que conectan cada uno un asistente a producción porque es fácil, nadie anota qué se expuso, y pasa un año de inconsistencias silenciosas antes de que alguien lo note.<\/p>\n También hay una versión que sale bien, y no es más cautelosa. Solo es más deliberada al principio. La misma tarde de configuración, precedida por una semana decidiendo qué debería ser accesible y qué significan tus términos.<\/p>\n Creemos que MCP es lo más relevante que le ha pasado a la integración con Salesforce en una década, y lo decimos aunque elimina trabajo por el que antes nos pagaban. La conexión ya no es la parte difícil. Es una buena noticia. Solo significa que la parte difícil ahora es la que siempre fue más importante.<\/p>\n Por si sirve de algo, esta es la idea detrás de PilotIQ<\/a>, nuestro propio asistente que funciona dentro de Salesforce: la misma convicción de que lo que un asistente puede alcanzar importa más que lo inteligente que sea.<\/p>\n Todas las fuentes están en inglés.<\/p>\n Los servidores MCP alojados de Salesforce llegaron a disponibilidad general en abril, y Claudeforce est\u00e1 construido sobre ellos. Conectar un LLM a tu org ahora toma una tarde. Las decisiones que deja pendientes son el trabajo real.<\/p>\n","protected":false},"author":17,"featured_media":19238,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pgc_sgb_lightbox_settings":"","footnotes":""},"categories":[588],"tags":[509,720,745,744],"sky-post-author":[703],"class_list":["post-19323","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-inteligencia-artificial","tag-integracion-de-salesforce","tag-inteligencia-artificial","tag-mcp-es","tag-tendencias-de-salesforce"],"_links":{"self":[{"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/posts\/19323","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/users\/17"}],"replies":[{"embeddable":true,"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/comments?post=19323"}],"version-history":[{"count":4,"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/posts\/19323\/revisions"}],"predecessor-version":[{"id":19327,"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/posts\/19323\/revisions\/19327"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/media\/19238"}],"wp:attachment":[{"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/media?parent=19323"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/categories?post=19323"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/tags?post=19323"},{"taxonomy":"sky-post-author","embeddable":true,"href":"https:\/\/www.theskyplanner.com\/es\/wp-json\/wp\/v2\/sky-post-author?post=19323"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Cómo era antes este problema<\/h2>\n
![\"Comparación](\"https:\/\/www.theskyplanner.com\/wp-content\/uploads\/2026\/10\/mcp-then-now-chart-es.png\")
El cambio que más importa no es el protocolo<\/h2>\n
![\"Diagrama](\"https:\/\/www.theskyplanner.com\/wp-content\/uploads\/2026\/10\/mcp-identity-chart-es.png\")
Con cuánto detalle se decide qué exponer<\/h2>\n
![\"Los](\"https:\/\/www.theskyplanner.com\/wp-content\/uploads\/2026\/10\/mcp-exposure-chart-es.png\")
sobject-reads<\/code> solo lee y consulta, sobject-mutations<\/code> permite crear y actualizar pero no eliminar, sobject-deletes<\/code> cubre la eliminación y sobject-all<\/code> da acceso completo. Habilitar uno y no los demás es un límite real, aplicado por la plataforma, no una política que esperas que la gente respete.<\/p>\n\n
Las preguntas que nos hicieron cuando lo mostramos<\/h2>\n
El trabajo se movió, no desapareció<\/h2>\n
\n
Lo que cambia Claudeforce, y lo que no<\/h2>\n
Por dónde empezar<\/h2>\n
platform\/sobject-reads<\/code> en un sandbox. Es de solo lectura, así que nada en tu org puede cambiar. Conecta un cliente de IA. Dáselo a tres o cuatro personas que conozcan bien tus datos y deja que hagan las preguntas que realmente tienen, durante dos semanas.<\/p>\n¿Estás pensando en conectar un LLM a tu org?<\/h3>\n
Nuestra visión<\/h2>\n
Fuentes<\/h2>\n
\n