Por qué una automatización puede decir "completado" y aun así perder tus datos

Una automatización puede marcar "completado" aunque el trabajo haya quedado mal hecho, porque casi todas comprueban que el proceso terminó y casi ninguna comprueba que el resultado sea correcto. Me pasó con mi propio respaldo: copió la base de datos sin un solo error, y al compararla con el original a una tabla le faltaban 22 de sus 316 registros. No es un problema raro ni exclusivo de empresas chicas. Según el informe de Kaseya de 2025, el 60% de los profesionales de TI encuestados creía poder recuperarse en menos de un día, y solo el 35% lo logró en la práctica.

Puntos clave

• "Terminó" y "está bien" son dos preguntas distintas. La mayoría de las herramientas solo responde la primera.
• Las fallas silenciosas no dejan errores: el estado dice OK, el archivo abre y el tamaño parece normal.
• Se detectan comparando lo que entró con lo que salió, y eso no requiere saber programar.

Qué es una falla silenciosa

Una falla silenciosa es cuando una automatización termina, reporta éxito y entrega un resultado incompleto o equivocado, sin ninguna alerta. Es más peligrosa que una caída. Cuando algo se cae, alguien se entera ese mismo día. Cuando algo falla en silencio, te enteras semanas después, casi siempre por un cliente.

La confusión viene de lo que significa "éxito" para una herramienta. Para Zapier, Make o un script programado, éxito quiere decir que cada paso corrió sin lanzar un error. No quiere decir que el correo llegó, que el registro quedó guardado o que la copia está completa. Esa distancia entre "corrió" y "funcionó" es donde se pierden los datos.

Hay otro detalle que vuelve todo más difícil de ver: muchas de estas fallas aparecen en automatizaciones que llevaban meses funcionando. Un campo cambia de nombre, un token vence, una dirección entra en una lista de rebote. Nadie tocó la automatización, así que nadie sospecha de ella.

El caso: mi respaldo decía que funcionaba

Uso algunas herramientas internas que construí para manejar mi estudio. Una guarda sus datos en SQLite, que es una base de datos contenida en un solo archivo. Antes de cambiar la forma en que esa herramienta guardaba la información quise tener un respaldo, y ya existía una función para eso: copiaba el archivo de la base a otra carpeta.

La copia terminó sin errores y con un tamaño creíble. Podría haberla dado por buena ahí mismo. En cambio, comparé seis tablas de la copia contra la base original. Cinco coincidían fila por fila. La de mensajes no: 316 en el original, 294 en la copia.

La explicación está en cómo trabaja SQLite en modo WAL (write-ahead logging). En ese modo, los cambios nuevos no se escriben de inmediato en el archivo principal. La documentación oficial lo explica así: el contenido original se conserva en el archivo de la base y los cambios se agregan a un archivo WAL separado. Más tarde, en un paso llamado checkpoint, esos cambios pasan al archivo principal.

Cuando medí, el archivo WAL tenía unos 2,3 MB de cambios que todavía no habían pasado. Mi respaldo copió el archivo principal y dejó el otro atrás. La documentación de SQLite advierte exactamente sobre esto: si separas la base de su archivo WAL, las transacciones ya confirmadas pueden perderse. Cuando después escribí una prueba para reproducir el problema, la copia vieja ni siquiera tenía una tabla que la prueba acababa de crear.

El arreglo tuvo cuatro partes:

1. Copiar a través de la base de datos y no del archivo. SQLite tiene un comando para esto, VACUUM INTO, que según su documentación genera una instantánea consistente de la base original, con los cambios pendientes incluidos.
2. Escribir primero una prueba que reprodujera el faltante y confirmar que fallaba con el código viejo. Una prueba que nunca falló no demuestra nada.
3. Hacer que cada respaldo corra una revisión de integridad y cuente las filas de cada tabla, para compararlo con el original en lugar de confiar a simple vista.
4. Guardar dos copias en dos discos distintos, todos los domingos, con una tarea programada.

