Riesgos de la inteligencia artificial: guía del NIST AI RMF

Ante la pregunta «¿Siguen el NIST AI RMF?», muestra cómo gestionas los riesgos de la inteligencia artificial en un sistema concreto: quién responde por ellos, qué pruebas hiciste, qué acciones permites y qué ocurre si algo falla. El marco tiene 4 funciones y su adopción es voluntaria; los primeros 30 días deberían servir para poner en marcha un proceso de gestión de riesgos y describir con precisión lo que falta. El marco de NIST aporta la estructura.

El AI Risk Management Framework (AI RMF) del National Institute of Standards and Technology (NIST) ayuda a las organizaciones a abordar los riesgos para las personas, las organizaciones y la sociedad al diseñar, desarrollar, desplegar o utilizar IA. Su alcance va más allá del modelo: también importan las personas, los datos, los permisos y el entorno del sistema. AI RMF 1.0 describe ese alcance más amplio.

Para una empresa de 20 a 200 personas que lleva modelos de lenguaje de gran tamaño, o LLM, a producción, conviene empezar con una implementación de alcance definido. Elige una funcionalidad cuyo impacto sea importante, vincula sus riesgos con decisiones y registros, y amplía el alcance después. Comprar un modelo a otra empresa no explica a tus clientes cómo controlas la funcionalidad que construiste con él.

Fuentes verificadas: 26 de octubre de 2026. El marco, el Playbook y el perfil de IA generativa se contrastaron con las páginas y publicaciones vigentes de NIST. La página del marco indica que AI RMF 1.0 está en revisión y sigue enlazando esa versión. Ese aviso no equivale a una nueva versión publicada ni anuncia cuándo se publicará.

Cómo ayuda NIST AI RMF a gestionar los riesgos de la inteligencia artificial

El marco propone conectar responsabilidades, contexto, evidencias y acciones durante toda la vida del sistema. Piensa en el plan de seguridad contra incendios de un edificio: conocer las salidas sirve de poco si nadie se ocupa de mantenerlas despejadas, comprobar su estado y responder cuando algo falla.

NIST AI 100-1: el documento de referencia

NIST AI 100-1 es el identificador de la publicación AI RMF 1.0, publicada el 26 de enero de 2023. La primera parte explica los riesgos y los atributos que hacen confiable a un sistema; la segunda presenta el núcleo del marco, llamado Core, y los perfiles. El Core organiza la gestión de riesgos en Govern, Map, Measure y Manage, cada una con categorías y subcategorías. Estas describen resultados y acciones, sin constituir una lista universal de auditoría que se aprueba o se suspende. Marco de NIST e información sobre su publicación; AI RMF 1.0, partes 1 y 2.

Los atributos de confiabilidad abarcan la validez y fiabilidad del sistema; su seguridad frente a daños; su protección frente a amenazas y su resiliencia; la rendición de cuentas y la transparencia; la explicabilidad y la interpretabilidad; la protección reforzada de la privacidad; y la equidad con gestión de los sesgos perjudiciales. Una respuesta fluida, por sí sola, no demuestra ninguno de ellos. NIST analiza estos atributos y las tensiones entre ellos en AI RMF 1.0, sección 3.

Por ejemplo, un asistente de soporte podría responder correctamente sobre un producto y, al mismo tiempo, revelar registros de otro cliente. Una evaluación útil debe examinar tanto la respuesta como los límites de acceso. Medir solo la calidad de las respuestas dejaría fuera el fallo de mayor impacto.

NIST AI RMF Playbook: elige las acciones que necesitas

El NIST AI RMF Playbook incorpora acciones sugeridas, referencias y orientaciones para alcanzar los resultados del Core. NIST permite expresamente que cada organización utilice las sugerencias que se ajusten a sus necesidades; no espera que todas lo implementen todo. El Playbook tampoco es una lista de tareas que deba seguirse en orden. Playbook de NIST; preguntas frecuentes sobre el Playbook de NIST.

