Bloqueo RFID contra borrados accidentales

La forma más rápida de arruinar un proyecto RFID bien organizado no siempre es una antena dañada, un lote defectuoso de tags o un lector con poca potencia. A veces, el problema empieza con un clic aparentemente inocente. Un técnico de IT abre el software de codificación RFID, selecciona la plantilla equivocada, pulsa escribir y, de pronto, un lote de etiquetas de activos que ya estaban asignadas a portátiles, servidores, herramientas o tarjetas de acceso deja de contener los datos correctos. Los tags siguen leyéndose. El hardware sigue funcionando. Pero la información que hacía útil cada tag ha sido sobrescrita, y ahora el equipo debe averiguar qué se perdió, qué registros siguen siendo fiables y cómo recuperar la confianza en el sistema.

Por eso el bloqueo de escritura RFID merece mucha más atención. No es una función vistosa. No impresiona en una demostración comercial. Nadie publica en LinkedIn capturas de bancos de memoria bloqueados. Sin embargo, para el seguimiento de activos IT, el control de hardware en centros de datos, los tags NFC seguros, las etiquetas inteligentes de inventario y los flujos de credenciales de acceso, el bloqueo de escritura es uno de esos controles silenciosos que evita que un pequeño error se convierta en una larga tarde de correcciones. En términos sencillos, le dice al tag, al lector y al software: estos datos no deben cambiarse sin control.

Qué significa realmente bloquear la escritura RFID

El bloqueo de escritura RFID no es un botón universal. El método exacto depende de la tecnología utilizada. En tags RFID UHF EPC Gen2, puede trabajar con memoria EPC, User Memory, TID, contraseñas de acceso y estados de bloqueo de memoria. En tags NFC, puede usar protección por contraseña, configuración de solo lectura, bits de bloqueo, bytes de bloqueo dinámico o chips seguros que controlan el acceso de otra manera. En tarjetas inteligentes MIFARE DESFire u otras tarjetas seguras, el acceso de escritura se vincula a claves, aplicaciones y permisos, no a un simple bloqueo de memoria pública. El principio, aun así, es el mismo: una vez codificados y verificados los datos correctos, se reduce la posibilidad de que herramientas comunes, operadores descuidados o plantillas incorrectas los sobrescriban.

Un departamento de IT hospitalario en Seattle lo aprendió después de etiquetar varios miles de activos móviles: bombas de infusión, tabletas, lectores de códigos de barras, monitores y carros inalámbricos. Los tags RFID UHF contenían un EPC serializado vinculado a la base de datos de activos del hospital, mientras que algunos tags también usaban User Memory para un código interno corto de categoría de equipo. Durante un proyecto de mantenimiento, un técnico reconfiguró una impresora codificadora RFID con una plantilla antigua de pruebas. Antes de que alguien lo notara, se imprimieron y codificaron unas 200 etiquetas de reemplazo con valores EPC duplicados. El hospital añadió entonces un paso de bloqueo de escritura después de la verificación. Desde ese momento, los tags se codificaban, se releían, se comprobaban contra el sistema de gestión de activos y luego se bloqueaban para que futuros trabajos de impresión no pudieran reescribir en silencio IDs ya aprobados.

Por qué los equipos IT necesitan bloqueo de escritura

Protección de la integridad de los datos

La primera razón por la que los profesionales de IT necesitan bloqueo de escritura es la integridad de los datos. La información RFID suele actuar como puente entre un objeto físico y un registro digital. Si cambia el ID del tag, el vínculo se rompe. Si se sobrescribe el tag de un portátil, ese portátil puede parecer otro dispositivo. Si se reescribe el tag de un rack, un servidor puede aparecer en el armario equivocado. Si un tag de activo retornable se sobrescribe con un código de prueba, el sistema de inventario puede tratar un activo real como un tag de demostración. El bloqueo de escritura protege la capa de identidad una vez confirmada.

