Decisiones automatizadas y perfilado en tu web/app: cómo no cruzar la línea roja del artículo 22 RGPD

Decisiones automatizadas y perfilado en tu web/app: cómo no cruzar la línea roja del artículo 22 RGPD

Durante años, muchas organizaciones han tratado el perfilado y las decisiones automatizadas como algo “lejano”, propio de bancos, aseguradoras o big tech. Pero la realidad es otra:
cada vez más sitios web y apps toman decisiones silenciosas sobre las personas:

• Qué contenido mostrar primero.

• Qué precio ofrecer.

• Qué solicitud priorizar… o ignorar.

• Qué usuario es “de riesgo” y debe someterse a más controles.

Si tu web o app hace cualquiera de estas cosas sin intervención humana real, estás entrando en el territorio del artículo 22 RGPD y de los sistemas de decisión automatizada (ADM).

Desde una mirada GRC (Gobernanza, Riesgo y Cumplimiento), esto no es solo un tema jurídico: es un tema de modelo de negocio, reputación y defensa regulatoria.

1. ¿Qué entendemos por “decisión automatizada” y “perfilado” en una web/app?

El RGPD define el perfilado como cualquier forma de tratamiento automatizado de datos personales para evaluar aspectos personales de una persona física (rendimiento, preferencias, intereses, fiabilidad, comportamiento, etc.).

En la práctica web/app, esto incluye, por ejemplo:

• Clasificar usuarios en segmentos de riesgo o valor.

• Asignar scoring (fraude, crédito, riesgo reputacional, comportamiento).

• Personalizar contenido, precios o límites de uso según comportamientos previos.

La decisión automatizada se produce cuando esa evaluación/profilado se usa para tomar decisiones que producen efectos jurídicos o les afectan de manera significativa (rechazar una solicitud, bloquear un servicio, limitar funcionalidades, aplicar condiciones menos favorables, etc.).

Cuando la decisión se toma “únicamente” por medios automatizados y entra en ese tipo de efectos, estamos en el terreno del art. 22 RGPD.

2. ¿Tu web o app está, de facto, tomando decisiones automatizadas?

Muchos responsables responden “no”… hasta que revisamos cómo funciona realmente el flujo:

1. Un sistema de scoring (motor de riesgo, motor de recomendaciones, regla de negocio compleja) se ejecuta completamente de forma automatizada.

2. El resultado de ese scoring decide:

   • si se muestra o no una oferta,

   • si se permite completar un proceso,

   • si se activa revisión manual o directamente se bloquea.

Si el resultado del algoritmo se aplica sin espacio real para que una persona revise, cuestione o modifique la decisión, estamos ante una posible decisión basada únicamente en tratamiento automatizado.

Los tribunales y autoridades han sido claros: no basta una “intervención humana cosmética” —la supervisión debe ser real, informada y con capacidad de cambiar el resultado.

3. La línea roja del artículo 22 RGPD (y por qué te importa aunque “no seas banco”)

El artículo 22 RGPD reconoce el derecho de toda persona a no ser objeto de una decisión basada únicamente en el tratamiento automatizado, incluida la elaboración de perfiles, que produzca efectos jurídicos sobre ella o le afecte significativamente de modo similar.

Esto implica que:

• Estas decisiones están prohibidas por defecto, salvo que se apoyen en:

  • un contrato necesario,

  • una autorización expresa del Derecho de la UE/Estado miembro, o

  • el consentimiento explícito de la persona.

• Y, aun en esos casos, deben existir salvaguardas reforzadas, entre ellas:

  • derecho a obtener intervención humana,

  • derecho a expresar su punto de vista,

  • derecho a impugnar la decisión,

  • explicaciones claras y comprensibles.

Para una web/app, esto se traduce en preguntas incómodas:

• ¿Estoy utilizando reglas o modelos que deciden automáticamente quién entra, quién compra, quién ve qué?

• ¿El usuario sabe que esto ocurre?

• ¿Tiene una forma realista y sencilla de pedir revisión humana y de impugnar el resultado?

4. Ejemplos típicos en sitios web y apps que se acercan al art. 22

Algunos patrones que vemos cada vez más:

• Sistemas antifraude que bloquean automáticamente pagos o registros online sin revisión humana previa.

• Motores de recomendación que no solo sugieren, sino que condicionan la disponibilidad de determinados productos u opciones.

• Scoring de comportamiento que activa medidas adicionales (KYC ampliado, restricciones, límites de gasto) sin que una persona revise el caso.

• Filtros automatizados de moderación de contenido, que eliminan publicaciones, comentarios o cuentas completas.

• Chatbots decisores, que admiten o rechazan solicitudes, o “cierran” incidentes sin pasar por un ser humano.

Si cruzas esto con datos sensibles, colectivos vulnerables o servicios esenciales, el riesgo jurídico y reputacional se dispara.

