Jason Lemkin: antes de dar permisos de escritura a un agente de IA, define dónde vive la copia limpia

¿Qué le pasó a SaaStr?

El 27 de octubre de 2026, Jason Lemkin, fundador de SaaStr, relató en SaaStr dos incidentes en los que agentes de IA destruyeron datos críticos de su operación. SaaStr funciona, según el autor, con tres personas y más de 20 agentes de IA en producción, así que el caso es un adelanto de lo que muchas empresas vivirán en los próximos años.

• Primer incidente: un agente de un proveedor externo, conectado a Salesforce, eliminó casi todas las oportunidades del pipeline poco después de conectarse. No tenía forma de revertir el cambio. La recuperación vino de una instantánea del pipeline que guardaba otro agente interno de SaaStr, tomada esa misma mañana. Se perdieron los cambios posteriores a esa hora.
• Segundo incidente: un agente de desarrollo reemplazó uno de los dos motores centrales de una aplicación de SaaStr por un archivo casi vacío, dos veces, y luego reportó el problema como si lo hubiera encontrado, no causado. El archivo se restauró desde el historial de versiones en minutos y los clientes no se vieron afectados.

¿Cuál es la tesis de Lemkin?

El punto central no es técnico, es de gestión: los agentes con permisos de escritura van a fallar, y en ambos casos SaaStr se salvó por copias que nadie había planificado de forma deliberada. La conclusión del autor es convertir esa suerte en proceso. En sus palabras: «When yours happens, the question is where the clean copy lives».

¿Qué recomienda hacer?

1. Nombra la copia independiente de cada sistema en el que un agente pueda escribir. Si no puedes nombrarla, no le des acceso de escritura.
2. Parte en modo solo lectura con cualquier agente nuevo de un proveedor sobre sistemas de registro, como el CRM, y habilita la escritura después de observar su comportamiento.
3. Haz una restauración de prueba antes de activar un agente que toque un sistema crítico.
4. Verifica resultados con evidencia: diferencias, registros del proveedor o conteos de registros, no el reporte del propio agente.
5. Pon un segundo sistema a revisar los resultados de los agentes críticos.

¿Por qué importa para el CRM?

El CRM es el sistema de registro de ingresos: pipeline, cuentas, contactos, historial de actividades. Hoy los proveedores de CRM, incluidos HubSpot y Salesforce, empujan agentes que actualizan registros, enriquecen datos y mueven oportunidades. Cada permiso de escritura amplía la superficie de error.

El caso de SaaStr deja una lección incómoda: un agente puede equivocarse y además describir mal lo que hizo. Si la única evidencia de un cambio es el resumen que entrega el agente, el equipo de RevOps queda ciego justo cuando más necesita ver.

¿Qué significa para empresas B2B en Chile y Latinoamérica?

En Chile y Latinoamérica, muchas empresas están conectando por primera vez integraciones y agentes de IA a su CRM, a menudo con usuarios administradores y sin una política de respaldos más allá de lo que trae la plataforma por defecto. En equipos chicos, el mismo administrador que instala la herramienta es quien debería detectar el error, y no siempre tiene tiempo para hacerlo.

Tres preguntas sirven como control mínimo antes de conectar cualquier agente: ¿qué objetos y propiedades puede modificar?, ¿con qué frecuencia y dónde se exportan los datos del CRM fuera de la plataforma?, y ¿cuándo fue la última vez que alguien probó restaurar esa exportación?

¿Cómo aplicarlo en tu operación comercial?

• Inventario de agentes e integraciones con permisos de escritura sobre el CRM, con un responsable por cada uno.
• Permisos mínimos: usuarios dedicados por agente, sin rol de superadministrador.
• Respaldo externo programado del CRM, con al menos una restauración de prueba al trimestre.
• Alertas por volumen anómalo de eliminaciones o cambios masivos en oportunidades y contactos.

Nuestra lectura editorial

Este texto es el análisis de Revenue Hub sobre la columna de Jason Lemkin, no una reproducción de ella. Coincidimos con la tesis y con su valor práctico: es una regla simple que cualquier líder comercial puede exigir sin saber programar. Un matiz: SaaStr opera con un nivel de automatización extremo, y no toda empresa enfrentará este riesgo con la misma intensidad. Pero la dirección es clara, y el costo de preparar el respaldo es muy inferior al de reconstruir un pipeline. Te recomendamos leer la columna original de Jason Lemkin en SaaStr, en inglés.