Un operador de centro de datos en Frankfurt usaba etiquetas RFID en bandejas de servidores, switches de red, módulos de alimentación y discos de repuesto. El equipo codificaba cada tag con un EPC asignado a la base de datos de gestión de configuración. Durante una actualización de hardware de fin de semana, un contratista utilizó un lector RFID portátil con capacidad de escritura para probar un nuevo flujo de trabajo. El lector escribió por accidente un EPC genérico de prueba en varias etiquetas de discos de repuesto colocadas sobre el banco de trabajo. Los discos no sufrieron daños físicos, pero el historial de inventario quedó desordenado. Después del incidente, el operador separó los perfiles portátiles de solo lectura de los perfiles de codificación y bloqueó los tags de producción inmediatamente después de la puesta en servicio. Los contratistas podían leer tags, pero no podían modificar IDs aprobados.

Separar la lectura de la escritura

La segunda razón es el control de roles. No todas las personas que pueden leer tags RFID deberían poder escribir en ellos. En muchas empresas, personal de almacén, soporte IT, ingenieros de campo, auditores, equipos de seguridad y contratistas utilizan lectores RFID. Si cada dispositivo o aplicación tiene acceso de escritura, los errores son inevitables. El bloqueo de escritura ayuda a reforzar una idea básica: la codificación es un proceso controlado, no una función que cualquier sesión de lectura debería poder ejecutar. También debe combinarse con permisos de software, perfiles de dispositivo y formación de operadores.

Un centro IT en Austin gestionaba miles de portátiles corporativos para incorporación de empleados, reparación, devolución y baja. Cada portátil llevaba una pequeña etiqueta RFID UHF de activo vinculada al número de serie, asignación de usuario, estado de garantía y estado de cifrado. Al principio, los mismos lectores portátiles usados para inventario también podían escribir datos en los tags. Un empleado de soporte ejecutó por accidente una actualización por lotes sobre el conjunto equivocado de tags mientras probaba una nueva categoría de activos. El centro cambió el proceso. La codificación quedó limitada a dos estaciones controladas, mientras que los lectores portátiles diarios se configuraron en modo de solo lectura. Las etiquetas de producción se bloqueaban después de una coincidencia correcta con la base de datos. El resultado fue aburrido, exactamente lo que IT quería.

Reducir errores de plantilla

La tercera razón es la seguridad de las plantillas. Las impresoras codificadoras RFID y el software de codificación son potentes porque pueden producir cientos o miles de etiquetas rápidamente. Esa potencia se vuelve peligrosa cuando se carga la plantilla incorrecta. Una plantilla puede escribir un valor fijo en lugar de un valor serializado. Puede usar un esquema EPC equivocado. Puede escribir en User Memory en vez de hacerlo en la memoria EPC. Incluso puede borrar por accidente un campo que otro sistema necesita. El bloqueo de escritura no corrige una mala plantilla antes de producción, pero sí puede impedir que tags ya aprobados se reescriban de forma casual más adelante.

Una biblioteca universitaria en Singapur usaba tags RFID en portátiles, tabletas, cámaras, proyectores y kits de laboratorio prestados a estudiantes. La biblioteca también imprimía nuevas tarjetas NFC para el acceso del personal a salas multimedia. Una tarde con mucho trabajo, un operador mezcló dos plantillas de codificación y casi escribió datos de tarjetas de personal sobre tags de equipos. El error se detectó durante una comprobación de lectura posterior, pero sirvió de advertencia. La biblioteca creó una regla sencilla: los tags nuevos permanecen desbloqueados solo durante la producción controlada, y los tags aprobados se bloquean antes de fijarse al equipo. El software de codificación también mostraba claramente el nombre del trabajo y el área de memoria objetivo antes de escribir. El sistema no se volvió complicado. Simplemente se volvió más difícil de arruinar por accidente.

Auditoría, identidad y protección de memoria

Mejorar la confianza en las auditorías

La cuarta razón es la confianza en auditorías. A los auditores no solo les importa que el sistema pueda leer tags. Les importa saber si los datos son fiables. Si los tags RFID pueden sobrescribirse sin control, un registro de activo puede no ser una evidencia fiable. El bloqueo de escritura permite a la empresa explicar un control más sólido: el tag se codificó desde el registro maestro, se verificó, se bloqueó y luego se usó en operaciones. Esto no resuelve todos los problemas de auditoría, pero reduce una debilidad evidente.

