La preparación para la IA y el problema de la arquitectura organizacional

La mayoría de los despliegues de IA en curso hoy se están preparando con marcos de trabajo de preparación heredados de la transformación digital, y la herencia está produciendo una categoría de dificultad de despliegue que esos marcos de trabajo nunca se diseñaron para diagnosticar. Los marcos de trabajo evalúan calidad de datos, capacidad de infraestructura, disponibilidad de talento y supervisión ética, dimensiones todas necesarias, mientras tratan a la organización misma como un contexto estable en el cual se está introduciendo la capacidad de la tecnología. Lo que la IA le hace a la organización es distinto en su naturaleza de lo que hicieron el ERP, la migración a la nube o la automatización de flujos de trabajo, porque la categoría de disrupción que produce queda fuera de las dimensiones que cubren los marcos de trabajo actuales. Está en la arquitectura de autoridad, en las definiciones de los roles y en las cadenas de accountability que esos marcos de trabajo asumen como dadas, y llega al punto del despliegue, en lugar de aplazarse a algún momento posterior de diseño organizacional. La preparación que excluye la arquitectura organizacional es, en la práctica, preparación para un piloto más grande.

El precedente histórico más instructivo para el momento actual es más antiguo que la transformación digital. Es el momento de la hoja de cálculo de 1979, cuando VisiCalc salió al mercado en el Apple II y comenzó una reestructuración de una década del trabajo analítico, cuyas consecuencias organizacionales se absorbieron, en la mayoría de las organizaciones, mediante ajustes informales en lugar de un rediseño deliberado. El precedente importa porque la forma estructural de lo que ocurrió entonces se parece a un nivel más profundo que la escala, porque la postura de absorción informal con que se manejó la transición de la hoja de cálculo produjo costos que las organizaciones involucradas todavía no han saldado del todo, y porque la IA está reproduciendo esa forma estructural a una escala mayor, en una línea de tiempo comprimida, sobre sistemas organizacionales cuyo trabajo cognitivo se ubica más cerca del centro de la autoridad profesional que el trabajo analítico que la hoja de cálculo desplazó.

El precedente de la hoja de cálculo

VisiCalc salió al mercado en octubre de 1979, y en una década la hoja de cálculo electrónica había desplazado casi por completo una categoría entera de trabajo analítico de la que las funciones de finanzas, estrategia y planificación de las grandes organizaciones habían dependido durante una generación: los equipos de analistas junior cuyo trabajo consistía en construir manualmente modelos financieros, correr análisis de sensibilidad y producir la base cuantitativa para la toma de decisiones ejecutivas. El desplazamiento no fue instantáneo, porque las hojas de cálculo se propagaron por las organizaciones al ritmo al que se propagaron las computadoras personales, ritmo que a comienzos de los ochenta todavía era lento, y la categoría de trabajo analítico no colapsó de un día para otro; sin embargo, dentro de diez años la razón entre analistas y decisión modelada había caído en un orden de magnitud en la mayoría de las funciones de finanzas y estrategia, y la función misma se había redefinido, pasando de la construcción manual a la orquestación algorítmica.

Lo que hace que esa transición sea instructiva para el momento actual es la respuesta organizacional que la tecnología suscitó, que fue casi enteramente informal. Ningún comité ejecutivo encomendó un rediseño de la función de finanzas para considerar lo que la hoja de cálculo le haría, ninguna arquitectura de carrera fue diseñada para los analistas junior cuyo desplazamiento llegaba en cuotas trimestrales, y ninguna estructura de gobernanza fue reformada para acomodar la nueva velocidad a la que podía realizarse el modelado financiero o las nuevas preguntas de legitimidad que surgían cuando un modelo producido en treinta minutos por un analista junior en una computadora personal podía competir, en precisión, con un modelo que antes había requerido tres semanas de trabajo de un equipo de tres personas. Las consecuencias organizacionales se absorbieron de la forma habitual en que las organizaciones absorben los cambios tecnológicos para los que no se han diseñado deliberadamente, es decir, de manera desigual, con daño colateral significativo a las carreras y al conocimiento institucional durante la transición, y con los costos de absorción distribuidos entre las capas menos poderosas de la organización.

