¿Qué es la clasificación de sistemas de IA?

Cómo funciona

Comienza con el alcance

Antes de asignar un nivel de riesgo, es necesario saber si la ley o el marco aplicable considera siquiera el software como un sistema de IA. Este primer paso parece básico, pero suele ser el más difícil. La definición actualizada de la OECD se centra en un sistema basado en máquinas que infiere a partir de entradas para generar predicciones, contenido, recomendaciones o decisiones, al tiempo que reconoce distintos niveles de autonomía y adaptabilidad tras el despliegue. En la UE, la Comisión ha publicado orientaciones no vinculantes para ayudar a proveedores y usuarios a determinar si un sistema de software cumple la definición del AI Act. Así, la primera pregunta de clasificación no es "¿qué tan arriesgado es?", sino "¿qué entra exactamente en el ámbito de aplicación aquí?"

Luego describe qué hace el sistema

Una vez que el sistema está dentro del ámbito de aplicación, una buena clasificación lo describe en términos técnicos y operativos antes de pasar a las etiquetas jurídicas. El Marco de la OECD para la Clasificación de Sistemas de IA resulta útil aquí porque no lo reduce todo a los compartimentos legales de un solo país. Analiza los efectos del sistema sobre las personas y el planeta, el contexto económico, los datos y las entradas, el modelo de IA, y la tarea y los resultados. Esto permite a los equipos describir si un sistema realiza reconocimiento, personalización, previsión, optimización, generación de contenido u otra tarea, y si se basa en aprendizaje automático, métodos basados en conocimiento o enfoques mixtos.

NIST aplica una idea similar en un formato de gobernanza. El AI RMF permite a las organizaciones crear perfiles por caso de uso y perfiles intersectoriales para clasificar los sistemas de manera que apoyen la gestión de riesgos. NIST ofrece ejemplos como perfiles de contratación y vivienda justa, y proporciona por separado un perfil de IA generativa para tecnología que aparece en múltiples sectores. El punto práctico es sencillo: la clasificación debe ante todo indicar qué es el sistema y cómo funciona, no solo si está permitido.

El contexto cambia la clase

Un modelo en abstracto rara vez es suficiente. Los reguladores y los organismos de normalización insisten repetidamente en el propósito previsto, el entorno de despliegue, los usuarios, las personas afectadas y la legislación aplicable. La función MAP de NIST establece que las organizaciones deben documentar los propósitos previstos, los usos beneficiosos, las leyes específicas del contexto, las normas, las expectativas y los entornos en los que se desplegará el sistema. El marco de clasificación de la OECD también está diseñado para sistemas en un proyecto y contexto específicos, no solo para descripciones en fase de laboratorio.

Esto importa porque el riesgo suele provenir del entorno más que de la familia de modelos. Un motor de recomendación dentro de una aplicación de música no plantea las mismas cuestiones de gobernanza que un sistema de recomendación utilizado en préstamos, seguros o servicios públicos. Un chatbot empleado para redacción interna no es lo mismo que un chatbot utilizado para comunicarse con clientes sobre derechos, seguridad o elegibilidad. La clasificación, por tanto, debe estar vinculada a la función que el sistema desempeña en el mundo real.

La autonomía y el control humano son relevantes

Otro eje fundamental es la autonomía. El marco de la OECD distingue entre sistemas que no pueden actuar según sus propias recomendaciones, sistemas que requieren la aprobación humana, sistemas que actúan salvo que un humano los vete, y sistemas que actúan sin intervención humana. Esta es una pregunta más útil que la afirmación vaga de que hay un humano "en el bucle". Pregunta qué autoridad tiene el sistema, cuándo interviene el humano y si esa intervención es significativa.

Aquí es donde se producen muchos errores de gobernanza. Los equipos suelen describir un sistema como de bajo riesgo porque alguien puede, en teoría, anularlo. Pero si la persona responsable carece de tiempo, formación o poder real para cambiar el resultado, la autonomía práctica del sistema puede seguir siendo alta. La clasificación debe, por tanto, reflejar el nivel real de acción delegada, no solo una declaración de política sobre supervisión.

Los niveles de riesgo conllevan efectos jurídicos

En las normas y los marcos de gobernanza, la clasificación suele ser descriptiva: ayuda a las organizaciones a reunir las evidencias adecuadas y a elegir el camino de revisión correcto. En el derecho vinculante, la clasificación puede tener consecuencias jurídicas directas. El EU AI Act es el ejemplo más claro en la actualidad. Utiliza una estructura basada en riesgos que incluye prácticas prohibidas, sistemas de IA de alto riesgo, sistemas sujetos a obligaciones de transparencia y obligaciones separadas para los modelos de IA de uso general. La condición de alto riesgo puede surgir por dos vías principales: el sistema de IA está integrado en determinados productos regulados, o se utiliza en uno de los contextos sensibles enumerados por la norma.

Lo importante es que las clases de riesgo legal no son etiquetas universales para toda la labor de gobernanza. Son herramientas específicas de cada jurisdicción, diseñadas para objetivos de política concretos. Un método de clasificación sólido debe, por tanto, ser capaz de traducir entre categorías descriptivas, como función o autonomía, y categorías jurídicas, como alto riesgo o prohibido, sin confundir unas con otras.

Las clases a nivel de modelo y a nivel de sistema pueden diferir

La regulación moderna de la IA separa cada vez más la capa del modelo de la capa del sistema. Esto es especialmente relevante para la tecnología de uso general y generativa. Una organización puede proporcionar un modelo que se adapte a múltiples productos derivados. Otra puede integrar ese modelo en un sistema de contratación, una herramienta de búsqueda, un asistente de redacción o un producto médico. No se trata del mismo objeto de cumplimiento.

Para los responsables, esto significa que una sola entrada en el inventario a menudo no es suficiente. Puede ser necesario registrar al menos tres elementos relacionados: el modelo, el sistema derivado y el caso de uso. Las obligaciones a nivel de modelo pueden referirse a la documentación, las pruebas o la transparencia de los datos de entrenamiento. Las obligaciones a nivel de sistema pueden referirse al propósito previsto, las instrucciones de uso, la supervisión humana, los avisos a los usuarios o las verificaciones de conformidad. La clasificación falla cuando estas capas se fusionan en una etiqueta vaga.

La clasificación se mantiene a lo largo del ciclo de vida

La clasificación no es un ejercicio puntual de taller. La OECD señala que la clasificación de un sistema puede cambiar a medida que evoluciona, incorpora nuevos datos, se despliega más ampliamente, madura técnicamente o adquiere nuevas capacidades. NIST hace el mismo apunte práctico al contemplar perfiles actuales y objetivo que pueden revisarse con el tiempo. En otras palabras, un sistema puede cambiar de clase aunque su familia de modelos original siga siendo la misma.

Operativamente, esto significa que las organizaciones deben tratar la clasificación como evidencia de gobernanza viva. Un registro sólido suele incluir el propósito previsto, los usuarios, los grupos afectados, el sector, las fuentes de datos, el tipo de tarea, el grado de autonomía de acción, el diseño de la revisión humana, las jurisdicciones aplicables y el motivo por el que se seleccionó la clase elegida. La revisión debe activarse ante cambios como el reentrenamiento, un despliegue más amplio, un mayor acceso a herramientas, nuevas integraciones, la entrada en un sector regulado o el paso de la asesoría a la acción.