Una empresa de servicios financieros en Londres usaba tags RFID de activos en portátiles cifrados, armarios de documentos seguros, equipos de red y dispositivos de videoconferencia. La auditoría interna preguntó si los técnicos de campo podían cambiar accidentalmente los IDs de los tags durante el inventario. La primera respuesta fue incómoda, porque los lectores técnicamente tenían capacidad de escritura. El equipo de activos IT actualizó su modelo de control. Los tags de producción se bloqueaban después de la instalación, los dispositivos con escritura quedaban restringidos al laboratorio de activos, y cualquier tag de reemplazo requería ticket, aprobación de un supervisor y un evento registrado de codificación y bloqueo. La siguiente revisión de auditoría fue más fluida porque el proceso por fin coincidía con la sensibilidad de los activos.

Evitar identidades duplicadas

La quinta razón es evitar identidades duplicadas. Los EPC duplicados o las URL NFC duplicadas son un problema serio porque hacen que dos objetos físicos parezcan uno solo. Si una operación de escritura copia por accidente una identidad antigua en un tag nuevo, el sistema puede mezclar historiales, sobrescribir ubicaciones o perder trazabilidad. Bloquear la escritura después de la serialización ayuda a impedir que un tag ya asignado se convierta más tarde en un duplicado.

Un almacén de herramientas en Chicago rastreaba llaves dinamométricas, calibres de inspección, bloques de calibración y herramientas de servicio especializadas con tags RFID. Algunas herramientas llevaban tags RFID UHF robustos, mientras que los kits más pequeños usaban etiquetas NFC para instrucciones técnicas. Durante un proyecto de reetiquetado, un trabajador copió un registro de tag válido y lo duplicó accidentalmente en tres tags de reemplazo. Más tarde, el sistema mostró la misma llave dinamométrica en varias ubicaciones. El taller corrigió los registros y luego cambió el flujo de trabajo. Cada tag se serializaba desde la base de datos de activos, se escaneaba de vuelta, se comprobaba su unicidad y se bloqueaba antes de liberarlo. El almacén siguió usando RFID por velocidad, pero dejó de tratar la escritura como una tarea informal de copiar y pegar.

Proteger la User Memory

La sexta razón es proteger la User Memory. Muchos equipos se concentran en el EPC y olvidan que User Memory puede contener datos operativos útiles: tipo de activo, código de mantenimiento, número de lote, intervalo de servicio, ID de cliente o estado de retorno. Si cualquier persona con el lector adecuado puede editar la User Memory, esta puede borrarse o modificarse por accidente. En algunos proyectos, el diseño más seguro consiste en almacenar solo un ID estable en el tag y mantener los datos cambiantes en el backend. En otros proyectos, una User Memory limitada resulta útil. En cualquier caso, el acceso de escritura debe ser deliberado.

Una planta de autopartes en Múnich usaba tags RFID UHF en contenedores retornables. El EPC identificaba cada contenedor, mientras que la User Memory almacenaba un código corto de clase de contenedor utilizado por equipos de clasificación antiguos. Durante una actualización de software, un lector de prueba borró la User Memory en varios contenedores sin cambiar el EPC. Los contenedores seguían apareciendo en inventario, pero el clasificador los rechazaba porque el código de clase había desaparecido. La planta añadió acceso de escritura protegido por contraseña y bloqueó el campo User Memory después de validarlo. También trasladó más lógica operativa al sistema central para que el tag llevara solo los datos que realmente necesitaban viajar con el contenedor.

Lecciones de bloqueo para NFC y operaciones de campo

Evitar cambios accidentales en contenidos NFC

La séptima razón es evitar cambios accidentales en contenidos NFC. Los tags NFC suelen utilizarse para autenticación de productos, instrucciones de configuración IT, páginas de servicio de activos, enlaces de formación y credenciales de visitantes. Si un tag NFC básico permanece editable, un miembro del personal puede actualizar el enlace equivocado, sobrescribir una página de configuración o cambiar un tag usado en un flujo visible para clientes. En tags NFC orientados al público, la protección de escritura suele ser esencial. De lo contrario, un tag puede convertirse en un punto débil para la confianza en la marca y la consistencia operativa.

Un equipo de tecnología para eventos en Dubái usaba credenciales NFC para invitados VIP, instrucciones de acceso entre bastidores y activaciones de salas de patrocinadores. Los tags NFC abrían páginas personalizadas y flujos de check-in. Durante un ensayo, una coordinadora utilizó una app móvil para actualizar un tag de muestra y reescribió por accidente una credencial real de la misma pila. La credencial seguía viéndose perfecta, pero abría la página del invitado equivocado. Desde entonces, las credenciales de producción se codificaban, probaban y bloqueaban antes del embalaje. Solo las credenciales de muestra permanecían editables, y se guardaban en una caja de pruebas claramente identificada. El equipo aprendió que la comodidad del NFC necesita límites.

