El modelo operativo de AI: titularidad, datos, controles y seguimiento de beneficios

1. Gobernar un sistema empresarial en lugar de una colección de herramientas de AI

La primera pregunta del consejo de administración sobre AI debería referirse al resultado operativo que la empresa pretende cambiar. Una licencia, un modelo, un asistente o un piloto son un insumo. El valor surge cuando la empresa cambia una decisión, un proceso, un producto o una propuesta al cliente y puede sostener ese cambio dentro de los límites de riesgo aprobados. El modelo operativo conecta la capacidad tecnológica con una acción empresarial con rendición de cuentas.

Esta distinción importa porque una cartera puede parecer activa y seguir siendo económicamente débil. Los equipos pueden contar demostraciones, usuarios, prompts o documentos generados. Esas métricas dicen poco sobre ingresos, costes, efectivo, servicio, calidad o riesgo. Un caso de uso puede funcionar bien en una prueba controlada y fallar en producción porque el acceso a los datos, la integración de flujos de trabajo, la adopción por parte de los empleados, la fiabilidad de los proveedores o la aceptación de los clientes son inadecuados.

Los Principios de la OCDE sobre AI exigen responsabilidad, trazabilidad y gestión sistemática del riesgo a lo largo del ciclo de vida de AI [1]. NIST organiza la gestión del riesgo de AI en torno a Gobernar, Mapear, Medir y Gestionar [3][4]. ISO/IEC 42001 enmarca la gestión de AI como un sistema de políticas, objetivos y procesos de mejora continua [7]. Estas fuentes respaldan una conclusión corporativa práctica: la gobernanza de AI pertenece al modelo operativo y no debe situarse al margen como un apéndice de cumplimiento.

Una cadena operativa completa contiene cinco objetos vinculados. La estrategia identifica la decisión o el flujo de trabajo que merece la pena cambiar. Una carta de caso de uso define el alcance, el propietario y el resultado previsto. Los controles de datos y modelos establecen si la capacidad puede operar de forma responsable. Las puertas de decisión del ciclo de vida determinan si puede avanzar. Un registro de beneficios muestra si el cambio llegó a la cuenta de resultados, al flujo de caja, al balance general, al resultado de servicio o a la posición de riesgo. El consejo de administración recibe una vista integrada de los cinco.

Cada capa tiene un responsable designado, un conjunto de evidencias, un derecho de decisión y una frecuencia de revisión.

2. Establecer el inventario empresarial antes de priorizar la cartera

La dirección no puede gobernar lo que no ha identificado. El inventario debe cubrir modelos desarrollados internamente, modelos alojados externamente, AI integrada en software empresarial, asistentes para empleados, componentes de decisión automatizada, modelos analíticos, agentes, productos habilitados por modelos y experimentos significativos. También debe registrar el uso en la sombra descubierto mediante encuestas, registros de acceso, datos de adquisiciones, controles de red y revisión del negocio.

La unidad de registro debe ser el caso de uso y no el nombre del proveedor. Un modelo de propósito general puede dar soporte al servicio al cliente, la programación, el marketing y la revisión de contratos, con datos, usuarios, decisiones y consecuencias diferentes. A la inversa, un caso de uso puede depender de varios modelos, servicios de recuperación de información, fuentes de datos y aplicaciones de flujo de trabajo. El inventario debe representar ambas relaciones.

Cada registro necesita un responsable de negocio, un responsable técnico, un nivel de riesgo, los usuarios previstos, las partes interesadas afectadas, el rol en la decisión, las categorías de datos, las dependencias de modelos y proveedores, la jurisdicción, el estado del ciclo de vida, la fecha de aprobación, los requisitos de monitorización, el responsable de beneficios y la ruta de retirada. El registro debe identificar si el sistema recomienda, redacta borradores, predice, clasifica, decide, actúa o controla otro sistema. La autonomía y la reversibilidad a menudo importan más que la sofisticación del modelo.

El inventario también respalda la economía de la cartera. Se pueden identificar licencias duplicadas, pilotos solapados y canalizaciones de datos incompatibles. Una capacidad común puede servir a varios casos de uso, mientras que un modelo especializado de alto coste puede tener un único responsable con un alcance estrecho. La dirección puede entonces asignar costes compartidos, negociar con proveedores y decidir qué plataformas merecen escalarse.

Tabla 1. Inventario empresarial mínimo de AI

El inventario reúne la evidencia operativa, técnica, de riesgo y financiera en un único registro controlado.

3. Diseñar el modelo operativo en torno a seis responsabilidades

Un programa AI necesita más que un comité directivo. Deben hacerse visibles seis responsabilidades. El consejo aprueba el apetito de riesgo, la inversión significativa y la supervisión. El sponsor ejecutivo es responsable de la tesis de la cartera. El responsable de negocio asume la adopción del flujo de trabajo y el resultado operativo. El responsable técnico asume la arquitectura, la implementación y el rendimiento del servicio. Las funciones de control independientes cuestionan la evidencia de riesgos, privacidad, seguridad, aspectos legales y cumplimiento. Finanzas controla la línea base de beneficios y valida el valor realizado.

Los roles pueden combinarse en una organización más pequeña, pero las responsabilidades deben seguir siendo distintas. La persona que propone un caso de uso puede preparar la evidencia. Un despliegue relevante sigue beneficiándose de que lo cuestione alguien que no construyó el modelo ni es responsable del beneficio previsto. La independencia puede ser proporcional al riesgo, el coste y la escala organizativa.

Los derechos de decisión deben vincularse a los eventos del ciclo de vida. El propietario de un producto puede aprobar un cambio de configuración de bajo impacto. Un comité de riesgos puede aprobar un despliegue de alto impacto. El consejo de administración puede reservarse las decisiones que impliquen capital relevante, consecuencias para la plantilla, elegibilidad de clientes, seguridad, resultados sujetos a regulación o exposición reputacional. La autoridad para la suspensión de emergencia debe ser explícita y estar disponible de inmediato.

Los comités deben decidir en lugar de recibir presentaciones. Cada punto del orden del día debe indicar la decisión solicitada, las opciones, la evidencia, el responsable, las limitaciones no resueltas y la próxima revisión. La oficina de portafolio mantiene los estándares y los registros. No debe absorber la responsabilidad del ejecutivo cuya función utiliza el sistema.

Tabla 2. Derechos de decisión en el modelo operativo AI

R significa responsable; A, responsable final; C, consultado; e I, informado; la asignación exacta debe reflejar el tamaño de la organización y los requisitos aplicables.

4. Convertir la estrategia en una carta de caso de uso controlada

La carta es el contrato mínimo útil entre la estrategia, la ejecución, el control y las finanzas. Define el problema de negocio, el flujo de trabajo actual, los usuarios previstos, las partes afectadas, el rol en la decisión, la intervención propuesta, el resultado esperado, las restricciones, las dependencias, el responsable, el techo de costes, el plan de evidencias y las condiciones de salida. Debe ser lo bastante breve para gobernar y lo bastante precisa para someterse a prueba.

El flujo de trabajo actual merece la misma atención que el modelo propuesto. La dirección necesita el tiempo de ciclo de referencia, la tasa de error, la tasa de conversión, el coste, la carga de control y el resultado para el cliente antes de automatizar. Los procesos débiles pueden convertirse en procesos débiles más rápidos. Por tanto, un caso de uso debe identificar qué paso cambia, qué decisiones siguen siendo humanas y qué proceso posterior absorbe la salida.