Vale la pena nombrar el daño colateral específicamente, porque el discurso actual sobre despliegues tiende a tratar la transición de la hoja de cálculo como una historia benigna de adopción tecnológica en la que la tecnología llegó y la organización se ajustó. Lo que en realidad ocurrió a lo largo de los años ochenta fue que toda una generación de roles de analistas junior, que habían funcionado como la capa de aprendizaje a través de la cual se había desarrollado históricamente la mayor parte del talento senior en finanzas y estrategia, fue vaciada en una década, y la mayoría de las organizaciones descubrió, cinco a diez años después, que había perdido el pipeline por el cual se suponía iba a cultivarse su próxima generación de talento analítico senior. El conocimiento institucional que vivía dentro del proceso de modelado manual, en particular alrededor de cómo se formulaban y probaban los supuestos, se perdió porque el proceso que cargaba ese conocimiento fue automatizado antes de que el conocimiento mismo se capturara explícitamente. La calidad de las decisiones durante la transición fue desigual, porque la velocidad a la que las nuevas herramientas producían análisis corría por delante de la capacidad de la organización para validar lo que ese análisis estaba haciendo, y varias industrias produjeron episodios bien documentados de exceso de confianza analítica en el período temprano de la hoja de cálculo que habrían sido difíciles de producir bajo el régimen manual más lento.

El efecto pipeline es el que más a menudo se malinterpreta en retrospectiva, porque no produjo una crisis visible en el momento en que ocurrió el desplazamiento. Los roles de analista junior por los que se había desarrollado históricamente el talento analítico senior no fueron eliminados en un solo año; fueron reducidos, reposicionados y dejados a la atrofia a lo largo de una década, mientras las organizaciones que habían dependido de ellos continuaron funcionando sobre el stock existente de talento senior formado bajo el régimen anterior. El efecto pipeline salió a la superficie, en la mayoría de las organizaciones, a fines de los noventa y comienzos de los dos mil, cuando la cohorte de analistas senior que debió haber emergido del pipeline de analistas junior de los ochenta no existía en los números esperados, y las organizaciones que descubrieron el vacío tuvieron que reconstruir la ruta de desarrollo mediante mecanismos nuevos cuyo costo no habían presupuestado. El costo del aplazamiento de los ochenta no se absorbió en los ochenta. Se absorbió en los dos mil, por un grupo distinto de ejecutivos, en condiciones que hicieron difícil nombrar la fuente del costo.

Nada de esto era inevitable en sentido estricto. Las organizaciones que pensaron deliberadamente sobre la transición del trabajo analítico, un número pequeño en agregado, terminaron la década con funciones de finanzas coherentes, pipelines de aprendizaje preservados y una gramática operativa para distinguir el trabajo que la hoja de cálculo había automatizado del trabajo que todavía requería juicio humano. La mayoría de las organizaciones no pensó deliberadamente en eso, porque la tecnología parecía estar llegando a una escala que hacía posible la adopción a nivel departamental sin necesidad de un rediseño a nivel organización, y porque el desplazamiento estaba ocurriendo en una capa de la organización cuya ausencia no era inmediatamente visible para los altos tomadores de decisiones cuya atención habría sido necesaria para diseñar la respuesta. El aplazamiento era cómodo, en el sentido ordinario en que los aplazamientos suelen serlo, y la cuenta llegó con un retraso lo suficientemente largo como para que la mayoría de las personas que tendrían que pagarla no fueran las personas que habían tomado la decisión de aplazar.

Lo que la transformación digital pudo permitirse eludir