Evitar reescrituras bien intencionadas en campo

La octava razón es proteger las operaciones de campo frente a correcciones bien intencionadas. El personal de campo suele resolver problemas con rapidez, y eso normalmente es positivo. Pero la escritura RFID no debe convertirse en una herramienta de improvisación salvo que el sistema haya sido diseñado para ello. Si un ingeniero de campo ve un tag que no se lee correctamente, puede intentar reescribirlo en vez de reemplazarlo, revisar la base de datos o escalar la incidencia. Eso puede ocultar el problema original y crear uno peor. El bloqueo de escritura orienta al personal de campo hacia flujos de excepción más seguros.

Un contratista de mantenimiento de telecomunicaciones en Toronto etiquetaba armarios de fibra, kits de prueba, baterías y cajas de servicio exteriores con etiquetas RFID robustas. Los ingenieros de campo llevaban lectores portátiles para auditorías de sitio. Un ingeniero intentó “arreglar” un tag desconocido escribiendo un nuevo ID tomado de un activo cercano. El tag volvió a leerse, pero ahora apuntaba al armario equivocado. El contratista cambió su política. Los tags desconocidos o ilegibles se reemplazaban mediante un flujo de reetiquetado controlado, no se reescribían en campo. Los tags de producción se bloquearon y los lectores de campo quedaron sin capacidad de escritura. La base de datos de activos se volvió más limpia porque las reparaciones en campo dejaron de crear cambios de identidad ocultos.

Mantener el estado del ciclo de vida en el backend

La novena razón es proteger el estado del ciclo de vida. Algunos tags deben cambiar de estado con el tiempo, pero la identidad en sí no debería cambiar. Por ejemplo, un portátil puede pasar de activo a reparación y luego a retirado, pero el ID del tag RFID debe permanecer estable. Un servidor puede moverse del rack A al rack B, pero el tag no debería reescribirse para mostrar la ubicación. Si la ubicación o el estado se guardan directamente en el tag y se actualizan con demasiada frecuencia, el sistema se vuelve frágil. Los profesionales de IT deben decidir con cuidado qué datos pertenecen al tag y qué datos pertenecen a la base de datos.

Un proveedor de servicios gestionados en Melbourne etiquetaba routers de clientes, switches de repuesto y appliances firewall. Al principio, los técnicos escribían el estado de despliegue en la User Memory porque parecía conveniente. Con el tiempo, las actualizaciones de campo se volvieron inconsistentes. Algunos dispositivos indicaban “listo” en el tag, pero “desplegado” en el sistema. Otros se reescribían durante la resolución de incidencias y perdían su código de proyecto original. El proveedor rediseñó el modelo de datos. El tag RFID conservaba un ID permanente de activo y quedaba bloqueado. El estado, cliente, sitio y notas de servicio vivían en la plataforma de activos. El tag pasó a ser una clave estable, no una pequeña base de datos poco fiable.

Crear un flujo seguro: codificar, verificar y bloquear

Planificar la recuperación antes del bloqueo

La décima razón es la planificación de recuperación. Incluso con bloqueo de escritura, pueden producirse errores antes del paso de bloqueo. Un buen programa RFID debe incluir un informe de verificación, un registro de tags rechazados, un procedimiento de reemplazo y un mapa de respaldo de datos. Si un tag se daña o debe sustituirse, el nuevo tag debe codificarse desde el sistema de registro fiable, no copiarse de memoria ni deducirse a partir de una etiqueta. El bloqueo de escritura es potente, pero funciona mejor como parte de un proceso más amplio de control de datos.

Una empresa de seguridad logística en Rotterdam usaba sellos RFID antimanipulación en envíos de alto valor. Cada sello tenía un EPC vinculado al ID del envío, ruta y cuenta del cliente. Durante un pedido urgente, un lote de sellos se imprimió correctamente, pero se codificó con el prefijo de cliente equivocado. El error se detectó antes del bloqueo porque el informe de verificación comparaba los valores EPC con el archivo de envío. El lote incorrecto fue rechazado y destruido. Más tarde, la empresa comentó que el paso de bloqueo era importante, pero la verificación previa al bloqueo lo era tanto como el propio bloqueo. No conviene proteger de forma permanente datos incorrectos.