Úsalo cuando un riesgo requiera una respuesta práctica. Si el asistente de soporte puede revelar registros privados, busca acciones relacionadas con datos, acceso, medición y gestión de incidentes. Deja constancia de lo que elegiste, por qué encaja y cómo sabes que funciona. Copiar todas las sugerencias en una hoja de cálculo genera trabajo, pero no resuelve si la funcionalidad está lista para lanzarse.

Las cuatro funciones y los registros que necesita un equipo pequeño

Mantén conectadas las funciones. Govern se aplica de forma transversal a Map, Measure y Manage, y el trabajo es iterativo durante todo el ciclo de vida de la IA. Una prueba puede revelar un riesgo que obligue a revisar el contexto; un incidente puede exigir un cambio de política. NIST no prescribe una secuencia de sentido único. Core de NIST AI RMF.

La siguiente correspondencia entre funciones y documentos es nuestra propuesta de implementación para equipos pequeños. NIST define los resultados; estos formatos de registro y la asignación de responsables son opciones prácticas para aportar evidencias de ellos. Un mismo documento puede servir a varias funciones.

Los identificadores y las descripciones de resultados anteriores proceden de las tablas de funciones del Core de NIST. Son referencias seleccionadas; la tabla no pretende abarcar todas las subcategorías.

Govern: asigna la autoridad para detener el sistema

Govern establece las políticas, las responsabilidades y la cultura necesarias para gestionar el riesgo. NIST incluye en esta función la documentación de roles, la responsabilidad de la dirección, la formación del personal y la supervisión humana. Core de NIST, Govern.

En una empresa de software hipotética de 40 personas, quien la fundó podría hacerse cargo de la política de riesgos; la persona responsable de soporte, del asistente; y un integrante de ingeniería, de los controles de acceso. No basta con que sus nombres figuren en un documento: necesitan autoridad. Especifica quién puede suspender la funcionalidad y quién puede aceptar el riesgo que queda tras aplicar las salvaguardas, denominado riesgo residual.

Una regla de supervisión humana aplicable en la práctica podría decir: «El asistente puede redactar borradores de respuesta con material de soporte aprobado. Una persona del equipo de soporte debe comprobar la fuente y el destinatario antes del envío. El asistente no tiene permiso para emitir reembolsos ni modificar el acceso a las cuentas. La persona responsable de soporte puede desactivarlo; para reactivarlo se requiere la aprobación de quien responde por ingeniería y de quien responde por soporte».

La regla ilustra una decisión de diseño. Otro flujo de trabajo puede justificar permisos distintos. Lo esencial es que los accesos efectivos y la forma de revisar coincidan con lo establecido.

Map: describe la funcionalidad completa

Map establece el contexto necesario para comprender los riesgos y los impactos, incluidos los componentes del sistema y los terceros involucrados. También ayuda a decidir si una solución de IA es adecuada desde el principio. Core de NIST, Map.

Crea una entrada propia para el asistente de soporte en el inventario. Registra su propósito, responsable, público, categorías de datos, fuentes de recuperación de información, sistemas conectados, identificador del modelo o servicio, acciones permitidas y estado de aprobación. Incluye a las personas afectadas por sus errores, también a los clientes que nunca interactúan directamente con él.

Después, describe cada riesgo mediante una causa, un evento y una consecuencia: «Un filtro de cuentas incorrecto recupera la solicitud de soporte de otro cliente; el asistente la incluye en un borrador; un revisor envía información confidencial al cliente equivocado». Escribir únicamente «riesgo de privacidad» no le dice a quien desarrolla el sistema qué debe corregir.

Anota las salvaguardas propuestas junto al escenario, con responsable, estado y enlace a las evidencias. Un cambio de propósito o un permiso nuevo merece otra evaluación, aunque el modelo subyacente siga siendo el mismo.

Measure: pon a prueba el riesgo que identificaste

Measure emplea métodos cuantitativos, cualitativos o mixtos para evaluar los riesgos y la confiabilidad. NIST incluye pruebas en condiciones similares a las del despliegue, documentación de limitaciones y evaluación de aspectos como la seguridad, la privacidad y los sesgos perjudiciales. Core de NIST, Measure.