Los cuarenta años entre VisiCalc y el actual momento de la IA no estuvieron vacíos; consumieron una generación de esfuerzo organizacional en implementaciones de ERP, migraciones a la nube, automatización de flujos de trabajo, construcciones de plataformas de datos y los diversos grandes programas tecnológicos que los practicantes llaman transformación digital. Esos programas fueron consecuentes y con frecuencia dolorosos, con sobrecostos reales, fallas reales y disrupción organizacional real, y produjeron la categoría de deuda de alineamiento que la mayoría de las organizaciones grandes todavía está gestionando. No fueron, sin embargo, estructuralmente similares a lo que la IA hoy le pide a las organizaciones que absorban, y la diferencia estructural explica por qué la transformación digital pudo perseguirse durante una generación sin forzar la pregunta sobre el rediseño de la gobernanza que la IA fuerza.

La diferencia es específica. El ERP, la migración a la nube y la automatización de flujos de trabajo cambiaron cómo se hacía el trabajo sin desafiar quién tenía autoridad sobre él. Un sistema ERP consolidó los procesos financieros entre unidades de negocio, estandarizó las definiciones de datos y produjo una única fuente de verdad financiera, mientras el CFO seguía siendo la autoridad sobre las decisiones financieras, los controllers financieros seguían siendo la autoridad sobre los reportes, y los líderes de finanzas de las unidades de negocio seguían siendo la autoridad sobre las decisiones locales dentro del marco de trabajo consolidado. Una migración a la nube movió las cargas de trabajo desde la infraestructura on-premises sin cambiar qué juicio gobernaba las decisiones que esa infraestructura soportaba, porque la autoridad del CIO y la autoridad de los responsables de aplicaciones se transfirió limpiamente de un paradigma de infraestructura a otro: la tecnología que se migraba no realizaba juicio. Los flujos digitales automatizaron secuencias administrativas, procesamiento de facturas, aprobación de gastos, ruteo de compras y los demás procesos repetitivos que absorbían tiempo profesional sin constituir identidad profesional, dejando en gran medida intacto el trabajo cognitivo sobre el que se habían construido la identidad profesional y la jerarquía organizacional.

Esta característica estructural permitió a la transformación digital aplazar las preguntas de diseño organizacional durante años, en muchos casos durante una década, porque la tecnología operaba dentro de las estructuras de autoridad existentes y podía absorberse sin perturbarlas. Las preguntas sobre quién decide, quién es accountable, qué significan los roles y cómo se distribuye la autoridad en la organización podían gestionarse después, o no gestionarse en absoluto. Muchas organizaciones aún no las han abordado. La deuda de alineamiento que ese aplazamiento acumuló sigue gestionándose, y la mayoría de las organizaciones maduras carga alguna versión de ella: el ERP que se configuró para encajar en el proceso pre-ERP de la organización porque reformar el proceso para que encajara en el sistema habría requerido una redistribución de autoridad que nadie quería liderar; la migración a la nube que replicó modelos operativos on-premises en un paradigma que podría haber soportado modelos fundamentalmente distintos si alguien hubiera estado preparado para rediseñar sobre él; el flujo digital que automatizó la superficie administrativa de un rol mientras dejaba la definición fundamental del rol sin cambios. La deuda existe, se carga, y su gestión se ha internalizado, en la mayoría de las organizaciones, como el precio ordinario de operar a escala.

La disponibilidad del aplazamiento es lo que hizo sobrevivible la transformación digital sin un rediseño organizacional fundamental, y esa disponibilidad es lo que la IA elimina. La tecnología no deja intacta la arquitectura de autoridad, porque la alcanza de manera directa, porque la arquitectura de autoridad fue construida sobre el trabajo cognitivo que la IA hoy realiza, y ninguna cantidad de preparación cuidadosa del despliegue puede preservar lo que la tecnología, por su naturaleza, disrumpe.

Por qué el caso de la IA no puede aplazarse

