Practicas de IA prohibidas: Guia practica para equipos SaaS

Las practicas de IA prohibidas son usos de AI que un equipo SaaS debe bloquear antes de que lleguen a clientes, empleados, vendors o procesos internos. El Article 5 del EU AI Act cubre una lista limitada de usos inaceptables: manipulacion perjudicial, explotacion de vulnerabilidades, ciertos tipos de social scoring, algunos usos de prediccion penal, scraping no dirigido de imagenes faciales, emotion recognition en trabajo y educacion, categorizacion biometrica sensible e identificacion biometrica remota en tiempo real para law enforcement salvo excepciones estrechas.

La respuesta practica no es esperar a que legal revise un feature terminado. El equipo debe tener un filtro previo al lanzamiento que pregunte si el caso de uso puede caer en una categoria prohibida, bloquee los casos evidentes, escale los dudosos y conserve evidencia de la decision. Ese filtro debe cubrir features de producto, herramientas internas, vendors embebidos, integraciones de modelos y automatizaciones configurables por clientes.

Por que importa

El screening de practicas prohibidas es la puerta de entrada de AI governance. Si un uso esta prohibido, no tiene sentido crear controles normales alrededor de el. La respuesta correcta es parar, redisenar, limitar el caso o escalar antes de que el trabajo quede dentro del roadmap o de un compromiso comercial.

En SaaS, la AI entra de forma incremental: nudges de producto, scoring de cuentas, analisis de empleados, vendor tools o funcionalidad biometrica dentro de plataformas ya usadas. Cada cambio puede parecer pequeno, pero puede alterar el perfil regulatorio y etico del servicio.

Que revisar

Convierta Article 5 en preguntas operativas. Pregunte si el sistema usa tecnicas ocultas, manipuladoras o enganosas que puedan alterar una decision y causar dano significativo. Pregunte si explota vulnerabilidades por edad, discapacidad o situacion social o economica. Revise si evalua personas entre contextos, si hace scoring social, si predice riesgo penal solo por profiling o rasgos personales, si crea bases de facial recognition desde scraping, si infiere emociones en trabajo o educacion, si usa biometria para inferir rasgos sensibles o si habilita identificacion biometrica remota en espacios publicos.

No basta mirar el nombre del modelo. Revise uso, contexto, datos, personas afectadas y efecto del output.

Workflow practico

Incluya una pregunta de AI en product review, vendor review, security review, privacy review e internal tool approval. No pregunte solo si algo esta prohibido. Pregunte que hace el sistema, a quien afecta, que datos usa, si influye decisiones, si hay biometria, si infiere emociones, si hay usuarios vulnerables y si el caso toca empleo, educacion, credito, servicios esenciales, law enforcement o seguridad publica.

Despues enrute la respuesta. Los "no" claros pueden pasar a clasificacion ordinaria y risk review. Los "si" claros deben detenerse hasta que legal y compliance aprueben un rediseño o confirmen que el caso queda fuera de la prohibicion. Las respuestas inciertas deben ir a un reviewer nombrado.

Use una plantilla de decision con sistema, owner, vendor, finalidad, personas afectadas, datos, geografia, rol bajo el AI Act, preguntas de Article 5, conclusion, razon, cambios requeridos, aprobador y trigger de nueva revision.

Evidencia

Conserve el intake, descripcion del producto o vendor, nota de data flow, analisis de usuarios afectados, screenshots o configuracion, decision, razon, reviewer, fecha y acciones de rediseño. Si hay vendor, guarde su documentacion de AI, compromisos contractuales y respuestas sobre biometria, emotion recognition, profiling, entrenamiento de modelos y manipulacion de usuarios.

La evidencia debe mostrar tambien cuando se reabrira la decision: cambio de finalidad, nuevo grupo de usuarios, nuevo mercado, nuevas fuentes de datos, cambios en revision humana, configuracion por cliente o nueva guia regulatoria.

Errores comunes

El primer error es revisar demasiado tarde. Cuando el feature ya esta listo, el diseno, contrato, mensaje comercial y engineering pueden depender de una premisa equivocada. El segundo es revisar solo lo customer-facing. Herramientas internas tambien importan si afectan trabajadores, candidatos, training, productividad, fraude, soporte o seguridad.

El tercero es confiar en labels del vendor como "insight", "sentiment", "safety" o "personalization". La pregunta real es que hace el sistema y como afecta a personas. El cuarto es creer que human in the loop lo resuelve todo. Puede ayudar, pero no arregla un uso construido sobre manipulacion prohibida o inferencia biometrica sensible.

FAQ

Cual es el proposito practico?

Identificar usos de AI que deben bloquearse, redisenarse o escalarse antes de entrar en producto, vendor workflow o proceso interno.

Cuando aplica a SaaS?

Cuando el equipo crea, compra, embebe, vende, configura o usa AI que puede tocar categorias de Article 5.

Que documentar primero?

Un intake, una decision, un reviewer nombrado y un launch gate conectado con producto, vendor, privacy, security y customer trust.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidelines on prohibited artificial intelligence practices.
• European Commission studies on Article 5 of the AI Act.