SnowWork de Snowflake convirtió su data warehouse en una capa de acción para Sales Ops. La auditoría de 5 preguntas antes de abrir la puerta

Su data warehouse era un almacén. Snowflake acaba de convertirlo en un runtime. Y Sales Operations (Sales Ops) ahora es responsable de una superficie que nadie le cedió formalmente.

Qué lanzó Snowflake realmente

Según el anuncio de Snowflake, el Proyecto SnowWork se lanzó en vista previa de investigación el 18 de marzo de 2026 como una plataforma de IA agéntica que permite a los usuarios de negocio ejecutar flujos de trabajo de múltiples pasos directamente sobre datos gobernados de Snowflake. Sin necesidad de código. Sin abrir un ticket al equipo de datos.

La plataforma incluye perfiles adaptados al rol para finanzas, ventas, marketing y operaciones. Cada perfil comprende la terminología y los KPIs típicos de esa función. Un representante con el perfil de ventas puede pedirle a SnowWork que repriorice las asignaciones de territorio, genere un informe de pipeline de múltiples fuentes o construya una presentación lista para la junta directiva. El agente planifica la tarea y la ejecuta directamente sobre sus datos gobernados.

Snowflake nombró explícitamente a Sales Ops como uno de los principales beneficiarios. La empresa afirmó que los equipos ahora pueden "automatizar informes repetitivos, trabajar con múltiples fuentes de datos sin programar y generar entregables listos para presentación en minutos en lugar de días". Es una capacidad real. Pero viene con una pregunta real que Sales Ops debe responder antes de que el primer usuario inicie sesión.

Y hay una segunda capa. El 27 de mayo, Snowflake anunció su intención de adquirir Natoma, una startup de gobernanza de MCP (Model Context Protocol). Natoma agrega un registro de servidores, una capa de identidad y un plano de políticas de acceso que permite a los agentes de SnowWork conectarse a plataformas de CRM como Salesforce y HubSpot, nubes privadas virtuales (VPC) y sistemas locales con gobernanza verificada. Como informó CIO.com, la capa de Natoma está específicamente diseñada para llevar la aplicación de políticas a los sistemas agénticos que antes no la tenían.

El stack combinado de SnowWork y Natoma cambia el rol del data warehouse de almacén pasivo a runtime activo. Ese cambio no es teórico. Ya está en vista previa.

Datos clave

• Snowflake lanzó SnowWork en vista previa de investigación en marzo de 2026, dirigido a usuarios de finanzas, ventas, marketing y operaciones con perfiles agénticos adaptados al rol.
• Las acciones de Snowflake subieron un 36% el 28 y 29 de mayo de 2026 (su mejor día desde el IPO), impulsadas por los resultados del primer trimestre, una alianza ampliada con AWS y el anuncio de la adquisición de Natoma, según CNBC.
• La adquisición pendiente de Natoma agrega gobernanza de MCP para que los agentes de SnowWork puedan actuar en Salesforce, HubSpot, VPCs y sistemas locales, no solo dentro de Snowflake.

Por qué esto recae en Sales Ops, no en IT

IT gobierna el acceso a la infraestructura. Pero Sales Ops es dueño de las definiciones que viven en esa infraestructura. Su lógica de segmentación. Sus reglas de territorio. Sus asignaciones de quota. Sus criterios de etapa del negocio.

Cuando un usuario de negocio le pide a SnowWork que "reasigne cuentas en el territorio del Mountain West", el agente escribe contra la lógica de segmentación que hay actualmente en su data warehouse. Si esa lógica está desactualizada, parcialmente migrada desde una hoja de cálculo, o simplemente incorrecta en un campo, el agente ejecuta contra la definición equivocada. A escala. De forma autónoma.

Esto es lo que significa que el data warehouse se convierta en una capa de acción: la distancia entre una definición de datos incorrecta y una decisión de negocio incorrecta se colapsa. En un warehouse tradicional, una definición incorrecta produce un informe incorrecto. Alguien lo detecta en la revisión. En un warehouse agéntico, una definición incorrecta produce una acción incorrecta. Y esas acciones pueden encadenarse.

