En Faktoria hemos diseñado y construido Begira, nuestro sistema de gobernanza, riesgo y cumplimiento para los proyectos con inteligencia artificial. Contamos por qué lo creamos, cómo funciona nuestra gobernanza de la IA y qué ha cambiado en nuestra forma de diseñar y desplegar estas soluciones.

Durante años, nuestro trabajo se medía principalmente por el funcionamiento de la solución. Si la centralita enrutaba bien las llamadas, si el contact center respondía a tiempo y si la automatización ahorraba horas, el proyecto cumplía su objetivo técnico.

Con la inteligencia artificial, esa comprobación sigue siendo necesaria, pero ya no basta. Lo vimos en uno de los primeros proyectos que analizamos con nuestra metodología: un voicebot que atendía llamadas en tres idiomas, conectado al ERP y a la PBX de una empresa. Técnicamente funcionaba bien. Entendía, respondía y resolvía.

Aun así, quedaban cuestiones por resolver antes de abrir el servicio en las condiciones previstas. Había que documentar dónde se procesaban los datos de las llamadas, definir cómo se identificaba a quien llamaba antes de facilitarle información de su cuenta y establecer cómo se le informaba de que estaba hablando con una IA. Las pruebas de funcionamiento no resolvían por sí solas ninguna de esas decisiones. Finalmente, se optó por un piloto controlado, con condiciones y plazos recogidos en el análisis.

Un sistema puede funcionar técnicamente y, aun así, necesitar ajustes antes de ponerse al servicio de las personas.

Qué entendemos por gobernanza de la IA

De esa necesidad nació Begira, nuestro sistema de gobernanza, riesgo y cumplimiento de IA, lo que en el sector se conoce como GRC-IA. Lo hemos diseñado y programado en Faktoria y lo hemos ido afinando sobre proyectos reales. Su nombre, que significa mirar, resume lo que buscamos: examinar cada sistema antes de desplegarlo y volver a evaluarlo cuando cambian las condiciones en las que se aprobó.

Begira, en euskera, significa «mirar» y es exactamente lo que hace.

Gobernar es tener claro quién decide y con qué criterio. Gestionar el riesgo es analizar qué puede salir mal, a quién le afectaría y cómo prevenirlo o reducir sus consecuencias. Y cumplir es identificar qué obligaciones corresponden a cada proyecto y comprobar cómo se atienden: desde el Reglamento Europeo de Inteligencia Artificial y la normativa de protección de datos hasta la legislación laboral o las normas sectoriales de atención a la clientela, cuando resulten aplicables.

Queremos incorporar esas preguntas de gobernanza de la IA al propio trabajo técnico. Si se plantean cuando ya están decididos la arquitectura, el proveedor y los flujos de datos, corregir la solución suele ser más difícil. Por eso buscamos abordarlas desde el diseño y mantenerlas presentes durante la operación.

En el centro están las personas. Cuando valoramos un riesgo, nos preguntamos tanto por sus consecuencias para la organización como por el daño que puede causar a quien utiliza el sistema o se ve afectado por él. Hablamos de discriminación, privacidad, falta de información o dificultades para cuestionar una decisión. También analizamos cuándo debe intervenir una persona y cómo hacer posible esa intervención.

Medimos cada riesgo por el daño que puede causar a las personas, no solo a la organización.

Cómo hemos puesto en marcha la gobernanza de la IA

Cuando empezamos a diseñar Begira tuvimos clara una cosa. No queríamos otro formulario de cumplimiento que se rellena al final y se archiva. Queríamos un sistema que acompañara al proyecto desde el primer boceto hasta mucho después de su puesta en marcha.

Begira organiza el análisis en cuatro pilares. La gobernanza establece responsables, roles y seguimiento. La deontología recoge los principios éticos que orientan nuestras decisiones y los límites que fijamos como organización. El cumplimiento identifica las normas aplicables y las evidencias necesarias para comprobar sus requisitos. Y el pilar de riesgo y seguridad analiza qué puede salir mal, qué controles se han previsto y cómo se comprueba su eficacia.