Para el asistente de soporte, conserva casos de prueba que cubran una consulta habitual, la falta de fuentes, políticas contradictorias, registros de otro cliente y una instrucción maliciosa insertada en el texto recuperado. La inyección de instrucciones, o prompt injection, consiste en que un atacante introduce instrucciones para desviar el comportamiento del sistema; el perfil de IA generativa de NIST, sección 2.9, aborda tanto los ataques directos como los que llegan a través del material que recupera el sistema.

Cada registro de evaluación debe identificar la configuración probada, las entradas del caso, el comportamiento esperado, la respuesta o acción real, el revisor y el resultado. Vincula cada caso fallido con el riesgo que revela. Conserva las evidencias sensibles con los controles de acceso adecuados, en lugar de copiar datos de clientes en un informe de uso general.

Define los criterios de aceptación antes de revisar los resultados. En este ejemplo, revelar información de un cliente a otro impide el lanzamiento, aunque las demás respuestas parezcan correctas. Es una regla de lanzamiento propuesta, no un umbral de NIST. Un conjunto pequeño de pruebas puede detectar un fallo; superarlo no demuestra que no puedan producirse fallos.

Manage: convierte los hallazgos en decisiones

Manage prioriza los riesgos y asigna recursos para abordarlos. NIST incluye decisiones sobre si continuar el desarrollo o el despliegue, opciones como mitigar o aceptar el riesgo, mecanismos para desactivar sistemas y actividades continuas de seguimiento y respuesta a incidentes. Core de NIST, Manage.

Si falla la prueba de separación entre cuentas, desactiva la vía de recuperación afectada, corrige el control de autorización y repite las pruebas antes de restablecer el acceso. Si el fallo tiene menos consecuencias, documenta por qué es aceptable un lanzamiento limitado con seguimiento y quién tomó esa decisión. Un riesgo marcado como «aceptado», sin justificación ni una persona responsable que lo apruebe, aporta poca evidencia.

Mantén un registro de incidentes con la hora de detección, el sistema y la configuración afectados, el impacto conocido, las medidas de contención, la ubicación de las evidencias, las comunicaciones, la acción correctiva y la aprobación para reactivar el sistema. Registra también los incidentes que estuvieron a punto de ocurrir. Si no ha ocurrido nada, un registro vacío es honesto; acompáñalo de un simulacro claramente identificado que demuestre que alguien puede ejecutar la respuesta.

NIST AI 600-1: qué aporta el perfil de IA generativa

NIST AI 600-1, el Generative Artificial Intelligence Profile, aplica el marco a riesgos exclusivos de la IA generativa o que esta intensifica. Publicado el 26 de julio de 2024, complementa AI RMF 1.0; no lo sustituye ni constituye una certificación independiente. Página de la publicación de NIST.

El perfil identifica 12 áreas de riesgo y propone acciones vinculadas al marco. Su elaboración se centró en la gobernanza, la procedencia del contenido, las pruebas previas al despliegue y la divulgación de incidentes. La procedencia del contenido se refiere a su origen y su historial. Estas consideraciones ayudan a conectar los resultados generados con prácticas operativas sujetas a rendición de cuentas. NIST AI 600-1, introducción, sección 2 y apéndice A.

Para el asistente de soporte, empieza por convertir los riesgos pertinentes en casos de fallo concretos:

• Confabulación: Una respuesta falsa pero expresada con seguridad inventa el derecho a un reembolso. Conserva la respuesta que correspondería según la política y comprueba si el material citado por el sistema la respalda.
• Privacidad de los datos y seguridad de la información: Se filtran datos de clientes o un contenido malicioso recuperado desvía al asistente. Pon a prueba tanto los límites de acceso a los datos como el comportamiento ante entradas hostiles.
• Configuración de la interacción entre personas e IA: Un revisor confía demasiado en un borrador bien redactado. Facilítale la fuente original, los criterios de rechazo y la autoridad para detener la acción.
• Sesgos perjudiciales u homogeneización: La calidad del servicio varía entre grupos de usuarios o idiomas relevantes. Examina los contextos en los que realmente prestas servicio y documenta los límites de las evidencias.
• Cadena de valor e integración de componentes: Cambia un modelo, una fuente de datos o una integración sin que comprendas su efecto. Conserva registros de dependencias y cambios, y vuelve a evaluar los riesgos afectados.

