Los cuatro jinetes del DELETE
Hay errores de código que rompen una pantalla, y errores de datos que rompen una empresa. La diferencia: los primeros se ven y se arreglan; los segundos a veces no tienen arreglo. Los cuatro patrones de este OA han borrado bases de datos reales de startups, agencias y tiendas —todos construidos con IA, todos precedidos de un «¿qué puede pasar?». Ninguno requiere maldad: solo confianza sin protocolo.
La anatomía del desastre
- Borrado sin red
DELETE FROM pedidos sin WHERE: la IA «limpió datos de prueba» y se llevó todo. Sin condición = toda la tabla.
- Correr sin copia
el script era correcto… y tocó producción sin respaldo previo. Un error del 1 % con consecuencia del 100 %.
- Debug en producción
«déjame probar el fix directo en la base real». Lo que se prueba en producción, en producción queda.
- Domino de dependencias
borró los «registros huérfanos»… que eran los históricos que los reportes y las facturas ya emitidas necesitan.
Por qué la IA los comete (y por qué no es su culpa)
| Error | Qué le pasó al modelo | Qué faltó del lado humano |
|---|---|---|
| DELETE sin WHERE | la petición fue «limpiar los datos de prueba»; el modelo priorizó la acción sobre la conservación | criterio de listo con límite explícito: «solo los 12 registros de la tabla _test, muéstrame cuáles antes» |
| Correr sin copia | el script que pidió «ejecutar» era suyo y parecía correcto | el protocolo no delegable: copia ANTES de ejecutar (M11), sin excepción por urgencia |
| Fix en producción | no hay noción de entorno: «la base» es una para el modelo | exigir entorno de prueba con copia de datos y solo aplicar ahí el fix verificado |
| Domino | ve la tabla, no ve quién la lee: las dependencias están en código que no abrió | preguntar antes de borrar «quién lee esto» es pregunta de humano: la respuesta cambia la definición de «huérfano» |
El protocolo anti-letal (pégalo en tu maestro)
Cinco pasos: el primero y el último son de lenguaje, no de tecnología
PROTOCOLO PARA CUALQUIER OPERACION QUE PUEDA BORRAR O MODIFICAR DATOS EN MASIVA:\n\n1. ENUMERAR: muestra las filas afectadas con su COUNT y una muestra de 10. Si el numero\n no coincide exactamente con mi expectativa, PARO aqui.\n2. RESPALDO: copia de la base (o de las tablas afectadas) verificada antes de ejecutar.\n Sin evidencia de copia restaurable, no hay ejecucion. Sin excepciones por urgencia.\n3. ENTORNO: se ensaya en copia con datos reales. La produccion solo ve el paso 5.\n4. REVERSA: cada paso destructive tiene su paso de vuelta escrito. Si no lo hay, el\n paso se divide hasta que lo haya o se jubila en vez de borrarse (M17-OA03).\n5. EN PRODUCCION: ejecuta UN paso, detente, muestra verificacion, espera mi ok.\n\nY antes de cualquier "limpieza": ¿quien lee estos datos? Reporta dependencias.\nLo historico nunca es basura: es sentencia de los reportes viejos.Para reforzar
Prueba
La IA te entrega un script «para limpiar los 12 registros de prueba». La primera revisión es: ¿aplica el protocolo? ¿Qué verificas ANTES de dejarlo correr?
Borrar registros «huérfanos» —los que no tienen relación activa— es siempre seguro porque nada los usa.
Detecta la confianza letal
Cinco escenas de alumnos con la IA y sus bases. Señala la que termina en pérdida de datos irrecuperable:
Marca la línea o las líneas con error y pulsa Comprobar.
Escribe el protocolo anti-letal como sección fija de tu documento maestro, y aplica su pregunta de dependencias hoy a un dato que «ya no sirve» en tu proyecto (o en uno ficticio): ¿quién lo lee? Si la respuesta es «no sé», acabas de encontrar por qué el protocolo existe.
Los datos que se pierden casi nunca fueron atacados: fueron "limpiados".
Tu texto se guarda sólo en este dispositivo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.