La función central de la IA, en los despliegues que hoy están dando forma a la práctica organizacional, es la ejecución de trabajo cognitivo que antes constituía la base de la autoridad humana, la identidad profesional y la jerarquía organizacional. Eso es lo que hace la tecnología, razón por la cual los marcos de trabajo de preparación que evalúan las condiciones del despliegue sin abordar lo que el despliegue le hace a la arquitectura de autoridad no están evaluando lo que importa. Un algoritmo que produce consistentemente mejores resultados analíticos que el experto realiza una función de gobernanza vestida de operación, porque la base de la autoridad del experto se redistribuye junto con el análisis sobre el que esa autoridad se construyó, y esa redistribución no puede gestionarse después si ya ha ocurrido a través del despliegue. Un motor de recomendación que sintetiza información de múltiples fuentes más rápido de lo que cualquier individuo puede hacerlo automatiza la función que justificaba la posición del gerente en la cadena de decisión, lo que constituye un evento de rol incluso cuando el despliegue se le llame mejora de productividad. Un sistema de apoyo a la decisión que opera a la velocidad de la interacción con el cliente, en lugar de a la velocidad de la deliberación de un comité, evita el comité por completo, lo que constituye un evento de accountability incluso cuando el despliegue se le llame mejora de flujo de trabajo.

La distinción entre eventos de gobernanza, eventos de rol y eventos de accountability, por un lado, y eventos de herramientas, productividad y flujo de trabajo, por el otro, es la distinción que la mayoría de las discusiones actuales sobre despliegue está fallando en hacer, y la falla es donde el patrón que este artículo intenta nombrar se vuelve visible. Las organizaciones se están preparando para el despliegue de la tecnología como si la categoría de cambio que se está produciendo fuera familiar, cuando no lo es. La categoría familiar, a la escala en que la mayoría de las organizaciones tiene experiencia, es la categoría de automatización de flujos de trabajo que la transformación digital normalizó a lo largo de cuatro décadas. La categoría no familiar, a la escala que la IA está produciendo, es la categoría de redistribución de autoridad que no tiene precedente en el manual estándar y que apareció por última vez, a la escala de toda una capa de trabajo analítico, en el momento de la hoja de cálculo de los ochenta.

Las tres colisiones que llegan juntas

Tres colisiones llegan al punto del despliegue de la IA, y a diferencia de las implicancias organizacionales de la transformación digital, que podían aplazarse durante años, estas no pueden aplazarse en absoluto. Llegan juntas, se componen unas sobre otras y se vuelven visibles en el momento en que el despliegue pasa del piloto a la operación a escala organizacional, que es el momento en que los marcos de trabajo de la era piloto se agotan.

La primera colisión, y la más consecuente de las tres, es la redistribución de la autoridad sin rediseño de la gobernanza. La autoridad sobre una decisión ha residido, históricamente, en el punto de la organización donde se realizaba el trabajo cognitivo requerido para esa decisión, como una propiedad emergente del modo en que las organizaciones construyen su arquitectura de decisión, más que como un principio formal que alguien hubiera elegido deliberadamente. El experto cuyo trabajo cognitivo producía el análisis tenía autoridad sobre la recomendación, porque la recomendación era inseparable del análisis, y el análisis solo podía producirse mediante el trabajo cognitivo que el experto realizaba. Cuando un algoritmo produce el análisis, el trabajo cognitivo se ha reubicado, y la autoridad que antes era inseparable del análisis se vuelve separable de él, lo que significa que la relación de autoridad tiene que rediseñarse explícitamente en lugar de heredarse tácitamente. Si el rediseño no ocurre con antelación, la organización descubre en el momento del despliegue que la pregunta sobre quién tiene autoridad sobre una recomendación producida por el algoritmo está activamente disputada, con el desarrollador del algoritmo reclamando autoridad mediante el trabajo analítico incrustado en el modelo, el experto cuyo rol incluía el análisis reclamando autoridad mediante el conocimiento de dominio sobre el que se entrenó el modelo, el gerente accountable por el resultado reclamando autoridad mediante la cadena de accountability, y el comité de gobernanza reclamando autoridad mediante sus derechos formales de decisión. La disputa no es neutral; se resuelve por los mecanismos ordinarios de la política organizacional, que producen una distribución de autoridad que nadie habría diseñado deliberadamente y que nadie puede deshacer fácilmente una vez que se ha asentado.

