Por qué el 43 % de los pilotos de IA gubernamentales nunca escala

01Un piloto que funciona no es prueba de que la tecnología funcione

La encuesta de la OCDE de 2025 sobre el uso gubernamental de la IA encontró que el 43 % de los despliegues permanecen atascados en la etapa de piloto. Ese número no es una instantánea de una tecnología que aún está madurando. Es la medición de instituciones que construyeron algo, lo vieron funcionar en un entorno controlado y luego no lograron llevarlo a producción.

Los entornos de piloto disponen de datos seleccionados, apoyo dedicado del proveedor y plazos indulgentes. La producción impone requisitos de auditoría, obligaciones de cumplimiento, brechas de conectividad y ciudadanos que esperan que el sistema esté bien a la primera. Un piloto prueba que un sistema puede funcionar cuando está aislado de la realidad. No prueba que la institución pueda operarlo una vez que ese aislamiento desaparece.

En las iniciativas digitales del sector público africano, seis modos de falla explican la mayor parte de la brecha entre el piloto y la producción. Ninguno de ellos es principalmente técnico.

021. El pensamiento tecnológico primero

La mayoría de las iniciativas digitales comienza con una licitación que especifica la capacidad de servidores y las funciones del tablero. Rara vez especifica quién usará el producto, para qué decisiones o según qué estándar de evidencia. Cuando la herramienta es el punto de partida en lugar del problema institucional, el sistema resultante se optimiza para el día de la demostración, no para la decisión que debía respaldar.

032. La ambigüedad de propiedad

TI es dueño de los servidores. Operaciones es dueña del proceso. Política es dueña del mandato. En la mayoría de los pilotos, ninguna entidad única es dueña de la evidencia que produce el sistema. Y cuando el financiamiento vence, la rendición de cuentas se desvanece con él. Un sistema con las huellas de tres departamentos y sin un responsable nombrado no sobrevive a su primera transición de liderazgo.

043. Las brechas de evidencia

Un tablero no es evidencia. La evidencia tiene trazabilidad: puede rastrearse desde el número en pantalla hasta sus datos de origen, el método usado para recolectarlos y cada transformación aplicada en el camino. Los pilotos producen con frecuencia tableros que parecen tener autoridad y que no pueden responder a una pregunta de auditoría elemental: de dónde salió este número y puede mostrar su trabajo.

054. La dependencia del piloto

Tratar el piloto como la prueba, en lugar de como un test, es uno de los errores más costosos en la tecnología del sector público africano. Las condiciones indulgentes de un piloto (datos limpios, ingenieros del proveedor disponibles, plazos generosos) son exactamente las condiciones que la producción no ofrecerá. Confundir ambas cosas significa presupuestar un despliegue que da por sentados problemas que el piloto nunca tuvo que enfrentar.

065. La gobernanza después del despliegue

El control de acceso, la clasificación de datos, la política de retención y el registro de auditoría deberían ser restricciones de diseño desde el primer diagrama de arquitectura. En cambio, con frecuencia se añaden después de la puesta en marcha, una vez que los auditores o los reguladores formulan preguntas que el sistema nunca fue diseñado para responder. Una gobernanza adaptada a posteriori sobre un sistema en producción cuesta más, cubre menos y llega después de que las decisiones que debía proteger ya se tomaron.

076. El éxito sin sucesión

Este es el modo de falla más común en entornos financiados por donantes, y el más costoso. El equipo del piloto termina su contrato y se va. El tablero sigue activo, pero nadie en la institución puede explicar qué significan los números, validarlos o rastrear un producto hasta su origen. La institución queda con un sistema que no puede operar: más pobre, habiendo gastado presupuesto y credibilidad en una capacidad que no puede sostener.

08El patrón que subyace a los seis

Cada uno de estos modos de falla es una falla de gobernanza, no una falla tecnológica. La solución no es un mejor proveedor ni un presupuesto mayor. Una institución con un presupuesto pequeño y reglas de evidencia claras superará a una con un presupuesto grande y ninguna. La solución es establecer la propiedad, los estándares de evidencia y los criterios de graduación antes de que comience el piloto, no después de que tenga éxito.

Ese es el argumento a favor de la gobernanza antes que la escala: construir la capacidad institucional de confiar en un sistema, auditarlo y sostenerlo antes de decidir si se lo expande.