Sales Ops siempre ha sido dueño del significado de esas definiciones. Pero cuando las definiciones vivían en un informe, el costo de la ambigüedad era un número confuso. Ahora el costo es un flujo de trabajo ejecutado. La superficie de gobernanza acaba de expandirse, y entender lo que significa actuar como operador de ventas con IA ya no es opcional.

La buena noticia: Sales Ops está bien posicionado aquí. Usted comprende el contexto que IT no comprende. Sabe qué división de territorio ocurrió en el tercer trimestre y todavía no se ha propagado completamente a la capa de datos. Sabe qué columna de quota es un campo heredado que nadie elimina pero que todos ignoran. Ese conocimiento institucional es exactamente lo que necesita una auditoría previa al despliegue.

La auditoría de 5 preguntas de Sales Ops

Ejecute estas preguntas antes de que cualquier usuario de negocio acceda a una interfaz de SnowWork.

1. ¿Quién es dueño de cada definición de métrica contra la que un agente podría escribir?

Comience con sus 10 KPIs principales: ingresos de cierre ganado, pipeline por etapa, cumplimiento de quota, asignación de territorio, pertenencia a segmento. Para cada uno, identifique quién actualizó la definición por última vez, dónde vive la definición (warehouse, CRM, hoja de cálculo, o las tres) y si esa persona todavía está en la empresa. Si no puede responder esas tres preguntas para una métrica, esa métrica no está lista para el acceso del agente. La higiene de datos del CRM asistida por IA es una condición previa, no algo deseable.

2. ¿Qué territorios, segmentos y quotas todavía viven en hojas de cálculo (no en Snowflake)?

SnowWork opera sobre lo que hay en el warehouse. Si su resegmentación de territorio del segundo trimestre todavía está en una hoja de Google pendiente de un ticket del equipo de datos, SnowWork no lo sabe. Un agente al que se le pide "optimizar la cobertura de territorio" optimizará contra datos del primer trimestre. Antes de habilitar SnowWork para los usuarios de ventas, audite la brecha entre su modelo de datos oficial y dónde viven realmente los datos de trabajo. La lógica de enrutamiento automatizado de leads y la reasignación de nivel de cuenta en tiempo real solo son tan buenas como los datos sobre los que se ejecutan.

3. ¿Cuál es la ruta de reversión cuando un agente reasigna incorrectamente un territorio o mueve una etapa del negocio?

Defínala antes de necesitarla. ¿Quién recibe la alerta? ¿Cuál es el proceso de reversión en Salesforce? ¿La escritura de vuelta al CRM desde la capa MCP de Natoma crea un evento de auditoría, o parece idéntica a una acción manual del representante? Una prueba útil: tome un error histórico de reasignación de territorio de los últimos 12 meses y analice cómo lo revertiría hoy. Luego compruebe si ese proceso sigue funcionando si el error provino de un agente en lugar de un humano.

4. ¿Cómo diferencia el acceso entre "puede leer" y "puede actuar", y dónde vive esa política?

El acceso de lectura y el acceso de acción son superficies de riesgo diferentes. Un representante de ventas leyendo un informe de pipeline es estándar. Un representante usando SnowWork para generar una presentación es un pequeño paso más. Un representante usando SnowWork para reasignar cuentas o mover etapas del negocio es un paso mucho mayor. La capa de gobernanza de Natoma agrega la aplicación de políticas, pero alguien tiene que escribir la política. Eso corresponde a Sales Ops, no a IT. La clasificación de datos para acceso de IA ofrece un framework para establecer niveles. Mapee sus objetos de Snowflake a niveles de acceso antes de que comience el primer piloto.

5. ¿Cuál es el registro de auditoría cuando un negocio avanza de etapa porque un agente lo sugirió?