La carta debe indicar la finalidad prevista del modelo y los usos prohibidos. Un sistema diseñado para resumir documentos no debe desviarse hacia decisiones de elegibilidad de clientes sin una nueva evaluación. Un asistente de ventas no debe incorporar materiales confidenciales de operaciones porque su interfaz lo haga conveniente. Unos límites claros favorecen el diseño de accesos, la monitorización y la formación de los empleados.

Los criterios de éxito deben abarcar cuatro dimensiones: rendimiento técnico, adopción operativa, eficacia del control y resultado financiero o de servicio. Un caso de uso avanza solo cuando existe evidencia en las dimensiones relevantes para su nivel. Esto evita que puntuaciones de modelo impresionantes hagan superar la puerta a un caso operativo débil.

La carta también debe definir una hipótesis de decisión. En ella se indica quién tomará una decisión distinta, qué evidencia aporta el sistema, con qué rapidez debe tomarse la decisión y cómo sabrá la dirección que el cambio mejoró el resultado. Esto obliga al sponsor financiero a identificar la acción humana o automatizada entre la salida del modelo y el valor. Una previsión que se detiene en la calidad de la salida sigue siendo incompleta.

Los criterios de salida son igualmente importantes. La dirección puede detener un caso de uso cuando el problema haya desaparecido, la intervención no pueda alcanzar su umbral, la economía del proveedor haya cambiado, la carga de control supere el valor o una mejora de proceso más sencilla funcione mejor. La carta debe indicar cómo se cerrarán el acceso, los datos, los registros, los contratos y las dependencias posteriores. Una vía de salida planificada refuerza la disciplina de capital al inicio de la inversión.

5. Clasificar los casos de uso por niveles según su consecuencia, autonomía, exposición y reversibilidad

La clasificación por niveles de riesgo debe determinar la intensidad de la gobernanza. La clasificación puede considerar la consecuencia de un error, el grado de automatización, las partes interesadas afectadas, la escala de exposición, la sensibilidad de los datos, el contexto legal, la novedad del modelo, la explicabilidad, la dependencia externa y la reversibilidad. Un asistente de redacción utilizado por empleados formados difiere sustancialmente de un sistema autónomo que modifica el acceso de los clientes o mueve dinero.

El nivel debe asociarse al caso de uso en su contexto. Un mismo modelo puede tener bajo impacto para una lluvia de ideas interna y alto impacto cuando su salida influye en la contratación, el crédito, los precios, la seguridad o la salud. Esta visión por caso de uso se alinea con los enfoques basados en riesgo recogidos en el Reglamento AI de la UE [9][10], el AI RMF del NIST [3], la revisión de ASIC sobre la gobernanza de licenciatarios [27] y el marco de riesgo de modelos de OSFI [29].

Una estructura práctica puede contener cuatro niveles internos. El nivel uno abarca asistencia acotada con baja consecuencia y revisión humana clara. El nivel dos abarca recomendaciones operativas o contenido que puede afectar a clientes o a resultados financieros. El nivel tres abarca decisiones materiales, datos sensibles, alta autonomía o flujos de trabajo regulados. El nivel cuatro abarca actividades prohibidas o fuera del apetito de riesgo. Los niveles internos nunca deben presentarse como clasificaciones legales sin un análisis específico de la jurisdicción.

La clasificación por niveles es dinámica. El aumento del volumen, nuevos datos, una actualización del proveedor, una mayor autonomía, nuevos grupos de usuarios o un incidente material pueden cambiar la clasificación. Por tanto, el inventario debe registrar la base, el aprobador y la fecha de la próxima revisión.

La matriz es una herramienta de gestión; las clasificaciones jurídicas requieren un análisis aparte.

Tabla 3. Disparadores de nivel ilustrativos y controles mínimos

La dirección debe adaptar el desencadenante y el conjunto de controles a la legislación aplicable, al sector y al apetito de riesgo.

6. Tratar los derechos sobre los datos y el linaje de datos como requisitos operativos previos

El rendimiento y la rendición de cuentas de AI dependen de datos que la organización pueda identificar, usar, proteger y reproducir. El archivo de control de datos debe registrar la fuente, el propietario, la finalidad permitida, la base legal o contractual, la clasificación, la ubicación geográfica, la retención, las pruebas de calidad, las transformaciones, el linaje y los usos posteriores. También debe identificar datos personales, confidenciales, privilegiados, sujetos a derechos de autor, licenciados y sensibles.

Los derechos sobre los datos pueden ser tan importantes como la calidad de los datos. Un conjunto de datos técnicamente útil puede no estar disponible para el entrenamiento de modelos, la recuperación o el procesamiento por parte de proveedores. Los acuerdos con clientes, las condiciones laborales, los derechos sobre bases de datos, la propiedad intelectual, las normas de privacidad y las obligaciones sectoriales pueden limitar su uso. La aprobación legal debe vincularse a una finalidad y un flujo de datos específicos, y no a la etiqueta amplia de AI.

El linaje debe seguir los datos desde la fuente pasando por la preparación, la recuperación, el contexto de las indicaciones, la interacción con el modelo, el almacenamiento de resultados y la decisión posterior. Esto facilita la reproducción, el análisis de incidentes, la eliminación, la revisión de accesos y la atribución de beneficios. La OCDE vincula la rendición de cuentas de AI con la trazabilidad entre conjuntos de datos, procesos y decisiones [1][2]. La directriz final E-23 de la OSFI también hace hincapié en la idoneidad, la procedencia y la gobernanza de datos empresariales para los modelos [29].

Los datos de producción deben compararse con los datos de desarrollo y de prueba. Los cambios en la población, los campos ausentes, las nuevas categorías, la estacionalidad y las soluciones alternativas operativas pueden debilitar un modelo sin cambiar su código. El diseño de monitorización necesita umbrales de calidad de datos y un responsable que pueda corregir el proceso de origen.

7. Controlar la cadena completa de dependencias del modelo y de los proveedores

El sistema relevante suele extenderse más allá de un único modelo. Puede incluir un modelo fundacional, embeddings, una base de datos de recuperación, una capa de orquestación, un filtro de seguridad, reglas de negocio, una aplicación, un servicio en la nube, revisión humana y un sistema posterior. Un modelo operativo debe registrar la cadena e identificar qué parte controla cada componente.

La diligencia debida de proveedores debe cubrir el uso previsto, la arquitectura del servicio, el tratamiento de datos, los subencargados, las versiones del modelo, la seguridad, la evidencia de pruebas, las condiciones de propiedad intelectual, la confidencialidad, la retención, la notificación de incidentes, los niveles de servicio, los derechos de auditoría, la notificación de cambios, la continuidad del negocio, la terminación y la devolución de datos. Un nombre de proveedor destacado no sustituye la diligencia debida del caso de uso.

La configuración puede cambiar el comportamiento de forma sustancial. Las indicaciones del sistema, las fuentes de recuperación, la temperatura, las herramientas, los permisos, la memoria, los límites de acción y las reglas de respaldo deben formar parte de una gestión de cambios controlada. Un proveedor puede actualizar el modelo subyacente mientras el nombre de la aplicación permanece sin cambios. La empresa necesita un desencadenante definido para volver a probar y volver a aprobar.

