Cuando alguien se plantea cancelar un servicio de IA, la primera pregunta que suele hacerse no es la que de verdad le va a doler. Ya hemos explicado qué pasa con tus datos si cancelas un servicio de IA desde el punto de vista del RGPD: portabilidad, borrado, plazos por contrato. Ese artículo responde a "¿me devuelven mis datos?". Este responde a una pregunta distinta y más incómoda: el lunes siguiente a la cancelación, ¿qué deja de funcionar en tu operación diaria, aunque tengas el export de datos perfectamente guardado en un disco duro?
De qué está hecho realmente un "histórico de trabajo"
Cuando una empresa lleva meses usando un agente de IA o un proceso automatizado, acumula mucho más que "datos" en sentido estricto. Acumula cuatro capas distintas, y cada una se comporta de forma diferente al cancelar:
- Registros brutos: conversaciones, tickets, documentos procesados. Esto es lo que normalmente cubre un export en CSV o JSON.
- Reglas de negocio afinadas con el uso: excepciones, matices y ajustes que el equipo fue introduciendo a lo largo de meses porque la realidad no encajaba con la configuración inicial. Rara vez está en un documento aparte; suele vivir dentro de la plataforma del proveedor.
- Cuadros de mando e informes históricos: gráficas y análisis construidos sobre esos datos, que no siempre son exportables como tales, aunque los datos de origen sí lo sean.
- Integraciones activas: conexiones con tu CRM, tu ERP o tu sistema de facturación que dejan de recibir información en el instante en que se apaga el servicio, aunque el propio dato exportado esté a salvo.
Un export de datos completo y bien hecho suele cubrir bien la capa 1 y, si el proveedor es serio, parte de la 2. Las capas 3 y 4 son las que casi nunca se planifican con antelación, y las que más fricción generan el día después.
Qué deja de funcionar el mismo día, aunque tengas todos tus datos
Imagina que cancelas un agente que lleva ocho meses gestionando la clasificación automática de tus facturas de proveedores. Tienes el export completo de facturas procesadas. Aun así, esa misma tarde: el flujo que enviaba automáticamente cada factura clasificada a tu contabilidad se detiene, el informe semanal que llegaba a dirección deja de generarse, y la persona que antes hacía esa tarea a mano ya no tiene el proceso documentado porque llevaba meses sin necesitarlo. Ninguno de estos tres problemas se resuelve teniendo los datos exportados; se resuelven teniendo un plan de continuidad operativa, que es un documento distinto al informe de portabilidad de datos.
La diferencia entre "tener tus datos" y "poder seguir operando"
Aquí está el matiz que se suele pasar por alto: la ley te garantiza el acceso a tus datos, no la continuidad de tu operación. Un proveedor puede cumplir al cien por cien con sus obligaciones de portabilidad y borrado, entregarte todo en el formato correcto y en el plazo pactado, y aun así dejarte sin capacidad de operar con normalidad si nadie preparó el traspaso del conocimiento operativo que ese servicio absorbió con el tiempo. Portabilidad de datos y continuidad de negocio son dos cosas distintas que conviene planificar por separado, no dar por resueltas con el mismo documento.
Cómo planificar la continuidad antes de cancelar, no después
Si estás valorando dar de baja un servicio de IA, hazlo con este orden:
- Documenta las reglas afinadas, no solo el resultado. Pide al proveedor, o reconstruye internamente, un resumen de las excepciones y ajustes que se han ido incorporando desde el arranque.
- Identifica quién asumirá cada tarea el día después. Si el proceso vuelve a ser manual, alguien tiene que saber ejecutarlo; si pasa a otro sistema, ese sistema debe estar probado antes, no después, de cortar el anterior.
- Exporta también los informes, no solo los datos crudos. Si tu equipo usa un cuadro de mando semanal para tomar decisiones, pide esa vista consolidada además de la tabla de datos que la alimenta.
- Prueba las integraciones nuevas en paralelo antes del corte, siguiendo la misma lógica que explicamos en cómo migrar de proveedor de IA sin perder el histórico, aunque en este caso no migres a otro proveedor sino que vuelvas a un proceso interno o simplemente cierres esa automatización.
Cuándo tiene sentido cancelar igualmente
Nada de esto significa que cancelar sea siempre un error o que haya que aplazarlo indefinidamente. Hay procesos que dejaron de tener sentido, servicios que se contrataron para una necesidad puntual ya resuelta, o proveedores con los que la relación simplemente no funciona. La diferencia entre una cancelación bien gestionada y una mala no está en si se cancela, sino en si alguien se sentó antes a responder estas preguntas con tiempo suficiente para actuar, en vez de descubrir las respuestas el mismo día del corte.
Un margen razonable para hacerlo bien suele ser de dos a cuatro semanas entre la decisión de cancelar y el corte efectivo del servicio, tiempo suficiente para documentar reglas, avisar a quien asumirá cada tarea y probar cualquier alternativa antes de depender de ella en producción. Cancelar de un día para otro, aunque el contrato lo permita, es casi siempre la parte más cara de todo el proceso, no por lo que cuesta el servicio, sino por las horas de improvisación que genera después.
Conclusión
El histórico de trabajo de un servicio de IA es mucho más que los datos que un export te puede entregar: incluye reglas afinadas con meses de uso, informes construidos sobre esos datos y procesos internos que dejaron de documentarse porque la automatización los cubría. Planificar la continuidad de esas tres cosas, antes de firmar la baja, es lo que separa una cancelación ordenada de una semana de improvisación. En MG Solutions ayudamos a nuestros clientes a documentar desde el primer día lo que necesitarían para operar sin fricción si algún día deciden cambiar de rumbo. Reserva una primera reunión si estás valorando dar de baja un servicio y quieres hacerlo bien.