FBI Sentinel: 25 años de innovación tras el 11-S

La lección fundamental que el FBI extrajo tras el 11-S fue que debía cambiar primero la estructura de trabajo, antes que las herramientas. La información dispersa y la verificación tardía condujeron al fracaso de VCF, mientras que Sentinel se desplegó por completo en 2012 después de introducir ciclos de desarrollo cortos y comentarios del personal de campo.

Las cifras y la cronología de este artículo se basan en el informe de la comisión de 2004 y en los registros de supervisión de Sentinel de 2012 a 2014.

Las señales que el FBI pasó por alto antes del 11-S

Antes del ataque, el FBI disponía de indicios que merecían ser examinados. El problema era que estaban dispersos entre distintas organizaciones y sistemas. También era débil el cauce que permitía que la información de campo llegara a las decisiones de la sede central. El ataque de 2001, en el que murieron alrededor de 3.000 personas, puso de manifiesto esta desconexión.

Los casos más representativos fueron el memorando de Phoenix y la investigación de Minneapolis. Un agente de Phoenix informó en julio de 2001 sobre las actividades en escuelas de aviación. Los agentes de Minneapolis trataron de registrar las pertenencias de Zacarias Moussaoui. Ninguna de las dos informaciones llegó a convertirse en una alerta integrada que mostrara el plan del ataque.

La Comisión del 11-S no culpó únicamente al intercambio de información. También señaló deficiencias en la capacidad de análisis y en el sistema de gestión. La siguiente frase es una formulación en español del pasaje correspondiente del informe.

«El FBI ni siquiera conocía adecuadamente la información que ya poseía». — Informe de la Comisión del 11-S

Interpretar este caso como una simple falta de datos supone perder de vista lo esencial. Aunque exista información, no puede utilizarse si no es localizable. Si no hay una persona responsable, también resulta difícil conectar distintos indicios. Cuando los cauces para plantear opiniones contrarias son débiles, las advertencias desaparecen con mayor facilidad.

×

Los analistas examinan un flujo de trabajo digital para detectar cuellos de botella y posibles mejoras.

Cronología del desarrollo de VCF y Sentinel

La transición del FBI hacia la gestión electrónica de casos se llevó a cabo mediante dos proyectos. VCF se canceló en 2005 sin llegar a desplegarse para el trabajo real. Sentinel también sufrió dificultades iniciales en la gestión del calendario y los costes. Sin embargo, tras su reorganización en 2010, alcanzó el despliegue completo en 2012.

Se sabe que se invirtieron alrededor de 170 millones de dólares en VCF. Sin embargo, el alcance de los costes contractuales y de los proyectos relacionados varía según cada documento de auditoría. Por tanto, esta cifra no debe interpretarse como el coste total de modernización del FBI. Lo que está claro es que VCF no llegó a funcionar como sistema de gestión de casos.

La escala inicial del proyecto Sentinel fue de 425 millones de dólares. El proyecto se dividió en varias fases, pero los retrasos del calendario se acumularon. En 2010 se concluyó que sería difícil completarlo conforme al plan existente. El FBI volvió a dividir el alcance y asumió internamente el control del desarrollo.

Comparación entre VCF y el Sentinel reorganizado

La diferencia entre ambos proyectos no residía tanto en el nombre del software como en el método de verificación. En VCF, uno de los principales problemas era que los resultados terminados se comprobaban demasiado tarde. El Sentinel reorganizado presentaba con frecuencia unidades funcionales. Los comentarios de los usuarios de campo también se incorporaban al siguiente ciclo de desarrollo.

No basta con considerar esto únicamente como el triunfo de una metodología ágil. El FBI también revisó el alcance del proyecto y la estructura de mando. Asimismo, amplió el papel del personal técnico interno. Los ciclos cortos de desarrollo fueron el medio que permitió que estos cambios funcionaran.

Resumen por situación de adopción de IA

El trabajo que debe corregirse primero varía según dónde se aplique la IA. La búsqueda de documentos requiere metadatos y permisos de acceso. El apoyo a la toma de decisiones requiere fundamentos y procedimientos de aprobación. La automatización necesita una persona responsable de gestionar las excepciones.

Primero debe representarse un proceso de trabajo completo, desde el inicio hasta el final. Después deben señalarse los tiempos de espera y las entradas duplicadas. La IA debe aplicarse de forma limitada en los puntos donde se hayan identificado cuellos de botella. Los resultados deben medirse no solo por su precisión, sino también por el coste de las correcciones.

Nuevos problemas en la estructura del conocimiento en la era de la IA

La IA generativa puede conectar de manera convincente información dispersa. Sin embargo, no puede conectar documentos a los que no tiene acceso. Si hay muchos documentos obsoletos, puede generar respuestas desactualizadas. Tampoco puede asumir por sí sola la responsabilidad ante normativas contradictorias.