Son ejemplos de implementación basados en las descripciones de riesgo del perfil, no una lista oficial abreviada. Las otras áreas que este identifica son información o capacidades CBRN —químicas, biológicas, radiológicas o nucleares—; contenido peligroso, violento o de odio; impactos ambientales; integridad de la información; propiedad intelectual; y contenido obsceno, degradante y/o abusivo. Valora su pertinencia para tu sistema y documenta el razonamiento. Las definiciones completas están en NIST AI 600-1, sección 2.

Una forma útil de trabajar con el perfil consiste en registrar el riesgo aplicable, la acción elegida, el responsable y las evidencias, y después explicar las exclusiones relevantes. Si un agente puede actuar a través de software conectado, evalúa el recorrido de esas acciones además del texto que genera. Un borrador correcto no demuestra que un cambio en una cuenta estuviera autorizado.

Los primeros 30 días: un plan de trabajo propuesto

El objetivo es contar con un proceso demostrable dentro de un alcance definido. Este calendario es nuestra recomendación, no un plazo de NIST, un nivel de madurez ni una garantía de haber terminado. Mantén activa la gobernanza durante todo el proceso; el calendario organiza el primer mes, sin imponer una secuencia en nombre del marco.

1. 1

   Días 1-5: define el alcance y los responsables

   Designa a un directivo que rinda cuentas y a una persona responsable del sistema. Haz un inventario de los usos actuales de IA, incluidas las funcionalidades integradas en el software que ya compras. Para la primera evaluación detallada, elige una funcionalidad en producción con riesgos significativos para los clientes, los datos o las acciones que puede ejecutar.

   Describe su propósito y sus límites, identifica a las personas afectadas y reúne los procedimientos existentes de lanzamiento, acceso y gestión de incidentes. Registra las lagunas en la identificación de usos, en lugar de declarar completo el inventario sin evidencias.

   Conserva: El inventario inicial, las responsabilidades asignadas y una regla de supervisión humana contrastada con los permisos reales de la funcionalidad.

2. 2

   Días 6-10: identifica los fallos y elige las respuestas

   Revisa la funcionalidad elegida junto con quien la desarrolló y quien opera el flujo de trabajo. Incluye a alguien capaz de cuestionar los supuestos sobre el impacto en los clientes. Sigue el recorrido de las entradas, el material recuperado, las salidas y las acciones conectadas.

   Documenta escenarios de daño en el registro de riesgos. Utiliza el perfil de IA generativa para poner a prueba la lista. Prioriza según el impacto potencial y la probabilidad, incluida la incertidumbre, y asigna un responsable del tratamiento. Decide qué fallos impiden el lanzamiento y cuáles exigen limitar el alcance operativo.

   Conserva: La descripción del sistema, el registro de riesgos, las acciones seleccionadas, las evidencias que faltan y los criterios de aceptación propuestos.

3. 3

   Días 11-20: evalúa el diseño que se desplegará

   Ejecuta casos representativos, de fallo y adversariales sobre la configuración que piensas utilizar. Registra los identificadores del modelo o servicio, los prompts, la configuración de recuperación de información y los permisos de las herramientas, en la medida en que estén disponibles. Si un proveedor oculta un detalle relevante, deja constancia de esa limitación en la evaluación.

   Incluye el paso de revisión humana: ¿puede el revisor reconocer una respuesta incorrecta, encontrar la fuente y rechazarla? Corrige los fallos y registra las nuevas pruebas. Cuando sea viable, recurre a un revisor distinto de quien desarrolló el sistema; una empresa muy pequeña puede acudir a un revisor externo con la cualificación adecuada para decisiones de gran impacto.

   Conserva: Registros de evaluación con control de versiones, hallazgos pendientes y enlaces a los riesgos asociados. No conviertas un supuesto sin probar en un resultado aprobado.

