Ética y privacidad en proyectos de tecnología cívica: guía para hackatones responsables

Un proyecto de tecnología cívica puede facilitar el acceso a servicios, mejorar la participación ciudadana o hacer visibles problemas locales. También puede exponer información personal, reforzar desigualdades o crear herramientas que se usen de formas distintas a las previstas. En un hackatón cívico, donde el tiempo es limitado y los prototipos se construyen rápido, la ética y la privacidad deben formar parte del diseño desde el primer momento.

Esta guía ofrece criterios prácticos para decidir qué datos hacen falta, cómo protegerlos y cuándo detenerse antes de publicar o escalar una solución. El objetivo no es eliminar todo riesgo, algo que ninguna técnica puede garantizar, sino reconocerlo y reducirlo con transparencia y participación de las personas afectadas.

Qué significa trabajar de forma ética en tecnología cívica

Trabajar de forma ética en tecnología cívica significa buscar un beneficio público y, al mismo tiempo, respetar los derechos, la seguridad y la capacidad de decisión de las personas implicadas. La finalidad social de una herramienta no basta para justificar cualquier método de recopilación o uso de datos.

Un mapa de baches, una plataforma para reportar problemas de accesibilidad o un tablero de servicios municipales pueden ayudar a una comunidad. Pero también pueden revelar quién vive en un lugar, qué servicios utiliza o qué dificultades enfrenta. La pregunta clave para un equipo no es solo «¿podemos construirlo?», sino «¿quién se beneficia, quién asume el riesgo y quién puede decidir?»

En un hackatón cívico, conviene aplicar tres filtros desde la idea inicial:

• Propósito: describir qué problema público aborda y qué resultado concreto espera.
• Proporcionalidad: comprobar que cada dato y función sea necesario para ese resultado.
• Rendición de cuentas: decidir quién responde si el prototipo causa daño, se filtra información o se usa fuera del contexto previsto.

Una iniciativa voluntaria puede tener consecuencias reales, aunque se presente como un experimento. Si el equipo no puede explicar el beneficio a las personas afectadas ni identificar quién será responsable del sistema después del evento, todavía no está listo para recopilar datos ciudadanos.

Riesgos éticos y de privacidad desde la idea inicial

Los riesgos éticos aparecen cuando una solución expone a las personas, distribuye beneficios de forma desigual o usa datos ciudadanos para fines que no esperaban. Identificarlos antes de programar permite cambiar el enfoque cuando aún es barato hacerlo.

Los datos personales incluyen información que identifica a alguien directamente o que, combinada con otros registros, permite reconocerlo. Los datos sensibles, como información sobre salud, origen étnico, situación migratoria, creencias o ubicación precisa, pueden causar daños graves si se divulgan o se interpretan fuera de contexto. En algunos casos, incluso un conjunto de datos que parece inocuo adquiere un riesgo nuevo al cruzarse con fuentes públicas.

También hay que revisar el sesgo algorítmico. Un modelo entrenado con reportes incompletos puede priorizar los barrios donde más personas tienen acceso a internet, no aquellos con mayor necesidad. Una puntuación automatizada puede convertir desigualdades históricas en decisiones que parecen neutrales. Para cada función, el equipo debería anotar:

• Qué personas podrían quedar excluidas o ser clasificadas de manera injusta.
• Qué daño podría producir un error, una filtración o un uso distinto del previsto.
• Quién tiene autoridad para corregir una decisión y cómo puede pedir una revisión.
• Qué alternativa existe si la tecnología no es adecuada para el problema.

El análisis debe incluir tanto el daño directo como el efecto acumulado: una ubicación publicada puede revelar rutinas; una herramienta de denuncias puede aumentar la vigilancia de un grupo; y un formulario puede desalentar a quienes temen que sus respuestas lleguen a una institución. Un prototipo no queda exento de esos riesgos por no estar todavía en producción.

Recopilar y usar datos con consentimiento y propósito claro

Para recopilar datos de forma responsable, definan primero el propósito, soliciten solo lo imprescindible y expliquen con claridad qué ocurrirá con cada respuesta. El consentimiento informado requiere que las personas comprendan esa explicación y puedan decidir sin presión.

Antes de crear un formulario o importar una base de datos, prueben la minimización de datos: por cada campo, pregunten si el proyecto deja de funcionar sin él. Si basta con conocer una zona aproximada, no pidan una dirección exacta. Si el prototipo solo necesita contar solicitudes, quizá no necesite nombres ni números de teléfono. Evitar la recopilación suele ser más seguro que intentar proteger información que nunca debió almacenarse.

El consentimiento debe explicar, en lenguaje sencillo:

• Qué datos se recogen y para qué se usarán.
• Quién tendrá acceso y si se compartirán con terceros.
• Durante cuánto tiempo se conservarán y cómo se eliminarán.
• Si participar es voluntario y cómo retirar la información, cuando sea posible.

Una casilla marcada por defecto o un aviso escondido en una página extensa no ofrece una decisión clara. Tampoco conviene presentar la participación como condición para acceder a un servicio esencial. En un hackatón, pueden trabajar con datos sintéticos o conjuntos públicos cuidadosamente revisados para construir y probar la interfaz sin exponer a personas reales. Esta elección puede limitar la prueba con situaciones auténticas, pero reduce el riesgo mientras el proyecto todavía cambia con rapidez.

Proteger la información durante un hackatón

Durante un hackatón, protejan la información limitando el acceso, usando almacenamiento controlado y eliminando los datos cuando ya no sean necesarios. La seguridad de la información depende tanto de las decisiones cotidianas del equipo como de las herramientas técnicas.

