1. Tratar el gasto en AI como una cartera gobernada
Una cartera de AI contiene más que proyectos. Normalmente incluye casos de uso que se espera que cambien los ingresos, los costes, el riesgo o el servicio; capacidades compartidas de datos e integración; suscripciones a modelos y aplicaciones; capacidad de nube o de centros de datos; equipos especializados; funciones de control; y actividades de cambio necesarias para modificar la forma en que se realiza el trabajo. Cada categoría tiene una vida económica, un perfil de dependencia y un grado de reversibilidad diferentes. Un único presupuesto de innovación puede ocultar estas diferencias.
El consejo necesita una visión que concilie los compromisos entre las clasificaciones contables. Parte del gasto puede ser infraestructura capitalizada, parte puede ser gasto operativo y parte puede estar integrada en la nómina de las unidades de negocio o en contratos con proveedores. La cuestión económica es el efectivo y la capacidad incrementales totales comprometidos con la cartera, incluido el coste operativo tras el lanzamiento. Una iniciativa puede parecer asequible durante un piloto porque la integración empresarial, la seguridad, la remediación de datos, el rediseño de procesos, la formación, la monitorización y el coste de funcionamiento quedan fuera del registro del piloto.
Las comunicaciones oficiales muestran por qué importa la disciplina de compromisos. Alphabet informó USD 91.4 billion de gasto de capital en 2025, principalmente infraestructura técnica, y señaló que esperaba un aumento significativo de la inversión en 2026 en servidores, equipos de red y centros de datos.[4] La presentación anual de Microsoft de 2026 indica que las inversiones AI se están realizando a escala significativa y por delante de flujos de ingresos plenamente desarrollados.[5] Meta informó USD 72.22 billion de gasto de capital en 2025, incluidos los pagos de principal de arrendamientos financieros, y previó USD 115 billion a USD 135 billion en gasto de capital en 2026 para apoyar los esfuerzos AI y su negocio principal.[6] Amazon informó USD 96.3 billion de gasto de capital en efectivo en los primeros seis meses de 2026, principalmente infraestructura tecnológica que respalda el crecimiento de AWS y la capacidad de cumplimiento de pedidos.[7] Estas cifras tienen definiciones diferentes y propósitos empresariales mixtos. Su relevancia radica en la magnitud, los largos plazos de entrega y la incertidumbre de la demanda descritos en las presentaciones.
Por lo tanto, la cartera debería revelar cinco totales: gasto acumulado aprobado; compromisos contractuales y de arrendamiento; run rate anual actual; coste operativo previsto a escala; y solicitudes de capacidad no comprometida. También debería identificar qué casos de uso consumen cada capacidad compartida. Esto evita que una plataforma se apruebe como necesidad estratégica mientras sus beneficios dependientes permanecen sin responsable.
2. Otorgue al consejo de administración un mandato de gobernanza definido
La supervisión del consejo debería centrarse en la exposición material, la coherencia de la cartera, el apetito de riesgo y la calidad de la evidencia. No debería exigir a los consejeros elegir modelos ni gestionar sprints de entrega. La dirección sigue siendo responsable de proponer y ejecutar las inversiones. El consejo establece qué compromisos requieren aprobación, qué evidencia debe acompañarlos, cómo opera el cuestionamiento independiente y qué ocurre cuando un caso de uso no cumple sus condiciones.
Los umbrales de aprobación deberían combinar materialidad financiera, riesgo y reversibilidad. Una aplicación de bajo coste que afecte al empleo, al crédito, a la salud, a la seguridad, a infraestructuras críticas o a datos personales sensibles puede merecer una supervisión mayor que una herramienta de productividad de mayor coste. Una reserva de capacidad plurianual puede requerir la atención del consejo porque reduce la flexibilidad estratégica incluso si el efectivo a corto plazo es modesto. Por lo tanto, los umbrales deberían considerar el gasto acumulado, los compromisos no cancelables, las decisiones y usuarios afectados, la sensibilidad de los datos, la autonomía, el alcance geográfico y el coste de salida.
El consejo también necesita un directivo responsable. El director ejecutivo, el director financiero o un patrocinador de transformación designado debería ser responsable del valor de la cartera. Los líderes tecnológicos son responsables de la arquitectura y la evidencia de entrega. Los responsables de negocio son responsables de la línea base operativa, la adopción y los beneficios realizados. Los líderes de riesgo, seguridad, privacidad, legal y cumplimiento son responsables de los estándares independientes dentro de sus mandatos. La auditoría interna puede probar el diseño y el funcionamiento sin convertirse en aprobador de primera línea.
Tabla 1. Derechos de decisión sobre la cartera de AI y titularidad de la evidencia
| Decisión o artefacto | Responsable designado | Cuestionamiento independiente | Evidencia mínima para la aprobación |
|---|---|---|---|
| apetito de cartera y envolvente anual | consejo | finanzas, riesgo y auditoría interna | estrategia, asequibilidad, concentración, apetito de riesgo y capacidad para escenarios adversos |
| problema y línea base del caso de uso | directivo de negocio | responsable de finanzas y procesos | volumen actual, tiempo, calidad, coste, riesgo y resultado para el cliente |
| compromiso de plataforma o infraestructura | directivo de tecnología | arquitectura, compras y finanzas | programación de la demanda, utilización de la capacidad, alternativas, condiciones contractuales y vía de salida |
| preparación y derechos de los datos | propietario de los datos | privacidad, aspectos legales y seguridad | acceso, calidad, linaje, uso permitido, retención, resiliencia y monitorización |
| diseño del modelo y de los controles | responsable de producto o modelo | riesgo de modelo, cumplimiento y seguridad | pruebas, supervisión humana, límites, respuesta a incidentes y riesgo residual |
| lanzamiento piloto | comité de inversiones delegado | funciones de finanzas y control | alcance acotado, línea base, plan de pruebas, presupuesto, reglas de parada y usuarios designados |
| puesta en producción y escalado | comité ejecutivo o consejo en función del umbral | finanzas, riesgo y responsables de los controles afectados | evidencia real del piloto, adopción, eficacia de los controles, economía unitaria y plan de capacidad |
| cierre de beneficios | responsable de negocio y finanzas | oficina de portafolio y auditoría interna en función del riesgo | beneficio verificado, coste total, obligaciones residuales, lecciones aprendidas y disposición de activos |
La asignación es un modelo. Las responsabilidades y delegaciones reales deben ajustarse a la constitución, la normativa y el marco de riesgo de la organización.
3. Hacer del caso de uso la unidad de valor
Un modelo, una plataforma o un data lake rara vez son la unidad directa de valor para el negocio. El valor aparece cuando un grupo definido de usuarios cambia una decisión o un flujo de trabajo y el cambio produce un resultado medible. Por lo tanto, el caso de uso debe especificar el usuario, el proceso operativo, la decisión o tarea, la contribución de AI, la responsabilidad humana, la línea base, el resultado objetivo y los controles afectados. Esta definición crea una línea desde la tecnología hasta el flujo de caja, el servicio o el riesgo.
El límite del caso de uso requiere disciplina. Una afirmación como «mejorar el servicio al cliente con AI» es demasiado amplia para aprobar una inversión. Un caso gobernado podría definir la asistencia para un tipo de contacto, una población de usuarios y un canal especificados; medir el tiempo de gestión, la resolución en el primer contacto, la calidad, las reclamaciones y el escalado; identificar las fuentes de datos y conocimiento aprobadas; y mantener la autoridad humana para las excepciones definidas. El alcance se vuelve comprobable y los costes se vuelven imputables.
La capacidad compartida debe asignarse de forma transparente. Si diez casos de uso requieren una capa de recuperación, controles de identidad y monitorización, el caso de la plataforma debe mostrar la capacidad compartida mínima, la capacidad incremental por caso de uso y la holgura no utilizada. Asignar todos los costes compartidos al primer caso de uso puede hacer que una capacidad viable parezca no económica. Tratar todos los costes compartidos como gastos generales estratégicos puede hacer que cada caso de uso parezca artificialmente atractivo. La cartera debe mostrar el análisis económico tanto antes como después de un método de asignación coherente.
Los casos de uso también necesitan identificadores estables y control de versiones. Un piloto que comienza como asistencia para redacción puede después generar comunicaciones con clientes o formular recomendaciones. Sus perfiles de riesgo, datos y beneficios han cambiado. El registro de aprobación debe mostrar el nuevo límite, el compromiso acumulado y el impacto en los controles, en lugar de permitir que la iniciativa conserve su etiqueta original de bajo riesgo.
4. Exigir un caso de negocio con solidez de inversión
Un caso con solidez de inversión es un registro de decisión que puede resistir el escrutinio financiero, operativo, tecnológico y de riesgos. Comienza con el problema operativo y el contrafactual de operación habitual. Luego compara opciones, identifica la ruta preferida, cuantifica el coste y el beneficio de todo el ciclo de vida, demuestra la entrega y la adopción, y establece los controles necesarios para su uso. Su profundidad debe ser proporcional al compromiso y a las consecuencias.
El Green Book 2026 de HM Treasury describe cinco dimensiones conectadas: estratégica, económica, comercial, financiera y de gestión. También exige evaluación de opciones y proporcionalidad.[17] La guía relacionada sobre casos de negocio desarrolla las propuestas mediante un caso de negocio de esquema estratégico, un caso de negocio de esquema y un caso de negocio completo.[18] Estos marcos del sector público no son reglas de aprobación corporativa. Su valor para los consejos de administración es la separación entre la justificación estratégica, el valor, los acuerdos con proveedores, la asequibilidad y la evidencia de entrega.
El contrafactual merece especial atención. El caso debe comparar la opción preferida de AI con la operación habitual, el rediseño de procesos sin AI, una opción de analítica basada en reglas o convencional, la externalización, la compra y el desarrollo interno. Si el rendimiento de referencia se está deteriorando, mantener el resultado actual puede requerir inversión por sí mismo. Si una transformación existente ya captura parte del beneficio, el caso de AI solo debe atribuirse el efecto incremental.
El caso debe explicitar la incertidumbre sin ocultarla en una única estimación puntual. Los rangos de costes deben reflejar la madurez de la estimación. Los rangos de beneficios deben reflejar la confianza en la medición y en la adopción. El análisis de escenarios debe mostrar los resultados de demanda, precio, utilización, calidad, productividad y control. Las dependencias de la disponibilidad de proveedores, energía, derechos sobre datos, capacidades especializadas y cambio de procesos deben seguir siendo explícitas.
Tabla 2. Evidencia mínima para un caso de negocio de AI
| Campo del caso de negocio | Contenido requerido | Responsable de la evidencia | Criterio de decisión |
|---|---|---|---|
| problema y contrafactual | perímetro del proceso, usuarios, rendimiento actual, causa y trayectoria de operación habitual | responsable del negocio | la línea base es actual, atribuible y relevante para la decisión |
| opciones | rutas de hacer lo mínimo, solo proceso, compra, desarrollo interno, alianza y aplazamiento | sponsor financiero y arquitectura | las alternativas utilizan supuestos coherentes e incluyen las implicaciones de salida |
| beneficios | resultados en ingresos, coste en efectivo, capacidad, calidad, servicio y riesgo | responsable de negocio y finanzas | se definen la métrica, la línea de base, el calendario, el responsable y el método de verificación |
| coste del ciclo de vida completo | construcción, licencia, cómputo, datos, integración, controles, cambio, operación y retirada | finanzas, tecnología y compras | la fecha del precio, el factor de volumen, el rango y la base contractual son trazables |
| preparación de los datos | acceso, calidad, linaje, derechos, representatividad, seguridad y monitorización | propietario de los datos | las limitaciones y la remediación tienen coste, responsable y plazo |
| diseño de controles | clasificación de riesgos, pruebas, supervisión, límites, registro y controles de incidentes y de salida | responsables de riesgo y de control | el riesgo residual se sitúa dentro del apetito de riesgo aprobado y la evidencia es reproducible |
| modelo de adopción y modelo operativo | cambio de procesos, roles, formación, incentivos, soporte y contingencia | responsable del negocio | se designan usuarios responsables y se establece el umbral mínimo de adopción |
| ejecución y dependencias | hitos, capacidad, proveedores, integraciones, decisiones y ruta crítica | responsables del programa y de tecnología | los compromisos se ajustan a la evidencia y a la contingencia |
| economía y escenarios | flujos de caja, asignación, tasa de descuento, sensibilidad, valores de conmutación y escenario a la baja | finanzas | la decisión permanece transparente bajo los supuestos declarados |
La evidencia debe madurar al ritmo del compromiso. Una propuesta de descubrimiento puede utilizar rangos acotados; las decisiones de producción y escalado requieren datos de entrada controlados, trazables y actualizados.
5. Segmente la cartera antes de establecer su ranking
La comparación de la cartera solo funciona cuando se identifican inversiones de distinta naturaleza. Un segmento puede contener casos de uso de ingresos, otro casos de capacidad laboral o de costes, otro aplicaciones de riesgo y control, y otro una capacidad estratégica cuyos beneficios directos se materializan a través de varios casos posteriores. El trabajo de infraestructura y cumplimiento obligatorio debe permanecer visible como capas separadas, en lugar de competir según una medida común de rentabilidad no sustentada.
La cartera también puede segmentarse por madurez. El descubrimiento valida el problema y los datos disponibles. El experimento prueba la viabilidad técnica dentro de un entorno acotado. El piloto prueba el proceso de extremo a extremo, el comportamiento del usuario y los controles. La producción establece un servicio controlado. El escalado aumenta usuarios, volumen, geografía o autonomía. La revisión de beneficios verifica los resultados materializados y determina si la capacidad debe ampliarse, corregirse, mantenerse o retirarse.
La segmentación de riesgos debe influir en la ruta de aprobación. El Marco de Gestión de Riesgos AI del NIST organiza la actividad en torno a gobernar, mapear, medir y gestionar, con la gobernanza operando a lo largo del ciclo de vida de AI.[10] Su perfil de AI generativa identifica acciones para riesgos que pueden ser nuevos o amplificados por sistemas generativos.[11] El marco de rendición de cuentas de la GAO agrupa prácticas en torno a gobernanza, datos, desempeño y monitorización.[12] Estos marcos respaldan un inventario común y permiten que los controles varíen según el caso de uso, el contexto y las consecuencias.
El mapa resultante debería mostrar tanto la exposición estratégica como la financiera. Un experimento pequeño puede permanecer en la cartera de descubrimiento. Un servicio de producción con coste recurrente de modelo y nube pertenece a la cartera comprometida. Una plataforma compartida debería mostrar los casos de uso y la demanda que la justifican. Una inversión obligatoria en controles debería mostrar la exposición que mitiga y las consecuencias operativas de retrasarla.
6. Construir un mapa de cartera de casos de uso
El mapa de cartera compara el valor económico esperado con la confianza de ejecución. El valor económico puede combinar flujo de caja incremental, coste en efectivo evitado, capacidad utilizable, mejora del servicio y reducción del riesgo, con etiquetas separadas cuando la conversión monetaria es débil. La confianza de ejecución combina claridad del problema, evidencia del beneficio, preparación de los datos, diseño de controles, adopción y capacidad de entrega. El tamaño de la burbuja puede representar el coste anual recurrente o el compromiso acumulado.
El mapa orienta la acción. Los casos de alto valor y alta confianza son candidatos a una escala controlada. Los casos de alto valor y baja confianza merecen una inversión específica en evidencia en lugar de un compromiso automático. Los casos de menor valor y alta confianza pueden seguir siendo útiles cuando habilitan capacidad estratégica, cumplen una obligación o ofrecen una vía rápida a la adopción. Los casos de menor valor y baja confianza normalmente deberían detenerse, fusionarse o volver a la definición del problema.
Una oficina de cartera debería impedir que el mapa se convierta en un concurso de belleza. Las puntuaciones necesitan definiciones ancladas, fechas de origen y responsables. El comité debería ver rangos de confianza e incumplimientos de líneas rojas. También debería ver la concentración por proveedor, modelo, proveedor de nube, dominio de datos, proceso de negocio y función de control. Diez casos de uso individualmente atractivos pueden crear una dependencia compartida material.
Los casos de uso, las puntuaciones y los costes anuales recurrentes son supuestos de modelización hipotéticos. El tamaño de la burbuja representa el coste anual; el mapa respalda la gobernanza y no establece una previsión ni una recomendación.
[/FIGURE]
7. Avanzar los beneficios mediante una escala de confianza
La confianza en los beneficios debe ganarse con evidencia. Una hipótesis de la dirección puede justificar el gasto de descubrimiento. No debería respaldar un gran compromiso de producción. Un piloto controlado puede establecer si la tecnología cambia el desempeño de la tarea en condiciones definidas. La evidencia de producción puede mostrar si el proceso más amplio, los usuarios y los controles sostienen el resultado. La verificación financiera puede confirmar si el cambio generó resultados en efectivo, capacidad, servicio o riesgo después de costes y efectos de desplazamiento.
La escala evita la falsa precisión. Un beneficio puede tener un importe estimado alto y una confianza baja. Otro puede tener un importe menor y evidencia más sólida. La cartera debería informar de ambos. La confianza debería disminuir cuando el caso de uso cambia de población, datos, modelo, proceso o escala, porque la evidencia anterior podría no ser transferible.
La investigación de la OCDE sobre la adopción de AI indica que la incertidumbre sobre el retorno de la inversión y la madurez insuficiente de los datos son barreras importantes, y que los directivos pueden subestimar las implicaciones culturales y de procesos en toda la empresa.[8] Una revisión separada de la OCDE sobre investigación experimental concluye que el desempeño depende de la tarea y de la experiencia del usuario, mientras que la evidencia organizativa a largo plazo sigue siendo limitada.[9] Estos hallazgos respaldan una transferencia cautelosa de experimentos de tareas individuales a afirmaciones sobre el flujo de caja de la empresa.
El área de finanzas debería definir la evidencia requerida en cada nivel. El tiempo ahorrado no se traduce automáticamente en efectivo ahorrado. Puede crear capacidad, mejorar el servicio, reducir horas extraordinarias, evitar contrataciones o permitir una reducción de plantilla; cada vía tiene evidencia y consecuencias diferentes. El aumento de ingresos requiere un grupo de control creíble u otro método de atribución. La reducción del riesgo puede requerir un análisis de pérdida esperada o de coste de control y debería preservar resultados no financieros graves que no son aptos para una monetización simple.
La escalera define la madurez de la evidencia. No asigna una probabilidad universal ni un incremento de valoración a un nivel de confianza.
[/FIGURE]
8. Establecer la línea base y el contrafactual
La línea base debe registrar el desempeño antes de la intervención AI. Según el caso de uso, puede incluir volumen de transacciones, tiempo de tramitación, retrabajo, errores, defectos, pérdidas, conversión, margen, reclamaciones, tiempo de ciclo, nivel de servicio, excepciones de control y esfuerzo de los empleados. Deben documentarse los sistemas de origen, el período de medición, las exclusiones y la estacionalidad. Una línea base construida después de un piloto exitoso puede introducir sesgo de selección.
El contrafactual define lo que ocurriría sin la inversión propuesta. La operación habitual puede incluir tendencias de productividad existentes, cambios de precios contractuales, planes de plantilla, mejora de procesos y otras implementaciones tecnológicas. El caso de negocio debe evitar atribuirse beneficios ya esperados de estos factores. Cuando un control aleatorizado no sea práctico, un despliegue por fases, un grupo emparejado, una serie temporal interrumpida o una comparación antes-después definida pueden aportar evidencia útil si se declaran las limitaciones.
Los beneficios necesitan una cadena desde la métrica operativa hasta los estados financieros o un resultado sujeto a gobernanza. Los minutos ahorrados por tarea se convierten en capacidad anual solo después de multiplicarlos por el volumen elegible, la adopción, la reducción sostenida de tiempo y la reasignación productiva. La capacidad se convierte en coste evitado solo cuando cambia un plan de contratación aprobado o se elimina un gasto de terceros. Los ingresos se convierten en contribución después del coste de entrega, la canibalización, los descuentos, el abandono de clientes y los impuestos cuando corresponda. El consejo debe ver cada puente.
El marco de Beneficios Digitales y de Datos del Reino Unido se desarrolló para ayudar a cuantificar los beneficios de los programas digitales y de datos, y está previsto que se utilice junto con la guía Green Book.[19] El Marco de Eficiencia Gubernamental también vincula los ahorros identificados con la gestión de beneficios y con disposiciones de gobernanza más amplias.[20] Su contexto de sector público difiere del de una cartera corporativa. La disciplina general sigue siendo útil: definir tipos de beneficios, métodos de medición, titularidad y la relación entre el cambio operativo y el valor.
9. Convertir la preparación de los datos en una puerta de decisión para el capital
La preparación de los datos tiene valor económico directo porque la remediación consume tiempo, esfuerzo especializado y atención operativa. También afecta al rendimiento y al riesgo de control. Un caso de uso debe identificar los datos necesarios, el propietario de los datos, la base legal o el derecho contractual, la vía de acceso, la calidad, la completitud, el linaje, la representatividad, la retención, la clasificación de seguridad, la resiliencia y la monitorización. Las incógnitas deben conllevar consecuencias de coste y calendario.
La evaluación de preparación debe separar la existencia de un conjunto de datos de un acceso utilizable. Los datos pueden estar distribuidos entre sistemas, bloqueados en contratos con proveedores, disponibles solo mediante extracción manual o no ser adecuados para la frecuencia requerida. Las etiquetas pueden ser inconsistentes. Los resultados históricos pueden reflejar políticas pasadas que han cambiado. Los datos de entrenamiento pueden no representar a los usuarios actuales ni los casos límite. Una afirmación de alto nivel de que la organización tiene datos no resuelve estas cuestiones.
El mapa de calor debe utilizar puntuaciones ancladas. Una puntuación roja significa que una condición definida está ausente o es inaceptable. Ámbar significa que la remediación está financiada y acotada. Verde significa que la evidencia actual satisface la puerta. Gris significa que la dimensión no se ha evaluado. Los promedios pueden ocultar fallos críticos, por lo que las cuestiones de derechos, seguridad o uso prohibido deben seguir siendo visibles incluso cuando otras dimensiones estén maduras.
La economía del caso de uso debe incluir la remediación de datos y el control continuo. Un producto de datos puede respaldar varios casos de uso, lo que permite una asignación compartida de costes. El consejo debe ver los casos de uso que justifican la inversión, la secuencia requerida y el riesgo de que la demanda prevista no se materialice.
Las puntuaciones son supuestos hipotéticos de modelización: 1 significa ausente o inaceptable, 3 significa remediación acotada y 5 significa evidencia lista para la puerta.
[/FIGURE]
10. Conciliar la economía de todo el ciclo de vida
El modelo de costes debería incluir descubrimiento, desarrollo, integración, datos, seguridad, validación, licencias, inferencia de modelos, nube o infraestructura, cambio, formación, soporte, monitorización y retirada. También debería incluir personal interno cuando represente capacidad escasa o contratación incremental. Los compromisos de volúmenes mínimos, capacidad reservada, arrendamientos y contratos take-or-pay deben mostrarse por separado del uso variable.
El modelo de beneficios debería distinguir entre efectivo, capacidad, ingresos, servicio y riesgo. Estas categorías no deben sumarse en un único total monetario a menos que la base de conversión sea creíble. Un caso puede mostrar un retorno de efectivo positivo y un resultado separado de cliente o de control. Un caso de uso obligatorio de cumplimiento puede tener un retorno convencional limitado a la vez que preserva el permiso para operar. Su coste sigue compitiendo por capital y capacidad de entrega.
El ejemplo hipotético siguiente utiliza un modelo nominal a cinco años, una tasa de descuento del 11 %, ningún valor terminal y un tratamiento fiscal simplificado. Supone que los costes de implementación se producen antes del escalado, que los beneficios aumentan gradualmente con la adopción y que el coste operativo anual aumenta con el volumen. Excluye la estructura de financiación, el tipo de cambio, el capital circulante, la capitalización contable y las interacciones con otros programas. Son supuestos de modelización, no datos de mercado.
Tabla 3. Economía hipotética del caso de uso desde el piloto hasta el escalado
| Componente económico | Caso base | Escenario adverso | Evidencia e implicación para la decisión |
|---|---|---|---|
| descubrimiento, piloto y creación de controles | 1.2 | 1.5 | alcance aprobado y base de estimación antes del piloto |
| integración y remediación de datos | 2.8 | 4.2 | entrega por fases a medida que se cumplen los hitos de datos |
| escalado y cambio de procesos | 2.0 | 3.0 | dependiente de la adopción y de la evidencia en producción |
| coste operativo anual al alcanzar la madurez | 1.8 | 2.6 | Los supuestos de volumen, precio y enrutamiento de modelos requieren seguimiento |
| beneficio bruto anual en efectivo al alcanzar la madurez | 5.4 | 2.9 | requiere un efecto de plantilla, proveedor o contribución verificado por Finanzas |
| VAN a cinco años | 5.7 | -2.6 | El caso base respalda un escalado condicional; el escenario adverso cruza el umbral de parada |
| periodo de recuperación descontado | Año 4 | No alcanzado | el escalado debe mantenerse por fases hasta que mejore la confianza en los beneficios |
Los valores son hipotéticos, en millones de USD. El VAN utiliza una tasa de descuento nominal del 11 por ciento durante cinco años y no incluye valor terminal; los totales están redondeados y no representan una previsión.
Los valores de conmutación mejoran la decisión. El caso debe mostrar el nivel de adopción, el precio unitario, la tasa de error, el beneficio por transacción o el volumen en el que el VAN alcanza cero o un umbral del consejo de administración. También debe mostrar el efectivo en riesgo antes de la próxima decisión reversible. Esto centra el debate en los supuestos que determinan el valor.
La visión de cartera debe evitar la doble contabilización. Una plataforma de datos compartida no puede atribuirse el beneficio completo de cada caso de uso dependiente mientras cada caso de uso también reclama el mismo valor. Un beneficio de productividad no puede contabilizarse como reducción de costes, evitación de contrataciones e ingresos adicionales a menos que la organización tenga una asignación creíble de la capacidad liberada. Finanzas debe mantener un registro de beneficios con un único propietario y un único tratamiento para cada resultado.
11. Asignar un precio explícito a la infraestructura, la capacidad y la energía
La economía de AI puede cambiar con la elección de modelo, el consumo de tokens o de cómputo, la latencia, la longitud del contexto, el almacenamiento en caché, la utilización, la capacidad reservada, el almacenamiento, la transferencia de datos, la depreciación del hardware y la disponibilidad de energía. El consejo no necesita una hoja de tarifas técnicas. Necesita los factores impulsores unitarios, los compromisos contractuales, la sensibilidad y la mitigación.
La Agencia Internacional de la Energía informa que los centros de datos centrados en AI crecieron rápidamente y que el uso de energía por tarea simple de AI ha mejorado sustancialmente, mientras que usos más intensivos como vídeo, razonamiento y agentes pueden consumir mucha más energía.[3] También informa de un crecimiento amplio e incierto de la capacidad de los centros de datos y de la demanda eléctrica. La implicación para un caso de uso corporativo es que el coste por tarea debe medirse con la carga de trabajo real en lugar de suponerse a partir de una demostración.
La aprobación de capacidad debe basarse en evidencia de demanda. Una empresa puede reservar infraestructura por razones estratégicas, protección del suministro o latencia, pero el caso debe mostrar utilización comprometida, valor de opción y riesgo a la baja. Los equipos con largos plazos de entrega, los contratos de energía y los arrendamientos de centros de datos pueden reducir la reversibilidad. La declaración de Alphabet, por ejemplo, describe proyectos de centros de datos plurianuales y compromisos significativos de infraestructura técnica.[4] El patrón de hechos es específico de la empresa; ilustra cómo la economía de la infraestructura va más allá de un piloto de software breve.
El enrutamiento de modelos puede preservar valor. Los modelos de menor coste pueden gestionar tareas acotadas, y los modelos más grandes se utilizan para excepciones. La recuperación, el almacenamiento en caché, el diseño de prompts y las restricciones de proceso pueden reducir el consumo. La cartera debe monitorizar el coste por resultado empresarial completado y aceptado, no solo el coste por solicitud. Los resultados fallidos, repetidos o corregidos manualmente deben incluirse en el denominador.
12. Diseñar los controles como parte de la inversión
Los controles son requisitos de producto y operativos con coste, calendario y titularidad. Deben diseñarse junto con el caso de uso en lugar de añadirse tras el éxito técnico. El conjunto de controles puede incluir finalidad aprobada, acceso, minimización de datos, pruebas, revisión humana, segregación, restricciones de resultados, registro, monitorización, respuesta a incidentes, supervisión de proveedores, conservación de registros, contingencia y retirada.
La proporcionalidad de los controles es importante. El marco del NIST es voluntario y agnóstico al caso de uso, y hace hincapié en la gestión continua del riesgo a lo largo del ciclo de vida.[10] ISO/IEC 42001 especifica un sistema de gestión AI para organizaciones que proporcionan o utilizan AI y utiliza una estructura de mejora continua.[13] La guía revisada de 2026 de la Reserva Federal sobre riesgo de modelos hace hincapié en un enfoque basado en el riesgo adaptado al perfil de modelos, tamaño y complejidad de una organización bancaria.[14] La guía bancaria se aplica dentro de su ámbito regulatorio declarado. Su lección de gobernanza más amplia es que la validación, las limitaciones, la supervisión y los controles deben ser proporcionales al uso significativo.
Las obligaciones legales requieren un análisis específico de la jurisdicción. La Ley AI de la UE utiliza una estructura basada en el riesgo y se aplica de forma progresiva; la Comisión Europea informó de que las facultades de ejecución y ciertas obligaciones de transparencia se aplicaban desde agosto de 2026, mientras que otras disposiciones de alto riesgo quedaban sujetas a fechas posteriores.[15][16] Un documento para el consejo debe indicar el rol de la organización, su ubicación, la clasificación del caso de uso y el asesoramiento jurídico. Una etiqueta genérica de «conforme a AI» es insuficiente.
Tabla 4. Diseño de controles vinculado a la evidencia de inversión
| Dominio de riesgo | Evidencia mínima de control | Indicador operativo | Consecuencia del hito de decisión |
|---|---|---|---|
| Finalidad y responsabilidad | Uso aprobado, propietario, usuarios, límites y acciones prohibidas | Eventos de uso no autorizado y cambios de alcance | Detener el lanzamiento hasta que el límite y la titularidad estén claros |
| datos y privacidad | controles de fuente, derechos, minimización, conservación, calidad y acceso | excepciones, deriva, fallo de acceso y rendimiento de la eliminación | retener o restringir la población |
| rendimiento y validación | prueba representativa, criterios de aceptación, análisis de errores y limitaciones | calidad, resultado falso, anulación y retrabajo | revalidar tras cambios materiales en el modelo, los datos o los procesos |
| supervisión humana | autoridad de decisión, punto de revisión, competencia y escalado | tasa de revisión, calidad de la anulación y escalado omitido | reducir la autonomía o suspender el uso |
| seguridad y resiliencia | modelo de amenazas, controles de proveedores, pruebas, registro, respaldo y recuperación | incidentes, latencia, disponibilidad y tiempo de recuperación | activar la autoridad de contingencia y de incidentes |
| equidad y partes afectadas | evaluación de impacto, pruebas por subgrupos, vía de reclamación y remedio | diferencia de resultados, reclamaciones y remediación | acotar el alcance, corregir o detener |
| proveedor y concentración | diligencia debida, niveles de servicio, notificación de cambios, derechos de auditoría y de salida | precio, disponibilidad, cambio de modelo y concentración | renegociar, tener doble fuente o limitar la exposición |
La tabla es un modelo de gobernanza y no sustituye los requisitos legales, regulatorios, de seguridad, de privacidad o específicos del sector.
13. Utilice puertas de control para alinear la autoridad con el compromiso
Las puertas deben autorizar un siguiente compromiso definido. La puerta 0 acepta el problema en la fase de descubrimiento. La puerta 1 aprueba un experimento acotado una vez que estén claros la línea base, el acceso a los datos y el plan de pruebas. La puerta 2 aprueba un piloto cuando el proceso, los usuarios, los controles y el método de medición de beneficios estén listos. La puerta 3 aprueba el lanzamiento a producción tras superarse la evidencia de rendimiento y control de extremo a extremo. La puerta 4 aprueba el escalado tras demostrarse la adopción y la economía unitaria. La puerta 5 cierra la realización de beneficios y determina la expansión, el mantenimiento o la retirada.
Cada puerta debe tener cuatro resultados posibles: avanzar; avanzar con condiciones con plazo definido; quedar en espera de evidencia; o detener. Las condiciones requieren un responsable, un elemento de evidencia, una fecha límite y una consecuencia. Las aprobaciones condicionales repetidas deben notificarse porque pueden convertir la falta de evidencia en una exposición permanente.
La autoridad de aprobación debe aumentar con el compromiso y las consecuencias. Un equipo delegado puede aprobar un experimento pequeño y aislado. Un comité de inversiones puede aprobar un lanzamiento a producción. El consejo de administración puede aprobar un compromiso importante de infraestructura, un cambio material en la automatización o un caso de uso de altas consecuencias. La actuación de emergencia sigue siendo posible mediante una excepción definida y una revisión retrospectiva.
La evidencia de las puertas es acumulativa. La autoridad de aprobación debe reflejar el compromiso acumulado, el riesgo, la reversibilidad y los usuarios afectados.
[/FIGURE]
14. Explicite las decisiones de detener o escalar
La aceptación técnica demuestra que un sistema puede funcionar. La evidencia de adopción demuestra que las personas lo utilizan en el proceso previsto y que el resultado operativo se mantiene. Un caso de escalado debe definir usuarios y transacciones elegibles, uso activo, frecuencia, finalización, aceptación, anulación, retrabajo, contingencia y soporte. También debe identificar el trabajo que pasó fuera del sistema medido.
La adopción debe medirse frente a un denominador de proceso. El número de usuarios con licencia es una evidencia débil si solo una pequeña parte del trabajo elegible pasa por el sistema. Un uso elevado también puede resultar engañoso si el resultado se descarta o se corrige. Los resultados aceptados por transacción elegible proporcionan un puente más sólido hacia el valor.
El diseño de procesos y los incentivos importan. Los usuarios pueden saltarse un control lento o poco fiable. Los directivos pueden fomentar el uso sin cambiar la carga de trabajo ni los objetivos. Los empleados pueden ahorrar tiempo pero recibir más trabajo, lo que afecta a la calidad y a la retención. Un caso de negocio debe indicar cómo cambian los roles, las medidas de desempeño, la formación, la supervisión, el soporte y la consulta a la plantilla. Cuando se apliquen derechos laborales o acuerdos colectivos, se requiere asesoramiento especializado.
El piloto debe representar a la población operativa prevista. Voluntarios entusiastas, datos limpios y un volumen bajo pueden sobreestimar el desempeño a escala. Una prueba en producción debe incluir usuarios habituales, periodos punta, excepciones y recuperación ante fallos. Por lo tanto, los umbrales de adopción deben combinarse con umbrales de calidad y de control.
15. Haga explícitas las decisiones de detener o escalar
Una revisión de detener o escalar combina la confianza en los beneficios, la economía unitaria, la adopción, la preparación de los datos, la eficacia de los controles y la capacidad de entrega. Debe realizarse en una fecha o un volumen determinados y antes del siguiente compromiso material. La decisión es una acción de cartera, no una puntuación retrospectiva del proyecto.
Escalar puede significar más usuarios, transacciones, países, unidades de negocio, fuentes de datos, autonomía o capacidad del modelo. Cada forma cambia el riesgo y el coste de manera diferente. La aprobación debe especificar la dimensión de escalado y la evidencia que sigue siendo válida. Un caso de uso que se amplía a una nueva jurisdicción legal o a una población afectada puede requerir una reclasificación y una nueva revisión de controles.
Detener debe tener un plan operativo. El equipo necesita autoridad para rescindir un contrato, liberar la capacidad reservada, archivar datos, retirar accesos, conservar registros, notificar a los usuarios, revertir el proceso y capturar aprendizajes. Una narrativa de costes hundidos no debe mantener vivo un caso de uso no económico o sin control.
Tabla 5. Matriz de decisión de detener o escalar
| Dimensión de la decisión | Señal de escalado | Señal de mantener o corregir | Señal de detención |
|---|---|---|---|
| confianza en los beneficios | efecto en producción controlada y puente de financiación | existe efecto piloto, pero la atribución o el escalado están incompletos | sin efecto material en condiciones representativas |
| economía unitaria | coste del resultado aceptado dentro del rango aprobado | coste por encima del rango con remediación acotada | el escenario negativo sigue sin ser económico con valores de cambio creíbles |
| adopción | uso sostenido del proceso elegible por encima del umbral | uso desigual con un plan de cambio con responsabilidades definidas | la omisión o el rechazo persistentes socavan el caso de beneficios |
| preparación de los datos | derechos, calidad, acceso y monitorización listos para el hito de decisión | remediación financiada con condiciones con plazos definidos | derechos no resueltos, seguridad o fallo grave de calidad |
| controles | eficacia de diseño y operativa evidenciada | excepciones no críticas con responsable y plazo | riesgo residual fuera del apetito de riesgo o control crítico fallido |
| entrega y capacidad | recursos, proveedores y soporte comprometidos para escalar | la dependencia sigue siendo condicional | capacidad crítica, proveedor o modelo operativo no disponible |
Los umbrales son ejemplos hipotéticos. Cada organización debe fijar umbrales de materialidad, riesgo y evidencia dentro de su marco de gobernanza.
Los valores y umbrales son supuestos hipotéticos de modelización. Los colores de estado resumen la evidencia subyacente y no establecen por sí solos la preparación ni el valor.
[/FIGURE]
16. Control de proveedores, concentración y salida
La selección de proveedores puede determinar el coste, el rendimiento, el uso de datos, la auditabilidad, la resiliencia del servicio y la salida. El caso de negocio debe distinguir entre proveedor de modelos, proveedor de aplicaciones, proveedor de nube o infraestructura, integrador y proveedor de datos. Un único contrato puede combinar varios roles. La concentración debe evaluarse a nivel de cartera, porque distintas unidades de negocio pueden generar una gran exposición compartida sin una visión central.
La diligencia debida debe abarcar el alcance del servicio, los factores que impulsan el precio, los mínimos, la capacidad, la seguridad, la privacidad, la propiedad intelectual, el uso de datos de entrenamiento, los cambios de modelo y funcionalidades, los subcontratistas, la notificación de incidentes, la ubicación de los datos, la auditoría, la cooperación regulatoria, la portabilidad, la transición y la terminación. Las afirmaciones de los proveedores deben contrastarse con el uso previsto y la evidencia interna. Una certificación o norma puede respaldar la diligencia debida, aunque sigue siendo insuficiente para la aceptación del caso de uso.
La economía de salida debe cuantificarse. La exportación de datos, la reconstrucción de flujos de trabajo, la recualificación de usuarios, la operación en paralelo y la retención de registros pueden ser relevantes. Un cambio de modelo puede alterar el rendimiento sin una versión de software convencional. Por tanto, los contratos y las operaciones deben contemplar preaviso, pruebas y reversión. Cuando el doble suministro no sea económico, el consejo debe ver la dependencia aceptada y el plan de contingencia.
La oficina de cartera debe mantener un calendario de compromisos. Debe mostrar fechas de renovación, revisiones de precios, escalones de volumen mínimo, reservas de capacidad y ventanas de rescisión. Una decisión de detener tomada después de una renovación automática ofrece menos protección económica que una revisión programada antes de la fecha de compromiso.
17. Proporcione al consejo un cuadro de mando basado en evidencias
El cuadro de mando del consejo debe ser compacto y trazable. Necesita totales de cartera, movimiento desde la reunión anterior, decisiones requeridas y excepciones relevantes. Debe mostrar gasto aprobado, compromisos, run rate anual, coste previsto a escala, beneficio por nivel de confianza, adopción, fallos de controles críticos, hitos de control de datos, concentración y casos de uso que se acercan a la revisión de detener o escalar.
Los agregados requieren desglose. Un promedio verde de cartera puede ocultar un caso de uso rojo de altas consecuencias. El consejo debe ver excepciones por compromiso acumulado y riesgo. También debe ver condiciones pendientes desde hace tiempo, aplazamientos reiterados de hitos y beneficios que se han mantenido en nivel de hipótesis o piloto mientras continuaba el gasto.
El valor previsto y el valor realizado deben permanecer separados. El cuadro de mando puede mostrar el beneficio esperado ponderado por confianza a efectos de escenarios, pero esto no debe reportarse como valor realizado. Los resultados de caja, capacidad, ingresos y servicio verificados por Finanzas necesitan sus propias líneas. El coste evitado debe identificar el plan o contrato aprobado que cambió.
La documentación del comité debe indicar supuestos y cambios relevantes. Un precio de modelo más bajo, un mayor volumen de usuarios, una licencia de datos revisada o una nueva regulación pueden cambiar el caso de negocio. El control de versiones debe conservar la base aprobada en cada hito y explicar el movimiento actual. Esto respalda la rendición de cuentas sin crear un caso de negocio estático que quede obsoleto tras el lanzamiento.
18. Movilice el sistema de gobernanza en noventa días
El primer mes debe establecer el inventario y el límite de decisión. La dirección debe identificar todos los casos de uso de AI, las plataformas, los compromisos de infraestructura, las suscripciones, los proveedores y los dominios de datos. Cada partida recibe un responsable, madurez, gasto acumulado, run rate, próxima fecha de compromiso y clasificación de riesgo. Finanzas concilia el libro mayor y los contratos con el inventario.
El segundo mes debe establecer el estándar común de evidencia. Los responsables de negocio definen líneas base y mecanismos de beneficio. Los equipos de tecnología y datos evalúan la arquitectura y la preparación. Las funciones de control definen hitos proporcionados. Compras identifica la concentración y la exposición a renovaciones. La oficina de cartera mapea dependencias e identifica casos cuyo próximo compromiso debe pausarse a la espera de evidencia.
El tercer mes debe ejecutar el primer ciclo de detener o escalar. La dirección selecciona los casos de mayor exposición y con el compromiso más próximo. El comité de inversiones prueba casos de negocio, condiciones y vías de salida. El consejo aprueba el marco de la cartera, las excepciones relevantes y la frecuencia futura de reporte. Los equipos operan entonces el sistema como un proceso de decisión recurrente.
Tabla 6. Movilización en noventa días de la gobernanza de capex de AI
| Periodo | Trabajo principal | Resultado requerido | Decisión del consejo o del comité |
|---|---|---|---|
| días 1-15 | inventariar casos de uso, plataformas, infraestructura, contratos y responsables | registro de cartera controlado con compromisos acumulados | confirmar alcance, directivo responsable y señales de alerta inmediatas |
| días 16-30 | conciliar gasto, ritmo de ejecución, renovaciones, capacidad y dependencias compartidas | línea base de asequibilidad y concentración | pausar compromisos materiales no respaldados cuando esté autorizado |
| días 31-45 | definir estándares de evidencia de casos de uso, beneficios, datos y control | plantilla de caso de negocio y criterios de decisión por etapas | aprobar vías proporcionales y límites delegados |
| días 46-60 | evaluar los casos de mayor exposición y las capacidades compartidas | mapa de cartera, niveles de confianza y mapa de calor de preparación | asignar responsables de remediación, fechas y reglas de parada |
| días 61-75 | completar revisiones representativas de detención o escalado | documentos de decisión con análisis económico, adopción y controles | avanzar, condicionar, mantener o detener cada caso revisado |
| días 76-90 | establecer panel de control, aseguramiento y calendario recurrente | documentación para el consejo, registro de beneficios y calendario de compromisos | aprobar el marco de la cartera y la cadencia de informes |
La secuencia es indicativa. Los plazos deben reflejar la escala de la cartera, las obligaciones regulatorias, la disponibilidad de datos y la madurez de la gobernanza existente.
La oficina debe comenzar con decisiones materiales, no con una reconstrucción histórica completa. Los experimentos de menor valor pueden situarse en una vía simplificada. Los elementos con alto compromiso, altas consecuencias o próximos a su renovación merecen atención inmediata. El inventario puede madurar mientras el sistema de gobernanza empieza a proteger la siguiente decisión.
Conclusión
AI la gobernanza de capex conecta el avance tecnológico con la disciplina de capital. El consejo necesita una cartera conciliada de casos de uso, capacidades compartidas y compromisos. Cada caso de uso material necesita un problema operativo definido, un contrafactual, economía de todo el ciclo de vida, preparación de datos, diseño de controles, plan de adopción y un responsable de beneficios con rendición de cuentas. La evidencia debe madurar a través de puertas antes de que aumente el compromiso.
El sistema descrito en este artículo utiliza cinco instrumentos vinculados: un mapa de la cartera de casos de uso, una escala de confianza en los beneficios, un mapa de calor de preparación de datos, puertas de control y un panel de control para detener o escalar. En conjunto, muestran qué casos merecen financiación para descubrimiento, cuáles necesitan remediación específica, cuáles están listos para un escalado controlado y cuáles deben cerrarse. También revelan exposiciones compartidas de infraestructura y proveedores que no pueden gobernarse un experimento a la vez.
La buena gobernanza preserva el aprendizaje mientras protege el capital. Un caso detenido puede producir evidencia útil cuando los compromisos están acotados y las lecciones se capturan. Un caso escalado gana mayor autoridad mediante un desempeño representativo, la adopción por parte de los usuarios, controles eficaces y valor verificado por finanzas. El papel del consejo es hacer explícitos esos estándares y asegurar que la dirección los aplique antes de que la cartera resulte difícil de revertir.
Apéndice A. Preguntas del consejo para un compromiso material de AI
- ¿Qué problema operativo y qué proceso afectado están dentro del alcance?
- ¿Qué ocurre en el curso habitual del negocio y qué opciones no relacionadas con AI se probaron?
- ¿Qué beneficios son resultados de efectivo, capacidad, ingresos, servicio o riesgo?
- ¿Cuál es el nivel actual de confianza para cada beneficio y qué evidencia lo incrementa?
- ¿Cuáles son los compromisos de efectivo, capacidad y contractuales durante todo el ciclo de vida?
- ¿Qué condiciones de derechos sobre los datos, calidad, linaje, seguridad y monitorización siguen abiertas?
- ¿Qué decisiones humanas, partes afectadas y jurisdicciones están implicadas?
- ¿Qué controles se requieren antes del piloto, la producción y el escalado?
- ¿Qué umbrales de adopción y calidad activan el escalado, la pausa o la detención?
- ¿Cuál es el próximo compromiso irreversible y el plan de salida antes de asumirlo?
Apéndice B. Paquete mínimo de evidencia para detener o escalar
- Definición actual del caso de uso e historial de versiones.
- Método de medición de la línea base, el contrafactual y los beneficios.
- Gasto real y previsto, compromisos y coste anual de funcionamiento.
- Resultados de piloto o producción en usuarios y condiciones representativos.
- Evidencia de adopción, aceptación, retrabajo, anulación y respaldo.
- Estado de preparación de los datos y remediación pendiente.
- Resultados de las pruebas de control, incidentes, limitaciones y aceptación del riesgo residual.
- Rendimiento de proveedores, concentración, renovación y posición de salida.
- Economía de escenarios, valores de conmutación y efectivo en riesgo antes de la próxima puerta de decisión.
- Recomendación de la dirección con condiciones, responsable, fecha y consecuencia.
Referencias
- Banco de Pagos Internacionales, Financiación del auge de la AI: de los flujos de caja a la deuda, Boletín del BIS n.º 120, publicado el 7 de enero de 2026. https://www.bis.org/publ/bisbull120.htm
- Banco de Pagos Internacionales, La carrera de inversión en AI, artículo de investigación del BIS n.º 1367, publicado el 14 de julio de 2026. https://www.bis.org/publ/work1367.htm
- Agencia Internacional de la Energía, Cuestiones clave sobre energía y AI, publicado en 2026. https://www.iea.org/reports/key-questions-on-energy-and-ai
- Alphabet Inc., Informe anual en el formulario 10-K para el ejercicio finalizado el 31 de diciembre de 2025, presentado el 5 de febrero de 2026. https://www.sec.gov/Archives/edgar/data/1652044/000165204426000018/goog-20251231.htm
- Microsoft Corporation, Informe anual en el formulario 10-K para el ejercicio finalizado el 30 de junio de 2026, presentado el 30 de julio de 2026. https://www.sec.gov/Archives/edgar/data/789019/000119312526323660/msft-20260630.htm
- Meta Platforms, Inc., Informe anual en el formulario 10-K para el ejercicio finalizado el 31 de diciembre de 2025, presentado el 29 de enero de 2026. https://www.sec.gov/Archives/edgar/data/1326801/000162828026025534/meta-12312025x10kars.htm
- Amazon.com, Inc., Informe trimestral en el formulario 10-Q para el trimestre finalizado el 30 de junio de 2026, presentado el 31 de julio de 2026. https://www.sec.gov/Archives/edgar/data/1018724/000101872426000026/amzn-20260630.htm
- OCDE, Boston Consulting Group e INSEAD, La adopción de la inteligencia artificial en las empresas: nuevas pruebas para la formulación de políticas, publicado el 2 de mayo de 2025. https://doi.org/10.1787/f9ef33c3-en
- OCDE, Los efectos de la AI generativa en la productividad, la innovación y el emprendimiento, Documentos de inteligencia artificial de la OCDE n.º 39, publicado el 20 de junio de 2025. https://doi.org/10.1787/b21df222-en
- Instituto Nacional de Estándares y Tecnología, Marco de gestión de riesgos de inteligencia artificial 1.0, publicado el 26 de enero de 2023. https://doi.org/10.6028/NIST.AI.100-1
- Instituto Nacional de Estándares y Tecnología, Marco de gestión de riesgos de inteligencia artificial: perfil de inteligencia artificial generativa, publicado el 26 de julio de 2024. https://doi.org/10.6028/NIST.AI.600-1
- Oficina de Rendición de Cuentas del Gobierno de Estados Unidos, Inteligencia artificial: un marco de rendición de cuentas para agencias federales y otras entidades, GAO-21-519SP, publicado el 30 de junio de 2021. https://www.gao.gov/products/gao-21-519sp
- Organización Internacional de Normalización, ISO/IEC 42001:2023 Tecnología de la información — Inteligencia artificial — Sistema de gestión, publicada en diciembre de 2023. https://www.iso.org/standard/81230.html
- Junta de Gobernadores del Sistema de la Reserva Federal, Guía revisada sobre la gestión del riesgo de modelos, SR 26-2, publicada el 17 de abril de 2026. https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm
- Comisión Europea, Ley AI: Marco regulatorio para la inteligencia artificial, actualizado el 3 de agosto de 2026. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- Unión Europea, Reglamento (UE) 2024/1689 por el que se establecen normas armonizadas sobre inteligencia artificial, publicado el 12 de julio de 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Tesorería de Su Majestad, El Libro Verde 2026, publicado el 5 de febrero de 2026. https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government/the-green-book-2026
- Tesorería de Su Majestad, Guía para la elaboración de casos de negocio, actualizada el 30 de junio de 2026. https://www.gov.uk/government/publications/guidance-on-developing-business-cases
- Departamento de Ciencia, Innovación y Tecnología y Servicio Digital del Gobierno, Marco de beneficios digitales y de datos, publicado el 7 de abril de 2026. https://www.gov.uk/government/publications/digital-and-data-benefits-framework
- Oficina del Gabinete y HM Treasury, The Government Efficiency Framework, publicado en 2025. https://www.gov.uk/government/publications/the-government-efficiency-framework/the-government-efficiency-framework--2