La segunda colisión concierne a los roles. Cuando la IA automatiza las funciones de procesamiento de información sobre las que se construyeron los roles profesionales de capa intermedia, los roles no se vuelven más eficientes; se vuelven estructuralmente inciertos, porque las identidades profesionales, las expectativas de compensación y las relaciones organizacionales que descansaban sobre el trabajo automatizado ya no están sostenidas por él. La analista cuyo rol se construyó sobre la elaboración del pronóstico trimestral descubre que el pronóstico ahora se elabora en minutos por un sistema que ella no opera, lo que significa que su trabajo ya no es el pronóstico, y si su rol no se rediseña para especificar qué es en lugar del pronóstico, queda en una posición cuya definición ha sido vaciada sin reemplazo. Las organizaciones que despliegan IA sin rediseñar estos roles con antelación experimentarán el desplazamiento como pérdida de talento, desenganche y un patrón que se diagnosticará, en el idioma estándar, como una falla de gestión del cambio. El diagnóstico tiene una validez estrecha, porque identifica un patrón de falla real, mientras ubica la falla a nivel de comunicación en lugar de a nivel de arquitectura, y los remedios de gestión del cambio que se derivan de él no abordarán lo que la omisión arquitectónica produjo.

La tercera colisión concierne a la accountability, y llega por un mecanismo para el que la arquitectura de gobernanza no tiene protocolo existente. Las recomendaciones generadas por los modelos fluyen a una velocidad que excede la velocidad de la deliberación de un comité, y cuando la velocidad de la recomendación excede la velocidad de la deliberación, la arquitectura de accountability que existía para la toma de decisiones a ritmo humano no tiene procedimiento para la nueva condición. En el régimen anterior, una recomendación llegaba del experto al tomador de decisiones, el tomador de decisiones deliberaba, y la accountability por la decisión se situaba claramente en el punto donde ocurría la deliberación; en el nuevo régimen, la recomendación llega del algoritmo a una velocidad que no permite la deliberación anterior, de modo que la decisión queda hecha efectivamente por la velocidad de la recomendación, en lugar de por el juicio considerado que la arquitectura de accountability asumía. Si la accountability no se ha rediseñado, se difunde, porque nadie tiene el ancho de banda cognitivo para deliberar al ritmo de la recomendación, y el comité de gobernanza cuya revisión se suponía debía proveer el control de accountability descubre que, para cuando su ciclo de revisión se completa, las recomendaciones que debía revisar ya han sido ejecutadas en terreno. La difusión es una consecuencia estructural de la brecha de velocidad entre lo que la tecnología habilita y lo que la arquitectura de gobernanza fue construida para manejar, no una elección que alguien en la organización hizo.

Las tres colisiones no se anuncian discretamente en la línea de tiempo del despliegue. Llegan juntas, se componen unas sobre otras y se vuelven legibles para la organización solo en agregado, habitualmente como un patrón de fricción en el despliegue que los marcos de trabajo que gestionaban el piloto no fueron construidos para describir. Las organizaciones que las abordan con antelación, mediante rediseño de gobernanza, arquitectura de roles y rediseño de accountability preparados antes de que el despliegue llegue a escala, tratan a las tres como una sola pregunta arquitectónica que debe responderse en conjunto. Las organizaciones que las abordan después del hecho, mediante programas de remediación que responden a cada colisión por separado a medida que sale a la superficie, están corriendo el manual de la era de la hoja de cálculo a escala IA y a velocidad IA.

Vale la pena describir la composición específicamente. Una organización que aplaza la pregunta sobre autoridad ve la primera colisión salir a la superficie como ambigüedad sobre quién aprueba una recomendación del algoritmo, una ambigüedad que la segunda colisión amplifica porque los roles de capa intermedia afectados ya no tienen trabajo claro que ancle su posición en la cadena de aprobación, lo que la tercera colisión empuja más allá del punto de recuperación porque la velocidad de las recomendaciones ya ha movido las decisiones al terreno antes de que las preguntas de autoridad y de rol puedan resolverse en deliberación. Las colisiones no se suman linealmente, porque cada una cambia las condiciones bajo las cuales se resuelve la siguiente, y los marcos de trabajo que las abordan como riesgos de despliegue separados a gestionarse en secuencia se pierden la propiedad estructural que hace de las tres un solo problema. Un registro de riesgos de despliegue que lista ambigüedad de autoridad, incertidumbre de rol y difusión de accountability como tres ítems a mitigar en paralelo está tratando la pregunta estructural como tres preguntas operativas manejables, y ese tratamiento produce planes de mitigación que no abordan la composición. La composición es el problema; los tres ítems son sus expresiones de superficie.

