Social, Legal, Ethical, Empathetic and Cultural Norm Operationalisation for AI Agents

El artículo propone un marco sistemático para operacionalizar las normas sociales, legales, éticas, empáticas y culturales (SLEEC) en agentes de IA, cerrando la brecha entre los principios abstractos y los requisitos verificables para garantizar su alineación con los valores humanos en dominios de alto riesgo.

Lo esencial

Imagina que estás construyendo un robot para cuidar a una persona mayor en su casa. Este robot no es solo una máquina que hace tareas; es un vecino digital que debe tomar decisiones importantes: ¿Debe llamar a una ambulancia si la persona se cae? ¿Debe despertar a la persona para comer o esperar a que se despierte sola? ¿Cómo debe hablarle si la persona tiene dificultades para entender?

Aquí es donde entra el problema: si le decimos al robot "sé amable", no sabemos exactamente qué significa eso en una situación de emergencia. ¿Qué pasa si "ser amable" (no molestar) choca con "salvar una vida" (llamar a emergencias)?

Este artículo de Radu Calinescu y su equipo es como un manual de instrucciones para convertir las reglas de la buena convivencia humana en código de computadora. Llamamos a estas reglas normas SLEEC (Sociales, Legales, Éticas, Empáticas y Culturales).

Aquí te explico el proceso que proponen, usando una analogía sencilla: Construir un Robot "Buen Vecino".

El Gran Desafío: De la "Filosofía" al "Código"

Hasta ahora, tenemos grandes documentos internacionales que dicen cosas como: "La IA debe respetar la privacidad" o "La IA debe ser justa". Pero esto es como decirle a un chef: "Haz algo delicioso". El chef necesita saber exactamente qué ingredientes usar, a qué temperatura cocinar y cuánto tiempo.

Los autores dicen: "No basta con tener las reglas generales; necesitamos traducirlas a pasos concretos que el robot pueda seguir y que podamos probar que las sigue".

Los 5 Pasos para Crear al Robot "Buen Vecino"

Imagina que este proceso es como entrenar y licenciar a un nuevo empleado antes de que empiece a trabajar.

1. Definir sus "Sentidos" y "Brazos" (Capacidades)

Primero, miramos qué puede hacer el robot.

• Analogía: ¿Tiene ojos (cámaras)? ¿Tiene oídos (micrófonos)? ¿Puede moverse?
• El problema: Si tiene una cámara, ¿puede ver todo lo que hace el usuario? Eso es un problema de privacidad. Si puede moverse, ¿puede mover cosas que no debe?
• La tarea: Listamos qué puede hacer y qué no debería hacer por razones éticas.

2. Traducir las Reglas a "Si... Entonces..." (Elicitación)

Aquí convertimos las ideas abstractas en reglas claras.

• Regla abstracta: "Respeta la autonomía del usuario".
• Regla concreta (SLEEC): "SI el usuario se cae (evento), ENTONCES llama a emergencias. PERO, SI el usuario dice 'no' (defeater), NO llames".
• La magia: Usan un lenguaje especial para escribir estas reglas de forma que no haya dudas. Es como escribir una receta de cocina donde cada paso es exacto.

3. El "Examen de Lógica" (Verificación de Bien Formado)

Antes de construir el robot, revisamos las reglas para ver si se contradicen.

• El conflicto: Imagina que tienes dos reglas:
  1. "Si hay humo, llama a bomberos en 2 minutos".
  2. "Si la persona se cae y dice 'no', no llames a nadie en 4 minutos".
  • ¿Qué pasa si la persona se cae Y hay humo al mismo tiempo? El robot se quedaría congelado pensando.
• La solución: Usamos herramientas matemáticas (como un juez muy estricto) para encontrar estos conflictos y arreglarlos antes de que el robot se confunda.

4. Programar al Robot (Implementación)

Ahora que las reglas son perfectas, las metemos en el cerebro del robot.

• Entrenamiento: Le enseñamos al robot ejemplos de situaciones donde siguió las reglas y donde las rompió.
• Guardianes de Seguridad: Ponemos un "guardia" en el sistema que vigila al robot en tiempo real. Si el robot intenta hacer algo prohibido (como llamar a emergencias sin permiso cuando no es necesario), el guardia lo detiene.

5. El Examen Final (Verificación)

Antes de soltar al robot en la casa de alguien, le hacemos una prueba final.

• Analogía: Es como el examen de conducir. Le ponemos situaciones difíciles (simuladas) para ver si cumple las reglas.
• Resultado: Si pasa, ¡se licencia y puede trabajar! Si falla, el proyecto se cancela. Es mejor cancelar un robot peligroso que soltarlo a la calle.

¿Por qué es importante esto?

El artículo nos dice que no podemos simplemente "esperar" a que los robots sean buenos por arte de magia. Necesitamos ingenieros, abogados, éticos y usuarios trabajando juntos.

Los retos que quedan:

• El idioma: Los ingenieros hablan de "código" y los abogados de "leyes". Necesitan aprender a hablar el mismo idioma.
• El tiempo: Las reglas humanas son lentas (puedes pensar un día antes de actuar), pero los robots son rápidos (milisegundos). ¿Cómo hacemos que un robot respete un proceso lento en un instante?
• El cambio: Las normas cambian. Lo que es aceptable hoy, quizás no lo sea mañana. Los robots necesitan poder aprender nuevas reglas sin tener que ser reprogramados desde cero.

En resumen

Este paper es un plan de construcción para que la Inteligencia Artificial no sea solo "inteligente", sino también buena, justa y respetuosa. Es como pasar de decirle a un niño "sé bueno" a darle una lista de reglas claras, explicarle por qué existen, probar que las entiende y asegurarnos de que las sigue antes de dejarlo solo en la casa.

Si logramos hacer esto, podremos tener robots que no solo nos ayuden a cocinar pasta, sino que lo hagan respetando nuestra dignidad, nuestra cultura y nuestras leyes.

Resumen técnico

A continuación presento un resumen técnico detallado del artículo "Operationalisation for AI Agents: Social, Legal, Ethical, Empathetic and Cultural Norm" (Operacionalización de Normas SLEEC para Agentes de IA), basado en el texto proporcionado.

1. El Problema

La integración de agentes de Inteligencia Artificial (IA) en dominios de alto riesgo (salud, aplicación de la ley, transporte) plantea un desafío crítico: alinear el comportamiento de estos agentes con normas SLEEC (Sociales, Legales, Éticas, Empáticas y Culturales).

• La Brecha: Aunque existen marcos internacionales (OECD, UNESCO, IEEE) que establecen principios normativos de alto nivel (ej. privacidad, autonomía, dignidad), existe una desconexión significativa entre estos principios abstractos y los requisitos técnicos concretos y verificables necesarios para implementar un agente de IA.
• Limitaciones de los Métodos Actuales: Las ingenierías de requisitos y sistemas tradicionales carecen de mecanismos para:
  • Involucrar a una amplia gama de partes interesadas (técnicos y no técnicos).
  • Manejar conflictos sutiles inherentes a las normas.
  • Garantizar la "bienformidad" (well-formedness) de los requisitos normativos.
  • Verificar el cumplimiento de estas normas antes del despliegue.
• Riesgo: Sin una operacionalización rigurosa, los agentes pueden tomar decisiones que prioricen valores incorrectos (ej. precisión sobre privacidad) o violar derechos humanos, sin que exista un método sistemático para prevenirlo.

2. Metodología: El Proceso de Operacionalización SLEEC

Los autores proponen un proceso sistemático de cinco etapas (ilustrado en la Figura 1 del artículo) para transformar principios abstractos en requisitos verificables. El proceso es iterativo; el fallo en cualquier etapa detiene el despliegue del agente.

Entrada del Proceso

Se basa en un corpus de principios, estándares y regulaciones (ej. Reglamento de IA de la UE, GDPR, principios de la UNESCO) que definen el paisaje normativo.

Etapa 1: Especificación de Capacidades del Agente

• Objetivo: Definir las capacidades funcionales del agente (sensores, actuadores, APIs) que influyen en las normas SLEEC.
• Doble enfoque:
  1. Identificar capacidades que generan implicaciones normativas (ej. una cámara implica riesgos de privacidad).
  2. Identificar capacidades necesarias para satisfacer las normas (ej. un canal de comunicación para solicitar ayuda si se detecta una caída).
• Salida: Una lista de capacidades informales y casos de uso.

Etapa 2: Elicitación de Requisitos SLEEC

• Objetivo: Traducir principios abstractos en reglas operativas accionables.
• Método: Involucra a múltiples partes interesadas (éticos, abogados, desarrolladores, usuarios) para:
  1. Identificar principios de alto nivel.
  2. Derivar "proxies" normativos (indicadores medibles de un valor, ej. "consentimiento" como proxy de "autonomía").
  3. Definir reglas en un Lenguaje Específico de Dominio (DSL) SLEEC.
• Estructura de la Regla SLEEC:
  id when triggerEvent [and triggerGuard] then response [within timeframe]
  • Incluye defeaters (excepciones): unless defeaterGuard [then defeaterResponse]. Si la condición del defeater es verdadera, la regla base no se aplica o se aplica una respuesta alternativa.

Etapa 3: Verificación de Bienformidad (Well-Formedness Checking)

• Objetivo: Detectar y resolver problemas en el conjunto de reglas (conflictos, redundancias, insuficiencia, sobre-restricción).
• Herramientas Formales:
  1. Método de Álgebra de Procesos: Mapea reglas a tock-CSP (álgebra de procesos secuenciales comunicantes con tiempo). Usa el verificador FDR para detectar conflictos y redundancias.
  2. Método Lógico (FOL):* Codifica el conjunto de reglas en lógica de primer orden con objetos relacionales. Usa el verificador de satisfacibilidad LEGOS para analizar interacciones globales, asegurando que el sistema no sea demasiado restrictivo ni insuficiente para evitar comportamientos indeseables.