Y una cosa que decidí no automatizar: borrar. Los respaldos viejos no se eliminan solos. Esa decisión la toma una persona.

Cinco formas en que una automatización reporta éxito sin hacer el trabajo

Mi caso fue técnico, pero el mismo patrón aparece en herramientas que usa cualquier negocio. Estos cinco salen de casos reales publicados en las comunidades de Zapier, Make y Shopify.

1. Un filtro deja de coincidir. En Make, un usuario documentó escenarios que terminan en "Success" sin haber escrito nada. Una de las causas: alguien renombró un campo en el origen y el filtro que dejaba pasar los datos dejó de coincidir. El escenario corre, no encuentra nada que pase el filtro y termina contento.

2. Una búsqueda devuelve cero resultados. Si un paso busca un registro y no lo encuentra, los pasos siguientes corren cero veces. Técnicamente no hubo error. En la práctica no pasó nada.

3. Un manejador de errores cierra la corrida como exitosa. Muchas herramientas permiten decir "si este paso falla, sigue". Es útil, pero si nadie revisa qué se saltó, la corrida queda registrada como exitosa con un paso perdido adentro.

4. El destino rechaza en silencio. En la comunidad de Zapier hay un caso de un envío de correos que funcionó un año y luego siguió marcando "successful" mientras los correos no llegaban. La dirección del destinatario había quedado en una lista de rebote. Pasa algo parecido con tokens vencidos: la herramienta envía, el otro lado rechaza, y el historial queda en verde.

5. Se copia algo incompleto. Es mi caso del respaldo, y también el de un dueño de tienda en Shopify cuyo formulario de contacto dejó de enviarle correos después de un año. Se enteró porque sus clientes empezaron a quejarse en redes de que nadie les respondía.

La brecha entre confianza y realidad

Los estudios muestran lo mismo desde el otro lado: la gente confía en sus sistemas más de lo que sus sistemas merecen.

Según Kaseya, que encuestó a más de 3.000 profesionales de TI en 2025, el 60% creía poder recuperarse en menos de un día y solo el 35% lo consiguió. Según el informe de Veeam de 2026, basado en más de 900 líderes de TI, seguridad y riesgo, el 90% de las organizaciones confía en su capacidad de recuperarse de un incidente, pero entre las que sufrieron ransomware solo el 28% recuperó todos sus datos. En promedio recuperaron el 72%.

En Latinoamérica aparece la misma brecha. El ESET Security Report 2025, con más de 3.000 personas de organizaciones de más de 15 países de la región, encontró que el 32% reconoce no tener herramientas para confirmar que no ha sido atacada. El mismo informe señala que el respaldo es la única medida de protección ampliamente implementada.

Conviene leer estas cifras con cuidado: casi todas vienen de empresas con equipos técnicos dedicados. Un negocio pequeño que usa un formulario, una herramienta de reservas y un respaldo en la nube suele tener menos control, no más, porque nadie tiene asignada la tarea de revisar.

W. Curtis Preston, que lleva décadas escribiendo sobre respaldos, lo resume en una frase: "A backup that fails silently is worse than no backup at all." Un respaldo que falla en silencio es peor que no tener respaldo, porque te hace dejar de preocuparte.

Cómo revisar tus automatizaciones sin saber programar

El libro de ingeniería de confiabilidad de Google (Site Reliability Engineering) recomienda dedicar mucho más esfuerzo a detectar síntomas que causas. Para un negocio, eso se traduce en algo concreto: no mires si la automatización dice OK, mira si pasó lo que tenía que pasar.

Ninguna de estas revisiones toma más de diez minutos. Lo difícil es acordarse de hacerlas, así que lo más útil es ponerlas en el calendario como cualquier otra tarea fija.

Antes de confiar en una automatización nueva, hazte tres preguntas. ¿Cómo me enteraría si deja de funcionar? Si la respuesta es "me avisaría un cliente", ya llegas tarde. ¿Qué revisa además de haber corrido? Si no revisa nada, agrégale una comparación. ¿Qué puede borrar o enviar por su cuenta? Eso último merece su propia sección.