No bloquear demasiado pronto

Hay una advertencia importante: no bloquee demasiado pronto. Un tag debe bloquearse solo después de que los datos sean correctos, estén verificados y coincidan con el registro adecuado. Si bloquea un tag antes de confirmarlo, puede convertir un simple error de codificación en material de descarte. Algunas acciones de bloqueo son reversibles con la contraseña de acceso correcta. Otras pueden ser permanentes según el tipo de tag y la configuración de bloqueo. Los equipos IT deben entender la diferencia entre protección temporal contra escritura, escritura protegida por contraseña y bloqueo permanente. La palabra “bloquear” nunca debería pulsarse de forma casual.

Un equipo de control de accesos corporativo en Berlín pidió tarjetas NFC personalizadas para salas de reuniones, carros audiovisuales y equipos de visitantes. Un técnico junior bloqueó varios tags antes de probar las URL finales. Dos enlaces contenían direcciones de staging en lugar de páginas de producción. Las tarjetas tuvieron que reemplazarse. El equipo cambió la secuencia: codificar, escanear con dos tipos de dispositivo, verificar el destino, comprobar la asignación en la base de datos y entonces bloquear. El problema no era que el bloqueo fuera malo. El problema fue bloquear antes de validar.

Gestionar contraseñas y credenciales de escritura

La gestión de contraseñas también importa. En tags UHF que usan contraseñas de acceso, mantener la contraseña predeterminada para siempre no es un control real. Compartir una sola contraseña en todos los proyectos también puede generar riesgo. Las contraseñas deben gestionarse según la sensibilidad de los activos y la necesidad operativa. Para muchos tags de activos ordinarios, un bloqueo básico puede ser suficiente. Para activos IT de mayor valor, resulta más adecuado aplicar una gestión segura de claves y limitar los dispositivos con capacidad de escritura. El objetivo no es hacer que el sistema sea imposible de gestionar. El objetivo es detener la reescritura accidental y casual.

Una empresa de reacondicionamiento de hardware cloud en Phoenix procesaba servidores usados, discos, switches y bandejas de memoria. La empresa usaba etiquetas RFID durante recepción, verificación de borrado, reparación, reventa y reciclaje. Como algunos activos eran sensibles en materia de seguridad, creó credenciales de codificación separadas para tags de recepción, tags de reparación y etiquetas finales de reventa. Los tags de producción se bloqueaban después de cada etapa principal del flujo, y solo los supervisores podían desbloquear o reemplazar un tag bajo ticket. Esto evitó que los trabajadores sobrescribieran por accidente un tag de verificación de borrado con un código de inventario de reventa. En un negocio donde la evidencia de destrucción de datos importaba, el control del tag también importaba.

Documentar el SOP y elegir el tag adecuado

El bloqueo de escritura también debe documentarse en el SOP. No puede depender de una sola persona experta que recuerde la pantalla correcta. El SOP debe indicar qué bancos de memoria se escriben, qué campos se verifican, qué ajustes de bloqueo se usan, quién está autorizado a escribir, qué perfil de software está aprobado, qué informe se guarda y qué hacer cuando un tag falla. En entornos IT, el SOP también debe definir cómo se reemplazan las etiquetas RFID durante reparación, reasignación, eliminación y auditoría de dispositivos.

Un laboratorio universitario de investigación en Boston rastreaba instrumentos de laboratorio costosos, portátiles en préstamo, microscopios, sensores portátiles y cajas de transporte de muestras. El laboratorio contaba con personas muy capacitadas, pero el proceso RFID era informal. Algunos asistentes de posgrado imprimían etiquetas de reemplazo sin actualizar a la oficina de activos. Después de dos ciclos de inventario, los registros estaban confusos. El laboratorio creó un SOP breve: solicitar reemplazo, generar ID desde el sistema de activos, imprimir y codificar, leer de vuelta, fijar, bloquear y confirmar en la base de datos. El proceso sonaba aburrido, pero evitó que los investigadores perdieran días en disputas de inventario.