• Resultado: Un conjunto de reglas depurado y formalmente validado.

Etapa 4: Implementación Consciente de SLEEC

• Objetivo: Integrar los requisitos validados en el diseño, entrenamiento y despliegue.
• Estrategia:
  • Entrenamiento: Los esquemas de datos se estructuran para codificar explícitamente situaciones que cumplen o violan las reglas SLEEC.
  • Tiempo de Ejecución (Runtime): Las reglas se implementan como guardarraíles (guardrails) que monitorean las percepciones y decisiones del agente. Estos guardarraíles son desacoplados de la lógica central del agente, permitiendo actualizaciones sin reentrenamiento completo.

Etapa 5: Verificación de Cumplimiento

• Objetivo: Verificar formalmente que el agente implementado cumple con el conjunto de reglas SLEEC.
• Técnica: Utiliza RoboChart (un lenguaje de modelado con semántica tock-CSP) y herramientas de verificación de modelos.
• Concepto Clave: Una noción de "conformidad" extendida que distingue entre capacidades para la misión y capacidades para la percepción del entorno. Si se detecta una violación, se genera un contraejemplo (trace) para corregir el diseño.

Salida del Proceso: Despliegue del agente (si todo se valida) o cancelación del proyecto (si no es posible cumplir las normas con la tecnología actual).

3. Contribuciones Clave

1. Marco de Operacionalización SLEEC: Un proceso integral de 5 etapas que cierra la brecha entre principios éticos abstractos y requisitos de ingeniería verificables.
2. Lenguaje y Herramientas Específicas: Propuesta del DSL SLEEC y el uso de herramientas formales (SLEEC-TK, LEGOS-SLEEC, RoboChart) para el análisis de conflictos y verificación de cumplimiento.
3. Mecanismo de Defeaters: Introducción formal de excepciones (defeaters) en las reglas para manejar conflictos de valores y contextos dinámicos (ej. priorizar la seguridad sobre la autonomía en caso de emergencia).
4. Enfoque Iterativo y de Cancelación: Reconocimiento de que la no viabilidad de cumplir normas es un resultado válido y positivo, evitando el despliegue de agentes no éticos.
5. Estudio de Caso (ALMI): Aplicación práctica del marco en un robot de asistencia para el cuidado (proyecto ALMI), demostrando la detección y resolución de conflictos reales (ej. conflicto entre llamar a emergencias por una caída vs. respetar la negativa del usuario).

4. Resultados y Ejemplos (Caso ALMI)

El artículo demuestra la eficacia del proceso mediante el robot de asistencia ALMI:

• Detección de Conflictos: Se identificó un conflicto entre la regla de llamar a emergencias por humo (R2) y la regla de no llamar si el usuario no consiente tras una caída (R3). El análisis formal sugirió ajustar los tiempos de espera para resolverlo.
• Detección de Sobre-restricción: Se descubrió que la regla original prohibía llamar a emergencias si el usuario no consentía, lo cual era peligroso si el usuario estaba inconsciente. Se refinó la regla (R3') para incluir una verificación de "responsividad" del usuario.
• Verificación de Cumplimiento: Se utilizó un modelo RoboChart para demostrar que una implementación inicial fallaba en cumplir el límite de tiempo de 4 minutos para llamar a emergencias debido a la priorización de tareas no críticas, generando un contraejemplo que obligó a rediseñar la lógica de interrupción.

5. Significado y Desafíos Abiertos

Significado:
El trabajo establece una agenda de investigación y política fundamental para el desarrollo de agentes de IA que no solo sean funcionales, sino demonstrablemente alineados con los valores humanos. Proporciona un método riguroso para pasar de la teoría ética a la práctica de ingeniería, permitiendo la certificación de sistemas de IA en dominios críticos.

Desafíos Abiertos (Open Challenges):

• Reificación de Principios: Dificultad para mapear principios globales abstractos a especificaciones técnicas concretas para dominios específicos.
• Ambigüedad y Conflictos de Valores: La necesidad de métodos deliberativos para resolver disputas entre partes interesadas y definir jerarquías de valores cuando los principios entran en conflicto.
• Ingeniería de Agentes SLEEC: Retos técnicos en trazabilidad (mapeo alto-bajo nivel), gestión de escalas temporales (consentimiento a largo plazo vs. decisiones de milisegundos) y capacidad computacional.
• Adaptación en Tiempo de Ejecución: La dificultad de permitir que los agentes adapten sus normas a contextos culturales o individuales no vistos durante el entrenamiento, manteniendo garantías formales.
• Competencia Normativa y de IA: La necesidad de formación multidisciplinaria para que ingenieros, reguladores y expertos en ética compartan un lenguaje común y eviten requisitos técnicamente inviables o éticamente deficientes.

En conclusión, el artículo propone que la única vía para garantizar la confianza en la IA de alto riesgo es mediante un proceso de operacionalización formal, iterativo y verificable que integre las normas SLEEC en el ciclo de vida completo del desarrollo del agente.