Protocolo de IA para una entidad social: qué permitir, qué proteger y quién responde

Un modelo práctico para acordar usos, herramientas, datos, revisión humana y responsabilidades, y pasar de las pruebas individuales a un criterio compartido en la entidad.

De las pruebas individuales a un criterio compartido

Una profesional prepara un borrador con IA, otra resume un documento y una tercera prueba una herramienta para traducir materiales. La pregunta no es solo si las herramientas funcionan: ¿la entidad sabe cuáles se están utilizando, con qué información y quién revisa los resultados?

La jornada sobre inteligencia artificial y cumplimiento normativo organizada el 6 de octubre por Suport Tercer Sector de Fundesplai abordó esa distancia entre el uso individual y la responsabilidad organizativa. Según la crónica de Xarxanet, las intervenciones se centraron en la protección de datos, los protocolos internos y una perspectiva humana que evite nuevas desigualdades.

Una respuesta práctica es disponer de un protocolo breve que el equipo pueda consultar antes de utilizar una herramienta. No una declaración genérica sobre innovación, sino unas reglas que ayuden a decidir qué se puede hacer, qué necesita autorización y qué queda fuera.

1. Aprobar usos concretos, no una herramienta para todo

Autorizar una aplicación no significa autorizar cualquier documento ni cualquier tarea. El protocolo debe vincular la herramienta con una finalidad y un tipo de información.

Para empezar, la entidad puede establecer tres grupos:

  • Usos permitidos con revisión: ideas para actividades, primeros borradores de textos públicos o resúmenes de documentos publicados, sin información personal ni confidencial.
  • Usos que requieren valoración previa: actas de reuniones, documentos internos, grabaciones o cualquier tarea con datos personales. No se introduce la información hasta que se haya aprobado ese uso y sus garantías.
  • Usos excluidos del protocolo inicial: decisiones automatizadas sobre acceso a servicios, priorización de personas o valoraciones profesionales de casos. Cualquier propuesta en este ámbito exige un análisis específico, no una excepción improvisada.

Esta clasificación es una propuesta de gobernanza interna. No sustituye el análisis normativo de cada uso ni significa que cualquier tratamiento sea aceptable solo porque alguien lo autorice.

2. Definir qué no se debe introducir

La regla debe ser fácil de aplicar: no copiar expedientes, informes sociales, datos de salud, credenciales ni documentos confidenciales en herramientas no aprobadas para esa finalidad. Tampoco adjuntar listas de personas atendidas para probar una funcionalidad.

Quitar el nombre no siempre evita la identificación. Una combinación de municipio, edad, situación familiar y circunstancias poco habituales puede permitir reconocer a una persona. Para formar al equipo, es mejor crear ejemplos ficticios que transformar superficialmente un caso real.

Antes de un uso con datos personales, hay que revisar la finalidad, la base jurídica, los roles de las partes, las condiciones del servicio, los accesos, la conservación, las posibles transferencias y las garantías necesarias, con la persona responsable de protección de datos o asesoramiento especializado cuando corresponda. Una cuenta de pago, por sí sola, no resuelve estas cuestiones.

3. Asignar quién aprueba y quién responde

Una entidad pequeña no necesita crear un comité para cada prueba. Sí necesita una persona de referencia y un circuito comprensible.

La dirección aprueba el marco de uso; la persona de referencia mantiene la lista de herramientas y finalidades autorizadas; las responsables de cada área validan la adecuación profesional de los resultados. Las cuestiones de privacidad y seguridad se derivan a los perfiles competentes.

Quien utiliza la IA no puede dar por revisado un documento porque «la herramienta lo ha dicho». Y nadie debería descubrir, ante una incidencia, que no estaba claro a quién había que avisar.

4. Convertir la revisión humana en una tarea concreta

Revisar no es solo releer. Antes de compartir un resultado, hay que comprobar datos, fuentes, nombres, fechas, tono y posibles omisiones. En una traducción o adaptación a lenguaje claro, también se debe verificar que no cambie el sentido ni desaparezcan condiciones importantes.

Para una comunicación sobre una convocatoria, por ejemplo, la persona revisora debe contrastar requisitos y plazos con la fuente oficial. Para una propuesta de actividad, debe valorar accesibilidad, adecuación al grupo y recursos necesarios. Son ejemplos de revisión, no casos reales de implantación.

Si la verificación exige más tiempo que hacer la tarea sin IA, conviene replantear la prueba. El objetivo no es utilizar la tecnología a cualquier precio.

5. Saber qué hacer cuando algo falla

El protocolo debe explicar qué hacer ante un dato introducido por error, una cuenta comprometida o un contenido inadecuado que ya se ha compartido: detener el uso afectado, avisar por el canal interno establecido y conservar solo la información necesaria para valorar el incidente.

La persona responsable debe coordinar las medidas de contención y corrección, y determinar con los perfiles competentes si hacen falta otras actuaciones. No se debe intentar resolver una exposición de información copiándola en otra herramienta para preguntarle qué hacer.

El registro de incidencias tampoco debe convertirse en una copia de los documentos sensibles: debe recoger lo necesario para gestionar y aprender del problema.

Un modelo breve para llevar a una reunión de equipo

Esta ficha puede servir como punto de partida para redactar el protocolo propio:

  • Finalidad: qué tareas queremos mejorar y cuáles excluimos.
  • Herramientas y cuentas: cuáles están aprobadas y para qué usos.
  • Información: qué se puede utilizar y qué requiere valoración previa.
  • Responsabilidades: quién autoriza, quién resuelve dudas y quién valida cada resultado.
  • Verificación: qué se debe comprobar antes de compartirlo.
  • Incidencias: a quién se avisa y cómo se detiene un uso problemático.
  • Formación: cómo conocerán las reglas profesionales y voluntariado.
  • Revisión: fecha, responsable y cambios que obligan a revisar el protocolo.

El documento debe tener versión, aprobación y una ubicación conocida. Una prueba inicial acotada permite detectar dudas antes de ampliar los usos. Hay que revisarlo también cuando cambian las herramientas, las condiciones del proveedor o la información tratada.

Gestión compartida, criterio humano

En MIDUE ya hemos hablado de las decisiones antes de incorporar IA y de tener la información ordenada. El protocolo da un paso distinto: convierte esos criterios en acuerdos operativos del equipo.

MIDUE integra documentación, gestión de personas, procesos de calidad y accesos por roles. Esa base puede ayudar a ordenar responsabilidades e información dentro de la entidad. No implica que la plataforma autorice herramientas externas, controle los usos de IA del equipo o garantice por sí sola el cumplimiento del protocolo.

Un buen protocolo no debe dejar al equipo sin margen para aprender. Debe evitar que cada persona asuma riesgos sin saberlo y asegurar que la tecnología siga al servicio de las personas.

¿Quieres ver MIDUE funcionando con los datos de tu entidad?

Demostración gratuita y sin compromiso, con un profesional que conoce el Tercer Sector.