NYDFS Parte 500 e IA: Lo que exige la regulación de ciberseguridad de Nueva York sobre la gobernanza de agentes
Las instituciones de servicios financieros de Nueva York están implementando agentes de IA en informes a clientes, evaluación de riesgos, procesamiento de reclamaciones, detección de fraude y flujos de trabajo regulatorios. La mayoría de estos flujos de trabajo acceden a información no pública, es decir, datos confidenciales de clientes que la 23 NYCRR Parte 500 fue diseñada para proteger. Esto coloca las implementaciones de agentes de IA directamente dentro del alcance de cumplimiento que el Departamento de Servicios Financieros de Nueva York ha estado aplicando con creciente rigor desde que la Segunda Enmienda entró en vigor en noviembre de 2023.
En octubre de 2024, NYDFS dejó clara su postura. Una carta sectorial de la Superintendente Adrienne Harris aclaró que la Regulación de Ciberseguridad ya exige que las entidades cubiertas evalúen y gestionen los riesgos de ciberseguridad relacionados con la IA, incluidos los riesgos de sus propias implementaciones de IA. No se necesitaba una nueva regulación. El marco existente de la Parte 500 se aplica directamente a los flujos de trabajo de agentes de IA que manejan información no pública.
Este artículo explica lo que exige la Parte 500 para flujos de trabajo habilitados con IA, qué aporta la guía de octubre de 2024, dónde las implementaciones de IA generan brechas de cumplimiento y cómo las entidades cubiertas pueden construir una postura de ciberseguridad defendible para el acceso de agentes de IA a información no pública.
Resumen Ejecutivo
Idea principal: Los requisitos centrales de la Parte 500 de NYDFS —evaluación de riesgos, controles de acceso, registros de auditoría, gestión de proveedores externos y respuesta a incidentes— se aplican a las implementaciones de agentes de IA que acceden a información no pública. La carta sectorial de NYDFS de octubre de 2024 confirmó esta interpretación, dejando claro que las entidades cubiertas deben incorporar riesgos específicos de IA en cada componente de su programa de ciberseguridad. Las entidades cubiertas que han implementado IA en flujos de trabajo que manejan información no pública sin actualizar sus evaluaciones de riesgos, políticas de control de acceso y marcos de gestión de proveedores ya están fuera de cumplimiento con la Parte 500.
Por qué te debe importar: NYDFS ha demostrado una tendencia a imponer sanciones de varios millones de dólares y a dirigir acciones contra ejecutivos individuales. La Segunda Enmienda introdujo la responsabilidad personal a nivel del órgano de gobierno superior: los CISOs y el ejecutivo de mayor rango deben firmar una certificación anual de cumplimiento material. Cualquier entidad cubierta cuyos agentes de IA hayan accedido a información no pública sin los controles de acceso, registros de auditoría y cobertura de evaluación de riesgos que exige la Parte 500 está certificando el cumplimiento de controles que no existen.
Puntos Clave
- La Parte 500 de NYDFS ya se aplica al acceso de agentes de IA a información no pública; la carta sectorial de octubre de 2024 lo confirmó sin agregar nuevos requisitos. Las entidades cubiertas no pueden tratar la gobernanza de IA como una obligación futura de cumplimiento. El marco existente de la Regulación de Ciberseguridad —evaluación de riesgos, controles de acceso, registros de auditoría— se aplica a los sistemas de IA ahora, y los examinadores de NYDFS están evaluando el cumplimiento en consecuencia.
- Las evaluaciones de riesgos deben actualizarse para abordar específicamente los riesgos relacionados con la IA. El requisito de evaluación de riesgos de la Parte 500 (Sección 500.9) exige actualizaciones periódicas cuando los sistemas de información u operaciones comerciales cambian. Implementar agentes de IA en flujos de trabajo que manejan información no pública es un cambio material. Las evaluaciones de riesgos anteriores a la implementación de IA de una organización, o que abordan la IA solo en términos genéricos, no cumplen este requisito.
- Los controles de acceso para agentes de IA deben abordar la amenaza específica de ataques potenciados por IA. La guía de octubre de 2024 enfatizó que los métodos de MFA vulnerables a deepfakes potenciados por IA —SMS, autenticación por voz y video— son insuficientes para proteger información no pública en un entorno de IA. Los controles de acceso tanto para usuarios humanos como para agentes de IA deben ser capaces de resistir ataques de autenticación manipulados por IA.
- Los proveedores externos de IA están sujetos a las mismas obligaciones de gestión de proveedores que cualquier otro proveedor que maneje información no pública. Si la infraestructura de un proveedor de IA procesa información no pública en nombre de una entidad cubierta, ese proveedor es un proveedor de servicios externo según la Parte 500 y debe cumplir con los estándares mínimos de ciberseguridad requeridos por la Sección 500.11. Las entidades cubiertas no pueden delegar su cumplimiento de la Parte 500 en las declaraciones de un proveedor de IA.
- Las certificaciones anuales de cumplimiento deben reflejar controles reales de gobernanza de IA, no aspiracionales. La Segunda Enmienda exige que los CISOs y el ejecutivo de mayor rango certifiquen el cumplimiento material anualmente. Cualquier entidad cubierta cuyos agentes de IA hayan accedido a información no pública sin los controles de acceso, registros de auditoría y cobertura de evaluación de riesgos que exige la Parte 500 está certificando el cumplimiento de controles que no existen, lo cual representa un riesgo de sanción.
Qué exige la Parte 500 de NYDFS para flujos de trabajo habilitados con IA
La Parte 500 es una regulación de ciberseguridad, no un marco de registro o divulgación. Sus requisitos centrales establecen lo que debe poder hacer el programa de ciberseguridad de una entidad cubierta: proteger la confidencialidad, integridad y disponibilidad de los sistemas de información; detectar y responder a eventos de ciberseguridad; y demostrar gobernanza a nivel de alta dirección. Cada uno de estos requisitos se aplica directamente a las implementaciones de agentes de IA que interactúan con información no pública.
Evaluación de riesgos (Sección 500.9)
La Parte 500 exige que las entidades cubiertas realicen evaluaciones de riesgos periódicas que identifiquen y evalúen los riesgos de ciberseguridad para la información no pública, actualizadas cuando los sistemas de información u operaciones comerciales cambian de manera significativa. La carta sectorial de octubre de 2024 especificó que las evaluaciones de riesgos deben abordar tres categorías específicas de IA: el uso propio de IA de la entidad cubierta; las tecnologías de IA utilizadas por proveedores de servicios externos; y las vulnerabilidades de aplicaciones de IA que puedan comprometer la confidencialidad, integridad o disponibilidad de la información no pública. Una implementación de IA que no fue evaluada específicamente en la evaluación de riesgos actual es un riesgo no evaluado, una deficiencia directa de la Sección 500.9 sin importar cuán bien funcione el sistema de IA operativamente.
Controles de acceso (Sección 500.7)
La Parte 500 exige que las entidades cubiertas implementen controles de acceso, incluyendo MFA, para limitar el acceso a información no pública solo a usuarios autorizados. Para los agentes de IA, esto tiene dos dimensiones. Primero, los agentes deben estar regulados por controles que restrinjan el acceso a información no pública solo a los flujos de trabajo y operaciones autorizados; ningún agente debe tener un alcance mayor del necesario para su tarea específica. Segundo, los mecanismos de autenticación que protegen sistemas que manejan información no pública deben resistir ataques potenciados por IA. La guía de octubre de 2024 señaló explícitamente que los deepfakes pueden eludir autenticación por SMS, voz y video, y dirigió a las entidades cubiertas a usar métodos resistentes al phishing que los medios generados por IA no puedan suplantar. Desde noviembre de 2025, MFA es obligatorio para todos los usuarios que acceden a información no pública, un requisito que se extiende a los sistemas y rutas por los que los agentes de IA acceden a dicha información.
Requisitos de registros de auditoría (Sección 500.6)
La Parte 500 exige que las entidades cubiertas mantengan registros de auditoría diseñados para detectar y responder a eventos de ciberseguridad. Para implementaciones de agentes de IA, el registro de auditoría debe capturar qué información no pública fue accedida, por qué agente o sistema, bajo qué autorización y cuándo, a un nivel de operación suficiente para respaldar la detección de incidentes e investigación forense. Los registros estándar de llamadas API y de inferencia de LLM no cumplen este requisito: registran eventos del sistema, no los datos de acceso a información no pública que exige la obligación de registro de la Parte 500. Los registros que respaldan el cumplimiento deben conservarse durante cinco años y estar disponibles para NYDFS si se solicitan.
Gestión de proveedores de servicios externos (Sección 500.11)
La Parte 500 exige que las entidades cubiertas mantengan políticas escritas que regulen a los proveedores de servicios externos que acceden a información no pública, incluyendo estándares mínimos de ciberseguridad y diligencia debida continua. Los proveedores de IA cuya infraestructura procesa información no pública —proveedores de alojamiento de modelos, operadores de puertas de enlace API, proveedores de bases de datos vectoriales— son proveedores de servicios externos según la Parte 500. La guía de octubre de 2024 añadió especificidad: la diligencia debida debe evaluar cómo las amenazas relacionadas con IA que enfrenta el proveedor pueden afectar a la entidad cubierta, y los acuerdos deben exigir que los proveedores notifiquen a la entidad cubierta sobre cualquier evento de ciberseguridad relacionado con IA. Una entidad cubierta que no haya evaluado a sus proveedores de IA bajo el marco de la Sección 500.11 tiene una brecha de cumplimiento.
Respuesta a incidentes (Sección 500.16)
La Parte 500 exige un plan de respuesta a incidentes capaz de abordar eventos de ciberseguridad. La guía de octubre de 2024 especificó que estos planes deben estar diseñados para abordar eventos de ciberseguridad relacionados con IA, incluidos ataques potenciados por IA e incidentes que involucren acceso o exposición de información no pública por parte de agentes de IA. Los incidentes de ciberseguridad que cumplan con ciertos criterios deben reportarse a NYDFS en un plazo de 72 horas. Un agente de IA que accede a información no pública sin autorización, o que es comprometido mediante prompt injection o ingeniería social potenciada por IA, constituye un evento de ciberseguridad según la Parte 500. Si el plan de respuesta a incidentes no aborda cómo detectar, contener y reportar este tipo de eventos, el plan es inadecuado.
¿Qué estándares de cumplimiento de datos importan?
Read Now
Dónde las implementaciones de IA generan brechas de cumplimiento con la Parte 500
Las brechas de cumplimiento con la Parte 500 introducidas por implementaciones de agentes de IA siguen un patrón consistente entre las entidades cubiertas. No son fallos de intención; la mayoría de las organizaciones que han implementado agentes de IA entienden que están reguladas. Son fallos de arquitectura: implementaciones de IA diseñadas para capacidad operativa sin los componentes del programa de ciberseguridad que exige la Parte 500.
Evaluaciones de riesgos que no reflejan el entorno de IA
La mayoría de las entidades cubiertas realizaron su evaluación de riesgos actual antes de que los agentes de IA formaran parte de sus operaciones, o la actualizaron de manera genérica cuando se implementó IA. La Parte 500 exige que las evaluaciones de riesgos reflejen los sistemas de información realmente utilizados. Una evaluación que identifica «servicios en la nube» como categoría de riesgo pero no menciona a los agentes de IA accediendo a información no pública, las vulnerabilidades específicas que introducen o las dependencias de proveedores que crean, no cumple con la Sección 500.9 para el entorno actual. Los examinadores de NYDFS compararán los sistemas de IA implementados con la evaluación de riesgos, y las brechas entre ambos serán hallazgos.
Controles de acceso diseñados para humanos, no para agentes
La mayoría de las entidades cubiertas han implementado MFA y controles de acceso para usuarios humanos. Los agentes de IA suelen eludir estos controles mediante cuentas de servicio o claves API con acceso amplio a información no pública, sin desafío de MFA a nivel de flujo de trabajo y sin delimitación a nivel de operación. Esta arquitectura no cumple ni con el requisito de control de acceso para el acceso del agente a información no pública ni con el estándar actualizado para mecanismos de autenticación resistentes a ataques de deepfake potenciados por IA. Trata a los agentes de IA como procesos internos confiables en lugar de como accesadores de información no pública sujetos a los requisitos de control de acceso de la Parte 500.
Gestión de proveedores que se queda en el contrato
Muchas entidades cubiertas tienen acuerdos con proveedores de IA con declaraciones estándar de ciberseguridad, pero no han realizado la evaluación sustantiva de la Sección 500.11 que exige la guía de octubre de 2024. Un acuerdo de proveedor con una garantía genérica de seguridad, sin evaluar cómo la infraestructura de IA del proveedor protege específicamente la información no pública durante la inferencia del modelo y sin disposiciones de notificación de incidentes específicos de IA, no cumple con los requisitos de gestión de terceros de la Parte 500.
Mejores prácticas para la gobernanza de agentes de IA conforme a la Parte 500 de NYDFS
1. Realiza una actualización específica de evaluación de riesgos para IA
Actualiza la evaluación de riesgos de la Parte 500 para abordar específicamente las implementaciones de IA: inventaría cada agente o sistema de IA que accede a información no pública, evalúa los riesgos de ciberseguridad que introduce cada uno (dependencias de proveedores, vulnerabilidades de autenticación, exposición de información no pública en caso de compromiso) y documenta los controles existentes o planificados. Esta es una actualización de la evaluación de riesgos central que impulsa todo el programa de ciberseguridad y debe completarse antes del próximo ciclo anual de certificación.
2. Extiende los controles de acceso a los flujos de trabajo de agentes de IA a nivel de operación
Implementa controles de acceso que regulen el acceso de agentes de IA a información no pública por operación, no solo por sesión. Cada flujo de trabajo de agente debe operar bajo una credencial de identidad única limitada a la información no pública necesaria, con acceso evaluado según el perfil autorizado del agente y la clasificación de los datos solicitados. Los mecanismos de autenticación que protegen sistemas que manejan información no pública deben usar métodos resistentes al phishing que no puedan ser suplantados por deepfakes de IA, evitando factores SMS, voz y video que NYDFS ha señalado como insuficientes en un entorno de amenazas de IA.
3. Crea registros de auditoría específicos de IA que respalden la detección de incidentes y la investigación forense
Implementa registros de auditoría a nivel de operación para el acceso de agentes de IA a información no pública: identidad del agente, contexto del flujo de trabajo autorizado, información no pública específica accedida, operación realizada y marca de tiempo. Los registros deben conservarse durante cinco años, ser evidentes ante manipulaciones y alimentar el SIEM de la organización para que el acceso anómalo de agentes de IA se detecte en tiempo real. Este registro de auditoría respalda tanto los requisitos de detección de la Sección 500.6 como la base forense para la notificación de incidentes a NYDFS en 72 horas si ocurre un evento de ciberseguridad relacionado con IA.
4. Realiza una diligencia debida sustantiva a proveedores de IA bajo la Sección 500.11
Para cada proveedor de IA cuya infraestructura procese información no pública, realiza la evaluación de riesgos de terceros que exige la Parte 500: evalúa cómo el proveedor protege la información no pública durante la inferencia del modelo, analiza la exposición del proveedor a amenazas relacionadas con IA y su posible impacto en la entidad cubierta, y actualiza los acuerdos para exigir la notificación de eventos de ciberseguridad relacionados con IA que afecten la información no pública de la entidad cubierta. Las garantías genéricas de seguridad no cumplen con el estándar actualizado de gestión de terceros.
5. Actualiza los planes de respuesta a incidentes para abordar eventos de ciberseguridad relacionados con IA
Revisa el plan de respuesta a incidentes para abordar específicamente eventos de ciberseguridad relacionados con IA: acceso no autorizado de agentes de IA a información no pública, ataques de prompt injection que causen exfiltración de información no pública, ingeniería social potenciada por IA que resulte en exposición de información no pública e incidentes de IA en el lado del proveedor que afecten la información no pública de la entidad cubierta. Define criterios de detección, procedimientos de contención y cómo se activa y ejecuta la obligación de notificación a NYDFS en 72 horas para cada tipo de evento.
Cómo Kiteworks respalda el cumplimiento de la Parte 500 de NYDFS para implementaciones de agentes de IA
El desafío central que plantea la Parte 500 para las implementaciones de IA es que la Regulación de Ciberseguridad exige que los controles estén integrados en los sistemas que acceden a información no pública, no añadidos después de la implementación. Los agentes de IA que acceden a información no pública mediante cuentas de servicio y prompts de sistema operan fuera del programa de ciberseguridad, no dentro de él. Llevar el acceso de agentes de IA a información no pública al cumplimiento de la Parte 500 requiere una capa de gobernanza que intercepte cada interacción del agente, aplicando los controles de acceso, registros de auditoría y gobernanza de identidad que exige la regulación.
La Red de Datos Privados de Kiteworks proporciona a las entidades cubiertas por NYDFS una arquitectura de gobernanza a nivel de datos que se sitúa entre los agentes de IA y la información no pública a la que necesitan acceder, verificando la identidad del agente, aplicando políticas de acceso a nivel de operación, utilizando cifrado validado FIPS 140-3 Nivel 1 y capturando un registro de auditoría evidente ante manipulaciones y retenible durante cinco años para cada interacción con información no pública. Cada flujo de trabajo de agente de IA hereda automáticamente los controles de ciberseguridad de la Parte 500, integrados en la arquitectura de acceso a datos en lugar de añadirse manualmente.
Controles de acceso a nivel de operación y gobernanza de identidad para la Sección 500.7
Kiteworks autentica a cada agente de IA antes de que ocurra el acceso a información no pública, usando credenciales únicas por flujo de trabajo vinculadas al autorizador humano que delegó la tarea. La política ABAC a nivel de operación asegura que cada agente acceda solo a la información no pública necesaria para el flujo de trabajo autorizado específico. Esto cumple con los requisitos de control de acceso de la Parte 500 para el acceso de agentes de IA a información no pública y proporciona la delimitación a nivel de operación que las implementaciones con cuentas de servicio no pueden demostrar.
Registro de auditoría evidente ante manipulaciones para la Sección 500.6 y notificación de incidentes en 72 horas
Cada interacción de agente de IA con información no pública se captura en un registro a nivel de operación evidente ante manipulaciones: identidad del agente, autorizador humano, información no pública específica accedida, tipo de operación, resultado de la evaluación de políticas y marca de tiempo. Los registros se conservan durante cinco años y se integran en el SIEM de la organización para la detección en tiempo real de accesos anómalos. Cuando ocurre un evento de ciberseguridad relacionado con IA que cumpla con los criterios, el registro completo de la interacción está disponible de inmediato para respaldar la obligación de notificación a NYDFS en 72 horas.
Soporte de gestión de proveedores externos para la Sección 500.11
Kiteworks ofrece a las entidades cubiertas una relación con el proveedor basada en el cumplimiento demostrable de la Parte 500. La arquitectura de la plataforma garantiza que la información no pública accedida por agentes de IA esté regulada por los mismos controles de acceso, cifrado e infraestructura de auditoría que cualquier otro intercambio de información no pública, proporcionando a las entidades cubiertas una relación de proveedor que pueden documentar en su evaluación de la Sección 500.11 con detalle, no solo con declaraciones genéricas.
Para las entidades cubiertas por NYDFS que buscan integrar las implementaciones de agentes de IA en su programa de ciberseguridad de la Parte 500 sin ralentizar la velocidad de implementación, Kiteworks hace que cada interacción de agente de IA con información no pública sea conforme por diseño. Descubre más sobre Kiteworks para servicios financieros o solicita una demo.
Preguntas frecuentes
La Parte 500 se aplica a los agentes de IA que acceden a información no pública. La carta sectorial de NYDFS de octubre de 2024 confirmó que los requisitos existentes de la Regulación de Ciberseguridad —evaluación de riesgos, controles de acceso, registros de auditoría, gestión de proveedores externos y respuesta a incidentes— aplican a las implementaciones de IA de las entidades cubiertas. La regulación regula el acceso a información no pública sin importar si dicho acceso lo realiza un empleado humano, un proceso automatizado o un agente de IA. Las entidades cubiertas no pueden tratar la gobernanza de IA como algo fuera del alcance de cumplimiento de la Parte 500.
La carta sectorial de NYDFS de octubre de 2024 no impone nuevos requisitos, sino que aclara cómo aplican las obligaciones existentes de la Parte 500 a la IA. Exige que las entidades cubiertas: actualicen las evaluaciones de riesgos para abordar específicamente los riesgos relacionados con la IA derivados de su propio uso de IA, dependencias de proveedores de IA y vulnerabilidades relacionadas con IA; evalúen si MFA y otros controles de acceso pueden resistir ataques potenciados por IA como los deepfakes; realicen diligencia debida específica de IA a proveedores externos de IA y exijan notificación de eventos de ciberseguridad relacionados con IA; inventaríen y gestionen la información no pública utilizada en sistemas de IA; y aseguren que los planes de respuesta a incidentes aborden eventos de ciberseguridad relacionados con IA. Cada uno de estos es una obligación existente de la Parte 500 aplicada al contexto de IA, no un nuevo requisito regulatorio.
Un informe SOC 2 por sí solo no cumple con los requisitos de proveedor de servicios externo de la Parte 500 según la Sección 500.11. La Parte 500 exige una diligencia debida sustantiva específica sobre cómo el proveedor protege la información no pública de la entidad cubierta, incluyendo cómo las amenazas relacionadas con IA que enfrenta el proveedor pueden afectar a la entidad cubierta. La guía de octubre de 2024 añade que los acuerdos con proveedores deben exigir la notificación de eventos de ciberseguridad relacionados con IA que afecten la información no pública de la entidad cubierta. Las entidades cubiertas deben complementar la revisión de SOC 2 con una evaluación de gestión de riesgos de terceros específica de IA sobre la arquitectura de acceso a información no pública del proveedor y actualizar los acuerdos para incluir notificación y declaraciones de ciberseguridad específicas de IA.
Para certificar el cumplimiento material de la Parte 500 durante un periodo en el que los agentes de IA accedieron a información no pública, las entidades cubiertas deben tener: una evaluación de riesgos actualizada que aborde específicamente los riesgos relacionados con IA; controles de acceso que regulen el acceso de agentes de IA a información no pública a nivel de operación; registros de auditoría que capturen el acceso de agentes de IA a información no pública con el nivel de detalle que exige la Sección 500.6; evaluaciones sustantivas de terceros sobre los proveedores de IA que manejen información no pública; y planes de respuesta a incidentes que aborden eventos de ciberseguridad relacionados con IA. Certificar el cumplimiento sin estos controles no solo es un riesgo de gobernanza, sino que puede exponer a fraude de certificación dada la responsabilidad personal exigida por la Segunda Enmienda.
Si un agente de IA provoca o está involucrado en un evento de ciberseguridad que cumple con el umbral de notificación de la Parte 500 —incluyendo acceso no autorizado o adquisición de información no pública— la entidad cubierta debe notificar a NYDFS en un plazo de 72 horas desde que determine que ocurrió el evento. La obligación de notificación no distingue entre incidentes causados por IA y por humanos. La guía de octubre de 2024 indicó específicamente a las entidades cubiertas que aseguren que los planes de respuesta a incidentes aborden eventos de ciberseguridad relacionados con IA. Si la entidad cubierta no puede detectar el incidente relacionado con IA de manera oportuna —porque el acceso de agentes de IA a información no pública no se captura en registros de auditoría en tiempo real— el plazo de 72 horas puede expirar antes de que se identifique el incidente.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: Por qué el 91% de las pequeñas empresas juegan a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe un «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.