Riesgos de la inteligencia artificial en la empresa: privacidad, sesgos y dependencia

La inteligencia artificial puede acelerar tareas, ampliar la capacidad analítica y facilitar nuevas formas de servicio. Pero su incorporación no convierte automáticamente una decisión en mejor ni elimina la responsabilidad de quien la utiliza. En una empresa, el riesgo aparece cuando una herramienta trabaja con información sensible sin control, reproduce desigualdades, induce a confiar demasiado en resultados plausibles o se vuelve tan central que la actividad no puede continuar cuando falla. El reto directivo no consiste en rechazar la tecnología ni en adoptarla por inercia: consiste en delimitar para qué se usa, quién responde y cómo se detectan consecuencias no deseadas.

Hablar de riesgos de la inteligencia artificial en empresas exige distinguir entre la herramienta, el caso de uso y el contexto. Un asistente que propone borradores internos no presenta la misma exposición que un sistema que interviene en la selección de personal, la evaluación de crédito o el acceso a servicios. La misma solución puede ser razonable en una tarea y problemática en otra. Por eso, las medidas sensatas comienzan con un inventario de usos y no con una política genérica que trate cada aplicación como si tuviera el mismo impacto.

El riesgo empieza con la finalidad, no con la etiqueta

La regulación europea adopta un enfoque basado en riesgos y determina la clasificación atendiendo a la finalidad prevista y a la forma concreta de uso. La Comisión Europea cita como casos potencialmente de alto riesgo, entre otros, determinados sistemas utilizados en empleo, educación, servicios esenciales y evaluación de solvencia. También recuerda que muchas aplicaciones se encuentran en categorías de menor riesgo regulatorio. Esto no significa que las de menor riesgo estén exentas de toda obligación: la legislación aplicable puede depender de los datos, del sector y del efecto de la decisión.

Una evaluación interna puede empezar con preguntas sencillas: ¿qué tarea se quiere mejorar?, ¿quién recibirá el resultado?, ¿qué decisión podría cambiar?, ¿qué información se aportará?, ¿qué sucede si el sistema se equivoca? Conviene registrar la respuesta y asignar una persona responsable. Cuando la finalidad es ambigua, hay que aclararla antes de probar la herramienta con datos reales. El piloto debe tener alcance, plazo, usuarios autorizados y criterios para detenerse. De lo contrario, un experimento informal puede convertirse en un proceso operativo sin que nadie haya evaluado sus efectos.

Privacidad: controlar los datos antes de introducirlos

El primer riesgo práctico suele ser menos sofisticado de lo que parece: alguien pega en un servicio externo un contrato, una ficha de cliente, una nómina o una conversación que no debería salir del entorno autorizado. La comodidad de una interfaz no aclara por sí sola quién puede acceder a los datos, cuánto tiempo se conservan, si se utilizan para otros fines o qué controles contractuales existen. La empresa necesita conocer las condiciones del servicio elegido, la configuración disponible, las ubicaciones y los flujos de información antes de decidir qué información puede tratar allí.

Clasificar la información ayuda a convertir una advertencia abstracta en una regla operativa. Por ejemplo, la organización puede diferenciar datos públicos, información interna, información confidencial y datos personales o especialmente delicados. Para cada nivel debe decidir qué herramientas están aprobadas, quién puede usarlas y qué medidas de minimización aplicar. El principio operativo es utilizar solo los datos necesarios para la tarea. Si una consulta puede resolverse con un caso sintético o con campos sustituidos, no hace falta incluir nombres, direcciones ni detalles identificativos.

También hay que separar la legitimidad de la finalidad de la mera disponibilidad técnica. Que un sistema permita cargar un archivo no demuestra que sea adecuado hacerlo. Deben revisarse la base y el propósito del tratamiento, los permisos, el acceso interno, la conservación y la posibilidad de atender derechos o corregir información. Cuando se tratan datos personales, la organización debe integrar el análisis con sus obligaciones de protección de datos y con las instrucciones de su responsable de privacidad. Ante un caso de alto impacto o dudas sobre el tratamiento, procede consultar a especialistas antes del despliegue, no después de una reclamación.

