Pilar 01 · Salesforce Blog

Piloto de Agentforce: dónde el 90% se estanca y qué hace el 10% distinto

Menos del 10% de los propios clientes de Salesforce que probaron Agentforce escaló el agente más allá del piloto. El número no viene de un competidor ni de un analista escéptico — viene de un análisis de mercado que cruzó datos reales de adopción con el discurso comercial de la propia plataforma. La mayoría de las empresas que firma el piloto nunca llega a la segunda fase.

El patrón no es exclusivo de Agentforce. Un relevamiento de marzo de 2026 con 650 líderes de tecnología empresarial encontró que el 78% de las empresas ya corre al menos un piloto de agente de IA — pero solo el 14% escaló un agente a uso organizacional real. La diferencia entre esos dos números es el embudo más caro de 2026: no el costo de probar un agente, sino el costo de nunca decidir si se convierte en operación.

El síntoma: el piloto se aprueba, la producción nunca llega

El patrón se repite en casi todo piloto de Agentforce que se estanca: el equipo técnico aprueba el agente porque se comportó bien dentro del alcance probado, alguien presenta el resultado en una reunión, todos coinciden en que "funcionó" — y el proyecto se detiene exactamente ahí. No porque el agente falló. Porque nadie decidió, antes de empezar el piloto, qué tenía que ser verdad para que saliera de la prueba de concepto.

El informe Tech Trends 2026 de Deloitte documenta la escala del problema: el 89% de los pilotos de agentes de IA falla antes de llegar a producción, y solo el 11% cruza esa línea. La causa no es el modelo de lenguaje detrás del agente — es la ausencia de un camino definido entre "el piloto funcionó" y "esto ahora corre todos los días, con alguien responsable de ello". Sin ese camino, un piloto que funcionó bien simplemente no tiene adónde ir.

El piloto no fracasa cuando el agente se equivoca — fracasa cuando nadie decidió, antes, qué tenía que ser verdad para que saliera de la prueba de concepto.

Cinco a once meses reales, contra tres a seis semanas prometidas

La primera fuente de fricción es la distancia entre lo que promete la propuesta comercial y lo que exige la operación real. Salesforce vende ciclos de implementación de tres a seis semanas. Un análisis independiente de proyectos reales de Agentforce en 2026 sitúa el tiempo hasta producción — con un integrador de sistemas involucrado en la mayoría de los casos — entre 5 y 11 meses.

Esa distancia no es exageración de vendedor ni lentitud del cliente. Es el tiempo que el rediseño de proceso realmente consume — tiempo que la propuesta de tres a seis semanas nunca incluyó como etapa. El mismo patrón ya apareció en la promesa de implementación de Salesforce en seis semanas: el plazo corto cubre la configuración técnica, no el cambio de proceso que decide si el proyecto se sostiene.

  1. Semanas 1 a 4 (lo que cubre la propuesta). Configurar el agente, conectar la fuente de datos, validar en un entorno controlado con un caso de prueba curado.
  2. Meses 2 a 6 (lo que la propuesta no cubre). Rediseñar quién aprueba qué cuando el agente actúa solo, decidir dónde la revisión humana sigue siendo obligatoria, capacitar a quien va a operar el agente día a día — no solo a quien lo va a monitorear.
  3. Meses 6 a 11 (donde se estanca la mayoría). Formalizar un dueño del agente, montar infraestructura de evaluación continua, aprobar presupuesto de mantenimiento recurrente — ninguna de estas tres etapas está en la propuesta original, y las tres son requisito para salir del piloto.

Lo que se estanca no es el agente — es el proceso a su alrededor

El piloto de Agentforce corre, casi siempre, sobre un recorte controlado de la operación: datos curados por el propio equipo, herramienta estable y revisión humana de cada salida antes de que se convierta en acción — las mismas tres condiciones que la producción elimina, una a la vez, a medida que el agente escala. Un piloto exitoso mide competencia en una tarea conocida. No mide si la empresa rediseñó el proceso a su alrededor lo suficiente como para soportar al agente decidiendo solo, a escala.

Aquí es donde la mayoría de las empresas confunde dos problemas distintos. El primero — si el agente funciona técnicamente — el piloto ya lo respondió. El segundo — quién aprueba qué cuando el agente se equivoca, quién tiene autoridad para pausarlo, quién responde por el resultado — normalmente ni siquiera se llegó a preguntar. Sin una persona formalmente responsable del agente desde el primer día hasta la baja, la decisión de escalar se queda sin quien la tome — y el piloto muere de inanición, no de rechazo formal.