La concentración debe ser visible a nivel de cartera. Varios flujos de trabajo críticos pueden depender de un único proveedor de modelos, plataforma en la nube o servicio de datos. El consejo debe comprender la dependencia en materia de interrupciones, precios, contratos y estrategia, y después decidir qué alternativas, respaldos o procedimientos manuales son proporcionados.

Tabla 4. Evidencia a lo largo de la cadena de dependencia de AI

El conjunto de evidencias debe ser proporcional al nivel del caso de uso y a la capacidad de la empresa para controlar cada componente.

8. Tomar decisiones de construir, comprar y configurar en función de la economía operativa total

La decisión de construir o comprar debe incluir la diferenciación estratégica, la ventaja en datos, la complejidad de integración, los requisitos de control, el tiempo hasta el valor, el talento, la infraestructura, la dependencia de proveedores y el coste total del ciclo de vida. El piloto más barato puede convertirse en una costosa dependencia operativa cuando se incluyen la integración, el aseguramiento, la monitorización y el cambio.

Comprar un modelo no transfiere la responsabilidad del caso de uso. La empresa sigue siendo titular del propósito, los usuarios, los datos, el flujo de trabajo, las decisiones, la monitorización y el resultado para el cliente. Construir internamente proporciona mayor control sobre algunos componentes y crea obligaciones para ingeniería, seguridad, documentación, mantenimiento y continuidad del talento.

La configuración suele ser la vía corporativa dominante. La empresa combina modelos externos con datos propietarios, prompts, reglas y flujo de trabajo. Esto puede crear valor diferenciado sin entrenar un modelo fundacional. También crea un sistema cuyo rendimiento depende de muchos componentes cambiantes. El modelo operativo debe gobernar el conjunto configurado.

El caso de inversión debe distinguir la capacidad de plataforma reutilizable del gasto específico de cada caso de uso. La identidad, el registro, la evaluación, el acceso seguro a los datos y la orquestación pueden dar soporte a múltiples casos. Finanzas puede asignar costes compartidos de forma transparente mientras la dirección evita imputar a cada caso de uso temprano la totalidad de la plataforma.

9. Utilice puertas de ciclo de vida que exijan evidencia en lugar de entusiasmo

El ciclo de vida puede contener seis puertas: descubrir, diseñar, validar, desplegar, escalar y retirar. Cada puerta debe tener criterios de entrada, evidencia requerida, autoridad de decisión, aprobaciones condicionales y una vía de excepción con plazo definido. Una puerta se cierra cuando la evidencia respalda la siguiente exposición, no cuando el equipo del proyecto ha completado una presentación.

El descubrimiento confirma el problema, el responsable y la línea base. El diseño define el flujo de trabajo, los datos, el sistema y la arquitectura de control. La validación prueba el rendimiento técnico, el proceso humano, la seguridad y los derechos pertinentes. El despliegue introduce una exposición controlada a producción. El escalado requiere evidencia de que la adopción, los controles y los beneficios siguen siendo sólidos con mayor volumen. La retirada elimina el acceso, las dependencias y los datos retenidos de forma controlada.

El playbook de NIST proporciona acciones en materia de gobernanza, mapeo, medición y gestión [4]. El perfil generativo de NIST AI añade atención a riesgos como la confabulación, la integridad de la información, la privacidad, la seguridad y la propiedad intelectual [5]. La puerta del ciclo de vida debe convertir tales consideraciones en evidencia del caso de uso.

La aprobación condicional puede ser valiosa cuando las limitaciones son conocidas y están contenidas. El registro debe especificar el alcance, la medida mitigadora, el responsable, la caducidad y la evidencia necesaria para la renovación. Las excepciones sin plazo definido permiten que las debilidades del piloto se conviertan en diseño de producción permanente.

La exposición solo debería aumentar después de que estén presentes la evidencia y la autoridad pertinentes.

10. Valide el sistema en el contexto en el que operará

La validación debe probar el sistema, el flujo de trabajo y el comportamiento del usuario frente al uso previsto. La evaluación técnica puede incluir precisión, fiabilidad, robustez, sesgo, explicabilidad, privacidad, seguridad, latencia y coste. La evaluación operativa debe examinar la escalación, la revisión humana, las acciones posteriores, los casos límite, el volumen de excepciones y la recuperación.

El conjunto de pruebas debe reflejar la población de producción y los modos de fallo relevantes. El rendimiento medio puede ocultar resultados deficientes en eventos poco frecuentes, grupos específicos de clientes o casos de alto valor. Los umbrales deben vincularse a las consecuencias. Un pequeño error de redacción y una instrucción de pago incorrecta exigen una tolerancia distinta.

La revisión crítica independiente debe ser proporcional. El revisor debe comprender el caso de uso, los datos, el modelo, el flujo de trabajo y los requisitos aplicables, y después evaluar si la evidencia respalda el despliegue. En casos de uso de mayor impacto, el revisor debe poder reproducir las pruebas clave y cuestionar la elección de la métrica, la población, el umbral y la medida mitigadora.

Los sistemas generativos necesitan evaluación cualitativa y adversarial, además de puntuaciones de referencia. Las pruebas pueden abarcar afirmaciones no respaldadas, inyección de prompts, filtración de datos confidenciales, contenido dañino, uso indebido de herramientas, respuestas incoherentes y comportamiento de rechazo. El perfil generativo AI del NIST y las directrices de desarrollo seguro de CISA y socios internacionales proporcionan puntos de referencia relevantes [5][17][18].

La verdad de referencia debe estar gobernada. Las etiquetas y las respuestas esperadas pueden contener desacuerdo entre expertos, políticas desactualizadas o sesgo histórico. El registro de validación debe identificar quién creó los casos de prueba, la fecha de la fuente, el método de revisión, la incertidumbre y la cobertura de la población. Cuando no se disponga de una respuesta exacta, la dirección puede evaluar si el sistema cita evidencia autorizada, expresa incertidumbre y escala adecuadamente.

La evaluación también debe reflejar la frecuencia y el coste. Un asistente de alto volumen puede requerir monitorización automatizada y revisión experta por muestreo. Una decisión material poco frecuente puede justificar la revisión completa del caso. El modelo operativo debe presupuestar la evaluación continua en lugar de tratar la prueba previa a la producción como un coste único del proyecto. La evidencia de validación pierde relevancia cuando cambian el modelo, los datos, el flujo de trabajo o la población afectada.

11. Definir la supervisión humana como un diseño de decisión

La supervisión humana debe especificar quién revisa qué, con qué información, bajo qué restricción de tiempo y con qué autoridad. Una instrucción genérica de mantener a una persona en el circuito puede fallar cuando el revisor carece de experiencia, tiene demasiados resultados, dispone de evidencia débil o tiene incentivos para aceptar la recomendación de la máquina.

El diseño puede distinguir entre aprobación, verificación, gestión de excepciones y apelación. Un revisor puede aprobar todos los resultados de alto impacto, muestrear resultados de bajo impacto, investigar incumplimientos de umbrales y ofrecer una vía de escalado para las partes afectadas. El revisor necesita acceso a la evidencia de origen y a las limitaciones conocidas, no solo a una respuesta pulida del modelo.

