Hay un punto en el que el software deja de ser algo que una organización construye y empieza a convertirse en algo que ha heredado. Los gobiernos conocen este problema particularmente bien.
Un gran ecosistema de software se parece un poco a una ciudad antigua. Nadie lo diseñó todo de una sola vez. Una generación construye algo útil, la siguiente construye a su alrededor y, con el tiempo, terminas con infraestructura nueva que atraviesa decisiones tomadas por personas que se fueron hace décadas.
En el software, esas capas son aplicaciones, reglas de negocio, infraestructura, dependencias de proveedores, lenguajes de programación y documentación de valor arqueológico variable. Nadie se despierta una mañana y decide crear un ecosistema tecnológico enorme y complicado. Se acumula porque la organización sigue existiendo.
Tarde o temprano, sin embargo, tienes que ocuparte de lo que heredaste.
Y la IA cambió lo que está en juego. Durante años, la deuda técnica fue en gran medida un problema de capacidad humana. ¿Cuántos desarrolladores podías asignar a un sistema de legado? ¿Qué tan rápido podían entender sistemas desconocidos? ¿Cuánto podías modernizar antes de que la siguiente parte quedara obsoleta?
La IA cambia ese cálculo en dos direcciones. Les da a las organizaciones nuevas herramientas para entender el software y trabajar en él a una escala que antes estaba limitada por la atención humana. También le da a cualquiera que intente atacar ese software herramientas más poderosas. Los modelos siguen mejorando, y también las capacidades al alcance de cualquiera que quiera encontrar vulnerabilidades, analizar sistemas o explotar debilidades.
Eso convierte cuarenta años de código acumulado en algo más que un costoso problema de mantenimiento. Cada vez más, es un pasivo que las organizaciones necesitan entender antes de que alguien más lo haga.
Ese es el problema que el Gobierno de Alberta se propuso abordar, y los Velocity White Papers son, en esencia, un registro de lo que pasó cuando lo hizo. A lo largo de 22 documentos, Alberta detalla su enfoque para usar IA agéntica con el fin de entender, proteger y modernizar un parque de software construido durante décadas. Los documentos cubren desde la arquitectura y las herramientas detrás del trabajo hasta los experimentos, las metodologías y las prácticas técnicas desarrolladas en el camino, y el código y los recursos asociados están disponibles abiertamente.
El Gobierno de Alberta informó que un equipo con unos 50 agentes de IA evaluó 466 millones de líneas de código gubernamental en unas 20 horas, en busca de vulnerabilidades de seguridad, debilidades de infraestructura y vacíos en la documentación.
Veinte horas es el tipo de cifra que llama la atención, pero la cifra no es realmente la razón por la que el trabajo de Alberta nos parece interesante. Lo que importa es que alguien lo intentó primero.
Hay un problema curioso con la IA en este momento: todo el mundo está experimentando y casi nadie sabe bien cuánto de lo que está viendo es señal y cuánto es humo. La tecnología tiene un potencial enorme, pero averiguar cómo usarla bien es, en sí mismo, un proceso de descubrimiento.
La primera organización que recorre ese proceso tiene que cometer todos los errores. Tiene que averiguar qué funciona, qué no, qué infraestructura falta, qué necesita aprender la gente, dónde están los riesgos y qué idea aparentemente ingeniosa resulta ser bastante menos ingeniosa en la práctica. Sin embargo, una vez hecho ese trabajo, alguien más puede empezar más arriba en la cuesta.
Eso es lo que hace que valga la pena prestar atención a los Velocity White Papers de Alberta.
En lugar de guardar esas lecciones dentro de la organización, Alberta las documentó como un conjunto de prácticas, herramientas y orientaciones reutilizables. Los documentos describen cómo las personas aprenden a trabajar con agentes de IA, cómo los agentes reciben contexto organizacional, cómo se acota y se observa su trabajo, cómo se evalúa el software y cómo esas prácticas pueden aplicarse en un gran ecosistema tecnológico. Alberta también puso los documentos y las herramientas asociadas a libre disposición para que otros gobiernos y organizaciones puedan usar el trabajo y construir sobre él.
Es algo notablemente útil en un momento en que tantas organizaciones intentan entender qué significa realmente la IA para ellas.
Las organizaciones son buenas para tener iniciativas. No son ni de cerca tan buenas para convertir esas iniciativas en conocimiento compartido. Un equipo descubre algo, una persona se convierte en la experta interna, se hace una presentación y, seis meses después, otro equipo comienza el mismo experimento con un conjunto de supuestos ligeramente distinto. Es una forma bastante ineficiente de aprender.
Poner el trabajo por escrito cambia la economía del aprendizaje. El siguiente equipo puede empezar con el conocimiento acumulado en lugar de la pregunta original. Puede discutir el método, mejorarlo, adaptarlo o decidir que algo no aplica en su caso. Lo que no tiene que hacer es redescubrir cada lección por su cuenta.
Git Insights es un buen ejemplo. El conjunto de datos público relaciona 4041 registros de aplicaciones con 2182 capacidades de negocio en 40 dominios, lo que crea una visión de qué hace el software del gobierno, qué tecnología usa, dónde hay riesgo y hacia dónde podría dirigirse el esfuerzo de modernización.
Es difícil imaginar un punto de partida más útil para una organización que tiene que lidiar con 466 millones de líneas de código. Antes de transformar algo, por lo general necesitas entender qué tienes. Suena casi insultantemente obvio. En una organización grande, rara vez lo es.
Hay una razón por la que todavía estudiamos los diarios astronómicos babilónicos. Siglos después, esas tablillas de arcilla acadias siguen siendo útiles porque los babilonios dejaron algo más que simples observaciones; dejaron datos empíricos que permitieron a las generaciones posteriores construir sobre lo que habían observado. El conocimiento se vuelve considerablemente más valioso cuando la siguiente persona puede ver dónde empezaste.
Los Velocity White Papers les dan a otras organizaciones algo parecido: un lugar por donde empezar.
Y hay otra lección enterrada en el trabajo de Alberta. La infraestructura necesaria para que la IA sea útil resulta ser notablemente familiar.
Buena documentación. Estándares claros. Mejor infraestructura de pruebas. Automatización. Prácticas de despliegue. Conocimiento de cómo funcionan realmente los sistemas y las bases de datos. Estas siempre han sido las cosas que hacen que las organizaciones de software funcionen bien, aunque rara vez han sido los elementos más glamorosos de la hoja de ruta tecnológica de nadie. Mejoraban la continuidad, reducían la fricción y le hacían la vida más fácil a quien heredaba tu código seis meses después.
La IA vuelve ese trabajo de base considerablemente más trascendente.
Un agente de IA puede moverse rápido por una base de código, pero la velocidad no sirve de mucho si la base de código contiene patrones que no deberían repetirse, si la infraestructura de pruebas es débil o si nadie ha explicado con claridad cómo se supone que funciona el sistema. El agente necesita saber cómo se ve lo “correcto”. Cuanto mejor sea el entorno alrededor del agente, más útil se vuelve el agente.
El trabajo de Alberta sugiere que esta preparación puede tener una recompensa muy tangible. La provincia informa ahorros de unos 5 millones de dólares a la semana gracias a su trabajo de modernización con IA, y al mismo tiempo empieza a adelantarse a la deuda técnica en lugar de quedarse siempre atrás.
Ahí es donde los Velocity White Papers se vuelven más interesantes que una colección de experimentos exitosos con IA. Alberta no se limitó a encontrar algunas aplicaciones útiles para una nueva tecnología; documentó el trabajo de averiguar cómo una organización puede usarla de verdad, incluida la preparación menos glamorosa que hace que la tecnología sea eficaz desde el principio.
Y quizá esa sea una de las formas más útiles de pensar hoy en la adopción de IA. Puede que las organizaciones que más se benefician no sean las que ejecutan la mayor cantidad de experimentos ni las que producen las demostraciones más impresionantes. Quizá sean las que aprenden a convertir un experimento en conocimiento institucional, y el conocimiento institucional en la forma en que trabaja la organización.