{"id":19328,"date":"2026-09-17T13:56:00","date_gmt":"2026-09-17T13:56:00","guid":{"rendered":"https:\/\/www.theskyplanner.com\/?p=19328"},"modified":"2026-10-12T18:56:33","modified_gmt":"2026-10-12T18:56:33","slug":"guardrails-de-ia-salesforce","status":"publish","type":"post","link":"https:\/\/www.theskyplanner.com\/es\/guardrails-de-ia-salesforce\/","title":{"rendered":"Guardrails de IA en Salesforce: qu\u00e9 decidir antes de dar acceso de escritura"},"content":{"rendered":"

<\/p>\n

La mayoría de los proyectos de IA no se traban por capacidad. Se traban en una reunión en la que alguien pregunta qué va a poder tocar exactamente esa herramienta, y nadie tiene la respuesta por escrito. Estas son las decisiones que tomamos antes de dejar que un asistente escriba cualquier cosa: las que definen sus guardrails de IA, es decir, los límites de lo que puede y no puede hacer.<\/em><\/p>\n

Hay un momento que se repite en casi todos los proyectos de IA en Salesforce. El caso de uso está acordado. Alguien vio una demo y le gustó. Hay presupuesto. Entonces la conversación llega a TI o a seguridad, y alguien hace una pregunta razonable:<\/p>\n

“¿Qué va a poder leer exactamente, y qué va a poder modificar?”<\/strong><\/p>\n

Y la sala se queda en silencio. No porque alguien haya sido descuidado, sino porque hasta ese momento la pregunta nunca había necesitado una respuesta por escrito. En Salesforce, los permisos siempre han gobernado a personas<\/em>, y las personas traen el criterio incorporado.<\/p>\n

Por qué esta pregunta es realmente nueva<\/h2>\n

Escribimos hace poco que conectar un asistente a Salesforce dejó de ser la parte difícil<\/a>, y que el trabajo pasó a ser decidir a qué debería llegar. Este artículo es esa decisión, por escrito. Y ya no es una cuestión hipotética: Salesforce ahora expone sus datos, sus reglas de negocio y sus permisos a interfaces de IA que están completamente fuera de Salesforce, y lo hace sin un modelo de permisos nuevo y sin migración. Lo que una org ya tenga configurado es lo que hereda un asistente. El modelo de permisos de Salesforce es maduro y se entiende bien. Perfiles, permission sets, reglas de uso compartido, seguridad a nivel de campo: nada de esto es nuevo, y la mayoría de los administradores lo conoce bien.<\/p>\n

Lo que cambia con la IA no es el modelo. Son los supuestos que tiene debajo.<\/p>\n

Un permission set está pensado para un ser humano que inicia sesión, ve lo que tiene permitido ver y actúa con prudencia. Si esa persona abre un registro y algo se ve mal, se detiene. Si le piden actualizar cuatrocientas cuentas, se toma un día, nota que la tercera es rara y hace una pregunta.<\/p>\n

El software no hace ninguna de esas dos cosas a menos que se lo indiques. Es más rápido, es literal y no hace pausas. Los mismos permisos que eran seguros para una persona pueden serlo bastante menos en manos de algo que actúa a velocidad de máquina y nunca sospecha.<\/p>\n

Esto no es un argumento en contra de darle acceso a la IA. Es un argumento para decidir los límites a propósito, por escrito, antes y no después.<\/p>\n

La brecha, en números<\/h2>\n

No es una preocupación de nicho. En la investigación State of Data and Analytics<\/a> de Salesforce, solo el 43% de los líderes de datos y analítica tiene marcos y políticas formales de gobierno de datos<\/strong>, mientras que el 88% coincide en que la IA exige enfoques completamente nuevos de gobierno y seguridad<\/strong> (Salesforce Newsroom, noviembre de 2025<\/a>).<\/p>\n

\"Gráfico:
Datos: Salesforce, State of Data and Analytics.<\/figcaption><\/figure>\n

Casi nueve de cada diez saben que las reglas tienen que cambiar. Menos de la mitad tiene reglas escritas para empezar. Esa distancia no es donde ocurren las filtraciones dramáticas. Es donde ocurren los incidentes comunes y evitables: un campo actualizado en masa que no debía tocarse, un resumen que incluyó datos de compensación, un correo que nadie aprobó, enviado a un cliente.<\/p>\n

Leer, escribir, actuar: tres decisiones, no una<\/h2>\n

Los guardrails de IA empiezan con una distinción fácil de pasar por alto y que sale cara si se entiende mal: lo que una IA puede leer<\/em>, lo que puede escribir<\/em> y aquello sobre lo que puede actuar<\/em>. Los equipos suelen meter todo eso en una sola conversación sobre permisos, y no deberían.<\/p>\n

\"Diagrama<\/figure>\n

Leer<\/strong> significa que la IA puede responder preguntas con datos que ya existen. Aquí está la mayor parte del valor práctico, y es lo que menos riesgo tiene. Nada cambia en tu org.<\/p>\n

Escribir<\/strong> significa que puede crear o actualizar registros. El riesgo es real pero recuperable, siempre que hayas decidido de antemano cómo te recuperarías.<\/p>\n

Actuar<\/strong> significa que puede hacer que algo pase fuera de Salesforce: enviar un correo a un cliente, abrir un caso, activar un proceso en un sistema externo. Es lo más difícil de deshacer, porque la consecuencia ya salió de tu org.<\/p>\n

Nuestra posición es sencilla: concede estos niveles en orden, y por separado. Un número sorprendente de empresas pide capacidad de actuar cuando lo que de verdad ayudaría a su equipo es poder leer.<\/p>\n

Las seis decisiones que tomamos antes de dar acceso de escritura<\/h2>\n

Estas son las preguntas que trabajamos con cada cliente, y dejamos las respuestas por escrito. El documento suele ocupar una página. Prepararlo toma menos tiempo del que la gente espera, y es lo que hace que un proyecto supere la conversación con el equipo de seguridad en lugar de quedarse atascado en ella.<\/p>\n

\"Seis<\/figure>\n

1. Identidad. ¿De quién hereda los permisos?<\/strong> Un asistente que actúa en nombre de un usuario concreto hereda exactamente el acceso de ese usuario, que normalmente es lo que quieres. Una integración que corre con una cuenta de servicio dedicada hereda lo que le hayas dado a esa cuenta, y ahí es donde el exceso de permisos se cuela sin que nadie lo note. Decide qué modelo corresponde y, si es una cuenta de servicio, dale el perfil más restringido que haga el trabajo. Salesforce está ajustando esto desde su lado: a partir del 1 de diciembre, toda conexión que inicie sesión con la llamada login()<\/code> de la API SOAP va a necesitar un permiso con nombre, uno de los tres cambios que repasamos en lo que cambia Winter ’27 en identidad, visibilidad y pruebas<\/a>.<\/p>\n

2. Alcance. ¿Qué objetos y campos, de forma explícita?<\/strong> El punto de partida seguro es denegar y luego agregar. No “puede ver los objetos estándar”, sino una lista con nombres. Lleva una tarde y ahorra muchas discusiones después.<\/p>\n

3. Límite. ¿Qué no debe hacer nunca?<\/strong> El acceso de escritura no es una sola cosa. Crear una tarea no es lo mismo que cambiar la etapa de una oportunidad, y ninguna de las dos es lo mismo que eliminar un registro. Escribimos una lista explícita de prohibiciones: nada de eliminaciones, nada de cambios en registros cerrados, nada de ediciones en campos que alimentan la compensación, lo que corresponda a cada org.<\/p>\n

4. Aprobación. ¿Qué requiere la aprobación de una persona?<\/strong> No todo necesita un punto de control, y si exiges aprobación para todo, la gente va a dejar de usar la herramienta. La versión útil se basa en umbrales: cualquier cosa que toque más de N registros, cualquier cosa que llegue al cliente, cualquier cosa por encima de cierto valor. Decide los umbrales mientras todos están tranquilos.<\/p>\n

5. Auditoría. ¿Qué queda registrado?<\/strong> Cada acción: qué se cambió, cuándo y en nombre de quién. Por dos razones: lo vas a necesitar la primera vez que algo se vea mal, y lo vas a necesitar la primera vez que alguien de la dirección pregunte si esto es seguro. Un historial de auditoría es además la forma más rápida de generar confianza interna, porque convierte un debate en una consulta.<\/p>\n

6. Reversión. ¿Cómo se deshace?<\/strong> Es la que más se pasa por alto. Si la IA actualiza mal dos mil registros un viernes, ¿cuál es el camino de recuperación, quién puede ejecutarlo y cuánto tarda? Pruébalo antes de salir en vivo y no durante un incidente. En la misma línea: asegúrate de que alguien sepa apagar todo, rápido, sin abrir un ticket.<\/p>\n

Lo que la gente suele olvidar<\/h2>\n

Hay algunos modos de falla que aparecen tan seguido que vale la pena nombrarlos.<\/p>\n

El acceso a nivel de campo no es lo mismo que el acceso a nivel de registro.<\/strong> Una IA que puede leer legítimamente una oportunidad quizá también esté leyendo un campo de notas con algo que nadie pretendía exponer. Para un usuario, el acceso de lectura y el permiso para resumir ese contenido en una respuesta<\/em> se sienten distintos, aunque técnicamente sean el mismo permiso.<\/p>\n

La trampa de “actuar como administrador”.<\/strong> Probar un asistente con una sesión de administrador del sistema da una idea equivocada de lo que puede alcanzar. Pruébalo con el rol que realmente lo va a usar.<\/p>\n

Lo masivo es otra clase de riesgo.<\/strong> Una sola instrucción puede tocar miles de registros. Los permisos que tienen sentido para trabajar registro por registro merecen una segunda mirada cuando se pueden ejercer a escala en un solo paso.<\/p>\n

Datos que salen de la org.<\/strong> Si el asistente envía contexto a un modelo externo, decide de forma explícita qué puede salir y confirma qué hace el proveedor con eso. Es una pregunta que tu equipo de seguridad va a hacer, y tenerla respondida de antemano es la diferencia entre una conversación corta y un proyecto detenido.<\/p>\n

Nuestra posición: empezar en solo lectura<\/h2>\n

Si pudiéramos dar un solo consejo sobre esto, sería operar primero en solo lectura durante un periodo definido. Un mes suele ser suficiente.<\/p>\n

No es timidez. Es la forma más barata que conocemos de descubrir en qué se habría equivocado la IA antes<\/em> de que pueda actuar. En una fase de solo lectura, una mala respuesta es un hallazgo útil. En una fase con escritura habilitada, esa misma mala respuesta son doscientos registros que ahora tienes que arreglar.<\/p>\n

Además hace algo que la gente no anticipa: saca a la luz tus problemas de datos de forma muy concreta. Cuando un asistente da con total seguridad una respuesta que todos en la sala saben que está mal, acabas de encontrar un problema de definiciones o de calidad de datos que llevaba tiempo afectando tus reportes en silencio. Solo por eso ya vale la pena ese mes.<\/p>\n

Esto conecta directamente con algo sobre lo que ya escribimos: un sistema de IA hereda la org a la que llega. Si quieres el argumento completo, está en nuestro artículo sobre por qué la base, no el modelo, decide si la IA funciona<\/a>.<\/p>\n

\n

¿No sabes qué debería permitir tu org?<\/h3>\n

Definir las reglas de acceso es parte de la evaluación de preparación de nuestros servicios de AI Enablement. Te llevas el documento de una página que describimos arriba, decidas lo que decidas construir después.<\/p>\n

Hablemos →<\/a><\/p>\n<\/div>\n

Cómo se ve cuando está bien hecho<\/h2>\n

Vas a saber que los guardrails están bien definidos cuando puedas entregarle a alguien una sola página que responda cinco preguntas en lenguaje sencillo:<\/p>\n