El sesgo de automatización debe tratarse como un riesgo operativo. La formación, el diseño de la interfaz y el muestreo de calidad pueden probar si los empleados cuestionan los resultados. Las anulaciones deben registrarse con un motivo para que la dirección pueda distinguir el juicio saludable de una práctica incoherente. Los patrones repetidos de anulación pueden revelar un problema de modelo, datos o flujo de trabajo.

La autoridad debe corresponder a las consecuencias. Un usuario puede corregir un borrador. Un responsable funcional puede suspender un flujo de trabajo. Un responsable de riesgos puede exigir un control. El consejo o el comité con competencias reservadas puede retirar un caso de uso material. La acción debe seguir siendo posible durante una interrupción o un incidente.

12. Desplegar mediante una producción controlada y gestión del cambio

El despliegue en producción debe utilizar entornos aprobados, controles de acceso, control de versiones, registro de eventos, segregación de funciones, reversión, planificación de capacidad, monitorización del servicio y registros de liberación. La decisión de despliegue debe confirmar que los responsables operativos, los equipos de soporte y los usuarios están preparados junto con la tecnología.

El paquete de liberación debe identificar las versiones del modelo y de los componentes, la configuración, las fuentes de datos, las pruebas, las limitaciones, las aprobaciones, los umbrales de monitorización, los contactos para incidentes y el mecanismo de respaldo. Esto crea una línea base reproducible. Un cambio material debe activar el subconjunto adecuado de repetición de pruebas y aprobación.

La clasificación de cambios puede distinguir entre cambios rutinarios, significativos y de emergencia. Una corrección de la redacción de un prompt puede seguir una vía estándar. Un nuevo permiso de herramienta, familia de modelos, fuente de datos, acción autónoma o grupo de clientes afectado puede requerir una nueva evaluación de riesgos. Los cambios de emergencia deben revisarse después del evento.

El despliegue también debe proteger el flujo de trabajo no AI. El respaldo manual, la continuidad del servicio y el acceso a los registros son importantes cuando un proveedor no está disponible o se suspende un modelo. La resiliencia debe probarse antes de que el sistema sea crítico.

13. Monitorizar el rendimiento, la deriva, los incidentes y la eficacia de los controles

La monitorización debe seguir la hipótesis del caso de uso. Las medidas técnicas pueden incluir precisión, tipo de error, calibración, deriva, latencia, disponibilidad, coste de tokens o de cómputo y eventos de seguridad. Las medidas operativas pueden incluir adopción, tiempo de finalización, retrabajo, anulaciones, reclamaciones, excepciones y defectos posteriores. Las medidas de beneficio deben seguir el resultado financiero o de servicio controlado.

Los umbrales deben ir acompañados de acciones. Un límite amarillo puede requerir investigación y una escala restringida. Un límite rojo puede requerir suspensión, reversión o contingencia manual. El responsable, el tiempo de respuesta y la ruta de escalado deben documentarse. Un panel sin lógica de acción es observación, no control.

La gestión de incidentes debe clasificar el daño, contener la exposición, preservar las evidencias, notificar a las partes internas y externas cuando sea necesario, corregir el sistema y confirmar la recuperación. Debe incluir incidentes de proveedores y cuasiincidentes. Las lecciones aprendidas deben actualizar las pruebas, los umbrales, la formación y los estándares de la cartera.

La monitorización debe tener en cuenta las versiones. El rendimiento antes de un cambio de modelo o de datos no debe mezclarse con el rendimiento posterior. El registro debe permitir el análisis por cohortes y explicar qué población, versión y flujo de trabajo generaron un resultado.

Los valores son supuestos de gestión hipotéticos utilizados para ilustrar una visión equilibrada de la monitorización.

14. Integrar la seguridad y la resiliencia en el diseño del producto

Los sistemas AI crean riesgos habituales de software y datos junto con rutas de ataque específicas de los modelos. Las amenazas pueden implicar inyección de prompts, envenenamiento de datos, acceso inseguro a herramientas, robo de modelos, divulgación de datos sensibles, entradas adversarias, salidas no seguras y compromiso de dependencias. Por lo tanto, la seguridad debe comenzar con la arquitectura y el uso previsto.

El modelo de amenazas debe identificar activos, actores, límites de confianza, interfaces y posibles usos indebidos. Los controles pueden incluir entornos aprobados, mínimo privilegio, tratamiento de entradas y salidas, gestión de secretos, restricciones de red, permisos de recuperación, listas de herramientas permitidas, controles de contenido, registro, detección de anomalías, red teaming y respuesta a incidentes. El conjunto correcto depende de las consecuencias y la exposición.

Los sistemas agénticos merecen especial atención porque pueden invocar herramientas y cambiar el estado externo. Los permisos, los límites de transacción, los pasos de confirmación, la separación de funciones y las acciones reversibles deben ser explícitos. La capacidad de un modelo para generar un plan correcto no le confiere autoridad para ejecutarlo.

Las orientaciones de seguridad desde el diseño de CISA, el NCSC del Reino Unido y socios internacionales hacen hincapié en la seguridad a lo largo del diseño, el desarrollo, el despliegue y la operación [17][18]. El modelo operativo debe traducir esto en evidencia para las puertas de decisión y un responsable de seguridad con rendición de cuentas.

15. Integrar la privacidad, la propiedad intelectual y los registros en el flujo de trabajo

El análisis de privacidad debe seguir el flujo real de datos y a las personas afectadas. La dirección debe comprender qué datos personales entran en los prompts, los sistemas de recuperación, los registros y las salidas; por dónde viajan; quién puede acceder a ellos; cuánto tiempo permanecen; y cómo se pueden ejercer los derechos. El cambio de finalidad y el uso de decisiones automatizadas pueden requerir un análisis adicional.

Los controles de propiedad intelectual deben abarcar las entradas, los datos de entrenamiento o ajuste fino, los resultados generados, las condiciones de los proveedores, los componentes de código abierto, el trabajo de los empleados y el material de clientes. La empresa debe definir cuándo el contenido generado puede publicarse, incorporarse a productos, servir de base para asesoramiento o compartirse externamente.

La política de registros debe preservar las decisiones y la evidencia, respetando al mismo tiempo los límites de conservación. Las aprobaciones relevantes, las pruebas, las versiones de modelos, los prompts o configuraciones, las excepciones, los incidentes y la validación de beneficios pueden requerir una conservación controlada. Los datos conversacionales rutinarios pueden tener un calendario diferente.

El Reglamento AI de la UE, las directrices relacionadas sobre transparencia, las directrices del Reino Unido sobre protección de datos, UAE y los marcos éticos de Arabia Saudí y los materiales de gobernanza de Singapur ilustran la creciente importancia de la trazabilidad, la transparencia y el uso responsable [9][11][15][20][21][22][25][26]. La aplicabilidad y el efecto jurídico dependen del sistema, el rol y la jurisdicción concretos.

16. Construir el caso de beneficios a partir de una línea de base controlada y un contrafactual

El seguimiento de beneficios comienza antes del despliegue. La carta debe registrar el proceso actual, el volumen, la mano de obra, el coste, el tiempo de ciclo, la calidad, la conversión, el servicio y el resultado de riesgo. También debe definir el contrafactual: qué espera la dirección sin la intervención. Una simple comparación antes y después puede atribuir erróneamente a AI el crecimiento del mercado, los precios, la dotación de personal o los cambios de proceso.

