Responsabilidad sobre resultados de IA: revisión humana y aceptación

El reparto concreto lo fija el contrato, pero estas son las piezas que suelen estar bajo el control de cada actor. Sirven como guía para no dejar huecos.

La última columna importa tanto como la segunda. Si el sistema presenta a la persona revisora una propuesta sin el documento de origen, esa persona no puede comprobarla de verdad, y su firma tiene poco valor como control. El diseño de la interfaz forma parte del reparto de responsabilidades.

Aceptar un sistema con IA no puede consistir en probar diez ejemplos en una reunión. Hace falta acordar antes, por escrito, cómo se medirá y qué resultado se considera suficiente para el uso previsto. Un esquema que funciona bien tiene cinco elementos:

1. Definición de la tarea: qué entra, qué debe salir y qué queda explícitamente fuera.
2. Conjunto de evaluación: casos reales o realistas, preparados con el cliente, que incluyan los difíciles y los poco frecuentes, no solo los típicos.
3. Métricas por tipo de error: no cuesta lo mismo clasificar mal una consulta comercial que pasar por alto una reclamación con plazo legal. Cada tipo de error puede tener su propio umbral.
4. Umbrales y condiciones: qué valores se exigen y qué ocurre si no se alcanzan (más trabajo, más supervisión o renunciar a automatizar esa parte).
5. Reaceptación: qué cambios obligan a repetir la evaluación, como una nueva versión del modelo, otro proveedor, un cambio relevante en las instrucciones o en el tipo de documentos.

Las cifras concretas dependen de cada caso y no tiene sentido fijarlas de antemano en una guía. Lo importante es que se acuerden con datos del propio proceso y que el cliente entienda qué significan: un umbral alto en promedio puede esconder un comportamiento pobre en la categoría que más importa.

La revisión humana no es un interruptor que se enciende o se apaga. Hay varios niveles, y elegir uno es una decisión de diseño que depende de cuánto cuesta un error, de si es reversible y de si afecta a personas.

Cuando el sistema interviene en decisiones sobre personas, hay que analizar el artículo 22 del Reglamento general de protección de datos, que reconoce el derecho a no ser objeto de decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos o afecten significativamente, con excepciones en las que el responsable debe ofrecer como mínimo el derecho a obtener intervención humana, a expresar el punto de vista y a impugnar la decisión. Además, puede aplicarse normativa específica sobre IA o del sector, cuya valoración corresponde a la empresa usuaria con su asesoría.

Un riesgo conocido de cualquier nivel con revisión es que las personas acaben aprobando por inercia lo que propone el sistema. Ayuda mostrar la evidencia junto a la propuesta, medir cuántas propuestas se corrigen y formar a quien revisa en los fallos típicos del sistema.

Sin registro no hay forma de saber, semanas después, por qué se tomó una decisión ni de quién fue. Un registro útil permite reconstruir cada caso relevante:

• Entrada recibida o una referencia a ella, y el contexto que se entregó al modelo.
• Versión del modelo, de las instrucciones y de las reglas aplicadas en ese momento.
• Resultado propuesto por el sistema y, si existe, su indicador de confianza.
• Quién revisó, qué decidió y, si modificó la propuesta, el motivo.
• Momento de cada paso y acción ejecutada en otros sistemas.

El registro también contiene datos y debe tratarse como tal: plazos de conservación proporcionados, acceso restringido y, si incluye datos personales, la misma protección que el resto del sistema.

Conviene definir qué se considera incidente antes de que ocurra: un error con consecuencias externas, una degradación sostenida de las métricas, una respuesta que revela información a quien no debía verla o un cambio no anunciado en el comportamiento del proveedor. Para cada uno, el procedimiento debería prever:

• Detección: alertas sobre métricas, tasa de correcciones y avisos de usuarios.
• Contención: poder desactivar la función o pasar a revisión total sin detener el proceso de negocio.
• Análisis: reconstruir los casos afectados gracias al registro.
• Corrección y reaceptación: ajustar, volver a evaluar y documentar el resultado.
• Comunicación: quién avisa a quién, en qué plazo, y qué obligaciones legales de notificación pueden aplicar, que corresponde valorar a la empresa usuaria.

• Descripción funcional del componente de IA y sus limitaciones conocidas, por escrito.
• Criterios de aceptación, conjunto de evaluación y condiciones de reaceptación.
• Nivel de supervisión previsto para cada tipo de resultado y obligaciones de cada parte para que funcione.
• Contenido y conservación del registro de decisiones.
• Mantenimiento ante cambios del modelo o del proveedor y procedimiento de incidentes.
• Límites de responsabilidad negociados de forma equilibrada y dentro de lo que permita la ley, sin exclusiones generales.

1. ¿Está claro qué pieza controla cada actor y no queda ninguna sin responsable?
2. ¿Hay criterios de aceptación medibles con datos del propio proceso y condiciones de reaceptación?
3. ¿El nivel de supervisión es proporcional al coste y reversibilidad del error?
4. ¿Recibe la persona revisora la información necesaria para comprobar de verdad?
5. ¿Permite el registro reconstruir cualquier decisión relevante?
6. ¿Existe un procedimiento de incidentes que incluya desactivar la IA sin parar el negocio?

Responder a estas preguntas antes de desarrollar evita discusiones sobre responsabilidad cuando ya hay un problema. Si estás valorando incorporar IA a un proceso, podemos ayudarte a definir la tarea, el conjunto de evaluación y los puntos de revisión como parte del análisis inicial.