Un conjunto sencillo de reglas ayuda a evitar errores comunes. Designen a una persona responsable de los datos y acuerden quién necesita acceso. No compartan archivos con permisos públicos, contraseñas en el chat del equipo ni copias descargadas en dispositivos personales sin protección. Si se conectan servicios externos, revisen qué información envían y las condiciones de uso antes de integrarlos.

La anonimización puede reducir la posibilidad de identificación, pero no garantiza que sea imposible reconocer a alguien. Quitar nombres no basta si quedan ubicaciones precisas, fechas, combinaciones de atributos poco comunes u otros identificadores indirectos. Cuando sea viable, agreguen los resultados o reduzcan su precisión; luego evalúen si todavía se podrían cruzar con otras fuentes.

Acuerden un ciclo de vida de datos, aunque el prototipo dure solo un día:

• Usar datos sintéticos o minimizados para las pruebas.
• Restringir el acceso durante el evento y evitar copias innecesarias.
• Eliminar archivos de trabajo y credenciales que ya no hagan falta.
• Confirmar qué datos se conservarán, por qué y bajo responsabilidad de quién.

Si ocurre una exposición accidental, detengan el acceso compartido, avisen a la persona responsable y documenten qué información pudo verse. No intenten ocultar el incidente ni prometan que no hubo impacto sin haberlo investigado.

Diseñar con las comunidades afectadas

Diseñar con las comunidades afectadas significa incluir sus perspectivas antes de fijar el problema y mantener su participación en las decisiones, no limitarse a pedir comentarios al final. La participación ciudadana ayuda a detectar necesidades y riesgos que el equipo puede pasar por alto.

Inviten a personas con experiencias distintas a revisar la idea, el lenguaje, los datos solicitados y los posibles efectos. Si el proyecto aborda accesibilidad, por ejemplo, consulten a personas con discapacidad antes de decidir qué indicadores usar y cómo presentar los resultados. Ofrezcan formatos y horarios accesibles, expliquen cómo influirá la opinión recibida y, cuando sea posible, compensen el tiempo de quienes aportan su experiencia.

La consulta no transfiere la responsabilidad ética a la comunidad. El equipo sigue siendo responsable de las decisiones técnicas y del tratamiento de los datos. También debe explicar qué cambios puede aceptar y cuáles no, con sus razones; pedir opiniones sin dar respuesta puede erosionar la confianza y convertir la participación en un trámite.

Una práctica útil es mantener un registro breve de decisiones: qué preocupación se planteó, qué se modificó y qué riesgo permanece. Así, el equipo puede revisar sus supuestos y compartir con las personas participantes una explicación honesta del estado del proyecto.

De prototipo a implementación responsable

Antes de publicar, compartir o escalar un prototipo, hagan una revisión ética que confirme su propósito, sus riesgos residuales, la protección de datos y la responsabilidad sobre el uso posterior. Ganar un premio en el hackatón no demuestra que la solución esté lista para operar.

La revisión puede ser breve, pero debe ser concreta. Comprueben si el prototipo recoge datos reales, si los permisos están bien configurados y si las explicaciones sobre privacidad coinciden con lo que hace el sistema. Revisen también errores previsibles, sesgos algorítmicos, accesibilidad y posibles usos secundarios. Si la herramienta afecta decisiones sobre personas, incluyan una forma de pedir revisión humana y corregir información incorrecta.

Antes de pasar a producción, definan quién mantendrá el servicio, quién responderá a incidentes, cuánto costará protegerlo y cuándo se revisará si sigue siendo útil. La evaluación ética continúa después del lanzamiento: cambian los datos, las comunidades usuarias y el contexto institucional. Si no hay una entidad dispuesta a asumir esas tareas, lo responsable puede ser publicar solo una demostración con datos ficticios o archivar el prototipo.

Preguntas frecuentes sobre ética y privacidad en hackatones cívicos

Las decisiones sobre datos dependen del propósito y del contexto, pero unas reglas básicas ayudan a reducir riesgos desde el primer día. Estas respuestas sirven como orientación general, no como asesoramiento legal para una jurisdicción concreta.

¿Qué datos personales conviene evitar recopilar en un hackatón?

Eviten nombres, documentos de identidad, datos financieros, información de salud, situación migratoria y ubicación precisa, salvo que exista una necesidad clara y medidas adecuadas. Para un prototipo, suelen bastar datos sintéticos, agregados o una muestra con identificadores retirados y riesgo revisado.

¿Cuándo se necesita consentimiento informado?

Cuando se recogen datos de personas o se les pide participar en pruebas, deben recibir información comprensible sobre el propósito, el acceso, la conservación y sus opciones. Los requisitos legales concretos varían; si el proyecto trata datos sensibles o puede afectar derechos, consulten a la institución responsable o a una persona especialista antes de recopilar.

¿La anonimización garantiza que los datos no puedan identificarse?

No. La anonimización reduce ciertos riesgos, pero la combinación con otras fuentes puede permitir la reidentificación, sobre todo con ubicaciones detalladas o grupos pequeños. Revisen qué atributos permanecen y consideren agregar, generalizar o retirar información.

¿Qué hacer con los datos después del evento?

Eliminen de forma segura los datos que ya no tengan un propósito aprobado y confirmen que no queden copias en carpetas compartidas, dispositivos o servicios conectados. Si se necesitan para continuar el proyecto, documenten quién los conserva, por cuánto tiempo, con qué controles y bajo qué responsabilidad.