Cada beneficio debe tener una fórmula, una fuente de datos, una frecuencia, un responsable y un método de validación. El tiempo ahorrado se convierte en valor financiero solo cuando la empresa cambia la capacidad, el coste, el rendimiento o el servicio. Una reducción prevista del tiempo de tramitación puede ser útil desde el punto de vista operativo. No debe presentarse como EBITDA hasta que se evidencie el puente hacia la dotación de personal, la producción o el gasto evitado.

Los beneficios de ingresos requieren una disciplina similar. Un proceso de ventas asistido por AI puede influir en la calidad de los clientes potenciales, la conversión, el precio, la retención o la capacidad de los representantes. La empresa debe identificar el mecanismo, comparar cohortes cuando sea viable, controlar otros cambios y evitar contabilizar los mismos ingresos en varias iniciativas.

La visión de coste total debe incluir licencias, capacidad de cómputo, implementación, integración, preparación de datos, aseguramiento, seguridad, formación, soporte, gestión del cambio y monitorización continua. El coste de la plataforma compartida debe asignarse de forma coherente. El coste de salida y la sensibilidad al precio de los proveedores deben formar parte del caso.

La atribución puede utilizar varios diseños. Un despliegue aleatorizado puede aportar evidencia sólida cuando sea ético y operativamente práctico. La implementación por fases, las cohortes emparejadas, las series temporales interrumpidas o la descomposición a nivel de proceso pueden ser más adecuadas en otros casos. El método elegido debe indicarse antes de revisar los resultados, registrando las limitaciones y los cambios concurrentes. La dirección debe resistirse a seleccionar el método que produzca la cifra más favorable a posteriori.

Los beneficios pueden ser resultados financieros, de servicio, de riesgo o de capacidad. No deben forzarse a una estimación monetaria cuando la evidencia no la respalde. Una reducción controlada de la variabilidad de la respuesta o una mejora de la trazabilidad puede importar al consejo aunque finanzas no pueda validar un efecto inmediato en la cuenta de resultados. El registro puede mostrar el resultado operativo y su relevancia para la decisión, preservando al mismo tiempo el límite en torno al valor financiero.

Las directrices sobre beneficios del sector público ofrecen un principio general útil: los beneficios deben identificarse, definirse, monitorearse, materializarse y mantenerse a lo largo del ciclo de vida, con responsables sujetos a rendición de cuentas y aseguramiento [31][32]. La misma disciplina mejora la asignación de capital en la empresa privada.

Tabla 5. Registro controlado de beneficios de AI

Los valores previstos, observados y validados por Finanzas deben mantenerse separados.

17. Traducir la evidencia operativa en un puente de cuenta de resultados, caja y valor

Finanzas debe mantener un puente desde el beneficio operativo bruto hasta el resultado económico validado. Comenzar por el cambio observado en la producción o el rendimiento. Eliminar los efectos concurrentes de volumen, mix, precio, mercado y otros. Deducir el coste recurrente, la amortización de la implementación cuando proceda, el coste incremental de control y el desplazamiento. Identificar si el resultado llega a ingresos, margen bruto, gasto operativo, capital circulante, inversión en capital o riesgo.

El tratamiento contable debe mantenerse separado de la medición del beneficio para la dirección. La NIC 38 contiene criterios de reconocimiento para activos intangibles, y el IASB ha seguido examinando cuestiones relacionadas con datos y soluciones vinculados a AI [33]. La dirección debe obtener asesoramiento contable en lugar de asumir que una inversión o un beneficio descritos internamente determinan el tratamiento en los estados financieros.

El puente de beneficios debe utilizar vistas por período, acumuladas y de run-rate. Un caso de uso puede generar una carga de implementación puntual, un coste recurrente y un beneficio recurrente posterior. El calendario de caja puede diferir del gasto contable. El consejo de administración necesita las tres dimensiones para asignar capital.

La confianza en la previsión debe ser explícita. Un rango con impulsores definidos es más útil para la toma de decisiones que una única cifra precisa basada en supuestos débiles de adopción. Los análisis de sensibilidad pueden mostrar la adopción por parte de los usuarios, el volumen de tareas, el precio del proveedor, la tasa de error y el tiempo hasta escalar.

Los valores son supuestos hipotéticos de la dirección y no representan un resultado ni una previsión de un cliente.

18. Tratar la adopción y el rediseño de flujos de trabajo como parte de la inversión

El beneficio de AI depende de que cambie el trabajo. La adopción debe definirse como el uso correcto en el flujo de trabajo previsto, y no como la actividad de inicio de sesión o de licencia. La empresa debe saber quién utiliza el sistema, para qué tareas, con qué revisión y si el resultado cambia la decisión posterior.

El rediseño de flujos de trabajo puede eliminar traspasos, cambiar los límites de los roles y crear nuevos pasos de control. También puede poner de manifiesto trabajo oculto que antes absorbían los empleados. El mapeo de procesos debe identificar adónde se traslada el tiempo, qué colas desaparecen, qué excepciones aumentan y qué capacidades cobran más valor.

La formación debe ser específica por rol y caso de uso. Los usuarios necesitan propósito, límites, reglas de datos, expectativas de revisión, escalado, ejemplos y limitaciones conocidas. Los responsables deben saber interpretar el seguimiento y la evidencia de beneficios. Los equipos técnicos y de control necesitan responsabilidades durante todo el ciclo de vida. Los miembros del consejo necesitan la economía de la cartera y la exposición material.

El plan de plantilla debe abordar la capacidad en lugar de asumir una eliminación inmediata de costes. El tiempo liberado puede apoyar el crecimiento del volumen, el servicio, la calidad o evitar incrementos de plantilla. El efecto económico materializado depende de la actuación de la dirección. También pueden aplicarse la consulta a los empleados y los requisitos locales de empleo.

19. Asignar capital mediante hitos de decisión de la cartera

La cartera debe competir por capital, datos, ingeniería, capacidad de control y atención de la dirección, que son escasos. Un marco de puntuación común puede comparar relevancia estratégica, valor abordable, calidad de la evidencia, tiempo hasta el impacto, reutilización, riesgo, dependencia y carga de implementación. Las puntuaciones orientan el juicio y no deben automatizar la decisión de inversión.

La financiación puede escalonarse. El descubrimiento recibe un pequeño presupuesto de evidencia. La validación recibe recursos una vez que la línea base y la arquitectura son creíbles. La financiación de producción sigue a las pruebas exitosas y a la preparación de controles. La financiación para escalar sigue a la adopción y a la evidencia de beneficios tempranos. Esto reduce la escalada de costes hundidos.

La revisión de la cartera debe identificar decisiones de parada. Un caso de uso puede tener éxito técnico y no ser atractivo económicamente. Otro puede seguir siendo valioso pero requerir un proveedor o flujo de trabajo diferente. El capital debe reasignarse cuando cambie la evidencia.

Las plataformas compartidas necesitan una gobernanza separada. La identidad, el acceso a datos, la evaluación, la monitorización y las pasarelas de modelos pueden reducir el coste marginal en toda la cartera. Su valor puede medirse mediante casos de uso habilitados, duplicación evitada y calidad del control, junto con el coste del servicio y el riesgo de concentración.