Qué no deberías automatizar por completo

Automatizar la preparación de una tarea casi siempre conviene. Automatizar la decisión final no siempre.

Las acciones que no se pueden deshacer deberían esperar la confirmación de una persona: borrar datos, enviar dinero, cancelar una cuenta, mandar un mensaje a toda tu lista de clientes. Si una automatización hace eso mal, no hay revisión posterior que lo arregle.

En mi caso, la herramienta de respaldo copia, verifica y guarda sola, pero nunca borra. En otra herramienta que uso, el sistema prepara los mensajes y una persona decide cuáles se envían. Es un poco más lento y es a propósito.

FAQ

¿Por qué una automatización dice "completado" si falló?

Porque "completado" significa que todos los pasos corrieron sin lanzar un error. Un filtro que no deja pasar nada, una búsqueda vacía o un destino que rechaza en silencio no generan errores, así que la corrida se registra como exitosa.

¿Cómo sé si mi formulario de contacto está funcionando?

Envíate una consulta de prueba, idealmente desde un correo distinto al tuyo, y confirma que llega. Hazlo una vez al mes y cada vez que cambies algo del sitio o del correo.

¿Cada cuánto conviene probar un respaldo?

Con una frecuencia que de verdad vayas a sostener, y siempre después de un cambio importante en el sistema que protege. Probar significa abrir la copia y encontrar algo reciente, no solo ver que existe.

¿Zapier o Make avisan cuando algo sale mal?

Avisan cuando un paso lanza un error. No avisan cuando el resultado está vacío o incompleto, porque para la herramienta eso no es un error. Por eso hace falta una revisión del resultado.

¿Tengo que dejar de automatizar para estar seguro?

No. Conviene automatizar lo repetitivo y agregar una comprobación del resultado. Lo único que recomiendo dejar siempre en manos de una persona es lo irreversible.

Para cerrar

Una copia no es un respaldo hasta que la abriste, y una automatización no está funcionando hasta que algo comparó lo que recibió con lo que entregó. Si automatizaste partes de tu negocio y no sabes cómo te enterarías si una deja de funcionar, esa es la primera pregunta que vale la pena contestar. Si quieres una segunda mirada, puedes escribirme desde sendalogica.com.

Fuentes

1. SQLite — Write-Ahead Logging https://sqlite.org/wal.html
2. SQLite — VACUUM (VACUUM INTO) https://sqlite.org/lang_vacuum.html
3. Kaseya — State of Backup and Recovery Report 2025, 6 de febrero de 2025 https://www.kaseya.com/press-release/kaseya-report-outlines-top-trends-in-backup-and-recovery-in-2025/
4. Veeam — Data Trust and Resilience Report 2026, 14 de abril de 2026 https://www.veeam.com/company/press-release/veeam-report-reveals-a-market-wide-shift-from-recovery-confidence-to-proven-data-resilience-amid-ransomware-threats-and-ai-adoption.html
5. ESET — Security Report 2025 Latinoamérica, 30 de julio de 2025 https://www.welivesecurity.com/es/informes/eset-security-report-2025-ciberseguridad-empresas-latinoamerica/
6. W. Curtis Preston, Backup Central — Backup Systems all Need These 10 Things, 8 de diciembre de 2025 https://backupcentral.com/backup-systems-all-need-these-10-things/
7. Google — Site Reliability Engineering, cap. 6: Monitoring Distributed Systems https://sre.google/sre-book/monitoring-distributed-systems/
8. Comunidad de Make — A scenario can finish "Success" and still have written nothing https://community.make.com/t/a-scenario-can-finish-success-and-still-have-written-nothing-three-ways-it-happens/114177
9. Comunidad de Zapier — Send Outbound Email: zap successful but email not received by recipient https://community.zapier.com/troubleshooting-99/send-outbound-email-in-email-by-zapier-zap-successful-but-email-not-received-by-recipient-32654
10. Comunidad de Shopify — Contact form no longer sending emails https://community.shopify.com/t/contact-form-no-longer-sending-emails/415874