{"id":19354,"date":"2026-10-15T13:46:04","date_gmt":"2026-10-15T13:46:04","guid":{"rendered":"https:\/\/www.theskyplanner.com\/?p=19354"},"modified":"2026-10-15T13:47:19","modified_gmt":"2026-10-15T13:47:19","slug":"datos-listos-para-ia-salesforce","status":"publish","type":"post","link":"https:\/\/www.theskyplanner.com\/es\/datos-listos-para-ia-salesforce\/","title":{"rendered":"Tu equipo sabe qu\u00e9 campos de Salesforce ignorar. La IA no."},"content":{"rendered":"

<\/p>\n

Pregunta a un equipo si sus datos de Salesforce están listos para la IA y la respuesta casi siempre habla de limpieza: duplicados, campos vacíos, formatos inconsistentes. Todo eso importa. Pero lo que de verdad decide si tienes datos listos para IA es otra pregunta, y casi nadie la hace hasta que un asistente da con total seguridad una respuesta que resulta ser falsa.<\/p>\n

La pregunta es esta: ¿cada campo que lee el asistente sigue significando algo para alguien?<\/p>\n

La mayoría de las orgs no saben responderla, y la mayoría de los equipos nunca lo han necesitado, porque las personas siempre han sabido qué campos ignorar.<\/p>\n

Tu equipo lee de forma selectiva. Un asistente lee al pie de la letra.<\/h2>\n

Cualquiera que lleve un año trabajando en una org de Salesforce tiene un mapa privado de ella. El campo Lead Source dejó de significar algo después de la reorganización de marketing. La probabilidad se calcula sola a partir de la etapa, así que nadie la mira. El estado real de una oportunidad está en Next Steps, no en la etapa. El campo Industry de las cuentas antiguas lo llenó un practicante en 2022 y nadie lo ha tocado desde entonces.<\/p>\n

Nada de eso está escrito en ninguna parte. No hace falta, mientras los únicos lectores sean personas que lo aprendieron unas de otras. Se saltan los campos que mienten, leen los que no, y lo hacen sin pensarlo.<\/p>\n

Un asistente conectado a la misma org recibe el esquema sin el folclore. Lee cada campo con la misma confianza. Te dirá que un cliente es del sector minorista porque el campo Industry lo dice, te dará una probabilidad del 70% porque el campo dice 70, y resumirá una oportunidad a partir de su etapa mientras la nota que dice que el comprador se fue de la empresa está dos campos más abajo.<\/p>\n

Gartner describió el problema de fondo sin rodeos: en la gestión de datos tradicional, los usos de los datos no están bien documentados, y a las organizaciones les faltan la práctica y los metadatos necesarios para evaluar si sus datos están listos para la IA. En una org de Salesforce, esos metadatos que faltan no son nada exótico. Son la respuesta a qué significa cada campo, y para quién.<\/p>\n

Cuatro tipos de campo que engañan a un asistente y nunca a una persona<\/h2>\n

En las orgs en las que trabajamos, los campos que causan problemas caen en cuatro tipos reconocibles. Ninguno es un problema de calidad de datos en el sentido habitual, y justamente por eso sobreviven a los proyectos de calidad de datos.<\/p>\n

El campo abandonado.<\/strong> Sigue lleno, porque un valor por defecto, una regla de validación o una automatización antigua lo sigue completando, y no lo lee nadie. Tiene una completitud perfecta. No significa nada. La gente lo ignora con tanta naturalidad que nadie recuerda que existe, hasta que un asistente lo cita.<\/p>\n

El campo con dos significados.<\/strong> La misma etiqueta, leída de forma distinta por dos equipos. Ventas marca un lead como calificado cuando hay una conversación; marketing quiere decir que superó un umbral de puntuación. Los dos tienen razón dentro de sus propios reportes, y el desacuerdo solo aparece cuando alguien compara totales. Un asistente no compara. Elige un significado en silencio, y no te enteras de cuál.<\/p>\n

El campo que fue cierto una vez.<\/strong> Se capturó al crear el registro y nunca se mantuvo: número de empleados, sector, región, el producto principal del cliente. Exacto el día en que se creó el registro y desactualizándose desde entonces. Las personas lo tratan como contexto aproximado. Un asistente lo trata como un hecho actual.<\/p>\n

El campo de texto que tiene la respuesta real.<\/strong> Next Steps, Description, un campo de notas que nadie diseñó. Los campos estructurados dicen una cosa; el texto libre dice lo que de verdad pasó. Una persona lee primero la nota. Un asistente puede darle más peso al campo estructurado, porque parece más oficial, y contarte la versión formal de una historia que todo el equipo sabe que está desactualizada.<\/p>\n

Por qué un proyecto de calidad de datos no los va a encontrar<\/h2>\n

Los proyectos de calidad de datos miden lo que se puede medir: completitud, duplicados, formatos, valores válidos. Los cuatro campos anteriores pueden pasar todas esas pruebas. Una lista de selección abandonada con valor por defecto está 100% completa. Un campo con dos significados tiene valores perfectamente válidos. Un número de empleados desactualizado tiene el formato correcto. El problema no es la calidad. Es el significado, y el significado no tiene regla de validación.<\/p>\n

La investigación apunta en la misma dirección. En el estudio State of Data and Analytics de Salesforce, casi la mitad (49%) de los líderes de datos y analítica dijo que sus empresas sacan conclusiones incorrectas de vez en cuando, o incluso con frecuencia, a partir de datos con poco contexto de negocio. Esos mismos líderes estimaron que más de una cuarta parte (26%) de los datos de su organización no son confiables. Poco contexto de negocio es exactamente lo que describen los cuatro campos anteriores: valores que están, que son válidos y que es un error leer de forma literal. Esa es la brecha que deja abierta un proyecto de limpieza, y es la parte de tener datos listos para IA que un asistente expone primero.<\/p>\n

Y la solución es menos técnica de lo que parece. En una encuesta de Gartner a 223 líderes de datos y analítica, realizada en marzo de 2026, la resistencia cultural pesó más que la falta de presupuesto como motivo principal del fracaso de las iniciativas de gobierno de datos: 60% frente a 40%. La conclusión de Gartner fue que los datos listos para la IA también necesitan personas listas para la IA. Por nuestra experiencia, es la forma correcta de decirlo, y lleva directo a la pregunta que vale la pena hacer.<\/p>\n

\n

¿No sabes en qué campos de tu org confiaría un asistente?<\/h3>\n

Una revisión de campos acotada a un caso de uso suele llevar días, no meses, y es el seguro más barato contra una respuesta segura y equivocada.<\/p>\n

Hablemos de AI Enablement →<\/a><\/p>\n<\/div>\n

La pregunta que hay que hacer: ¿para quién es este campo?<\/h2>\n

Cada campo de una org de Salesforce se creó para un lector. Un reporte que alguien necesitaba, una aprobación que dependía de él, un gerente que quería verlo en un formato de página. Mientras ese lector existe, el campo se mantiene honesto, porque alguien se da cuenta cuando está mal.<\/p>\n

Cuando el lector se va, el campo se queda. El reporte se retira, la aprobación se rediseña, el gerente cambia de puesto, y el campo se sigue llenando, por costumbre o por automatización, sin nadie que note si está bien. Así se crean los cuatro tipos de campo engañoso. Son huérfanos.<\/p>\n

Por eso la versión útil de la pregunta no es ¿nuestros datos están limpios? Es una pregunta que se hace campo por campo: ¿quién lee esto, y se daría cuenta si estuviera mal?<\/strong> Un campo con respuesta se le puede dar a un asistente. Un campo sin respuesta no, por completo que parezca.<\/p>\n

Por qué importa más cuando el asistente puede actuar<\/h3>\n

Mientras un asistente solo responde preguntas, un campo engañoso produce una frase equivocada, y quien la lee tiene la oportunidad de detectarla. Cuando un asistente puede actualizar registros, redactar correos o asignar trabajo, el mismo campo produce una acción equivocada, y la persona que la habría detectado ya no está en el proceso. Un campo huérfano que era una molestia en un resumen se convierte en un riesgo en un flujo de trabajo. Por eso hay que resolver lo de los datos listos para IA antes de hablar de acceso de escritura, no después.<\/p>\n

También por eso esta pregunta no la puede responder una herramienta. Un software de perfilado te puede decir que un campo está lleno en un 98%. Solo una persona te puede decir que nadie lo ha mirado desde la última reorganización.<\/p>\n

Cómo hacerlo en la parte de la org que importa<\/h2>\n

El error es tratarlo como un proyecto de datos de toda la org. No lo es, y no debería serlo, porque los proyectos de toda la org no terminan. Acótalo a lo que un asistente va a leer de verdad.<\/p>\n

Empieza por el caso de uso, no por el esquema.<\/strong> Elige lo primero que quieres que haga un asistente y haz la lista de los objetos y campos que tendría que leer para hacerlo. Suelen ser tres o cuatro objetos y unos cientos de campos, la mayoría de los cuales nadie extrañaría.<\/p>\n

Dale a cada campo uno de tres resultados.<\/strong> Mantener: tiene un dueño que lo lee y que notaría si estuviera mal. Definir: la gente lo usa, pero cada uno entiende algo distinto, así que necesita una frase escrita con su significado antes de que lo lea un asistente. Ocultar: no tiene dueño, así que el asistente no debería verlo. Ocultar es barato y reversible. Eliminar campos es otro proyecto, mucho más arriesgado, y no es de lo que se trata aquí.<\/p>\n

Resuelve los campos en disputa en lugar de promediarlos.<\/strong> Cuando un campo resulta tener dos significados, solo hay dos salidas honestas: ponerse de acuerdo en uno y escribirlo, o dividirlo en dos campos que signifiquen una sola cosa cada uno. La tercera opción tentadora, una definición tan vaga que los dos equipos la puedan firmar, es peor que nada, porque parece resuelta y no lo está. También es el paso que más a menudo necesita a alguien con autoridad en la reunión, que era el punto cultural de Gartner.<\/p>\n

Nombra a los dueños como roles, no como personas.<\/strong> «Operaciones de ventas» sobrevive a una renuncia. «María» no, y el objetivo es justamente que los campos no vuelvan a quedarse huérfanos la próxima vez que alguien se vaya.<\/p>\n

Escribe las definiciones donde ocurre el trabajo.<\/strong> En el texto de ayuda del campo (Field-Level Help), no en una wiki. Lo ve la persona que llena el campo, y lo ve cualquiera, o cualquier cosa, que lea el campo después.<\/p>\n

Expón solo lo que decidiste mantener.<\/strong> Aquí es donde el ejercicio se paga solo. Los servidores MCP alojados de Salesforce te permiten definir exactamente qué objetos y campos devuelve una herramienta mediante consultas con nombre, algo que contamos en qué cambió cuando Salesforce MCP hizo fácil la conexión<\/a>. El alcance es también la segunda de las decisiones que tomamos antes de darle cualquier acceso a un asistente, en los guardrails que ponemos antes de que la IA pueda escribir en Salesforce<\/a>. Y Salesforce avanza hacia darles a los agentes sus propios permisos, más acotados, en lugar de prestarles los de una persona, lo que convierte la lista de campos en configuración y no en un documento.<\/p>\n

Repítelo cuando cambie la org.<\/strong> Una reorganización, un reporte retirado, un equipo nuevo: cada uno crea huérfanos. La revisión es mucho más corta la segunda vez, porque solo revisas los campos cuyos lectores cambiaron.<\/p>\n

La mitad que la plataforma no puede hacer por ti<\/h2>\n

Cuando analizamos lo que significan las actualizaciones de versión de Winter ’27 para estar preparados para la IA<\/a>, la conclusión fue que la plataforma ahora impone parte de la maquinaria: identidades con nombre, visibilidad decidida, automatización que se puede probar. Es un avance real, y nada de eso toca lo que significa un campo. Una versión puede obligarte a decir quién es un usuario de integración. Ninguna versión te puede decir si tu campo Industry sigue siendo cierto.<\/p>\n

Esa es la mitad de la preparación que queda en manos de quienes administran la org. No tiene fecha límite, y justamente por eso siempre pierde frente al trabajo que sí la tiene, y es también la mitad que decide si las respuestas de un asistente las puede verificar quien las recibe.<\/p>\n

Nuestra opinión<\/h2>\n

Lo de tener datos listos para IA se suele plantear como un proyecto de limpieza, y los proyectos de limpieza son fáciles de posponer porque nunca se sienten terminados. Creemos que es mejor plantearlo como una cuestión de responsabilidad, y esa cuestión se puede responder en pocos días para la parte de la org que un asistente va a leer de verdad.<\/p>\n

Una org en la que cada campo que lee el asistente tiene dueño va a seguir dando respuestas equivocadas de vez en cuando. La diferencia es que alguien lo va a notar, y rápido, porque el campo es suyo. Esa es la propiedad que importa, y es la que la mayoría de las orgs todavía no tiene. También es la base sobre la que se apoya todo lo demás, y por eso insistimos en que es la base, no el modelo, lo que decide si la IA funciona<\/a>.<\/p>\n

Fuentes<\/h2>\n

Todas las cifras se leyeron en la fuente original el 7 de octubre de 2026. Todas las fuentes están en inglés.<\/p>\n