4. 4

   Días 21-30: decide, ensaya e informa

   Aprueba, limita o suspende la funcionalidad según las evidencias. Identifica a la persona que acepta el riesgo restante y establece qué cambios en los datos, modelos, propósito o permisos activan una revisión.

   Ensaya un incidente: un cliente informa de que una respuesta contiene información de otra cuenta. Confirma quién puede desactivar el acceso, conservar las evidencias, evaluar el impacto, coordinar las comunicaciones y autorizar la reactivación. Identifica el ejercicio como simulacro.

   Conserva: Una decisión de lanzamiento documentada, la responsabilidad del seguimiento, el registro de incidentes y una breve comunicación para clientes o el consejo de administración que distinga los controles en funcionamiento del trabajo pendiente.

Formación en NIST AI RMF: ensaya una decisión

Forma a cada persona para las decisiones que le corresponden. GOVERN 2.2 aborda la formación en gestión de riesgos del personal y los socios; el resultado buscado es que puedan cumplir sus responsabilidades. Core de NIST, Govern.

Para quien dirige soporte, eso implica reconocer una divulgación indebida, suspender el asistente y escalar el incidente. Para quien trabaja en ingeniería, significa saber qué cambio de permisos exige una nueva evaluación. Conserva el escenario del simulacro, los participantes, las decisiones y las acciones de seguimiento. Acreditar la finalización de un curso no demuestra, por sí solo, que la respuesta funcione en producción.

NIST también describe los perfiles actuales y los perfiles objetivo, que recogen los resultados de gestión de riesgos existentes y los deseados. Compararlos permite ver el trabajo pendiente. Una empresa pequeña puede trasladar esa distinción a su índice de evidencias: implementado, parcialmente implementado, previsto o no aplicable con justificación. Esas etiquetas de estado son nuestra propuesta. AI RMF 1.0, sección 6.

Qué comunicar a un cliente, un auditor o el consejo de administración

Describe el alcance y la madurez de tu trabajo antes de afirmar que está alineado con el marco. Un cliente que evalúa un asistente de soporte necesita saber si tus evidencias cubren esa funcionalidad, su configuración actual y sus acciones permitidas.

Si la implementación sigue en curso, dilo. Por ejemplo:

Estamos implementando prácticas de NIST AI RMF para nuestro asistente de soporte al cliente. Ya contamos con responsables asignados, inventario del sistema y evaluación de riesgos. Siguen pendientes la evaluación del funcionamiento y el simulacro de respuesta a incidentes. La funcionalidad mantiene su alcance restringido actual hasta que se hayan tomado esas decisiones.

Si las prácticas ya funcionan y los registros lo respaldan, puedes dar una respuesta más completa:

Utilizamos NIST AI RMF 1.0 para organizar la gestión de riesgos de nuestro asistente de soporte al cliente, con acciones pertinentes del perfil de IA generativa. Mantenemos reglas de responsabilidad y supervisión, registros del sistema y de sus riesgos, evidencias de evaluación y procedimientos de gestión de incidentes. Nuestra declaración de alcance identifica las configuraciones evaluadas, las limitaciones conocidas, las acciones pendientes y la próxima revisión. Esta es nuestra descripción de la implementación, no una certificación de NIST.

Son ejemplos que debes adaptar a tus evidencias reales. No copies la declaración más avanzada si los controles que deberían respaldarla todavía están previstos.

Envía un índice breve de evidencias con los responsables de los documentos, las fechas y enlaces con control de acceso. Para cada afirmación, distingue la política del registro que demuestra su ejecución. La regla de supervisión describe lo que debería ocurrir; un registro de revisión del lanzamiento o de aprobación demuestra lo que ocurrió. Comparte una versión de la evaluación que oculte la información sensible cuando las evidencias originales contengan datos de clientes o detalles de seguridad sensibles.

Ante el consejo de administración, destaca los riesgos pendientes de mayor impacto, las decisiones necesarias y sus responsables. Un porcentaje de filas completadas en una hoja de cálculo puede ocultar el único problema abierto que debería impedir el despliegue.

Qué deben cambiar quienes desarrollan, operan y compran

Quienes desarrollan: Considera cada ampliación de permisos como un cambio de diseño. Dar acceso a reembolsos a un asistente que redacta borradores cambia el riesgo, aunque el modelo y el prompt sigan iguales. Actualiza la descripción del sistema, las pruebas de permisos y la decisión de aprobación antes de habilitarlo.