La revisión de capital debe considerar el valor del aprendizaje. Un experimento acotado puede merecer financiación porque resuelve una incertidumbre material sobre los datos, la adopción, la respuesta del cliente o la viabilidad técnica. El registro de la decisión debe indicar la incertidumbre, la evidencia buscada, la exposición máxima y la fecha en la que la dirección escalará, rediseñará o detendrá. Esto trata la experimentación como una opción comprada con vencimiento definido, no como un piloto indefinido.

La cartera también debe reconocer los cuellos de botella. Diez casos de uso financiados pueden competir por un único propietario de datos, revisor de seguridad o equipo de flujo de trabajo, retrasándolos todos. La planificación de la capacidad debe secuenciar el trabajo en torno a la capacidad escasa que determina el rendimiento. El consejo puede entonces decidir si añade capacidad, reduce la cartera o cambia la arquitectura.

20. Aplicar capas adicionales por jurisdicción y sector sin fragmentar el núcleo

La empresa puede mantener un único modelo operativo central y adjuntar capas adicionales para la entidad jurídica, la geografía, el sector y el caso de uso. El núcleo contiene inventario, titularidad, clasificación por niveles, ciclo de vida, evidencia, monitorización y beneficios. Una capa adicional incorpora derechos aplicables, aprobaciones, registros, divulgaciones, pruebas o expectativas supervisoras.

La Ley AI de la UE utiliza un marco basado en riesgos con obligaciones que varían según el sistema y el actor; la ejecución y los plazos de aplicación han seguido evolucionando [9][10][11][12]. Las autoridades británicas utilizan principios transversales junto con los reguladores existentes, mientras que la PRA aplica expectativas de riesgo de modelo a determinadas empresas [14][16]. Las fuentes estadounidenses incluyen marcos voluntarios del NIST, normas sectoriales y medidas de aplicación contra declaraciones no respaldadas [3][5][19].

El UAE y Arabia Saudí publican directrices de ética y gobernanza que hacen hincapié en la rendición de cuentas, la transparencia, la privacidad, la seguridad y la adopción responsable [20][21][22][23]. El trabajo FREE-AI del RBI de la India aborda el AI responsable en finanzas [24]. Los marcos de gobernanza de Singapur y el programa AI Verify apoyan las pruebas prácticas y el despliegue responsable [25][26]. ASIC ha identificado brechas entre la adopción de AI y la gobernanza entre los licenciatarios revisados [27]. La OSFI de Canadá ha finalizado una amplia directriz de riesgo de modelo del ciclo de vida con consideraciones de AI y fecha de entrada en vigor en 2027 [29][30].

Estas fuentes difieren en estatus legal, alcance y calendario. El modelo operativo debe registrar la aplicabilidad y el asesoramiento para cada caso de uso. Una declaración de política global no debe sustituir un análisis legal local.

La arquitectura transfronteriza requiere una visión operativa de la ubicación de los datos, el acceso remoto, el procesamiento por proveedores, los equipos de soporte, la notificación de incidentes y el acceso regulatorio. Un contrato puede identificar una región de servicio mientras la telemetría, el soporte humano o los subprocesadores operan en otro lugar. El registro del flujo de datos debe reflejar el procesamiento real y debe actualizarse cuando cambie el servicio.

Las capas adicionales por sector pueden añadir controles sin crear un sistema empresarial separado. Un caso de uso financiero puede requerir evidencia de riesgo de modelo, conducta y resultados para el cliente. Un caso de uso de salud, empleo, seguridad o infraestructura crítica puede requerir un análisis profesional, de derechos y de resiliencia diferente. El inventario y la estructura de puertas de decisión comunes preservan la visibilidad de la cartera, mientras que la capa adicional preserva la rendición de cuentas específica del dominio.

21. Probar el marco mediante un caso hipotético de operación de servicio

Considere una empresa participada hipotética que procesa 240.000 solicitudes de atención al cliente cada año. La dirección propone un asistente que recupera conocimiento aprobado, redacta una respuesta y recomienda un código de enrutamiento. Los empleados siguen siendo responsables de la revisión y el envío. La empresa espera un tiempo de tramitación más corto y menos reprocesos.

El descubrimiento establece el flujo de trabajo actual: tiempo de tramitación mediano, revisión de calidad, contactos repetidos, tasa de reclamaciones, cola, composición de la plantilla y volumen estacional. La carta del proyecto identifica a operaciones de cliente como responsable de negocio, a tecnología como responsable del sistema, al equipo de conocimiento como responsable de datos y a finanzas como validador de beneficios. Los datos personales y confidenciales se mapean antes del diseño.

El caso de uso se clasifica en el nivel intermedio porque los resultados llegan a los clientes y pueden afectar al servicio o a los derechos, mientras que los empleados capacitados conservan la aprobación. La validación utiliza casos representativos, categorías difíciles, prompts adversariales y una prueba separada de permisos de recuperación. La empresa establece umbrales para el respaldo fáctico, la precisión del enrutamiento, el tratamiento de datos confidenciales, la calidad de la revisión y los resultados de reclamaciones.

El piloto inicial muestra una reducción hipotética del 24 por ciento en el tiempo de tramitación de las solicitudes elegibles. Solo el 58 por ciento de las solicitudes son elegibles, y la adopción alcanza el 70 por ciento del volumen elegible. Por lo tanto, la dirección evita aplicar el 24 por ciento a toda la base de costes. Finanzas modela la capacidad realizada a partir del volumen elegible real, la adopción, los reprocesos y el coste incremental de funcionamiento.

La aprobación del escalado depende de una actualización controlada del conocimiento, la formación de usuarios, la estabilidad de los umbrales y un plan de plantilla para la capacidad liberada. El consejo recibe por separado los beneficios previstos, observados y validados. No se atribuye ningún valor al modelo simplemente porque esté desplegado.

22. Dar al consejo un paquete de decisiones en lugar de un informe de actividad de AI

El paquete para el consejo debe mostrar la exposición de la cartera, las decisiones y la evidencia. Un cuadro de mando de una página puede incluir casos de uso por nivel y ciclo de vida, capital comprometido, valor previsto y validado, adopción, dependencias materiales, excepciones de control, incidentes, revisiones vencidas y decisiones requeridas. El detalle debe quedar detrás del cuadro de mando.

Cada caso de uso material debe mostrar el propietario, el resultado previsto, la etapa, el nivel de riesgo, la evidencia más reciente, la limitación no resuelta, la siguiente puerta de control y el estado de los beneficios. Los beneficios deben separarse en valores previstos, observados y validados por finanzas. Los costes deben incluir vistas de comprometidos, incurridos y de tasa de ejecución.

La narrativa importa cuando cambian las métricas. La dirección debe explicar por qué cambiaron la adopción, el rendimiento del modelo, los umbrales de control o el valor; qué decisión se adoptó a continuación; y quién es responsable de la acción. El paquete debe preservar la coherencia de versión y periodo.

El consejo también debe ver la concentración: flujos de trabajo críticos por proveedor, nube, fuente de datos y persona clave. Esto conecta la supervisión de AI con la resiliencia operativa, el riesgo cibernético, las compras y la sucesión.

