La investigación judicial sobre la tragedia de El Bocal ha ido dejando una diferencia cada vez más visible entre la descripción oficial realizada por el Ayuntamiento de Santander sobre el funcionamiento de la Policía Local en la ciudad y la lógica que aparece reflejada en los propios documentos técnicos del sistema.

Durante las primeras fases de la instrucción, la Jefatura de la Policía Local defendió ante el juzgado la existencia de un sistema “protocolizado” que guiaba de forma estructurada la actuación de los operadores del Centro de Coordinación de Servicios.

En uno de los informes remitidos a la jueza, la Policía Local sostenía que el sistema “guía al operador paso a paso”, que “establece una secuencia cronológica obligatoria” y que “la aplicación impide el cierre de la incidencia si no se han completado todas las actuaciones requeridas”.

Esa descripción proyectaba la imagen de un sistema rígido, estructurado y automatizado, en el que el margen de actuación del operador quedaba condicionado por una secuencia predefinida de pasos obligatorios, con lo que el Ayuntamiento trata de presentar el sistema como formal y completo, dentro de su estrategia de desviar la atención del propio funcionamiento del cuerpo a una situación personal de la agente a la que quieren incriminar.

Sin embargo, el propio manual técnico aportado por el Ayuntamiento y consultado por EL FARADIO describe un funcionamiento diferente.

El Ayuntamiento presenta como protocolos el manual de uso de un programa informático y documentos con fechas posteriores a la tragedia de El Bocal

El documento ‘Sistema de Gestión de Recepción de llamadas del 092’ funciona esencialmente como un manual de uso del programa informático empleado en la Sala. A lo largo de sus páginas, el sistema aparece descrito a través de operaciones manuales realizadas por el agente operador, como introducir datos, modificar actuaciones, seleccionar hechos, asociar protocolos, añadir implicados, validar información o cerrar expedientes.

El propio manual explica que “los datos a introducir por el agente operador en cada una de las actuaciones son” elementos como la fecha, la hora, la localización, la descripción, los agentes, los implicados, los protocolos o las actuaciones asociadas.

Además, en otro apartado, el documento señala que “todos los datos que se insertan, modifican o borran” no quedan grabados en la base de datos “hasta que no pulsamos sobre este botón”. De este modo, parte de la trazabilidad del sistema dependía directamente de operaciones realizadas por el propio operador.

La lógica central del sistema no gira alrededor de protocolos autónomos de emergencia, sino de “hechos” codificados a los que se vinculan determinadas actuaciones mínimas.

El manual explica que el sistema permite “asociar un hecho a un protocolo mínimo de actuación” y muestra una pantalla específica de “asignación de hechos a protocolos”. Es decir, el funcionamiento descrito en la documentación técnica responde a una estructura informática donde determinados códigos despliegan protocolos asociados dentro de la base de datos.

El propio manual añade que “la actuación se cerrará cuando todos los protocolos mínimos requeridos han sido realizados”. Pero inmediatamente introduce un matiz relevante: “Inicialmente no es obligatorio introducir los agentes, implicados o protocolos para salvar los datos, ya que se pueden introducir posteriormente con la opción de modificar actuación”.

Esa frase muestra que buena parte del sistema dependía de actuaciones posteriores realizadas manualmente por el operador y no de automatismos cerrados ejecutados en tiempo real.

La diferencia entre ambas descripciones no es menor. Mientras los informes remitidos por la Jefatura presentan un sistema cronológico y obligatorio que “guía al operador paso a paso”, el manual describe una herramienta donde el operador introduce datos, selecciona hechos, incorpora protocolos, modifica actuaciones y valida manualmente la información antes de cerrar la incidencia.

Ese contraste coincide además con testimonios incorporados posteriormente a la investigación judicial. Varios agentes del Centro de Coordinación de Servicios aseguraron ante la jueza que era “la primera vez que ven esos documentos en su trayectoria profesional”.

Los mismos testimonios cuestionaban la naturaleza operativa real del Anexo I aportado por el Ayuntamiento. Según explicaban, “el Anexo I es un listado de tipo de hechos que aparecen en el programa Oracle” y “no tiene carácter de protocolo a seguir”.

La documentación técnica muestra así un modelo más cercano a una herramienta de gestión administrativa de incidencias que a un protocolo clásico de coordinación de emergencias complejas.

El sistema aparece construido sobre categorías predefinidas, hechos codificados, protocolos asociados, validaciones manuales y cierres administrativos. El operador debía completar información, modificar actuaciones y seleccionar elementos dentro del programa antes del cierre formal de cada expediente.

Esto ayuda a entender también por qué muchos de los ejemplos incorporados a la causa mostraban estructuras similares para situaciones completamente distintas, como atentados, accidentes, incidencias administrativas, protección de datos o simples consultas. Todos ellos aparecían organizados bajo la misma lógica informática de hechos y protocolos asociados.

Llamar a la grúa municipal, entre las acciones que recomienda el «protocolo» de la Policía Local para el supuesto de El Bocal

📣 Rompe el algoritmo. Mueve esta información por tus redes o mensajería y decide tú de qué se habla.

🧭 Podemos hablar del funcionamiento de los servicios públicos, la transparencia y la rendición de cuentas gracias a apoyos como el tuyo. Súmate a la comunidad de EL FARADIO y hazte socia o socio por 8 euros al mes: https://www.elfaradio.com/hazte-socio/