Sesgos: un resultado promedio puede ocultar daños concentrados

Un modelo no necesita recibir una variable explícitamente sensible para producir diferencias injustificadas. Puede apoyarse en variables relacionadas, en datos históricos que reflejen prácticas desiguales o en muestras poco representativas del grupo sobre el que se aplica. Una media de aciertos aparentemente aceptable no revela necesariamente cómo rinde para perfiles menos frecuentes. En selección, por ejemplo, una recomendación puede penalizar trayectorias distintas de las que aparecen con mayor frecuencia en los datos, aunque el sistema nunca pregunte directamente por una característica protegida.

El artículo 10 del Reglamento europeo de IA establece, para los sistemas de alto riesgo, requisitos sobre gobernanza de datos, relevancia y representatividad, examen de posibles sesgos y medidas para detectarlos, prevenirlos y mitigarlos. La propia norma presta atención al contexto geográfico, conductual y funcional de utilización. Para una empresa, la consecuencia práctica es que la calidad no se reduce a que los datos estén completos o técnicamente limpios: también importa si son adecuados para la finalidad y la población afectada.

Una revisión responsable compara errores y resultados por grupos pertinentes cuando sea lícito y metodológicamente válido, documenta las limitaciones de la muestra y analiza los casos difíciles. No se trata de buscar un único indicador que certifique que todo es justo. El examen debe valorar la elección del objetivo, las variables disponibles, los errores de clasificación y la forma en que las personas pueden corregir o cuestionar una decisión. Si no existe una forma legítima de medir diferencias, esa limitación debe quedar registrada y compensarse con controles alternativos, pruebas cualitativas y revisión humana.

Dependencia: el coste oculto de dejar de poder decidir

La dependencia aparece cuando el equipo ya no conserva el conocimiento para revisar el trabajo del sistema, cuando un proveedor concentra una función crítica o cuando los procesos se diseñan alrededor de una herramienta sin alternativa. Puede afectar a la continuidad, a la negociación y a la capacidad de cambiar de solución. También es cognitiva: si los profesionales aceptan por defecto cada respuesta, dejan de comprobar premisas, cálculos y excepciones. Una recomendación convincente no equivale a una explicación verificable ni a una decisión autorizada.

Para reducir esa exposición, hay que conservar procedimientos alternativos proporcionales a la importancia de la tarea. Definir un modo manual de contingencia, exportar los datos necesarios en formatos utilizables y documentar el flujo operativo son medidas sencillas que evitan que una interrupción técnica se convierta en una crisis de servicio. Es razonable probar qué ocurriría ante una caída, una modificación de precios, un cambio de condiciones o la terminación del contrato. La salida debe incluir qué datos se recuperan, quién los valida y qué tareas se reanudan primero.

El conocimiento también necesita redundancia. Quienes utilizan la herramienta deben comprender la tarea que esta apoya, conocer sus límites y poder explicar cuándo no seguir una recomendación. Formar a un pequeño grupo de especialistas internos y compartir criterios de revisión reduce la dependencia de una persona concreta. La organización no necesita replicar la tecnología; necesita mantener el juicio suficiente para cuestionarla, cambiarla o prescindir de ella sin perder el control del proceso.

Un sistema de gestión que aprende del uso

El artículo 9 del Reglamento europeo exige para los sistemas de alto riesgo un proceso de gestión de riesgos continuo, documentado y revisado durante su ciclo de vida. Incluye identificar y evaluar riesgos previsibles, atender al uso incorrecto razonablemente previsible, aplicar medidas dirigidas y comprobar el comportamiento frente a métricas definidas. Aunque una empresa no sea proveedora de un sistema de alto riesgo, la lógica de trabajo resulta útil para gobernar usos internos: evaluar antes, supervisar durante y revisar después, ajustando controles cuando cambien los datos, la finalidad o el entorno.

