Tu IA no debería tocar un dato real de un cliente la primera vez que lo intenta de verdad. Parece obvio dicho así, y aun así es justo lo que falla cuando alguien conecta un agente a un ERP o un CRM con prisa: el día que por fin escribe, escribe en caliente, sin haber visto antes qué iba a cambiar. En AutoBoost nos topamos con el mismo riesgo al revisar un cambio de fondo en nuestro propio sistema de gestión de clientes y colaboradores, y la solución que aplicamos es una regla que vale para cualquier IA, script o proceso automático al que le vayas a dar permiso de escritura sobre datos reales.
El cambio: reorganizar datos reales sin poder permitirte un fallo a mitad
Necesitábamos reestructurar cómo se organizan los proyectos y las bolsas de horas de nuestros clientes: añadir un código propio por cliente, guardar el historial de horas de cortesía que se regalan de vez en cuando, y permitir bolsas facturables por hora además de por paquete cerrado. Nada de esto se podía probar en un entorno de mentira y ya está: el cambio tenía que aplicarse sobre la base de datos real, con clientes y colaboradores usando el sistema en ese mismo momento.
El riesgo no era que el cambio estuviera mal diseñado. El riesgo era que un fallo a mitad de la ejecución dejara el sistema en un estado intermedio: con las columnas nuevas a medio rellenar, con proyectos fusionados que no deberían haberlo sido todavía, o con código nuevo leyendo una estructura que el paso anterior no había terminado de preparar. Ese tipo de fallo no avisa con un error claro. Avisa con datos raros que alguien descubre días después, cuando ya es mucho más caro de deshacer.
La regla: ensayo por defecto, escritura solo si lo pides explícitamente
Dividimos el cambio en dos pasos, y le dimos a cada uno una propiedad que no es negociable: por defecto, el script que ejecuta cualquiera de los dos pasos no escribe nada. Solo lee la base de datos real y muestra, para cada cliente y cada proyecto, exactamente qué cambiaría si se le dejara escribir. Hace falta pasarle una marca explícita para que pase del modo "te enseño lo que haría" al modo "lo hago de verdad".
Los dos pasos, en orden:
- Paso 1, solo añade. Crea las columnas nuevas y las rellena a partir de lo que ya existía, sin tocar ni borrar nada de lo que ya funcionaba. Si este paso falla a mitad, el sistema sigue funcionando exactamente igual que antes, porque no ha quitado nada.
- Paso 2, depende del código nuevo ya desplegado. Fusiona proyectos y elimina lo que ha quedado obsoleto, y solo se ejecuta cuando el código que depende del paso 1 ya está en producción y funcionando. Nunca se lanzan los dos pasos juntos, aunque técnicamente se pudiera.
La clave no es la herramienta ni el lenguaje del script. Es que el modo por defecto es el seguro, y hay que pedir explícitamente el modo peligroso. Y que el paso que depende de otro espera su turno, en vez de confiar en que "seguramente ya está listo".
Por qué esto no es solo una anécdota de ingeniería interna
Esta misma regla es la que debería cumplir cualquier IA a la que le das acceso de escritura sobre un sistema real, no solo un script de migración puntual. Un agente de IA que cotiza, factura o actualiza inventario dentro de tu ERP está haciendo, en pequeño y todos los días, lo mismo que hace una migración: lee un estado, decide un cambio, y lo escribe. Si no puedes ver antes qué va a escribir, estás confiando en que acierte siempre a la primera, y ningún agente lo hace siempre.
En el comercial de IA que construimos para una distribuidora industrial con más de 50.000 productos en catálogo, el agente valida primero quién es el cliente, comprueba el stock real y aplica la tarifa que le corresponde antes de crear la oportunidad o el pedido de verdad dentro de Odoo (puedes ver el caso completo en comercial de IA en el ERP). Esa secuencia de validaciones es, en el fondo, el mismo "ensayo antes de escribir" aplicado a cada mensaje, no solo a una migración que se corre una vez.
Checklist antes de dar permiso de escritura a una IA sobre datos reales
Antes de dejar que un agente de IA (o cualquier proceso automático) escriba en tu ERP, tu CRM o tu base de datos de clientes, estas son las preguntas que nos hacemos en AutoBoost:
| Pregunta | Por qué importa |
|---|---|
| ¿Tiene un modo "solo simular" que muestre qué cambiaría sin tocar nada? | Si no puedes ver el cambio antes de que pase, el primer error real lo descubres tú, no la simulación. |
| ¿Hace falta una marca explícita para activar la escritura? | El modo seguro tiene que ser el que pasa si no se dice lo contrario, nunca al revés. |
| Si el cambio tiene varios pasos, ¿el que depende de otro espera a que el primero esté en producción? | Lanzar dos pasos dependientes a la vez multiplica el daño de cualquier fallo a mitad. |
| ¿El paso que solo añade se puede revertir sin pérdida, si algo sale mal? | Un paso que solo añade (nunca borra ni fusiona) deja siempre un camino de vuelta. |
| ¿Alguien ha mirado la simulación con datos reales antes de autorizar la escritura, o se confía en que "probablemente está bien"? | La simulación solo vale si alguien la lee antes de decir que sí. |
Si tu respuesta a la primera o la segunda pregunta es "no", no es que tu IA vaya a fallar seguro. Es que, si falla, no hay nada entre el fallo y tus datos reales.
Cómo lo aplicamos en AutoBoost
Nuestro enfoque es que la IA aporte donde aporta, y el código haga de guardarraíl donde hace falta: primero se ordena el dato y se blinda el proceso, y solo entonces se deja que la IA actúe sobre él con permiso de escritura. Lo aplicamos tanto en nuestros propios sistemas internos como en los agentes de IA que integramos en el ERP, el CRM o la contabilidad de nuestros clientes, con la misma plataforma de datos que ya usamos para que una IA razone sobre más de un millón de líneas de venta de un grupo de farmacias y reconstruya cifras que el sistema original calculaba mal (puedes ver el caso en plataforma de datos e IA controller).
Si estás evaluando dar acceso de escritura a una IA sobre tu sistema real y no tienes claro si hoy tiene un modo de ensayo de verdad o solo la promesa de que "funciona bien", cuéntanos tu caso y lo revisamos contigo.