La parte de gobernanza del problema es medible: solo el 21% de las empresas reporta tener un modelo de gobernanza maduro para IA agéntica, según el mismo informe de Deloitte. Gobernanza aquí no significa comité ni política escrita guardada en la intranet — significa una decisión previa sobre dónde el agente puede actuar solo, dónde necesita aprobación humana, y quién revisa esa frontera a medida que el agente gana alcance nuevo. La empresa que trata a un agente autónomo como si fuera un dashboard — lo sube, lo aprueba, lo olvida — descubre la brecha recién después del primer incidente visible.

Lo que el 10% hace distinto

El grupo minoritario que escala no tiene acceso a tecnología distinta del resto — el modelo detrás de Agentforce es el mismo para todo cliente. La diferencia es operativa, y se repite en cuatro puntos:

  1. Nombran un dueño del agente antes de aprobar el piloto, no después. La pregunta "quién responde por esto cuando salga mal" tiene respuesta definida antes de que el primer caso real pase por el agente — no se debate en una reunión de crisis después del primer error visible.
  2. Rediseñan el flujo de aprobación, no solo configuran el agente. Deciden, por categoría de decisión, dónde el agente actúa sin intervención y dónde la revisión humana sigue siendo obligatoria — en vez de mantener el proceso de aprobación idéntico al de antes e insertar el agente en el medio.
  3. Construyen evaluación continua antes de necesitarla. Miden la tasa de acierto del agente en producción, no solo el día de la demostración — la misma disciplina que falta en la mayoría de los informes de IA hoy.
  4. Presupuestan el mantenimiento recurrente desde el piloto. Saben, antes de aprobar la siguiente fase, que un agente en producción consume revisión de prompt, actualización de herramientas y ajuste de alcance de forma continua — no es un proyecto que termina cuando el piloto "funciona".

Ninguno de los cuatro puntos exige una función nueva de la plataforma. Exige una decisión organizacional tomada mientras el piloto todavía está corriendo — no después de que ya probó que funciona técnicamente y nadie sabe el siguiente paso.

Escalar no es suerte — es una decisión que alguien tiene que tomar

El piloto que nunca se convierte en producción no es, en la mayoría de los casos, un piloto que fracasó. Es un piloto que funcionó lo suficientemente bien como para no morir — y no estuvo definido lo suficiente como para que alguien decidiera escalarlo. Mientras tanto, la demanda comercial por Agentforce sigue creciendo: los contratos pagos crecieron 50% trimestre contra trimestre en el tercer trimestre fiscal de 2026, señal de que la conversión de piloto a contrato real está sucediendo — solo que concentrada en una porción pequeña de clientes que resolvió el problema organizacional antes de pedir el próximo presupuesto.

La pregunta que decide si una empresa se queda en el 90% o entra al 10% no es técnica. Es si alguien, antes de que terminara el piloto, asumió la responsabilidad de decidir qué tenía que ser verdad para que saliera de la prueba de concepto.

Preguntas que siempre vuelven

Para cerrar, las dudas más comunes sobre por qué los pilotos de Agentforce no llegan a producción.

¿Por qué la mayoría de los pilotos de Agentforce no se convierte en producción?

Porque el piloto mide si el agente funciona técnicamente dentro de un alcance controlado — datos curados, herramienta estable, revisión humana de cada salida — y no mide si la empresa rediseñó su proceso de aprobación, nombró un dueño formal y presupuestó el mantenimiento recurrente que exige la operación real. Menos del 10% de los propios clientes de Salesforce escala más allá de esa fase, y el motivo más citado en investigaciones de 2026 es organizacional, no técnico: no existe un camino definido entre "el piloto funcionó" y "esto ahora es parte de la operación diaria".

¿Cuánto tiempo tarda realmente un piloto de Agentforce en llegar a producción?

Entre 5 y 11 meses, según análisis independiente de proyectos reales — bastante más allá de las 3 a 6 semanas que suele anunciar la propuesta comercial, y casi siempre con un integrador de sistemas involucrado. El plazo corto cubre la configuración técnica; el tiempo adicional lo consume el rediseño de proceso, la definición de un dueño del agente y la construcción de evaluación continua — etapas que rara vez aparecen en la propuesta inicial.

¿Qué cambia entre una empresa que escala el agente y una que se estanca en el piloto?

Cuatro prácticas concentran la diferencia: nombrar un dueño del agente antes de aprobar el piloto (no después de un incidente), rediseñar el flujo de aprobación por categoría de decisión en vez de mantener el proceso antiguo con el agente encajado en el medio, medir la tasa de acierto del agente de forma continua en producción, y presupuestar el mantenimiento recurrente desde la fase de piloto. Ninguna de estas prácticas depende de una función nueva de la plataforma — dependen de una decisión organizacional tomada mientras el piloto todavía está corriendo.

Continuar la conversación

¿Quieres discutir este tema con un socio?

Diagnóstico inicial sin compromiso. Hacemos una primera lectura de tu escenario en una semana y devolvemos un informe.

Hablar con un socio