Futurism reportó el 29 de abril sobre Kyle Dausman, residente de Cherry Hills Village al sur de Denver, cuya camioneta fue marcada por los lectores automáticos de matrículas (ALPRs) de Flock Safety y que ahora dispara alertas a la policía local cada vez que maneja. La policía de Cherry Hills Village le dijo a 9News que Dausman no ha hecho nada malo — su matrícula está "erróneamente conectada" a una orden judicial en la base de datos del Colorado Crime Information Center, rastreada a un error de entrada de datos en una orden emitida del condado de Gilpin. Dausman intentó arreglarlo a través del sistema judicial de Gilpin; los funcionarios le dijeron que necesitaría nombrar al sospechoso de la orden errónea, que ninguna agencia de seguridad compartirá porque el caso sigue activo. Está atrapado en un catch-22 que la propia base de datos de órdenes creó.
Éste es un modo de falla diferente al que documentamos en nuestra pieza anterior de Flock, donde el análisis del Institute for Justice mostró 14 casos de policías usando ALPRs para acechar a parejas románticas. El acoso por parte de policías es uso indebido intencional. El error de base de datos por el sistema es uso indebido no intencional, y argumentablemente más preocupante para el diseño de vigilancia con IA porque no requiere ningún mal actor — sólo requiere malos datos y un sistema que trata las coincidencias de base de datos como autoritarias. Sólo el condado de Arapahoe tiene al menos 283 cámaras Flock activas, según DeFlock, una herramienta de base construida por ciudadanos para rastrear despliegues de ALPR. La referencia a DeFlock es el detalle relevante para builders: cuando la infraestructura de vigilancia prolifera más rápido que la supervisión, el tooling de sociedad civil llena el vacío. Mirá herramientas estilo DeFlock expandirse a otras categorías de vigilancia con IA — despliegues de reconocimiento facial, monitoreo de redes sociales, vigilancia de empleadores — en los próximos 18 meses.
Dos patrones importan. Primero, el catch-22 en el que está Dausman no es un bug de Flock — es un problema de integridad de base de datos que la red ALPR de Flock amplifica. El mismo flag de orden errónea habría causado paradas policiales ocasionales en un mundo pre-ALPR. Con 283 cámaras en un solo condado, el mismo flag ahora causa contacto policial casi constante. La vigilancia con IA no introduce errores nuevos; convierte errores de baja frecuencia en daños sistémicos de alta frecuencia al eliminar la fricción que antes limitaba su alcance. Segundo, la carga de corrección está sobre la víctima. "Una vez que estás en el sistema Flock, depende de vos salirte," dijo Dausman, y el proceso le da la razón: el retiro de la lista de alerta sucede sólo cuando la víctima logra navegar un proceso que el sistema mismo obstruye. Ésta es la inversión distópica del debido proceso — sos presumido marcado, y limpiarte requiere pelear contra las instituciones que te marcaron.
Para los builders, tres cosas concretas. Primero, si construís cualquier sistema que dispare alertas a las fuerzas de seguridad basadas en coincidencia de base de datos, el problema de la carga de corrección es tu responsabilidad de diseño. Construí el camino de apelación dentro del producto, con un cronograma documentado y una manera para que un usuario marcado verifique que el registro subyacente es correcto sin requerir información a la que no puede acceder legalmente. De lo contrario construiste un Flock — un sistema que puede atrapar a personas inocentes en bucles de retroalimentación costosos. Segundo, las herramientas de seguimiento ciudadano como DeFlock ahora son parte del paisaje de vigilancia; si lanzás infraestructura de vigilancia, esperá documentación adversarial de dónde operás y cómo. Cocíne transparencia en el producto antes de que un tercero la construya para vos con encuadre hostil. Tercero, el patrón "la IA convierte errores de baja frecuencia en daños de alta frecuencia" generaliza. Cualquier producto que automatiza un proceso antes limitado por fricción — moderación de contenido, marcado de fraude, verificación de identidad — va a sacar a flote errores que no introdujo, pero a escala. Auditá tus tasas de error por diez mil y por millón de eventos, no por cien. Una tasa de falso positivo del 0,1% está bien hasta que cae sobre un millón de personas.