La primera ficha de un uso debería recoger propietario del proceso, proveedor, finalidad, usuarios, datos tratados, personas afectadas, consecuencias de error y controles disponibles. A continuación se puede clasificar la exposición como baja, media o alta según el daño potencial, la escala, la reversibilidad y la sensibilidad de la información. Esa clasificación no sustituye un análisis jurídico, pero ayuda a priorizar recursos. Un borrador de comunicación interna puede necesitar controles distintos de una recomendación que influya en la contratación o en un servicio esencial.

Antes de escalar una prueba, conviene comparar el resultado con un proceso de referencia, probar ejemplos límite y pedir a usuarios competentes que documenten cuándo corrigen la salida. Definir un umbral de aceptación no significa buscar un número universal; significa anticipar qué errores serían inaceptables para esa tarea. El seguimiento posterior debe incluir incidencias, reclamaciones, cambios de versión, degradación de resultados y excepciones. Una reunión periódica de revisión puede decidir mantener, restringir, corregir o retirar el uso, y dejar constancia del motivo.

La supervisión humana debe tener capacidad real

La frase «hay una persona en el circuito» no constituye por sí misma una salvaguarda. La persona debe conocer el objetivo, recibir información suficiente, disponer de tiempo y autoridad para apartarse de la recomendación y comprender en qué casos la revisión es obligatoria. Si el proceso mide al profesional solo por velocidad, si el resultado se presenta como certeza o si nadie puede explicar el sistema, la intervención humana corre el riesgo de convertirse en una formalidad.

Es preferible asignar derechos claros: quién aprueba el uso, quién configura el sistema, quién evalúa datos y resultados, quién gestiona incidentes y quién suspende la actividad. La respuesta también debe prever a las personas afectadas: cómo se corrige un dato, se revisa una salida y se presenta una queja. Cada excepción merece una ruta de escalado que no dependa de la buena voluntad de quien está utilizando la herramienta ese día. La empresa conserva la responsabilidad sobre el proceso que organiza; no la transfiere al software por contratarlo.

Decidir con prudencia, no con miedo

Una política útil explica qué usos están permitidos, qué información no debe introducirse, qué controles se requieren y cómo solicitar una excepción. Debe ofrecer una vía autorizada para experimentar con seguridad, porque la prohibición total puede desplazar el uso hacia canales invisibles. A la vez, no basta con una sesión de formación inicial: los casos de uso, servicios y reglas cambian, así que la política debe revisarse y comunicarse de forma comprensible.

La dirección puede plantear una pregunta más estratégica que «¿qué herramienta deberíamos comprar?»: ¿qué capacidad queremos mejorar sin perder control sobre los datos, el criterio y la continuidad? La respuesta puede ser automatizar una tarea limitada, rediseñar primero el proceso, mantener la decisión en manos humanas o no utilizar IA todavía. Esas opciones no representan grados de modernidad, sino diferentes ajustes entre beneficio, coste y riesgo.

La inteligencia artificial merece confianza cuando puede ser cuestionada y gobernada. Una empresa preparada no presume de eliminar todos los errores: identifica dónde podrían producirse, limita sus efectos y aprende de ellos. Privacidad, sesgos y dependencia no son apéndices técnicos que se resuelven al final del proyecto; son dimensiones de diseño que condicionan la viabilidad de una iniciativa. Si la organización mantiene responsables claros, pruebas proporcionales y capacidad de detener o cambiar el sistema, la tecnología puede servir a la estrategia en lugar de sustituirla.

Para profundizar en otra de las tecnologías que más preguntas plantea en las empresas, puedes leer qué son los agentes de IA y cuáles son sus límites.

Fuentes y referencias

• Comisión Europea, Navigating the AI Act.
• AI Act Service Desk de la Comisión Europea, Artículo 9: Sistema de gestión de riesgos.
• AI Act Service Desk de la Comisión Europea, Artículo 10: Datos y gobernanza de datos.