Por este motivo, en la era de la IA resulta difícil evaluar la gestión del conocimiento por el volumen almacenado. Cada documento debe indicar su autor y periodo de aplicación. También deben distinguirse su estado de aprobación y si ha sido descartado. Las respuestas deben permitir volver a localizar la fuente original.

Los siguientes elementos pueden revisarse antes de seleccionar un modelo.

• ¿Las normas sobre un mismo tema están duplicadas en varios repositorios?
• ¿Es posible distinguir entre documentos actualizados y descartados?
• ¿Se aplican permisos de acceso por función a la información sensible?
• ¿Es posible comprobar los documentos de referencia y las versiones de las respuestas de la IA?
• ¿Hay una persona responsable de recibir informes sobre respuestas incorrectas y corregirlas?
• ¿Están definidas las tareas que requieren necesariamente la aprobación de una persona?

Esta perspectiva también muestra un nuevo riesgo que no existía en el antiguo caso del FBI. En el pasado, el principal problema era que la información no podía localizarse. Ahora, la información conectada incorrectamente puede difundirse con rapidez. La capacidad de búsqueda y la capacidad de verificación deben diseñarse conjuntamente.

Errores y malentendidos frecuentes

En primer lugar, el 11-S no debe explicarse como un simple caso de falta de información. Existían varios indicios, pero no fueron analizados en conjunto. La estructura organizativa y los procedimientos de decisión también influyeron en el resultado. Limitarse a aumentar el volumen de datos recopilados difícilmente evitará que se repita el mismo problema.

En segundo lugar, el fracaso de VCF no debe reducirse únicamente al método en cascada. También hubo problemas en la gestión de requisitos y la supervisión contractual. La participación de los usuarios y el control técnico tampoco fueron suficientes. El método de desarrollo fue solo una de las diversas causas.

En tercer lugar, no debe suponerse que Sentinel tuvo éxito automáticamente al adoptar métodos ágiles. La reestructuración del alcance del proyecto se llevó a cabo junto con cambios de liderazgo. El personal interno también asumió una mayor responsabilidad. La metodología no sustituye a la estructura de responsabilidades.

En cuarto lugar, puede ser inexacto describir el derrumbe del World Trade Center con una única cifra definitiva de «14 segundos». Las dos torres tuvieron momentos distintos de impacto y derrumbe. La forma de expresar la duración del derrumbe también varía según los criterios de medición. Las cifras aisladas que no guardan relación con la lección principal deben tratarse con cautela.

Secuencia de ejecución para aplicarlo a una organización

Resulta más seguro verificar la adopción de IA en unidades de trabajo pequeñas. El objetivo debe definirse en términos de resultados laborales, no de tasa de uso de la herramienta. También se necesitan criterios de interrupción que permitan detectar pronto los fallos. La siguiente secuencia puede utilizarse al probar una tarea.

1. Seleccione una tarea repetitiva o que sufra retrasos frecuentes.
2. Registre la información de entrada y a la persona responsable de la aprobación final.
3. Mida el tiempo de procesamiento actual y los tipos de errores.
4. Divida el alcance que asumirá la IA y el que asumirán las personas.
5. Despliéguela primero para un grupo reducido de usuarios.
6. Incorpore los errores y el tiempo de corrección al siguiente ciclo.
7. Amplíe el alcance de aplicación solo cuando se cumplan los criterios.

No defina los indicadores de rendimiento únicamente por la frecuencia de uso. Examine conjuntamente el tiempo de procesamiento y el volumen de retrabajo. Compruebe también con qué rapidez se detectaron los errores graves. Asimismo, debe registrar si los comentarios del personal de campo condujeron a cambios reales.

Las preguntas organizativas que dejó el caso del FBI

Este caso muestra que la IA puede amplificar los hábitos existentes de una organización. En una organización donde la información está aislada, la IA también recibe un contexto incompleto. Si las fases de aprobación no están claras, la generación rápida aumenta el retrabajo. Si se pospone la verificación, los errores también se acumulan a gran escala.

La organización puede empezar por responder tres preguntas.

• ¿Quién posee la información necesaria?
• ¿Quién es responsable de conectar señales diferentes?
• ¿Cuándo puede detectarse y detenerse un fallo pequeño?

La esencia del caso de FBI Sentinel no consiste en reproducir un método de desarrollo específico. Reside en el principio operativo de dividir la incertidumbre en partes pequeñas y comprobarla con frecuencia. Las herramientas de IA también deben someterse al mismo control. La velocidad de aprendizaje de la organización debe adelantarse a la velocidad de adopción.