El análisis realiza un recorrido de hasta doce pasos. Comienza por identificar el sistema, los roles y la gobernanza del expediente, y por delimitar su contexto y alcance. Después llega la clasificación inicial, que orienta el análisis según la finalidad, las características y el uso previsto de la solución. Esta clasificación ayuda a identificar posibles prácticas prohibidas, supuestos de alto riesgo y obligaciones específicas. También permite ajustar la profundidad del análisis. Un sistema que no se clasifica como de alto riesgo puede seguir necesitando medidas de privacidad, transparencia o seguridad; lo importante es determinar cuáles corresponden a su caso.

Cuando el sistema es de alto riesgo, el análisis se vuelve más exigente. Comprobamos los requisitos que el Reglamento impone a estos sistemas, desde la gestión de riesgos y la calidad de los datos hasta la supervisión humana, la precisión y la ciberseguridad, y determinamos si quien lo va a utilizar debe realizar una evaluación de impacto sobre los derechos fundamentales. Esa evaluación es una obligación de la organización que despliega el sistema, no del proveedor, pero la integramos en el expediente sección a sección, con su responsable y su evidencia. Es ahí donde se ve con más claridad a quién puede afectar una decisión automatizada y qué garantías hacen falta para protegerlo.

Antes incluso de esa clasificación, cada proyecto es analizado bajo principios deontológicos. Revisamos nueve principios éticos que consideramos innegociables y, para cada uno, qué medida lo garantiza, cómo se comprueba y qué prueba lo respalda. Lo aplicamos a todos los proyectos, sea cual sea su nivel de riesgo, porque un sistema que no respeta alguno de esos principios no se despliega. Después llegan el contexto y el alcance del sistema, la privacidad, los requisitos normativos, los riesgos con sus controles y las evidencias.

Hay dos reglas importantes en nuestra forma de trabajar la gobernanza de la IA. La primera es que una respuesta favorable debe tener un respaldo suficiente para lo que se está afirmando. Distinguimos entre declaraciones, documentación y comprobaciones, y valoramos su alcance. Que un proveedor declare que no utiliza los datos para entrenar sus modelos es información relevante; para dar esa condición por suficientemente respaldada, debemos revisar también en qué términos se compromete y a qué servicio y configuración se refiere.

La segunda es separar la elaboración, la revisión y la aprobación del expediente. Nuestra metodología asigna esas funciones a personas distintas. Quien aprueba debe hacerlo sobre el análisis y sus evidencias, sin convertir una carencia pendiente en una conclusión favorable mediante una simple validación.

El expediente puede quedar incompleto, pendiente de evidencias o a falta de revisión. También puede concluir con un resultado desfavorable, una propuesta limitada a un piloto controlado, un resultado favorable condicionado a medidas con plazo o un resultado favorable dentro del alcance evaluado.

Las condiciones deben distinguir lo que tiene que resolverse antes de iniciar el uso de lo que puede quedar sujeto a seguimiento. Un piloto o una aprobación condicionada no permiten eludir una obligación aplicable ni un bloqueo que impida ese uso. Cada bloqueo se acompaña de su motivo y de la acción necesaria para resolverlo.

El día del despliegue no es el final

Esta es probablemente la idea que más ha cambiado nuestra manera de pensar la gobernanza de la IA. Podemos analizar un sistema antes de ponerlo en marcha, documentarlo y aprobar su uso. Pero las condiciones que hemos evaluado pueden cambiar durante su funcionamiento.

El proveedor actualiza el LLM que hay detrás. Una herramienta pensada para entender por qué llaman los clientes empieza a utilizarse para evaluar a quienes los atienden. Los datos pasan a procesarse en otro país porque cambia el servicio contratado. Aunque el equipo no haya modificado su propio código, la solución puede haber cambiado en aspectos relevantes para el análisis.