Una buena estrategia de bloqueo de escritura también depende de elegir el tag adecuado. Algunas etiquetas RFID de bajo coste tienen memoria limitada y opciones de bloqueo limitadas. Algunos tags NFC admiten bits de bloqueo permanente que no pueden revertirse. Algunos tags industriales ofrecen protección por contraseña y una estructura de memoria más robusta. Algunas tarjetas seguras gestionan permisos de acceso mediante claves de aplicación. Si el flujo de trabajo requiere actualizaciones controladas, no compre el tag más barato sin entender sus funciones de protección de memoria. El tag correcto no se define solo por el alcance de lectura. También se define por cómo se protegerán los datos después de la codificación.

Una empresa de taquillas inteligentes en Singapur usaba tags NFC dentro de paneles de servicio para identificar módulos de taquilla durante el mantenimiento. La primera opción de tag era económica y fácil de codificar, pero una vez bloqueada no permitía ajustar la configuración. Cuando cambió el diseño de la taquilla, la empresa tuvo que reemplazar tags que no soportaban el nuevo modelo de datos. La siguiente versión utilizó un tag NFC más adecuado, con capacidad de actualización protegida por contraseña durante la fabricación y bloqueo final después de la instalación. El tag costaba más, pero encajaba mejor con el ciclo de vida del producto.

Lista práctica para compradores y equipos IT

Los profesionales de IT deberían tratar la escritura RFID como tratan las actualizaciones de bases de datos. No se permite que cualquiera edite tablas de producción. No se ejecutan scripts sin copias de seguridad. No se sobrescriben números de serie de forma casual. Los tags RFID pueden ser pequeños y económicos, pero a menudo representan activos físicos que valen mucho más que la etiqueta. Un portátil, una blade de servidor, un dispositivo médico, un armario inteligente, una credencial de acceso o un envío sellado pueden depender de la identidad de ese tag. El bloqueo de escritura equivale a pasar de una hoja de cálculo editable a un registro controlado.

El flujo práctico es sencillo. Codifique desde una fuente de datos fiable. Lea el tag de vuelta. Compare el EPC, la User Memory, el contenido NFC o los datos seguros de aplicación con el registro esperado. Pruebe el tag con el lector real o con un teléfono cuando sea necesario. Bloquee el área de memoria adecuada. Registre el estado de bloqueo. Fije el tag al activo correcto. Después, use los lectores diarios en modo de solo lectura salvo que una excepción controlada requiera reemplazo. Esa secuencia evita la mayoría de los borrados accidentales antes de que se vuelvan costosos.

Para compradores, la lista de comprobación es directa. Pregunte si el tag RFID admite bloqueo de escritura, protección por contraseña, bloqueo permanente o permisos seguros de aplicación. Pregunte qué áreas de memoria pueden protegerse. Pregunte si el software de codificación admite verificación por lectura posterior. Pregunte si los roles de operador pueden separar escritura y lectura. Pregunte qué ocurre si un tag se bloquea con datos incorrectos. Pregunte cómo se emiten los tags de reemplazo. Pregunte si los lectores portátiles usados en campo pueden restringirse al modo de solo lectura. Estas preguntas son más útiles que limitarse a preguntar si el tag tiene “buena memoria”.

Conclusión final

El “truco” de bloqueo de escritura RFID que todo profesional de IT necesita no es realmente un truco. Es una disciplina. Deje de mantener tags de producción editables después de asignarlos. Deje de permitir que cada lector se comporte como un codificador. Deje de almacenar datos operativos cambiantes en los tags cuando el backend es un lugar más adecuado. Deje de confiar en que los operadores siempre elegirán la plantilla correcta. Codifique, verifique, bloquee y documente. Ese pequeño hábito puede evitar confusión de activos, fallos de auditoría, IDs duplicados, enlaces NFC rotos y horas de limpieza de datos.

Los datos RFID son fáciles de crear, fáciles de leer y, a veces, peligrosamente fáciles de sobrescribir. El bloqueo de escritura añade la pausa que faltaba. Convierte un tag editable de forma casual en un marcador de identidad estable. Para seguimiento de activos IT, control de centros de datos, despliegues NFC seguros, etiquetas inteligentes de inventario y flujos relacionados con accesos, esa estabilidad no es opcional. Es la diferencia silenciosa entre un sistema en el que el equipo confía y un sistema que todos siguen reparando después de que alguien pulsa el botón equivocado.