Cómo detectar daños invisibles en sistemas de IA

Alguien pide recetas bajas en azúcar a un chatbot. Sin saberlo, el sistema infiere una condición de salud, esa señal viaja por el ecosistema de datos y termina influyendo en el precio de un seguro. La persona nunca supo que compartió datos médicos, nunca apareció en ninguna lista de afectados y, sin embargo, fue perjudicada. Ese tipo de daño invisible es exactamente lo que se puede aprender a detectar con un marco de tres preguntas simples pero poderosas: ¿a quién afecta?, ¿qué daño puede ocurrir? y ¿quién responde? [0:08]

¿Quiénes son las personas afectadas por un sistema de IA?

Cada vez que un sistema toca datos o involucra un modelo de lenguaje grande (LLM), hay cinco capas de personas afectadas que deben identificarse [1:02]:

• Usuarios directos: quienes interactúan con el sistema a propósito, como el empleado que abre un chatbot.
• Usuarios finales: quienes reciben el impacto sin haber tocado nada, por ejemplo un paciente cuyo diagnóstico fue sugerido por una IA que nunca eligió.
• Terceros: personas cuyos datos aparecen sin relación directa, como autores de textos usados para entrenar un modelo sin consentimiento.
• Organizaciones: quienes despliegan el sistema; aunque no lo hayan construido, cargan con la responsabilidad.
• La sociedad: un modelo que discrimina por código postal no genera un daño individual, genera un daño estructural.

Para aterrizar esto, cuatro preguntas son clave: quién provee los datos, quién recibe el resultado, quién podría ser dañado si el modelo se equivoca y —la más incómoda— quién no tiene voz en este proceso [1:50]. Suelen ser grupos marginados, personas con baja alfabetización digital y culturas subrepresentadas. El patrón se repite: son los más afectados y los menos visibles.

¿Qué tipos de daño puede provocar un sistema?

Dentro de los daños directos se encuentran la pérdida financiera por filtración, la violación de privacidad, el daño reputacional (como un deep fake) e incluso el daño físico [2:26]. Los daños indirectos son igual de graves: la gente deja de compartir información, la discriminación se acumula con el tiempo y la confianza en las instituciones se erosiona.

¿Quién es responsable cuando algo sale mal?

La analogía es clara: en un accidente de auto no se culpa al vehículo, sino al conductor, al fabricante o a la autoridad [2:50]. Con la IA funciona igual:

• Quien recopiló los datos responde por sesgos.
• Quien desplegó el modelo responde por su comportamiento.
• Quien decidió usarla responde por el contexto.

La IA no es responsable. Las decisiones humanas, sí.

¿Cuáles son los tres riesgos que se esconden detrás de un fallo?

Muchos equipos dicen "falló el modelo", pero en realidad existen tres riesgos distintos [3:18]:

• Riesgo de modelo: errores técnicos, como un reconocimiento facial que identifica mal. Se mejora con datos, entrenamiento y testing.
• Riesgo de producto: decisiones de diseño incorrectas. Por ejemplo, escanear a toda persona en un espacio público. El modelo puede funcionar perfecto y el sistema seguir siendo injusto.
• Riesgo de proceso: el más silencioso. Datos mal etiquetados, evaluación débil, despliegue sin control y monitoreo inexistente. Cada etapa débil multiplica el daño en la siguiente.

¿Cómo documentar riesgos de forma práctica y verificable?

Imagina que vas a lanzar un chatbot de recursos humanos. Necesitas redactar una nota de riesgos de aproximadamente una página, como una etiqueta de medicamento [4:06]. Debe incluir:

• Nombre, versión y uso previsto.
• Nivel de riesgo y datos utilizados, incluyendo si hay datos sensibles.
• Riesgos identificados, población afectada y controles.
• Riesgo residual, cumplimiento y un dueño con nombre y fecha.

Cada riesgo documentado necesita cuatro partes [4:30]: un riesgo claro y concreto (por ejemplo: "el chatbot podría mostrar el salario de un empleado en respuesta a otro"), el daño especificando quién se ve afectado y qué tan grave es, un dueño con nombre y apellido —no un equipo genérico— y un control medible. No sirve decir "revisamos el modelo y parece justo"; lo correcto es informar algo como: "paridad demográfica 0,97, T sobre 5.000 registros, auditado el 15 de abril" [5:10].

Un dato crítico sobre privacidad: muchos sistemas usan datos de chat para entrenamiento por defecto. Lo que el usuario escribe se captura, se almacena —a veces sin expiración— y puede filtrarse en respuestas [5:26]. Como regla simple: trata todo lo que entra a un chatbot como si fuera público.

Antes de avanzar con cualquier proyecto, tres preguntas deben tener respuesta afirmativa: ¿está claro qué puede salir mal y a quién afecta?, ¿hay un responsable con nombre y apellido?, ¿hay un control concreto? Si falta una, no se avanza [5:42].

Ahora te queda un ejercicio concreto: piensa en un chatbot interno para empleados que puede responder sobre salarios, evaluaciones de desempeño e historial laboral. Identifica al menos dos riesgos concretos, define a quién afectan y propone un control verificable. Comparte tu análisis o un caso real en los comentarios.