Lo que omiten los marcos de trabajo estándar de preparación

Las evaluaciones estándar de preparación para la IA cubren calidad de datos, capacidad de infraestructura, disponibilidad de talento y marcos de trabajo de ética, y cada una de esas dimensiones es real e importante. Las evaluaciones típicamente no cubren la arquitectura organizacional, es decir, las estructuras de gobernanza, los derechos de decisión y las definiciones de roles que el despliegue de la tecnología disrumpirá y que necesitan rediseñarse con antelación si el despliegue ha de producir lo que el piloto sugería posible. La omisión no es accidental. Los marcos de trabajo de preparación los construyen las comunidades cuya pericia es técnica, y representan, en su cobertura, lo que esas comunidades están calificadas para evaluar; la arquitectura organizacional queda fuera de ese alcance, porque su evaluación requiere un tipo distinto de pericia, y los marcos de trabajo que la incluirían, en su mayor parte, no se han construido, porque las organizaciones que los comprarían, en su mayor parte, no han articulado el requerimiento.

El piloto tiene éxito en parte porque opera en un entorno acotado: un solo equipo, un caso de uso definido, un conjunto contenido de stakeholders, un alcance dentro del cual las preguntas de diseño organizacional pueden abordarse localmente o evitarse por completo sin distorsionar el éxito del piloto. El despliegue a escala organizacional remueve todos esos límites, porque introduce a la IA en estructuras de gobernanza que no fueron diseñadas para ella, en autoridades de decisión que redistribuye sin aviso y en arquitecturas de rol que desplaza sin reemplazo. El éxito del piloto no se transfiere, y el marco de trabajo que certificó la preparación del piloto no certifica lo que se requiere para el despliegue que sigue, que es el significado práctico de la afirmación de que la preparación que excluye la arquitectura organizacional es preparación para un piloto más grande.

Lo que realmente requiere la preparación estructural es una postura distinta de evaluación, no una lista de chequeo más larga. El rediseño de gobernanza para la toma de decisiones aumentada por IA necesita resolver, antes del despliegue y no durante él, las preguntas sobre quién revisa las recomendaciones algorítmicas antes de que informen la acción, quién retiene autoridad de anulación bajo qué condiciones, y quién es accountable por las decisiones que las recomendaciones del modelo dieron forma; las organizaciones que redactan especificaciones para esas preguntas antes del despliegue gastan menos capital organizacional, después, gestionando los conflictos que surgen de no haberlas redactado. La arquitectura de autoridad para la colaboración humano-máquina requiere un diseño explícito de cómo se distribuye la autoridad de decisión entre la recomendación algorítmica y el juicio humano a lo largo de cada contexto de decisión que el despliegue afecta, porque la distribución no es constante a lo largo de los tipos de decisión: algunas decisiones pueden moverse sustancialmente hacia la recomendación algorítmica sin riesgo de gobernanza, mientras otras requieren juicio humano que el algoritmo no puede replicar, y diseñar la distinción con antelación es lo que separa un despliegue que produce valor duradero de uno que produce fricción descubrible. El diseño de la evolución de los roles requiere que las organizaciones determinen, antes del despliegue, en qué se convierten los roles cuando su función de procesamiento de información se automatiza, porque los roles no desaparecen cuando su trabajo se automatiza; cambian, y el cambio necesita ser diseñado en lugar de descubierto a través del desplazamiento.