El aseguramiento debe ser visible como un mapa de cobertura. Auditoría interna, riesgo, cumplimiento, seguridad, privacidad, finanzas y especialistas externos pueden probar cada uno una parte del sistema. El consejo debe ver qué afirmaciones materiales se han revisado, el periodo y el alcance, los hallazgos no resueltos y la respuesta de la dirección. Múltiples revisiones no generan un aseguramiento completo cuando examinan el mismo control limitado y dejan intactas la titularidad, la adopción o la atribución de beneficios.

La información para el consejo debe madurar con la cartera. Los paquetes iniciales pueden enfatizar la exhaustividad del inventario, el apetito y el diseño de puertas. Una cartera en escalado debe enfatizar el rendimiento en producción, los incidentes, la concentración y el valor validado. Una cartera madura también debe mostrar la retirada, la eficiencia del control y si la capacidad compartida está reduciendo el coste marginal. La arquitectura de la información debe cambiar cuando cambien las decisiones del consejo.

Tabla 6. Cuadro de mando del modelo operativo de AI para el consejo

Cada línea debe conducir a una decisión, una escalación o una acción operativa confirmada.

23. Implementar el modelo operativo en cien días

Los primeros treinta días establecen visibilidad y autoridad. Nombra al sponsor ejecutivo, aprueba el apetito provisional, identifica casos de uso y herramientas relevantes, define el inventario, asigna responsables y detiene cualquier actividad fuera de límites claros. Finanzas selecciona un pequeño número de líneas base de beneficios prioritarias.

Los días treinta y uno a sesenta construyen la columna vertebral de control. Define niveles de riesgo, hitos de control del ciclo de vida, evidencia mínima, clasificación de cambios, ruta de incidentes, requisitos de proveedores y registro de beneficios. Selecciona dos o tres casos de uso prioritarios que sean comercialmente relevantes y estén suficientemente acotados para probar el sistema.

Los días sesenta y uno a noventa ejecutan el primer ciclo controlado. Completa el diseño, el mapeo de datos, la validación, la revisión de seguridad, la formación de usuarios y la preparación para producción de los casos seleccionados. Registra aprobaciones condicionales y excepciones. Establece el monitoreo y un puente de beneficios bajo responsabilidad de Finanzas.

Los días noventa y uno a cien cierran el primer ciclo del consejo. Presenta el inventario, la exposición, la evidencia, los resultados operativos iniciales, la confianza en los beneficios, las decisiones y la asignación de capital del próximo trimestre. El modelo operativo se vuelve rutinario solo cuando gobernanza, ejecución y finanzas utilizan los mismos registros.

El calendario es ilustrativo y debe ampliarse cuando la consecuencia sistémica, la regulación o la preparación organizativa lo requieran.

Referencias

1. OCDE, Principios AI de la OCDE, actualizados en 2024, https://www.oecd.org/en/topics/ai-principles.html
2. OCDE, AI, Gobernanza y privacidad de datos: sinergias y áreas de cooperación internacional, 2024, https://www.oecd.org/content/dam/oecd/en/publications/reports/2024/06/ai-data-governance-and-privacy_2ac13a42/2476b1a4-en.pdf
3. Instituto Nacional de Estándares y Tecnología, Marco de gestión de riesgos de inteligencia artificial 1.0, 2023, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
4. Instituto Nacional de Estándares y Tecnología, Manual del RMF AI, actualizado en 2026, https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook
5. Instituto Nacional de Estándares y Tecnología, Marco de Gestión de Riesgos de Inteligencia Artificial: Perfil de Inteligencia Artificial Generativa, 2024, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
6. Instituto Nacional de Estándares y Tecnología, Centro de Recursos AI Confiable y Responsable, 2026, https://airc.nist.gov/
7. Organización Internacional de Normalización, ISO/IEC 42001:2023 Sistema de Gestión de Inteligencia Artificial, 2023, https://www.iso.org/standard/42001.html
8. Organización Internacional de Normalización, ISO/IEC 23894:2023 Gestión de Riesgos de Inteligencia Artificial, 2023, https://www.iso.org/standard/77304.html
9. Comisión Europea, Reglamento AI: marco regulatorio para la inteligencia artificial, actualizado en 2026, https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
10. Comisión Europea, marco de aplicación del Reglamento AI, 2026, https://digital-strategy.ec.europa.eu/en/policies/enforcement-ai-act
11. Comisión Europea, Directrices sobre obligaciones de transparencia para proveedores y responsables del despliegue de determinados sistemas AI, 2026, https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-transparency-obligations
12. Comisión Europea, Directrices sobre las obligaciones de los proveedores de AI de propósito general, 2025, https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers
13. EUR-Lex, Reglamento (UE) 2016/679, Reglamento General de Protección de Datos, 2016, https://eur-lex.europa.eu/eli/reg/2016/679/oj
14. Gobierno del Reino Unido, Aplicación de los principios regulatorios AI del Reino Unido: orientaciones para reguladores, 2024, https://assets.publishing.service.gov.uk/media/65c0b6bd63a23d0013c821a0/implementing_the_uk_ai_regulatory_principles_guidance_for_regulators.pdf
15. Oficina del Comisionado de Información, Orientaciones sobre AI y protección de datos, actualizadas en 2023, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
16. Banco de Inglaterra, Autoridad de Regulación Prudencial, Principios de gestión del riesgo de modelos para bancos SS1/23, actualizados en 2026, https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss
17. Agencia de Seguridad de Ciberseguridad e Infraestructura y Centro Nacional de Ciberseguridad del Reino Unido, Directrices para el desarrollo seguro de sistemas de AI, 2023, https://www.cisa.gov/news-events/alerts/2023/11/26/cisa-and-uk-ncsc-unveil-joint-guidelines-secure-ai-system-development
18. Agencia de Seguridad de Ciberseguridad e Infraestructura, Elección de tecnologías seguras y verificables, 2024, https://www.cisa.gov/resources-tools/resources/choosing-secure-and-verifiable-technologies
19. Comisión Federal de Comercio, Inteligencia artificial: aplicación de la ley y orientación para empresas, actualizado 2026, https://www.ftc.gov/industry/technology/artificial-intelligence
20. UAE Oficina del Ministro de Estado para Inteligencia Artificial, Economía Digital y Aplicaciones de Trabajo Remoto, UAE Posición sobre la política de AI, 2024, https://ai.gov.ae/wp-content/uploads/2024/10/UAE-Guiding-on-ai-policy-EN-V3.pdf
21. UAE Oficina de Inteligencia Artificial, Principios y directrices éticos de AI, 2022, https://ai.gov.ae/wp-content/uploads/2023/05/MOCAI-AI-Ethics-EN.pdf
22. Autoridad Saudí de Datos e Inteligencia Artificial, Principios éticos de AI, https://sdaia.gov.sa/en/SDAIA/about/Documents/ai-principles.pdf
23. Autoridad Saudí de Datos e Inteligencia Artificial, Reglamentos y políticas, actualizado 2026, https://sdaia.gov.sa/en/SDAIA/about/Pages/RegulationsAndPolicies.aspx
24. Banco de Reserva de la India, Informe del Comité FREE-AI: Marco para la habilitación responsable y ética de la inteligencia artificial, 2025, https://www.rbi.org.in/Scripts/PublicationReportDetails.aspx?UrlPage=&ID=1299
25. Comisión de Protección de Datos Personales de Singapur, Marco modelo de gobernanza de la inteligencia artificial, 2020, https://www.pdpc.gov.sg/help-and-resources/2020/01/model-ai-governance-framework
26. Autoridad de Desarrollo de Medios e Infocomunicaciones de Singapur, Marco modelo de gobernanza de AI para AI generativa, 2024, https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2024/model-ai-governance-framework-for-generative-ai
27. Comisión Australiana de Valores e Inversiones, REP 798 Cuidado con la brecha: disposiciones de gobernanza ante la innovación en AI, 2024, https://asic.gov.au/regulatory-resources/find-a-document/reports/rep-798-beware-the-gap-governance-arrangements-in-the-face-of-ai-innovation/
28. Autoridad Australiana de Regulación Prudencial, CPS 230 Gestión del riesgo operacional, actualizado 2026, https://www.apra.gov.au/standards/cps-230
29. Oficina del Superintendente de Instituciones Financieras de Canadá, Directriz E-23 Gestión del riesgo de modelo, 2025, https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/guideline-e-23-model-risk-management-2027
30. Oficina del Superintendente de Instituciones Financieras de Canadá y Agencia Financiera de Consumo de Canadá, Usos y riesgos de AI en instituciones financieras reguladas federalmente, 2024, https://www.osfi-bsif.gc.ca/en/about-osfi/reports-publications/osfi-fcac-risk-report-ai-uses-risks-federally-regulated-financial-institutions
31. Autoridad de Infraestructura y Proyectos del Reino Unido y Oficina del Gabinete, Guía para una gestión eficaz de beneficios en grandes proyectos, 2017, https://www.gov.uk/government/publications/guide-for-effective-benefits-management-in-major-projects
32. Gobierno del Reino Unido, El Marco de Eficiencia Gubernamental, 2025, https://www.gov.uk/government/publications/the-government-efficiency-framework/the-government-efficiency-framework--2
33. Fundación IFRS, Activos intangibles: otros posibles casos de prueba, incluidos los recursos de datos y los datos y soluciones relacionados con la inteligencia artificial, 2026, https://www.ifrs.org/content/dam/ifrs/meetings/2026/january/iasb/ap17d-other-potential-test-cases-data-ai.pdf