Esta pregunta importa por dos razones. Primera, precisión del forecast: si el movimiento de un agente infla o deflacta un recuento de etapas, necesita saberlo. Segunda, coaching: si un negocio avanza de etapa porque un agente lo sugirió y un representante hizo clic en aceptar, esa es una conversación de coaching diferente a la de un representante que tomó la decisión de forma independiente. Los registros de auditoría para acciones ejecutadas por IA no son infraestructura opcional. Son la forma de mantener la responsabilidad en un sistema donde humanos y agentes comparten un flujo de trabajo.

Preguntas frecuentes

¿Qué es el Proyecto SnowWork de Snowflake?

SnowWork es la plataforma de IA agéntica de Snowflake, lanzada en vista previa de investigación en marzo de 2026. Permite a los usuarios de negocio ejecutar flujos de trabajo autónomos de múltiples pasos directamente sobre datos gobernados de Snowflake, sin escribir código ni involucrar a un equipo de datos. Los usuarios interactúan con una interfaz adaptada al rol que comprende la terminología y los KPIs típicos de su función. Para Sales Ops, eso significa que tareas como el análisis de territorio, los informes de pipeline y la generación de presentaciones pueden ser activadas por un usuario de negocio en lugar de un ingeniero de datos.

¿En qué se diferencia SnowWork de una herramienta de BI habitual o de un informe de CRM?

Una herramienta de BI lee datos y devuelve una visualización. Un informe de CRM extrae una instantánea filtrada. SnowWork planifica y ejecuta flujos de trabajo. Puede encadenar múltiples pasos, escribir de vuelta en los sistemas a través de la capa de gobernanza MCP (Model Context Protocol) de Natoma, y producir outputs como presentaciones o acciones de reasignación, no solo gráficos. La distinción importa porque el modo de fallo cambia: un gráfico de BI incorrecto es un gráfico incorrecto. Un flujo de trabajo de SnowWork incorrecto es una acción incorrecta tomada contra sistemas en producción.

¿Debería Sales Ops permitir que los usuarios de negocio usen SnowWork directamente?

Sí, pero no todavía, y no sin la auditoría. Las cinco preguntas anteriores no son una lista de verificación para retrasar la adopción. Son la diligencia debida mínima antes de permitir que un agente actúe sobre datos que su equipo gestiona. Los usuarios que más se beneficiarán de SnowWork, representantes de ventas, gerentes de ventas y analistas de operaciones, encontrarán ahorros de tiempo genuinos. El riesgo no es la herramienta. Es abrir una puerta antes de saber qué hay detrás.

Qué hacer esta semana

• Diseñe un piloto de una semana con un equipo, un flujo de trabajo y una prueba de reversión. El flujo de trabajo ideal para el piloto es uno que actualmente lleva a un representante entre 30 y 60 minutos y produce un único entregable (un informe de territorio, un deck de forecast, una lista de cuentas). Ejecute la versión del agente en paralelo con la versión manual y compare los resultados.
• Audite la propiedad de las definiciones de métricas para los 10 KPIs principales que Sales Ops reporta. Para cada métrica: quién es dueño de la definición, dónde vive y si está completamente cargada en Snowflake o todavía está atrapada en una hoja de cálculo.
• Establezca una prueba de reversión antes de que comience su piloto. Elija la acción más arriesgada que su flujo de trabajo piloto podría tomar (la que tiene más consecuencias aguas abajo si es incorrecta) y confirme que la ruta de reversión funciona. Luego documéntela.
• Inicie la conversación sobre niveles de acceso con su equipo de datos ahora. La capa de gobernanza de Natoma le da a Snowflake la infraestructura para aplicar la política de acceso. Sales Ops necesita definir cuál es realmente la política. Esa conversación lleva más tiempo que un sprint. Iníciela antes de estar bajo presión.

Más información

• Qué es un operador de ventas con IA
• AI Sales Ops vs. Sales Ops tradicional
• Por qué Sales Ops tiene el caso de uso de IA con mayor ROI
• De la llamada a la actualización del CRM de forma automática
• Las empresas no alcanzan sus objetivos de ingresos pese al gasto en IA y datos
• Agentes de OpenAI en Salesforce y Slack