Cómo hacer una evaluación de riesgos de IA
Una evaluación de riesgos de IA identifica, analiza y documenta los impactos técnicos, jurídicos y éticos derivados del ciclo de vida de un sistema algorítmico. Este proceso conecta las obligaciones normativas con controles técnicos verificables mediante evidencia. Su finalidad principal no es generar un documento estático, sino fundamentar decisiones formales sobre la aprobación, mitigación o descarte de un caso de uso.
Delimitación del alcance entre desarrollo propio y adopción de terceros
El punto de partida para una evaluación de riesgos de IA consiste en definir con precisión la frontera del sistema analizado. Cuando una organización entrena o ajusta modelos internamente, el alcance incluye la recolección del dato, el preprocesamiento, la arquitectura algorítmica, las pruebas de sesgo y la infraestructura de despliegue. En este escenario, el control sobre el código y los parámetros permite aplicar medidas de mitigación directas a nivel de ingeniería.
En cambio, al incorporar herramientas de terceros, modelos fundacionales o software como servicio con componentes inteligentes, el alcance se desplaza hacia la gobernanza de accesos, los términos de uso de los datos de entrada, las integraciones vía API y la dependencia operativa del proveedor. La evaluación debe determinar si las indicaciones del fabricante cubren el contexto operativo previsto y si las limitaciones contractuales o técnicas introducen vulnerabilidades no documentadas.
Un alcance mal delimitado conduce a evaluaciones superficiales que omiten riesgos de integración o asumen controles inexistentes en proveedores externos. Registrar formalmente el caso de uso, sus entradas, salidas y usuarios finales es el requisito básico para iniciar cualquier análisis estructurado.
- Mapeo de fuentes de datos, flujos de entrada y destino de las inferencias generadas.
- Identificación de dependencias técnicas externas, APIs y librerías de código abierto utilizadas.
- Definición clara del rol de la organización: desarrolladora, integradora o usuaria final de la solución.
- Identificación de los perfiles de usuarios directos y de las personas impactadas por los resultados del modelo.
Criterios de análisis: categorías de impacto y severidad
El análisis debe clasificar el riesgo en función del impacto potencial y su probabilidad de ocurrencia, evaluando categorías técnicas, operativas y de derechos fundamentales. Las categorías clave abarcan la seguridad de la información, la opacidad de los resultados, la discriminación indirecta, la generación de contenido no fundamentado o engañoso, y el incumplimiento de normas vigentes como la legislación de protección de datos personales.
Para establecer criterios objetivos, las organizaciones recurren a marcos de referencia como la norma ISO/IEC 42001, que define directrices de gestión para sistemas de inteligencia artificial, y a debates legislativos de referencia como el Proyecto de Ley 2338/2023 en Brasil, que propone clasificaciones basadas en el riesgo para derechos fundamentales. Estos marcos sirven como guía metodológica para definir umbrales de severidad, sin asumir obligaciones definitivas fuera del ordenamiento vigente.
La severidad debe medirse por el daño que una falla algorítmica puede infligir a una persona o al negocio. Los casos de uso que influyen en decisiones de empleo, acceso a crédito, salud o interacciones legales automáticas exigen criterios de escrutinio sustancialmente más estrictos que aquellos aplicados a tareas de automatización interna de bajo impacto.
- Vulnerabilidad a ataques de inyección de instrucciones, envenenamiento de datos o extracción de modelos.
- Nivel de explicabilidad técnica frente a usuarios finales y auditores externos.
- Presencia de sesgos en datos históricos que puedan reproducir asimetrías de género, raza o condición social.
- Grado de autonomía conferido al modelo en la ejecución de acciones irreversibles.
Participantes esenciales y distribución de responsabilidades
Una evaluación de riesgos de IA no puede quedar aislada en el equipo de ciencia de datos ni en el departamento legal. Requiere un comité multidisciplinario donde cada parte asuma responsabilidades concretas sobre aspectos específicos del ciclo de vida del sistema. La dispersión de funciones sin dueños claros deriva habitualmente en vacíos de supervisión operativa.
Los responsables de negocio o producto deben documentar la justificación y los límites de uso previstos; los ingenieros y científicos de datos analizan el comportamiento técnico, la deriva del modelo y las métricas de precisión; los equipos de seguridad evalúan la superficie de ataque; y las áreas de privacidad y cumplimiento verifican la adecuación legal y el respeto a los derechos de los titulares de datos.
El resultado debe incluir un responsable formal que valide el análisis y apruebe las decisiones tomadas. La rendición de cuentas exige que las aprobaciones no sean tácitas, sino registros fechados y sustentados en evidencia documental verificable.
- Líder de producto o negocio: define el propósito comercial y responde por el impacto operativo del uso.
- Equipo técnico o de datos: aporta métricas de desempeño, resultados de pruebas de robustez y arquitectura.
- Oficial de Privacidad (DPO) y área legal: examinan bases legales de tratamiento y responsabilidades regulatorias.
- Seguridad de la información: audita vectores de ataque, custodia de credenciales e integridad de tuberías de datos.
Impacto práctico: decisiones vinculadas y controles obligatorios
El objetivo primordial de una evaluación de riesgos de IA es alterar la realidad operativa del sistema evaluado. Un informe que clasifica un modelo en riesgo elevado sin condicionar su implementación carece de utilidad práctica. La evaluación debe desembocar obligatoriamente en una de tres decisiones: aprobación estándar, aprobación condicionada a la implementación de controles o rechazo del caso de uso.
Cuando se determina una aprobación condicionada, el equipo técnico debe desplegar controles específicos antes de la puesta en producción. Estos controles pueden consistir en salvaguardas de supervisión humana activa, filtros de entrada y salida para mitigar alucinaciones, anonimización rigurosa de conjuntos de prueba o cláusulas contractuales adicionales con proveedores de infraestructura.
Cada control asignado debe tener una fecha límite de implementación, un propietario técnico asignado y un tipo de evidencia documental requerido para demostrar su efectividad. Sin esta trazabilidad, los riesgos identificados permanecen como contingencias abiertas en la organización.
- Definición obligatoria de mecanismos de supervisión humana e intervención en caso de anomalías.
- Ajuste en los permisos de acceso y políticas de retención de los datos utilizados en inferencias.
- Modificación de contratos con terceros para limitar el reentrenamiento con datos corporativos.
- Establecimiento de umbrales automáticos de bloqueo frente a salidas con baja confianza estadística.
Registro de evidencias y revisión continua del sistema algorítmico
La evaluación no concluye con la puesta en producción. A diferencia del software tradicional, los modelos de IA sufren degradación de rendimiento por deriva conceptual o de datos a lo largo del tiempo. Por consiguiente, la validez del análisis de riesgo está sujeta a revisiones periódicas o reactivas ante cambios estructurales.
La organización debe conservar un rastro auditable que vincule cada riesgo con su obligación correspondiente, el control implementado, las pruebas realizadas y la decisión tomada por los responsables. Este acervo probatorio es indispensable ante auditorías internas, requerimientos de autoridades de supervisión o incidentes operativos.
Se deben establecer disparadores automáticos para reabrir la evaluación de riesgos: la actualización del modelo base por parte del proveedor, una alteración significativa en el volumen o perfil de los datos de entrada, o la identificación de resultados anómalos recurrentes reportados por usuarios o monitores técnicos.
Preguntas frecuentes
¿En qué momento del ciclo de vida debe realizarse la evaluación de riesgos de IA?
Debe iniciarse durante la fase conceptual, antes de adquirir licencias, recolectar datos o entrenar modelos. Postergar la evaluación hasta la víspera del despliegue incrementa los costos de corrección y suele forzar compromisos inadecuados entre plazos de entrega y controles de seguridad. Posteriormente, debe actualizarse ante cualquier cambio sustancial en la arquitectura o en los datos de entrada.
¿Cuál es la diferencia entre esta evaluación y una evaluación de impacto a la privacidad (EIPD / RIPD)?
La evaluación de impacto a la protección de datos se concentra en los riesgos para los derechos de los titulares derivados del tratamiento de información personal. La evaluación de riesgos de IA abarca un espectro más amplio: incluye riesgos de seguridad algorítmica, fallas de precisión técnica, sesgo de salida, alucinaciones, impactos sistémicos y continuidad del negocio, aunque ambos análisis se complementan estrechamente.
¿Cómo afecta el Proyecto de Ley 2338/2023 de Brasil a estas evaluaciones?
El PL 2338/2023 es un proyecto legislativo en tramitación en el Congreso brasileño que busca regular el desarrollo y uso de la IA mediante un enfoque basado en riesgos. Aunque aún no constituye ley vigente, sus debates y propuestas técnicas establecen criterios útiles sobre la categorización de alto riesgo, la necesidad de evaluaciones de impacto algorítmico y la exigencia de trazabilidad documental para desarrolladores e implementadores.
¿Qué debe cambiar concretamente tras completar la evaluación de riesgos?
El resultado debe modificar los requisitos operativos: puede exigir la reconfiguración de filtros técnicos, imponer supervisión humana en decisiones críticas, demandar cambios contractuales con proveedores externos o, en última instancia, vetar el lanzamiento del sistema si las medidas de mitigación resultan insuficientes para contener el daño potencial.