Cada vez es más habitual que una empresa plantee una integración, una automatización o un sistema basado en Inteligencia Artificial y que, desde un punto de vista técnico, sea perfectamente viable. Sabemos qué herramientas utilizar, qué APIs conectar, cómo mover los datos entre sistemas y cómo conseguir que todo funcione.

Sin embargo, que algo se pueda hacer no significa automáticamente que deba hacerse de esa manera. Y esa diferencia, que puede parecer pequeña, empieza a ser cada vez más importante.

En muchos proyectos, de hecho, el verdadero problema no aparece en la tecnología, sino en todo lo que la rodea. Puede haber datos personales, información confidencial, decisiones que afectan a personas, accesos mal planteados, tratamientos de información sin suficientes garantías o procesos automatizados que necesitan supervisión.

En ese momento, la pregunta deja de ser únicamente si podemos construirlo y pasa a ser otra bastante más incómoda: ¿podemos construirlo bien?

Porque una solución puede ser técnicamente impecable y, al mismo tiempo, estar mal diseñada desde el punto de vista legal, organizativo o de responsabilidad.

«No lo hago» no significa «no sé hacerlo»

Hay una situación especialmente incómoda para quienes trabajamos en este ámbito. Un cliente plantea un proyecto, lo analizas y entiendes perfectamente cómo desarrollarlo. Aun así, detectas problemas importantes en la forma en que se quieren utilizar los datos, en los accesos, en la automatización de determinadas decisiones o en el propio planteamiento del sistema.

Entonces explicas que así no debería hacerse, que habría que modificar algo o introducir determinadas garantías antes de seguir adelante.

Y después aparece otra persona que dice que sí.

Desde fuera puede parecer que esa persona ha sabido resolver algo que tú no has sido capaz de resolver. Sin embargo, muchas veces no estamos ante una diferencia de capacidad técnica, sino ante una diferencia de criterio profesional.

Hay proyectos que no rechazo porque no sepa hacerlos, sino precisamente porque sé suficientemente bien lo que estoy haciendo como para entender que no deberían desarrollarse de esa manera.

Eso, evidentemente, tiene un coste. Puedes perder una oportunidad, puedes parecer alguien que está poniendo problemas mientras otro proveedor “aporta soluciones” e incluso puedes quedar peor ante un cliente que únicamente ve que una persona le ha dicho que no y otra le ha dicho que sí.

Pero competir por ver quién pone menos límites no me parece una buena forma de trabajar.

El cliente también tiene responsabilidad

Tampoco tendría sentido cargar toda la responsabilidad sobre quien desarrolla la solución. El cliente decide qué problema quiere resolver, qué datos pone a disposición del sistema, qué finalidad persigue y cómo va a utilizar el resultado.

Externalizar la parte técnica no elimina automáticamente su responsabilidad sobre el uso que hace de la herramienta.

Si una empresa decide utilizar Inteligencia Artificial para evaluar personas, clasificar candidatos, analizar empleados o intervenir en decisiones relevantes, no puede desentenderse de las consecuencias simplemente porque la solución la haya desarrollado un tercero.

Dependiendo del proyecto, del tipo de datos y del papel que tenga cada parte, las obligaciones podrán ser diferentes. Pero el hecho de contratar a un proveedor no convierte al cliente en un espectador.

El desarrollador tampoco debería limitarse a ejecutar

Lo contrario también es cierto. Quien desarrolla o integra una solución de IA no debería actuar como un simple ejecutor técnico cuando detecta riesgos evidentes.

Si sabemos que determinados datos no deberían circular de una determinada manera, que un sistema necesita control de accesos, que una automatización puede afectar a personas o que una decisión no debería dejarse completamente en manos de un modelo, tenemos que advertirlo.

No hace falta convertir cada proyecto en una auditoría jurídica. Pero tampoco tiene sentido comportarse como si privacidad, seguridad, RGPD o AI Act fueran cuestiones que deben revisarse al final.

Diseñar primero y preguntar después suele salir caro.

Casos en los que conviene frenar antes de construir

Hay situaciones en las que merece la pena parar y revisar el planteamiento antes de seguir adelante. Puede ocurrir cuando una automatización utiliza datos personales y los envía a varios servicios externos; cuando un chatbot interno puede acceder a documentación que no debería estar disponible para todos los empleados; cuando una IA se utiliza para clasificar o evaluar personas; o cuando un proceso automatizado termina tomando decisiones sin una supervisión adecuada.

También puede ocurrir con proyectos aparentemente sencillos. Una empresa puede querer conectar su CRM con un modelo de Inteligencia Artificial para analizar información comercial y, técnicamente, la integración puede ser muy fácil.