Fuentes y lecturas adicionales

1. OCDE, Principios AI de la OCDE, actualizados en 2024, Fuente oficial
2. OCDE, AI, Gobernanza y privacidad de datos: sinergias y áreas de cooperación internacional, 2024, Fuente oficial
3. Instituto Nacional de Estándares y Tecnología, Marco de gestión de riesgos de inteligencia artificial 1.0, 2023, Fuente oficial
4. Instituto Nacional de Estándares y Tecnología, Manual del RMF AI, actualizado en 2026, Fuente oficial
5. Instituto Nacional de Estándares y Tecnología, Marco de Gestión de Riesgos de Inteligencia Artificial: Perfil de Inteligencia Artificial Generativa, 2024, Fuente oficial
6. Instituto Nacional de Estándares y Tecnología, Centro de Recursos AI Confiable y Responsable, 2026, Fuente oficial
7. Organización Internacional de Normalización, ISO/IEC 42001:2023 Sistema de Gestión de Inteligencia Artificial, 2023, Fuente oficial
8. Organización Internacional de Normalización, ISO/IEC 23894:2023 Gestión de Riesgos de Inteligencia Artificial, 2023, Fuente oficial
9. Comisión Europea, Reglamento AI: marco regulatorio para la inteligencia artificial, actualizado en 2026, Fuente oficial
10. Comisión Europea, marco de aplicación del Reglamento AI, 2026, Fuente oficial
11. Comisión Europea, Directrices sobre obligaciones de transparencia para proveedores y responsables del despliegue de determinados sistemas AI, 2026, Fuente oficial
12. Comisión Europea, Directrices sobre las obligaciones de los proveedores de AI de propósito general, 2025, Fuente oficial
13. EUR-Lex, Reglamento (UE) 2016/679, Reglamento General de Protección de Datos, 2016, Fuente oficial
14. Gobierno del Reino Unido, Aplicación de los principios regulatorios AI del Reino Unido: orientaciones para reguladores, 2024, Fuente oficial
15. Oficina del Comisionado de Información, Orientaciones sobre AI y protección de datos, actualizadas en 2023, Fuente oficial
16. Banco de Inglaterra, Autoridad de Regulación Prudencial, Principios de gestión del riesgo de modelos para bancos SS1/23, actualizados en 2026, Fuente oficial
17. Agencia de Seguridad de Ciberseguridad e Infraestructura y Centro Nacional de Ciberseguridad del Reino Unido, Directrices para el desarrollo seguro de sistemas de AI, 2023, Fuente oficial
18. Agencia de Seguridad de Ciberseguridad e Infraestructura, Elección de tecnologías seguras y verificables, 2024, Fuente oficial
19. Comisión Federal de Comercio, Inteligencia artificial: aplicación de la ley y orientación para empresas, actualizado 2026, Fuente oficial
20. UAE Oficina del Ministro de Estado para Inteligencia Artificial, Economía Digital y Aplicaciones de Trabajo Remoto, UAE Posición sobre la política de AI, 2024, Fuente oficial
21. UAE Oficina de Inteligencia Artificial, Principios y directrices éticos de AI, 2022, Fuente oficial
22. Autoridad Saudí de Datos e Inteligencia Artificial, Principios éticos de AI, Fuente oficial
23. Autoridad Saudí de Datos e Inteligencia Artificial, Reglamentos y políticas, actualizado 2026, Fuente oficial
24. Banco de Reserva de la India, Informe del Comité FREE-AI: Marco para la habilitación responsable y ética de la inteligencia artificial, 2025, Fuente oficial
25. Comisión de Protección de Datos Personales de Singapur, Marco modelo de gobernanza de la inteligencia artificial, 2020, Fuente oficial
26. Autoridad de Desarrollo de Medios e Infocomunicaciones de Singapur, Marco modelo de gobernanza de AI para AI generativa, 2024, Fuente oficial
27. Comisión Australiana de Valores e Inversiones, REP 798 Cuidado con la brecha: disposiciones de gobernanza ante la innovación en AI, 2024, Fuente oficial
28. Autoridad Australiana de Regulación Prudencial, CPS 230 Gestión del riesgo operacional, actualizado 2026, Fuente oficial
29. Oficina del Superintendente de Instituciones Financieras de Canadá, Directriz E-23 Gestión del riesgo de modelo, 2025, Fuente oficial
30. Oficina del Superintendente de Instituciones Financieras de Canadá y Agencia Financiera de Consumo de Canadá, Usos y riesgos de AI en instituciones financieras reguladas federalmente, 2024, Fuente oficial
31. Autoridad de Infraestructura y Proyectos del Reino Unido y Oficina del Gabinete, Guía para una gestión eficaz de beneficios en grandes proyectos, 2017, Fuente oficial
32. Gobierno del Reino Unido, El Marco de Eficiencia Gubernamental, 2025, Fuente oficial
33. Fundación IFRS, Activos intangibles: otros posibles casos de prueba, incluidos los recursos de datos y los datos y soluciones relacionados con la inteligencia artificial, 2026, Fuente oficial