Por eso cada expediente tiene una fecha de próxima revisión, las condiciones llevan plazo y las evidencias deben revisarse según su vigencia y alcance.

La metodología también contempla la aceptación expresa de determinados riesgos residuales por una persona con autoridad y durante un periodo definido. Esa aceptación debe quedar justificada y separada de la elaboración y revisión del análisis. No permite dar por cumplida una obligación incumplida ni dejar sin efecto los límites que impiden desplegar el sistema.

Hemos identificado diferentes tipos de cambios que pueden exigir una nueva evaluación; entre ellos, un nuevo modelo o proveedor, una modificación de la finalidad, cambios en las personas afectadas o una variación de las normas aplicables.

Al aprobar, la herramienta conserva una huella del contenido evaluado para poder contrastarlo con modificaciones posteriores del expediente. Ese mecanismo necesita un procedimiento que lleve al expediente los cambios que se produzcan en el sistema real. La revisión depende también de que los responsables comuniquen y documenten esas modificaciones.

La aprobación se refiere a un sistema, un uso y unas condiciones concretas, que deben seguir siendo válidas durante su funcionamiento.

Las reglas con las que analizamos cada proyecto también tienen versiones, igual que el software. Cada expediente conserva la referencia a los criterios utilizados. Si más adelante necesitamos explicar una decisión, podremos reconstruir qué se evaluó, qué evidencias se tuvieron en cuenta y con qué criterio se aprobó.

En qué nos apoyamos

Begira combina obligaciones normativas, marcos reconocidos y políticas propias de Faktoria. Buscamos distinguir cuándo una regla responde a una exigencia legal, cuándo recoge una interpretación y cuándo expresa un criterio interno, que puede ser más exigente que el mínimo normativo.

Del marco de gestión de riesgos de IA del NIST tomamos como referencia sus cuatro funciones (gobernar, mapear, medir y gestionar) para organizar el análisis. Su enfoque de gobernanza también nos ayuda a examinar cómo se distribuyen las responsabilidades y cómo gestiona la organización sus sistemas de IA.

Para el análisis de los requisitos de alto riesgo nos hemos apoyado además en las guías publicadas por la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) a partir del sandbox español de IA. Su enfoque nos ha servido para distinguir entre disponer de documentación y haber implantado y comprobado las medidas descritas.

Estas referencias aportan una estructura común y facilitan explicar de dónde proceden nuestros criterios. Su utilización no acredita por sí sola el cumplimiento de un proyecto: esa conclusión requiere analizar el caso concreto, las obligaciones aplicables y las evidencias disponibles.

Lo que ha cambiado en nuestra forma de trabajar

Begira está cambiando el orden de las conversaciones. Hablamos de gobernanza de la IA cuando diseñamos la arquitectura, cuando elegimos un proveedor, cuando decidimos dónde se procesarán los datos y cuando valoramos qué parte de una interacción conviene automatizar y dónde hace falta intervención humana.

Lo estamos aplicando a proyectos reales y nuestro objetivo es extender progresivamente esta forma de trabajar a los proyectos de Faktoria que incorporan IA.

Creemos en lo que la inteligencia artificial puede aportar a las comunicaciones de una empresa. Por eso queremos poder explicar cómo funciona cada solución, cuáles son sus límites y qué medidas permiten utilizarla de forma adecuada durante su vida en producción.

Eso importa a las personas que llaman, a quienes trabajan junto a estos sistemas y a las organizaciones que los ponen a su servicio.

Creemos que la próxima etapa exigirá algo más que incorporar nuevas funciones de IA. Exigirá saber qué hace cada sistema, bajo qué condiciones puede utilizarse, quién ha aprobado ese uso y cuándo debe revisarse.

Si estás incorporando inteligencia artificial a tus comunicaciones o a tu atención al cliente, en Faktoria podemos ayudarte a diseñar la solución y a evaluar las condiciones para ponerla en marcha y mantenerla.