Una cadena de suministro de proveedores de IA de nivel bancario es aquella en la que cada artefacto que llega a producción se puede rastrear hasta la fuente revisada, reconstruirse en el mismo resumen y verificarse criptográficamente antes de ejecutarse. Concretamente, el proveedor puede demostrar compilaciones de imágenes propias reproducibles, firmas verificadas por un controlador de admisión en el momento de la implementación, procedencia legible por máquina y una lista de materiales de software para cada lanzamiento, y una ruta de lanzamiento donde los humanos no pueden empujar un artefacto no verificado alrededor de los controles. Según la Ley de Resiliencia Operacional Digital (DORA), [Reglamento (UE) 2022/2554] (https://eur-lex.europa.eu/eli/reg/2022/2554/oj), el banco tiene la obligación de evaluar exactamente esto antes de firmar, por lo que un proveedor serio llega con las pruebas preparadas. Este artículo describe cada práctica, la evidencia que un revisor debe solicitar ver, la disposición DORA que cada una ofrece y una lista de verificación de preguntas que un equipo de adquisiciones o de riesgo tecnológico puede plantear a cualquier proveedor de IA.
Las prácticas descritas aquí son las que KLA utiliza para su propia ruta de lanzamiento; las páginas Seguridad y Centro de confianza contienen los reclamos vigentes. Para conocer un panorama más amplio del control de los agentes bancarios, comience con la [guía de gobernanza de la IA en la banca] (/blog/ai-governance-banking-2026-guide).
Por qué la cadena de suministro de software es una cuestión de DORA
DORA se adoptó el 14 de diciembre de 2022 y se aplica a las entidades financieras de la UE desde el 17 de enero de 2025. Su Capítulo V, "Gestión del riesgo de terceros en TIC", regula cómo una entidad financiera contrata tecnología externa. Las definiciones hacen el trabajo inicial. El artículo 3, apartado 19, define a un tercero proveedor de servicios de TIC como "una empresa que presta servicios de TIC", una definición lo suficientemente amplia como para abarcar esencialmente a todos los proveedores de IA. El artículo 3, apartado 22, define una función crítica o importante como aquella cuya interrupción, o cuyo desempeño interrumpido, defectuoso o fallido perjudicaría materialmente el desempeño financiero de la entidad, la solidez o continuidad de sus servicios, o su cumplimiento continuo de las condiciones de su autorización. Un sistema de inteligencia artificial que evalúe las transacciones, clasifica las alertas ALD o controle la liberación de pagos con frecuencia respaldará dicha función una vez que el banco realice la autoevaluación documentada.
Esa clasificación eleva el listón para todo el compromiso. El artículo 28, apartado 4, exige que la entidad financiera, antes de celebrar el contrato, identifique y evalúe todos los riesgos relevantes y lleve a cabo toda la diligencia debida respecto del posible proveedor. El artículo 28(5) permite contratar únicamente con proveedores que cumplan con estándares apropiados de seguridad de la información y requiere, para funciones críticas o importantes, la debida consideración del uso por parte del proveedor de los estándares de seguridad de la información más actualizados y de mayor calidad. El artículo 30(3)(c) obliga entonces al propio contrato, cuando se respalden funciones críticas o importantes, a exigir que el proveedor cuente con medidas, herramientas y políticas de seguridad de TIC acordes con el marco regulatorio de la entidad.
Un proceso de creación de proveedores comprometido o no verificable es una ruta directa a los daños a los que se dirigen esas disposiciones. Si el proveedor no puede indicar qué artefacto exacto se ejecuta en producción, el banco no puede responder a sus propias tareas de gestión de cambios y parches conforme al Artículo 9(4)(e) y (f) para la función subcontratada, no puede abarcar un informe de incidente importante conforme al Artículo 19 a las versiones afectadas y no puede cumplir con los derechos de auditoría que el Artículo 30(3)(e) exige que el contrato otorgue. Por lo tanto, la evidencia de la cadena de suministro es material de evaluación para el expediente del Artículo 28 del banco, más que el marketing del proveedor.
| Disposición | lo que requiere | Lo que ofrece el proveedor |
|---|---|---|
| Artículo 28, apartado 4 | Identificación de riesgos previos al contrato y debida diligencia total sobre el posible proveedor | Un expediente revisable de la cadena de suministro: construcción, firma, verificación, procedencia, SBOM, controles de liberación |
| Artículo 28, apartado 5 | Contratar únicamente con proveedores que cumplan con los estándares apropiados de seguridad de la información; Los más altos estándares de calidad para funciones críticas o importantes. | Conformidad del marco nombrado (por ejemplo, objetivos de nivel SLSA) con los artefactos que lo respaldan |
| Artículo 28, apartado 3 | Un registro de información que cubre todos los acuerdos contractuales de TIC. | Identificadores estables de servicio, componente y versión que el banco puede incluir en su registro. |
| Artículo 30, apartado 3, letra c) | Medidas, herramientas y políticas contractuales de seguridad de las TIC para funciones críticas o importantes | Los controles de la cadena de suministro escritos como compromisos contractuales auditables. |
| Artículo 30, apartado 3, letra e) | Derechos de seguimiento, acceso, inspección y auditoría continuos | Comandos de verificación y acceso a evidencia que un auditor bancario puede ejercer sin la ayuda del proveedor. |
| Artículo 19 | Notificación de incidentes TIC mayores por parte de la entidad financiera | Identificación exacta de la versión afectada a partir de resúmenes, SBOM y procedencia dentro de los plazos del incidente. |
Construcciones reproducibles: la misma fuente produce el mismo resumen
Una compilación es reproducible cuando una reconstrucción independiente de la misma revisión fuente produce un artefacto de bits idénticos, lo que para imágenes de contenedor significa el mismo resumen de imagen. La reproducibilidad convierte "confiar en nuestro proceso" en una propiedad que cualquiera puede probar. Si una reconstrucción a partir del código fuente publicado produce el resumen en ejecución, entonces no se inyectó nada entre la revisión del código fuente y la producción, y no hay ningún indicador del compilador no revisado, deriva de dependencia o parche manual dentro del artefacto.
La ingeniería que hay detrás es específica y comprobable. Las marcas de tiempo de compilación se fijan a la revisión de origen en lugar del reloj de pared, por lo que dos compilaciones de la misma confirmación incorporan las mismas horas. El constructor en sí está fijado por resumen, por lo que la cadena de herramientas no puede moverse silenciosamente. Las marcas de tiempo de las capas se reescriben en el valor fijado. Las dependencias se resuelven a partir de un archivo de bloqueo y la compilación rechaza las entradas no fijadas. En el proceso de lanzamiento de KLA, una puerta de reproducibilidad realiza dos reconstrucciones limpias de cada imagen de servicio propio cubierta con cachés deshabilitadas y falla la liberación cuando los resúmenes difieren, y el resumen de lanzamiento debe ser igual al resumen reconstruido antes de la promoción.
Para un revisor de DORA, la reproducibilidad sustenta el derecho de auditoría del Artículo 28(6) con algo más fuerte que la evidencia de la entrevista: la auditoría puede volver a ejecutar la compilación. También le da contenido real a la descripción del servicio del Artículo 30(2)(a), porque "el software que proporcionamos" se resuelve en un resumen en lugar de una cadena de versión escrita por un humano.
- Evidencia a solicitar: el resultado de la verificación de reproducibilidad para una versión reciente que muestra el resumen de reconstrucción es igual al resumen de la versión.
- Evidencia a solicitar: la configuración de la canalización que demuestra marcas de tiempo de compilación fijadas, compiladores fijados en resumen y dependencias bloqueadas.
- Evidencia a solicitar: la declaración de alcance: qué imágenes están cubiertas por la puerta de reproducibilidad y cuál es el plan para el resto.
- Señal de alerta: un proveedor que no puede nombrar el resumen que se está ejecutando actualmente para su propio servicio.
Imágenes firmadas, verificadas donde cuenta: al ingresar
Una firma en una imagen de contenedor vincula el artefacto a una identidad. Cosign de Sigstore se ha convertido en la herramienta común: el canal firma el resumen de la imagen después de su compilación y la verificación verifica tanto la firma como la identidad del firmante. La firma sin clave fortalece la afirmación de identidad, porque el certificado se emite contra la identidad OIDC del sistema CI para un repositorio y flujo de trabajo específicos, por lo que la firma afirma "construido por esta tubería en esta rama" en lugar de "firmado por quien tenía un archivo de clave".
La firma por sí sola es decorativa a menos que algo se niegue a ejecutar artefactos sin firmar. El punto de aplicación que importa es la admisión de grupos. Un controlador de admisión de Kubernetes, Kyverno en la implementación de KLA, verifica la firma en cada imagen propia antes de que se admita el pod, resuelve etiquetas en resúmenes inmutables para que lo que se verificó sea lo que se ejecuta y falla en el cierre en producción: cuando la política no se puede evaluar, la carga de trabajo no comienza. La implementación se realiza por etapas, con observación en modo auditoría en desarrollo antes de la aplicación en los espacios de nombres de producción.
Este es el control que un equipo bancario debería investigar más a fondo, porque convierte toda la historia de la firma del proceso en física. También se corresponde claramente con el lenguaje DORA: el artículo 9(4)(e) exige controles documentados de gestión de cambios que garanticen que los cambios en los sistemas de TIC se registren, prueben, evalúen, aprueben, implementen y verifiquen de manera controlada, y la verificación del tiempo de admisión es el paso "verificado" que se hace mecánico. En el caso del contrato, se trata de una medida de seguridad concreta del artículo 30, apartado 3, letra c), cuya configuración puede leer un auditor.
Los caminos negativos merecen igual atención. Pregunte qué sucede cuando falla la verificación, cuando no se puede acceder al registro de transparencia de firmas y cuando alguien intenta implementar una imagen creada fuera del proceso autorizado. Una respuesta de nivel bancario muestra un evento de admisión bloqueado y una alerta, y el proveedor debería poder demostrar el bloqueo a pedido. Alertar sobre la política de verificación en sí, por lo que una política deshabilitada silenciosamente llama a alguien, cierra el círculo.
Procedencia y SBOM: qué es y de dónde viene
La procedencia es una certificación firmada que registra cómo se construyó un artefacto: la revisión de origen, el constructor, el flujo de trabajo y los parámetros de compilación. El marco SLSA estandariza el formato y define los niveles de integridad para la tubería que lo produce. Una lista de materiales de software (SBOM) enumera los componentes dentro del artefacto en un formato legible por máquina, como SPDX o CycloneDX. La procedencia responde "quién construyó esto a partir de qué"; el SBOM responde "lo que hay dentro". Un proveedor serio genera ambos en proceso en el momento de la construcción, los adjunta a la imagen y los firma, de modo que compartan las garantías de integridad del artefacto en lugar de vivir en una wiki.
Para el banco, la SBOM es lo que convierte una divulgación de vulnerabilidad en una pregunta acotada. Cuando el próximo CVE crítico llega a una biblioteca común, el banco puede preguntar al proveedor qué versiones implementadas contienen el componente afectado y esperar una respuesta derivada de los SBOM de los resúmenes en ejecución, en cuestión de horas. Esa capacidad alimenta las políticas de actualización y parches del Artículo 9(4)(f) del banco para la función subcontratada, y alimenta el informe de incidentes del Artículo 19, donde el informe debe abarcar qué servicios y versiones se vieron afectados. La procedencia sirve al derecho de monitoreo del Artículo 30(3)(e): un auditor que tenga la certificación puede confirmar de forma independiente que el artefacto en funcionamiento fue construido por el oleoducto sancionado a partir de la revisión indicada.
Dos preguntas de seguimiento separan a los proveedores experimentados de los aspiracionales. Primero, la cobertura: ¿se producen certificaciones para cada artefacto de lanzamiento o solo para la imagen principal? En segundo lugar, la verificación: ¿hay algo que consuma las certificaciones o se producen y nunca se verifican? Producir una procedencia que nada verifica todavía tiene valor para el análisis forense de incidentes, y un proveedor que establece ese límite honestamente es más creíble que uno que implica verificaciones que no existen.
Una vía de liberación controlada: sin puertas laterales
La pregunta que queda es si se pueden eludir los controles anteriores. Una ruta de lanzamiento controlada significa que la ruta desde el origen fusionado hasta el tráfico de producción está cerrada: cada imagen en tiempo de ejecución está referenciada por un resumen inmutable en lugar de una etiqueta mutable, el estado de implementación se declara en una configuración controlada por versión (GitOps) para que los cambios del clúster se rastreen hasta las confirmaciones revisadas, y las propias dependencias de la canalización de CI, incluidas las acciones de CI de terceros, se fijan a revisiones exactas para que el sistema de compilación no pueda modificarse antes de la firma.
La fijación del resumen merece su propia revisión porque es donde las buenas tuberías tienen fugas silenciosas. Una etiqueta como v1.4 se puede redireccionar al registro después de su revisión; un resumen no puede. La canalización de KLA valida que el tiempo de ejecución muestre imágenes de referencia mediante resumen y mantenga la lista de excepciones vacía; Las imágenes de terceros que deben ejecutarse en el clúster se reflejan, escanean y firman con la misma identidad que las imágenes propias, por lo que la política de admisión se aplica a todo.
Aquí también se pone a prueba el factor humano. Pregunte quién puede pasar directamente a producción, bajo qué procedimiento de rotura de cristales y qué registro deja un despliegue de rotura de cristales. El artículo 30(3)(b) exige que el contrato incluya obligaciones de notificación e información sobre acontecimientos que afecten materialmente la capacidad de entrega del proveedor; una liberación de emergencia fuera de la ruta estándar es exactamente un desarrollo de este tipo, y un proveedor de nivel bancario puede mostrar el procedimiento, el rastro de aprobación que produce y cómo el artefacto aún se firma y verifica incluso en el caso de emergencia.
| Práctica | Evidencia que un revisor puede verificar | Relevancia de DORA |
|---|---|---|
| Construcciones propias reproducibles | Reconstruir la transcripción que muestra la igualdad del resumen de una versión reciente; Configuración de canalización de marca de tiempo fijada y constructor fijado | Justifica las normas de seguridad del artículo 28, apartado 5; hace que las auditorías del artículo 28, apartado 6, sean repetibles |
| Firma de imágenes sin llave vinculada a la identidad de CI | Salida del comando de verificación que muestra la identidad del firmante vinculada al flujo de trabajo de lanzamiento | Artículo 30, apartado 3, letra e), seguimiento independiente; prueba de identidad para el registro del artículo 28, apartado 3 |
| Verificación de firma de tiempo de admisión, falla cerrada en producción | La política de admisión, un despliegue bloqueado demostrado y la alerta que generó | Artículo 9(4)(e) control de cambios verificado como medida contractual Artículo 30(3)(c) |
| Declaraciones de procedencia firmadas (SLSA) | Atestación para un resumen de producción, revisión de fuente de nombres, generador y flujo de trabajo | Artículo 30, apartado 3, letra e), derechos de auditoría; análisis forense de incidentes en virtud del artículo 19 |
| SBOM por artefacto de lanzamiento | Documento SPDX o CycloneDX para el resumen en ejecución; una respuesta cronometrada a "qué versiones contienen el componente X" | Alimenta las políticas de parches del Artículo 9(4)(f) del banco y el alcance de incidentes del Artículo 19 |
| Fijación de resumen e implementación declarada por GitOps | Salida de validación del manifiesto; una lista de excepciones vacía; cambiar el estado del clúster de seguimiento del historial a las confirmaciones revisadas | Artículo 30, apartado 2, letra a), descripción precisa del servicio; Artículo 28, apartado 4, aportaciones a la evaluación de riesgos |
| Dependencias de CI ancladas | Archivos de flujo de trabajo que vinculan acciones y constructores de terceros a revisiones exactas | Reduce la exposición a la cadena de subcontratistas El artículo 29(2) exige que el banco sopese |
La lista de verificación del comprador: preguntas y cómo es una buena respuesta
La siguiente tabla es el activo de elevación y uso. Presente las preguntas a cualquier proveedor de IA, registre las respuestas en el archivo de evaluación del Artículo 28(4) y trate la columna de "buenas respuestas" como el ancla de puntuación. Toda buena respuesta comparte una propiedad: apunta a un artefacto o una demostración en lugar de un PDF de política.
| Pregunta | Que buena respuesta parece |
|---|---|
| ¿Puedes reconstruir una imagen de producción desde la fuente y obtener el mismo resumen? | Sí, con una transcripción de reconstrucción reciente. El proveedor nombra qué imágenes están cubiertas y establece el plan para el resto. |
| ¿Qué resumen se está ejecutando para su servicio en este momento y cómo lo sabe? | Un resumen leído del estado de implementación, coincidente con un registro de versión, en minutos. La vacilación aquí socava cualquier otra respuesta. |
| ¿Cómo se firman las imágenes y qué identidad afirma la firma? | Firma a nivel de resumen con el certificado vinculado a la identidad del flujo de trabajo de CI y el comando de verificación exacto que un tercero puede ejecutar. |
| ¿Qué se niega a publicar una imagen sin firmar o mal firmada? | Un controlador de admisión que verifica las firmas antes de que se inicien los pods, aplica y cierra en producción, con una implementación bloqueada demostrada. |
| ¿Qué sucede cuando la infraestructura de verificación de firmas no funciona? | Una postura declarada de cierre de fallas para la admisión de producción, el respaldo operativo y la alerta que se activa. La compensación se comprende y se posee. |
| ¿Producen certificados de procedencia? ¿Puedo verificar uno? | Procedencia de SLSA firmada por revisión de fuente de nomenclatura de versión, generador y flujo de trabajo, con el comando de verificación incluido. |
| ¿Puedes darme un SBOM para la versión exacta que ejecutaríamos? | Un SBOM legible por máquina generado en el momento de la compilación para ese resumen, además de una respuesta comprometida para las preguntas sobre exposición de componentes. |
| ¿Se hace referencia a sus imágenes en tiempo de ejecución mediante etiquetas o resúmenes? | Resumen en todas partes, aplicado mediante una verificación de canalización, con la lista de excepciones vacía o corta y justificada. |
| ¿Cómo reciben el mismo tratamiento las imágenes de terceros y las dependencias de CI? | Imágenes de terceros reflejadas, escaneadas y firmadas bajo la propia identidad del proveedor; Acciones de CI y constructores fijados a revisiones exactas. |
| ¿Quién puede implementar en producción fuera de la ruta estándar y qué rastro deja? | Un procedimiento de ruptura de cristales con aprobaciones registradas, artefactos aún firmados y verificados, y el evento reportable al banco. |
| Cuando aterriza un CVE crítico, ¿qué tan rápido puede decirme si estamos expuestos? | Un cronograma comprometido, respondido a partir de SBOM de resúmenes en ejecución, consistente con las obligaciones de notificación del contrato. |
| ¿Pondrán estos controles en el contrato? | Sí: las prácticas mencionadas anteriormente están escritas como compromisos del Artículo 30(3) con derechos de auditoría, en lugar de ser referenciadas como un documento de política mutable. |
Leyendo las respuestas: puntuación y seguimiento del contrato
La puntuación es sencilla. Una respuesta respaldada por un artefacto que el banco puede verificar obtiene la máxima puntuación. Una respuesta que describe un control real sin evidencia independiente se califica como parcial y genera una solicitud de evidencia. Una respuesta que redirige a una certificación obtiene una puntuación de cero en esta lista de verificación: un informe SOC 2 da fe del período de auditoría y los controles en alcance, y rara vez demuestra la reproducibilidad, el cumplimiento de la admisión o la procedencia del artefacto específico que ejecutará el banco. Las certificaciones complementan la evidencia a nivel de artefacto; no lo sustituyen.
Las declaraciones honestas de límites deberían puntuar, y esto es válido en ambos sentidos. KLA publica sus propios límites en el [Centro de Confianza] (/trust), incluidos qué controles se aplican hoy y cuáles se realizan por etapas, porque un proveedor que afirma que un oleoducto es perfecto está describiendo un oleoducto que nadie ha inspeccionado. Espere brechas de cobertura; Juzgue si el proveedor sabe dónde están, los monitorea y secuencia el cierre.
Luego mueva los resultados al contrato. El artículo 30(1) exige el contrato completo en un solo documento escrito; El artículo 30(2)(b) exige que los lugares de procesamiento y almacenamiento sean notificados con antelación de los cambios; El artículo 30(3)(e) exige derechos de acceso, inspección y auditoría irrestrictos para funciones críticas o importantes. Las prácticas de la cadena de suministro verificadas durante la diligencia debida se convierten en el contenido concreto de la cláusula de medidas de seguridad del Artículo 30(3)(c), y los comandos de verificación se convierten en el mecanismo a través del cual el banco ejerce sus derechos de monitoreo sin programar una llamada al proveedor. El artículo 28(8) exige estrategias de salida; Las construcciones reproducibles y los SBOM completos reducen materialmente el riesgo de salida, porque el banco sabe exactamente qué estaba ejecutando cuando sale.
Para los equipos que evalúan KLA específicamente: las reclamaciones permanentes de la cadena de suministro se encuentran en la [página de seguridad] (/security), las respuestas previas a la revisión y las divulgaciones del subprocesador en el [Centro de confianza] (/trust) y el contexto bancario en [Soluciones para servicios financieros] (/solutions/financial-services).
Preguntas frecuentes
¿Es un proveedor de IA un proveedor externo de servicios de TIC según DORA?
El artículo 3, apartado 19, del Reglamento (UE) 2022/2554 define a un tercero proveedor de servicios de TIC como una empresa que presta servicios de TIC, y el artículo 3, apartado 21, define los servicios de TIC en sentido amplio como servicios digitales y de datos prestados a través de sistemas de TIC de forma continua. Un proveedor de IA que ofrece un servicio de software alojado o implementado entra dentro de esa definición, y las obligaciones contractuales, de registro y de diligencia debida del banco en los artículos 28 a 30 se aplican al acuerdo.
¿DORA exige que los proveedores tengan construcciones reproducibles o imágenes firmadas?
Ninguna disposición menciona esas técnicas. DORA exige que la entidad financiera realice la diligencia debida y una evaluación de riesgos antes de contratar (Artículo 28(4)), que contrate únicamente con proveedores que cumplan con estándares apropiados de seguridad de la información (Artículo 28(5)), y que obligue a los proveedores que apoyan funciones críticas o importantes a medidas, herramientas y políticas contractuales de seguridad de TIC (Artículo 30(3)(c)). Las compilaciones reproducibles, las imágenes firmadas verificadas en el momento de la admisión, la procedencia y los SBOM son las pruebas más sólidas que un proveedor puede ofrecer actualmente contra esas pruebas.
¿Qué evidencia de la cadena de suministro debería solicitar un banco a un proveedor de IA?
Una transcripción de reconstrucción que demuestra una reproducción idéntica al resumen para una versión reciente, el comando de verificación de firma con la identidad del firmante vinculado a CI, la política de admisión que bloquea imágenes no verificadas junto con un bloque demostrado, una atestación de procedencia firmada para un resumen de producción, un SBOM legible por máquina para la versión exacta que se ejecutará, la validación de fijación de resumen para manifiestos en tiempo de ejecución y el procedimiento de ruptura con el rastro que deja.
¿Por qué es más importante la verificación del tiempo de admisión que la firma misma?
Una firma que nada verifica no cambia el resultado. La verificación en el momento de la admisión realiza la verificación en el momento en que comienza una carga de trabajo, por lo que un artefacto sin firmar o firmado incorrectamente no puede ejecutarse en producción, independientemente de quién lo impulsó o por qué. También le brinda al banco un único punto de control auditable: la configuración de la póliza, los eventos de admisión bloqueada y las alertas sobre la póliza misma.
¿Cómo se conecta la evidencia de la cadena de suministro con la notificación de incidentes de DORA?
El artículo 19 exige que las entidades financieras informen de los incidentes importantes relacionados con las TIC a su autoridad competente. El alcance de un informe de este tipo para un servicio de IA subcontratado depende de saber exactamente qué versiones de artefactos se vieron afectadas. Las implementaciones fijadas en el resumen, los SBOM y la procedencia permiten al proveedor responder eso en horas, que es lo que el banco necesita para cumplir con sus propios plazos de presentación de informes y cumplir con las obligaciones de notificación escritas en el contrato según el Artículo 30(3)(b).
Conclusiones clave
Se demuestra una cadena de suministro de proveedores de IA de nivel bancario con artefactos: una reconstrucción que reproduce el resumen de producción, una firma vinculada a la identidad del canal, un controlador de admisión que bloquea todo lo demás, procedencia y un SBOM para cada versión, y un camino cerrado desde la fuente revisada hasta la carga de trabajo en ejecución. DORA le da al banco comprador tanto el mandato como el vocabulario para exigir esta evidencia antes de firmar, y brinda a los proveedores serios una manera de ser visiblemente diferentes de los proveedores con una póliza PDF. Utilice la lista de verificación anterior en la siguiente evaluación, lea las afirmaciones permanentes de KLA en la Página de seguridad y el Centro de confianza, y coloque la conversación con los proveedores en el panorama de control más amplio con la Guía de gobernanza de IA en banca y Soluciones para servicios financieros.