Quienes operan: Conecta los comentarios recibidos con el registro de riesgos. Una queja recurrente sobre políticas inventadas debería dar lugar a la investigación de un patrón de fallos, un caso de evaluación y una decisión sobre la continuidad del uso. Asigna a alguien la responsabilidad de completar ese recorrido.

Quienes compran y fundan empresas: Pide el alcance evaluado, evidencias recientes de evaluación y las limitaciones restantes. La declaración de alineación de un proveedor debe explicar qué controla él y qué debes configurar o supervisar por tu cuenta.

Actúa ahora si una funcionalidad maneja información sensible, influye en una decisión de gran impacto, envía contenido a clientes o puede modificar registros externos. Aplica un proceso más ligero a un experimento acotado que use información pública o sintética y no ejecute acciones externas. Espera antes de ampliar la autonomía si no puedes demostrar los límites de permisos, el proceso de revisión o el mecanismo de suspensión. Son criterios de priorización propuestos, no clasificaciones de riesgo de NIST.

Una revisión del marco no elimina las exposiciones conocidas. Sigue gestionándolas y deja explícita en tu documentación la versión que utilizas.

Cómo encajan ISO/IEC 42001 y la Ley de IA de la UE

Utiliza cada documento para su propósito específico. ISO/IEC 42001:2023 establece requisitos para un sistema de gestión de IA de una organización. Las organizaciones pueden solicitar una certificación independiente de ese sistema de gestión; ISO no emite los certificados. Descripción de la norma por ISO; explicación de ISO sobre la certificación.

La Ley de IA de la Unión Europea impone obligaciones legales según el rol, el sistema y el uso correspondientes. Los registros de AI RMF pueden apoyar ese trabajo, pero estar alineado con el marco no demuestra el cumplimiento de la ley. Consulta las orientaciones de la Comisión Europea sobre la Ley de IA para conocer las reglas y el calendario aplicables, y nuestra página sobre la Ley de IA de la UE para ampliar la lectura en este sitio.

Nuestro marco de gobernanza de inteligencia artificial aporta la estructura de responsabilidades a nivel de empresa; la política de uso aceptable de IA establece las reglas para el personal. Vincula ambas con las evidencias de cada sistema, en lugar de mantener políticas desconectadas para cada marco.

Promesas exageradas: certificados, porcentajes de avance y modelos seguros

La mayor exageración es afirmar que adoptar el marco demuestra que un sistema es seguro. Las orientaciones de NIST organizan la gestión de riesgos; las evidencias útiles siguen dependiendo del sistema, el contexto y las decisiones. Su Core es expresamente flexible e iterativo. Core de NIST AI RMF.

Una certificación de NIST AI RMF no es una credencial emitida por NIST

NIST no certifica a las organizaciones respecto al AI RMF. Describe tu implementación, su alcance y sus evidencias; no afirmes que está «certificada por NIST». Una evaluación independiente puede ser útil, pero su informe debe indicar quién evaluó qué y con qué criterios. Eso no la convierte en un certificado emitido por NIST. El punto de partida oficial es el AI RMF voluntario de NIST.

Completar una lista no equivale a tomar una decisión sobre riesgos. NIST no fija una tolerancia al riesgo universal y el Playbook no exige aplicar todas las acciones sugeridas. Elige criterios de aceptación adecuados al daño potencial y explícalos. AI RMF 1.0, sección 1.2.2; orientaciones del Playbook.

Las evidencias del proveedor no cubren toda tu aplicación. Los datos que recupera, los controles de acceso, las integraciones y los usuarios añaden contexto. NIST aborda expresamente los componentes de terceros y su gestión continua; conserva las evidencias del proveedor y prueba también tu propio diseño operativo. Core de NIST, Map y Manage.

La revisión humana no es una salvaguarda mágica. Quien revisa necesita la fuente, tiempo, conocimientos pertinentes y autoridad para intervenir. Si el flujo de trabajo hace que en la práctica la aprobación sea automática, cámbialo antes de describirlo como una supervisión eficaz.

Preguntas frecuentes

¿Para qué hace falta un marco de gestión de riesgos de IA?