Sin embargo, la pregunta importante no es únicamente si podemos conectar ambos sistemas. También debemos preguntarnos qué información estamos enviando, a qué proveedor, para qué finalidad y con qué garantías.

Que exista una API no significa que automáticamente tengamos derecho a enviarle cualquier dato.

Decir «no» no significa cancelar el proyecto

Esta es probablemente una de las ideas más importantes. Decir “así no” no significa necesariamente decir “no” al proyecto; muchas veces significa rediseñarlo.

Puede que no podamos utilizar determinados datos, pero sí otros. Puede que la IA no deba tomar una decisión automáticamente, pero sí preparar una recomendación que revise una persona. Puede que no queramos enviar determinada documentación a un servicio externo, pero sí podamos utilizar una arquitectura privada.

También puede ocurrir que un chatbot no deba acceder a toda la información de la empresa, pero sí hacerlo con permisos bien definidos por departamentos.

La buena consultoría no consiste únicamente en bloquear riesgos, sino en intentar encontrar una forma de conseguir el objetivo sin cruzar determinadas líneas.

Porque el cliente normalmente no necesita exactamente la solución que ha imaginado; necesita resolver un problema. Y casi siempre hay más de una forma de hacerlo.

El problema de decir que sí a todo

Estamos en un mercado en el que prácticamente cualquiera puede presentarse como experto en Inteligencia Artificial. En ese contexto, decir que sí a todo puede parecer una ventaja comercial.

El problema es que una ilegalidad no desaparece porque alguien encuentre una forma técnicamente elegante de automatizarla. Y una mala práctica tampoco se convierte en buena simplemente porque funcione.

Por eso conviene diferenciar entre saber utilizar herramientas y asumir la responsabilidad de diseñar soluciones que van a formar parte de procesos reales de una empresa.

No es lo mismo saber conectar una API que entender las consecuencias de lo que estamos construyendo.

La responsabilidad es compartida

En un proyecto de Inteligencia Artificial puede haber varias partes implicadas: cliente, consultor, desarrollador, proveedor tecnológico, responsables internos y, en algunos casos, otras figuras.

Cada una tendrá unas obligaciones diferentes. Pero hay algo que debería ser común: nadie debería asumir que la responsabilidad siempre corresponde al otro.

El cliente no puede pensar que todo queda cubierto porque ha contratado a un proveedor. Y el proveedor no debería pensar que puede hacer cualquier cosa porque “el cliente lo ha pedido”.

La responsabilidad empieza precisamente cuando entendemos qué estamos construyendo, qué datos utilizamos, qué riesgos existen y qué consecuencias puede tener el sistema.

El contrato también debería dejar claro qué IA se utiliza y para qué

Cuando un proyecto incorpora Inteligencia Artificial, no basta con definir el alcance técnico y el precio.

Conviene —y en determinados casos debe— quedar documentado qué sistema de IA se va a utilizar, qué función cumple dentro del proceso, qué datos va a recibir, qué proveedores intervienen y qué decisiones puede o no puede tomar.

Esto es especialmente importante cuando intervienen datos personales, información confidencial, servicios externos o procesos que pueden afectar a personas.

El cliente debería saber qué herramientas forman parte de la solución. Y el proveedor debería dejar claro qué papel desempeña cada una, qué limitaciones tiene y qué parte del tratamiento o de la automatización depende de terceros.

También conviene concretar aspectos como quién valida los resultados, quién autoriza los cambios relevantes en el sistema, qué ocurre si se sustituye un modelo o proveedor y qué responsabilidades corresponden a cada parte.

No es lo mismo contratar una automatización que utiliza un modelo concreto bajo unas determinadas condiciones que descubrir meses después que esa pieza ha cambiado. Ese cambio puede modificar también el recorrido de los datos o las garantías del servicio.

La transparencia entre cliente y proveedor no debería empezar cuando aparece un problema, sino formar parte del diseño del proyecto desde el principio.

La verdadera profesionalidad empieza cuando sabes cuándo no hacerlo

Para mí, un buen profesional de Inteligencia Artificial no es quien consigue hacer cualquier cosa que le pidan, sino quien sabe distinguir entre lo técnicamente posible, lo legalmente admisible y lo profesionalmente responsable.

Y a veces eso significa decir que no. O, mejor dicho, decir: “Así, no.”

Porque muchas veces el verdadero valor profesional no está en saber conectar una API, automatizar un flujo o integrar un modelo. Está en saber cuándo hacerlo, cómo hacerlo y cuándo conviene plantear otra solución.

Eso también es trabajar con Inteligencia Artificial con criterio.