La dimensión de preparación que la mayoría de los marcos de trabajo estándar omite por completo es lo que podría llamarse arquitectura de aprendizaje organizacional, que es la infraestructura de gobernanza requerida para que la organización absorba continuamente los cambios impulsados por la tecnología en el flujo de trabajo, la autoridad y la definición de roles que continuarán llegando mucho después de que cualquier despliegue específico haya cerrado. El despliegue de la IA no es un programa discreto con fecha de cierre, porque la tecnología continuará desarrollándose y sus implicancias organizacionales continuarán acumulándose, y las organizaciones que tratan cada despliegue como un programa discreto con línea de llegada se encontrarán, dentro de cinco años, cargando una arquitectura organizacional acumulada que nadie diseñó deliberadamente, producida a través de una sucesión de despliegues puntuales, ninguno de los cuales abordó el efecto acumulado. Esta es la misma trampa que produjo el momento de la hoja de cálculo, ampliada y comprimida.

Cómo se ve en la práctica la arquitectura de aprendizaje organizacional no es un programa permanente ni un comité dedicado, las dos respuestas predeterminadas a las que recurren las organizaciones cuando reconocen una brecha de gobernanza. Se ve como una disciplina: la disciplina de tratar cada despliegue de IA como un cambio al mapa de autoridad, rol y accountability que se revisa y actualiza formalmente, en lugar de como un programa acotado que cierra en el go-live; la disciplina de mantener, a nivel organizacional y no a nivel de despliegue, una descripción explícita de cómo se distribuye la autoridad de decisión entre el juicio algorítmico y el humano, y de mantener esa descripción al día a medida que nuevos despliegues desplazan la distribución; la disciplina de tratar la evolución de los roles como una responsabilidad organizacional continua en lugar de como un ejercicio único de rediseño. La disciplina es poco vistosa, y rara vez se encomienda con antelación, porque el retorno sobre la inversión es difícil de articular en el lenguaje que hablan la mayoría de los procesos de asignación de capital. Las organizaciones que construyen la disciplina tienden a construirla a través de la experiencia de la alternativa, que es el patrón que este artículo ha estado describiendo.

La pregunta estructural que el despliegue está por hacer

VisiCalc funcionó. Produjo modelos financieros más rápido y con más precisión que los equipos de analistas a los que desplazó, y ese hecho técnico no estuvo, después de los primeros dos o tres años, en disputa significativa. Lo que sí estuvo en disputa, y lo que ninguna organización abordó con antelación, fue si la arquitectura organizacional podía absorber lo que la tecnología le hacía a los roles profesionales, a la autoridad de decisión y a las trayectorias de carrera. La mayoría de las organizaciones absorbió el cambio mediante una década de ajuste informal que produjo el daño colateral ya nombrado, y el éxito de la tecnología y la dificultad de la transición resultaron ser el mismo evento visto desde distintos niveles de la organización.

La IA presenta la misma estructura a una escala mayor, con la misma distinción entre la pregunta técnica y la pregunta organizacional, y la misma tendencia a que la pregunta organizacional se aplace en la expectativa de que pueda gestionarse después. La tecnología funciona. La arquitectura no, en la forma en que la mayoría de las organizaciones la carga actualmente, y la distancia entre lo que el piloto demostró y lo que el despliegue absorberá es donde se acumulará el daño colateral. Las organizaciones que aborden la pregunta arquitectónica de manera deliberada, mediante rediseño de gobernanza, arquitectura de roles y rediseño de accountability preparados con antelación, encontrarán la transición sustancialmente menos costosa que las organizaciones que repitan el patrón de la era de la hoja de cálculo de absorción informal. El daño colateral esta vez será proporcionalmente mayor, porque el trabajo cognitivo que la IA automatiza se ubica más cerca del centro de la autoridad organizacional que el trabajo analítico que VisiCalc desplazó, lo que significa que las organizaciones que aplazan la pregunta arquitectónica no están aplazando un costo periférico. Están aplazando el trabajo central de absorber la tecnología, y el aplazamiento, esta vez, aterrizará sobre las estructuras de autoridad sobre las que opera la organización, a una escala y en una línea de tiempo que no permitirán la misma década de ajuste informal de la que dispuso la era de la hoja de cálculo.