5. Mirada GRC: gobernar las decisiones automatizadas como un riesgo estratégico

Desde la óptica GRC, las decisiones automatizadas en tu web/app deberían tratarse como:

• Riesgos en el mapa corporativo (no solo “riesgo TI”).

• Procesos sujetos a políticas y estándares internos (no solo “experimentos de producto”).

• Objetos de auditoría periódica (no solo “cajas negras” que nadie toca).

Esto implica, como mínimo:

1. Inventariar los flujos de decisión automatizada

   • ¿Dónde, en qué pantallas, procesos y APIs se están tomando decisiones automatizadas?

   • ¿Qué datos se usan? ¿De qué fuentes vienen?

2. Clasificar el impacto

   • ¿La decisión tiene efectos jurídicos (aceptar/rechazar contrato, servicio, etc.)?

   • ¿Puede afectar significativamente al usuario (acceso, reputación, oportunidades económicas)?

3. Mapear responsabilidades

   • Responsable de tratamiento.

   • Encargados y subencargados (proveedores de scoring, motores de IA, plataformas cloud).

   • Equipos internos: producto, datos, legal, seguridad, auditoría interna.

6. Requisitos clave: transparencia, bases de licitud y EIPD/DPIA

Algunos elementos que no pueden faltar si tu web/app utiliza perfilado o decisiones automatizadas:

a) Transparencia reforzada

Más allá del típico “tratamos tus datos para mejorar el servicio”, deberías explicar:

• Que existe perfilado/ADM.

• Qué tipo de datos se utilizan (declarados, observados, inferidos, de terceros).

• Qué consecuencias puede tener para la persona (ej., ofertas limitadas, rechazo automático, revisión adicional).

• Posibilidad de solicitar explicación y revisión humana.

Idealmente, parte de esta información debe aparecer en el propio flujo de decisión (por ejemplo, cerca del botón de solicitud, del formulario o del chatbot), no enterrada solo en la política de privacidad.

b) Base jurídica robusta (y honesta)

• El interés legítimo no es un comodín si hay impacto significativo sobre la persona.

• En decisiones amparadas por el art. 22.2, a menudo necesitarás consentimiento explícito o una base jurídica específica en una norma.

• El contrato solo puede justificar la ADM si es realmente necesaria para su ejecución, no por comodidad del responsable.

c) Evaluación de impacto (EIPD/DPIA)

Cuando la ADM o el perfilado puedan implicar alto riesgo para derechos y libertades, la EIPD no es un “nice to have”, sino una obligación:

• Identificar bien la lógica y finalidades del sistema.

• Analizar sesgos, errores, falsos positivos/negativos y su impacto.

• Definir salvaguardas: revisión humana, logging, explicabilidad, canales de recurso.

• Documentar decisiones y trade-offs, por si una autoridad de control llama a la puerta.

7. Controles prácticos para webs y apps: checklist rápido

Si quieres empezar a bajar esto a la realidad de tu web/app, aquí tienes un mini-checklist:

• ¿He identificado todos los puntos donde se toman decisiones automatizadas sobre usuarios (incluyendo algoritmos de scoring, motores de reglas, IA en chatbots)?

• ¿Sé qué decisiones pueden producir efectos jurídicos o significativos?

• ¿He documentado los datos de entrada, la lógica básica y las posibles salidas del sistema?

• ¿Existe una intervención humana real (no meramente formal) en las decisiones de alto impacto?

• ¿El usuario está informado de forma clara de que existe perfilado/ADM y de sus consecuencias?

• ¿Tiene canales sencillos para pedir revisión humana y impugnar decisiones?

• ¿Se ha realizado una EIPD/DPIA cuando el riesgo lo exige y se ha integrado en el ciclo de vida del sistema?

• ¿Auditoría interna, CISO/DPO o terceros han revisado al menos alguna vez el sistema?

• ¿Los contratos con proveedores cubren su rol (responsable conjunto/encargado), la lógica del tratamiento y las obligaciones de soporte ante reclamaciones?

8. Conclusión: del “black box” al diseño responsable

Para muchas organizaciones, el gran riesgo no es tener modelos de IA o scoring muy sofisticados. El gran riesgo es no saber qué están decidiendo en la práctica, ni cómo explicarlo si la AEPD, la CNIL o cualquier otra autoridad lo pregunta.

La buena noticia es que el enfoque GRC te da un marco claro:

• Gobernanza: quién decide, quién revisa, quién responde.

• Riesgo: cómo clasificar y mitigar el impacto sobre personas y negocio.

• Cumplimiento: cómo demostrar –con documentación real– que has hecho los deberes.

El objetivo no es renunciar a la automatización, sino usarla con responsabilidad, transparencia y capacidad de rendir cuentas. Lo que hoy puede parecer “solo una regla de negocio” en tu web, mañana puede ser el centro de una investigación regulatoria… o de tu ventaja competitiva si lo haces bien.