El riesgo de la IA surge de la interacción entre la tecnología, las personas y el contexto de despliegue. El marco ayuda a las organizaciones a gestionar esas interacciones durante todo el ciclo de vida, incluidos los impactos en personas que no son usuarios directos. Es un recurso voluntario; adoptarlo no es una exigencia legal. NIST AI RMF 1.0.

¿Cuáles son 5 riesgos de la IA?

Para una funcionalidad de IA generativa, cinco ejemplos útiles son las respuestas falsas expresadas con seguridad, la filtración de información privada, los sesgos perjudiciales, la dependencia excesiva de las personas y los ataques que desvían el comportamiento del sistema. Se corresponden con áreas tratadas en el perfil de IA generativa; no son su lista completa de riesgos. NIST AI 600-1, sección 2.

¿Cuál es el objetivo principal del marco de gestión de riesgos (RMF) de NIST?

En el caso del AI RMF que tratamos aquí, el objetivo es ayudar a las organizaciones a gestionar los riesgos de IA e incorporar atributos de confiabilidad al desarrollo y al uso. Especifica «AI RMF» al responder a un cliente para que quede claro a qué marco te refieres. Descripción del marco de NIST.

¿Es obligatorio NIST AI RMF?

El marco en sí es voluntario. Revisa por separado los compromisos contractuales, de contratación o legales aplicables a tu empresa; adoptar un marco voluntario no resuelve esas obligaciones. Descripción del marco de NIST.

¿Qué va a sustituir al RMF?

Para el AI RMF, la página de NIST consultada el 26 de octubre de 2026 indica que la versión 1.0 está en revisión y sigue enlazándola. Ese aviso no permite deducir que ya se haya publicado una versión sucesora. NIST AI 600-1 es un perfil complementario de IA generativa. Página del marco de NIST.

¿La IA sustituirá la gestión de riesgos financieros (FRM)?

El AI RMF no permite deducir si la IA sustituirá el trabajo de gestión de riesgos financieros. Este marco aborda cómo gestionan las organizaciones los riesgos de IA, incluidas las responsabilidades humanas y la supervisión; no establece una previsión sobre la sustitución de una profesión. Core de NIST, Govern.

¿Cuáles son los 3 principales marcos de ciberseguridad?

No existe una clasificación universal de los tres mejores marcos para todas las organizaciones. Elige las orientaciones de ciberseguridad según tus sistemas, obligaciones y necesidades de aseguramiento. Para esta decisión, utiliza el AI RMF para abordar los riesgos específicos de IA junto con tu programa de seguridad existente; sus resultados de seguridad y resiliencia no abarcan toda la función de ciberseguridad. NIST AI RMF 1.0.

¿Está desapareciendo el campo de la ciberseguridad?

Introducir IA no elimina la necesidad de trabajar en seguridad. El AI RMF incluye evaluar la seguridad y la resiliencia, gestionar riesgos de terceros y responder a incidentes. Para quien opera un sistema en producción, siguen siendo responsabilidades que hay que asignar y cuyo cumplimiento debe demostrarse. Es una consecuencia operativa, no una previsión del mercado laboral. Core de NIST.

¿Cuál es la amenaza de ciberseguridad #1 en la actualidad?

Ninguna amenaza merece ese puesto para todas las empresas. Prioriza lo que puede causar daños en tu despliegue. En el ejemplo del asistente de soporte, el acceso no autorizado a datos y la inyección de instrucciones requieren pruebas explícitas; su prioridad depende de los datos y los permisos involucrados. Perfil de IA generativa de NIST, sección 2.9.

Una acción para el lunes

Abre el inventario con la persona responsable de la funcionalidad de IA de mayor impacto. Elige un fallo plausible, identifica quién podría sufrir daños y sigue su conexión con una prueba, una decisión de lanzamiento y un procedimiento de suspensión. Si la conexión se rompe, convierte esa carencia en la siguiente acción y asígnale un responsable.

Así, tu próxima respuesta a un cliente tendrá una base concreta: el sistema incluido en el alcance, las evidencias disponibles y el trabajo que aún queda.

Para recibir notas prácticas sobre cómo llevar IA a producción, suscríbete al boletín.